美團大資料平臺
今天給大家介紹的內容主要包括以下四個部分首先是介紹一下美團大資料平臺的架構，然後回顧一下歷史，看整個平臺演進的時間演進線，每一步是怎麼做的，以及一些挑戰和應對策略，最後總結一下，聊一聊我對平臺化的看法。
謝語宸是來自美團的大資料構建平臺的架構師。他在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。選擇性的重構，最後才會大改，特別在選擇的時候我們起來強調從業務需求出發，理智的進行選型權衡，最終拿出來的方案是靠譜能落地實施的方案，我的分享就到這裡，謝謝大家。