数据工程中的数据集成原理

介绍

多个数据源包括供应商、产品、工具、第三方和设备。在大小和速度方面的数据复杂性更高。以及来自消费者的其他数据请求。尽管如此，只有您和您的团队才能将这一切整合起来。

什么是数据集成？

数据集成是我们作为数据工程师所做的大部分工作的总称。它是识别数据、接收数据、转换数据并将其提供给消费者的过程和方法。它“整合”了企业内外的新旧数据并进行准备。如果数据集成团队有一句拉丁格言，它就像美国的格言：E Pluribus Unum，或“out of many one [table]”。

然而，与只是数据集成一部分的数据摄取不同，集成进入了数据工程的分析阶段。它位于可视化层以及商业智能 (BI) 工具中发生的事情。所以它对数据的结果承担了更多的责任。

来源：——datasolutionslab

在过去的十年中，数据集成经历了几次时尚，所以你可以原谅你没有跟上时代。提取、加载和转换 (ELT) 方法受到青睐，部分原因是分析成本大幅下降。更少的团队担心来自 AWS 或 GCP 的意外审计。ELT 还允许您为未来不可预见的用例做准备，因此少做就意味着更大的灵活性。结果，人们将更多的原始数据存储在湖中，以供以后分析和转换。

而且由于数据集成向下延伸到可视化层，数据工程师对这些最终消费者负责。消费者需要数据准确、可用且符合预期。但是，如果您的企业从数千个数据源中提取数据并运行数千个有向无环图 (DAG)，那么为所有这些消费者提供服务就变得相当具有挑战性。您不能每次都手动编写这些集成代码并仍然维护它们。

这就是为什么有 Airflow 和 Spark 等管道自动化工具来帮助您运行和管理许多DAG并准确集成数据的原因。这也是 Databank 这样的可观察性平台存在的原因：帮助您了解每个阶段数据的性质和质量，满足您的数据 SLA 并实现通用可用性以支持每个人的产品和项目。

数据整合六大原则

牢记上述定义，以下是更多创新集成的六项原则。

1.永远不要无缘无故整合

如果您无法明确说明数据的目的，则永远不要整合数据。换句话说，保护您现有的数据并通过一系列逻辑探索来强制执行每个数据集成要求。否则，这些差异会像放射性物质一样扩散开来，导致剩下的一切都腐烂。

大数据的历史是写成的，它将分为两个部分：每个企业都抓住一切可能的时期，以及企业意识到这不是一个好主意之后的时期。在这个早期阶段，我们看到了诸如主数据管理 (MDM) 和中央数据平台 (CDP) 等举措。存储系统充满了如此多的不相关和非结构化数据，以至于无法使用。

这就是为什么 Gartner 几年前的一份报告发现只有 20% 的数据计划已经完成，并且只有 8% 的数据提供了真正的价值。现代数据工程师在处理新数据源之前更了解并需要证明。假设您需要其他团队在输入需求时填写简报。在这种情况下，您会发现它有助于迫使业务经理或数据科学家考虑他们的需求的实用性、优点和缺点，并考虑在团队时间和整个系统稳定性方面进行权衡。

2. 通过 ELT 进行质量检查

即使您正在为以后的转换 (ELT) 加载数据，您仍然需要进行一些修改以评估和确保质量。例如，列检查和意外的空值。在这里拿数据“生态系统”类比是有帮助的——如果您认为通过组织的所有数据都是活跃的，并且有时包含错误（病毒），那么您需要检查点和隔离区。否则，如果您拥有一个高度互连的数据环境，其中包含无数高度可变的资源和数千个 DAG（并且您没有经常检查数据质量），那么您的系统就很容易受到数据错误疾病的影响。

问题在于 Airflow 和 Spark 等管道工具无法控制数据质量。它们旨在告诉您作业是否正确运行 - 但作业可以正确运行，并且数据可能完全损坏。这种情况经常发生在运行没有人想过要仔细检查并且包含缺失数据或列的旧内部数据时。或者，第三方来源缺乏您的目标系统所期望的粒度，或者直接从物联网设备接收几乎没有结构化的部分时，就会发生这种情况。

但这就是存在数据可观察性工具（如数据库）的原因：它们允许您在流程的每个阶段对健康数据流进行采样，并且：

• 设置异常检测警报
• 自动暂停存在严重数据问题的作业
• 对同时发生的错误进行分组以帮助隔离根本原因
• 根据您的参数判断质量

3. 将流水线分阶段进行调试

继上一点之后，创建模块化。由于可能显而易见的原因，一条被分成许多独立段的管道更容易诊断和调试——必须对单片线路进行端到端检查。

如果您从多个来源获取数据，这一点尤其重要。一组理想且高度稳定的通道来自最少数量的、具有高度数据完整性的易于理解的来源。最复杂的管道则相反——来自多个来源不明和完整性存疑的来源。最后一种类型是我们大多数人使用的。因此，在它们与任何重要的交互之前，在预链接层中规范化和检查这些资源。

4. 设置 SLA 日期并制定事件管理计划

谁期望您提供什么数据以及何时？这是企业数据集成策略中的一个基本问题，数据工程师可能花费的时间可能比他们应该考虑的要少。很容易陷入数据封地的机制中，而忽略了为数据消费者提供服务并应将他们的需求放在首位的事实。

这就是为什么最好：

• 建立内部数据 SLA——让您保持敏锐并与客户保持一致
• 发布数据事件管理计划——这样当出现问题时，每个人都清楚自己的角色和该怎么做

5. 建立集中的流程和定义

发布数据字典并实现一种集中管理模式的方法，即使您现在所能做的只是创建一个共享表。当您想要扩展您的系统时，您也将忙于记录您所做的事情或培训他人。这将改变数据，这些微小的模式变化将意味着以下三件事之一：

1. 在集成存储库时，您将永远依赖一次性编码和部落知识；

2. 你有一个痛苦的数据清理项目即将到来，或者；

6.自动化大多数任务

这主要不言自明。与人类一样聪明，作为品味创造者、梦想家和提问者一样必要，数据集成的某些元素最好留给机器。如果您可以自动化编排、数据质量检查、异常检测和列级分析，您和您的工程师就可以处理更高价值的任务。例如，您正在衡量数据平台的成功和/或发现优化或构建以减少技术债务的机会。

但是，当然，虽然您应该信任您的自动化元素，但您也应该验证它们。为此，可观察性平台可能是无价的。

数据集成工具

您的工作需要哪些数据集成工具？不要被所有关于“现代数据技术堆栈”的讨论所迷惑——您听到的大多数示例来自无代码/低代码用例（例如，帮助消费者使用 Salesforce 数据做出快速决策）或使用案例分析。这意味着你在媒体上看到的所有文章都有一个偏见：它们不适合你。现代数据工程师的技术堆栈看起来不同，可以包括以下工具的任意组合。

管道工作流管理和编排

• Apache Airflow、Dragster、Prefect – 开源工作流管理

• Jenkins、CircleCI、GitLab Argo – DevOps 工具

• Kafka、Beam、Flink – 流媒体系统

计算工具

• Apache Spark – 分布式数据处理的开放系统

• Google Dataflow – 基于 Apache Beam 构建的托管数据流系统

• DBT – 基于 SQL 的数据转换工具

接收数据的工具

• Fivetran – 用于集成企业数据的托管工具

• Meltano ELT – 开源数据集成工具

• Airbyte ELT – 适用于中端市场的托管数据集成工具

数据存储

• S3、Azure Blob 存储、Google Drive 或 GCS – 云数据湖

结论

什么是最好的企业数据集成架构？它是适合您的。ELT 或 ETL、Airflow 或 Spark，以及无代码或亲代码架构都是考虑因素，没有统一的答案。但是，请遵循六项原则。如果您需要理由、一致的清理、考虑模块化的构建、设置数据 SLA、集中模式以及自动化不需要您注意的所有内容，那么您将处于最佳状态。并且要知道您是否处于良好状态并保持良好状态，这是可观察性的。

• 数据集成向下延伸到可视化层，数据工程师对这些最终消费者负责。消费者需要数据准确、可用且符合预期。
• 大数据的历史是写成的，它将分为两个部分：每个企业都抓住一切可能的时期，以及企业意识到这不是一个好主意之后的时期。在这个早期阶段，我们看到了诸如主数据管理 (MDM) 和中央数据平台 (CDP) 等举措。
• 提取、加载和转换 (ELT) 方法受到青睐，部分原因是分析成本大幅下降。更少的团队担心来自 AWS 或 GCP 的意外审计。ELT 还允许您为未来不可预见的用例做准备，因此少做就意味着更大的灵活性。

原文标题：The Principles of Data Integration in Data Enginering

原文作者：Chetan Dekate 

原文链接：https://www.analyticsvidhya.com/blog/2022/10/the-principles-of-data-integration-in-data-enginering/