导读 本文分享的主题是《从数据集成到现代数据栈》，主要分成四个部分：

1. 数据集成

2. 数据集成工具

3. 现代数据栈

4. 现代数据栈实践

分享嘉宾｜徐榜江 Flink 数据通道负责人

编辑整理｜陈沃晨 浪潮云信息技术有限公司

出品社区｜DataFun

01/数据集成

1. 数据集成（Data Integration）

（1） 数据集成的概念

数据集成是将多个分散的数据源，在逻辑或物理上有机地集中，为企业解决

数据孤岛问题，通过统一的数据视图为企业提供决策支持。

（2） 数据集成的目的

数据集成的目标是对数据进行集成，最早的数据集成系统可以追溯到1991年，

明尼苏达大学在构建人口数据库系统IPUMS时，使用了一种数据仓库方法，从不同的数据源中进行数据提取、数据转换并加载到一个统一的模式中，实现了数据集成。

2. 数据仓库（Data Warehouse）

（1）数据仓库的概念

数据仓库是一个集成的（Integrated），面向主题的（Subject-Oriented），随时间变化的（Time-Variant），不可修改的（Nonvolatile）数据集合，用于支持管理决策（数据仓库之父Bill Inmon于1990年定义）。

（2）与数据集成关系

数据仓库的首要目的是数据集成，将多个分散的、异构的数据源在逻辑或者物理上整合在一起，便于后续分析。

3. 数据湖(Data Lake)

（1）数据湖

数据湖这个概念最早于2011年提出。数据湖是一个集中式存储，用于存储、处理大量结构化数据、半结构化数据、非结构化数据，它可以以原生格式存储数据，并处理任何转换格式（Google Cloud的数据湖定义）。

（2）与数据集成关系

数据湖的首要目的也是数据集成，将多个分散的、异构的数据源的所有原始数据整合在一起。数据湖与数据仓库主要区别在于：数据湖的存储成本更低，无需提前定义数据的schema。

4. ETL

ETL 是数据集成的主要步骤，即：

• 数据接入（Extract）
• 数据清洗、打宽（Transformation）
• 数据入仓、入湖（Load）

02 /数据集成工具

1. 数据集成工具（Data Integration Tool）

Gartner数据集成工具魔力象限从多个维度客观地评价了现在的数据集成工具，包括传统做数据集成的老牌劲旅，比如SAP，也有一些新兴做现代数据栈的云上服务提供商，比如Talend、FiveTran等。

Data engineering 2022路线图包含了对Data Engineering领域相关技术的分类。比如我们要做数据接入，就可以在相关分类里面找到数据接入的SAAS服务提供商和技术分别有哪些。路线图围绕整个Data Engineering大的技术栈，包含云上的对象存储技术、Metastore、数据治理、数据质量、MLOps等很多领域。大家可以重点先看下图中前面的两类：Ingest SAAS和Ingest Tech。对于我们做数据集成或者ETL技术的人，会发现我们经常接触到的Stitch、Airbyte、FiveTran以及Flink、Materialize这些产品或技术出现在这个路线图里面了。

接下来我重点选取前面提到的Stitch、Fivetran、Airbyte这3个典型的数据集成工具放在一起比较。其实这3个工具跟前面的Garther魔力象限还是比较匹配的，Stitch被Talend收购了，Talend就是在魔力象限的第二象限；Fivetran大家比较熟悉，它是一个闭源产品；Airbyte是我最近比较关注的产品，它是一个完全开源的数据集成工具，最近两三年成长起来，而且成长速度非常快。

从产品聚焦点上来对比，这3个工具都是专注于数据的Ingest或者说做数据集成的ETL或ELT，其中Airbyte还支持反向ETL。从数据源上看，它们支持的数据源都非常多， Stitch支持超过130个、Fivetran超过150个、Airbyte在4~5个月前已经超过120个。从Destinations上看，3家对主流的数据库、数据仓库和数据湖都是支持的。从自定义的Connectors上看，数据源和数据存储都支持自定义，生态的扩展性友好。

3个工具在Database Replication方面都支持全表和CDC增量的方式，在计价模式上Stitch和Fivetran都是基于数据同步记录数做定价， 而Airbyte则根据用户场景定价， 比如根据网络带块、计算资源等进行灵活计价。在与数据栈的其他组件集成方面， Stitch目前不支持， Fivetran 则是支持dbt，AirByte对集成的支持更丰富，支持集成dbt、Kubernetes、Airflow等，开源属性决定了后续AirByte还会和更多数据栈做集成。最后，在SLA方面， 3家也都是支持的。如果大家感兴趣，可以进一步查看lakeFS data engineering 2022 map这篇文章了解更多细节。

2. ETL vs ELT

上文介绍了3家业界做数据集成工具的TOP厂商，并提到了ELT这个词，要想了解它的含义，我首先要跟大家讲一下ETL。就以Fink CDC举例，我们从一个Mysql数据库中以全量或增量的方式同步数据，并在同步的过程中对数据进行清洗、加工等处理，再存储到数据湖或者数据库中，这就是一个标准的ETL过程。Flink CDC做数据采集、Flink做计算：表JOIN、打宽、大写小写转换等，再写到下游。在实时数仓、实时数据湖场景中，会把数据写入到Hudi、TiDB、ClickHouse、Hologres等中。

所谓的ELT，采集完的数据会直接传到下游，中间不做任何的转换，或者说是做非常少且有限的转换，转换的逻辑全部交给数据仓库或数据湖上面的分析引擎来完成。比如说把数据放到Hudi中，让Flink或者Presto来做分析和计算。还有的直接放到数据仓库中，交给数据仓库的分析引擎来做转换，比如ClickHouse、Hologres等。数据仓库或者数据湖中已经有全量的历史明细数据，Extract层和Load层分别负责数据的采集和装载写入， Transformation层就全部交给数据仓库或数据湖专门的分析引擎，对于整个数据仓库或者数据湖来说这种分层是最清晰的。

早在2019年，Fivetran就在提ELT的口号："ETL已经过时了，现在大家要做Modern ELT"。Modern ELT的核心就是把Transformation（转换）这部分放到数据仓库或数据湖中，整个负责ETL的工具只做Extract和Load 的工作，上图中下面蓝色这个部分都交给数据仓库或者数据湖上的分析引擎来完成。

03 /现代数据栈（Modern Data Stack）

了解了数据集成的一些工具，我们切入到今天的主题：现代数据栈。这个概念最近在国外比较火，当然这也跟国内外的云技术的普及程度是分不开的，目前国内也在慢慢发展起来。

1. 数据栈(Data Stack)

• 数据栈

数据堆栈是一组对原始数据进行提取、转换和存储的技术或工具的组合，这些工具可以让数据工程师、分析师能够提取和清洗数据，将原始数据转换为有价值的数据并存储，然后根据需要进行分析。

• 数据栈的意义

原始的数据往往是不能提供给数据工程师和分析师直接消费的，数据栈可以完成抽取原始数据，转换为有价值的数据并进行存储，让数据变得可消费，可分析，从而实现数据驱动业务。

2. 现代数据栈（Modern Data Stack）

• 现代数据栈

现代数据栈是在数据栈的基础上，使用创新的或基于云上数仓/湖的工具或技术的组合，现代数据栈构建在云上，比传统数据栈更容易访问和扩展。

• 现代数据栈的意义现代数据栈基于云上构建的特点，具备传统数据栈很难具备的弹性和扩容优势，现代数据栈层次清晰有利于垂直领域的工具形成标准的SaaS服务，而SaaS服务可极大地降低了运维和管理成本。
• Fivetran的现代数据栈

Fivetran的现代数据栈中，通过Fivetran把数据库数据、文件等集成到数据仓库或者数据湖中，比如Snowflake、Redshift。然后做Transformation（灰色的框里面）全部交给数据仓库或者数据湖来做。最后给终端用户提供服务，比如实现BI报表、数据驱动、机器学习等。整个数据栈的层次是非常清晰，让专业的人做专业的事。Transformation让Dbt来做，采集就是Fivetran，换成Stitch、Airbyte也是一样的。核心就是层次非常清晰，每个工具专注做自己的事，并且都是通过云上的saas提供服务，不需要自己做运维和管理。

围绕Airbyte的现代数据栈是完全开源的，划分了数据采集层、数据仓库层、Transformation层、元数据管理层、分析层。围绕开源的软件或工具提供商，做了一个非常明显的分层。在Airbyte的现代数据栈里面，比如Flink、Dbt只做简单的Transformation工作。数据存储在Clickhouse中。数据分析工具也是单独的。

整体上看，不管闭源实现的数据栈还是开源实现的数据栈，一个核心的要素就是把软件的层次分的特别清楚，让专业的工具做专业的事，避免一个大而全的系统。

刚刚介绍了Airbyte的发展特别迅速，大家看一下上图中红色的线，是我们之前做的一个Fink CDC项目的发展曲线，它的发展还是非常快的，对比一个老牌的做离线同步的Apache Sqoop，你会看到Fink CDC明显的更快。但是Fink CDC和Airbyte相比，就会发现Airbyte从2021年底已经开始爆发，它的增长更加迅猛。这也是开源软件优势之一：能更快地敲开市场、更快地触达到用户。

3. 现代数据栈优势

• 速度

相比传统数据栈，现代数据栈基于云的工具的弹性和扩容能力更加先进，

执行同样的工作速度通常会更快。

• 成本

基于云的解决方案不需要关心硬件和平台维护，降低了开发运维成本。

• 自动化

云上的全托管和自动化服务简化了数据集成流程，减轻了用户负担。

• 易用性

现代数据栈中的工具都很容易使用，用户不需要理解底层技术细节

04 /现代数据栈实践（Build Modern Data Stack）

1. 不同公司的现代数据栈

这是Modern Data Stack网站的一张截图，这个网站里收集了不同公司的数据栈，包括传统的和现代的。比如说5x这家网站的公司就选用了Fivetran、Dbt、Snowflake等来构建自己的现代数据栈。大家可以根据自己公司的业务类型做一个参考，了解别的公司是如何构建现代数据栈的。

2. 围绕Flink CDC的数据集成

Flink CDC支持的数据源类型是非常广泛的，同时支撑的下游也非常丰富，并且可以通过SQL API和Data Stream API做很多强大的Transformation，相比于SQL API，Data Stream API门槛更高但功能也更强大。

3. Flink集成能力

从图中大家可以看到，Flink的集成能力也非常强大，特别适合做数据集成。

4. 围绕Flink CDC的传统数据栈

上面这张图是我们早期会提供给客户的一个围绕Flink CDC的传统数据栈，它把数据抽取（Extract）的流程和计算（Transformation）整合到一起，让客户不用了解Debezium、Canal、Kafka这些额外的组件。通过Flinck CDC把Mysql的数据直接做一个采集、计算，然后再导入到终端的数据湖或数据库中。降低了组件个数，减少了链路复杂度。

5. 围绕Flink CDC的现代数据栈

围绕Flink CDC的现代数据栈，只让Flink CDC来做数据采集，计算基本不做，直接Load到数据湖、数据仓库、OLAP引擎（TiDB、ClickHouse、Hologres）、消息队列等这些中。在这些存储上构建我们的实时数仓或数据湖。所有的Transformation都用计算引擎来做，或者直接在数仓或数据湖中完成。数据湖中计算引擎可以选择Flink、Presto，实时数仓里面可以直接选Flink、Hologres等。

6. 围绕实时计算Flink CDC的现代数据栈

另外，在阿里云上我们也有这方面的实践，阿里云针对这种ELT也提供了一些强大的能力，整条链路从Mysql到Flink CDC，再到Hologres，做了很多增强。比如说支持全增量一体化同步、整库同步、分库分表合并同步、表结构变更自动同步等，这样的现代数据栈实际上提供了更多的功能。在这个现代数据栈里面，很多都是实时计算Flink CDC提供的能力，在Hologres里面就可以围绕数仓做更多的分析，可以把Transformation全部放到数仓里面来做。

把Transformation全部交给数仓后，整个围绕实时计算Flink CDC的现代数据栈的一个全景图基本上就是这样（如上图）：原始的日志数据或者数据库数据通过Flink CDC（Kafka可选）抽取到实时数仓Hologres里面，并构造经典的实时数据仓分层：ODS层、DWD层、DWS层。中间的Transformation全部交给Flink， 在仓内完成Transformation，数据也都是在Hologres中。最终处理完后提供给终端用户：比如数据工程师、业务的决策人员，支撑他们做报表分析、实时大屏、数据应用等具体应用。这就是在阿里云上围绕实时计算Flink CDC的一个现代数据栈。

7. 阿里云实时计算Flink版

阿里云上有相应的实时计算Flink版本，它针对Flink CDC、Hologres等做了集成，提供了企业级的能力，包括流批一体的一站式开发运维平台、Flink CDC实时入湖入仓、丰富的Connectors等，欢迎感兴趣的同学扫二维码进一步了解。

05 /Q&A

Q1：在仓内做Transformation，对仓的稳定性和成本压力太大了吧，仓的成本控制不住吧?

A1：在一个数仓中，Transformation也不一定由数仓来做，只是说数据在仓内也有一些专门做Transformation的分析引擎可以选择使用。如果你是分析导致的不稳定，这个不稳定性不是对仓，仓只是提供了数据的存储。如果是你的仓里面也有分析引擎的能力，就变成仓里面对分析引擎上的压力，那就看你对这个仓的定位了。成本压力上，数仓的成本比数据湖的成本要大。现在很多仓都在做一些优化，比如说Materialize VIEW，它不会把每一个表加工的结果直接存储，而是通过VIEW的方式，节省了很大的成本。

Q2：数据源支持Oracle吗?

A2：支持；首先，Flink CDC是支持Oracle的，并且今天介绍的开源现代数据栈里面的这些ETL工具中，包括Stitch、Fivetran、Airbyte也都是支持的。

Q3：数据入湖后，如果用Flink来处理，是ELT，如何理解，数据还是需要提取到Flink计算引擎，在仓内处理吗？

A3：在Flink Table Store没有出来以前，Flink只是一个计算引擎，它不会存储数据。一旦数据入湖后，比如存储到Hudi中，后面再用Flink读出来，做完计算后写入hudi中。Flink在这个过程里面就是一个计算引擎，中间不会存储任何数据；如果数据是在数仓的话，仓内会用一些外部的分析引擎来做分析。

Q4：Flink CDC相对于演讲中的提到Fivetran和开源的集成工具，有什么优势？

A4：考虑到国内外产品形式的区别，Flink CDC目前专注在数据库集成，暂时没有做SAAS、日志、云上应用数据的采集。在数据库集成这方面Flink CDC核心的优势是它有一个全增量框架、支持并发和Exactly Once、断点续传的能力。这方面Fivetran是不具备的。另外， Fivetran最小的调度周期是5分钟（1个月前调研），并且是离线调度。而Flink CDC的增量同步的调度周期可以做到亚秒级，这两点是目前最大的优势。

Q5：Flink CDC支持Schema同步吗？

A5：现在Flink CDC社区版本只支持DataStream API，可以获取到所有DDL变更和事件的详情，需要自己做DDL的解析和处理，以及和下游系统的对接。云上版本是跟Hologres、Hudi这些做了对接的，可以实现Schema的同步。

Q6：Oracle CDC 和Flink CDC 有啥区别么?

A6：从Connector上讲，Flink CDC的Connector有很多；Oracle CDC只是其中一个；从Oracle CDC和Flink CDC的实现机制上看，每个数据库有自己不同的CDC机制，比如Mysql是把变更数据写到BinLog里面去。Oracle也是写日志，不过它会用LogMiner做一些解析。