美團大數據平臺架構實踐

今天給大家介紹的內容主要包括以下四個部分首先是介紹一下美團大數據平臺的架構，然后回顧一下歷史，看整個平臺演進的時間演進線，每一步是怎么做的，以及一些挑戰和應對策略，最后總結一下，聊一聊我對平臺化的看法。

    謝語宸是來自美團的大數據構建平臺的架構師。他在QCon2016北京站分享了一些整體上構建大數據平臺的方法，除了聚焦在某一個點上的還有構建整體的大數據，以及各種各樣技術的應用，希望能給大家一些關于大數據方面的啟迪。
 

    非常感謝給我這個機會給大家帶來這個演講，我是2011年加入美團，最開始負責統計報表還有數據倉庫的建設。2012年推動了數據倉庫分布式化，把分布式計算放到了Hadoop上，之后把數據開發流程放到了線上，2014年帶離線平臺團隊。

    我今天給大家介紹的內容主要包括以下四個部分首先是介紹一下美團大數據平臺的架構，然后回顧一下歷史，看整個平臺演進的時間演進線，每一步是怎么做的，以及一些挑戰和應對策略，最后總結一下，聊一聊我對平臺化的看法。

    1.美團大數據平臺的架構

    1.1總體架構：

    上圖是美團網數據體系組織架構圖，上面每一個豎線都是數據開發業務線，下面是我所在的基礎數據庫團隊， 最下面我們依賴美團云提供的一些虛擬機、物理機、機房等基礎設施，同時我們也協助美團云做了大數據云服務的產品探索。

    1.2數據流架構：

    下面我以數據流的架構角度介紹一下整個美團數據平臺的架構，這是最恢復的架構圖，最左邊首先從業務流到平臺，分別到實時計算，離線數據。

    最下面支撐這一系列的有一個數據開發的平臺，這張圖比較細，這是我們詳細的整體數據流架構圖。包括最左邊是數據接入，上面是流式計算，然后是Hadoop離線計算。

    將上圖左上角擴大來看，首先是數據接入與流式計算，電商系統產生數據分兩個場景，一個是追加型的日志型數據，另外是關系型數據的維度數據。我們對于前一種是使用Flume比較標準化的，大家都在用的日志收集系統。最近使用了阿里開源的Canal，之后有三個下游。所有的流式數據都是走Kafka這套流走的。

    數據收集特性：

    對于數據收集平臺，日志數據是多接口的，可以打到文件里觀察文件，也可以更新數據庫表。關系型數據庫是基于Binlog獲取增量的，如果做數據倉庫的話有大量的關系型數據庫，有一些變更沒法發現等等的情況，通過Binlog手段可以解決。通過一個Kafka消息隊列集中化分發支持下游，目前支持了850以上的日志類型，峰值每秒有百萬介入。

    流式計算平臺特性：

    構建流式計算平臺的時候充分考慮了開發的復雜度，基于Storm。有一個在線的開發平臺，測試開發過程都在在線平臺上做，提供一個相當于對Storm應用場景的封裝，有一個拓撲開發框架，因為是流式計算，我們也做了延遲統計和報警，現在支持了1100以上的實時拓撲，秒級實時數據流延遲。

    這上面可以配置公司內部定的某個參數，某個代碼，可以在平臺上編譯有調試。實時計算和數據接入部分就介紹到這兒，下面介紹一下離線計算。

    離線計算：我們是基于Hadoop的數據倉庫數據應用，主要是展示了對數據倉庫分成的規劃，包括原始數據接入，到核心數據倉庫的基礎層，包括事實和衍生事實，維度表橫跨了聚合的結果，最右邊提供了數據應用：一些挖掘和使用場景，上面是各個業務線自建的需求報表和分析庫。

    這幅圖是離線數據平臺的部署架構圖，最下面是三個基礎服務，包括Yarn、HDFS、HiveMeta。不同的計算場景提供不同的計算引擎支持。如果是新建的公司，其實這里是有一些架構選型的。Cloud Table是自己做的HBase分裝封口。我們使用Hive構建數據倉庫，用Spark在數據挖掘和機器學習，Presto支持Adhoc上查詢，也可能寫一些復雜的SQL。對應關系這里Presto沒有部署到Yarn，跟Yarn是同步的，Spark 是 on Yarn跑。目前Hive還是依賴Mapreduce的，目前嘗試著Hive on tez的測試和部署上線。

    離線計算平臺特性：

    目前42P+總存儲量，每天有15萬個Mapreduce和Spark任務，有2500萬節點，支持3機房部署，后面跨機房一會兒會介紹，數據庫總共16K個數據表，復雜度還是蠻高的。

    1.3數據管理體系：

    數據管理體系特性：

    下面簡單聊一下數據管理體系，這相當于主要面向數據開發者的操作經驗，主要包括自研的調配系統，然后數據質量的監控，資源管理和任務審核一條開發配置中心等等，都是在數據管理體系的，下面會整合到整個的數據開放平臺。

    數據管理體系我們這邊主要實現了幾點，

    第一點我們是基于SQL解析去做了ETL任務之間的自動解析。

    基于資源預留的模式做了各業務線成本的核算，整體的資源大體是跑到Yarn上的，每個業務線會有一些承諾資源、保證資源，還可以彈性伸縮，里面會有一些預算。

    我們工作的重點，對于關鍵性任務會注冊SLA保障，并且包括數據內容質量，數據時效性內容都有一定的監控。

    這是解析出來的依賴關系，紅色的是展示的一條任務，有一系列的上游。這是我們的資源管理系統，可以分析細到每個任務每時每刻的資源使用，可以聚合，給每個業務線做成本核算。

    這是對于數據質量管理中心，圖比較小，上面可以寫一些簡單的SQL，監控某一個表的數據結果是否符合我們業務的預期。下面是數據管理，就是我們剛剛提到的，對每個關鍵的數據表都有一些SLA的跟蹤保障，會定期發日報，觀察他們完成時間的一些變動。

    1.4BI產品：

    上面是BI產品，數據應用平臺化的場景。我們的查詢主要是有一個查詢中心來支持，包括Hive，MySQL，Presto，Kylin等等的引擎，在查詢中心里面我們做SQL解析。前面是一系列的BI產品，大部分是自研的，面向用戶可以直接寫SQL的自主查詢，并且看某一個指標，某一個時間段類似于online的分析數據產品，以及給老大們看的天機系統。

    還有指標提取工具，其實跟商用oneline前端分析引擎設計是比較類似的，選取維度范圍，還有適時的計算口徑，會有一系列對維度適時的管理。數據內容數據表不夠，還會配一些dashboard。

    我們開發了星空展示中心，可以基于前面指標提取結果，配置一系列的餅圖、線圖、柱狀圖，去拖拽，最后build出來一個dashboard。

    2.平臺演進時間線

    2.1 平臺發展

    下面聊一下整個數據平臺發展的時間線。因為我是2011年加入美團的，美團剛剛建立一年左右。最開始2011年的時候，我們主要的數據統計都是基于手寫的報表，就是來一個需求我們基于線上數據建立一個報表頁面，寫一些表格。這里帶來的嚴重的問題，首先是內部信息系統的工作狀態，并不是一個垂直的，專門用做數據分析的平臺。這個系統當時還是跟業務去共享的，跟業務的隔離非常弱，跟業務是強耦合的，而且每次來數據需求的時候我們都要有一些特殊的開發，開發周期非常長。

    我們面對這個場景怎么辦呢？我們做了一個目前來看還算比較好的決策，就是重度依賴SQL。我們對SQL分裝了一些報表工具，對SQL做了etl工具。主要是在SQL層面做一些模板化的工具，支持時間等變量。這個變量會有一些外部的參數傳遞進來，然后替換到SQL的行為。

    我們在2011下半年引入了整個數據倉庫的概念，梳理了所有數據流，設計整個數據體系。做完了數據倉庫整體的構建，我們發現有整體的ETL被開發出來了。首先ETL都是有一定的依賴關系的，但是管理起來成本非常高。所以我們自研了一個系統，另外我們發現數據量越來越大，原來基于單機MySQL的數據解析是搞不定的，所以2012年我們上了四臺Hadoop機器，后面十幾臺，到最后的幾千臺，目前可以支撐各個業務去使用。

    2.2 最新進展

    我們也做了一個非常重要的事就是ETL開發平臺，原來都是基于Git倉庫管理，管理成本非常高，當時跟個業務線已經開始建立自己數據開發的團隊了。我們把他們開發的整個流程平臺化，各個業務線就可以自建。之后我們遇到的業務場景需求越來越多，特別是實時應用。2014年啟動了實時計算平臺，把原來原有關系型數據表全量同步模式，改為Binlog同步模式。我們也是在國內比較早的上了Hadoop2.0 on Yarn的改進版，好處是更好的激起了Spark的發展。另外還有Hadoop集群跨多機房，多集群部署的情況，還有OLAP保障，同步開發工具。

    3.近期挑戰和應對

    3.1Hadoop多機房

    Hadoop多機房背景：

    下面重點講三個挑戰還有應對策略，首先是Hadoop多機房。Hadoop為什么要多機房部署呢？之前只有淘寶這樣做。2015年初我們被告知總機房架位只有500個節點，我們遷到的機房，主要還是機房合同發生了一些違約。我們溝通到新的離線機房需要在9月份交付，2015年6月份我們需要1000個計算節點，12月份的時候需要1500個計算節點，這肯定是不夠的。那就要進行梳理，業務緊耦合，快速拆分沒法支撐快速增長，而且數據倉庫拆分會帶來數據拷貝，數據傳輸成本的，這時候只能讓Hadoop多機房進行部署。

    我們思考了一下，為什么Hadoop不能多機房部署呢？

    其實就兩個問題。

    一個是跨機房帶寬非常小，而且跨機房帶寬比較高，幾十G，可能給力的能上百G，但是機房核心交換節點是超過這些的。而且Hadoop是天生的分布式系統，他一旦跨節點就一定會有跨機房的問題。

    我們梳理了Hadoop運行過程中，跨節點的數據流程，基本上是三種。

    首先是APP內部，就是任務內部的一些Container通信的網絡交換，比較明確的場景就是Map和educe之間。

    第二個是非DataNode本地讀取，如果跨機房部署讀數據就是跨機房的，帶寬量非常大。

    第三個寫入數據的時候要構建一個三節點的pipeline，可能是跨機房的，就要帶來很多數據流量。

    Hadoop多機房架構決策：

    我們當時考慮到壓力，先做多機房的方案再做NameSpace，這跟淘寶方案有所差別。我們每個節點都有一個所屬的機房屬性，把這個東西維護起來，基本上也是基于網絡段判斷的。對于剛剛提到的第一個問題，我們的方案在Yarn隊列上打一個機房的tag，每個隊列里面的任務只會在某一個機房里跑起來，這里要修改一下Yarn fairscheduler的代碼的。

    第二個是基于HDFS修改了addBlock策略，只返回client所在機房的DataNode列表，這樣寫入的時候pipeline就不會有跨機房，讀取也會優先選取clinet所在的機房。還有其他的場景會跨機房，比如說Balancer也是節點之間做數據遷移的。最終我們還做了一件事，就是Balancer是直接DataNode溝通，有通道的，我們是直接構造了Block文件分布工具。

    Hadoop多機房結構效果：

    效果上看，左邊是2015年3月份節點數，300多，2016年3月份是2400多，中間不同的段是每個機房當時承載的節點數。這時候我們只有一個機房了，因為我們整個跨機房，多機房的方案是為了配合一個臨時的狀態，所以它方案前面通過Balancer模塊的接口，把所有數據最終都搬遷到了大的離線計算機房。

    Hadoop多機房架構特點：

    做這個架構的時候，我們設計的時候主要考慮第一代碼改動要小，因為當時我們團隊沒有那么深的對Hadoop代碼的掌控，我們要保證設計出來的結果，對于Hadoop原生邏輯的影響范圍是可控的；第二個是能快速開發，優先頂住節點資源分布不夠的問題；第三個整個遷移過程是業務全透明的，只要在他數據讀取之前把塊分布到我希望任務所調動的機房就可以了。

    3.2 任務托管和交互式開發

    任務托管和交互式開發背景：

    我們原來的方式是給業務線去布一些開源原生Hadoop和Spark的Client的。

    在本機要編寫代碼和編譯，拷到線上的執行節點，因為要有線上的認證。

    并且要部署一個新的執行節點的時候，要給我們提申請，分配虛擬機，key和client，這個管理成本非常高。

    而且同一個團隊共享一個虛擬機開發總會遇到一個問題，某個虛擬機會被內存任務占滿，要解決這個問題。

    而且由于在Spark發展的過程中，我們會持續地給業務提供Spark技術支持這樣一個服務。如果大家寫代碼運行失敗了，他們沒有那么強的debug能力，當我們上手幫他們debug的時候，首先編譯環境、執行環境，編譯代碼內容我們都沒法第一時間獲取，這個溝通成本是非常高的。同時在推Spark的時候，我們發現它的開發效率非常高，學習嘗試的成本也是非常高的。那怎么辦呢？

    任務托管和交互式開發架構決策：

    為了解決學習成本高的問題，我們做了兩個事。

    一個是任務托管平臺，將任務的代碼編譯打包、執行、測試還有最終上線跑，都統一在一個平臺進行管理。

    另一個是我們推動了交互式開發工具，當時調研了ipthon notebook + spark和zeppelin，最后選擇了zeppelin，覺得比較成熟。基于后者開發，修復了一系列bug，補充登陸認證。效果是任務托管平臺，本機編寫代碼，提交代碼到公司公有的地址上。在這個平臺界面，平臺界面進來都不是必須的了，還進行了本機的任務行，提交一個任務，開始在平臺上統一測試，統一執行，最后還可以基于這個配置到我們剛剛說到的自研調度系統。

    交互式開發目前可能都需要二次開發才能做起來，但是值得嘗試。業務線用它的話主要是兩個場景，第一個場景是要分析、調研一些數據。原來我們提供adhoc的Sql的查詢接口其實并不一定能滿足他的需求，他要查查接口有一些sql查詢復雜數據，如果想用spark每次用spark都要編譯或者用Spark管理起來非常不直觀。

    另外有一些先行Spark嘗試者寫了一些Spark的應用，這些應用如何讓其他同學也能看到，也能對他進行學習和理解，并且能支持他自己構建自己的應用場景呢？也可以通過這么一個平臺化的代碼、結果，對應展示的平臺來解決他們交互的問題。

    3.3 OLAP引擎

    OLAP引擎的需求特點：

    最后聊一下在OLAP引擎部分的探索，大概2015年末的時候，我們開始關注到業務的數據集市，數據量已經非常大了，而且包括維度，表的大小、復雜度都增長的非常快。這些業務也比較崩潰，MySQL和HBase都會做一些特殊的方法來支持。我們調研了一下需求，普遍說是要支持億級別的事實，指標的話每個cube數據 立方體要有50個以內，要支持取值范圍在千萬級別維度20個以內類別；

    查詢請求，因為數據集市一般都是提供給銷售管理團隊去看業績，對延遲要求比較高，對我們當時TP99，前99%查詢要小于3秒鐘。

    有多種維度組合聚合查詢，因為要上轉下轉對業務進行分析。

    還有一個特點，就是對去重的指標要求比較精確，因為有些涉及到業績的指標比如團購單，去重訪問用戶數如果有偏差會影響到業績的預算。

    OLAP引擎可能的方案：

    當時考慮到了業界可能的方案，

    一個是原來推薦的使用方法，就是Presto、hive、Spark on ORCFile，這是最早的方案。

    另外有先行的業務方案，基于hive grouping set的功能，把grouping set按不同維度組合去做聚合，然后形成一個大表，導到HBase里，HBase按需做二級索引的方案，這其實還是有一些瓶頸的。

    還有社區里興起的Druid、Elasticsearch還有Kylin這些項目，我們面臨這樣的場景思路是這樣的。首先直觀的看，考慮穩定性、成熟度，以及團隊對這個產品可能的掌控程度，還有社區的活躍度，我們優先嘗試Kylin。我們團隊有兩個Kylin contributors。

    OLAP引擎探索思路：

    由于前面有這樣多的解決方案，我們怎么保證我們選的解決方案是靠譜的呢？我們基于dpch構建了一個Star Schema Benchmark構造了OLAP場景和測試數據；我們用這一套數據結構和數據內容對不同的引擎進行測試，看它的表現和功能性，滿足的情況。并且推動的過程中持續的分享我們調研和壓縮的進展，優先收集他們實際業務場景需求之后，再回過頭來改進數據集市的需求，更適合業務線需求，下圖就是Kylin的界面。

    具體它提供一個界面聲明你的維度、事實，有哪些指標，這些指標會被怎樣聚合，會生成Mapreduce任務，出來的結果會按照設計進行壓縮，導到HBase里面。他還提供一個SQL引擎，會轉成HBase上查詢，把結果撈出來，總體來講還是蠻成熟的。

    這是StarSchemaBenchmark，一張大的事實表，有很多維度掛在上面，我們做了很多不同數據量級的參照，也參照了現實的數據。

    OLAP引擎目前進展：

    目前進展的話，我們完成了Presto、Kylin1.3、Kylin1.5，Druid測試。這個確實比Kylin好一些，但是有特殊場景，天生不支持SQL接口，所以不會重度使用。

    我們拿Kylin支持了某個BI項目7個數據立方體，數據立方體基本上是一個事實，帶一系列維度，是某一個場景下的分析。

    業務開發周期做一系列的聚合表，梳理聚合成績，維護這些聚合成績7天縮短到一天。

    線上實際跑的數據有3億行數據，TP95%查詢響應時間在1S內，TP99是3秒內；支撐外賣團隊日查詢量2萬。由于這是外賣的銷售團隊去看，他們量非常大。

    4.平臺化思路總結

    4.1平臺的價值：

    最后聊一下做了這么多年數據平臺，對于數據平臺的思考。我覺得平臺不管是不是數據平臺，作為一個平臺的團隊，核心價值其實就是這三個。

    第一個是對重復的事情，這一個平臺團隊做精做專，而且重復的事情只做一次，減少投入。

    另外統一化，可以推一些標準，推一些數據管理的模式，減少業務之間的對接成本，這是平臺的一大價值。

    最重要的是為業務整體效率負責，包括開發效率、迭代效率、維護運維數據流程的效率，還有整個資源利用的效率，這都是要讓業務團隊對業務團隊負責的。無論我們推什么事情，第一時間其實站在業務的角度要考慮他們的業務成本。

    4.2平臺的發展：

    如果才能發展成一個好的平臺呢？

    我理解是這三點：

    首先支持業務是第一位的，如果沒有業務我們平臺其實是沒法繼續發展的。

    第二是與先進業務同行，輔助并沉淀技術。在一個所謂平臺化的公司，有多個業務線，甚至各個業務線已經是獨立的情況下，必定有一些業務線是先行者，他們有很強的開發能力、調研能力，我們的目標是跟這些先行業務線同行。我們跟他們一起走的過程中，一方面是輔助他們，能解決一系列的問題。比如說他們有突發的業務需求，遇到問題我們來幫助解決。

    第三是設立規范，用積累的技術支撐后發業務。就是跟他們一起前進的過程中，把一些經驗、技術、方案、規范慢慢沉淀下來。對于剛剛新建的業務線，或者發展比較慢的業務線，我們基本策略是設置一系列的規范，跟優先先行業務線積累去支撐后續的業務線，以及功能開發的時候也可以借助。保持平臺團隊對業務的理解。

    4.3關于開源：

    最后聊一下開源，剛剛也提到了我們同時對開源有一些自己需求的改進和重構，但是同時又一些產品是我們直接開源的來用的，比如說，zeppelin，Kylin。

    我們的策略是持續關注，其實也是幫業務線做前瞻性調研，他們團隊每天都在看數據，看新聞，他們會講新出的一個項目你們怎么推，你們不推我們推了，我們可能需要持續關注，設計一系列的調研方案，幫助這些業務去調研，這樣調研這個事情我們也是重復的事情只干一次。

    如果有一些共性patch的事情，特別一些bug、問題內部也會有一個表共享，內部有大幾十個patch。選擇性的重構，最后才會大改，特別在選擇的時候我們起來強調從業務需求出發，理智的進行選型權衡，最終拿出來的方案是靠譜能落地實施的方案，我的分享就到這里，謝謝大家。