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