最近有个朋友,有几十 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 呀!