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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、交換平臺(tái)的現(xiàn)實(shí)挑戰(zhàn)

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

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

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

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

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

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

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