實時分析系統（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等高速硬件上。