Parquet地板vs兽人vs兽人带snappy

esbemjvw  于 2021-06-03  发布在  Hadoop
关注(0)|答案(5)|浏览(389)

我正在对hive可用的存储格式进行一些测试,并将parquet和orc作为主要选项。我包括了orc一次默认压缩和一次snappy。
我读过很多文件,说Parquet地板在时间/空间复杂度上比兽人更好,但我的测试结果和我读过的文件相反。
下面是我的数据的一些细节。

Table A- Text File Format- 2.5GB

Table B - ORC - 652MB

Table C - ORC with Snappy - 802MB

Table D - Parquet - 1.9 GB

就我桌上的压力而言,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

这是否意味着兽人比Parquet更快?或者我可以做些什么来提高查询响应时间和压缩比?
谢谢!

btxsgosb

btxsgosb1#

你看到这个是因为:
Hive有一个矢量化的orc读卡器,但没有矢量化的Parquet读卡器。
spark有一个矢量化的Parquet读取器,没有矢量化的orc读取器。
Spark与Parquet地板的表现最好,Hive与兽人的表现最好。
我见过类似的差异运行兽人和Parquet与Spark。
矢量化意味着成批对行进行解码,极大地提高了内存局部性和缓存利用率。
(从hive 2.0和spark 2.1起更正)

iklwldmw

iklwldmw2#

两者各有优势。我们在工作中与hive和impala一起使用parquet,但只想指出orc比parquet的一些优点:在长时间执行查询期间,当hive查询orc表时,gc的调用频率降低了大约10倍。对许多项目来说可能不算什么,但对其他项目来说可能至关重要。
当您只需要从表中选择几列时,orc所花费的时间也少得多。其他一些查询,尤其是使用连接的查询,由于执行矢量化的查询(这对parquet不可用),所需的时间也较少
此外,兽人压缩有时是有点随机,而Parquet地板压缩是更加一致的。当orc表有许多数字列时,它就不会压缩了。它同时影响zlib和snappy压缩

rfbsl7qr

rfbsl7qr3#

Parquet地板和兽人都有各自的优点和缺点。但我只是试着遵循一个简单的经验法则——“数据的嵌套程度和列数”。如果你遵循谷歌dremel你可以找到Parquet地板是如何设计的。它们使用一个层次树结构来存储数据。巢越深树越深。
但orc是为扁平的文件存储而设计的。所以,如果你的数据是用更少的列压平的,你可以用兽人,否则,Parquet对你来说是好的。在orc中,对扁平化数据的压缩效果惊人。
我们用一个更大的扁平文件做了一些基准测试,把它转换成sparkDataframe,以parquet和orc格式存储在s3中,并用红移频谱进行查询。

Size of the file in parquet: ~7.5 GB and took 7 minutes to write
Size of the file in ORC: ~7.1. GB and took 6 minutes to write
Query seems faster in ORC files.

不久我们将对嵌套数据进行一些基准测试,并在这里更新结果。

e0bqpujr

e0bqpujr4#

我们做了一些基准测试,比较了不同用例中的不同文件格式(avro、json、orc和parquet)。
https://www.slideshare.net/oom65/file-format-benchmarks-avro-json-orc-parquet
所有数据都是公开的,基准代码都是开源的:
https://github.com/apache/orc/tree/branch-1.4/java/bench

qgelzfjb

qgelzfjb5#

我想说,这两种格式都有各自的优点。
如果您有高度嵌套的数据,parquet可能会更好,因为它像googledremel那样以树的形式存储其元素(参见这里)。
如果文件结构扁平化,apacheorc可能会更好。
据我所知,Parquet还不支持索引。orc提供了一个轻量级索引,并且由于Hive0.14提供了一个额外的bloom过滤器,这可能有助于提高查询响应时间,特别是在求和操作方面。
Parquet地板的默认压缩是snappy。表a-b-c和表d是否包含相同的数据集?如果是的话,当它只压缩到1.9gb时,它看起来有点可疑

相关问题