說到ETL，很多開發伙伴可能會有些陌生，我也是在近幾年的工作過程中才接觸到ETL的，現在的項目是比較依賴于ETL，可以說是項目中重要的一部分。
先看一看ETL是做什么用的：ETL是將各個業務系統的數據，通過抽取、清洗、轉換之后，加載到數據倉庫的過程；ETL可以將分散、零亂、標準不統一的數據整合到一起。完整的ETL功能有很多（ETL是三個三次的縮寫...），我只從我實際使用的場景出發，說明我對ETL的理解和實際應用。
我接觸過的項目，使用ETL工具的場景有這個幾種：
報表、BI系統：在公司建設的初期，業務比較少，系統也比較少，一臺數據庫就搞定了；
隨著公司業務的增加，業務系統被拆成很多系統；
隨著數據量的繼續增加，單個系統的數據增加到一定程度的時候，也做了分庫分表；
這時候領導、業務人員在用數據做分析的時候，數據來源可能是多個系統的多張表，這時候企圖通過一個復雜的SQL跑出來結果就很困難了；通常公司會建立一個數據倉庫，通過ETL工具把數據抽取到數據倉庫中，再做數據的擬合和展示。
跨系統的數據加工或查詢：我們現在所在公司，業務系統有幾百個，由于業務流程比較復雜，前端系統在做業務操作的時候，在正式提交交易之前，有很多業務校驗；比如要查詢客戶在A系統的交易歷史，在B系統的交易歷史，在C系統的交易歷史；那么就需要分別調用A、B、C系統的接口，這個對前端系統很不友好，那么通常的解決方案是什么？
學阿里，建中臺，、把A/B/C系統合并成一個大中臺，對外提供服務；這種方法很好，但是非常難；很多公司，別說把A/B/C合成一個系統了，就是A系統本身的重構，都非常地困難；
第二種方案，在前段系統和A/B/C系統之間，增加一層，可以叫做服務中臺，它的作用是整合A/B/C系統的服務，然后對外提供一個服務給前端系統調用；好處是前端系統只需要調用服務中臺的一個接口即可；
我們現在采用的是第三個方案，把A/B/C系統的數據，通過ETL抽取到一起，并通過Java把數據提前加工好，保存到MongoDB中的同一個Collection中（利用了MongoDB數據結構的特點）；再對外提供服務的時候，相當于做了一次單表查詢，就可以查詢到三個系統的數據；好處是可以調一個接口查出三個系統的數據，并且緩解了三個系統的查詢壓力；
當然這個方案也有著一個很大的缺陷，就是有一定的延遲，需要根據業務場景進行評估，是否接受這個延遲。
ETL的工具也有不少，我們現在使用的是Informatica，這是收費的，開源的只接觸過Kettle；
我們現在是根據數據表的時間戳，做增量抽取，在我看來，比較理想的方案是業務系統可以把數據“吐出來”，比如業務系統埋點發送MQ、MySQL可以監聽binlog日志，不過在我們公司都非常難以實現；
所以，至少在我們項目，ETL是很難被替換掉的。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。