我想知道是否有人同时使用过AWS Redshift和Snowflake以及一个更好的用例。我使用过Redshift，但最近有人建议将雪花作为一个不错的选择。我的用例基本上是零售营销数据，这些数据将被少数分析师使用，他们不是非常精通SQL并且很可能在顶部具有报告工具。
Redshift 是一个很好的产品，但很难想到它比 Snowflake 更好的用例。以下是雪花更好的一些原因：
- 管理控制台很棒，Redshift没有。
- 放大/缩小在几秒钟到几分钟内发生，Redshift 需要几分钟到几小时。
- 两种产品的文档都很好，但雪花铺设得更好 出门，更方便。
- 你需要知道更少的"秘密调味料"才能让雪花很好地工作。在 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作为他们的首选云DW。
我评估了Redshift(Redshfit光谱与S3)和SnowFlake。
在我的poc中，雪花比Redshift好得多。SnowFlake与Relational/NOSQL数据很好地集成在一起。无需前期索引或分区键。它的效果很棒，无需担心以何种方式访问这一天。
Redshift非常有限，没有json支持。很难理解分区。你必须做很多工作才能完成一些事情。 没有 json 支持。您可以使用红移光谱作为创可贴来访问 S3。祝你好运，提前分手。在 S3 存储桶中创建分区后，您就完成了此操作，除非您将所有数据再次重做为新结构，否则无法更改。您最终将花费时间来解决这些问题，而不是致力于解决实际的业务问题。
这就像比较智能手机与摩尔斯电码机甲。Redshift就像莫尔斯电码的实现，它不适合mordern开发
。我们最近从Redshift切换到Snowflake，原因如下：
- 实时数据同步
- 并发查询的处理
- 最小化数据库管理
- 为不同的 Looker 用户提供不同数量的计算能力
更深入的文章可以在我们的数据博客上找到。
我评估了Redshift和Snowflake，以及一点点Athena和Spectrum。后两者在我们有大连接的情况下是非启动器，因为它们会耗尽内存。对于 Redshift，我实际上可以获得更好的性价比，原因如下：
- 允许我选择一个对于共存连接来说巨大的分布键
- 允许三年预留定价的极端折扣，以至于您可以以合理的成本真正扩展您的计算
在大多数情况下，使用 Redshift 可以获得更好的性能，但它需要良好的 MPP 知识才能正确设置物理架构。专业知识和复杂性的成本抵消了部分产品成本。
Redshift 将 JSON 存储在 VARCHAR 列中。在跨大型表查询 JSON 元素子集时，这可能会导致问题 (OOM)，其中 VARCHAR 列的大小太大。在我们的例子中，我们必须将 VARCHAR 定义为非常大，以容纳一些具有非常大的 JSON 文档的记录。
雪花功能令人惊叹，包括：
- 克隆对象的能力
- 处理 JSON 数据的深层功能
- 用于低维护负载、自动扩展负载、涓流更新的 Snowpipe
- 自有ETL的流和任务
- 能够单独扩展存储和计算
- 能够在一分钟内扩展计算，无需数据迁移
- 等等
关于 Snowflake，我要提醒的一件事是，人们可能会试图雇用技能较低的开发人员/DBA 来运行系统。糟糕的架构设计中的性能可以使用巨大的计算集群来解决，但这可能不是最好的选择。无论如何，Snowflake的功能是惊人的。