1032851561的博客

在非schema on read模式下对schema进行变更需要注意以下情况可以增加新字段，但是建议只是追加，而且新schema数据需写入成功后才进行查询可以删减字段，一般不建议不可以改变列的数据类型不支持更改列名。

hudi对schema evolution进行了统一设计，在官网文档中也指明了从0.11版本开始，spark-sql ddl是支持schema evolution的，而flink-sql在旧版本中并不支持ddl方式对表结构，所以full schema evolution都隐藏在读写过程中。对于使用者，我们最终只关心表的读和写，但从实现层面来看，schema evolution需要覆盖不同的数据文件格式，还需要集成在各种hudi的表服务中。

KeyGenerator和分区提取器都是插件化，并均提供了多种开箱即用实现，基本能覆盖常用的场景。两者的选择主要是依赖于分区的数量和数据类型。

Timeline Service（时间线服务）是hudi的一个组件，用于暴露接口给客户端，是一个基于Javalin+Jetty实现的web服务。当客户端使用远程文件系统视图()时，就是访问时间线服务http接口默认情况下，如果开启了时间线服务，则它运行在JobManager(如果是spark，则在driver中)，所有写任务都会向它发出请求。

hudi表的数据一直在演变过程中，存储在文件系统中的数据文件也在不断增加和版本迭代，hudi提供了的文件系统视图(filesystem view)来简单、直观地了解表中的数据分布情况、数据文件的状态和变化，以及数据的版本控制信息。SliceView当然，文件系统视图持续进行着自我更新、重置，以保持最新视图。

Append模式每次都生成新的parquet文件，不涉及数据修改、去重。cow+insert一直是append模式，mor+insert在0.13.1后也统一走append写流程append写过程比upsert简单直接得多，因此写入性能远优于upsert.

hudi使用mvcc来实现数据的读写一致性和并发控制，基于timeline实现对事务和表服务的管理，会产生大量比较小的数据文件和元数据文件。大量小文件会对存储和查询性能产生不利影响，包括增加文件系统的开销、文件管理的复杂性以及查询性能的下降。对于namenode而言，当整个集群中文件数到了几千万，就已经会变得很不稳定了。

hudi有很多种写入流程，使用不同的表类型、写类型()、索引类型(IndexType)，流程上都会有所差异。使用flink流式写MOR表场景比较多，顺道梳理一下这个流程的细节。

hudi在对mor进行增量查询时会出现首次checkpoint超时报错，从现象到原因分析，并提出几种解决方案进行对比。

曾经做数据同步受存储引擎和采集工具的限制，经常都是全量定时同步，亦或是以自增ID或时间作为增量的依据进行增量定时同步，无论是哪种，都存在数据延时较大、会重复同步不变的数据、浪费资源等问题。后来刚接触canal时还大感惊奇，基于mysql的binlog可以这么方便实时同步最新数据，然而历史数据的初始化仍然得使用第三方ETL工具来全量同步。直到flink cdc项目诞生，完全解决了前面的痛点。实时技术的发展已经不能满足于数据只能实时采集，还需要实时地进行数据建模和数据分析，即全链路实时。

hudi支持多种数据写入方式：insert、bulk_insert、upsert、boostrap，我们可以根据数据本身属性(append-only或upsert)来选择insert和upsert方式，同时也支持对历史数据的高效同步并嫁接到实时流程。

有个hudi mor的事实表，需要与外部的维表进行关联以生成明细宽表，方案是基于flink sql对事实表进行增量查询，同时与外部的维表进行lookup join，除了无需编码之外，通过jdbc的方式连接外部表还能利用flink jdbc-connector的缓存功能。这种join方式要求事实表必须有一个处理时间(process time)属性，所以在定义事实表时增加了一个计算列从flink sql的角度来看，这并没什么毛病，但是直接查这个表的数据时就会报错。

hudi的文件布局是能实现增量查询、数据更新等特性的基础，每个hudi表有一个固定的目录，存放元数据(.hoodie)以及数据文件，其中数据文件可以以分区方式进行划分，每个分区有多个数据文件(基础文件和日志文件)，这些数据文件在逻辑上被组织为文件组、文件分片上面的示例中，2023-02-15这个分区下有一个文件组，文件中组中有3个文件切片，其中一个只有log文件，一个只有base文件。

hudi的索引机制是为了加速upsert/delete操作，它维护着（分区 + key）-> fileID之间的映射关系，所以可以减少对非必要base文件的合并key是指索引key，可以是表的任意字段，在全局索引中常用主键key作为索引。

在中介绍了清理的大致流程，除了可以防止文件系统的无限膨胀，它是必须的。hudi提供三种查询方式：读优化、快照读、增量读，无论是哪种方式，由于hudi的文件组织是有版本的概念(FileGroup,FileSlice)，旧版本的文件持续在执行清理，如果被清理的文件正在读取或者即将被读取到，那岂不是很影响使用，所以我们需要设置合理的清理策略保障上层数据处理任务的平稳运行，提高系统的容错性。可以通过来配置使用以上哪一种清理策略。

hudi自身支持FULL & UPSERT 两种模式，两种模式分别在写入与读取有所差异。

引入hudi使用整个构架就是变得简单了，可以实现分钟级别的实时数仓，数据统一存储减少一致性的风险

flink smallint类型不兼容hudi

hudi会不断生成commit、deltacommit、clean等类型的Instant从而形成活跃时间轴（ActiveTimeline），随着时间增长，时间轴变长，.hoodie元数据目录下的文件不断累积，为了限制元数据文件数量，需要对一些比较久远的元数据文件进行归档，保存到.hoodie/archived目录下，可以称之为归档时间轴（ArchivedTimeline）。

压缩（compaction）仅作用于MergeOnRead类型表，MOR表每次增量提交（deltacommit）都会生成若干个日志文件（行存储的avro文件），为了避免读放大以及减少文件数量，需要配置合适的压缩策略将增量的log file合并到base file（parquet）中。...

hudi采用的是mvcc设计，提供了清理工具cleaner来把旧版本的文件分片删除，默认开启了清理功能，可以防止文件系统的存储空间和文件数量的无限增长。

hudi的两大特性流式查询和支持upsert/delete，hudi的数据变更是基于timeline的，所以时间点(Instant)就成为了实现增量查询的依据。在与flink集成中，当开启了流式读，其实就是一个持续的增量查询的过程，可以通过配置参数read.start-commit和read.end-commit来指定一个无状态的flinkjob的初始查询范围。...............