我們需要什麼樣的ETL?

從10年前的數據倉庫到當前的大數據平台，ETL也需要與時俱進，這裡來談談個人的理解，如果你在考慮建設新的企業級ETL平台，可以作為參考：

定位的重新認識

ETL作為傳統數據倉庫的底層技術組件，主要是服務於數據採集的，因此，一般數據流動往往是單向的，但在新的時期，我們需要拓展其概念的內涵，從ETL升級到交換，以適應更多的應用場景，這是大數據平台規劃人員特別需要考慮的。

但我們看到，在很多企業PaaS平台級的研發中，並未將交換其納入產品的核心功能，為什麼？

ETL出來之時，的確適應了數據倉庫建設的需要，畢竟系統建設之初，數據採集和整合為王， 技術驅動業務，沒什麼好說的。

但在大數據時代，需要與時俱進，基於筆者的實踐，感覺開放的交換平台將是未來標配，原因有以下幾個：

從業務角度講， 隨著數據應用的日益豐富，不同平台、系統的相互大批量數據交互成常態，僅僅滿足於採集數據已經不適應業務需要，還需要能夠為數據的目的端落地提供支撐，我們需要一個端到端的更適應業務需要的交換系統，而不是只管自己一畝三分地的ETL系統， 比如浙江移動的日常的數據交換應用早就超過了簡單的數據採集需求，業務始終為王。

從技術角度講，ETL做一定的擴展可以升級為兼具交換能力，兩者有傳承，可以實現平滑過渡，不是有誰沒誰的問題，我們好不容易搞了PaaS級的ETL，但交換卻要考慮用另一個工具實現，同時未來大數據平台組件將異常豐富，相互之間的數據交換將是常態，必須要有個PaaS級的交換工具滿足這種要求，這是個趨勢性的東西。

從管理角度講，無論是ETL，還是系統或應用間的數據交換，管理的對象都是介面，描述的方式沒有本質的區別，我們需要用一種工具實現所有介面的透明化統一管理，顯然升級ETL是最好的方案，很多企業採集由於ETL工具存在管的還算可以，但交互的介面管理一塌糊塗，比如繁多的FTP搞暈了運維人員，付出的管理成本很大。

交換平台的一種架構

以下是勾畫的一種數據交換平台的功能架構，供參考。

交換平台除了傳統ETL功能， 分散式動態可擴展是必須的，現在雲化交換平台產品已經很多了，應該各有千秋吧，特彆強調以下幾點：

必須具備多樣化數據採集能力，支持對錶、文件、消息等多種數據的實時增量數據採集（使用flume、消息隊列、OGG等技術）和批量數據分散式採集等能力（SQOOP、FTP VOER HDFS），比基於傳統ETL性能有量級上的提升。

必須支持對於業界主流資料庫的相互對接能力，包括ORACLE/HIVE/GBASE/IMPALA/ASTER/HBASE等等，要實現這些功能，涉及到互信等眾多問題，但對於業務的價值巨大。

必須具備多租戶的管理，因為傳統ETL可能跟應用無關，統一運維團隊配置即可，但交換跟應用強相關，必須要能夠授權自主配置，這個時候，多租戶管理就變得非常重要。

必須具備能力開放能力，能夠對外輸出元數據，這個其實是未來對於任何企業級平台的剛性要求，做平台的企業別老想著封閉，包打天下， 比如浙江移動有個統一的數據管理平台，不能由於交換平台的封閉，讓數據管理平台廢了半條腿，這是企業未來引入技術組件必須考慮的因素。

必須具備可視化快速配置能力，能夠提供圖形化的開發和維護界面，支持圖形化拖拽式開發，免代碼編寫，降低開發難度，每配置一個數據介面耗時越小越好，比如以前我們採用的老ETL平台一個介面平均配置3小時，這是無法忍受的。

必須具備統一調度管控能力，實現採集任務的統一調度，可支持Hadoop的多種技術組件（如 MapReduce、Spark 、HIVE）、關係型資料庫存儲過程、 shell腳本等，支持多種調度策略（時間/介面通知/手工）。

交換平台的現實挑戰

除了BAT，業內真正能打造這類PaaS級的ETL平台屈指可數，因為要實現此類交換平台綜合要求其實非常高，除了技術因素，挑戰更多來自於需求理解、開放性及持續服務能力，這是我們在實踐中碰到的痛點：

客戶需求的理解往往是硬傷，很多公司技術的確很強，但由於產品是賣給別人的，自己也不會用，其很難達到BAT產品的境界，未來是BAT的，不是說BAT技術有多強，而在於其產品從實踐中走出來，在客戶需求理解能力上是大多數公司難以項背的，客戶大多數時候並不需要你的技術有多牛逼，快速解決問題就行，但此類產品經常陷入拼性能，列功能，強升級的場景，而忽視本質的東西。

開放性也是很多公司的軟肋，隨便拿個可視化界面來講吧， 大多數場景其實需要極簡的界面，我們經常哀求能否開放個API出來啊，其他平台無縫集成下行不，但往往無法滿足，說不符合產品路線，如果下回有個ETL公司來跟你推銷產品，你首先得問一句，能開放元數據介面不？能開放API不？

服務型公司才是未來，一個產品打天下的時代即將過去，未來是服務的時代，甭跟我提一堆概念，誰都無法預測未來，我更關注當下，既然我找你，你就要做好持續服務的準備，一個合理的優化短則一月，多則1-2年，沒有哪個客戶有耐心。

ETL作為企業搞大數據核心的技術平台，在建設或選擇的時候，要考慮的東西其實非常多，大多傳統企業在這方面的掌控能力是非常欠缺的，很容易陷入建設的怪圈而效益卻很難顯現，以為搞了雲化就OK了，其實僅僅解決了ETL中很小的一個問題，不被忽悠並理解自己真正想要什麼其實很難。

我上面列的那張功能架構圖，任何一個點的需求即使要進行確認，投入的精力也是蠻大的， 不全面考慮，死磕到底，最後吃虧的終將是企業自己， 一個小功能的缺失就可能導致ETL的效率的大幅降低，甚至可能推倒重來，留給運維團隊的也將是無盡的痛苦。

當然如果企業的數據量不大，那怎麼搗鼓都行，其實大多數企業當前並不需要重型的ETL大炮，但對於每個BI人，從大數據的角度講，理解它又是有必要的。

End.

作者：傅一平 （統計網特邀認證作者）

本文為統計網原創文章，需要轉載請聯繫統計網（），轉載時請註明作者及出處，並保留本文鏈接。