Azure 流分析解决方案模式

与Azure中的其他许多服务一样，流分析最好与其他服务一起使用，以创建更大的端到端解决方案。 本文讨论简单的Azure 流分析解决方案和各种体系结构模式。 可以基于这些模式构建项目以开发更复杂的解决方案。 本文所述的模式可用于各种方案。 特定于方案的模式示例可用于 Azure 解决方案体系结构。

创建流分析作业以驱动实时仪表板体验

使用 Azure 流分析，可以快速创建实时仪表板和警报。 简单的解决方案从事件中心或IoT 中心引入事件，通过流式数据集传输到 Power BI 仪表板。 有关详细信息，请参阅详细的教程使用流分析分析对欺诈性呼叫数据进行可视化，并在Power BI仪表板中可视化结果。

只需几分钟即可使用 Azure 门户生成此解决方案。 无需大量编写代码。 而可使用 SQL 语言来表达业务逻辑。

此解决方案模式提供从事件源到浏览器中Power BI仪表板的最低延迟。 Azure 流分析是唯一具有此内置功能的Azure服务。

对仪表板使用 SQL

Power BI仪表板提供低延迟，但不能使用它生成完整的Power BI报表。 常见报告模式是先将数据输出到 SQL 数据库。 然后使用Power BI的 SQL 连接器查询 SQL 以获取最新数据。

图表显示 SQL 数据库作为流分析和 Power BI 仪表板之间的中介存储。

使用 SQL 数据库时，它提供给你更大的灵活性，代价是延迟略有提高。 此解决方案最适合延迟要求超过一秒的作业。 在使用此方法时，您可以最大化Power BI的功能，以便进一步切分和数据钻取，用于报表分析，并提供更多种类的可视化选项。 此外，你可以灵活地使用其他仪表板解决方案，例如 Tableau。

SQL 不是一种高吞吐量的数据存储。 从 Azure 流分析 到 SQL 数据库的最大吞吐量目前约为 24 MB/秒。 如果解决方案中的事件源以更高的速率生成数据，则你需要使用流分析中的处理逻辑来降低到 SQL 的输出速率。 您可以使用筛选、窗口聚合、结合时间联接进行模式匹配以及分析函数等技术。 可以使用在 Azure 流分析 输出到 Azure SQL 数据库 中描述的技术来优化输出到 SQL 数据库的速率。

使用事件消息传送将实时见解整合到应用程序中

流分析的第二种最常见用途是生成实时警报。 在此解决方案模式中，可以使用流分析中的业务逻辑来检测时态和空间模式或异常，然后生成警报信号。 但是，与流分析使用Power BI作为首选终结点的仪表板解决方案不同，可以使用其他中间数据接收器。 这些接收端包括事件中心、服务总线 和 Azure Functions。 应用程序构建者需要确定哪个数据接收器最适合自己的方案。

需要实现下游事件使用者逻辑以在现有的业务工作流中生成警报。 由于可以在Azure Functions中实现自定义逻辑，因此Azure Functions是执行此集成最快的方法。 有关使用 Azure Function 作为流分析作业的输出的教程，请参阅从Azure 流分析作业运行Azure Functions。 Azure Functions还支持各种类型的通知，包括文本和电子邮件。 您还可以使用逻辑应用程序进行此类集成，在流分析与逻辑应用程序之间使用事件中心。

另一方面，Azure 事件中心服务提供最灵活的集成点。 许多其他服务（如Azure 数据资源管理器）可以处理来自 Event Hubs 的事件。 服务可以直接从Azure 流分析连接到事件中心接收器，以完成解决方案。 事件中心也是此类集成方案Azure上提供的最高吞吐量消息传送代理。

动态应用程序和网站

可以使用Azure 流分析和Azure SignalR 服务创建自定义实时可视化效果，例如仪表板或地图可视化效果。 使用 SignalR 时，可更新 Web 客户端和实时显示动态内容。

通过数据存储将实时见解整合到应用程序中

当今的大多数 Web 服务和 Web 应用程序都使用请求/响应模式来为呈现层提供服务。 请求/响应模式易于构建，并且可以通过无状态前端和可扩展存储（如 Azure Cosmos DB）以较低的响应时间实现轻松扩展。

高数据量通常会在基于 CRUD 的系统中产生性能瓶颈。 事件寻源解决方案模式可用于解决性能瓶颈。 此外，从传统的数据存储中提取时态模式和见解也比较困难，且效率低下。 大量数据驱动的新式应用程序通常采用基于数据流的体系结构。 Azure 流分析作为动态数据的计算引擎是该体系结构中的关键。

在此解决方案模式中，事件通过Azure 流分析处理和聚合到数据存储中。 应用层使用传统的请求/响应模式来与数据存储交互。 由于流分析能够实时处理大量事件，因此应用程序具有高度可伸缩性，无需大量占用数据存储层。 数据存储层在本质上是系统中的具体化视图。 Azure 流分析输出到 Azure Cosmos DB描述如何将Azure Cosmos DB用作流分析输出。

在处理逻辑复杂且需要独立升级某些部分的实际应用程序中，可以将多个流分析作业与事件中心结合使用，其中事件中心作为中间事件代理。

此模式改善了系统的复原能力和可管理性。 但是，尽管流分析保证只处理一次，但重复事件仍会进入中间事件中心（这种情况很少见）。 下游流分析作业非常在回查窗口中使用逻辑键删除重复事件。 有关事件传递的详细信息，请参阅事件传递保证参考文章。

使用引用数据进行应用程序自定义

Azure 流分析参考数据功能专为最终用户自定义设计，例如警报阈值、处理规则和 geofences。 应用层可以接受参数更改，并将其存储在 SQL 数据库中。 流分析作业定期查询数据库中的更改，并使得自定义参数可通过引用数据联接操作进行访问。 有关如何使用引用数据进行应用程序自定义的详细信息，请参阅参考数据联接。

此模式还可用于实现从引用数据定义规则阈值的规则引擎。 有关规则的详细信息，请参阅 在 Azure 流分析。

将机器学习添加到实时见解中

Azure 流分析的内置 Anomaly 检测模型是向实时应用程序引入机器学习的便捷方法。 有关更广泛的机器学习需求，请参阅 Azure 流分析 与 Azure 机器学习 的集成。 可以从Azure 机器学习部署模型，并在流分析查询中将其称为用户定义的函数（UDF）。

对于想要将联机训练和评分纳入同一流分析管道的高级用户，请参阅此示例，了解如何使用 线性回归执行此操作。

实时数据仓库

另一种常见模式是实时数据仓库，也称为流数据仓库。 除了应用程序发送到事件中心和 IoT 中心 的事件外，在 IoT Edge 上运行的 Azure 流分析 还可以用于进行数据清理、数据精简，以及满足数据的存储和转发需求。 在IoT Edge上运行的流分析可以正常处理系统中的带宽限制和连接问题。 流分析可以在写入Azure Synapse Analytics时支持高达 200 MB/秒的吞吐量速率。

存档实时数据用于分析

大部分数据科学和分析活动仍脱机进行。 可以在 Azure 流分析 中，通过 Azure Data Lake Store Gen2 和 Parquet 输出格式来存档数据。 此功能消除了将数据直接馈送到Azure Synapse Analytics、Azure Databricks、Microsoft Fabric和Azure HDInsight的摩擦。 Azure 流分析用作此解决方案中的近实时提取-转换-加载（ETL）引擎。 可以使用各种计算引擎浏览Data Lake中的存档数据。

使用引用数据进行扩充

ETL 引擎通常需要数据扩充。 Azure 流分析 支持通过 SQL 数据库和 Azure Blob 存储的 参考数据 进行数据扩充。 可以在Azure Data Lake和Azure Synapse Analytics中为数据登陆完成数据扩充。

将存档数据中的见解转化为行动

如果将脱机分析模式与近实时应用程序模式相结合，则可以创建一个反馈循环。 该反馈循环可让应用程序自动调整数据的更改模式。 此反馈循环可以像更改警报的阈值一样简单，也可以像重新训练机器学习模型一样复杂。 相同的解决方案体系结构可以应用于在云中和IoT Edge上运行的 ASA 作业。

Apache Kafka 集成

流分析通过 Kafka 终结点使用 Azure 事件中心，支持将 Apache Kafka 作为输入和输出。 此模式使能够：

• 从基于 Kafka 的现有体系结构迁移到Azure
• 将本地 Kafka 群集连接到Azure的混合方案
• 与 Apache Kafka 生态系统工具和连接器集成

选择正确的模式

使用此表来帮助为方案选择适当的模式：

如何监视 ASA 作业

Azure 流分析作业可以运行 24/7 来实时处理传入事件。 流分析的运行时间保证对于整个应用程序的运行状况而言至关重要。 虽然流分析是行业中唯一提供 99.9% 可用性保证的流分析服务，但仍可能会造成一定程度的停机。 多年来，流分析陆续引进了指标、日志和作业状态来反映作业的运行状况。 所有这些都通过 Azure Monitor 服务展示，并可以进一步导出到 OMS。 有关详细信息，请参阅 使用 Azure 门户监控流分析作业。

需要监视两项关键信息：

• 作业失败状态

  首先且最重要的是，需要确保该作业正在运行。 如果作业不是处于运行状态，则不会生成新的指标或日志。 作业可能因各种原因而更改为失败状态，包括 SU 利用率较高（即资源不足）。

• 水印延迟指标

  此指标反映处理管道滞后于挂钟时间的程度（秒）。 某些延迟归因于固有的处理逻辑。 因此，监视趋势的增长比监视绝对值重要得多。 应该通过应用程序设计而不是监视或警报来解决稳定态延迟。

设置警报和仪表板

为主动监视配置Azure Monitor警报：

1. SU 利用率 - 当持续超过 80% 时发出警报，以防止作业失败
2. 水印延迟 - 关于处理滞后增长趋势的警报
3. 输入/输出事件 - 监视是否有突然下降，以表明连接问题
4. 运行时错误 - 跟踪反序列化和数据转换失败

为了获得集中观测性，请将流分析指标和日志导出到Log Analytics工作区。 这样做可以实现以下操作：

• 跨作业相关性和分析
• 用于深度诊断的自定义 Kusto 查询
• 与Azure仪表板和工作簿集成

发生失败时，活动日志和诊断日志是开始查找错误的最佳位置。

构建可复原的任务关键型应用程序

无论 Azure 流分析 的 SLA 保证如何，或者您在运行端到端应用程序时有多谨慎，都会发生中断。 对于任务关键型应用程序，需要为中断做好准备，以便到时能够正常恢复。

对于警报应用程序，最重要的一点是检测下一条警报。 可选择从恢复时的当前时间重启作业，并忽略以往的警报。 作业启动时间语义是根据第一个输出时间而不是第一个输入时间确定的。 输入将后退适当的一段时间，以保证指定时间的第一个输出完成且正确。 因此，你不会收到部分聚合并意外触发警报。

还可选择从过去的某个时间段启动输出。 事件中心和IoT 中心的保留策略都保留合理的数据量，以允许从过去进行处理。 要权衡的利弊是能够以最多的速度赶上当前时间，并及时开始生成新警报。 数据很快就会失去其价值，因此，快速赶上当前时间非常重要。 可通过两种方式快速赶上进度：

• 赶上进度时预配更多的资源 (SU)。
• 从当前时间重启。

从当前时间重启会很简单，弊端是处理期间会留下间隙。 以这种方式重启对于告警方案可能是可行的，但在仪表板方案中可能会有问题，对于存档和数据仓库方案则不切实际。

预配更多资源可以加速处理，处理速度激增造成的影响非常复杂。

• 请测试作业是否可缩放到更多的 SU。 并非所有查询都可缩放。 需确保查询已并行化。

• 请确保上游事件中心或IoT 中心中有足够的分区，可以添加更多吞吐量单位（TU），以缩放输入吞吐量。 请记住，每个事件中心 TU 可以应对的最大输出速率为 2 MB/秒。

• 确保在输出接收器（即 SQL 数据库, Azure Cosmos DB）中预配了足够的资源，以避免限制输出激增，这有时会导致系统暂时冻结。

最重要的是预测处理速率的变化，在投入生产之前测试这些方案，并准备好在故障恢复期间正确缩放处理能力。

在极端情况下，如果传入的事件全部延迟，并且你对作业应用了延迟抵达时限，则可能会删除所有延迟的事件。 最初，删除事件看上去像是一种诡异的行为；但是，在考虑到流分析是一种实时处理引擎的情况下，预期事件传入时间与挂钟时间接近。 它必须删除违反这些约束的事件。

Lambda 体系结构或回填过程

幸运的是，前面的数据存档模式可用于正常处理这些滞后的事件。 其理念是，存档作业按到达时间处理传入的事件，并将这些事件根据其事件时间存档到正确的时间段内，存储于 Azure Blob 或 Azure Data Lake Store 中。 事件在多晚的时间抵达并不重要，它永远不会被删除。 它始终会进入适当的时间桶。 在恢复过程中，可以重新处理已存档的事件，并将结果回填到所选的存储。 这类似于 lambda 模式的实现方式。

回填过程必须使用脱机批处理系统来完成，该系统很可能具有与Azure 流分析不同的编程模型。 这意味着，必须重新实现整个处理逻辑。

对于回填，至少应暂时在输出接收器中预配更多资源来处理比稳定态处理更高的吞吐量，这一点仍很重要。

汇总

不难想象，可将前述所有解决方案模式一起组合到一个复杂的端到端系统中。 该组合系统可以包括仪表板、警报、事件寻源应用程序、数据仓库和脱机分析功能。

关键是在可组合的模式中设计系统，以便可以单独构建、测试、升级和恢复每个子系统。

后续步骤

你已了解了使用Azure 流分析的各种解决方案模式。 接下来，你可以进行深入了解并创建第一个流分析作业：

• 使用 Azure 门户创建流分析作业
• 使用托管标识来保护作业