作為IT從業者，今天看到這邊篇文章，自己的想法還是挺多的，轉載過來保存一下，方便自己后期閱讀吧。

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

史前時代

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

通常的做法是：

工程師寫一段PHP或者Shell腳本，從命令行輸入參數。

自己連接數據庫，通常是一個業務數據庫的從庫，將需要的原始數據提取出來。

在內存中計算數據。

然后將結果寫入一個專門存放統計結果的DB。

再寫一個PHP頁面作為報表提供給需求方。

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

有很多重復勞動和代碼，比如連接數據庫的代碼，每個人都要寫，各種寫法不同，分布在很多地方，如果哪個DB的連接方法變更了，需要更改很多地方。

中間數據缺失，中間計算結果不能共享。比如每個Deal每天的銷量，不同的人寫報表，每人都可能要重算一次。

很難管理和維護，程序語言五花八門，同一指標可以寫多種統計方法，各種語言各種執行方式，缺少文檔，其他人很難接手維護。

數據的清洗和轉換沒有統一方法，比如，哪天是每月第一天或每周第幾天這種需求，靠手工調用各種時間函數來計算，非常容易出錯。

不同數據源的數據很難綜合使用， 比如一個數 據需要使用主站的數據和合同系統的數據， 要把這些數據組織在一起就很麻煩

為了解決這些問題，在2011年Q2初，數據組開始搭建美團的數據倉庫。

引入ETL

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

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

第一，解決不同數據源的數據聯合使用的問題。

第二，因為是獨立的DB，可以進行復雜的計算而不用考慮會影響線上個系統的DB。

第三，可以保留大量需要重復使用的中間數據。

第四，數據在首次進入數據倉庫時，就可以進行清洗整理，去掉無效數據和臟數據，添加常用字段比如 datekey。

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

ETL的優點是：

封裝了到各個數據庫的連接，使得工程師只需要關注數據的抽取和轉換邏輯，而不必處理各種數據庫的連接細節。

將數據抽取和轉換統一使用SQL來表示，形式化的統一使得理解處理過程變的簡單，便于不同的人協作開發，同時，用SQL表示邏輯將各種復雜的統計交給關系數據庫來處理，也降低了出錯的可能性。數據抽取的過程中同時完成各種清洗和轉換，替換空值，規范時間表示等。

這一時間也同時確定了很多規范:

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

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

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

嘗試OLAP

要做數據倉庫，而不是數據墳墓，數據如果不被使用，就毫無用處。怎么能供各部門更好的使用這些數據呢？我們要做平臺，可供人去探索數據的平臺。

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

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

從2011年Q4開始到2012Q1，數據組開始調研試用開源的OLAP工具套件。耗時較長，從調研和最后試用的情況看，現有的OLAP系統不適合我們。

有幾個主要的問題：

開發和使用太復雜，成本太高。

產品成熟度較低，很多數據需求沒法支持。

笨重，不太適應互聯網公司快速靈活的節奏。

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

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

數據倉庫是一套完整的環境

2012Q1時，數據倉庫出現了很多新的棘手的問題。

首先，有哪些流程在線我們不清楚，什么時間執行的，有沒有按時執行不清楚。報表出了問題要查流程歷史記錄都很難查。

其次，我們已經有了幾百個ETL流程，流程之間有執行順序的依賴關系，但是沒有好的工具來管理，靠crontab里設定執行時間間隔。經常出現上游還沒有算完，下游就啟動了，會出現臟數據。另一方面，并行開發太多，一個人的修改，不知道會不會影響別人，經常出現沖突。

第三，每次都用PHP手寫報表，重復工作太多，開發上線都非常復雜。

第四，數據表和指標很多，命名不規范，經常會遇到兩個相近概念的比較問題，解釋起來非常麻煩，需要遍歷整個計算過程才能梳理清楚。

針對這些問題，分別開發了相應的工具。

第一個是流程的注冊，管理，查看的工具，每個流程都有了戶口本和行為記錄。

第二，寫工具分析流程之間的依賴關系，畫出關系圖。

第三，開發調度系統，根據關系圖調度ETL流程執行。

第四，抽象報表工具，屏蔽復雜的報表頁面開發，將報表抽象為SQL和配置。

第五，建立數據字典，解釋每個指標和名詞的意思和計算過程。

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

協作開放

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

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

第一，建設主題表，將各種數據按照常用的維度展開成寬達幾十列上百列的表，使得查數據非常的容易。比如，將一個城市一天的幾百個指標放在一行，以城市id和日期作為主鍵，不用任何連表，使用簡單的語法就能獲取關于城市的各個角度的數據。類似的主題表還有用戶，訂單，Deal等角度。豐富的主題表不但簡化了報表開發， 也為非技術人員能夠自助查詢數據提供了方便。

第二，開發自助查詢工具，培訓使用，讓各個部門的人都能在數據倉庫上查自己需求的數據，培訓大家使用SQL，自助完成需求。

第三，建立數據集市，按業務拆分，將部分數據導入到各個不同的DB，供業務部門更靈活的數據需求。

第四，將數據的存儲和計算，向Hadoop/Hive 分布式平臺遷移，已達到線性擴展計算和存儲能力的需求。

第五，開放數據的存儲和計算環境，讓ETL流程的編寫和部署Web化，讓其它組有能力的RD，可以自己在數據倉庫上部署計算流程，計算自己需要的數據。

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

還有很多挑戰

美團的成長速度非常快，數據的規模和復雜度還將十倍百倍的增長；業務多樣且變化迅速。如何能夠在海量數據基礎上進行數據的管理、加工、分析以支持快速成長的業務，后續還面臨很多挑戰。

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