摘要：一大數據平臺介紹大數據平臺架構演變如圖所示魅族大數據平臺架構演變歷程年底，我們開始實踐大數據，并部署了測試集群。因此，大數據運維的目標是以解決運維復雜度的自動化為首要目標。大數據運維存在的問題大數據運維存在的問題包括部署及運維復雜。

一、大數據平臺介紹

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.1 平臺選型

?

首先要選擇一個適合自己需求的平臺進行開發?，F在比較有代表性的平臺選型是Cloudera和Hortonworks，當然我們也可以自己進行組件開發?；诠镜默F狀，用商業產品成本太大，完全照搬開源產品又不能滿足我們的需求。

?

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

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.1 總結

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

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

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

3.2 展望

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

l?提供高質量業務運維服務，我們希望用戶可以通過平臺申請自動創建交付集群，開展業務運營。

l?同時我們也希望運維團隊可以充分利用大數據分析技術提升預測、發現和自動檢測的能力，預測分配資源，動態伸縮集群，實現智能預警，自動修復，推動運維向智能化方向發展。

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

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

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