实时分析系统（Hive/Hbase/Impala）浅析

1. 什么是实时分析（在线查询）系统？

大数据领域里面，实时分析（在线查询）系统是最多见的一种场景，一般用于客户投诉处理，实时数据分析，在线查询等等过。由于是查询应用，一般有如下特色：

a. 时延低（秒级别）。

b. 查询条件复杂（多个维度，维度不固定），有简单（带有ID)。

c. 查询范围大（一般查询表记录在几十亿级别）。

d. 返回结果数小（几十条甚至几千条）。

e. 并发数要求高（几百上千同时并发）。

f. 支持SQL（这个业界基本上达成共识了，缘由是很难找到一个又会数据分析，还能写JAVA代码的分析工程师）。

传统上，经常使用数据仓库来承担这一任务，数据仓库经过建立索引来应对多维度复杂查询。传统数据仓库也存在很明显的缺点，扩展性不强，索引建立成本高，索引易失效等等。当查询条件复杂时，传统领域和hadoop目前都没有一个特别好的解决方案。维度若是不固定，就没法建立索引或者索引代价过高，一般只能经过全盘暴力SCAN的方法来解决。

目前来完美解决实时分析的系统还在探索中，下面来说讲hadoop领域几种常见的解决方案

2. Hive

一句话描述Hive: hive是基于Hadoop的一个数据仓库工具，能够将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能，能够将sql语句转换为MapReduce任务进行运行。Hive支持HSQL，是一种类SQL。

也真是因为这种机制致使Hive最大的缺点是慢。Map/reduce调度自己只适合批量，长周期任务，相似查询这种要求短平快的业务，代价过高。

Map/reduce为何只适合批量任务，这里不解释，建议你们看下相关原理，业界对这快的分析比较多，由此也诞生了spark等一系列解决方案。

3. Hbase

HBase是一个分布式的、面向列的开源数据库，该技术来源于Chang et al所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统（File System）所提供的分布式数据存储同样，HBase在Hadoop之上提供了相似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不一样于通常的关系数据库，它是一个适合于非结构化数据存储的数据库。另外一个不一样的是HBase基于列的而不是基于行的模式。

Hbase核心是将数据抽象成表，表中只有rowkey和column family。Rowkey是记录的主键，经过key /value很容易找到。Colum family中存储实际的数据。仅能经过主键(row key)和主键的range来检索数据，仅支持单行事务(可经过hive支持来实现多表join等复杂操做)。主要用来存储非结构化和半结构化的松散数据。

正是因为Hbase这种结构，应对查询中带了主键（use id）的应用很是有效果，查询结果返回速度很是快。对没有带主键，经过多个维度来查询时，就很是困难。业界为了解决这个问题，在上面实现了一些技术方案，效果也基本差强人意：

a. 华为的二级索引，核心思路仿照数据库建索引方式对须要查询的列建索引，带来的问题时影响加载速度，数据膨胀率大，二级索引不能建太多，最多1～2个。

b. Hbase自身的协处理器，碰到不带rowkey的查询，由协处理器，经过线程并行扫描。

c. Hbase上的Phoniex，Phoniex 可让开发者在HBase数据集上使用SQL查询。Phoenix查询引擎会将SQL查询转换为一个或多个HBase scan，并编排执行以生成标准的JDBC结果集，对于简单查询来讲，性能甚至赛过Hive。

4. Impala

Impala是Cloudera在受到Google的Dremel启发下开发的实时交互SQL大数据查询工具，Impala没有再使用缓慢的Hive+MapReduce批处理，而是经过使用与商用并行关系数据库中相似的分布式查询引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分组成），能够直接从HDFS或HBase中用SELECT、JOIN和统计函数查询数据，从而大大下降了延迟。其架构如图 1所示，Impala主要由Impalad， State Store和CLI组成。

Impalad: 与DataNode运行在同一节点上，由Impalad进程表示，它接收客户端的查询请求（接收查询请求的Impalad为Coordinator，Coordinator经过JNI调用java前端解释SQL查询语句，生成查询计划树，再经过调度器把执行计划分发给具备相应数据的其它Impalad进行执行），读写数据，并行执行查询，并把结果经过网络流式的传送回给Coordinator，由Coordinator返回给客户端。同时Impalad也与State Store保持链接，用于肯定哪一个Impalad是健康和能够接受新的工做。在Impalad中启动三个ThriftServer: beeswax_server（链接客户端），hs2_server（借用Hive元数据）， be_server（Impalad内部使用）和一个ImpalaServer服务。

Impala State Store: 跟踪集群中的Impalad的健康状态及位置信息，由statestored进程表示，它经过建立多个线程来处理Impalad的注册订阅和与各Impalad保持心跳链接，各Impalad都会缓存一份State Store中的信息，当State Store离线后（Impalad发现State Store处于离线时，会进入recovery模式，反复注册，当State Store从新加入集群后，自动恢复正常，更新缓存数据）由于Impalad有State Store的缓存仍然能够工做，但会由于有些Impalad失效了，而已缓存数据没法更新，致使把执行计划分配给了失效的Impalad，致使查询失败。

CLI: 提供给用户查询使用的命令行工具（Impala Shell使用python实现），同时Impala还提供了Hue，JDBC， ODBC使用接口。

Impala架构相似分布式数据库Greenplum数据库，一个大的查询经过分析为一一个子查询，分布到底层的执行，最后再合并结果，说白了就是经过多线程并发来暴力SCAN来实现高速。

架构是完美的，现实是骨感的，实际使用过程当中，Impala性能和稳定性还差得远。尤为是Impala虽然号称支持HDFS和HBASE，但实际使用中发现，运行在HDFS上，性能还差强人意，运行在HBASE上性能不好，另外还常常有内存溢出之类的问题尚待解决。

5. 结语

目前来看，业界尚未一个完美的解决方案，一般的思路有：

a. 提早根据查询结果来组织数据。每种业务都是不一样的，要想查询得快，就要提早分析场景，在数据入库时，就提早根据查询结果来组织数据。这也是微博等应用的作法，根据显示结果提早存储数据。

b. 对不固定维度的，多维度查询，目前来看hadoop和传统的并行数据库架构上会有一个融合的过程，相信最后会异曲同工，Impala仍是有前途的。

c. 多查询引擎的融合，一般咱们但愿一份数据，能够承担多种应用，既能够承担直接带用户id的快速查询，也系统能够搞定多维度的复杂分析，因此要支持多种应用，多查询引擎的特色融合不能够避免。但愿后面impala能够解决在habase上性能不高的问题。

d. 用高速硬件加速，flash卡目前愈来愈便宜，将须要高速查询的数据换成到flash等高速硬件上。