欢迎关注大数据技术架构与案例微信公众号:过往记忆大数据
过往记忆博客公众号iteblog_hadoop
欢迎关注微信公众号:
过往记忆大数据

Apache CarbonData性能基准报告:查询性能秒杀Parquet

本文相关测试数据由华为陈亮大神提供,特别感谢。

  Apache CarbonData是由华为开发、开源并支持Apache Hadoop的列式存储文件格式,支持索引、压缩以及解编码等,其目的是为了实现同一份数据达到多种需求,而且能够实现更快的交互查询,目前该项目正处于Apache孵化过程中。详细介绍可以参见(《CarbonData:华为开发并支持Hadoop的列式文件格式》文章介绍了)。

下载CarbonData源码 阅读CarbonData的Wiki

  本文将介绍Apache CarbonData的性能基准测试及其结果,此测试结果是基于Apache CarbonData 0.1.0版本,并且和Apache Parquet进行对比,主要包括以下三方面:
  1、数据加载性能;
  2、数据压缩率;
  3、数据查询和扫描性能。

测试环境

1、硬件配置

机器:Huawei Server RH2288
CPU:Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz (2 CPUs, 6 cores per one,logic cores 48)
内存:387G
磁盘:12 disks(SATA 3600G/7200RPM)

2、软件配置

OS: SUSE Linux 11 SP3 64 Bit
JDK:Oracle JDK 1.8.0
Hadoop版本:hadoop 2.7.2
Spark:Spark 1.6.2

3、部署架构

测试场景和结果

1、基准测试设置

1)配置

节点个数: 3
集群管理:YARN in HA
为Carbon/Parquet配置的资源: --num-executors 3 --executor-cores 32 --executor-memory 250G --driver-memory 20G
HDFS Node Size: 3
HDFS块副本因子: 3
NO_DICTIONARY column:PROD_UNQ_MDL_ID,CUST_NICK_NAME,CUST_LOGIN,CUST_EMAIL_ADDR,PROD_UNQ_DEVICE_ADDR,PROD_UQ_UUID,PROD_BAR_CODE,TRACKING_NO,STR_ORDER_NO

ThriftServer参数: bin/spark-submit --conf spark.sql.hive.thriftServer.singleSession=true --class org.carbondata.spark.thriftserver.CarbonThriftServer --num-executors 3 --driver-memory 20g --executor-memory 250g --executor-cores 32 /srv/OSCON/BigData/HACluster/install/spark/sparkJdbc/lib/carbondata_2.10-0.1.0-incubating-SNAPSHOT-shade-hadoop2.7.2.jar hdfs://hacluster/user/hive/warehouse/carbon.store

2)表模式

本文测试使用到的表一共有300多列,详情请参考下面附件

下面是详细的测试结果

2、数据加载性能测试

  数据加载时使用到9.8亿行数据,原始数据大小有1.95TB,我们分别把这些数据加载到Apache CarbonData和Apache Parquet中,结果是:

  Apache CarbonData使用了6.14小时;而Apache Parquet使用了5.3小时。可以看到在数据加载方面CarbonData稍微比Parquet要慢,之所以是这样是因为CarbonData需要建立索引和字典编码,这将对后面的数据搜索大有帮助,可以在后面测试看到。

3、数据压缩率

  我们把1.9T的数据分别加载到Apache CarbonData和Apache Parquet中,压缩之后大小分别为461GB和432.5,两者压缩率相差不大。

4、查询速度测试

下面的测试SQL是基于以下场景的。

1、SQL 1~3主要是全量数据进行扫描的聚合操作,结果如下:

序号SQLResultset (rows)CarbonData (s)Parquet (s)
1
select CUST_COUNTRY,CUST_CITY, count(distinct CUST_ID) from oscon_carbon where CUST_INCOME >50000 and TOTAL_TX_AMT < 1500 
group by CUST_COUNTRY,CUST_CITY;
236917.2739.01
2
select CUST_COUNTRY, SUM(STR_ORD_QTY) from oscon_carbon group by CUST_COUNTRY;
5617.1024.88
3
select CUST_CITY, AVG(WAITING_PERIOD) from oscon_carbon group by CUST_CITY;
23609.1948.42

CarbonData通过使用全局字典编码来加快计算速度,其使得处理/查询引擎可以直接在编码好的数据上进行处理而不需要转换数据。数据只有在返回结果给用户的时候才转换成用户可读的形式。
2、SQL 4~5主要进行OLAP的聚合操作,结果如下:

序号SQLResultset (rows)CarbonData (s)Parquet (s)
4
select CUST_SEX,PROD_COLOR, count(distinct CUST_ID) from  oscon_carbon 
where CUST_JOB_TITLE ="Public Relations Associate" and CUST_COUNTRY ="India" and PRODUCT_NAME = "Huawei P9" 
group by CUST_SEX, PROD_COLOR;
53.1425.44
5
select PROD_COLOR, SUM(STR_ORD_QTY) from  oscon_carbon 
where CUST_COUNTRY ='India' and CUST_CITY = 'Bengaluru' and PRODUCT_NAME = 'Xiaomi Mi Note Pro'
group by PROD_COLOR;
50.3819.41

CarbonData查询性能之所以好是因为其使用了
(1)、MDK, Min-Max and Inverted indices可以只查询需要的块;
(2)、延迟解码使得聚合操作更快。

3、SQL 6~7测试随机查询,结果如下:

序号SQLResultset (rows)CarbonData (s)Parquet (s)
6
SELECT *  from oscon_carbon 
where CUST_PRFRD_FLG="N" and PROD_BRAND_NAME = "LG" and PROD_COLOR = "GOLD" 
and CUST_LAST_RVW_DATE = "2015-12-01 00:00:00" and CUST_COUNTRY = "United Kingdom" 
and product_name = "LG C199 phone" ;
1153.41459.02
7
SELECT CUST_NICK_NAME,CUST_FIRST_NAME,CUST_LAST_NAME,
CUST_PRFRD_FLG,CUST_BIRTH_DY,CUST_BIRTH_MM,CUST_BIRTH_YR,
CUST_BIRTH_COUNTRY,CUST_LOGIN,CUST_EMAIL_ADDR,CUST_LAST_RVW_DATE,
CUST_SEX,CUST_ADDRESS_ID,CUST_STREET_NO,CUST_STREET_NAME,CUST_AGE,
CUST_SUITE_NO,CUST_ZIP,CUST_COUNTY,CUST_DEP_COUNT,CUST_VEHICLE_COUNT,
CUST_ADDRESS_CNT,CUST_CRNT_CDEMO_CNT,CUST_CRNT_HDEMO_CNT,
CUST_CRNT_ADDR_DM,CUST_FIRST_SHIPTO_CNT,CUST_FIRST_SALES_CNT,
CUST_GMT_OFFSET,CUST_DEMO_CNT,CUST_INCOME,PRODUCT_ID,
PROD_UNQ_DEVICE_ADDR,PROD_UQ_UUID,PROD_SHELL_COLOR,
DEVICE_NAME,PROD_SHORT_DESC,PROD_LONG_DESC,PROD_THUMB,
PROD_IMAGE  from oscon_carbon where CUST_PRFRD_FLG="N" 
and PROD_BRAND_NAME = "LG" and PROD_COLOR = "GOLD" 
and CUST_LAST_RVW_DATE = "2015-12-01 00:00:00" 
and CUST_COUNTRY = "United Kingdom" and product_name = "LG C199 phone" ;
1150.7861.89

CarbonData查询性能之所以好是因为以下原因:
(1)、倒排索引可以更快地重建行数据;
(2)、列组(Column group)技术消除了行数据重建时的隐式join操作。

4、SQL 8~9 也是测试随机查询,主要测试high cardinality column的过滤操作,结果如下:

序号SQLResultset (rows)CarbonData (s)Parquet (s)
8
select * from  oscon_carbon 
where CUST_ID = "Cust00333333" and CUST_CITY="Tirupathur" 
and CUST_LAST_RVW_DATE between "2015-12-03 00:00:00" and "2015-12-06 00:00:00";
463.46453.83
9
select CUST_NICK_NAME,CUST_FIRST_NAME,CUST_LAST_NAME,CUST_PRFRD_FLG,CUST_BIRTH_DY,
CUST_BIRTH_MM,CUST_BIRTH_YR,CUST_BIRTH_COUNTRY,CUST_LOGIN,CUST_EMAIL_ADDR,
CUST_LAST_RVW_DATE,CUST_SEX,CUST_ADDRESS_ID,CUST_STREET_NO,CUST_STREET_NAME,
CUST_AGE,CUST_SUITE_NO,CUST_ZIP,CUST_COUNTY,CUST_DEP_COUNT,CUST_VEHICLE_COUNT,
CUST_ADDRESS_CNT,CUST_CRNT_CDEMO_CNT,CUST_CRNT_HDEMO_CNT,
CUST_CRNT_ADDR_DM,CUST_FIRST_SHIPTO_CNT,CUST_FIRST_SALES_CNT,CUST_GMT_OFFSET,
CUST_DEMO_CNT,CUST_INCOME,PRODUCT_ID,PROD_UNQ_DEVICE_ADDR,PROD_UQ_UUID,
PROD_SHELL_COLOR,DEVICE_NAME,PROD_SHORT_DESC,PROD_LONG_DESC,PROD_THUMB,
PROD_IMAGE  from oscon_carbon where  CUST_ID = "Cust00881055" ;
9660.7952.10

CarbonData查询性能之所以好是因为以下原因:
(1)、倒排索引可以更快地重建行数据;
(2)、列组(Column group)技术消除了行数据重建时的隐式join操作。

总结

CarbonData在数据加载和数据压缩率表现稍微比Parquet要差,但是其读性能表现比Parquet好很多,在那种写一次读多次的场景下非常适合使用;而且目前CarbonData版本已经有稳定版本可以下载,相信会有越来越多的项目会使用到。

表模式数据下载

点击进入下载

本博客文章除特别声明,全部都是原创!
原创文章版权归过往记忆大数据(过往记忆)所有,未经许可不得转载。
本文链接: 【Apache CarbonData性能基准报告:查询性能秒杀Parquet】(https://www.iteblog.com/archives/1806.html)
喜欢 (7)
分享 (0)
发表我的评论
取消评论

表情
本博客评论系统带有自动识别垃圾评论功能,请写一些有意义的评论,谢谢!
(1)个小伙伴在吐槽
  1. 您好,文章中提到测试数据有9.8亿条,但是发现提供下载的表的统计信息中cust_id 仅为100万,是否是提供下载的仅为部分测试数据的统计信息?

    ╱★经过2017-05-05 15:45 回复