作者：蔡永承

大數(shù)據(jù)平臺(tái)在唯品會(huì)近幾年有了飛速發(fā)展，已經(jīng)完成了從0到1的過程，各個(gè)部門逐漸將其引入到實(shí)際業(yè)務(wù)中。 “百尺竿頭，更進(jìn)一步”，在業(yè)務(wù)壓力和集群負(fù)載同步增加的情況下，如何實(shí)現(xiàn)平臺(tái)優(yōu)化是2017年的主旋律。

我們不可能面面俱到講所有新東西，主要從集群健康和資源有效利用角度進(jìn)行探討，圍繞集群監(jiān)控，HDFS，Yarn和Capping調(diào)度來展開。

集群監(jiān)控

這個(gè)技術(shù)架構(gòu)主要關(guān)注于離線數(shù)據(jù)平臺(tái)。原始數(shù)據(jù)通過flume和sqoop接入不同的數(shù)據(jù)源，離線的ETL主要通過Hive 和SparkSQL進(jìn)行數(shù)據(jù)處理。Presto主要用于Ad hoc的查詢?nèi)蝿?wù)。這些工作都在數(shù)據(jù)開發(fā)平臺(tái)自研的數(shù)坊中進(jìn)行。ETL開發(fā)自助的數(shù)據(jù)查詢、定時(shí)任務(wù)ETL開發(fā)以及自助報(bào)表訂閱，這些作業(yè)通過調(diào)度程序和作業(yè)前置依賴進(jìn)行調(diào)度。在前端我們開發(fā)了自助分析平臺(tái)和各種數(shù)據(jù)產(chǎn)品，比如比價(jià)選品、魔方等數(shù)據(jù)應(yīng)用于生產(chǎn)。

Hadoop集群開始于2013年，已經(jīng)有4年時(shí)間了。我們從0開始建設(shè)，到現(xiàn)在有一個(gè)將近1000個(gè)節(jié)點(diǎn)主的集群以及一個(gè)用于實(shí)時(shí)離線融合的SSD集群。我們正在升級(jí)Hadoop以及Hive到最新版本。目前每天運(yùn)行作業(yè)10萬，yarn app達(dá)到50萬以上。

首先，通過專為海量數(shù)據(jù)批量處理設(shè)計(jì)的Hadoop集中式存儲(chǔ)數(shù)據(jù)的平臺(tái)，數(shù)據(jù)進(jìn)入Hive數(shù)據(jù)倉庫后，任意表就能關(guān)聯(lián)、合并和計(jì)算，同時(shí)還保存了全量數(shù)據(jù)。SQL基本是個(gè)人人都會(huì)的開發(fā)語言，在唯品數(shù)坊中通過SQL查詢和處理數(shù)據(jù)，結(jié)合調(diào)度系統(tǒng)，就可以自動(dòng)處理，合理分配資源執(zhí)行大數(shù)據(jù)量的數(shù)據(jù)批量任務(wù)。對(duì)于個(gè)性化推薦需求，機(jī)器學(xué)習(xí)pipeline建立了DAG，開發(fā)者通過DAG Editor就可以通過拖拉的方式建立機(jī)器學(xué)習(xí)實(shí)例，并且分布式進(jìn)行調(diào)度。大數(shù)據(jù)除了應(yīng)用于內(nèi)部數(shù)據(jù)分析工具外，還出品線上業(yè)務(wù)的數(shù)據(jù)產(chǎn)品比如消費(fèi)者在前端看到的實(shí)時(shí)個(gè)性化推薦，內(nèi)部比價(jià)系統(tǒng)和供應(yīng)商用于生產(chǎn)的售中組貨，魔方等。

大數(shù)據(jù)平臺(tái)主要職責(zé)是維護(hù)集群的穩(wěn)定性，提供充足的資源以及多樣化場景的需求。這個(gè)和我們面對(duì)的挑戰(zhàn)是一致的。集群穩(wěn)定性很重要的一點(diǎn)是可以通過平臺(tái)監(jiān)控來感知平臺(tái)的隱患和壓力。在監(jiān)控中發(fā)現(xiàn)集群壓力，我們下一步就要進(jìn)行性能優(yōu)化。優(yōu)化后我們通過監(jiān)控系統(tǒng)查看效果。這在整體上是一個(gè)閉環(huán)的過程。

系統(tǒng)告警在框架上必須滿足三大要求：第一是必須全部覆蓋機(jī)器層面、日志層面和服務(wù)層面，不可偏頗；第二必須是實(shí)時(shí)監(jiān)控，遇到故障需要從郵件、短信和電話不同級(jí)別地升級(jí)和降級(jí)；第三也是非常重要的，就是告警規(guī)則必須是容易配置的。

用ES來監(jiān)控日志文件和Zabbix來做機(jī)器層面的監(jiān)控是我們做了比較久的，今年我們新的嘗試是引入Prometheus和Grafna來重構(gòu)服務(wù)層的監(jiān)控。Prometheus相當(dāng)于就是開源版本的Borgmon，而Borgmon是Google內(nèi)部做大規(guī)模集群的監(jiān)控系統(tǒng)。唯品會(huì)使用Prometheus主動(dòng)Pull各種指標(biāo)數(shù)據(jù)通過Grafana完美展現(xiàn)部門大屏dashboard。目前Grafana已經(jīng)對(duì)接原有的Zabbix數(shù)據(jù)源和ES數(shù)據(jù)源，同時(shí)開通了基于jmx的各種開源組件監(jiān)控，包括Kafka，Hadoop，Cassandra等，對(duì)接郵件、短信和電話告警用于生產(chǎn)。

這里簡單介紹一下如何通過Prometheus做服務(wù)層面的監(jiān)控原理。Preometheus 是采用pull的模式而不是通過玩agent的方式拿數(shù)據(jù)，這樣的好處就是不用客戶端的強(qiáng)依賴。但是prometheus對(duì)于數(shù)據(jù)格式是有要求的，所以在這里首先需要建立一個(gè)Http Server來將metrics轉(zhuǎn)換成prometheus認(rèn)識(shí)的文本格式。這里的例子是獲取kafka lagoffset，然后這個(gè)服務(wù)開放以后，prometheus就可以主動(dòng)pull這個(gè)網(wǎng)址來實(shí)時(shí)抓到數(shù)據(jù)了。

Prometheus拿到數(shù)據(jù)后就會(huì)存儲(chǔ)到本地或者remote的存儲(chǔ)，前端Grafana的配置也是非常簡單的，定義好數(shù)據(jù)源和metrics，加到Graph就可以了。在這個(gè)配置中，可以通過嵌入的web hook來定義告警規(guī)則。規(guī)則定義也是所見即所得，運(yùn)維人員非常容易上手。

通過Grafana展示可以校驗(yàn)監(jiān)控?cái)?shù)據(jù)的鏈路。Grafana提供了托拉拽的功能，我們把各種不同的metrics監(jiān)控圖組合成立了一個(gè)部門大屏。通過統(tǒng)一制定大屏，我們可以對(duì)系統(tǒng)情況一目了然。我現(xiàn)在每天上班的第一件事情，就是打開這個(gè)部門大屏查看系統(tǒng)情況。

Hive在多HDFS集群上的實(shí)踐

說完了監(jiān)控部分，我們開始今年的一個(gè)落地嘗試–實(shí)現(xiàn)多HDFS集群。在調(diào)研落地時(shí)我們發(fā)現(xiàn)目前比較流行的社區(qū)Federation方案與業(yè)務(wù)不是非常兼容。在這個(gè)基礎(chǔ)上，我們研究了多HDFS集群的應(yīng)用，保持一個(gè)YARN、支持多個(gè)HDFS集群方式。該實(shí)踐的特點(diǎn)是通過Hive層來使HDFS透明化，最大限度兼容原來的應(yīng)用。

從多HDFS架構(gòu)上來看，我們可以支持更多的HDFS集群，在上面暴露給業(yè)務(wù)方的是一個(gè)統(tǒng)一的yarn和Hive metastore。通過底層的改變，我們希望用戶如果通過metastore的訪問可以做到透明。但是如果用戶直接訪問HDFS層，就需要通過設(shè)置一個(gè)缺省的hdfs集群保持不變。

需要多HDFS集群是由于單節(jié)點(diǎn)的NameNode壓力導(dǎo)致。在去年9月份時(shí)一億的元數(shù)據(jù)增長一年就到了兩億元數(shù)據(jù)，數(shù)據(jù)增長非常快。對(duì)于平臺(tái)方來講，我們需要未雨綢繆。這樣如何橫向擴(kuò)展NameNode能力就被提上了日程。

目前業(yè)界比較普遍的做法是采用Federation，我們?cè)谡{(diào)研后發(fā)現(xiàn)federation需要業(yè)務(wù)分割的比較清楚，這和我們目前的業(yè)務(wù)模式不是非常吻合，而且它需要通過比較重的客戶端ViewFS來實(shí)現(xiàn)，需要使用mounttable的掛載方式，這就好比為行駛中的汽車換輪胎一樣。有沒有一種更加輕量級(jí)的方法來實(shí)現(xiàn)類似的橫向擴(kuò)展呢？

多HDFS擴(kuò)展首先需要解決的問題是如何透明地支持上層應(yīng)用。我們用的方法是使用Hive的location特性使得表的location是可以區(qū)分集群的。這個(gè)可以支持一個(gè)表的不同分區(qū)在不同HDFS集群上面。

在xml配置上，和federation 非常類似,但是去除了部分關(guān)于mount table的配置和減少重客戶端viewFS的方式。我們?cè)黾恿薸nternal.dataservices的屬性，來指定缺省的集群。

我們已經(jīng)部署了半年時(shí)間，對(duì)用戶唯一不方便的地方則是直接寫hdfs的程序使用具體的集群，由于我們?cè)谂渲美锛恿薸nternal.nameservices，如果用戶不寫，缺省就會(huì)到缺省的集群。各方面反映還是不錯(cuò)的。

Yarn分配container性能優(yōu)化

第三部分是圍繞Yarn做的優(yōu)化。

問題的提出是這樣的，在優(yōu)化以前每一個(gè)containser分配資源需要0.8ms，那么總共7萬個(gè)container，如果順序分配完的話就需要大約1分鐘。這個(gè)需要進(jìn)行優(yōu)化。

優(yōu)化首先要了解分配原理是怎樣的。唯品會(huì)使用的yarn的分配策略是fair scheduler，它的特點(diǎn)是傾向于公平分配。調(diào)度器每次選擇作業(yè)資源缺額最大的。那么每一次分配逐層遍歷并根據(jù)缺額進(jìn)行倒排序，然后嘗試分配。

我們通過打metrics將耗時(shí)進(jìn)行了分析，發(fā)現(xiàn)分配資源占了一半時(shí)間。當(dāng)然分配失敗是有很多種原因的，這里不一一列舉了。我們的關(guān)注點(diǎn)在于如何提高資源分配的成功率，這將會(huì)縮短分配時(shí)間，提高分配效率。

有了前面的分析以后，新的分配算法就呼之欲出了。我們通過分配container不排序同時(shí)啟發(fā)策略，從上一次index開始繼續(xù)分配。這個(gè)方法提高了分配的時(shí)間效率，當(dāng)然這是一種trade-off。

從優(yōu)化結(jié)果看，提高了近一倍的分配效率。

基于Hook的Capping資源管控

最后再講一下以capping的流量控制為基礎(chǔ)的資源管控。

這個(gè)資源管控問題源自于交通控制問題。那么在交通繁忙的時(shí)候，馬路上公交車的優(yōu)先級(jí)比私家車高，救火車的優(yōu)先級(jí)又比公交車高。這個(gè)原理同樣可以應(yīng)用于Hadoop的資源管控。

實(shí)現(xiàn)作業(yè)資源管制的方法是首先我們能夠認(rèn)識(shí)來的作業(yè)是什么項(xiàng)目的，作業(yè)的優(yōu)先級(jí)設(shè)置是怎樣的。在平臺(tái)這一層還需要配置不同優(yōu)先級(jí)的隊(duì)列，就像馬路上不同的車道一樣的道理。這里核心功能就是engineswitch可以通過讀取metadata，給作業(yè)填上不同的隊(duì)列信息進(jìn)行作業(yè)提交。

有了capping控制模塊以后，作業(yè)將不會(huì)直接提交到集群，而是調(diào)用hook首先感知系統(tǒng)資源使用繁忙程度，然后比較隊(duì)列capping閾值，再?zèng)Q定是否直接提交還是繼續(xù)等待。我們?cè)O(shè)置了等待重試6次將會(huì)直接設(shè)置作業(yè)失敗。

通過一個(gè)實(shí)際例子，我們可以更加清楚地了解這個(gè)原理。Root.bigdata_traffic.critical 和root.bigdata_traffic.online是兩個(gè)三級(jí)隊(duì)列，他們的capping閾值是不同的。在高峰期，他們的capping值分別是1和0.9。當(dāng)系統(tǒng)繁忙root.usage在0.95時(shí)，critical這個(gè)關(guān)鍵隊(duì)列里的作業(yè)就可以提交作業(yè)，而online隊(duì)列就被堵塞了。直到root.usage下降了或者到了非高峰期的閾值變成了0.95。

另外一點(diǎn)是我們已經(jīng)實(shí)現(xiàn)了為各業(yè)務(wù)團(tuán)隊(duì)配置資源的限額（Quota），一旦該團(tuán)隊(duì)當(dāng)日使用量超過日Quota值，系統(tǒng)將會(huì)自動(dòng)降級(jí)該團(tuán)隊(duì)下面隊(duì)列的Capping閾值。

感謝各位，以上是我們?cè)?017年做的一部分工作，歡迎指正。

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。