王永坤,羅 萱,金耀輝,2

(1.上海交通大學網(wǎng)絡(luò)信息中心,上海 200240;2.上海交通大學光纖通信國家重點實驗室,上海 200240)

1 引言

隨著社會對大數(shù)據(jù)分析技術(shù)的需求日益高漲，用于支撐大數(shù)據(jù)分析的底層數(shù)據(jù)平臺技術(shù)也得到了長足的發(fā)展。開源社區(qū)提供了很多開源技術(shù)方案，例如Apache Hadoop、Apache Hive[1]、Apache Spark[2]來解決數(shù)據(jù)的存儲、查詢和計算，并且有專門公司提供企業(yè)級服務(wù)。在數(shù)據(jù)平臺之上，提供了Hue、Jupyter、Zepplin等交互計算接口，并提供基本的訪問控制。很多廠商也基于大數(shù)據(jù)分析技術(shù)的標準框架，提供了建立在云上的大數(shù)據(jù)平臺方案，包括國外的亞馬遜云AWS(Amazon Web Services)、谷歌云平臺大數(shù)據(jù)產(chǎn)品、微軟云(Azure)上的Hadoop，國內(nèi)有阿里云大數(shù)據(jù)服務(wù)Max Compute、天池、及數(shù)加、騰訊大數(shù)據(jù)、百度大數(shù)據(jù)+。云上的解決方案可擴展性強，可以滿足用戶不斷變化的需求。

雖然這些云平臺上的數(shù)據(jù)平臺方案規(guī)模大、技術(shù)水平高、可擴展性高，但是相對而言成本也比學校等非盈利機構(gòu)的內(nèi)部平臺要高，而且涉及的知識產(chǎn)權(quán)問題等較嚴格，數(shù)據(jù)開放共享的難度較大。因此，我們的目標是能完全獨立地使用開源社區(qū)的解決方案來搭建一個數(shù)據(jù)平臺，以較低的成本來搭建高性能、可擴展的數(shù)據(jù)平臺，而且不被任何一種私有技術(shù)鎖定。

為了實現(xiàn)這一目標，接下來介紹我們的混合數(shù)據(jù)平臺設(shè)計：基于私有云和物理服務(wù)器的混合數(shù)據(jù)平臺設(shè)計。將數(shù)據(jù)平臺建立在云上具有管理簡單、可擴展性好等優(yōu)點，但是性能損失較大。在2016年10月于巴塞羅那舉辦的Openstack峰會上有用戶報告了基于KVM(Kernel-based Virtual Machine)云主機方案的數(shù)據(jù)平臺，運行Spark異常檢測任務(wù)(Spark Anomaly Detection Job)，所用的時間是基于物理服務(wù)器上的數(shù)據(jù)平臺的近2倍(1.95×)(基于容器(Nova-LXD等)的方案會大大減少額外開銷，運行Spark異常檢測任務(wù)用時是物理服務(wù)器數(shù)據(jù)平臺的1.1倍(10%的額外開銷)。但是，考慮到用戶對各種云主機需求的多樣性以及平臺的穩(wěn)定性，我們的私有云平臺使用了基于KVM的解決方案)。出于高性能的數(shù)據(jù)處理考慮，我們將數(shù)據(jù)平臺的主體部分搭建在物理服務(wù)器上。當數(shù)據(jù)平臺的處理能力不足時，動態(tài)擴展到我們的私有云平臺上。

我們的平臺完全使用開源軟件，自己選取設(shè)計組件，自己搭建和運維。開源軟件代碼公開并且由開源社區(qū)維護，適合高校這種IT經(jīng)費相對較少但是智力資源較多的環(huán)境。我們的平臺用于校內(nèi)及部分公開服務(wù)，也定期提供給數(shù)據(jù)大賽這種大規(guī)模、高強度、集中式、密集計算的場景使用。在這樣的應(yīng)用場景下，我們的混合數(shù)據(jù)平臺設(shè)計方案可以很好地兼顧性能和彈性使用需求。

根據(jù)我們了解，這在國內(nèi)外高校中也是一種大膽的嘗試，希望我們的經(jīng)驗可以給其它院校和機構(gòu)一些參考。

我們的貢獻概括如下：

(1)設(shè)計了一種混合的數(shù)據(jù)平臺架構(gòu)：數(shù)據(jù)平臺的主體運行在物理服務(wù)器上，當資源不足時，動態(tài)擴展到內(nèi)部的私有云平臺上；

(2)選取硬件并配置了生產(chǎn)環(huán)境，給出基本的評測結(jié)果驗證了這種設(shè)計的可行性；

(3)使用這種混合數(shù)據(jù)平臺服務(wù)了校內(nèi)外的用戶，并介紹了其中的經(jīng)驗和見解。

2 背景及相關(guān)工作

2.1 異構(gòu)數(shù)據(jù)實時采集、計算和存儲

得益于各行各業(yè)信息化的普及和物聯(lián)網(wǎng)的發(fā)展，各行各業(yè)的數(shù)據(jù)量正以驚人的速度增長。同時，因為數(shù)據(jù)源不同，數(shù)據(jù)格式也多種多樣，呈現(xiàn)異構(gòu)特征。如何采集、傳輸和計算大量異構(gòu)的數(shù)據(jù)是一個非常大的挑戰(zhàn)。Apache Kafka是一個分布式的數(shù)據(jù)傳輸和共享系統(tǒng)。Apache Flume、Fluentd等都是廣泛應(yīng)用的數(shù)據(jù)采集傳輸工具。

不同的數(shù)據(jù)源會生成不同的數(shù)據(jù)，形成多維數(shù)據(jù)，數(shù)據(jù)字段和格式不相同。對有些數(shù)據(jù)如交換機流量甚至需要自己定義如何從數(shù)據(jù)流中分割出數(shù)據(jù)包。由于數(shù)據(jù)生成速度快而且數(shù)據(jù)量較大，不適合使用傳統(tǒng)的文件系統(tǒng)和關(guān)系型數(shù)據(jù)庫。需利用分布式的文件系統(tǒng)來進行實時存儲，并且選取的分布式文件系統(tǒng)需要很好地支持后續(xù)的計算。例如谷歌設(shè)計了GFS(Google File System)[3]來作分布式存儲。開源社區(qū)也開發(fā)了分布式文件系統(tǒng)HDFS(Hadoop Distributed File System)，廣泛用于各個大數(shù)據(jù)存儲處理場景。目前流行的企業(yè)內(nèi)部的數(shù)據(jù)湖(Data Lake)的做法也一般使用HDFS來做存儲。

2.2 異構(gòu)數(shù)據(jù)的計算

對于海量多源異構(gòu)數(shù)據(jù)，不太適合使用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫來存儲和查詢。所以，谷歌公司設(shè)計了名為BigTable[4]的數(shù)據(jù)模型，變schema-on-write為schema-on-read,數(shù)據(jù)可以非常靈活地以動態(tài)的標簽或者列名來存儲。谷歌公司同時提出了MapReduce[5]的分布式計算模型，通過使用Map和Reduce操作，可以非常方便地將計算擴展到大量機器上。開源社區(qū)也跟進開發(fā)了Hadoop系統(tǒng)來實現(xiàn)MapReduce操作，并使用HBase等NoSQL系統(tǒng)來存儲無結(jié)構(gòu)化數(shù)據(jù)。

2.3 按需分配、靈活可擴的云平臺

云計算在過去10年中得到了長足的發(fā)展，技術(shù)相對比較穩(wěn)定。在傳統(tǒng)的服務(wù)器操作系統(tǒng)層面，Xen、KVM以及后續(xù)的容器技術(shù)已經(jīng)發(fā)展成為穩(wěn)定的生產(chǎn)級別可用的技術(shù)。特別是KVM技術(shù)，有Redhat等Linux操作系統(tǒng)主要發(fā)行商支持，作為生產(chǎn)環(huán)境有很大的穩(wěn)定性保障。隨著虛擬數(shù)據(jù)中心技術(shù)的興起，也誕生了很多虛擬數(shù)據(jù)中心的開源項目，特別是Openstack，被IBM、HP、VMware等大公司共同推廣和維護，成為建設(shè)虛擬數(shù)據(jù)中心和云計算平臺的主流框架。

Openstack等云計算框架是“基礎(chǔ)設(shè)施即服務(wù)IaaS(Infrastructure as a Service)”的具體實現(xiàn)，可以提供靈活的虛擬數(shù)據(jù)中心方案。它提供了計算、存儲、網(wǎng)絡(luò)、鏡像、認證、計量等管理模塊以及其他模塊，用戶可以非常方便地創(chuàng)建自己的虛擬網(wǎng)絡(luò)，啟動虛擬主機并掛載虛擬硬盤，開始自己的業(yè)務(wù)，無需擔心底層的實現(xiàn)和運維。虛擬主機和存儲等模塊支持動態(tài)擴展和擴容，當用戶發(fā)現(xiàn)自己的資源緊張的時候，可以隨時請求更多的CPU、內(nèi)存、存儲以及虛擬機等資源。因此，云平臺對處理復雜多變的需求非常有效，這也是我們選擇將云平臺作為數(shù)據(jù)平臺動態(tài)擴展池的主要原因。

3 混合數(shù)據(jù)平臺架構(gòu)設(shè)計

根據(jù)已有成熟的開源軟件框架，搭建了數(shù)據(jù)平臺和私有云平臺。所有組件都是開源免費的。系統(tǒng)的總體架構(gòu)如圖1所示。具體組件及設(shè)計考慮會在下面幾節(jié)展開介紹。

Figure 1 Architecture of hybrid data platform圖1 混合數(shù)據(jù)平臺架構(gòu)

3.1 總體架構(gòu)

混合型數(shù)據(jù)平臺的總體架構(gòu)如圖1所示。一部分按數(shù)據(jù)平臺要求設(shè)計的物理服務(wù)器被專職用作數(shù)據(jù)平臺計算和存儲(圖1中標記Big Data的虛線框內(nèi)的服務(wù)器)。另外一部分物理服務(wù)器按照云計算的要求定制后，專職用做云計算的場景(圖1中標記Private Cloud的虛線框內(nèi)的服務(wù)器)。兩批服務(wù)器通過多個冗余的接入交換機接到數(shù)據(jù)中心網(wǎng)絡(luò)中。兩個集群的一部分服務(wù)器共享接入交換機，通過Rack aware的配置讓管理員和系統(tǒng)知道數(shù)據(jù)所處的網(wǎng)絡(luò)位置，為云和數(shù)據(jù)平臺之間的數(shù)據(jù)交換提供了高速通道。

3.2 私有云平臺架構(gòu)

校級云平臺架構(gòu)如圖2所示。底層是基礎(chǔ)設(shè)施層，采用了時下業(yè)界流行的Openstack框架來實現(xiàn)軟件定義網(wǎng)絡(luò)、彈性計算以及軟件定義存儲等功能。關(guān)于軟件定義存儲，我們將Openstack的塊存儲模塊Cinder和對象存儲開源軟件Ceph結(jié)合起來，將存儲資源虛擬化成存儲池，實現(xiàn)了塊存儲、對象存儲和文件存儲三種服務(wù)形式，為虛擬機或者其他用戶需求提供靈活穩(wěn)定的存儲服務(wù)。

Figure 2 Architecture of private cloud圖2 云平臺架構(gòu)及組件

關(guān)于計算模塊，我們使用了Openstack計算管理模塊Nova，并且用KVM來作為虛擬機的實現(xiàn)。我們并沒有選用性能更好的容器，是出于穩(wěn)定性和操作系統(tǒng)的多樣性考慮。在物理服務(wù)器上，我們使用了開源Linux操作系統(tǒng)的服務(wù)器發(fā)行版CentOS。

在圖2的中間部分，可以看到各種虛擬基礎(chǔ)設(shè)施的管理功能，基本是標準的Openstack開源組件，例如鏡像管理模塊Glance、網(wǎng)絡(luò)管理模塊Neutron、認證管理模塊Keystone和界面模塊Horizon等。我們對前端訪問做了負載均衡設(shè)計，對數(shù)據(jù)庫組件做了高可用設(shè)計，保障業(yè)務(wù)平穩(wěn)運行。我們也進行了部分定制，保證和校園內(nèi)的其他業(yè)務(wù)能夠無縫鏈接起來。

3.3 數(shù)據(jù)平臺架構(gòu)

設(shè)計的數(shù)據(jù)平臺如圖3所示。中間部分是數(shù)據(jù)平臺的核心組件，包括Hadoop的HDFS和YARN(Yet Another Resource Negotiator)資源調(diào)度管理器,都做了高可用設(shè)計，特別是針對控制結(jié)點使用了高可用方案。下面詳細介紹各部分的設(shè)計和考慮。

Figure 3 Architecture of big data platform圖3 大數(shù)據(jù)平臺架構(gòu)及組件

3.3.1 文件系統(tǒng)

使用Hadoop的分布式文件系統(tǒng)HDFS來儲存數(shù)據(jù)。HDFS的控制結(jié)點NameNode存儲了文件系統(tǒng)的元數(shù)據(jù)，因此NameNode需要提供高可用的熱備功能來保證NameNode長時在線。HDFS內(nèi)置了NameNode HA的實現(xiàn)。默認使用的是ZKFC(ZooKeeper Failover Controller)，使用Apache Zookeeper集群來做同步鎖。

數(shù)據(jù)平臺也采用默認的HA方案。使用兩臺物理結(jié)點(并且部署在不同機架上)來啟動兩個NameNode，配置三個結(jié)點為日志結(jié)點(JournalNode)，用于在兩個NameNode之間同步數(shù)據(jù)。使用ZKFC和Zookeeper集群來保證只有一個活躍NameNode結(jié)點，當活躍NameNode無響應(yīng)時主動切換到備用的NameNode。

3.3.2 高可用作業(yè)調(diào)度系統(tǒng)

使用Hadoop YARN來做調(diào)度器，自動調(diào)度和部署用戶的任務(wù)到不同機器上運行。資源管理器(ResourceManager)是YARN的一個重要組件，負責為所有的任務(wù)調(diào)度資源，因此資源管理器也需要高可用HA配置。在兩個結(jié)點分別配置兩個一樣的資源管理器，使用內(nèi)置的、利用Zookeeper集群的熱備系統(tǒng)來自動檢測失敗的資源管理器，并切換到活躍的資源管理器上。

3.3.3 查詢和計算

支持大部分的計算框架，包括將SQL轉(zhuǎn)換為MapReduce任務(wù)的Apache Hive、使用RDD(Resilient Distributed Datasets)[6]的Spark計算框架以及原生的MapReduce和Streaming任務(wù)。對于不習慣命令行的用戶，也提供了HUE來很方便通過網(wǎng)頁提交查詢、查看任務(wù)進展和查看結(jié)果或出錯信息。對于習慣使用IPython[7]Notebook風格來進行數(shù)據(jù)分析的用戶，也搭建了Jupyter Hub和Zepplin，讓用戶使用Python Notebook或者Spark Notebook來進行交互式的數(shù)據(jù)分析。

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

對于如何將數(shù)據(jù)導入到數(shù)據(jù)平臺中，使用以下三種方式：

對于流式數(shù)據(jù)，使用Apache Kafka來實時進行數(shù)據(jù)分享和交換，同時將數(shù)據(jù)導入到數(shù)據(jù)平臺的Hadoop中來做離線計算；

對于結(jié)構(gòu)化數(shù)據(jù)，使用Apache Sqoop來選取相關(guān)的數(shù)據(jù)表并且盡量按照原來的表結(jié)構(gòu)存儲到數(shù)據(jù)平臺的Hadoop中；

對于其它的各種以文件形式存在的數(shù)據(jù)，在進行格式轉(zhuǎn)換后上傳至數(shù)據(jù)平臺中。

3.3.5 其它配置

訪問控制方面，使用Kerberos[8]來驗證用戶的身份。對文件系統(tǒng)，根據(jù)文件的用戶和分組來進行訪問控制；對于Hive查詢，也使用Sentry來實現(xiàn)訪問控制。

針對監(jiān)控，部署了Zabbix、Grafana以及netdata，可以非常方便地查看整個系統(tǒng)資源的實時和歷史使用狀況。

另外，備份和恢復是每個系統(tǒng)必須考慮的問題。在應(yīng)用程序?qū)?HDFS)默認設(shè)置了三個數(shù)據(jù)副本，這樣既實現(xiàn)了高可用和高訪問吞吐量，也在一定程度上實現(xiàn)了數(shù)據(jù)的備份。三個數(shù)據(jù)副本分別在不同機架的不同機器中，避免了機器或者機架不可用時丟失數(shù)據(jù)的情況。很多元數(shù)據(jù)保存在關(guān)系型數(shù)據(jù)庫MySQL中，設(shè)計了MySQL集群來保證其高可用性，同時也做定期的備份。

3.4 混合數(shù)據(jù)平臺

本節(jié)介紹混合數(shù)據(jù)平臺工作調(diào)度器調(diào)度策略。在我們的數(shù)據(jù)平臺上有一個調(diào)度器，監(jiān)控集群負載，通過啟動或者停止虛擬機來彈性分配或者釋放私有云上的計算資源。調(diào)度器的工作流程如圖4所示。

Figure 4 Flow of controller for allocating new VMs圖4 調(diào)度器工作流程

從圖4可以看到，調(diào)度器是個無限循環(huán)精靈進程，檢查集群的負載。如果資源不夠，則從云上分配n個虛擬機VM(Virtual Machine)。基于數(shù)據(jù)三副本的考慮，每次分配的虛擬機數(shù)目n是3的倍數(shù)。如果本次分配虛擬機數(shù)n過小，不能滿足新任務(wù)的需求，則在下面幾個循環(huán)中會很快補足；如果本次分配虛擬機數(shù)過多，則在后面的循環(huán)中會被不斷回收。也通過不斷學習用戶提交任務(wù)的歷史數(shù)據(jù)，根據(jù)時間動態(tài)調(diào)整每次分配的虛擬機個數(shù)，避免每次都過多或者過少地分配虛擬機。虛擬機分配好后，這些新分配的虛擬機，和已經(jīng)存在的虛擬機，它們的活躍時間(Active Time)被更新為當前時間。如果本次循環(huán)發(fā)現(xiàn)集群資源充裕，則找出空閑的虛擬機，檢查這些空閑的虛擬機的活躍時間與當前時間的差值，空閑超出一定閾值t的虛擬機被釋放。閾值t是根據(jù)集群歷史負載和當前負載情況動態(tài)計算出來的，這樣可以避免頻繁分配和釋放虛擬機。

一般地，僅從云上補充計算資源。關(guān)于存儲，涉及數(shù)據(jù)的遷移，結(jié)點間的數(shù)據(jù)需要再平衡，網(wǎng)絡(luò)帶寬可能會成為瓶頸，所以除了本地讀寫可以加速的任務(wù)，一般不推薦使用數(shù)據(jù)存儲彈性方案。

4 應(yīng)用評估

本節(jié)介紹如何根據(jù)需求選取服務(wù)器來搭建生產(chǎn)環(huán)境，并作了基本的評估。

4.1 數(shù)據(jù)平臺部署

對數(shù)據(jù)平臺的服務(wù)器，我們簡單地按功能分為兩大類：一類是控制結(jié)點；另一類是計算和存儲結(jié)點。控制結(jié)點需要存取元數(shù)據(jù)，對內(nèi)存和存儲性能要求較高。所以，使用大內(nèi)存結(jié)點(256 GB)，存儲介質(zhì)使用了4+塊高性能、大容量的閃存固態(tài)盤SSD(Sold State Drives)，這些固態(tài)盤配置成磁盤陣列RAID10模式(磁盤組內(nèi)是RAID1，磁盤組間是RAID0)，容錯能力比較好。計算和存儲結(jié)點的存儲容量要求較高，為了更好地利用磁盤空間，給每個結(jié)點選用了12塊6TB的磁盤，并且配置成JBOD(Just a Bunch of Disks)模式，對于數(shù)據(jù)安全和負載平衡，則通過數(shù)據(jù)平臺軟件在多機間實現(xiàn)。另外，對所有結(jié)點都額外配置了2塊10 KRPM 600 GB熱插拔硬盤，將其配置成RAID1給操作系統(tǒng)使用。結(jié)點間使用了雙路萬兆網(wǎng)卡互聯(lián)。在操作系統(tǒng)內(nèi)使用動態(tài)鏈路聚合模式將兩路鏈接聚合起來，帶寬加倍可達到20 Gbps。兩種服務(wù)器配置如表1所示。第一期我們購置了16臺服務(wù)器，包括4臺控制結(jié)點、12臺計算和存儲結(jié)點，總存儲容量接近900 TB。第二期在2017年底會擴容10倍，后期計劃擴容至目前規(guī)模的30倍左右。

Table 1 Specifications of servers for big data platform

Openstack云平臺主要為校內(nèi)約6萬師生教職工的科研、教學活動提供服務(wù)，同時作為數(shù)據(jù)平臺的彈性擴展池，在數(shù)據(jù)平臺資源匱乏時，也提供計算資源。目前整個集群有40臺2U服務(wù)器，第二期在2017年底會擴容4～5倍。

4.2 測試配置

本節(jié)的目的是驗證混合數(shù)據(jù)平臺可以按照預期來提供服務(wù)。數(shù)據(jù)平臺基本組件都是基于開源軟件和推薦配置，所以我們的目的不是和其他平臺進行性能比較。我們的目的是對系統(tǒng)進行測試以驗證性能和功能符合預期，并且提供結(jié)果給用戶來估計任務(wù)耗時。有關(guān)數(shù)據(jù)平臺的性能測試，學術(shù)界、產(chǎn)業(yè)界和開源社區(qū)已經(jīng)有大量很好的工作。有關(guān)測試工具，用戶可以參考中國科學院計算技術(shù)研究所的BigDataBench[9]以及英特爾公司的HiBench[10]。本文選擇HiBench 5.0版本來進行測試。

本文測試的主要軟件版本如表2所示。

Table 2 Software configuration

使用MapReduce任務(wù)來測試數(shù)據(jù)平臺，因為我們發(fā)現(xiàn)很多用戶仍然使用MapReduce (或者間接通過Hive產(chǎn)生MapReduce任務(wù))，并且MapReduce任務(wù)執(zhí)行時間較長，對CPU、內(nèi)存、網(wǎng)絡(luò)資源都有需求。限于篇幅沒有展示對內(nèi)存、磁盤使用優(yōu)化得更好的Spark框架的評估結(jié)果。

4.3 測試及分析

下面幾個測試的場景是：物理集群的資源已經(jīng)全部被用戶任務(wù)占滿，新來的任務(wù)要么等在調(diào)度隊列中，要么分到很小的資源配額來緩慢運行。物理集群資源用完后才分配虛擬機來擴展，理由如下：如果物理集群的資源未飽和時，添加私有云虛擬機并調(diào)度任務(wù)的部分或者全部子任務(wù)到云主機上運行，被調(diào)度到云上的任務(wù)的完成時間可能會變長，因為物理集群的性能要遠遠高于云主機(云主機服務(wù)器的CPU進行了超售Over provision，即云主機的云CPU性能一般是要低于物理機的CPU，云主機間的網(wǎng)絡(luò)帶寬也被限速至0.5 Gbps，而物理集群內(nèi)部是雙萬兆聚合，可達20 Gbps。也在考慮給大數(shù)據(jù)平臺的擴展虛擬機進行特殊的網(wǎng)絡(luò)設(shè)置，提高帶寬，這是將來的工作)。所以，一般在物理集群資源用盡后才擴展到私有云上，這樣充分利用了物理集群的處理能力，又避免了與云上用戶爭奪資源。

4.3.1 可擴展性測試

在本節(jié)想確認系統(tǒng)的處理能力是否會隨著虛擬機的不斷加入而不斷增強。通過運行相同的任務(wù)，但是不斷添加計算資源，來觀察任務(wù)的執(zhí)行時間，從而判斷系統(tǒng)的處理能力是否得到增強。通過停止或者壓測物理集群上的計算結(jié)點來使物理集群的資源不可用，從而使集群任務(wù)調(diào)度器YARN把子任務(wù)調(diào)度到新增加的虛擬機上來，以驗證新添加的資源的有效性及可擴展性。

圖5顯示了可擴展性測試的結(jié)果。分別啟動3個、6個、9個虛擬機(8個云CPU核16 GB內(nèi)存，下同)，然后由物理集群的YARN調(diào)度HiBench中的Terasort排序任務(wù)，使用Hadoop MapReduce框架執(zhí)行。可以明顯看出，隨著虛擬機個數(shù)的增多，任務(wù)的執(zhí)行時間急劇減少。這符合我們的預期。用集群中的三臺物理機做了對比(兩個CPU共32線程、128 GB內(nèi)存)，圖5也驗證了物理機的性能要遠遠高于虛擬機的。所以，在資源有空余的情況下，會優(yōu)先把用戶的任務(wù)調(diào)度到物理機上。

Figure 5 Scalability test (Hibench Scale:huge)圖5 可擴展性測試 (HiBench擴展度:huge)

通過圖5觀察到性能增加并非是線性的，這是由任務(wù)的特性決定的，下一節(jié)將專門進行分析。

4.3.2 負載類型測試

上節(jié)根據(jù)用戶任務(wù)對計算、磁盤、網(wǎng)絡(luò)等資源使用的使用情況，將用戶任務(wù)簡單分為計算密集型和IO密集型兩種。計算密集型的任務(wù)主要消耗CPU和內(nèi)存，而IO密集型任務(wù)則需要更多的磁盤存取操作和網(wǎng)絡(luò)傳輸操作。

排序測試Terasort在使用MapReduce框架時涉及大量的磁盤讀寫和網(wǎng)絡(luò)傳輸。從圖5a中可以看到，即使云主機的IO性能與物理機差距很大，但是在增加虛擬機結(jié)點個數(shù)后，性能仍然得到不斷提升。

Figure 6 Evaluation with mixed tasks (Scale:large)圖6 混合任務(wù)測試 (擴展度:large)

Pagerank排序算法涉及很多迭代過程，是計算密集型任務(wù)。圖5b也顯示了當虛擬機個數(shù)不斷增加時，Pagerank任務(wù)的執(zhí)行時間也不斷減少。

從圖5也看到，增加虛擬機的個數(shù)，性能并非線性增加，這是由任務(wù)的本身特性決定的。增加資源只能減少高并發(fā)度子任務(wù)的運行時間，其他部分的時間并沒有減少。例如，Pagerank算法，初始時有很多并行的子任務(wù)，需要大量的計算資源，因此增加虛擬機個數(shù)顯著增加了并行度，所以前期的計算時間顯著減少。后期部分不斷迭代收斂時，不需要很多計算資源，而且后期迭代次數(shù)是比較穩(wěn)定的，所以即使前期高度并行計算部分的時間大大減少了，但是后面迭代的時間并沒有改變，所以總的執(zhí)行時間不會減少太多。這就是我們從圖5b中看到的從6 VMs到9 VMs時，性能提升并不明顯?？梢灶A計，再增加更多的虛擬機，性能提升也不明顯。但是，如果我們增大任務(wù)的并行度需求，例如增大數(shù)據(jù)量，增加虛擬機后性能提升仍然是非常顯著的。

4.3.3 混合任務(wù)測試

在本節(jié)模擬多用戶同時執(zhí)行各類型任務(wù)的場景。HiBench 5.0默認是順序啟動任務(wù)，前面任務(wù)結(jié)束后再啟動下一個任務(wù)。我們稍微改動了HiBench 5.0的任務(wù)啟動腳本，讓所有任務(wù)同時啟動執(zhí)行。這些任務(wù)包括Aggregation、Kmeans、Pagerank、Wordcount、Bayes和Terasort。執(zhí)行的時間長短也不一，既有幾分鐘即可完成的任務(wù)，如Wordcount，也有長達幾小時的任務(wù)，如Bayes。

圖6展示了同時啟動多個不同類型負載后的執(zhí)行時間。我們可以看到，各種任務(wù)混合在一起，隨著虛擬機資源的增大(3 VMs到9 VMs)，執(zhí)行時間明顯縮短，處理能力不斷提升。

我們又觀察到了性能增加并非是線性的，即從6 VMs到9 VMs，性能增加不顯著。上一節(jié)專門做了分析，此處原因類似。我們認為，增大數(shù)據(jù)量，提高并行度，對資源需求量明顯增大，那么增加資源后性能提升的效果才會明顯。

4.3.4 物理集群和虛擬機共同執(zhí)行任務(wù)

前文給出的性能測試結(jié)果是在物理集群負載飽和時擴展到云主機后的場景。本節(jié)也簡單討論一下物理集群未滿載時啟動云虛擬機這種場景。直觀上講，添加云主機對資源需求較大的任務(wù)是有幫助的，特別是一些并行度較大、子任務(wù)間通信較少的任務(wù)(云主機之間帶寬遠小于物理集群)。然而，對并行度不大但是迭代和歸并通信要求較多的場景，添加云虛擬機并不會提高性能，因為云虛擬機的CPU的性能沒有物理服務(wù)器好，特別地，云虛擬機的網(wǎng)絡(luò)帶寬被限制在0.5 Gbps，而物理集群的網(wǎng)絡(luò)帶寬是20 Gbps，遠高于云主機的帶寬。圖7給出了物理集群負載未飽和狀態(tài)下的擴展性測試結(jié)果?？梢钥吹絾渭兪褂梦锢頇C器(3BMs)集群時，性能比后面添加虛擬機性能要好。這也驗證了我們的猜測。所以，我們只在物理集群負載飽和的狀態(tài)下添加云虛擬機來接收新負載。我們在不斷探索各種負載類型，尋找最優(yōu)的場景使用云虛擬機來擴展集群；也在探討使用專門的網(wǎng)絡(luò)來連接兩個集群，消除網(wǎng)絡(luò)帶寬的瓶頸。

Figure 7 Scalability test when bare metal cluster is not fully loaded (Terasort MR,Scale:huge.Data Nodes are started on VMs)圖7 物理集群未飽和狀態(tài)下的擴展性測試 (Terasort MR,HiBench擴展度:huge,云主機上數(shù)據(jù)結(jié)點也啟動起來)

4.3.5 虛擬機及數(shù)據(jù)平臺程序啟動時延

在生產(chǎn)環(huán)境中，我們目測到的啟動時延約為數(shù)秒。我們并沒有進行精確的定量分析，因為面向的場景一般是高負載持續(xù)數(shù)十分鐘或數(shù)小時甚至更長時間段。

在我們的測試中，虛擬機及數(shù)據(jù)平臺程序數(shù)秒的啟動延時對性能加速的影響很小，可以忽略不計。我們也有興趣在將來研究在極端情況下(例如云平臺負載很高的情況下)，用于擴展的虛擬機的啟動時延及其他因素的影響；我們也有興趣測試頻繁啟動和銷毀擴展虛擬機時系統(tǒng)的加速情況。限于篇幅，在此不作討論。

5 生產(chǎn)應(yīng)用

目前我們使用數(shù)據(jù)平臺集群支撐了校內(nèi)上網(wǎng)行為分析、基因序列拼接、自然語言處理研究以及各種數(shù)據(jù)比賽，包括大規(guī)模的上海開放數(shù)據(jù)創(chuàng)新應(yīng)用大賽SODA(Shanghai Open Data Apps)，具體細節(jié)可以參考我們2016年的工作[11]。數(shù)據(jù)平臺以項目或者課題組申請的方式來申請使用，不開放給個人申請，以保證重要的項目及課題組能有充分的資源。對分散的個人任務(wù)，我們推薦在私有云上搭建自己的平臺進行小規(guī)模測試和分析。目前數(shù)據(jù)平臺在平時的磁盤使用量為20 TB以上(三副本約60 TB以上)。上線一年多累計運行了1萬多個用戶分析任務(wù)。

6 結(jié)束語

嘗試完全使用開源軟件設(shè)計并配置了一個彈性數(shù)據(jù)平臺。該數(shù)據(jù)平臺主要構(gòu)筑在物理服務(wù)器上，保證了分析性能，當資源緊張時，可以動態(tài)擴展到私有云平臺上。私有云平臺也是同樣基于開源軟件構(gòu)建的。構(gòu)建了生產(chǎn)環(huán)境并服務(wù)了廣大師生，以及社會上的專業(yè)賽事。使用開源的評測工具給出了初步的分析結(jié)果并提供了我們的見解。將來會更加深入地測試多個影響調(diào)度性能的因素。

[1] Thusoo A,Sarma J,Jain N,et al.Hive-A warehousing solution over a map-reduce framework[J]. Proceedings of the VLDB Endowment, 2009 2(2):1626-1629.

[2] Zaharia M,Chowdhury M,Franklin M J,et al.Spark:Cluster computing with working sets[C]∥Proc of the 2nd USENIX Workshop on Hot Topics in Cloud Computing,2010:10.

[3] Ghemawat S,Gobioff H,Leung S.The Google file system[C]∥Proc of the 19th ACM Symposium on Operating Systems Principles,2003:29-43.

[4] Chang F,Dean J,Ghemawat S,et al:Bigtable:A distributed storage system for structured data[C]∥Proc of the 7th Symposium on Operating Systems Design and Implementation(OSDI 2006),2006:205-218.

[5] Dean J,Ghemawat S.MapReduce:Simplified data processing on large clusters[C]∥Proc of the 6th Symposium on Operating System Design and Implementation (OSDI 2004),2004:137-150.

[6] Zaharia M,Chowdhury M,Das T,et al.Resilient distributed datasets:A fault-tolerant abstraction for in-memory cluster computing[C]∥Proc of the 9th USENIX Symposium on Networked Systems Design and Implementation,2012:15-28.

[7] Bernard J. Running scientific code using IPython and SciPy[J].Linux Journal,2013(228):Article No.3.

[8] Neuman B C,Ts’o T. Kerberos:An authentication service for computer networks[J].IEEE Communications,1994,32 (9):33-38.

[9] Wang Lei, Zhan Jian-feng, Luo Chun-jie, et al.BigDataBench:A big data benchmark suite from internet services[C]∥Proc of the 20th IEEE International Symposium on High Performance Computer Architecture,2014:488-499.

[10] Huang S, Huang J, Dai J,et al.The HiBench benchmark suite:Characterization of the MapReduce-based data analysis[C]∥Proc of the 26th International Conference on Data Engineering,2010:41-51.

[11] Wang Yong-kun, Jin Yao-hui.Design of data platform and application in data competition [J/OL].Journal of Frontiers of Computer Science and Technology,2017-04-12. [2017-09-25].http://kns.cnki.net/kcms/detail/11.5602.TP.20170412.1115.002.html.(in Chinese)

[12] Bhardwaj A P,Deshpande A,Elmore A J,et al.Collaborative data analytics with dataHub[J].Proceedings of the VLDB Endowment,2015:1916-1919.

[13] Armbrust M,Xin R S,Lian C,et al.Spark SQL:Relational data processing in Spark[C]∥Proc of the 2015 ACM SIGMOD International Conference on Management of Data (SIGMOD’15),2015:1383-1394.

[14] Melnik S,Gubarev A,Long J,et a.Dremel:Interactive analysis of web-scale datasets[J].Communications of the ACM,2011,54(6):114-123.

[15] Johnson T.Performance measurements of compressed bitmap indices[C]∥Proc of the 25th International Conference on Very Large Data Bases (VLDB’99),1999:278-289.

[16] DeCandia G,Hastorun D,Jampani M,et al.Dynamo:Amazon’s highly available key-value store[C]∥Proc of the 21st ACM Symposium on Operating Systems Principles, 2007:205-220.

附中文參考文獻：

[16] 王永坤,金耀輝.數(shù)據(jù)平臺的設(shè)計和實現(xiàn)以及大賽中的應(yīng)用[J/OL].計算機科學與探索,2017-04-12. [2017-09-25].http://kns.cnki.net/kcms/detail/11.5602.TP.20170412.1115.002.html.