ETL系列专题 1——DW/BI的基石
2013-06-15 17:57
232 查看
ETL系列专题 1——DW/BI的基石
Warren
zqw_qw@hotmail.com
在DW领域中真的不敢说有什么大的经验,因为之前一起工作的中外同事都不知道要比我高深多少。如果说他们是太平洋,我充其量就是我现在身边的这杯水,还被我喝掉了半瓶!
开始想写时还真不知道写点什么?那就索性先写点ETL的东西吧,该系列将主要介绍Kimball ETL架构理论,期间会加入笔者的一些拙劣想法或经验。
ETL系统可以成就数据整个DW/BI系统,同样也可以摧毁DW/BI系统。虽然ETL系统是“后台”活动的,不与终端用户直接交互,但是ETL系统的开发部署与运维占据了整个DW/BI系统的70%的资源!ETL系统绝对不是字面上定义的那样从源系统取出数据然后加载到DW的简单行为。相反它具有很多附加的功能,比如:
1、
删除错误数据,修正缺失数据
2、
提供可信的量度数据
3、
跟踪业务数据流
4、
校正多系统中的不一致性
5、
使终端应用用户更容易使用数据分析业务
ETL系统即简单又复杂,为什么这么说呢?简单到好像我们从E-T-L字面理解的那样简单,说其复杂,是指在E->T->L这条路上,更多的ETL架构师和开发实施者会做更多精细的工作(统计,日志,异常处理,监控报警等等),这些工作的多少,分化的粒度则取决于实际情况:数据源的多少,数据奇异程度,业务需求,现有的软件或工具,以及最终的展示应用等等。没有最精细,只有更精细,但是笔者认为“点到为止”地满足各种需求(业务需求,扩展需求,性能与可运维需求…),是恰倒好处的架构设计。这里建议了解一下ETL
38个子系统的阐述,其实我们在ETL架构实施过程中,不知不觉地使用了这些子系统,只是我们没有像Kimball那样把它们归纳总结下来,或者是我们的ETL系统都是按照Kimball的总结设计的,笔者更倾向于后面的原因。
ETL的设计开发工作应该如何展开呢?
ETL 团队必须深刻了解业务与业务需求共进取,同时必须弄清数据源的数据格式和缺陷程度,熟悉现有的业务系统,强化和现有业务团队的协同工作的技能,时刻关注用户的需求变更。以及考虑ETL处理窗口时间如何设定等等。
两条主线一定要在习惯上形成:计划与设计主线和数据流主线。从高层次上考察两条主线,它们在流程上是高度相关的和吻合的。
该主线可分为四步骤如下
一、业务需求与实际状况分析,应主要包括:
1、业务需要
2、数据源状况分析,数据质量考察
3、可行的需求项
4、数据延迟容忍度
5、数据集成边界
6、归档需求
7、终端用户技能状况
8、终端应用程序
9、现有软硬状况
二、架构
1、ETL工具,自制编程还是选择ETL供应商
2、批量加载还是流加载
3、任务之间的依赖关系,水平依赖还是垂直依赖
4、DQ
5、异常处理
6、ETL调度
7、ETL
的Rerun和Restart
8、元数据
9、安全管理
三、ETL实现
1、软硬件
2、编码规范
3、文档规范
4、质量检查
四、测试与发布
1、测试环境:SIT,UAT,Production
2、测试软件/工具
3、交付流程控制
4、系统备份
5、系统调优
抽取的主要工作:
1、
读取数据源数据模型
2、
连接数据源,访问数据
3、设置抽取时间
4、获取变更数据
5、Staging抽取数据到磁盘
清洗:
1、
建立元数据为基础的数据质量描述数据结构
2、
执行数据业务规则验证数据
3、
Staging清洗的数据到磁盘
转换:
1、
业务术语统一转换
2、
统一量度和KPI
3、
标准国际化
4、
去重
5、
Staging 转换的数据到磁盘
数据交付:
1、
维度数据交付
2、
事实数据交付
3、
Staging 交付数据到磁盘(DW/DM)
再次回到数据流的主线图形上,这四个基本步骤均被包含在ETL操作过程中,ETL操作流程包括如下功能:
1、
调度ETL
2、
执行ETL任务
3、
异常处理
4、
Rerun 和 restart
5、
质量检查
6、
发布
7、
运维
从数据流的各个步骤的工作内容来看,似乎ETL的工作更符合数据建模的工作,因为每个步骤都更多地涉及到数据结构的转变,但是在DW/BI中的数据模型更多指的是DW/DM的数据模型师的工作,然而实际工作中ETL架构设计者和DW模型师通常会是相同的人或团队!如果ETL架构者不了解DW/DM的数据模型,很难想象架构设计的ETL系统能很好地满足数据处理工作。
Warren
zqw_qw@hotmail.com
在DW领域中真的不敢说有什么大的经验,因为之前一起工作的中外同事都不知道要比我高深多少。如果说他们是太平洋,我充其量就是我现在身边的这杯水,还被我喝掉了半瓶!
开始想写时还真不知道写点什么?那就索性先写点ETL的东西吧,该系列将主要介绍Kimball ETL架构理论,期间会加入笔者的一些拙劣想法或经验。
什么是ETL
ETL(Extract-Transform-Load),即抽取、转换和加载。即从源系统(业务系统)抽取数据,加以转换,并加载到DW或DM。为什么说ETL系统是DW/DM(以下均称为DW)基石?理由是:数据仓库系统中数据质量,数据一致性,多数据源的统一集成,最终交付数据给决策应用层等工作均有ETL系统完成,而这些素质正式数据仓库必备的属性,这些素质任何一项不能满足,数据仓库系统是不健康的,是不足以被信赖用以商业决策支持的。ETL系统可以成就数据整个DW/BI系统,同样也可以摧毁DW/BI系统。虽然ETL系统是“后台”活动的,不与终端用户直接交互,但是ETL系统的开发部署与运维占据了整个DW/BI系统的70%的资源!ETL系统绝对不是字面上定义的那样从源系统取出数据然后加载到DW的简单行为。相反它具有很多附加的功能,比如:
1、
删除错误数据,修正缺失数据
2、
提供可信的量度数据
3、
跟踪业务数据流
4、
校正多系统中的不一致性
5、
使终端应用用户更容易使用数据分析业务
ETL系统即简单又复杂,为什么这么说呢?简单到好像我们从E-T-L字面理解的那样简单,说其复杂,是指在E->T->L这条路上,更多的ETL架构师和开发实施者会做更多精细的工作(统计,日志,异常处理,监控报警等等),这些工作的多少,分化的粒度则取决于实际情况:数据源的多少,数据奇异程度,业务需求,现有的软件或工具,以及最终的展示应用等等。没有最精细,只有更精细,但是笔者认为“点到为止”地满足各种需求(业务需求,扩展需求,性能与可运维需求…),是恰倒好处的架构设计。这里建议了解一下ETL
38个子系统的阐述,其实我们在ETL架构实施过程中,不知不觉地使用了这些子系统,只是我们没有像Kimball那样把它们归纳总结下来,或者是我们的ETL系统都是按照Kimball的总结设计的,笔者更倾向于后面的原因。
ETL的设计开发工作应该如何展开呢?
两条主线同时进行
这里再次强调DW/BI的实施过程中一定要高度重视ETL。不要轻视ETL,要从理论上认识到设计一个成熟的,稳定的,健壮的ETL系统是一项非常挑战的工作。绝对不是我们的团队成员精通了DataStage,Informatica等ETL工具或者精通了SQL,就可以开发出优质的ETL系统的。ETL 团队必须深刻了解业务与业务需求共进取,同时必须弄清数据源的数据格式和缺陷程度,熟悉现有的业务系统,强化和现有业务团队的协同工作的技能,时刻关注用户的需求变更。以及考虑ETL处理窗口时间如何设定等等。
两条主线一定要在习惯上形成:计划与设计主线和数据流主线。从高层次上考察两条主线,它们在流程上是高度相关的和吻合的。
计划与设计
“如果没有计划,就是在计划着失败”!该主线可分为四步骤如下
一、业务需求与实际状况分析,应主要包括:
1、业务需要
2、数据源状况分析,数据质量考察
3、可行的需求项
4、数据延迟容忍度
5、数据集成边界
6、归档需求
7、终端用户技能状况
8、终端应用程序
9、现有软硬状况
二、架构
1、ETL工具,自制编程还是选择ETL供应商
2、批量加载还是流加载
3、任务之间的依赖关系,水平依赖还是垂直依赖
4、DQ
5、异常处理
6、ETL调度
7、ETL
的Rerun和Restart
8、元数据
9、安全管理
三、ETL实现
1、软硬件
2、编码规范
3、文档规范
4、质量检查
四、测试与发布
1、测试环境:SIT,UAT,Production
2、测试软件/工具
3、交付流程控制
4、系统备份
5、系统调优
数据流
数据流主线,对于ETL开发者来说是非常亲切的流程,最简单的可以用E-T-L流程。大致流程如下:从ETL操作流程上比较,数据流主线与计划设计主线相同,均为4个步骤。抽取的主要工作:
1、
读取数据源数据模型
2、
连接数据源,访问数据
3、设置抽取时间
4、获取变更数据
5、Staging抽取数据到磁盘
清洗:
1、
建立元数据为基础的数据质量描述数据结构
2、
执行数据业务规则验证数据
3、
Staging清洗的数据到磁盘
转换:
1、
业务术语统一转换
2、
统一量度和KPI
3、
标准国际化
4、
去重
5、
Staging 转换的数据到磁盘
数据交付:
1、
维度数据交付
2、
事实数据交付
3、
Staging 交付数据到磁盘(DW/DM)
再次回到数据流的主线图形上,这四个基本步骤均被包含在ETL操作过程中,ETL操作流程包括如下功能:
1、
调度ETL
2、
执行ETL任务
3、
异常处理
4、
Rerun 和 restart
5、
质量检查
6、
发布
7、
运维
从数据流的各个步骤的工作内容来看,似乎ETL的工作更符合数据建模的工作,因为每个步骤都更多地涉及到数据结构的转变,但是在DW/BI中的数据模型更多指的是DW/DM的数据模型师的工作,然而实际工作中ETL架构设计者和DW模型师通常会是相同的人或团队!如果ETL架构者不了解DW/DM的数据模型,很难想象架构设计的ETL系统能很好地满足数据处理工作。
总结
本章强调了ETL在数据仓库/商业智能系统中的重要地位,以及架构设计ETL系统的两条主线,两条主线同时存在相互照应。并介绍了两条主线各个步骤应完成的相应工作。相关文章推荐
- 必看:DB-ETL-DW-OLAP-DM-BI关系结构图
- DB、ETL、DW、OLAP、DM、BI关系结构图
- 什么是BI、ETL、DW
- DB、ETL、DW、OLAP、DM、BI关系结构图
- DB、ETL、DW、OLAP、DM、BI关系结构图
- [分享]微软BI专题-SQL Server BI Development Studio使用技巧系列(一)
- ETL系列专题2——ETL中的数据结构
- ETL系列专题4——ETL之T
- ETL系列专题6——Load之FactLoad
- BI开发(ETL-DW)
- DB、ETL、DW、OLAP、DM、BI关系
- DB、ETL、DW、OLAP、DM、BI关系结构图
- DB、ETL、DW、OLAP、DM、BI关系结构图
- DB、ETL、DW、OLAP、DM、BI关系结构图
- ETL系列专题5——L之DimLoad
- DB、ETL、DW、OLAP、DM、BI关系结构图
- ETL系列专题3——ETL之E
- ETL利器Kettle实战应用解析系列二 【应用场景和实战DEMO下载】
- SQL2005 BI系列课程
- Exchange2013专题系列(四)NLB网络均衡的实现