祁國輝：一學就會一用卻廢！到底用ETL還是ELT？

ELT大行其道的同時， 也給資料倉儲的技術帶來了幾個問題， 下面我跟你簡單說說。

第一個問題，就是大量的儲存過程怎麼排程的問題。  我見到過一家國內大型科技企業的資料倉儲， 有超過一萬個資料處理指令碼。隨著業務發展， 這些指令碼的數量還是繼續增加。

那麼如此多的指令碼，我們不得不去思考這樣的幾個問題：

這麼多的指令碼進行排程，還有先後依賴關係，怎麼確定ETL 指令碼的分層管理， 如何實現整個排程過程的圖形化展現和監控，就變成了一個新的問題。

第二個問題， 後設資料管理的問題。 我記得我最初寫ETL 指令碼的時候， 只考慮了資料怎麼從源取出來， 然後再怎麼經過mapping ，生成最終結果， 中間的過程完全不需要對外輸出過程資訊。

但是這樣一來， 我們就很容易陷入另外一種僵局， 就如同前面提到的那家企業， 一萬多指令碼， 鼎盛時期有400多開發人員在做開發， 但是一旦人員流失， 換新人怎麼維護這個程式碼？難度自然就直線上升了。

同時， 如果在結果展示的時候 想知道某個資料，是經過什麼口徑統計過來的？那就完全不知道了， 因為整個指令碼就是個黑盒子， 大家都不知道資料之間的繼承沿革關係。所以怎麼利用儲存過程，自動生成ETL 後設資料， 就是第二個問題。

第三個問題， 儲存過程效率問題。 所有資料轉換都利用資料庫的特性， 那麼這個時候的資料處理效率就會全面依賴資料庫的特性，這種處理難以避免的就是多個大表Join， 排序。那麼您選擇的資料庫在大表連線的時候怎樣效率最高，怎麼利用資料庫提供的函式或者特性，加速資料處理效率，就變成了程式設計師必須要了解的一個知識點。

曾經碰到一個專案， 程式設計師對資料庫特徵不太瞭解， 同時為了程式易讀， 就透過臨時表來簡化過程， 看上去是個很好的習慣。

但是極端情況下， 原來只需要一個複雜SQL 就能解決的問題， 資料反覆寫臨時表20多次，系統上線之後，還在納悶， 資料邏輯完全沒變， 怎麼就跑不動了呢？