Append模式每次都生成新的parquet文件，不涉及数据修改、去重

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

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

一般来说在使用Streaming Api编程时都建议给算子自定义uid，特别有些转换涉及到状态，因为算子ID是算子和状态之间的纽带，一直都认为指定的uid就是最终的算子ID。但是在基于flink sql层次编程时，很多时候并不清楚整个job最由多少个算子组成，也不知道每个算子的ID是怎么生成的，以及如果进行个修改会不会不能从状态中恢复。

hudi的索引机制是为了加速upsert/delete操作，它维护着（分区 + key）-> fileID之间的映射关系，所以可以减少对非必要base文件的合并

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

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

hudi自身支持ChangelogModes#FULL & ChangelogModes#UPSERT 两种模式

flink可以以local或cluster方式运行job，一般来说在本地开发调试时就以local在idea中运行，完成后就提交到cluster.根据资源管理器不同又可以分为standalone,yarn,k8s等，从命令参数也可以看出，flink对yarn和k8s的支持是最好的。

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

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

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

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

UnsafeRow是InternalRow的子类，它表示一个可变的基于原始内存(raw-memory)的二进制行格式，简单来说UnsafeRow代表一行记录，用于替代java对象（属于Tungsten计划的一部分，可以减少内存使用以及GC开销）

spark计算框架使用内存构成分析