孟母三遷 — Data Warehouse 搬遷實錄（三）

西瓜偎大邊 AWS -> GCP

前情提要

搬遷實錄（一）：搬遷檔案格式
搬遷實錄（二）：IDC 到 AWS

雖然 Bigquery 在前年就有聽到有在使用的前輩大力推薦，但是當時公司剛上 AWS，也沒啥機會用．中間一年我去其他公司晃一晃都用超猛的實體機，只有在閒暇之餘玩一下 GCP (感恩 300 鎂)．沒想到去年回來現公司，又有搬移到 GCP 上的計劃！（搬家真的超累人的，不管線上還是線下）

需求

過了一年多，Data team 人數也成長了兩倍，業務量是大大大大增，原有的架構其實已經撐不起業務需求．在 EMR 上做 adhoc query 和分析有幾個缺點：

• 要等機器開
  更不用說最近 spot instance 超難開…像下面這張，一個機器要開一個小時還分析個雕．如果跑到一半機器被標走直接 crash ．

• 難以預估要開多少機器
  這是我自己剛回來的時候遇到的問題，之前公司 Cluster 超大跑 spark 超爽， 剛回來老是抓不準要開多少機器才能跑得動資料．
• 資源不足或浪費
  延續上一個問題，當開不夠就是慢，開太多就是浪費資源．

然後還有其他種種原因啦（跟主題無關略過），所以決定搬到 GCP

BigQuery

Bigquery 有多猛應該不用多做說明．真的是瞬間處理幾百 G 上 TB 的資料．但是這次搬遷真的很惡夢，因為 BQ 和現有架構差多，真的狂踩雷．（部分可以參考 [GCP] BigQuery 踩雷遊記）這些差異包括：

• 檔案格式不符：BQ 一直到最近才支援 parquet，之前只支援 CSV、Json和 AVRO．
• 自訂 Partition：最近開始支援自訂 partition 的欄位，但是，自動偵測 schema 時不能指定 partition 欄位，偏偏如果資料來源是 parquet 的時候一定是自動偵測欄位．所以如果是有 partition 的 parquet 資料還是要另外轉檔-.-．
• 路徑結構和 partition：延續上一篇， Hive 在儲存資料時，會把 partition 欄位從資料中拿出來，變成路徑結構的一部分-.-．例如：

id,action,dt
001,view,2018-01-01
002,click,2018-01-02

如果原始資料資料是上面這樣， dt 是 partition 欄位，存到hive 時，路徑會變成這樣

table_name/dt=2018-01-01/data.csv
table_name/df=2018-01-02/data/csv

其中的 table_name/dt=2018–01–01/data.csv 會長這樣

id,action
001,view

dt 就這樣硬生生不見了．

而且另外現在 bigquery 雖然支援 * 的import ，但是不支援 nested 的 import …，表示我們所有檔案都要轉過一輪才能進 bq．

• NULL 的問題
  在 Hive 裡面，不管欄位是什麼資料格式 NULL 都是標記為 NULL，原始檔案就是紀錄成 NULL，直接丟到 BQ 變成一定要用字串才能存，就算原本的欄位是數值資料…
• 髒資料
  這不想講…有時候轉 CSV 會撞邪．

權限控管

商業的 data warehouse 最重要的一項功能就是權限控管．最好能細到 table 和 column ，BQ 目前還沒辦法做到這樣，只能用 dataset 來管理．

View 的問題

這個其實也不能怪 BQ，只是原本期望可以用 view 來控制權限和預算，但是View 目前不算很堪用．

1. View 不能 Preview
   因為是 logical view 所以不能 preview 很正常，但是 bq 如果不能 preview ，掃一次是要花錢的 XD．使用者如果想看一下 view 的內容，就等於直接 query 了，但還是能幫助使用者把常用的 query 記錄下來啦 XD．
2. View 不能強制限制一定要加 partition
   原本 table 有個很貼心的功能就是強制使用者一定要加 partition．但是在建 view 的時候就必須填上 partition，所以使用者直接 query View 的時候就沒有任何額外限制．這也不是問題但是如果使用者很無知的使用時也會滿危險的．

這件事目前還在進行中，未來有近一步更好的規劃會再來分享der~