你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

测试车队的数据分析

Microsoft Fabric
Azure 数据资源管理器
Azure 事件中心
Azure Functions
Azure 事件网格

汽车原始设备制造商 (OEM) 需要解决方案,以最大限度地缩短试驾和将试驾诊断数据提供给研发工程师之间的时间。 随着车辆越来越自动化,软件的开发生命周期越来越短,这需要数字反馈循环变得更快。 新技术可以使数据访问大众化,并为研发工程师提供对试驾诊断数据的准实时见解。 使用 Copilot 进行数据科学和数据工程的数据分析,可进一步缩短洞察时间。 安全数据共享可以增强 OEM 和供应商之间的协作,并缩短开发周期。

本文中的指南适用于遥测场景和批量试驾数据引入场景。 该架构侧重于处理诊断数据的数据平台,以及用于数据可视化和数据报告的连接器。

体系结构

显示流式汽车处理数据和文件的分析数据流的示意图。

下载包含本文中所有示意图的 PowerPoint 文件

数据流

以下数据流与上图相对应:

  1. 数据捕获设备连接到车辆网络,并收集高分辨率车辆信号数据和视频。 (1a) 设备使用 MQTT 客户端将实时遥测消息或 (1b) 请求将记录的数据文件上传到 Azure 事件网格 MQTT 代理功能。 此功能使用声明检查模式。

  2. (2a) 事件网格将实时车辆信号数据路由到 Azure Functions 应用。 此应用将车辆信号解码为 JavaScript 对象表示法 (JSON) 格式,并将其发布到事件流。

    (2b) 事件网格协调从设备客户端上传到 Lakehouse 的文件。 完成的文件上传会触发一个管道,该管道对数据进行解码,并以适合引入的格式(如 parquet 或 CSV)将解码文件写入 OneLine。

  3. (3a) 事件流路由解码的 JSON 车辆信号,以便在事件屋中引入。

    (3b) 数据管道触发从 Lakehouse 引入解码文件。

  4. Eventhouse 使用 更新策略来扩充数据并将 JSON 数据扩展到合适的行格式,例如位置数据可能会聚集以与地理空间分析保持一致。 每次引入新行时,实时分析引擎都会调用关联的 Update() 函数。

  5. 数据工程师和数据科学家使用Kusto 查询语言 (KQL) 来构建分析用例。 用户将经常使用的情况存储为可共享用户定义函数。 工程师通过 Copilot 支持使用内置的 KQL 函数,例如聚合、时序分析、地理空间聚类分析、窗口化和机器学习插件。

  6. 研发工程师和数据科学家使用笔记本来分析数据并生成测试和验证用例。

    1. 研发工程师使用 KQL 查询集Copilot 进行实时智能来执行交互式数据分析。

    2. 数据工程师和数据科学家使用笔记本来存储和共享其分析过程。 借助笔记本,工程师可以使用 Azure Spark 来运行分析,并使用 Git 管理笔记本代码。 用户可以将 Copilot 用于数据科学和数据工程,以使用上下文代码建议支持其工作流。

  7. 研发工程师和数据科学家可以将 Power BI 与动态查询或实时分析仪表板配合使用,以创建可视化效果以与业务用户共享。 这些可视化效果调用用户定义的函数,以便于维护。

  8. 工程师还可以将更多工具连接到 Microsoft Fabric。 例如,他们可以将 Azure Managed Grafana 连接到 eventhouse 或创建直接查询 eventhouse 的 Web 应用程序。

  9. 数据工程师和研发工程师使用Data Activator创建反射项来监视条件和触发操作,例如触发 Power Automate 流以实现业务集成。 例如,如果设备运行状况下降,Data Activator可以通知 Teams 频道。

  10. 数据收集器配置使工程师能够更改数据捕获设备的数据收集策略。 Azure API 管理抽象和保护合作伙伴配置 API 并提供可观测性。

KQL 数据库架构

显示用于提取、扩展和扩充数据的 KQL 数据库及方法的关系图。

设计表架构时,请考虑fact表和dimension表之间的差异。 遥测是一个 fact 表,因为车辆信号以流式传输方式逐渐追加,或者作为完整记录的一部分追加,并且遥测不会更改。 您可以将机队元数据分类为缓慢更新的 fact 表。

车辆遥测数据位于原始表中。 您可以使用以下消息处理概念来组织数据进行分析和报告:

  • 使用如下方法创建更新策略,将 JSON 遥测文件扩展到单个车辆信号记录中:

    • mv-expand(),用于将存储在 JSON 结构中的复杂值扩展为具有单独信号的行。
    • geo_point_to_h3cell()geo_point_to_geohash(),用于将纬度和经度转换为 geohash 以进行地理空间分析。
    • todouble()tostring(),用于将从动态 JSON 对象中提取的值强制转换为适当的数据类型。
    • lookup 使用维度表中的值扩展记录。
  • 使用唯一键和时间戳上的聚合函数创建 Signals Dedupedtake_any() 具体化视图。 此具体化视图删除重复信号。

  • 使用时间戳上的聚合函数创建 Signals Last Known Valuesarg_max() 具体化视图。 此具体化视图提供车辆的最新状态。

  • 使用汇总运算符和时间箱(例如每小时每天)创建 Signals Downsampled 具体化视图。 此具体化视图聚合信号并简化整个车队的报告。

  • 创建提供异常情况检测或根本原因分析的用户定义函数。

    • 使用时序函数进行异常情况检测和预测,以检测潜在问题并预测故障。

    • 使用扫描运算符从数据中扫描、匹配和生成序列。 工程师可以使用 scan 运算符来检测序列。 例如,如果发生特定事件,则必须在特定时间内发生后续事件。

    • 使用 autocluster 机器学习插件来查找离散属性的常见模式。

  • 使用用户定义的函数执行地理空间分析。 使用地理空间分析函数将坐标转换为合适的网格系统,并针对数据执行聚合。

  • 创建车队元数据表,用于存储车辆元数据和配置的更改。 创建车队元数据最后一个 已知值具体化视图,以基于上次修改的列存储车辆车队的最新状态。

组件

以下关键技术实现此工作负载。 对于体系结构中的每个组件,请使用良好架构框架中可用的相关服务指南。 有关详细信息,请参阅 架构良好的框架服务指南

  • Fabric Real-Time Intelligence 支持提取动态车辆遥测的见解和可视化效果。 您可以使用事件流和时序 KQL 数据库来存储和分析数据,并使用反射来响应事件。

  • Data Activator是一种无代码工具,可用于在模式或条件更改数据时自动执行操作。

  • 事件网格是一种高度可扩缩的完全托管型发布/订阅消息分发服务,支持 MQTT 协议。 车辆可以使用事件网格来发布和订阅主题,例如,它们可以发布遥测数据并订阅命令和控制消息。

  • Azure 事件中心是一个实时数据流式处理平台,非常适合以低延迟每秒流式处理数百万辆车辆事件。

  • Functions 是一种无服务器解决方案,它通过使用所选语言通过事件驱动触发器和绑定大规模简化车辆遥测事件。

  • Azure 托管 Grafana 是基于 Grafana Labs 中的软件的数据可视化平台。 Microsoft 管理和支持 Azure 托管 Grafana。

  • Azure 应用程序服务让您能够生成和托管 Web 应用、移动后端和 RESTful API,这些 API 提供对存储在 Fabric 中的车辆遥测数据的访问权限。 此方法简化了消耗。

  • API 管理是一种适用于 API 的混合式多云管理平台。

备选方法

您还可以使用以下 Azure 服务来实现此体系结构:

  • Azure Blob 存储 存储大量非结构化数据,例如车辆的录制、日志和视频。 它将替换 OneLake 存储。

  • Azure 数据资源管理器是一个快速、完全托管的数据分析服务,可用于实时分析。 它将替换 Fabric Real-Time Intelligence KQL 数据库。

  • Azure Batch 是可用于解码复杂文件的替代方法。 此方案涉及大量文件,每个文件超过 300 兆字节。 这些文件需要基于文件版本或文件类型的不同解码算法。 您可以使用 Fabric 或使用 Blob 存储和 Azure 数据资源管理器来实现以下方法。

显示用于解码复杂文件的替代 Batch 方法的示意图。

  1. 用户或录制设备将录制的数据文件上传到 Lakehouse。 上传完成后,它会触发计划解码的 Functions 应用。

  2. 计划程序启动一个 Functions 应用,该应用基于文件类型、文件大小和所需的解码算法创建批处理作业。 应用从池中选择大小合适的虚拟机并启动作业。

  3. Batch 在作业完成后将生成的解码文件写回到 Lakehouse。 此文件必须适合采用事件屋支持的格式直接引入。

  4. Lakehouse 触发一个函数,该函数在文件写入时将数据引入到 eventhouse 中。 此函数在必要时创建表和数据映射,并启动引入过程。

  5. KQL 数据库从 Lakehouse 引入数据文件。

此方法提供以下好处:

  • Functions 和 Batch 池能够稳健高效地处理可缩放的数据处理任务。

  • Batch 池提供有关处理统计信息、任务队列和批处理池运行状况的见解。 你可以可视化状态、检测问题并重新运行失败的任务。

  • Functions 和 Batch 的组合支持 Docker 容器中的即插即用处理。

  • 可以使用现成虚拟机在非高峰期处理文件,从而节省资金。

方案详细信息

汽车 OEM 使用大量原型和测试车队来测试和验证多项车辆功能。 测试过程成本高昂,因为需要真实的驾驶员和车辆,并且某些特定的实际道路测试场景必须多次通过。 集成测试对于评估复杂系统中电气、电子和机械组件之间的交互尤其重要。

为了验证车辆功能并分析异常和故障,您必须从电子控制单元 (ECU)、计算机节点、控制器局域网 (CAN) 和以太网等车辆通信总线以及传感器捕获数千兆字节的诊断数据。

过去,车辆中的小型数据记录器服务器将诊断数据本地存储为主数据格式 (MDF)、多媒体融合扩展 (MFX)、CSV 或 JSON 文件。 试驾完成后,服务器会将诊断数据上传到数据中心,数据中心对其进行处理并将其提供给研发工程师进行分析。 此过程可能需要数小时,有时数天。 最近的场景使用遥测引入模式,例如基于消息队列遥测传输 (MQTT) 的同步数据流,或准实时文件上传。

可能的用例

  • 车辆管理会评估每个车辆在多个测试场景中的性能和收集的数据。

  • 系统和组件验证使用收集到的车辆数据来验证车辆组件的行为是否在行程中处于操作范围内。

  • 异常情况检测可实时定位传感器值相对于其典型基线模式的偏差模式。

  • 根本原因分析使用机器学习插件(如聚类分析算法)来确定多个维度上值分布的变化。

  • 预测性维护结合了多个数据源、扩充的位置数据和车辆信号,以预测组件故障时间。

  • 可持续性评估通过驾驶员行为和能源消耗来评估车辆运行对环境的影响。

  • 旨在了解和提高车辆在赛前、期间和赛后性能的汽车比赛。

注意事项

这些注意事项实施 Azure 架构良好的框架的支柱原则,即一套可用于改善工作负荷质量的指导原则。 有关详细信息,请参阅 Microsoft Azure 架构良好的框架

可靠性

可靠性可确保应用程序符合你对客户的承诺。 有关详细信息,请参阅可靠性设计评审核对清单

  • Azure 可用性区域是同一 Azure 区域中独特的物理位置。 可用性区域可以保护 Azure 数据资源管理器计算群集和数据不会在部分区域发生故障。

  • 使用 Azure 数据资源管理器中的业务连续性和灾难恢复 (BCDR),你的业务能够在发生中断时继续正常运转。

  • 后续数据库在生产和非生产用例之间分隔计算资源。

安全性

安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息,请参阅可靠性设计审查检查表

请务必了解汽车 OEM 与 Microsoft 之间的责任分工。 在车辆中,OEM 拥有整个堆栈,但随着数据迁移到云,一些责任也转让给了 Microsoft。 Azure 平台即服务 (PaaS) 在物理堆栈(包括操作系统)上提供内置安全性。

所有这些功能都有助于汽车 OEM 为其车辆遥测数据创建安全环境。 有关详细信息,请参阅 Fabric 中的安全

成本优化

成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息,请参阅成本优化设计评审核对清单

此解决方案使用以下做法来帮助优化成本:

  • 正确配置 Raw 和 Signals 表的热缓存和冷存储。 热数据缓存存储在 RAM 或 SSD 中,性能更佳。 但是,冷数据便宜 45 倍。 为用例设置适当的热缓存策略,例如 30 天。

  • 在 Raw 和 Signals 表上设置保留策略。 确定信号数据何时不再相关(例如 365 天后),并相应地设置保留策略。

  • 考虑哪些信号与分析相关。

  • 当您查询信号上一个已知值、重复数据删除信号和下采样信号时,请使用具体化视图。 具体化视图消耗的资源比对每个查询执行源表聚合要少。

  • 考虑实时数据分析需求。 为实时遥测表设置流式引入,以提供引入和查询之间的延迟小于 1 秒。 此方法会增加 CPU 周期和成本。

性能效率

性能效率是指工作负荷能够以高效的方式扩展以满足用户对它的需求。 有关详细信息,请参阅性能效率设计评审核对清单

  • 如果每天记录的数据文件的数量和大小超过 1,000 个文件或 300 MB,请考虑使用 Batch 进行解码。

  • 考虑在引入后执行常见的计算和分析,并将其存储在其他表中。

  • 使用 KQL 查询最佳做法可加快查询的运行速度。

  • where使用子句定义时间范围以减少查询的数据量。 如果常见的搜索条件不是基于时间的,例如按记录 ID 和信号名称进行筛选,请考虑更改信号表的数据分区策略。 当 KQL 数据库扩展为包含数十亿或数万亿条记录时,适当的数据过滤变得至关重要,尤其是在考虑活动分区策略时。

警告

在更改数据分区策略之前,请咨询支持团队。

部署此方案

使用分步教程部署此方案。 本指南演示如何部署免费实例、分析 MDF 文件、引入数据和执行多个基本查询。

作者

本文由 Microsoft 维护, 它最初是由以下贡献者撰写的。

主要作者:

其他参与者:

若要查看非公开领英个人资料,请登录领英。

后续步骤