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

作者：蔡永承

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

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

集群監(jiān)控

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

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

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

大數據平臺主要職責是維護集群的穩(wěn)定性，提供充足的資源以及多樣化場景的需求。這個和我們面對的挑戰(zhàn)是一致的。集群穩(wěn)定性很重要的一點是可以通過平臺監(jiān)控來感知平臺的隱患和壓力。在監(jiān)控中發(fā)現集群壓力，我們下一步就要進行性能優(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各種指標數據通過Grafana完美展現部門大屏dashboard。目前Grafana已經對接原有的Zabbix數據源和ES數據源，同時開通了基于jmx的各種開源組件監(jiān)控，包括Kafka，Hadoop，Cassandra等，對接郵件、短信和電話告警用于生產。

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

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

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

Hive在多HDFS集群上的實踐

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

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

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

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

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

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

我們已經部署了半年時間，對用戶唯一不方便的地方則是直接寫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è)資源缺額最大的。那么每一次分配逐層遍歷并根據缺額進行倒排序，然后嘗試分配。

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

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

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

基于Hook的Capping資源管控

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

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

實現作業(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。

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

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

生成海報

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