从10年前的数据仓库到当前的大数据平台，ETL也须要与时俱进，这里来谈谈我的的理解，若是你在考虑建设新的企业级ETL平台，能够做为参考：shell
定位的从新认识
ETL做为传统数据仓库的底层技术组件，主要是服务于数据采集的，所以，通常数据流动每每是单向的，但在新的时期，咱们须要拓展其概念的内涵，从ETL升级到交换，以适应更多的应用场景，这是大数据平台规划人员特别须要考虑的。数据库
但咱们看到，在不少企业PaaS平台级的研发中，并未将交换其归入产品的核心功能，为何？架构
ETL出来之时，的确适应了数据仓库建设的须要，毕竟系统建设之初，数据采集和整合为王， 技术驱动业务，没什么好说的。运维
但在大数据时代，须要与时俱进，基于笔者的实践，感受开放的交换平台将是将来标配，缘由有如下几个：分布式
从业务角度讲， 随着数据应用的日益丰富，不一样平台、系统的相互大批量数据交互成常态，仅仅知足于采集数据已经不适应业务须要，还须要可以为数据的目的端落地提供支撑，咱们须要一个端到端的更适应业务须要的交换系统，而不是只管本身一亩三分地的ETL系统， 好比浙江移动的平常的数据交换应用早就超过了简单的数据采集需求，业务始终为王。工具
从技术角度讲，ETL作必定的扩展能够升级为兼具交换能力，二者有传承，能够实现平滑过渡，不是有谁没谁的问题，咱们好不容易搞了PaaS级的ETL，但交换却要考虑用另外一个工具实现，同时将来大数据平台组件将异常丰富，相互之间的数据交换将是常态，必需要有个PaaS级的交换工具知足这种要求，这是个趋势性的东西。oop
从管理角度讲，不管是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人，从大数据的角度讲，理解它又是有必要的。