问题标签 [dimensional-modeling]

假设，假设我在数据仓库设置中有一个星型模式。有一个非常非常长的事实表（想想数十亿到数万亿行）和几个低基数维度表（想想 100 个维度表）。每个指向维度表主键的事实表外键都被位图索引。每个维度表的主键也是位图索引的。这都是为了快速加入。都很标准。

假设数据仓库开始出现性能下降。从位图连接返回结果所需的时间越长，事实表越长。业务需求是事实表不断增长（我们不能将超过一年的数据移至归档存储）

我正在考虑以下解决方案：

1. 哈希分区事实表，但这只是暂时阻止了不可避免的增长问题。
2. 数据库将物理星型模式数据库划分为多个模式/数据库。1..N 个事实表及其维度副本，每个都保存通过 hash(1..N) 函数分配给它们的数据，该函数在单独的 ETL 暂存数据库中执行以确定事实行的数据库/模式（由 ETL 产生过程）将进入。如果任何维度发生更改，请将更改复制到其他数据库对应的维度。同样，这不会作为永久解决方案。
3. 折叠维度并将所有维度值直接存储在事实表中。然后，将事实表导入到 HBASE on Hadoop。你得到一个巨大的 HBASE 表，没有维度表的键值存储。我会这样做是因为连接在 HBASE 中的成本过高（因此实际上没有维度连接，只需在维度列上强制执行维度值）。

以前有人做过吗？

有人对解决方案＃3有任何提示吗？

就通过快速读取进行扩展而言，HBASE 解决方案是最优的吗？

就写入而言，我不关心快速写入，因为它们会在下班时间作为批处理过程完成。

如果有人选择了解决方案 1 或 2，是否有人使用了一致的散列算法（如果更多分区、散列键是动态创建的，以避免像在普通旧散列中那样重新映射）？没有完整重新映射的分区数量的动态增长可能不是一个选项（就分区表而言，我还没有看到它在实践中完成）所以在我看来，任何分区解决方案都会导致扩展问题。

将具有多维的巨型事实表（传统的 DW 星型模式）移动到 HBASE 巨型无量纲表有什么想法、建议和经验？

相关问题：

如何在数据中聚合传统上驻留在物化视图中的数据集合（或者作为链接到与最细粒度的事实表相同的维度的单独事实表 - 即每小时/每天/每周/每月，其中基本事实表是每小时一次）仓库映射到 HBASE？

我的想法是，由于 HBASE 中没有物化视图，因此聚合数据集合存储为 HBASE 表，这些表在最细粒度、最低级别的事实表发生更改时随时更新/插入。

对 HBASE 中的聚合表有什么想法吗？是否有人使用 Hive 脚本从本质上模仿物化视图的行为，以在更改最细粒度的事实表时更新存储在其中的聚合数据的辅助 HBASE 表中的聚合列数据（即daily_aggregates_fact_table、weekly_aggregates_fact_table、monthly_aggregates_fact_table）？

我想为餐厅销售交易设置一个事实表。将整个事实表相加将得出整个餐厅的全部销售额。这家餐厅有两个主要的收入来源——食品和饮料。每个的尺寸都非常不同。

例如，对于食物，我可能想跟踪它是否不含乳制品、不含麸质等。或者我可能想查看这道菜是意大利菜还是法国菜等。对于葡萄酒，我可能对年份感兴趣，其中酒来自，酒是什么葡萄。

如何使用一个事实表完成此操作？如果项目是食物，我是否应该简单地拥有一个为 NULL 的 Wine 维度，如果项目是葡萄酒，我是否应该拥有一个为 NULL 的 Food 维度？

我正在尝试实现 Kimball 数据集市，它在维度表中使用 -1 和 -2 行来表示迟到的维度和 NULL 业务键。我在下面有一个示例代码，它为事实和维度数据创建一个临时表，为数据集市创建两个维度表和一个事实表。这是我的示例代码，其中包含 SQL 中的数据：

如何为源系统中缺少业务键的行分配 -2。您可以从 Kimball 阅读更多关于此实现背后的理论：

• Kimball 设计技巧 128
• Kimball 设计技巧 78

这基本上是我想要实现的目标：

处理维度和度量中的 NULL

编辑：

我想我可以在左连接中使用COALESCEor ISNULL，它似乎产生了正确的结果：

寻求一点帮助来阐明维度模型。我正在研究归结为 Web 事件分析的内容 - 给定 Web 日志，我想解析和存储 URL 中存在的变量。诀窍是这些变量并不总是预定义的，有时，一个变量可能包含多个值。

让我们看一个假设。如果我有一个查询字符串

session_id=SID&key1=value1&key2=value2&key3=value3a&key3=value3b&key3=value3c

我的目标是能够通过这些键的任意组合来计算聚合。例如，我可能会说“有多少页面点击的 key3 值为 value3a”，或者“有多少页面点击的 key1 值为 value1，而 key3 的值为 value3b”。为了增加复杂性，最终可能会出现 key4 和 key5 等，并且可能没有足够的预警来能够在值出现之前进行维度模型更改。

一种方法可能是创建 3 个维度表，dim_key1、dim_key2和dim_key3，每个表都有一个id字段和一个value字段。

然后我的事实表可能看起来像

id, session_id, dim_key1, dim_key2, dim_key3, count

这样做的缺点是我需要在我的事实表中创建 3 行，以便key3从查询字符串中正确捕获 3 个值。此外，对于出现的每个维度，我都需要提前通知，并且需要创建我的新维度表。

另一种可能的方法，更适合 dim_key3，可能是创建一个维度表，如

id, value3a, value3b, value3c, ...

其中该表中的行由表示这些值组合的 1 和 0 组成。例如，上面的查询字符串会有一行看起来像1, 1, 1, 1, 0, 0, ...，并且页面命中事实表的 dim_key3 维度 id 为 1。

从好的方面来说，每个页面点击在事实表中只有一个条目，并且维度表可以保持稀疏表示，我们只在其中为我们实际看到的组合创建新行（即我们不需要所有 key3 组合的幂集）。不利的一面是，每个新值key3仍然需要在该暗表中添加一个新列。

最后一个想法，fordim_key3将有一个类似 的表id, value_list，其中value_list存储以逗号分隔的值列表。它与“每个值的列”方法类似，但只是保持了更紧凑的表示。在这种情况下，我们可能有一个维度行，如1, "value3a,value3b,value3c".

同样，这只需要事实表中的一行，并且作为一个额外的优势，当新值出现时不需要新列。缺点是它迫使查询变得复杂，不得不进行全文匹配/正则表达式。（如果有兴趣，我可以深入探讨，但我觉得我已经进行了足够长的时间）。

我查看了几个参考资料，包括 Kimball 的“数据仓库工具包”，但没有找到任何可以直接回答我问题的内容。大多数点击/网络/事件流分析维度模型示例都有一组固定不变的奇异值变量。

我概述的三种方法中的任何一种是否合理，和/或是否有人对我错过的另一种模型有任何建议？

提前致谢！

环境：SSAS 2005，投标 2008。

数据架构：

系主任

• 部门编号int (PARENT)
• SubDepartmentNumber int (CHILD)

分类大师：

• DepartmentNumber int 引用 DepartmentMaster.DepartmentNumber
• 类别编号 int

我想要的功能：

• 分层钻取：
  
  • 部门 -> 类别
  • 部门 -> 子部门 -> 类别

通过以下方式实现：

• 类别维度
• 部门维度
  • 子部门和部门的父子层次结构。

为什么这是一个问题：

我觉得 Category 真的应该在同一个 Dimension 中，叫它“Product”或“Item”。最初，没有子部门，这就是我设置它的方式：

• 物品尺寸
  • 部门 -> 类别

不幸的是，一旦在部门级别引入了父实体，我就无法再以正确（或根本）构建的方式配置属性关系。

我的问题：

是否可以配置这些关系，使它们都在一维中，给我上面描述的层次结构？如果有可能 - 我应该吗？是不是因为我一开始就做错了，所以效果不好？

目前我有一个如下表：

日期 01/01/1900，这意味着没有配偶/孩子。我想像下面这样转换这个表：

但是这个表仍然不能提供在特定时间 (01/01/2006) 和 (01/01/2011) 回答这个问题的最佳方法，用户 1 有几个孩子？答案是 1 和 2。而且我还发现很难从表 1 转换为表 2，我被困在如何为相同的 user_id 创建新行。关于如何改善这种情况或解决转换表问题的任何想法？非常感谢您的帮助。先感谢您。

我正在尝试为从多个表中采购的客户偏好建立一个维度。

源表示例如下：

我已经构建了 Dim Customer，现在我必须设计 Customer Preference Dimension。新维度将是 SCD1；始终拥有客户的最新偏好。但是给定的客户可以有多种组合。

现在我的问题是：为每个首选项表设计维度是否好，我是否应该将客户的所有首选项属性放入一个单独的维度表中，如下所示：

突出显示的列将使客户具有独特的偏好。*客户可以有多种偏好。

如果将来业务引入更多偏好并希望包含在维度中怎么办。然后我必须将这些属性以及使唯一的键带入上表。

是按照偏好做单个维度还是将所有维度合并到一个大维度中更好。

请提出建议。

编辑：

根据我的阅读，我了解到我必须在我的 Customer Dim 和其他 Customer Preference 维度之间设计一个桥接表。

我的计划是为每种偏好类型和所有组合创建 CustomerPreference Dimension。并将这些映射到一个可以有多对多客户偏好关系的桥接表中。

示例如下

这是正确的做法还是有任何最佳做法。

[或]这是正确的方法吗？

编辑：27-03-2013

根据 Pondlife 的建议，我将采用 Snowflake 方法，如下所示：

我正在建模一个具有 6 维的数据仓库。其中一个维度是客户端，它有大约 600k 行，还有一些其他维度，例如帐户和产品。我通过乘以每个维度表的基数来估计事实表的行数，结果为 1*10^12 行。我的问题是，如果客户没有某个产品，该产品是否会有一行（在事实表中有cero 值），或者根本不会有一行？我需要这些信息来知道我的近似值是行数的上限，还是确切的行数。

在数据仓库上工作，并正在寻找有关具有多个维度与具有属性的大维度的建议。

我们目前有 DimEntity、DimStation、DimZone、DimGroup、DimCompany，并且有多个事实表，其中包含来自每个维度的键。这是最好的方法，还是只有一个维度 DimEntity 并包括站、区域、组和公司作为实体的属性更好？

我们已经使用我们的 ETL 走了单独维度的路线，因此填充和构建星型模式的工作不是问题。性能和可维护性很重要。这些尺寸不会经常变化，因此请寻求有关处理此类尺寸的最佳方法的指导。

事实表有超过 1 亿条记录。实体维度有大约 1000 条记录，其他列出的每条记录不到 200 条。

我有一个带有“值”的事实表。事实表有两个外键“Job Manager”和“Project Director”，它们都链接到 DimPerson 表中的 PersonKey。这个 DimPerson 表有人名等。我如何查看 Job Manager 的值？我只能按人名查看，但这并不能告诉我他们是工作经理还是项目总监，但两者都是加在一起的。使用 powerpivot 如何查看 Job Manager 的值？还是项目总监的价值？