hadoop - Parquet vs ORC vs ORC with Snappy

Question

我正在对 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 更快？或者我可以做些什么来让它更好地处理查询响应时间和压缩率？

谢谢!

Answer 1

我想说，这两种格式各有优势。

如果您有高度嵌套的数据，Parquet 可能会更好，因为它像 Google Dremel 那样将其元素存储为树 ( See here )。
如果您的文件结构扁平化，Apache ORC 可能会更好。

据我所知，parquet 还不支持索引。 ORC 带有一个轻量级索引，并且自 Hive 0.14 起，一个额外的 Bloom Filter 可能有助于缩短查询响应时间，尤其是在求和操作方面。

Parquet 默认压缩是 SNAPPY。表 A - B - C 和 D 是否持有相同的数据集？如果是，当它只压缩到 1.9 GB 时，它看起来有些不对劲