Hudi数据管理

一、表数据结构

一个hudi表的存储文件分为两类

.hoodie文件：由于CRUD的零散性，每一次的操作都会生成一个文件，这些小文件越来越多后，会严重影响HDFS的性能，Hudi设计了一套文件合并机制。.hoodie文件夹中存放了对应的文件合并操作相关的日志文件。

americas和asia相关的路径是实际的数据文件，按分区存储，分区的路径key是可以指定的。

 

（1）.hoodie文件

    hudi把随着时间流逝，对表的一系列CRUD操作叫做Timeline,Timeline中某一次的操作，叫做Instant。

        Instant Action，记录本次操作是一次数据提交（COMMITS），还是文件合并（COMPACTION），或者是文件清理（CLEANS）

        Instant Time，本次操作发生的时间

        State，操作的状态，发起（REQUESTED），进行中（INFLIGHT）,已完成（COMPLETED）

    .hoddie文件夹中存放对应操作的状态记录

    

 

（2）数据文件

    hudi真实的数据文件使用Parquet文件格式存储

    

    其中包含一个metadata元数据文件和数据文件parquet列式存储

    hudi为了实现数据的CRUD，需要能够唯一标识一条记录，hudi将把数据集中的唯一字段(record key) + 数据所在分区(partitonPath)联合起来当做数据的唯一键

 

 

二、数据存储

hudi数据集的组织目录结构与hive非常相似，一份数据集对应一个根目录。数据集被打散为多个分区，分区字段以文件夹形式存在，该文件夹包含该分区的所有文件。

 

在根目录下，每个分区都有唯一的分区路径，每个分区数据存储在多个文件中

 

每个文件都有唯一的fileId和生成文件的commit所标识。如果发生更新操作时，多个文件共享相同的fileId,但会有不同的commit

 

三、Metadata 元数据

以时间轴(timeline)的形式将数据集上的各项操作元数据维护起来，以支持数据集的瞬态视图，这部分元数据存储于根目录下的元数据目录。

一共有三种类型的元数据：

    Commits：一个单独的commit包含对数据集上一批数据的一次原子写入操作的相关信息。我们用单调递增的时间戳来标识commits，标的是一次写入操作的开始。

    Cleans：用于清除数据集中不再被查询所用到的旧版本文件的后台活动。

    Compactions：用于协调hudi内部的数据结构差异的后台活动。例如，将更新操作由基于行存的日志文件归集到列式数据上。

 

四、Index索引

hudi维护着一个索引，以支持在记录key存在情况下，将新纪录的key快速映射到对应的fileId。

    Bloom filter：默认。存储于数据文件页脚。默认选项，不依赖外部系统实现。数据和索引始终保持一致。

    Apache HBase：可高效查找一小批key。在索引标记期间，此选项可能快几秒钟。

 

 

五、Data数据

hudi以两种不通的存储格式存储所有摄取的数据，用户可选择满足下列条件的任意数据格式：

    读优化的列存格式（ROFormat）：缺省值为Apache Parquet

    写优化的行存格式（WOFormat）：缺省值为Apache Avro