数据仓库ETl工具箱

《数据仓库ETl工具箱》由会员分享，可在线阅读，更多相关《数据仓库ETl工具箱（37页珍藏版）》请在金锄头文库上搜索。

1、第二部分 数据流第二部分 数据流 抽取抽取 一旦开始了数据仓库项目 你就会很快意识到 集成整个企业中所有不同的系统来得到 数据仓库可用的状态是一个真正的挑战 没有数据 数据仓库就是无用的 集成的第一步就 是成功地从主要的源系统抽取数据 流程检查流程检查 规划与设计 规划与设计 需求需求 现状现状 架构架构 实现实现 测试测试 发布发布 数据流 抽取数据流 抽取 清洗清洗 规格化规格化 提交提交 本书的其它章节主要集中在转换和加载数据到数据仓库 本章的重点是为项目建立访问 需要的源系统的接口 每一数据源都有不同的特点需要分别管理 以便为 ETL 过程有效的 抽取数据 随着企业的发展 需要建设或者

2、继承多个不同的计算机系统来帮助公司运作他们的业 务 销售系统 库存管理 生产控制 总帐系统 这个列表还在不断增长 更糟糕的是 不但这些系统是分离的且产生于不同的时间 而且他们经常是在逻辑上和物理上不兼容 ETL 过程需要有效集成不同的系统 数据管理系统 操作系统 硬件 通信协议 在开始创建抽取系统之前 需要一份逻辑数据映射 它描述了那些提交到前台的表中原 始源字段和最终目标字段之间的关系 该文档将贯穿 ETL 系统的始终 我们将在本章第一 部分介绍如何创建逻辑数据映射 本章第 2 部分列举了可能经常遇到的各种源系统 我们将 深入研究每一种源系统 以便选择正确的处理方法 本章结束部分介绍了变化数

3、据和删除数据的捕获这一主题 15 年前我们还认为数据仓 库是永恒不变的 它是一个一次性写成的数据大库 随着这些年的丰富经验的积累 我们现 在知道数据仓库经常需要修改 纠错和更新 本章的变化数据捕获抽取技术只是这一复杂问 题解决的第一步 在后续的提交和操作章节中 仍将继续这一变化数据捕获主题 第第 1 部分 逻辑数据映射部分 逻辑数据映射 在物理实施之前如果没有仔细地规划结构将会是一场灾难 正如任何其它形式的建筑物 一样 在敲击第一个钉子前必须拥有一个蓝图 在开始开发一个单一的 ETL 处理前 确保 你拥有合适的文档 以便该处理与已有的 ETL 策略 过程和标准在逻辑上和物理上保持一 致 流程检

4、查流程检查 规划与设计 需求规划与设计 需求 现状现状 架构架构 实现实现 测试测试 发布发布 数据流 抽取数据流 抽取 清洗清洗 规格化规格化 提交提交 逻辑数据映射描述了 ETL 系统中起点和终点之间的关系 物理之前设计逻辑物理之前设计逻辑 直接跳到物理数据映射会浪费宝贵的时间 并将无法文档跟踪 这一节描述如何开发逻 辑的 ETL 过程并使用它来制订出物理 ETL 执行流程 在开始任何物理 ETL 开发之前 确定 以下的步骤已经完成 1 有一个规划 这个 ETL 过程必须用逻辑的和文档化的形式表示出来 逻辑数据映射 由数据仓库架构师提供 并且它是为 ETL 团队创建物理 ETL 作业而制定

5、的 该文档有时会 作为数据流报告 逻辑数据映射是元数据的基础 随后将提交给测试员来保证数据质量 并 且最终将提交给最终用户来详细描述在源系统和数据仓库之间到底做了些什么 2 确定候选的数据源 从最高级别的业务对象出发 确定你认为将支持业务人员进行 决策的可能的候选数据源 并且确定这些源中你认为对最终用户的数据很重要的特定的数据 元素 这些数据元素将成为接下来的数据评估步骤的输入 3 使用数据评估工具分析源系统 源系统中的数据必须在数据质量 完整性和适合使 用方面进行仔细检查 根据于你的组织结构 数据质量可能是或者不是由 ETL 小组负责 但是这个数据评估步骤必须由对最终使用数据仓库的决策者的需

6、求有一定了解的人来负责 每一个源系统的数据都必须进行分析 任何监测到的异常数据都必须用文档记录下来 对任 何进入数据仓库的数据都必须按照适当的业务规则进行修正是最好的选择 你必须要一直关 注项目在这个阶段就停下来的可能性 如果数据不能支持业务目标 这个时候就要发现 在 第四章中将更多的探讨数据评估 4 接收数据线和业务规则的遍历 一旦源数据完成数据评估步骤的质量保证并且理解 了最终的目标数据模型 数据仓库架构工程师和业务分析师必须和 ETL 架构工程师及开发 者一起完成为抽取 转换和加载的数据仓库的主题域的整个数据线和业务规则 并且最好他 们理解这些规则 完全的理解这些数据线和业务规则是几乎不

7、可能的 因为那样 ETL 小组 必须遇到所有的数据实际问题 但这一步骤的目标是提交尽可能多的知识给 ETL 小组 数 据评估步骤必须创建 ETL 特有的业务规则的两个子类 4a 在数据清洗步骤中需要进行改造的数据 4b 对分离的数据源的维度实体和可度量的数字事实强制一致性来获得标准的结构 5 充分理解数据仓库数据模型 ETL 小组必须充分理解数据仓库的物理数据模型 这 种理解包括维度模型的概念 仅仅理解基本的表到表之间的映射是不够的 开发小组必须对 如何使维度 事实及其他维度模型中的特定表一起发挥作用来实施一个成功的 ETL 解决方 案有好的理解 切记 ETL 系统的主要目标是用最有效的方式将

8、数据送给最终用户工具 6 验证计算和公式的有效性 与最终用户一起校验任何在数据链中任何指定的计算 这个规则来源于纽约市建筑行业的谚语 测两次 切一次 正如你不想得到一座用错误尺 寸的材料造成的摩天大楼 你同样不希望在数据仓库中部署不正确的度量指标 在 ETL 过 程中花时间以错误的法法编码之前 确保你的计算公式都是正确的将是非常有用的 逻辑数据映射内部逻辑数据映射内部 在深入你将遇到的不同的数据源细节之前 我们需要研究逻辑数据映射文档的实际设 计 该文档包括整个企业针对数据仓库源系统的数据定义 目标数据仓库数据模型 以及从 原有格式到最终目的转换所需要的完全数据操作 逻辑数据映射的组成逻辑数据

9、映射的组成 逻辑数据映射 见图 3 1 通常用一个表或者电子表格格式来表示 它包括以下特定的 组成部分 目标表名称 数据仓库中出现的物理表名称 目标列名称 数据仓库表中的列名称 表类型 表示这个表是事实表 维表或者子维表 支节 SCD 缓慢变化维 类型 对维表 这个部分表示是类型 1 类型 2 或者类型 3 的 缓慢变化维 这个指标对维表中的不同的列可以是不同的 比如在客户维中 名字可能属于类型 2 保留历史信息 而姓可能属于类型 1 覆 盖 这些 SCD 类型将在第五章展开详细探讨 源数据库 源数据所在的数据库实例的名称 这里通常是指连接数据库所需的连接 字符串 如果出现在文件系统中 它也可

10、以是一个文件的名称 这时 还需要包含 这个文件的路径 源表名称 源数据所在的源表的名称 很多时候需要多个表 这时 只需将生成目 标数据仓库相关表的所有表简单列出即可 源列名称 生成目标所需的相关列 简单的列出装载目标列需要的所有列 源列之 间的关联在转换部分记录 转换 源数据与期望的目标格式对应所需的详细操作 这个部分通常用 SQL 或者 伪代码来编写 逻辑数据映射中的列有时是组合的 比如 源数据库 表名称和列名称可能被组合在一 个源列中 这个组合列的信息可能用原点来分隔信息 如 ORDERS STATUS STATUS CODE 如果不考虑格式 这个逻辑数据映射文档的内容已经把进行有效的规划

11、 ETL 过程的所有的 关键的信息都提供了 逻辑数据映射中的某些部分看起来很简单并且很直接 然而 当仔细研究的时候 该文 档就会揭示许多 ETL 小组可能忽略的隐藏的需求 这个文档的主要的目标是为 ETL 开发者 提供一个清晰的蓝图 它精确的说明可以从 ETL 过程获得什么 这个表必须清晰地描述在 转换过程中包含的动作流程 不能有任何疑问的地方 看一下图 3 1 图表图表 3 1 逻辑数据映射 逻辑数据映射 仔细观察这个图 你可能会注意到一些注意事项 如果它们没有被关注 可能会引起许 多故障诊断和调试的工作甚至最终延误这个项目 比如 你可能注意到 STATE 在源和目标 中的数据类型已经从 2

12、55 字符转换为 75 字符 尽管数据分析文档可以支持数据范围的减小 但将来创建任何大于 75 字符的值时 就有可能丢失这些数据 而且 一些 ETL 工具实际上 可能终止或者使整个包含这些数据溢出错误的过程失败 请注意 STATE 的转换说明没有明 确定义这一数据转换 转换是隐含的 根据定义 不应该有一个明确定义的账户是隐含转换 的 隐含转换在破坏你的处理流程方面是常见和臭名昭著的 为了避免不幸的发生 ETL 小组必须假定对这些类型的隐含数据转换都负责任地进行了明确的处理 ETL 工具包通常持续跟踪这些隐含的数据转换并提供报告来标识任何的这种 类型的转换 工具包通常持续跟踪这些隐含的数据转换并

13、提供报告来标识任何的这种 类型的转换 表类型给了我们数据加载过程执行的次序 先是维表 然后是事实表 与表类型一起 加载维表过程 SCD 类型显得至关重要 正如我们在这一章的前面所解 释的 表结构的本身无法揭示缓慢变化维的策略是什么 错误地解释缓慢变化维策略将引起 数周开发时间的浪费 在开始开发加载过程之前 需要清楚地了解哪些列需要保留历史信息 以及如何获取历史信息所需的策略 这个列的值随着时间的推移可能发生改变 通常在单元 测试的时候 当你第一次挑选用户来观察数据仓库中的数据时 他们看到了不想得到的结果 即使数据建模者极其努力的尝试 SCD 的概念还是很难向用户表达 并且一旦他们开始进 行维度

14、的加载时 他们总是想要与你的 SCD 策略背道而驰 这种需求是很常见的 这需要 数据仓库项目经理来处理并改变管理流程 映射中的转换是这个流程中的小阶段 这里是技术性好的开发者首先关注的 但你必须 迫使自己不要只集中精力在编码上 在进入转换之前要仔细检查整个映射 这个转换可能包 含了整个解决方案或者根本就什么都不是 最常见的 转换可能用 SQL 来表示 SQL 可能 是也可能不是完整的语句 通常 它是那些不能在映射用其他元素表达的代码段 比如 SQL 中的 WHERE 子句 在其他时候 转换也可能是一种方法 没有特殊的 SQL 只有普通的 英语说明 比如从一个平面文件进行预加载 或者基于数据库之

15、外的标准进行加载转换 或 者拒绝已知的异常数据到一个拒绝文件中的指导性说明 如果转换是空的 这说明映射是直 接从源到目标的 没有任何转换的需求 以上是逻辑数据映射的全部内容 在开始任何实际的编码开始之前和 以上是逻辑数据映射的全部内容 在开始任何实际的编码开始之前和 ETL 开 发者一起对文档做一个全面的走查 开 发者一起对文档做一个全面的走查 使用工具设计逻辑数据映射使用工具设计逻辑数据映射 一些 ETL 和数据建模工具能直接抓取逻辑数据映射信息 人们很自然的想要在这些工 具中直接表示数据映射 输入信息到工具中使得我们可以共享元数据 这是不错的选择 但 在写信息的时候 并没有说明与逻辑数据映

16、射相关的适当的数据元素的标准 在各种工具中 可用的实际元素差别很大 正如数据仓库中的元数据标准是成熟的一样 对逻辑数据映射中 的元素定义也应该建立一个标准 建立元数据标准将使得这些工具对这一目的变得更加一致 和可用 你要调查你当前的工具包对存储逻辑数据映射来说是否可用并充分利用已有的任何 功能 然而 如果你的工具没有实现所有你需要的元素 你将不得不把逻辑数据映射放在不 同的地方 这使你的维护工作变成一件非常麻烦的事件 请密切关注各种产品在这方面所做 的改进 创建逻辑数据映射创建逻辑数据映射 数据仓库的成功主要来源于这样的情形 所有的数据放在一个逻辑位置 使用户可以执 行交叉功能分析 在后台 ETL 小组无缝的整合和转换分散的无组织的数据并使它看起来 好像从一开始就在一起的一样 数据仓库成功的主要标准之一是它存储的数据是干净的和一 致的 统一的数据存储需要对每一个源系统有相当深入地了解 对数据源中的数据甚至源系 统本身理解的重要性常常在 ETL 的项目规划阶段被忽略和低估 在源系统得到确认和分析 之前完整的逻辑数据映射是不存在的 源系统分析通常分为两个主要阶段 数据发现阶段 异常检测阶段