工具繁多
從 DataStage到Kettle, ETL 工具覆蓋了商業(yè)化領域和開源領域, 價格從幾十萬到免費,起碼有幾十種選擇钮莲。
有人要說了,選擇多不是一件好事么?如果再早幾年,我會同意這是好事,可到現(xiàn)在,我要說 NO!
前面關于決策思維的博文提到一個論點:相比于普通人做出決策,專家是會直接給一種可行方案還是羅列眾多方案類比優(yōu)劣?
答案是前者,也是我反對選擇眾多是好事這一論點的依據(jù)之一太雨。
那么選擇多有什么壞處?
基礎方案混雜派阱。各公司方案不同,甚至一個公司 ETL 環(huán)節(jié)也采用不同工具及架構(gòu),人才無法公用,維護成本高。
數(shù)據(jù)項目失敗案例遠多于成功案例, 項目選型越復雜成功概率越低。大量公司做 BI柔滔、做大數(shù)據(jù),甚至在沒有人懂的情況下招人開工!事實上在數(shù)據(jù)領域,熟手都清楚一個現(xiàn)象,沒有成功案例的人很難做成數(shù)據(jù)項目。很殘忍的現(xiàn)實,但也讓那些盲目投入資源跟風做項目的公司考慮冷靜下來了嘹履。
抬高實施門檻。現(xiàn)在大家都想做數(shù)據(jù),進入大數(shù)據(jù)領域,尤其是有很多不具備該領域經(jīng)驗的公司想要做债热。那么實施前首先就是選型了,如果從三個產(chǎn)品選一個來做還可行的話,那么要從三十個產(chǎn)品中選型,這個工作本身就阻礙了數(shù)據(jù)項目的開展!
GUI工具
說到這里反對的朋友更多了,GUI 所見即所得,降低使用門檻,好處一頁都寫不完,作為一名數(shù)據(jù)領域從業(yè)者,我決然反對,自己都能感覺到火藥味砾嫉。為了論證我的觀點,這里要羅列ETL領域那些GUI的罪證了。
ETL 工具的六大問題
- 工具太大了,卡卡卡!我不是說 SSIS 之類,也不是說 Kettle 相關,我說的是他們所有人……
- 好用的太貴, 便宜的不好用!
- 組件式的拖拉開發(fā),性能真的沒法起來!尤其是那些依靠組件解決數(shù)據(jù)變化提取的兄弟們,你們想多了窒篱。
- 我需要一包廁紙而已,你非要給我整個超市焕刮。在我蹲之前非得找遍整個超市!大家對比下里面的功能自己使用的比率。
- 說 GUI 簡單好用的,我強烈反對墙杯。GUI 好調(diào)試么?映射過程報錯了大家要怎么辦?檢查源檢查目標也就算了,連映射環(huán)節(jié)都要排查配并。除了自己設定的格式類型,還要考慮工具環(huán)節(jié)自己的轉(zhuǎn)換類型,這不是增加負擔么?
- 部署,我都不想說部署了。一千個任務下來,ETL 工具別談部署了!這時候有同學開始研究調(diào)度,有些關注數(shù)據(jù)質(zhì)量,任務數(shù)量起來,想什么都是多的,保佑這混亂情況別出岔子就阿彌陀佛了高镐。
ETL 工具阻礙了設計
直接用工具拉數(shù)據(jù)的項目,認真找找有沒有架構(gòu)設計,有沒有項目文檔,有沒有擴展性考慮,性能考慮?或者簡單點,這項目換人可能接手下來么?
數(shù)據(jù)項目是團隊項目,ETL 工具是個人化工具溉旋。如果多個成員不能無縫接替工作,對不起,我認為這不是數(shù)據(jù)項目。哦不對,不算是一個項目嫉髓。
組件報錯是工具問題,轉(zhuǎn)換異常跟自己沒關系观腊。工具的 bug 和我真沒關系,我項目做得好好的,ETL 工具崩潰了管我什么事?遇到這種情況不說我也知道做法,崩潰了再起來跑一跑嘛,運氣好數(shù)據(jù)就跑出來了。至于數(shù)據(jù)質(zhì)量管理是什么這樣的問題,就別問出來了岩喷。
