《DAMA-DMBOK2》读书笔记-第11章数据仓库和商务智能

辉哥

发布于 2022-09-08 11:38:19

9610

发布于 2022-09-08 11:38:19

文章被收录于专栏：区块链入门区块链入门

1 文章结构脑图

第11章数据仓库和商务智能 10%.png

2 基本概念

2.1 商务智能

商务智能这个术语有两层含义。 P292

第一层含义,商务智能指的是一种理解组织诉求和寻找机会的数据分析活动。数据分析的结果用来提高组织决策的成功率。
第二层含义,商务智能指的是支持这类数据分析活动的技术集合。决策支持工具、商务智能工具的不断进化,促成了数据查询、数据挖掘、统计分析、报表分析、场景建模、数据可视化及仪表板等一系列应用,它们被用于从预算到高级分析的方方面面。

2.2 数据仓库

数据仓库有两个重要组成部分: 一个集成的决策支持数据库和与之相关的用于收集、清理、转换和存储来自各种操作和外部源数据的软件程序。 P292 数据仓库建设还会包括相依赖的数据集市,数据集市是数据仓库中数据子集的副本。 P292 从广义上来说,数据仓库包括为任何支持商务智能目标的实现提供数据的数据存储或提取操作。 P292

2.3 数据仓库建设

数据仓库建设指的 是数据仓库中数据的抽取、清洗、转换、控制、加载等操作过程。数据仓库建设流程的重点,是通过强制业务规则、维护适当的业务数据关系,在运营的数据上实现一个集成的、历史的业务环境。数据仓库建设还包括与元数据资料库交互的流程。 P292

传统意义上建设主要关注结构化数据，现在也包含半结构化数据和非结构化数据。 P293

2.4 数据仓库建设的方法

两位思想领袖比尔·恩门(BillInmon)和拉尔夫·金博尔( RalphKimball) 分别使用范式建模和多维建模来完成数据仓库建模。P293

比尔·恩门在《数据仓库》(Building theDataWarehouse )中定义: 数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合。

拉尔夫·金博尔在《数据仓库工具箱》(The DataWarehouse Toolkit) 中提出: 主张自下而上(DMDW)的方式，力推数据集市建设，他定义为“为查询和分析定制的交易数据的副本。 ”

参考 : https://blog.csdn.net/Luomingkui1109/article/details/91349335 ; https://dataclub.blog.csdn.net/article/details/118663623;

他们遵循的核心理念相似: P293

1)数据仓库存储的数据来自其他系统。
2)存储行为包括以提升数据价值的方式整合数据。
3)数据仓库便于数据被访问和分析使用。
4)组织建设数据仓库,因为他们需要让授权的利益相关方访问到可靠的、集成的数据。
5)数据仓库数据建设有很多目的,涵盖工作流支持、运营管理和预测分析。

2.5 企业信息工厂（Inmon）

企业信息工厂(Corporate Information Factory，CIF): Inmon关于数据仓库的组成是这样描述的:“面向主题的、整合的、随时间变化的、包含汇总和明细的、稳定的历史数据集合”。 P293

这种概念描述也适用于CIF,并指出了数据仓库和业务系统的区别。 P293

面向主题的。数据仓库是基于主要业务实体组织的,而不关注功能或应用
整合的。数据仓库中的数据是统一的、内聚的。因为数据是整合的,数据仓库不是简单的运营数据的副本。相反,数据仓库变成了一个数据记录的系统。
随时间变化的。数据仓库存储的是某个时间段的数据。数据仓库中的数据像快照一样,每一张快照都反映了某个时点的数据状态。
稳定的。在数据仓库中,数据记录不会像在业务系统里那样频繁更新。相反,新数据只会追加到老数据的后面。
聚合数据和明细数据。数据仓库中的数据包括原子的交易明细,也包括汇总后的数据。
历史的。业务系统的重心是当前的数据。数据仓库还包括历史数据,通常要消耗很大的存储空间。

Inmon、Claudia Imhoff和Ryan Sousa等是在CIF的语境下描述数据仓库的。CIF的组成部分包括: P294

应用程序。
数据暂存区。
集成和转换。
操作型数据存储 (ODS)。
数据集市。
操作型数据集市(OpDM)。操作型数据集市是专注于运营决策支持的数据集市。直接从操作型数据存储而不是从数据仓库获取数据，具有与操作型数据存储相同的特性:包含当前或近期的数据，这些数据是经常变化的。
数据仓库。单向流向数据集市。
运营报告。运营报告从数据存储中输出。
参考数据、主数据和外部数据。

业务系统到数据集市，数据流程过程的变化: P295 1)目标:功能执行——>数据分析。2)用户:业务人员——>决策人员。3)使用:固定操作——>即席查询。4)时间:即时要求高——>不高。 5)影响面:数据少——>涉及更多数据。

数据仓库和数据集市的数据与应用程序中的数据不同: P295

数据的组织形式是==按主题域而不是按功能需要==。
数据是==整合的数据,而不是“孤立”的烟囱数据==。
数据是==随时间变化的系列数据,而非仅当前时间的值==。
数据在数据仓库中的==延迟比在应用程序中高==。
数据仓库中提供的==历史数据比应用程序中提供的历史数据多==。

2.6 多维数据仓库（Kimball）

Kimball将数据仓库简单地定义为“专为查询和分析而构建的事务数据的副本”。多维模型旨在方便数据使用者理解和使用数据, 同时还支持更优的查询性能。它不是以实体关系模型的规范化要求组织的。 P295

多维模型通常称为星型模型,由事实表(包含有关业务流程的定量数据,如销售数据)和维度表(存储与事实表数据相关的描述性属性, 为数据消费者解答关于事实表的问题,如这个季度产品X卖了多少)组成。事实表与许多维表关联,整个图看上去像星星一样。 P296

多个事实数据表将通过“总线”共享公共的维度或遵循一致性的维度,类似于计算机中的总线。通过插入遵循维度的总线,可以将多个数据集市集成为企业级的数据集市。 P296

Kimball的数据仓库比Inmon的数据仓库的可扩展性更强。数据仓库包含数据暂存和数据展示区域的所有组件。 Kimball 的数据仓库分为业务源系统、数据暂存区域、数据展示区域、数据访问工具四个部分。 P296 见下图11-3

数据仓库的总线矩阵展示 的是生成事实数据的业务流程和表示维度的数据主题域的交汇。独立于技术，用于表示数据仓库/BI 系统长期数据的内容需求，帮助组织确定可管理的开发工作范围。P296 见下表11-4

2.7 数据仓库架构组件

数据仓库环境包括一系列组织起来以满足企业需求的架构组件。包括源系统，数据集成，数据存储区域等。 P298 见下图 11-5 大数据方案一般会先加载数据，再处理，即 ELT。

源系统。 包括要流入数据仓库/商务智能环境的业务系统和外部数据。P297
数据集成。 数据集成包括抽取、转换和加载(此三者英文首字母缩写为E、T、L,通常直接这把三者称为ETL)、数据虚拟化以及将数据转换为通用格式和位置的其他技术。P298
数据存储区域 P298 数据仓库包含多个不同用途的存储区域:
1. 暂存区。介于原始数据源和集中式数据存储库之间的中间数据存储区域。
2. 参考数据和主数据一致性维度。
3. 中央数据仓库。 数据结构的设计元素包括: 1 基于性能考虑而设计的业务主键和代理主键之间的关系。 2 创建索引和外键以支持维度表。 3 用于检测、维护和存储历史记录的变更数据捕获(Change Data Capture，CDC)技术。
4. 操作型数据存储 ODS。操作型数据存储包含一个时间窗口的数据而不是全部历史记录，因此可以比数据仓库有更快地刷新频率。
5. 数据集市。面向特定主题域、单个部门或单个业务流程。
6. 数据立方体 Cubes。3 种经典的支持在线分析处理系统 OLAP:基于关系、基于多维及混合型存储结构。

2.8 加载处理的方式

数据仓库建设涉及两种主要的数据集成处理类型：历史数据加载和持续不断的数据更新。P299

历史数据 P299
1. Inmon 类型的数据仓库建议所有数据存储在单个数据仓库层中。这一层中存储已清洗过的、标准化的和受管控的原子级数据。
2. Kimball 类型的数据仓库建议，数据仓库由包含已清洗过的、标准化的和受管控数据的部门级数据集市合并而成。数据集市将在原子级别存储历史记录，由一致性维度表和一致性事实表提供企业级信息。
3. Data Vault，作为数据暂存处理的一部分，同样进行数据清洗和标准化。历史数据以规范化的原子结构存储，每个维度定义了代理键(Surrogate key)、主键(Primary key)、备用键(Alternate key)
批量变更数据捕获 P300 数据仓库是通过每天晚上的批处理窗口进行一次数据加载服务。因为不同源系统可能需要不同的变更捕获技术，所以加载过程可以包含各种变更检测。各种变更数据捕获技术之间的差异。见下表11-2
准实时和实时数据加载 P300 操作型商务智能(或运营分析)的出现推动了更低延迟的需求,将更多实时的或准实时的数据集成到数据仓库中,新的架构方法随之出现,用于处理易变化的数据。 批处理的替代方案解决数据仓库中对数据可用性延迟越来越短的要求,有 涓流式加载、消息传送和流式传送三种主要的替代方案,它们在等待处理时的数据累积位置不同。
1. 涓流式加载(源端累积)。与夜间窗口批量加载不同,涓流式加载是以更频繁的节奏(如每小时甚至每5分钟)或者以阈值的方式(如每300个事务,每1 G数据)进行批量加载。这
2. 消息传送(总线累积)。当极小的数据报(消息、事件或事务)发布到消息总线时,实时或接近实时的消息交互就非常有用。
3. 流式传送(目标端累积)。与在源端定时或按阀值加载不同, 目标端系统用缓冲区或队列方式收集数据,并按顺序处理。

3 语境关系图

3.1 定义

数据仓库(Data Warehouse，DW): 始于 20 世纪 80 年代，发展于 20 世纪 90 年代，后与商务智能(Business Inteligence,BI)作为业务决策主要驱动力协同发展。赋能组织将不同来源的数据整合到公共的数据模型，整合后的数据能为业务运营提供洞察，为企业决策支持和创造组织价值开辟新的可能性。数据仓库还是减少企业建设大量决策支持系统(Decision Support System,DSS)的一种手段,大部分DSS系统使用的都是企业中同样的核心数据。企业数据仓库提供了一种减少数据冗余、提高信息一致性,让企业能够利用数据做出更优决策的方法。数据仓库是企业数据管理的核心。P290

3.2 目标

数据仓库的建设目标: 1)支持商务智能活动。2)赋能商业分析和高效决策。3)基于数据洞察寻找创新方法。P291

数据仓库建设应遵循原则: P291-292

聚焦业务目标。用于最优级的业务并解决它。
以终为始。以业务优先级和最终成果驱动仓库创建。
全局性的思考和设计，局部性的行动和建设。
总结并持续优化，而不是一开始就这样做。
提升透明度和自助服务。
与数据仓库一起建立元数据。 DW 的成功关键是能准确解释数据。
协同。与其他数据活动协作，尤其是数据治理、数据质量和元数据管理活动。
不要千篇一律。为每种数据消费者提供正确的工具和产品。

3.3 业务驱动因素

数据仓库建设的主要驱动力是 运营支持职能、合规需求和商务智能活动(尽管不是所有的商务智能活动都依赖仓库数据)。 P291

3.4 输入

3.5 活动

活动: 1.理解需求。2.定义和维护 DW 和 BI 架构。3.开发数据仓库和数据集市。4.加载数据仓库。 5.实施 BI 产品组合。6.维护数据产品。

【活动 1】理解需求 P301

首先,要考虑业务目标和业务战略,确定业务领域并框定范围;
然后,确定并对相关的业务人员进行访谈,了解他们想做些什么和这么做的原因,记录他们当下关心的具体问题和想要询问的数据,以及他们如何区分和分类重要信息。
在可能的情况下,界定并书面记录关键的性能指标和计算口径。
将需求进行分类并排出优先级,与生产上线相关的排在前面,将与数据仓库相关的和那些可以等的排在后面。
寻找并快速启动那些简单且有价值的项目,以便在项目初始发布阶段就能获得产出。

【活动 2】定义和维护数据仓库/商务智能架构 P301 数据仓库/商务智能架构应该描述数据从哪里来、到哪里去、什么时候去、为什么要去,以及用什么样的方式流入数据仓库。

确定数据仓库/商务智能技术架构。应能以原子化的数据处理方式支撑交易级和运营级的报表需求。做好原型设计可以快速证明或驳斥关键需求的实现，避免对某些技术或架构进行过大的投入。
确定数据仓库/商务智能管理流程。通过协调和集成维护流程进行生产管理，定期向业务团队发布。建立一个有效的发布流程，确保管理层理解这是一个以数据产品为中心的主动流程，而不是已安装产品的被动式问题解决方式。

【活动 3】开发数据仓库和数据集市 P302

数据仓库/商务智能建设项目有三条并存的构建轨迹:

==支持业务分析所必需的数据==。识别最佳来源、设计规则、处理不合预期数据。
==技术==。支持数据存储和迁移的后端系统及流程。
==商务智能工具==。数据消费者从已部署的数据产品中获得有意义的数据洞察所必需的应用套件。

内容:(70%的工作)

将源映射到目标。建立转换规则。确保链接有效性或等效性。逻辑数据模型。最困难是确定多系统数据间的链接有效性或等效性。
修正和转换数据。数据修正或清理活动的执行标准。纠正域值。源系统应负责数据的修复工作并确保数据正确。乐观加载策略:创建维度记录以容纳事实数据。悲观加载策略:事实数据的回收区域。

【活动 4】加载数据仓库 P303

在所有数据仓库/商务智能工作中,工作量最大的部分都是数据准备和预处理。描述数据仓库中所包含的设计决策和原则是数据仓库/商务智能架构设计的关键考量因素。

确定数据加载方法时， 1.要考虑的关键因素是数据仓库和数据集市所需的延迟要求、源可用性、批处理窗口或上载间隔、目标数据库及时间帧的一致性，还必须解决数据质量处理过程、执行转换的时间、延迟到达的维度和数据拒绝等问题。2.另一个因素是围绕变更数据捕获过程检测源系统中的数据变更，将这些变更集成在一起，并依时间调整变更。

【活动 5】实施商务智能产品组合 P304

实施商务智能组合是为了在业务部门内部或业务部门之间为正确的用户社区选定合适的工具,通过协调常见业务流程、性能分析、管理风格和需求找到相似之处。

根据需要给用户分组。了解用户组。将工具与用户组匹配。
将工具与用户要求相匹配。需要系统资源、技术支持、培训和架构集成。

【活动 6】维护数据产品 P305

发布管理。确保是最佳状态。
管理数据产品开发生命周期。
监控和调优加载过程。了解性能瓶颈和依赖路径。在需要的地方和时刻使用数据库调优技术,包括分区、备份调优和恢复策略调整。数据归档是数据仓库构建中的一个难题。
监控和调优商务智能活动和性能。商务智能监控和调优的最佳实践是定义和显示一组面向客户满意度的指标,如平均查询响应时间,每天、每周或每月的用户数就是有用的指标。定期审查。透明度和可见性推动数据仓库/商务智能监控的关键原则。

3.6 交付成果

3.7 技术驱动因素

3.8 方法

驱动需求的原型。在实现产品之前,通过创建一组演示数据并在协调原型设计工作中采用需求挖掘的方法,快速确定需求优先级。 对数据进行剖析(Profiling) 有助于原型设计,并降低与非预期数据相关的风险。数据仓库通常最先体会到源系统或数据输入函数中数据质量差的痛楚。概要分析还揭示了可能对数据集成造成障碍的数据来源之间的差异。数据可能在其来源中具有高质量,但由于各来源的不同, 数据集成过程变得更加复杂。 对源数据的状态评估,有助于对集成可行性和工作范围进行更准确的前期估算。评估对于设定适当的期望值也很重要。计划与数据质量和数据治理团队合作,并结合其他主题专家的专业知识来了解数据差异和风险。 ==数据剖析有助于原型设计，降低风险。状态评估有助于集成可行性和工作范围的评估。演示数据。数据虚拟技术。数据探查。源系统评估。==
自助式商务智能。自助服务是商务智能产品的基本交付方式。它通常会将用户活动放在受管门户中,根据用户的权限提供各种功能,包括消息传递、警报、查看预定的生产报表、与分析报表交互、开发即席查询报表,当然还有仪表盘和计分卡功能。将协作工具向外扩展到用户社区,可以提供一些自助服务提示和技巧、负载状态、整体性能和发布进度的公告,也可以在论坛对话。 ==基本交付形式。根据用户权限提供。按标准计划推送。在门户中执行报表提取数据。社区。==
可查询的审计数据。为了维系数据血缘关系,所有的结构和流程都应该能够创建和存储审计信息,并能够进行细粒度的跟踪和报告。允许用户查询该审计数据,让用户能够自己验证数据的状况和到达情况,从而提高用户的信心。当出现数据问题时,使用审计信息还可以进行更详细的故障排除。 ==所有结构和流程都应能创建和存储审计数据。能进行细粒度的跟踪和报告。提升用户信心。可快速定位问题。==

3.9 工具

==元数据存储库。== P307 A.数据字典和术语。数据字典是支撑数据仓库使用的必需组件。字典用业务术语来描述数据，包括使用该数据所需的其他信息(如数据类型、结构细节、安全限制)。数据字典内容来自逻辑数据模型。 B.数据和数据模型的血缘关系。 记录的数据血缘关系有很多用途： 1)调查数据问题的根本原因。2)对系统变更或数据问题进行影响分析。3)根据数据来源确定数据的可靠性。
==数据集成工具。== P308 用于加载数据仓库。考虑系统管理的如下功能: 1)过程审计、控制、重启和调度。 2)有选择地提取数据元素并将其提供给下游系统进行审计的能力。 3)控制操作的执行，并重启失败或中止的进程。还提供 BI 产品的集成功能，支持工作流消息、电子邮件甚至语义层的导入导出。
==商务智能工具。== P308 1)运营报表。 2)业务绩效管理 BPM。旨在优化业务战略的执行。绩效度量和带正反馈回路是关键的要素。绩效度量和带正反馈回路是关键的要素。 3)描述性自助分析。为前台提供，指导运营决策。

【运营报表】 P309 业务用户直接从交易系统、应用程序或数据仓库生成报表。 数据检索和报表工具，有时称为即席查询工具，允许用户编写自己需要的报表或创建供他人使用的报表。 业务运营报表中的需求通常与业务查询报告的需求不同。 生产报表跨越了数据仓库/商务智能的边界，它经常直接查询交易系统，产生诸如发票或银行对账单之类的操作项。 传统的商务智能工具可以很好地展现表格、饼图、折线图、面积图、条形图、直方图、K 线图等一些数据可视化方法。

【业务绩效管理】 P309 绩效管理是一套集成的组织流程和应用程序,旨在优化业务战略的执行。应用程序包括预算、规划和财务合并。

【在线分析处理OLAP】 P310 OLAP工具和Cube(数据立方体)的价值是,通过将数据内容与分析师的心理模型对齐,减少混淆和错误解释。 多维分析查询提供快速性能的方法。常见操作有切片、切块、向下/向上钻取、向上卷积、透视。 三种经典 OLAP 实现方法如下: 关系型联机分析处理 ROLAP。多维矩阵型联机分析处理 MOLAP。混合型联机分析处理 HOLAP。

3.10 度量指标

使用指标。 包括注册用户数、连接用户数或并发用户数。
主题域覆盖率。 衡量每个部门访问仓库的程度
响应时间和性能指标。 指标的后续跟进工作是验证和服务级别调整。

4 实施指南

就绪评估/风险评估: 所有IT项目都应该有业务支持,与战略保持一致,并有一个定义好的架构方法。 P312 数据仓库应该能够实现以下几点:

明确数据敏感性和安全性约束。
选择工具。
保障资源安全。
创建抽取过程以评估和接收源数据。

版本路线图: 因为需要进行大量的开发工作,所以数据仓库是逐步构建的。无论选择何种实现方法,不管是瀑布式、迭代式,还是敏捷开发,都应该考虑到想要实现的最终状态。 P313

组织与文件变革: 始终保持一致的业务重点是项目成功的关键。了解企业的价值链是理解业务环境的好方法,企业价值链中的特定业务流程提供了一个自然地面向业务的环境,该环境可用于构建分析领域。 P313

最重要的是,考虑到以下关键成功因素,将项目与实际业务需求保持一致并评估必要的业务支持: P314

业务倡议。是否有合适的管理层支持?
业务目标和范围。是否有确切的业务需要、业务目标和工作范围?
业务资源。是否有专家?参与度如何?
业务准备情况。业务合作是否准备好这是长期的增量交付项目?目标组织内的平均知识水平或技能差距有多大?
愿景一致。IT 战略对业务愿景的支持程度如何?

5 数据仓库和商务智能治理

5.1 业务接受度

一个关键的成功因素是业务对数据的接受程度,包括可以理解的数据、具有可验证的质量,以及具有可证明的数据血缘关系。

预先还要考虑一些非常重要的架构子组件及其支持活动,具体如下:

概念数据模型。组核心信息?关键的业务概念? 如何相互关联?
数据质量反馈循环。如何识别和修正问题数据?如何了解问题是怎么产生的? 怎样对解决问题负责?对数据仓库的数据集成过程中引起的问题进行补救的过程是什么?
端到端元数据。架构如何支持集成的端到端元数据流?是否理解上下文环境的意义?数据消费者如何回答诸如“这个报表的含义是什么”或“这个指标是什么意思”等基本的问题?
端到端可验证数据血缘。业务用户公开访问的项目是否能以自动化的、可自维护的方式追溯到源系统?所有数据是否都记录在案?

5.2 报表策略

确保BI产品组合内部和跨BI产品组合间都存在报表策略。报表策略包括 标准、流程、指南、最佳实践和程序,它将确保用户获得清晰、准确和及时的信息。

报表策略必须解决如下问题:

安全访问。确保只有获得授权的用户才能访问敏感数据。
描述用户交互、报告、检查或查看其数据的访问机制。
用户社区类型和使用它的适当工具。
报表摘要、详细信息、例外情况以及频率、时间、分布和存储格式的本质。
通过图形化输出发挥可视化功能的潜力。
及时性和性能之间的权衡。

6 关键架构图

图11-1 数据仓库和商务智能语境关系图

图11-1 数据仓库和商务智能语境关系图

图11-2 企业信息工厂（CIF）

图11-2 企业信息工厂（CIF）

图11-3 Kimball 的数据仓库棋子视图

图11-3 Kimball 的数据仓库棋子视图

表11-4 数据仓库总线矩阵示例

表11-4 数据仓库总线矩阵示例

图11-5 数据仓库/商务智能和大数据概念架构

图11-5 数据仓库/商务智能和大数据概念架构

表11-6 CDC技术比对

表11-6 CDC技术比对

图11-7 发布流程示例

图11-7 发布流程示例

本文参与腾讯云自媒体同步曝光计划，分享自作者个人站点/博客。

原始发表：2022-07-18，如有侵权请联系 cloudcommunity@tencent.com 删除

数据库

本文分享自作者个人站点/博客前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体同步曝光计划，欢迎热爱写作的你一起参与！

登录后参与评论

0 条评论

热度