Apache Hudi 原理解析二-- hudi upsert过程

Hudi的Upsert的过程整体分为3步（这里省略了很多不太重要的步骤）：

• 1、根据partitionPath进行重新分区。

• 2、根据recordKey确定哪些记录需要插入，哪些记录需要更新。对于需要更新的记录，还需要找到旧的记录所在的文件。（这个过程被称为tagging）

• 3、把记录写入实际的文件。

重新分区

无论DataFrame在写入前是如何分区的，Hudi都会对它们进行重新分区。重新分区的依据就是partitionPath。partitionPath相同的record都会被分到同一个partition，并交给一个executor负责写入。上面例子中的配置项PARTITIONPATH_FIELD_OPT_KEY就是用来指定record里面的哪个字段作为partitionPath。

Tagging

在确定了每个record的partition之后，接下来做的就是tagging。tagging是写入过程中最重要的一步，核心逻辑是确定每条record是insert还是update，以及如果是update，则定位到上次写入时的fileId。

Hudi如何确定一条record是insert还是update？是通过recordKey。用户在写入时需要指定每条record的recordKey，Hudi会用这个recordKey和现有的数据进行比对，如果找到一条key相同的record，则认为这次新的写入是update，否则就是insert。

对于一条update的数据，也就是说之前曾经插入过相同key的record，那么Hudi会把旧的record的fileId取出来，作为这条新record的fileId。之前一直没有解释fileId的含义，现在可以解释下了。fileId是Hudi为每条record赋予的id，用于标识这条record被保存在哪个文件里，或者更严格地说，是“哪一批文件”里。由于每次update都会生成一个新的文件，但是共享同一个fileId，所以最终会变成一批文件。Hudi把具有相同fileId的一批文件称为file group。最后，fileId本身是一个uuid，是全局唯一的。文件名里包含fileId1的2个文件就是一个file group

整个tagging过程还有一个显而易见的问题，那就是tagging需要在已有的数据里寻找key相同的record，如果表的数据量比较大时会非常耗时。为了解决这个问题，Hudi引入了index机制。

写入文件

当tagging完成以后，就会开始真正地写入数据。Hudi会把需要写入的数据分为insert和update两部分，update的数据会用原来的fileId进行写入，insert的数据则会生成一个新的fileId用于写入。值得一提的是，insert的数据也不会全部写入到同一个文件，而是到达了一定阈值（由hoodie.parquet.max.file.size配置项控制）以后，关闭当前文件，换一个新的文件继续写入（同时也会生成一个新的fileId）。