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