提取、转换和加载 (ETL)
组织面临的一个常见问题是如何以多种格式从多个数据源收集数据。 然后，需要将其移动至一个或多个数据存储区。 目标的数据存储类型可能与数据源不同。 通常格式不同，或者需要在将数据加载至最终目标之前对其进行整形或清理。
过去几年以来，行业中已开发了多种工具、服务和过程来解决这些难题。 不管采用哪种过程，往往都需要协调工作，并在数据管道中应用某种级别的数据转换。 以下部分重点介绍执行这些任务的常用方法。
提取、转换、加载 (ETL) 过程
提取、转换、加载 (ETL) 是一种用于从不同数据源收集数据的数据管道。 然后根据业务规则对数据进行转换，并将数据加载到目标数据存储区中。 ETL 中的转换工作在专用引擎中进行，通常涉及到使用临时表暂时保存正在转换、并最终要载入其目标的数据。
数据转换通常涉及到各种操作，例如筛选、排序、聚合、联接数据、清理数据、删除重复数据和验证数据。
通常，三个 ETL 阶段是同时运行的，以节省时间。 例如，在提取数据时，转换过程可以处理已收到的数据并做好加载数据的准备，加载过程可以开始处理已准备好的数据，而无需等待整个提取过程完成。
相关服务：
其他工具：
提取、加载、转换 (ELT)
提取、加载、转换 (ELT) 与 ETL 的唯一不同之处在于转换的发生位置。 在 ELT 管道中，转换发生在目标数据存储中。 在不使用单独转换引擎的情况下，将使用目标数据存储的处理功能来转换数据。 这就从管道中删除了转换引擎，从而简化了体系结构。 此方法的另一个好处是，缩放目标数据存储也会缩放 ELT 管道性能。 但是，仅当目标系统足够强大，可以有效转换数据时，ELT 才能正常工作。
ELT 的典型用例属于大数据领域。 例如，首先可将所有源数据提取到 Hadoop 分布式文件系统、Azure Blob Storage 或 Azure Data Lake gen 2（或者两者组合）等可缩放存储中的平面文件。 然后，可以使用 Spark、Hive 或 PolyBase 等技术查询源数据。 ELT 的关键之处在于，用于执行转换的数据存储是最终要在其中使用数据的同一数据存储。 此数据存储直接从可缩放的存储读取，而不是将数据载入其自身的专有存储。 此方法可跳过 ETL 中存在的数据复制步骤，该步骤对于大型数据集运行往往很耗时。
ELT 管道的最后一个阶段通常是将源数据转换为最终格式，对于需要支持的查询类型，此格式更为有效。 例如，可将数据分区。 此外，ELT 可能使用 Parquet 等优化的存储格式，以纵栏表形式存储面向行的数据，并提供优化的索引。
相关Microsoft服务：
数据流和控制流
在数据管道的上下文中，控制流确保有序处理一组任务。 要实施这些任务的正确处理顺序，可以使用优先约束。 可将这些约束视为工作流关系图中的连接器，如下图所示。 每个任务都有结果，例如成功、失败或完成。 只有在前面的任务已完成并生成了结果时，后面的任务才会启动处理。
控制流以任务的形式执行数据流。 在数据流任务中，会从源提取数据、转换数据，或将数据载入数据存储。 一个数据流任务的输出可以是下一个数据流任务的输入，数据流可以并行运行。 与控制流不同，无法在数据流中的任务之间添加约束。 但是，可以添加数据查看器来观察每个任务处理的数据。
在上图中，控制流包含多个任务，其中一个任务是数据流任务。 有一个任务嵌套在容器中。 可以使用容器来提供任务结构和工作单元。 一个例子是使用容器来重复集合中的元素，例如文件夹中的文件，或数据库语句。
相关服务：
流数据和热路径体系结构（推送、转换和加载）
如果需要 Lambda 热路径或 Kappa 体系结构，另一个选项是订阅各种数据源，因为正在生成数据。 与 ETL 或 ELT 不同，它在计划的批处理中对数据集进行作，实时流式处理在到达时处理数据，从而实现即时见解和作。
在流式处理体系结构中，数据从事件源引入消息中转站或事件中心（例如 Azure 事件中心、Kafka），然后由流处理器（例如 Fabric Real-Time Intelligence、Azure 流分析、Apache Flink）进行处理。 在将结果路由到下游系统（如仪表板、警报或数据库）之前，处理器应用转换，例如筛选、聚合、扩充或联接引用数据（全部动态）。
此方法非常适合低延迟和持续更新至关重要的方案，例如：
- 监视异常的制造设备
- 检测金融交易中的欺诈行为
- 为物流或运营提供实时仪表板
- 基于传感器阈值触发警报
技术选择
后续步骤
相关资源
以下参考体系结构演示了 Azure 上的端到端 ELT 管道：