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等高速硬體上。