数据仓库ETL之数据交换

从1990年数据仓库之父比尔·恩门（Bill Inmon）提出数据仓库的概念，ETL作为数据仓库的核心组件，在传统的数据仓库中是服务于数据采集，数据处理，大数据时代来临，对ETL的理解也由【抽取、转换、加载】升级到【交换】这个层面。如果你也考虑建设企业级数据仓库可以作为参考。

0x0 ETL之定位

业内多数知名数据仓库解决方案提供方利用公司的自我研发的ETL工具及数据平台从生产系统接入数据源，在库内进行数据转换工作，与其他三方厂家（乙方）一样，自顾一亩三分地，完成了端对端的数据支撑，然而对于甲方而言，各个厂家的端的数据采集无疑是对生产系统的增加多倍压力，另外厂家之间的数据交换也是常态。

建设数据仓库的模式有由上而下以及由下而上两种模式，对于大企业而言，各个部门的运营模式、业务方向均有千差万别，部门大多建设自己的数据仓库，公司从各个部门建设的数据仓库之上建立总的数据仓库。在我们公司，部门之间数据ETL，一方面因业务模式，另一方面各部门数据平台产品多样化，ETL大多采用ftp、rsync这种文件数据传输方式，日志采集则使用DataStream或flume等。我们通常面临企业之间的数据交互，政府部门的数据推送，即便是一个部门内部数据的交换也是常态，数据共享有利于大数据生态发展，离线平台需要生产系统的数据进行计算，生产系统也需要离线平台的数据支撑。数据交换作为ETL一个升级模式成为企业级数据仓库建设的必然。

0x1 交换平台的产生

大多大数据从业人士也认识到数据交换，很多厂家也认识到了ETL模式的与时俱进，阿里的数据工场，亚信的云化交换平台，华为的云化交换平台以及我们的猛犸大数据平台应运而生，大数据交换平台服务于企业（部门、系统）数据交换，数据交换对于用户而言都是透明的，不仅满足传统的ETL功能，同时需要满足动态扩展。
大数据形势下，互联网数据仓库较之传统的数据仓库平台有如下特点：

为适应数据仓库的发展，那么数据交换平台应该具备哪些能力呢？小编认为可从如下几个方面进行阐述，数据采集能力，数据存储能力，数据管理能力，数据计算能力，平台开放能力，作业调度能力。

(1) 数据采集能力
交换平台应支持对表（关系表，k-v表）、文件（结构化、非结构化）、消息、数据流等多种数据形式的支持，同时需支持多样化的采集方式：实时增量流式（flume、DataStream等），消息队列（nsq、Kafaka）等主流技术。由于技术繁杂，种类繁多，选取适合自己业务模式的工具形成组件化利于跨平台部署，这是数据采集应考虑的。（PS：实际上对于日志流式收集的形式通常是效率高，高响应，但也处于不稳定的，易丢失数据等现状。）

(2) 数据存储能力
互联网的数据【大】是毋庸置疑的事实，传统RDBMS的核心设计思想基本上是30年前形成的，在数据仓库领域有相当权威的公司有Teradata、IBM、Oracle、SAP等这里公司均拥有自身数据存储系统以及软硬一体化的大数据解决方案，支持动态扩展的能力，Teradata、Aster Data、GreenPlum都是MPP存储架构，支持PB级别存储（前两者属于商业数据库，GreenPlum开源），这些均是关系型数据库，我们最熟悉的Hadoop是属于SMP架构，支持非结构化、半结构化、结构化数据存储，数据存储平台的选型根据企业的业务模式选定。

(3) 平台管理能力
数据管理：数据的交换忌讳数据冗余，浙江移动大数据中心使用亚信云化交换平台出现了这样的一个场景，厂家A需要生产系统中数据表T1部分字段,，厂家B需要生产系统中数据表T1的所有字段，另有特殊情景长家C需要表中的字段与厂家A有交叉字段现象，生产系统为给三个厂家同时供数，造成了大量数据冗余，空间有效利用率60%不到。

多租户管理：数据交换本身的一个概念就是交换，意味着多租户，平台是开放的，面向多个部门甚至多个企业，租户可以灵活创建自己的作业体系，提出相应的数据需求，进行自主管理和配置，跨系统或者跨部门的数据请求开放给用户，开启有效的需求管理体系。

作业管理：ETL平台所需维护的细节繁多，如果交互的接口管理一塌糊涂，比如繁多的FTP、散乱的Shell脚本、crontab定时任务搞晕了运维人员，一旦人员迭代，付出的管理成本很大，建立一套完善的元数据管理体系是保障系统正常运作必需的工具。

(4) 数据计算能力

互联网的数据“大”是不争的事实，现在分析一下数据处理技术面临的挑战，近几年见过形形色色的数据仓库，大多使用的自下而上的方式建设，生态数仓中所使用的平台产品多样性，然而传统行业电信也好，银行也好，互联网产品数仓也罢，鲜有PB级别的数仓，面对的用户量几千万，对应的数据是几百TB，数据量少怎么样的建设方案都是无所谓的，当面对10亿级别的用户，PB级别的数据时，如何满足数据计算？如何适应多种数据平台的接入？

数据交换平台需具备强大的数据计算能力，支持常见的分布式计算模型，以实现数据的预处理（格式转换【例如lzo转换成HFile】，空值处理、数据压缩等）以及常见的计算函数（窗口函数，中位数计算、时序计算、图计算等）。

(5) 平台开放能力
能够对外输出数据，这是企业级的交换平台所应具备的基本能力，数据开放并不意味着谁都可以随意获取数据，放弃数据安全，数据开放表示数据共享，满足企业的各项业务需求，根据部门的具体需求，申请已开放的数据，数据安全保障。

数据交换平台所应支持的不仅是传统的数据开放，更应具有元数据开放、计算能力的开放，丰富的API提供，既然无法满足所有的个性化需求，那就应有开放的API为其他系统无缝衔接，单纯的数据导出已无法满足业务的发展。

(6) 作业调度能力
调度功能是从ETL工具形成初便拥有的，ETL调度工具发展也从最初的crontab衍生到现在的调度平台，业内企业级的调度工具例如国外的Informatica公司的Informatica、Teradata的 ETL Automation、微软的 SSIS、Control-M，国内的有自主研发阿里的Zeus，亚信的 AI-CLOUD-ETL，华为研发的云-ETL，网易的nschedule、猛犸等，开源的调度工具有Azkaban，Kettle等。

调度模式是各色各样，有以工作流调度单位，有以作业为调度单位，所支持的作业形式也是多种，脚本形式(shell、python、Perl，ruby)，SQL、Java、MapReduce以及其他组件形式。调度策略也是丰富多样，有时间触发、时间触发、接口通知、手工执行。

实现任务的统一调度，支持动态扩展的作业类型，丰富的调度模式是数据交换平台应具备的。以上所列举的6项能力提出一些常见的体现，构建数据交换平台所考虑的细节非常多。

0x3 交换平台建设最佳实践

很多数据平台提供的是纯粹的数据服务，较少提供Api或元数据服务以满足其他平台的嵌入，业内打造成PaaS级的ETL交换平台屈指可数，技术因素是一方面，业务需求是否需要打造这样一个平台也是其中一个原因，对业务需求的理解，是否具有持续的维护及更新能力又是另一方面。还有一句话是这么说的，规则与灵活怎么取舍？为便于维护可能将主流的需求满足，对于一些个性化的需求则被抛弃，很多公司技术也很强，但打造这样一个ETL交换平台更多的考虑是从用户需求中来，到实践去来，纯粹的为实现功能，大谈性能也未必是一个好的解决方案，业务始终为王。下面设想一个交换平台架构图供参考：

稍作拓展：

rel：http://deletee.top/2017/06/05/edw-data-exchange/