我們在前面兩篇中介紹了數(shù)據(jù)倉庫工具 Hive厚骗，但是早期的 Hive 是依賴 Hadoop 的 MapReduce 進(jìn)行并行數(shù)據(jù)處理扭仁，而 MapReduce 作為離線批處理計算框架的延時是非常高的隘马，用 Hive 做實時交互式查詢的等待一般都是在分鐘級別，這顯然無法滿足企業(yè)的即席查詢要求。為了解決實時交互式查詢這一問題坑律，Cloudera 公司開發(fā)了 Impala臂痕，Impala 的查詢速度是 Hive 的 3~30倍伯襟。當(dāng)然，Impala 也提供了數(shù)據(jù)倉庫的功能握童，業(yè)界很多人甚至認(rèn)為姆怪，Impala 將會替代 Hive 成為數(shù)據(jù)倉庫最火的工具。
Impala 系統(tǒng)架構(gòu)
上圖給出了 Impala 的整個系統(tǒng)架構(gòu)澡绩，其中黃色標(biāo)出來的部分是屬于 Impala 的系統(tǒng)組件稽揭，而藍(lán)色部分是 Hadoop 的其他組件，從這張圖小伙伴們就可以明白肥卡，Impala 并不是單獨部署而是跟 Hadoop 的其他組件部署在同一個集群上的溪掀。正是由于部署在同一個集群上，Impala 才可以使用 HDFS 和 HBase 來存儲數(shù)據(jù)步鉴，還可以使用 Hive 為其存儲元數(shù)據(jù)揪胃！
Impalad（Impala Daemon）：駐留在集群的每個 DataNode 節(jié)點上的守護(hù)進(jìn)程璃哟，與集群中的其他節(jié)點上的 Impalad 進(jìn)行分布式并行工作，負(fù)責(zé)具體的查詢?nèi)蝿?wù)喊递，其包含三個模塊：Query Planner随闪，Query Coordinator 和 Query Exec Engine。
Impalad 主要負(fù)責(zé)協(xié)調(diào)客戶端提交的查詢的執(zhí)行骚勘，與 HDFS 的數(shù)據(jù)節(jié)點（HDFS DataNode）運行在同一節(jié)點上铐伴，這樣可以就近處理數(shù)據(jù)，實現(xiàn)了計算向數(shù)據(jù)靠攏俏讹。給其他 Impalad 分配任務(wù)以及收集其他 Impalad 的執(zhí)行結(jié)果進(jìn)行匯總盛杰，這也比較好理解，對于大規(guī)模數(shù)據(jù)藐石，要想快速得到結(jié)果即供，肯定是分布式查詢，將一個大的查詢分成很多的子查詢于微，每個子查詢（Impalad 執(zhí)行其他 Impalad 給其分配的任務(wù)逗嫡，對本地 HDFS 和 HBase 里的部分?jǐn)?shù)據(jù)進(jìn)行操作）處理一個節(jié)點上的數(shù)據(jù)，然后再將這些結(jié)果進(jìn)行匯總株依。
StateStore：負(fù)責(zé)整個元數(shù)據(jù)管理和狀態(tài)信息維護(hù)驱证，每個 Impala 的查詢提交時，系統(tǒng)都會為其創(chuàng)建一個 StateStored 進(jìn)程恋腕，前面我們剛提到 Impalad 會將一個查詢?nèi)蝿?wù)分解成很多子查詢抹锄，并讓其他節(jié)點上的 Impalad 為其執(zhí)行子查詢?nèi)蝿?wù)，那么 Impala 如何知道這些子查詢是否成功了呢荠藤？就要靠 StateStored 進(jìn)程去跟蹤每個 Impalad 的執(zhí)行情況以及監(jiān)控狀態(tài)信息伙单。所以，StateStored 進(jìn)程就是負(fù)責(zé)收集分布在集群中各個 Impalad 進(jìn)程的資源信息用于查詢調(diào)度哈肖。
CLI：即用戶訪問接口吻育，給用戶提供查詢使用的命令行工具。
需要注意的是淤井，Impala 的元數(shù)據(jù)是直接存儲在 Hive 中的布疼。所以，Impala 采用與 Hive 相同的元數(shù)據(jù)币狠、相同的 SQL 語法游两，相同的 ODBC 驅(qū)動程序和用戶接口，這樣做的好處是可以在一個 Hadoop 平臺上統(tǒng)一部署 Hive 和 Impala 等分析工具漩绵，實現(xiàn)在一個平臺上可以同時滿足批處理和實時查詢贱案。
Impala 查詢的執(zhí)行過程
第0步，在用戶提交查詢之前渐行，Impala 就已經(jīng)創(chuàng)建了一個負(fù)責(zé)協(xié)調(diào)客戶端提交查詢的 Impalad 進(jìn)程轰坊，該進(jìn)程會向 StateStore 提交注冊訂閱信息铸董，StateStore 會創(chuàng)建一個 statestored 進(jìn)程，statestored 進(jìn)程通過創(chuàng)建多個線程來處理 Impalad 的注冊訂閱信息肴沫。
第1步粟害，用戶通過 CLI 客戶端提交一個查詢到 Impalad 進(jìn)程，Impalad 的 Query Planner 對 SQL 語句進(jìn)行解析颤芬，生成解析樹悲幅，Planner 把這個查詢的解析樹再變成若干 PlanFragment，發(fā)送到 Query Coordinator站蝠。
第2步汰具，Coordinator 通過從 MySQL 元數(shù)據(jù)庫中獲取元數(shù)據(jù)，從 HDFS 的 NameNode 節(jié)點中獲取數(shù)據(jù)的存儲地址菱魔，以得到存儲這個查詢相關(guān)數(shù)據(jù)的所有數(shù)據(jù)節(jié)點留荔。
第3步，Coordinator 初始化相應(yīng) Impalad 上的任務(wù)執(zhí)行澜倦，即把查詢?nèi)蝿?wù)分配給所有存儲這個查詢相關(guān)數(shù)據(jù)的數(shù)據(jù)節(jié)點聚蝶。
第4步档礁，Query Executor 通過流式交換中間輸出秽澳，并由 Query Coordinator 匯聚來自各個 Impalad 的結(jié)果。
第5步奇瘦，Coordinator 把匯總后的結(jié)果返回給 CLI 客戶端桩卵。
Impala 與 Hive 的比較
不同點
- Hive 適合長時間的批處理查詢分析验靡，而 Impala 適合實時交互式 SQL 查詢。
- Hive 依賴于 MapReduce 計算框架雏节，Impala 把整個執(zhí)行計劃表現(xiàn)為一棵完整的執(zhí)行計劃樹胜嗓，直接分發(fā)執(zhí)行計劃到各個 Impalad 執(zhí)行查詢。
- Hive 在執(zhí)行過程中矾屯，如果內(nèi)存放不下所有數(shù)據(jù)則會啟用磁盤兼蕊，以保證查詢可以順利執(zhí)行。但是 Impala 在遇到內(nèi)存放不下的情況時件蚕，不會利用磁盤。
相同點
- Hive 和 Impala 均采用 HDFS 和 HBase 存儲數(shù)據(jù)产禾。
- Hive 和 Impala 均使用相同的元數(shù)據(jù)排作。
- Hive 和 Impala 均是通過將 SQL 解析處理成計劃樹，生成執(zhí)行計劃亚情。
那么妄痪，通過本篇的講解，相信小伙伴們已經(jīng)對 Impala 有了定位楞件，Impala 的存在并不是為了取代 Hive衫生，而是為了彌補 Hive 的處理時間過長裳瘪，無法做到實時查詢的問題。所以罪针，企業(yè)在實際使用時彭羹，往往是配合使用 Hive 和 Impala，即先用 Hive 對數(shù)據(jù)進(jìn)行轉(zhuǎn)換處理之后泪酱，再使用 Impala 在 Hive 處理完成的數(shù)據(jù)集上進(jìn)行快速數(shù)據(jù)分析派殷。
