数据仓库工具箱—读书笔记01(数据仓库、商业智能及维度建模初步)

喻师傅2024-12-15 19:08

数据仓库、商业智能及维度建模初步

记录一下读《数据仓库工具箱》时的思考，摘录一些书中关于维度建模比较重要的思想与大家分享🤣🤣🤣

博主在这里先把这本书"变薄"~有时间的小伙伴可以亲自再读一读，感受一下"变厚"再"变薄"的过程。欢迎交流讨论哈🤣🤣🤣

数据仓库、商业智能及维度建模初步

  • 数据仓库、商业智能及维度建模初步
    • [1.1 数据获取与数据分析的区别](#1.1 数据获取与数据分析的区别)
    • [1.2 数据仓库与商业智能的目标](#1.2 数据仓库与商业智能的目标)
    • [1.3 维度建模简介](#1.3 维度建模简介)
      • [1.3.1 星型模式与OLAP多维数据库](#1.3.1 星型模式与OLAP多维数据库)
      • [1.3.2 用于度量的事实表](#1.3.2 用于度量的事实表)
      • [1.3.2 用于描述环境的维度表](#1.3.2 用于描述环境的维度表)
      • [1.3.4 星型模式中维度与事实的连接](#1.3.4 星型模式中维度与事实的连接)
    • [1.4 Kimball的DW/BI架构](#1.4 Kimball的DW/BI架构)
      • [1.4.1 操作型源系统](#1.4.1 操作型源系统)
      • [1.4.2 获取-转换-加载（ETL）系统](#1.4.2 获取-转换-加载（ETL）系统)
      • [1.4.3 用于支持商业智能决策的展现区](#1.4.3 用于支持商业智能决策的展现区)
      • [1.4.4 商业智能应用](#1.4.4 商业智能应用)
      • [1.4.5 以餐厅为例描述Kimball架构](#1.4.5 以餐厅为例描述Kimball架构)
    • [1.5 其他DW/BI架构](#1.5 其他DW/BI架构)
    • [1.6 维度建模神话](#1.6 维度建模神话)
      • [1.6.1 神话1：维度模型仅包含汇总数据](#1.6.1 神话1：维度模型仅包含汇总数据)
      • [1.6.2 神话2：维度模型是部门级而不是企业级的](#1.6.2 神话2：维度模型是部门级而不是企业级的)
      • [1.6.3 神话3：维度模型是不可扩展的](#1.6.3 神话3：维度模型是不可扩展的)
      • [1.6.4 神话4：维度模型仅用于预测](#1.6.4 神话4：维度模型仅用于预测)
      • [1.6.5 神话5：维度模型不能被集成](#1.6.5 神话5：维度模型不能被集成)
    • 水平有限，欢迎在评论区讨论交流~

数据仓库和商业智能（Data Warehousing and Bussiness Intelligence，DW/BI）系统首先应该考虑的问题是业务需求。

tips：技术服务于业务，不能一味的追求技术上的精进，对于业务的精准把握与理解同等重要😎。

1.1 数据获取与数据分析的区别

信息几乎总是用作两个目的：（书上这两点总结的可以说非常到位了🤣）

  • 操作型记录的保存---操作型系统保存数据。
  • 分析型决策的制定---DW/BI系统使用数据。

（1）操作型系统 的用户确保组织正常运转。🍬

  • 对操作型系统进行优化的目的---更快地处理事务。

  • 操作型系统一般一次处理一个事务记录，通常不必维护历史数据，只需修改数据以反映最新的状态。

（2）DW/BI系统 的用户研究分析企业的运转，并对其性能进行评估。🍬

  • 分析并判断操作型过程是否处于正确的工作状态。
  • DW/BI系统一般不会一次只处理一个事务（回答用户的查询通常需要搜索成千上万的事务，并将查询结果放入一个查询集合中）。
  • DW/BI系统的用户通常要求保存历史环境，用于精确地评估组织在一段时间内的性能。
  • 对DW/BI系统进行优化的目的是高性能的完成用户的查询。

1.2 数据仓库与商业智能的目标

书中引入了几个挺有意思的话题：🤣🤣🤣

  • 🍕我们收集了海量的数据，但无法对其访问
  • 🍔我们需要以各种方式方便地对数据进行切片以及切块
  • 🍟业务人员需要方便地获取数据
  • 🌭将最重要的事情展示给我
  • 🍿会议自始至终争论的是谁的数字正确，而不是制定决策
  • 🥞我们希望人们能过够使用信息来支持更多的基于事实的决策制定

大家看了上面的topic，想必已经对DW/BI系统需要解决的问题以及目标有所感悟🤣🤣🤣。

摘录一下书中关于DW/BI系统目标最重要的两点：

  • （1）DW/BI系统必须成为提高决策能力的权威和可信的基础。

  • （2）DW/BI系统成功的标志是业务群体接受DW/BI系统。

书中关于DW/BI系统管理者的责任总结的非常到位，列位可以向这些目标所靠拢，思考一下怎么去做好自己的工作。（不要感觉枯燥，个人认为文中讲的每一点都值得仔细推敲，能做到这些都是业界翘楚啦🤣🤣🤣）

（1）理解业务用户🍕

  • 理解他们的工作责任、目标和任务🍞

    tips（个人见解）：理解业务用户的日常职责、面临的挑战以及他们需要达成的目标是什么。了解这些，才能确保系统提供的功能是符合他们需求的。

  • 确定商业用户在制定哪些决策时需要DW/BI系统的帮助🥐

    tips（个人见解）：不同的业务用户需要DW/BI系统帮助的决策点不同。明确哪些决策点是关键，并为这些决策提供必要的支持。

  • 识别出那些制定高效、高影响决策的"最佳用户"🥨

    tips（个人见解）：并不是所有用户的决策对公司影响一样大。有些人负责的是战略层面的决策，他们的决策可能对公司发展有着更大影响。需要识别出这些关键人物，确保他们能够得到系统支持。

  • 发现潜在的新用户，并让他们意识到DW/BI系统能够给他们带来什么能力🥖

    tips（个人见解）：在公司中，可能有一些部门或角色还没有充分意识到DW/BI系统的价值。应该主动发现这些潜在的新用户，向他们展示如何通过数据分析提升工作效率或决策质量。

（2）对业务用户发布高质量、相关的、可访问的信息和分析🍕

  • 选择最健壮、可操作的数据放入DW/BI系统中🧀

    tips（个人见解）：数据是DW/BI系统的核心，但并不是所有数据都值得投入 。需要确保选择的是最有用、最可靠的数据，这些数据应该能够支持业务决策，并且是容易被使用和理解的。

  • 简化用户接口和应用，采用模版驱动方式，与用户的认知过程轮廓匹配🥗

    tips（个人见解）：为了让业务用户能够顺利使用DW/BI系统，应该简化用户界面，并通过模板等方式帮助用户轻松获取所需的信息。就好像把复杂的报表变成一个简单的图表，用户看得懂、用得方便。

  • 确保数据精确、可信，使其标识在整个企业具有一致性🥙

    tips（个人见解）：如果系统中的数据不准确，业务决策将会受到严重影响。确保数据的质量和一致性是底线。比如，财务部门的数据与销售部门的数据必须一致，不能因为数据的差异导致错误的决策。

  • 不间断地监控数据和分析的准确性🥪

    tips（个人见解）：DW/BI系统不是一次性建设完成的，而是一个持续更新的过程。需要定期监控数据的质量，确保信息和分析的准确性。如果发现问题，及时修正，避免误导业务决策。

  • 适应用户不断变化的思维方式、需求和业务优先级，及新数据源的可用性🌮

    tips（个人见解）：业务环境在不断变化，用户的需求和思维方式也在变化。需要快速响应这些变化，不断调整系统，满足用户新的需求和新的数据源。

（3）维护DW/BI环境🍕

  • 采用DW/BI系统制定的成功的业务决策，验证人员配置及要投入的开支🥫

  • 定期对DW/BI系统进行更新🍖

    tips（个人见解）：技术和业务需求都在不断发展，DW/BI系统需要不断进行更新和优化。这不仅仅是技术上的更新，还包括数据、模型和功能上的更新，确保系统始终满足业务需求。

  • 保持业务用户的信任🥩

    tips（个人见解）：用户对系统的信任是系统能否成功应用的关键。如果业务用户认为系统的数据不准确，或者界面难用，他们就不会愿意使用。需要保证系统的稳定性、可靠性，并且定期与用户沟通，解决他们的疑虑，保持他们的信任。

  • 保持业务用户、执行赞助商和IT管理层满意度🍠

    tips（个人见解）：DW/BI系统的成功不仅仅是技术团队的责任，还需要业务部门的支持、管理层的赞助和持续投入。确保各方面的利益相关者都对系统感到满意，确保系统能够持续发展和优化。

1.3 维度建模简介

维度建模并不是一种新技术，早期主要用于简化数据库。简单性至关重要，确保快速有效发现、公布结果。

维度建模是展现分析数据的首选技术：

  • 以商业用户可理解的方式发布数据。
  • 提供高效的查询性能。

从简单的数据模型开始是保持设计简单性的基础。如果从复杂的数据模型起步，最终会导致模型过度复杂，查询性能低下，最终使商业用户反感。

尽管维度模型通常应用在关系数据库管理系统上，但是并不要求维度模型必须满足3NF（第三范式）。

  • 3NF主要是为了消除冗余，规范化的3NF将数据划分为多个不同的实体，每个实体构成一个关系表。（满足3NF可能会出现"北京地铁线路图"，超级复杂😂😂😂）
  • 业界有时将3NF模型称为实体-关系模型 （ER模型---实体关系图表示了表间的交互关系）。但是3NF和维度模型都可以用ER模型表示 ，因为都包含可连接的关系表。主要差别在于规范化程度 ，书中强调不要将ER模型当成3NF模型。
  • 规范化的3NF模型主要应用于操作过程中，因为对事务的更新与插入仅仅触及数据库的单一地方。
  • 然而，对于BI查询来说，规范化模型太复杂，用户难以理解、检索。维度建模则解决了模式过分复杂的问题。

Tips:😎 维度模型包含的信息与规范化模型包含的信息相同，但将数据以一种用户可理解的、满足查询性能要求的、灵活多变的方式进行了包装。

1.3.1 星型模式与OLAP多维数据库

  • 在RDBMS中实现的维度模型称为星型模式（结构类似星星🤣🤣🤣）。
  • 在多维数据库环境中实现的维度模型通常称为联机分析处理（OnLine Analytical Processing,OLAP）多维数据库。
  • 如果采用的DW/BI环境包括星型模式或者OLAP多维数据库，则可以说是利用了维度概念。

1.3.2 用于度量的事实表

  • 维度模型中的事实表 存储组织机构业务过程事件的性能度量结果 。"事实 "这一术语 表示某个业务度量。

  • 应该尽量将来源于同一个业务过程的底层度量结果存储于一个维度模型中 。因为度量的数据量巨大，所以不应该为满足多个组织功能的需要而将这些数据存放在多个地方。

  • 应该允许多个组织的业务用户 访问同一个单一的集中式数据仓库 ，确保他们能在整个企业中使用一致的数据 。（保持一致性🤣🤣🤣）
  • 事实表中的每行对应一个度量事件 。每行中的数据是一个特定级别的细节数据，称为粒度。
  • 维度建模的核心原则之一 ------同一事实表中所有度量行必须具有相同的粒度（确保不会出现重复计算度量的问题）。

Tips😎：

  • 物理世界的每一个度量事件与对应的事实表行具有一对一的关系，这一思想是维度建模的基本原则。其他工作都是以此为基础建立的。
  • 最实用的事实是数值类型和可加类型事实 ，可加性至关重要，因为BI应用不太可能仅仅检索事实表的单一行。🤣🤣🤣 一般都是一次检索成百上千行甚至百万级别的事实表行(最有用的操作就是把他们加在一起)。
  • 一般事实表具有两个或者更多的外键与维度表中的主键关联，可以通过维度表使用连接操作来实现对事实表的访问 。
  • 通常几个维度一起唯一标识每一个事实表行。
Sales_ID Customer_ID Product_ID Date_ID Store_ID Sales_Amount Quantity_Sold
1 C001 P001 20240101 S001 50 2
2 C002 P003 20240102 S002 30 1
3 C003 P002 20240103 S001 75 3
  • 如果没有相关维度，不要试图以0表示没有活动发生来填充事实表，因为这些0将会占据大量的事实表。
  • 从行的数量来看，事实表趋向于变长。从列的数量来看，事实表趋向于变短。鉴于事实表占据大量空间的实际情况，应该仔细考虑对事实表空间的利用问题。

1.3.2 用于描述环境的维度表

  • 维度表包含与业务过程度量事件有关的文本环境（"谁、什么、哪里、何时、如何、为什么"）。

  • 维度属性可以作为查询约束、分组、报表标识的主要来源。维度属性对构建DW/BI系统的可用性和可理解性也起着非常重要的作用（属性应该是真实使用的词汇而不是令人迷惑的缩写）。

  • 与事实表比较，维度表趋向于包含较少的行，但由于可能存在大量文本列而导致存在多列的情况。
  • 维度表通常以层次关系表示。例如产品抽象为品牌，然后抽象为类别。（层次描述信息虽然存在冗余，但可以方便使用和提高查询性能。）
产品链 产品描述 品牌名称 类别名称
P001 Phone A Apple Electronics
P002 Phone B Samsung Electronics
P003 Sports Shoes C Nike Sportswear
P004 Laptop D Dell Electronics
P005 Running Shoes E Adidas Sportswear
P006 Sofa F IKEA Furniture
  • 维度表通常不一定要满足3NF，常常是非规范化的，一个维度表往往存在多对一的关系。

Tips😎：

  • 一个数字量到底是事实还是维度属性，对设计者来说是一个两难的问题 。一般认为：连续值数字基本上可以认为属于事实，来自于一个不太大的列表的离散数字基本可认为是维度属性。
  • 多数情况下，数据仓库的好坏直接取决于维度属性的设置；DW/BI环境的分析能力直接取决于维度属性的质量和深度。------强大的维度熟悉带来的回报是健壮的分片-分块能力。

1.3.4 星型模式中维度与事实的连接

维度模型表示每个业务过程包含事实表，事实表存储事件的数值化度量，围绕事实表的是多个维度表，维度表包含事件发生时实际存在的文本环境。

  • 维度模型首先需要注意的是其简单性（对业务用户有利，属于易于理解和查询）和对称性。
  • 维度模型的简单性也会带来性能方面的好处。数据库优化器在处理这些很少使用连接操作的简单模式会更加高效。
  • 维度模型非常适于变化。每个维度的地位都相同，所有维度在事实表中都存在对应的入口点。如果业务用户建议采用新的模式分析业务，不需要调整模式（例如需要添加一个新的维度（比如"渠道"维度），只需要在维度表中添加一个新的维度数据表，并且通过外键与事实表连接即可）。

1.4 Kimball的DW/BI架构

Kimball的DW/BI架构分为四个不同的组成部分：

  • 操作型源系统、ETL系统、数据展现、商业智能应用。

1.4.1 操作型源系统

  • 操作型源系统 是指产生原始数据的业务系统 ，也就是日常运营中使用的系统（主要关注处理性能和可用性）。
  • 操作型源系统中的数据通常是事务性的、实时的 ，用于支持日常的业务操作。源系统中的数据是进入数据仓库的基础。
  • 数据的结构通常是 规范化的 （即数据尽量避免冗余），以优化数据的存储和处理效率。
  • 源系统一般不维护历史信息，好的数据仓库可以更好地承担源系统表示过去情况的责任。

1.4.2 获取-转换-加载（ETL）系统

ETL（Extract, Transform, Load）系统是整个数据仓库架构中的关键部分。它的主要任务是从操作型源系统中获取数据，进行必要的转换，并将数据加载到数据仓库中。

  1. 获取（Extract）：

    • 从操作型源系统中提取数据。这些数据可以来自不同的数据库、文件系统、API等。
    • 获取过程需要从不同的数据源抽取数据，并确保数据的完整性。

  2. 转换（Transform）：

    • 数据在ETL过程中需要进行转换，使其符合数据仓库的设计要求和业务需求。转换的过程可能包括：
      • 清洗：例如，处理缺失数据、去除重复数据、规范化字段格式（如日期格式统一）。
      • 计算：进行各种业务计算，如汇总、加总、平均值计算等。
      • 映射和整合：将来自不同系统的数据映射到统一的标准，合并不同数据源中的信息。
      • 数据质量验证：确保数据的正确性和一致性。

  3. 加载（Load）：

    • 将清洗和转换后的数据加载到数据仓库中。根据数据仓库的设计，数据可以按 批量加载 （如每晚一次）或者 实时加载（如使用流式处理）。

ETL系统的目标是确保数据仓库中的数据是高质量、统一的，并且能够快速响应业务决策的需求。

1.4.3 用于支持商业智能决策的展现区

展现区（Presentation Layer）是数据仓库的核心部分，也是支持商业智能（BI）决策的基础。这个区域存储着经过ETL处理、符合查询需求的数据。

展现区的设计通常遵循以下模式：

  • 星型模式（Star Schema） ：在这种模式下，数据仓库的核心是 事实表 ，它包含了业务数据（如销售数量、金额等）。围绕事实表，存在多个 维度表，它们提供了业务数据的上下文（如时间、产品、客户等）。星型模式简单、易理解，适合高效查询。

  • 雪花模式（Snowflake Schema）：与星型模式相似，但维度表进一步规范化，形成类似雪花形状的结构。虽然雪花模式减少了数据冗余，但查询性能相对较差，通常适用于需要较复杂分析的情况。

  • 数据集市（Data Mart） ：对于大型企业来说，可能会将整个数据仓库分成多个小的 数据集市，每个数据集市针对特定部门或业务领域（如销售数据集市、财务数据集市等）。数据集市通常是数据仓库的一个子集，能够提供特定部门所需的数据。

Tips：

《数据仓库工具箱》第三版中关于展现区设计的重要原则：

  1. 数据应该以维度模型来展现（星型模型或OLAP多维数据库）：

    • 维度模型 是数据仓库中的一种常见结构，主要用于支持高效的查询和分析。在展现区，数据应该通过星型模型 或OLAP多维数据库来组织和展现。
    • 星型模型由一个中心的事实表和多个与其相连的维度表组成。这种结构非常直观，易于理解，适合快速查询和多维分析。
    • OLAP多维数据库 则是另一种将数据按照多个维度组织的方式，通常通过数据立方体来实现，支持更加灵活和复杂的查询方式，如切片、切块、钻取等。
    • 维度模型的设计有助于高效地支持报表和数据分析，它可以将复杂的数据结构简化为便于理解和查询的格式。

  2. 必须包含详细的原子数据：

    • 展现区不仅要提供汇总和聚合数据，还应当包含详细的原子数据。这些原子数据是数据仓库中的基础单元，是任何高级分析或报表的构建基础。
    • 原子数据通常来自于数据仓库的事实表，它包含每个事件或交易的基本信息，如销售记录、交易金额等。通过提供原子数据，业务用户可以更深入地分析数据，进行详细的钻取、追踪和分析。
    • 例如，销售数据不仅应该提供销售额的汇总，还应该包括每一笔交易的详细记录，支持用户进行更精细的分析和探索。

  3. 围绕业务过程度量事件来构建：

    • 展现区的数据应该围绕业务过程度量事件来构建。业务过程是指企业运作中的关键活动或操作，如销售、生产、库存等。每一个业务过程通常会产生度量数据（如销售额、生产数量等）。
    • 在设计展现区时，应该确保这些业务过程的度量数据在事实表中得到体现，并且能够被按不同的维度进行分析。例如，销售过程的度量数据可以按时间、区域、产品等维度进行分析，帮助决策者更好地理解业务情况。
    • 这种以度量事件为核心的设计方式有助于确保数据仓库中的数据反映了实际的业务活动，符合业务需求。

  4. 必须使用公共且一致的维度建立维度结构，遵守总线结构：

    • 展现区应该使用公共且一致的维度来构建维度结构。维度表是数据仓库中用来描述和分析数据的结构，它们与事实表中的度量数据一起使用来生成报表和分析视图。
    • 总线结构是一种标准化的数据仓库设计方法，要求在整个数据仓库中使用一致的维度。这些维度表应当在所有数据集市中共享，以确保不同部门或功能区域使用的是一致的数据。
    • 使用一致的维度结构有助于确保跨业务部门或功能区域的数据能够进行一致性分析，并提高数据的可维护性和可扩展性。例如，客户维度、时间维度、产品维度等应该在整个数据仓库中保持一致，避免不同区域或部门使用不同版本的维度数据。

1.4.4 商业智能应用

商业智能应用是最终用户用来访问数据仓库和展现区的工具。它们包括各种用于数据分析、报告和决策支持的应用程序和工具。

  • 报表工具：用于生成定期的业务报告。例如，财务报告、销售报告等。

  • 仪表盘（Dashboards）：可视化工具，帮助用户实时查看业务关键指标（KPI），例如销售额、利润、库存等。仪表盘通常用于监控和跟踪实时业务数据。

  • OLAP（在线分析处理）工具：支持多维分析，让用户能够从不同的角度分析数据。例如，用户可以按时间、地点、产品等多个维度查看销售数据。

  • 数据挖掘工具：用于深入分析数据，发现潜在的趋势、模式和关系。例如，预测模型、客户行为分析等。

  • 自助式BI工具：例如Tableau、Power BI等，它们使业务用户能够不依赖IT部门，自主探索数据、生成报告和创建可视化图表。

1.4.5 以餐厅为例描述Kimball架构

在《数据仓库工具箱》第三版的1.4.5节中，书中通过餐厅 的例子来描述了Kimball架构：

餐厅的运营流程：

  1. 顾客点餐 ：顾客是餐厅的用户，他们通过点餐开始了整个过程。在这个比喻中，顾客就代表了业务用户，他们需要通过数据仓库来获取所需的信息。
  2. 厨房准备食物 ：餐厅的厨房代表着数据仓库的ETL过程 （数据提取、转换和加载）。数据从不同的来源系统提取出来，经过清洗和转换，最终被准备好（类似食物的准备过程），然后进入展现区，供顾客（业务用户）享用。
  3. 菜单设计 ：餐厅的菜单类似于数据仓库中的数据模型 ，它列出了顾客可以选择的各种菜品。在数据仓库中，菜单是指数据模型的设计，例如使用维度模型（如星型模型）来组织和展示数据，确保业务用户能够通过简单的查询快速获得所需信息。
  4. 顾客享用餐食 ：顾客最终通过餐厅的服务（例如点餐系统、服务员等）享用食物，这个环节对应了数据仓库的用户访问层。业务用户通过BI工具或其他应用程序，访问和分析数据，以支持决策。

Kimball架构的关键特点：

  1. 业务需求驱动 ：餐厅的设计和菜单是根据顾客需求来决定的，类似地，Kimball架构强调数据仓库的设计必须从业务需求出发，确保数据仓库能够满足最终用户的需求。
  2. 数据集市（Data Mart） ：餐厅的菜单可以看作是不同的数据集市 。在Kimball架构中，数据仓库通常被分为多个数据集市，针对不同的业务领域（如销售、财务、客户等）进行优化。这些数据集市通过共享的维度模型（如星型模型）来整合成一个整体的企业数据仓库。
  3. ETL流程：数据仓库的ETL流程就像餐厅的厨房一样，负责从多个数据源提取数据、进行清洗和转化，然后将数据加载到数据仓库中的事实表和维度表。这个过程确保了数据的质量和一致性。
  4. 共享维度 ：餐厅的菜单上的菜品和价格等信息是统一的，Kimball架构 要求所有的数据集市都应使用公共且一致的维度，例如客户、时间、产品等维度，从而确保跨部门和跨业务领域的数据能够一致地进行分析和报表生成。
  5. 以分析为驱动：餐厅不仅要提供美食，还要根据顾客需求不断调整菜单。同样，数据仓库的设计不仅仅是为了存储数据，更是为了支持分析和决策。因此，Kimball架构强调围绕业务过程（如销售、生产、库存等）来设计数据仓库，确保数据能够高效支持各种业务分析需求。

1.5 其他DW/BI架构

这一小节不太重要，略过啦~

1.6 维度建模神话

维度建模（尤其是星型模型）是数据仓库设计的核心，但它也有一些误解存在，这些误解可能导致数据仓库设计的误区。

《数据仓库工具箱》第三版1.6节中关于维度建模的一些常见误解做出的解释：

1.6.1 神话1：维度模型仅包含汇总数据

  • 神话内容：许多人认为维度模型只处理汇总数据，即将大量的详细数据聚合到一个简化的视图中，进行统计分析。

  • 现实 ：实际上，维度模型不仅包含汇总数据，还包含原始的、详细的事务数据。维度模型的目的是让用户能够灵活地对数据进行多维度查询和分析。这些维度表中的数据可以支持从汇总到细节的各种查询。比如，用户不仅可以查询"销售总额"，还可以钻取到每一笔具体的销售记录。

    结论：维度模型可以同时存储详细数据和汇总数据，提供更深层次的分析能力。

1.6.2 神话2：维度模型是部门级而不是企业级的

  • 神话内容：有人认为维度模型仅适用于某一部门（如销售、财务等）级别的业务分析，而不能跨部门或跨企业进行整合。

  • 现实 ：维度模型的设计可以是企业级的 ，通过使用共享的维度（例如，时间、客户、产品等）来保证跨部门的数据一致性。这种设计方式能够促进跨部门的数据整合，使得整个企业的数据仓库形成统一的数据视图。例如，一个企业可以有多个部门的数据集市，但这些集市都会共享一个统一的客户维度、时间维度等，确保数据的一致性和互操作性。

    结论：维度模型设计可以服务于整个企业，而不仅仅是某个部门。通过共享维度，维度模型能够实现企业级的数据整合和分析。

1.6.3 神话3：维度模型是不可扩展的

  • 神话内容：有些人认为维度模型一旦设计好，就无法扩展或修改。例如，增加新的维度或度量项会很困难。

  • 现实 ：维度模型具有很高的可扩展性。随着业务需求的变化，新的维度、事实表或度量项可以轻松地被添加到现有的模型中。例如，可以根据新的业务需求，增加客户地域、产品类别等维度，或者增加新的指标（如新的销售渠道或服务类型）。通过适当的设计，维度模型能够适应业务的发展，支持业务的不断扩展。

    结论：维度模型具有很好的可扩展性，能够根据业务需求的变化灵活调整。

1.6.4 神话4：维度模型仅用于预测

  • 神话内容：有人误以为维度模型仅用于预测分析（如趋势预测、需求预测等），而不适用于其他类型的数据分析。

  • 现实 ：维度模型广泛应用于各种类型的数据分析，不仅仅局限于预测。它能够支持包括历史数据分析、运营数据监控、性能分析等多种分析需求。维度模型通过多维度视角支持报表生成、趋势分析、KPI（关键绩效指标）分析等各类业务决策，帮助企业在多个维度上进行深入分析。

    结论：维度模型不仅适用于预测分析，还可以广泛用于历史数据分析、报表生成、趋势分析等多种类型的商业智能分析。

1.6.5 神话5：维度模型不能被集成

  • 神话内容：有些人认为维度模型无法与其他数据源（如大数据平台、数据湖等）进行集成，因此它只能在传统数据仓库环境中使用。

  • 现实：维度模型是非常灵活的，可以与多种不同的数据源集成，包括传统的关系型数据库、大数据平台、云数据仓库以及数据湖等。通过适当的数据集成方法和工具，维度模型可以从多种数据源抽取数据，并统一存储和管理。无论是从结构化数据源，还是从非结构化数据源（如日志数据、文本数据等）获取的数据，都可以集成到维度模型中，进行统一分析。

    结论：维度模型不仅能与传统数据仓库集成，还可以与大数据平台、云计算和数据湖等现代数据架构集成。

水平有限，欢迎在评论区讨论交流~

相关推荐
上辈子杀猪这辈子学IT4 小时前
【Hive数据仓库】Hive部署、Hive数据库操作（增删改查）、表操作（内部表、外部表、分区表、桶表）
大数据·数据库·数据仓库·hive·hadoop
靠谱杨4 小时前
数据仓库、大数据平台和数据中台都是指什么
大数据·数据仓库·etl工程师·数据中台
sunxunyong5 小时前
hive 小文件分析
数据仓库·hive·hadoop
键道码屋10 小时前
【Hive 如何进行update更新？】
数据仓库·hive·hadoop
liuwufei11 小时前
数据仓库-基于角色的权限管理(RBAC)
数据库·数据仓库·oracle
风子~19 小时前
hive—炸裂函数explode/posexplode
数据仓库·hive·hadoop
liuwufei1 天前
数据仓库-用户管理实践
数据库·数据仓库·oracle
liuwufei1 天前
数据仓库-集群管理
数据仓库
PersistJiao1 天前
调度系统：分析 Apache Airflow 和 Prefect 在 基于Couchbase构建数据仓库 和 ETL任务调度 的场景下，哪一个更合适
数据仓库·apache·etl
热门推荐
01WPS-0DAY-20230809的分析和利用复现02玄机平台应急响应—webshell查杀03(欧拉)openEuler系统添加网卡文件配置流程、(欧拉)openEuler系统手动配置ipv6地址流程、(欧拉)openEuler系统网络管理说明04如何解决电脑无声问题：排除故障的几种常见方法05MacBook外接键盘修改键位06Docker 夺命连环 15 问07文心一言最新重磅发布！08【凡人修仙传_01】散修厉飞羽是如何出师未捷身先死的！09PyTorch机器学习实现液态神经网络10硬件知识积累 USB 接口 type - A type - B type - C 的介绍与功能说明 （简单介绍）