有人知道OLAP Internals吗？答案

【问题标题】：Anyone know anything about OLAP Internals?有人知道OLAP Internals吗？
【发布时间】：2010-10-18 17:08:56
【问题描述】：

我对数据库内部结构有所了解。我之前实际上已经实现了一个小型、简单的关系数据库引擎，使用磁盘上的 ISAM 结构和 BTree 索引以及所有类似的东西。这很有趣，而且很有教育意义。我知道我对仔细设计数据库模式和编写查询更加了解，因为我对 RDBMS 如何在后台工作有所了解。

但我对多维 OLAP 数据模型一无所知，而且我很难在互联网上找到任何有用的信息。

这些信息是如何存储在磁盘上的？多维数据集包含哪些数据结构？如果 MOLAP 模型不使用包含列和记录的表，那么……什么？尤其是在高维数据中，什么样的数据结构让 MOLAP 模型如此高效？ MOLAP 实现是否使用类似于 RDBMS 索引的东西？

为什么 OLAP 服务器在处理即席查询方面表现出色？在普通关系数据库中可能需要小时处理的相同类型的聚合可以在 OLTP 多维数据集中以毫秒为单位进行处理。使这成为可能的模型的基本机制是什么？

【问题讨论】：

标签： algorithm data-structures theory olap cubes

【解决方案1】：

我已经实现了几个模仿 OLAP 多维数据集的系统，下面是我们为使它们工作而做的一些事情。

核心数据保存在一个 n 维数组中，全部在内存中，所有键都是通过指向底层数组的指针层次结构实现的。通过这种方式，我们可以为相同的数据拥有多组不同的键。数组中的数据相当于事实表，通常它只有几条数据，在一个例子中是价格和销售数量。
底层数组通常是稀疏的，因此，一旦创建它，我们就会删除所有空白单元格以节省内存 - 大量的硬核指针算法，但它有效。
由于我们有键的层次结构，我们可以很容易地编写例程来轻松地向下钻取/向上钻取层次结构。例如，我们将通过月份键访问年份数据，而月份键又映射到天和/或周。在每个级别，我们都会聚合数据作为构建多维数据集的一部分 - 使计算速度更快。
我们没有实现任何类型的查询语言，但我们确实支持在所有轴上向下钻取（在我们最大的立方体中最多 7 个），这与用户喜欢的 UI 直接相关。
我们在 C++ 中实现了核心内容，但这些天我认为 C# 可能足够快，但我担心如何实现稀疏数组。

希望有帮助，听起来很有趣。

【讨论】：

【解决方案2】：

Microsoft SQL Server 2008 Analysis Services Unleashed 这本书详细阐述了 SSAS 2008 的一些特殊性。这不是“这就是 SSAS 在幕后工作的确切方式”，但它很有启发性，尤其是在数据结构方面。（关于确切的算法，它没有那么详细/具体。）作为该领域的业余爱好者，我从这本书中收集了一些东西。这是关于 SSAS MOLAP 的全部内容：

尽管大家都在谈论多维多维数据集，但事实表（又名度量值组）数据仍然是，第一个近似值，最终存储在基本的二维表中，每个事实一行。许多 OLAP 操作似乎最终都包括对 2D 表中的行进行迭代。
但是，MOLAP 中的数据可能比相应 SQL 表中的数据小得多。一个技巧是每个唯一的字符串只存储一次，在“字符串存储”中。然后，数据结构可以以更紧凑的形式（基本上通过字符串 ID）引用字符串。 SSAS 还以某种形式压缩 MOLAP 存储中的行。我认为这种缩小可以让更多数据同时保留在 RAM 中，这很好。
同样，SSAS 通常可以迭代数据的一个子集，而不是整个数据集。有一些机制在起作用：
- 默认情况下，SSAS为每个维度/属性值建立一个哈希索引；因此，它“立即”知道磁盘上的哪些页面包含相关数据，例如 Year=1997。
- 有一个缓存架构，其中相关的数据子集存储在 RAM 中，与整个数据集分开。例如，您可能缓存了一个只有少数字段的子多维数据集，并且仅与 1997 年的数据有关。如果查询仅询问 1997 年的数据，那么它将仅遍历该子多维数据集，从而加快处理速度. （但请注意，“子立方体”大致上只是一个 2D 表。）
- 如果您是预定义的聚合，那么这些较小的子集也可以在多维数据集处理时预先计算，而不仅仅是按需计算/缓存。
SSAS 事实表行是固定大小的，这可能有助于某种形式。（相比之下，在 SQL 中，您可能有可变宽度的字符串列。）
缓存架构还意味着，一旦计算了聚合，就不需要从磁盘重新获取并一次又一次地重新计算。

无论如何，这些都是在 SSAS 中起作用的一些因素。我不能说没有其他重要的东西。

【讨论】：