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

走走上雲端

前期提要

在上一集 孟母三遷 — Data Warehouse 搬遷實錄（一）提到：資料一直來，有一天還是爆炸了．但就算是壓縮成 Parquet 還是有爆炸的一天，剛好公司有搬上雲端的計畫，所以就得規劃一下看怎麼搬比較好．那時候有幾個考量：

1. 成本控制
   和實體機租好放著不一樣，雲端的東西就是用多少算多少，而且這是公司第一次導入雲端資源，其中一個目的也是希望能節省成本．
2. 計算資源分配
   當時在實體機作業時，最常發生的問題就是在上班時間如果有同事在使用 Hive 的時候，其他人大概就只能等了．為了因應當時正在成長的 data team，也需要考量到資源的配置．
3. 基本權限管理
   因為是小 team 所以權限不用控制的很嚴，但還是希望能有基本的權限，可以控制使用者只能訪問某些 database ，或哪些 db 只能讀不能寫．

AWS

當時 AWS 上的 data warehouse 有兩個方案 — EMR 和 Redshift．細節比較可以參考 AWS 官網 XD 但是後來不用 Redshift 的原因就是因為太貴了． Data Team 主要的任務包含了日常的 ETL 、 Adhoc Query 以及資料探索及建模的部分．Redshift 如果要滿足上述所有需求的話就太貴了，而且因為在上班時間可能很多人都要探索資料，也會影響計算資源，所以當時就不考慮 Redshift，而改走 EMR 路線．

而 EMR 也有分為兩種路線．一種是跟實體一樣，維護一座常駐的 EMR 集群．但是缺點其實就跟 Redshift 一樣，貴又搶資源．所以最後決定用以下的規劃方式：

1. 資料都放在 S3 上，不放在 EMR 的 local HDFS．
2. 透過 RDS 當作 Hive 的 Metastore，雖然需要常駐，但 RDS 很便宜．
3. EMR 和 EC2 可以用一樣的方式設定 Hive Metastore ，無論使用 EMR 或 EC2 都可以存取 Hive 的資源．而且就算 team 成長到十個人，十個人可以開各自的集群來處理資料．
4. 這種做法同時也兼容 Spark ，Spark 可以透過 Hive 的 Metastore 來存取資料，如果要建模還是做其他計算也很方便，不用完全依賴 SQL．

從 Local 上 Cloud

雖然上面說 Redshift 很貴，但初期還是有試著導入一下，但是真的“一下”就崩潰了．主要的原因在於 Redshift 是 Schema on Write 的資料庫，剛好跟 Hive Schema on Read 的特性相反．所以原本一些很髒的資料存在 Hive 上通常都沒問題，但是一往 Redshift 丟就爆炸了…以我們的資料量和當時的人力來說根本沒空去清資料，所以一下就放棄了．

從 Local Hive 到 Aws EMR 的過程雖然沒有資料的問題但還是有其他問題．

1. 檔案結構
   Hive 的檔案結構是 表格名稱/partition/file (tablename/dt=2011–01–01/test.csv)．這個檔案結構可以直接往 s3 丟．
2. metastore
   原本Hive 大部分都是 original table，但是到了 EMR + s3 的組合時，table 就必須改成 external table ，所以這部分所有表格都需要重新 create．這部分是最麻煩的
3. 舊的資料要重新 repair
   如果資料不是透過 insert into 進去，而是直接放到資料夾中的話，需要 repair 這個表，讓他重新掃一遍裡面有哪些partition．
4. 新的資料直接倒進去
   只要 database name 和 table 沒變的話，原本 Hive 的 ETL 改動也相對小．
5. 權限問題
   權限其實是裡面最麻煩的．因為 EMR 預設的使用者不管誰開都是 emr-user，權限都是一樣的，而且分不出哪些使用者做過哪些事情．這部分客制了很多 initial script ，包括根據開啟的人建立不同使用者名稱，還要再 hadoop 裡開相對應使用者的權限和目錄，等等等設定．加上 EMR 當時的 log 真的很亂，過程很想殺人．