追忆Teradata的ELT工具，展望现代数据集成工具特性

来源于： https://ai2news.com/blog/2592817/ 

 追忆似水年华，其实就是回望烟雨长路，看流水东去，落花成冢。

上周Teradata退出中国，我公众号的一篇《[再见，我的数仓黄埔军校，Teradata正式退出中国](http://mp.weixin.qq.com/s?__biz=MzA4NDQzMjU3MA==&mid=2247483787&idx=1&sn=0debe708323527b68ff7957f26451359&chksm=9fe6025ea8918b48670e9e0ea0a1c32162fb17f3ad3028907a2462d8af3192b28bc0c37136bf&scene=21#wechat_redirect)[！](http://mp.weixin.qq.com/s?__biz=MzA4NDQzMjU3MA==&mid=2247483787&idx=1&sn=0debe708323527b68ff7957f26451359&chksm=9fe6025ea8918b48670e9e0ea0a1c32162fb17f3ad3028907a2462d8af3192b28bc0c37136bf&scene=21#wechat_redirect)》引起无数数据行业老炮感慨。

前两天，我又看到一篇《[致敬即将逝去的 Teradata Automation！](http://mp.weixin.qq.com/s?__biz=MzkxNDMwMTI0NQ==&mid=2247484987&idx=1&sn=1021751d46c942bf8458762cdcd81130&chksm=c171ce69f606477f9538c4dfccc33812b2ec2c0d7ae59e4dde31553126fa215b333b96f09607&scene=21#wechat_redirect)》文章里面提到的Teradata的Load工具 FastLoad、BTEQ、Multiload、TPump、Parallel Transporter \(TPT\) ，一下打开了我回忆的闸门，想起快20年前，自己手敲代码调试的年代以及这些陪伴我共同奋战老伙计们。今天追忆下这些陪伴我们初入职场的Teradata工具集的业务场景，也聊一聊对现代数据集成工具的展望。

Teradata因为它数据仓库的超级强大，所以它也是最早遵循ELT架构的数据仓库，那个时代没有Apache SeaTunnel 、FiveTran、Airbyte、这些专门的Data Ingestion/Data Integration工具，只有Informatica/Datastage这些ETL工具。Teradata为了更好更快地把各类数据在各种场景下快速把数据装载到Teradata数据仓库当中，针对各个场景开发了一系列的工具集合，包括FastLoad、BTEQ、Multiload、TPump。所以，经常有人针对这么多ELT工具的分不清楚，其实当年Teradata因为遇到全球最大量的数据加载集成场景，针对每个细分场景都设计了一个工具以达到性能最高的目标，后续才有的Parallel Transporter \(TPT\) ，针对每个工具的场景实现进行了集成。

追忆Teradata的ELT工具特性

这些工具的初始版虽然很有年代感，但是这些业务场景却持续存在，2022年Teradata的数据导入还发布了新版本的Teradata Parallel Transporter \(TPT\)，可见数据集成的技术和场景一直在发展。我们今天这里追忆Teradata ELT工具集业务场景，并展望下现代技术集成工具应有的特性：

超高速加载数据进入空表-Teradata Fastload： **

**

针对空表加载，Teradata单独设立了快速加载方式Fastload，从而可以把复杂的数据快速加载到数据准备层中的日表/月表（当年叫做SData, 类似于分库分表），然后在进行后续原子层（PData）的加工统一在一张流水表当中，场景非常确定。而从技术实现来看，Fastload会以直接写不同节点上Teradata数据文件的方式快速实现，特性如下：

      *  _目标表必须为空才能使用 FastLoad_
  *  _仅支持插入——无法在 FastLoad 中执行更新或删除  
 Fastload虽然使用多个session来加载数据，但是一次只能处理一张目标表_  

  *  _Teradata Fastload 不支持连接索引、目标表中的外键引用和定义了二级索引的表。有必要在加载之前删除列出的任何约束并在之后重新创建它们。  
 系统管理员可以调整并发 Teradata Fastload 任务的最大数量。_
  *  _不会加载重复的行_

高速加载数据进入有数据的表-Teradata Multiload：

如果针对已经有数据的表，做追加、更新等操作，会使用Multiload，同样写数据文件的方式，可以使用Multiload模式，不过因为要支持更新、删除等操作，速率低于Fastload，但高于后续的数据加载：

      *  _以批量方式加载、更新和删除Teradata中的大表  
_
  *  _高效加载非常大的表  
_
  *  _一次可以加载多个表  
_
  *  _以块模式更新数据库中的数据（一次物理写入可以更新多行）  
_
  *  _使用表级锁  
_
  *  _资源消耗：以尽可能高的吞吐量加载  
_
  *  _允许重复行_

大批量数据SQL导入-Teradata BTEQ： **

**

BTEQ是最早的Teradata工具之一，支持已经有数据的表通过SQL的形式进行加载，可以把若干个SQL整合成一个提交任务一起执行，不过由于BTEQ效率比较低，所以，后续大家常见的用法是把BTEQ当做Teradata执行SQL任务的提交器使用，例如，它和Automation的整合，它的特性如下：

      *  _目标表普通数据库表格_
  *  _支持SQL脚本导入  
_
  *  _允许多个会话并将多行的数据打包到一条数据库消息中  
_
  *  _BTEQ 实用程序用于批处理和交互模式  
_
  *  _它可用于运行任何 DML 语句、DDL 语句、创建宏和存储过程  
_
  *  _出现锁表或冲突会停止加载导入_

实时数据集成-Teradata TPump： **

**

TPump是后来出现的Teradata工具，面对需要支持的数据流/CDC等，将SQL源源不断地加载到Teradata数据仓库当中。因为是实时数据加载，因此，面对可能出错或者锁表的情况，进行了特殊的处理：

      *  _目标表是普通数据库表格  
_
  *  _支持SQL脚本实时不间断的导入  
_
  *  _允许多个会话并将多行的数据打包到一条数据库消息中  
_
  *  _对“序列化”的支持以限制会话之间的锁冲突  
_
  *  _支持记录错误但继续加载_

全面数据集成工具-Teradata Parallel Transporter (TPT)

**
**

后续，Teradata发布了Teradata Parallel Transporter。前面的工具都是单线程的，一般一个表一个线程，开多个表可能对资源有争抢，没有办法很好的协调多线程之间的协调情况。TPT的发布解决了这个问题，同时融合了前面所有的工具，fastload对应tpt里的load operator，multiload对应tpt里的update operator，tpump对应tpt里的stream operator，bteq对应tpt里的sql operator，并增加了Command Operator等。

      *  _支持多线程加载  
_
  *  _支持多数据源兼容（文件、流、sql或data connector支持类型）  
_
  *  _支持类SQL语言来针对数据进行细微调整_
  *  _https://www.docs.teradata.com/r/Teradata-Parallel-Transporter-User-Guide/June-2022/Introduction-to-Teradata-PT/High-Level-Description_

 

展望未来的数据集成工具应有的特性

 

_ 多数据源支持_ **
**

当前业务场景属于混合数据源大爆发时代，和早期数据仓库场景完全不同，除了传统的数据库例如MySQL，SQLServer，Oracle等数据库和文件数据，还有消息中间件Kafka，Pulsar的实时消息数据，加上云上数据库AWS Redshift，AWS Aurora，Oracle Cloud Service，还有数不清的各种SaaS数据源Workday、Salesforce、Google Analytics，如何简便、准确、高效地把数据快速集成到目标数据源当中是最重要的特性之一。这个场景下，开源的Apache SeaTunnel支持了100多个Connector，不过还是沧海一粟，需要更多的Connector才会支持的

_ 数据一致性特性_ **

**

数据同步和集成，高效的同时一定确保数据一致性，这个一致性包括：

• 源端或目标端出现问题时，数据缓存机制
• 任何节点出现问题时，Checkpoint和事务回滚机制
• 分库分表或者多分区并行读取时的协同
• 大量数据集成时断点续传能力等

在复杂数据源情况下，一致性挑战性不小，例如数据源情况越复杂，并行处理的场景越复杂，数据一致性越难全部保证，这在Apache SeaTunnel也是在这里遇到了太多现有引擎无法实现的挑战，舍弃Flink和Spark，最后单独设计了Zeta引擎来满足各种同步数据一致性需求。

_ 高速大批量数据抽取/加载_ **

**

数据同步集成和普通的ETL不同，往往面临的是大批量异构数据加载集成的问题，所以，Teradata在这里都能根据不同场景衍生出很多工具或者算子出来，总结下其实有这样几个场景需要做到的：

• 高速多线程抽取/加载

• 高速加载到数据库底层文件（空表/非空表）

• 限流抽取/加载

• 整库、多表数据同步加载

• 支持自动建表和针对已有表数据出现冲突时的复杂处理

  这些场景都是在不同数据源之间进行数据集成的时候非常常见的需求。目前，像Apache Hbase的Bulkload，或者Apache SeaTunnel Sink里面的ClickHouse File这些组件都已经开始向这些方向进取，我相信随着用户场景的增加贡献者的增加，这些需求也一定会得到满足。

_ 实时数据与CDC支持_ **

**

当年Teradata针对实时数据加载产生了TPump，在现在的数据环境里具有很多更复杂的实时场景，数据源可能是Kafka、SaaS API、或者是数据库的Binlog，此时，新一代的数据集成工具也一定支持更多的实时场景：

• 消息中间件实时读取并实时向目标数据源写入

• 支持数据库Binlog解析与CDC（Change Data Capture）

• 支持表自动变更（Schema Evolution），例如针对湖入库的变更

• 目标数据是批量数据时，支持实时数据缓存再转为微批量加载

  随着数据湖（Data Lake）的普及，越来越多的贴源实时数据场景出现，实时数据和CDC场景是未来数据集成工具必备的功能。目前我在推进的开源社区Apache SeaTunnel也刚刚支持了部分例如MySQL、POSTGRE 的CDC和各种消息中间件的实时处理，要支持上述场景还有很多的工作要做。

一读多写与多写一读

随着数据场景的复杂，往往一份数据源会被实时、批量数据多次引用，如果按照过去的流和批分配处理的方式，那么就需要两次读取的代价，此时，一次读取向多个目标端写入的需求就出现了。往往，我们会在数据读取后，向实时数据仓库和批量的数据湖分别都写一份，这样批和流的数据一致性更容易保证。而在分库分表的场景下有多个数据源同时向一张表里同步数据的情况。多源读在目标一次写入的需求也很明确。 

其实在数据集成这个领域里，还有很多的场景要去做，过去，我们只关注了很多JDBC的方式来处理各种各样的场景，所以在Teradata和Hadoop年代我们都叫做ELT架构，就可以解决当前的问题。而目前，越来越多复杂的场景出现，于是在海外已经新的架构叫做 EtLT架构，小t代表归一化等简单的数据转化，而不是复杂的join、Group by这种逻辑转化，通过EtL把各种数据放到数据湖和数据仓库当中，然后利用数据湖和数据仓库强大的计算和SQL功能再进行复杂的业务加工：