Parquet vs ORC vs ORC与Snappy

Rah*_*hul 79 hadoop hive snappy parquet orc

我正在对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
Run Code Online (Sandbox Code Playgroud)

就我的桌子的压缩而言,实木复合地板是最糟糕的.

我对上表的测试得出以下结果.

行计数操作

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
Run Code Online (Sandbox Code Playgroud)

列操作的总和

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
Run Code Online (Sandbox Code Playgroud)

列操作的平均值

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 
Run Code Online (Sandbox Code Playgroud)

使用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 
Run Code Online (Sandbox Code Playgroud)

这是否意味着ORC比Parquet更快?或者我可以做些什么来使查询响应时间和压缩率更好地工作?

谢谢!

Pha*_*mas 46

我想说,这两种格式都有自己的优势.

如果您拥有高度嵌套的数据,Parquet可能会更好,因为它将其元素存储为像Google Dremel一样的树(参见此处).
如果您的文件结构被展平,Apache ORC可能会更好.

据我所知,实木复合地板还不支持索引.ORC附带一个轻量级索引,从Hive 0.14开始,额外的布隆过滤器可能有助于提高查询响应时间,特别是在总和操作方面.

Parquet默认压缩是SNAPPY.表A - B - C和D是否持有相同的数据集?如果是的话,当它只压缩到1.9 GB时,它看起来有些阴暗

  • 表A - 文本文件格式 - 无压缩.........表B - 带ZLIB压缩的ORC文件格式.........表C - 带Snappy的ORC .......表D - Parquet with Snappy .....我在另一张桌子上工作,大约150列,大小约160 GB,以检查文件格式在那里的表现.Parquet花了35 GB来存储160GB的数据,而ORC和snappy一共花了39GB ......对于Parquet来说压缩效果看起来比问题测试更好但是性能再次出现在相似的线上.. ORC甚至在这里闪耀着光芒比ORC + SNAPPY组合更好的性能. (2认同)

小智 41

你看到这个是因为:

  • Hive有一个矢量化的ORC阅读器,但没有矢量化的镶木地板阅读器.

  • Spark有一个矢量镶木地板阅读器,没有矢量化的ORC阅读器.

  • Spark最适合镶木地板,蜂巢最适合ORC.

我在使用Spark运行ORC和Parquet时看到了类似的差异.

矢量化意味着批量解码行,大大提高了内存局部性和缓存利用率.

(从Hive 2.0和Spark 2.1开始)

  • 从2.3.0开始,spark _does_有一个矢量化的ORC阅读器:https://issues.apache.org/jira/browse/SPARK-16060 (14认同)
  • Hive 2.3.0已经矢量化Parquet阅读器 - https://issues.apache.org/jira/browse/HIVE-14815 (5认同)

jam*_*ndu 11

Parquet 和 ORC 各有优缺点。但我只是尝试遵循一个简单的经验法则 - “您的数据如何嵌套以及有多少列”。如果您关注Google Dremel,您可以找到镶木地板的设计方式。他们使用分层树状结构来存储数据。树的嵌套越深。

但是ORC是为扁平化文件存储而设计的。因此,如果您的数据以较少的列扁平化,您可以使用 ORC,否则,镶木地板对您来说很好。在 ORC 中,扁平化数据的压缩效果非常好。

我们使用更大的扁平文件进行了一些基准测试,将其转换为 spark Dataframe 并将其以 parquet 和 ORC 格式存储在S3 中,并使用 **Redshift-Spectrum ** 进行查询。

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.
Run Code Online (Sandbox Code Playgroud)

很快我们将对嵌套数据进行一些基准测试并在此处更新结果。


Owe*_*ley 6

我们做了一些基准测试,比较了不同用例中的不同文件格式(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

  • 这非常有用,但应该有一个免责声明@Owen适用于最初开发ORC文件格式的Horton Works (4认同)