大數(shù)據(jù)平臺 | 網(wǎng)易大數(shù)據(jù)平臺運維實戰(zhàn)

各位SACC觀眾，大家好，感謝各位參加本次智能運維實踐會場的最后一場分享會。算是壓軸出場吧，也希望本次的分享能給大家?guī)硪恍嵱玫母韶?，特別是對于有重構(gòu)服務(wù)平臺需求的朋友。 

簡單自我介紹一下，我叫金川，來自網(wǎng)易杭州研究院，目前所在的部門是大數(shù)據(jù)基礎(chǔ)設(shè)施組，負責(zé)大數(shù)據(jù)平臺SRE的相關(guān)工作。如果在分享過程中有任何問題，大家可以先在評論欄中留言，在事后的QA環(huán)節(jié)會為大家統(tǒng)一做解答。

我本次的分享的內(nèi)容包括以下幾個部分：

首先，介紹網(wǎng)易的大數(shù)據(jù)應(yīng)用現(xiàn)狀；

其次，說明下網(wǎng)易大數(shù)據(jù)管控平臺的現(xiàn)狀，內(nèi)部暫定的名稱是EasyOps。取使用方便靈活之意；

再者，介紹通用的大數(shù)據(jù)服務(wù)運維框架；

然后，說明基于Prometheus套件的通用的大數(shù)據(jù)監(jiān)控報警實現(xiàn)；

最后，大數(shù)據(jù)平臺運維實戰(zhàn)經(jīng)驗分享。

這里列舉了目前我們的大數(shù)據(jù)平臺支撐的互聯(lián)網(wǎng)產(chǎn)品矩陣，大頭主要是云音樂、嚴選這2個，同時內(nèi)部還有其他待孵化的產(chǎn)品線，這里就不做舉例了。

平臺使用的技術(shù)棧底層是Hadoop生態(tài)系統(tǒng)，大概有22多個組件；中臺是網(wǎng)易自研的有數(shù)，大概27個組件。我們離線集群分為6個，此外實時集群也有2個主要是運行sparkstreaming或flink作業(yè)。

這里是我們有數(shù)中臺的一些功能模塊，具體的使用的介紹這里不做展開，有興趣的朋友請關(guān)注網(wǎng)易有數(shù)公眾號，針對各個模塊都有詳細的文章介紹。

接下來，介紹下我們使用的大數(shù)據(jù)管控平臺EasyOps。之所以要重新做一套管控工具，是因為我們在使用開源的Ambari系統(tǒng)來部署和管理大數(shù)據(jù)平臺時，遇到了的各類問題。新的管控平臺就是要解決這些問題，當(dāng)然這也是一個逐漸迭代的過程，不會是一蹴而就的事情。

這頁是EasyOps管控平臺關(guān)于HDFS服務(wù)的一個實例的詳情頁面，這里包括了該實例所屬的各類組件和節(jié)點。左側(cè)是所有的服務(wù)列表，右側(cè)是服務(wù)詳情，上方是關(guān)于服務(wù)的一個概要報表。

接下來是管控平臺的主機頁面，我們可以看到接入的所有主機，然后是主機支持的若干操作。

這個是主機的詳情頁，這里可以看到這臺主機上安裝的所有服務(wù)和組件，包括主機本身的一些報表。細心的同學(xué)可能會看出右圖的監(jiān)控報表和NodeExporter很像，是的，我們監(jiān)控主機狀態(tài)用的就是Node Exporter，關(guān)于監(jiān)控的實現(xiàn)，我們在后面會進行介紹，這里暫且不表。

這里是我們的服務(wù)配置頁面，可以支持常規(guī)的配置組、變更歷史切換和任意的配置下發(fā)功能。

這是我們基于Grafana的Dashboard大盤，匯總了所有相關(guān)服務(wù)的監(jiān)控儀表盤。

接下來為大家介紹下通用的大數(shù)據(jù)服務(wù)運維框架，具備一些開發(fā)資源的團隊可以在短時間內(nèi)完成一個可用的服務(wù)運維平臺，這里我們會分這么幾個區(qū)塊來給大家介紹。

一個通用的服務(wù)運維平臺往往會包括以下操作：

其他服務(wù)的特異性操作，譬如HDFS數(shù)據(jù)遷移，HDFS數(shù)據(jù)均衡，YARN的隊列或任務(wù)操作等等

以服務(wù)安裝流程為例，說明一下整個流程……

這個通用的運維框架是以Ansible技術(shù)棧為基礎(chǔ)，包括以上三個主要的功能模塊。

我們使用Ansible Runner目錄結(jié)構(gòu)來組織Playbooks，基本的結(jié)構(gòu)見上圖，在playbook目錄下面是各個組件或服務(wù)的運維操作的入口。

在roles下以服務(wù)名創(chuàng)建目錄，目錄下創(chuàng)建defaults,tasks,templates,vars目錄。

defaults：用于存放默認的變量值，必須創(chuàng)建main.yml文件，調(diào)用role時會自動加載

tasks: 所有的任務(wù)腳本存放的目錄，必須創(chuàng)建main.yml，當(dāng)調(diào)用role時，會調(diào)用main.yml

templates: 用于存放templates模板，生成配置文件

vars: 用于存放動態(tài)的變量值，需要include對應(yīng)的變量文件才會加載

平臺的前端我們使用的技術(shù)方案是……

平臺后端的技術(shù)棧是……

整個平臺的架構(gòu)圖如上……

以之前提到的Ansible的服務(wù)安裝調(diào)用邏輯為例，說明下整個調(diào)用流程……

服務(wù)的配置管理分為以上幾個部分：

上圖是YARN服務(wù)的配置管理，可以看到變更的歷史記錄。

關(guān)于配置文件的參數(shù)變更，我們有這么一個場景，需要能支持任意參數(shù)的配置透傳。我們定義了一套流程來解決上述問題，上面就是一個調(diào)用圖例。

為什么要有配置透傳？很簡單，因為開發(fā)懶，不想每次服務(wù)版本變更增加配置參數(shù)后，還需要進行一次適配。而是按照規(guī)范，為特定的配置文件實現(xiàn)動態(tài)配置添加策略。

接下來我們介紹下通用的大數(shù)據(jù)服務(wù)監(jiān)控報警框架，它基于Prometheus/Grafana等組件實現(xiàn)；內(nèi)部使用的TSDB是基于InfluxDB改造后的NTSDB。

所以很明顯，在集群模式下Prometheus服務(wù)是我們監(jiān)控的核心模塊，為此我們針對分布式和高可用問題，定制了一套架構(gòu)，下面是分布式讀寫實現(xiàn)。

這里是Prometheus的高可用架構(gòu)，所有采集端的prometheus均由prometheusMonitor進行監(jiān)控。當(dāng)一個prometheus無法提供服務(wù)時，會先由watchdog進行重啟；如果依舊無法提供服務(wù)，alarmManager會進行報警，調(diào)用Ansible的相關(guān)接口，拉取無法提供服務(wù)的prometheus的完整配置文件，然后在合適的主機上創(chuàng)建新的實例。

上圖是我們的度量采集方案，有些服務(wù)自己就暴露了prometheus的度量接口，譬如Neo4j，Grafana，Prometheus等，這類服務(wù)我們直接通過prometheus抓取相關(guān)監(jiān)控數(shù)據(jù)即可。JVM服務(wù)我們使用的是micrometer插件（https://micrometer.io/）。

接下來是我們自定義的日志監(jiān)控流程，日志采集可以使用filebeat，logstash等已有的組件，但我們有內(nèi)部的一個DSAgent方案。通過日志采集，流入到kafka，然后我們會有定制的日志分析邏輯，譬如分析異常日志，聚合度量等，消費后的數(shù)據(jù)會分流至ES，NTSDB或者MySQL等存儲，用于可視化或者報警平臺邏輯。

我們的報表系統(tǒng)基于Grafana定制而成。

報警我們可以直接使用Grafana的Alert模塊來實現(xiàn)，通過導(dǎo)入定制的Alert規(guī)則，可以方便對集群的通用性指標統(tǒng)一添加監(jiān)控報警。

簡單，易用，方便移植。使用Grafana更加通用

除此之外我們參考Prometheus的AlertManger組件，改造了Prometheus，用它來實現(xiàn)更靈活的自定義報警邏輯。

接下來我們進入最后一個環(huán)節(jié)，運維經(jīng)驗的交流。我這邊會以這么幾塊內(nèi)容來說明我們的平臺在演進過程中的問題和思路。

從網(wǎng)絡(luò)架構(gòu)、存算分離、服務(wù)上云等方面來介紹平臺的演進過程，這些方面的演進最終目標還是達成成本優(yōu)化。最后從系統(tǒng)、服務(wù)等方面介紹一些性能優(yōu)化的改進點

大數(shù)據(jù)HADOOP業(yè)務(wù)相較于常規(guī)業(yè)務(wù)在流量方面有很大的區(qū)別，hadoop業(yè)務(wù)因數(shù)據(jù)分析、離線計算等需求會對東西向的流量有非常大的需求，但是又因其數(shù)據(jù)存儲功能同時也會存在大量其他業(yè)務(wù)的數(shù)據(jù)存儲到hadoop服務(wù)器中導(dǎo)致南北向的流量也非常大。要滿足這樣的流量模型的需求就需要有一個大收斂比的網(wǎng)絡(luò)架構(gòu)，spine leaf架構(gòu)恰好能滿足這點。（使用老架構(gòu)，解決ARP的廣播問題，而且隔離性好）

Spine類似三層架構(gòu)中的核心交換機，但形態(tài)有所變化：高端口密度高吞吐量的三層交換機替代了大型框式核心交換機，4臺spine設(shè)備為一個pod節(jié)點，結(jié)合ARP轉(zhuǎn)路由使用將網(wǎng)絡(luò)的壓力從集中式負載于核心交換機，變成給許多的leaf交換機來均衡分擔(dān)。

存儲分離在上云過程中一直有提高，這個對于整體的成本優(yōu)化有明顯的好處，我們自己內(nèi)部的評估就是同等存儲和計算規(guī)格條件下，使用存儲分離可以節(jié)省至少20%的成本，同時任務(wù)的性能也能得到較大提升。

這里我們主要使用HDFS Router/Federation架構(gòu)，以及Yarn的Node Label等特性來實現(xiàn)。

最后說到服務(wù)上云的實踐，這里是我們云上實踐的部署架構(gòu)圖。大數(shù)據(jù)上云一般來說最大的困難還是存儲接口的問題，主流的云存儲方案，包括s3，obs，oss等等。

為了提供統(tǒng)一的底層接入環(huán)境，我們引入Alluxio來作為中間層來屏蔽底層的存儲細節(jié)，從而上層的計算框架和平臺只需要做稍微的參數(shù)適配來實現(xiàn)通用的云上部署邏輯。

最后說到性能優(yōu)化，我這里不會說到一些具體的細節(jié)，概要的來說，我們可以參考以上的幾個原則來進行優(yōu)化。

最后是本次的QA環(huán)節(jié)，大家有沒有問題？上面的二維碼是網(wǎng)易有數(shù)的公眾號，我們會定期發(fā)布網(wǎng)易大數(shù)據(jù)的相關(guān)技術(shù)文章和產(chǎn)品介紹，感興趣的朋友可以關(guān)注一下。

今天的分享就到這里，非常感謝大家的聆聽。謝謝大家！