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