亚洲免费av电影一区二区三区,日韩爱爱视频,51精品视频一区二区三区,91视频爱爱,日韩欧美在线播放视频,中文字幕少妇AV,亚洲电影中文字幕,久久久久亚洲av成人网址,久久综合视频网站,国产在线不卡免费播放

        ?

        數(shù)據(jù)平臺的設計和實現(xiàn)以及大賽中的應用*

        2018-01-16 01:42:51王永坤金耀輝
        計算機與生活 2018年1期
        關鍵詞:代碼節(jié)點用戶

        王永坤,金耀輝,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ù)集排序所耗費的時間??梢钥吹皆诒WC結果正確的前提下,增加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.

        猜你喜歡
        代碼節(jié)點用戶
        CM節(jié)點控制在船舶上的應用
        Analysis of the characteristics of electronic equipment usage distance for common users
        基于AutoCAD的門窗節(jié)點圖快速構建
        創(chuàng)世代碼
        動漫星空(2018年11期)2018-10-26 02:24:02
        創(chuàng)世代碼
        動漫星空(2018年2期)2018-10-26 02:11:00
        創(chuàng)世代碼
        動漫星空(2018年9期)2018-10-26 01:16:48
        創(chuàng)世代碼
        動漫星空(2018年5期)2018-10-26 01:15:02
        關注用戶
        商用汽車(2016年11期)2016-12-19 01:20:16
        關注用戶
        商用汽車(2016年6期)2016-06-29 09:18:54
        關注用戶
        商用汽車(2016年4期)2016-05-09 01:23:12
        亚洲AV永久青草无码性色av| 亚洲一区二区三区地址| 一区二区在线观看视频高清| 久久综合久久美利坚合众国| 99久久精品午夜一区二区| 午夜成人精品福利网站在线观看| 日本55丰满熟妇厨房伦| 亚洲另类激情专区小说婷婷久 | 少妇精品偷拍高潮少妇在线观看| 开心五月激情五月五月天| 人妻体内射精一区二区三区| 国产人妻精品无码av在线| 久久久久国产精品熟女影院 | 蜜桃av一区在线观看| 亚洲24小时免费视频| 天堂一区二区三区在线观看视频 | 亚洲精品字幕| 99久久超碰中文字幕伊人| 日韩精品成人一区二区三区久久久 | 99久久久无码国产精品试看| 久久成年片色大黄全免费网站 | 蜜桃精品免费久久久久影院| 中文字幕久久久久久精| 亚洲av色在线观看网站| 白白色最新福利视频二| 日韩人妻精品中文字幕专区| 宅男666在线永久免费观看| 天天摸日日摸狠狠添| аⅴ天堂国产最新版在线中文| 国产区高清在线一区二区三区| 亚洲国产国语对白在线观看 | 亚洲精品成人一区二区三区| 国产偷国产偷亚洲高清视频| 最新中文字幕av无码不卡| 国产乱理伦片在线观看| 91精品久久久久含羞草| 国产熟妇一区二区三区网站| 国产一级二级三级在线观看视频| 中文字幕日本人妻久久久免费 | 无码AV高潮喷水无码专区线| 厕所极品偷拍一区二区三区视频|