从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 呀!

相关推荐
苍老流年3 小时前
Hive中各种Join的实现
数据仓库·hive·hadoop
EDG Zmjjkk5 小时前
Hive 查询(详细实操版)
数据仓库·hive·hadoop
Hsu_kk6 小时前
Hive 查询各类型专利 Top 10 申请人及对应的专利申请数
数据仓库·hive·hadoop
大数据编程之光6 小时前
Hive 查询各类型专利 top10 申请人及专利申请数
大数据·数据仓库·hive·hadoop
杰克逊的日记6 小时前
Hive详解
数据仓库·hive·hadoop
码喽哈哈哈6 小时前
Kettle——CSV文件转换成excel文件输出
etl
Acrelhuang7 小时前
安科瑞5G基站直流叠光监控系统-安科瑞黄安南
大数据·数据库·数据仓库·物联网
消失在人海中8 小时前
数据仓库之 Atlas 血缘分析:揭示数据流奥秘
数据仓库
Hsu_kk8 小时前
Hive 查询用户连续三天登录的所有记录
数据仓库·hive·hadoop
RestCloud1 天前
如何理解ETLCloud在iPaas中的关键角色
etl·数据可视化·数据集成·数据传输·ipaas·集成工具