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

SQL-on-Hadoop结构化大数据分析系统性能评测陈跃国中国人民大学数据工程与知识工程教育部重点实验室战国时代，新的大数据系统不断涌现…百家争鸣，孰优孰劣？基准的意义•如今大数据市场形如80年代的的数据库市场–新的系统和产品迅速涌现，尚未形成垄断•传统数据库成功非常受益于基准的制定和推广–TPC:TransactionProcessingPerformanceCouncil•目前缺少大数据系统之间比较的基准–基准制定困难：数据类型多、应用类型多、系统复杂、负载动态等基准测试•大数据基准正在建设，尚需完善–BigBench，BerkeleyBigDataBenchmark等–研究和产业化不能坐等公认的基准形成•当前交互式大数据分析系统（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,Presto6评测系统•ApacheHive(0.10)–几个被比较系统的基础，将HQL转换成MR任务•HortonworksStinger(Hive0.11)–对Hive的升级，查询优化、Hadoop性能提升、ORCFile•BerkeleyShark(0.7.0)–数据尽可能使用内存列存储–中间结果避免写到磁盘，并具备容错机制•ClouderaImpala(1.0.1)–脱离MR，初级MPP分析数据库引擎，并行查询处理–Parquet列存储的使用，嵌套数据和缓存的使用•FacebookPresto(0.54)–脱离MR，in-memory和pipeline处理–RCFile，热数据缓存，类似Impala查询集…•单表查询:--qA5o--selectss_store_skasstore_sk,ss_sold_date_skasdate_skss_ext_sales_priceassales_price,ss_net_profitasprofitfromstore_saleswheress_ext_sales_price20orderbyprofitlimit100;--qA9--selectcount(*)fromstore_saleswheress_quantitybetween1and20limit100;查询集..•Adhoc查询:--qB65g—(两表连接)selectss_store_sk,ss_item_sk,sum(ss_sales_price)asrevenuefromstore_salesjoindate_dimon(store_sales.ss_sold_date_sk=date_dim.d_date_sk)whered_month_seqbetween1176and1176+11groupbyss_store_sk,ss_item_sklimit100;查询集.•星形查询:--qD27go--(5表连接)selecti_item_id,s_state,avg(ss_quantity)agg1,avg(ss_list_price)agg2,avg(ss_coupon_amt)agg3,avg(ss_sales_price)agg4fromstore_salesssjoincustomer_demographicscdon(ss.ss_cdemo_sk=cd.cd_demo_sk)joindate_dimddon(ss.ss_sold_date_sk=dd.d_date_sk)joinstoreson(ss.ss_store_sk=s.s_store_sk)joinitemion(ss.ss_item_sk=i.i_item_sk)wherecd_gender='M'andcd_marital_status='S'andcd_education_status='College'andd_year=2002ands_state='TN'groupbyi_item_id,s_stateorderbyi_item_id,s_statelimit100;查询集•复杂查询:--qD6gho—(5表连接)selecta.ca_statestate,count(*)cntfromcustomer_addressajoincustomercon(a.customer_address.ca_address_sk=c.c_current_addr_sk)joinstore_salesson(c.c_customer_sk=s.ss_customer_sk)joindate_dimdon(s.ss_sold_date_sk=d.d_date_sk)joinitemion(s.ss_item_sk=i.i_item_sk)groupbya.ca_statehavingcount(*)=10orderbycntlimit100;结果集大小•查询无limit限制、无聚集操作时查询300GB1TB3TBqA5796M2655M7964MqA5o796M2655M7964MqA9165M550M1650MqB10o16M54M162MqB3213M41M125MqB65g163M544M1632MqD27go0.17M0.38M1.37MqD6gho806M2685M8056M100个节点，数据量变化错误错误错误错误错误错误错误错误错误错误错误1TB数据，节点数变化错误错误错误错误错误错误被测系统分析测试结论•列存储一般对查询性能提升明显，尤其大表是一个包含很多列的表–从Stinger(Hive0.11withORCFile)VSHive，以及Impala的ParquetVSTextfile•绕开MR计算模型，省去中间结果的持久化和MR任务调度的延迟，会带来性能提升–Impala，Shark，Presto要好于Hive和Stinger–但这种优势随着数据量增加和查询变复杂而减弱•使用MPP数据库技术对连接查询有帮助–Impala在两表、多表连接查询中优势明显测试结论•充分利用缓存的系统在内存充足的情况下性能优势明显–Shark、Impala在小数据量时性能优势明显–内存不足时性能下降严重，Shark出现很多问题•数据倾斜会严重影响一些系统的性能–Hive、Stinger、Shark对数据倾斜比较敏感，容易造成倾斜–Impala受这方面的影响似乎不大大数据实时分析的基准•很多大数据应用不断累积数据–存在典型的OLTP+OLAP应用–需要基准能够从以下方面度量系统的性能•分析系统查询处理性能–具备交互性的复杂分析–实时分析•数据更新的实时性和吞吐量–数据产生到影响查询结果的延时–系统处理更新的吞吐量•系统的可扩展性–随着规模的变化，系统性能指标表现出的变化趋势张慧杰卞昊穹刘德海陈峻高彦杰何龙董兆安杜小勇教授覃雄派博士30谢谢大家！