我正在对 Hive 可用的存储格式进行一些测试，并使用 Parquet 和 ORC 作为主要选项。我包括一次默认压缩的 ORC 和一次 Snappy。
我已经阅读了许多文档，这些文档表明 Parquet 在时间/空间复杂度方面比 ORC 更好，但我的测试与我所经历的文档相反。
遵循我的数据的一些细节。
Table A- Text File Format- 2.5GB
Table B - ORC - 652MB
Table C - ORC with Snappy - 802MB
Table D - Parquet - 1.9 GB
就我的 table 的压缩而言，Parquet 是最糟糕的。
我对上表的测试产生了以下结果。
行计数操作
Text Format Cumulative CPU - 123.33 sec
Parquet Format Cumulative CPU - 204.92 sec
ORC Format Cumulative CPU - 119.99 sec
ORC with SNAPPY Cumulative CPU - 107.05 sec
列操作的总和
Text Format Cumulative CPU - 127.85 sec
Parquet Format Cumulative CPU - 255.2 sec
ORC Format Cumulative CPU - 120.48 sec
ORC with SNAPPY Cumulative CPU - 98.27 sec
列操作的平均值
Text Format Cumulative CPU - 128.79 sec
Parquet Format Cumulative CPU - 211.73 sec
ORC Format Cumulative CPU - 165.5 sec
ORC with SNAPPY Cumulative CPU - 135.45 sec
使用 where 子句从给定范围中选择 4 列
Text Format Cumulative CPU - 72.48 sec
Parquet Format Cumulative CPU - 136.4 sec
ORC Format Cumulative CPU - 96.63 sec
ORC with SNAPPY Cumulative CPU - 82.05 sec
这是否意味着 ORC 比 Parquet 快？或者我可以做些什么来使其在查询响应时间和压缩率方面更好地工作？
谢谢!
最佳答案
我想说，这两种格式都有自己的优势。
如果您有高度嵌套的数据，Parquet 可能会更好，因为它将其元素存储为一棵树，例如 Google Dremel ( See here )。
如果您的文件结构扁平化，Apache ORC 可能会更好。
据我所知，parquet 还不支持索引。 ORC 带有一个轻量级的索引，并且自 Hive 0.14 起有一个额外的布隆过滤器，这可能有助于更好的查询响应时间，尤其是在求和运算方面。
Parquet 默认压缩是 SNAPPY。表 A - B - C 和 D 是否持有相同的数据集？如果是的话，当它只压缩到 1.9 GB 时，它看起来有些阴暗
关于hadoop - Parquet vs ORC vs ORC with Snappy，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/32373460/