美團數(shù)據(jù)倉庫，在過去的兩年中，與我們的業(yè)務(wù)一起高速發(fā)展。在這一演進過程中，有很多值得總結(jié)和沉淀的內(nèi)容。這篇文檔回顧下美團數(shù)據(jù)倉庫這兩年發(fā)展過程中遇到的各種問題，為什么選擇了現(xiàn)在的技術(shù)方案，每一個功能和模塊是在什么情況下產(chǎn)生的，解決的是什么問題，中間有過哪些彎路。既可以作為大家熟悉美團數(shù)據(jù)倉庫構(gòu)建過程的一篇文檔，也可以作為初次建立數(shù)據(jù)倉庫的參考。

史前時代

在正式建設(shè)美團數(shù)據(jù)倉庫之前，數(shù)據(jù)組也為各部門提供數(shù)據(jù)支持，不過那個時候的數(shù)據(jù)需求還比較少，而且也相對簡單。

通常的做法是：

• 工程師寫一段PHP或者Shell腳本，從命令行輸入?yún)?shù)。
• 自己連接數(shù)據(jù)庫，通常是一個業(yè)務(wù)數(shù)據(jù)庫的從庫，將需要的原始數(shù)據(jù)提取出來。
• 在內(nèi)存中計算數(shù)據(jù)。
• 然后將結(jié)果寫入一個專門存放統(tǒng)計結(jié)果的DB。
• 再寫一個PHP頁面作為報表提供給需求方。

這是簡單明了的流程，但是隨著需求的增加和精細化，有一些問題變得很棘手，并嚴重影響的開發(fā)效率：

• 有很多重復(fù)勞動和代碼，比如連接數(shù)據(jù)庫的代碼，每個人都要寫，各種寫法不同，分布在很多地方，如果哪個DB的連接方法變更了，需要更改很多地方。
• 中間數(shù)據(jù)缺失，中間計算結(jié)果不能共享。比如每個Deal每天的銷量，不同的人寫報表，每人都可能要重算一次。
• 很難管理和維護，程序語言五花八門，同一指標可以寫多種統(tǒng)計方法，各種語言各種執(zhí)行方式，缺少文檔，其他人很難接手維護。
• 數(shù)據(jù)的清洗和轉(zhuǎn)換沒有統(tǒng)一方法，比如，哪天是每月第一天或每周第幾天這種需求，靠手工調(diào)用各種時間函數(shù)來計算，非常容易出錯。
• 不同數(shù)據(jù)源的數(shù)據(jù)很難綜合使用， 比如一個數(shù) 據(jù)需要使用主站的數(shù)據(jù)和合同系統(tǒng)的數(shù)據(jù)， 要把這些數(shù)據(jù)組織在一起就很麻煩
• 為了解決這些問題，在2011年Q2初，數(shù)據(jù)組開始搭建美團的數(shù)據(jù)倉庫。

引入ETL

數(shù)據(jù)倉庫的學(xué)術(shù)定義有很多版本和特點，其中有幾個詞能概括這一段工作的特點，規(guī)范和集成。

首先需要建立一個DB用于保存從各個數(shù)據(jù)源提取出來的數(shù)據(jù)。

• 第一，解決不同數(shù)據(jù)源的數(shù)據(jù)聯(lián)合使用的問題。
• 第二，因為是獨立的DB，可以進行復(fù)雜的計算而不用考慮會影響線上個系統(tǒng)的DB。
• 第三，可以保留大量需要重復(fù)使用的中間數(shù)據(jù)。
• 第四，數(shù)據(jù)在首次進入數(shù)據(jù)倉庫時，就可以進行清洗整理，去掉無效數(shù)據(jù)和臟數(shù)據(jù)，添加常用字段比如 datekey。

這一時間的一個重要工作是，引入了一個工具——ETL。ETL是Extract（抽取），Transform（轉(zhuǎn)換），Load（載入）的首字母組合。顧名思義，ETL工具的功能就是抽取數(shù)據(jù)，經(jīng)過加工后，再載入到新的位置。

ETL的優(yōu)點是：

• 封裝了到各個數(shù)據(jù)庫的連接，使得工程師只需要關(guān)注數(shù)據(jù)的抽取和轉(zhuǎn)換邏輯，而不必處理各種數(shù)據(jù)庫的連接細節(jié)。
• 將數(shù)據(jù)抽取和轉(zhuǎn)換統(tǒng)一使用SQL來表示，形式化的統(tǒng)一使得理解處理過程變的簡單，便于不同的人協(xié)作開發(fā)，同時，用SQL表示邏輯將各種復(fù)雜的統(tǒng)計交給關(guān)系數(shù)據(jù)庫來處理，也降低了出錯的可能性。數(shù)據(jù)抽取的過程中同時完成各種清洗和轉(zhuǎn)換，替換空值，規(guī)范時間表示等。

這一時間也同時確定了很多規(guī)范:

用數(shù)據(jù)表示邏輯，典型例子是，不再使用各種時間函數(shù)來計算時間，而是建立一個日期表，把某一天的各種信息屬性全部算出來存在一張表里，需要的時候只要連表就可以得到。大大降低了時間邏輯出錯的可能性并簡化了開發(fā)。

將數(shù)據(jù)分為維度數(shù)據(jù)，事實數(shù)據(jù)，衍生數(shù)據(jù)，聚合數(shù)據(jù)等類型， 以及第一版的命名規(guī)范。 為后續(xù)數(shù)據(jù)的組織和管理奠定了基礎(chǔ)。

數(shù)據(jù)倉庫的基礎(chǔ)數(shù)據(jù)建設(shè)，一直是數(shù)據(jù)組的一個主要工作，直到2011年Q4，隨著各種數(shù)據(jù)需求的增加，在如何使用數(shù)據(jù)上，有了一些新想法。

嘗試OLAP

要做數(shù)據(jù)倉庫，而不是數(shù)據(jù)墳?zāi)?#xff0c;數(shù)據(jù)如果不被使用，就毫無用處。怎么能供各部門更好的使用這些數(shù)據(jù)呢？我們要做平臺，可供人去探索數(shù)據(jù)的平臺。

2011年下半年，隨著美團業(yè)務(wù)的高速發(fā)展，用數(shù)據(jù)支撐運營變得越來越重要，各種數(shù)據(jù)需求出現(xiàn)了一個井噴期，開發(fā)人手比較少，一時間有些捉襟見肘。

有沒有方法能讓需求方自助的獲取數(shù)據(jù)，而不依賴RD呢，想到了一個非常流行的概念是OLAP——聯(lián)機分析處理（相對于OLTP——聯(lián)機事務(wù)處理），目標是做成一個自助探索工具的平臺。

從2011年Q4開始到2012Q1，數(shù)據(jù)組開始調(diào)研試用開源的OLAP工具套件。耗時較長，從調(diào)研和最后試用的情況看，現(xiàn)有的OLAP系統(tǒng)不適合我們。

有幾個主要的問題：

• 開發(fā)和使用太復(fù)雜，成本太高。
• 產(chǎn)品成熟度較低，很多數(shù)據(jù)需求沒法支持。
• 笨重，不太適應(yīng)互聯(lián)網(wǎng)公司快速靈活的節(jié)奏。

因為上述原因，到2012Q1， 放棄了OLAP的嘗試。

同時在這個時間點上，公司對數(shù)據(jù)需求的增長，暴露出了數(shù)據(jù)倉庫的很多問題，可以說是需求走在了技術(shù)的前面，迫使我們集中力量做很多大規(guī)模的升級。

數(shù)據(jù)倉庫是一套完整的環(huán)境

2012Q1時，數(shù)據(jù)倉庫出現(xiàn)了很多新的棘手的問題。

• 首先，有哪些流程在線我們不清楚，什么時間執(zhí)行的，有沒有按時執(zhí)行不清楚。報表出了問題要查流程歷史記錄都很難查。
• 其次，我們已經(jīng)有了幾百個ETL流程，流程之間有執(zhí)行順序的依賴關(guān)系，但是沒有好的工具來管理，靠crontab里設(shè)定執(zhí)行時間間隔。經(jīng)常出現(xiàn)上游還沒有算完，下游就啟動了，會出現(xiàn)臟數(shù)據(jù)。另一方面，并行開發(fā)太多，一個人的修改，不知道會不會影響別人，經(jīng)常出現(xiàn)沖突。
• 第三，每次都用PHP手寫報表，重復(fù)工作太多，開發(fā)上線都非常復(fù)雜。
• 第四，數(shù)據(jù)表和指標很多，命名不規(guī)范，經(jīng)常會遇到兩個相近概念的比較問題，解釋起來非常麻煩，需要遍歷整個計算過程才能梳理清楚。

針對這些問題，分別開發(fā)了相應(yīng)的工具。

• 第一個是流程的注冊，管理，查看的工具，每個流程都有了戶口本和行為記錄。
• 第二，寫工具分析流程之間的依賴關(guān)系，畫出關(guān)系圖。
• 第三，開發(fā)調(diào)度系統(tǒng)，根據(jù)關(guān)系圖調(diào)度ETL流程執(zhí)行。
• 第四，抽象報表工具，屏蔽復(fù)雜的報表頁面開發(fā)，將報表抽象為SQL和配置。
• 第五，建立數(shù)據(jù)字典，解釋每個指標和名詞的意思和計算過程。

通過這幾項主要工作，美團數(shù)據(jù)倉庫發(fā)展到了一個比較成熟的階段。也正是經(jīng)歷了這樣一個過程，我們深刻體會到，數(shù)據(jù)倉庫不僅僅是一個“數(shù)據(jù)存儲的工具”， 數(shù)據(jù)倉庫應(yīng)該是一套完整的軟件環(huán)境，它應(yīng)該包括：數(shù)據(jù)抽取，計算，存儲，查詢，展示，以及管理這些過程的工具。

協(xié)作開放

美團的數(shù)據(jù)需求發(fā)展非常快，這體現(xiàn)在數(shù)據(jù)規(guī)模的增長，數(shù)據(jù)分析人員的增長，數(shù)據(jù)分析復(fù)雜程度的增長。2012年下半年，快速發(fā)展的數(shù)據(jù)需求讓原有的數(shù)據(jù)倉庫架構(gòu)達到了瓶頸。無論是DB的計算和存儲能力，還是開發(fā)人員的精力，都達到了很高的負荷。而且由于開發(fā)流程和提取數(shù)據(jù)的重復(fù)勞動很多，團隊士氣也比較低落。這一時間的迫切工作是，如何能讓需求方自助獲取數(shù)據(jù)并分析，如何能讓數(shù)據(jù)的計算和存儲方便的擴展。

從2012年中開始，重點推進了幾項工作以解決上述問題：

• 第一，建設(shè)主題表，將各種數(shù)據(jù)按照常用的維度展開成寬達幾十列上百列的表，使得查數(shù)據(jù)非常的容易。比如，將一個城市一天的幾百個指標放在一行，以城市id和日期作為主鍵，不用任何連表，使用簡單的語法就能獲取關(guān)于城市的各個角度的數(shù)據(jù)。類似的主題表還有用戶，訂單，Deal等角度。豐富的主題表不但簡化了報表開發(fā)， 也為非技術(shù)人員能夠自助查詢數(shù)據(jù)提供了方便。
• 第二，開發(fā)自助查詢工具，培訓(xùn)使用，讓各個部門的人都能在數(shù)據(jù)倉庫上查自己需求的數(shù)據(jù)，培訓(xùn)大家使用SQL，自助完成需求。
• 第三，建立數(shù)據(jù)集市，按業(yè)務(wù)拆分，將部分數(shù)據(jù)導(dǎo)入到各個不同的DB，供業(yè)務(wù)部門更靈活的數(shù)據(jù)需求。
• 第四，將數(shù)據(jù)的存儲和計算，向Hadoop/Hive 分布式平臺遷移，已達到線性擴展計算和存儲能力的需求。
• 第五，開放數(shù)據(jù)的存儲和計算環(huán)境，讓ETL流程的編寫和部署Web化，讓其它組有能力的RD，可以自己在數(shù)據(jù)倉庫上部署計算流程，計算自己需要的數(shù)據(jù)。

這幾個工作的周期都比較長，現(xiàn)在也在進行中，效果也十分明顯，終于有和需求并肩走在一起，沒有落后的壓迫感了。但還沒有走在需求前面。

未來的挑戰(zhàn)

美團的成長速度非常快，數(shù)據(jù)的規(guī)模和復(fù)雜度還將十倍百倍的增長；業(yè)務(wù)多樣且變化迅速。如何能夠在海量數(shù)據(jù)基礎(chǔ)上進行數(shù)據(jù)的管理、加工、分析以支持快速成長的業(yè)務(wù)，后續(xù)還面臨很多挑戰(zhàn)。

我們期待對數(shù)據(jù)敏感、對管理海量復(fù)雜數(shù)據(jù)、對建設(shè)大型互聯(lián)網(wǎng)電商數(shù)據(jù)倉庫有興趣的朋友們，加入美團數(shù)據(jù)倉庫團隊！歡迎投遞簡歷到 diaoshihan(#)meituan.com

總結(jié)

以上是生活随笔為你收集整理的美团数据仓库的演进的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。