為什麼 ETL 越來越難?
04-26
summary:
自傳統數據倉庫理論形成,ETL 佔據其中70%工作量就已經成為常識。可即便經過幾十年到今天,各個平台的 ETL 普遍還在初級階段,這背後深層次的原因是什麼?tags:- BI
- ETL- DW- 大數據...
為什麼 ETL 很困難?
工具繁多
從 DataStage到Kettle, ETL 工具覆蓋了商業化領域和開源領域, 價格從幾十萬到免費,起碼有幾十種選擇。
有人要說了,選擇多不是一件好事么?如果再早幾年,我會同意這是好事,可到現在,我要說 NO!
前面關於決策思維的博文提到一個論點:相比於普通人做出決策,專家是會直接給一種可行方案還是羅列眾多方案類比優劣?
答案是前者,也是我反對選擇眾多是好事這一論點的依據之一。
那麼選擇多有什麼壞處?
- 基礎方案混雜。各公司方案不同,甚至一個公司 ETL 環節也採用不同工具及架構,人才無法公用,維護成本高。
- 數據項目失敗案例遠多於成功案例, 項目選型越複雜成功概率越低。大量公司做 BI、做大數據,甚至在沒有人懂的情況下招人開工!事實上在數據領域,熟手都清楚一個現象,沒有成功案例的人很難做成數據項目。很殘忍的現實,但也讓那些盲目投入資源跟風做項目的公司考慮冷靜下來了。
- 抬高實施門檻。現在大家都想做數據,進入大數據領域,尤其是有很多不具備該領域經驗的公司想要做。那麼實施前首先就是選型了,如果從三個產品選一個來做還可行的話,那麼要從三十個產品中選型,這個工作本身就阻礙了數據項目的開展!
GUI工具
說到這裡反對的朋友更多了,GUI 所見即所得,降低使用門檻,好處一頁都寫不完,作為一名數據領域從業者,我決然反對,自己都能感覺到火藥味。
為了論證我的觀點,這裡要羅列ETL領域那些GUI的罪證了。ETL 工具的六大問題- 工具太大了,卡卡卡!我不是說 SSIS 之類,也不是說 Kettle 相關,我說的是他們所有人……
- 好用的太貴, 便宜的不好用!
- 組件式的拖拉開發,性能真的沒法起來!尤其是那些依靠組件解決數據變化提取的兄弟們,你們想多了。
- 我需要一包廁紙而已,你非要給我整個超市。在我蹲之前非得找遍整個超市!大家對比下裡面的功能自己使用的比率。
- 說 GUI 簡單好用的,我強烈反對。GUI 好調試么?映射過程報錯了大家要怎麼辦?檢查源檢查目標也就算了,連映射環節都要排查。除了自己設定的格式類型,還要考慮工具環節自己的轉換類型,這不是增加負擔么?
- 部署,我都不想說部署了。一千個任務下來,ETL 工具別談部署了!這時候有同學開始研究調度,有些關注數據質量,任務數量起來,想什麼都是多的,保佑這混亂情況別出岔子就阿彌陀佛了。
ETL 工具阻礙了設計
- 直接用工具拉數據的項目,認真找找有沒有架構設計,有沒有項目文檔,有沒有擴展性考慮,性能考慮?或者簡單點,這項目換人可能接手下來么?
- 數據項目是團隊項目,ETL 工具是個人化工具。如果多個成員不能無縫接替工作,對不起,我認為這不是數據項目。哦不對,不算是一個項目。
- 組件報錯是工具問題,轉換異常跟自己沒關係。工具的 bug 和我真沒關係,我項目做得好好的,ETL 工具崩潰了管我什麼事?遇到這種情況不說我也知道做法,崩潰了再起來跑一跑嘛,運氣好數據就跑出來了。至於數據質量管理是什麼這樣的問題,就別問出來了。
這裡有關於 ETL 的一切
這裡有直接上手的 ETL 方案
這裡有十年數據解決方案的結晶
推薦閱讀:
※大數據預測:未來最吸金的領域
※G20遐想:馬雲、李彥宏、孫丕恕等大咖們的數據觀
※知識布局-sql-impala解析
※大數據、沉浸式學習、物聯網……美國教育從業者眼中的2018年七大教育科技趨勢
※阿里巴巴大數據之路-數據模型篇
TAG:大數據 |