hudi使用mvcc来实现数据的读写一致性和并发控制，基于timeline实现对事务和表服务的管理，会产生大量比较小的数据文件和元数据文件。大量小文件会对存储和查询性能产生不利影响，包括增加文件系统的开销、文件管理的复杂性以及查询性能的下降。对于namenode而言，当整个集群中文件数到了几千万，就已经会变得很不稳定了。hudi自身提供了各种方法对表中产生的小文件进行了优化，总结下来无非是几种方式：

1. 合并现有小文件
2. 删除无用小文件
3. 对于支持append的文件系统，直接往小文件追加数据，如hdfs

元数据文件优化

hudi使用元数据文件来管理和维护表的元数据信息，包括表的结构、分区信息、数据文件的位置和版本等。.hoodie是元数据根目录，直接目录下在存储着活跃时间线下所有的元数据，一般不会被删除，通过配置来控制活跃时间线的跨度，进而限制了元数据文件数量的无限增长。如果活跃时间线跨度过长，在timeline上的一些操作将变得更低效，对读、写和其它表服务都影响很大(hudi通过timeline server和MDT可以对此进行优化)。

较久前的元数据文件会定时被归档形成归档时间线，保存在archived目录中，随着归档文件不断增加，归档后的文件会自动rollover或合并，这取决于文件系统是否支持append.

数据文件优化

hdfs的思想是一次写入多次读取，不支持对已经存储在文件系统中的数据进行直接修改。hudi不公支持数据修改，还增加了流式处理的场景，流写数据不像批处理那么容易控制单文件大小&