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

簡介

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

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

2014年（系統搭建）

2014年組建數據團隊，總體結構以下：

當時迅速的理解了業務，區分出來了核心主題，主要工做是數據（數據報表）支持。 2014年大數據仍是比較新鮮的，部門很是重視，配置了NB的產品和技術，老大在不少重要場合宣稱部門要轉向數據化運營，產品和運營的KPI由數據產考覈，而且爲此搭建了CRM系統。每次想到這裏都感慨BOSS的眼光，我當時就是想不明白，出個數據有啥做用。N年後的如今，沒有數據，怎麼精細化產品和運行...

按理說數據團隊應該策馬奔騰邁向小康社會了。可是蜜月期很短，幾個月後就逐步出現了問題。最主要的表現是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. 協調資源

所謂資源，就是要人和時間。向BOSS說明兄弟部門投入多少多少人力和時間達到了什麼效果，反觀我們只有那麼點點...固然因爲衆志成城、團結一心，能夠只用XX成本就能達到那個效果...歷經N次電話會議，終於理解了數據倉庫的搭建方案和應用細節

2. 搭建倉庫

首先選型，kimball仍是inmon，區別就很少說了。選擇的是Kimball，爲了讓運營和產品用的更方便，也產出了寬表，這樣寬表能夠覆蓋90%的需求，寬表+維度表能夠覆蓋剩下的需求。 

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

 

3. 維護

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

數據倉庫的迭代週期也很關鍵，業務主要使用的是寬表，咱們總結了以往的經驗後，發現業務常常遇到新需求就但願在寬表增長字段，避免關聯的煩惱，隨着字段的增長，又不控制必然會從新陷入到到天然演化體系的困局。因此採用的辦法是創建一個原則：準確+經常使用。若是符合這個原則的屬性，是以月爲單位排期加入到寬表裏面，這樣寬表就有了生命力

2018年（數據化運營）

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