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

搬家勞神傷財

這一系列包括：

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

最後來總結一下這幾次搬遷來學到的經驗．

資料格式由簡入奢難

如果資料庫本身對於資料格式不是很嚴謹的（像是 Hive），要搬到正統資料格式嚴謹的 DB 時（如 Redshift），會非常痛苦．因為不確定資料哪時候會跟格式不符讓 ETL 爆掉，這時候有兩種解法：

1. 根據實際需求和資料該有的格式設定：例如一個 varchar 本來就不會超過 30 ，那以前沒辦法設定就算了，現在就好好設定，爆了就爆了，爆了再來看是不是資料有問題．
2. 全部都設容忍度最高的值：如果沒時間好好處理歷史資料，卻又要馬上都要搬遷完畢的話，也只能這樣做．Varchar 設最大，能用 long 就不用 int．不過這當然會造成儲存空間的浪費．

先搞定 ETL 和新資料，再來搬舊資料

因為舊的資料搬遷真的很麻煩，但是又需要趕快在新平台上做事的話．最好的方法就是先建立新的 ETL Pipeline ，讓新的資料可以進去，舊的資料再慢慢處理．ETL 過程在搬遷中，通常幾乎需要大改，改得部分可能但是不限於：

1. SQL 內容：每家 SQL 不一樣，改這個滿想死．比較好的作法可能就是中間先做一層 ORM 之類的來呼叫，這樣子只要改 connector 就好，但是一般應該不會這樣做（畢竟誰想到的到未來會搬家）．
2. Trigger SQL 的指令：hive 是用 hive -e，bq 也有自己的 command line tool，這部分也很麻煩．當然比較好的做法也是中間再包一層，未來搬家只要改 middleware 就好，當然這也滿像幹話的．

新舊資料驗證

根據上述狀況，通常換了 ETL 後和 SQL 語法後，也需要驗證一下資料會不會跑掉．這邊沒事就沒事，有事問題就很難找了．因為 SQL 不會差太多，通常問題會發生在資料搬移的過程中是不是被丟掉（資料格式問題導致）．

結論

沒事別搬家