Recommended
More Related Content
Similar to 陈跃国：Sql on-hadoop结构化大数据分析系统性能评测
Similar to 陈跃国：Sql on-hadoop结构化大数据分析系统性能评测 (20)
More from hdhappy001
More from hdhappy001 (20)
陈跃国：Sql on-hadoop结构化大数据分析系统性能评测
- 3. 基准的意义 • 如今大数据市场形如80年代的的数据库市场 – 新的系统和产品迅速涌现，尚未形成垄断 • 传统数据库成功非常受益于基准的制定和 推广 – TPC: Transaction Processing Performance Council • 目前缺少大数据系统之间比较的基准 – 基准制定困难：数据类型多、应用类型多、系统 复杂、负载动态等
- 4. 基准测试 • 大数据基准正在建设，尚需完善 – BigBench，Berkeley Big Data Benchmark等 – 研究和产业化不能坐等公认的基准形成 • 当前交互式大数据分析系统（SQL-onHadoop）非常火热 – 在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 5
- 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 6
- 7. 查询集… • 单表查询: --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 profit limit 100; --qA9-select count(*) from store_sales where ss_quantity between 1 and 20 limit 100;
- 8. 查询集.. • 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;
- 9. 查询集. • 星形查询: --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 ;
- 10. 查询集 • 复杂查询: --qD6gho—(5表连接) select a.ca_state state, count(*) cnt from customer_address a join 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_state having count(*) >= 10 order by cnt limit 100;
- 12. 100个节点，数据量变化
- 13. 错误 错误
- 14. 错误 错误
- 16. 1TB数据，节点数变化
- 17. 错误 错误
- 18. 错误 错误
- 19. 错误 错误
- 20. 被测系统分析
- 26. 测试结论 • 列存储一般对查询性能提升明显，尤其大表是一 个包含很多列的表 – 从Stinger (Hive 0.11 with ORCFile) VS Hive，以及Impala的 Parquet VS Textfile • 绕开MR计算模型，省去中间结果的持久化和MR 任务调度的延迟，会带来性能提升 – Impala，Shark，Presto要好于Hive和Stinger – 但这种优势随着数据量增加和查询变复杂而减弱 • 使用MPP数据库技术对连接查询有帮助 – Impala在两表、多表连接查询中优势明显
- 27. 测试结论 • 充分利用缓存的系统在内存充足的情况下 性能优势明显 – Shark、Impala在小数据量时性能优势明显 – 内存不足时性能下降严重，Shark出现很多问题 • 数据倾斜会严重影响一些系统的性能 – Hive、Stinger、Shark对数据倾斜比较敏感，容 易造成倾斜 – Impala受这方面的影响似乎不大
- 28. 大数据实时分析的基准 • 很多大数据应用不断累积数据 – 存在典型的OLTP+OLAP应用 – 需要基准能够从以下方面度量系统的性能 • 分析系统查询处理性能 – 具备交互性的复杂分析 – 实时分析 • 数据更新的实时性和吞吐量 – 数据产生到影响查询结果的延时 – 系统处理更新的吞吐量 • 系统的可扩展性 – 随着规模的变化，系统性能指标表现出的变化趋势
- 30. 谢谢大家！ 30