Hadoop叢集從180到1500，攜程大資料實踐之路

摘要

攜程大家應該是蠻熟悉了吧，全國領先的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訓練的固定流程。當模型訓練好並達到所制定的指標和要求之後，接下來就是上線，這部分分為特徵上線和服務上線。

我們期望通過圖中所示的3個平臺來支援AI研發的整個生命週期。以特徵管理平臺管理所有的特徵，能夠支援特徵工程，快速生成一些訓練集和測試集，能夠以更為簡便的方式上線特徵。

模型引擎主要用來cover服務上線過程，目標是讓使用者只需要開發必要的資料抽取邏輯等，其他的部分都可以通過配置的方式來形成上線服務，該模組後續計劃會和我們公司的釋出系統打通。而針對AI訓練部分，我們希望通過AI訓練協作平臺來幫助使用者更好的完成任務。

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

特徵平臺的特徵配置包括基礎資訊、資料來源、計算邏輯、儲存資訊。我們的特徵平臺想做的是通過統一的SQL方式表示特徵的計算邏輯，並以key value的形式儲存。對於特徵提取我們提供了對應API，使用者可以通過特徵ID和別名來獲取相關特徵。

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

第一期的模型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資料開發的工程技術能力；短期的全員客服等。

（文中相關資料，以演講當時為準，可能和實際情況有所差異）