ETL和ELT到底有啥區別？？？
我最早聽說 ELT 的時候也楞了一下，只不過簡單琢磨了一下就放下了。今天重新聽到，其實也沒啥感覺。
反正有人也給出了最言簡意賅的解釋：
只是換個順序？
然后就有人蒙圈了啊！這都行？
還有人猜：
額。。。其實吧，?ETL?和?ELT?還真的只是順序不一樣。
ETL?是Extract（抽取）、Transform（轉換）、Load（加載）；
ELT?是Extract（抽取）、Load（加載）、Transform（轉換）。
你是不是會感覺這幫搞數倉的整天就知道裝神弄鬼，整點新詞兒忽悠人！
額...你要是這么想，那可就小看了我們數倉人了，小看了架構這件事情了。來，我今天就給你細細的講一講?ETL?和?ELT?到底是咋回事。
你可以瞧不起我，但是你不能瞧不起我的專業！
那時候...
老數倉人做項目，都是一板一眼，很有章法的。
我們一般會先從業務系統開始調研，摸清楚所有數據來源的數據結構。
同時會去了解業務流程，看看業務到底是怎么運轉的，系統又是怎么留痕的，這樣兩下驗證，邏輯上就通了。
其實到這一步，我們就能知道很多信息了，經驗豐富的人基本上已經在腦子里猜到用戶的需求，開始設計報表了。
那下一步自然是去獲取用戶需求，規劃上面的即席查詢、多維分析、固定報表、儀表盤啥的數據應用了。
然后就是各種的分主題域、分層、邏輯模型咔咔一頓操作猛如虎。
如果您還有印象，應該記得我之前寫過數倉建設步驟：
注意看上圖最后一個步驟“物理建模”，從這時候起，我們才真正開始大規模的在數據倉庫中建表，也就是落地執行了。
再往后呢？就是 ETL 了，從業務系統搬數據到ODS（Extract抽取），然后像流水線一樣，處理一個環節（Transform轉換），再放到一個框里（Load加載），再處理一個環節，再放到一個框里（數倉某一層）。
這就是DWD、DWB、DWS、DM等數倉各層的建設，就這樣一層層的先處理數據，再加載到本層數倉，然后下一層再處理數據，再加載到過去。
所以，整個數據處理和流轉的過程就是 ETL ，也就是先Extract（抽取），再Transform（轉換），最后Load（加載）了。
流水線最大的好處是在固定的處理環節前提下，建設效率最快，成本最優，建好之后基本上只需要維護就行了。
我有幾個朋友是普通公司數據負責人，數據建設工作結束后，整個團隊很輕松。每天基本上就是看看任務有沒有問題，處理一些簡單的報表維護工作。
想必你也看出來了， ETL 非常適應需求比較清晰、業務比較固定的場景。
大清亡了...
很簡單，因為大清亡了啊！
ETL 很好用，自動處理所有數據，把數據規規整整的碼放在數據倉庫里供各方調取。
ETL 也很簡單，基本上都是可視化、低代碼的形式，設計好流程就行了。
ETL 的成本很低，一次性建設，之后就不用重復投入，只需要每天看看跑批任務有沒有問題就行了。所以很多人的重點工作都是運維。
但是 ETL 也有非常致命的缺點：流程太長、太笨重、時間太長，改起來成本太高了！！！
反正我是不想改別人做的 ETL 的，太痛苦了。我甚至連自己寫的都不想動。因為 ETL 程序通常是把 E 和 L 放在一起做，這就導致單個程序中的邏輯經常非常非常復雜的。
先給你來一個簡單的：
Dolphin Schedul 的代立冬代總還給了我一個文藝一些的：
是不是挺復雜的？這還不算啥，我再給你看一個復雜的：
好像沒啥是吧？還沒上面一張圖里的節點多是吧？其實這是因為一張圖根本放不下！
提供這張圖的兄弟“跨越新生”告訴我，這一共 1100 多個節點！他親手設計的！
不過我就想問問他，現在敢動不敢動！敢不敢？嘿嘿~~~
他不敢啊！所以他最怕什么？最怕改需求，最怕改業務庫！
如果業務或者底層數據要動一下， ETL 流程就要隨之進行調整。簡單的邏輯還好處理，一旦遇到“跨越新生”兄弟的這個局面，別的不說，光找節點就得找死人啊！
所以， ETL 開發很簡單，但是維護成本奇高無比！復雜度奇高無比！工作難度奇高無比！
業務的頻繁變化，再加上 ETL 的時間成本和吞吐量限制（堵塞），所以導致 ETL 這種數據加工的方式不能滿足于現在的企業發展需要啊。
改變！
當然是改變了！
但是，咋變？
誒，有聰明的兄弟就說了，把?ETL?變成?ELT?啊！
對，但是沒說到點子上。
并不是單純的把流程倒置這么簡單的，咱還得回到?ETL?問題的根本。
ETL?之所以這么復雜，是因為 Transform （轉換）和 Load （加載）兩個環節耦合過緊導致的。
我們用最樸素的架構思維想一下就明白了，讓復雜的事情變簡單，最簡單的方式是啥？
一個字：“拆”字訣！
把 Transform （轉換）和 Load （加載）哥倆拆開了就行了，這樣處理數據的部分就專心計算就行了，搬運數據的部分就專心搬運就好了，別混在一起四腳八叉的。
所以， ETL 工具就變成了搬運組件、計算引擎和調度引擎。
搬運組件專門負責搬運數據，不做任何數據處理的操作；
計算引擎專門負責進行數據處理，其他事情跟我沒關系；
調度引擎專門負責做流程編排，其他事情也跟我沒關系。
有哥們會問， ETL 工具跑哪里去了？是這樣的，我們需要把 ETL 和 ETL 工具分開哈。這里的 ETL 特指數據處理流程。
在上面的步驟中，也是可以用 ETL 工具代替的。畢竟 ETL 工具全能嘛，這三件事情都是能做的哈。
既然是整個工作流都拆開了，那流程也自然就有變化了。第一步沒啥變化，但是之后的事情就不太一樣了，整體就變成這個德行：
需要注意的是：上面這個架構只是示意哈，里面的所有具體的組件都是可以換的。
比如說抽取這個動作，你可以用 ETL 工具，可以用 Kafka，這種神奇的東西最大的好處就是吞吐量極大，任你來多少數據都能吃的下。
ODS 可以是數倉的 ODS，也可以是數據湖，奇葩一些用 Kafka 也沒問題，別重復了就行。
加載這個動作也可以用 Kafka 或者啥 ETL 工具都行；
計算引擎你用 Spark 還是 Flink 還是 MR 都隨意，反正只要能跑任務就行，最后直接輸出到 HBase 也行，扔到 Kafka 或者 Redis 都可以。
你現在再看看對比一下兩張圖就會發現為啥是?ETL?和?ELT?了。
那?ELT?有啥好處呢？
最底層的改變是E、T、L徹底的解耦了。解耦之后好處多多，比如突破性能瓶頸、程序簡化、組件替換、維護成本降低等等。
不過最重要的還是解耦導致的極致的靈活，可以適應當前復雜多變的市場環境。
因為在復雜多變的環境下， ETL 這種傳統的數據處理套路是極度不適應的。
等你慢慢分主題域、抽取實體、建好模型、寫各種代碼、各種調試，好不容易出一張報表的時候，業務過來跟你說：哥，咱的打法變了，APP 都迭代了 3 輪了，這是新需求。你上哪哭去？
所以現在很多大廠的新業務中，都在弱化建模，強化效率，用的其實就是?ELT?的邏輯。
數據直接入湖，然后寫個腳本扔 Spark 里跑，直接拖張寬表扔庫里，然后懟到一個報表展示工具完事了。
這又不得不提到那個百度的小伙伴在脈脈上提的問題：
結語
時代一直在變，技術也是在不停的變。我們需要做的事情是持續學習，不斷精進，深度思考。關注我，我們攜手同行！
大數據
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
相關文章
