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