你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
大数据体系结构管理数据的引入、处理和分析，该数据对于传统数据库系统来说过于庞大或复杂。 进入大数据领域的阈值因组织工具和用户功能而异。 一些组织管理数百 GB 的数据，其他组织管理数百 TB 的数据。 随着处理大数据集的工具的发展，大数据的定义从专注于数据大小转向强调从高级分析派生的值。 尽管这些类型的方案往往具有大量数据。
多年来，数据格局一直在变。 数据的功能和预期功能一直在变。 存储成本急剧下降，而数据收集方法继续扩大。 某些数据以快速的速度到达，需要持续收集和观察。 其他数据到达速度较慢，但通常一次性就会以几十年的历史数据形式到来。 可能会遇到高级分析问题或需要机器学习解决的问题。 大数据体系结构努力解决这些挑战。
大数据解决方案通常涉及以下一种或多种工作负荷：
- 在静止状态下的大数据源的批处理
- 动态大数据的实时处理
- 大数据的交互式探索
- 预测分析和机器学习
需要执行以下任务时，请考虑大数据体系结构：
- 存储和处理数据的规模太大，传统数据库无法容纳。
- 转换非结构化数据以供分析和报告
- 实时或低延迟捕获、处理和分析无限数据流
大数据架构的组件
下图显示了大数据体系结构的逻辑组件。 单个解决方案可能不包含此关系图中的每个项。
大多数大数据体系结构包括以下部分或全部组件：
数据源： 所有大数据解决方案都以一个或多个数据源开头。 示例包括：
- 应用程序数据存储，例如关系数据库。
- 应用程序生成的静态文件，例如 Web 服务器日志文件。
- 实时数据源，例如物联网（IoT）设备。
数据存储： 批处理作的数据通常存储在分布式文件存储中，可以采用各种格式保存大量大型文件。 此类存储通常称为 数据湖。 实现此存储的选项包括 Azure Data Lake Store、Azure 存储中的 blob 容器或 Microsoft Fabric 中的 OneLake。
批处理： 数据集很大，因此大数据解决方案通常使用长时间运行的批处理作业来筛选、聚合数据，并准备数据进行分析。 通常，这些作业涉及读取源文件、处理源文件以及将输出写入新文件。 您可以使用下列选项：
- 在 Azure Databricks 笔记本中使用 Python、Scala 或 SQL 语言。
- 在 Fabric 笔记本中使用 Python、Scala 或 SQL 语言。
实时消息引入： 如果解决方案包含实时源，则体系结构必须捕获和存储实时消息以供流处理。 例如，可以有一个简单的数据存储来收集传入消息进行处理。 但是，许多解决方案需要一个消息引入存储来充当消息的缓冲区，并支持横向扩展处理、可靠传递和其他消息队列语义。 流式处理体系结构的这一部分通常称为 流缓冲。 选项包括 Azure 事件中心、Azure IoT 中心和 Kafka。
流处理： 解决方案捕获实时消息后，它必须通过筛选、聚合和准备数据进行分析来处理它们。 然后，处理过的流数据将写入输出接收器。
- 可以使用开源 Apache 流式处理技术，如 Spark 流式处理、Azure Databricks 中的流式处理技术。
- Azure Functions 是一种无服务器计算服务，可以运行事件驱动代码，非常适合轻型流处理任务。
- Fabric 支持使用事件流和 Spark 处理进行实时数据处理。
分析数据存储： 许多大数据解决方案准备数据进行分析，然后以结构化格式为处理的数据提供服务，分析工具可以查询。 提供这些查询的分析数据存储可以是 Kimball 样式的关系数据仓库。 大多数传统的商业智能（BI）解决方案都使用这种类型的数据仓库。 或者，可以通过低延迟 NoSQL 技术（如 HBase）或交互式 Hive 数据库来呈现数据，该数据库提供分布式数据存储中数据文件的元数据抽象。
- Fabric 提供各种数据存储，包括 SQL 数据库、数据仓库、Lakehouse 和 eventhouse。 这些工具可以提供数据进行分析。
- Azure 提供其他分析数据存储，例如 Azure Databricks、Azure 数据资源管理器、Azure SQL 数据库和 Azure Cosmos DB。
分析和报告： 大多数大数据解决方案都努力通过分析和报告来深入了解数据。 为了允许用户分析数据，体系结构可能包括数据建模层，例如 Azure Analysis Services 中的多维联机分析处理多维数据集或表格数据模型。 它还可能通过使用 Power BI 或 Excel 中的建模和可视化技术来支持自助服务 BI。
数据科学家或数据分析师还可以通过交互式数据浏览分析和报告。 对于这些方案，许多 Azure 服务支持分析笔记本（例如 Jupyter），使这些用户能够将其现有技能与 Python 或 Microsoft R 配合使用。对于大规模数据浏览，可以使用 Microsoft R Server（独立或 Spark）。 还可以使用 Fabric 编辑数据模型，这为数据建模和分析提供了灵活性和效率。
编排： 大多数大数据解决方案都由封装在工作流中的重复数据处理操作组成。 操作执行以下任务：
- 转换源数据
- 在多个源和接收器之间移动数据
- 将处理的数据加载到分析数据存储中
- 将结果直接推送到报表或仪表板
若要自动执行这些工作流，请使用 Azure 数据工厂、Fabric 或 Apache Oozie 和 Apache Sqoop 等业务流程技术。
Lambda 体系结构
使用大型数据集时，运行客户端所需的查询类型可能需要很长时间。 这些查询不能实时执行，它们通常需要分布式处理算法，例如 MapReduce ，这些算法在整个数据集中并行运行。 查询结果与原始数据分开存储，用于进一步查询。
此方法的一个缺点是它引入了延迟。 如果处理需要几个小时，查询可能会返回几小时后的结果。 理想情况下，应实时获得一些结果，可能丢失准确性，并将这些结果与批处理分析的结果相结合。
Lambda 体系结构通过为数据流创建两个路径来解决此问题。 进入系统的所有数据都经过以下两个路径：
批处理层（冷路径）以原始形式存储所有传入数据，并对该数据执行批处理。 此处理的结果以批处理视图的形式存储。
速度层（热路径）可实时分析数据。 设计此层是为了降低延迟，但代价是准确性也会降低。
批处理层将结果馈送到服务层中，后者会编制批处理视图的索引，以便提高查询效率。 速度层会根据最新数据使用增量更新来更新服务层。
由于速度层施加的延迟要求，必须快速处理流入热路径的数据。 快速处理可确保数据可供立即使用，但可能会引入不准确。 例如，考虑 IoT 方案，其中许多温度传感器发送遥测数据。 速度层可能会用于处理传入数据的滑动时间窗口。
流入冷路径的数据不受相同的低延迟要求的约束。 冷路径跨大型数据集提供较高的准确度计算，但可能需要很长时间。
热路径和冷路径最终在分析客户端应用程序处会合。 如果客户端需要及时显示但可能不太准确的实时数据，它将从热路径获取其结果。 否则，客户端会从冷路径中选择结果，以便显示不太及时但更准确的数据。 换言之，一开始可以使用时限相对较短的热路径的数据作为结果，稍后再使用冷路径的准确性较高的数据对结果进行更新。
存储在批处理层的原始数据是不可变的。 传入数据将追加到现有数据，并且不会覆盖以前的数据。 对特定基准值所做的更改存储为新的时间戳事件记录。 时间戳事件记录允许在所收集数据历史记录的任何时间点重新计算。 从原始原始数据重新计算批处理视图的能力非常重要，因为它使新视图在系统的发展过程中得以创建。
Lambda 体系结构中的机器学习
Lambda 体系结构通过提供用于模型定型的历史数据和用于推理的实时数据来支持机器学习工作负载。 批处理层支持使用 Azure 机器学习 或 Fabric 数据科学工作负荷对综合历史数据集进行训练。 速度层有助于实时模型推理和评分。 这种双重方法允许针对完整历史数据训练的模型，同时提供对传入数据流的即时预测。
Kappa 体系结构
Lambda 体系结构的缺点是其复杂性。 处理逻辑显示在两个不同的位置，即冷路径和热路径，通过不同的框架。 此过程会导致两个路径的体系结构重复计算逻辑和复杂的管理。
Kappa 体系结构是 Lambda 体系结构的替代方法。 它的基本目标与 Lambda 体系结构相同，但所有数据通过流处理系统通过单个路径流动。
与 Lambda 体系结构的批处理层类似，事件数据是不可变的，并且会收集所有数据，而不是一部分数据。 数据作为事件流引入到分布式容错统一日志中。 这些事件按顺序排列。一个事件的当前状态只在追加新事件的情况下更改。 与 Lambda 体系结构的速度层类似，所有事件处理都会在输入流上执行，并作为实时视图持久保存。
如果需要重新计算整个数据集（相当于批处理层在 Lambda 体系结构中执行的操作），可以重播流。 此过程通常使用并行度及时完成计算。
Kappa 体系结构中的机器学习
通过单个流式处理管道处理所有数据，Kappa 体系结构可实现统一的机器学习工作流。 此方法简化了模型部署和维护，因为相同的处理逻辑同时适用于历史数据和实时数据。 可以使用 Azure 机器学习或 Fabric 数据科学工作负载生成处理流数据的模型，从而实现持续学习和实时适应。 该体系结构支持联机学习算法，这些算法在新数据到达时以增量方式更新模型。
Lakehouse 的体系结构
Data Lake 是一个集中式数据存储库，用于存储结构化数据（数据库表）、半结构化数据（XML 文件）和非结构化数据（图像和音频文件）。 此数据采用原始原始格式，不需要预定义架构。 数据湖可以处理大量数据，因此它适用于大数据处理和分析。 数据湖使用低成本存储解决方案，从而提供一种经济高效的方法来存储大量数据。
数据仓库是一个集中式存储库，用于存储结构化和半结构化数据以用于报告、分析和 BI 目的。 数据仓库可以通过提供一致和全面的数据视图来帮助做出明智的决策。
Lakehouse 体系结构结合了数据湖和数据仓库的最佳元素。 该模式旨在提供一个支持结构化和非结构化数据的统一平台，从而实现高效的数据管理和分析。 这些系统通常以开放格式（如 Parquet 或 Optimized Row Columnar）使用低成本的云存储来存储原始数据和已处理的数据。
Lakehouse 体系结构的常见用例包括：
- 统一分析： 非常适合需要单个平台进行历史数据分析和实时数据分析的组织
- 数据管理： 确保跨大型数据集的符合性和数据质量
Lakehouse 体系结构中的机器学习
Lakehouse 体系结构通过提供对结构化和非结构化数据的统一访问来支持端到端机器学习工作流。 数据科学家可以使用 Fabric 数据科学工作负载来访问原始数据，以便进行探索分析、特征工程和模型训练，而无需复杂的数据移动。 该体系结构支持完整的机器学习生命周期，从使用 Azure 机器学习或 Fabric 笔记本的数据准备和模型开发到模型部署和监视。 统一存储层支持数据工程师和数据科学家之间的高效协作，同时维护数据世系和管理。
IoT
IoT 表示连接到 Internet 并发送或接收数据的任何设备。 IoT 设备包括电脑、手机、智能手表、智能恒温器、智能冰箱、联网汽车和心脏监测植入物。
连接的设备数量每天都会增长，它们生成的数据量也是如此。 此数据通常在具有重大约束且有时高延迟的环境中收集。 在其他情况下，数千或数百万台设备从低延迟环境发送数据，这需要快速引入和处理。 必须正确计划处理这些约束和唯一要求。
事件驱动的架构是 IoT 解决方案的中心环节。 下图显示了 IoT 的逻辑体系结构。 此图强调体系结构的事件流式处理组件。
云网关通过可靠的低延迟消息传送系统引入云边界的设备事件。
设备可能会直接向云网关或 现场网关发送事件。 现场网关是一种专用设备或软件，通常与接收事件并将事件转接到云网关的设备位于同一位置。 现场网关还可以预处理原始设备事件，包括执行筛选、聚合或协议转换函数。
引入后，事件会经历一个或多个 流处理器 ，这些处理器可将数据路由到目标，例如存储或执行分析和其他处理。
常见的处理类型包括：
将事件数据写入冷存储以存档或批处理分析。
热路径分析。 近乎实时地分析事件流，以检测异常、识别滚动时间窗口的模式，或在流中出现特定条件时触发警报。
处理设备中特殊类型的非遥测消息，例如通知和警报。
用于预测性维护、异常情况检测和智能决策的机器学习。
在上图中，灰色框是与事件流不直接相关的 IoT 系统的组件。 它们包含在关系图中，以确保完整性。
设备注册表 是预配设备的数据库，包括设备 ID 和设备元数据（例如位置）。
预配 API 是用于预配和注册新设备的常见外部接口。
某些 IoT 解决方案允许 命令和控制消息 发送到设备。
IoT 体系结构中的机器学习
IoT 体系结构使用机器学习进行智能边缘计算和基于云的分析。 Edge 设备可以运行轻型模型进行实时决策，而综合模型使用 Azure 机器学习或 Fabric 数据科学工作负载处理云中的聚合数据。 常见应用程序包括预测性维护、异常情况检测和自动响应系统。 该体系结构支持流分析，用于即时见解和批处理，以便使用历史 IoT 数据进行模型训练和优化。