为什么 ETL 很困难?

工具繁多

从 DataStage到Kettle, ETL 工具覆盖了商业化领域和开源领域, 价格从几十万到免费,起码有几十种选择。
有人要说了,选择多不是一件好事么?如果再早几年,我会同意这是好事,可到现在,我要说 NO!
前面关于决策思维的博文提到一个论点:相比于普通人做出决策,专家是会直接给一种可行方案还是罗列众多方案类比优劣?
答案是前者,也是我反对选择众多是好事这一论点的依据之一。

那么选择多有什么坏处?

基础方案混杂。各公司方案不同,甚至一个公司 ETL 环节也采用不同工具及架构,人才无法公用,维护成本高。
数据项目失败案例远多于成功案例, 项目选型越复杂成功概率越低。大量公司做 BI、做大数据,甚至在没有人懂的情况下招人开工!事实上在数据领域,熟手都清楚一个现象,没有成功案例的人很难做成数据项目。很残忍的现实,但也让那些盲目投入资源跟风做项目的公司考虑冷静下来了。
抬高实施门槛。现在大家都想做数据,进入大数据领域,尤其是有很多不具备该领域经验的公司想要做。那么实施前首先就是选型了,如果从三个产品选一个来做还可行的话,那么要从三十个产品中选型,这个工作本身就阻碍了数据项目的开展!

GUI工具

说到这里反对的朋友更多了,GUI 所见即所得,降低使用门槛,好处一页都写不完,作为一名数据领域从业者,我决然反对,自己都能感觉到火药味。为了论证我的观点,这里要罗列ETL领域那些GUI的罪证了。

ETL 工具的六大问题

工具太大了,卡卡卡!我不是说 SSIS 之类,也不是说 Kettle 相关,我说的是他们所有人……
好用的太贵, 便宜的不好用!
组件式的拖拉开发,性能真的没法起来!尤其是那些依靠组件解决数据变化提取的兄弟们,你们想多了。
我需要一包厕纸而已,你非要给我整个超市。在我蹲之前非得找遍整个超市!大家对比下里面的功能自己使用的比率。
说 GUI 简单好用的,我强烈反对。GUI 好调试么?映射过程报错了大家要怎么办?检查源检查目标也就算了,连映射环节都要排查。除了自己设定的格式类型,还要考虑工具环节自己的转换类型,这不是增加负担么?
部署,我都不想说部署了。一千个任务下来,ETL 工具别谈部署了!这时候有同学开始研究调度,有些关注数据质量,任务数量起来,想什么都是多的,保佑这混乱情况别出岔子就阿弥陀佛了。

ETL 工具阻碍了设计

直接用工具拉数据的项目,认真找找有没有架构设计,有没有项目文档,有没有扩展性考虑,性能考虑?或者简单点,这项目换人可能接手下来么?
数据项目是团队项目,ETL 工具是个人化工具。如果多个成员不能无缝接替工作,对不起,我认为这不是数据项目。哦不对,不算是一个项目。
组件报错是工具问题,转换异常跟自己没关系。工具的 bug 和我真没关系,我项目做得好好的,ETL 工具崩溃了管我什么事?遇到这种情况不说我也知道做法,崩溃了再起来跑一跑嘛,运气好数据就跑出来了。至于数据质量管理是什么这样的问题,就别问出来了。

这里有关于 ETL 的一切
这里有直接上手的 ETL 方案
这里有十年数据解决方案的结晶