本文深入探讨数据摄取的主要架构模式，助力有效数据集成与分析。
原文标题：独家 | 数据摄取第一部分：体系结构模式
原文作者：数据派THU
冷月清谈：
怜星夜思：
2、如何应对ETL和ELT之间的选择困惑？
3、实时数据处理的未来趋势是什么？
原文内容
作者：janmeskens翻译：陈超校对：赵茹萱本文约5000字，建议阅读10+分钟
本文探讨了如何选择合适的数据摄取技术的体系结构范例。
在前两篇文章中，我全面地探索了数据摄取这一打通操作和分析世界的基本原则。数据摄取对于从原始操作环境众多来源——通常被称为“操作平面”——到分析的领域，或“分析平面”传输数据至关重要。这种转移对于释放分析赋权的全部潜力至关重要。
数据摄取是操作平面(数据产生的地方)和分析平面(数据被转换成分析产品，如人工智能模型、仪表板和api)之间的关键环节（图片来源：作者）。
这种授权的本质是生成数据驱动的见解和实施人工智能模型的能力，依赖于各种数据源。一个组织的分析能力通常与它能有效分析的数据源的数量直接相关。因此，选择正确的数据摄取策略至关重要。这些策略必须足够强大，能够处理各种相关数据源，从CRM、ERP和金融系统等标准操作应用程序，到物联网传感器、API等非常规应用程序，以及(抓取)文档、图像和视频等各种格式。
数据摄取是更广泛的数据平台难题中的一个关键部分。摄取策略的选择取决于底层的体系结构设计，并且可以通过各种各样的工具风格来执行。(图片：作者)。
从更广泛的角度来看，数据摄取虽然只是一个元素，但显然是组织中更大的数据平台难题的关键组成部分。该数据平台通常作为数字化转型计划的基石，协助组织实现其业务目标。数据平台的核心包括各种体系结构模式和一系列工具，每一个都在其功能和有效性方面发挥着至关重要的作用。
在专门讨论数据摄取的两篇文章中的第一篇文章中，本文探讨了指导如何选择合适的数据摄取技术的体系结构范例。我的目标是提炼每种模式的精华，揭示它们对数据摄取过程的重要含义。提出这些模式的目标是识别并克服某些障碍，这些障碍通常会使理论上最直白、但绝对必要的任务变得复杂:在分析框架中集成数据。掌握数据摄取的重要性对于保证组织数据生态系统中数据的流畅过渡和有效利用至关重要。
模式1：统一数据存储库
我们研究的第一个体系结构方法是统一数据存储库模式，其中单个存储系统满足操作应用程序需求和分析处理。通常，这个系统是一个关系数据库管理系统(RDBMS)。在这种设置中，日常操作和数据分析都使用同一个数据库，从而消除了在不同存储解决方案之间传输数据的必要性。
统一的数据存储库满足操作应用程序的需求，并支持分析处理。分析性见解是通过虚拟化、使用视图或复制和转换数据生成的(图片来源：作者)。
在这种方法中，有两个流行的子模式:
1. 虚拟化——这涉及到创建虚拟数据库层或视图，这些层或视图在数据库中的可操作表之上提供分析透视图。这是一种通过分析视角“看到”数据的方法，而无需对数据进行物理更改或复制。
2. 复制和转换——在这里，操作数据以一种更有利于分析的格式进行复制。这可以通过存储过程、物化视图或在操作应用程序的存储层本身实现，从而有效地创建为分析查询优化的数据的并行版本。
虽然这种模式提供了数据管理的简单性和原始数据的可用性，但它也有明显的局限性:
-
数据集成的挑战——由于模型依赖于单一的存储系统，因此它在集成来自不同物理数据库的数据方面存在固有的困难。为了克服这个问题，可以求助于链接服务器或跨数据库查询等技术，但是，这些技术往往会引入额外的复杂性，通常不受欢迎。
-
潜在的系统干扰——在同一数据库上并发操作的操作流程和分析流程可能会导致相互干扰，从而导致负载增加，并可能降低操作应用程序和分析处理的性能。
-
性能权衡——联机事务处理(OLTP)系统优先处理大量事务的效率，而联机分析处理(OLAP)系统针对复杂的查询处理进行优化，两者的优化需求不同，这意味着尝试同时处理这两种任务的系统可能对每个任务都不是最优的。
-
紧密耦合——统一的数据存储库模式导致操作域和分析域之间的强互连，从而导致这两个领域的灵活性受到限制或没有灵活性。
考虑到这些限制，通常不建议使用统一数据存储库方法来处理大型数据集或处理多个物理数据源。它可能适用于运行在健壮数据库上的小规模应用程序，在这种情况下，规模不会倾向于复杂性。
模式2：数据虚拟化
在初始模式的基础上，数据虚拟化方法利用专门的软件在多个底层数据源上建立虚拟化数据层。这个中间层允许执行部分由原始数据源处理的查询，将结果集成到一个内聚的数据集中进行分析。
虚拟化数据层协调跨一系列底层数据源的实时查询的执行(图片来源：作者)。
这种方法的主要好处包括：
1. 近实时数据访问——由于数据不是物理地重新定位到分析数据库，而是直接在源处查询，因此这种模式提供了快速的数据可用性，非常接近实时。
2. 智能缓冲存储——数据虚拟化系统通常设计为具有高级缓存功能，这可以最大限度地减少对源系统的需求并优化性能。
然而，这种方法也引入了几个问题:
-
源系统限制——如果源数据库没有针对某些查询类型进行优化，那么它们的性能瓶颈可能会扩展到虚拟层，特别是当它依赖于查询执行的源响应时。
-
网络开销——与分布在不同网络区域的数据源接口的虚拟化层可能会遇到延迟，从而影响整体性能。
-
历史数据跟踪——由于虚拟层本身并不存储数据，因此它对跨越数据摄取时间轴的历史分析(通常称为“时间旅行”)提出了挑战。
需要注意的是，特定的数据虚拟化解决方案可能提供独特的机制来解决这些问题。对于任何重要的体系结构决策(包括本文)，我的首要建议是使用您的特定基础设施彻底地测试数据虚拟化解决方案。这将有助于理解它的功能和限制，通过允许适当地缩放和微调，以优化集成和分析过程。
模式3：ETL
ETL代表提取、转换、加载，它代表了数据处理中一个成熟的范例。最初，从数据源获取数据(Extract)，然后在ETL服务器上进行精炼(Transform)，最后，精炼后的输出存储到以分析为重点的数据库(Load)中。
ETL服务器执行设计接口中配置的ETL流程。这些管道管理从原始数据提取数据，将其转换为适合分析的格式，以及随后将其加载到数据平台(如数据仓库或操作数据存储)。数据产品通常访问和利用存储在这些平台中的信息(图片来源：作者)。
多年来，许多ETL工具提供者都支持这种方法，提供各种专门的转换技术和设计风格。流行的样式包括图形界面，用户可以在直观的可视化工作流中将Extract、Transform和Load操作相互链接。这些流程通常可以通过脚本或直接SQL查询进一步定制。
ETL的主要优点包括：
-
集中的逻辑——ETL过程支持在单一的、可管理的环境中整合完整的转换逻辑，因此不仅促进了数据摄取，还能让数据以满足分析需求。
-
用户友好设计——ETL工具的可视化特性使数据转换过程民主化，使不同技能水平的用户能够参与数据管道的创建。
然而，ETL并非没有缺点，这导致了替代模型的出现:
1. 对特定供应商的依赖——ETL工具的依赖可能导致某种形式的供应商锁定，使得向其他平台的过渡成本高昂且复杂，特别是如果当前工具改变了定价或停止了功能。
2. 性能约束——ETL转换由指定的服务器执行，这些服务器可能无法与现代数据仓库中可用的高性能计算资源进行比较，从而成为潜在的瓶颈。这个场景呈现了一个悖论:尽管具有用于查询执行的高效数据仓库引擎，但整个管道的吞吐量受到ETL服务器的限制，后者以相当慢的速度处理转换。
3. 不透明的数据血统——可视化组件的简化通常掩盖了数据转换的复杂性，使得对数据旅程(数据血统)的理解和审计对ETL工具环境之外的人来说具有挑战性。
4. 有限的可扩展性——虽然ETL工具是为广泛的可访问性而设计的，但它们可能缺乏强大的可扩展性和工业化能力(例如DataOps框架中所描述的)，而这些能力对于数据平台的增长至关重要。
5. 刚性——当ETL工具不能适应独特的数据摄取需求时，就会出现缺乏灵活性的情况，从而导致导致技术债务的变通解决方案。
ETL模式的这些常见限制通常可以由特定的ETL供应商解决。特别是当ETL工具集成到为特定云DWH设计的综合套件中时，与速度和性能相关的问题可以得到缓解。尽管如此，了解ETL工具的发展轨迹至关重要，确保它继续与不断发展的数据摄取需求(如不断增长的数据量或新兴的数据源类型)保持一致。
模式四：ELT
ETL，分享了ETL的基本步骤，但通过重组和重新定义这些过程而产生分歧。在ETL中:
-
EL - Extract和Load操作，将原始数据直接传输到数据平台，而无需立即进行转换。
-
T -转换随后发生，将原始数据转换为可操作的见解。至关重要的是，转换任务可以独立运行，并且与提取和加载的时间表不同。
ELT管道被分为两个不同的部分:EL组件，它处理数据摄取到数据平台中，以及Transformation组件，它在数据平台中执行以处理和精炼数据(图片来源：作者)。
这个重组的过程解决了几个ETL限制：
-
增强的灵活性——从转换工具中分离提取/加载增加了适应性，允许为不同的数据类型和转换标准选择不同的工具。
-
一致的性能——转换发生在数据平台内，利用其全部计算能力，并且对于使用分布式计算引擎处理大量数据集特别有效。
-
改进的可扩展性——ELT固有的灵活性有助于选择在自动化和可扩展性方面表现出色的转换工具。
尽管有这些改进，ELT模型引入了新的复杂性:
-
多种工具的治理——使用不同的工具进行提取、加载和转换，需要严格的治理来管理许可、定价、更新周期和支持结构。
-
配器挑战——更多样化的工具包需要复杂的配器，通常基于有向无环图(DAG)，以确保只有在成功提取和加载数据后才能进行转换。
ELT模式因其灵活性而受到个人的喜爱，但它要求承诺管理多工具环境和复杂的配器策略。
新兴模式
在已建立的模式之外，新的方法和模式不断出现。本节讨论两种新兴模式:推送和流处理。
推(vs拉)
前面提到的传统模式是典型的“拉”类型，其中分析平面主动地从操作平面检索数据。与此相反，“Push”方法将此流程颠倒过来:一旦发生更改，例如创建、读取、更新和删除(CRUD)操作，操作平面主动发送或“Push”数据到分析平面。
虽然传统模式遵循“拉”策略，但在某些情况下，“推”可能是一种选择(图片来源:作者)。
推送方法经常出现在流架构中(后面会讨论)，但并不局限于流架构。从根本上说，它涉及到将数据传输到由分析平面指定的端点的操作平面。这种设置通常要求开发团队通过单独的组件或通过增强现有的可操作应用程序来实现推送机制。
这种方法的主要好处是，它允许分析团队专注于数据价值转换，而不必分散构建摄取管道的注意力——操作系统负责数据交付。然而，它有两个明显的缺点:
-
对专门的应用程序开发团队的需求——这对于预打包软件、软件即服务(SaaS)产品或物联网设备等外部硬件来说是有问题的，因为这样的团队可能不存在或不容易获得。在这种情况下，建立一个专门的“数据集成团队”来促进进入分析环境可能是必要的，但这可能很快变成瓶颈。
-
处理推故障——与推架构相比，基于拉的架构通常表现出更强的管道中断弹性。如果拉出失败，分析平台可以重新启动该过程。但是，如果推送失败，分析平台可能仍然不知道丢失的推送消息。为了克服这个缺点，基于推送的管道通常被合并到高可用的流架构中，设计用于并发操作和健壮的可用性。
推送模式最适合具有较高软件开发成熟度和/或在采购现成解决方案时可以协商数据推送功能的组织。在不可行的情况下，谨慎的做法是将推送与其他数据摄取模式结合起来，以确保平稳高效的数据集成。
流处理
流处理，也称为流处理或事件流，是数据生成时的连续流，支持实时处理和分析，以获得即时见解。这些系统对于即时决策任务至关重要，并支持金融交易、实时分析和物联网监控等活动的大容量、低延迟处理。
一般来说，流中间件可以通过两种方式来促进数据摄取:(1)通过使用ETL/ELT消费者来获取流消息并将其推送到分析平面，或者(2)通过利用流缓存作为分析源(图片来源:作者)。
当将流处理与分析结合在一起时，有两种方法脱颖而出:
-
为流媒体调整ELT(甚至ETL)——这包括提取实时事件并将其加载到数据平台中，通过定制或专门的流媒体消费者使用新数据源保留熟悉的工作流。
-
利用流缓存——集中的、持久的流缓存充当事件数据的高性能存储库。一些新颖的模式分析是利用这些缓存，创建共享数据存储的现代、高效变体。这里的一个主要考虑是流数据与静态数据源的集成，静态数据源可能永远不会通过流缓存。
在KAPPA和LAMBDA等数据架构模式中，流数据和更多静态数据的统一正在制定蓝图。这两种体系结构提供了一种将两个世界结合在一起的方法(在需要时)。
结论
数据摄取方法的战略性集成是不断发展的数据分析领域的基石。本文重点介绍了四种主要的数据摄取模式——统一数据存储库、数据虚拟化、ETL和ELT——每种模式都具有独特的优势和限制。当我们剖析这些模式时，我们看到了统一数据存储库的简单性但有限的可扩展性，以潜在的性能成本为代价的数据虚拟化的接近实时能力，被潜在瓶颈和刚性掩盖的ETL的集中控制，以及ELT的灵活性和可扩展性，以平衡配器挑战。
此外，新兴的流处理范例强调了行业向实时分析的支点。这些方法虽然相对较新，但正在为一种更加即时和动态的数据处理方法铺平道路，以适应信息生成的不断速度。
在我的后续文章中，我将更深入地探讨为您的数据平台选择合适的数据摄取工具。此过程中的一个关键考虑因素是该工具将集成在其中的体系结构模式。
原文标题：Data Ingestion — Part 1: Architectural Patterns
原文链接：https://medium.com/@meskensjan/the-art-of-data-ingestion-powering-analytics-from-operational-sources-467552d6c9a2
译者简介
翻译组招募信息
工作内容：需要一颗细致的心，将选取好的外文文章翻译成流畅的中文。如果你是数据科学/统计学/计算机类的留学生，或在海外从事相关工作，或对自己外语水平有信心的朋友欢迎加入翻译小组。
你能得到：定期的翻译培训提高志愿者的翻译水平，提高对于数据科学前沿的认知，海外的朋友可以和国内技术应用发展保持联系，THU数据派产学研的背景为志愿者带来好的发展机遇。
其他福利：来自于名企的数据科学工作者，北大清华以及海外等名校学生他们都将成为你在翻译小组的伙伴。
点击文末“阅读原文”加入数据派团队~
转载须知
如需转载，请在开篇显著位置注明作者和出处（转自：数据派ID：DatapiTHU），并在文章结尾放置数据派醒目二维码。有原创标识文章，请发送【文章名称-待授权公众号名称及ID】至联系邮箱，申请白名单授权并按要求编辑。
发布后请将链接反馈至联系邮箱（见下方）。未经许可的转载以及改编者，我们将依法追究其法律责任。
