我们需要什么样的ETL?

从10年前的数据仓库到当前的大数据平台，ETL也需要与时俱进，这里来谈谈个人的理解，如果你在考虑建设新的企业级ETL平台，可以作为参考：

一、定位的重新认识

ETL作为传统数据仓库的底层技术组件，主要是服务于数据采集的，因此，一般数据流动往往是单向的，但在新的时期，我们需要拓展其概念的内涵，从ETL升级到交换，以适应更多的应用场景，这是大数据平台规划人员特别需要考虑的。

但我们看到，在很多企业PaaS平台级的研发中，并未将交换其纳入产品的核心功能，为什么？

ETL出来之时，的确适应了数据仓库建设的需要，毕竟系统建设之初，数据采集和整合为王， 技术驱动业务，没什么好说的。

但在大数据时代，需要与时俱进，基于笔者的实践，感觉开放的交换平台将是未来标配，原因有以下几个：

从业务角度讲， 随着数据应用的日益丰富，不同平台、系统的相互大批量数据交互成常态，仅仅满足于采集数据已经不适应业务需要，还需要能够为数据的目的端落地提供支撑，我们需要一个端到端的更适应业务需要的交换系统，而不是只管自己一亩三分地的ETL系统， 比如浙江移动的日常的数据交换应用早就超过了简单的数据采集需求，业务始终为王。

从技术角度讲，ETL做一定的扩展可以升级为兼具交换能力，两者有传承，可以实现平滑过渡，不是有谁没谁的问题，我们好不容易搞了PaaS级的ETL，但交换却要考虑用另一个工具实现，同时未来大数据平台组件将异常丰富，相互之间的数据交换将是常态，必须要有个PaaS级的交换工具满足这种要求，这是个趋势性的东西。

从管理角度讲，无论是ETL，还是系统或应用间的数据交换，管理的对象都是接口，描述的方式没有本质的区别，我们需要用一种工具实现所有接口的透明化统一管理，显然升级ETL是最好的方案，很多企业采集由于ETL工具存在管的还算可以，但交互的接口管理一塌糊涂，比如繁多的FTP搞晕了运维人员，付出的管理成本很大。

二、交换平台的一种架构

以下是勾画的一种数据交换平台的功能架构，供参考。

交换平台除了传统ETL功能， 分布式动态可扩展是必须的，现在云化交换平台产品已经很多了，应该各有千秋吧，特别强调以下几点，：

必须具备多样化数据采集能力，支持对表、文件、消息等多种数据的实时增量数据采集（使用flume、消息队列、OGG等技术）和批量数据分布式采集等能力（SQOOP、FTP VOER HDFS），比基于传统ETL性能有量级上的提升。

必须支持对于业界主流数据库的相互对接能力，包括ORACLE/HIVE/GBASE/IMPALA/ASTER/HBASE等等，要实现这些功能，涉及到互信等众多问题，但对于业务的价值巨大。

必须具备多租户的管理，因为传统ETL可能跟应用无关，统一运维团队配置即可，但交换跟应用强相关，必须要能够授权自主配置，这个时候，多租户管理就变得非常重要。

必须具备能力开放能力，能够对外输出元数据，这个其实是未来对于任何企业级平台的刚性要求，做平台的企业别老想着封闭，包打天下， 比如浙江移动有个统一的数据管理平台，不能由于交换平台的封闭，让数据管理平台废了半条腿，这是企业未来引入技术组件必须考虑的因素。

必须具备可视化快速配置能力，能够提供图形化的开发和维护界面，支持图形化拖拽式开发，免代码编写，降低开发难度，每配置一个数据接口耗时越小越好，比如以前我们采用的老ETL平台一个接口平均配置3小时，这是无法忍受的。

必须具备统一调度管控能力，实现采集任务的统一调度，可支持Hadoop的多种技术组件（如 MapReduce、Spark 、HIVE）、关系型数据库存储过程、 shell脚本等，支持多种调度策略（时间/接口通知/手工）。

三、交换平台的现实挑战

除了BAT，业内真正能打造这类PaaS级的ETL平台屈指可数，因为要实现此类交换平台综合要求其实非常高，除了技术因素，挑战更多来自于需求理解、开放性及持续服务能力，这是我们在实践中碰到的痛点：

客户需求的理解往往是硬伤，很多公司技术的确很强，但由于产品是卖给别人的，自己也不会用，其很难达到BAT产品的境界，未来是BAT的，不是说BAT技术有多强，而在于其产品从实践中走出来，在客户需求理解能力上是大多数公司难以项背的，客户大多数时候并不需要你的技术有多牛逼，快速解决问题就行，但此类产品经常陷入拼性能，列功能，强升级的场景，而忽视本质的东西。

开放性也是很多公司的软肋，随便拿个可视化界面来讲吧， 大多数场景其实需要极简的界面，我们经常哀求能否开放个API出来啊，其他平台无缝集成下行不，但往往无法满足，说不符合产品路线，如果下回有个ETL公司来跟你推销产品，你首先得问一句，能开放元数据接口不？能开放API不？

服务型公司才是未来，一个产品打天下的时代即将过去，未来是服务的时代，甭跟我提一堆概念，谁都无法预测未来，我更关注当下，既然我找你，你就要做好持续服务的准备，一个合理的优化短则一月，多则1-2年，没有哪个客户有耐心。

ETL作为企业搞大数据核心的技术平台，在建设或选择的时候，要考虑的东西其实非常多，大多传统企业在这方面的掌控能力是非常欠缺的，很容易陷入建设的怪圈而效益却很难显现，以为搞了云化就OK了，其实仅仅解决了ETL中很小的一个问题，不被忽悠并理解自己真正想要什么其实很难。

我上面列的那张功能架构图，任何一个点的需求即使要进行确认，投入的精力也是蛮大的， 不全面考虑，死磕到底，最后吃亏的终将是企业自己， 一个小功能的缺失就可能导致ETL的效率的大幅降低，甚至可能推倒重来，留给运维团队的也将是无尽的痛苦。

当然如果企业的数据量不大，那怎么捣鼓都行，其实大多数企业当前并不需要重型的ETL大炮，但对于每个BI人，从大数据的角度讲，理解它又是有必要的。