肯定不行，而且ETL在未來的發展中，ETL工程師的作用還會更大。

先說說ETL是什麼吧，資料的抽取、轉換和載入。

你以為你最後給老闆看的報表，就是把平時進入公司系統的資料稍微處理一下，就能上臺面了？

別想太多！

需要經過很多的操作，而ETL卻是必經的過程，只有把那些髒資料給清除掉，留下來的才是有用的資料，就拿阿里和騰訊來說，一天的資料量大的嚇人，給兩位馬爸爸看，不得好好處理一下？

雖然被認為是苦X的職業之一，但是我會的多！

我懂各種資料庫和介面，會搭hadoop，會寫超複雜邏輯的sql（不是取數機），還負責資料倉庫、資料建模、還有一些額外的運維工作，想想就有很多事情，沒了我，你以為就是失去了一個普通員工？

你得再招好幾個！

ETL工具現在有了很大的進步，隨著實時資料的要求越來越大，份量會更足。

甚至有了這樣的說法：ETL 是 SQL 人重啟輝煌之光的必經之路。

不管ETL還是ELT這都是概念和方法論，短時間看不到其被顛覆的可能，好比大米，得煮熟了才能吃。當然也不排除未來哪天人們開始生吃。

不可以。

哈哈，是不是離你的預期答案差很多？

先說說為什麼會有不想再使用ETL的想法？

因為儘管在ETL上花費了大量時間和金錢，公司仍然會遇到很大的問題：比如資料不準確、查詢不夠徹底等。

那這些問題現在有辦法解決嗎？

暫時是沒有的，ETL還是得用，在具有成熟業務的公司裡不可或缺，但這並不代表這是一個好崗位。

etl工程師主要進行資料採集、轉換等方面的資料預處理，也稱資料清洗。這個工作打個不恰當的比喻，是洗菜工而不是廚師，所以和工作年限和年齡無關，和自己的發展規劃相關。

所以做了幾年之後，發展的空間不夠大，但是養活自己是沒有問題的。

ETL的使用既痛苦又昂貴且容易失敗，但我們能做些什麼呢？事實上，許多公司已採取各種方法來解決這一難題。

1. 合併OLTP和OLAP

2. 給ELT一個機會

3.實時流式ETL

這些都是解決方法，你都可以參考使用。

目前來說是不行的，ETL任然是大資料時代下資料遷移不可缺少的

首先說一下什麼是ETL，ETL是英文Extract-Transform-Load的縮寫，用來描述將資料從來源端經過抽取（extract）、轉換（transform）、載入（load）至目的端的過程。ETL一詞較常用在資料倉庫，但其物件並不限於資料倉庫。也就是說幾乎所有的資料的移動都需要ETL的參與！

目前用到的ETL工具常見的有Datastage，informatica，kettle三種，前兩者是收費的，並且佔據了大多數國內市場，而kettle是來源免費的！但是在大資料量下Informatica 與Datastage的處理速度是比較快的，比較穩定。Kettle的處理速度相比之下稍慢。所以很多公司尤其是金融機構選Informatica 與Datastage。但是kettle由於是開源的所以有很強的擴充套件性。

資料要想有價值，就必須把它進行分析，挖掘出來它潛藏的價值，人們日常活動產生的資料一般是放在業務系統中，而在業務系統中的資料是不能直接進行分析處理的，這個時候我就得把這些資料搬運到一個倉庫裡，再進行分析！也就是所說的資料倉庫，在而這個資料的搬運工就是ETL，在搬運的過程中我們還要做一些初步的清洗，去掉一些無用的不全的資料，這也是ETL的功能！最後我們那這些處理過的資料進行商業分析！這就是一個ETL的過程。

在資料就是價值的今天我們更加離不開ETL，當然這個過程也在不斷的改進，運用也越來越智慧越來越方便

說到ETL，很多開發夥伴可能會有些陌生，我也是在近幾年的工作過程中才接觸到ETL的，現在的專案是比較依賴於ETL，可以說是專案中重要的一部分。

先看一看ETL是做什麼用的：ETL是將各個業務系統的資料，透過抽取、清洗、轉換之後，載入到資料倉庫的過程；ETL可以將分散、零亂、標準不統一的資料整合到一起。完整的ETL功能有很多（ETL是三個三次的縮寫...），我只從我實際使用的場景出發，說明我對ETL的理解和實際應用。

我接觸過的專案，使用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是很難被替換掉的。

ETL的實現方式有多種，但是以下三種較為常見：

（1）ETL工具（如SQLServer2008的SSIS服務、Informatica，DataStage，Kettle等）實現；

（2）SQL方式實現（編碼實現）；

（3）ETL工具和SQL相結合。

目前我們常採用的方式就是第三種ETL工具和SQL相結合，他綜合了ETL工具可以快速建立ETL工程的特點，摒棄了複雜的編碼任務，提高了速度，同時也吸納了SQL靈活的特點，可以提高ETL的執行效率，而且本身圖形化簡單便於操作，並且處理海量資料的速度、響應快，流程清晰便於檢視，同時支援多種作業系統的部署，綜上優勢，可以讓ETL的開發速度的效率得以極大的提高。

隨著企業的不斷髮展壯大，資料的分析也會不斷的多樣化，這就導致資料的來源會是多個數據源，而這些資料來源的資料也會是多樣化的，例如事務性資料，時間序列和地理資料等，這些資料直接儲存數倉是不行的，需要經過ETL進行資料的轉換才能進入到數倉，而對於這些資料的處理，由於源資料庫的儲存方式各不相同，並且很多資料庫相互獨立（業務上是有關聯的），必須關聯後對映到資料倉庫中，而且根據實際的情況進行特殊命名，梳理成數倉統一格式，而這部分工作就需要進行大量指令碼的編制，而且隨著業務的不斷變化，形式也會發生改變，指令碼也需要隨之調整，這就導致企業需要投入更多的人力、物力、財力進行相應的維護和開發工作，給企業無形中添加了更大的壓力。

對於ETL是否使用，其實需要根據企業的實際情況來定，對於業務相對較為成熟的大型企業，其業務發展相對較為固化，業務調整頻率也不會太高，這個時候使用ETL就會更快的凸顯其價值，而且能夠透過ETL的使用，更好，更快的體現業務價值，而且由於業務改動頻率較低，可以更好的發揮ETL的優勢。而對於發展中的企業來說，沒有更多的財力、人力進行投入，而且業務變化需要根據其發展情況不斷調整，這個時候使用ETL就會成為企業的負擔，加重企業的投入，但是為了滿足企業分析的需求，我們可以選擇一些ESB資料匯流排產品進行替代使用，可以對協議類、大資料、非格式化資料能更好的支援，同時能夠更好適應企業頻繁的業務變化，調整更為容易。

如果要做資料倉庫，ETL是必不可少的一個步驟，如果缺乏了這個環節，後面的環節就沒有辦法開展，因此ETL還是非常重要的，如果要選工具的話，推薦使用智分析去做ETL。