均一網站 — 資料收集和分析架構 (下)


前言

我們希望能夠使用老師、學生在均一平台產生的資料,幫助功能開發的決策。無奈剛開始做資料分析的時候,沒有完整的資料分析架構去幫助資料分析。經過了一年多的思考和嘗試,現在均一的資料收集和處理系統有一個相較以往完整的雛形,在此篇文章將分享以及回顧這段過程,希望可以幫助到需要自己建立資料處理系統的讀者。

本文分(上)、(下) 兩篇,(上)篇會著重在各種資料的收集,儲存進統一的資料庫,(下)篇則會著重在這些資料後續的處理和應用。

均一資料架構圖

前情提要

在 (上) 的時候我們分享了均一如何從 DB 、 server 、 client 端把資料導入我們主要處理資料的 Big Query,另外再加上 AB test。之後將分享如何把資料做整理,最後再根據適合的管道投放給有不同需求的對象。

匯入資料整理

經由不同管道匯入的資料需要經過整理後才方便使用,根據以下幾點理由:

       1. 許多不同管道有匯入同一資料的情形(ex. 使用者縣市位置:有某些 email 可以反查、有些 ip 可以從學網反查、有些使用者有自填、最後 GA 也會有一個參考值)

       2. 許多不同管道匯入的資料表其實圍繞著同一個主題(ex. 教練派任務給學生),整合起來使用更方便。

       3. 從 DB 匯入的資料表有些是系統資訊,資料分析不需要用到。

       4. 從 DB 匯入的資料有些是其資料格式獨有的 repeated field,在後續使用 ORM 的時候會有問題(見後文)

       5. 一些欄位命名不當造成混淆、資料表在匯入時的資料格式限制(ex. 系統的時間是 UTC 而不是 GMT)

因此我們在 Jenkings 設定了一個工作排程,目前是每週會把個管道的資料表做一次整合,在符合 Tidy 原則的情況下,整合成約 20 張資料表,之後後續的分析使用希望都是依據這些資料表,軟體團隊也比較好續控管資料的品質,也方便跟外部單位做資料分析和研究上的合作。

建構資料 DashBoard 給非技術人員使用

均一初期使用的資料呈現工具是 Google spread sheet (路線5),最近嘗試把它搬到 Metabase 上面。當初選擇 Google spread sheet 的原因如下:

      1. 建構資料 Dash Board,初期需要很多的嘗試 (不知道自己真正要看的是什麼、生了很多資料表最後卻無法連接到行動),因此需要一個容易上手、有大彈性做改動的平台,多做嘗試 (Running Lean 的作法) --> 排除一些較大型 BI 系統。

      2. 因為對像是非技術人員,希望呈現頁面是他們容易理解互動的。

      3. 需要容易和 big query 對接 (ref. 其他和 BigQuery 的第三方合作產品)

      4. 因為不確定成效如何,想找一個免費或夠便宜的。

我們在 2016 年暑假找過許多 big query 第三方合作產品,根據以上條件沒有找到適合的,反而是 Google spread sheet,同時兼顧以上幾個優點,當然,因為它本身的使用情境(見下圖說明),使用上也並不那麼方便。因此,最近我們轉而使用 Metabase 的主要原因如下:

      1. 直接使用 big query language 即可, Google spread sheet 還需要搭配 Google 自創的 app script。

      2. Metabase 下參數更容易

      3. Metabase 作圖更方便

      4. Metabase 的頁面較美觀

我們將常用的query 條件,進行可視覺化的面板選項選取,當欄位完成後,按下 send query 按鈕(可自行設計) 靠著指令編輯器選取,將各個欄位值組合成Query 字串,傳給Bigquery 進行資料擷取,比較常見的是將值放入  where 的用法,例如:如果我將地區設定為 ‘新北’,那麼會在某一段 Query 內部放入一個 「WHERE CITY == ‘新北’ 」這樣的概念。

 經過BigQuery 送回的資料,回傳後顯示如上。

Metabase 只負責送出 query,再接收回傳值,本身不負責內容運算, 每次的回傳結果,可直接做圖,或存成表格,將這些結果個別儲存在 dashboard 上,隨時可以檢視。另外 Matabase 的 query 提供安插變數功能,非常方便。附上 Metabase 的 Github

建構 ORM 方便 Query Code 的管理和重複利用

在使用 query language 進行資料分析的時候,query code 只要一複雜 (query 裡面有 sub-query 裡面有 sub-query...),就會產生以下幾個問題:

      1. 很難 debug

      2. 之後很難重複使用

      3. query 上的成果難和他人共享

因此我們最近開始導入 ORM(Object Relational Mapping) (路線 6) 來試著解決問題。

Big Query 目前沒有提供和 ORM 連結的服務,我們使用 Ibis,Ibis 可以把 ORM 編譯成 Impala query code ,我們寫了一個很醜的文字轉換方程式,把 Impala 轉成 sql standard,最後從 Pandas 的 gbq 介面把 sql standard code 丟到 Big Query 上面,成功得到回傳的 Pandas dataframe,來做後續的資料處理。我們把這整個過程包成一個 package 在 github 上面,叫做 big-orm,歡迎大家一起使用。

未來希望以此為基礎,幫助工程師建立可共享和重複使用的資料分析成果,預期也可以開始做資料分析的 Code Review 了!

心得小結

在 (下) 篇我們簡短介紹均一的資料從匯入  Big Query 之後,我們統整,再藉由不同管道匯出給有不同需求的人做使用。

你很容易就會發現,我們開發的套件,或是一些工具的使用方式都很簡陋、很粗糙。因為我們想要先把整個路程(從原始資料的收集到分析到最終做決策影響行動)建構起來,把這整個資料的處理到應用過程視為一個系統,之後在分析資料做決策或建構機器學習功能(我們分析資料的目的)時,再不斷回過頭去檢視系統哪些地方是需要改進的,是有效幫助我們達到最後目標的關鍵。我們認為這會比一開始花好幾倍的時間建構出一個完整的系統,最終卻發揮和我們真正的需求有出入來得有效率。

希望這兩篇文章,對於想要自行建構資料處理系統的團隊有幫助!如果針對裡面那個部分的技術和作法有疑問或建議,都很歡迎大家來彼此認識討論 ^^"

Leave a comment

你的電子郵件位址並不會被公開。 必要欄位標記為 *