­　　作者｜趙健博

­　　編輯｜尚劍

­　　本文將為你分享58大數(shù)據(jù)平臺在最近一年半內(nèi)技術(shù)演進(jìn)的過程，包括：58大數(shù)據(jù)平臺目前的整體架構(gòu)是怎么樣的；最近一年半的時(shí)間內(nèi)我們面臨的問題、挑戰(zhàn)以及技術(shù)演進(jìn)過程；以及未來的規(guī)劃。

­　　寫在前面

­　　趙健博，來自58趕集，本文將為大家分享58大數(shù)據(jù)這塊的經(jīng)驗(yàn)。本科和研究生分別是在北京郵電大學(xué)和中國科學(xué)院計(jì)算技術(shù)研究所，之前在百度和360工作，現(xiàn)在是58趕集高級架構(gòu)師、58大數(shù)據(jù)平臺負(fù)責(zé)人。多年的分布式系統(tǒng)（存儲、計(jì)算）的實(shí)踐和研發(fā)經(jīng)驗(yàn)，在工作的這些年中運(yùn)營了大大小小的集群，最大單集群也達(dá)到了四五千臺，在這個(gè)過程中做了大量的功能研發(fā)、系統(tǒng)優(yōu)化，也淌了大量的坑，本文會給大家介紹一些自認(rèn)為比較重要的經(jīng)驗(yàn)。

­　　首先看一下58大數(shù)據(jù)平臺架構(gòu)。大的方面來說分為三層：數(shù)據(jù)基礎(chǔ)平臺層、數(shù)據(jù)應(yīng)用平臺層、數(shù)據(jù)應(yīng)用層，還有兩列監(jiān)控與報(bào)警和平臺管理。

­　　數(shù)據(jù)基礎(chǔ)平臺層又分為四個(gè)子層：

­　　接入層，包括了Canal/Sqoop（主要解決數(shù)據(jù)庫數(shù)據(jù)接入問題）、還有大量的數(shù)據(jù)采用Flume解決方案；

­　　存儲層，典型的系統(tǒng)HDFS（文件存儲）、HBase（KV存儲）、Kafka（消息緩存）；

­　　再往上就是調(diào)度層，這個(gè)層次上我們采用了Yarn的統(tǒng)一調(diào)度以及Kubernetes的基于容器的管理和調(diào)度的技術(shù)；

­　　再往上是計(jì)算層，包含了典型的所有計(jì)算模型的計(jì)算引擎，包含了MR、HIVE、Storm、Spark、Kylin以及深度學(xué)習(xí)平臺比如Caffe、Tensorflow等等。

­　　數(shù)據(jù)應(yīng)用平臺主要包括以下功能：

­　　元信息管理，還有針對所有計(jì)算引擎、計(jì)算引擎job的作業(yè)管理，之后就是交互分析、多維分析以及數(shù)據(jù)可視化的功能。

­　　再往上是支撐58集團(tuán)的數(shù)據(jù)業(yè)務(wù)，比如說流量統(tǒng)計(jì)、用戶行為分析、用戶畫像、搜索、廣告等等。針對業(yè)務(wù)、數(shù)據(jù)、服務(wù)、硬件要有完備的檢測與報(bào)警體系。

­　　平臺管理方面，需要對流程、權(quán)限、配額、升級、版本、機(jī)器要有很全面的管理平臺。

­　　這個(gè)就是目前58大數(shù)據(jù)平臺的整體架構(gòu)圖：

­　　這個(gè)圖展示的是架構(gòu)圖中所包含的系統(tǒng)數(shù)據(jù)流動的情況。分為兩個(gè)部分：

­　　首先是實(shí)時(shí)流，就是黃色箭頭標(biāo)識的這個(gè)路徑。數(shù)據(jù)實(shí)時(shí)采集過來之后首先會進(jìn)入到Kafka平臺，先做緩存。實(shí)時(shí)計(jì)算引擎比如Spark streaming或storm會實(shí)時(shí)的從Kafka中取出它們想要計(jì)算的數(shù)據(jù)。經(jīng)過實(shí)時(shí)的處理之后結(jié)果可能會寫回到Kafka或者是形成最終的數(shù)據(jù)存到MySQL或者HBase，提供給業(yè)務(wù)系統(tǒng)，這是一個(gè)實(shí)時(shí)路徑。

­　　對于離線路徑，通過接入層的采集和收集，數(shù)據(jù)最后會落到HDFS上，然后經(jīng)過Spark、MR批量計(jì)算引擎處理甚至是機(jī)器學(xué)習(xí)引擎的處理。其中大部分的數(shù)據(jù)要進(jìn)去數(shù)據(jù)倉庫中，在數(shù)據(jù)倉庫這部分是要經(jīng)過數(shù)據(jù)抽取、清洗、過濾、映射、合并匯總，最后聚合建模等等幾部分的處理，形成數(shù)據(jù)倉庫的數(shù)據(jù)。然后通過HIVE、Kylin、SparkSQL這種接口將數(shù)據(jù)提供給各個(gè)業(yè)務(wù)系統(tǒng)或者我們內(nèi)部的數(shù)據(jù)產(chǎn)品，有一部分還會流向MySQL。以上是數(shù)據(jù)在大數(shù)據(jù)平臺上的流動情況。

­　　在數(shù)據(jù)流之外還有一套管理平臺。包括元信息管理（云窗）、作業(yè)管理平臺（58dp）、權(quán)限審批和流程自動化管理平臺（NightFury）。

­　　我們的規(guī)模可能不算大，跟BAT比起來有些小，但是也過了一千臺，目前有1200臺的機(jī)器。我們的數(shù)據(jù)規(guī)模目前有27PB，每天增量有50TB。作業(yè)規(guī)模每天大概有80000個(gè)job，核心job（產(chǎn)生公司核心指標(biāo)的job）有20000個(gè)，每天80000個(gè)job要處理數(shù)據(jù)量是2.5PB。

­　　技術(shù)平臺技術(shù)演進(jìn)與實(shí)現(xiàn)

­　　接下來我會重點(diǎn)介紹一下在最近一年半時(shí)間內(nèi)我們大數(shù)據(jù)平臺的技術(shù)演進(jìn)過程，共分四個(gè)部分：穩(wěn)定性、平臺治理、性能以及異構(gòu)計(jì)算。第一個(gè)部分關(guān)于穩(wěn)定性的改進(jìn)，穩(wěn)定性是最基礎(chǔ)的工作，我們做了比較多的工作。第二個(gè)部分是在平臺治理方面的內(nèi)容。第三個(gè)方面我們針對性能也做了一些優(yōu)化。第四個(gè)方面，我們針對異構(gòu)環(huán)境，比如說機(jī)器的異構(gòu)、作業(yè)的異構(gòu)，在這種環(huán)境下怎么合理地使用資源。

­　　穩(wěn)定性改進(jìn)

­　　首先看一下穩(wěn)定性的改進(jìn)。這塊我會舉一些例子進(jìn)行說明。穩(wěn)定性包含了幾個(gè)方面，其中第一個(gè)方面就是系統(tǒng)的可用性，大家可以采用社區(qū)提供的HDFS HA、Yarn HA，Storm HA來解決。另外一個(gè)方面是關(guān)于擴(kuò)展性，例如Flume、HDFS，Yarn，Storm的擴(kuò)展性。這里主要介紹下Flume和HDFS的擴(kuò)展性相關(guān)的一些考慮。

­　　此外，有了可用性和擴(kuò)展性，系統(tǒng)就穩(wěn)定了嗎？實(shí)際上不是這樣。因?yàn)檫€有很多的突發(fā)問題。即使解決了可用性和擴(kuò)展性，但突發(fā)問題還是可能會造成系統(tǒng)不可用，例如由于一些問題造成兩臺NameNode全部宕機(jī)。

­　　首先看一下Flume的擴(kuò)展性。我們?nèi)藶榈陌阉x了兩層。一個(gè)是FlumeLocal（主要解決一臺機(jī)器的日志采集問題，簡稱Local），一個(gè)是FlumeCenter（主要從Local上收集數(shù)據(jù)，然后把數(shù)據(jù)寫到HDFS上，簡稱Center），Local和Center之間是有一個(gè)HA的考慮的，就是Local需要在配置文件里指定兩個(gè)Center去寫入，一旦一個(gè)Center出現(xiàn)問題，數(shù)據(jù)可以馬上從另一個(gè)Center流向HDFS。

­　　此外，我們還開發(fā)了一個(gè)高可靠的Agent。業(yè)務(wù)系統(tǒng)中會把數(shù)據(jù)產(chǎn)生日志寫到磁盤上，Agent保證數(shù)據(jù)從磁盤上實(shí)時(shí)可靠的收集給本地的Local，其中我們采用了檢查點(diǎn)的技術(shù)來解決數(shù)據(jù)可靠性的問題。

­　　這是Flume的典型架構(gòu)。Local需要在配置文件里面指定死要連到哪幾個(gè)Center上。如果說10臺，可能還OK，100臺也OK，如果一千臺呢？如果發(fā)現(xiàn)兩臺Flume Center已經(jīng)達(dá)到機(jī)器資源的上限，如何做緊急的擴(kuò)容呢？所以從這個(gè)角度看Flume的擴(kuò)展性是有問題的。

­　　我們的解決方法是在Local和Center中間加了一個(gè)ZooKeeper，Local通過ZK動態(tài)發(fā)現(xiàn)Center，動態(tài)的發(fā)現(xiàn)下游有什么，就可以達(dá)到Center自動擴(kuò)容的目標(biāo)了。我們公司Local有兩千多臺，擴(kuò)容一臺Center僅需一分鐘，這種架構(gòu)實(shí)際上可以支持達(dá)到萬臺規(guī)模的，這是Flume擴(kuò)展性的一些改進(jìn)。

­　　接下來看一下HDFS擴(kuò)展性的問題。上面這張圖展示了hdfs federation的架構(gòu)，左側(cè)是一個(gè)單namespace架構(gòu)，即整個(gè)目錄樹在一個(gè)namespace中，整個(gè)集群的文件數(shù)規(guī)模受限制于單機(jī)內(nèi)存的限制。federation的思想是把目錄樹拆分，形成不同的namespace，不同namespace由不同namenode管理，這樣就打破了單機(jī)資源限制，從而達(dá)到了可擴(kuò)展的目標(biāo)，如右側(cè)圖。

­　　但這個(gè)方案有一些隱藏的問題，不知道大家有沒有注意到，比如這里每個(gè)Datanode都會與所有的NameNode去心跳，如果DataNode數(shù)量上萬臺，那么就可能會出現(xiàn)兩個(gè)問題：第一，從主節(jié)點(diǎn)之間的心跳、塊匯報(bào)成為瓶頸，第二，如果單個(gè)部門的數(shù)據(jù)規(guī)模過大那該怎么辦？

­　　針對從主節(jié)點(diǎn)之間交互的問題，我們可以進(jìn)行拆分，控制一個(gè)NameNode管理的DateNode的數(shù)量，這樣就可以避免主從節(jié)點(diǎn)交互開銷過大的問題。針對單部門數(shù)據(jù)過大的話可以針對部門內(nèi)數(shù)據(jù)進(jìn)行進(jìn)一步細(xì)拆，就OK了。或者可以考慮百度之前提供的一個(gè)方案，即把目錄樹和inode信息進(jìn)行抽象，然后分層管理和存儲。當(dāng)然我們目前采用社區(qū)federation的方案。如果好好規(guī)劃的話，也是可以到萬臺了。

­　　不知道大家有沒有在自己運(yùn)營集群過程中遇到過一些問題，你們是怎么解決的，有些問題可能相當(dāng)?shù)募?。突發(fā)問題是非常緊急而且重要的，需要在短時(shí)間內(nèi)搞定。接下來我會分享三個(gè)例子。

­　　第一個(gè)例子是HDFS的Active NN會不定期異常退出，觸發(fā)HA切換，這就好像一個(gè)不定時(shí)炸彈一樣。這個(gè)圖展示了HDFS的HA的架構(gòu)圖，客戶端進(jìn)行變更操作（如創(chuàng)建文件）的話會發(fā)出請求給namenode，namenode請求處理完之后會進(jìn)行持久化工作，會在本地磁盤存一份，同時(shí)會在共享存儲存一份，共享存儲是為了active和standby之間同步狀態(tài)的，standby會周期從共享存儲中拉取更新的數(shù)據(jù)應(yīng)用到自己的內(nèi)存和目錄樹當(dāng)中，所有的DataNode都是雙匯報(bào)的，這樣兩個(gè)namenode都會有最新的塊信息。最上面的是兩個(gè)Checker，是為了仲裁究竟誰是Active的。

­　　還有一個(gè)過程，Standby NameNode會定期做checkpoint工作，然后在checkpoint做完之后會回傳最新的fsimage給active，最終保存在active的磁盤中，默認(rèn)情況下在回傳過程會造成大量的網(wǎng)絡(luò)和磁盤的壓力，導(dǎo)致active的本地磁盤的Util達(dá)到100%，此時(shí)用戶變更請求延遲就會變高。如果磁盤的Util100%持續(xù)時(shí)間很長就會導(dǎo)致用戶請求超時(shí)，甚至Checher的檢測請求也因排隊(duì)過長而超時(shí)，最終然后觸發(fā)Checker仲裁HA切換。

­　　切換的過程中在設(shè)計(jì)上有很重要一點(diǎn)考慮，不能同時(shí)有兩個(gè)Active，所以要成為新Active NameNode，要把原來的Active NameNode停止掉。先會很友好地停止，什么是友好呢？就是發(fā)一個(gè)RPC，如果成功了就是友好的，如果失敗了，就會ssh過去，把原來active namenode進(jìn)程kill掉，這就是Active NameNode異常退的原因。

­　　當(dāng)這個(gè)原因了解了之后，其實(shí)要解決這個(gè)問題也非常簡單。

­　　第一點(diǎn)要把editlog與fsimage保存的本地目錄分離配置，這種分離是磁盤上的分離，物理分離。

­　　第二是checkpoint之后fsimage回傳限速。把editlog與fsimage兩個(gè)磁盤分離，fsimage回傳的io壓力不會對客戶端請求造成影響，另外，回傳限速后，也能限制io壓力。這是比較棘手的問題。原因看起來很簡單，但是從現(xiàn)象找到原因，這個(gè)過程并沒有那么容易。

­　　第二個(gè)案例也是一樣，Active NN又出現(xiàn)異常退出，產(chǎn)生HA切換。這次和網(wǎng)絡(luò)連接數(shù)有關(guān)，這張圖是Active NameNode的所在機(jī)器的網(wǎng)絡(luò)連接數(shù)，平時(shí)都挺正常，20000到30000之間，忽然有一個(gè)點(diǎn)一下打到60000多，然后就打平了，最后降下來，降下來的原因很明顯，是服務(wù)進(jìn)程退了。

­　　為什么會出現(xiàn)這個(gè)情況呢？在后續(xù)分析的過程中我們發(fā)現(xiàn)了一個(gè)線索，在NameNode日志里報(bào)了一個(gè)空指針的異常。就順藤摸瓜發(fā)現(xiàn)了一個(gè)JDK1.7的BUG，參見上面圖片所示，在java select庫函數(shù)調(diào)度路徑過程中最終會調(diào)用這個(gè)函數(shù)（setUpdateEvents），大家可以看到，如果fd的個(gè)數(shù)超過了MAX_UPDATE_ARRAY_SIZE（65535）這個(gè)數(shù)的話，將會走到else路徑，這個(gè)路徑在if進(jìn)行不等表達(dá)式判斷時(shí)，將會出發(fā)空指針異常。

­　　接下來的問題是，為什么會產(chǎn)生這么多的鏈接呢？經(jīng)過分析我們發(fā)現(xiàn)，在問題出現(xiàn)的時(shí)候，存在一次大目錄的DU操作，而DU會鎖住整個(gè)namespace，這樣就導(dǎo)致后續(xù)的寫請求被阻塞，最終導(dǎo)致請求的堆積，請求的堆積導(dǎo)致了連接數(shù)大量堆積，連接數(shù)堆積到一定程度就觸發(fā)JDK1.7的這個(gè)BUG。這個(gè)問題的解決，從兩個(gè)方面看，首先我們先把JDK升級到1.8。其次，調(diào)整參數(shù)dfs.content-summary.limit，限制du操作的持鎖時(shí)間。該參數(shù)默認(rèn)參數(shù)是0。我們現(xiàn)在是設(shè)成10000了，大家可以參考。這是第二個(gè)非常棘手的問題。

­　　第三個(gè)案例關(guān)于YARN主節(jié)點(diǎn)的，有一天中午，我們收到報(bào)警，發(fā)現(xiàn)Active RM異常進(jìn)程退出，觸發(fā)HA的切換，然而切換后一會新的Active RM節(jié)點(diǎn)也會異常退出，這就比較悲劇，我們先進(jìn)行了恢復(fù)。

­　　之后我們從當(dāng)時(shí)的日志中發(fā)現(xiàn)了原因：一個(gè)用戶寫了一萬個(gè)文件到分布式緩存里，分布式緩存里數(shù)據(jù)會同步到ZK上，RM持久化作業(yè)狀態(tài)到ZK時(shí)超過Znode單節(jié)點(diǎn)最大上限，拋出異常，最終導(dǎo)致ResourceManager進(jìn)程的異常退出。其實(shí)問題的解決方法也非常簡單，我們增加了限制邏輯，對于序列化數(shù)據(jù)量大于Znode節(jié)點(diǎn)大小的Job，直接拋異常觸發(fā)Job的失敗。另外我們還適當(dāng)提升Znode節(jié)點(diǎn)大小。

­　　以上是在穩(wěn)定性方面的一些工作，這三個(gè)案例跟大家分享一下，如果有類似的問題建議大家可以嘗試一下，這些方案是被我們驗(yàn)證OK的。

­　　平臺治理

­　　接下來介紹一下平臺治理這塊。包含幾個(gè)問題，其中第一問題是關(guān)于數(shù)據(jù)的，一方面，就是大家開發(fā)了數(shù)據(jù)之后，經(jīng)常找不到，要靠喊，比如說在群里喊一下什么數(shù)據(jù)在哪，誰能告訴我一下，這個(gè)效率很低下。另外一方面是之前的管理數(shù)據(jù)是共享的，不安全，任何人都可以訪問其他人的數(shù)據(jù)。

­　　第二個(gè)問題是關(guān)于資源，之前是“大鍋飯”模式，大家共享計(jì)算資源，相互競爭，這樣“能吃的“肯定是擠兌”不能吃的“，經(jīng)常出現(xiàn)核心任務(wù)不能按時(shí)按點(diǎn)完成，老板看不到數(shù)據(jù)，這點(diǎn)很可怕。還有是整個(gè)集群資源使用情況沒有感知，這樣根本不知道資源要怎么分配，是否夠用。

­　　第三個(gè)問題是關(guān)于作業(yè)的，開發(fā)人員開發(fā)大量的作業(yè)之后，這些作業(yè)要怎么管理，實(shí)際上他們可能都不知道。還有就是關(guān)于作業(yè)之間依賴，經(jīng)常一個(gè)指標(biāo)計(jì)算出來要經(jīng)歷多個(gè)作業(yè)，作業(yè)之間依賴是怎么考慮的，單純靠時(shí)間上的依賴是非常脆弱的，如果前期的job延遲產(chǎn)生了，后續(xù)的job必然失敗。最后一個(gè)問題是數(shù)據(jù)開發(fā)人員的效率不高，所需要做的步驟過多。

­　　針對這四個(gè)問題我們做了一些改進(jìn)，首先是數(shù)據(jù)與資源治理。數(shù)據(jù)方面要引入安全策略、元信息管理與基礎(chǔ)數(shù)倉建設(shè)。我們自己開發(fā)了一套安全控制策略，主要增加了白名單和權(quán)限控制策略。一個(gè)HDFS的請求的流程，首先客戶端會向NameNode發(fā)請求，NameNode接到請求之后首先要做連接解析，讀取出請求相關(guān)內(nèi)容做請求處理，再把結(jié)果反饋回來，之后客戶端向相應(yīng)的DataNode進(jìn)行寫入數(shù)據(jù)或者讀取數(shù)據(jù)。從上述流程可以看出，所有HDFS操作全部要經(jīng)過NameNode這一層。

­　　那么安全策略只要在NameNode的兩個(gè)點(diǎn)做下控制既可完成：在連接解析后，我們會驗(yàn)證請求方的IP，以及用戶是不是在合法配置下面的。如果驗(yàn)證失敗，則拒絕請求。如果驗(yàn)證通過，我們會進(jìn)一步在請求處理過程中驗(yàn)證用戶訪問的目錄和用戶在否在合法的配置下。

­　　比如說用戶A想訪問用戶B的數(shù)據(jù)，如果沒在允許的情況下會把連接關(guān)掉，通過簡單的策略調(diào)整就能達(dá)到靈活的數(shù)據(jù)的安全控制和數(shù)據(jù)共享的方式。接下來針對數(shù)據(jù)找不到的問題，我們開發(fā)了全公司層面的基礎(chǔ)數(shù)據(jù)倉庫以及針對全公司層面元數(shù)據(jù)管理平臺。

­　　這張圖展示了基礎(chǔ)數(shù)據(jù)倉庫覆蓋度，它覆蓋了集團(tuán)各個(gè)公司，又覆蓋了多個(gè)平臺，比如說手機(jī)、App端、PC端、微信端等等。數(shù)據(jù)層次，是數(shù)據(jù)倉庫層、數(shù)據(jù)集市層還是數(shù)據(jù)應(yīng)用層，所屬哪個(gè)事業(yè)群，最后針對數(shù)據(jù)進(jìn)行分類標(biāo)簽，比如說帖子數(shù)據(jù)、用戶數(shù)據(jù)等等都可以通過標(biāo)簽的方式來找到。當(dāng)想找具體一份數(shù)據(jù)的時(shí)候可以通過這個(gè)界面，點(diǎn)一些標(biāo)簽，篩選出一些數(shù)據(jù)表，甚至在搜索框里面搜數(shù)據(jù)的關(guān)鍵字。

­　　當(dāng)查到數(shù)據(jù)表的時(shí)候可以在右側(cè)按鈕，將顯示出表結(jié)構(gòu)，還有表信息，表信息表明了這個(gè)表有多少列，這個(gè)表的負(fù)責(zé)人是什么，還有關(guān)于數(shù)據(jù)質(zhì)量，表的數(shù)據(jù)量的變化情況等等，如果你想申請可以點(diǎn)擊最右邊的權(quán)限開通。整體開通流程也是自動化的。這是針對數(shù)據(jù)找不到的問題做的一些改進(jìn)。

­　　針對資源問題要避免大鍋飯，必須要引入賬號概念，資源按照賬號預(yù)留與隔離。我們劃分了不同的配額，根據(jù)預(yù)算、業(yè)務(wù)需求去申請配額，然后我們調(diào)整配額。針對隊(duì)列這塊我們劃分多個(gè)隊(duì)列，每個(gè)業(yè)務(wù)線有自己的隊(duì)列，不同業(yè)務(wù)線不能跨隊(duì)列提交任務(wù)，每個(gè)隊(duì)列劃分出不同資源，資源主要是針對業(yè)務(wù)線需求而定的。通過這些改進(jìn)可以達(dá)到資源的隔離以及適度的共享。

­　　有了賬號的概念之后我們就可以統(tǒng)計(jì)每個(gè)業(yè)務(wù)線資源使用情況。我們每天都會有報(bào)表。顯示了業(yè)務(wù)線的計(jì)算和存儲資源的使用情況，甚至是Job的細(xì)節(jié)情況。

­　　接下來我會介紹一下業(yè)務(wù)線開發(fā)效率低下問題的改進(jìn)，實(shí)際上我們在易用性上也做了很多改進(jìn)。首先我們開發(fā)了云窗平臺，它主要解決了元信息查找、數(shù)據(jù)查詢、可是化展示和多維分析這些需求。然后針對任務(wù)開發(fā)這塊我們開發(fā)了58DP解決了元信息開發(fā)、作業(yè)管理與統(tǒng)計(jì)等。我們針對實(shí)時(shí)多維分析開發(fā)了飛流，實(shí)時(shí)作業(yè)開發(fā)全部配置化、同時(shí)支持多種統(tǒng)計(jì)算子、自動圖表生成等等。還有NightFury，流程自動化管理平臺。

­　　這是云窗的界面，上面是一個(gè)SQL查詢界面，下面是可視化產(chǎn)品界面，這是我們數(shù)據(jù)可視化的一個(gè)結(jié)果。

­　　然后關(guān)于任務(wù)開發(fā)的話，我們用58DP來做任務(wù)開發(fā)，可以支持的不同任務(wù)，涵蓋目前的所有主流作業(yè)以及作業(yè)依賴等管理。這是58DP的頁面，可以設(shè)置基本信息、調(diào)度及依賴等。

­　　飛流是支持周期性的統(tǒng)計(jì)、全天累計(jì)性的統(tǒng)計(jì)，大家可以定義統(tǒng)計(jì)方法、定義任務(wù)的一些基本信息，設(shè)置維度、設(shè)置度量，設(shè)置完之后就展現(xiàn)了圖形，也提供了跟昨天的對比情況。當(dāng)在圖里點(diǎn)任何一個(gè)點(diǎn)的時(shí)候，可以看到不同維度組合下在這個(gè)點(diǎn)上的數(shù)據(jù)分布，點(diǎn)擊兩個(gè)點(diǎn)可以看到不同維度下兩個(gè)點(diǎn)的分布對比。針對歷史數(shù)據(jù)可以進(jìn)行對比，我們可以把時(shí)間拉的更長，可以查看不同周的實(shí)時(shí)統(tǒng)計(jì)結(jié)果，而不是一天。

­　　這是NightFury的界面，這就是我們運(yùn)維的自動化管理平臺，大家可以看到有很多個(gè)流程和權(quán)限的開通申請，表單的填寫、工單審批，審批之后的一些流程全部是自動化的。

­　　性能

­　　性能方面，主要分為四個(gè)方面：

­　　MR作業(yè)性能、數(shù)據(jù)收集性能、SQL查詢性能和多維分析的性能。針對MR作業(yè)性能，我們引用多租戶功能，資源預(yù)留，核心作業(yè)執(zhí)行有保障。

­　　第二點(diǎn)小文件合并處理，可以提升任務(wù)執(zhí)行效率，減少調(diào)度本身的開銷。

­　　第三點(diǎn)我們針對Shuffle階段參數(shù)優(yōu)化，可以實(shí)現(xiàn)并發(fā)度提升，IO消耗降低。

­　　經(jīng)過三個(gè)方面的改進(jìn)之后，我們整體任務(wù)的運(yùn)行時(shí)間實(shí)際上有一倍左右的提升。數(shù)據(jù)傳輸優(yōu)化方面，我們經(jīng)過消息合并改進(jìn)數(shù)據(jù)傳輸性能，提升了20倍。在SQL優(yōu)化方面我們引用內(nèi)存執(zhí)行引擎與列存儲方案的結(jié)合，在同等資源情況下針對線上一百多條SQL進(jìn)行測試，總體性能大概提升80%。在多維計(jì)算這塊，我們引入Kylin，針對多維的查詢95%以上查詢能控制在2s以內(nèi)。

­　　異構(gòu)計(jì)算

­　　異構(gòu)計(jì)算方面我們面臨了兩個(gè)主要問題，一個(gè)是作業(yè)的異構(gòu)，我們有多種類型的作業(yè)，比如說實(shí)時(shí)作業(yè)強(qiáng)調(diào)低時(shí)延，而離線作業(yè)強(qiáng)調(diào)高吞吐，這本身就是矛盾的，怎么解決這個(gè)矛盾。第二方面是機(jī)器異構(gòu)，CPU、內(nèi)存、網(wǎng)絡(luò)、磁盤配置不同，這種異構(gòu)環(huán)境又要怎么辦。

­　　從上面圖中可以看出：如果實(shí)時(shí)作業(yè)的task和批處理作業(yè)的task被調(diào)度到一臺機(jī)器上了，如果批處理作業(yè)把資源占滿了（例如網(wǎng)絡(luò)帶寬），則實(shí)時(shí)作業(yè)的task必將收到影響。所以，需要對實(shí)時(shí)作業(yè)和批處理作業(yè)做隔離才行。

­　　做資源隔離，我們的思路是采用標(biāo)簽化，給每個(gè)NodeManager賦予不同標(biāo)簽，表示不同機(jī)器被分配了不同標(biāo)簽；資源隊(duì)列也賦予不同標(biāo)簽，然后在RM調(diào)度時(shí)，保證相同標(biāo)簽的隊(duì)列里容器資源必從相同標(biāo)簽的NodeManager上分配的。這樣就可以通過標(biāo)簽的不同達(dá)到物理上的資源隔離目標(biāo)。

­　　這張圖是實(shí)現(xiàn)圖。首先可以看到NodeManager分成了兩個(gè)集合，一個(gè)是實(shí)時(shí)的，一個(gè)是離線的，不同的隊(duì)列也被賦予了實(shí)時(shí)或離線的標(biāo)簽，當(dāng)用戶提交一個(gè)job的時(shí)候它可以指定一個(gè)隊(duì)列，提交到離線隊(duì)列里就是離線任務(wù)，ResourceManager就會把這個(gè)作業(yè)所需要的資源分配到離線標(biāo)簽的NodeManager上，這樣就可以做到物理資源隔離。

­　　未來規(guī)劃

­　　以上主要是介紹了我們最近一年半做的一些工作。接下來我會介紹一下未來的規(guī)劃。首先就是深度學(xué)習(xí)。這個(gè)概念今年非?；鸨踔潦且?，深度學(xué)習(xí)在58這塊需求也是蠻強(qiáng)烈的。目前深度學(xué)習(xí)工具有這么多，caffe、theano、torch等等非常多，怎么做整合，怎么降低使用成本，這是第一個(gè)問題。

­　　第二個(gè)問題，機(jī)器是有限的，怎么高效利用資源，需要把機(jī)器分配模式變成資源分配模式。還有光有單機(jī)的機(jī)器學(xué)習(xí)或者深度學(xué)習(xí)工具還不夠，因?yàn)樾阅芴?，所以我們需要將深度學(xué)習(xí)訓(xùn)練分布式化。我們做了一個(gè)初步的測試，針對caffe與Tensorflow工具的分布式化訓(xùn)練做了比較，4卡相對于單卡模型訓(xùn)練性能提升100%~170%，所以分布式化的工作本身意義也是非常大的。

­　　這個(gè)圖展示的是工具融合方案。我們這里利用的是Kubernetes，支持主流的深度學(xué)習(xí)工具，每個(gè)工具做成鏡像形成POD，用戶需要的話可以直接把POD分發(fā)給他，用戶在訓(xùn)練的時(shí)候從HDFS上直接拉取樣本，并且把訓(xùn)練的參數(shù)回寫到HDFS上，也就是說通過HDFS做數(shù)據(jù)的共享，通過這種模式可以很輕松地支持多種深度學(xué)習(xí)工具，也可以達(dá)到按所需資源量進(jìn)行資源的分配目標(biāo)。

­　　另外我們會做一個(gè)深度學(xué)習(xí)工具分布式的改造，是針對caffe，我們用的是CaffeOnSpark，即把整個(gè)分布式的方案做成模板供用戶使用。首先啟動多個(gè)POD，通過POD啟動一個(gè)Spark集群，然后再提一個(gè)Spark job來做訓(xùn)練，最后在整個(gè)訓(xùn)練結(jié)束之后再把集群停掉。Tensorflow也是一樣的，首先啟動tensorflow集群，然后提交任務(wù)，任務(wù)訓(xùn)練完以后再把集群停掉。其他工具分布式化我們也會采取類似的思路解決。以上是關(guān)于深度學(xué)習(xí)這塊我們目前的一些工作。

­　　其次，是關(guān)于空間資源利用率的。目前我們有一千多臺機(jī)器，存儲是很大的成本。之前也提到了，我們是屬于花錢的部門，所以壓力非常大。那怎么節(jié)省成本是一個(gè)很重要的問題。除了傳統(tǒng)壓縮之外，還能做什么？HDFS RAID是一個(gè)比較好的解決方案。

­　　HDFS RAID采用是RC編碼，類似RAID6，比如一個(gè)文件有m個(gè)塊，根據(jù)m個(gè)塊生成k個(gè)校驗(yàn)塊，然后能保證k個(gè)塊丟失的情況下數(shù)據(jù)還能找回來，舉個(gè)例子來說，比如文件2.5G大小，256M一個(gè)塊，可以分成10個(gè)塊，根據(jù)RC算法再生成4個(gè)校驗(yàn)塊，可以保證丟了4個(gè)塊情況下，數(shù)據(jù)都能找回來。在這個(gè)例子中，3副本情況下，一共需要30個(gè)塊，而采用HDFS RAID，僅需要14個(gè)塊。但他們的可靠性一樣，空間占用情況卻差了57%。

­　　具體實(shí)施時(shí)，第一步對集群數(shù)據(jù)進(jìn)行冷熱分析，RAID畢竟有些性能問題，一旦數(shù)據(jù)有問題，你要通過計(jì)算才能恢復(fù)，勢必會造成性能低下，所以針對冷數(shù)據(jù)做肯定是風(fēng)險(xiǎn)最低的。第二步就是壓縮+archive+RAID，通過三方面技術(shù)結(jié)合把文件數(shù)和空間全部節(jié)省出來。歸檔實(shí)際上是會變換目錄的，為了做適配，我們通過軟連接功能，做到對用戶透明。最后在數(shù)據(jù)讀取時(shí)，如果是RAID數(shù)據(jù)，就要具備實(shí)時(shí)RAID修復(fù)功能才能保證在數(shù)據(jù)缺失的情況下不影響數(shù)據(jù)的訪問。

­　　后續(xù)我們會對計(jì)算資源利用率再做進(jìn)一步提升。另外也會考慮Storm和YARN擴(kuò)展性。還有Kubernetes調(diào)度優(yōu)化，比如針對GPU資源管理功能。

­　　以上就是我今天想介紹的全部內(nèi)容。在結(jié)束之前請?jiān)试S我再做一下總結(jié)。

­　　首先我介紹了58目前的大數(shù)據(jù)平臺架構(gòu)是怎么樣的，簡單來說就是“342”，三個(gè)層次、細(xì)分為四個(gè)子層、旁邊兩列。所以大家要做大數(shù)據(jù)平臺建設(shè)工作，這幾個(gè)方面是必備的。

­　　第二個(gè)方面我重點(diǎn)的介紹了58在一年半的時(shí)間內(nèi)的技術(shù)改進(jìn)。第一點(diǎn)是關(guān)于穩(wěn)定性，主要從Flume和HDFS擴(kuò)展性方面重點(diǎn)介紹了我們的解決方案，舉了三個(gè)案例來說明突發(fā)問題，不是說有了可用性和擴(kuò)展性就萬事OK了，還要解決突發(fā)問題。針對平臺治理首先介紹了一下數(shù)據(jù)和資源的治理方法，接著又介紹了關(guān)于易用性方面的改進(jìn)，我們提供了一系列平臺來提高開發(fā)人員的開發(fā)效率。

­　　第三方面從性能上介紹了我們這邊做的優(yōu)化工作以及優(yōu)化的結(jié)果是怎么樣的；

­　　第四方面介紹了在異構(gòu)環(huán)境下如何支持不同特征的作業(yè)進(jìn)行合理調(diào)度。

­　　最后我介紹了58深度學(xué)習(xí)平臺建設(shè)方面以及存儲資源空間利用率優(yōu)化方面的內(nèi)容。以上就是我今天的全部內(nèi)容，希望對大家有幫助。

­　　今日薦文

­　　微軟開源軟件列表