魅族大數據運維平臺實踐

1、大數據平臺介紹

1.1大數據平臺架構演變

 

如圖所示魅族大數據平臺架構演變歷程：

2013年末，咱們開始實踐大數據，並部署了測試集羣。當時只有三個節點，由於咱們起步比較晚，沒有遇上Hadoop1.0，直接是用YARN來跑的大數據集羣，並且默認就上了HA功能；

2014年9月節點增長到20個，數據日增30GB；

2015年6月上線Spark和Hbase，同時節點達到100個，數據日增10T；

2016年5月實現數據異地災備；

如今咱們主要在作大數據安全方面，包括用戶認證和受權。目前規模已達到近千臺服務器，存儲30PB，日增60TB，天天跑2萬個計算任務，業務包括搜索、廣告、推薦、統計分析、用戶畫像、崩潰跟蹤等等，今年還準備上線一個新機房，專門用來跑大數據業務。屆時節點將達到2000個以上。

 

上圖展現的是魅族大數據的總體架構，組件不少，組件之間相互關聯，提供的應用也不少。

1.2 大數據運維的挑戰

運維這樣一個大規模的平臺要面對哪些挑戰呢？

首先來看大數據運維的特色。

l 集羣規模、數據量大，且爆發式增加。大數據從字面上理解就是「大」，數據量大、規模大，並且是爆發式增加。

l 組件多，相互關聯，關係複雜。

l 組件批量部署、上下線。部署上線的時候通常都是批量進行的，若是用傳統方式（好比腳本工具）操做的話效率很是低，且容易出現問題。

大數據運維的特色決定了大數據運維的核心問題主要體如今兩個方面：

l 一是如何管理好如何大規模的集羣；

l 二是如何爲用戶提供高質量的服務。

所以，大數據運維的目標是：

l 以解決運維複雜度的自動化爲首要目標。自動化可以提高穩定性，機器的操做比人要靠譜，固化的操做交給機器去作，能夠下降人爲形成的一些錯誤，提升線上的穩定性；；另外一方面，自動化可以提升效率，把大部分操做交給機器以後，把運維人員從平常繁瑣的操做中解放出來，咱們就有更多的時間完成更加有意義、有價值的事情。

l 以預測和自動決策爲目標的智能化。大數據運維的趨勢正在從以解決運維複雜度爲目標的自動化，向以預測和自動決策爲目標的智能化轉變，因此咱們先要作好自動化才能夠擁抱智能化。

1.3大數據運維存在的問題

 

大數據運維存在的問題包括：

l 部署及運維複雜。

l 重複監控、重複告警、監控分散。

l 權限控制、安全審計、任意跑任務。咱們沒有對用戶的權限進行限制，一個用戶拿一個帳號就能夠訪問整個集羣的數據，安全審計方面咱們沒法得知該用戶是否訪問敏感數據。另外，在Hadoop官網上也沒有完善的用戶管理體系和開箱即用的安全設置，須要咱們摸索和實踐。

l 沒法查詢業務資源使用、任意申請資源。在資源使用上，咱們不知道業務天天用了多少存儲、多少計算資源，業務要擴容也只是口頭說資源不夠了，並且運維他也沒有足夠的理由不給。

2、大數據運維平臺建設

2.1 平臺選型

 

首先要選擇一個適合本身需求的平臺進行開發。如今比較有表明性的平臺選型是Cloudera和Hortonworks，固然咱們也能夠本身進行組件開發。基於公司的現狀，用商業產品成本太大，徹底照搬開源產品又不能知足咱們的需求。

 

對比來看商業化產品和開源產品：

l 商業化產品，優勢是安裝部署很是簡單，界面功能齊全；缺點是更新比較慢，由於它是非開源的，咱們沒法對其進行優化，並且通常商業化產品佔用系統資源也比較高。

l 開源產品，優勢是很是開放、自由，有強大的社區支持，安裝部署方便；缺點是穩定性比較差，功能比較固定。

l 還有第三種選擇，就是自研，咱們獨立研發產品，這樣就能夠實現定製化，功能靈活豐富，但一樣存在缺點：耗時耗力，研發成本很是高。

咱們的作法是集中三者的優勢，在投入較低成本的狀況下，得到功能豐富、可定製化、穩定迭代的管理平臺，在出現問題的時候咱們又能夠依靠強大的社區獲得快速解決。

2.2組件版本選型

 

基於業務發展需求，以及考慮到組件自己的穩定性和安全性，咱們須要在不一樣階段對組件的版本進行迭代和微調，因而可知商業方案和開源方案是走不通的，這些方案的版本都比較固定。

2.3運維規範制定

 

在平臺化建設以前，咱們作了不少技術規範，經過標準化來規範運維操做，平臺化來落地標準化。

l 系統規範，主要是約束系統的版本、內核、系統帳號等；

l 部署規範，主要是約束組件的版本、配置等；

l 擴容和升級規範，主要是用來制定擴容的窗口期等；

l 任務運行規範，好比說一個任務不能一天24小時跑下去；

l 監控標準，咱們儘量的避免規範形成的事故。

咱們經過制定規範來約束人員操做，最大限度避免因不規範形成的運維事故。

2.4平臺建設歷程

 

上圖是咱們整個平臺建設的歷程。

l 首先經過平臺將固化操做自動化，並經過平臺化落地規範。

l 而後是創建統一的監控與告警平臺。

l 第三是創建全面的安全防禦。

l 最後是實現資源使用可視化、成本化。

2.4.1 平臺化、自動化

如圖，以一個集羣的生命週期展現大數據運維是如何作到平臺化和自動化的。

裝機平臺&雲平臺 

第一步是初始化，也就是系統的安裝。根據機器的不一樣，分爲物理機和虛擬機。物理機有裝機平臺，在平臺上能夠批量安裝物理機操做系統，規範系統版本和帳號。虛擬機也有云平臺，能夠批量建立並初始化雲主機，可用於跑一些臨時任務或實驗性的集羣。

集羣管理

集羣管理方面，以前說到的商業化產品也好，開源產品也好，通常都是針對單個集羣來進行管理的。若是有多個集羣，就必須部署多套平臺來進行管理，這在必定程度上增長了運維的複雜度。

 

咱們的作法是將多套集羣統一管理起來，它們又擁有各自獨立的空間互不干擾。在產品層面上實現前羣分組管理，下降了運維難度，提升了運維效率。

主機管理

在平臺上能夠查看主機狀態、過濾主機列表、執行主機級操做，好比爲一些主機進行開關機操做，還能夠刪除主機、添加主機作機架管理、機架展現等。

 

主機列表

在主機列表頁面，能夠方便地看到主機詳情和組件情況，健康狀態、使用狀態，包括CPU、內存、磁盤等方面的狀況。

 

主機的健康狀態主要分爲四種，若是圖標是紅色，表示主機上至少有一個master組件掛掉了；橙色表示至少有一個Stave組件是掛掉的；黃色表示主機三分鐘沒有上報心跳了；藍色則表示主機運行狀態正常。

組件運維

在組件運維方面，能夠看到全部的組件概述和狀態，也能夠實施組件級別的啓停操做、添加刪除組件、修改組件配置、執行組件的操做。集羣完整的生命週期應該包括下線，就是回收階段，這部分也比較好理解，基本上就是把上面的四步倒過來操做就能夠了。

 

經過平臺化咱們落地了標準化，自動化又大大下降了大數據集羣部署的難度，提升了運維效率，保證了集羣的穩定性。

2.4.2 統一監控和統一告警

監控數據收集架構（時序指標）

前面提到傳統大數據監控是比較分散的。咱們的方案是用AMBARI指標監控系統，它能夠統一監控平臺各種服務及主機的運行狀況，提供各種服務及主機的相關指標，從而達到判斷集羣健康狀況的目的。整個流程包括監控指標的採集、存儲、聚合及指標獲取。

數據的收集流程

 

首先是位於主機上的AMS Client會不斷的收集集羣相關的各項指標和性能數據發送到ams的 metric collector，metric collector會將收集到的數據分別存到兩張表裏面

一張是以主機爲單位的指標信息表，一張是以集羣爲單位的指標聚合信息表。

而後是指標的獲取，Ambari提供了兩種方式：一種是經過指標獲取中心獲取；另外一種是經過Ambari Server端獲取，前一種方式更接近於原生的指標數據，後一種方式則是更爲經常使用的方式，能夠說Ambari上層指標的獲取都是經過這種方式來獲取的，但本質上仍是調用的第一種方式，拿到庫中的原生數據，再進行加工及邏輯處理，最後返回到WEB端。

統一告警平臺：接收告警並根據規則發送給責任人

 

有監控的需求就有告警的需求，但告警不能僅僅是對信息的轉發，否則會讓告警接收人員淹沒在茫茫告警信息裏面，全部的告警信息必需要有一個統一的平臺進行接管，平臺對收到的信息進行必要的和按規則設定進行合併再發送。

咱們開發統一告警平臺的目的解決報警遺漏、對非值班人員的打擾以及減小告警疲勞，確保報警/故障/提醒通告等及時、準確、高效地通知到具體人員。經過優化現有報警處理流程，咱們引入值班機制、告警升級機制、告警合併收斂規則，作到故障的準確通知。經過統一監控平臺和統一告警平臺，下降大數據告警設置的難度，同時也提升了運維人員對告警的敏感度。

2.4.3認證、受權、審計全面防禦Hadoop

 

全面防禦Hadoop。咱們最先部署Hadoop集羣時並無考慮安全問題，隨着集羣的不斷擴大， 各部門對集羣的使用需求增長，集羣安全問題就顯得頗爲重要。經過上圖來看從裏到外的安全防禦體系主要包括哪些方面。

l 最裏面的是OS級別的安全，主要是一些帳號設置等。

l 第二方面是權限控制，主要是對特定資源和特定訪問用戶進行受權或拒絕訪問。權限控制是創建在安全認證基礎上的。

l 第三層次是安全認證，安全認證是對用戶的身份進行覈對，確保用戶是正確的用戶，咱們用的是Kerberos體系。

l 最後是網絡邊界安全體系，包括硬件防火牆，VLAN/子網隔離等等。

l 經過這四層，咱們保證進來的用戶都是經過安全認證的，並且是有權限去操做這個集羣的。但用戶操做是否合理、到底訪問了哪些數據，或者說有沒有嘗試訪問敏感數據，這就要交給審計來作了，安全審計對數據安全也是相當重要的。OS級別的安全和網絡安全通常都是統一的，這裏不作展開。

安全認證

Hadoop的安全認證是基於Kerberos來作的，Kerberos是一個網絡身份驗證協議，用戶輸入本身的驗證信息來進行驗證，若是驗證經過，會獲取到ticket，用戶拿這些ticket去訪問多個接入Kerberos的服務。

它主要解決了服務器到服務器的認證，解決了Client到服務器的認證，但對用戶級別的認證沒有實現，也就是說它沒法限制用戶提交做業。

Hadoop自己並不串接用戶帳號，它主要是經過Kerberos協議對用戶的身份進行驗證。咱們從 YARN 上的 MR 任務提交過程簡單說明一下。

 

在客戶端執行任務以前，它會先跟KDC作自我驗證，獲取TGT，客戶端經過TGT向KDC請求服務ticket，KDC 生成 session key 後一併發給客戶端，客戶端拿到ticket以後，向服務驗證本身，完成身份驗證。

權限控制

權限控制咱們用的是Hadoop系統當中的安全管理框架Apache Ranger來實現，它是一種定義和管理安全策略的集中式組件，裏面內置了一些通用的策略防禦和策略模型，這些安全策略在Hadoop支持的組件上會被強制執行。

如上圖，咱們來看一下策略執行過程。

首先用戶請求資源，匹配到該資源的全部權限，而後對全部資源進行檢查，先看是否是在拒絕訪問列表裏，若是在就拒絕訪問，若是不在就看是否是在容許列表裏，若是在就容許訪問，若是不在，就拒絕訪問，或者作決策下放。Ranger能夠選擇將決策下放給系統自己的訪問控制層。

 

Ranger架構

 

Ranger架構主要由三個部分組成：

第一部分是同步用戶，它會按期加載用戶，而後同步給管理中心；

第二部分是管理中心，管理中心提供接口，同時也執行用戶設置的策略。

第三部分是客戶端的插件。這些插件會被嵌入到組件執行流程當中，按期向管理中心拉取策略，用來執行這個策略的訪問決策。固然它也會按期把這些訪問的審計日誌記錄起來。

 

安全審計

 

安全防禦的最後一環是審計。審計咱們用的是Apache Eagle框架，它是一個高度可擴展的行爲監控警報平臺，採用了靈活的應用框架和通過實踐考驗的大數據技術，如 Kafka，Hbase和 Storm。提供了基於元數據驅動的告警引擎和高度可定製的告警策略來報告異常行爲的發生，實時監控用戶的操做行爲，實時檢測敏感數據訪問和惡意數據操做。

Apache  Eagle框架主要由三個部分組成：

l 首先是數據流的接收和存儲。Eagle支持任何類型的數據流接收到它的策略引擎中。好比HDFS的審計機制能夠經過Kafka將這些資質收集過來，發送到簡單的策略執行當中進行處理。

l 第二部分是主機的實時數據處理引擎，Eagle提供一個獨立於物理平臺的高效流處理API，處理實時發過來的數據。

l 第三個是告警，它提供了靈活的告警框架。

Eagle的應用場景，主要是用來作數據行爲監控。

l 監控Hadoop中的數據訪問。

l 檢測非法入侵和違反安全規則的行爲。

l 檢測敏感數據訪問，防止數據丟失。

l 基於策略的實時檢測和預警

l 基於用戶行爲的異常檢測

安全是互聯網產品的生命基線，咱們經過認證、受權、審計全方位的防禦Hadoop的安全，保障了大數據集羣的穩定運行。而成本則是最終校驗運維效率的標準，如人力成本的節約、業務資源使用的把控都是運維價值的直接體現。

2.4.4資源可視化、成本化

在進行資源可視化、成本化以前，咱們經常不知道一個業務資源使用是否合理、資源擴容是否有必要。經過對業務資源的可視化、成本化，能夠統計業務資源消費、展現業務消費明晰、任務詳細信息，能夠提供業務彈性依據，爲推進業務優化計算任務提供有利依據。

 

在這個平臺上咱們直觀給出每一個業務系的CPU、內存、存儲的佔用狀況、使用的時長，以及轉換的成本，同時也能夠經過消費曲線觀察異常消費，進行成本優化。

 

咱們還從用戶的維度給出消費明細，作到有理有據，便於後面的一些反查。

 

同時還能夠了解到任務詳細運行狀況。好比任務的類型，何時啓動，何時結束，使用時長等。

以上所述是大數據運維平臺建設過程中所用的一些方法論和技術。

3、總結與展望

3.1 總結

l 在質量和效率上，闡述了大數據運維平臺化和自動化的必要性，實現了集羣、主機、組件自動化部署與管理；

l 在安全上，解決了誰有權限、有什麼權限、作了什麼的問題，保證了平臺的安全；

l 在成本上，作到了有圖有真相，伸縮有依據，優化有目標。

3.2 展望

l 大數據運維的整體目標是用盡量低的成原本提供足夠好的服務質量和用戶體驗。網絡帶寬、服務器、維護人力是大數據成本主要的來源，咱們但願經過大數據分析技術，對硬件故障的預測和自動化進行管理，對機器的管理實現零投入，最大化利用資源，減小預算開銷。

l 提供高質量業務運維服務，咱們但願用戶能夠經過平臺申請自動建立交付集羣，開展業務運營。

l 同時咱們也但願運維團隊能夠充分利用大數據分析技術提高預測、發現和自動檢測的能力，預測分配資源，動態伸縮集羣，實現智能預警，自動修復，推進運維向智能化方向發展。

11月9-12日，北京國家會議中心，第六屆TOP100全球軟件案例研究峯會，魅族科技主題桌面負責人譚林英將分享《手機廠商如何作互聯網產品》。

TOP100全球軟件案例研究峯會已舉辦六屆，甄選全球軟件研發優秀案例，每一年參會者達上萬人次。包含產品、團隊、架構、運維、大數據、人工智能等多個技術專場，現場學習谷歌、微軟、騰訊、阿里、百度等一線互聯網企業的最新研發實踐。

更多TOP100案例信息及日程請前往[官網]查閱。4天時間集中分享2017年最值得學習的100個研發案例實踐。本平臺共送出10張開幕式單天免費體驗票，數量有限，先到先得。