Fivetran数据仓库基准比较了Azure、BigQuery、Presto、Redshift和Snowflake的价格、性能和差异化功能。

 

2018年9月更新

Fivetran是一个数据管道，它将来自应用程序、数据库和文件存储的数据同步到我们客户的数据仓库中。我们经常被问到的问题是，“我应该选择什么数据仓库？“为了更好地回答这个问题，我们对五个最流行的数据仓库的速度和成本进行了基准比较：

• Amazon Redshift
• Snowflake
• Azure Synapse
• Presto
• Google BigQuery

基准测试都是为了做出选择：我将使用什么样的数据？多少钱？什么样的问题？如何做出这些选择非常重要：更改数据的形状或查询的结构，最快的仓库可能成为最慢的仓库。我们试图以一种代表典型Fivetran用户的方式做出这些选择，因此结果将对使用Fivetran的公司有用。

典型的Fivetran用户可能会将Salesforce、Zendesk、Marketo、Adwords及其生产MySQL数据库同步到数据仓库中。这些数据源并没有那么大：一个典型的数据源将包含数十到数百千兆字节。它们很复杂：它们在规范化模式中包含数百个表，我们的客户编写复杂的SQL查询来汇总这些数据。

此基准测试的源代码可以在https://github.com/fivetran/benchmark上找到。

我们查询了哪些数据？

我们以100GB和1TB的规模生成了TPC-DS[1]数据集。TPC-DS在雪花模式中有24个表；这些表表示虚拟零售商的web、目录和商店销售。最大的事实表在100GB级别上有4亿行，在1TB级别上有40亿行[2]。

我们运行了哪些查询？

2018年8-9月，我们运行了99个TPC-DS查询[3]。这些查询很复杂：它们有很多连接、聚合和子查询。我们只运行每个查询一次，以防止仓库缓存以前的结果。

因为每个查询只运行一次，所以这些时间包括编译查询和运行查询的时间。Redshift尤其对这种假设非常敏感；它编译这些查询所花费的时间比运行它们所花费的时间要多。我们将在深入研究中进一步探讨这个问题。

我们是如何配置仓库的？

我们以100GB和1TB的大小配置设置每个仓库：

	100 GB		1TB
	Configuration	Cost / Hour	Configuration	Cost / Hour
Redshift	8x dc2.large	$2.00	4x dc2.8xlarge	$19.20
Snowflake	X-Small	$2.00	Large	$16.00
Azure [4]	DW200	$2.42	DW1500c	$18.12
Presto [5]	4x n1-standard-8	$1.23	32x n1-standard-8	$9.82
BigQuery [6]	On-demand		On-demand

我们是如何调整仓库的？

这些数据仓库都提供高级功能，如排序键、集群键和日期分区。我们选择在基准测试中不使用这些特性。我们确实在Redshift中应用了列压缩编码；Snowflake、Azure和BigQuery自动应用压缩；Presto在HDFS中使用了ORC文件，这是一种压缩格式。

我们在深入研究中探索了各种优化调整：

https://get.fivetran.com/datawarehouse-benchmarks.html

 

结果

 

哪个数据仓库最快？

所有的仓库都有很好的执行速度，适合于特别的、交互式的查询。

Redshift的速度较慢主要是因为它的查询规划器较慢；在重复运行类似查询的情况下，第二个查询将快得多。

Azure在100GB级别上的速度较慢是因为使用了Gen1架构；Gen2架构在较小的仓库中还不可用。

 

哪个数据仓库最便宜？

BigQuery对每个查询收费，因此我们将显示Google云计算的实际成本。为了计算其他仓库的每个查询的成本，我们假设了一个典型的仓库空闲的时间。例如，如果您以每小时2美元的价格运行一个Snowflake X小型仓库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’s Redshift vs. BigQuery benchmark

2016年10月，亚马逊在BigQuery和Redshift上运行了一个TPC-DS查询版本。亚马逊报告称，Redshift的速度提高了6倍，BigQuery的执行时间通常超过1分钟。他们的基准和我们的基准之间的主要区别是：

他们使用了10倍大的数据集（10TB比1TB）和2倍大的Redshift集群（38.40美元/小时比19.20美元/小时）。

他们使用sort和dist键调整了仓库，而我们没有。

BigQueryStandardSQL在2016年10月仍处于测试阶段，到2018年底运行这个基准测试时，速度可能会更快。

那些声称自己的产品是最好的供应商所提供的基准应该是小菜一碟。亚马逊的博客文章中有很多细节没有具体说明。例如，他们使用了一个巨大的Redshift集群——他们是否将所有内存分配给一个用户，以使这个基准测试完成得超级快，即使这不是一个实际的配置？我们不知道。如果AWS能够发布必要的代码来重现它们的基准测试，那么我们就可以评估它的真实性。

Periscope’s Redshift vs. Snowflake vs. BigQuery Benchmark

同样在2016年10月，Periscope 数据使用每小时聚合查询的三种变体来比较Redshift、Snowflake和BigQuery，这三种变体将一个10亿行的事实表与一个小维度表连接起来。他们发现Redshift的速度和BigQuery差不多，但是SnowFlake的速度慢了两倍。他们的基准和我们的基准之间的主要区别是：

• 他们多次运行相同的查询，这就消除了Redshift编译速度慢的问题。
• 他们的查询比我们的TPC-DS查询简单得多。

使用“easy”查询进行基准测试的问题是，每个仓库在这个测试中都会做得很好；Snowflake快速执行简单查询，Redshift快速执行简单查询并不重要。重要的是你是否能足够快地完成硬查询。

Periscope也比较了成本，但是他们使用了不同的方法来计算每个查询的成本。和我们一样，他们查看客户的实际使用数据；但他们没有使用空闲时间百分比，而是查看每小时的查询数。他们确定大多数（但不是所有）潜望镜客户会发现Redshift 更便宜，但这并不是一个巨大的区别。

Mark Litwintschik’s 1.1 Billion Taxi Rides Benchmark

Mark Litwintshik于2016年4月对BigQuery进行了基准测试，并于2016年6月对Redshift进行了基准测试。他对一个拥有11亿行的表运行了4个简单的查询。他发现BigQuery的速度和Redshift集群差不多，大约是我们的两倍（41美元/小时）。两个仓库都在1-3秒内完成了他的查询，因此这可能代表了“性能下限”：即使是最简单的查询也有最短的执行时间。

结论

这些仓库的价格和性能都很好。我们不必惊讶它们是相似的：自从C-Store论文在2005年发表以来，快速列式数据仓库的基本技术已经众所周知。这些数据仓库无疑使用了标准的性能技巧：列存储、基于成本的查询规划、流水线执行和实时编译。我们应该对任何声称一个数据仓库比另一个数据仓库快几个数量级的基准表示怀疑。

仓库之间最重要的区别在于它们的设计选择所导致的质量差异：一些仓库强调可调性，另一些则强调易用性。如果您正在评估数据仓库，您应该演示多个系统，并选择一个适合您的平衡点。

笔记

[1] TPC-DS is an industry-standard benchmarking meant for data warehouses. Even though we used TPC-DS data and queries, this benchmark is not an official TPC-DS benchmark, because we only used one scale, we modified the queries slightly, and we didn’t tune the data warehouses or generate alternative versions of the queries.

[2] This is a small scale by the standards of data warehouses, but most Fivetran users are interested data sources like Salesforce or MySQL, which have complex schemas but modest size.

[3] We had to modify the queries slightly to get them to run across all warehouses. The modifications we made were small, mostly changing type names. We used BigQuery standard-SQL, not legacy-SQL.

[4] The DW1500c configuration for Azure uses Microsoft's Gen2 architecture; the Gen2 architecture is not yet available in a small warehouse size appropriate for the 100 GB scale, so we used the Gen1 DW200 configuration at that scale.

[5] Presto is an open-source query engine, so it isn't really comparable to the commercial data warehouses in this benchmark. But it has the potential to become an important open-source alternative in this space. We used v0.195e of the Starburst distribution of Presto. Cost is based on the on-demand cost of the instances on Google Cloud.

[6] BigQuery is a pure shared-resource query service, so there is no equivalent “configuration”; you simply send queries to BigQuery, and it sends you back results.

[7] If you know what kind of queries are going to run on your warehouse, you can use these features to tune your tables and make specific queries much faster. However, typical Fivetran users run all kinds of unpredictable queries on their warehouses, so there will always be a lot of queries that don’t benefit from tuning.

[8] Some readers may be surprised these data warehouses are idle most of the time. Fivetran users tend to use their warehouses for interactive queries, where a human is waiting for the result, so they need queries to return in a few seconds. To achieve this performance target, you need to provision a large warehouse relative to the size of your data, and that warehouse is going to be idle most of the time. Also, note that this doesn’t mean these warehouses are doing nothing for hours; it means that there are many small gaps of idleness interspersed between queries.

[9] The formula for calculating cost-per-query is [Query cost] = [Query execution time] * [Cluster cost] / (1 — [Cluster idle time])

[10] Redshift takes minutes-to-hours to restore a cluster; in practice this means you will run your cluster 24/7, even if you only use it for part of each day.

[11] Snowflake bills per-second, with a minimum of 1 minute, so you can save money by configuring your cluster to turn off during periods of inactivity.

[12] BigQuery bills per-query, so you only pay for exactly what you use.

[13] Redshift automatically backs up to S3, but in the event of a node failure you will lose a few hours of data and experience downtime while you wait for a restore.

[14] Redshift doesn't have an UNNEST or FLATTEN operator, so it's impractical to work with nested JSON arrays.

[15] Snowflake supports JSON data natively via its VARIANT type

[16] You can convert JSON to typed STRUCT/ARRAY types by writing a user-defined-function in Javascript.

[17] BigQuery only allows partitioning on date columns, and date-partitioning limits how you can use DML operations; but it works well for event tables.

 

原文：https://fivetran.com/blog/warehouse-benchmark

本文：http://jiagoushi.pro/node/941

讨论：请加入知识星球【首席架构师圈】或者微信圈子【首席架构师圈】