從10年前的數據倉庫到當前的大數據平臺，ETL也須要與時俱進，這裏來談談我的的理解，若是你在考慮建設新的企業級ETL平臺，能夠做爲參考：shell
定位的從新認識
ETL做爲傳統數據倉庫的底層技術組件，主要是服務於數據採集的，所以，通常數據流動每每是單向的，但在新的時期，咱們須要拓展其概念的內涵，從ETL升級到交換，以適應更多的應用場景，這是大數據平臺規劃人員特別須要考慮的。數據庫
但咱們看到，在不少企業PaaS平臺級的研發中，並未將交換其歸入產品的核心功能，爲何？架構
ETL出來之時，的確適應了數據倉庫建設的須要，畢竟系統建設之初，數據採集和整合爲王， 技術驅動業務，沒什麼好說的。運維
但在大數據時代，須要與時俱進，基於筆者的實踐，感受開放的交換平臺將是將來標配，緣由有如下幾個：分佈式
從業務角度講， 隨着數據應用的日益豐富，不一樣平臺、系統的相互大批量數據交互成常態，僅僅知足於採集數據已經不適應業務須要，還須要可以爲數據的目的端落地提供支撐，咱們須要一個端到端的更適應業務須要的交換系統，而不是隻管本身一畝三分地的ETL系統， 好比浙江移動的平常的數據交換應用早就超過了簡單的數據採集需求，業務始終爲王。工具
從技術角度講，ETL作必定的擴展能夠升級爲兼具交換能力，二者有傳承，能夠實現平滑過渡，不是有誰沒誰的問題，咱們好不容易搞了PaaS級的ETL，但交換卻要考慮用另外一個工具實現，同時將來大數據平臺組件將異常豐富，相互之間的數據交換將是常態，必需要有個PaaS級的交換工具知足這種要求，這是個趨勢性的東西。oop
從管理角度講，不管是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人，從大數據的角度講，理解它又是有必要的。