孟母三遷 — 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 目前不算很堪用.
- View 不能 Preview
因為是 logical view 所以不能 preview 很正常,但是 bq 如果不能 preview ,掃一次是要花錢的 XD.使用者如果想看一下 view 的內容,就等於直接 query 了,但還是能幫助使用者把常用的 query 記錄下來啦 XD. - View 不能強制限制一定要加 partition
原本 table 有個很貼心的功能就是強制使用者一定要加 partition.但是在建 view 的時候就必須填上 partition,所以使用者直接 query View 的時候就沒有任何額外限制.這也不是問題但是如果使用者很無知的使用時也會滿危險的.
這件事目前還在進行中,未來有近一步更好的規劃會再來分享der~