HiveSQL的執行過程分析

首先，我們看一下hive的整個系統架構：

我們可以發現，hive主要由以下幾部分組成：

客戶端/ThriftServer/Driver/MetaStore四部分組成。

其中可用的客戶端包括：CLI（命令列介面）/JDBC或者ODBC客戶端/WEB介面介面，我們可以通過上面三種客戶端向hive提交我們的命令。

ThriftServer：Jdbc或者Odbc通過ThriftServer連線到Hive，而且Hive使用ThriftServer來連線到MetaStore來讀取hive的後設資料資訊。

MetaStore：Hive與Pig等系統的主要區別就是，在hive中提供了存放後設資料的MetaStore。Hive將表/分割槽/列等資訊存放在MetaStore中。Hive並沒有將MetaStore包存在HDFS上，而是將它儲存在了關聯式資料庫，比如MySql中。這麼做的主要目的就是，當Hive需要訪問MetaStore的時候，可以低延遲的快速的訪問到需要的後設資料資訊，而HDFS的訪問延遲一般都比較大。此外有一點需要注意的就是，分析HiveSQL之後生成的MapReduce任務在執行的時候如果需要訪問後設資料資訊時，它並不會直接去訪問MetaStore。那麼，他們是如何獲得需要的後設資料資訊的呢？？原來，當將生成的物理計劃序列化到plan.xml的時候，已經將相應的後設資料資訊儲存到了plan.xml中。而plan.xml檔案之後會被放入Hadoop的分散式快取中，所以MapReduce任務就可以從分散式快取中獲得需要的後設資料資訊。

Driver/QueryCompiler/ExecutionEngine:客戶端提交的HiveSQL首先進入Driver，然後Driver會為此次HiveSQL的執行建立一個Session，Driver維護整個session的生命週期。Driver首先將HiveSQL傳送給QueryCompiler，然後由QueryCompiler來對使用者提交的HiveSQL進行編譯/檢查/優化並最終生成MapReduce任務。

首先 QueryCompiler對HiveSQL進行Parse，Hive使用Antlr語法解析器來對HiveSQL進行解析，並生成相應的AST（抽象語法樹）。之後，進入到Typechecking and SemanticAnalysis（型別的檢查和語法）的分析階段，hive需要訪問MetaStore後設資料資訊來進行檢查操作

。在該階段首先將上一步生成的AST轉化成operatortree(DAG有向無環圖)，生成相應的邏輯計劃。然後Hive會根據一定的rule來對生成的operatortree的優化操作，在優化操作中會涉及到5個主要的物件，包括：Node,GraphWalker，Dispatcher，Rule，Processor。其中Node就代表DAG圖中的結點。整個優化的過程是：hive首先對GraphWalker和Dispatcher進行初始化，Dispatcher是GraphWalker的組成部分，而且Dispatcher中儲存了匹配某些rule需要的滿足條件以及rule與Processor的對應對映關係。然後hive通過GraphWalker對整個DAG進行遍歷，當訪問到某個Node的時候，通過Dispatcher對該Node進行rule判斷，檢視它是否滿足了某個rule的條件，如果滿足了rule的條件，然後再通過Dispatcher找到與該rule對應的Processor，最終通過Processor對該Node進行處理。整個流程圖如下：

當進行優化之後，會將DAG轉化稱相應的MapReduce任務。

生成的MapReduce任務會交給Hive的ExecutionEngine來執行，ExecutionEngine會與Hadoop進行互動，將MapReduce任務交給Hadoop來執行，並從Hadoop取得最終的執行結果，並返回給使用者。至此整個Hive的執行過程結束了。