簡介

一轉眼在去哪兒網玩樂事業部工作快4年了，經歷了數據團隊的組建和發展，回顧一下整體過程，經歷了很多坎坷，普通而不簡單。下面是大事記

• 2014年（系統搭建）：開發報表平臺、接入HADOOP、搭建調度系統
• 2015年（數據集市）：搭建數據集市、開發數據同步工具
• 2016年（數據應用）：系統定價、多維分析
• 2017年（數據重構）：重構底層、數據分級、元數據、數據質量
• 2018年（數據化運營）：實時系統、用戶畫像、模型搭建

2014年（系統搭建）

2014年組建數據團隊，整體結構如下：

當時迅速區理解了業務，並區分出來了核心主題，並且主要工作是產出數據，也就是數據報表。 2014年大數據還是比較新鮮的，部門非常重視，配置了NB的產品和技術，老大在很多重要場合宣稱部門要轉向數據化運營，產品和運營的KPI由數據產考核，並且為此搭建了CRM系統。

按理說數據團隊應該策馬奔騰邁向小康社會了。但是蜜月期很短，幾個月後就逐步出現了問題。最主要的表現是BOSS、產品、運營看見的數據不準確、不一致、不及時....

2015年（數據集市）

蜜月期過了之後，BOSS經常在重要場合表達對數據團隊的失望，我記得非常清楚的話是：“你們知道我為了TMD數據團隊背後做了多少努力嗎？我咨詢了XXX個公司，XXX說咱們的數據，TMD1個月就能搭起來”。或者是：“你們到底要做什麽，難道就是一個提數的嗎？好，你們就做一個提數的工具吧！”。當時的情況：http://www.cnblogs.com/liqiu/p/4869748.html

重新審視了數據的問題之後，決心從底層做起，搭建數據集市（數據寬表）。效果確實很好，緩解了數據一致性、數據及時性、數據準確性的問題。大家對數據團隊的期望基本穩定了，系統也隨之穩定了下來。

2016年（數據應用）

數據穩定之後，希望做一些有意思的東西出來，首先就是解決數據同步的問題，業界有sqoop、dataX，但是對於PG支持的不好，特別是PG的擴展屬性，比如hstore支持的有限，所以決定自己開發。

1 數據同步

項目名稱是synchronous，它的設計借鑒了DATAX的插件設計理念，DATAX的文檔：https://github.com/alibaba/DataX。synchronous和DATAX的技術上區別是：代碼小巧，精煉，易懂易讀，有興趣的同學可以快速深入，讀懂了synchronous有助於快速理解DATAX。

下面偏重流程方面介紹一下synchronous：

1. 選擇同步的雙方：插件的好處就是擴展性強，可隨時增加數據源
2. CHECK元數據：至少兩邊的數據字段要一致
3. 選擇數據分片：數據量可能很大，需要分片處理
4. 同步數據：采用多線程的生產者消費者模型

詳細設計過程可見：http://www.cnblogs.com/liqiu/p/4882821.html ； 代碼在：https://github.com/autumn-star/synchronous。

2 系統定價

去哪兒以前是taobao的模式，只提供平臺和流量。後來有了自營產品，隨著業務的發展，自營產品越來越多，定價就是問題了。按照一般的策略是保證利潤率的情況下，比競對低一點。

3 自動化接口

經常需要給外部提供數據，如果每個都寫dao、dto、service和controller，開發和維護成本特別高，所以研發了一個系統，配置SQL直接吐出數據接口數據，比如一個接口需要統計一段時間每個產品的訂單量和份數，那麽數據表裏面保存這樣一個記錄,主鍵id是1：

SELECT
  product_id, --產品id
  SUM(quantity) as quantity, --份數
  COUNT(1) as order_num --訂單量
FROM table1
WHERE stat_date between @{start_date} and @{end_date}
GROUP BY product_id

訪問的時候，帶著參數就可以，比如：url?id=1&start_date=2017-01-01&end_date=2017-10-01。這樣就吐出了時間在2017-01-01~2017-10-01之間的數據。

4 多維

為了將開發從無休止的SQL需求中解救出來，搭建了多維系統，就是數據立方體。當時用的是saiku+kylin，可是saiku需要持久的前端投入，kylin對少量維度支持的還好，維度達到幾十個之後就出現問題了，所以這個項目就暫定了。但是底層數據還在，我們轉而推出一個頁面轉成SQL的簡易方案（不支持上卷、下鉆、跨天和圖形對比），雖然交互性差，但由於成本極低，一直支持長尾的數據需求。

2017年（數據重構）

年初遇到了一些問題，技術方面：1、部分數據產出延遲；2、維護成本高，人員流動性高；3、寬表不能完全滿足需求，隨之關聯了幾十上百張數據表；業務方面沒有明確的收益預期；

調研了攜程、阿裏的數據體系之後，決定先重新搭建數據倉庫，解決提升數據質量和降低人力成本，然後再發展個性化應用。步驟如下：

1. 協調資源

所謂資源，就是要人和時間。向BOSS說明兄弟部門投入多少多少人力和時間達到了什麽效果，反觀咱們只有那麽點點...當然由於眾誌成城、團結一心，可以只用XX成本就能達到那個效果...

成功之後，自己也認識到了差距，確實起點比較低，歷經N次電話會議，逐步理解了數據倉庫的搭建方案和應用細節

2. 搭建倉庫

首先選型，kimball還是inmon，區別就不多說了。選擇的是Kimball，為了讓運營和產品用的更方便，也產出了寬表，這樣寬表可以覆蓋90%的需求，寬表+維度表可以覆蓋剩下的需求。

2017的數據倉庫結構圖如下：

3. 維護

數據倉庫要準確、及時的產出數據，由於數據分散人力有限，不可能保證所有數據都百分百符合預期，所以要對數據進行分級。首先BOSS關心的報表，以及依賴的數據表是一級重要，要實時的嚴格校驗，這裏叫強一致性校驗，如果發現問題需要在任何時候電話+qt+郵件預警。財務和運營的KPI數據次之，白天qt+郵件預警即可，最後是其他的數據。

數據倉庫的叠代周期也很關鍵，業務主要使用的是寬表，我們總結了以往的經驗後，發現業務經常遇到新需求就希望在寬表增加字段，避免關聯的煩惱，隨著字段的增加，又不控制必然會重新陷入到到自然演化體系的困局。所以采用的辦法是建立一個原則：準確+常用。如果符合這個原則的屬性，是以月為單位排期加入到寬表裏面，這樣寬表就有了生命力

2018年（數據化運營）

這是正在進行的，僅介紹一下願景，隨著精細化運營的來臨，必然對數據提出更細致更及時的要求，那麽以離線為主T-1的瓶頸更加凸顯出來，所以要搭建實時的數據倉庫。另外隨著分析經驗的積累，不能像以前那樣粗狂的看報表，而要細分用戶群，采用不同的策略，所以需要高質量的用戶畫像，那麽今年會從實時+用戶畫像兩個方面展開...

去哪兒網玩樂事業部-數據模式演進