Parquet数据框按时间戳分区的最优实现与查询存储优化

你现在用的年/月/日/时四级分区，完全是踩了分区粒度过细的常见坑：

• 全年分钟级数据算下来总共也就52万多行，拆到小时粒度会产生 365*24=8760 个分区，每个分区里只有60行数据，生成的单个Parquet文件往往只有几百字节。
• 不管是Parquet格式还是底层的存储系统，读文件都有固定成本：每个Parquet文件要存schema、文件footer、行组索引、压缩块头，哪怕里面只有1行数据，这些固定开销也要占几百字节；存储层面打开一个小文件、定位文件块的开销，比读几KB实际数据的开销还要高。
• 这种极小的文件根本发挥不了Parquet的压缩优势：字典编码、RLE这类高效压缩算法需要一定量的同列数据才能达到高压缩比，单文件里每列就几十字节，压缩完甚至可能比原始数据还大。
• 算下来你现在的总磁盘占用里，90%以上都是这些无效的固定开销，根本不是实际的时序数据，这就是为啥分区后的总大小是未分区版本的10倍。而且查询的时候要遍历近万级的小文件元数据，反复给存储系统发寻址请求，读取速度自然比读几个大的未分区Parquet慢得多。

核心逻辑从来不是把时间拆得越细越好，而是单个分区下的总数据量控制在128MB~1GB区间，从根源上避免小文件，同时让分区的过滤粒度匹配你最常用的查询范围。结合你是分钟级时序、主要按区间查时间的场景：

• 如果你的全年数据（单值时序、无额外标签）未压缩总大小在100MB以内：直接按月做单级分区就行，全年也就12个分区，每个分区生成1-2个大Parquet文件。要查单日甚至某几个小时的区间时，直接定位到对应月份的分区，靠Parquet文件内Timestamp列的min/max统计索引做文件内的行组过滤，性能比拆到小时级好太多——毕竟一个月的大文件总共才几MB，读完全部内容的开销都比遍历24个小时小文件的寻址开销低。
• 如果你的数据规模更大，比如每个分钟点带多个指标标签、全年未压缩总大小在10GB以上：可以调整到按天做单级分区，全年365个分区，每个分区大概几十MB，刚好落在最优大小区间。查跨天的时间范围时，直接定位到对应日期的分区就行，完全不需要拆到小时粒度。
• 不要搞年/月/日/时的四级嵌套目录：哪怕按天分区，也不用拆成YYYY/MM/DD三层，直接用类似dt=2018-01-05的单级分区目录，目录层级更浅，遍历元数据的开销更低。

• 分区后千万别删原始的Timestamp列：如果把时间戳列从数据行里去掉，只靠分区目录的时间值过滤，查小时级区间的时候根本没法在文件内做精准的行组过滤，只能读整个分区的全部数据。
• 保存Parquet的时候开启列级统计信息：保留每个行组内Timestamp列的最小、最大值，查询时直接跳过和时间范围不匹配的行组，不需要读完全部文件内容。
• 开启Spark AQE的小文件合并功能：哪怕选对了分区粒度，也要让引擎自动把同分区下的零散小文件合并成大文件，彻底避免小文件问题。

补充：只有当你单小时分区内的数据量能达到几十MB以上（也就是单小时有几十万行数据），再考虑拆到小时粒度分区，否则一律优先更粗的分区粒度。

内容的提问来源于stack exchange，提问作者charlie_boy