从ETL到EtLT架构的演进历程

　　ETL到EtLT架构演进
　　为了更好地理解，我们先来介绍一下数仓从 ETL 到 EtLT 的架构演进。
　　回顾过去，我们会发现其实整个数仓在 1990 年到 2015 年都是 ETL 的架构，在这个架构下数据源主要是结构化数据，如 MySQL、SQL、Server、Oracle、ERP、CRM 等。同时，数据仓库计算主要由 OLTP 时代的Oracle，DB2 来承担，就是用来做查询和存储历史数据的数据库。在这个时代，其实Oracle、DB2 这样的数据库本身计算能力还是比较弱的，很难满足所有场景的数仓计算任务需求。
　　在这个过程中就诞生了 Information、Talend，还有Kettle 等专业化 ETL 软件。这些软件目前很多企业还在用，随着新的技术的出现，比如 MPP技术，还有分布式架构技术流行，比如 Hadoop、Hive 等，这些技术的出现让大家发现，其实可以用一些很低成本的硬件，代替以前昂贵的 Oracle、DB 的硬件服务。伴随着这些技术，我们已经进入到了 ELT 时代。
　　这个时代的核心特性，来自不同数据源的数据，包括结构化非结构化数据，日志等等，其实都可以不经过任何处理，或者只是经过一些简单的标准化，比如清洗、字数删减等，就可以加载到数仓中。在数仓中再经过 MapReduce、Spark 等引擎层层计算。这个时候因为数据源还不是太多，太复杂，大家处理从数据源到数仓的过程，主要还是通过写 MR 程序或者 写 Spark 程序来完成。
　　随着数据源越来越复杂，很多新兴的技术不断出现，数据源更加复杂，一些 SaaS 服务和云上数据存储出现了很多，进一步导致数据源更复杂。同时，在目标端，数仓和以前的数仓已经很不一样了，随着数据湖、实时数仓技术的出现，数据集成的目标端也更加复杂。这时，如果还像以前那样由数据工程师去开发 MR 程序，集成效率会非常低，这时迫切需要一些专业的团队和专业工具，来解决这样的 ELT 过程。
　　于是，数据集成这样一个领域就诞生了。SeaTunnel 就是下一代数据集成的平台。
　　在 ELT 场景下，有个概念叫做 EtLT，这里的小 t 区别于后面的大写 T，表示数据标准化的事情，比如字段筛选，对非结构化数据进行结构化转换等，它不涉及到 join，也不涉及到聚合。我们把这两套体系下的人员也是进行了拆分，数据 EL 的过程，也就是前面 EtL的过程，主要由一些不需要太懂业务的数据工程师来处理，他们只需要足够了解不同数据源之间的数据特性和差异就可以。当数据加载到数仓后，再由专业的 AI 数据科学家、数据分析师、SQL 开发人员等更懂业务的人，基于原始数据去做计算。
　　这就是从 ETL 到 EtLT 架构的演进历程。2020年，James Densmore在《Data Pipelines Pocket Reference》这本书中提出了EtLT 这个架构，他预测从 2020 年开始到未来，这是架构的演变趋势。
　　数据集成领域的痛点&常见的解决方案
　　由此，我们再引申到数据集成领域的一些常见的痛点和解决方案。
　　我在之前的技术探索中发现了一些数据集成领域的核心痛点，包括： 数据源多，SeaTunnel 社区目前统计到的数据源已经接近 500 个而且还在迅速的增长；版本不兼容，随着数据源版本迭代，兼容性上会出现问题，而且随着新技术的不断出现，数据集成领域需要快速地适配数据源，这是需要解决的一个核心痛点； 同步场景复杂：数据同步包括离线、实时，全量、增量同步，CDC，多表同步等，CDC的核心需求是要解决直接读物数据库的变更日志并解析，将其应用到下游，这个过程中，如何解析不同数据库的日志数据格式，事务处理，整库同步，分库分表等很多场景都有待适配支持； 过程如何监控、指标如何量化：同步过程中的监控缺失会带来信息的不透明，例如不确定已经同步的数据数量等； 有限资源下如何实现高吞吐、低延时，以降低成本； 如何降低对数据源的影响：多个表需要实时同步时，频繁读取 binlog 对数据源造成的压力较大，影响数据源的稳定性。同时JDBC 连接数过多时，也会导致数据源不稳定，甚至在数据源限制了最大连接数的情况下，同步作业可能无法正常运行。数据集成平台需要尽量降低对数据源的影响，比如减少连接占用，限制同步速度等。 如何做到数据一致性、不丢失、不重复：有些数据一致性要求高的系统，是不允许出现数据丢失和重复的。
　　为了满足这些需求，我们需要一个简单易用、易扩展、易管理、已维护的数据集成产品。我们为此做了方案调研。
　　我们发现，不同的数据集成产品大多是针对以下几个场景：
　　1. 全量离线增量
　　这个场景下，早期大家使用较多的是 Sqoop，它之前也是 Apache 基金会下的项目，但它的核心问题在于支持的数据源很少，而且依赖于 MapReduce 架构，很慢。而且它已经从 Apache 退役了，属于是上一代的数据集成项目了。
　　目前 DataX 也比较流行，这是一个很好用的数据同步工具，但问题在于其开源版本不支持实时同步，所以无法支持多级并行处理。而且因为内部设计没有分布式快照算法，无法保证数据的一致性，且无法支持断点续传。
　　2. 实时同步场景
　　在实时场景下，大家用得比较多的是 Flink 和 Spark Streaming。但由于这两个产品的定位是计算引擎，核心能力其实更多的是在于处理复杂的数据计算，很难像一个专业的数据同步产品一样支持足够多的数据源。而且两者从设计上来说容错力比较大，这就会导致在做多表同步时，一张表同步失败，整个作业都需要停掉重新执行。而且有些情况下需要写 Flink 和 Spark 代码，学习成本也有。
　　3. CDC 场景
　　对于 CDC 场景，目前大家使用比较多的还是 Flink CDC，但它的问题在于其底层还是 Flink，Flink 本身存在的问题它也有，而且不支持表结构的变更和单个 Source 读取多表（每个 Source只能读取一张表，意味着 CDC 同步时，需要使用的 JDBC 连接数和表的个数相等）。
　　综合下来，在数据集成场景下，用户如果想要支持所有场景，这三个组件都需要用到，整体的架构会非常复杂，而且需要公司有大数据平台，学习成本也相当高，在不同场景下，不同的代码管理也很难。
　　这些痛点，下一代数据集成平台 SeaTunnel 是都能解决的。
　　下一代数据集成平台Apache SeaTunnel
　　1
　　6大设计目标
　　SeaTunnel 的设计目标主要有总结为6个。第一个是它一定要简单易用，能够通过很少的配置，一些简单的命令，就能去起一个同步作业。
　　第二个点是它一定要能够做到同步的过程可监控，指标一定要可量化，让用户清晰地知道当前同步作业的情况，不能是一个黑盒。
　　第三个是要有丰富的数据源支持，社区统计到的 500 多个数据源，目前社区已经支持了 100 多个，而且数据源支持增速很快，基本上一个 Q 能增长四五十个新数据源。
　　第四个很重要是要做到全场景支持，支持实时同步、离线同步、增量全量、CDC、多表同步等场景，不需要用户用各种工具去组合。
　　第五是要解决数据一致性的问题，保证那些对于数据一致性要求高的系统能够做到不丢失数据，数据也重复。
　　最后在性能上，我们需要在满足这些功能的基础上，思考如何减少资源的占用，减少对数据源的影响。
　　2
　　项目发展历程
　　这里也简单讲一下 SeaTunnel 项目的发展历程。这个项目其实在 2017 年的时候就已经开源了，当时是叫Waterdrop，有些公司可能早期用的还是 OPPO 的版本，我们在 2021 年 12 月份贡献给了 Apache 基金会，全票通过。经过三个月，在 2022 年3 月份我们发布了第一个 SeaTunnel 版本，10 月份完成了一次大版本的重构，重构主要带来的效果是它能够支持多引擎的运行，而且将整个设计和引擎进行了重构，扩展性更好了。11月，我们发布 SeaTunnel Zeta 这样一个专门用来做数据集成的引擎，12 月份就支持了 CDC 连接器，同时连接器的数量突破了 100 个。今年，我们很快会发布新的版本，可以支持 Flink 和 Spark 更高版本，Zeta Engine 会支持多表同步，表结构变更等特性。
　　3
　　用户遍布全球
　　SeaTunnel 社区目前有接近 5000 人，社区的贡献者超过 200，PR 的提交速度和合并的速度也比较快。另外，我们的用户覆盖了国内的互联网企业，比如 B 站、腾讯云等企业。在海外，Shopee，印度第二大电信运营商巴帝电信等也在使用 SeaTunnel。
　　核心设计和架构
　　1
　　整体架构
　　SeaTunnel 架构主要分为三个模块，第一个是数据源，包含了一些国内外的数据库；第二部分是目标端，其实目标端和数据源可以合成在一起，都叫数据源，主要也是数据库，SaaS服务，以及数据湖、仓等产品组件。从数据源到目标端，我们定义了一套专门用来做数据同步的 API，它是和引擎解耦的，理论上能扩展到很多引擎里。目前我们支持的引擎包括 SeaTunnel Zeta，Flink 和 Spark。
　　2
　　与引擎解耦的连接器API
　　这套 API 设计上的核心是与引擎进行解耦，专门针对数据集成场景，分为 Source的 API，Transform API，其实就是我们之前说到的小 t, Sink API，以及 CDC API。借助于 Translation API 进行翻译，可以让这些连接器在不同的引擎上执行。
　　在整个所有的引擎里，连接器 API 基于 checkpoint机制，核心的目标是能够集成不同引擎里面的分布式快照算法，并应用底层引擎的 checkpoint 能力，实现两阶段提交等特性，保证数据的一致性。
　　3
　　Source Connector
　　基于这套API，我们实现了 Source连接器，以JDBC连接器为例，支持离线和实时两种运 式，同 个连接器，只需要在env配置中指定job.mode为BATCH或STREAMING即可轻松切换离线和实时同步两种模式。
　　Source 连接器主要提供的能力包含并行读取、动态发现分片、字段投影、Exactly-once 语义保证，底层借助了引擎提供的checkpoint 能力，加上 Source API 支持底层的引擎调用 checkpoint API，能够保证同步中数据不会丢失，也不会重复。
　　4
　　Sink Connector
　　Sink Connector 主要支持的特性包括： SaveMode支持，灵活选择目标表现有数据的处理 式 自动建表，支持建表模板修改，多表同步场景下解放双  Exactly-once语义支持，数据不丢失也不会重复，CheckPoint能 适配Zeta,Spark,Flink三种引擎 CDC支持，支持处理数据库日志事件
　　5
　　Transform Connector
　　Transform Connector 的主要功能包括： 支持复制一列到新列 支持字段改名、改顺序、类型修改、删除列 支持替换数据中的内容 支持将一列拆分成多列 CDC Connector设计
　　CDC Connector 主要具有以下功能： 支持无锁并行快照历史数据 支持动态加表 支持分库分表和多结构表读取 支持Schemaevolution 支持Checkpoint流程，保证数据不丢失不重复 支持离线批量CDC同步
　　6
　　Checkpoint功能设计
　　最后需要强调的是，SeaTunnel 所有的 Connector 都是基于 checkpoint 逻辑来设计的。作业从 Split 枚举器开始，进入到 Source 的 reader 中，经过读取后将数据发送给 Sink Writer，最终由 AggregateCommitter 提交。
　　下一代数据集成引擎SeaTunnel Zeta
　　下一代数据集成引擎SeaTunnel Zeta 的定位是一个简单易用，全场景数据集成的专用引擎，并在此基础上实现更快、更稳定、更省资源。
　　1
　　SeaTunnel Zeta集群管理
　　SeaTunnel Zeta 的集群管理方式有以下几个特点：
　　不需要依赖三方组件，不依赖大数据平台
　　• 无主（自选主）
　　• WAL，整个集群重启也可恢复之前正在运行的作业
　　• 支持分布式快照算法，保障数据一致性
　　接下来介绍一下 SeaTunnel Zeta引擎里的一些专有属性，以及其解决了什么核心问题。
　　2
　　SeaTunnel Zeta PipelineBase Failover
　　无论是批作业，还是流作业，以Pipeline为单位进行资源分配，Pipeline分配到所需资源后即可开始执行，不会等待所有task 都获取到资源。这可以解决 Flink 等引擎在数据同步时的一些痛点问题，也就是作业中有多个 Source 和 Sink 进行同步时，如果任何一端出现问题，整个作业都会被标为失败而被停止。 以Pipeline为粒度进行容错（Checkpoint, 状态回滚），目标表出现问题后，只会影响到上下游任务，其他任务会正常执行。
　　问题解决后，支持对单个Pipeline进行手工恢复。
　　3
　　SeaTunnel Zeta 动态线程共享
　　动态线程核心是要减少 CDC 多表同步，尤其是大量小表存在的场景下，由于资源有限而且线程多而导致性能下降的问题。动态线程可以根据运行时间和数据量对线程进行动态匹配，节约资源。经过测试，在单个 JVM 场景下运行 500 个小表的 job，开启动态线程之后性能可以提升 2 倍以上。
　　4
　　SeaTunnel Zeta 连接池共享
　　连接池共享主要用于解决大量 JDBC 占用的场景，比如单个非常大的表，有很多个并行 Task 去处理，或者多表离线同步，多表 CDC 同步等。连接池共享可以让同一个 TaskExecutionService 节点上的同一个Job 共享 JDBC 连接，从而减少 JDBC 使用。
　　5
　　SeaTunnel Zeta多表同步
　　最后是多表同步，主要应用于 CDC Source 读完了之后进行 tablel partition transform 处理，将数据分发到不同的 Sink 里，每个 Sink 会处理一张表的数据。在这个过程中会利用到连接器共享来降低 JDBC 连接的使用，以及动态线程共享来降低线程使用，从而提高性能。
　　6
　　性能对比
　　我们进行了性能测试，主要包括 SeaTunnel 从 MySQL 数据同步至 Hive 等本地环境下，以及 MySQL 同步至 S3 云测试环境下的性能表现。
　　测试环境：
　　-------------------------------------------------------------- -
　　本地测试场景：MySQL-Hive, Postgres-Hive, SQLServer-Hive,
　　Orache-Hive
　　-------------------------------------------------------------- -
　　云测试场景：MySQL-S3
　　列数：32，基本包含大部分数据类型
　　行数：3000w行
　　Hive文件text格式18G
　　测试节点：1， 8C16G
　　-------------------------------------------------------------- -
　　结果：
　　--------------------------------------------------------------
　　本地测试：SeaTunnel Zeta VS DataX
　　SeaTunnel Zeta 比 DataX 同步数据快 30-50% 左右。
　　内存对 SeaTunnel Zeta 的性能没有显著影响。
　　-------------------------------------------------------------- -
　　云数据同步：
　　SeaTunnel 在 MySQL 到 S3 场景下性能是 Airbyte 的 30 多，是 AWS DMS 和 Glue 的 2 到 5 倍。
　　-------------------------------------------------------------- -
　　可以看到，SeaTunnel 在很小的内存下就能够完成同步，而且还是在单点的情况下，因为 Zeta 支持分布式，相信在数量级更大，多机并行下，SeaTunnel 会有更好的性能表现。
　　近期规划&参与社区
　　SeaTunnel 近期计划完成一些新特性的支持，包括：
　　Spark3支持
　　• Flink15、16支持
　　• Schema evolution
　　• 多表同步
　　...
　　对我们的工作感兴趣的小伙伴欢迎加入到 SeaTunnel 社区！