OLAP和OLTP的区别
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一般分为即席查询和固化查询，
- 即席查询:通过手写sql完成一些临时的数据分析需求，这类sql形式多变、逻辑复杂，对查询时间没有严格要求
- 固化查询：指的是一些固化下来的取数、看数需求，通过数据产品的形式提供给用户，从而提高数据分析和运营的效率。这类的sql固定模式，对响应时间有较高要求。
按照架构实现划分，主流的OLAP引擎主要有下面三点：
- MPP架构系统(Presto/Impala/SparkSQL/Drill等)。这种架构主要还是从查询引擎入手，使用分布式查询引擎，而不是使用hive+mapreduce架构，提高查询效率。
- 搜索引擎架构的系统(es，solr等)，在入库时将数据转换为倒排索引，采用Scatter-Gather计算模型，牺牲了灵活性换取很好的性能，在搜索类查询上能做到亚秒级响应。但是对于扫描聚合为主的查询，随着处理数据量的增加，响应时间也会退化到分钟级。
- 预计算系统（Druid/Kylin等）则在入库时对数据进行预聚合，进一步牺牲灵活性换取性能，以实现对超大数据集的秒级响应。
数据轨迹现有的实现方式，从业务诉求看为:每账期按照指定的查询列取数据，进行分析未结算原因，偏向固化查询的方式。但现有的实现方式为先按照查询列值查询出主表数据，再根据主表附属表的关联字段，获取查询附属表的sql，sql为动态拼接出来，这种方式更偏向于即席查询的实现。
需要从以下三个方面考虑框架选型：数据存储和构建、安装搭建、开发成本。
impala
impala是Cloudera开发开源的，Impala是Cloudera开发并开源的，能查询存储在HDFS和HBase中的数据。同Hive一样，也是一种SQL on Hadoop解决方案。但Impala抛弃了MapReduce,使用更类似于传统的MPP数据库技术来提高查询速度。
- impala可以直接查询hdfs或hbase上的数据，可以与现有的存储无缝对接。
- impala需要单独安装，公司内paas主推。需要与现场确认。
- impala提供jdbc接口和sql执行引擎，可以与现有系统集成
Presto
presto是Facebook开源的大数据查询引擎，为了解决hive查询慢产生。使用java编写，数据全部在内存中处理。
Facebook开源的一个java写的分布式数据查询框架，原生集成了Hive、Hbase和关系型数据库，Presto背后所使用的执行模式与Hive有根本的不同，它没有使用MapReduce，大部分场景下比hive快一个数量级，其中的关键是所有的处理都在内存中完成。
- 原生集成了Hive、Hbase和关系型数据库。
- 需要与现场确认是否能提供
- 提供jdbc接口和sql执行引擎，可以与现有系统集成
druid
druid同kylin一样，是采用预计算的方式。主要解决的是对于大量的基于时序的数据进行聚合查询。数据可以实时摄入，进入到Druid后立即可查，同时数据是几乎是不可变。通常是基于时序的事实事件，事实发生后进入Druid，外部系统就可以对该事实进行查询。
是一个实时处理时序数据的OLAP数据库，因为它的索引首先按照时间分片，查询的时候也是按照时间线去路由索引。
- 需要预计算，将数据存储在druid的Segment文件中，占用一部分存储资源
- 需要与现场确认是否能提供
- 对sql支持不友好，需要用他自己的方言书写
kylin
kylin是一种OLAP数据引擎，支持大数据生态圈的数据分析业务，主要是通过预计算的方式将用户设定的多维度数据立方体(cube)缓存起来，达到快速查询的目的。应用场景应该是针对复杂sql join后的数据缓存。
核心是Cube，cube是一种预计算技术，基本思路是预先对数据作多维索引，查询时只扫描索引而不访问原始数据从而提速。
这种OLAP引擎，一般包括以下几部分：
- 数据构建存储：cube构建，元数据信息
- sql解析执行：Query引擎(sql解释器)，routing模块(sql执行)
- 上层接口服务；jdbc/odbc接口，rest服务
应用思路：将hive中的数据按照查询列 构建成cube，存储到hbase中，数据轨迹连接kylin的jdbc接口实现快速查询。
- 需要预计算，将数据构建成cube存储到hbase
- 需要与现场确认是否能提供
- 提供jdbc接口和rest服务
redis
将要分析的数据同步到redis，在redis中快速查询数据。可以在分析前将本月数据同步到redis。
Spark SQL
基于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引擎。
一、Impala概述
什么是Impala？
Impala是用于处理存储在Hadoop集群中的大量数据的MPP（大规模并行处理）SQL查询引擎。与其他Hadoop的SQL引擎相比，它提供了高性能和低延迟。换句话说，Impala是性能最高的SQL引擎（提供类似RDBMS的体验），它提供了访问存储在Hadoop分布式文件系统中的数据的最快方法。
为什么选择Impala？ Impala的优点
Impala通过使用标准组件（如HDFS，HBase，Metastore，YARN）将传统分析数据库的SQL支持和多用户性能与Apache Hadoop的可扩展性和灵活性相结合。
1、 使用Impala，与其他SQL引擎（如Hive）相比，用户可以使用传统的SQL查询以更快的方式与HDFS或HBase进行通信。以极快的速度处理存储在HDFS中的数据。
2、Impala支持内存中数据处理，即，它访问/分析存储在Hadoop数据节点上的数据，而无需数据移动。
基于内存进行计算，能够对PB级数据进行交互式实时查询、分析
由于在数据驻留（在Hadoop集群上）时执行数据处理，因此在使用Impala时，不需要对存储在Hadoop上的数据进行数据转换和数据移动。
使用Impala，您可以将数据存储在存储系统中，如HDFS，Apache HBase和Amazon s3。
3、Impala可以读取Hadoop使用的几乎所有文件格式，如Parquet，Avro，RCFile。
Impala正在率先使用Parquet文件格式，这是一种针对数据仓库场景中典型的大规模查询进行优化的柱状存储布局。
4、Impala使用Apache Hive的元数据，ODBC驱动程序和SQL语法。
Impala将相同的元数据，SQL语法（Hive SQL），ODBC驱动程序和用户界面（Hue Beeswax）用作Apache Hive，为面向批量或实时查询提供熟悉且统一的平台。
5、与Apache Hive不同，Impala不基于MapReduce算法。 它实现了一个基于守护进程的分布式架构，它负责在同一台机器上运行的查询执行的所有方面。因此，它减少了使用MapReduce的延迟，这使Impala比Apache Hive快。
6、可以将Impala与业务智能工具（如Tableau，Pentaho，Micro策略和缩放数据）集成。
Impala的缺点
1、Impala不提供任何对序列化和反序列化的支持。
2、Impala只能读取文本文件，而不能读取自定义二进制文件。
3、每当新的记录/文件被添加到HDFS中的数据目录时，该表需要被刷新。
4、对内存依赖大，只在内存中计算，官方建议128G(一般64G基本满足)，可优化: 各个节点汇总的节点(服务器)内存选用大的，不汇总节点可小点
5、稳定性不如hive
关系数据库和Impala
Impala使用类似于SQL和HiveQL的Query语言。 下表描述了SQL和Impala查询语言之间的一些关键差异。
| Impala |
关系型数据库 |
|
| Impala使用类似于HiveQL的类似SQL的查询语言。 |
关系数据库使用SQL语言。 |
|
| 在Impala中，您无法更新或删除单个记录。 |
在关系数据库中，可以更新或删除单个记录。 |
|
| Impala不支持事务。 |
关系数据库支持事务。 |
|
| Impala不支持索引。 |
关系数据库支持索引。 |
|
| Impala存储和管理大量数据（PB）。 |
与Impala相比，关系数据库处理的数据量较少（TB）。 |
Hive、Hbase、Impala
虽然Cloudera Impala使用与Hive相同的查询语言，元数据和用户界面，但在某些方面它与Hive和HBase不同。 下表介绍了HBase，Hive和Impala之间的比较分析。
| HBase |
Hive |
Impala |
| HBase是基于Apache Hadoop的宽列存储数据库。 它使用BigTable的概念。 |
Hive是一个数据仓库软件。 使用它，我们可以访问和管理基于Hadoop的大型分布式数据集。 |
Impala是一个管理，分析存储在Hadoop上的数据的工具。 |
| HBase的数据模型是宽列存储。 |
Hive遵循关系模型。 |
Impala遵循关系模型。 |
| HBase是使用Java语言开发的。 |
Hive是使用Java语言开发的。 |
Impala是使用C ++开发的。 |
| HBase的数据模型是无模式的。 |
Hive的数据模型是基于模式的。 |
Impala的数据模型是基于模式的。 |
| HBase提供Java，RESTful和Thrift API。 |
Hive提供JDBC，ODBC，Thrift API。 |
Impala提供JDBC和ODBC API。 |
| 支持C，C＃，C ++，Groovy，Java PHP，Python和Scala等编程语言。 |
支持C ++，Java，PHP和Python等编程语言。 |
Impala支持所有支持JDBC / ODBC的语言。 |
| HBase提供对触发器的支持。 |
Hive不提供任何触发器支持。 |
Impala不提供对触发器的任何支持。 |
二、Impala架构
Impala是在Hadoop集群中的许多系统上运行的MPP（大规模并行处理）查询执行引擎。 与传统存储系统不同，impala与其存储引擎解耦。 它有三个主要组件，即Impala daemon（Impalad），Impala Statestore和Impala元数据或metastore。
Impala daemon（Impalad）
Impala daemon（也称为impalad）在安装Impala的每个节点上运行。 它接受来自各种接口的查询，如impala shell，hue browser等...并处理它们。
每当将查询提交到特定节点上的impalad时，该节点充当该查询的“协调器节点”。 Impalad还在其他节点上运行多个查询。 接受查询后，Impalad读取和写入数据文件，并通过将工作分发到Impala集群中的其他Impala节点来并行化查询。 当查询处理各种Impalad实例时，所有查询都将结果返回到中央协调节点。
根据需要，可以将查询提交到专用Impalad或以负载平衡方式提交到集群中的另一Impalad。
Impala 存储的状态
Impala有另一个称为Impala State存储的重要组件，它负责检查每个Impalad的运行状况，然后经常将每个Impala Daemon运行状况中继给其他守护程序。 这可以在运行Impala服务器或群集中的其他节点的同一节点上运行。
Impala State存储守护进程的名称为存储的状态。 Impalad将其运行状况报告给Impala State存储守护程序，即存储的状态。
在由于任何原因导致节点故障的情况下，Statestore将更新所有其他节点关于此故障，并且一旦此类通知可用于其他impalad，则其他Impala守护程序不会向受影响的节点分配任何进一步的查询。
Impala元数据和元存储
Impala元数据和元存储是另一个重要组件。 Impala使用传统的MySQL或PostgreSQL数据库来存储表定义。 诸如表和列信息和表定义的重要细节存储在称为元存储的集中式数据库中。
每个Impala节点在本地缓存所有元数据。 当处理极大量的数据和/或许多分区时，获得表特定的元数据可能需要大量的时间。 因此，本地存储的元数据缓存有助于立即提供这样的信息。
当表定义或表数据更新时，其他Impala后台进程必须通过检索最新元数据来更新其元数据缓存，然后对相关表发出新查询。
五、Impala与Hive的异同
数据存储
- 使用相同的存储数据池都支持把数据存储于HDFS, HBase。
元数据：
- 两者使用相同的元数据
SQL解释处理：
- 比较相似都是通过词法分析生成执行计划。
执行计划：
- Hive: 依赖于MapReduce执行框架，执行计划分成 map->shuffle->reduce->map->shuffle->reduce…的模型。如果一个Query会 被编译成多轮MapReduce，则会有更多的写中间结果。由于MapReduce执行框架本身的特点，过多的中间过程会增加整个Query的执行时间。
- Impala: 把执行计划表现为一棵完整的执行计划树，可以更自然地分发执行计划到各个Impalad执行查询，而不用像Hive那样把它组合成管道型的 map->reduce模式，以此保证Impala有更好的并发性和避免不必要的中间sort与shuffle。
数据流：
- Hive: 采用推的方式，每一个计算节点计算完成后将数据主动推给后续节点。
- Impala: 采用拉的方式，后续节点通过getNext主动向前面节点要数据，以此方式数据可以流式的返回给客户端，且只要有1条数据被处理完，就可以立即展现出来，而不用等到全部处理完成，更符合SQL交互式查询使用。
内存使用：
- Hive: 在执行过程中如果内存放不下所有数据，则会使用外存，以保证Query能顺序执行完。每一轮MapReduce结束，中间结果也会写入HDFS中，同样由于MapReduce执行架构的特性，shuffle过程也会有写本地磁盘的操作。
- Impala: 在遇到内存放不下数据时，当前版本1.0.1是直接返回错误，而不会利用外存，以后版本应该会进行改进。这使用得Impala目前处理Query会受到一 定的限制，最好还是与Hive配合使用。Impala在多个阶段之间利用网络传输数据，在执行过程不会有写磁盘的操作（insert除外）
调度
- Hive任务的调度依赖于Hadoop的调度策略。
- Impala的调度由自己完成，目前的调度算法会尽量满足数据的局部性，即扫描数据的进程应尽量靠近数据本身所在的物理机器。但目前调度暂时还没有考虑负载均衡的问题。从Cloudera的资料看，Impala程序的瓶颈是网络IO，目前Impala中已经存在对Impalad机器网络吞吐进行统计，但目前还没有利用统计结果进行调度。
容错
- Hive任务依赖于Hadoop框架的容错能力，可以做到很好的failover
- Impala中不存在任何容错逻辑，如果执行过程中发生故障，则直接返回错误。当一个Impalad失败时，在这个Impalad上正在运行的所有query都将失败。但由于Impalad是对等的，用户可以向其他Impalad提交query，不影响服务。当StateStore失败时，也不会影响服务，但由于Impalad已经不能再更新集群状态，如果此时有其他Impalad失败，则无法及时发现。这样调度时，如果谓一个已经失效的Impalad调度了一个任务，则整个query无法执行。
六、Spark SQL vs Impala, 同样作为大数据SQL查询引擎框架有什么不同之处？
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）高。