OLAP(On-Line Analytical Processing)联机分析处理,也称为面向交易的处理过程,其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理,并在很短的时间内给出处理结果,是对用户操作快速响应的方式之一。应用在数据仓库,使用对象是决策者。OLAP系统强调的是数据分析,响应速度要求没那么高。
目前市面上主流的开源OLAP引擎包含不限于:Hive、Presto、Kylin、Impala、Sparksql、Druid、等
OLTP(On-Line Transaction Processing)联机事务处理,它使分析人员能够迅速、一致、交互地从各个方面观察信息,以达到深入理解数据的目的。它具有FASMI(Fast Analysis of Shared Multidimensional Information),即共享多维信息的快速分析的特征。主要应用是传统关系型数据库。OLTP系统强调的是内存效率,实时性比较高。Oracle、Redis、Hbase
按照查询类型划分,OLAP一般分为即席查询和固化查询,
按照架构实现划分,主流的OLAP引擎主要有下面三点:
数据轨迹现有的实现方式,从业务诉求看为:每账期按照指定的查询列取数据,进行分析未结算原因,偏向固化查询的方式。但现有的实现方式为先按照查询列值查询出主表数据,再根据主表附属表的关联字段,获取查询附属表的sql,sql为动态拼接出来,这种方式更偏向于即席查询的实现。
需要从以下三个方面考虑框架选型:数据存储和构建、安装搭建、开发成本。
impala是Cloudera开发开源的,Impala是Cloudera开发并开源的,能查询存储在HDFS和HBase中的数据。同Hive一样,也是一种SQL on Hadoop解决方案。但Impala抛弃了MapReduce,使用更类似于传统的MPP数据库技术来提高查询速度。
presto是Facebook开源的大数据查询引擎,为了解决hive查询慢产生。使用java编写,数据全部在内存中处理。
Facebook开源的一个java写的分布式数据查询框架,原生集成了Hive、Hbase和关系型数据库,Presto背后所使用的执行模式与Hive有根本的不同,它没有使用MapReduce,大部分场景下比hive快一个数量级,其中的关键是所有的处理都在内存中完成。
druid同kylin一样,是采用预计算的方式。主要解决的是对于大量的基于时序的数据进行聚合查询。数据可以实时摄入,进入到Druid后立即可查,同时数据是几乎是不可变。通常是基于时序的事实事件,事实发生后进入Druid,外部系统就可以对该事实进行查询。
是一个实时处理时序数据的OLAP数据库,因为它的索引首先按照时间分片,查询的时候也是按照时间线去路由索引。
kylin是一种OLAP数据引擎,支持大数据生态圈的数据分析业务,主要是通过预计算的方式将用户设定的多维度数据立方体(cube)缓存起来,达到快速查询的目的。应用场景应该是针对复杂sql join后的数据缓存。
核心是Cube,cube是一种预计算技术,基本思路是预先对数据作多维索引,查询时只扫描索引而不访问原始数据从而提速。
这种OLAP引擎,一般包括以下几部分:
应用思路:将hive中的数据按照查询列 构建成cube,存储到hbase中,数据轨迹连接kylin的jdbc接口实现快速查询。
基于spark平台上的一个olap框架,本质上也是基于DAG的MPP, 基本思路是增加机器来并行计算,从而提高查询速度。
这几种框架各有优缺点,存在就是合理,如何选型个人看法如下:
从成熟度来讲:kylin>spark sql>Druid>presto
从超大数据的查询效率来看:Druid>kylin>presto>spark sql
从支持的数据源种类来讲:presto>spark sql>kylin>Druid
大数据查询目前来讲可以大体分为三类:
1.基于hbase预聚合的,比如Opentsdb,Kylin,Druid等,需要指定预聚合的指标,在数据接入的时候根据指定的指标进行聚合运算,适合相对固定的业务报表类需求,只需要统计少量维度即可满足业务报表需求
2.基于Parquet列式存储的,比如Presto, Drill,Impala等,基本是完全基于内存的并行计算,Parquet系能降低存储空间,提高IO效率,以离线处理为主,很难提高数据写的实时性,超大表的join支持可能不够好。spark sql也算类似,但它在内存不足时可以spill disk来支持超大数据查询和join
3.基于lucene外部索引的,比如ElasticSearch和Solr,能够满足的的查询场景远多于传统的数据库存储,但对于日志、行为类时序数据,所有的搜索请求都也必须搜索所有的分片,另外,对于聚合分析场景的支持也是软肋
与X沟通,建议使用impala或者spark做查询,于是查询对比各种开源的OLAP引擎。
(1)cloudera公司2014年做的性能基准对比测试,原文链接:http://blog.cloudera.com/blog/2014/09/new-benchmarks-for-sql-on-hadoop-impala-1-4-widens-the-performance-gap/
下面看看这个测试是怎么做的。
配置:
所有测试都运行在一个完全相同的21节点集群上,每个节点只配有64G内存。之所以内存不配大,就是为了消除人们对于Impala只有在非常大的内存上才有好性能的错误认识:
对比产品:
查询:
结果:
单用户如下图所示。
多用户如下图所示。
查询吞吐率如下图所示。
Impala本身就是cloudera公司的主打产品,因此只听其一面之词未免有失偏颇,下面就再看一个SAS公司的测试
(2)SAS2013年做的Impala和Hive的对比测试
硬件:
刀片服务器配置
软件:
数据:
数据模型如下图所示。
查询:
使用了以下5条查询语句
- -- What are the most visited top-level directories on the customer support website for a given week and year?
- select top_directory, count(*) as unique_visits
- from (select distinct visitor_id, split(requested_file, '[\\/]')[1] as top_directory
- from page_click_flat
- where domain_nm = 'support.sas.com'
- and flash_enabled='1'
- and weekofyear(detail_tm) = 48
- and year(detail_tm) = 2012
- ) directory_summary
- group by top_directory
- order by unique_visits;
- -- What are the most visited pages that are referred from a Google search for a given month?
- select domain_nm, requested_file, count(*) as unique_visitors, month
- from (select distinct domain_nm, requested_file, visitor_id, month(detail_tm) as month
- from page_click_flat
- where domain_nm = 'support.sas.com'
- and referrer_domain_nm = 'www.google.com'
- ) visits_pp_ph_summary
- group by domain_nm, requested_file, month
- order by domain_nm, requested_file, unique_visitors desc, month asc;
- -- What are the most common search terms used on the customer support website for a given year?
- select query_string_txt, count(*) as count
- from page_click_flat
- where query_string_txt <> ''
- and domain_nm='support.sas.com'
- and year(detail_tm) = '2012'
- group by query_string_txt
- order by count desc;
- -- What is the total number of visitors per page using the Safari browser?
- select domain_nm, requested_file, count(*) as unique_visitors
- from (select distinct domain_nm, requested_file, visitor_id
- from page_click_flat
- where domain_nm='support.sas.com'
- and browser_nm like '%Safari%'
- and weekofyear(detail_tm) = 48
- and year(detail_tm) = 2012
- ) uv_summary
- group by domain_nm, requested_file
- order by unique_visitors desc;
- -- How many visitors spend more than 10 seconds viewing each page for a given week and year?
- select domain_nm, requested_file, count(*) as unique_visits
- from (select distinct domain_nm, requested_file, visitor_id
- from page_click_flat
- where domain_nm='support.sas.com'
- and weekofyear(detail_tm) = 48
- and year(detail_tm) = 2012
- and seconds_spent_on_page_cnt > 10;
- ) visits_summary
- group by domain_nm, requested_file
- order by unique_visits desc;
结果:
Hive与Impala查询时间对比如下图所示。
可以看到,查询1、2、4Impala比Hive快的多,而查询3、5Impala却比Hive慢很多。这个测试可能更客观一些,而且也从侧面说明了一个问题,不要轻信厂商宣传的数据,还是要根据自己的实际测试情况得出结论。
1、Impala
Impala和 presto, pinot, spark sql等相比,确实是查询性能最快的(注意,我单单说的是查询性能)。Impala最大的问题在于catalogd是个单点,元数据多了后会遇到各种问题。
Catalogd进程是Impala中用来传递Impala SQL导致的元数据变化的组件,它把这些变化传递给集群中所有的节点。一个集群中只需要一个节点上有这个守护进程,因为请求是通过Statestore传递的,因此Statestored和Catalogd 服务应当运行在同一节点上。
引入Catalogd进程的目的就是减少执行REFRESH和INVALIDATE METADATA语句,当在Impala中执行 CREATE TABLE 、 INSERT 或其他表修改、数据修改操作时,不再需要执行 REFRESH 或INVALIDATE METADATA 语句,但是在Hive中执行这些操作,或者直接在HDFS操作数据,这两个语句仍然需要,但是只需要在其中一个节点上运行,不再需要在所有节点上都运行。
本质上,Impala是一个MPP engine,各节点不共享资源,每个executor可以独自完成数据的读取和计算,缺点在于怕stragglers,遇到后整个engine的性能下降到该straggler的能力,所谓木桶的短板,这也是为什么MPP架构不适合异构的机器,要求各节点配置一样。
2、Spark SQL
Spark SQL应该还是算做Batching Processing, 中间计算结果需要落地到磁盘,所以查询效率没有MPP架构的引擎(如Impala)高。
联系客服