從10年前的數(shù)據(jù)倉庫到當(dāng)前的大數(shù)據(jù)平臺，ETL也需要與時俱進(jìn)，這里來談?wù)剛€人的理解，如果你在考慮建設(shè)新的企業(yè)級ETL平臺，可以作為參考：

一、定位的重新認(rèn)識

ETL作為傳統(tǒng)數(shù)據(jù)倉庫的底層技術(shù)組件，主要是服務(wù)于數(shù)據(jù)采集的，因此，一般數(shù)據(jù)流動往往是單向的，但在新的時期，我們需要拓展其概念的內(nèi)涵，從ETL升級到交換，以適應(yīng)更多的應(yīng)用場景，這是大數(shù)據(jù)平臺規(guī)劃人員特別需要考慮的。

但我們看到，在很多企業(yè)PaaS平臺級的研發(fā)中，并未將交換其納入產(chǎn)品的核心功能，為什么?

ETL出來之時，的確適應(yīng)了數(shù)據(jù)倉庫建設(shè)的需要，畢竟系統(tǒng)建設(shè)之初，數(shù)據(jù)采集和整合為王， 技術(shù)驅(qū)動業(yè)務(wù)，沒什么好說的。

但在大數(shù)據(jù)時代，需要與時俱進(jìn)，基于筆者的實踐，感覺開放的交換平臺將是未來標(biāo)配，原因有以下幾個：

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

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

從管理角度講，無論是ETL，還是系統(tǒng)或應(yīng)用間的數(shù)據(jù)交換，管理的對象都是接口，描述的方式?jīng)]有本質(zhì)的區(qū)別，我們需要用一種工具實現(xiàn)所有接口的透明化統(tǒng)一管理，顯然升級ETL是最好的方案，很多企業(yè)采集由于ETL工具存在管的還算可以，但交互的接口管理一塌糊涂，比如繁多的FTP搞暈了運(yùn)維人員，付出的管理成本很大。

二、交換平臺的一種架構(gòu)

以下是勾畫的一種數(shù)據(jù)交換平臺的功能架構(gòu)，供參考。

交換平臺除了傳統(tǒng)ETL功能， 分布式動態(tài)可擴(kuò)展是必須的，現(xiàn)在云化交換平臺產(chǎn)品已經(jīng)很多了，應(yīng)該各有千秋吧，特別強(qiáng)調(diào)以下幾點，：

必須具備多樣化數(shù)據(jù)采集能力，支持對表、文件、消息等多種數(shù)據(jù)的實時增量數(shù)據(jù)采集(使用flume、消息隊列、OGG等技術(shù))和批量數(shù)據(jù)分布式采集等能力(SQOOP、FTP VOER HDFS)，比基于傳統(tǒng)ETL性能有量級上的提升。

必須支持對于業(yè)界主流數(shù)據(jù)庫的相互對接能力，包括ORACLE/HIVE/GBASE/IMPALA/ASTER/HBASE等等，要實現(xiàn)這些功能，涉及到互信等眾多問題，但對于業(yè)務(wù)的價值巨大。

必須具備多租戶的管理，因為傳統(tǒng)ETL可能跟應(yīng)用無關(guān)，統(tǒng)一運(yùn)維團(tuán)隊配置即可，但交換跟應(yīng)用強(qiáng)相關(guān)，必須要能夠授權(quán)自主配置，這個時候，多租戶管理就變得非常重要。

必須具備能力開放能力，能夠?qū)ν廨敵鲈獢?shù)據(jù)，這個其實是未來對于任何企業(yè)級平臺的剛性要求，做平臺的企業(yè)別老想著封閉，包打天下， 比如浙江移動有個統(tǒng)一的數(shù)據(jù)管理平臺，不能由于交換平臺的封閉，讓數(shù)據(jù)管理平臺廢了半條腿，這是企業(yè)未來引入技術(shù)組件必須考慮的因素。

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

必須具備統(tǒng)一調(diào)度管控能力，實現(xiàn)采集任務(wù)的統(tǒng)一調(diào)度，可支持Hadoop的多種技術(shù)組件(如 MapReduce、Spark 、HIVE)、關(guān)系型數(shù)據(jù)庫存儲過程、 shell腳本等，支持多種調(diào)度策略(時間/接口通知/手工)。

三、交換平臺的現(xiàn)實挑戰(zhàn)

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

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

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

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

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

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

當(dāng)然如果企業(yè)的數(shù)據(jù)量不大，那怎么搗鼓都行，其實大多數(shù)企業(yè)當(dāng)前并不需要重型的ETL大炮，但對于每個BI人，從大數(shù)據(jù)的角度講，理解它又是有必要的。