大數據平台在唯品會近幾年有了飛速發展，已經完成了從0到1的過程，各個部門逐漸將其引入到實際業務中。 “百尺竿頭，更進一步”，在業務壓力和集群負載同步增加的情況下，如何實現平台優化是2017年的主旋律。
我們不可能面面俱到講所有新東西，主要從集群健康和資源有效利用角度進行探討，圍繞集群監控，HDFS，Yarn和Capping調度來展開。
集群監控
這個技術架構主要關注於離線數據平台。原始數據通過flume和sqoop接入不同的數據源，離線的ETL主要通過Hive 和SparkSQL進行數據處理。Presto主要用於Ad hoc的查詢任務。這些工作都在數據開發平台自研的數坊中進行。ETL開發自助的數據查詢、定時任務ETL開發以及自助報表訂閱，這些作業通過調度程序和作業前置依賴進行調度。在前端我們開發了自助分析平台和各種數據產品，比如比價選品、魔方等數據應用於生產。
Hadoop集群開始於2013年，已經有4年時間了。我們從0開始建設，到現在有一個將近1000個節點主的集群以及一個用於實時離線融合的SSD集群。我們正在升級Hadoop以及Hive到最新版本。目前每天運行作業10萬，yarn app達到50萬以上。
首先，通過專為海量數據批量處理設計的Hadoop集中式存儲數據的平台，數據進入Hive數據倉庫后，任意表就能關聯、合並和計算，同時還保存了全量數據。SQL基本是個人人都會的開發語言，在唯品數坊中通過SQL查詢和處理數據，結合調度系統，就可以自動處理，合理分配資源執行大數據量的數據批量任務。對於個性化推薦需求，機器學習pipeline建立了DAG，開發者通過DAG Editor就可以通過拖拉的方式建立機器學習實例，並且分布式進行調度。大數據除了應用於內部數據分析工具外，還出品線上業務的數據產品比如消費者在前端看到的實時個性化推薦，內部比價系統和供應商用於生產的售中組貨，魔方等。
大數據平台主要職責是維護集群的穩定性，提供充足的資源以及多樣化場景的需求。這個和我們面對的挑戰是一致的。集群穩定性很重要的一點是可以通過平台監控來感知平台的隱患和壓力。在監控中發現集群壓力，我們下一步就要進行性能優化。優化后我們通過監控系統查看效果。這在整體上是一個閉環的過程。
系統告警在框架上必須滿足三大要求：第一是必須全部覆蓋機器層面、日志層面和服務層面，不可偏頗；第二必須是實時監控，遇到故障需要從郵件、短信和電話不同級別地升級和降級；第三也是非常重要的，就是告警規則必須是容易配置的。
用ES來監控日志文件和Zabbix來做機器層面的監控是我們做了比較久的，今年我們新的嘗試是引入Prometheus和Grafna來重構服務層的監控。Prometheus相當於就是開源版本的Borgmon，而Borgmon是Google內部做大規模集群的監控系統。唯品會使用Prometheus主動Pull各種指標數據通過Grafana完美展現部門大屏dashboard。目前Grafana已經對接原有的Zabbix數據源和ES數據源，同時開通了基於jmx的各種開源組件監控，包括Kafka，Hadoop，Cassandra等，對接郵件、短信和電話告警用於生產。
這里簡單介紹一下如何通過Prometheus做服務層面的監控原理。Preometheus 是采用pull的模式而不是通過玩agent的方式拿數據，這樣的好處就是不用客戶端的強依賴。但是prometheus對於數據格式是有要求的，所以在這里首先需要建立一個Http Server來將metrics轉換成prometheus認識的文本格式。這里的例子是獲取kafka lagoffset，然后這個服務開放以后，prometheus就可以主動pull這個網址來實時抓到數據了。
Prometheus拿到數據后就會存儲到本地或者remote的存儲，前端Grafana的配置也是非常簡單的，定義好數據源和metrics，加到Graph就可以了。在這個配置中，可以通過嵌入的web hook來定義告警規則。規則定義也是所見即所得，運維人員非常容易上手。
通過Grafana展示可以校驗監控數據的鏈路。Grafana提供了托拉拽的功能，我們把各種不同的metrics監控圖組合成立了一個部門大屏。通過統一制定大屏，我們可以對系統情況一目了然。我現在每天上班的第一件事情，就是打開這個部門大屏查看系統情況。
Hive在多HDFS集群上的實踐
說完了監控部分，我們開始今年的一個落地嘗試–實現多HDFS集群。在調研落地時我們發現目前比較流行的社區Federation方案與業務不是非常兼容。在這個基礎上，我們研究了多HDFS集群的應用，保持一個YARN、支持多個HDFS集群方式。該實踐的特點是通過Hive層來使HDFS透明化，最大限度兼容原來的應用。
從多HDFS架構上來看，我們可以支持更多的HDFS集群，在上面暴露給業務方的是一個統一的yarn和Hive metastore。通過底層的改變，我們希望用戶如果通過metastore的訪問可以做到透明。但是如果用戶直接訪問HDFS層，就需要通過設置一個缺省的hdfs集群保持不變。
需要多HDFS集群是由於單節點的NameNode壓力導致。在去年9月份時一億的元數據增長一年就到了兩億元數據，數據增長非常快。對於平台方來講，我們需要未雨綢繆。這樣如何橫向擴展NameNode能力就被提上了日程。
目前業界比較普遍的做法是采用Federation，我們在調研后發現federation需要業務分割的比較清楚，這和我們目前的業務模式不是非常吻合，而且它需要通過比較重的客戶端ViewFS來實現，需要使用mounttable的掛載方式，這就好比為行駛中的汽車換輪胎一樣。有沒有一種更加輕量級的方法來實現類似的橫向擴展呢？
多HDFS擴展首先需要解決的問題是如何透明地支持上層應用。我們用的方法是使用Hive的location特性使得表的location是可以區分集群的。這個可以支持一個表的不同分區在不同HDFS集群上面。
在xml配置上，和federation 非常類似,但是去除了部分關於mount table的配置和減少重客戶端viewFS的方式。我們增加了internal.dataservices的屬性，來指定缺省的集群。
我們已經部署了半年時間，對用戶唯一不方便的地方則是直接寫hdfs的程序使用具體的集群，由於我們在配置里加了internal.nameservices，如果用戶不寫，缺省就會到缺省的集群。各方面反映還是不錯的。
Yarn分配container性能優化
第三部分是圍繞Yarn做的優化。
問題的提出是這樣的，在優化以前每一個containser分配資源需要0.8ms，那么總共7萬個container，如果順序分配完的話就需要大約1分鍾。這個需要進行優化。
優化首先要了解分配原理是怎樣的。唯品會使用的yarn的分配策略是fair scheduler，它的特點是傾向於公平分配。調度器每次選擇作業資源缺額最大的。那么每一次分配逐層遍歷並根據缺額進行倒排序，然后嘗試分配。
我們通過打metrics將耗時進行了分析，發現分配資源占了一半時間。當然分配失敗是有很多種原因的，這里不一一列舉了。我們的關注點在於如何提高資源分配的成功率，這將會縮短分配時間，提高分配效率。
有了前面的分析以后，新的分配算法就呼之欲出了。我們通過分配container不排序同時啟發策略，從上一次index開始繼續分配。這個方法提高了分配的時間效率，當然這是一種trade-off。
從優化結果看，提高了近一倍的分配效率。
基於Hook的Capping資源管控
最后再講一下以capping的流量控制為基礎的資源管控。
這個資源管控問題源自於交通控制問題。那么在交通繁忙的時候，馬路上公交車的優先級比私家車高，救火車的優先級又比公交車高。這個原理同樣可以應用於Hadoop的資源管控。
實現作業資源管制的方法是首先我們能夠認識來的作業是什么項目的，作業的優先級設置是怎樣的。在平台這一層還需要配置不同優先級的隊列，就像馬路上不同的車道一樣的道理。這里核心功能就是engineswitch可以通過讀取metadata，給作業填上不同的隊列信息進行作業提交。
有了capping控制模塊以后，作業將不會直接提交到集群，而是調用hook首先感知系統資源使用繁忙程度，然后比較隊列capping閾值，再決定是否直接提交還是繼續等待。我們設置了等待重試6次將會直接設置作業失敗。
通過一個實際例子，我們可以更加清楚地了解這個原理。Root.bigdata_traffic.critical 和root.bigdata_traffic.online是兩個三級隊列，他們的capping閾值是不同的。在高峰期，他們的capping值分別是1和0.9。當系統繁忙root.usage在0.95時，critical這個關鍵隊列里的作業就可以提交作業，而online隊列就被堵塞了。直到root.usage下降了或者到了非高峰期的閾值變成了0.95。
另外一點是我們已經實現了為各業務團隊配置資源的限額（Quota），一旦該團隊當日使用量超過日Quota值，系統將會自動降級該團隊下面隊列的Capping閾值。