顺丰科技 Hudi on Flink 实时数仓实践

最新推荐文章于 2024-03-17 00:00:10 发布

阿里云技术

最新推荐文章于 2024-03-17 00:00:10 发布

阅读量154

点赞数

文章标签： flink spark big data

本文链接：https://blog.csdn.net/weixin_43970890/article/details/120719414

版权

顺丰科技在2019年采用Hudi on Spark，2020年升级至Hudi on Flink进行实时数仓建设，解决了Hudi代码漏洞和状态优化问题。在Flink的AT LEAST ONCE模式下，Hudi的丢数问题通过深入分析和调整得以解决。目前，他们正通过优化状态管理和利用Hudi的upsert能力，降低状态大小，如将Top One和多表Join操作下沉到Hudi。未来规划包括收集Parquet元数据和增强Flink的批处理能力。

摘要由CSDN通过智能技术生成

本文作者为刘杰，介绍了顺丰科技数仓的架构，趟过的一些问题、使用 Hudi 来优化整个 job 状态的实践细节，以及未来的一些规划。主要内容为：
1.数仓架构
2.Hudi 代码躺过的坑
3.状态优化
4.未来规划

顺丰科技早在 2019 年引入 Hudi ,当时是基于 Spark 批处理，2020 年对数据的实时性要求更高公司对架构进行了升级，在社区 Hudi on Flink 的半成品上持续优化实现 Binlog 数据 CDC 入湖。在 Hudi 社区飞速发展的同时公司今年对数仓也提出了新的要求，最终采用 Flink + Hudi 的方式来宽表的实时化。过程中遇到了很多问题主要有两点：

Hudi Master 代码当时存在一些漏洞；
宽表涉及到多个 Join，Top One 等操作使得状态很大。

庆幸的是社区的修复速度很给力加上 Hudi 强大 upsert 能力使这两个问题得到以有效的解决。

一、数仓架构

感兴趣的同学可以参考之前顺丰分享的 Hudi on Flink 在顺丰的实践应用。

二、Hudi 代码趟过的坑

在去年我们是基于 Hudi 0.6 左右进行的 Hudi on Flink 的实践，代码较老。为了拥抱社区我们使用最新 master 代码进行实践，在大数据量写入场景中，发现了一个比较隐秘的丢数问题，这个问题花了将近两周的时间才定位到。

1. HudiStreamWriteFunction算子核心流程梳理

StreamWriteFunction 算子收数据的时候会先把数据按照 fileld 分组缓存好，数据的持续流会使得缓存数据越来越大，当达到一定阈值时便会执行 flush。阈值由 2 个核心参数控制： write.batch.size 默认 64M ，write.task.max.size 默认 1G 。当单个分组数据达到 64M 或者总缓存数据达到 800M ~ 1G 就会触发 flush 。

flush 会调用 client 的 api 去创建一个 WriteHandle，然后把 WriteHandle 放入 Map 进行缓存，一个 handle 可以理解为对应一个文件的 cow。

如果一个 fileld 在同一 checkpoint 期间被多次写入，则后一次是基于前一次的 cow, 它的 handle 是一个
FlinkMergeAndReplaceHandle，判断一个 fileld 是否之前被写入过就是根据上面 Map 缓存得来的。