SQL-on-Hadoop结构化大数据分析系统性能评测

陈跃国 中国人民大学

数据工程与知识工程教育部重点实验室

战国时代，新的大数据系统不断涌现…

百家争鸣，孰优孰劣？

基准的意义

• 如今大数据市场形如80年代的的数据库市场– 新的系统和产品迅速涌现，尚未形成垄断• 传统数据库成功非常受益于基准的制定和推广

– TPC: Transaction Processing Performance Council

• 目前缺少大数据系统之间比较的基准– 基准制定困难：数据类型多、应用类型多、系统复杂、负载动态等

基准测试

• 大数据基准正在建设，尚需完善– BigBench，Berkeley Big Data Benchmark等–研究和产业化不能坐等公认的基准形成

• 当前交互式大数据分析系统（SQL-on-Hadoop）非常火热–在Hadoop构架基础上深度借鉴MPP数据库技术–性能远超Hive，各说各的好，缺少公正比较

• TPC-DS可以做到100TB–可以用来比较SQL-on-Hadoop系统

5

近期的测试工作

• 利用人大行云平台– 50台物理机，虚拟出100个节点–单节点4核，20GB内存，1TB本地磁盘存储–普通千兆网

• 使用TPC-DS生成关系型数据– 300GB、1TB、3TB

• 测试开源大数据分析系统(SQL-on-Hadoop)– Hive, Stinger, Shark– Impala, Presto

6

评测系统

• Apache Hive (0.10)– 几个被比较系统的基础，将HQL转换成MR任务

• Hortonworks Stinger (Hive 0.11)– 对Hive的升级，查询优化、Hadoop性能提升、ORCFile

• Berkeley Shark (0.7.0)– 数据尽可能使用内存列存储– 中间结果避免写到磁盘，并具备容错机制

• Cloudera Impala (1.0.1)– 脱离MR，初级MPP分析数据库引擎，并行查询处理– Parquet列存储的使用，嵌套数据和缓存的使用

• Facebook Presto (0.54)– 脱离MR，in-memory和pipeline处理– RCFile，热数据缓存，类似Impala

查询集…

• 单表查询: --qA5o--select ss_store_sk as store_sk, ss_sold_date_sk as date_sk

ss_ext_sales_price as sales_price, ss_net_profit as profit from store_sales where ss_ext_sales_price>20 order by profitlimit 100;

--qA9--select count(*) from store_sales where ss_quantity between 1 and 20 limit 100;

查询集..

• Ad hoc查询: --qB65g—(两表连接)

select ss_store_sk, ss_item_sk, sum(ss_sales_price) as revenue

from store_sales join date_dim on(store_sales.ss_sold_date_sk =date_dim.d_date_sk) where d_month_seq between 1176 and 1176+11 group by ss_store_sk, ss_item_sk limit 100;

查询集.

• 星形查询: --qD27go--(5表连接)select i_item_id, s_state, avg(ss_quantity) agg1, avg(ss_list_price) agg2, avg(ss_coupon_amt) agg3, avg(ss_sales_price) agg4 from store_sales ss

join customer_demographics cd on(ss.ss_cdemo_sk = cd.cd_demo_sk) join date_dim dd on(ss.ss_sold_date_sk = dd.d_date_sk) join store s on(ss.ss_store_sk = s.s_store_sk) join item i on(ss.ss_item_sk = i.i_item_sk)

where cd_gender = 'M' and cd_marital_status = 'S' and cd_education_status = 'College' and d_year = 2002 and s_state='TN' group by i_item_id, s_state order by i_item_id ,s_state limit 100 ;

查询集

• 复杂查询: --qD6gho—(5表连接)select a.ca_state state, count(*) cnt

from customer_address ajoin customer c on(a.customer_address.ca_address_sk =

c.c_current_addr_sk)join store_sales s on(c.c_customer_sk = s.ss_customer_sk)join date_dim d on(s.ss_sold_date_sk = d.d_date_sk)join item i on(s.ss_item_sk = i.i_item_sk)

group by a.ca_statehaving count(*) >= 10order by cnt limit 100;

结果集大小

• 查询无limit限制、无聚集操作时

查询 300GB 1TB 3TB

qA5 796M 2655M 7964M

qA5o 796M 2655M 7964M

qA9 165M 550M 1650M

qB10o 16M 54M 162M

qB32 13M 41M 125M

qB65g 163M 544M 1632M

qD27go 0.17M 0.38M 1.37M

qD6gho 806M 2685M 8056M

100个节点，数据量变化

错误

错误

错误

错误

错误

错误

错误错误错误错误错误

1TB数据，节点数变化

错误

错误

错误

错误

错误

错误

被测系统分析

测试结论

• 列存储一般对查询性能提升明显，尤其大表是一个包含很多列的表– 从Stinger (Hive 0.11 with ORCFile) VS Hive，以及Impala的

Parquet VS Textfile

• 绕开MR计算模型，省去中间结果的持久化和MR任务调度的延迟，会带来性能提升– Impala，Shark，Presto要好于Hive和Stinger– 但这种优势随着数据量增加和查询变复杂而减弱

• 使用MPP数据库技术对连接查询有帮助– Impala在两表、多表连接查询中优势明显

测试结论

• 充分利用缓存的系统在内存充足的情况下性能优势明显– Shark、Impala在小数据量时性能优势明显–内存不足时性能下降严重，Shark出现很多问题

• 数据倾斜会严重影响一些系统的性能– Hive、Stinger、Shark对数据倾斜比较敏感，容易造成倾斜

– Impala受这方面的影响似乎不大

大数据实时分析的基准

• 很多大数据应用不断累积数据– 存在典型的OLTP+OLAP应用– 需要基准能够从以下方面度量系统的性能

• 分析系统查询处理性能– 具备交互性的复杂分析– 实时分析

• 数据更新的实时性和吞吐量– 数据产生到影响查询结果的延时– 系统处理更新的吞吐量

• 系统的可扩展性– 随着规模的变化，系统性能指标表现出的变化趋势

张慧杰

卞昊穹

刘德海

陈峻

高彦杰 何龙董兆安

杜小勇教授 覃雄派博士

30

谢谢大家！