亚马逊AWS官方博客
数据架构的云原生迭代：从 Snowflake 到 AWS Data Lake
 |
前言
在企业最初选择数据仓库时，Snowflake 常常成为一个非常受欢迎的选项。这主要归功于其友好的生态系统、易于上手的特性以及卓越的性能优势。Snowflake 的架构采用了存储与计算分离的设计，使得企业可以根据实际需求灵活扩展资源，避免了传统数据仓库在面对数据量激增时可能出现的性能瓶颈。此外，Snowflake 支持多种数据格式和复杂查询，极大地提升了数据分析的效率和灵活性。
然而，随着企业数据规模的不断扩大和分析任务的日益增加，单一的数据仓库架构逐渐无法满足多样化的业务需求。因此，许多企业开始考虑将其数据仓库体系扩展到数据湖，以便更好地管理海量数据并灵活地增加不同的分析服务。本文将通过一个用户案例来阐述这一转变过程，探讨如何在 AWS 环境中实现数据湖与 Snowflake 之间的集成，以支持更复杂的数据分析需求。
Snowflake 标准架构如下：
 |
该架构的数据处理流程如下：
数据源 –> AWS 流服务/S3 –> Snowpipe 加载 –> Warehouse SQL 聚合操作 –> 域进行访问控制 –> 数据产品化，支持业务决策和数据应用
可以看到，基于 Snowflake 的 Data Mesh 支持与 AWS 多个数据流和存储服务的集成。然而，这一架构可能面临的问题有：
- 额外软件计费，处理复杂或持续运行的任务时造成较高成本，随着数据规模增加成本难以控制；
- 数仓分析建立在 SQL 结构上，对于非结构化数据不友好；
- 依赖于专有数据格式和结构化存储，不能自由切换到第三方分析组件；
- 在中国区域缺乏工程师支持。
挑战与方案
在具体用户场景中，我们面临着以下挑战。
- 成本：用户 OLAP 需求集中于内部数据分析与报表，需要严格控制成本，而 Snowflake 的额外软件计费在处理复杂或持续运行的任务时可能导致较高费用。
- 性能：用户写入数据量的规模未知，要求保障数据接入处理与聚合的总时长满足业务要求，查询有实时交互查询与定时报表查询两种模式，保障秒级接口响应。
- 灵活处理模式：用户的数据源来自多个部门，格式多样，包括 JDBC 的结构化数据和来自 Kafka、CRM 接口的数据，需要灵活，自动化的处理方式。
- 合规：AD 联合鉴权，完成多租户（管理员，分析师，终端用户）基于数据血缘进行数据访问控制，以及 BI 工具下不同数据源/面板的访问控制。从网络层保证数据完全内网访问与处理。
方案架构如下，针对用户的挑战，我们进行了下述架构优化：
 |
成本：ETL 与数仓使用 Glue 与 Redshift
AWS Glue 是一款无服务器的 spark ETL（提取、转换、加载）服务，旨在简化数据集成和处理的过程。在 AWS Glue 中，ETL 作业的计费是基于数据处理单元（DPU）和作业的持续时间。一些研究表明，当使用 AWS Glue 进行数据管道处理时，相比于 Snowflake 的 XL 仓库，Glue 的成本可降低多达 78%。
Amazon Redshift 提供多种节点类型和无服务器选项，用户可以根据需求灵活选择。根据第三方报告，在某些情况下，Redshift 的运行成本比 Snowflake 低约 30%（即 1.3 倍）。此外，通过预留实例，Redshift 的成本优势更为显著，甚至可以达到 Snowflake 成本的 1.9 到 3.7 倍的节省。Redshift 还提供免费并发扩展积分，这对于需要进行大量批量报表查询的场景非常有用。更重要的是，Redshift 允许用户在不使用时暂停集群，从而停止计费，这样可以有效控制非工作时间不必要的开支。
从存储成本的角度来看，无论是 AWS Glue 还是 Redshift，都利用 Amazon S3 进行数据存储。S3 的存储费用远低于传统本地存储，并且其计费模式是基于实际存储的数据量，无需预估容量，也不需要为数据可用性创建多副本，从而降低了管理复杂性和成本。
性能：持续版本升级与性能优化
Glue 使用使用 Apache Spark 引擎，通过 Spark 的分布式计算能力，结合 AWS Glue 3.0 运行时优化，能够加速数据集成和查询处理，有效降低启动延迟，在复杂的 ETL 任务中处理时间显著优于 2.0。当使用 AWS Glue 进行数据管道处理时，相比于 Snowflake 的 XL 仓库，性能提升可达 23%。
在最开始使用 Redshift 的时候，用户抱怨 Redshift 性能不如 Snowflake，但通过联合 SSO 团队深入研究，我们采取了一系列措施提升性能：
- 有效利用分布和排序键。通过合理选择分布键（DISTKEY）和排序键（SORTKEY），减少了节点之间的数据移动，从而降低了性能瓶颈的风险。这一策略使得数据在查询时能够更高效地访问。
- 重构 SQL 查询与视图构建。例如避免使用 SELECT *，从而减少了不必要的数据传输和处理。
- 创建 WLM 队列。根据不同的工作负载需求创建多个 WLM 队列，以便为不同类型的查询分配相应的资源。这可以减少排队时间，提高并发处理能力。
此外，Redshift 有自动表优化功能。查询执行计划生成和编译代码等功能，这些特性均可以提升查询性能。
灵活处理模式：使用 Glue Connector、Data Catalog、visual ETL 与 MWAA
在应对多来源，多格式，不同处理需求的架构考虑上，我们主要使用 Glue 的原生服务特性，配合 MWAA 与 dbt 数据血缘管理复杂 pipeline。
- 通过 AWS Glue Connector 一站式完成数据源的集成
多种数据源支持：Glue Connector 支持多种数据源，包括关系数据库（如 Amazon RDS、MySQL、PostgreSQL）、NoSQL 数据库（如 MongoDB），以及其他应用程序等。同时，可以使用自定义 JDBC 驱动程序来连接数据源（max compute），从而扩展连接功能。用户还可以从 AWS Marketplace 中获取并使用第三方连接器（如 Snowflake），进一步丰富数据集成的选择。
高可用：通过原生冗余和备份机制，Glue Connector 保持高服务可用性，降低用户连接维护成本。AWS Glue 是 serverless 的，无论是数据量的突然增加还是减少，Glue 都能自动调整资源以确保作业顺利进行。
连接复用：通过创建连接，用户可以在 ETL 任务中轻松访问数据源，简化不同数据连接复用流程。
- 通过 AWS Glue Data Catalog 集中化的元数据管理。
Glue Data Catalog 作为通用持久化的元数据存储，一站支持所有数据资产的管理，同时维护了高可用性。支持 Redshift、Athena、glue ETL、Lake Formation、EMR 等多个服务使用。
- Glue visual ETL 快速原型迭代。
用户可以通过拖放组件来构建 ETL 流程，轻松添加数据源、转换节点和目标数据存储。在设计过程中，用户可以实时预览数据流动和转换结果，便于快速调整和优化工作流。visual ETL 提供多种内置的转换节点，如数据清洗、格式转换、聚合等，用户可以直接使用这些节点进行数据处理。最后，visual ETL 可以转化为代码。对于复杂的转换逻辑，用户也可以在可视化界面中插入自定义代码，显著加快功能开发与迭代速度。
针对用户之前广泛采用 dbt, 我们通过托管的 airflow（MWAA）进行工作流调度，Glue、Redshift 均可以便捷地与 dbt 以及 airflow 集成，清晰展现数据处理 pipeline 以及数据血缘关系。
合规：网络、赋权与数据安全三重考虑
在本场景中，我们将 Amazon Redshift 设置为私有访问模式，并部署在私有子网中，增强数据安全性。同时我们通过 AWS CloudTrail 记录 Redshift 操作，包括连接尝试、查询和对数据仓库的更改。我们建议 AD 与 IAM 通过 SSO 进行联合授权，通过 RBAC 进行数据库角色权限控制，进一步确保数据访问控制符合公司安全策略。
在 ETL 流程中，我们主要进行以下安全设计：
- Glue 私有网络配置：Glue connection可以便捷地通过 Private link 实现私网的端口映射，满足用户合规要求。同时，由于用户网络拓扑复杂，我们推荐通过安全组进行网络数据流向控制，增加数据传输安全。此外， VPC Endpoint 可以减少因通过互联网传输数据而导致的延迟。
- 元数据统一管理：Glue Data Catalog 提供全面的审计功能，可以跟踪对元数据的访问和更改，从而增强合规性。同时支持对元数据进行加密，并提供详细的访问日志记录。
- 连接信息安全管理：通过 Connector 与 Secrets Manager 保存连接信息，以避免明文密码泄露风险。
总结
在该用户场景下，数据平台日常支持 7000+ IOPS 峰值请求以及 TB 级数据的月增分析需求。经过系统上线后的实际运行情况显示，AWS Glue 的月用量低于 $1,000，而 Redshift 的月成本则低于 $2,000。同时，S3 的数据存储成本也保持在每月低于 $2,000。
这个案例体现了云原生数据湖架构可以有效应对日益增长的数据规模和复杂分析需求。在控制成本、提升性能、实现灵活处理以及确保合规性方面，这一解决方案也展现了显著优势，为企业提供了云原生的支持，使其能够更好地利用企业数据进行决策与分析。
参考链接
https://blog.panoply.io/redshift-vs-snowflake-the-full-comparison