This website requires JavaScript.

ORC与Parquet存储格式对比[译]

CSV是最通用的数据存储格式。在本文中我会对ORC及Parquet格式就性能方面进行对比。有很多文章对这两种格式有介绍,所以本文不会介绍。

Parquet一样,ORC也是列存储格式,Parquet由Cloudera推广,而ORC则被Hortonworks推广,这里有两片文章(1,2)对Parquet和ORC做了对比。

CSV数据可以使用Hive转换为ORC和Parquet格式。这里涉及一些步骤,相同的步骤也适用于ORC。简单地说,用ORC替换Parquet。 在后台,将运行一个MapReduce作业,它将CSV转换为适当的格式。

  • 创建Hive表(ontime)
  • 将CSV数据导入到ontime表
  • 创建Hive表ontime_parquet并指定为Parquet格式
  • 将ontime表中的数据移动到ontime_parquet表

在上一篇博客中,我们已经看到了如何使用Hive将CSV转换为Parquet。 要转为ORC,只需在表定义中将 STORED AS PARQUET改为STORED AS ORC,如下所示,并指定要使用的压缩格式。

create external table ontime_orc_snappy (
    Year INT,
    Month INT,
    DayofMonth INT,
    DayOfWeek INT,
    DepTime INT,
    CRSDepTime INT,
    ArrTime INT,
    CRSArrTime INT,
    UniqueCarrier STRING,
    FlightNum INT,
    TailNum STRING,
    ActualElapsedTime INT,
    CRSElapsedTime INT,
    AirTime INT,
    ArrDelay INT,
    DepDelay INT,
    Origin STRING,
    Dest STRING,
    Distance INT,
    TaxiIn INT,
    TaxiOut INT,
    Cancelled INT,
    CancellationCode STRING,
    Diverted STRING,
    CarrierDelay INT,
    WeatherDelay INT,
    NASDelay INT,
    SecurityDelay INT,
    LateAircraftDelay INT
) STORED AS PARQUET LOCATION '/user/bigdata/airline/input-orc-snappy-from-hive' TBLPROPERTIES ("orc.compress"="SNAPPY");

然后,使用以下命令将数据从Hive表(ontime)移动到ontime_orc_snappy

INSERT OVERWRITE TABLE ontime_parquet_gzip SELECT * FROM ontime;

下表中提及了Parquet和ORC的默认压缩属性, 当不使用默认压缩格式时,在TBLPROPERTIES中单独设置,如上面的表创建命令所示。 注意,ORC里面的ZLIB,Parquet里面的GZIP其实是一样的,只是名字不同。

configuration-properties

对于orc/parquet和snappy/zlib/gzip压缩的组合,需要在Hive中创建四个表,如下所示。

hive-beeline-different-tables

现在已经创建了表,把ontime的数据移动到这四个表。 HDFS中创建的文件夹如下所示。

hdfs-different-formats

这四格表我都运行两个查询。 第一个是聚合查询,以查找每个Origin延迟的航班数,如下所示。

select Origin, count(*) from ontime_parquet_gzip where DepTime > CRSDepTime group by Origin;

第二个查询是获取单个行中的所有列,如下所示。

select * from ontime_parquet_gzip where origin = 'LNY' and AirTime = 16;

以下是比较结果的矩阵

comparison-matrix

下面是我想强调的几点

  • 在使用相同的压缩格式(如“SNAPPY VS SNAPPY”和“ZLIB vs GZIP”)时,ORC和Parquet对存储空间的占用几乎没什么区别。
  • 从CSV转换为ORC和Parquet格式的时间非常接近,没有太大差别。
  • Hortonworks的博客说,与Parquet相比,ORC格式提供了更好的压缩率。这里有误导,因为ORC默认使用的是ZLIB,Parquet使用的是SNAPPY。 如果都使用相同的压缩格式,如上述矩阵所示,压缩比没有太大的差别。 所以最好关注与一些特性吧。
  • 对于聚合查询,如延迟航班的时间,没有巨大差异。 与CSV格式相比,ORC和Parquet格式的表现都非常好。
  • 在使用“where origin ='LNY'和AirTime = 16”这样的条件获取单个行的所有列时,ORC比Parquet具有优势,因为ORC格式在每个文件上都有轻索引。 通过使用ORC中的索引,底层的MapRedeuce或Spark可以避免读取整个块。
  • Parquet中的索引似乎是一个很好的differentiator。 尽管ORC在创建文件时必须创建Index,但是对于转换和这两种格式的文件大小没有显着差异。
  • 不同的大数据供应商试图推广自己的格式,而不关心互操作性。 Cloudera认证有关于Parquet的主题,而Hortonworks认证有关于ORC的主题。

这篇博客比我预想的要长,所以各位晚点再见,Bye~

原文:Comparing ORC vs Parquet Data Storage Formats using Hive

0条评论
avatar