王永坤，金耀輝,2+

1.上海交通大學 網(wǎng)絡信息中心，上海 200240

2.上海交通大學 光纖通信國家重點實驗室，上海 200240

1 引言

大數(shù)據(jù)研究及應用在最近幾年得到了快速發(fā)展。大數(shù)據(jù)對各個行業(yè)的運行方式都產(chǎn)生了重大影響。在行政方面，大數(shù)據(jù)利用民生數(shù)據(jù)等幫助提高治理水平；在產(chǎn)業(yè)方面，大數(shù)據(jù)在需求、物流、營銷等各個環(huán)節(jié)提供優(yōu)化建議；在科學研究方面，大數(shù)據(jù)加速科學數(shù)據(jù)分析，幫助發(fā)現(xiàn)新領域。國家也對大數(shù)據(jù)技術高度重視?！笆濉币?guī)劃中提出了“國家大數(shù)據(jù)戰(zhàn)略”。國務院印發(fā)了《促進大數(shù)據(jù)發(fā)展行動綱要》，推動形成公共信息資源共享共用和大數(shù)據(jù)產(chǎn)業(yè)健康發(fā)展的良好格局。以往塵封的數(shù)據(jù)都在國家政策指導下逐步開放，特別是城市數(shù)據(jù)，關系民生，價值巨大，推動了智慧城市的發(fā)展。

經(jīng)過近幾年的研究和實踐，大數(shù)據(jù)的很多理論和系統(tǒng)架構都逐漸成熟。但是在實際應用中，仍然有很多挑戰(zhàn)。例如城市的數(shù)據(jù)主管部門可能缺乏大數(shù)據(jù)的存儲和計算的設施；數(shù)據(jù)分析平臺無法最大限度地共享數(shù)據(jù)的同時又隔離有害代碼，保證數(shù)據(jù)和計算平臺的安全等。

已有很多研究和系統(tǒng)在解決這些問題。開源社區(qū)提供了很多開源大數(shù)據(jù)解決方案，例如Apache Hadoop、Apache Hive[1]、Apache Spark[2]，來解決數(shù)據(jù)的存儲、查詢和計算，并且有專門公司提供企業(yè)級服務。在數(shù)據(jù)平臺之上，提供了HUE、Jupyter、Zepplin等交互計算接口，并提供基本的訪問控制。在學術界，DataHub[3]是MIT開發(fā)的一個試驗性的平臺，提供了數(shù)據(jù)的存儲、共享和協(xié)作服務；用戶可以發(fā)布自己的數(shù)據(jù)，也可以使用別人的數(shù)據(jù)。數(shù)據(jù)集有版本。用戶可以通過Thrift使用不同的語言來操作數(shù)據(jù)。俄勒岡健康與科學大學（Oregon Health and Science University）與英特爾公司（Intel）合作建立了一個精準醫(yī)療分析平臺，用于共享分析各機構的醫(yī)療數(shù)據(jù)，同時保護患者的隱私1）http://www.ohsu.edu/blogs/96kmiles/2015/08/20/intel-ohsu-announce-collaborative-cancer-cloud-at-intel-developer-forum/。。工業(yè)界有很多建立在云上的大數(shù)據(jù)平臺方案，包括國外的亞馬遜云AWS（Amazon Web services）、谷歌云平臺大數(shù)據(jù)產(chǎn)品、微軟云（Azure）上的Hadoop，國內(nèi)有阿里云大數(shù)據(jù)服務ODPS（open data processing service）、天池及數(shù)加，騰訊大數(shù)據(jù)，百度大數(shù)據(jù)+。

上面提到的方案中，學術界的新想法需要更多實踐來驗證；工業(yè)界的方案規(guī)模大，技術水平高，相對而言成本也比學校等非盈利機構的平臺要高，而且涉及的知識產(chǎn)權問題等較嚴格，數(shù)據(jù)開放共享的難度較大。

因此，本文的目的是完全獨立地使用開源社區(qū)的解決方案來搭建一個一站式的共享數(shù)據(jù)、計算和代碼的數(shù)據(jù)平臺。本文的平臺完全使用開源軟件，自己選取設計組件，自己搭建和運維。開源軟件代碼公開并且由開源社區(qū)維護，非常適合高校這種IT經(jīng)費相對較少但是智力資源較多的環(huán)境。本文的平臺用于校內(nèi)及部分公開服務，也定期提供給數(shù)據(jù)大賽這種大規(guī)模、高強度、集中式、密集計算的場景使用。根據(jù)了解，這在國內(nèi)外高校中也是一種大膽的嘗試，希望該經(jīng)驗可以給其他院校和機構一些參考。

本文的貢獻概括如下：

（1）設計了一種數(shù)據(jù)和計算共享的數(shù)據(jù)平臺架構，包含了數(shù)據(jù)平臺和代碼倉庫，代碼可以自動調(diào)度到平臺上運行；

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

（3）使用這個數(shù)據(jù)平臺服務了大規(guī)模的上海開放數(shù)據(jù)創(chuàng)新應用大賽，介紹了其中的經(jīng)驗和見解。

本文內(nèi)容組織如下：第2章介紹問題背景及需求；第3章介紹系統(tǒng)架構設計；第4章介紹系統(tǒng)的基本評估；第5章介紹數(shù)據(jù)平臺在上海開放數(shù)據(jù)創(chuàng)新應用大賽中的應用；第6章總結全文。

2 背景及需求

2.1 異構數(shù)據(jù)實時采集和存儲

得益于各行各業(yè)信息化的普及和物聯(lián)網(wǎng)的發(fā)展，數(shù)據(jù)量正以驚人的速度增長。同時因為數(shù)據(jù)源不同，所以數(shù)據(jù)格式也多種多樣，呈現(xiàn)異構特征。如何采集、傳輸和存儲大量異構的數(shù)據(jù)是一個非常大的挑戰(zhàn)。

采集程序通常分為實時采集和批量采集。實時采集的程序直接和生產(chǎn)環(huán)境的數(shù)據(jù)源對接，將最新生成的數(shù)據(jù)直接傳回。一般采集程序是非常輕量級的，不能影響生產(chǎn)環(huán)境的運行，并且可以斷點續(xù)傳。批量采集程序一般是針對離線庫或者備份定期進行大量數(shù)據(jù)回傳，對生產(chǎn)環(huán)境的影響較小。

數(shù)據(jù)的可靠傳輸可以保證數(shù)據(jù)不丟包，最后的運算結果不出現(xiàn)偏差。一般的做法是針對每個或者多個數(shù)據(jù)包，接收端采取回復確認包（ACK）的方式來確保數(shù)據(jù)正確收到。沒有收到的數(shù)據(jù)會要求重傳。ACK的管理可以是集中式或者分布式。集中式的回傳確認方式是發(fā)送方將已發(fā)數(shù)據(jù)包編號發(fā)給全局控制節(jié)點，接收方收到包后也將確認包發(fā)給同一個控制節(jié)點，控制節(jié)點來控制是否重發(fā)。優(yōu)點是實現(xiàn)非常簡單；缺點是控制節(jié)點可能成為性能瓶頸，并且有可能成為單點故障點（single point of failure，SPOF）。比較魯棒的做法是讓每個節(jié)點維護已發(fā)送包列表和確認包列表，將確認包一直回傳至源發(fā)送節(jié)點。這種分布式的實現(xiàn)方式吞吐量大，整個系統(tǒng)可靠性高，但是實現(xiàn)復雜。第三種方式是使用集中的分布式存儲來緩存數(shù)據(jù)，發(fā)送方和訂閱方可以在一跳內(nèi)得到數(shù)據(jù)。這種方式需要分布式存儲，并且發(fā)送方和訂閱方一般需要在同一子網(wǎng)內(nèi)。本文采用第三種方式，利用Kafka來實現(xiàn)數(shù)據(jù)的傳輸和短期分享。

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

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

對于多源異構數(shù)據(jù)，如果使用傳統(tǒng)的關系型數(shù)據(jù)庫來處理，需要事先定義好數(shù)據(jù)結構，然后導入數(shù)據(jù)，使用昂貴的硬件來支撐，并且擴展性不好，這不適合大量數(shù)據(jù)的場景。因此，谷歌設計了名為Big-Table[5]的數(shù)據(jù)模型，變schema-on-write為schema-onread，數(shù)據(jù)可以非常靈活地以動態(tài)的標簽或者列名來存儲。谷歌同時提出了MapReduce[6]的分布式計算模型，通過使用Map和Reduce操作，可以非常方便地將計算擴展到大量機器上。

很多傳統(tǒng)的數(shù)據(jù)分析人員仍然偏好使用結構化查詢語言（structured query language，SQL）來進行數(shù)據(jù)分析。因此，對于一個數(shù)據(jù)平臺也需要考慮將SQL轉(zhuǎn)換成分布式的查詢和計算，降低傳統(tǒng)分析人員的學習曲線。目前SQL-on-XXX技術也比較成熟，比如Apache Hive和Spark SQL等。

2.3 數(shù)據(jù)共享、計算隔離

大規(guī)模數(shù)據(jù)平臺一般由不同組織、部門的分析人員來共享。即使同一部門的人員，也可能由于業(yè)務原因，需要對不同業(yè)務數(shù)據(jù)進行訪問控制。因此，數(shù)據(jù)平臺需要細粒度地支持不同的共享訪問方案；需要支持對數(shù)據(jù)的分層抽象而不需要額外的存儲空間；可以對接和集成常規(guī)的認證機制來保證用戶身份的真實性；需要支持經(jīng)典的角色訪問控制機制（role-based access control，RBAC），來給不同業(yè)務、部門、組織的人員進行權限控制；對于更精細粒度和更加靈活的訪問控制需求，需要平臺能夠支持屬性訪問控制機制（attribute-based access control，ABAC）。

對于計算，需要平臺支持不同的調(diào)度，可以按照各種屬性或者優(yōu)先級來分配資源給不同的任務。同時對同等優(yōu)先級的任務，需要保證公平。

Fig.1 Architecture of data platform圖1 數(shù)據(jù)平臺架構及組件

如果數(shù)據(jù)平臺開放給公眾使用，則可能需要對提交的任務代碼進行審核。一般數(shù)據(jù)平臺運算的代碼基本都是編譯好的代碼，即使一些腳本語言寫的代碼，在運行時進行檢查也比較困難。因此，需要在數(shù)據(jù)平臺集成代碼倉庫的功能，以便按需審核任務代碼。

3 數(shù)據(jù)平臺架構設計

本文根據(jù)已有成熟的開源軟件框架，搭建了數(shù)據(jù)平臺。所有組件基本都是開源免費的，因為開源軟件代碼公開，并且由開源社區(qū)維護，非常適合高校這種IT經(jīng)費相對較少但是智力資源較多的環(huán)境。本文設計的基本架構如圖1所示。具體組件及設計方法會在下面幾節(jié)展開介紹。

3.1 高可用存儲系統(tǒng)

本文使用Hadoop分布式文件系統(tǒng)（HDFS）來儲存數(shù)據(jù)。HDFS的控制節(jié)點NameNode存儲了文件系統(tǒng)的元數(shù)據(jù)。如果NameNode崩潰，整個分布式文件系統(tǒng)會停止工作。因此NameNode非常重要，需要提供高可用的熱備功能來保證NameNode常時在線。Hadoop文件系統(tǒng)早期版本并沒有內(nèi)置熱備（failover）功能，待機的Secondary NameNode并不能接替崩潰的主NameNode。很多機構或者公司開發(fā)了自己的高可用（high availability，HA）版本。也有一些設計依賴外部HA機制，如DRBD（distributed replicated block device）。直到Hadoop 2.0發(fā)布，內(nèi)置了HA的實現(xiàn)。默認使用的是ZKFC（Zookeeper failover controller），使用Apache Zookeeper集群來進行同步鎖。

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

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

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

3.3 安全控制

本文使用Kerberos[7]來驗證用戶的身份。Kerberos是一個“客戶端-服務器”模式的驗證模型。用戶先向認證服務器請求認證，獲準后方可向服務器請求服務。

對于權限控制，使用了RBAC機制。對文件系統(tǒng)，根據(jù)文件的用戶和分組來進行訪問控制；對于Hive查詢，也使用Sentry來實現(xiàn)訪問控制。

3.4 查詢和計算

本文的數(shù)據(jù)平臺支持大部分的計算框架，包括將SQL轉(zhuǎn)換為MapReduce任務的Apache Hive，使用RDD（resilient distributed datasets）[8]的 Spark 計算框架，以及原生的MapReduce和Streaming任務。

Apache Hive仍然是傳統(tǒng)商業(yè)智能（business intelligence，BI）分析人員偏好的工具?？梢允褂肧QL來操作數(shù)據(jù)，易于上手。Spark SQL[9]也類似，使用SQL在Spark計算框架上方便地進行數(shù)據(jù)操作。對于不習慣命令行的用戶，也提供了HUE（Hadoop user experience）很方便地通過網(wǎng)頁來提交查詢，查看任務進展和查看結果或出錯信息。

對于習慣于使用IPython[10]Notebook風格來進行數(shù)據(jù)分析的用戶，也搭建了Jupyter Hub和Zepplin給用戶使用Python Notebook或者Spark Notebook來進行交互式的數(shù)據(jù)分析。

另外也開放了數(shù)據(jù)倉庫和商業(yè)智能系統(tǒng)的接口，可以使傳統(tǒng)的數(shù)據(jù)分析工具如Qlik方便地接入。

3.5 數(shù)據(jù)質(zhì)量分析

用戶上傳到數(shù)據(jù)平臺的多源異構數(shù)據(jù)通常非常雜亂。即使用戶以為整理好的結構化的數(shù)據(jù)，歷經(jīng)多次數(shù)據(jù)導入、系統(tǒng)升級等操作，實際也可能存在字段值缺失、不規(guī)范、類型不統(tǒng)一等問題。因此需要工具來幫助用戶方便地查看數(shù)據(jù)質(zhì)量，直觀地給出數(shù)據(jù)質(zhì)量報告，并且?guī)椭C正不正確的數(shù)據(jù)。

本文使用OpenRefine來幫助用戶快速理解數(shù)據(jù)字段各種數(shù)據(jù)的分布情況，同時幫助用戶改正、增強相關數(shù)據(jù)。對于數(shù)據(jù)量比較大的情況，將數(shù)據(jù)統(tǒng)計分析做成MapReduce任務，在集群上調(diào)度執(zhí)行。

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

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

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

（2）對于結構化數(shù)據(jù)，使用Apache Sqoop來選取相關的數(shù)據(jù)表，并且盡量按照原來的表結構存儲到數(shù)據(jù)平臺的Hadoop中；

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

3.7 其他組件

本文在數(shù)據(jù)平臺中集成了如下組件：

搜索引擎及查詢可視化系統(tǒng)（Elastic&Kibana）。用戶數(shù)據(jù)被轉(zhuǎn)成JSON（JavaScript object notation）格式，然后存入Elastic集群中并被索引。用戶可以使用Kibana界面來方便地查詢并且實時地可視化結果。

為了滿足一部分用戶的近似實時的數(shù)據(jù)存取需求，提供了NoSQL數(shù)據(jù)庫，如Apache Cassandra。Cassandra上層使用的是BigTable的數(shù)據(jù)模型，數(shù)據(jù)存取非常靈活；底層使用的是亞馬遜Dynamo[11]的P2P架構，可用性和可靠性非常高。

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

所有的部署和運維都是由集群自動化工具Ansible來完成的，重復部署及擴展都很方便。部署和運維腳本開發(fā)完成后，可以比較容易地將配置從數(shù)十臺機器擴展到數(shù)百臺甚至更多。

3.8 代碼倉庫、審核和調(diào)度

對于用戶來講，也希望能有一站式的代碼存儲和數(shù)據(jù)查詢的服務。傳統(tǒng)做法是將代碼提交至Github或者Bitbucket等公有的代碼倉庫，或者企業(yè)、私人的存儲空間中，并將代碼移到數(shù)據(jù)提供方來進行查詢，這種方式比較繁瑣。對于數(shù)據(jù)平臺維護方來說，希望能將有限的資源盡可能有效利用起來，同時也希望數(shù)據(jù)平臺能免于惡意代碼的攻擊。

針對上述用戶的需求，本文在數(shù)據(jù)平臺中集成了帶版本控制的代碼倉庫的功能，使用GitLab來搭建代碼存儲和版本控制系統(tǒng)。通過GitLab搭建的代碼管理系統(tǒng)，和Github功能類似，可以使用git來管理代碼版本，可以瀏覽代碼，管理缺陷及注釋，并支持團隊協(xié)作開發(fā)。這樣可以幫助平臺運維方來掌控用戶的代碼，避免惡意代碼損害平臺和其他用戶的資源。

本文針對用戶的代碼進行初步的檢查，幫助用戶提前發(fā)現(xiàn)代碼中遺漏的問題，并且阻止惡意代碼。代碼的自動檢查是個非常大的挑戰(zhàn)，已有的技術主要是針對代碼的靜態(tài)分析。Facebook Infer可以檢查Java、C和Objective-C代碼；對于Java，也可以使用經(jīng)典的FindBugs結合Jenkins，在代碼集成測試的時候進行分析；對于Python代碼可以使用Pylint；對于C和C++代碼，可以使用經(jīng)典的Valgrind來進行分析。Cloudera還使用了商業(yè)軟件來對代碼進行安全掃描2）Quality Assurance at Cloudera:Static Source-Code Analysis,https://blog.cloudera.com/blog/2016/03/quality-assurance-at-clouderastatic-source-code-analysis/。。

除了掃描用戶的源代碼外，還對數(shù)據(jù)進行了細粒度的訪問控制。給數(shù)據(jù)和帳號仔細設置了訪問權限，最大限度限制了每個帳號對系統(tǒng)的無關訪問。并且調(diào)整Hadoop/Spark的資源分配算法，保證在公平的前提下資源盡量得到充分利用。

本文并沒有對用戶的代碼性能進行分析和改進，但會推薦用戶自己選用合適的數(shù)據(jù)結構和存儲方式來加速計算，也推薦用戶使用平臺內(nèi)置的工具來幫助提高執(zhí)行速度，比如使用Apache Hive的EXPLAIN命令來查看執(zhí)行計劃。

本文設定一些限制條件來選取代碼倉庫的代碼到數(shù)據(jù)平臺運行。開設“發(fā)布（release）”代碼分支倉庫讓用戶將準備好的代碼提交進來。只有源代碼分析通過的任務才會被調(diào)度到數(shù)據(jù)平臺上執(zhí)行。

3.9 系統(tǒng)備份和恢復

備份和恢復是每個系統(tǒng)必須考慮的問題。本文的數(shù)據(jù)平臺的存儲系統(tǒng)存儲了大量數(shù)據(jù)，對此在應用程序?qū)樱℉DFS）默認設置了3個數(shù)據(jù)副本，這樣既實現(xiàn)了高可用和高訪問吞吐量，也在一定程度上實現(xiàn)了數(shù)據(jù)的備份。3個數(shù)據(jù)副本分別在不同機架的不同機器中，避免了機器或者機架不可用時丟失數(shù)據(jù)的情況。元數(shù)據(jù)也同樣重要，本文的數(shù)據(jù)平臺主要有文件系統(tǒng)元數(shù)據(jù)、查詢系統(tǒng)Hive元數(shù)據(jù)。文件系統(tǒng)的元數(shù)據(jù)存儲在控制節(jié)點中，3.1節(jié)介紹了高可用的控制節(jié)點設計，兩個控制節(jié)點互為備份。因為元數(shù)據(jù)總量較小，所以也在考慮使用離線備份工具備份并保存最近的數(shù)據(jù)。查詢系統(tǒng)Hive元數(shù)據(jù)保存在關系型數(shù)據(jù)庫MySQL中。本文設計了MySQL集群來保證高可用性，同時也做定期的備份。

代碼倉庫GitLab也使用文件系統(tǒng)存儲數(shù)據(jù)，使用關系型數(shù)據(jù)庫來存儲元數(shù)據(jù)。本文參考了官方文檔中的高可用設計3）GitLab Documentation HighAvailability,http://docs.gitlab.com/ce/administration/high_availability/README.html。：使用負載均衡、網(wǎng)絡文件系統(tǒng)（network file system，NFS）等來保證高可用性。對于元數(shù)據(jù)，也使用了數(shù)據(jù)庫集群，并且做定期備份。

3.10 系統(tǒng)擴展

本文分析了未來的潛在需求，數(shù)據(jù)平臺的系統(tǒng)擴展主要在存儲和計算上。歸功于Hadoop等軟件的高可擴展性設計，數(shù)據(jù)平臺的線性擴展非常容易。新添加的服務器可以快速安裝Hadoop的計算和存儲模塊，加入集群參與存儲和計算。本文使用的Hadoop版本也實現(xiàn)了HDFS Federation的功能，因此文件系統(tǒng)元數(shù)據(jù)也可以通過給控制節(jié)點添加服務器來進行線性擴展。

4 應用評估

下面介紹如何根據(jù)需求選取服務器來搭建生產(chǎn)環(huán)境，并進行基本的評估。

4.1 平臺部署

本文簡單地將服務器按功能分為兩大類：一類是控制節(jié)點；另一類是計算和存儲節(jié)點?？刂乒?jié)點需要存取元數(shù)據(jù)，對內(nèi)存和存儲性能要求較高。因此使用大內(nèi)存節(jié)點（256 GB），存儲介質(zhì)使用了多塊高性能、大容量的閃存固態(tài)盤（solid state drives，SSD），這些固態(tài)盤配置成磁盤陣列RAID10模式（磁盤組內(nèi)是RAID1，磁盤組間是RAID0），容錯能力比較好。計算和存儲節(jié)點的存儲容量要求較高，因此給每個節(jié)點選用了12塊6 TB的磁盤，并且配置成JBOD（just a bunch of disks）模式，是為了更好地利用磁盤空間。對于數(shù)據(jù)安全和負載平衡，則通過數(shù)據(jù)平臺軟件在多機間實現(xiàn)。另外對所有節(jié)點都額外配置了2塊10K熱插拔硬盤做成RAID1給操作系統(tǒng)使用。節(jié)點間使用了雙路萬兆網(wǎng)卡互聯(lián)。在操作系統(tǒng)內(nèi)使用動態(tài)鏈路聚合模式將兩路鏈接聚合起來，帶寬加倍可達到20 Gb/s。集群節(jié)點間的通信帶寬的提高對Hadoop/Spark等的Shuffle操作非常有利，因為Shuffle操作是Reducer從Mapper那里拷貝中間結果，涉及大量的網(wǎng)絡數(shù)據(jù)傳輸。兩種服務器配置如表1所示。第一期購置了16臺服務器，包括4臺控制節(jié)點，12臺計算和存儲節(jié)點，總存儲容量接近900 TB。后期計劃擴容至目前規(guī)模的30倍左右。

Table 1 Specifications of servers表1 數(shù)據(jù)平臺硬件配置

4.2 測試及分析

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

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

Table 2 Software configuration表2 軟件版本

本文使用了Hadoop安裝包內(nèi)置的TeraSort排序任務來進行基本的測試。圖2（a）顯示了本文平臺使用TeraSort對不同大小的數(shù)據(jù)集排序所耗費的時間。圖2（b）顯示了使用不同數(shù)目的Reducer對1 TB數(shù)據(jù)集排序所耗費的時間?？梢钥吹皆诒ＷC結果正確的前提下，增加Reducer的數(shù)目可以顯著縮短任務的執(zhí)行時間。

Fig.2 TeraSort benchmark圖2 TeraSort測試

由于機器學習算法的用戶使用率較高，本文選取了3種典型的算法，分別是用于分類的Bayes、用于聚類的K-Means以及用于排名的PageRank。在Hi-Bench 5.0的默認設置下，對每種算法，分別用Hadoop的Map/Reduce框架和Spark來運行測試，結果如表3所示。可以看到基于內(nèi)存計算的Spark框架有較大的優(yōu)勢。本測試并非飽和壓力測試，結果僅供用戶提交任務時參考。

本文仍然有很多優(yōu)化的空間，例如使用特別的壓縮文件格式可以顯著提高磁盤輸入輸出（I/O）性能，能夠減少CPU的iowait等待時間（TeraSort測試中觀察到CPU的一些iowait時間）。也可以結合一些特定的易于壓縮的存儲格式（比如Parquet列存儲格式，Parquet部分算法來自Dremel[14]）來研究性能提升。也可以深入分析BigDataBench以及HiBench的壓力測試結果。

Table 3 HiBench report表3 HiBench測試結果①

5 開放數(shù)據(jù)大賽SODA應用

上海市擁有2 415.27萬4）2015年上海市國民經(jīng)濟和社會發(fā)展統(tǒng)計公報，上海市統(tǒng)計局，國家統(tǒng)計局上海調(diào)查總隊，2016-02-29。常住居民以及龐大的公共設施系統(tǒng)，如公共交通系統(tǒng)，政府手中積累了大量的與城市生活息息相關的數(shù)據(jù)。為了提升數(shù)據(jù)的價值，上海市政府組織了上海開放數(shù)據(jù)創(chuàng)新應用大賽（Shanghai Open Data Apps，SODA），利用大眾的智慧來一起挖掘城市數(shù)據(jù)的價值。大賽總計有來自國內(nèi)外的2 914人報名參賽，組隊817個。參賽選手的背景非常多樣化，有專業(yè)的數(shù)據(jù)分析師、工程師、設計師和產(chǎn)品經(jīng)理等，也有高校教師、公務員、學生等。選手來自的機構也包括了國內(nèi)外知名高校（如MIT、清華、交大、復旦等）和知名企業(yè)（如阿里巴巴）等。大賽征集了有效創(chuàng)意方案總計505個5）2015上海開放數(shù)據(jù)創(chuàng)新應用大賽決賽鳴鑼，http://sh.qq.com/a/20151116/038896.htm。。數(shù)量眾多的參賽選手和大量的創(chuàng)意方案產(chǎn)生，體現(xiàn)了數(shù)據(jù)的密集使用，離不開對數(shù)據(jù)高強度的計算。

關于數(shù)據(jù)，除了上海市政府數(shù)據(jù)服務網(wǎng)（http://www.datashanghai.gov.cn）開放的約1 000個數(shù)據(jù)集外，上海市政府又特別開放了10個大容量高質(zhì)量的數(shù)據(jù)集，如表4所示。其中一卡通刷卡的數(shù)據(jù)量達到了4億多條，而出租車行車數(shù)據(jù)更是超過了34億條。本文的設計雖然著眼于大規(guī)模的數(shù)據(jù)平臺集群，但是限于硬件資源，搭建的生產(chǎn)環(huán)境仍是一個小規(guī)模的集群，用于先導試驗。這些數(shù)據(jù)對本文設計的計算平臺來講，是一個極大的挑戰(zhàn)。

Table 4 SODAdataset表4 SODA數(shù)據(jù)集

限于篇幅和大賽組織方對選手代碼和使用行為的保密協(xié)議，本文僅描述一些有趣的規(guī)律，希望能為其他平臺設計和優(yōu)化提供參考。

發(fā)現(xiàn)大多數(shù)計算仍然是用于數(shù)據(jù)統(tǒng)計的聚集（aggregation）操作。例如，某一個方案計算了出租車的平均速度。由于出租車在不同時間段、不同路段和不同方向上的平均速度是不一樣的，一般通過計算某一較短時間段內(nèi)的、某路段上同方向的所有車的平均車速，來設計相關預測。其中路段是由經(jīng)緯度來按用戶的需求劃分的。下面給出了一個典型的工作日平均速度計算的腳本（Apache Hive Query），簡單起見，按小時來計算平均值，實際的時間間隔要求更短。

上面的代碼非常簡單，但是多人并發(fā)訪問的數(shù)據(jù)量較大。對34億條記錄計算后結果會保存到內(nèi)存數(shù)據(jù)庫或者Key-Value Store中，用于近似實時的查詢。某些選手只對特別的路段（road_segment）感興趣，會對路段的經(jīng)緯度進行過濾。因此路段經(jīng)緯度的索引設置比較重要，索引方案也要根據(jù)數(shù)據(jù)類型進行選取。對路段使用了Hive中簡單穩(wěn)定的Compact-IndexHandler，而對行車方向direction（上行、下行）使用了位圖索引（BitmapIndexHandler）[15]。

Fig.3 Running Pyspark and regression prediction on YARN by Jupyter圖3 使用Jupyter調(diào)用Pyspark在YARN集群上運行回歸預測

發(fā)現(xiàn)大量的聚集操作主要是數(shù)據(jù)預處理，給后面的分類或預測算法提供足夠的特征。經(jīng)過預處理后的數(shù)據(jù)集已經(jīng)變得非常小，因此很多用戶將處理好的數(shù)據(jù)集下載到本地，然后使用算法進行分析預測。例如公交卡刷卡數(shù)據(jù)有4億多條，但是經(jīng)過處理識別后，得到的一些特別的事件記錄只有數(shù)十條。因此將來會考慮對數(shù)據(jù)做更進一步的預處理來減少用戶重復進行預處理的時間。

對于使用機器學習的運行任務，本文平臺也給用戶提供了Jupyter接口來使用Python Notebook。圖3顯示了使用Jupyter調(diào)用Spark的Python接口（Pyspark），在YARN集群上運行不同的回歸（regression）分析進行預測的例子（代碼只是示例，從用戶代碼提取而來）。

對用戶代碼倉庫中的代碼，僅調(diào)度選手的代碼倉庫的發(fā)布（release）分支中的代碼。這樣做的好處是有效減少了作業(yè)的總數(shù)量，降低了單個作業(yè)的響應時間。選手的大量調(diào)試代碼先要在線下對樣本數(shù)據(jù)進行調(diào)試，通過后才會調(diào)度，這也促使選手在提交代碼之前認真思考代碼的目的，因此線上的代碼質(zhì)量比較高（完整性好，bug較少）。

6 結束語

本文嘗試完全使用開源軟件設計并配置了一個存儲、計算及代碼并存的數(shù)據(jù)平臺。用戶不僅可以共享數(shù)據(jù)和計算，還可以追蹤自己的代碼的改變。平臺可以自動審核用戶代碼，并且自動調(diào)度到數(shù)據(jù)平臺進行計算。選取硬件搭建了一個生產(chǎn)環(huán)境，并且給出了基本的測試。使用這個平臺服務于上海開放數(shù)據(jù)創(chuàng)新應用大賽（SODA），給出了大賽使用中的經(jīng)驗、分析和見解。將來會考慮對平臺進行深度優(yōu)化，并且探索如何在各平臺間進行數(shù)據(jù)和計算的共享。

致謝感謝上海市經(jīng)信委和SODA組委會的大力支持。

[1]Thusoo A,Sarma J S,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]//Proceedings of the 2nd USENIX Workshop on Hot Topics in Cloud Computing,Boston,Jun 22,2010.Berkeley:USENIXAssociation,2010:10.

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

[4]Ghemawat S,Gobioff H,Leung S T.The Google file system[C]//Proceedings of the 19th ACM Symposium on Operating Systems Principles,Bolton Landing,Oct 19-22,2003.New York:ACM,2003:29-43.

[5]Chang F,Dean J,Ghemawat S,et al.Bigtable:a distributed storage system for structured data[C]//Proceedings of the 7th Symposium on Operating Systems Design and Implementation,Seattle,Nov 6-8,2006.Berkeley:USENIX Association,2006:205-218.

[6]Dean J,Ghemawat S.MapReduce:simplified data processing on large clusters[C]//Proceedings of the 6th Symposium on Operating System Design and Implementation,San Francisco,Dec 6-8,2004.Berkeley:USENIX Association,2004:137-150.

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

[8]Zaharia M,Chowdhury M,Das T,et al.Resilient distributed datasets:a fault-tolerant abstraction for in-memory cluster computing[C]//Proceedings of the 9th USENIX Symposium on Networked Systems Design and Implementation,San Jose,Apr 25-27,2012.Berkeley:USENIX Association,2012:15-28.

[9]Armbrust M,Xin R S,Lian Cheng,et al.Spark SQL:relational data processing in Spark[C]//Proceedings of the 2015 International Conference on Management of Data,Melbourne,May 31-Jun 4,2015.New York:ACM,2015:1383-1394.

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

[11]DeCandia G,Hastorun D,Jampani M,et al.Dynamo:Amazon's highly available key-value store[C]//Proceedings of the 21st Symposium on Operating Systems Principles,Stevenson,Oct 14-17,2007.New York:ACM,2007:205-220.

[12]Wang Lei,Zhan Jianfeng,Luo Chunjie,et al.BigDataBench:a big data benchmark suite from Internet services[C]//Proceedings of the 20th International Symposium on High Performance Computer Architecture,Orlando,Feb 15-19,2014.Washington:IEEE Computer Society,2014:488-499.

[13]Huang Shengsheng,Huang Jie,Dai Jinquan,et al.The Hi-Bench benchmark suite:characterization of the MapReducebased data analysis[C]//Proceedings of the 29th International Conference on Data Engineering Workshops,Long Beach,Mar 1-6,2010.Washington:IEEE Computer Society,2010:41-51.

[14]Melnik S,Gubarev A,Long Jingjing,et al.Dremel:interactive analysis of Web-scale datasets[J].Communications of theACM,2011,54(6):114-123.

[15]Johnson T.Performance measurements of compressed bitmap indices[C]//Proceedings of the 25th International Conference on Very Large Data Bases,Edinburgh Sep 7-10,1999.San Francisco:Morgan Kaufmann Publishers Inc,1999:278-289.