共计 3503 个字符，预计需要花费 9 分钟才能阅读完成。
Flink 中文学习网站
https://flink-learning.org.cn
前言
随着云数仓技术的一直成熟，数据湖俨然已成为当下最热门的技术之一，而 Apache Hudi 是当下最具竞争力的数据湖格局之一：
- 领有最沉闷的开源社区之一，周沉闷 PR 始终维持在 50+ 程度；
- 领有最沉闷的国内用户群之一，目前的 Apache Hudi 钉钉群用户已超过 2200+，国内各大厂商都曾经布局 Apache Hudi 生态。
Apache Hudi 的活跃度得益于其杰出的 file format 设计和丰盛的事物语义反对：
- 类 LSM 的 file format 布局很好的适配了近实时更新场景，解决了超大数据集更新的痛点；
- Hudi 的事物层语义在目前的湖存储中是极其成熟和丰盛的，根本所有的数据治理都能够自动化实现：compaction、rollback、cleaning、clustering。
Flink On Hudi
Apache Hudi 的 table format 对流计算敌对的个性使得 Flink On Hudi 成为 Apache Hudi 我的项目最值得摸索和开掘的方向之一，Flink 不仅为 Hudi 解锁了超大数据流的实时更新能力、更增加了流式生产和计算的能力，让端到端近实时 ETL 得以在低成本的文件存储上轻松实现。
Flink On Hudi 我的项目在 2020 年 11 月立项，至今已迭代了三个版本，从第一个版本开始人气和活跃度就始终低落。5 月份组建的 Apache Hudi 钉钉群截止目前半年的工夫，曾经有超过 2200+ 用户，并且活跃度始终排在 Flink 用户群的前列。
Flink On Hudi 已成为部署 Apache Hudi 我的项目的首选计划，国内次要云厂商：阿里云、华为云、腾讯云，国外的 AWS 都已集成 Flink On Hudi；国内的大型互联网公司：头条、快手、B 站 以及传统企业：顺丰、海康等均有 Flink On Hudi 的生产实践，具钉钉群的跟踪回访等不齐全统计，至多超过 50+ 国内公司在生产上应用 Flink On Hudi，Uber 公司更将 Flink On Hudi 作为 2022 年的重点方向在推动！
Flink On Hudi 的开发者生态也十分沉闷，目前国内有阿里云、华为云、头条、B 站的同学继续奉献，Uber 公司和 AWS 更专门投入人力来对接 Flink On Hudi。
版本 Highlights
0.10.0 版本通过社区用户的千锤百炼，奉献了多项重要的 fix，更有外围读写能力的大幅加强，解锁了多个新场景，Flink On Hudi 侧的更新重点梳理如下：
Bug 修复
- 修复对象存储上极其 case 流读数据失落的问题 [HUDI-2548]；
- 修复全量 + 增量同步偶发的数据反复 [HUDI-2686]；
- 修复 changelog 模式下无奈正确处理 DELETE 音讯 [HUDI-2798]；
- 修复在线压缩的内存透露问题 [HUDI-2715]。
新个性
- 反对增量读取；
- 反对 batch 更新；
- 新增 Append 模式写入，同时反对小文件合并；
- 反对 metadata table。
性能加强
- 写入性能大幅晋升：优化写入内存、优化了小文件策略(更加平衡，无碎片文件)、优化了 write task 和 coordinator 的交互；
- 流读语义加强：新增参数
earliest，晋升从最早生产性能、反对参数跳过压缩读取，解决读取反复问题； - 在线压缩策略加强：新增 eager failover + rollback，压缩程序改为从最早开始；
- 优化事件程序语义：反对解决序，反对事件序主动推导。
上面挑一些重点内容为大家具体介绍。
小文件优化
Flink On Hudi 写入流程大抵分为以下几个组件：
- row data to hoodie：负责将 table 的数据结构转成 HoodieRecord；
- bucket assigner：负责新的文件 bucket(file group) 调配；
- write task：负责将数据写入文件存储；
- coordinator：负责写 trasaction 的发动和 commit；
- cleaner：负责数据清理。
其中的 bucket assigner 负责了文件 file group 的调配，也是小文件调配策略的外围组件。0.10.0 版本的每个 bucket assign task 持有一个 bucket assigner，每个 bucket assigner 独立治理本人的一组 file group 分组：
在写入 INSERT 数据的时候，bucket assigner 会扫描文件视图，查看以后治理的 file group 中哪些属于小文件领域，如果 file group 被断定为小文件，则会持续追加写入。比方上图中 task-1 会持续往 FG-1、FG-2 中追加 80MB 和 60MB 的数据。
为了防止适度的写放大，当可写入的 buffer 过小时会疏忽，比方上图中 FG-3、FG-4、FG-5 尽管是小文件，然而不会往文件中追加写。task-2 会新开一个 file group 写入。
全局文件视图
0.10.0 版本将本来 write task 端的文件视图对立挪到 JobManager，JobManager 启动之后会应用 Javaline 本地启动一个 web server，提供全局文件视图的拜访代理。Write task 通过发送 http 申请和 web server 交互，拿到以后写入的 file group 视图。
Web server 防止了反复的文件系统视图加载，极大的节俭了内存开销。
流读能力加强
0.10.0 版本新增了从最早生产数据的参数，通过指定 read.start-commit 为 earliest 即可流读全量 + 增量数据，值得一提的是，当从 earliest 开始生产时，第一次的 file split 抓取会走间接扫描文件视图的形式，在开启 metadata table 性能后，文件的扫描效率会大幅度晋升；之后的增量读取局部会扫描增量的 metadata，以便疾速轻量地获取增量的文件讯息。
新增解决程序
Apache Hudi 的音讯合并大体分为两块：增量数据外部合并、历史数据和增量数据合并。音讯之间合并通过
write.precombine.field 字段来判断版本新旧，如下图中标注蓝色方块的音讯为合并后被选中的音讯。
0.10.0 版本能够不指定 write.precombine.field 字段，此时应用解决程序：即起初的音讯比拟新，对应上图紫色局部被选中的音讯。
Metadata Table
Metadata table 是 0.7.0 Hudi 引入的性能，目标是在查问端缩小 DFS 的拜访，相似于文件 listings 和 partitions 信息间接通过 metadata table 查问获取。Metadata 在 0.10.0 版本失去大幅增强，Flink 端也反对了 该性能。
新版的 metadata table 为同步更新模型，当实现一次胜利的数据写入之后，coordinator 会先同步抽取文件列表、partiiton 列表等信息写入 metadata table 而后再写 event log 到 timeline（即 metadata 文件）。
Metadata table 的根本文件格式为 avro log，avro log 中的文件编码区别于失常的 MOR data log 文件，是由高效的 HFile data block 形成，这样做的益处是自持更高效率的 kv 查找。同时 metadata table 的 avro log 反对间接压缩成 HFile 文件，进一步优化查问效率。
总结和瞻望
在短短的半年工夫，Flink On Hudi 至今已积攒了数量宏大的用户群体。踊跃的用户反馈和丰盛的用户场景一直打磨 Flink On Hudi 的易用性和成熟度，使得 Flink On Hudi 我的项目以十分高效的模式疾速迭代。通过和头部公司如头条、B 站等共建的模式，Flink On Hudi 造成了十分良性的开发者用户群。
Flink On Hudi 是 Apache Hudi 社区接下来两个大版本次要的发力方向，在将来布局中，次要有三点：
- 欠缺端到端 streaming ETL 场景 反对原生的 change log、反对维表查问、反对更轻量的去重场景；
- Streaming 查问优化 record-level 索引，二级索引，独立的文件索引；
- Batch 查问优化 z-ordering、data skipping。
致谢
最初感激 Flink Hudi 沉闷的社区用户以及开发者，正是有你们一路相伴，Flink On Hudi 能力高效率地演变和迭代；也因为有你们，Flink On Hudi 在实时数据湖方向的摸索和实际逐步成为行业先驱，且越来越成熟 ~
对 Hudi 感兴趣的同学能够扫码退出钉群。
近期热点
Flink Forward Asia 2021 延期，线上相见
更多 Flink 相干技术问题，可扫码退出社区钉钉交换群
第一工夫获取最新技术文章和社区动静，请关注公众号～
