数据仓库之ETL
Posted 数据仓库与分析
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了数据仓库之ETL相关的知识，希望对你有一定的参考价值。
本文是数据仓库系列的第一篇，以后这个系列也会写下去，毕竟是我主要的工作方向。数据仓库系列计划写仓库建设的几个大的方面包括ETL，模型建设，指标建设与管理，应用集市开发，数据仓库框架设计等，有些是知识的总结，有些是经验的归纳，当然有些也是好的实践的分享。
什么是ETL
ETL就是Extraction，Transformation，Loading；也就是抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，肩负着破解企业数据孤岛的重任，同时为企业的决策提供分析依据， ETL是BI、数据仓库重要的一个环节。
ETL常见的工具
Kettle
Kettle作为开源的ETL工具，很多公司使用，可以根据自己的需要进行优化开发；
Talend
无使用经验，也没有研究过，当然也没有精力研究。
Informatica
Informatica作为传统老牌ETL工具，需要收费，而且价格比较贵，优点是服务稳定，性能好，目前使用看来Informatica比Kettle好很多。
除了上面的几个常见的软件，还有很多ETL工具，包括采集日志的Logstash，Fluentd；还包括sqoop，
DataX，还有很多公司自有开发的具有ETL功能的工具。
ETL采集推送方式
源推送，目标获取的方式
此种方式适用于大型银行等需要大量数据交换的公司；数据推送成功后可以写一个标志位告诉大家数据可以获取了，目标获取方发现标志后即可开始加载。
在源的采集推送，目标的加载获取的中间还有一个系统，暂且称之为数据交换管理吧！数据交换管理肩负着数据的转码，数据的交换和管理所有表结构的重任。
这里的管理所有表结构不是通过技术实现，而是通过管理来实现的，如果目标系统发现数据交换管理给的表结构不一致，也就是数据加载报错，那么就算一次源系统导致的生产事故。
这种方式的问题在于，如果数据有问题，则需要源系统的支持。
ETL工具进行集中采集推送的方式
这种方式采用在源系统与目标系统中间的数据交换管理系统负责数据的采集和推送。
这种方式对数据交换管理来说调度稍微复杂一点，而且表结构也无法管理。这样以后开发过程中会因为表结构无法管理而部分失控。
两种方式比较
两种方式各有优缺点，大型集团业务线很多，数据量很大的不适合集中采集推送，一般大型集团作业都是十万，百万级；
目前我司采用的是集中采集推送，而且作业数到万级。因为集中采集推送毕竟依靠的是集中的服务，虽然也可以分布式的部署，但是开发，部署，运维的工作量很大，而且这一块的工作比较重要，对时效性有一定的要求，对下游影响大。
Informatica集中采集推送实践经验
使用文件交换
informatica支持采集各种源和推送各种目标，我司在实践的过程中批量作业采用文件交换的方式。这种文件交换的方式就是采集作业采集的信息生成文件，推送作业根据采集的文件进行目标推送，这样做的目的有两个：
解决网络问题，我司因为监管要求，网络是隔离的，也就是部分源和目标的网络不通，无法直接的源到目标的采集推送；所以采用的是落地文件的方式，文件落地到NAS盘，特别申请一个全网通的NAS服务器，也就解决了公司的网络隔离问题。
解决作业复用问题，一个系统的采集作业可能多个系统需要，如果中间不落地成文件，则需要多次的采集，对源系统的压力比较大；采用文件落地的方式，一次采集多次推送。
作业目录管理
一般根据作业的采集或者推送的源不同，分目录对作业进行管理。比如一个推送系统一个目录，所有的采集放在一个目录，定时调度也使用一个目录。
作业初始化
因为使用Informatica自带的调度，在调度之前有一个调度初始化，初始化分为如下几个步骤：
生成新的参数文件
生成初始化文件比如ini_*.ok等
删除上个批次的无用参数文件
生成作业所需要的文件夹
生成wf调用命令主函数
调度管理
调度分两部分，一个是定时，一个是标准文件触发；
定时作业使用scheduler做定时，根据制度作业跑的时间来进行调度运行。
文件触发比较复杂，首先有一个作业不停的在后台读取标志，如果标志到了后生成一个Clear_*.ok文件；采集和推送作业安排在一个作业调度，设置一个启动调度的时间，作业启动后，如果Clear_*.ok没有到则一直等待，如果到了就跑采集，采集完后生成一个采集作业名同名的OK文件；同理推送也是一样，采集成功的OK文件未到就等待，到了就运行。
Informatica集中采集推送碰见的问题
我司使用的Informatica工具作为数据交换管理系统，个人非常推崇Informatica的服务，非常稳定；但是在Informatica的使用过程中也存在一些问题：
新的采集推送作业界面开发缓慢，不适合大批量的作业开发；
新加字段开发麻烦，尤其是字段变更比较多的情况；
批量调度需要仔细优化，需要额外增加源分析与影响分析，比如采集报错如何快速的推送到下游；
作业的清理非常麻烦；
定制化的开发文档支持不够；
Informatica集中采集推送问题方案
开发自动开发平台
使用Informatica的javaApi开发生成作业XML，这部分需要根据各个公司的不同而定制开发；这里需要吐槽一点的是API的文档写的一般。
元数据整理
自动开发需要读取元数据支持，因为网络或者异构的数据库的原因，需要开发一个类似元数据系统的API，方便使用；
这里不仅需要管理各个表的表结构，自动生成建表语句，还有表的权限管理和查询，infa链接的管理也是很重要的。
影响分析与调度管理
wf里面的关系错综复杂，这里需要梳理清晰，知道这个作业由什么作业调度的，推送了哪些下游；
监控管理与调度
作业运行的情况，做了多少作业，给某个系统推送了什么作业等，相关的统计信息在这里都是一目了然。
除了查询还可以调度，也是使用APi的调度方法，调度可以精确到wf或者session级别，可以随意的上传相关的参数。
待解决的问题
作业自动上传
API生成的XML文件部分可以自动上传，但是部分不可以，不可以自动上传的主要是多目录的作业，比如一个作业的source和mapping不在一个目录的情况不能自动上传
作业的快速清理
作业清理很不友好，我司infa使用了大几年，很多作业因为各种原因需要下掉的，不然作业越来越多，这一块目前看来纯手工的操作，比较麻烦。
表结构的变动
目前最怕的就是表结构的变动，因为这种频率太大了。不管是管理的原因还是开发的原因，表结构变动的频率还是很大的，对于INFORMATICA来说就比较头疼，没有一个像自动开发的解决方案。
以上是关于数据仓库之ETL的主要内容，如果未能解决你的问题，请参考以下文章