相信接觸數據管道的公司都很困惑到底應該選擇ETL還是ELT？有人認為ELT可以根據數據的分布情況進行并行處理優化，它更好；也有人認為ETL可以分擔數據庫系統的負載，可采用單獨的硬件服務器部署，所以它更好，到底誰好一直爭論不休，那么希望看完本文能平息這一爭端。

回歸本源

任何數據管道的流動的目的只是將以規定的格式和結構存儲的數據從一個地方移動到另一個地方。數據的源頭稱為源，目的地稱為目標，有時也稱為匯。有兩種模式描述了這個過程，但都沒有規定持續時間、頻率、傳輸技術、編程語言或工具。這兩種模式如下：

ETL--代表提取、轉換、加載，確切地描述了流水線的每個階段所發生的事情。首先從源頭提取數據，然后以某種方式進行轉換。最后，數據子集被加載到目標系統中。

ELT - Extract, Load, Transform模式類似。管道開始時，再次從源數據中提取一個數據子集，但隨后立即將其加載到目標中。最后一步執行數據轉換。

很明顯，這兩種模式之間的唯一區別是，當你執行數據轉換時。請注意，這兩種模式都沒有規定轉換是發生在數據傳輸之前、期間還是之后。例如，讓我們檢查一下ETL模式。

下圖說明了數據子集是在轉換和最終加載發生之前通過線傳輸的。

同樣的道理，在傳輸和最終加載之前，提取和轉換數據子集也同樣有效。

在現實中，廠商的實現往往決定了數據傳輸操作的順序和優先性。事實上，前面提到的許多實施細節（如頻率等）也高度依賴于供應商。

ETL和批處理

一般來說，ETL流程按照預定的時間表運行，例如每分鐘、每小時、每天或每周，這取決于用例。請注意，ETL管道也可以響應外部觸發器或事件而運行，但這種情況不太常見。

一個預定的ETL過程被稱為以批處理模式運行，其頻率往往由以下約束條件決定。

• 所需數據的及時性
• 提取數據的時間
• 轉換的持續時間
• 傳輸數據的時間
• 執行加載的時間
• 批次之間的交易量

總的來說，這個過程很好用，但當數據量和ETL處理時間超過所需的時效性時，就會出現困難。例如，一家銀行可能需要每10分鐘更新100萬筆交易的數據倉庫，但提取、轉換和加載批處理需要15分鐘。將頻率延長到20分鐘不是答案，因為數據量也分別增加到了200萬行。

它們是做什么的？

ELT、CDC和實時

銀行的備用策略是重新思考流程，并在不同步驟發生時重新安排優先級。如果我們假設提取、傳輸和加載數據的時間與之前相同，那么使用ELT可以讓后端進行轉換，可能是在更多資源可用的時候。

這種模式可以通過添加變更數據捕獲（CDC）進一步增強。CDC不像ETL那樣按批處理計劃運行，而是在數據源發生變化時每次都會被觸發。因此，在我們銀行的例子中，ELT流程為每一筆交易運行，并且通過電報傳輸的數據量很少。不需要等待處理一百萬行的數據。實際上，提取和加載過程是實時發生的。

然后，銀行可以選擇安排一個批量轉換過程，或者推遲轉換，直到數據被消耗。通常情況下，我們發現客戶會采用這兩種選擇。

此外，近年來數據的數量、速度和種類都在大規模增長，ELT在很多情況下已經取代ETL成為數據移動的事實模式，尤其是在云數據遷移、數據倉庫和湖泊攝取以及ML Ops--利用機器學習實現數據管道的持續交付和自動化等場景下。

結論

在這篇文章的開頭，我們爭論了對于數據管道來說，ETL還是ELT是更好的模式，最后得出了 "這要看情況 "這個不滿意的答案。雖然傳統上ETL一直是數據集成的主力軍，然而事實是，時效性很重要，而ETL卻步履蹣跚。因此，如果你的分析或機器學習項目需要實時的數據，那么ELT是首選模式。

如果您想使用屢獲殊榮的ELT解決方案實時移動數據，請選擇進行測試。