30分钟掌握沧湖一体化：flink+hudi（干货，建议收藏）_flink hudi sink

• 索引，将传入的记录键快速映射到文件（如果已存在记录键）。索引实现是可插拔的，Bloom过滤器-由于不依赖任何外部系统，因此它是默认配置，索引和数据始终保持一致。Apache HBase-对少量key更高效。在索引标记过程中可能会节省几秒钟。
• 数据，Hudi以两种不同的存储格式存储数据。实际使用的格式是可插入的，但要求具有以下特征–读优化的列存储格式（ROFormat），默认值为Apache Parquet；写优化的基于行的存储格式（WOFormat），默认值为Apache Avro。

为什么Hudi对于大规模和近实时应用很重要？

Hudi解决了以下限制

• HDFS的可伸缩性限制
• 需要在Hadoop中更快地呈现数据
• 没有直接支持对现有数据的更新和删除
• 快速的ETL和建模
• 要检索所有更新的记录，无论这些更新是添加到最近日期分区的新记录还是对旧数据的更新，Hudi都允许用户使用最后一个检查点时间戳。此过程不用执行扫描整个源表的查询

Hudi的优势

• HDFS中的可伸缩性限制。
• Hadoop中数据的快速呈现
• 支持对于现有数据的更新和删除
• 快速的ETL和建模

（以上内容主要引用于：Apache Hudi 详解_风中云彩的博客-优快云博客）

新架构与湖仓一体

通过湖仓一体、流批一体，准实时场景下做到了：数据同源、同计算引擎、同存储、同计算口径。数据的时效性可以到分钟级，能很好的满足业务准实时数仓的需求。下面是架构图：

MySQL 数据通过 Flink CDC 进入到 Kafka。之所以数据先入 Kafka 而不是直接入 Hudi，是为了实现多个实时任务复用 MySQL 过来的数据，避免多个任务通过 Flink CDC 接 MySQL 表以及 Binlog，对 MySQL 库的性能造成影响。

通过 CDC 进入到 Kafka 的数据除了落一份到离线数据仓库的 ODS 层之外，会同时按照实时数据仓库的链路，从 ODS->DWD->DWS->OLAP 数据库，最后供报表等数据服务使用。实时数仓的每一层结果数据会准实时的落一份到离线数仓，通过这种方式做到程序一次开发、指标口径统一，数据统一。

从架构图上，可以看到有一步数据修正 (重跑历史数据) 的动作，之所以有这一步是考虑到：有可能存在由于口径调整或者前一天的实时任务计算结果错误，导致重跑历史数据的情况。

而存储在 Kafka 的数据有失效时间，不会存太久的历史数据，重跑很久的历史数据无法从 Kafka 中获取历史源数据。再者，如果把大量的历史数据再一次推到 Kafka，走实时计算的链路来修正历史数据，可能会影响当天的实时作业。所以针对重跑历史数据，会通过数据修正这一步来处理。

总体上说，这个架构属于 Lambda 和 Kappa 混搭的架构。流批一体数据仓库的各个数据链路有数据质量校验的流程。第二天对前一天的数据进行对账，如果前一天实时计算的数据无异常，则不需要修正数据，Kappa 架构已经足够。

（本节内容，引用自：37 手游基于 Flink CDC + Hudi 湖仓一体方案实践）

最佳实践

版本搭配

版本选择，这个问题可能会成为困扰大家的第一个绊脚石，下面是hudi中文社区推荐的版本适配：

flink	hudi
1.12.2	0.9.0
1.13.1	0.10.0

官方说的支持版本是这样， 不过目前我的1.13和0.10组合并没有配置成功，所以大家还是尽量选择 1.12.2+0.9.0 吧，配合scala 2.11 。

下载hudi

https://mvnrepository.com/artifact/org.apache.hudi/hudi-flink-bundle

执行

如果将 hudi-flink-bundle_2.11-0.9.0.jar 放到了 flink/lib 下，则只需要如下执行即可，否则会出现各种找不到类的异常

bin/sql-client.sh embedded