DAMA学习笔记(十)-数据仓库与商务智能

1.引言

  数据仓库（Data Warehouse，DW）的概念始于20世纪80年代。该技术赋能组织将不同来源的数据整合到公共的数据模型中去，整合后的数据能为业务运营提供洞察，为企业决策支持和创造组织价值开辟新的可能性。与商务智能（Business Inteligence，BI）作为业务决策主要驱动力协同发展。

1.业务驱动因素

  数据仓库建设的主要驱动力是运营支持职能、合规需求和商务智能活动(尽管不是所有的商务智能活动都依赖仓库数据)。商务智能支持一直是建设数据仓库的主要原因，商务智能为组织、客户及产品提供洞察。通过商务智能获得决策知识并采取行动的组织，能提升其运营效率，增强其竞争优势。

2.目标和原则

  组织建设数据仓库的目标通常有：

• 1）支持商务智能活动。
• 2）赋能商业分析和高效决策。
• 3）基于数据洞察寻找创新方法。

  数据仓库建设应遵循如下指导原则：

• 1）聚焦业务目标。确保数据仓库用于组织最优先级的业务并解决业务问题。
• 2）以终为始。让业务优先级和最终交付的数据范围驱动数据仓库 内容的创建。
• 3）全局性的思考和设计，局部性的行动和建设。让最终的愿景指导体系架构，通过集中项目快速迭代构建增量交付，从而实现更直接的投资回报。
• 4）总结并持续优化，而不是一开始就这样做。以原始数据为基 础，通过汇总和聚合来满足需求并确保性能，但不替换细节数据。
• 5）提升透明度和自助服务。上下文（各种元数据）信息越丰富， 数据消费者越能从数据中获得更多数据价值。向利益相关方公开集成的数据及其流程信息。
• 6）与数据仓库一起建立元数据。数据仓库成功的关键是能够准确解释数据。能回答一些基本问题，如“这个数字为什么是X?” “这个怎么计算出来的?” “这个数据哪里来的?”。元数据的获取应该作为软件开发周期的一部分，元数据的管理也应该作为数据仓库持续运营的一部分。
• 7）协同。与其他数据活动协作，尤其是数据治理、数据质量和元数据管理活动。
• 8）不要千篇一律。为每种数据消费者提供正确的工具和产品。

3.基本概念

3.1 商务智能

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

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

3.2 数据仓库

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

3.3 数据仓库建设

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

  传统意义上的数据仓库建设，主要关注结构化数据：定义字段中的元素，无论是在文件中还是在表中，都要与数据模型中记录的一致。商务智能和数据仓库空间现在也包含半结构化数据和非结构化数据。非结构化数据指的是无法通过数据模型预定义的数据。

3.4 数据仓库建设的方法

  Inmon把数据仓库定义为“面向主题的、整合的、随时间变化的、相对稳定的支持管理决策的数据集合” ，用规范化的关系模型来存储和管理数据。而Kimball则把数据仓库定义为“为查询和分析定制的交易数据的副本”，他的方法通常称作多维模型。 虽然Inmon和Kimball提倡的数据仓库建设方法不同，但他们遵循的核心理念相似：

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

3.5 企业信息工厂(Inmon)

  Bill Inmon的企业信息工厂（Corporate Information Factory，CIF）是两种主要的数据仓库建设模式之一。Inmon关于数据仓库的组成是这样描述的：“面向主题的、整合的、随时间变化的、包含汇总和明细的、稳定的历史数据集合”。这种概念描述也适用于CIF，并指出了数据仓库和业务系统的区别。

关于数据仓库的理解:

• 1）面向主题的。数据仓库是基于主要业务实体组织的，而不关注功能或应用。
• 2. 整合的。数据仓库中的数据是统一的、内聚的。保持相同的关键结构，结构的编码和解码、数据定义和命名规范在整个仓库中都是一致的。因为数据是整合的，数据仓库不是简单的运营数据的副本。相反，数据仓库变成了一个数据记录的系统。
• 3）随时间变化的。数据仓库存储的是某个时间段的数据。数据仓库中的数据像快照一样，每一张快照都反映了某个时点的数据状态。意味着基于某个时间段的数据查询总是得到相同的结果，无论什么时候去查询。
• 4）稳定的。在数据仓库中，数据记录不会像在业务系统里那样频繁更新。相反，新数据只会追加到老数据的后面。一组记录可以代表同一个交易的不同状态。
• 5）聚合数据和明细数据。数据仓库中的数据包括原子的交易明细，也包括汇总后的数据。业务系统很少聚合数据。汇总数据可以是持久地存在一个表里，也可以是非持久的、以视图的形式展现。汇总数据是否持久化的决定因素通常是性能上是否需要。
• 6）历史的。业务系统的重心是当前的数据。数据仓库还包括历史数据，通常要消耗很大的存储空间。

关于企业信息工厂的组成:

• 1）应用程序。应用程序处理业务流程。应用程序产生的明细数据流转到数据仓库和操作型数据存储中，继而用作分析。
• 2）数据暂存区。介于业务系统源数据库和目标数据仓库之间的一个数据库。暂存区是用于数据抽取、转换和加载的地方，对最终用户透明。数据大部分是暂存的, 少部分数据持久化。
• 3）集成和转换。在集成层，来自不同数据源的数据被转换整合为数仓和ODS里的标准企业模型。
• 4）操作型数据存储（ODS）。操作型数据存储是业务数据的集成数据库。数据可能直接来源于应用系统，也可能来自其他数据库。操作型数据存储可以作为数据仓库的主要来源，还可用于对数据仓库做审计。 操作型数据存储数据周期短(30-90天), 且变化频率快。
• 5）数据集市。数据集市为后续的数据分析提供数据。这里说的数据通常是数据仓库的子集，用于支持特定分析或特定种类的消费者。
• 6）操作型数据集市（OpDM）。操作型数据集市是专注于运营决策支持的数据集市。
• 7）数据仓库。数据仓库为企业数据提供了一个统一的整合入口，以支持管理决策、战略分析和规划。
• 8）运营报告。运营报告从数据存储中输出。
• 9）参考数据、主数据和外部数据。交易所需的数据，如参考数据和主数据。

下图描绘了企业信息工厂内的数据流动，从通过应用程序进行数据的收集和创建（左侧），到通过集市进行信息创建和分析（右侧），在从左到右的数据流动过程中还包括其他一些更改。

• 1）目标从业务功能的执行转向数据分析。
• 2）系统最终用户从一线业务人员变成企业决策者。
• 3）系统使用从固定操作转向即席查询。
• 4）响应时间的要求不再重要（战略决策分析比例行操作需要花更多的时间）。
• 5）每个操作、查询或流程涉及更多数据。

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

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

3.6 多维数据仓库(Kimball)

  Kimball将数据仓库简单地定义为“专为查询和分析而构建的事务数据的副本”（Kimball，2002）。仓库数据存 储在多维数据模型中。多维模型旨在方便数据使用者理解和使用数据，同时还支持更优的查询性能。多维模型通常称为星型模型，由事实表(包含有关业务流程的定量数据，如销售数据)和维度表(存储与事实表数据相关的描述性属性， 为数据消费者解答关于事实表的问题，如这个季度产品X卖了多少)组成。通过插入遵循维度的总线，可以将多个数据集市集成为企业级的数据集市。

  数据仓库的总线矩阵展示的是生成事实数据的业务流程和表示维度的数据主题域的交汇。

  企业数据仓库总线矩阵独立于技术，可用于表示数据仓库/商务智能系统长期数据的内容需求。图11-3表示Kimball的数据仓库/商务智能架构的数据工厂棋子视图。请注意，Kimball的数据仓库比Inmon的数据仓库的可扩展性更强。

• 1）业务源系统。企业中的操作型/交易型应用程序。这些应用程序产生数据，数据再被集成到操作型数据存储和数据仓库中。
• 2）数据暂存区域。Kimball的暂存区域包括需要集成的流程和用于展示的转换数据，可以与企业信息工厂的集成、转换和数据仓库组件的组合进行类比。
• 3）数据展示区域。关键的架构差异在于“数据仓库总线”的集成范式，如应用于若干个数据集市的共享或一致的维度。
• 4）数据访问工具。Kimball方法侧重于最终用户的数据需求。

3.7 数据仓库组件

  数据仓库环境包括一系列组织起来以满足企业需求的架构组件。下图描述了本节讨论的数据仓库/商务智能和大数据环境的架构组件。下图还描述了数据生命周期的各个方面。源系统–>数据暂存区–>中央仓库–>数据集市或多立方体–>生成各种各样的报表。

• （1）源系统 左侧的源系统包括要流入数据仓库/商务智能环境的业务系统和外部数据。eg:客户关系管理系统
• （2）数据集成 数据集成包括抽取、转换和加载、数据虚拟化以及将数据转换为通用格式和位置的其他技术。
• （3）数据存储区域
  • 1）暂存区。 数据在这里短暂存留，以便可以对其进行转换、集成并准备加载到仓库。
  • 2）参考数据和主数据一致性维度。 参考数据和主数据可以存储在单独的存储库中。
  • 3）中央数据仓库。完成转换和准备流程后，数据仓库中的数据通常会保留在中央或原子层中。
  • 4）操作型数据存储（ODS）。操作型数据存储是中央持久存储的一个解决方案，它能支持较低的延迟，因此可以支持业务应用。
  • 5）数据集市。数据集市面向特定主题域、单个部门或单个业务流程。
  • 6）数据立方体（Cubes）。基于关系数据库的、基于多维数据库的及混合型存储结构的，它们的名称与底层数据库类型有关。

3.8 加载处理的方式

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

• （1）历史数据

  • 数据仓库的一个优势是它可以捕获所存储数据的详细历史记录。
  • Inmon类型的数据仓库建议所有数据存储在单个数据仓库层中。这一层中存储已清洗过的、标准化的和受管控的原子级数据。
  • Kimball类型的数据仓库建议，数据仓库由包含已清洗过的、标准化的和受管控数据的部门级数据集市合并而成。数据集市将在原子级别存储历史记录，由一致性维度表和一致性事实表提供企业级信息。
  • Data Vault，作为数据暂存处理的一部分，同样进行数据清洗和标准化。历史数据以规范化的原子结构存储，每个维度定义了代理键（Surrogate key）、主键（Primary key）、备用键（Alternate key）。

• （2）批量变更数据捕获

  • 数据仓库是通过每天晚上的批处理窗口进行一次数据加载服务。因为不同源系统可能需要不同的变更捕获技术，所以加载过程可以包含各种变更检测。

  • 下表总结了各种变更数据捕获技术之间的差异，包括它们的相对复杂度和加载效率。

    方法	对源系统的要求	复杂度	事实表加载	维表加载	重叠	删除
    时间戳增量加载	源系统中的变化由系统日期和时间戳标识	低	快	快	是	否
    日志表增量加载	捕获源系统中的变化并记录在日志表	中	普通	普通	是	是
    数据库交易日志	在交易日志记录数据库变化	高	普通	普通	否	是
    消息增量	源系统中的变化发布在实时消息(队列)	极高	慢	慢	否	是
    全量加载	没有更改标识符,抽取全表数据并比较判断改动	极低	慢	普通	是	是

• （3）准实时和实时数据加载

  • 批处理的替代方案解决数据仓库中对数据可用性延迟越来越短的要求，有涓流式加载、消息传送和流式传送三种主要的替代方案，它们在等待处理时的数据累积位置不同。
  • 1）涓流式加载（源端累积）。与夜间窗口批量加载不同，涓流式加载是以更频繁的节奏（如每小时甚至每5分钟）或者以阈值的方式（如每300个事务，每1G数据）进行批量加载。
  • 2）消息传送（总线累积）。当极小的数据报（消息、事件或事务）发布到消息总线时，实时或接近实时的消息交互就非常有用。
  • 3）流式传送（目标端累积）。与在源端定时或按阀值加载不同，目标端系统用缓冲区或队列方式收集数据，并按顺序处理。

2.活动

2.1 理解需求

  在收集数据仓库/商务智能项目的需求时, 需要考虑以下几个方面:

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

2.2 定义和维护数据仓库/商务智能架构

  数据仓库/商务智能架构应该描述数据从哪里来、到哪里去、什么时候去、为什么要去，以及用什么样的方式流入数据仓库。

2.2.1 确定数据仓库/商务智能技术架构

• 最佳的数据仓库/商务智能架构将提供一种能够以原子化的数据处理方式支撑交易级和运营级报表需求的机制，这种机制可以避免数据仓库存贮每一笔交易细节。
• 做好原型设计可以快速证明或驳斥关键需求的实现，避免对某些技术或架构进行过大的投入。

2.2.2 确定数据仓库/商务智能管理流程

• 通过协调和集成维护流程进行生产管理，定期向业务团队发布。
• 建立一个有效的发布流程，确保管理层理解这是一个以数据产品为中心的主动流程，而不是已安装产品的被动式问题解决方式。

2.3 开发数据仓库和数据集市

  通常来说，数据仓库/商务智能建设项目有三条并存的构建轨迹：

• 1. 数据。支持业务分析所必需的数据。设计如何修正、转换、集成、存储以及提供给应用程序使用数据的规则。此步骤还包括决定如何处理不符合预期的数据。
• 2）技术。支持数据存储和迁移的后端系统及流程。
• 3）商务智能工具。
  • 1. 将源映射到目标
    • 源到目标的映射为从各个源系统到目标系统的实体和数据元素建立转换规则(逻辑数据模型可实现)。
    • 所有映射工作最困难的部分都是确定多个系统中数据元素之间的链接有效性或等效性
  • 2. 修正和转换数据
    • 强化数据修正或清理活动的执行标准，并纠正和增强各个数据元素的域值。
    • 源端系统应负责数据的修复工作并确保数据正确。
    • 乐观加载策略可以包括创建维度记录以容纳事实数据，过程中必须考虑如何更新和处理这些记录。
    • 悲观加载策略应该考虑一个事实数据的回收区域，该区域不能与相应的维度键关联。

2.4 加载数据仓库

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

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

2.5 实施商务智能产品组合

  实施商务智能组合是为了在业务部门内部或业务部门之间为正确的用户社区选定合适的工具。

• 1. 根据需要给用户分组: 了解用户组；将工具与公司中的用户组进行匹配。
• 2. 将工具与用户要求相匹配: 需要系统资源、技术支持、培训和架构集成。

2.6 维护数据产品

• 1. 发布管理: 发布管理对增量的开发过程至关重要，增加新功能，增强生产部署，并确保为已部署的资产提供定期维护, 将使数据仓库保持是最新的、清洁的，并以最佳状态运行。

• 2. 管理数据产品开发生命周期: 每次迭代都将扩展现有增量，或加入业务团队提出的新功能。版本发布需要保持功 能与业务团队的需求一致，而迭代将使功能与产品经理管理的配置本身 保持一致。
• 3. 监控和调优加载过程: 监控整个系统的加载处理，并了解性能瓶颈和性能的依赖路径。在需要的地方和时刻使用数据库调优技术，包括分区、备份调优和恢复策略调整。数据归档是数据仓库构建中的一个难题。
• 4. 监控和调优商务智能活动和性能: 商务智能监控和调优的最佳实践是定义和显示一组面向客户满意度的指标，如平均查询响应时间，每天、每周或每月的用户数就是有用的指标。透明度和可见性是推动数据仓库/商务智能监控的关键原则。

3.工具

  工具集的选择可能是一个漫长的过程，既要满足近期需求、非功能性规范，还需要考虑尚未产生的后续需求。提供决策标准工具集、流程实施工具和专业服务可以促进和加快此过程，不仅要评估传统的架构或购买策略，还要评估SaaS厂商提供的租赁选项。

3.1 元数据存储库

  元数据存储库的关键是能够将来自各种来源的元数据“黏合”在一起，并使用各种技术实现存储库的自动化和集成填充。

• 1. 数据字典和术语
  • 数据字典是支撑数据仓库使用的必需组件。字典用业务术语来描述数据，包括使用该数据所需的其他信息。
  • 数据字典的内容直接来自逻辑数据模型。
• 2. 数据和数据模型的血缘关系: 记录的数据血缘关系有很多用途：
  • 1）调查数据问题的根本原因。
  • 2）对系统变更或数据问题进行影响分析。
  • 3）根据数据来源确定数据的可靠性。

3.2 数据集成工具

  数据集成工具用于加载数据仓库。除了完成数据集成工作之外，它们还可以将来自多个数据源的复杂数据交付以作业的方式进行调度。在选择工具时，还要考虑系统管理的如下功能：

• 1）过程审计、控制、重启和调度。
• 2）在执行时有选择地提取数据元素并将其传递给下游系统进行审计的能力。
• 3）控制哪些操作可以执行或不能执行，并重新启动那些失败或中止的进程。
• 4. 与BI产品的集成功能，支持工作流消息、电子邮件甚至语义层的导入和导出。

3.3 商务智能工具的类型

• 1）运营报表。是商务智能工具的应用，分析短期（月度）和长期（年度）的业务趋势。
• 2）业务绩效管理（BPM）。包括对组织目标一致性的指标的正式评估，此评估通常发生在高管层面。
• 3）描述性的自助分析。为前台业务提供的商务智能工具，其分析功能可指导运营决策。

3.3.1 运营报表

• 运营报表指的是业务用户直接从交易系统、应用程序或数据仓库生成报表。
• 数据检索和报表工具，有时称为即席查询工具，允许用户编写自己需要的报表或创建供他人使用的报表。
• 业务运营报表中的需求通常与业务查询报告的需求不同。业务运营报表中的需求通常与业务查询报告的需求不同。
• 传统的商务智能工具可以很好地展现表格、饼图、折线图、面积图、条形图、直方图、K线图等一些数据可视化方法。

3.3.2 业务绩效管理

• 绩效管理是一套集成的组织流程和应用程序，旨在优化业务战略的执行。应用程序包括预算、规划和财务合并。
• 从广义上讲，绩效管理技术通过流程帮助组织实现目标。绩效度量和带正反馈回路是关键的要素。

3.3.3 运营分析应用

• 分析型应用程序包括从众所周知的源系统（如应用商ERP系统、数据集市的数据模型、预构建的报表和仪表板）中提取数据的逻辑和流程。
• 在线分析处理（OLAP）是一种为多维分析查询提供快速性能的方法。
• OLAP工具和Cube（数据立方体）的价值是，通过将数据内容与分析师的心理模型对齐，减少混淆和错误解释。
• 常见的OLAP操作包括切片和切块、向下钻取、向上钻取、向上卷积和透视。
• 三种经典的OLAP实现方法如下：）关系型联机分析处理（ROLAP）、多维矩阵型联机分析处理（MOLAP）、混合型联机分析处理（HOLAP）。

4.方法

4.1 驱动需求的原型

• 1. 对数据进行剖析（Profiling）有助于原型设计，并降低与非预期数据相关的风险。
• 2. 对源数据的状态评估，有助于对集成可行性和工作范围进行更准确的前期估算。

4.2 自助式商务智能

• 1. 自助服务是商务智能产品的基本交付方式。
• 2. 根据用户的权限提供各种功能，包括消息传递、警报、查看预定的生产报表、与分析报表交互、开发即席查询报表，当然还有仪表盘和计分卡功能。
• 3. 报表可以按标准计划推送到门户，供用户在空闲时检索。
• 4. 用户还可以通过在门户中执行报表来提取数据。

4.3 可查询的审计数据

• 所有的结构和流程都应该能够创建和存储审计信息，并能够进行细粒度的跟踪和报告。

5.实施指南

5.1 就绪评估/风险评估

  所有IT项目都应该有业务支持，与战略保持一致，并有一个定义好的架构方法。此外，数 据仓库应该能够实现以下几点：

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

  识别并清点数据仓库中敏感或受限的数据元素。在选择工具和分配资源之前，需考虑安全性约束，确保遵循相关审核和批准的数据治理过程。

5.2 版本路线图

  因为需要进行大量的开发工作，所以数据仓库是逐步构建的。无论选择何种实现方法，不管是瀑布式、迭代式，还是敏捷开发，都应该虑到想要实现的最终状态。建议将数据仓库总线矩阵作为一个沟通和推广的工具在逐步迭代的过程中使用。

5.3 配置管理

  配置管理与发布路线图保持一致，并提供必要的后台调整和脚本，以自动化开发、测试和发布到生产。

5.4 组织文化变革

  在整个数据仓库/商务智能生命周期中，始终保持一致的业务重点是项目成功的关键。最重要的是，考虑到以下关键成功因素，将项目与实际业务需求保持一致并评估必要的业务支持：

• 1）业务倡议。是否有合适的管理层支持？
• 2）业务目标和范围。是否有确切的业务需要、业务目标和工作范围？
• 3）业务资源。业务管理层是否承诺提供或聘用相应的业务专家，专家的参与度如何？
• 4）业务准备情况。业务合作伙伴是否准备好这是一个长期的增量交付项目？
• 5）愿景一致。IT战略对业务愿景的支持程度如何？

6.数据仓库/商务智能治理

  数据仓库治理流程应与风险管理保持一致。治理流程应该降低风险，而不是减少任务的执行。最关键的功能是那些管理业务运营的发现或改进区域，以及确保数据仓库本身质量稳定的功能。

6.1 业务接受度

  一个关键的成功因素是业务对数据的接受程度，包括可以理解的数据、具有可验证的质量，以及具有可证明的数据血缘关系。满足验收要求对于每个数据仓库/商务智能实施都是至关重要的，预先还要考虑一些非常重要的架构子组件及其支持活动，具体如下：

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

6.2 客户/用户满意度

  对数据质量的认识将提升客户满意度，但满意度也取决于其他因素，如数据消费者对数据的理解以及运营团队对已识别问题的响应能力。

6.3 服务水平协议

  对具体数仓环境的业务和技术期望应在服务水平协议（SLA）中指定。通常，响应时间、数据保留和可用性要求在不同业务需求类别及其各自的支持系统（如ODS、数据仓库和数据集市）之间存在很大差异。

6.4 报表策略

• 确保BI产品组合内部和跨BI产品组合间都存在报表策略。
• 报表策略包括标准、流程、指南、最佳实践和程序，它将确保用户获得清晰、准确和及时的信息。
• 报表策略必须解决如下问题：
  • 1）安全访问。确保只有获得授权的用户才能访问敏感数据。
  • 2）描述用户交互、报告、检查或查看其数据的访问机制。
  • 3）用户社区类型和使用它的适当工具。
  • 4）报表摘要、详细信息、例外情况以及频率、时间、分布和存储 格式的本质。
  • 5）通过图形化输出发挥可视化功能的潜力。
  • 6）及时性和性能之间的权衡。
• 应定期评估标准报表，以确保它们仍然具有价值，因为报表运行会增加存储成本和处理成本。
• 数据源的治理监控也很重要，确保为授权人员安全地提供适当级别的数据，并且可以根据商定的级别访问订阅数据。

6.5 度量指标

• 1. 使用指标: 数据仓库中使用的度量指标通常包括注册用户数、连接用户数或并发用户数。
• 2. 主题域覆盖率: 主题域覆盖百分比衡量每个部门访问仓库的程度（从数据拓扑的角度来看），还强调哪些数据是跨部门共享的，哪些还不是但也可能是共享的。
• 3. 响应时间和性能指标: 通过工具检索响应或性能指标, 此数据指标代表用户的数量和类型。指标的后续跟进工作是验证和服务级别调整。

7.总结

• 数据仓库（Data Warehouse，DW） 与商务智能（Business Inteligence,BI）作为业务决策主要驱动力协同发展。数据仓库赋能组织将不同来源的数据整合到公共的数据模型，整合后的数据能为业务运营提供洞察，为企业决策支持和创造组织价值开辟新的可能性。
• 业务驱动因素：运营支持职能、合规需求(历史数据响应)和商务智能活动（主因: 提供洞察、提升效率、增强竞争优势。)
• 数据仓库的建设目标： 1）支持商务智能活动。2）赋能商业分析和高效决策。3）基于数据洞察寻找创新方法。
• 数据仓库建设应遵循原则： 1）聚焦业务目标。2）以终为始。3）全局性的思考和设计，局部性的行动和建设。4）总结并持续优化，而不是一开始就这样做。5）提升透明度和自助服务。6）与数据仓库一起建立元数据。7）协同。8）不要千篇一律。
• 活动： 1.理解需求。2.定义和维护 DW 和 BI 架构。3.开发数据仓库和数据集市。4.加载数据仓库。5.实施 BI 产品组合。6.维护数据产品。
• **商务智能：**第一层含义，商务智能指的是一种理解组织诉求和寻找机会的数据分析活动。数据分析的结果用来提高组织决策的成功率。第二层含义，商务智能指的是支持这类数据分析活动的技术集合。
• 数据仓库：一个集成的决策支持数据库和与之相关的用于收集、清理、转换和存储来自各种操作和外部源数据的软件程序。数据集市是数据仓库中数据子集的副本。
• 数据仓库建设：数据仓库中数据的抽取、清洗、转换、控制、加载等操作过程。
• 数据仓库建设的方法。比尔·恩门在《数据仓库》（Building the Data Warehouse ）中定义：数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合。**拉尔夫·金博尔在《数据仓库工具箱》(The DataWarehouse Toolkit）**中提出：主张自下而上（DMDW）的方式，力推数据集市建设，他定义为“为查询和分析定制的交易数据的副本。
• 数据仓库的核心理念: 1) 数据源于其他系统。2）以提升数据价值的方式整合数据。3）便于数据被访问和分析。4）都为了让授权的利益相关方访问到可靠的、集成的数据。5）建设目的涵盖工作流支持、运营管理和预测分析。
• 企业信息工厂（Corporate Information Factory，CIF）： 1）面向主题的。不关注功能或应用。2）整合的。统一的、内聚的。3）随时间变化的。存储的是某个时间段的数据。4）稳定的。数 据不频繁更新，新数据加到老数据后。一组记录可代表交易的不同状态。5）聚合数据和明细数据。即有原子的交易明细，也有汇总后的数据。6）历史的。当前的/历史的。
• 企业信息工厂(Inmon)组成：1）应用程序。2）数据暂存区 3）集成和转换。4）操作型数据存储（ODS）。5）数据集市。6）操作型数据集市（OpDM）。7）数据仓库。 8) 运营报告。 9) 参考数据、主数据和外部数据。
• 数据仓库和集市中的数据与应用程序中的数据不同：1）按主题域而非功能需要组织。2）是整合而非孤立的。3）随时间变化的系列数据而非仅当前时间点的。4）延迟高。5）历史数据多。
• 多维数据仓库（Kimball）：专为查询和分析而构建的事务数据的副本，它不是以实体关系模型的规范化要求组织的。由事实表和维度表组成。
• Kimball 的数据仓库分为业务源系统、数据暂存区域、数据展示区域、数据访问工具四个部分。
• 数据仓库的总线矩阵展示的是生成事实数据的业务流程和表示维度的数据主题域的交汇。
• 数据仓库环境包括： 一系列组织起来以满足企业需求的架构组件。包括源系统，数据集成，数据存储区域等。大数据方案一般会先加载数据，再处理，即 ELT。
• 数据仓库架构组件的数据存储区域包含：
  • 1）暂存区。 介于原始数据源和集中式数据存储库之间的中间数据存储区域。
  • 2）参考数据和主数据一致性维度。
  • 3）中央数据仓库。 数据结构的设计元素包括：①基于性能考虑而设计的业务主键和代理主键之间的关系。②创建索引和外键以 支持维度表。③用于检测、维护和存储历史记录的变更数据捕获（Change Data Capture，CDC） 技术。
  • 4）操作型数据存储 ODS。操作型数据存储包含一个时间窗口的数据而不是全部历史记录， 因此可以比数据仓库有更快地刷新频率。
  • 5）数据集市。 面向特定主题域、单个部门或单个业务流程。
  • 6）数据立方体Cubes。3 种经典的支持在线分析处理系统 OLAP：基于关系、基于多维及混合型存储结构。
• 数据仓库建设涉及两种主要的数据集成处理类型：历史数据加载和持续不断的数据更新。
• 历史数据处理：
  • 1.Inmon 类型的数据仓库建议所有数据存储在单个数据仓库层中。
  • 2.Kimball 类型的数据仓库建议，数据仓库由包含已清洗过的、标准化的和受管控数据的部门级数据集市合并而成。
  • 3.Data Vault，作为数据暂存处理的一部分，同样进行数据清洗和标准化。历史数据以规范化的原子结构存储，每个维度定义了代理键（Surrogate key）、主键（Primary key）、备用键（Alternate key）。
• 批量变更数据捕获。 数据仓库是通过每天晚上的批处理窗口进行一次数据加载服务。
• 准实时和实时数据加载： 1）涓流式加载（源端累积）。2）消息传送（总线累积）。3）流式传送（目标端累积）。
• 数据仓库活动:
  • 【活动 1】理解需求。
  • 【活动 2】定义和维护数据仓库/商务智能架构。
    • 【活动 2-1】确定数据仓库/商务智能技术架构。
    • 【活动 2-2】确定数据仓库/商务智能管理流程。
  • 【活动 3】开发数据仓库和数据集市。
  • 【活动 4】加载数据仓库。
  • 【活动 5】实施商务智能产品组合。
  • 【活动 6】维护数据产品。
• 数据仓库使用的工具:
  • 1.元数据存储库。 2.数据集成工具。 3,商务智能工具
• 运营报表：业务用户直接从交易系统、应用程序或数据仓库生成报表。
• 在线分析处理 OLAP：多维分析查询提供快速性能的方法。
• 就绪评估/风险评估： 从先决条件清单开始，业务支持，与战略保持一致。1）明确数据敏感性和安全性约束。2）选择工具。3）保障资源安全。4）创建抽取过程以评估和接收源数据。
• 组织与文件变革：始终保持一致的业务重点是项目成功的关键。了解企业的价值链是理解业务环境的好方法。要确保数据仓库团队与业务部门团队保持一致。
• 成功的关键：1）业务倡议。 是否有合适的管理层支持？2）业务目标和范围。是否有确切的业务需要、业务目标和工作范围？3）业务资源。 是否有专家？参与度如何？4）业务准备情况。 业务合作是否准备好这是长期的增量交付项目？目标组织内的平均知识水平或技能差距有多大？5）愿景一致。IT 战略对业务愿景的支持程度如何？
• 业务接受度： 一个关键的成功因素是业务对数据的接受程度，包括可理解的数据、具有可验证的质量、具有可证明的数据血缘关系。
• 报表策略要解决： 确保 BI 产品组合内部和跨 BI 产品组合间都存在报表策略。
  业务支持，与战略保持一致。1）明确数据敏感性和安全性约束。2）选择工具。3）保障资源安全。4）创建抽取过程以评估和接收源数据。
• 度量指标：1.使用指标。 包括注册用户数、连接用户数或并发用户数。2.主题域覆盖率。 衡量每个部门访问仓库的程度 3.响应时间和性能指标。 指标的后续跟进工作是验证和服务级别调整。