大家好，我是一哥。

ETL 和 ELT 有很多共同點，從本質上講，每種集成方法都可以將數據從源端抽取到數據倉庫中，兩者的區別在于數據在哪里進行轉換。 接下來，我們一起詳細地分析一下 ETL 和 ELT各自的優缺點，看看在你們現在的業務中用哪種方式處理數據比較合適。

1.ETL

ETL - 抽取、轉換、加載

從不同的數據源抽取信息，將其轉換為根據業務定義的格式，然后將其加載到其他數據庫或數據倉庫中。另一種 ETL 集成方法是反向 ETL，它將結構化數據從數據倉庫中加載到業務數據庫中，如我們常用數據倉庫加工好的報表，推送到報表系統的數據庫中。

2.ELT

ELT - 抽取、加載、轉換

同樣的從一個或多個數據源中抽取數據，然后將其加載到目標數據倉庫中，此時不需要進行數據格式的轉換。在 ELT 過程中，數據的轉換發生在目標數據倉庫中。ELT 對遠程資源的要求較少，只需要它們的原始數據即可。

3.ELT的演變

ELT 已經存在了一段時間，但 Hadoop 等大數據技術出現后，更加活躍了。像以前轉換 PB 級原始數據這樣的大型任務無法處理，現在可以被分成小作業，進行處理，然后再加載到目標數據庫中。同時，處理能力也提高了，尤其是以私有云集群的方式，把處理、加工數據可以在一個數據倉庫中完成了。

4.ELT的工作原理

與 ETL 不同，ELT是從多個數據源收集信息，將其加載到數據倉庫(或者數據湖)中，然后將其轉換為可操作的商業智能的過程。

抽取——在ELT和ETL兩種數據管理方法中的原理相似。一般我們會采用增量抽取，對于一些維表數據量比較小的也會采用全量抽取。

加載——這是 ELT 和 ETL 開始不同的地方了。ELT 不是在抽取大量原始數據的過程中將其轉換，而是將所有數據都加在到湖倉中，然后統一進行轉換，這樣做加快了抽取的效率，但也意味著數據變得有用之前還有很多工作要做。

轉換——數據湖或數據倉庫對數據進行規范化，將部分或全部數據保留在湖倉中，并可用于定制報告。存儲海量數據的開銷更高，但也是為了后續能夠更加快速的進行數據挖掘和報表展現，也就是我們常說的用空間換時間。

5.什么時候我們選擇ELT

這取決于公司現有的網絡和技術架構、預算以及它已經利用云和大數據技術的程度。如果是有下面三個需求場景時，那么ELT就是正確的選擇~

（1）當抽取速度是第一選擇時

因為 ELT 不必等待數據在抽取過程中進行轉換后再加載，那么抽取過程要快得多。

（2）當需要隨時訪問原始數據時

有很多場景，我們需要保留所有歷史數據，分析師可以根據時間、銷售模式、季節性趨勢或任何對業務變得重要的新興指標進行挖掘。由于數據在加載之前未進行轉換，因此您可以訪問所有原始數據。比如，數據倉庫一般都有一個原始數據層，很多數據科學家更喜歡訪問原始數據，而業務用戶更喜歡使用分析后的應用層或者模型層數據。

（3）當需要隨時可擴展數據湖倉時

當您使用 Hadoop 或云數據倉庫等數據處理引擎時，ELT 可以利用本機處理能力實現更高的可擴展性。

6.數據湖是不是很好的ELT落腳點

首先，我們思考一下數倉為什么會出現?其實是數據量的飛速增長，以至于當時的數據存儲計算引擎，不能很好的滿足分析需求;于是數倉概念和經典的理論出現了，很好的解決了當時的問題，用“規范+存儲”來解決了當時的問題。

那么現在大數據時代，隨著技術的不斷發展，很多新技術出現了，大批量的存儲和計算不再是那么難了，那么我們放棄數倉那一套是否可行呢?從一哥現在處理的業務看，如果你的業務系統相對較單一，沒有幾十個業務系統每天往數倉里灌數據，那么數據湖可以滿足你的需求，并且對于“數據驅動”更“敏捷”。如果一線的業務系統較復雜，那么現在使用數據湖也會一不小心會變成“數據沼澤”。

數據湖治理策略沒有明確前，還不要急著就上數據湖，并不是適用于每個公司的業務場景的!

7.結語

ELT和ETL都有各自的應用場景，可以說現在大數據環境下，很多已經是ELT架構了，所以這也是我近幾年一直不看好很多廠商在推“拖拉拽”的ETL工具或者平臺，未來肯定是需要一種通用語言來實現所有的ELT過程。

同樣，數據湖是趨勢，但現在依然不成熟，不要看網上很多一線大廠的技術文章中提到了很多數據湖的概念和技術應用，但是請結合自己公司的業務場景，暫時先謹慎選擇!

本文轉載自微信公眾號「數據社」，可以通過以下二維碼關注。轉載本文請聯系數據社公眾號。