针对实时写入，选择了时效性更好的MOR。

考察了索引类型，首先因为WAL不能每次都获取到数据的分区，所以必须要全局索引。在几种全局索引实现中，为了实现高性能的写入，HBase是唯一的选择。另外两种的实现决定了都和HBase在性能有本质上的差距。

在计算引擎上和API上，当时Hudi对Flink的支持还不是特别完善，所以选择了更为成熟的Spark，为了能灵活实现一些定制功能和逻辑，也因为DataFrame的API语义限制比较多，所以选择了更底层的RDD API。

首先我们基于一种内部的存储提供的语义实现了原子变更和异地多活。用户可以通过接口原子地触发Schema变更并立刻获得结果。

并通过加入版本号的方法实现了Schema的多版本，有了版本号之后可以方便的使用Schema而不是把Json传来传去。有了多版本也可以实现Schema更灵活的演进。

我们还支持了列级别的额外信息编码，来帮助业务实现一些场景下特有的扩展功能。并把列名替换成了数字来节约使用过程中的开销。

Hudi的Spark Job在使用的时候会在JVM级别构建一个local cache并通过pull的方式和元数据中心同步数据，实现Schema的快速访问和进程内Schema的单例。

Schema：数据使用Avro序列化开销特别大，而且消耗资源也非常多。针对这个问题，我们首先借助Schema的JVM单例，规避了序列化过程中很多费CPU的比较操作。

通过优化Payload逻辑，减少了需要序列化的次数。

借助了第三方的Avro序列化实现，通过将序列化过程编译成字节码的方式来提高SerDe的速度以及降低内存占用。对这种序列化形式做了修改，以保证我们的复杂Schema也能够正常编译。

Hudi除了默认的Inline/Async compaction选项之外，还支持Compaction的灵活部署。Compaction Job的作业特性和Ingestion作业其实有较大区别。在同一个Spark Application当中不仅不能针对性设置，也存在资源弹性不足的问题。我们首先构建了独立部署的脚本，让Compaction作业可以独立触发运行。使用了低成本的混部队列并可以针对此次Compaction的Plan做资源申请。除此之外还做了基于规则和启发式的Compaction Strategy，用户的需求通常是保证天级别或者小时级别的SLA，并针对性地压缩某些分区的数据，所以提供了针对性压缩的能力。

为了能缩短关键Compaction的时间，我们通常会提前做Compaction来避免所有工作都在一个Compaction Job中完成。但是如果一个Compact过的FileGroup又有新的Update，就不得不再次Compact。为了优化整体的效率，我们根据业务信息对一个FileGroup该在何时被压缩做了启发式的调度以减少额外的压缩损耗。该特性的具体收益还在评估中。

最后我们对Compaction做了一些流程的优化，比如不使用WriteStatus的Cache等等。

首先把原有的数据HSync操作替换为HFlush，避免了分散性update导致的磁盘IO写放大。

针对场景调参做了激进的pipeline切换设置，并且HDFS团队开发了灵活的可以控制pipeline的api，来实现这个场景下灵活的配置。

最后还通过logfile独立IO隔离的方式保证了实时写入的时效性。