如何选择合适的数据管道设计模式？(数据管道批处理架构模式)

选择哪种设计模式？有很多事情需要考虑，比如使用哪个数据栈？ 需要考虑哪些工具？ 如何从概念上设计数据管道？ ETL 还是 ELT？ 也许是ETLT？ 什么是变更数据捕获CDC？

根据过往数据实施经验，本篇文章尝试回答这些问题。

由于这些数据逻辑处理步骤间数据流的联系，每个处理步骤都会生成一个输出，用作下一个步骤的输入。
只要A点和B点之间有数据处理，就存在一条数据管道。

数据管道的三个主要部分是源、一个或多个处理步骤以及目标。
然后，可以将从外部 API（源）抽取的数据加载到数据仓库（目标）中。
这是最常见的数据管道的示例，其中源和目标不同。
然而，情况并非总是如此，因为目标表映射到目标表的数据管道也存在。
例如，在报表系统中分析数据，数据首先可以作为数据仓库中的参考表被生成，然后经过一些数据转换后，它可以加载到新的schema中。
当数据在源和目标之间进行处理时，始终存在数据管道。

数据管道示例图

由后端服务数据源(使用Apache Plusar或kafka生成的事件流数据)产生的事件流数据可以输送到不同的目标表。
例如来自App点击流数据，因为它作为事件流流动，可用于用户活动的分析仪表板和用于流失预测的机器学习 (ML) 管道。
尽管使用相同的数据源，但这两类管道都是独立运行的，并且必须成功完成才能让用户看到结果。
或者，来自两个或多个源位置的数据可以聚合到一个目标表中。
例如，来自不同支付商家提供商的数据可以转换生成BI 仪表板的收入报表。

数据质量检查、数据清理、转换、丰富数据内容、过滤、分组、聚合以及对数据应用算法是数据管道中的常见步骤。

数据管道架构作为一个术语可能有多种含义，具体取决于具体情况。
一般来说，它可以分为概念和平台级别或架构类型。

概念逻辑部分描述了如何处理数据集并将其从数据采集转换为数据服务，而平台架构则侧重于给定场景中使用的一组单独的工具和框架，以及它们各自发挥的功能。
下图是数据仓库管道的逻辑结构：

数据仓库管道的逻辑结构

这是一个数据湖管道示例：

数据湖管道示例

这是一个平台架构示例：

平台架构示例

通过使用流处理，应用程序可以实时响应新数据事件，这种处理方式成为企业数据必备的解决方案。
流处理在数据产生时便进行数据的采集与处理，与批处理定时固定频率汇集数据的方式不同。
常见应用场景包括异常检测和欺诈预防、实时个性化和营销以及物联网等方面。
数据和事件通常由发布者或源产生并传输到流处理应用程序，在发送到订阅者之前会立即在其中进行处理。
通常，作为源，会遇到使用 Hadoop、Apache Kafka、Apache Plusar等构建的流应用程序。
“发布者/订阅者”模式通常称为发布/订阅。

流处理

在此示例中，我们可以配置流式ELT（提取、加载、转换）管道将数据传输到Apache Doris数据仓库中。
当流数据直接上传到数据仓库表时，Apache Kafka可以提供无缝集成，实现高效的数据传输。
使用 BI（商业智能）工具，可以轻松地转换数据以创建各种报表，从而帮助我们更好地分析和理解数据。

批处理是按照预定阈值或频率收集数据并随后进行处理的方式，既包含微批处理也包含传统批处理。
过去，数据处理的工作重心主要面向批处理。
然而，当前的应用程序不断产生大量数据，企业更倾向于采用微批处理和流处理，即时处理数据以保持竞争优势。
微批量加载技术包括Apache Spark Streaming、Flink和Logstash，其与传统的批处理非常相似，其中事件是按照计划或分组方式进行处理。
如果对数据的准确性要求并不高，那么这是一个不错的选择。

批处理

这种数据管道设计模式更适合需要持续处理的较小数据集。

该架构结合了批处理和流处理方法。
它结合了两种架构方式的优点，并建议必须保留原始数据，例如，保留在数据湖中，以防您想再次使用它来构建新管道或重新数据修改数据。
它具有批处理和流（速度）层，有助于立即响应不断变化的业务需求。
Lambda 架构有时会非常复杂，需要维护多个代码存储库。

Lambda/Kappa 架构

ETL 被认为是一种传统方法，也是过去使用最广泛的方法。
随着数据仓库架构的不断演变和数据湖概念的兴起，ELT 变得越来越流行。
确实，如果我们可以将数据仓库中的所有数据管道汇总起来，为什么我们需要首先进行转换呢？

虚拟化是数据仓库的另一种流行方法，我们在数据上创建视图而不是物化表。
对业务敏捷性的新要求将成本效益放在项目实施的日程上，并且数据消费用户可以查询视图而不是表。

变更数据捕获CDC是在更改发生时准确更新数据的另一种方法。
CDC 技术可以识别发生的数据更改并提供有关这些更改的信息。
更改的数据通常被推送到消息队列或作为流提供。

近年来，数据管道等数据架构组件已经发展到支持海量数据。
“大数据”一词可以被描述为具有三个特征：数量、多样性和速度。
大数据可以在各种场景中开辟新的机会，包括预测分析、实时报告和警报。
由于数据量、多样性和速度的大幅增加，架构师和开发人员必须适应新的“大数据”要求。
新的数据处理框架不断涌现。
由于当今数据流的高速传输，我们可能需要使用流数据管道。
然后可以实时收集和分析数据，以便加快数据分析决策。

然而，流数据管道设计模式并不总是最具成本效益的。

例如，在大多数数据仓库解决方案中，批量数据抽取消耗成本低。
然而，流处理可能需要付出高昂的成本。
同样也适用于数据处理， 在大多数情况下，流处理是数据转换最昂贵的方案。

大数据量要求数据管道能够同时处理事件，因为它们通常是同时发送的。
数据解决方案必须是可扩展的。

多样性意味着数据可能以不同的格式通过管道，通常是非结构化或半结构化的。

架构类型取决于各种因素，即目标表类型和数据最终必须位于的位置、成本考虑因素以及团队的开发技术栈；以及团队已经具备的某些数据处理技能。
数据管道是否必须进行管理且基于云，还是更愿意将其部署在本地？ 实际上，有许多变量组合可以帮助选择最佳的数据平台架构。
该管道中的速度或数据流量是多少？ 是否需要实时分析，或者近实时就足够了？ 这将解决是否需要“流式”管道的问题。

例如，有些服务可以创建和运行流式和批处理数据管道，而有些只能处理流式任务，例如Logstash只。
那么它与数据仓库解决方案中构建的任何其他管道有何不同？ 选择将取决于现有的基础设施。
例如，如果你有一些现有的 Hadoop 批处理任务，那么Logstash流处理将是一个错误的选择，因为它不允许您重复使用代码。
在这种情况下，需要使用适用于 Hadoop/Spark 代码。

大数据为数据开发人员提出了新的具有挑战性的数据架构要求。
不断新增的数据格式和数据源，加大了在不中断生产应用程序的情况下数据集成的重要性。
企业越来越致力于自动化数据集成过程、实时处理流数据以及简化数据湖和仓库的生命周期。
考虑到过去十年中数据量、速度和数据格式的多样性不断增加，这确实成为一项具有挑战性的工作。
现在，数据管道设计必须稳健，同时灵活，以便能够以简化和自动化的方式创建新的数据管道。

使用数据架构和数据集市平台的日益增长的趋势，需要创建数据目录去满足数据管道建设的需求。
为了创建受控的、企业可用的数据，并为数据消费者提供一种简单的方法来查找、检查和自行提供数据，这个过程最好也应该自动化。
因此，选择正确的数据管道设计模式可以有效解决这些问题。