通过

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

使用 Azure Synapse Analytics 进行近实时 Lakehouse 数据处理

Azure AI 搜索
Azure Cosmos DB
Azure Data Lake
Azure 事件中心
Azure Synapse Analytics

数据驱动型企业需要使其后端和分析系统与面向客户的应用程序保持近实时同步。 事务、更新和更改的影响必须通过端到端进程、相关应用程序和联机事务处理 （OLTP） 系统准确反映。 OLTP 应用程序中更改的可容忍延迟，以反映使用数据的下游系统可能只有几分钟时间。

本文介绍一个端到端解决方案，用于准实时数据处理，以保持湖屋数据同步。该解决方案使用Azure 事件中心、Azure Synapse Analytics 和 Azure Data Lake Storage 进行数据处理和分析。

注释

可以使用 Microsoft Fabric 实现类似的体系结构，该结构提供统一的软件即服务（SaaS）平台，用于数据引入、转换、存储和分析。 在这种情况下，Fabric 取代了体系结构的 Azure Synapse Analytics 组件，并提供用于实时数据处理和分析的集成功能。 有关详细信息，请参阅 Fabric Real-Time Intelligence。

Apache® 和 Apache Spark 是美国和/或其他国家/地区 Apache Software Foundation 的注册商标或商标。 使用这些标记并不暗示获得 Apache Software Foundation 的认可。

体系结构

展示端到端数据处理解决方案的数据流的图示。

下载此体系结构的 Visio 文件 。

数据流

  1. 更改数据捕获（CDC）是源系统侦听更改的先决条件。 Debezium 连接器 可以连接到不同的源系统，并在发生更改时利用这些更改。 连接器可从各种关系数据库管理系统 (RDBMS) 捕获更改并生成事件。 安装 Debezium 连接器需要 Kafka 连接系统。

  2. 连接器提取更改数据并将捕获的事件发送到事件中心。 事件中心可从多个源接收大量数据。

  3. 事件中心直接将数据流式传输到 Azure Synapse Analytics Spark 池，或以原始格式将数据发送到 Data Lake Storage 登陆区域。

  4. 其他批处理数据源可以使用 Azure Synapse Analytics 管道将数据复制到 Data Lake Storage，并使其可用于处理。 端到端提取、转换和加载（ETL）工作流可能需要链接不同的步骤或添加步骤之间的依赖关系。 Azure Synapse Analytics 管道可以协调整个处理框架中的工作流依赖项。

  5. Azure Synapse Analytics Spark 池使用完全支持的 Apache Spark 结构化流式处理 API 来处理 Spark 流式处理框架中的数据。 数据处理步骤包含数据质量检查和高级业务规则验证。

  6. Data Lake Storage 以开放式 Delta Lake 格式存储已验证的数据。 Delta Lake 为现有数据湖提供原子性、一致性、隔离性和持久性 (ACID) 语义和事务、可缩放的元数据处理以及统一的流式和批数据处理。

    使用索引进行查询加速可以提高 Delta Lake 性能。 来自 Data Lake Storage 验证区域的数据也可以作为进一步高级分析和机器学习的源。

  7. Data Lake Storage 验证区域中的数据，通过更多规则转换和扩充到其最终处理状态，加载到专用 SQL 池以运行大规模分析查询。

  8. Power BI 使用通过专用 SQL 池公开的数据来生成企业级仪表板和报表。

  9. 还可以在 Data Lake Store 中使用捕获的原始数据和 Delta 格式的已验证数据来执行以下任务：

    • 通过 Azure Synapse Analytics 无服务器 SQL 池进行计划外分析和探索分析

    • 通过 Azure 机器学习训练和部署机器学习模型

  10. 对于某些低延迟接口，必须对数据进行非规范化处理，以实现个位数服务器延迟。 此用例主要用于 API 响应。 此方案在 NoSQL 数据存储（例如 Azure Cosmos DB）中查询文档以实现个位数毫秒响应。

  11. Azure Cosmos DB 分区策略可能无法有效地支持所有查询模式。 如果是这种情况，可以通过为 API 需要使用 Azure AI 搜索访问的数据编制索引来增强解决方案。 Azure Cosmos DB 和 AI 搜索可以满足大多数需要低延迟查询响应的方案。 例如，零售应用程序在 Azure Cosmos DB 中存储产品目录数据，但需要全文搜索功能和灵活的索引。 AI 搜索可以索引数据并提供高级搜索功能，例如自动完成、同义词和语义排名。 当 Azure Cosmos DB 索引限制限制限制复杂的搜索方案时，这些功能非常有用。

组件

此解决方案使用以下 Azure 组件：

  • 事件中心 是一种托管的分布式引入服务，可扩展到引入大量数据。 通过使用事件中心发布服务器-订阅者机制，不同的应用程序可以将消息发送到事件中心主题，下游使用者可以连接到和处理这些消息。 事件中心捕获功能可以在消息到达时以 Avro 格式将消息写入 Data Lake Storage。 此功能可实现简单的微批处理和长期保留方案。 事件中心还提供与 Kafka 兼容的 API，并支持架构注册表。 在此体系结构中，事件中心接收来自多个源的 CDC 事件，并将其分发给下游使用者。

  • Data Lake Storage 是一种可缩放且安全的 Data Lake 解决方案。 它形成以原始格式和已验证格式存储所有数据的存储子系统。 在此体系结构中，Data Lake Storage 可大规模处理事务，并支持不同的文件格式和大小。 分层命名空间有助于将数据组织到熟悉的文件夹结构中，并支持适用于 Unix 的可移植操作系统接口（POSIX）权限。 Azure Blob 文件系统 （ABFS） 驱动程序提供与 Hadoop 兼容的 API。

  • Azure Synapse Analytics 是一种无限的分析服务，它结合了数据集成、企业数据仓库和大数据分析。 此解决方案使用以下 Azure Synapse Analytics 生态系统的功能：

    • Azure Synapse Analytics Spark 池 是提供按需 Spark 运行时的群集，用于向开源 Spark 添加内置性能增强功能。 在此体系结构中，客户可以配置灵活的自动缩放设置，通过 Apache Livy 终结点远程提交作业，并使用 Synapse Studio 笔记本界面进行交互式体验。

    • Azure Synapse Analytics 无服务器 SQL 池 是一项按需查询功能，它提供一个接口，用于使用熟悉的 T-SQL 语法查询 Lakehouse 数据。 没有要设置的基础结构，Azure Synapse Analytics 工作区部署会自动创建终结点。 在此体系结构中，Azure Synapse Analytics 无服务器 SQL 池支持对数据进行基本发现和探索，以便进行计划外查询分析。

    • Azure Synapse Analytics 专用 SQL 池 已预配数据仓库资源。 它们使用列式存储将数据存储在关系表中。 在此体系结构中，专用 SQL 池使用横向扩展体系结构在多个节点之间分配数据处理。 PolyBase 查询将数据引入 SQL 池表。 这些表可以连接到 Power BI 进行分析和报告。

  • Power BI 是一项业务分析服务，提供用于创建和访问报表和仪表板的可视界面。 Power BI Desktop 可连接到各种数据源，将源合并到数据模型中，并生成报表或仪表板。 在此体系结构中，可以使用 Power BI 根据业务需求转换数据，并与客户共享视觉对象和报表。

  • Azure Cosmos DB 是一种全球分布式 NoSQL 数据库服务。 此解决方案对需要个位数毫秒响应时间和高可用性的应用程序使用 Azure Cosmos DB。 Azure Cosmos DB 在所有 Azure 区域提供多区域写入。

  • AI 搜索 是一种由 AI 提供支持的平台即服务（PaaS），使开发人员能够为其应用程序和网站构建丰富的搜索体验。 如果 Azure Cosmos DB 索引模型对于高级搜索方案过于严格，请使用此解决方案中的 AI 搜索。 AI 搜索支持使用拼写错误、自动完成、语义排名和同义词匹配等功能进行灵活的查询。 可以使用 REST API 或 .NET SDK 查询索引数据。 如果需要从多个索引检索数据，可以将它们合并到单个索引中，或使用 复杂的数据类型 对嵌套结构进行建模。

方案详细信息

要以准实时的方式处理更改的端到端工作流需要：

  • CDC 技术。 OLTP 应用程序可能具有不同的后端数据存储，例如 SQL Server、MySQL 和 Oracle。 第一步是在发生更改时侦听更改，并将它们向前传播。

  • 用于大规模发布更改事件的引入缓冲区。 此服务应能够在消息到达时处理大量数据。 单个订阅者可连接到此系统并处理数据。

  • 分布式可缩放存储，按原始格式原样存储数据。

  • 一个分布式高效流式处理系统，允许用户重启和管理状态。

  • 一个大规模运行的分析系统，为业务决策提供支持。

  • 一个自助服务分析接口。

  • 对于低延迟 API 响应，NoSQL 数据库用于存储数据的非规范化表示形式。

  • （在某些情况下）一个系统，用于为数据编制索引，定期刷新索引，并使最新的数据可供下游使用。

上述所有技术都应使用外围安全、身份验证、授权和数据加密的相关安全构造。

可能的用例

此解决方案适用于以下用例：

  • 需要将更改从 OLTP 传播到联机分析处理 (OLAP) 的行业。

  • 需要数据转换或扩充的应用程序。

实时数据处理方案对于金融服务行业尤其重要。 例如，如果保险、信用卡或银行客户付款后立即联系客户服务，客户支持代理需要获得最新信息。

类似的方案适用于零售、商业和医疗保健行业。 启用这些方案可以简化运营，并提升组织工作效率并提高客户满意度。

注意事项

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

可靠性

可靠性有助于确保应用程序能够履行对客户的承诺。 有关详细信息，请参阅 可靠性设计评审清单。

  • 事件中心在高级层和专用层上提供 90 天的数据保留期。 对于故障转移方案，可在配对区域中设置辅助命名空间，并在故障转移期间激活它。 启用区域冗余，确保针对数据中心故障的复原能力。 可以使用事件中心捕获功能将数据保存到 Data Lake Storage，以便重播和恢复方案。

  • Azure Synapse Analytics Spark 池作业每七天回收一次，因为节点已关闭进行维护。 在处理绑定到系统的服务级别协议（SLA）时，请考虑此活动。 对于恢复时间目标（RTO）大约 15 分钟的情况，此限制并不是问题。 确保自动缩放配置为处理负载高峰和节点故障。

  • 使用具有异地备份和区域冗余存储（ZRS）的专用 SQL 池，以防止区域性和区域性中断。

成本优化

成本优化侧重于减少不必要的开支和提高运营效率的方法。 有关详细信息，请参阅 成本优化的设计评审清单。

  • 可根据工作负载特征从不同的事件中心层中进行选择。 事件中心根据 Data Lake Storage 上存储的数据量单独计费捕获存储。

  • 考虑通过 Data Lake Storage 上的层进行对象生命周期管理。 随着数据老化，可以将数据从热层（需要访问最近的数据进行分析）移到成本较低的冷存储层。 对于长期保留，冷存储层是一种经济高效的选择。

  • 在开发或测试环境中不使用专用 SQL 池时，可暂停该池。 可计划脚本以根据需要暂停池，也可以通过门户手动暂停池。

  • 对于 Azure Synapse Analytics Spark 池，请使用自动缩放根据工作负荷需求动态分配资源，并避免过度预配。 选择满足性能需求的最小池大小，并使用自动终止设置来及时关闭空闲池。 通过最小化随机作、缓存中间结果和优化分区大小来优化 Spark 作业，以减少运行时和资源消耗。 使用 Azure Synapse Analytics 监视工具监视使用情况，并根据作业性能和成本趋势调整配置。

  • 若要优化 Azure Cosmos DB 中的成本效益，请定制索引策略以仅包含必要的路径，从而减少存储和请求单位（RU）消耗。 选择适当的 API 和一致性级别，以满足工作负载需求，而无需过度预配。 使用自动缩放吞吐量根据需求动态调整 RU，并在可能的情况下将工作负荷合并到更少的容器中，以最大程度地减少开销。 使用Microsoft成本管理定期监视使用情况，并设置警报以避免意外费用。

  • 使用 Azure 定价计算器 估算定价。

性能效率

性能效率是指工作负荷能够高效地缩放以满足用户需求。 有关详细信息，请参阅 性能效率的设计评审清单。

  • 可以通过分区来缩放事件中心，从而跨多个并行日志（分区）分布事件以提高吞吐量。 若要保留相关事件的顺序（例如来自同一客户或设备的事件），请发布事件时使用一致的 分区键 。 这种做法可确保所有相关事件路由到同一分区，其中事件中心维护其顺序。 根据预期的事件量调整吞吐量单位（TU）。 使用捕获功能以 Avro 或 Parquet 格式直接写入 Data Lake Storage，以高效下游处理。

  • 可以根据工作负荷设置具有小型、中型或大型虚拟机（VM）SKU 的 Azure Synapse Analytics Spark 池。 还可以在 Azure Synapse Analytics Spark 池上配置自动缩放，以考虑工作负荷中的活动峰值。 如果需要更多计算资源，群集会自动纵向扩展以满足需求，并在处理完成后纵向缩减。

  • Delta Lake 在此体系结构中确保高性能、可靠且可缩放的数据处理具有核心作用：

    • 启用 Delta Lake 中的自动优化和自动压缩功能，以便在写入作期间自动管理小文件并优化数据布局。 这些功能非常适合流式处理或频繁的微批处理引入方案，因为它们减少了手动干预的需求。

    • 用于 OPTIMIZE 将小文件手动压缩为较大的文件。 当你希望提高读取效率并减少流式引入后元数据开销会创建许多小型文件时，这种做法特别有用。

    • 与经常查询的列（如时间戳或客户 ID）一 OPTIMIZE 起使用 ZORDER BY ，以共同分配相关数据。 此查询通过减少读取期间扫描的数据量来提高查询性能。

  • 若要优化专用 SQL 池中用于近实时分析的性能，请执行以下任务：

    • 使用适当的分布方法，例如哈希、轮循机制和复制的方法。
    • 按时间或区域对大型表进行分区以提高查询修剪。
    • 对经常访问的数据使用具体化视图和结果集缓存。
    • 维护 up-to日期统计信息和索引，以高效运行查询。
    • 分配资源类来管理内存和并发。
    • 使用 SQL Insights 和动态管理视图（DMV）等内置工具监视性能。

    这些做法有助于确保大规模分析工作负荷中的低延迟、高吞吐量性能。

  • 若要针对实时分析方案中的性能优化 Azure Cosmos DB，请配置适当的索引策略以减少查询延迟和存储开销，并选择适当的一致性级别来平衡性能与数据准确性。 有效地使用分区来均匀分配工作负荷，并避免热分区。 使用 RU 按需动态缩放，为低延迟全局访问启用多区域写入，并监视吞吐量。 这些做法有助于确保高引入、低延迟工作负荷的响应响应、可缩放性能。

作者

Microsoft维护本文。 以下参与者撰写了本文。

主要作者：

其他参与者：

若要查看非公开的LinkedIn个人资料，请登录LinkedIn。

后续步骤