李 翀,張彤彤,2,杜偉靜,2,劉學(xué)敏

1(中國(guó)科學(xué)院 計(jì)算機(jī)網(wǎng)絡(luò)信息中心,北京 100190)

2(中國(guó)科學(xué)院大學(xué),北京 100190)

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

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

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

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

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

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

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

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

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

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

2.1 技術(shù)選型

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

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

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

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

綜上所述,Hive on Spark 與Hive on MapReduce 結(jié)合,可以高效切換計(jì)算引擎,同時(shí)提高資源利用率,降低運(yùn)維成本.

2.2 高可用性

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

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

HDFS 集群的不可用主要包括以下兩種情況：一是主節(jié)點(diǎn)主機(jī)宕機(jī),導(dǎo)致集群不可用；二是計(jì)劃內(nèi)的主節(jié)點(diǎn)軟件或硬件升級(jí),導(dǎo)致集群在短時(shí)間內(nèi)不可用.

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

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

圖1 高可用原理

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

2.3 系統(tǒng)設(shè)計(jì)

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

圖2 系統(tǒng)技術(shù)架構(gòu)

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

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

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

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

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

表1 各資源版本

3.1 集群部署架構(gòu)

Hadoop 集群和Spark 集群搭建在5 臺(tái)虛擬機(jī)上,虛擬機(jī)具體配置信息見表2.集群設(shè)置有一個(gè)主節(jié)點(diǎn),一個(gè)主節(jié)點(diǎn)備用節(jié)點(diǎn),進(jìn)行任務(wù)管理,三個(gè)從節(jié)點(diǎn)進(jìn)行任務(wù)執(zhí)行,架構(gòu)如圖3所示.

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

圖3 集群架構(gòu)

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

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

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

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

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

(2) Hive JDBC 服務(wù)：

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ā)和認(rèn)證,并且允許遠(yuǎn)程客戶端使用多種編程語言如Java、Python向Hive 提交請(qǐng)求,取回結(jié)果,為開放API 客戶端如JDBC、ODBC 提供了更好的支持.HS2 使得客戶端可以在不啟動(dòng)CLI 的情況下對(duì)Hive 中的數(shù)據(jù)進(jìn)行操作,如可以使用beeline 連接HS2 執(zhí)行查詢.當(dāng)集群中存在多個(gè)HS2 服務(wù)時(shí),用戶可以自行選擇具體主機(jī)進(jìn)行連接,但某臺(tái)服務(wù)器連接數(shù)過大時(shí)容易造成端口不響應(yīng),服務(wù)器故障也會(huì)造成無法查詢,使用HAProxy 可以最大程度避免這種情況.HAProxy 是一款提供高可用性、負(fù)載均衡,基于TCP和HTTP 應(yīng)用的代理軟件,并且具有代理集群狀態(tài)監(jiān)控功能.HAProxy 通過配置前端(frontend)監(jiān)聽端口和后端(backend)服務(wù)端口進(jìn)行請(qǐng)求轉(zhuǎn)發(fā),并提供多種負(fù)載均衡算法,適合不同場(chǎng)景下的負(fù)載均衡.當(dāng)客戶端向前端綁定的端口發(fā)送請(qǐng)求時(shí),HAProxy 根據(jù)指定的算法選擇可用的后端服務(wù),并將請(qǐng)求轉(zhuǎn)發(fā).

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

表3 集群服務(wù)部署

圖4 負(fù)載均衡原理

HAProxy 核心配置如下所示：

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

mode tcp #在第四層進(jìn)行代理服務(wù)

balance leastconn #調(diào)度算法

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

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

3.4 其他優(yōu)化

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

YARN 主要由ResourceManager、NodeManager、ApplicationMaster和Container 等幾個(gè)組件構(gòu)成.

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

ResourceManager 內(nèi)存資源配置,配置的是資源調(diào)度相關(guān)：

yarn.scheduler.minimum-allocation-mb 分配給AM 單個(gè)容器可申請(qǐng)的最小內(nèi)存,默認(rèn)1024 MB；

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

NodeManager 的內(nèi)存資源配置,配置的是硬件資源相關(guān)：

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

yarn.nodemanager.vmem-pmem-ratio 虛擬內(nèi)存率,默認(rèn)2.1.

可以計(jì)算節(jié)點(diǎn)最大Container 數(shù)量：

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

(2) MapReduce 調(diào)優(yōu)：

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

3.5 測(cè)試與分析

(1)高可用性測(cè)試：

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

經(jīng)過測(cè)試,Hadoop、YARN、Spark 均可以進(jìn)行主備節(jié)點(diǎn)故障切換.

表4 YARN 高可用測(cè)試

(2)負(fù)載均衡測(cè)試：

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

[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&

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

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

圖6 多客戶端請(qǐng)求

4 結(jié)論與展望

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

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