基於Hadoop的數據倉庫Hive 基礎知識 - miao君的文章 - 知乎 https://zhuanlan.zhihu.com/p/25608332
Hive是基於Hadoop的數據倉庫工具，可對存儲在HDFS上的文件中的數據集進行數據整理、特殊查詢和分析處理，提供了類似於SQL語言的查詢語言–HiveQL，可通過HQL語句實現簡單的MR統計，Hive將HQL語句轉換成MR任務進行執行。
一、概述
1.1 數據倉庫概念
數據倉庫（Data Warehouse）是一個面向主題的（Subject Oriented）、集成的（Integrated）、相對穩定的（Non-Volatile）、反應歷史變化（Time Variant）的數據集合，用於支持管理決策。
數據倉庫體系結構通常含四個層次：數據源、數據存儲和管理、數據服務、數據應用。
數據源：是數據倉庫的數據來源，含外部數據、現有業務系統和文檔資料等；
數據集成：完成數據的抽取、清洗、轉換和加載任務，數據源中的數據採用ETL（Extract-Transform-Load）工具以固定的週期加載到數據倉庫中。
數據存儲和管理：此層次主要涉及對數據的存儲和管理，含數據倉庫、數據集市、數據倉庫檢測、運行與維護工具和元數據管理等。
數據服務：爲前端和應用提供數據服務，可直接從數據倉庫中獲取數據供前端應用使用，也可通過OLAP（OnLine Analytical Processing，聯機分析處理）服務器爲前端應用提供負責的數據服務。
數據應用：此層次直接面向用戶，含數據查詢工具、自由報表工具、數據分析工具、數據挖掘工具和各類應用系統。
1.2 傳統數據倉庫的問題
無法滿足快速增長的海量數據存儲需求，傳統數據倉庫基於關係型數據庫，橫向擴展性較差，縱向擴展有限。
無法處理不同類型的數據，傳統數據倉庫只能存儲結構化數據，企業業務發展，數據源的格式越來越豐富。
傳統數據倉庫建立在關係型數據倉庫之上，計算和處理能力不足，當數據量達到TB級後基本無法獲得好的性能。
1.3 Hive
Hive是建立在Hadoop之上的數據倉庫，由Facebook開發，在某種程度上可以看成是用戶編程接口，本身並不存儲和處理數據，依賴於HDFS存儲數據，依賴MR處理數據。有類SQL語言HiveQL，不完全支持SQL標準，如，不支持更新操作、索引和事務，其子查詢和連接操作也存在很多限制。
Hive把HQL語句轉換成MR任務後，採用批處理的方式對海量數據進行處理。數據倉庫存儲的是靜態數據，很適合採用MR進行批處理。Hive還提供了一系列對數據進行提取、轉換、加載的工具，可以存儲、查詢和分析存儲在HDFS上的數據。
1.4 Hive與Hadoop生態系統中其他組件的關係
Hive依賴於HDFS存儲數據，依賴MR處理數據；
Pig可作爲Hive的替代工具，是一種數據流語言和運行環境，適合用於在Hadoop平臺上查詢半結構化數據集，用於與ETL過程的一部分，即將外部數據裝載到Hadoop集羣中，轉換爲用戶需要的數據格式；
HBase是一個面向列的、分佈式可伸縮的數據庫，可提供數據的實時訪問功能，而Hive只能處理靜態數據，主要是BI報表數據，Hive的初衷是爲減少複雜MR應用程序的編寫工作，HBase則是爲了實現對數據的實時訪問。
1.5 Hive與傳統數據庫的對比
1.6 Hive的部署和應用
1.6.1 Hive在企業大數據分析平臺中的應用
當前企業中部署的大數據分析平臺，除Hadoop的基本組件HDFS和MR外，還結合使用Hive、Pig、HBase、Mahout，從而滿足不同業務場景需求。
上圖是企業中一種常見的大數據分析平臺部署框架 ，在這種部署架構中：
- Hive和Pig用於報表中心，Hive用於分析報表，Pig用於報表中數據的轉換工作。
- HBase用於在線業務，HDFS不支持隨機讀寫操作，而HBase正是爲此開發，可較好地支持實時訪問數據。
- Mahout提供一些可擴展的機器學習領域的經典算法實現，用於創建商務智能（BI）應用程序。
二、Hive系統架構
下圖顯示Hive的主要組成模塊、Hive如何與Hadoop交互工作、以及從外部訪問Hive的幾種典型方式。
Hive主要由以下三個模塊組成：
- 用戶接口模塊，含CLI、HWI、JDBC、Thrift Server等，用來實現對Hive的訪問。CLI是Hive自帶的命令行界面；HWI是Hive的一個簡單網頁界面；JDBC、ODBC以及Thrift Server可向用戶提供進行編程的接口，其中Thrift Server是基於Thrift軟件框架開發的，提供Hive的RPC通信接口。
- 驅動模塊（Driver），含編譯器、優化器、執行器等，負責把HiveQL語句轉換成一系列MR作業，所有命令和查詢都會進入驅動模塊，通過該模塊的解析變異，對計算過程進行優化，然後按照指定的步驟執行。
- 元數據存儲模塊（Metastore），是一個獨立的關係型數據庫，通常與MySQL數據庫連接後創建的一個MySQL實例，也可以是Hive自帶的Derby數據庫實例。此模塊主要保存表模式和其他系統元數據，如表的名稱、表的列及其屬性、表的分區及其屬性、表的屬性、表中數據所在位置信息等。
喜歡圖形界面的用戶，可採用幾種典型的外部訪問工具：Karmasphere、Hue、Qubole等。
三、Hive工作原理
3.1 SQL語句轉換成MapReduce作業的基本原理
3.1.1 用MapReduce實現連接操作
假設連接（join）的兩個表分別是用戶表User(uid,name)和訂單表Order(uid,orderid)，具體的SQL命令：
SELECT name, orderid FROM User u JOIN Order o ON u.uid=o.uid;
上圖描述了連接操作轉換爲MapReduce操作任務的具體執行過程。
首先，在Map階段，
- User表以uid爲key，以name和表的標記位（這裏User的標記位記爲1）爲value，進行Map操作，把表中記錄轉換生成一系列KV對的形式。比如，User表中記錄(1,Lily)轉換爲鍵值對(1,<1,Lily>)，其中第一個“1”是uid的值，第二個“1”是表User的標記位，用來標示這個鍵值對來自User表；
- 同樣，Order表以uid爲key，以orderid和表的標記位（這裏表Order的標記位記爲2）爲值進行Map操作，把表中的記錄轉換生成一系列KV對的形式；
- 接着，在Shuffle階段，把User表和Order表生成的KV對按鍵值進行Hash，然後傳送給對應的Reduce機器執行。比如KV對(1,<1,Lily>)、(1,<2,101>)、(1,<2,102>)傳送到同一臺Reduce機器上。當Reduce機器接收到這些KV對時，還需按表的標記位對這些鍵值對進行排序，以優化連接操作；
- 最後，在Reduce階段，對同一臺Reduce機器上的鍵值對，根據“值”（value）中的表標記位，對來自表User和Order的數據進行笛卡爾積連接操作，以生成最終的結果。比如鍵值對(1,<1,Lily>)與鍵值對(1,<2,101>)、(1,<2,102>)的連接結果是(Lily,101)、(Lily,102)。
3.1.2 用MR實現分組操作
假設分數表Score(rank, level)，具有rank（排名）和level（級別）兩個屬性，需要進行一個分組（Group By）操作，功能是把表Score的不同片段按照rank和level的組合值進行合併，並計算不同的組合值有幾條記錄。SQL語句命令如下：
SELECT rank,level,count(*) as value FROM score GROUP BY rank,level;
上圖描述分組操作轉化爲MapReduce任務的具體執行過程。
- 首先，在Map階段，對錶Score進行Map操作，生成一系列KV對，其鍵爲<rank, level>，值爲“擁有該<rank, level>組合值的記錄的條數”。比如，Score表的第一片段中有兩條記錄(A,1)，所以進行Map操作後，轉化爲鍵值對(<A,1>,2);
- 接着在Shuffle階段，對Score表生成的鍵值對，按照“鍵”的值進行Hash，然後根據Hash結果傳送給對應的Reduce機器去執行。比如，鍵值對(<A,1>,2)、(<A,1>,1)傳送到同一臺Reduce機器上，鍵值對(<B,2>,1)傳送另一Reduce機器上。然後，Reduce機器對接收到的這些鍵值對，按“鍵”的值進行排序；
- 在Reduce階段，把具有相同鍵的所有鍵值對的“值”進行累加，生成分組的最終結果。比如，在同一臺Reduce機器上的鍵值對(<A,1>,2)和(<A,1>,1)Reduce操作後的輸出結果爲(A,1,3)。
3.2 Hive中SQL查詢轉換成MR作業的過程
當Hive接收到一條HQL語句後，需要與Hadoop交互工作來完成該操作。HQL首先進入驅動模塊，由驅動模塊中的編譯器解析編譯，並由優化器對該操作進行優化計算，然後交給執行器去執行。執行器通常啓動一個或多個MR任務，有時也不啓動（如SELECT * FROM tb1，全表掃描，不存在投影和選擇操作）
上圖是Hive把HQL語句轉化成MR任務進行執行的詳細過程。
- 由驅動模塊中的編譯器–Antlr語言識別工具，對用戶輸入的SQL語句進行詞法和語法解析，將HQL語句轉換成抽象語法樹（AST Tree）的形式；
- 遍歷抽象語法樹，轉化成QueryBlock查詢單元。因爲AST結構複雜，不方便直接翻譯成MR算法程序。其中QueryBlock是一條最基本的SQL語法組成單元，包括輸入源、計算過程、和輸入三個部分；
- 遍歷QueryBlock，生成OperatorTree（操作樹），OperatorTree由很多邏輯操作符組成，如TableScanOperator、SelectOperator、FilterOperator、JoinOperator、GroupByOperator和ReduceSinkOperator等。這些邏輯操作符可在Map、Reduce階段完成某一特定操作；
- Hive驅動模塊中的邏輯優化器對OperatorTree進行優化，變換OperatorTree的形式，合併多餘的操作符，減少MR任務數、以及Shuffle階段的數據量；
- 遍歷優化後的OperatorTree，根據OperatorTree中的邏輯操作符生成需要執行的MR任務；
- 啓動Hive驅動模塊中的物理優化器，對生成的MR任務進行優化，生成最終的MR任務執行計劃；
- 最後，有Hive驅動模塊中的執行器，對最終的MR任務執行輸出。
Hive驅動模塊中的執行器執行最終的MR任務時，Hive本身不會生成MR算法程序。它通過一個表示“Job執行計劃”的XML文件，來驅動內置的、原生的Mapper和Reducer模塊。Hive通過和JobTracker通信來初始化MR任務，而不需直接部署在JobTracker所在管理節點上執行。通常在大型集羣中，會有專門的網關機來部署Hive工具，這些網關機的作用主要是遠程操作和管理節點上的JobTracker通信來執行任務。Hive要處理的數據文件常存儲在HDFS上，HDFS由名稱節點（NameNode）來管理。
四、Hive HA基本原理
在實際應用中，Hive也暴露出不穩定的問題，在極少數情況下，會出現端口不響應或進程丟失問題。Hive HA（High Availablity）可以解決這類問題。
在Hive HA中，在Hadoop集羣上構建的數據倉庫是由多個Hive實例進行管理的，這些Hive實例被納入到一個資源池中，由HAProxy提供統一的對外接口。客戶端的查詢請求，首先訪問HAProxy，由HAProxy對訪問請求進行轉發。HAProxy收到請求後，會輪詢資源池中可用的Hive實例，執行邏輯可用性測試。
如果某個Hive實例邏輯可用，就會把客戶端的訪問請求轉發到Hive實例上；
如果某個實例不可用，就把它放入黑名單，並繼續從資源池中取出下一個Hive實例進行邏輯可用性測試。
對於黑名單中的Hive，Hive HA會每隔一段時間進行統一處理，首先嚐試重啓該Hive實例，如果重啓成功，就再次把它放入資源池中。
由於HAProxy提供統一的對外訪問接口，因此，對於程序開發人員來說，可把它看成一臺超強“Hive”。
五、Impala
5.1 Impala簡介
Impala由Cloudera公司開發，提供SQL語義，可查詢存儲在Hadoop和HBase上的PB級海量數據。Hive也提供SQL語義，但底層執行任務仍藉助於MR，實時性不好，查詢延遲較高。
Impala作爲新一代開源大數據分析引擎，最初參照Dremel（由Google開發的交互式數據分析系統），支持實時計算，提供與Hive類似的功能，在性能上高出Hive3~30倍。Impala可能會超過Hive的使用率能成爲Hadoop上最流行的實時計算平臺。Impala採用與商用並行關係數據庫類似的分佈式查詢引擎，可直接從HDFS、HBase中用SQL語句查詢數據，不需把SQL語句轉換成MR任務，降低延遲，可很好地滿足實時查詢需求。
Impala不能替換Hive，可提供一個統一的平臺用於實時查詢。Impala的運行依賴於Hive的元數據（Metastore）。Impala和Hive採用相同的SQL語法、ODBC驅動程序和用戶接口，可統一部署Hive和Impala等分析工具，同時支持批處理和實時查詢。
5.2 Impala系統架構
上圖是Impala系統結構圖，虛線模塊數據Impala組件。Impala和Hive、HDFS、HBase統一部署在Hadoop平臺上。Impala由Impalad、State Store和CLI三部分組成。
- Implalad：是Impala的一個進程，負責協調客戶端提供的查詢執行，給其他Impalad分配任務，以及收集其他Impalad的執行結果進行彙總。Impalad也會執行其他Impalad給其分配的任務，主要是對本地HDFS和HBase裏的部分數據進行操作。Impalad進程主要含Query Planner、Query Coordinator和Query Exec Engine三個模塊，與HDFS的數據節點（HDFS DataNode）運行在同一節點上，且完全分佈運行在MPP（大規模並行處理系統）架構上。
- State Store：收集分佈在集羣上各個Impalad進程的資源信息，用於查詢的調度，它會創建一個statestored進程，來跟蹤集羣中的Impalad的健康狀態及位置信息。statestored進程通過創建多個線程來處理Impalad的註冊訂閱以及與多個Impalad保持心跳連接，此外，各Impalad都會緩存一份State Store中的信息。當State Store離線後，Impalad一旦發現State Store處於離線狀態時，就會進入恢復模式，並進行返回註冊。當State Store重新加入集羣后，自動恢復正常，更新緩存數據。
- CLI：CLI給用戶提供了執行查詢的命令行工具。Impala還提供了Hue、JDBC及ODBC使用接口。
5.3 Impala查詢執行過程
- 註冊和訂閱。當用戶提交查詢前，Impala先創建一個Impalad進程來負責協調客戶端提交的查詢，該進程會向State Store提交註冊訂閱信息，State Store會創建一個statestored進程，statestored進程通過創建多個線程來處理Impalad的註冊訂閱信息。
- 提交查詢。通過CLI提交一個查詢到Impalad進程，Impalad的Query Planner對SQL語句解析，生成解析樹；Planner將解析樹變成若干PlanFragment，發送到Query Coordinator。其中PlanFragment由PlanNode組成，能被分發到單獨的節點上執行，每個PlanNode表示一個關係操作和對其執行優化需要的信息。
- 獲取元數據與數據地址。Query Coordinator從MySQL元數據庫中獲取元數據（即查詢需要用到哪些數據），從HDFS的名稱節點中獲取數據地址（即數據被保存到哪個數據節點上），從而得到存儲這個查詢相關數據的所有數據節點。
- 分發查詢任務。Query Coordinator初始化相應的Impalad上的任務，即把查詢任務分配給所有存儲這個查詢相關數據的數據節點。
- 匯聚結果。Query Executor通過流式交換中間輸出，並由Query Coordinator匯聚來自各個Impalad的結果。
- 返回結果。Query Coordinator把彙總後的結果返回給CLI客戶端。
5.4 Impala與Hive
不同點：
Hive適合長時間批處理查詢分析；而Impala適合進行交互式SQL查詢。
Hive依賴於MR計算框架，執行計劃組合成管道型MR任務模型進行執行；而Impala則把執行計劃表現爲一棵完整的執行計劃樹，可更自然地分發執行計劃到各個Impalad執行查詢。
Hive在執行過程中，若內存放不下所有數據，則會使用外存，以保證查詢能夠順利執行完成；而Impala在遇到內存放不下數據時，不會利用外存，所以Impala處理查詢時會受到一定的限制。
相同點：
使用相同的存儲數據池，都支持把數據存儲在HDFS和HBase中，其中HDFS支持存儲TEXT、RCFILE、PARQUET、AVRO、ETC等格式的數據，HBase存儲表中記錄。
使用相同的元數據。
對SQL的解析處理比較類似，都是通過詞法分析生成執行計劃。