从ETL与ELT谈起，理解数仓的任务

最近有个朋友，有几十 PB 的异构数据，数据源包括 MySQL、DB2、Oracle、CSV、磁带机，等等，然后他需要把这些数据中的一些信息做关联整合，从这几十 PB 的数据中提取出若干业务字段到数据仓库，做统一分析。

数据载入

他让我推荐数据提取工具，我学习了一下，发现带 GUI 的开源工具里，AirByte 非常不错，界面大方，支持的 Connector 种类丰富。但是，当我深入研究下去发现一个问题，它的文档里居然没有任何从表格里提取出若干列做同步的描述，倒是支持把数据同步到目标库后，再基于 dbt 做自动转换的能力。再一学习才注意到：AirByte 是一个 E-L-T！ 工具，而不是一个 ETL 工具！ELT、ETL，一字之差，用途相差万里。

• E：Extract，指的是从源端拉取数据，可能是一个 SELECT、可能是 BINLOG、可能是一个文本文件读取动作
• L：Load，指的是把数据装载到数据仓库，通常基于 INSERT 语句实现。
• T：Transform，指的是对数据做转换。在 ETL 中，T 通常是由负责数据同步的软件来完成，在 ELT 中，这个门道就多了，负责数据同步的软件一定会做 E、L 两个操作，至于后面的 T，在 AirByte 中它提供的解决方案是 dbt，在其它系统里，可能会依赖目标库/湖的其它解决方案，可以非常灵活。

我以前觉得，ELT 是真好，方便多了。数据先入湖，以后随时用随时变换，多方便灵活。嗯，看上去很美。而实际上，对应的麻烦事可真是一大堆！

• 数据传输成本大增。我朋友的这个案例里，他的原始数据有几十 PB，但是抽取后的目标数据，大概就是百 T 的水平。ETL 只需要传百 T 的数据，而 ELT 则需要传输几十 PB 的数据，百倍的差距。
• 存储成本大增。全量数据存在目标库里，会有非常大的存储成本。还不敢随便用过期策略。
• 管理成本大增。因为数据已经入了湖，但是里面大部分是永远用不到的垃圾数据，如何管理这些数据，也是个头疼事。

从这个实际案例我意识到，ETL、ELT 没有好坏之分，用 ETL 还是 ELT，还是要根据业务来选择。浪漫、性感，在成本面前，不值一提。

数仓

另一个直观的感受就是“数仓”的概念很具体了。数仓很大的价值点就是数据归集作用，这个案例里体现得非常明显。

我挺想给他推荐 OceanBase 开源版的，可惜他要求数据全场景加密，TDE（Transparent Data Encryption）必不可少。而这个我们没有开源。

另外就是我们的存储成本还是高，他的场景里，如果数据存在 S3 里，延迟大点也能接受，QPS 非常低，一天也就查几次。这个挺适合 4.4 的场景，但目标的场景不划算。

最后，他这个场景我给他推荐了 Snowflake，S3存储成本很低，QPS 非常低，说不定机器还可以随用随关。

其它

AirByte 不太行，于是看了 Kettle 和 Astera，感觉 Kettle 像是上个时代的产物，没人维护了一样，Astera 感觉可能还可以，但是网站也很老旧，十年前的风格。TapData 商业版看上去还挺不错的，DB2作为数据源都支持，但是，搜下来，发现居然不支持以 Snowflake 作为目标写入！！！！

熬！AirByte，你怎么就不支持 ETL 了呢！你完全可以支持一个 ETLT 呀！