為什麼需要防火牆? 是有什麼會燒起來嗎?萬一燒起來再救火不行嗎?
先解釋一下這邊防火牆的意思是,在 Data Lake和實際的 Data warehouse之間的一個預先處理措施。
以均一來說 Data Lake包含了 Google Cloud Storage (GCS) 和 GA,GCS之中有大量後端的資料,GA之中則是特定事件觸發的紀錄,都會直接傳送到 BigQuery之中。
傳送過來之前有經過一定的處理,所以組成大致上是資料表形式,能夠直接被 Query操作,但可能存在重複資料,有些資料欄位並不需要等問題,如果直接使用,將會非常浪費效能。
另外,如果一個欄位有問題,會需要改動數張到數十張使用到該欄位的 Data warehouse表格,相當的麻煩。
因此我們的想法是,在資料來源的資料表與 Data warehouse之間再多一層,形成有如下圖的 1對1對多架構
以下以均一實際案例來說明改動的前後差異
-- 創造防火牆表格程式碼
CREATE OR REPLACE PROCEDURE
`DataSource.VideoLog_from_DB`(dump_date STRING)
BEGIN
CREATE OR REPLACE TABLE
`DataSource.VideoLog_from_DB`
AS
SELECT
TIMESTAMP_ADD(time_watched, INTERVAL 8 HOUR) AS active_timestamp_TW,
user.email AS user_primary_key,
IFNULL(video.path, auditable.path) AS video_path,
ip_address,
is_video_completed,
last_second_watched,
points_earned,
seconds_watched AS time_taken_second,
youtube_id,
FROM
`datastore_backup.VideoLog_*`
WHERE
_TABLE_SUFFIX = dump_date
AND (video.path IS NOT NULL OR auditable.path IS NOT NULL);
END;
可以看得出來程式碼並不複雜,但事前的研究工作不能馬虎
集中欄位處理
- TIMESTAMP 轉為台灣時區,原本後續 10張表都要分別撰寫轉換 Code,現在只要寫一遍,更利於 debug。
seconds_watched AS time_taken_second
將原本不夠明確的欄位重新命名,同樣也避免後續各自命名產生不一致。
前後差異比較
欄位數量:30 -> 9
資料容量:230. GB -> 86 GB(省下 63%,共 144 GB),後續有10張表使用到這個資料來源,至少省下了 1440 GB的查詢費用(約 USD $7)
結論
單一張 data lake table的改寫或許沒有省下太多查詢成本,但是在易讀性,可維護性上都會有所提昇;當資料出現問題時,工程師改1張表與改10張表的時間會有巨大的差異,越少被干擾,工程師越能專注在原有的目標上。
均一總共有20多張的 data lake table,如果全面改寫,仍能夠每週省下一筆可觀的費用,可以讓大家拿來多喝些啤酒(誤)。