数据仓库基准比较了Azure、BigQuery、Presto、Redshift和Snowflake的价格、性能和差异化功能。
年9月更新
Fivetran是一个数据管道，它将来自应用程序、数据库和文件存储的数据同步到我们客户的数据仓库中。我们经常被问到的问题是，“我应该选择什么数据仓库？“为了更好地回答这个问题，我们对五个最流行的数据仓库的速度和成本进行了基准比较：
AmazonRedshiftSnowflakeAzureSynapsePrestoGoogleBigQuery基准测试都是为了做出选择：我将使用什么样的数据？多少钱？什么样的问题？如何做出这些选择非常重要：更改数据的形状或查询的结构，最快的仓库可能成为最慢的仓库。我们试图以一种代表典型Fivetran用户的方式做出这些选择，因此结果将对使用Fivetran的公司有用。
典型的Fivetran用户可能会将Salesforce、Zendesk、Marketo、Adwords及其生产MySQL数据库同步到数据仓库中。这些数据源并没有那么大：一个典型的数据源将包含数十到数百千兆字节。它们很复杂：它们在规范化模式中包含数百个表，我们的客户编写复杂的SQL查询来汇总这些数据。
我们查询了哪些数据？
我们以GB和1TB的规模生成了TPC-DS[1]数据集。TPC-DS在雪花模式中有24个表；这些表表示虚拟零售商的web、目录和商店销售。最大的事实表在GB级别上有4亿行，在1TB级别上有40亿行[2]。
我们运行了哪些查询？
年8-9月，我们运行了99个TPC-DS查询[3]。这些查询很复杂：它们有很多连接、聚合和子查询。我们只运行每个查询一次，以防止仓库缓存以前的结果。
因为每个查询只运行一次，所以这些时间包括编译查询和运行查询的时间。Redshift尤其对这种假设非常敏感；它编译这些查询所花费的时间比运行它们所花费的时间要多。我们将在深入研究中进一步探讨这个问题。
我们是如何配置仓库的？
我们以GB和1TB的大小配置设置每个仓库：
我们是如何调整仓库的？
这些数据仓库都提供高级功能，如排序键、集群键和日期分区。我们选择在基准测试中不使用这些特性。我们确实在Redshift中应用了列压缩编码；Snowflake、Azure和BigQuery自动应用压缩；Presto在HDFS中使用了ORC文件，这是一种压缩格式。
我们在深入研究中探索了各种优化调整：
结果
哪个数据仓库最快？
所有的仓库都有很好的执行速度，适合于特别的、交互式的查询。
Redshift的速度较慢主要是因为它的查询规划器较慢；在重复运行类似查询的情况下，第二个查询将快得多。
Azure在GB级别上的速度较慢是因为使用了Gen1架构；Gen2架构在较小的仓库中还不可用。
哪个数据仓库最便宜？
BigQuery对每个查询收费，因此我们将显示Google云计算的实际成本。为了计算其他仓库的每个查询的成本，我们假设了一个典型的仓库空闲的时间。例如，如果您以每小时2美元的价格运行一个SnowflakeX小型仓库1小时，并且在此期间运行一个查询需要30分钟，则该查询将花费您2美元，并且您的仓库在50%的时间内处于空闲状态。另一方面，如果您运行两个30分钟的查询，而仓库将0%的时间闲置，则每个查询只花费1美元。我们查看了一个拥有Redshift仓库的Fivetran用户示例的实际使用数据。中位数Redshift集群在82%的时间内处于空闲状态[8]。
这种比较在很大程度上取决于我们关于懒惰的假设[9]。如果您的工作负载非常“尖细”，那么BigQuery将比其他仓库便宜得多。如果您有一个非常“稳定”的工作负载，那么BigQuery将要昂贵得多。
哪个仓库是“最好的”？
速度和成本并不是唯一的考虑因素；这些仓库有着重要的质量差异。根据我们与真实客户的经验，我们认为有5个关键特征可以区分数据仓库：
弹性：数据仓库能够以多快的速度增加和减少容量以响应不断变化的工作负载？可用性：仓库如何提供高正常运行时间？JSON支持：可以存储和查询JSON数据吗？你能通过划分数据来调整WHERE子句吗？可以通过指定数据分布来优化联接吗？我们总结了Redshift、Snowflake和BigQuery在这些标准上的比较；我们还没有足够的Azure和Presto客户将它们纳入定性比较：
比较数据仓库及其特性
为什么我们的结果与以前的基准不同？
Amazon’sRedshiftvs.BigQuerybenchmark
年10月，亚马逊在BigQuery和Redshift上运行了一个TPC-DS查询版本。亚马逊报告称，Redshift的速度提高了6倍，BigQuery的执行时间通常超过1分钟。他们的基准和我们的基准之间的主要区别是：
他们使用了10倍大的数据集（10TB比1TB）和2倍大的Redshift集群（38.40美元/小时比19.20美元/小时）。
他们使用sort和dist键调整了仓库，而我们没有。
BigQueryStandardSQL在年10月仍处于测试阶段，到年底运行这个基准测试时，速度可能会更快。
那些声称自己的产品是最好的供应商所提供的基准应该是小菜一碟。亚马逊的博客文章中有很多细节没有具体说明。例如，他们使用了一个巨大的Redshift集群——他们是否将所有内存分配给一个用户，以使这个基准测试完成得超级快，即使这不是一个实际的配置？我们不知道。如果AWS能够发布必要的代码来重现它们的基准测试，那么我们就可以评估它的真实性。
Periscope’sRedshiftvs.Snowflakevs.BigQueryBenchmark
同样在年10月，Periscope数据使用每小时聚合查询的三种变体来比较Redshift、Snowflake和BigQuery，这三种变体将一个10亿行的事实表与一个小维度表连接起来。他们发现Redshift的速度和BigQuery差不多，但是SnowFlake的速度慢了两倍。他们的基准和我们的基准之间的主要区别是：
他们多次运行相同的查询，这就消除了Redshift编译速度慢的问题。他们的查询比我们的TPC-DS查询简单得多。使用“easy”查询进行基准测试的问题是，每个仓库在这个测试中都会做得很好；Snowflake快速执行简单查询，Redshift快速执行简单查询并不重要。重要的是你是否能足够快地完成硬查询。
Periscope也比较了成本，但是他们使用了不同的方法来计算每个查询的成本。和我们一样，他们查看客户的实际使用数据；但他们没有使用空闲时间百分比，而是查看每小时的查询数。他们确定大多数（但不是所有）潜望镜客户会发现Redshift更便宜，但这并不是一个巨大的区别。
MarkLitwintschik’s1.1BillionTaxiRidesBenchmark
MarkLitwintshik于年4月对BigQuery进行了基准测试，并于年6月对Redshift进行了基准测试。他对一个拥有11亿行的表运行了4个简单的查询。他发现BigQuery的速度和Redshift集群差不多，大约是我们的两倍（41美元/小时）。两个仓库都在1-3秒内完成了他的查询，因此这可能代表了“性能下限”：即使是最简单的查询也有最短的执行时间。
结论
这些仓库的价格和性能都很好。我们不必惊讶它们是相似的：自从C-Store论文在年发表以来，快速列式数据仓库的基本技术已经众所周知。这些数据仓库无疑使用了标准的性能技巧：列存储、基于成本的查询规划、流水线执行和实时编译。我们应该对任何声称一个数据仓库比另一个数据仓库快几个数量级的基准表示怀疑。
仓库之间最重要的区别在于它们的设计选择所导致的质量差异：一些仓库强调可调性，另一些则强调易用性。如果您正在评估数据仓库，您应该演示多个系统，并选择一个适合您的平衡点。
数据仓库与数据挖掘实践京东￥33.6购买想了解更多精彩内容，快来