Hadoop集羣從180到1500，攜程大數據實踐之路

內容來源：2018 年 09 月 08 日，攜程大數據平臺技術總監張翼在「2018開源數據庫論壇暨首屆MariaDB中國用戶者大會」進行《大數據平臺在攜程的實踐》演講分享。IT 大咖說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：3501 | 9分鐘閱讀

獲取嘉賓演講視頻及PPT，請點擊： t.cn/EZtuxxP。

摘要

攜程你們應該是蠻熟悉了吧，全國領先的OTA平臺，旅遊出行相關的均可以在上面一站式的完成，從酒店和機票的預訂到火車票和汽車票，租車等，只要你能想到的和旅行相關的全部東西，在攜程上均可以輕鬆實現。

攜程大數據平臺現狀

平臺規模

2015年我剛加入攜程的時候，它的Hadoop集羣規模還僅有約180臺，如今已經發展到超過1500臺，也就是8倍的提高。同時天天的數據增量在200T以上，調度任務數9萬，運行的實例超過18萬，其中80%的做業都運行在SparkSQL上。 這些調度任務轉換成底層任務大概是MR Job 27萬，Spark Job 9萬。實時方面咱們如今支持Jstorm和Spark-streaming，整個集羣規模100以上。

平臺架構

上圖爲咱們的平臺架構。底層是自動化運維和監控；中間層是一些開源的大數據基礎架構，分爲批量計算框架和實時框架，批量部分的底層基於hadoop，在此之上的ETO主要是用Hive和Spark，另外還有Presto和kylin；平臺最上層被劃分爲4個系統，開發平臺Zeus、查詢平臺ART、AI開發和管理平臺，以及實時數據平臺Muise。

若是單從界面上來看muise就像一個管理平臺，用戶能夠經過它作一些提交。但其實咱們還對Sprak進行了封裝，並提供本身的library。這是爲了限制併發資源的使用，讓用戶能夠控制併發資源，同時可以觸發外部報警。

系統 「蜻蜓點水」

數據開發平臺總覽

咱們的開發平臺分爲5個系統，最主要的是調度系統Zeus。Datax數據傳輸系統用於給用戶提供快捷配置的界面，用戶操做完成後任務會被提交給Zeus。

主數據管理系統會展現表的信息並分析Job和Job間的依賴關係，以及經過解析SQL獲取總體序列。

數據質量系統中配置了一些質量校驗的規則，在調度系統運行完成以後會觸發質量檢驗任務，若是優先級較高的質量校驗任務失敗就會阻斷主要調度任務執行。最後是統一的權限綁定系統，這部分較爲簡單就很少作贅述了。

今年新進展

AI平臺

雖然今年咱們在底層上也作了不少嘗試，但本次主要仍是講AI相關的基礎設施上的一些工做。

上圖爲簡化的生命週期圖，從數據處理到特徵工程、模型訓練、模型更新這樣的過程，通常是AI訓練的固定流程。當模型訓練好並達到所制定的指標和要求以後，接下來就是上線，這部分分爲特徵上線和服務上線。

咱們指望經過圖中所示的3個平臺來支持AI研發的整個生命週期。以特徵管理平臺管理全部的特徵，可以支持特徵工程，快速生成一些訓練集和測試集，可以以更爲簡便的方式上線特徵。

模型引擎主要用來cover服務上線過程，目標是讓用戶只須要開發必要的數據抽取邏輯等，其餘的部分均可以經過配置的方式來造成上線服務，該模塊後續計劃會和咱們公司的發佈系統打通。而針對AI訓練部分，咱們但願經過AI訓練協做平臺來幫助用戶更好的完成任務。

現階段特徵平臺基本上開發完成，並已上線使用，AI訓練平臺剛剛開發完成，尚處於部署和測試階段，而模型引擎仍在開發過程當中。（截至演講時間）

特徵平臺

特徵平臺的特徵配置包括基礎信息、數據源、計算邏輯、存儲信息。咱們的特徵平臺想作的是經過統一的SQL方式表示特徵的計算邏輯，並以key value的形式存儲。對於特徵提取咱們提供了對應API，用戶能夠經過特徵ID和別名來獲取相關特徵。

特徵提取完成後，用戶會測試特徵上線過程，平臺爲此提供了隨機生成離線和實時任務的能力。離線任務主要是在Zeus的基礎上增長一些傳輸做業。實時方面則會生成blink任務 ，由Kafka讀取數據並處理後放到Spark上。

模型Engine

第一期的模型Engine會提供模型服務的SOA框架，其中包含自動轉換的Input Convertor、Out Convertor。

模型服務的數據通常分爲兩種，經過服務直接輸入的數據或者放在Aerospike上的特徵。用戶要完成的是前面的transformer，作的更多的是根據輸入的配置從Aerospike上獲取特徵，而後拼接在一塊兒，再通過處理獲得結果。後面的transformer基本上和訓練的東西同樣，只要經過配置的方式加載進來就能夠了。

整個SOA框架由模型引擎管理系統負責管理，最後和咱們的發佈系統Tars集成發佈到模型服務集羣中。

大數據平臺建設經驗分享

選型原則

技術選型主要受需求成本、技術趨勢、團隊能力這3點所約束。前兩點相信你們都有考慮到，不過我要強調的是團隊能力也很是重要，它並不是一種靜態的要求，而是動態的過程，須要領導者培養團隊各方面能力以適應不斷出現的新技術。

就拿轉向SparkSQL爲例。不一樣於其餘大廠早就用到了SparkSQL，咱們去年年底纔開始從Hive轉到SparkSQL。一方面是由於SparkSQL在2.2以後解決了不少問題，穩定性上已經達到了咱們的要求；另外一方面是咱們自身的條件也已成熟，團隊中有一兩位同窗已經能夠深刻到Spark源碼上解決問題。正是基於這種條件，咱們才決定啓動全面Hive轉Spark的過程，這也是爲何說團隊能力也很重要的緣由。

案例 - 數據分析基礎設施選型

對於數據分析基礎設施選型咱們首先面臨的問題是，選擇自建仍是使用雲服務，就我我的來看對於小規模沒有特殊需求的數據分析，雲服務是不錯的選擇。

其次是是否要用到Hadoop，這個主要看數據量及其增加狀況，量不大的時候能夠直接用數據庫應對，要用Hadoop的話，如今通常採起HDFS加Spark的方式，數據存儲格式用Parquet、Carbondata、ORC等。

另外還要考慮是否須要實時分析數據，目前這方面都是用的Spark-Streaming或者Flink。最後若是對數據交互查詢的速度要求不高，用Spark就夠了，不然推薦使用Presto、kylin、ClickHouse。

如何「擁抱」新技術

有效和有限的分散——是美國曆史上最成功的基金經理彼得林奇的投資原則之一。它的作法是以90%的資金重倉預先看好的股票，剩下的10%分散到多支股票上，並觀察他們的趨勢，而後將後續趨勢較好的股票升級到重倉池中。

技術的投入其實也適用於這個原則。團隊中大部分的資源應該先放在主要使用的技術上，對底層的系統來講要可以作到「代碼級」維護。少部分的資源能夠放在多種新技術或是平臺的「預備」/ POC上，若是靠譜，能夠開始用在低優先級的系統或項目上，最後也許會變成主要使用的技術。

「成長的煩惱」有什麼

平臺自己的增加確定會給底層的技術人員帶來必定的壓力，主要體如今3個方面。

第一是在運維方面，系統規模的不斷擴大，會使得運維繫統愈加複雜，而且種類也不斷增多。

第二是開源系統的問題，開源是把「雙刃劍」，它能幫你快速構建起相應的系統，但隨着系統規模的增大，問題也會不斷暴露出來。

第三是服務和支持方面，用戶不斷增加的「物質文化需求」與「短小精悍」團隊之間的矛盾，臨時的支持與問題排查工做也會變多。

解決運維問題最重要是在於自動化，而自動化的關鍵的有2個，一是要保證測試環境和線上配置一致，二是覆蓋範圍儘量全，特別是客戶端部分也要涉及到。監控方面比較簡單，主要是監控重要指標並創建自動恢復的機制。

對於開源系統的使用，我認爲仍是要在思想上作好長期鬥爭的準備。最關鍵的是要創建「代碼級」的維護能力，好比招聘時選擇對技術有濃厚興趣，可以沉下心來的同窗；在底層團隊經過各類層次的分享創建學習，研究的氛圍。

服務和支持問題的應對策略能夠分爲幾點，包括從使用者的角度去設計產品，關注產品的易用性；控制推廣的節奏；完善文檔以及常見問題FAQ；加強BU數據開發的工程技術能力；短時間的全員客服等。

（文中相關數據，以演講當時爲準，可能和實際狀況有所差別）

以上爲今天的分享內容，謝謝你們！