Chapter6 数据仓库Hive
6.1數據倉庫概念
6.1.1什么是數據倉庫
數據倉庫：數據倉庫是一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合，用于支持管理決策。
數據倉庫的目的：支持企業內部的商業分析和決策，讓企業可以基于數據倉庫的分析結果作出相關的經營決策。
數據倉庫的典型體系結構：
數據倉庫的數據都來自數據源，數據源中的數據需要經過抽取、轉換、加載（ETL過程），再進入數據倉庫。接著可以通過OLAP服務器和數據挖掘引擎，對上層應用提供服務，從而提供各種類型的服務。
數據倉庫是相對穩定的，倉庫中的數據不會頻繁變化甚至根本不會變化。大部分情況下，數據源中的數據經過ETL過程進入數據倉庫后就不會再發生變更，基本保留了歷史上所有時刻的狀態（大量歷史數據可以被用于多維數據OLAP分析，找出企業經營管理規律）。但傳統數據庫只能存儲在某個時刻的狀態，原來的歷史信息不保留。
傳統數據倉庫面臨的挑戰：
1.無法滿足快速增長的海量數據存儲需求。
2.無法有效處理不同類型的數據。
基于傳統數據庫構建，只能存儲結構化數據。
3.計算和處理能力不足。
沒有辦法橫向擴展，縱向擴展的能力也是有限的。
6.2Hive簡介
6.2.1概述
Hive是一個構建于Hadoop頂層的數據倉庫工具，支持大規模數據存儲分析。由于Hadoop是大數據處理架構、分布式處理架構，具有非常好的水平可擴展性，所以構建在其上的Hive也有很好的水平可擴展性。
雖然Hive是數據倉庫工具，但是它和傳統的數據倉庫是有區別的。
傳統的數據倉庫即是數據存儲產品也是數據分析處理產品，能同時支持數據的存儲和處理分析。然而，Hive本身并不支持數據存儲和處理，應該將它看作一個面向用戶的接口，相當于給用戶提供了一種編程語言。讓用戶可以用類似SQL的編程語言去編寫分析需求。
Hive架構在底層的Hadoop核心組件之上，而Hadoop平臺有支持大規模數據存儲的組件HDFS、支持大規模數據處理的組件MapReduce。Hive正是借助于這兩個組件完成數據的存儲和處理。具體來說，Hive依賴分布式文件系統HDFS存儲數據、依賴分布式并行計算模型MapReduce處理分析數據。
Hive為用戶提供了一種非常簡單的查詢語言，和SQL非常類似（借鑒SQL語言），即新的查詢語言HiveQL。
用戶可以通過HiveQL這種語句，執行具體的MapReduce任務。
并且，Hive支持類似SQL的接口，很容易進行移植。可以很容易的把原來構建在關系數據庫上的數據倉庫應用程序移植到Hadoop平臺上。
因此，Hive是一個可以提供有效合理直觀組織和使用數據的分析工具。
Hive兩個方面的特性
1.采用批處理方式處理海量數據
Hive本身并不負責數據的處理分析，會把用戶提交的HiveQL語句轉換成一系列的MapReduce任務執行。而MapReduce是典型的面相批處理的框架。
數據倉庫存儲的是靜態數據，不會發生頻繁變化甚至根本不會變化。所以對靜態數據的分析適合采用批處理方式，不需要快速響應給出結果。數據倉庫的這種靜態特性很適合使用Hive。
2.Hive提供了一系列對數據進行提取、轉換，加載（ETL）的工具
可以存儲、查詢和分析存儲在Hadoop中的大規模數據，這些工具可以很好的滿足數據倉庫的各種應用場景。
6.2.2Hive和Hadoop生態系統中各組件關系
Hive建立在Hadoop平臺之上，依賴HDFS存儲數據，依賴MapReduce處理數據。
Pig是一種面向流式處理的語言，類似于SQL語句，可以通過編寫Pig Latin腳本語言以使用數據倉庫和數據分析的工作，無需編寫復雜代碼。在某種程度上，Pig和Hive提供的數據倉庫的功能是類似的，也是讓用戶輸入類似SQL的語句，也會把語句轉換為MapReduce任務運行。但是二者也存在區別，相對于Hive來說，Pig是一種輕量級分析工具，比較適合做實時性交互分析，不適合做大規模數據批處理。二者在發展過程中應用場景不同，Pig主要用于數據倉庫的ETL環節，而Hive主要用于數據倉庫海量數據的批處理分析。
在Hadoop生態系統中，HBase是一款支持實時性交互的數據庫產品，彌補了HDFS的缺陷（HDFS只允許追加不允許修改，不支持隨機讀寫），這種數據讀寫可以利用HBase實現。HBase和Hive是一種互補的關系，Hive的時延較高，因此如果需要實時性查詢，可以通過HBase實現。
6.2.3Hive和傳統數據庫對比
Hive在很多方面和傳統數據庫類似，但是Hive底層依賴的是Hadoop兩大核心組件（HDFS和MapReduce），因此在很多方面又有別于傳統數據庫。
Hive和傳統數據庫在不同項目中的對比表：
6.2.4Hive在企業中的部署和應用
Hive在企業大數據分析平臺中的應用：
Hive在Facebook公司的應用
Facebook是Hive數據倉庫的開發者，這是由于基于Oracle的數據倉庫已經無法滿足激增的業務需求，所以Facebook公司開發了數據倉庫工具Hive，并在企業內部進行了大量部署。
Web服務器每天會產生大量的日志流，通過訂閱（Scribe）服務器進行收集整理，存儲到網絡文件服務器（Filers）。Filers會將海量日志保存在分布式文件系統HDFS上。同時，Facebook內部的許多關系型數據庫集群，例如MYSQL，用于存儲維度數據；這些數據也要被導入Hadoop平臺，并存儲到HDFS中。各種數據都進入到HDFS之后，Hive就會為這些數據構建起一個數據倉庫，用戶即可進行各種操作，得到的分析結果可以導入MYSQL，也可以導入Oracle RAC。
6.2.5Hive系統架構
在系統架構中，包含三個非常核心的模塊：用戶接口模塊、驅動模塊（Driver）、元數據存儲模塊（Metastore）。
Hive對外訪問接口：
驅動模塊（Driver）：
包含編譯器、優化器、執行器。
負責把HiveQL語句轉換成一系列MapReduce作業。
元數據存儲模塊（Metastore）：
是一個獨立的關系型數據庫。
存儲數據倉庫的各種元數據，比如表、表中的列、列的名稱、分區信息。
通過MySQL數據庫存儲Hive元數據。
Karmasphere、Hue、Qubole也可以訪問Hive數據倉庫。
其中，Qubole直接作為一種服務提供給用戶，不需要在本地部署數據倉庫，直接提供亞馬遜的AWS云平臺即可遠程使用數據倉庫。整個數據倉庫集群管理都是亞馬遜完成。
6.2.6Hive HA基本原理
Hive HA：全稱為Hive High Availability，高可用性Hive解決方案。
在實際應用中，Hive會表現出很多不穩定性，比如端口調用沒有響應、進程丟失等。Hive HA就是對這種不穩定性的解決方案。
外部訪問先訪問HA Proxy，然后HA Proxy依次對底層的各個示例進行詢問示例是否可用，執行邏輯可用性測試，如果通過測試就將用戶請求轉發給這個可用的示例，否則將示例加入黑名單。每隔一定周期，HA Proxy會對列入黑名單的示例進行統一處理（進行重啟，重啟成功的重新放回資源池）。
6.3SQL語句轉為MapReduce作業
Hive本身不做具體的數據處理和存儲，而是把SQL語句轉換成相關的MapReduce作業。
6.3.1SQL語句轉為MapReduce作業的基本原理
連接：怎么能用MapReduce來實現數據庫的連接操作？
實例1. join的實現原理
user表和order表具有公共字段uid，因此兩表具有連接條件。
首先，需要用戶編寫一個Map處理邏輯，將關系數據庫的表輸入到Map處理邏輯中，對于輸入的每一行記錄通過Map進行轉換，生成一系列鍵值對。比如User表的第一行記錄經過Map處理后會輸出鍵值對，key為uid的值，value是一個二元組<1,Lily>，這個二元組中的1表示鍵值對所屬的表，是表User的標記位。同理，2是表Score的標記位。
通過Map函數，可以將輸入的User表和Order表都轉換成鍵值對，通過Shuffle的過程把這些鍵值對進行分區、排序，分別發送給不同的Reduce。在圖中假設，把所有key為1的鍵值對都分配給第一個Reduce任務，把所有key為2的鍵值對都分配給第二個Reduce任務。
鍵值對進行Reduce操作的前提是他們的key相等且來自不同表。
實例2. group by的實現原理
假設下圖中是來自Score表的兩個不同片段，現在想要進行group by操作，把表Score的不同片段按照rank和level的組合值進行合并，計算不同rank和level的組合值分別有幾條記錄，比如rank為A且level為1的記錄條數。該操作對應的SQL語句為：
若想用MapReduce實現，首先把表輸入到Map函數中做用戶邏輯的處理，處理后輸出鍵值對，鍵值對的key為rank和level的組合，value為計算出的這種組合的記錄條數。
經過Map函數映射后，得到鍵值對列表。接著對這些鍵值對進行Shuffle操作，進行分區、排序，然后分配給不同的Reduce任務處理。
6.3.2Hive中SQL查詢轉換成MapReduce作業的過程
當用戶向Hive輸入一段命令或查詢時，Hive需要與Hadoop交互來完成該操作：
1.驅動模塊接收該命令或查詢編譯器
2.對該命令或查詢進行解析編譯
3.由優化器對該命令或查詢進行優化計算
4.該命令或查詢通過執行器進行執行
具體過程可以分為如下七個步驟：
1.由Hive驅動模塊中的編譯器對用戶輸入的SQL語言進行詞法和語法解析，將SQL語句轉化成抽象語法樹的形式。
2.抽象語法樹的結構仍然很復雜，不方便直接翻譯為MapReduce算法程序，因此需要把抽象語法樹轉化為查詢塊。
3.把查詢塊轉換成邏輯查詢計劃，里面包含了許多邏輯操作符。
4.重寫邏輯操作計劃，進行優化合并多余操作，減少MapReduce任務數量。
5.將邏輯操作符轉換成需要執行的具體MapReduce任務。
6.對生成的MapReduce任務進行優化生成最終的MapReduce任務執行計劃。
7.由Hive驅動模塊中的執行器對最終的MapReduce任務進行執行輸出。
示意圖如下：
需要注意的是：
當啟動MapReduce程序時，Hive本身是不會生成MapReduce程序的。
需要通過一個表示"Job執行計劃"的XML文件驅動執行內置的、原生的Mapper和Reducer模塊。Hive本身并不生成MapReduce算法程序。
Hive通過和JobTracker通信來初始化MapReduce任務（JobTracker是MapReduce的管家），不必直接部署在JobTracker所在的管理節點上執行。
通常在大型集群上，會有專門的網關機來部署Hive工具。（網關機會和遠程節點上的JobTracker進行通信完成任務）
數據文件通常存儲在HDFS上，HDFS由名稱節點管理。
6.4Impala
6.4.1Impala簡介
Hive建立在Hadoop平臺上，它依賴底層的MapReduce和HDFS，所以延遲比較高。針對這個問題，設計了Impala，也用于做數據倉庫分析，但是性能比Hive高3~30倍。
有人認為，Impala未來會稱為最流行的實時性交互查詢工具。
Impala是由Cloudera公司開發的新型查詢系統，允許通過SQL語句查詢底層數據，可以查詢PB級別以上的大數據，能查詢存儲在Hadoop的HDFS中，或者HBase中的數據。
Impala的運行需要依賴于Hive的元數據。
Impala最初是參考Google的Dremel系統（專門做實時性交互查詢的）進行設計的。
與Hive不同的是，Hive要將SQL語句轉換為底層的一系列MapReduce任務執行，而Impala采用了與商用并行關系數據庫類似的分布式查詢引擎，可以直接與HDFS和HBase進行交互查詢，查詢實時性比Hive高。
如下圖所示，Impala和Hive都是構建在底層的HDFS和HBase之上的，Impala和Hive都不是自身存儲數據。并且，Impala和Hive采用相同的SQL語法、ODBC驅動程序和用戶接口。
6.4.2Impala系統架構
圖中虛線部分，表示屬于Impala系統組件。實線部分表示Impala并不是單獨部署的，和Hadoop平臺的其他組件部署在同一個集群上面。
Impala和Hive、HDFS、HBase等工具是統一部署在一個Hadoop平臺上的。
Impala的三大組件：
Impalad
負責具體的相關查詢任務。
包含著三個模塊：Query Planner（查詢計劃器）、Query Coordinator（查詢協調器）、Query Exec Engine（查詢執行引擎）。
負責協調客戶端提交的查詢的執行。
與HDFS的數據節點（HDFS DataNode）運行在同一節點上，以便就近處理數據。
給其他Impalad分配任務，以及收集其他Impalad的執行結果進行匯總。（大規模數據集分布存儲在不同的數據節點上，運行時要進行分布式查詢，每個子查詢查詢不同數據節點上的數據，這些子查詢由在不同數據節點上的Impalad執行，Impalad負責執行各自的子查詢。）
Impalad也會執行其他Impalad給其分配的任務（其他查詢發起后，也會有另外的Impalad作為管家，把分片分成多個子查詢給Impalad做），對本地HDFS和HBase里的部分數據進行操作。
State Store
負責元數據管理和狀態信息維護。
每個查詢提交后，系統會為其創建一個state store進程。由于不同節點上有多個Impalad進程，分別執行各自的任務，因此需要state store跟蹤執行情況、健康狀態信息等。
因此，state store要負責收集分布在集群中各個Impalad進程的資源信息用于查詢調度。
CLI
用戶訪問接口。
CLI是給用戶提供查詢使用的命令行工具，同時提供了Hue、JDBC、ODBC的使用接口。
說明：
Impala的元數據是直接存儲在Hive中的，它借助Hive來存儲Impala的元數據。
Impala采用與Hive相同的元數據、相同的SQL語法、相同的ODBC驅動程序和用戶接口，使得在一個Hadoop平臺上可以統一部署Hive和Impala等分析工具，實現在一個平臺什么可以同時滿足批處理和實時查詢。
6.4.3Impala查詢執行過程
Impala執行查詢的過程如下所示：
具體的查詢步驟為：
0.用戶的一個查詢提交之前，Impala先創建一個負責協調客戶端提交的查詢的Impalad進程。該進程會向Impala State Store提交注冊訂閱信息，State Store會創建一個statestored進程，statestored進程通過創建多個線程來處理Impalad的注冊訂閱信息。
1.用戶通過CLI客戶端提交一個查詢到Impalad進程，Impalad的Query Planner對SQL語句進行解析，生成解析樹，Planner把這個解析樹變成若干PlanFragment，發送到Query Coordinator（協調不同Impalad進行子查詢、收集結果等）。
2.Coordinator通過從MySQL元數據庫中獲取元數據，從HDFS的名稱節點中獲取數據地址，以得到存儲這個查詢相關數據的所有數據節點。
3.Coordinator初始化相應Impalad上的任務執行，即把查詢任務分配給所有存儲這個查詢相關數據的數據節點。
4.Query Executor通過流式交換中間輸出，并由Query Coordinator匯聚來自各個Impalad的結果。
5.Coordinator把匯總后的結果返回給CLI客戶端。
6.4.4Impala與Hive的比較
對比示意圖：
Impala與Hive的不同點：
Impala與Hive的相同點：
總結：
Impala的設計目的不在于替換現有的MapReduce工具。（為了彌補Hive實時性不高的缺陷）
把Hive與Impala配合使用效果最佳。
可以先使用Hive進行數據轉換處理，之后再使用Impala在Hive處理后的結果數據集上進行快速的數據分析。
總結
以上是生活随笔為你收集整理的Chapter6 数据仓库Hive的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 生源985占比100%，北大叉院这个专业
- 下一篇： 如何测试手机开机键 ？