唯品會大數(shù)據(jù)平臺優(yōu)化

作者：蔡永承

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

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

集群監(jiān)控

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

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

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

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

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

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

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

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

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

Hive在多HDFS集群上的實踐

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

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

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

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

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

在xml配置上，和federation 非常類似,但是去除了部分關于mount table的配置和減少重客戶端viewFS的方式。我們增加了internal.dataservices的屬性，來指定缺省的集群。

我們已經(jīng)部署了半年時間，對用戶唯一不方便的地方則是直接寫hdfs的程序使用具體的集群，由于我們在配置里加了internal.nameservices，如果用戶不寫，缺省就會到缺省的集群。各方面反映還是不錯的。

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

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

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

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

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

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

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

基于Hook的Capping資源管控

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

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

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

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

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

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

感謝各位，以上是我們在2017年做的一部分工作，歡迎指正。

生成海報

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