数据摄取之架构模式

数据摄取是连接操作和分析世界的基本过程。对于将数据从原始操作环境中的多个来源传输到分析领域至关重要。

数据摄取是操作层面（数据来源）和分析层面（数据转化为 AI 模型、仪表板和 API 等分析产品）之间的关键链接

这种赋能的本质是能够依靠各种数据源生成数据驱动的见解并实施人工智能模型。组织的分析能力通常与其有效分析的数据源数量直接相关。因此，选择正确的数据摄取策略至关重要。这些策略必须足够强大，能够处理各种相关数据源，从 CRM、ERP 和财务系统等标准操作应用程序到 IoT 传感器、API 等更加非常规的应用程序以及抓取的文档、图像、和视频。

数据摄取是更广泛的数据平台难题中的关键部分。摄取策略的选择取决于底层架构设计，并且可以通过各种工具风格来执行。

从更广泛的角度来看，很明显数据摄取虽然只是一个要素，但却是组织内更大的数据平台难题的关键组成部分。该数据平台通常充当数字化转型计划的基石，帮助组织实现其业务目标。数据平台的核心由各种架构模式和一系列工具组成，每个工具在其功能和有效性方面都发挥着重要的作用。

本文探讨指导选择合适的数据摄取技术的架构范例。我的目标是提炼每种模式的本质，阐明它们对数据摄取过程的战略影响。提出这些模式背后的目标是识别并克服一些障碍，这些障碍往往使理论上最简单但绝对必要的任务变得复杂：将数据集成到分析框架中。掌握数据摄取的战略重要性对于保证在组织广阔的数据生态系统中数据的流畅过渡和有效利用至关重要。

模式一：统一数据存储库

我们研究的第一个架构方法是统一数据存储库模式，其中单个存储系统可以满足操作应用程序需求和分析处理需求。通常，该系统是关系数据库管理系统（RDBMS）。在这样的设置中，同一数据库用于日常操作和数据分析，从而消除了不同存储解决方案之间数据传输的必要性。

统一的数据存储库满足操作应用程序的需求并支持分析处理。分析见解是通过虚拟化、使用视图或通过复制和转换数据生成的

在这种方法中，有两种流行的子模式：

1. 虚拟化 —— 这涉及创建虚拟数据库层或视图，以在数据库内的操作表之上提供分析视角。这是一种通过分析镜头“查看”数据而无需物理更改或复制数据的方法。
2. 复制和转换 —— 在这里，操作数据以更有利于分析的格式复制。这可以通过存储过程、物化视图或在操作应用程序的存储层本身内实现，从而有效地创建针对分析查询优化的数据的并行版本。

虽然此模型提供了数据管理的简单性和原始数据的可用性，但它确实存在很大的局限性：

1. 数据集成挑战 —— 该模型本质上难以集成来自不同物理数据库的数据，因为它依赖于单个存储系统。为了克服这个问题，人们可以诉诸链接服务器或跨数据库查询等技术，然而，这些技术往往会引入额外的复杂性，并且通常不是首选的。
2. 系统干扰的可能性 —— 在同一数据库上同时运行的操作和分析进程可能会导致相互干扰，从而导致负载增加，并可能降低操作应用程序和分析处理的性能。
3. 性能权衡 —— 在线事务处理 (OLTP) 系统（优先考虑高效处理大量事务）和在线分析处理 (OLAP) 系统（针对复杂查询处理进行优化）的不同优化需求意味着系统尝试同时完成这两项任务对于每项任务来说可能都不是最佳的。
4. 紧密耦合 —— 统一的数据存储库模式导致操作域和分析域之间的紧密互连，从而导致任一区域的灵活性受到限制或没有灵活性。

鉴于这些限制，通常不建议使用统一数据存储库方法来处理大型数据集或处理多个物理数据源。它可能适合在强大的数据库上运行的较小规模的应用程序，其中规模不会变得复杂。

模式二：数据虚拟化

数据虚拟化方法以初始模式为基础，利用专用软件在多个底层数据源上建立虚拟化数据层。该中间层允许执行由原始数据源部分处理的查询，将结果集成到一个内聚的数据集中进行分析。

虚拟化数据层协调跨一系列底层数据源的实时查询的执行

这种方法的主要优点包括：

1. 近实时数据访问 —— 由于数据不会物理地重新定位到分析数据库，而是直接在源处查询，因此这种模式提供了快速的数据可用性，非常接近实时。
2. 智能缓存 —— 数据虚拟化系统通常设计有高级缓存功能，可以最大限度地减少对源系统的需求并优化性能。

然而，这种方法也带来了几个问题：

1. 源系统限制 —— 如果源数据库未针对某些查询类型进行优化，则其性能瓶颈可能会扩展到虚拟层，特别是当它依赖于查询执行的源响应时。
2. 网络开销 —— 与分布在不同网络区域的数据源交互的虚拟化层可能会遇到延迟，从而影响整体性能。
3. 历史数据跟踪 —— 由于虚拟层本身并不存储数据，因此它给跨数据摄取时间线的历史分析（通常称为“时间旅行”）带来了挑战。

值得注意的是，特定的数据虚拟化解决方案可能提供独特的机制来解决这些问题。我对任何重大架构决策（包括这一决策）的首要建议是使用您的特定基础架构彻底测试数据虚拟化解决方案。这将有助于了解其功能和局限性，从而进行适当的扩展和微调以优化集成和分析过程。

模式 3：ETL

ETL 代表提取、转换、加载，代表了数据处理中成熟的范例。最初，从数据源 ( Extract )获取数据，然后在 ETL 服务器上进行精炼 ( Transform )，最后将精炼后的输出存入以分析为中心的数据库 ( Load )。

ETL 服务器执行设计界面中配置的 ETL 过程。这些管道管理从源头提取数据、将其转换为适合分析的格式，以及随后将其加载到数据仓库或操作数据存储等数据平台中。数据产品通常访问和利用这些平台中存储的信息

多年来，众多 ETL 工具提供商都支持这种方法，提供各种专门的转换技术和设计风格。流行的风格涉及图形界面，用户可以在直观的可视化工作流程中互连提取、转换和加载操作。这些过程通常可以通过脚本或直接 SQL 查询进一步定制。

ETL 的主要优点包括：

1. 集中逻辑 —— ETL 流程可以将完整的转换逻辑整合到一个可管理的环境中，从而不仅促进数据摄取，还可以调整数据以满足分析要求。
2. 用户友好的设计 —— ETL 工具的可视化特性使数据转换过程民主化，使不同技能水平的用户能够参与数据管道的创建。

然而，ETL 也并非没有缺点，这导致了替代模型的出现：

1. 对特定供应商的依赖 —— ETL 工具依赖可能会导致某种形式的供应商锁定，从而导致向其他平台的过渡成本高昂且复杂，特别是在当前工具改变定价或停止功能的情况下。
2. 性能限制 —— ETL 转换由指定服务器执行，这些服务器的扩展能力可能无法与现代数据仓库中可用的高性能计算资源相媲美，从而成为潜在的瓶颈。此场景呈现出一个悖论：尽管具有用于查询执行的高效数据仓库引擎，但整个管道的吞吐量受到 ETL 服务器的限制，该服务器处理转换的速度要慢得多。
3. 不透明的数据沿袭 —— 可视化组件的简化通常掩盖了数据转换的复杂性，使得 ETL 工具环境之外的人员难以理解和审核数据旅程（数据沿袭）。
4. 可扩展性有限 —— 虽然 ETL 工具是为广泛的可访问性而设计的，但它们可能缺乏强大的扩展和工业化功能（例如DataOps框架中描述的），而随着数据平台的发展，这些功能至关重要。
5. 刚性 —— 当 ETL 工具无法满足独特的数据摄取要求时，就会出现不灵活性，从而导致解决方案增加技术债务。

ETL 模式的这些常见限制通常可以由特定的 ETL 供应商来解决。特别是当 ETL 工具集成到为特定云 DWH 设计的综合套件中时，可以缓解与速度和性能相关的问题。尽管如此，了解 ETL 工具的发展轨迹保持领先地位至关重要，确保它继续符合不断变化的数据摄取要求，例如不断增长的数据量或新兴数据源类型。

模式 4：ELT

ELT 共享 ETL 的基本步骤，但通过重组和重新定义这些流程而有所不同。在英语教学中：

• EL —— 首先进行Extract和Load操作，将原始数据直接传输到数据平台，不立即进行转换。
• T —— 随后发生转换，将原始数据转换为可操作的见解。至关重要的是，转换任务可以独立运行，并按照提取和加载的不同时间表运行。

ELT 管道分为两个不同的部分：EL 组件，用于处理将数据引入数据平台；转换组件，在数据平台内执行以处理和细化数据

此重组流程解决了几个 ETL 限制：

1. 增强的灵活性 —— 将提取/加载与转换工具分开可以提高适应性，从而可以为不同的数据类型和转换标准选择不同的工具。
2. 一致的性能——转换发生在数据平台内，充分利用其全部计算能力，对于使用分布式计算引擎处理海量数据集特别有效。
3. 提高可扩展性——ELT 固有的灵活性有助于选择在自动化和可扩展性方面表现出色的转换工具。

尽管有这些改进，ELT 模型还是引入了新的复杂性：

• 多种工具的治理 —— 使用不同的工具进行提取、加载和转换需要严格的治理来管理许可、定价、更新周期和支持结构。
• 编排挑战 —— 更加多样化的工具包需要复杂的编排，通常基于有向无环图 (DAG)，以确保仅在成功提取和加载数据后才能进行转换。

ELT 模式因其灵活性而受到个人喜爱，但它需要致力于管理多工具环境和复杂的编排策略。

新兴模式

除了既定的模式之外，新的方法论和模式正在不断出现。本节讨论两种新兴模式：推送和流处理。

推（与拉）

前面提到的传统模式通常属于“拉”类型，其中分析平面主动从操作平面检索数据。相比之下，“推送”方法反转了此流程：一旦发生更改，例如创建、读取、更新和删除 (CRUD) 操作，操作平面就会主动将数据发送或“推送”到分析平面。

虽然传统模式遵循“拉”策略，但在某些情况下“推”可能是一种选择

推送方法经常出现在流式架构中（接下来讨论），但并不局限于它们。从根本上讲，它涉及操作平面启动数据传输到分析平面指定的端点。这种设置通常要求开发团队通过单独的组件或通过增强现有的操作应用程序来实现推送机制。

这种方法的主要好处是，它允许分析团队专注于数据价值转换，而不必分心构建摄取管道 —— 操作系统负责数据交付。然而，有两个明显的缺点：

1. 需要专门的应用程序开发 团队 —— 这对于预打包软件、软件即服务 (SaaS) 产品或物联网设备等外部硬件来说会成为问题，因为这样的团队可能不存在或随时可用。在这种情况下，建立专门的“数据集成团队”来促进分析环境的推进可能是必要的，但这很快就会变成瓶颈。
2. 处理推送故障 —— 与推送架构相比，基于拉取的架构通常表现出更强的管道中断恢复能力。如果拉取失败，分析平台可以重新启动该过程。然而，如果推送失败，分析平台可能仍然不知道丢失的推送消息。为了克服这个缺点，基于推送的管道通常被合并到高度可用的流架构中，专为并发操作和强大的可用性而设计。

推送模式最适合软件开发成熟度较高和/或在采购现成解决方案时可以协商数据推送功能的组织。在这不可行的情况下，谨慎的做法可能是将推送与其他数据摄取模式结合起来，以确保平稳高效的数据集成。

流处理

流处理也称为流处理或事件流，是生成数据时的连续流，支持实时处理和分析以获得即时见解。这些系统对于即时决策任务至关重要，并支持金融交易、实时分析和物联网监控等活动的大容量、低延迟处理。

一般来说，流式中间件可用于通过两种方式促进数据摄取：(1) 使用 ETL/ELT 使用者来获取流式消息并将其推送到分析平面，或 (2) 利用流式缓存作为源用于分析

将流处理与分析结合起来时，有两种方法脱颖而出：

• 使 ELT（甚至 ETL）适应流媒体——这涉及提取实时事件并将其加载到数据平台中，通过定制或专门的流媒体消费者使用新颖的数据源保留熟悉的工作流程。
• 利用流缓存——集中、持久的流缓存充当事件数据的高性能存储库。一些新颖的模式以分析方式利用这些缓存，创建共享数据存储的现代、高效变体。这里的一个主要考虑因素是流数据与静态数据源的集成，静态数据源可能永远不会通过流缓存。

流数据和更多静态数据的统一正在KAPPA 和 LAMBDA等数据架构模式中绘制蓝图。这两种架构提供了一种将两个世界结合在一起的方法（在需要时）。

结论

数据摄取方法的战略集成是不断发展的数据分析领域的基石。本文重点介绍了四种主要的数据摄取模式——统一数据存储库、数据虚拟化、ETL 和 ELT——每种模式都有独特的优势和限制。当我们剖析这些模式时，我们看到了统一数据存储库的简单性但可扩展性有限，数据虚拟化的近实时功能（以潜在的性能成本为代价），ETL 的集中控制受到潜在瓶颈和刚性的影响，以及灵活性和灵活性。ELT 的可扩展性与编排挑战相平衡。

此外，新兴的流处理范例强调了行业向实时分析的转变。这些方法虽然相对较新，但正在为更加即时和动态的数据处理方法铺平道路，适应信息生成的不断速度。

在后续文章中，我将更深入地探讨如何为数据平台选择合适的数据摄取工具。此过程中的一个关键考虑因素是该工具将集成到的架构模式。

原文作者：janmeskens