謝語(yǔ)宸是來(lái)自美團(tuán)的大數(shù)據(jù)構(gòu)建平臺(tái)的架構(gòu)師。他在QCon2016北京站分享了一些整體上構(gòu)建大數(shù)據(jù)平臺(tái)的方法，除了聚焦在某一個(gè)點(diǎn)上的還有構(gòu)建整體的大數(shù)據(jù)，以及各種各樣技術(shù)的應(yīng)用，希望能給大家一些關(guān)于大數(shù)據(jù)方面的啟迪。
非常感謝給我這個(gè)機(jī)會(huì)給大家?guī)?lái)這個(gè)演講，我是2011年加入美團(tuán)，最開(kāi)始負(fù)責(zé)統(tǒng)計(jì)報(bào)表還有數(shù)據(jù)倉(cāng)庫(kù)的建設(shè)。2012年推動(dòng)了數(shù)據(jù)倉(cāng)庫(kù)分布式化，把分布式計(jì)算放到了Hadoop上，之后把數(shù)據(jù)開(kāi)發(fā)流程放到了線上，2014年帶離線平臺(tái)團(tuán)隊(duì)。
我今天給大家介紹的內(nèi)容主要包括以下四個(gè)部分首先是介紹一下美團(tuán)大數(shù)據(jù)平臺(tái)的架構(gòu)，然后回顧一下歷史，看整個(gè)平臺(tái)演進(jìn)的時(shí)間演進(jìn)線，每一步是怎么做的，以及一些挑戰(zhàn)和應(yīng)對(duì)策略，最后總結(jié)一下，聊一聊我對(duì)平臺(tái)化的看法。
1.美團(tuán)大數(shù)據(jù)平臺(tái)的架構(gòu)
1.1總體架構(gòu)：
上圖是美團(tuán)網(wǎng)數(shù)據(jù)體系組織架構(gòu)圖，上面每一個(gè)豎線都是數(shù)據(jù)開(kāi)發(fā)業(yè)務(wù)線，下面是我所在的基礎(chǔ)數(shù)據(jù)庫(kù)團(tuán)隊(duì)， 最下面我們依賴美團(tuán)云提供的一些虛擬機(jī)、物理機(jī)、機(jī)房等基礎(chǔ)設(shè)施，同時(shí)我們也協(xié)助美團(tuán)云做了大數(shù)據(jù)云服務(wù)的產(chǎn)品探索。
1.2數(shù)據(jù)流架構(gòu)：
下面我以數(shù)據(jù)流的架構(gòu)角度介紹一下整個(gè)美團(tuán)數(shù)據(jù)平臺(tái)的架構(gòu)，這是最恢復(fù)的架構(gòu)圖，最左邊首先從業(yè)務(wù)流到平臺(tái)，分別到實(shí)時(shí)計(jì)算，離線數(shù)據(jù)。
最下面支撐這一系列的有一個(gè)數(shù)據(jù)開(kāi)發(fā)的平臺(tái)，這張圖比較細(xì)，這是我們?cè)敿?xì)的整體數(shù)據(jù)流架構(gòu)圖。包括最左邊是數(shù)據(jù)接入，上面是流式計(jì)算，然后是Hadoop離線計(jì)算。
將上圖左上角擴(kuò)大來(lái)看，首先是數(shù)據(jù)接入與流式計(jì)算，電商系統(tǒng)產(chǎn)生數(shù)據(jù)分兩個(gè)場(chǎng)景，一個(gè)是追加型的日志型數(shù)據(jù)，另外是關(guān)系型數(shù)據(jù)的維度數(shù)據(jù)。我們對(duì)于前一種是使用Flume比較標(biāo)準(zhǔn)化的，大家都在用的日志收集系統(tǒng)。最近使用了阿里開(kāi)源的Canal，之后有三個(gè)下游。所有的流式數(shù)據(jù)都是走Kafka這套流走的。
數(shù)據(jù)收集特性：
對(duì)于數(shù)據(jù)收集平臺(tái)，日志數(shù)據(jù)是多接口的，可以打到文件里觀察文件，也可以更新數(shù)據(jù)庫(kù)表。關(guān)系型數(shù)據(jù)庫(kù)是基于Binlog獲取增量的，如果做數(shù)據(jù)倉(cāng)庫(kù)的話有大量的關(guān)系型數(shù)據(jù)庫(kù)，有一些變更沒(méi)法發(fā)現(xiàn)等等的情況，通過(guò)Binlog手段可以解決。通過(guò)一個(gè)Kafka消息隊(duì)列集中化分發(fā)支持下游，目前支持了850以上的日志類型，峰值每秒有百萬(wàn)介入。
流式計(jì)算平臺(tái)特性：
構(gòu)建流式計(jì)算平臺(tái)的時(shí)候充分考慮了開(kāi)發(fā)的復(fù)雜度，基于Storm。有一個(gè)在線的開(kāi)發(fā)平臺(tái)，測(cè)試開(kāi)發(fā)過(guò)程都在在線平臺(tái)上做，提供一個(gè)相當(dāng)于對(duì)Storm應(yīng)用場(chǎng)景的封裝，有一個(gè)拓?fù)溟_(kāi)發(fā)框架，因?yàn)槭橇魇接?jì)算，我們也做了延遲統(tǒng)計(jì)和報(bào)警，現(xiàn)在支持了1100以上的實(shí)時(shí)拓?fù)�，秒�?jí)實(shí)時(shí)數(shù)據(jù)流延遲。
這上面可以配置公司內(nèi)部定的某個(gè)參數(shù)，某個(gè)代碼，可以在平臺(tái)上編譯有調(diào)試。實(shí)時(shí)計(jì)算和數(shù)據(jù)接入部分就介紹到這兒，下面介紹一下離線計(jì)算。
離線計(jì)算：我們是基于Hadoop的數(shù)據(jù)倉(cāng)庫(kù)數(shù)據(jù)應(yīng)用，主要是展示了對(duì)數(shù)據(jù)倉(cāng)庫(kù)分成的規(guī)劃，包括原始數(shù)據(jù)接入，到核心數(shù)據(jù)倉(cāng)庫(kù)的基礎(chǔ)層，包括事實(shí)和衍生事實(shí)，維度表橫跨了聚合的結(jié)果，最右邊提供了數(shù)據(jù)應(yīng)用：一些挖掘和使用場(chǎng)景，上面是各個(gè)業(yè)務(wù)線自建的需求報(bào)表和分析庫(kù)。
這幅圖是離線數(shù)據(jù)平臺(tái)的部署架構(gòu)圖，最下面是三個(gè)基礎(chǔ)服務(wù)，包括Yarn、HDFS、HiveMeta。不同的計(jì)算場(chǎng)景提供不同的計(jì)算引擎支持。如果是新建的公司，其實(shí)這里是有一些架構(gòu)選型的。Cloud Table是自己做的HBase分裝封口。我們使用Hive構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)，用Spark在數(shù)據(jù)挖掘和機(jī)器學(xué)習(xí)，Presto支持Adhoc上查詢，也可能寫(xiě)一些復(fù)雜的SQL。對(duì)應(yīng)關(guān)系這里Presto沒(méi)有部署到Y(jié)arn，跟Yarn是同步的，Spark 是 on Yarn跑。目前Hive還是依賴Mapreduce的，目前嘗試著Hive on tez的測(cè)試和部署上線。
離線計(jì)算平臺(tái)特性：
目前42P+總存儲(chǔ)量，每天有15萬(wàn)個(gè)Mapreduce和Spark任務(wù)，有2500萬(wàn)節(jié)點(diǎn)，支持3機(jī)房部署，后面跨機(jī)房一會(huì)兒會(huì)介紹，數(shù)據(jù)庫(kù)總共16K個(gè)數(shù)據(jù)表，復(fù)雜度還是蠻高的。
1.3數(shù)據(jù)管理體系：
數(shù)據(jù)管理體系特性：
下面簡(jiǎn)單聊一下數(shù)據(jù)管理體系，這相當(dāng)于主要面向數(shù)據(jù)開(kāi)發(fā)者的操作經(jīng)驗(yàn)，主要包括自研的調(diào)配系統(tǒng)，然后數(shù)據(jù)質(zhì)量的監(jiān)控，資源管理和任務(wù)審核一條開(kāi)發(fā)配置中心等等，都是在數(shù)據(jù)管理體系的，下面會(huì)整合到整個(gè)的數(shù)據(jù)開(kāi)放平臺(tái)。
數(shù)據(jù)管理體系我們這邊主要實(shí)現(xiàn)了幾點(diǎn)，
第一點(diǎn)我們是基于SQL解析去做了ETL任務(wù)之間的自動(dòng)解析。
基于資源預(yù)留的模式做了各業(yè)務(wù)線成本的核算，整體的資源大體是跑到Y(jié)arn上的，每個(gè)業(yè)務(wù)線會(huì)有一些承諾資源、保證資源，還可以彈性伸縮，里面會(huì)有一些預(yù)算。
我們工作的重點(diǎn)，對(duì)于關(guān)鍵性任務(wù)會(huì)注冊(cè)SLA保障，并且包括數(shù)據(jù)內(nèi)容質(zhì)量，數(shù)據(jù)時(shí)效性內(nèi)容都有一定的監(jiān)控。
這是解析出來(lái)的依賴關(guān)系，紅色的是展示的一條任務(wù)，有一系列的上游。這是我們的資源管理系統(tǒng)，可以分析細(xì)到每個(gè)任務(wù)每時(shí)每刻的資源使用，可以聚合，給每個(gè)業(yè)務(wù)線做成本核算。
這是對(duì)于數(shù)據(jù)質(zhì)量管理中心，圖比較小，上面可以寫(xiě)一些簡(jiǎn)單的SQL，監(jiān)控某一個(gè)表的數(shù)據(jù)結(jié)果是否符合我們業(yè)務(wù)的預(yù)期。下面是數(shù)據(jù)管理，就是我們剛剛提到的，對(duì)每個(gè)關(guān)鍵的數(shù)據(jù)表都有一些SLA的跟蹤保障，會(huì)定期發(fā)日?qǐng)?bào)，觀察他們完成時(shí)間的一些變動(dòng)。
1.4BI產(chǎn)品：
上面是BI產(chǎn)品，數(shù)據(jù)應(yīng)用平臺(tái)化的場(chǎng)景。我們的查詢主要是有一個(gè)查詢中心來(lái)支持，包括Hive，MySQL，Presto，Kylin等等的引擎，在查詢中心里面我們做SQL解析。前面是一系列的BI產(chǎn)品，大部分是自研的，面向用戶可以直接寫(xiě)SQL的自主查詢，并且看某一個(gè)指標(biāo)，某一個(gè)時(shí)間段類似于online的分析數(shù)據(jù)產(chǎn)品，以及給老大們看的天機(jī)系統(tǒng)。
還有指標(biāo)提取工具，其實(shí)跟商用oneline前端分析引擎設(shè)計(jì)是比較類似的，選取維度范圍，還有適時(shí)的計(jì)算口徑，會(huì)有一系列對(duì)維度適時(shí)的管理。數(shù)據(jù)內(nèi)容數(shù)據(jù)表不夠，還會(huì)配一些dashboard。
我們開(kāi)發(fā)了星空展示中心，可以基于前面指標(biāo)提取結(jié)果，配置一系列的餅圖、線圖、柱狀圖，去拖拽，最后build出來(lái)一個(gè)dashboard。
2.平臺(tái)演進(jìn)時(shí)間線
2.1 平臺(tái)發(fā)展
下面聊一下整個(gè)數(shù)據(jù)平臺(tái)發(fā)展的時(shí)間線。因?yàn)槲沂?011年加入美團(tuán)的，美團(tuán)剛剛建立一年左右。最開(kāi)始2011年的時(shí)候，我們主要的數(shù)據(jù)統(tǒng)計(jì)都是基于手寫(xiě)的報(bào)表，就是來(lái)一個(gè)需求我們基于線上數(shù)據(jù)建立一個(gè)報(bào)表頁(yè)面，寫(xiě)一些表格。這里帶來(lái)的嚴(yán)重的問(wèn)題，首先是內(nèi)部信息系統(tǒng)的工作狀態(tài)，并不是一個(gè)垂直的，專門(mén)用做數(shù)據(jù)分析的平臺(tái)。這個(gè)系統(tǒng)當(dāng)時(shí)還是跟業(yè)務(wù)去共享的，跟業(yè)務(wù)的隔離非常弱，跟業(yè)務(wù)是強(qiáng)耦合的，而且每次來(lái)數(shù)據(jù)需求的時(shí)候我們都要有一些特殊的開(kāi)發(fā)，開(kāi)發(fā)周期非常長(zhǎng)。
我們面對(duì)這個(gè)場(chǎng)景怎么辦呢？我們做了一個(gè)目前來(lái)看還算比較好的決策，就是重度依賴SQL。我們對(duì)SQL分裝了一些報(bào)表工具，對(duì)SQL做了etl工具。主要是在SQL層面做一些模板化的工具，支持時(shí)間等變量。這個(gè)變量會(huì)有一些外部的參數(shù)傳遞進(jìn)來(lái)，然后替換到SQL的行為。
我們?cè)?011下半年引入了整個(gè)數(shù)據(jù)倉(cāng)庫(kù)的概念，梳理了所有數(shù)據(jù)流，設(shè)計(jì)整個(gè)數(shù)據(jù)體系。做完了數(shù)據(jù)倉(cāng)庫(kù)整體的構(gòu)建，我們發(fā)現(xiàn)有整體的ETL被開(kāi)發(fā)出來(lái)了。首先ETL都是有一定的依賴關(guān)系的，但是管理起來(lái)成本非常高。所以我們自研了一個(gè)系統(tǒng)，另外我們發(fā)現(xiàn)數(shù)據(jù)量越來(lái)越大，原來(lái)基于單機(jī)MySQL的數(shù)據(jù)解析是搞不定的，所以2012年我們上了四臺(tái)Hadoop機(jī)器，后面十幾臺(tái)，到最后的幾千臺(tái)，目前可以支撐各個(gè)業(yè)務(wù)去使用。
2.2 最新進(jìn)展
我們也做了一個(gè)非常重要的事就是ETL開(kāi)發(fā)平臺(tái)，原來(lái)都是基于Git倉(cāng)庫(kù)管理，管理成本非常高，當(dāng)時(shí)跟個(gè)業(yè)務(wù)線已經(jīng)開(kāi)始建立自己數(shù)據(jù)開(kāi)發(fā)的團(tuán)隊(duì)了。我們把他們開(kāi)發(fā)的整個(gè)流程平臺(tái)化，各個(gè)業(yè)務(wù)線就可以自建。之后我們遇到的業(yè)務(wù)場(chǎng)景需求越來(lái)越多，特別是實(shí)時(shí)應(yīng)用。2014年啟動(dòng)了實(shí)時(shí)計(jì)算平臺(tái)，把原來(lái)原有關(guān)系型數(shù)據(jù)表全量同步模式，改為Binlog同步模式。我們也是在國(guó)內(nèi)比較早的上了Hadoop2.0 on Yarn的改進(jìn)版，好處是更好的激起了Spark的發(fā)展。另外還有Hadoop集群跨多機(jī)房，多集群部署的情況，還有OLAP保障，同步開(kāi)發(fā)工具。
3.近期挑戰(zhàn)和應(yīng)對(duì)
3.1Hadoop多機(jī)房
Hadoop多機(jī)房背景：
下面重點(diǎn)講三個(gè)挑戰(zhàn)還有應(yīng)對(duì)策略，首先是Hadoop多機(jī)房。Hadoop為什么要多機(jī)房部署呢？之前只有淘寶這樣做。2015年初我們被告知總機(jī)房架位只有500個(gè)節(jié)點(diǎn)，我們遷到的機(jī)房，主要還是機(jī)房合同發(fā)生了一些違約。我們溝通到新的離線機(jī)房需要在9月份交付，2015年6月份我們需要1000個(gè)計(jì)算節(jié)點(diǎn)，12月份的時(shí)候需要1500個(gè)計(jì)算節(jié)點(diǎn)，這肯定是不夠的。那就要進(jìn)行梳理，業(yè)務(wù)緊耦合，快速拆分沒(méi)法支撐快速增長(zhǎng)，而且數(shù)據(jù)倉(cāng)庫(kù)拆分會(huì)帶來(lái)數(shù)據(jù)拷貝，數(shù)據(jù)傳輸成本的，這時(shí)候只能讓Hadoop多機(jī)房進(jìn)行部署。
我們思考了一下，為什么Hadoop不能多機(jī)房部署呢？
其實(shí)就兩個(gè)問(wèn)題。
一個(gè)是跨機(jī)房帶寬非常小，而且跨機(jī)房帶寬比較高，幾十G，可能給力的能上百G，但是機(jī)房核心交換節(jié)點(diǎn)是超過(guò)這些的。而且Hadoop是天生的分布式系統(tǒng)，他一旦跨節(jié)點(diǎn)就一定會(huì)有跨機(jī)房的問(wèn)題。
我們梳理了Hadoop運(yùn)行過(guò)程中，跨節(jié)點(diǎn)的數(shù)據(jù)流程，基本上是三種。
首先是APP內(nèi)部，就是任務(wù)內(nèi)部的一些Container通信的網(wǎng)絡(luò)交換，比較明確的場(chǎng)景就是Map和educe之間。
第二個(gè)是非DataNode本地讀取，如果跨機(jī)房部署讀數(shù)據(jù)就是跨機(jī)房的，帶寬量非常大。
第三個(gè)寫(xiě)入數(shù)據(jù)的時(shí)候要構(gòu)建一個(gè)三節(jié)點(diǎn)的pipeline，可能是跨機(jī)房的，就要帶來(lái)很多數(shù)據(jù)流量。
Hadoop多機(jī)房架構(gòu)決策：
我們當(dāng)時(shí)考慮到壓力，先做多機(jī)房的方案再做NameSpace，這跟淘寶方案有所差別。我們每個(gè)節(jié)點(diǎn)都有一個(gè)所屬的機(jī)房屬性，把這個(gè)東西維護(hù)起來(lái)，基本上也是基于網(wǎng)絡(luò)段判斷的。對(duì)于剛剛提到的第一個(gè)問(wèn)題，我們的方案在Yarn隊(duì)列上打一個(gè)機(jī)房的tag，每個(gè)隊(duì)列里面的任務(wù)只會(huì)在某一個(gè)機(jī)房里跑起來(lái)，這里要修改一下Yarn fairscheduler的代碼的。
第二個(gè)是基于HDFS修改了addBlock策略，只返回client所在機(jī)房的DataNode列表，這樣寫(xiě)入的時(shí)候pipeline就不會(huì)有跨機(jī)房，讀取也會(huì)優(yōu)先選取clinet所在的機(jī)房。還有其他的場(chǎng)景會(huì)跨機(jī)房，比如說(shuō)Balancer也是節(jié)點(diǎn)之間做數(shù)據(jù)遷移的。最終我們還做了一件事，就是Balancer是直接DataNode溝通，有通道的，我們是直接構(gòu)造了Block文件分布工具。
Hadoop多機(jī)房結(jié)構(gòu)效果：
效果上看，左邊是2015年3月份節(jié)點(diǎn)數(shù)，300多，2016年3月份是2400多，中間不同的段是每個(gè)機(jī)房當(dāng)時(shí)承載的節(jié)點(diǎn)數(shù)。這時(shí)候我們只有一個(gè)機(jī)房了，因?yàn)槲覀冋麄�(gè)跨機(jī)房，多機(jī)房的方案是為了配合一個(gè)臨時(shí)的狀態(tài)，所以它方案前面通過(guò)Balancer模塊的接口，把所有數(shù)據(jù)最終都搬遷到了大的離線計(jì)算機(jī)房。
Hadoop多機(jī)房架構(gòu)特點(diǎn)：
做這個(gè)架構(gòu)的時(shí)候，我們?cè)O(shè)計(jì)的時(shí)候主要考慮第一代碼改動(dòng)要小，因?yàn)楫?dāng)時(shí)我們團(tuán)隊(duì)沒(méi)有那么深的對(duì)Hadoop代碼的掌控，我們要保證設(shè)計(jì)出來(lái)的結(jié)果，對(duì)于Hadoop原生邏輯的影響范圍是可控的；第二個(gè)是能快速開(kāi)發(fā)，優(yōu)先頂住節(jié)點(diǎn)資源分布不夠的問(wèn)題；第三個(gè)整個(gè)遷移過(guò)程是業(yè)務(wù)全透明的，只要在他數(shù)據(jù)讀取之前把塊分布到我希望任務(wù)所調(diào)動(dòng)的機(jī)房就可以了。
3.2 任務(wù)托管和交互式開(kāi)發(fā)
任務(wù)托管和交互式開(kāi)發(fā)背景：
我們?cè)瓉?lái)的方式是給業(yè)務(wù)線去布一些開(kāi)源原生Hadoop和Spark的Client的。
在本機(jī)要編寫(xiě)代碼和編譯，拷到線上的執(zhí)行節(jié)點(diǎn)，因?yàn)橐芯�上的認(rèn)證。
并且要部署一個(gè)新的執(zhí)行節(jié)點(diǎn)的時(shí)候，要給我們提申請(qǐng)，分配虛擬機(jī)，key和client，這個(gè)管理成本非常高。
而且同一個(gè)團(tuán)隊(duì)共享一個(gè)虛擬機(jī)開(kāi)發(fā)總會(huì)遇到一個(gè)問(wèn)題，某個(gè)虛擬機(jī)會(huì)被內(nèi)存任務(wù)占滿，要解決這個(gè)問(wèn)題。
而且由于在Spark發(fā)展的過(guò)程中，我們會(huì)持續(xù)地給業(yè)務(wù)提供Spark技術(shù)支持這樣一個(gè)服務(wù)。如果大家寫(xiě)代碼運(yùn)行失敗了，他們沒(méi)有那么強(qiáng)的debug能力，當(dāng)我們上手幫他們debug的時(shí)候，首先編譯環(huán)境、執(zhí)行環(huán)境，編譯代碼內(nèi)容我們都沒(méi)法第一時(shí)間獲取，這個(gè)溝通成本是非常高的。同時(shí)在推Spark的時(shí)候，我們發(fā)現(xiàn)它的開(kāi)發(fā)效率非常高，學(xué)習(xí)嘗試的成本也是非常高的。那怎么辦呢？
任務(wù)托管和交互式開(kāi)發(fā)架構(gòu)決策：
為了解決學(xué)習(xí)成本高的問(wèn)題，我們做了兩個(gè)事。
一個(gè)是任務(wù)托管平臺(tái)，將任務(wù)的代碼編譯打包、執(zhí)行、測(cè)試還有最終上線跑，都統(tǒng)一在一個(gè)平臺(tái)進(jìn)行管理。
另一個(gè)是我們推動(dòng)了交互式開(kāi)發(fā)工具，當(dāng)時(shí)調(diào)研了ipthon notebook + spark和zeppelin，最后選擇了zeppelin，覺(jué)得比較成熟。基于后者開(kāi)發(fā)，修復(fù)了一系列bug，補(bǔ)充登陸認(rèn)證。效果是任務(wù)托管平臺(tái)，本機(jī)編寫(xiě)代碼，提交代碼到公司公有的地址上。在這個(gè)平臺(tái)界面，平臺(tái)界面進(jìn)來(lái)都不是必須的了，還進(jìn)行了本機(jī)的任務(wù)行，提交一個(gè)任務(wù)，開(kāi)始在平臺(tái)上統(tǒng)一測(cè)試，統(tǒng)一執(zhí)行，最后還可以基于這個(gè)配置到我們剛剛說(shuō)到的自研調(diào)度系統(tǒng)。
交互式開(kāi)發(fā)目前可能都需要二次開(kāi)發(fā)才能做起來(lái)，但是值得嘗試。業(yè)務(wù)線用它的話主要是兩個(gè)場(chǎng)景，第一個(gè)場(chǎng)景是要分析、調(diào)研一些數(shù)據(jù)。原來(lái)我們提供adhoc的Sql的查詢接口其實(shí)并不一定能滿足他的需求，他要查查接口有一些sql查詢復(fù)雜數(shù)據(jù)，如果想用spark每次用spark都要編譯或者用Spark管理起來(lái)非常不直觀。
另外有一些先行Spark嘗試者寫(xiě)了一些Spark的應(yīng)用，這些應(yīng)用如何讓其他同學(xué)也能看到，也能對(duì)他進(jìn)行學(xué)習(xí)和理解，并且能支持他自己構(gòu)建自己的應(yīng)用場(chǎng)景呢？也可以通過(guò)這么一個(gè)平臺(tái)化的代碼、結(jié)果，對(duì)應(yīng)展示的平臺(tái)來(lái)解決他們交互的問(wèn)題。
3.3 OLAP引擎
OLAP引擎的需求特點(diǎn)：
最后聊一下在OLAP引擎部分的探索，大概2015年末的時(shí)候，我們開(kāi)始關(guān)注到業(yè)務(wù)的數(shù)據(jù)集市，數(shù)據(jù)量已經(jīng)非常大了，而且包括維度，表的大小、復(fù)雜度都增長(zhǎng)的非�？臁＿@些業(yè)務(wù)也比較崩潰，MySQL和HBase都會(huì)做一些特殊的方法來(lái)支持。我們調(diào)研了一下需求，普遍說(shuō)是要支持億級(jí)別的事實(shí)，指標(biāo)的話每個(gè)cube數(shù)據(jù) 立方體要有50個(gè)以內(nèi)，要支持取值范圍在千萬(wàn)級(jí)別維度20個(gè)以內(nèi)類別；
查詢請(qǐng)求，因?yàn)閿?shù)據(jù)集市一般都是提供給銷售管理團(tuán)隊(duì)去看業(yè)績(jī)，對(duì)延遲要求比較高，對(duì)我們當(dāng)時(shí)TP99，前99%查詢要小于3秒鐘。
有多種維度組合聚合查詢，因?yàn)橐限D(zhuǎn)下轉(zhuǎn)對(duì)業(yè)務(wù)進(jìn)行分析。
還有一個(gè)特點(diǎn)，就是對(duì)去重的指標(biāo)要求比較精確，因?yàn)橛行┥婕暗綐I(yè)績(jī)的指標(biāo)比如團(tuán)購(gòu)單，去重訪問(wèn)用戶數(shù)如果有偏差會(huì)影響到業(yè)績(jī)的預(yù)算。
OLAP引擎可能的方案：
當(dāng)時(shí)考慮到了業(yè)界可能的方案，
一個(gè)是原來(lái)推薦的使用方法，就是Presto、hive、Spark on ORCFile，這是最早的方案。
另外有先行的業(yè)務(wù)方案，基于hive grouping set的功能，把grouping set按不同維度組合去做聚合，然后形成一個(gè)大表，導(dǎo)到HBase里，HBase按需做二級(jí)索引的方案，這其實(shí)還是有一些瓶頸的。
還有社區(qū)里興起的Druid、Elasticsearch還有Kylin這些項(xiàng)目，我們面臨這樣的場(chǎng)景思路是這樣的。首先直觀的看，考慮穩(wěn)定性、成熟度，以及團(tuán)隊(duì)對(duì)這個(gè)產(chǎn)品可能的掌控程度，還有社區(qū)的活躍度，我們優(yōu)先嘗試Kylin。我們團(tuán)隊(duì)有兩個(gè)Kylin contributors。
OLAP引擎探索思路：
由于前面有這樣多的解決方案，我們?cè)趺幢ＷC我們選的解決方案是靠譜的呢？我們基于dpch構(gòu)建了一個(gè)Star Schema Benchmark構(gòu)造了OLAP場(chǎng)景和測(cè)試數(shù)據(jù)；我們用這一套數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)內(nèi)容對(duì)不同的引擎進(jìn)行測(cè)試，看它的表現(xiàn)和功能性，滿足的情況。并且推動(dòng)的過(guò)程中持續(xù)的分享我們調(diào)研和壓縮的進(jìn)展，優(yōu)先收集他們實(shí)際業(yè)務(wù)場(chǎng)景需求之后，再回過(guò)頭來(lái)改進(jìn)數(shù)據(jù)集市的需求，更適合業(yè)務(wù)線需求，下圖就是Kylin的界面。
具體它提供一個(gè)界面聲明你的維度、事實(shí)，有哪些指標(biāo)，這些指標(biāo)會(huì)被怎樣聚合，會(huì)生成Mapreduce任務(wù)，出來(lái)的結(jié)果會(huì)按照設(shè)計(jì)進(jìn)行壓縮，導(dǎo)到HBase里面。他還提供一個(gè)SQL引擎，會(huì)轉(zhuǎn)成HBase上查詢，把結(jié)果撈出來(lái)，總體來(lái)講還是蠻成熟的。
這是StarSchemaBenchmark，一張大的事實(shí)表，有很多維度掛在上面，我們做了很多不同數(shù)據(jù)量級(jí)的參照，也參照了現(xiàn)實(shí)的數(shù)據(jù)。
OLAP引擎目前進(jìn)展：
目前進(jìn)展的話，我們完成了Presto、Kylin1.3、Kylin1.5，Druid測(cè)試。這個(gè)確實(shí)比Kylin好一些，但是有特殊場(chǎng)景，天生不支持SQL接口，所以不會(huì)重度使用。
我們拿Kylin支持了某個(gè)BI項(xiàng)目7個(gè)數(shù)據(jù)立方體，數(shù)據(jù)立方體基本上是一個(gè)事實(shí)，帶一系列維度，是某一個(gè)場(chǎng)景下的分析。
業(yè)務(wù)開(kāi)發(fā)周期做一系列的聚合表，梳理聚合成績(jī)，維護(hù)這些聚合成績(jī)7天縮短到一天。
線上實(shí)際跑的數(shù)據(jù)有3億行數(shù)據(jù)，TP95%查詢響應(yīng)時(shí)間在1S內(nèi)，TP99是3秒內(nèi)；支撐外賣(mài)團(tuán)隊(duì)日查詢量2萬(wàn)。由于這是外賣(mài)的銷售團(tuán)隊(duì)去看，他們量非常大。
4.平臺(tái)化思路總結(jié)
4.1平臺(tái)的價(jià)值：
最后聊一下做了這么多年數(shù)據(jù)平臺(tái)，對(duì)于數(shù)據(jù)平臺(tái)的思考。我覺(jué)得平臺(tái)不管是不是數(shù)據(jù)平臺(tái)，作為一個(gè)平臺(tái)的團(tuán)隊(duì)，核心價(jià)值其實(shí)就是這三個(gè)。
第一個(gè)是對(duì)重復(fù)的事情，這一個(gè)平臺(tái)團(tuán)隊(duì)做精做專，而且重復(fù)的事情只做一次，減少投入。
另外統(tǒng)一化，可以推一些標(biāo)準(zhǔn)，推一些數(shù)據(jù)管理的模式，減少業(yè)務(wù)之間的對(duì)接成本，這是平臺(tái)的一大價(jià)值。
最重要的是為業(yè)務(wù)整體效率負(fù)責(zé)，包括開(kāi)發(fā)效率、迭代效率、維護(hù)運(yùn)維數(shù)據(jù)流程的效率，還有整個(gè)資源利用的效率，這都是要讓業(yè)務(wù)團(tuán)隊(duì)對(duì)業(yè)務(wù)團(tuán)隊(duì)負(fù)責(zé)的。無(wú)論我們推什么事情，第一時(shí)間其實(shí)站在業(yè)務(wù)的角度要考慮他們的業(yè)務(wù)成本。
4.2平臺(tái)的發(fā)展：
如果才能發(fā)展成一個(gè)好的平臺(tái)呢？
我理解是這三點(diǎn)：
首先支持業(yè)務(wù)是第一位的，如果沒(méi)有業(yè)務(wù)我們平臺(tái)其實(shí)是沒(méi)法繼續(xù)發(fā)展的。
第二是與先進(jìn)業(yè)務(wù)同行，輔助并沉淀技術(shù)。在一個(gè)所謂平臺(tái)化的公司，有多個(gè)業(yè)務(wù)線，甚至各個(gè)業(yè)務(wù)線已經(jīng)是獨(dú)立的情況下，必定有一些業(yè)務(wù)線是先行者，他們有很強(qiáng)的開(kāi)發(fā)能力、調(diào)研能力，我們的目標(biāo)是跟這些先行業(yè)務(wù)線同行。我們跟他們一起走的過(guò)程中，一方面是輔助他們，能解決一系列的問(wèn)題。比如說(shuō)他們有突發(fā)的業(yè)務(wù)需求，遇到問(wèn)題我們來(lái)幫助解決。
第三是設(shè)立規(guī)范，用積累的技術(shù)支撐后發(fā)業(yè)務(wù)。就是跟他們一起前進(jìn)的過(guò)程中，把一些經(jīng)驗(yàn)、技術(shù)、方案、規(guī)范慢慢沉淀下來(lái)。對(duì)于剛剛新建的業(yè)務(wù)線，或者發(fā)展比較慢的業(yè)務(wù)線，我們基本策略是設(shè)置一系列的規(guī)范，跟優(yōu)先先行業(yè)務(wù)線積累去支撐后續(xù)的業(yè)務(wù)線，以及功能開(kāi)發(fā)的時(shí)候也可以借助。保持平臺(tái)團(tuán)隊(duì)對(duì)業(yè)務(wù)的理解。
4.3關(guān)于開(kāi)源：
最后聊一下開(kāi)源，剛剛也提到了我們同時(shí)對(duì)開(kāi)源有一些自己需求的改進(jìn)和重構(gòu)，但是同時(shí)又一些產(chǎn)品是我們直接開(kāi)源的來(lái)用的，比如說(shuō)，zeppelin，Kylin。
我們的策略是持續(xù)關(guān)注，其實(shí)也是幫業(yè)務(wù)線做前瞻性調(diào)研，他們團(tuán)隊(duì)每天都在看數(shù)據(jù)，看新聞，他們會(huì)講新出的一個(gè)項(xiàng)目你們?cè)趺赐�，你們不推我們推了，我們可能需要持續(xù)關(guān)注，設(shè)計(jì)一系列的調(diào)研方案，幫助這些業(yè)務(wù)去調(diào)研，這樣調(diào)研這個(gè)事情我們也是重復(fù)的事情只干一次。
如果有一些共性patch的事情，特別一些bug、問(wèn)題內(nèi)部也會(huì)有一個(gè)表共享，內(nèi)部有大幾十個(gè)patch。選擇性的重構(gòu)，最后才會(huì)大改，特別在選擇的時(shí)候我們起來(lái)強(qiáng)調(diào)從業(yè)務(wù)需求出發(fā)，理智的進(jìn)行選型權(quán)衡，最終拿出來(lái)的方案是靠譜能落地實(shí)施的方案，我的分享就到這里，謝謝大家。
核心關(guān)注：拓步ERP系統(tǒng)平臺(tái)是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請(qǐng)注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標(biāo)題：美團(tuán)大數(shù)據(jù)平臺(tái)架構(gòu)實(shí)踐
相關(guān)文章
