其他
数仓实时化改造:Hudi on Flink 在顺丰的实践应用
作者 | 蔡适择(顺丰大数据平台负责人)
整理 | 赵阳(Flink 社区志愿者)
顺丰业务介绍 Hudi on Flink 产品化支持 后续计划
1、顺丰业务
大数据平台,中间的基础部分是大数据平台,这块是顺丰结合开源组件自行搭建的。与之相关的是大数据分析与人工智能,顺丰有一个非常强的地面部队,就是线下的快递小哥以及运输车辆,需要使用 AI 以及大数据分析来辅助管理,提升整体效率。
区块链,顺丰对接了很多客户与商家,对于商家来说,首先需要确保快件是可信的能够做货物的交易与交换。这块涉及的基本上都是品牌商家,溯源与存证的业务顺丰也有涉及。
IoT,就像之前提及到的,因为顺丰地面部队较多,相应需要采集的数据也会比较多。我们的部分包裹中是有传感器的,车辆也有相关的传感器,如车辆的摄像头,以及快递小哥的手环(包含地理位置、员工的健康状态,对应做一些关怀的举动)。同时,还有一些工作场景既有叉车,也有分拣设备,这些就需要大数据平台来做一些联动,因此 IoT 的应用相对较多。
智慧供应链和智慧物流,这两块更多的是指如何用大数据的手段辅助业务做一些经营上的决策。比如我们有很多 B 端客户,对于他们来说如何在每个仓库里备货,如何协调以及互相调拨,这部分就由智慧物流来完成。
2、Hudi on Flink
首先,Hudi 提供了一个在 Hadoop 中更新删除的解决方案,所以它的核心在于能够增量更新,同时增量删除。增量更新的好处是国内与国际现在对隐私数据的保护要求比较高,比如在 Hive 中清理删除某一个用户的数据是比较困难的,相当于重新清洗一遍数据。使用 Hudi 可以根据主键快速抓取,并将其删除掉。
另外,时间漫游。之前我们有很多应用需要做准实时计算。如果要找出半个小时内的增量到底是什么,变化点在哪,必须要把一天的数据全捞出来,过滤一遍才能找出来。Hudi 提供时间漫游能力,只需要类似 SQL 的语法就能快速地把全部增量捞出来,然后后台应用使用时,就能够直接根据里面的数据做业务的更新,这是 Hudi 时间漫游里最重要的能力。
copy on write。
copy on write 这种形式更多是在每次写的时候,能够重写历史中关于更新记录所在的文件,把它重写并且把增量部分再重新记录下来,相当于把历史状态也给记录下来。唯一的不足之处在于,写的时候性能会稍微弱,但是读的性能是很强的,和正常使用 Hive 没有什么区别。这个也是 Hudi 本身的优点。实时性略低,这部分取决于写的文件合并的频率。不过批量的话,写也不会影响到多少性能,所以本身也是批量的去写。比如每隔几分钟写一次,这个其实也不会产生很高的性能损耗,这就是 copy on write。
merge on read
merge on read 就是写的时候实时会把 log 以 append 方式写到 HDFS 中并写成文件,然后在读的时候将已经生成的文本,再加上增量的部分合并,做一个 merge 操作。好处在于查询的时候数据都是实时的,但是由于查询任务确实较多,相当于是说每次查的时候,都要把两部分数据取出来并做一个合并,因此也会造成损耗。
一部分是 DML,它会有过滤,当库里面有 100 张表时,很多时候有些表是不需要的,这部分我们会直接过滤掉,过滤就主要是通过产品化来打通它。
另一部分是 DDl,能够实时更新 schema。比如库表字段的增加或者变更,再或者可能加了个表或者改了一个表,这部分会在实时程序中打通数据直通车,只要有任何变更,就会生成一个新的版本,然后将元数据信息记录到直通车里,同时也会包装到 binlog kafka sink 里记录,每一行会打上相应的版本号。这样的话就对于后面的使用就能够直接对应该条记录,使用非常方便,不会有出错的情况。
第一层,对于 ODS,可以直接连接 Kafka,用 Hudi on Flink 的框架就能够完成。
第二层,DWD,这里也有两种办法:
一种是用 Flink SQL 先把实时的 Kafka 宽表做完,不过这种办法成本会高一点,相当于再次引入了 Kafka,整个数据链路变长,如果真正需要去用实时宽表可以小部分去推,但如果不存在纯实时数据的需求,就没有必要去做 DWD 的实时 Kafka 宽表。 另外,在没有 DWD 的实时 Kafka 宽表的情况下,如何完成上述离线层的 DWD 实时化?这里有几个步骤,首先创建一个维表的 UDF 做表关联,也是最方便的方式。其次,可以考虑直接用 join 的方式,用两个实时表来做关联,但可能存在关联不到的情况。
3、产品化支持
4、后续计划