ACM通信

BLOG@CACM

我对数据仓库的十大断言

由Michael Stonebraker
2010年8月26日
评论(3)

数据仓库、商业智能、商业分析和复杂分析是日益激烈的营销战的主题，甲骨文最近引入Exadata设备似乎加速了营销战的进程。以下是我对这种情况的看法，整理成我对这个话题的十大论断。请注意，我在几家数据库公司有财务利益，并且可能在许多不同的方面有偏见。读者应该时刻记住这一点。

断言1:星型和雪花模式在数据仓库世界中是一个好主意。

简而言之，数据仓库存储了大量的事实。这些事实中的绝大多数都是“5w”(谁，什么，在哪里，什么时候，为什么)，以及关于事实的一系列属性。例如，一个典型的零售组织存储关于历史事务的事实。这些事实包括顾客(谁)、零售商店(在哪里)、销售时间(什么时候)和购买的产品(什么)，以及销售的属性(例如，价格、销售税、使用的信用卡等)。

我们应该按照图1所示的方式组织这些数据:

时间(t-key, t-attributes)
| |
| |
事实(c-key, s-key, t-key, p-key，属性)
| |
| |
Product (p-key, p-attributes)

星型模式图
图1

这样的模式称为星型模式，中间有一个事实表和周围维表。如果存储被组织成分区，那么星型模式在Store和Fact之间有另一个表，并成为雪花模式．Star和Snowflake模式干净、简单、易于并行化，通常会产生非常高性能的数据库管理系统(DBMS)应用程序。

如果您是一名数据仓库设计人员，并且提出了雪花模式以外的方案，那么您可能应该重新考虑您的设计。

然而，您经常会遇到在事实表中有大量属性的设计;40个属性是常规的，200个并不罕见。当前的数据仓库管理员通常会倒立起来，在当前的关系数据库管理系统(rdbms)上执行“胖”事实表。这就引出了我的第二个断言。

断言2:随着时间的推移，列存储将取代行存储主导数据仓库市场。

行存储的问题在于，它们将数据逐行存储在磁盘上的事实表中。一个典型的商业智能查询需要6个或更少的属性(例如，为我查找过去两年按商店按月的小部件平均价格)。行存储将读取所有200个属性，尽管只需要6个属性。相比之下，按列组织数据的DBMS只读取所需的6个，节省了33倍。

由于业务分析人员希望访问越来越多的信息，事实表随着时间的推移变得越来越胖，因此这种体系结构差异将变得越来越重要。即使出现“瘦”事实表或读取许多属性时，列存储仍然可能具有优势，因为它具有优越的压缩能力。

由于这些原因，随着时间的推移，列存储显然会胜出。注意，几乎所有传统的rdbms都是行存储，包括Oracle、SQLServer、Postgres、MySQL和DB2。此外，在单个块(如Exadata)上实现pax风格编码(在Web浏览器中输入“Anastassia Ailamaki”以获得有关该主题的大量参考目录)的系统，只是更改了块的内部布局，而没有更改上面提到的列存储优势。

断言3:绝大多数数据仓库都不是主存或闪存的候选者。

我的经验是，数据仓库的规模增长速度快于存储成本下降的速度。业务分析人员渴望获得尽可能多的属性数据，并希望保持越来越长的历史周期。因此，数据仓库问题正变得“更难联网”，而不是“更容易联网”。换句话说，大多数数据仓库的度量单位是今天的Gbytes、明天的Tbytes和第二天的Pbytes。

主存或闪存的价格要便宜到足以处理大多数仓库问题还需要很长时间。因此，非磁盘技术只能用于临时表、非常“热门”的数据元素或非常小的数据仓库。

断言4:大规模并行处理器(MPP)系统将在这个市场中无处不在。

大规模并行处理器系统(现在是10级，明天将是100级)是唯一一种可以扩展到千字节的计算机架构。除了极少数例外，所有的供应商都支持MPP。不要在MPP阵营之外的任何东西上下注。

断言5:“没有旋钮”是唯一有意义的东西。

很明显，人力操作成本主导着运行数据仓库的成本。这主要是系统管理和数据库管理，涉及保持MPP系统正常运行和管理一个pbyte大小的仓库。数据库管理员(DBA)的成本包括设计模式、重新配置数据库以添加或删除资源、添加和删除用户、调优和返回DBMS等。

几乎所有dbms都有100个或更多复杂的调优“旋钮”。这要求dba成为“四星级向导”，并增加了运营成本。显然，唯一有意义的事情是有一个程序来自动调整这些旋钮。换句话说，寻找“无障碍”作为降低DBA成本的唯一方法。

断言6:设备应该“只属于软件”。

在我作为DBMS领域的计算机科学专业人员的40年经验中，我还没有看到一个专门的硬件架构——所谓的数据库机——胜出。

换句话说，可以从主要芯片供应商购买通用CPU周期，也可以从数据库机器供应商购买专用CPU周期。由于通用供应商的数量是专门供应商的1万或10万倍，因此它们的价格低于专门供应商的价格一个数量级。要成为性价比的赢家，专业供应商必须至少快20 - 30倍。

我从来没有见过一个专门的硬件架构比它快这么多。然而，每十年都有一些供应商尝试(并失败)。

换句话说，我认为数据库设备是一个打包练习——即。，预配置通用硬件，并在其上预加载DBMS。这就产生了一个只有软件的设备。

断言7:混合工作负载不是通过“一刀切”来优化的。

如果一个人的工作负载部分是在线事务处理(OLTP)，部分是数据仓库，那么他或她有两个选择:

1)运行一个通用的RDBMS来存储这两种数据;

2)运行OLTP引擎和数据仓库引擎两个系统，配合高速交换，将操作数据移动到数据仓库中。

行存储不适用于数据仓库应用程序(参见断言1)。列存储为数据仓库优化，不适用于OLTP。因此，这两种方法都不是“一刀切”实现的好方法。相反，有许多有趣的新想法可以加速OLTP，包括主存SQL引擎、主存缓存、闪光系统等。当与双系统配置中的列存储相结合时，我断言结果将比解决方案1快50倍左右。换句话说，两个专门的系统都比解决方案1中的单一“一刀切”系统快50倍。

50的倍数是不容小觑的。

断言8:基本上所有数据仓库安装都需要高可用性(HA)。

如上所述，数据仓库变得越来越大。如果在10 t字节的仓库中有数据损坏，那么从数据库日志中恢复数据库将花费非常长的时间。当然，确切的时间取决于日志格式、分配给日志的磁盘数量等。但是，从10个磁盘恢复一个10 t字节的转储可能需要数小时，而不是几分钟，然后必须从转储执行前滚。几乎没有人对这种休息时间感兴趣。

相反，如果有数据损坏，大多数安装使用复制并故障转移到副本(串联计算机样式)。然后，可以将损坏的副本作为后台任务重新构建。因此，HA用于恢复，而不是DBMS日志。显然，这需要DBMS支持HA;否则，在用户代码中完成同样的事情就需要DBA手工操作。此外，如果这是一种恢复策略，就没有理由写一个DBMS日志。因此，可以避免运行时开销的来源。

断言9:dbms应该支持在线重置。

虽然不是经常，但我经常会听到有人要求在网上重新安排。换句话说，最初分配10个节点来完成仓库处理。负载稍后增加，希望将20个节点分配给最初由10个节点完成的任务。这需要在两倍的节点数量上重新分区数据库。

几乎没有人愿意花费所需的停机时间来转储和重新加载DBMS。同样，这样做也是DBA的一个麻烦。更好的解决方案是DBMS支持重新配置，而不脱机。目前很少有系统具有此功能，但是应该鼓励供应商快速行动以提供此功能。

断言10:虚拟化在DBMS世界中经常存在性能问题。

我听到许多用户说他们的长期目标是转移到云上，无论是使用公共云(比如EC2)还是在“企业云”的防火墙内部。这里，将一组服务器分配给企业防火墙内的多对多DBMS应用程序。通常，通过使用虚拟化软件将虚拟节点呈现给DBMS及其应用程序来管理这类系统。

我的经验是，CPU资源可以以较小的开销(比如10%)进行虚拟化。然而，数据仓库需要基于磁盘的数据。在这个世界中，所有MPP dbms“将查询移动到数据”(即，它们将复合查询的组成部分发送到各个节点进行本地处理)。显然，这需要了解物理数据分布。虚拟化将破坏这些知识，并将最初对本地磁盘的读取变为对非本地磁盘的读取。换句话说，本地I/O被远程I/O所取代，从而造成明显的性能损失。

在更好、更便宜的网络使远程I/O以合理的成本和本地I/O一样快之前，人们应该非常小心虚拟化DBMS软件。请清楚地注意，数据仓库dbms读取分配给它们的磁盘的带宽是磁盘带宽的一半。因此，一个10磁盘的数据仓库应用程序将需要千兆的带宽。现在，在企业云上放置10个这样的应用程序，您的速度将接近太比特。在这样的速度下，合理的成本网络仍有一段路要走。

当然，虚拟化环境的好处不是微不足道的，它们可能会超过性能损失。我唯一想说的是，虚拟化I/O并不便宜。

同样的一般评论也适用于存储区域网络(SAN)安装。如果MPP DBMS运行在SAN存储上，那么本地I/O将被远程I/O所取代，通过SAN供应商支持的任何互连。同样，成本可能不是微不足道的。

披露:除了是麻省理工学院的兼职教授，迈克尔Stonebraker与四家数据库技术的生产者或消费者创业公司有关。

---

评论

---

显示3评论