https://www.vldb.org/pvldb/vol17/p148-zeng.pdf 最近在列存引擎上做了一点工作，于是顺便读了VLDB '23上非常火的评测列存格式的论文，补一下读后感。首先对于不熟悉 Apache Parquet 和 ORC 列存格式的读者（例如我），该论文的第一部分有一个简明扼要的概述和对比，十分推荐。
在实际的评估部分，TL;DR Parquet 在多项指标上都比 ORC 强：如图1所示，不论四项数据特性如何变化，Parquet 的文件几乎总是更小，在扫描和点查时间上也有类似的结论。文章分析这些差异并得到了八条 Lesson（图2），其中我认为比较显著和有趣的就是前两条了，第一，大家（包括 ORC）总是直觉的认为浮点数由于其稠密性字典编码效果应该不好，但实时并非如此，这导致图1中浮点数所有情况下ORC编码质量都比 Parquet 显著低，对所有数据结构都应用字典编码的 Parquet 恰恰歪打正着；第二，对现代硬件来说，简单的编码更重要，ORC 使用一个启发式贪心算法依据数据性质在多个编码方法间反复横跳却在文件大小和性能上双输（见图1第一行）就是一个反例；最后，块级的压缩作用不大（图3），Andy 在课上曾说压缩不仅可以节约大小还能提升吞吐量，实践中这可能并不明显。
这篇文章的方法非常健壮。各个方面分析使用的严格的控制变量法很难挑出毛病，对真实世界负载做的统计分析和解读也十分精彩。不过，cuDF（GPU）的实现被高度优化的CPU实现轻松碾压（图4），足以见得写进摘要里的GPU计算看起来却仍不成熟，这方面的分析恐怕很快就会过时。最后，这篇文章还带来一个研究方向的提示：对老模型做细致、健壮的概述和分析的文章，认可度仍然不低。 #selected
在实际的评估部分，TL;DR Parquet 在多项指标上都比 ORC 强：如图1所示，不论四项数据特性如何变化，Parquet 的文件几乎总是更小，在扫描和点查时间上也有类似的结论。文章分析这些差异并得到了八条 Lesson（图2），其中我认为比较显著和有趣的就是前两条了，第一，大家（包括 ORC）总是直觉的认为浮点数由于其稠密性字典编码效果应该不好，但实时并非如此，这导致图1中浮点数所有情况下ORC编码质量都比 Parquet 显著低，对所有数据结构都应用字典编码的 Parquet 恰恰歪打正着；第二，对现代硬件来说，简单的编码更重要，ORC 使用一个启发式贪心算法依据数据性质在多个编码方法间反复横跳却在文件大小和性能上双输（见图1第一行）就是一个反例；最后，块级的压缩作用不大（图3），Andy 在课上曾说压缩不仅可以节约大小还能提升吞吐量，实践中这可能并不明显。
这篇文章的方法非常健壮。各个方面分析使用的严格的控制变量法很难挑出毛病，对真实世界负载做的统计分析和解读也十分精彩。不过，cuDF（GPU）的实现被高度优化的CPU实现轻松碾压（图4），足以见得写进摘要里的GPU计算看起来却仍不成熟，这方面的分析恐怕很快就会过时。最后，这篇文章还带来一个研究方向的提示：对老模型做细致、健壮的概述和分析的文章，认可度仍然不低。 #selected