AWS Redshift与Snowflake用例

Question

我想知道是否有人使用过AWS Redshift和Snowflake以及使用哪个更好的情况。我使用过Redshift，但最近有人建议Snowflake作为一个很好的选择。我的用例基本上是零售营销数据，将由少数分析师使用，这些分析师不是非常精通SQL，并且最有可能拥有报告工具

Answer 1

Redshift是一个很好的产品，但很难想象它比Snowflake更好的用例。以下是Snowflake更好的原因：

• 管理控制台很棒，Redshift没有。
• 放大/缩小发生在几秒到几分钟内，Redshift需要几分钟到几小时。
• 这两种产品的文档都很好，但Snowflake更好 out and more access。
• 你需要知道更少的秘密酱油＃34;使Snowflake运作良好。在Redshift上，您至少需要了解和理解分发键和排序键等性能影响。
• Snowflake的加载过程比Redshift更优雅。 Redshift假定您的数据已经在S3中。 Snowflake支持S3，但具有对JDBC，ODBC和dbAPI的扩展，可以真正简化和保护摄取过程。
• Snowflake非常支持数据库内JSON，并且正在迅速增强其XML。 Redshift有一种更复杂的JSON方法，并建议针对除了较小的用例以外的所有用户，并且不支持XML。

我只能想到Redshift获胜的两个案例。一个是地理可用性，因为Redshift在比Snowflake更多的位置可用，这可以改变数据传输和语句提交时间。另一种是提交一批多个陈述的能力。 Snowflake一次只能接受一个语句，如果它们包含许多语句，这可能会减慢批量，特别是如果你在服务器的另一个大陆上。

在Ajilius我们的开发人员每天都使用Redshift，Snowflake和Azure SQL数据仓库;我们在所有三个平台上都有客户。即使有这样的选择，每个开发人员都喜欢将Snowflake作为他们的首选云。

Answer 2

我同时评估了Redshift（带有S3的Redshfit频谱）和SnowFlake。

在我看来，snowFlake比Redshift更好。 SnowFlake与Relational / NOSQL数据很好地集成在一起。不需要前期索引或分区键。无需担心使用哪种方式访问​​一天，它的效果就很棒。

Redshift非常有限，并且不支持json。很难理解分区。您必须要做很多工作才能完成某些工作。不支持json。您可以使用redshift specturm作为创可贴来访问S3。预先分配好运。在S3存储桶中创建分区后，就可以完成操作，除非您再次将所有数据重新处理为新结构，否则就无法更改。您将最终花时间解决这些问题，而不是着手解决实际的业务问题。

这就像比较智能手机与莫尔斯电码机器。 Redshift就像莫尔斯电码那样的实现方式，而不是现代发展

Answer 3

由于以下原因，我们最近从Redshift切换到Snowflake：

• 实时数据同步
• 并发查询的处理
• 最小化数据库管理
• 为不同的Looker用户提供不同数量的计算能力

在我们的data blog上可以找到更深入的文章。

Answer 4

我评估了Redshift和Snowflake，还评估了Athena和Spectrum。在我们有大量联接的情况下，后两者不是入门者，因为它们会耗尽内存。对于Redshift，出于以下几个原因，我实际上可以获得更好的性价比：

• 允许我选择一个对于同一位置的联接来说非常重要的分发密钥
• 允许在三年的保留价格上享受极大的折扣，以至于您可以以合理的成本真正扩大计算量

在大多数情况下，使用Redshift可以获得更好的性能，但是需要具备丰富的MPP知识才能正确设置物理模式。专业知识和复杂性的成本抵消了部分产品成本。

Redshift将JSON存储在VARCHAR列中。在大型表中查询JSON元素的子集时，这可能会导致问题（OOM），其中VARCHAR列的大小太大。在我们的案例中，我们必须将VARCHAR定义为非常大，以容纳一些包含非常大的JSON文档的记录。

雪花功能很棒，包括：

• 克隆对象的能力
• 处理JSON数据的深层功能
• 用于维护成本低，自动缩放负载，细流更新的防雪管
• 本地ETL的流和任务
• 能够分别扩展存储和计算的能力
• 在一分钟内扩展计算的能力，无需迁移数据
• 还有更多

我要警告Snowflake的一件事是，可能会想聘请技术水平较低的开发人员/ DBA来运行该系统。可以使用庞大的计算群集来解决不良模式设计中的性能问题，但这可能不是最理想的选择。无论如何，Snowflake中的功能都很棒。