1.數據倉庫

1.1數據倉庫的概念

數據倉庫（Data Warehouse）是一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合，用于支持管理決策。

1. 面向主題。操作型數據庫的數據組織面向事務處理任務，而數據倉庫中的數據按照一定的主題域進行組織。主題是指用戶使用數據倉庫進行決策時所關心的重點，一個主題通常與多個操作型信息系統相關。

2. 集成。數據倉庫的數據來自分散的操作型數據，將所需數據從原來的數據中抽取出來，進行加工與集成、統一與綜合之后才能進入數據倉庫。

3. 相對穩定。數據倉庫一般是不可更新的。數據倉庫主要為決策分析提供數據，所涉及的操作主要是數據的查詢。

4. 反映歷史變化。在構建數據倉庫時，會每隔一定的時間（比如每周、每天或每小時）從數據源抽取數據并加載到數據倉庫。

1.2數據倉庫的結構

一個典型的數據倉庫系統通常包含數據源、數據存儲和管理、OLAP（Online Analytical Processing）服務器、前端工具和應用等4個部分。

1.3數據倉庫和數據庫之間的區別

特性	數據庫	數據倉庫
擅長做什么	事務處理	分析、報告、大數據
數據從哪里來	從單個來源“捕獲”	從多個來源抽取和標準化
數據標準化	高度標準化的靜態Schema	非標準化Schema
數據如何寫	針對連續寫入操作進行優化	按批處理計劃進行批量寫入操作
數據怎么存	針對單行型物理塊的高吞吐寫操作進行了優化	使用列式存儲進行了優化，便于實現高速查詢和低開銷訪問
數據怎么讀	大量小型讀取操作	為最小化I/O且最大化吞吐而優化

2.數據湖

企業在持續發展，企業的數據也不斷堆積，雖然“含金量”最高的數據都存在數據庫和數據倉庫里，支撐著企業的運轉。但是，企業希望把生產經營中的所有相關數據，歷史的、實時的，在線的、離線的，內部的、外部的，結構化的、非結構化的，都能完整保存下來，方便“沙中淘金”。數據庫和數據倉庫都不具備這個功能，怎么辦呢？

2.1 數據湖的概念

數據湖是一類存儲數據自然、原始格式的系統或存儲，通常是對象塊或者文件。

數據湖通常是企業中全量數據的單一存儲。全量數據包括原始系統所產生的原始數據拷貝以及為了各類任務而產生的轉換數據，各類任務包括報表、可視化、高級分析和機器學習等。

數據湖的本質，是由“數據存儲架構+數據處理工具”組成的解決方案，而不是某個單一獨立產品。

數據處理工具則分為兩大類。

分類	關鍵信息	具體描述	工具示例
第一類數據處理工具	解決數據 “搬到” 湖里的問題	定義數據源、制定數據訪問和安全策略、移動數據、編制數據目錄等，保障數據質量，避免數據湖變成 “數據沼澤”	Amazon Web Services 的 “Lake Formation”，搭配 Amazon Glue 進行 ETL、編制數據目錄，提高數據質量
第二類數據處理工具	從海量數據中 “淘金”	對數據進行分析、挖掘、利用，提供給機器學習、數據科學類業務，進行離線分析、實時分析、交互式分析、機器學習等多種數據分析	無（未提及具體工具）

2.2 數據湖與數據倉庫的區別

特性	數據倉庫	數據湖
存放什么數據	結構化數據，抽取自事務系統、運營數據庫和業務應用系統	所有類型的數據，結構化、半結構化和非結構化
數據模式（Schema）	通常在數倉實施之前設計，但也可以在數據分析時編寫	在分析時編寫
性價比	起步成本高，使用本地存儲以獲得最快查詢結果	起步成本低，計算存儲分離
數據質量如何	可作為重要事實依據的數據	包含原始數據在內的任何數據
最適合誰用	業務分析師為主	數據科學家、數據開發人員為主
具體能做什么	批處理報告、BI、可視化分析	機器學習、探索性分析、數據發現、流處理、大數據與特征分析

2.3數據湖能解決的企業問題

在企業實際應用中，數據湖能解決的問題包括以下幾個方面：

1. 數據分散，存儲散亂，形成數據孤島，無法聯合數據發現更多價值。
2. 存儲成本問題。
3. SQL無法滿足的分析需求。
4. 存儲、計算擴展性不足。
5. 業務模型不定，無法預先建模

3.湖倉一體

因為數倉和數據庫的出發點不同、架構不同，企業在實際使用過程中，“性價比”差異很大。

湖倉一體是一種新型的開放式架構，打通了數據倉庫和數據湖，將數據倉庫的高性能及管理能力與數據湖的靈活性融合了起來，底層支持多種數據類型并存，能實現數據間的相互共享，上層可以通過統一封裝的接口進行訪問，可同時支持實時查詢和分析，為企業進行數據治理帶來了更多的便利性。

“湖倉一體”架構最重要的一點，是實現“湖里”和“倉里”的數據/元數據能夠無縫打通，并且“自由”流動。湖里的“新鮮”數據可以流到倉里，甚至可以直接被數據倉庫使用，而倉里的“不新鮮”數據，也可以流到湖里，低成本長久保存，供未來的數據挖掘使用。

“湖倉一體”架構具有以下特性：

特性	描述
事務支持	為業務系統提供并發的讀取和寫入，對事務的 ACID 支持，確保數據并發訪問的一致性、正確性（在 SQL 訪問模式下）
數據治理	支持各類數據模型的實現和轉變，如星型模型、雪花模型等，保證數據完整性，具備健全的治理和審計機制
BI 支持	支持直接在源數據上使用 BI 工具，加快分析效率，降低數據延時，相比在數據湖和數據倉庫分別操作兩個副本更具成本優勢
存算分離	使系統能夠擴展到更大規模的并發能力和數據容量
開放性	采用開放、標準化的存儲格式（如 Parquet 等），提供豐富的 API 支持，可讓各種工具和引擎（包括機器學習和 Python、R 等）高效地直接訪問數據

4.Hive概述

4.1 傳統數據倉庫面臨的挑戰

隨著大數據時代的全面到來，傳統數據倉庫面臨著巨大的挑戰，主要包括以下幾個方面。

1. **無法滿足快速增長的海量數據存儲需求。**目前企業數據增長速度非常快，動輒幾十TB的數據，已經大大超出了Oracle/DB2等傳統數據倉庫的處理能力。這是因為傳統數據倉庫大都基于關系數據庫，關系數據庫橫向擴展性較差，縱向擴展性有限。

2. **無法有效處理不同類型的數據。**傳統數據倉庫通常只能存儲和處理結構化數據，但是，隨著企業業務的發展，企業中部署的系統越來越多，數據源的數據格式越來越豐富，很顯然，傳統數據倉庫無法處理如此眾多的數據類型。

3. **計算和處理能力不足。**由于傳統數據倉庫建立在關系數據庫基礎之上，因此，會存在一個很大的痛點，即計算和處理能力不足，當數據量達到TB量級后，傳統數據倉庫基本無法獲得好的性能。

4.2 Hive簡介

Hive是一個構建于Hadoop頂層的數據倉庫工具

• 某種程度上可以看作是用戶編程接口，本身不存儲和處理數據

• 依賴分布式文件系統HDFS存儲數據

• 依賴分布式并行計算模型MapReduce處理數據

• 定義了簡單的類SQL 查詢語言——HiveQL

• 用戶可以通過編寫的HiveQL語句運行MapReduce任務

• 是一個可以提供有效、合理、直觀組織和使用數據的模型

Hive具有的特點非常適用于數據倉庫:

特點	功能
采用批處理方式處理海量數據	Hive需要把HiveQL語句轉換成MapReduce任務進行運行；數據倉庫存儲的是靜態數據，對靜態數據的分析適合采用批處理方式，不需要快速響應給出結果，而且數據本身也不會頻繁變化。
提供適合數據倉庫操作的工具	Hive本身提供了一系列對數據進行提取轉化加載的工具，可以存儲、查詢和分析存儲在Hadoop中的大規模數據；非常適合數據倉庫應用程序維護海量數據、對數據進行挖掘、形成意見和報告等。

4.3 Hive與Hadoop生態系統中其他組件的關系

工具	依賴關系或特點	具體描述
Hive	依賴于 HDFS 存儲數據	HDFS 是高可靠性的底層存儲，用于存儲海量數據
Hive	依賴于 MapReduce 處理數據	MapReduce 對海量數據進行處理，實現高性能計算，HiveQL 語句編寫的處理邏輯會轉化為 MapReduce 任務運行
Pig	作為 Hive 的替代工具	是一種數據流語言和運行環境，適合在 Hadoop 和 MapReduce 平臺上查詢半結構化數據集，常用于 ETL 過程，將外部數據裝載到 Hadoop 集群并轉換為期望的數據格式
HBase	提供數據的實時訪問	一個面向列的、分布式的、可伸縮的數據庫，功能與 Hive 互補，Hive 主要處理靜態數據（如 BI 報表數據）

4.4 Hive與傳統數據庫的對比分析

Hive在很多方面和傳統的關系數據庫類似，但是它的底層依賴的是HDFS和MapReduce，所以在很多方面又有別于傳統數據庫。

對比項目	Hive	傳統數據庫
數據插入	支持批量導入	支持單條和批量導入
數據更新	不支持	支持
索引	支持	支持
分區	支持	支持
執行延遲	高	低
擴展性	好	有限

5.Hive系統架構

Hive主要由以下3個模塊組成，用戶接口模塊、驅動模塊以及元數據存儲模塊：

模塊	詳情
用戶接口模塊	包括 CLI、Hive 網頁接口（Hive Web Interface，HWI）、JDBC、ODBC、Thrift Server 等，用于實現外部應用對 Hive 的訪問。 CLI 是 Hive 自帶命令行客戶端工具，Hive 3.0 以上版本中 Beeline 取代了 CLI。 HWI 是 Hive 的簡單網頁。 JDBC、ODBC 和 Thrift Server 提供編程訪問接口，Thrift Server 基于 Thrift 軟件框架開發，提供 Hive 的 RPC 通信接口。
驅動模塊（Driver）	包括編譯器、優化器、執行器等，執行引擎可以是 MapReduce、Tez 或 Spark 等。 當采用 MapReduce 作為執行引擎時，負責把 HiveQL 語句轉換成一系列 MapReduce 作業，對輸入進行解析編譯、優化計算過程并按步驟執行。
元數據存儲模塊（Metastore）	是一個獨立的關系數據庫，通常與 MySQL 數據庫連接創建 MySQL 實例，也可是 Hive 自帶的 derby 數據庫實例。 主要保存表模式和其他系統元數據，如表的名稱、表的列及其屬性、表的分區及其屬性、表的屬性、表中數據所在位置信息等。

6.Hive工作原理

6.1 SQL語句轉換成MapReduce作業的基本原理

1.用MapReduce實現連接操作

? Map階段

在Map階段，表 user 中記錄 (uid, name) 映射為鍵值對 (uid, <1, name>)，表 order 中記錄 (uid, orderid) 映射為鍵值對 (uid, <2, orderid >)，其中 1,2 是表 user 和 order 的標記位。

例如：

• (1, Lily) 映射為 (1, <1, Lily>)
• (1, 101) 映射為 (1, <2, 101>)

? Shuffle、Sort階段

在Shuffle、Sort階段，(uid, <1, name>) 和 (uid, <2, orderid >) 按鍵 uid 的值進行哈希，然后傳送給對應的Reduce機器執行，并在該機器上按表的標記位對這些鍵值對進行排序。

例如：

• (1, <1, Lily>)、(1, <2, 101>) 和 (1, <2, 102>) 傳送到同一臺Reduce機器上，并按該順序排序
• (2, <1, Tom>) 和 (2, <2, 103>) 傳送到同一臺Reduce機器上，并按該順序排序

? Reduce階段

在Reduce階段，對同一臺Reduce機器上的鍵值對，根據表標記位對來自不同表的數據進行笛卡爾積連接操作，以生成最終的連接結果。

例如：

• (1, <1, Lily>) ∞ (1, <2, 101>) 得到 (Lily, 101)
• (1, <1, Lily>) ∞ (1, <2, 102>) 得到 (Lily, 102)
• (2, <1, Tom>) ∞ (2, <2, 103>) 得到 (Tom, 103)

2.用MapReduce實現分組操作

? Map階段

在Map階段，表 score 中記錄 (rank, level) 映射為鍵值對 (<rank, level>, count(rank, level))。

• 對于 score 表的第一片段，有兩條記錄 (A, 1)，映射后為 (<A, 1>, 2)。

• 對于 score 表的第二片段，有一條記錄 (A, 1)，映射后為 (<A, 1>, 1)。

? Shuffle、Sort階段

在Shuffle、Sort階段，鍵值對 (<rank, level>, count(rank, level)) 按鍵 (<rank, level>) 的值進行哈希，然后傳送給對應的Reduce機器執行，并在該機器上按 (<rank, level>) 的值對這些鍵值對進行排序。

• (<A, 1>, 2) 和 (<A, 1>, 1) 傳送到同一臺Reduce機器上，按到達順序排序。
• (<B, 2>, 1) 傳送到另一臺Reduce機器上。

? Reduce階段

在Reduce階段，對Reduce機器上的這些鍵值對，把具有相同 (<rank, level>) 鍵的所有 count(rank, level) 值進行累加，生成最終結果。

• (<A, 1>, 2) 和 (<A, 1>, 1) 累加后得到 (A, 1, 3)。
• (<B, 2>, 1) 最終結果為 (B, 2, 1)。

9.6.2 SQL查詢轉換成MapReduce作業的過程

當用戶向Hive輸入一段命令或查詢時，Hive需要與Hadoop交互工作來完成該操作。

? 首先，驅動模塊接收該命令或查詢編譯器。

? 接著，對該命令或查詢進行解析編譯。

? 然后，由優化器對該命令或查詢進行優化計算。最后該命令或查詢通過執行器進行執行。

執行器通常的任務是啟動一個或多個MapReduce任務，有時也不需要啟動MapReduce任務，像執行包含*的操作（如select * from 表）時。

7.Hive HA工作原理

在Hive HA中，在Hadoop集群上構建的數據倉庫是由多個Hive實例進行管理的，這些Hive實例被納入一個資源池中，并由HAProxy提供一個統一的對外接口。客戶端的查詢請求首先訪問HAProxy，由HAProxy對訪問請求進行轉發。HAProxy收到請求后，會輪詢資源池里可用的Hive實例，執行邏輯可用性測試。

8.Impala

8.1 Impala簡介

Impala是由Cloudera公司開發的新型查詢系統，它提供SQL語義，能查詢存儲在Hadoop的HDFS和HBase上的PB級大數據。Impala最開始是參照 Dremel系統進行設計的，Impala的目的不在于替換現有的MapReduce工具，而是提供一個統一的平臺用于實時查詢。

Impala與其他組件的關系:

比較項	Hive	Impala
數據交互	可與 HDFS 和 HBase 交互	可與 HDFS 和 HBase 交互
執行引擎與任務類型	采用 MapReduce 作為執行引擎，主要用于處理長時間運行的批處理任務，如批量提取、轉化、加載類型的任務	通過類似商用并行關系數據庫的分布式查詢引擎，大大降低延遲，主要用于實時查詢
SQL 語法等	和 Impala 采用相同的 SQL 語法、ODBC 驅動程序和用戶接口	和 Hive 采用相同的 SQL 語法、ODBC 驅動程序和用戶接口

8.2 Impala系統架構

組成部分	描述	具體模塊及特點
Impalad	是 Impala 的進程，負責協調客戶端提交查詢的執行、給其他 Impalad 分配任務、匯總其他 Impalad 的執行結果，還能執行其他 Impalad 分配的任務，對本地 HDFS 和 HBase 里的部分數據進行操作	包含 Query Planner、Query Coordinator 和 Query Exec Engine 3 個模塊；與 HDFS 的數據節點（HDFS DN）運行在同一節點上，基于 MPP 架構完全分布式運行
State Store	負責收集集群中各個 Impalad 進程的資源信息用于查詢調度，跟蹤 Impalad 的健康狀態及位置信息	創建 statestored 進程，通過多個線程處理 Impalad 的注冊訂閱并保持心跳連接；各 Impalad 緩存 State Store 信息，State Store 離線時 Impalad 進入恢復模式并反復注冊，State Store 重新加入集群后自動恢復正常并更新緩存數據
CLI	給用戶提供執行查詢的命令行工具	同時提供 Hue、JDBC 及 ODBC 使用接口

8.3 Impala查詢執行過程

步驟	具體內容	詳細描述
第 1 步：注冊和訂閱	Impalad 進程向 State Store 提交注冊訂閱信息，State Store 的 statestored 進程處理注冊訂閱	當用戶提交查詢前，創建 Impalad 進程負責協調客戶端查詢；State Store 創建 statestored 進程，通過多個線程處理 Impalad 的注冊訂閱信息
第 2 步：提交查詢	Impalad 的 Query Planner 解析 SQL 語句生成解析樹，再變成 PlanFragment 發送到 Query Coordinator	用戶通過 CLI 客戶端提交查詢到 Impalad 進程；Query Planner 進行解析工作，PlanFragment 由 PlanNode 組成，可分發到單獨節點執行，每個 PlanNode 表示一個關系操作及執行優化所需信息
第 3 步：獲取元數據與數據地址	Query Coordinator 從 MySQL 元數據庫獲取元數據，從 HDFS 名稱節點獲取數據地址，得到相關數據所在的數據節點	Query Coordinator 分別從不同位置獲取元數據和數據地址信息，確定存儲查詢相關數據的所有數據節點
第 4 步：分發查詢任務	Query Coordinator 初始化相應 Impalad 上的任務，將查詢任務分配給存儲查詢相關數據的數據節點	Query Coordinator 針對存儲有查詢相關數據的各個數據節點，在對應的 Impalad 上初始化并分配查詢任務
第 5 步：匯聚結果	Query Executor 通過流式交換中間輸出，Query Coordinator 匯聚來自各個 Impalad 的結果	Query Executor 以流式方式處理中間輸出數據，Query Coordinator 將各個 Impalad 產生的結果進行匯總
第 6 步：返回結果	Query Coordinator 把匯總后的結果返回給 CLI 客戶端	Query Coordinator 將最終匯總的結果反饋給最初提交查詢的 CLI 客戶端

8.4 Impala與Hive的比較

1.Hive 與 Impala 的不同點

比較維度	Hive	Impala
查詢特點	架構基于 Hadoop，采用批處理方式，作業提交和調度開銷大，不適合大規模數據集的低延遲快速查詢，適合長時間批處理查詢分析	適合實時交互式 SQL 查詢
執行模式	以 MapReduce 為執行引擎，依賴 MapReduce 計算框架，執行計劃是管道型的 MapReduce 任務模式	執行計劃呈現為完整的執行計劃樹，能自然地將執行計劃分發到各個 Impalad 執行查詢
數據處理能力	執行時若內存無法容納所有數據，會借助外存確保查詢按順序執行完成	內存無法容納數據時不使用外存，更適合處理輸出數據量較小的查詢請求，對于大數據量的批量處理，Hive 更具優勢

2.Hive 與 Impala 的相同點

比較維度	詳情
數據存儲	使用相同的存儲數據池，均支持將數據存儲于 HDFS（支持 TEXT、RCFILE、PARQUET、AVRO、ETC 等格式的數據）和 HBase（存儲表中記錄）
元數據	使用相同的元數據
SQL 處理	對 SQL 的解釋處理方式相似，都通過詞法分析生成執行計劃