通常，数据是分步处理、提取和转换的。因此，一系列数据处理阶段可以称为数据流水线。
选择哪种设计模式？
有很多事情需要考虑，即使用哪个数据栈？需要考虑哪些工具？如何从概念上设计数据管道？ETL 还是 ELT？也许是 ETLT？什么是变更数据捕获？
我将尝试在这里讨论这些问题。
数据管道
所以它是一系列数据处理步骤。由于这些阶段之间的逻辑数据流连接，每个阶段都会生成一个输出，作为下一个阶段的输入。
只要A点和B点之间有数据处理，就会有一条数据管道。
数据管道的三个主要部分是源、一个或多个处理步骤和目标。然后可以将从外部 API（源）提取的数据加载到数据仓库（目标）中。这是最常见的数据管道示例，其中源和目标不同。然而，情况并非总是如此，因为也存在目的地到目的地的管道。
例如，数据最初可以作为reference数据仓库中的一个表产生，然后经过一些数据转换后，它可以进入一个新的模式，例如，analytics用于报告解决方案。
在源和目标之间处理数据时，始终存在数据管道。
仅由一个在后端创建的事件数据source，一个使用 Kinesis Firehose 或 Kafka 流构建的事件流，可以提供许多不同的destinations.
考虑来自Google Analytics的用户参与数据，因为它作为事件流流动，可用于用户活动的分析仪表板和用于流失预测的机器学习 (ML) 管道。
尽管使用相同的数据源，但两个管道都是独立运行的，并且必须在用户看到结果之前成功完成。
或者，来自两个或多个source位置的数据可以聚合到一个destination. 例如，来自不同支付商家提供商的数据可以转换为商业智能 (BI) 仪表板的收入报告。
数据质量检查、数据清理、转换、丰富、过滤、分组、聚合以及将算法应用于数据是数据管道中的常见步骤。
架构类型和示例
数据管道架构作为一个术语可能有多种含义，具体取决于具体情况。一般来说，它可以分为概念（逻辑）和平台级别或架构类型。
概念上的逻辑部分描述了数据集是如何处理和从收集到服务的转换，而平台架构则侧重于在给定场景中使用的一组单独的工具和框架，以及它们各自发挥的功能。
这是数据仓库管道的逻辑结构：
编辑
添加图片注释，不超过 140 字（可选）
概念数据管道设计。图片由作者提供
在本文中，我找到了一种从 Firebase/Google Analytics 4 中提取实时数据并将其加载到 BigQuery 中的方法：
这是一个概念性的数据湖管道示例：
例如，在这篇文章中，我之前写过如何从 MySQL 数据库中提取数据，并将其保存在 Cloud Storage 中，以便稍后可以用于分析：
这是一个平台级架构示例：
对于许多湖屋架构解决方案来说，这是一种非常常见的模式。在这篇博文中，我创建了一个定制的数据摄取管理器，当它们在 Cloud Storage 中创建时由新对象事件触发：
Stream流
得益于流处理，应用程序可以触发对新数据事件的即时响应。
Streaming 是企业数据的“必备”解决方案。
流处理将在数据生成时收集和处理数据，而不是像批处理那样以预定频率聚合数据。常见用例是异常检测和欺诈预防、实时个性化和营销以及物联网。数据和事件通常由“发布者”或“来源”产生，并传输到“流处理应用程序”，在数据被发送到“订阅者”之前立即进行处理。很多时候，作为一个source，您可以遇到使用Hadoop、Apache Kafka、Amazon Kinesis等构建的流式应用程序。“发布者/订阅者”模式通常被称为pub/sub.
在此示例中，我们可以设置到AWS Redshift的ELT 流数据管道。当流数据将直接上传到数据仓库表中时，AWS Firehose 交付流可以提供这种类型的无缝集成。然后将数据转换为使用AWS Quicksight作为 BI 工具创建报告。
批量处理
批处理是一种模型，在微批处理和传统批处理中都根据预定的阈值或频率收集数据，然后进行处理。从历史上看，工作负载在数据环境中主要是面向批处理的。然而，现代应用程序不断产生大量数据，企业倾向于微批处理和流处理，即立即处理数据以保持竞争优势。微批量加载的技术包括Apache Spark Streaming、Fluentd 和 Logstash ，它与传统的批处理非常相似，其中事件按计划或以小组的形式处理。
如果您的数据的准确性目前与此无关，这是一个不错的选择。
这种数据管道设计模式更适用于需要持续处理的较小数据集，因为 Athena 根据扫描的数据量收费。
比方说，您不想change log在 MySQL 数据库实例上使用。这将是一个理想的情况，因为支付数据集并不大。
Lambda/Kappa 架构
该架构结合了批处理和流处理方法。它结合了两全其美，并建议必须保留原始数据，例如，在数据湖中，以防您想要再次使用它来构建新管道或调查中断。它同时具有批处理和流（速度）层，有助于即时响应不断变化的业务和市场条件。Lambda 架构有时会非常复杂，需要维护多个代码存储库。
先转换再加载？
ETL被认为是一种传统的方法，也是历史上使用最广泛的方法。随着数据仓库的兴起，ELT变得越来越流行。
确实，如果我们可以为数据仓库中的所有数据管道集中它，为什么我们需要首先进行转换？
虚拟化是另一种流行的数据仓库方法，我们在其中创建数据视图而不是计量表。对业务敏捷性的新要求将成本效益放在发送计划上，数据用户需要查询视图而不是表。
#更改数据捕获CDC是另一种在更改发生时准确更新数据的方法。当通常使用潜在数据管道时，CDC 技术可以在数据发生变化时识别它们并提供有关这些变化的信息。更改通常被推送到消息队列或作为流提供。
如何选择数据流水线架构？
近年来，数据管道等数据架构组件得到发展以支持海量数据。术语“大数据”可以描述为具有三个特征，即体积、多样性和速度。大数据可以在各种用例中开辟新的机会，包括预测分析、实时报告和警报。由于数据量、多样性和速度的显着增加，架构师和开发人员不得不适应新的“大数据”要求。新的数据处理框架不断涌现。由于现代数据流的高速传输，我们可能希望使用流数据管道。然后可以实时收集和分析数据，以便立即采取行动。
然而，流数据管道设计模式并不总是最具成本效益的。
例如，在大多数数据仓库解决方案中，批量数据摄取是免费的。然而，流媒体可能需要付出代价。相同的声明将与数据处理相关。在大多数情况下，流式传输是处理数据的最昂贵方式。
大数据volumes要求数据管道能够同时处理事件，因为它们经常同时发送。数据解决方案必须是可扩展的。
这意味着数据可能以不同的格式通过管道，通常是非结构化或半结构化的。
架构类型取决于多种因素，即destination类型和数据最终必须存放的位置、成本考虑因素以及您团队的开发堆栈以及您和您的同事已经具备的某些数据处理技能。
您的数据管道是否必须进行管理并基于云，或者您更愿意将其部署在本地？
实际上，有许多变量组合可以帮助选择最佳数据平台架构。该管道中的速度或数据流量是多少？您需要实时分析，还是接近实时就足够了？这将解决您是否需要“流”管道的问题。
例如，有一些服务可以创建和运行流式和批式数据管道，即Google Dataflow。那么它与数据仓库解决方案中内置的任何其他管道有何不同？选择将取决于现有的基础设施。例如，如果您有一些现有的Hadoop工作负载，那么 GCP DataFlow 将是一个错误的选择，因为它不会让您重新使用代码（它使用的是 Apachec Beam）。在这种情况下，您可能希望使用适用于Hadoop/Spark代码的GCP Dataproc 。
经验法则是，如果处理依赖于 Hadoop 生态系统中的任何工具，则应使用 Dataproc。
它基本上是一个 Hadoop 扩展服务。
另一方面，如果您不受现有代码的限制，并且希望可靠地处理不断增加的流数据量，那么Dataflow是推荐的选择。如果你喜欢在JAVA中做事，你可以检查这些数据流模板。
Google有一个系统设计指南
结论
大数据对数据开发人员提出了新的具有挑战性的数据架构要求。不断增加的各种数据格式和数据源增加了在不中断生产应用程序的情况下进行数据集成的重要性。企业越来越多地致力于自动化数据集成过程、实时处理流数据以及简化数据湖和仓库的生命周期。考虑到过去十年中数据量、速度和数据格式的多样性不断增加，这确实成为一项具有挑战性的任务。现在，数据管道设计必须稳健，同时又要灵活，以便能够以简化和自动化的方式创建新的数据管道。
使用的增加趋势data mesh/data mart平台需要创建数据目录。为了创建受控的、企业就绪的数据，并为数据消费者提供一种查找、检查和自行提供数据的简便方法，理想情况下，这个过程也应该是自动化的。因此，选择合适的数据管道架构可以有效解决这些问题。