[翻译]Implementing Data Cubes Efficiently摘要简介翻译

https://web.eecs.umich.edu/~jag/eecs584/papers/implementing_data_cube.pdf

 

摘要

决策支持应用程序涉及到非常大的数据库上的复杂查询。由于响应时间应该很小，因此查询优化至关重要。用户通常将数据视为多
维数据多维数据集。数据多维数据集的每个单元格都是关注汇总（例如总销售额）的视图。这些单元格中的许多单元格的值取决于数据多维数据集中其他单元格的值。一种常见而强大的查询优化技术是具体化部分或全部这些单元格，而不是每次都从原始数据中进行计算。商业系统的主要区别在于其实现数据立方体的方法。

1介绍

决策支持系统（DSS）迅速成为获得企业竞争优势的关键。 DSS允许企业获取被锁定在运营数据库中的数据，并将其转化为有用的信息。许多公司已经建立或正在建立称为数据仓库的新统一决策支持数据库，用户可以在该数据库上进行分析。
在运营数据库维护状态信息的同时，数据仓库通常维护历史信息。结果，数据仓库往往非常大，并且会随着时间增长。
DSS的用户通常对识别趋势感兴趣，而不是孤立地查看单个记录。因此，决策支持查询大量使用聚合，并且比OLTP查询复杂得多。
数据仓库的大小和查询的复杂性可能导致查询花费很长时间才能完成。在大多数DSS环境中，这种延迟是不可接受的，因为它严重限制了生产率。通常的要求是查询执行时间最多为几秒钟或几分钟。
有许多方法可以实现这种性能目标。可以增强查询优化器和查询评估技术，以更好地处理聚合[CS94]，[GHQ95]，[YL95]，以使用不同的索引策略，例如位映射索引和联接索引[OG95]等。

一种常用的技术是实现（预先计算）经常提出的查询。例如，在Mervyn的百货商店链中的数据仓库共有2400个预先计算的表[Rad95]，以提高查询性能。选择正确的查询集以实现是一项艰巨的任务，因为通过实现查询，我们可能能够快速回答其他查询。例如，我们可能想实现一个相对很少被问到的查询，它是否有助于我们快速回答许多其他查询。在本文中，我们提出了一个框架和算法，使我们能够选择一组很好的查询以实现。我们的框架还可以让我们推断这些查询的实现顺序。

1.1数据立方体

数据仓库的用户在图形环境中工作，数据通常以多维“数据立方体”的形式呈现给他们，他们探索2-D，3-D甚至更高维度的子立方体，试图发现有趣的信息。此数据多维数据集的每个单元格中的值是一些令人感兴趣的“度量”。例如，考虑TPC-D决策支持基准。

例1.1 TPC-D基准测试为商业仓库建模。从供应商处购买零件，然后以销售价格SP出售给客户。该数据库具有有关6年内每笔此类交易的信息。

我们关注三个维度：零件part，供应商supplier和客户customer。利息的“量度”是总销售额totalsales。因此，对于此3-D数据多维数据集中的每个单元cell（p，s，c），我们存储从供应商s购买并出售给客户c的零件p的总销售额。在本节中，我们将术语维度和属性交换使用。在一般情况下，给定维度可能具有许多属性，我们将在第2节中看到。

用户还对合并销售感兴趣：例如，给定客户c的给定部件p的总销售额是多少？[GBLP95]建议在每个维度的域中添加一个附加值“ ALL”以实现此目标。在上面的问题中，我们希望“ ALL”供应商给定客户c的给定部件的总销售额。通过查询单元格中的值来回答查询（p，ALL，c）。

1.在物理上实现整个数据立方体。这种方法可以提供最佳的查询响应时间。但是，对于大数据立方体，预先计算和存储每个单元不是可行的选择，因为消耗的空间变得过多。应当注意，数据多维数据集占用的空间也是创建数据多维数据集所花费时间的良好指标，这在许多应用程序中很重要。消耗的空间也会影响索引编制，因此会增加总成本。、

2，无实现，在这种情况下，我们需要转到原始数据并根据请求计算每个单元格。这种方法解决了对存储原始数据的数据库系统的快速查询响应的问题。需要原始数据。

3.仅实现数据多维数据集的一部分。我们在本文中考虑了这种方法。在数据多维数据集中，许多单元的值可以与数据多维数据集中其他单元的值进行计算。
这种依赖性类似于电子表格，其中单元格的值可以表示为
其他单元格的值的函数。我们称这种细胞为“依赖”细胞。例如，在示例1.1中，我们可以将cell（p，ALL，c）的值计算为的值。
（p，s1，c），…，（p，s N supplier，c），其中N supplier是供应商的数量。实现的单元越多，查询性能就越好。但是，对于大型数据多维数据集，由于空间和其他限制，我们可能只能实现一小部分数据多维数据集单元。因此，重要的是我们选择合适的单元来实现。我们的方法具有很好的可扩展性，可以很好地处理大型数据多维数据集。

在本文中，我们将使用大小为1GB的TPC-D数据库作为运行示例。有关此基准的更多详细信息，请参阅[TPCD]。
我们仅讨论了将数据集作为多维数据立方体呈现给用户的问题。可以使用以下实现方案：
1.在物理上实现整个数据立方体。这种方法可以提供最佳的查询响应时间。但是，对于大数据立方体，预先计算和存储每个单元不是可行的选择，因为消耗的空间变得过多。应当注意，数据多维数据集占用的空间也是创建数据多维数据集所花费时间的良好指标，这在许多应用程序中很重要。消耗的空间也会影响索引编制，因此会增加总成本。
2.没有实现。在这种情况下，我们需要转到原始数据并根据请求计算每个单元格。这种方法解决了对存储原始数据的数据库系统的快速查询响应的问题。除了原始数据的空间外，不需要其他空间。
3.仅实现数据多维数据集的一部分。我们在本文中考虑了这种方法。在数据多维数据集中，许多单元的值可以与数据多维数据集中其他单元的值进行计算。
这种依赖性类似于电子表格，其中单元格的值可以表示为其他单元格的值的函数。我们称这种单元格为“依赖”细胞。例如，在示例1.1中，我们可以将cell（p，ALL，c）的值计算为（p，s1，c）...，（p，sNgupplier，c）的和，其中Nsupplier是供应商的数量。我们实现的单元越多，查询性能就越好。但是，对于大型数据多维数据集，由于空间和其他限制，我们可能只能实现一小部分数据多维数据集单元。因此，重要的是我们选择合适的单元来实现。我们的方法具有很好的可扩展性，可以很好地处理大型数据多维数据集。

具有“ ALL”值作为其地址组成部分之一的任何单元都是从属单元。此单元格的值可以与数据多维数据集中其他单元格的值进行计算。如果一个单元格的组成部分中没有“ ALL”，则无法根据其他单元格的值来计算其值，我们必须查询原始数据以计算其值。以“ ALL”作为其组成部分之一的单元数通常是数据多维数据集中单元总数的很大一部分。在TPC-D数据库中，其尺寸如示例1.1所示，数据多维数据集中所有单元的百分之七十是从属的。

实现数据多维数据集的哪些单元的问题是一个非常现实的问题。有不同的商业系统选择上面给出的不同策略之一。显然，每种策略都有其好处。例如，对于性能至关重要而可伸缩性并不重要的应用程序，我们可以采用“物化一切”的策略。例如，Essbase系统[ESS]实现了整个数据多维数据集，而BusinessOb对象[X94]则没有实现任何数据，而MetaCube系统[STGI]实现了多维数据集的一部分。
还有一个具体的数据立方体存储在哪里的问题：在关系系统或专有的MDDB（多维数据库）系统中。在本文中，我们假设数据多维数据集存储在关系系统的“摘要”表中。数据多维数据集的单元格集分配给不同的表。
数据多维数据集的单元根据其地址中“ ALL”的位置被组织为不同的集合。因此，例如，其地址与address（，ALL，_）匹配的所有单元都放置在同一组中。在此，“”是一个匹配任何值的占位符。这些集合中的每一个都对应于不同的SQL查询。单元格集合（-，ALL，）中的值由SQL查询输出：

SELECT Part,Customer,SUN(SP)AS TotalSales FROMR GROUP BY Part,Customer;

在此，R是指原始数据关系。对应于不同单元格集的查询仅在GROUP-BY子句中有所不同。通常，在单元格集的描述中具有“ ALL”值的属性不会出现在上述SQL查询的GROUP-BY子句中。例如，供应商在集合说明中具有“ ALL”值（-，ALL，-）。因此，它不会出现在SQL查询的GROUP-BY子句中。由于各个单元集的SQL查询仅在分组属性上有所不同，因此我们使用分组属性唯一地标识查询。
确定要实现的单元格集合等同于确定要实现的相应SQL查询（视图）。因此，在本文的其余部分中，我们将使用视图而不是使用单元格集。

1.2动机示例

我们在示例1.1中考虑的TPC-D数据库具有3个属性：零件，供应商，客户。
因此，我们有8种可能的属性分组。我们在下面列出了所有可能的查询（视图）及其结果中的行数。再次注意，仅在视图的GROUP-BY子句中提及属性就足够了。

1. part, supplier, customer(6M,i.e,6 million rows)
2. part, customer(6M)
3. part, supplier(0.8M)
4. supplier, customer(6M)
5. part(0.2M)
6. supplier(0.01M)
7. customer(0.1M)
8. none(1)

none表示GROUP-BY子句中没有属性。图1显示了这8个视图，它们按类型的网格组织，我们将在第2节中讨论。在命名图中的视图时，我们将缩写p表示部件，将s表示供应商，将c表示客户。

图1：可通过按零件，供应商和客户分组来构造的八个视图

一个可能的用户查询是对整个视图的请求。例如，用户可以要求按零件分组的销售。如果我们实现了仅按零件分组的视图（视图5），则只需扫描视图并输出答案。我们还可以使用按零件和客户分组的视图（视图2）来回答此查询。在这种情况下，由于我们拥有每个客户的总销售额，因此对于每个零件，我们需要对所有客户的销售额求和以得出结果。
在本文中，我们假设回答查询的成本与所检查的行数成正比。因此，如果实现了按部分分组的总销售额（如果实现了视图5）的成本是处理20万行的成本（此视图的大小）。为了使用零件来回答相同的查询，客户视图我们将需要处理600万行。
另一类用户查询将仅询问单个零件的销售额，例如“小零件”。如果视图没有索引，则我们仍然必须扫描整个视图（或平均视图的一半）才能回答此问题。因此，相同的比较（视图5的0.2M行与视图2的6M行）将适用于此查询。但是，如果两个视图中都有合适的索引，则查找小部件的销售仅需要从视图5中访问一行，而在视图2中，我们平均必须访问6M / 0.2M = 30行。但是，无论关于是否对物化视图进行索引，我们期望回答这些查询（整个视图或单个单元格）中的每个查询的成本
将与我们从中回答查询的视图的大小成比例。我们将在第3节中更详细地讨论成本模型。

 

我们现在可以提出一些有趣的问题：
1.为了实现合理的业绩，我们必须实现多少个观点？
2.假设我们有空间S，那么我们将实现哪些视图，以使平均查询成本最小化？
3.如果我们愿意容忍完全实现的数据立方体的平均查询成本降低X％，那么与完全实现的数据立方体相比，我们可以节省多少空间？

在本文中，我们提供了可帮助我们回答上述问题并提供接近最佳结果的算法。
在上面的示例中，完全实现的数据多维数据集将实现所有视图，因此具有略多于1900万的行。
现在让我们看看是否可以做得更好。为了避免使用原始数据，我们需要具体化按零件，供应商和客户分组的视图（视图1），因为不能从任何其他视图构造该视图。现在考虑按零件和客户分组的视图（视图2）。
使用此视图回答任何查询将需要我们处理600万行。始终可以使用按零件，供应商和客户分组的视图来回答同一查询，这再次需要处理600万行。因此，按零件和客户实例化视图分组没有任何好处。通过类似的推理，实现供应商和客户的视图分组（视图4）没有优势。因此，我们仅使用700万行就可以得到几乎相同的平均查询成本，就空间消耗和创建数据多维数据集的成本而言，提高了60％以上。
因此，通过明智地选择要实现的数据多维数据集的哪些部分，我们可以获得巨大的收益。

1.3相关工作
 多维数据处理（也称为OLAP）近来引人注目。有两种基本的实现方法可以促进OLAP。第一种方法是避免使用SQL和关系数据库，并使用专有的多维数据库（MDDB）系统和OLAP的PIs。因此，当原始数据位于关系数据仓库中时，数据多维数据集将在MDDB中实现。用户查询数据多维数据集，并且MDDB有效地获取给定其地址的单元格的值。为了仅为原始数据中存在的那些单元分配空间，而不是为数据多维数据集的每个可能的单元分配空间，使用了单元地址哈希方案。Arbor的Essbase [ESS]其他许多MDDB都是通过这种方式实现的。请注意，此方法仍会实现原始数据中存在的数据多维数据集的所有单元，这可能非常大。
另一种方法是使用关系数据库系统，并让用户直接查询原始数据。查询性能问题是使用智能索引和其他常规关系查询优化策略来解决的。有许多产品，例如BusinessObjects和Mi-crostrategy的DSS代理采取了这种措施。但是，MDDB保留了显着的性能优势。通过将数据多维数据集具体化为汇总表，可以显着提高关系数据库系统的性能。

1.4论文的组织
论文的组织如下。在第2节中，我们介绍了用于构架视图之间依赖性的模型。我们还将展示lattice框架如何对涉及属性任意层次的更复杂的分组进行建模。然后在第3节中，我们介绍了本文中使用的查询成本模型。第4节介绍了一种通用技术，用于基于任意lattice为问题生成物化视图的最佳选择。在第5节中，我们考虑“超立方体”lattice的重要特殊情况，其中每个视图都与一组发生分组的属性相关联。 1.2节的运行示例就是这样的超立方体。