接下來(lái)我會(huì)跟大家分享一下58大數(shù)據(jù)平臺(tái)在最近一年半的時(shí)間內(nèi)技術(shù)演進(jìn)的過(guò)程。主要內(nèi)容分為三方面：58大數(shù)據(jù)平臺(tái)目前的整體架構(gòu)是怎么樣的；最近一年半的時(shí)間內(nèi)我們面臨的問(wèn)題、挑戰(zhàn)以及技術(shù)演進(jìn)過(guò)程；以及未來(lái)的規(guī)劃。

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

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

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

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

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

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

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

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

再往上是支撐58集團(tuán)的數(shù)據(jù)業(yè)務(wù)，比如說(shuō)流量統(tǒng)計(jì)、用戶行為分析、用戶畫(huà)像、搜索、廣告等等。

針對(duì)業(yè)務(wù)、數(shù)據(jù)、服務(wù)、硬件要有完備的檢測(cè)與報(bào)警體系。

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

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

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

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

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

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

我們的規(guī)?？赡懿凰愦?，跟BAT比起來(lái)有些小，但是也過(guò)了一千臺(tái)，目前有1200臺(tái)的機(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ù)平臺(tái)技術(shù)演進(jìn)與實(shí)現(xiàn)

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

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

首先看一下穩(wěn)定性的改進(jìn)。這塊我會(huì)舉一些例子進(jìn)行說(shuō)明。穩(wěn)定性包含了幾個(gè)方面，其中第一個(gè)方面就是系統(tǒng)的可用性，大家可以采用社區(qū)提供的HDFSHA、YarnHA，StormHA來(lái)解決。另外一個(gè)方面是關(guān)于擴(kuò)展性，例如Flume、HDFS，Yarn，Storm的擴(kuò)展性。這里主要介紹下Flume和HDFS的擴(kuò)展性相關(guān)的一些考慮。此外，有了可用性和擴(kuò)展性，系統(tǒng)就穩(wěn)定了嗎？實(shí)際上不是這樣。因?yàn)檫€有很多的突發(fā)問(wèn)題。即使解決了可用性和擴(kuò)展性，但突發(fā)問(wèn)題還是可能會(huì)造成系統(tǒng)不可用，例如由于一些問(wèn)題造成兩臺(tái)NameNode全部宕機(jī)。

首先看一下Flume的擴(kuò)展性。我們?nèi)藶榈陌阉x了兩層。一個(gè)是FlumeLocal（主要解決一臺(tái)機(jī)器的日志采集問(wèn)題，簡(jiǎn)稱Local），一個(gè)是FlumeCenter（主要從Local上收集數(shù)據(jù)，然后把數(shù)據(jù)寫到HDFS上，簡(jiǎn)稱Center），Local和Center之間是有一個(gè)HA的考慮的，就是Local需要在配置文件里指定兩個(gè)Center去寫入，一旦一個(gè)Center出現(xiàn)問(wèn)題，數(shù)據(jù)可以馬上從另一個(gè)Center流向HDFS。此外，我們還開(kāi)發(fā)了一個(gè)高可靠的Agent。業(yè)務(wù)系統(tǒng)中會(huì)把數(shù)據(jù)產(chǎn)生日志寫到磁盤上，Agent保證數(shù)據(jù)從磁盤上實(shí)時(shí)可靠的收集給本地的Local，其中我們采用了檢查點(diǎn)的技術(shù)來(lái)解決數(shù)據(jù)可靠性的問(wèn)題。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第三個(gè)案例關(guān)于YARN主節(jié)點(diǎn)的，有一天中午，我們收到報(bào)警，發(fā)現(xiàn)ActiveRM異常進(jìn)程退出，觸發(fā)HA的切換，然而切換后一會(huì)新的ActiveRM節(jié)點(diǎn)也會(huì)異常退出，這就比較悲劇，我們先進(jìn)行了恢復(fù)。之后我們從當(dāng)時(shí)的日志中發(fā)現(xiàn)了原因：一個(gè)用戶寫了一萬(wàn)個(gè)文件到分布式緩存里，分布式緩存里數(shù)據(jù)會(huì)同步到ZK上，RM持久化作業(yè)狀態(tài)到ZK時(shí)超過(guò)Znode單節(jié)點(diǎn)最大上限，拋出異常，最終導(dǎo)致ResourceManager進(jìn)程的異常退出。其實(shí)問(wèn)題的解決方法也非常簡(jiǎn)單，我們?cè)黾恿讼拗七壿?，?duì)于序列化數(shù)據(jù)量大于Znode節(jié)點(diǎn)大小的Job，直接拋異常觸發(fā)Job的失敗。另外我們還適當(dāng)提升Znode節(jié)點(diǎn)大小。

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

平臺(tái)治理

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

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

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

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

那么安全策略只要在NameNode的兩個(gè)點(diǎn)做下控制既可完成：在連接解析后，我們會(huì)驗(yàn)證請(qǐng)求方的IP，以及用戶是不是在合法配置下面的。如果驗(yàn)證失敗，則拒絕請(qǐng)求。如果驗(yàn)證通過(guò)，我們會(huì)進(jìn)一步在請(qǐng)求處理過(guò)程中驗(yàn)證用戶訪問(wèn)的目錄和用戶在否在合法的配置下。比如說(shuō)用戶A想訪問(wèn)用戶B的數(shù)據(jù)，如果沒(méi)在允許的情況下會(huì)把連接關(guān)掉，通過(guò)簡(jiǎn)單的策略調(diào)整就能達(dá)到靈活的數(shù)據(jù)的安全控制和數(shù)據(jù)共享的方式。接下來(lái)針對(duì)數(shù)據(jù)找不到的問(wèn)題，我們開(kāi)發(fā)了全公司層面的基礎(chǔ)數(shù)據(jù)倉(cāng)庫(kù)以及針對(duì)全公司層面元數(shù)據(jù)管理平臺(tái)。

這張圖展示了基礎(chǔ)數(shù)據(jù)倉(cāng)庫(kù)覆蓋度，它覆蓋了集團(tuán)各個(gè)公司，又覆蓋了多個(gè)平臺(tái)，比如說(shuō)手機(jī)、App端、PC端、微信端等等。數(shù)據(jù)層次，是數(shù)據(jù)倉(cāng)庫(kù)層、數(shù)據(jù)集市層還是數(shù)據(jù)應(yīng)用層，所屬哪個(gè)事業(yè)群，最后針對(duì)數(shù)據(jù)進(jìn)行分類標(biāo)簽，比如說(shuō)帖子數(shù)據(jù)、用戶數(shù)據(jù)等等都可以通過(guò)標(biāo)簽的方式來(lái)找到。當(dāng)想找具體一份數(shù)據(jù)的時(shí)候可以通過(guò)這個(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ù)量的變化情況等等，如果你想申請(qǐng)可以點(diǎn)擊最右邊的權(quán)限開(kāi)通。整體開(kāi)通流程也是自動(dòng)化的。這是針對(duì)數(shù)據(jù)找不到的問(wèn)題做的一些改進(jìn)。

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

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

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

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

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

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

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

性能

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

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

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

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

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

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

異構(gòu)計(jì)算方面我們面臨了兩個(gè)主要問(wèn)題，一個(gè)是作業(yè)的異構(gòu)，我們有多種類型的作業(yè)，比如說(shuō)實(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)度到一臺(tái)機(jī)器上了，如果批處理作業(yè)把資源占滿了（例如網(wǎng)絡(luò)帶寬），則實(shí)時(shí)作業(yè)的task必將收到影響。所以，需要對(duì)實(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上分配的。這樣就可以通過(guò)標(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就會(huì)把這個(gè)作業(yè)所需要的資源分配到離線標(biāo)簽的NodeManager上，這樣就可以做到物理資源隔離。

未來(lái)規(guī)劃

以上主要是介紹了我們最近一年半做的一些工作。接下來(lái)我會(huì)介紹一下未來(lái)的規(guī)劃。首先就是深度學(xué)習(xí)。這個(gè)概念今年非?；鸨?，甚至是要爆炸了，深度學(xué)習(xí)在58這塊需求也是蠻強(qiáng)烈的。目前深度學(xué)習(xí)工具有這么多，caffe、theano、torch等等非常多，怎么做整合，怎么降低使用成本，這是第一個(gè)問(wèn)題。第二個(gè)問(wèn)題，機(jī)器是有限的，怎么高效利用資源，需要把機(jī)器分配模式變成資源分配模式。還有光有單機(jī)的機(jī)器學(xué)習(xí)或者深度學(xué)習(xí)工具還不夠，因?yàn)樾阅芴?，所以我們需要將深度學(xué)習(xí)訓(xùn)練分布式化。我們做了一個(gè)初步的測(cè)試，針對(duì)caffe與Tensorflow工具的分布式化訓(xùn)練做了比較，4卡相對(duì)于單卡模型訓(xùn)練性能提升100%~170%，所以分布式化的工作本身意義也是非常大的。

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

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

其次，是關(guān)于空間資源利用率的。目前我們有一千多臺(tái)機(jī)器，存儲(chǔ)是很大的成本。之前也提到了，我們是屬于花錢的部門，所以壓力非常大。那怎么節(jié)省成本是一個(gè)很重要的問(wèn)題。除了傳統(tǒng)壓縮之外，還能做什么？HDFSRAID是一個(gè)比較好的解決方案。HDFSRAID采用是RC編碼，類似RAID6，比如一個(gè)文件有m個(gè)塊，根據(jù)m個(gè)塊生成k個(gè)校驗(yàn)塊，然后能保證k個(gè)塊丟失的情況下數(shù)據(jù)還能找回來(lái)，舉個(gè)例子來(lái)說(shuō)，比如文件2.5G大小，256M一個(gè)塊，可以分成10個(gè)塊，根據(jù)RC算法再生成4個(gè)校驗(yàn)塊，可以保證丟了4個(gè)塊情況下，數(shù)據(jù)都能找回來(lái)。在這個(gè)例子中，3副本情況下，一共需要30個(gè)塊，而采用HDFSRAID，僅需要14個(gè)塊。但他們的可靠性一樣，空間占用情況卻差了57%。

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

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

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

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

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

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

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

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

來(lái)源：大數(shù)據(jù)雜談