Data Ingestion: Architectural Patterns

在数据驱动的时代，数据摄取是构建高效数据生态系统的基石。合理的摄取架构直接影响数据质量、处理效率与业务价值释放。本文系统梳理统一数据存储库、数据虚拟化、ETL/ELT 等经典架构模式，解析其核心原理与应用场景；同时探讨推 / 拉模式及流处理等新兴技术趋势，助读者掌握数据摄取架构设计的关键逻辑，为企业数据管理与分析提供可落地的参考方案。

原文：

https://medium.com/the-modern-scientist/the-art-of-data-ingestion-powering-analytics-from-operational-sources-467552d6c9a2

Overview

本质上来说，data ingestion 就是把运营平面的数据，同步到 分析平面中，这样就可以解锁 分析平面的所有能力了

企业的分析平台需要对 各种数据源做分析，因此选择合适的 data ingestion 策略就很重要这个 data ingestion 必须覆盖各种场景

• 比如标准的应用，CRM、ERP、金融系统等

• 非结构的数据，如 IoT 传感器

• 还有 API，各种文档、图片、视频等

其中，数据平台由各种架构模式、各种工具组成，他们在其中扮演重要的功能、有效性的角色

本文介绍架构范式，指导选择合适的数据摄取策略，并指出其背后的本质

Pattern-Unified Data Repository

这种模式就是 一个数据库，同时处理 OLTP、OLAP 数据

好处是简单，消除了数据同步的需要

这种方式又分为两种 子模式

• Virtualization，在 OLTP 表之上建立视图，为 OLAP 使用

• Duplication and Transformation，在原 OLTP 表之上，建立物化视图，或者复制一份表，供 OLAP 使用

这种模式的限制

• Data Integration Challenges，因为是一个数据库来管理 OLAP、OLTP，如果数据源种类很多，就不好处理，需要跨数据源查询，带来复杂度

• Potential for System Interference，OLTP、OLAP 同时使用导致相关干扰

• Performance Trade-offs，OLTP 的场景跟 OLAP 复杂查询的场景不同，很难同时兼顾优化两个场景

• Tightly Coupled，导致 OLTP 和 OLAP 层的紧耦合，降低了灵活性

这种模式，适合数据集不大的场景，或者数据源种类较少的场景

Pattern-Data Virtualization

这种模式利用了特殊的软件，在多个底层的源之上，建立了数据虚拟层

也就是通过一个中间件整合底层的数据，做汇总后返回给 分析层

这种模式的好处

• Near-Real-Time Data Access，因为没有物理数据，访问的都是原始数据集，所以能提供 近实时的查询

• Intelligent Caching，通过整合了 cache，可以对底层系统的影响最小，也能提升性能

这种模式的限制

• Source System Limitations，如果底层系统对特定查询没有优化，则会影响到上层的访问

• Network Overhead，可能需要跨多个机房做跨数据源查询，有一定的延迟

• Historical Data Tracking，由于不存物理数据，没有做历史分离，也就是 time travel

使用这种模式时，需要详细的测试 底层基础设置，了解其限制和能力，这样才能更好的整合、优化这种模式

Pattern-ETL

这种就是标准的 ETL，Extract，Transform,Load 操作

现在有很多这种 ETL 工具，还有直观的图形界面，方便用户观察细节用户还可以通过脚本、SQL 来直接操作

这种管道方式的好处

• Centralized Logic，不光利用了数据摄取的能力，同时将数据塑造成满足 分析场景的模式

• User-Friendly Design，可视化的 ETL 可以让不同技能的用户都能参与进来

Pattern-ELT

类似于 ETL，但是有些不同

• EL，首先直接 提取、加载操作，而转换操作直接在目标数据平台上完成，但不是立即转换的

• T，随后才发生的操作，这个操作是独立的，可以跟 EL 操作隔离开

这种模式解决了 ETL 的几个问题

• Enhanced Flexibility，由于将 转换操作单独拿出来了，所以增强了灵活性，可以为不同的数据类型、转换标准选择不同的工具

• Aligned Performance，利用了数据平台的计算能力，可以做并行处理

• Improved Scalability，有助于选择自动化，可伸缩性方面的工具

这个模式的缺点

• Governance of Multiple Tools，使用不同的工具做 EL、T，需要严格的治理来管理许可、定价、更新周期和支持结构

• Orchestration Challenges，需要一个更好的工具来支持编排，基于 DAG 来确保转换发生在 EL 之后

Emerging Patterns

Push (vs Pull)

传统的模式是 pull 的方式，也就是 分析平台主动的从运营平台 拉取数据

而 push 模式，是运行平台将数据 push 到分析平台，只要源端发生了 create、read、update、delete CRUD 操作

这种模式下主要用于流系统，但不止于此，运营平面需要额外的组件来扩展这个功能，或者在运营平板新增一些功能这样就使得 分析平面只需要考虑 转换问题，而不需要考虑数据摄取管道相关的事情这种方式的缺点

• Requirement for a dedicated application development team，需要额外的团队来完成这些任务

• Handling Push Failures，pull 失败了只要重试即可，但是 push 失败了 分析平面感知不到，需要设计高可用，高并发的 push 流系统

这种模式下，需要组织有很高的软件开发成熟度，否则需要跟其他方案配合使用

Stream Processing

流处理系统，适合大数据量、低延迟的系统，如金融交易、实时分析和物联网监控

有两个好处

• Adapting ELT (or even ETL) for Streaming，可以提取实时的事件，并加载到分析平台

• Leveraging Streaming Caches，利用流 cache 作为一个数据源，相当于共享数据存储的变体，但要注意静态数据 cache 问题

Kappa、Lambda 则是统一两个世界的架构

Conclusions

提供了 5 种模式

• Unified Data Repository，最简单，但是限制了伸缩性

• Data Virtualization，提供了实时的能力，但限制了性能

• ETL，独立了两个平台的能力，但是也有性能瓶颈，僵化、不灵活

• ELT，很灵活，伸缩性很好，但是需要额外的编排

• 新兴的流处理模式，提供了实时性，提供了动态的方式获取数据

Reference

• Data Streaming: The Complete Introduction

• Lambda vs. Kappa