我正在对 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 起,一个额外的 Bloom Filter 可能有助于缩短查询响应时间,尤其是在求和操作方面。
Parquet 默认压缩是 SNAPPY。表 A - B - C 和 D 是否持有相同的数据集?如果是,当它只压缩到 1.9 GB 时,它看起来有些不对劲
关于hadoop - Parquet vs ORC vs ORC with Snappy,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/32373460/