orc格式和parquet格式对比

点击有惊喜

相比传统的方式存储引擎,列式存储引擎具有更高的压缩比,更少的IO操作而备受青睐,尤其是在数据列column数很多,单词操作仅针对若干列的情景,列式存储引擎的性价比更高.
在互联网数据应用场景下,大部分情况下,数据很大且数据字段很多,但每次查询数据只针对其中的少数几行,这时候列式存储是极佳的选择,目前在开源实现中,最有名的列式存储引擎parquet 和orc ,在最近一年内,他们都晋升apache顶级项目 可见它的重要性,本文尝试比较这两种存储引擎.

Apache Parquet
源自google Dremel 系统,Parquet 相当一Dremel中的数据存储引擎,而Apache顶级开源醒目 Drill正式Dremel的开源实现.
Apache Parquet 最初的设计动机是存储嵌套式数据,比如Protocolbuffer thrift json 等 将这类数据存储成列式格式以方便对其高效压缩和编码,且使用更少的IO操作取出需要的数据,也是Parquet 相比于ORC的优势,它能透明的将protobuf 和thrift被广泛的使用的今天,于parquet 进行集成,是一件非常容易和自然地事情,除了上述优势外,相比于ORC,Parquet 没有太多其他可圈可点的地方,比如他不支持uodate操作(数据写成后不可修改),不支持ACID等.

Apache ORC
ORC(optimizedRC File) 存储源自RC(RecordCloimnar File)这种存储格式,RC是一种列式存储引擎,对schema演化(修改schema需要重新生成数据)支持较差,主要是在压缩编码,查询性能方面做了优化.RC/ORC最初是在Hive中得到使用,最后发展势头不错,独立成一个单独的项目.Hive1.xbanbendu版本对事物和update操作的支持,便是给予ORC实现的(其他存储格式暂不支持).
OCR发展到今天,已经具备一些非常高级的feature,比如支持update操作,支持ACID,支持struct,array复杂类型.你可以使用复杂类型构建一个类似parquet的嵌套式数据架构,但层数非常多时,写起来非常麻烦和复杂,而parquet提供的schema表达方式更容易表示出多级嵌套的数据类型.

Parquet 与 ORC对比

点击有惊喜