王新東 王一大 李昌盛 張亞威 郭 煒

中國聯(lián)合網(wǎng)絡(luò)通信有限公司濟(jì)南軟件研究院 濟(jì)南 250100

引言

開源Hadoop平臺在國內(nèi)各領(lǐng)域應(yīng)用廣泛，但隨著國產(chǎn)化芯片、操作系統(tǒng)、數(shù)據(jù)庫等應(yīng)用普及，Hadoop已無法完全適配國產(chǎn)化芯片和操作系統(tǒng)?，F(xiàn)有大數(shù)據(jù)組件不能兼容傳統(tǒng)X86主機(jī)和ARM主機(jī)，在麒麟操作系統(tǒng)中運行不穩(wěn)定，且部分功能在麒麟操作系統(tǒng)中不適配，嚴(yán)重阻礙了國內(nèi)大數(shù)據(jù)行業(yè)的發(fā)展。基于以上背景，本文研究了一種基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺，能夠較好適配國產(chǎn)化芯片、操作系統(tǒng)等國產(chǎn)化組件。目前開源Hadoop平臺仍存在以下幾個問題。

1)分布式調(diào)度系統(tǒng)YARN調(diào)度功能不完善，資源無法復(fù)用。YARN的ResourceManager雖然支持Memory和CPU調(diào)度，但CPU資源調(diào)度功能不完善，且AppMaster無法復(fù)用資源，交互效率低[1]。

2)分布式存儲系統(tǒng)HDFS存在單點故障問題。HDFS中所有Metadata操作均需要通過Namenode，數(shù)據(jù)量訪問過大時，這種設(shè)計會成為系統(tǒng)中明顯的單點故障源，影響Hadoop性能發(fā)揮，雖然引入Federation機(jī)制，使用多個獨立NameSpace滿足HDFS命名空間的水平擴(kuò)展，但并未完全解決單點故障問題，在很大程度上制約了整個集群的擴(kuò)展性和可靠性[2]。

3)海量數(shù)據(jù)處理場景受限，元數(shù)據(jù)不統(tǒng)一，缺少權(quán)限安全管理。應(yīng)用開源Hadoop體系使我們從底層架構(gòu)受制于人，無法滿足海量數(shù)據(jù)處理場景，元數(shù)據(jù)不統(tǒng)一，無法進(jìn)行全局的數(shù)據(jù)倉庫規(guī)劃，數(shù)據(jù)安全各自為戰(zhàn)，缺乏權(quán)限安全管控[3]。

4)開源Hadoop平臺無法實現(xiàn)高效存儲、處理大量小文件[4]。小數(shù)據(jù)處理過程中，會出現(xiàn)配置任務(wù)時間超出運行計算時間的情況，且在HDFS中，每個文件對應(yīng)一個數(shù)據(jù)塊，若存儲大量小文件，系統(tǒng)會消耗Namenode大量內(nèi)存來保護(hù)這些數(shù)據(jù)塊信息[5]。

針對上述問題并借鑒國內(nèi)外相關(guān)文獻(xiàn)，本文提出一種基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺。一方面擺脫了底層架構(gòu)受限問題，可以很好地適配國產(chǎn)化ARM主機(jī)和傳統(tǒng)X86主機(jī)，且全部功能均適配國產(chǎn)化麒麟操作系統(tǒng)，性能穩(wěn)定可靠；另一方面解決開源Hadoop平臺調(diào)度系統(tǒng)不完善、交互效率低和單點故障問題。

1 基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺架構(gòu)

本文主要研究了適配國產(chǎn)化ARM主機(jī)和麒麟操作系統(tǒng)的大數(shù)據(jù)平臺架構(gòu)，下面分別從分布式調(diào)度系統(tǒng)、分布式存儲系統(tǒng)、統(tǒng)一元數(shù)據(jù)及安全體系、運維監(jiān)控告警平臺、一站式數(shù)據(jù)智能研發(fā)與綜合治理服務(wù)、適配X86與ARM主機(jī)、適配Centos與麒麟操作系統(tǒng)、部署架構(gòu)八大方面詳細(xì)闡述基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺。其中基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺整體架構(gòu)如圖1所示。

圖1 基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺整體架構(gòu)圖

基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺架構(gòu)由7層組成，包括主機(jī)資源層、操作系統(tǒng)層、分布式調(diào)度與存儲層、大數(shù)據(jù)組件層、計算引擎層、接口層、應(yīng)用層。如圖1所示，其底座是由X86主機(jī)或ARM主機(jī)的主機(jī)資源層組成，基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺既支持單獨部署在X86集群上，也支持單獨部署在ARM集群上，還支持在ARM集群跟X86集群進(jìn)行混合部署，實現(xiàn)了資源重復(fù)利用，部署更加靈活；上一層是操作系統(tǒng)層，包括Centos操作系統(tǒng)與麒麟操作系統(tǒng)，基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺既支持單獨部署在Centos操作系統(tǒng)上，也支持單獨部署在麒麟操作系統(tǒng)上，還支持混合部署，實現(xiàn)了平臺的可移植性；在操作系統(tǒng)層之上為分布式調(diào)度與存儲層，包括分布式調(diào)度系統(tǒng)及分布式存儲系統(tǒng)，用于存儲底層數(shù)據(jù)、調(diào)度任務(wù)作業(yè)等；分布式調(diào)度與存儲層之上為大數(shù)據(jù)組件層，能夠支撐多種大數(shù)據(jù)組件，包括HDFS、YARN、HIVE、HBASE、HUDI、FLINK等；大數(shù)據(jù)組件層之上為計算引擎層，基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺支持多種計算引擎，包括SQL、MapReduce、機(jī)器學(xué)習(xí)等；計算引擎層之上為接口層，基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺不僅支持RESTful API接口接入，也支持RPC API接口接入，同時兼容Java SDK、Python SDK、JDBC、Console等工具供開發(fā)者使用；接口層之上為應(yīng)用層，目前已開發(fā)的應(yīng)用有一站式數(shù)據(jù)智能研發(fā)平臺、統(tǒng)一元數(shù)據(jù)及安全系統(tǒng)、運維監(jiān)控告警平臺。

應(yīng)用層中研發(fā)了一站式數(shù)據(jù)智能研發(fā)平臺，封裝了一系列操作，提供了統(tǒng)一的數(shù)據(jù)建模、數(shù)據(jù)采集、數(shù)據(jù)加工、調(diào)度等一系列能力。通過研發(fā)統(tǒng)一元數(shù)據(jù)及安全系統(tǒng)，基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺將所有元數(shù)據(jù)統(tǒng)一管理，有助于進(jìn)行全局?jǐn)?shù)據(jù)倉庫規(guī)劃；基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺將具備完善的安全體系，Capability機(jī)制、沙箱、IP白名單、多租戶管理、數(shù)據(jù)分級打標(biāo)、項目保護(hù)模式等可獨立做數(shù)據(jù)權(quán)限管理。研發(fā)運維監(jiān)控告警平臺，實現(xiàn)了對基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺中集群、主機(jī)、項目、服務(wù)的全方位管控。

1.1 分布式調(diào)度系統(tǒng)

分布式調(diào)度系統(tǒng)主要負(fù)責(zé)任務(wù)調(diào)度與資源管理，目前常見的三種分布式調(diào)度系統(tǒng)主要有Hadoop MR、YARN、Mesos，它們均存在較多問題，Hadoop MR規(guī)模擴(kuò)展存在瓶頸，容錯性差，不利于功能擴(kuò)展，可靠性差，資源利用率低；YARN的ResourceManager雖然支持內(nèi)存和CPU調(diào)度，但CPU資源調(diào)度仍需完善，且AppMaster無法復(fù)用資源，交互效率低；Mesos計算框架只能被動接受Resource Offer，不能精確描述資源需求，且一次資源分配需要兩次通信交互，調(diào)度效率低，不支持資源搶占等問題[6]。

在此基礎(chǔ)上，研發(fā)了一種分布式調(diào)度系統(tǒng)，由資源調(diào)度和任務(wù)調(diào)度分離兩層架構(gòu)組成。本文提出通過資源調(diào)度器和agsou結(jié)構(gòu)解決分布式調(diào)度中資源調(diào)度問題，將每個計算任務(wù)的APP Master及一組APP Worker組合起來解決分布式調(diào)度中的任務(wù)調(diào)度問題，其架構(gòu)如圖2所示。

圖2 分布式調(diào)度系統(tǒng)架構(gòu)圖

Client負(fù)責(zé)接受用戶請求；APP Master負(fù)責(zé)向資源調(diào)度器申請/釋放資源，調(diào)度APP Worker到集群節(jié)點，分配Instance、APP Worker數(shù)據(jù)傳輸，管理APP Worker生命周期，故障重啟等；APP Worker負(fù)責(zé)接收Instance，執(zhí)行用戶計算邏輯；agsou負(fù)責(zé)收集每個機(jī)器的硬件資源(CPU、Memory、Disk等)，發(fā)送給資源調(diào)度器；資源調(diào)度器作為中控節(jié)點，負(fù)責(zé)整個集群的調(diào)度。

集群部署完畢，分布式調(diào)度系統(tǒng)操作步驟如下：

1)用戶通過Client向資源調(diào)度器提交計算任務(wù)；

2)資源調(diào)度器選擇一臺agsou啟動計算任務(wù)對應(yīng)的APP Master；

3)APP Master向資源調(diào)度器提交資源申請，資源調(diào)度器經(jīng)過資源調(diào)度，將結(jié)果返回給APP Master；

4)APP Master進(jìn)行任務(wù)調(diào)度，決定計算任務(wù)適配的機(jī)器，并將計算任務(wù)發(fā)送給對應(yīng)機(jī)器上的agsou進(jìn)程；

5)agsou接受命令，從程序包管理器中下載對應(yīng)程序并解壓，啟動用戶APP Worker；

6)APP Worker根據(jù)配置信息讀取文件存儲系統(tǒng)中的數(shù)據(jù)進(jìn)行計算，并將計算結(jié)果發(fā)往下一個APP Worker。

本文提出的分布式調(diào)度系統(tǒng)相比現(xiàn)有的分布式調(diào)度系統(tǒng)有明顯優(yōu)勢，包括：資源調(diào)度器擴(kuò)展性強(qiáng)，針對不同任務(wù)在APP Master中可通過心跳監(jiān)控選擇不同調(diào)度策略，實現(xiàn)了負(fù)載均衡；通過對開源組件Ambari進(jìn)行優(yōu)化，實現(xiàn)了YARN、Zookeeper的復(fù)用，以支撐多種計算框架，達(dá)到資源復(fù)用的效果，提高了資源交互效率；分布式調(diào)度系統(tǒng)支持集群節(jié)點超大規(guī)模，水平擴(kuò)展，能夠支撐2000臺大數(shù)據(jù)節(jié)點規(guī)模，另外支撐集群節(jié)點擴(kuò)縮容；通過借鑒HDFS HA思想，對每個角色都部署多個節(jié)點，同時主節(jié)點與備節(jié)點保持心跳通信，以達(dá)到主節(jié)點發(fā)生故障可隨時切換備節(jié)點，同時數(shù)據(jù)不丟失，實現(xiàn)了分布式調(diào)度系統(tǒng)的高容錯性，任何角色故障不影響任務(wù)執(zhí)行。

1.2 分布式存儲系統(tǒng)

在超大規(guī)模分布式集群中，小概率故障成為常態(tài)，可能帶來“雪崩效應(yīng)”[6]。本文提出了一個穩(wěn)定可靠的分布式存儲系統(tǒng)，設(shè)置3個不同角色負(fù)責(zé)管理不同事務(wù)：元數(shù)據(jù)服務(wù)器(Master)、數(shù)據(jù)存儲服務(wù)器(ChunkServer)、客戶端(Client)，解決了集群小概率故障問題，同時確保數(shù)據(jù)具有強(qiáng)一致性、安全性、可靠性、可用性。分布式存儲系統(tǒng)架構(gòu)如圖3所示。

圖3 分布式存儲系統(tǒng)架構(gòu)圖

Client負(fù)責(zé)接受用戶請求，部分用戶偏向高性能，部分用戶偏向大存儲，針對用戶不同需求，系統(tǒng)采用多線程同步，同時支撐不同用戶。Master負(fù)責(zé)管理整個存儲集群的元數(shù)據(jù)，采用Paxos選主，而非Zookeeper的外部服務(wù)，支撐海量存儲穩(wěn)定運行。ChunkServer負(fù)責(zé)磁盤管理，將閃存和機(jī)械硬盤相結(jié)合，數(shù)據(jù)前臺先寫入閃存，后臺轉(zhuǎn)儲到機(jī)械硬盤上，實現(xiàn)了在關(guān)鍵節(jié)點使用閃存以代替全部使用閃存的方式，解決了存儲皆使用閃存導(dǎo)致存儲成本高的問題。

數(shù)據(jù)高可用：由于對外服務(wù)器數(shù)量固定，單純增加服務(wù)器數(shù)量無法實現(xiàn)數(shù)據(jù)的高可用，將目錄樹分割成volume，通過不同volume實現(xiàn)Master水平擴(kuò)展，保證了數(shù)據(jù)高可用。

數(shù)據(jù)高可靠：分布式存儲系統(tǒng)中，采用多副本機(jī)制，設(shè)置多副本位于不同故障域，當(dāng)有數(shù)據(jù)節(jié)點故障時，Master就會發(fā)起復(fù)制機(jī)制，在ChunkServer間復(fù)制數(shù)據(jù)，保證了數(shù)據(jù)高可靠。

數(shù)據(jù)完整性：在小概率事件下，內(nèi)存或磁盤存儲的數(shù)據(jù)可能會發(fā)生改變。每段數(shù)據(jù)后面設(shè)置循環(huán)冗余校驗(CRC)，進(jìn)行數(shù)據(jù)周期性掃描，若發(fā)現(xiàn)數(shù)據(jù)與CRC無法匹配，則認(rèn)為此段數(shù)據(jù)發(fā)生了位反轉(zhuǎn)，此時采用完整副本覆蓋發(fā)生位反轉(zhuǎn)副本，保證了數(shù)據(jù)完整性。

1.3 統(tǒng)一元數(shù)據(jù)及安全體系

基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺將元數(shù)據(jù)統(tǒng)一管理，提供了項目元數(shù)據(jù)視圖和作業(yè)歷史視圖，可查看元數(shù)據(jù)，使用歷史數(shù)據(jù)、項目內(nèi)的作業(yè)歷史等信息。為管控元數(shù)據(jù)安全查看，設(shè)置用戶訪問權(quán)限，若項目內(nèi)其他用戶或角色需要查看時，需申請授權(quán)。

基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺提供完善的安全管理體系，主要包含用戶及授權(quán)管理(負(fù)責(zé)用戶認(rèn)證、用戶管理、授權(quán)、角色管理及權(quán)限查看)、列級別訪問控制(設(shè)置安全策略，對敏感數(shù)據(jù)劃分等級，實現(xiàn)用戶對列級敏感數(shù)據(jù)訪問)、數(shù)據(jù)下載權(quán)限管控、項目空間安全配置(支持多種正交授權(quán)機(jī)制，定制鑒權(quán)模型)、項目空間數(shù)據(jù)保護(hù)(自行設(shè)置數(shù)據(jù)保護(hù)機(jī)制，防止敏感數(shù)流出)、IP白名單(限制白名單以外設(shè)備訪問項目空間)等。

1.4 運維監(jiān)控告警平臺

運維監(jiān)控告警平臺是為基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺研發(fā)的運維管控平臺，支持從業(yè)務(wù)、集群、服務(wù)和主機(jī)維度對大數(shù)據(jù)組件進(jìn)行運維管理。

1)業(yè)務(wù)運維

業(yè)務(wù)運維功能包括項目管理(負(fù)責(zé)展示項目列表及項目詳情、元倉資源授權(quán)、數(shù)據(jù)存儲加密、容災(zāi)查看及切換、項目遷移)，隊列管理(負(fù)責(zé)展示、新增及修改項目隊列、查看詳情)，作業(yè)管理(展示集群所有作業(yè)、查看運行日志、終止作業(yè))。

2)集群運維

集群運維功能包括集群概況(CPU、磁盤、內(nèi)存、服務(wù)狀態(tài)、LOAD、PACKAGE等運行信息)、集群健康管理(查看集群檢查項)、機(jī)器列表(展示集群主機(jī)信息)。

3)服務(wù)運維

服務(wù)運維包括控制服務(wù)運維、分布式調(diào)度系統(tǒng)運維、分布式存儲系統(tǒng)運維和數(shù)據(jù)通道運維?？刂品?wù)運維主要負(fù)責(zé)查看服務(wù)總體運行狀態(tài)，查看服務(wù)檢查項及詳情，查看服務(wù)元倉狀況，啟停服務(wù)，采集服務(wù)日志。分布式調(diào)度系統(tǒng)運維主要監(jiān)控分布式調(diào)度系統(tǒng)的關(guān)鍵運行指標(biāo)(服務(wù)狀態(tài)、CPU和內(nèi)存使用情況、計算節(jié)點使用情況等)、分布式調(diào)度系統(tǒng)健康狀況管理(檢查項、檢查狀態(tài)等)、分布式調(diào)度系統(tǒng)隊列管理。分布式存儲系統(tǒng)運維主要管理關(guān)鍵運行指標(biāo)、健康狀況、存儲節(jié)點和服務(wù)實例(展示分布式存儲系統(tǒng)的Master主機(jī)和服務(wù)角色信息)。數(shù)據(jù)通道管理數(shù)據(jù)流量分析。

4)主機(jī)運維

主機(jī)運維功能包括主機(jī)概況(展示集群中主機(jī)信息、運行健康、以及機(jī)器CPU、內(nèi)存、存儲、負(fù)載等信息)，主機(jī)健康管理(查看主機(jī)檢查項及詳情)，主機(jī)服務(wù)(查看主機(jī)所屬集群、主機(jī)運行服務(wù)實例等)。

除此之外，運維監(jiān)控告警平臺還支持對大數(shù)據(jù)組件自定義監(jiān)控告警，當(dāng)指標(biāo)超出設(shè)定閾值，監(jiān)控系統(tǒng)會通過短信、釘釘、電話等多種形式自動向運維人員發(fā)送報警信息，通過監(jiān)控大盤界面也可實時觀察監(jiān)控指標(biāo)變化。

1.5 一站式數(shù)據(jù)智能研發(fā)與綜合治理服務(wù)

一站式數(shù)據(jù)智能研發(fā)與綜合治理服務(wù)是集ETL、數(shù)據(jù)質(zhì)量檢測、智能調(diào)度和數(shù)據(jù)血緣管理于一體的全方位多功能平臺，與基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺深度集成，支持多種計算和存儲引擎服務(wù)。

1)數(shù)據(jù)集成

在復(fù)雜網(wǎng)絡(luò)環(huán)境下，異構(gòu)數(shù)據(jù)源之間數(shù)據(jù)傳輸與同步困難，數(shù)據(jù)集成模塊是一個可跨異構(gòu)數(shù)據(jù)進(jìn)行數(shù)據(jù)傳輸?shù)姆€(wěn)定、安全可靠的數(shù)據(jù)同步平臺。數(shù)據(jù)集成模塊包括離線和實時數(shù)據(jù)同步兩種方式，不僅提供不同網(wǎng)絡(luò)環(huán)境下全量或增量數(shù)據(jù)同步，而且提供批量創(chuàng)建同步任務(wù)，實現(xiàn)數(shù)據(jù)庫內(nèi)所有表批量上傳到基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺中，提高了工作效率。

2)數(shù)據(jù)開發(fā)

數(shù)據(jù)開發(fā)模塊支持開發(fā)、生產(chǎn)相隔離，提供了更穩(wěn)定、更可靠的生產(chǎn)環(huán)境。數(shù)據(jù)開發(fā)模塊還支持開發(fā)者自主組合SQL、MapReduce、Flink和機(jī)器學(xué)習(xí)等各項任務(wù)的混編工作流，實現(xiàn)分鐘級調(diào)度、邏輯控制等。除此以外，開發(fā)者可以從業(yè)務(wù)角度管控工作流，將同類型業(yè)務(wù)組織為解決方案，實現(xiàn)沉浸式開發(fā)。

3)數(shù)據(jù)質(zhì)量檢測

數(shù)據(jù)質(zhì)量檢測支持多種異構(gòu)數(shù)據(jù)源的質(zhì)量校驗、通知及管理，支持基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺數(shù)據(jù)表和實時數(shù)據(jù)流。

4)智能調(diào)度

智能調(diào)度模塊通過設(shè)置調(diào)度參數(shù)、時間屬性、資源屬性、調(diào)度依賴等不同調(diào)度配置實現(xiàn)強(qiáng)大的調(diào)度功能，支持通過時間屬性和調(diào)度依賴配置進(jìn)行任務(wù)觸發(fā)，時間屬性包含實例生成方式、調(diào)度類型、重跑屬性及調(diào)度周期等配置。調(diào)度依賴即上游節(jié)點輸出作為下游節(jié)點輸入，形成依賴關(guān)系，防止下游節(jié)點調(diào)用上游數(shù)據(jù)時，上游數(shù)據(jù)未正常產(chǎn)出而影響下游節(jié)點運行。同時，智能調(diào)度模塊支持按月、周、小時和分鐘等多種調(diào)度周期配置，支持每日千萬級別任務(wù)調(diào)度，可通過DAG圖準(zhǔn)確、準(zhǔn)時地運行。

5)數(shù)據(jù)血緣管理

數(shù)據(jù)血緣管理是在元數(shù)據(jù)基礎(chǔ)上提供數(shù)據(jù)目錄管理模塊，支持全局?jǐn)?shù)據(jù)檢索、查看元數(shù)據(jù)詳情、血緣管理等功能，讓數(shù)據(jù)資產(chǎn)盡可能在組織內(nèi)被更好地共享、發(fā)現(xiàn)，從而提升數(shù)據(jù)使用率、降低數(shù)據(jù)重復(fù)率。元數(shù)據(jù)接入時，可通過數(shù)據(jù)血緣管理服務(wù)對基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺引擎直接進(jìn)行表元數(shù)據(jù)管理操作，也可以對不同數(shù)據(jù)源的元數(shù)據(jù)導(dǎo)入數(shù)據(jù)血緣管理服務(wù)中統(tǒng)一管理。通過血緣管理可視化節(jié)點的依賴關(guān)系圖和內(nèi)部血緣圖，方便研發(fā)人員快速清晰地理解數(shù)據(jù)生成路徑。

1.6 適配X86與ARM主機(jī)

開源大數(shù)據(jù)平臺為原生HDP大數(shù)據(jù)平臺，主要包括Ambari管理平臺以及各大數(shù)據(jù)服務(wù)組件(HDFS、YARN、HIVE等)。而國產(chǎn)化平臺采購的主機(jī)主要包括X86架構(gòu)主機(jī)和ARM架構(gòu)主機(jī)。我們需要解決HDP大數(shù)據(jù)平臺在這兩種機(jī)型的安裝，以便實現(xiàn)兩種機(jī)型的混合部署，從而規(guī)避產(chǎn)業(yè)鏈中潛在的卡脖子風(fēng)險。

適配主機(jī)的本質(zhì)，就是將HDP大數(shù)據(jù)平臺的rpm安裝包中的各類文件，如jar包文件、靜態(tài)鏈接庫文件(.a)、動態(tài)鏈接庫文件(.so)、二進(jìn)制執(zhí)行文件、配置文本文件等，以及這些文件的目錄層級關(guān)系安裝到所適配架構(gòu)的主機(jī)上。

1.6.1 X86主機(jī)適配

由于HDP大數(shù)據(jù)平臺官網(wǎng)提供針對X86芯片的安裝包，因此針對X86芯片主機(jī)并不需要做單獨適配工作，經(jīng)測試可以直接使用官方提供的X86安裝包在X86主機(jī)上進(jìn)行安裝使用，性能與Intel X86并無明顯差異。

1.6.2 ARM主機(jī)適配

針對ARM芯片，由于其芯片架構(gòu)與X86有較大差異，因此在該芯片架構(gòu)上安裝HDP大數(shù)據(jù)平臺，需要專門適配，基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺基于原生HDP大數(shù)據(jù)集群，包括Ambari管理平臺以及各大數(shù)據(jù)服務(wù)組件(HDFS、Yarn、Hive、HBase等)。

本次rpm包的架構(gòu)適配實際上是rpm安裝包中靜態(tài)、動態(tài)鏈接庫和二進(jìn)制執(zhí)行文件的適配，即通過將同版本源碼在需要適配的架構(gòu)上(本次適配的是采用arm v8的linux aarch64架構(gòu))進(jìn)行編譯，得到的編譯產(chǎn)物就是對應(yīng)架構(gòu)的安裝包。

本次編譯過程總體分為三大步，具體如下。

1)安裝編譯前置依賴，如rpm-build、gcc-c++、python-devel、gulp、git等。

2)安裝編譯工具，如phantomjs、frontend-mavenplugin、leveldb/jni等。

3)Ambari源碼編譯。從官方下載源碼后需要將部分pom文件中的X86和amd64修改為arm和aarch64，以適配ARM芯片架構(gòu)，涉及的文件列表如下：

#將noarch改為aarch64

ambari-logsearch/pom.xml

ambari-funtest/pom.xml

ambari-metrics/ambari-metrics-grafana/pom.xml

#將amd64或i386 amd64改為arm64

ambari-agent/pom.xml

ambari-logsearch/pom.xml

ambari-server/pom.xml

contrib/views/ambari-views-package/pom.xml

ambari-client/python-client/pom.xml

ambari-shell/ambari-python-shell/pom.xml

#將X86改為aarch64

ambari-agent/pom.xml

ambari-metrics/ambari-metircs-assembly/pom.xml

ambari-server/pom.xml

修改芯片架構(gòu)參數(shù)后仍需要按照上述2步安裝的依賴與編譯工具版本修改對應(yīng)pom文件中的版本號，涉及的文件列表如下：

ambari-logsearch/pom.xml

ambari-funtest/pom.xml

ambari-metrics/ambari-metrics-grafana/pom.xml

ambari-metrics/pom.xml

ambari-admin/pom.xml

最后需要將ambari-web/package.json中的emberhandlerbars-brunch修改為github，鏈接如下：

“ember-handlerbars-brunch”:“git://github.com/ember-handlerbars-brunch.git#540127137296a 09601cbd215dcf4da4d27bcfb9e”

以上配置修改完后即可完成編譯，rpm包將會存儲在對應(yīng)target路徑下。

1.7 適配Centos與麒麟操作系統(tǒng)

在操作系統(tǒng)層面主要使用了Centos操作系統(tǒng)與麒麟操作系統(tǒng)。我們的目標(biāo)是不僅實現(xiàn)大數(shù)據(jù)平臺在這些操作系統(tǒng)上安裝，還要實現(xiàn)混合部署，以具備可移植性和靈活性。

針對Centos：開源HDP均在Centos主機(jī)上安裝且十分成熟，因此大數(shù)據(jù)平臺安裝包無需更改即可平滑安裝于Centos主機(jī)。

針對麒麟操作系統(tǒng)：由于開源HDP并未對麒麟操作系統(tǒng)進(jìn)行兼容適配，需對ambari-agent下的相關(guān)腳本和配置進(jìn)行修改，以完成對麒麟操作系統(tǒng)的適配，修改內(nèi)容涉及以下幾個方面。

1)配置操作系統(tǒng)校驗，將Ambari agent校驗中添加麒麟操作系統(tǒng)，需要修改操作系統(tǒng)校驗相關(guān)腳本，路徑為：/usr/lib/ambariagent/lib/ambari_commons/os_check.py。在207行添加：

elif _is_kylin_linux():

distribution = (“Centos”,“7.6.1810”,“LTS”)

意思為若操作系統(tǒng)判斷為麒麟操作系統(tǒng)，則返回麒麟操作系統(tǒng)的版本。

2)按照適配的HDP版本號，固定安裝腳本中的版本號信息。需要修改的腳本路徑為：/usr/lib/ambari-agent/lib/resource_management/libraries/script/script.py和/usr/lib/ambari-agent/lib/ambari_commons/repo_manager/yum_manager.py。由于自行適配的版本針對3.1.0進(jìn)行，因此將所有腳本中的版本號固定為3.1.0，防止出現(xiàn)yum自動安裝時版本不一致的問題，其中script.py需要修改89行如下：

STACK_VERSION_PLACEHOLDER=“3_1_0_0_78”

yum_mamager.py需要修改yum_check_package_available函數(shù)，該函數(shù)的作用為在yum安裝之前校驗安裝包是否存在，將版本校驗部分邏輯修改為只校驗3.1.0版本安裝包，強(qiáng)行使安裝包校驗這一步通過，修改如下：

if name.find(“stack_version”) != -1:

name=name.replace(“${stack_version}”，“3_1_0_0_78”)

3)固定yum源地址。由于Centos和麒麟混部需求，因此自動化安裝需要配置兩套yum源，其中一套yum源為Centos版本，另外一套為麒麟版本，其中在麒麟版本安裝時，將yum源校驗這部分腳本代碼修改為固定地址，即強(qiáng)行使麒麟主機(jī)安裝各組件的過程通過設(shè)置單一yum源下載安裝包，以解決麒麟版本對Centos版本yum源誤掃描的問題，需要修改的腳本路徑為：/usr/lib/ambari-agent/lib/resource_management/libraries/functions/repository_util.py。修改內(nèi)容如下：

base_url=“http://{kylin-yumip:port}/HDP/Centos7/3.1.0.0-78”

1.8 基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺部署架構(gòu)

1)基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺支持X86主機(jī)與ARM主機(jī)混合部署，其架構(gòu)如圖4所示。

圖4 基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺X86與ARM混部架構(gòu)圖

本文提出的基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺既支持單獨部署在X86集群上，也支持單獨部署在ARM集群上，還支持在ARM集群跟X86集群進(jìn)行混合部署，實現(xiàn)了資源重復(fù)利用，部署更加靈活。

2)基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺支持Centos操作系統(tǒng)與麒麟操作系統(tǒng)混合部署，其架構(gòu)如圖5所示。

圖5 基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺Centos與麒麟混部架構(gòu)圖

本文提出的基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺既支持單獨部署在Centos操作系統(tǒng)上，也支持單獨部署在麒麟操作系統(tǒng)上，還支持Centos操作系統(tǒng)與麒麟操作系統(tǒng)混合部署，實現(xiàn)了平臺的可移植性。

3)基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺支持跨機(jī)房部署，其架構(gòu)如圖6所示。

圖6 基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺跨機(jī)房部署架構(gòu)圖

相比于開源Hadoop平臺，本文提出的基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺支持跨機(jī)房部署，如圖6所示，控制集群和計算集群均可以部署在不同機(jī)房，保證了集群的高可用。

2 基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺應(yīng)用

為進(jìn)一步分析基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺應(yīng)用，本文通過TPCDS SQL性能實驗、批量數(shù)據(jù)加工實驗進(jìn)行兩組對比實驗，分析開源Hadoop平臺與本文提出的基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺的性能對比。

2.1 TPCDS SQL性能實驗

對100臺物理機(jī)資源部署集群平臺，分別選50臺機(jī)器部署開源Hadoop平臺，50臺機(jī)器部署基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺。集群部署正常且運行正常情況下，通過TPC-DS工具在集群上構(gòu)建實驗數(shù)據(jù)，規(guī)模為100TB TPC-DS實驗數(shù)據(jù)。通過TPC-DS工具依次運行99條標(biāo)準(zhǔn)SQL，記錄每條SQL執(zhí)行時間，分別得到開源Hadoop平臺和基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺運行99條標(biāo)準(zhǔn)SQL的整體耗時對比結(jié)果，如圖7所示。

圖7 TPCDS 99條SQL運行結(jié)果對比圖

由圖7可知，對2個平臺分別運行了兩次99條TPCDS SQL，整體耗時方面，基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺比開源Hadoop平臺耗時縮短一倍，運行速度得到較大提升，說明本文提出的基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺優(yōu)于開源Hadoop平臺。

2.2 批量數(shù)據(jù)加工實驗

分別針對基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺與開源Hadoop平臺創(chuàng)建離線加工租戶，均分配2560Hz的CPU資源、10T內(nèi)存，建表并導(dǎo)入數(shù)據(jù)，其中包含6個數(shù)據(jù)庫，涉及32張表，共計2.4T數(shù)據(jù)量，進(jìn)行一系列數(shù)據(jù)加工流程：依次執(zhí)行SRC→ODS加工流程，ODS→DWD加工流程，DWD→DWA加工流程，DWA→DM加工流程，并記錄每個加工流程的耗時，分別得到基于混合架構(gòu)的大數(shù)據(jù)平臺和開源Hadoop平臺對批量數(shù)據(jù)加工實驗的整體耗時對比結(jié)果，如圖8所示。

圖8 批量加工流程整體耗時對比圖

由圖8可知，批量數(shù)據(jù)加工過程中，開源Hadoop平臺整體耗時0.927小時，基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺整體耗時0.256小時，數(shù)據(jù)表明，本文提出的基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺運行效率更優(yōu)。

3 結(jié)論

基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺通過對開源Hadoop平臺進(jìn)行改進(jìn)，通過研發(fā)了一套分布式調(diào)度系統(tǒng)和分布式存儲系統(tǒng)，一方面擺脫了底層架構(gòu)受限問題，可以很好地適配ARM主機(jī)和傳統(tǒng)X86主機(jī)，且全部功能均適配麒麟操作系統(tǒng)，性能穩(wěn)定可靠；另一方面解決開源Hadoop平臺調(diào)度系統(tǒng)不完善、交互效率低和單點故障問題。通過統(tǒng)一元數(shù)據(jù)及安全管理體系，將元數(shù)據(jù)統(tǒng)一規(guī)劃，節(jié)省存儲費用，提高安全管控能力。并通過業(yè)界通用的TPCDS SQL實驗及批量數(shù)據(jù)加工實驗，證明了基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺具有一定的可行性及有效性。

基于混合架構(gòu)的國產(chǎn)化大數(shù)據(jù)平臺還有很多地方需要改進(jìn)，由于本文特定場景的需求并沒有引入其它實時業(yè)務(wù)場景，在今后的研究工作中將引入實時場景進(jìn)行多項驗證，探索能否形成一套通用平臺，既可應(yīng)用于離線大數(shù)據(jù)任務(wù)也可應(yīng)用于實時大數(shù)據(jù)任務(wù)，以便應(yīng)用于不同生產(chǎn)系統(tǒng)，從而大大提高平臺的靈活性。