更新时间:2024-05-28 GMT+08:00

Hudi表分区设计规范

规则

分区键不可以被更新:

Hudi具有主键唯一性机制,但在分区表的场景下通常只能保证分区内主键唯一,因此如果分区键的值发生变更后,会导致相同主键的行记录出现多条的情况。在以日期分区的场景,可采用数据的创建时间为分区字段,切记不要采用数据更新时间做分区。

当指定Hudi的索引类型为Global索引类型时,Hudi支持跨分区进行数据更新,但Global索引性能较差一般不建议使用。

建议

  • 事实表采用日期分区表,维度表采用非分区或者大颗粒度的日期分区

    是否采用分区表要根据表的总数据量、增量和使用方式来决定。从表的使用属性看事实表和维度表具有的特点:

    • 事实表:数据总量大,增量大,数据读取多以日期做切分,读取一定时间段的数据。
    • 维度表:总量相对小,增量小,多以更新操作为主,数据读取会是全表读取,或者按照对应业务ID过滤。

    基于以上考虑,维度表采用天分区会导致文件数过多,而且是全表读取,会导致所需要的文件读取Task过多,采用大颗粒度的日期分区,例如年分区,可以有效降低分区个数和文件数量;对于增量不是很大的维度表,也可以采用非分区表。如果维度表的总数据量很大或者增量也很大,可以考虑采用某个业务ID进行分区,在大部分数据处理逻辑中针对大维度表,会有一定的业务条件进行过滤来提升处理性能,这类表要结合一定的业务场景来进行优化,无法从单纯的日期分区进行优化。事实表读取方式都会按照时间段切分,近一年、近一个月或者近一天,读取的文件数相对稳定可控,所以事实表优先考虑日期分区表。

  • 分区采用日期字段,分区表粒度,要基于数据更新范围确定,不要过大也不要过小。

    分区粒度可以采用年、月、日,分区粒度的目标是减少同时写入的文件桶数,尤其是在有数据量更新,且更新数据有一定时间范围规律的,比如:近一个月的数据更新占比最大,可以按照月份创建分区;近一天内的数据更新占比大,可以按照天进行分区。

    采用Bucket索引,写入是通过主键Hash打散的,数据会均匀的写入到分区下每个桶。因为各个分区的数据量是会有波动的,分区下桶的个数设计一般会按照最大分区数据量计算,这样会出现越细粒度的分区,桶的个数会冗余越多。例如:

    采用天级分区,平均的日增数据量是3GB,最多一天的日志是8GB,这个会采用Bucket桶数= 8GB/2GB = 4 来创建表;每天的更新数据占比较高,且主要分散到近一个月。这样会导致结果是,每天的数据会写入到全月的Bucket桶中,那就是4*30 = 120个桶。如果采用月分区,分区桶的个数= 3GB * 30 /2GB = 45个桶 ,这样写入的数据桶数减少到了45个桶。在有限的计算资源下,写入的桶数越少,性能越高。