1.综合需求
业务需求
在项目将要支持的业务需求定义期间,必须维护一个揭示关键性能指标(KPI)的列表,以及业务用户需要研究某个KPI “为什么”发生变化时,所需要的下钻和跨钻目标。(信息需求)
合规性
改变法律条文和报表需求要求多数组织严格地对待其报表并证明这些报表的数字是准确的、完整的且未被篡改的。当然,受到严格管理的业务的DW/BI系统,例如电讯,会.花费数年时间编辑报表需求。但是金融报表的整体氛围对每个人来说会越来越严格。
数据质量
将那些已经知道的不中意的数据元素记录下来,描述是否与源系统达成共识以便在获取数据之前进行更正。列举数据分析期间发现的那些需要在ETL过程中持续监控和标记的数据元素
安全性
应当将合规性列表扩展,使其包含熟知的安全和隐私需求
数据集成
应当利用业务过程的总线矩阵建立一致性维度(总线矩阵的列)的优先列表。对每个总线矩阵的行进行标注,指明参与到集成过程中的业务过程是否有明确的执行需求,以及是否由ETL小组负责这些业务过程。
数据延迟
数据延迟描述通过DW/BI系统发布给业务用户的源系统数据的速度。显然,数据延迟1需求对ETL架构具有较大的影响
归档与世系
应当记录数据源和归档的中间数据步骤以及保留政策、合规性、安全和隐私方面的约束
BI接口发布
可用的技能
传统的许可证
2.ETL的34个子系统
- 获取:从源系统中收集原始数据并通常在所有明显的数据重构发生之前将收集的数据写到ETL环境的磁盘上。子系统1~子系统3用于支持获取过程。
- 清洗及转换:将获取的源数据通过ETL系统的一系列处理步骤,改进从源系统获得数据的质量。将来自两个或多个数据源的数据融合,用于建立和执行一致性维度和一致性度量。子系统4~子系统8描述了支持清洗和转换工作所需要的结构。
- 发布:物理构建并加载数据到展现服务器的目标维度模型中。子系统9~子系统21提供了将数据发布到展现服务器的功能。
- 管理:以一致的方法管理与ETL环境相关的系统和过程。子系统22~子系统34描述了用于支持ETL系统持续管理所需要的各种部件。
3.获取:将数据插入到数据仓库中
子系统1 数据分析
数据分析是对数据的技术分析,包括对数据内容、一致性和结构的描述。
预先开展数据分析工作!使用数据分析结果设置业务资助人有关现实的开发计划、对源数据的限制、投资更好的源数据获取实践的期望
子系统2 变化数据获取系统
变化系统获取子系统的主要目标:
- 分离变化数据以允许可选择加载过程而不是完全更新加载。
- 获取源数据所有的变化(删除、更新和插入),包括由非标准接口所产生的变化。
- 用变化原因标记变化了的数据,以区分对错误更正和真正的更新。
- 利用其他的元数据支持合规性跟踪。
- 尽早执行CDC(数据获取)步骤,最好是在大量数据传输到数据仓库前完成。
获取源数据变化的方式
- 审计列:
某些情况下,源系统包含审计列,这些列存储着一条记录被插入或修改的日期和时间。这些列一般是在数据库记录被插入或更新时,激活触发器而自动产生的。有时,出于性能方面的考虑,这些列由源系统的应用而不是通过触发器产生的。当这些不是由触发器而是由其他任何方式建立的字段被加载时,一定要注意它们的完整性,分析并测试每一列以确保它们是表示变化的可靠来源。如果发现存在空值,则一定要找到其他用于检测变化的方法。最常见的阻碍ETL系统使用审计列的情况是,当这些字段由源系统应用建立时, DBA小组允许在后端用脚本对数据进行更新。如果这种情况在您的环境中存在,则会面临在增量加载期间丢失变化数据的风险。最后,您需要理解当一个记录被从源中删除时会发生何种反应,因为查询和审计列可能无法获得删除事件。(难点是使用审计列来捕获变化数据情况时,审计列发生丢失情况的处理) - 定时获取
在采用定时获取方法时,通常会选择所有那些建立日期或修改日期字段(这一方法作者说不靠谱,作者说选取建立/修改时间数据来获取变化数据,可能的重启或失败情形会造成数据杂乱或者丢失) - 全差异比较
全差异比较将保存所有昨天数据的快照,并与之进行比较。将其与今天的数据逐个比较,找到那些发生了变化的数据。这一技术的好处是它非常严密:可保证找到所有的变化。明显的缺点在于,多数情况下,采用这一技术对资源的消耗巨大。 - 数据库日志抓取
有效的日志抓取利用时间计划点(通常是午夜时间)的数据库重做日志快照并在那些ETL加载用到的受影响的表的事务中搜寻。检测包括轮询重做日志,实时获取事务
为特殊需求创建一个日志 - 消息队列监控
在一个基于消息的事务系统中,监视所有针对感兴趣表的事务的队列。流的内容与日志探索差不多。这一过程的好处之一是开销相对较低,因为消息队列已经存在。然而,消息队列没有回放功能。如果与消息队列的连接消失,将会丢失数据。
子系统3 获取系统
多数情况下,每个源都位于不同的系统中,处于不同的环境并采用不同的数据库管理系统。
如果要通过公共网络或在距离比较长的情况下传输大量数据,对数据进行压缩后再传输是非常重要的。在此情况下,通讯链路通常会成为瓶颈。如果传输数据花费大量的时间,则压缩可以减少30%~50%或更多的传输时间,效果如何要看原始数据文件的属性。
4.清洗与整合数据
看起来不起眼的数据质量问题,实际上是拆散业务流程的重要标志
子系统4 数据清洗系统
ETL数据清洗过程通常希望订正脏数据,同时希望数据仓库能够提供对组织生产系统中的数据的准确描述。在各种冲突的目标之间实现平衡是基本的要求。
在描述清洗系统时, 目标之一是提供清洗数据、获取数据质量事件,以及度量并最终控制数据仓库中的数据质量的全面结构。
子系统的目标
- 尽早诊断并分类数据质量问题。
- 为获得更好的数据而对源系统及集成工作的需求。
- 提供在ETL中可能遇到的数据错误的专门描述。
- 获取所有数据质量错误以及随时间变化精确度量数据质量矩阵的框架。
- 附加到最终数据上的质量可信度度量。
数据质量屏幕
- 列屏幕测试单一列中的数据。这些测试通常是简单的、比较明显的测试,例如,测试·某列是否包含未预期的空值,某个值是否超出了规定的范围,或者某个值是否未能遵守需要的格式。
- 结构屏幕测试数据列之间的关系。测试两个或更多的列以验证它们是否满足层次要求,例如,一系列多对一关系。结构屏幕也对两个表之间存在的外键/主键的约束关系进行测试,还包括对整个列块的测试,验证它们的邮政编码是否满足合法性。
- 业务规则屏幕实现由列和结构测试无法适应的更复杂的测试。例如,可能需要测试与客户档案有关的复杂的与时间关联的业务规则,例如,需要测试那些申请终身白金飞行常客的成员,要求至少有5年乘机历史并且飞行距离超过200万公里。业务规则屏幕也包括聚集阈值数据质量检查
子系统5 错误事件模式
错误事件模式是一种集中式的维度模式,其目的是记录ETL流水线中所有质量屏幕出·现的错误事件。尽管我们主要关注的是数据仓库的ETL过程,但该方法也可应用于一般的.需要在遗留应用之间传输数据的数据集成应用中
子系统6 审计维度装配器
子系统7 重复数据删除系统
数据保留(survivorship)是合并匹配记录集合到统一视图的过程,该统一视图将从匹配记录中获得的具有最高质量的列合并到一致性的行中。数据保留包括建立按照来自所有可,能源系统的列值而清楚定义了优先顺序的业务规则,用于确保每个存在的行具有最佳的保留属性。如果维度设计来自多个系统,则必须维护带有反向引用的不同列,例如自然键,用于所有参与的源系统行的构建工作
采集多个源头的数据.由此采集造成的数据重复,怎么删除重复的数据,感觉是个难题
子系统8 一致性系统
一致性处理包含所有需要调整维度中的一些或所有列的内容以与数据仓库中其他相同或类似的维度保持一致的步骤。
(对于多源头数据属性怎么提取出一致性维度属性)
5.发布 准备展现
子系统9 缓慢变化维度管理器(重点)
类型一 重写
类型1技术简单地在已有维度行中重写一个或多个属性。将从变化数据获取系统中获取的修改后的数据重写到维度表中的相应内容。当需要改正数据或对先前值没有保存的业务需求时,类型1是比较适当的。例如,您可能需要改正客户的地址。在此情况下,重写是正确的选择。注意,如果维度表包含类型2变化跟踪,应当重写该客户的所有受影响的列。类型1更新必须传播到前面早期已经永久存储的阶段表,并重写所有受影响的阶段表中的数据,这些阶段表如果被用于重建最终的加载表时,才会体现出重写的影响效果。
类型二 增加新行
类型2-SCD是一种用于跟踪维度变化并将其与正确的事实行关联的标准技术。支持类型2变化需要强大的变化数据获取系统,用于检测发生的变化。对类型2更新来说,复制先前维度行的版本,从头开始建立新行。然后更新行中发生变化的列并增加所需要的其他列。这一技术是处理需要随时间而跟踪的维度属性变化的主要技术
类型2处理不会像类型1那样对历史情况做出改变,因此类型2变化不需要重建受影响的聚集表,只要变化是“今天”而不是之前发生的。
类型三 增加新属性
类型3技术用于支持属性发生“软”变化的情况,允许用户既可以使用属性旧值也可以使用新值。
与类型1处理类似,类型3变化更新将会导致所有针对更新列所做的聚集失效。维度管理器必须通知受影响的事实提供者,使他们能够删除并重新建立受影响的聚集。
类型三 增加微型维度
在维度中的一组属性变化非常快的情况下,需要将它们划分到微型维度上,此时将采用类型4技术。这种情况有时被称为快速变化超大维度。
子系统10 代理键产生器
DBMS来分派代理键,这样对ETL过程是最好的,不需要ETL直接调用数据库序列产生器。
子系统11 层次管理器
在维度中通常具有多个同时存在的、嵌入的层次结构
子系统12 特定维度管理器
日期/时间维度
难点:涉及到跨国组织环境时,考虑到多个财务报表周期或多种不同的传统日历,就复杂了-
杂项维度
杂项维度涉及那些当您从事实表中删除所有关键属性后遗留下来的文本和繁杂的标识
建立杂项维度的结构 微型维度
缩减子集维度
缩减维度是一种一致性维度,其行与/或列是基维度的子集。ETL数据流应当根据基维度建立一致性缩减维度,而不是独立于基维度,以确保一致性。小型静态维度
用户维度的维度
子系统13 事实表建立器
事务事实表加载器
如果需要更新已经存在的行,该过程应当采取两步处理。第1步是插入更正的行,不需要重写或,删除原始行,然后在第2步中删除原始行。在事实表中采用顺序分配的单一代理键,能够使先执行插入后删除的两步过程得以实现周期快照表加载器
周期快照通常具有与事务粒度事实表类似的加载特性。插入和更新的过程相同。假定·数据被及时发送到ETL系统中,每个加载周期的所有记录可以以最近时间分区聚类。传统上,周期快照在适当的时期结束时将被集体加载。累积快照表加载器
累积快照事实表是一种表示具有良好定义的开始和结束的有限过程的有效方式。
子系统14 代理键流水线
使用实际的维度表作为代理键的最新值替换对应的自然键。每当需要,当前代理键时,用自然键查询与其值相等的维度中的所有行,然后利用当前行标识或开始及结束有效日期选择与事实表行历史环境对齐的代理键。当前的硬件环境提供几乎无限的可编址地址空间,使该方法具有实用性
子系统15 多值桥接表建立器
建立和维护桥接表是ETL小组将面临的挑战。当遇到事实表行存在的多值关系时,ETL系统可选择将每个观察值集合构建唯一组或当相同观察值集合发生时重用该组
子系统16 迟到数据处理器
对于实时数仓来说维度信息的迟到是一个难题
子系统17 维度管理器系统
- 实现在维度设计期间由数据管理人员和利益共同体许可的公共描述性标识。
- 在新源数据产生后,在一致性维度中增加新行,建立新的代理键。
- 当己存在的维度条目发生类型2变化时,建立新的代理键。
- 在类型1和类型3变化发生时,修改涉及的行,但不需要改变代理键。
- 在类型1和类型3变化发生时,更新维度的版本号。
- 将更新的维度同时复制到所有事实表提供者。
维度管理器是负责为数据仓库社团准备和发布一致性维度的集中负责之处
子系统18 事实提供者系统
- 从维度管理器接收或下载复制的维度。
- 在某些环境中,维度无法被简单地复制而必须采用本地更新方法,此时,事实提供者必须处理标识为新的和当前的维度记录,并在代理键流水线中更新当前键映射,同时需要处理标识为新的但包含迟填日期的维度记录。
- 在将自然键替换为正确的代理键后,在事实表中增加新行。
- 修改由于错误更正、累积快照和迟到维度变化所涉及的所有事实表中的行。
- 将那些因为发生改变而失效的聚集删除。
- 重新计算受影响的聚集。如果维度的新版本没有改变版本号,仅需扩展聚集以处理那些新加载的事实数据。如果维度的版本号发生了改变,则整个历史聚集可能都需要重新计算。
- 确保所有基本和聚集事实表的质量,这取决于对聚集表的正确计算。
- 将更新后的事实和维度表在线发布。
- 通知用户数据库被更新了。如果发生了重大变化则告诉他们,包括维度版本改变、迟填日期记录被增加,历史聚集发生了变化。
子系统19 聚集建造器
用户反馈查询速度缓慢是设计聚集的关键输入
子系统20 OLAP多维数据库建造器
OLAP服务器以一种更直观的方式展现维度数据,确保一些分析用户能够对数据进行切片和切块操作。
子系统21 数据传播管理器
数据传播管理器负责需要将一致的、集成的企业数据从数据仓库展现服务器发送到其他环境中以应对特殊目的的ETL过程。
6.管理ETL环境
三个标准
可靠性。ETL过程必须始终在运行。它们必须运行以完成提供及时的数据,这些数据的所有细节级别都是值得信任的。
可用性。数据仓库必须满足其服务级别协议(Service Level Agreement, SLA)。数据仓库应做出承诺。
可管理性。成功的数据仓库是永远无法实现的。它将随着业务的发展而不断发展变化。ETL过程需要不断改进。
子系统22 任务调度器
任务控制包含的部分:
- 任务定义
- 任务调度
- 元数据获取
- 日志记录
- 通知
子系统23 备份系统
确定将什么信息移出数据仓库是一个涉及成本效益的问题。保存数据需要成本-它会占用磁盘空间并使加载和查询时间变慢。另一方面,业务用户可能仅仅需要这些数据来完成一些关键的历史分析。同样,审计师可能需要归档数据进行合规检查。解决方案是不要将这些数据抛弃,但要将其放入开销更低但仍然能够访问的地方。归档是数据仓库的数据安全保障。
归档数据的长期影响是什么???
子系统24 恢复与重启系统
ETL运行的过程越长,您必须意识到出现错误的可能就越大。设计针对灾难和未预期中断的具有弹性的高效过程构成的模块化ETL系统,可以减少导致大量恢复工作的错误的风险。仔细考虑何时物理地将数据写到磁盘上,仔细设计恢复和加载日期时间戳,顺序化事实表代理键,从而确保定义合适的重启逻辑。
子系统25 版本控制系统
版本控制系统是一种针对ETL流水线中所有逻辑和元数据进行归档和恢复时具有“快,速拍照”能力的系统。它控制所有ETL模块和任务的签出及签入处理。它应当支持对源的比较工作以揭示版本之间的差别。
子系统26 版本迁移系统
子系统27 工作流监视器
成功的数据仓库具有一致且可靠的可用性,并得到商业团体的认可。为实现这一目标,ETL系统必须持续监视,保证ETL过程操作的有效性,保证数据仓库能够连续及时地进行加载。任务调度器(子系统22)应在每次ETL过程开始时获取性能数据。
导致ETL缓慢的原因
- 针对源系统或中间表的低效索引查询
- SQL语法导致优化器做出错误的选择
- 随机访问内存(RAM)不足导致的内存颠簸
- 在RDBMS中进行的排序操作
- 缓慢的转换步骤
- 过多的IO操作
- 不必要的读写
- 重新开始删除并重建聚集而不是增量式地执行这一操作
- 在流水线中过滤(改变数据获取)操作应用太迟
- 未利用并行化和流水线方式
- 不必要的事务日志,特别是在更新时存在的事务日志
- 网络通信及文件传输的开销
子系统28 排序系统
子系统29 世系与依赖分析器
世系。以中间表或BI报表的特定数据元素开始,识别数据元素的来源、包含该元素及其来源的其他上游的中间表,以及该元素及其来源的所有转换。
依赖。从包含在源表或中间表的特定数据元素开始,识别所有包含该元素或根据其推导产生的下游中间表和最终的BI报表,还包含所有应用到该数据元素的转换和其派生元素。
子系统30 问题提升系统
ETL系统的支持结构应当遵循一个相当标准的支持结构。
子系统31 并行/流水线系统
ETL系统的目标,除了提供高质量的数据以外,还包括在分配的处理窗口内加载数据仓库。在大型组织中,包含大量的数据、大型的维度和大量的事实,在这些限制条件下加载数据是极富挑战性的工作。并行流水线系统提供了在面对这些限制时保证ETL系统得以发布的能力。
子系统32 安全系统
子系统33 合规性管理器
合规性系统的基础是几个已经被描述过的采用一些关键技术和能力的子系统之间的交互:
世系分析
依赖分析
版本控制
备份与恢复
安全
审计维度
子系统34 源数据存储器管理器
ETL系统负责使用并建立DW/BI环境中的大多数元数据。整个元数据策略的部分工作涉及专门获取ETL元数据,包括过程元数据、技术元数据和业务元数据。需要在什么都不做和什么都做之间设计出一种平衡的策略。确保在ETL开发任务中有时间来获取和管理元数据。最后,确保在DWBI小组中指派人员作为元数据管理员并负责建立并实现元数据策略。
要点
导致ETL慢的原因
世系和依赖
维度表的更新问题
事实表的代理键的问题
ETL大致的流程与子系统的描述