基于Hive的高可用雙引擎數(shù)據倉庫①

李 翀,張彤彤,2,杜偉靜,2,劉學敏

1(中國科學院 計算機網絡信息中心,北京 100190)

2(中國科學院大學,北京 100190)

隨著大數(shù)據分析挖掘技術不斷發(fā)展,數(shù)據所蘊含的價值被不斷發(fā)掘,數(shù)據已成為各行各業(yè)社會團體最重要的資源之一.如何高效存儲這種來自不同系統(tǒng),具有不同格式的多源異構數(shù)據,怎樣將這些科研管理數(shù)據整合利用,打破信息孤島,進行數(shù)據挖掘,輔助決策分析,實現(xiàn)數(shù)據互通,支持在線流處理、離線批處理及OLAP、OLTP 不同場景的數(shù)據分析處理需求,優(yōu)化查詢效率,提供經濟高效分析計算平臺是當下研究熱點.

在數(shù)字化高速發(fā)展的信息時代,科研管理過程的實質是信息化管理的過程,是對科研信息資源進行收集、整理、統(tǒng)計、分析并加以利用的過程[1,2].科研管理信息系統(tǒng)廣泛應用于高校和科研院所,已積累形式多樣、相互隔離、分布廣泛,標準各異的海量數(shù)據,由于缺乏全局管理、治理維護、統(tǒng)一平臺,無法對科研成果科學評估及輔助決策制定提供有效支持.

本文以中國科學院科研管理態(tài)勢感知和競爭力分析為研究背景,依托中國科學院科研與教育態(tài)勢感知服務項目,以匯聚全院科研與教育投入、產出、成果、發(fā)展等結構化、半結構化和非結構化數(shù)據,構建可擴展高可用大數(shù)據倉庫、高效OLAP 查詢分析實際需求為切入點,聚焦科研管理大數(shù)據匯集、存儲、分析的需求,研究、設計和構建面向全院科研管理大數(shù)據的數(shù)據倉庫,為項目后續(xù)在線分析、數(shù)據挖掘、搭建知識圖譜、學科態(tài)勢和競爭力分析等需求提供平臺支持.

1 研究現(xiàn)狀和相關工作

數(shù)據倉庫(data warehouse) 是一個面向主題的(subject oriented)、集成的(integrated)、相對穩(wěn)定的(non-volatile)、反映歷史變化(time variant)的數(shù)據集合,是在現(xiàn)有數(shù)據庫的基礎上,對其中的數(shù)據再次進行抽取、加工和使用,并最終用于管理決策的集合,并不是簡單的數(shù)據復制或數(shù)據累加[3,4].數(shù)據倉庫當前主要的應用場景包括報表展示、實時查詢、BI (Business Intelligence)展示、數(shù)據分析、數(shù)據挖掘、模型訓練等方面.它提供了一種有效的訪問這些數(shù)據的方法,可以幫助科研機構快速而正確的做出決策.

傳統(tǒng)數(shù)據倉庫大都是基于Oracle、MySQL 這樣的關系型數(shù)據庫,擴展成本高,面對PB 級別的數(shù)據量以及各種關系數(shù)據庫、NoSQL 數(shù)據庫、XML 文件等數(shù)據源,其處理速度和處理效率不能夠滿足數(shù)據存儲、查詢以及融合多維度數(shù)據進行分析的需要[5].

廣義上來說,Hadoop 大數(shù)據平臺也可以看做是新一代的數(shù)據倉庫系統(tǒng),它具有很多現(xiàn)代數(shù)據倉庫的特征,且具有低成本、高性能、高容錯和可擴展等特性,被企業(yè)所廣泛使用.IBM 的研究人員將基于Hadoop 平臺的SQL 查詢系統(tǒng)分為兩大類：Database-Hadoop hybrids和Native Hadoop-based systems.第一類中只是使用了Hadoop 的調度和容錯機制,使用關系數(shù)據庫進行查詢[6].第二類則充分利用了Hadoop 平臺的可擴展性,主要分為3 個小類：1)基于MapReduce 的Hive；2) 基于內存計算框架Spark 的Spark SQL；3) 基于shared-nothing 架構的大規(guī)模并行處理(Massively Parallel Processing,MPP)引擎,如Impala.在文獻[7]和文獻[8]對比分析了最具代表性的Hive、Impala和Spark SQL 這3 種SQL-on-Hadoop 查詢引擎,實驗表明3 個查詢引擎均有各自的優(yōu)點,綜合來看,Hive 的查詢結果準確率更高,更為穩(wěn)定,但查詢時延較為嚴重,適合批處理；Impala 查詢速度最快,但系統(tǒng)穩(wěn)定性有待提高；Spark SQL 處理速度處于二者之間,更適合多并發(fā)和流處理場景.

基于Hadoop 的多種SQL 查詢引擎各有優(yōu)勢,但從穩(wěn)定性、易用性、兼容性和性能多個方面對比分析,目前并不存在各方面均最優(yōu)的SQL 引擎.考慮到項目離線批處理和在線流處理的需求,而目前較少有兼顧兩種需求的數(shù)據倉庫實施方案,結合當下較為成熟的開源技術方案,本文設計并實現(xiàn)了面向科研管理大數(shù)據的數(shù)據存儲系統(tǒng).

2 大數(shù)據倉庫設計

傳統(tǒng)數(shù)據倉庫大都只用到結構化數(shù)據處理技術,大數(shù)據倉庫不僅要處理關系數(shù)據庫中的結構化數(shù)據,還要處理海量半結構化和非結構化數(shù)據,并為大數(shù)據分析提供平臺,需要結合大數(shù)據技術設計和構建.以下分別以相關技術分析選型、集群高可用設計、系統(tǒng)設計闡述大數(shù)據倉庫設計思路.

2.1 技術選型

Hive 是基于Hadoop 的數(shù)據倉庫工具,可以提供類SQL 查詢功能,本質是將SQL 查詢轉換為MapReduce程序.MapReduce 框架主要適用于大批量的集群任務,批量執(zhí)行導致時效性偏低,并不適合在線數(shù)據處理的場景,一般用來做數(shù)據的離線處理.使用Hive 來做用來做離線數(shù)據分析,比直接用MapReduce 程序開發(fā)效率更高.因為大多數(shù)的數(shù)據倉庫應用程序是基于關系數(shù)據庫現(xiàn)實的,所以Hive 降低了將這些應用程序移植到Hadoop 上的障礙[9].

MapReduce 框架及其生態(tài)相對較為簡單,對計算機性能的要求也相對較弱,運行更穩(wěn)定,方便搭建及擴充集群,適合長期后臺運行.但其執(zhí)行速度慢,不適合實時性要求較高的查詢場景,在保證系統(tǒng)穩(wěn)定、減少運維難度的前提下,融合同樣基于Hadoop 平臺且系統(tǒng)相對穩(wěn)定的Spark 框架是更好的選擇,并且能為在線分析、數(shù)據挖掘等提供支持.

Spark 是借鑒了MapReduce 框架并在其基礎上發(fā)展起來的,繼承了其分布式計算的優(yōu)點并改進了MapReduce明顯的缺陷.Spark SQL 作為Spark 生態(tài)主要組件之一,與Hive 基于MapReduce 進行查詢類似,Spark SQL 使用Spark 作為計算引擎,在使用時需要處于Spark 環(huán)境.Spark SQL 幾乎完全兼容HiveQL 語法,只是Hive 特有的一些優(yōu)化參數(shù)及極少用語法不支持.

Hive on Spark 是由Cloudera 發(fā)起,由Intel、MapR等公司共同參與的開源項目.它把Spark 作為Hive 的一個計算引擎,將Hive 查詢作為Spark 任務提交到Spark 集群進行計算.Hive On Spark和Spark SQL 只是SQL 引擎不同,并無本質的區(qū)別,都是把SQL 查詢翻譯成分布式可執(zhí)行的Spark 程序.而Hive on Spark與Hive on MapReduce 一樣可以使用HiveQL 語法.如果要在數(shù)據倉庫中使用Spark 作為計算引擎,融入Hive on Spark 是更好的選擇.

綜上所述,Hive on Spark 與Hive on MapReduce 結合,可以高效切換計算引擎,同時提高資源利用率,降低運維成本.

2.2 高可用性

高可用性,即HA (High Availability),指的是通過盡量縮短因日常維護和突發(fā)系統(tǒng)崩潰導致的停機時間,以提高系統(tǒng)和應用的可用性.

分布式系統(tǒng)通常采用主從結構,即一個主節(jié)點,連接N個從節(jié)點.主節(jié)點負責分發(fā)任務,從節(jié)點負責執(zhí)行任務,當主節(jié)點發(fā)生故障時,整個集群都會失效,這種故障稱為單點故障.

HDFS 集群的不可用主要包括以下兩種情況：一是主節(jié)點主機宕機,導致集群不可用；二是計劃內的主節(jié)點軟件或硬件升級,導致集群在短時間內不可用.

在Hadoop2.0 之前,也有若干技術試圖解決單點故障的問題.如元數(shù)據備份、Secondary NameNode、Backup NameNode、Facebook AvatarNode 方案[10]等,還有若干解決方案,基本都是依賴外部的HA 機制,譬如DRBD[11],Linux HA,VMware 的FT 等等.但以上方案存在需要手動切換、恢復時間過長、需要引入另一個單點等問題.

為了解決上述問題,Hadoop 社區(qū)在Hadoop2.X 版本中給出了真正意義上的高可用HA 方案：Hadoop 集群由兩個NameNode 組成,一個處于Active 狀態(tài),另一個處于Standby 狀態(tài).Active NameNode 對外提供服務,而Standby NameNode 僅同步Active NameNode 的狀態(tài),以便能夠在它失敗時快速進行切換.其原理如圖1所示.集群通過ZooKeeper 進行心跳檢測,通過JournalNode 獨立進程進行相互通信,同步NameNode狀態(tài).

圖1 高可用原理

在生產環(huán)境中,必然要考慮到集群的高可用性,因此集群需要設置一個主節(jié)點備用節(jié)點,在主節(jié)點出現(xiàn)故障后能夠及時切換到備用節(jié)點,保證集群可用性.

2.3 系統(tǒng)設計

基于以上分析,本文采用基于Hive 的MapReduce+Spark 雙計算引擎混合架構進行大數(shù)據倉庫系統(tǒng)設計,滿足了項目對于數(shù)據倉庫高效、高可用和可擴展性的需求.為更好的管理Hadoop和Spark 兩個計算集群,提高集群資源的利用率及集群的計算效率,采用YARN (Yet Another Resource Negotiator)進行資源管理,保證了整個系統(tǒng)的穩(wěn)定性和可靠性,系統(tǒng)架構如圖2所示.

圖2 系統(tǒng)技術架構

系統(tǒng)將來自不同數(shù)據庫、互聯(lián)網、第三方的多源異構數(shù)據匯聚到HDFS 文件系統(tǒng),采用Hive 進行管理和索引,再通過上層計算引擎對數(shù)據進行查詢分析和計算.通過YARN 進行Hadoop 集群和Spark 集群的資源分配和管理,并通過ZooKeeper 實現(xiàn)系統(tǒng)中Hadoop、Spark、YARN 組件的高可用性,可按需擴展集群節(jié)點進行擴容.

依據計算需求不同,通過配置或簡單命令可以隨時切換Hive 計算引擎.在對實時性要求不高或對穩(wěn)定性要求較高的場景下使用MapReduce 引擎；對實時性有一定要求時使用Spark 引擎.兩種引擎均使用HiveQL對數(shù)據進行操作,無需切換開發(fā)環(huán)境,可以高效利用集群資源對數(shù)據進行抽取、轉換,為機器學習和圖計算提供數(shù)據源,系統(tǒng)還可以通過Spark Streaming 基于HDFS 對數(shù)據進行流處理,為實時流處理提供平臺.

3 實現(xiàn)與優(yōu)化

Hadoop和Spark 均依賴于Java,集群需要安裝JDK,同時使用MapReduce和Spark 作為數(shù)據倉庫的計算引擎,需要安裝配置Hive.

以Spark 作為計算引擎時,需要注意Hive 版本對Spark 版本的兼容性,具體對應版本在可以在下載Hive 源碼時查看pom.xml 文件中的spark.version,或者參考Hive 官網[12].默認Spark 預發(fā)布的版本中有Hive 的jar 包,要使用Hive on Spark 需要去掉這些Spark 訪問Hive 的jar 包,所以需要重新編譯Spark 源碼.不同的Spark 版本編譯命令有所區(qū)別,同樣參考Hive 官網.編譯Spark 源碼需要用到Maven,使用Spark 框架還需要用到Scala,Spark 從2.X 版本開始使用Scala 的2.11.X 版本.我們使用MySQL 數(shù)據庫存儲Hive 元數(shù)據.各資源版本如表1所示.

表1 各資源版本

3.1 集群部署架構

Hadoop 集群和Spark 集群搭建在5 臺虛擬機上,虛擬機具體配置信息見表2.集群設置有一個主節(jié)點,一個主節(jié)點備用節(jié)點,進行任務管理,三個從節(jié)點進行任務執(zhí)行,架構如圖3所示.

表2 服務器集群環(huán)境

圖3 集群架構

3.2 高可用性實現(xiàn)

集群使用YARN 進行資源管理,Spark 集群部署為yarn-cluster 模式,通過高性能協(xié)調服務Zoo-Keeper和ZKFC (ZK Failover Controller process)組件實現(xiàn)高可用,具體服務部署如表3所示.目前已實現(xiàn)Hadoop、YARN、Spark 主備節(jié)點故障切換.在主節(jié)點進程Namenode (Hadoop)、Resourcemanager (YARN)、Master(Spark)因異常退出后,備用節(jié)點能夠及時啟用,繼續(xù)管理集群.

3.3 Hive 負載均衡實現(xiàn)與優(yōu)化

使用Hive 數(shù)據倉庫有三種連接方式：

(1) Hive 的CLI 操作方式：bin/hive.

(2) Hive JDBC 服務：

nohup bin/hive --service hiveserver2 &

bin/beeline

!connect jdbc：hive2：//10.2.4.60：10000

(3) Hive 命令,bin/hive-e “HQL 語句”或者bin/hivef SQL 文件.

以上連接方式,CLI 或者Hive 命令的方式僅允許使用HiveQL 執(zhí)行查詢、更新等操作,并且比較笨拙單一.而HiveServer2(HS2)支持多客戶端的并發(fā)和認證,并且允許遠程客戶端使用多種編程語言如Java、Python向Hive 提交請求,取回結果,為開放API 客戶端如JDBC、ODBC 提供了更好的支持.HS2 使得客戶端可以在不啟動CLI 的情況下對Hive 中的數(shù)據進行操作,如可以使用beeline 連接HS2 執(zhí)行查詢.當集群中存在多個HS2 服務時,用戶可以自行選擇具體主機進行連接,但某臺服務器連接數(shù)過大時容易造成端口不響應,服務器故障也會造成無法查詢,使用HAProxy 可以最大程度避免這種情況.HAProxy 是一款提供高可用性、負載均衡,基于TCP和HTTP 應用的代理軟件,并且具有代理集群狀態(tài)監(jiān)控功能.HAProxy 通過配置前端(frontend)監(jiān)聽端口和后端(backend)服務端口進行請求轉發(fā),并提供多種負載均衡算法,適合不同場景下的負載均衡.當客戶端向前端綁定的端口發(fā)送請求時,HAProxy 根據指定的算法選擇可用的后端服務,并將請求轉發(fā).

將HAProxy 部署在服務器1 上,并將服務器3、4、5 作為Hive Server,運行HiveServer2 服務,工作原理如圖4所示.

表3 集群服務部署

圖4 負載均衡原理

HAProxy 核心配置如下所示：

bind 0.0.0.0：25005 #HAProxy 作為代理綁定的IP,端口

mode tcp #在第四層進行代理服務

balance leastconn #調度算法

maxconn 1024 #最大連接數(shù)

server hive_1 10.2.4.62：10000 check inter 180000 rise

1 fall 2

server hive_2 10.2.4.63：10000 check inter 180000 rise

1 fall 2

server hive_3 10.2.4.64：10000 check inter 180000 rise

1 fall 2

將服務器1 上的25005 作為前端端口,每當通過beeline 客戶端向服務器1 上的25005 端口發(fā)起請求時,HAProxy 通過leastconn 算法(最少連接數(shù)分配)[13]輪詢可用的后端服務,即輪詢hive_1、hive_2、hive_3 的10000 端口,10000 端口為HS2 提供TCP 層服務的默認端口.服務器3-5 上需要配置Hive 元數(shù)據對應信息,客戶端通過10000 端口獲取元數(shù)據信息,進而查詢Hive 數(shù)據.集群只需對外提供服務器1 的統(tǒng)一前端端口,最終即可實現(xiàn)通過任意beeline 客戶端訪問服務器1 的HAProxy 代理,使用服務器3-5 上的Hive Server2 服務執(zhí)行Hive 查詢.并充分使用每個Hive Server,分散壓力.

3.4 其他優(yōu)化

(1) 資源管理器調度優(yōu)化：

YARN 主要由ResourceManager、NodeManager、ApplicationMaster和Container 等幾個組件構成.

ResourceManager 是Master 上一個獨立運行的進程,負責集群統(tǒng)一的資源管理、調度、分配等等；NodeManager 是Slave 上一個獨立運行的進程,負責上報節(jié)點的狀態(tài)；App Master和Container 是運行在Slave 上的組件,Container 是YARN 中分配資源的一個單位,包涵內存、CPU 等等資源,YARN 以Container為單位分配資源.

ResourceManager 內存資源配置,配置的是資源調度相關：

yarn.scheduler.minimum-allocation-mb 分配給AM 單個容器可申請的最小內存,默認1024 MB；

yarn.scheduler.maximum-allocation-mb 分配給AM 單個容器可申請的最大內存,默認8192 MB,由于我們所有的虛擬機都是8 GB 內存,需要留2 GB 內存給操作系統(tǒng),1 GB 內存給Hbase,因此此處將單個Container 內存分配上限設為5 GB,即5120 MB.

NodeManager 的內存資源配置,配置的是硬件資源相關：

yarn.nodemanager.resource.memory-mb 節(jié)點最大可用內存,默認8192 MB,參考RM 設置為5120 MB.

yarn.nodemanager.vmem-pmem-ratio 虛擬內存率,默認2.1.

可以計算節(jié)點最大Container 數(shù)量：

max(Container)=yarn.nodemanager.resource.memor y-mb/yarn.scheduler.minimum-allocation-mb=5.

(2) MapReduce 調優(yōu)：

MapReduce 程序優(yōu)化關系到Hive 作業(yè)的每次提交,一些特定值的設置會較大影響到MapReduce 任務執(zhí)行效率.Map Task和Reduce Task 調優(yōu)的一個原則就是減少數(shù)據的傳輸量、盡量使用內存、減少磁盤IO 的次數(shù)、增大任務并行數(shù),除此之外還要根據自己集群及網絡的實際情況來調優(yōu).

3.5 測試與分析

(1)高可用性測試：

以YARN 為例驗證自動故障切換,在Active 節(jié)點上kill 掉ResourceManager 服務,備用節(jié)點能夠自動由Standby 狀態(tài)切換為Active,過程及結果如表4所示.

經過測試,Hadoop、YARN、Spark 均可以進行主備節(jié)點故障切換.

表4 YARN 高可用測試

(2)負載均衡測試：

啟動3、4、5 節(jié)點的HiveServer2 服務,服務器3、4、5 分別命名為hive_1、hive_2、hive_3,集群監(jiān)控管理界面如圖5所示,當前狀態(tài)為無客戶端請求.通過beeline 客戶端連接HAProxy 服務器前端服務對應端口,輸入存放元數(shù)據的MySQL 數(shù)據庫賬號密碼,即可成功通過HiveServer2 服務對Hive 中的數(shù)據進行操作,如下所示：

[root@slave1 bin]# beeline

Beeline version 3.1.0 by Apache Hive

beeline＞!connect jdbc：hive2：//10.2.4.60：25005

Connecting to jdbc：hive2：//10.2.4.60：25005

Enter username for jdbc：hive2：//10.2.4.60：25005：root

Enter password for jdbc：hive2：//10.2.4.60：25005：**********

Connected to：Apache Hive (version 3.1.0)

Driver：Hive JDBC (version 3.1.0)

Transaction isolation：TRANSACTION_REPEATABLE_READ

0：jdbc：hive2：//10.2.4.60：25005&

當多個beeline 客戶端請求連接時,HAProxy 會自動分配可用的Hive Server,如圖6所示,可以看到Sessions一欄中當前連接數(shù)Cur 由全部為0 變?yōu)閔ive_1 為0、hive_2 為1、hive_3 為1,已按照leastconn 分配算法成功實現(xiàn)請求分配,可有效利用Hive Server,均衡Hive 請求.

圖5 代理集群監(jiān)控

圖6 多客戶端請求

4 結論與展望

本文根據中國科學院教育科研態(tài)勢感知服務項目現(xiàn)階段實際需求,以數(shù)據倉庫的高可用性和OLAP 為目標,研究、設計和構建了面向科研管理大數(shù)據的Hadoop+Spark 雙引擎數(shù)據倉庫,支持對異構數(shù)據高效存儲,提供多種查詢分析引擎,為項目后續(xù)需求如數(shù)據挖掘、搭建知識圖譜、學科態(tài)勢分析等非實時場景提供了數(shù)據存儲和計算分析平臺.

由于Hive 對事務弱支持,且事務執(zhí)行速度很慢,存在諸多限制和不便,不適合高并發(fā)的場景.目前架構具有較好擴展性,未來考慮整合Hbase 以提升數(shù)據倉庫查詢實時性和對于事務更好的支持,讓平臺滿足更廣泛的應用場景.