English
Nederlands
Deutsch
Français
Español
Português
Italiano
Polski
中文
हिन्दी
仅欧洲替代方案 Snowflake.
Snowflake 是通过计算与存储分离赢得分析市场的云数据仓库，在 AWS、Azure 或 GCP 上设有 EU 区域。Snowflake Inc. 是一家特拉华州公司；其 EU 区域运行在美国超大规模云厂商的基础设施上，这意味着两层美国司法管辖权。对于涉及 EU 客户数据的分析工作负载，在 Snowflake 上真正做到 Schrems II 合规是困难的。主权替代方案包括：ClickHouse（开源列式数据仓库）、DuckDB（嵌入式分析）或带有适当列式扩展的 PostgreSQL，它们都可以部署在 EU 主权基础设施上。
- 供应商
- Snowflake
- 总部
- Bozeman, MT
- 司法管辖区
- 美国
- 法律制度
- CLOUD Act, FISA 702
"欧盟区域"不等于主权。四个问题决定一切。
数据驻留告诉你数据存放在哪里。主权则告诉你哪个法律体系可以强制访问。这四点的答案必须都成立 - 否则该技术栈就不具备主权性。
- 驻留
-
数据物理存储在哪里?
不只是笼统的“在云端” - 而是具体在哪个数据中心、哪个国家、受哪种司法管辖。
- 次级处理者
-
您的数据路径中还有谁?
每一个接触数据的供应商:CDN、邮件中继、错误追踪、分析管道。
- 司法管辖区
-
哪些法律可以强制披露?
总部位于美国的提供商受 FISA 702 和 CLOUD Act 管辖 - 即使数据存放在法兰克福也不例外。
- 密钥托管
-
谁实际持有加密密钥?
如果云服务商同时持有数据和密钥，无论签订何种 DPA，数据对其而言都是可读的。
在司法管辖权和密钥托管上失败。
欧盟数据、美国母公司、默认路径中的美国次级处理者、供应商管理的密钥。
四项全部通过。
托管在欧盟、由欧盟总部基础设施提供。默认路径中零美国次级处理者。客户持有或欧盟 KMS 密钥。在您的第 28 条 DPA 中按名称列出。
为什么团队正在退出 Snowflake
我们评估过的 Snowflake 退出案例，多来自监管行业的工作负载，其分析型数据仓库中存有欧盟客户的个人数据，且 Schrems II 分析在多个层面均无法通过。独特的迁移挑战在于：数据仓库体量庞大、查询复杂，且 dbt / Looker / Tableau 数据管道需要重新指向新目标。对于 Snowflake 退出，诚实的答案是需要 3-6 个月的细致工作，而非简单的快速替换。节省空间在于：规模化使用的 Snowflake 积分费用（常见为每月 2 万至 10 万美元以上）可压缩为在欧盟裸金属服务器上运行 ClickHouse 的一小部分成本。
Snowflake 服务及其仅欧盟等效方案
迁移不是"换一个盒子"。下面的映射是我们为离开以下平台的客户运行的 Snowflake 基于 Schrems II 的考量 - 完全适用欧盟司法管辖，数据链路中不涉及美国母公司。
Snowflake compute (warehouses)
- 我们改用什么
- Binadit 托管云平台。ClickHouse 或带列式扩展的 PostgreSQL，使用 dbt 建模。
- 工程说明
- 对于 OLAP 工作负载，ClickHouse 是最强的自主可控替代方案。对于临时查询工作负载，基于 EU 对象存储的 Trino 是典型的 lakehouse 模式。
Snowflake storage
- 我们改用什么
- Binadit 托管云平台。分层 MinIO 或 Ceph 存储池，通过生命周期规则将冷数据迁移至更廉价的磁盘。
- 工程说明
- 对于湖仓一体架构，可采用兼容 S3 的欧盟存储作为数据层，并以 ClickHouse 或 Trino 作为查询引擎。
Snowpipe (continuous ingestion)
- 我们改用什么
- Binadit 托管云平台。Kafka 或 Redpanda 数据流入 ClickHouse，通过 dbt 编排。
- 工程说明
- 对于基于 Kafka 的数据接入，ClickHouse 提供原生 Kafka 引擎；对于批量数据接入，可在欧盟计算资源上使用 Airflow。
Streams & Tasks
- 我们改用什么
- Binadit 托管云平台。PostgreSQL 触发器与 LISTEN/NOTIFY，或使用 Kubernetes CronJobs 执行定时任务。
- 工程说明
- ClickHouse 中的物化视图涵盖了大多数“Stream”用例。
Snowpark (Python/Scala in DB)
- 我们改用什么
- Binadit 托管云平台。PostgreSQL 配合 PL/Python，或在数据库旁部署 Python worker。
- 工程说明
- 对于在数据仓库层进行机器学习和特征工程，在欧盟计算资源上使用 PySpark 是标准方案。
Time Travel + Zero-Copy Cloning
- 我们改用什么
- Binadit 托管云平台。pgBackRest 时间点恢复，配合 ZFS 或 Ceph 快照实现即时克隆。
- 工程说明
- Snowflake 的 Time Travel 是一项独特功能；ClickHouse 的快照提供了较为粗略的等效方案。
Secure Data Sharing
- 我们改用什么
- Binadit 托管云平台。只读副本、签名导出，或在数据集前设置受限范围的 API。
- 工程说明
- Secure Data Sharing 没有直接的等效方案；迁移需要重新设计数据共享模式。
Snowflake Marketplace
- 我们改用什么
- Binadit DevOps & Support。您实际使用的组件，作为您技术栈的一部分进行部署和运维。
- 工程说明
- 对于您目前通过 Marketplace 订阅的数据集，通常需要与供应商直接签订合同。
Snowflake Cortex (LLMs)
- 我们改用什么
- Binadit Private Infrastructure。在专用 GPU 硬件上自托管开放权重模型，通过 vLLM 或 Ollama 提供服务。
- 工程说明
- Cortex 出现时间不长；自主可控的 EU LLM 领域（Mistral、Aleph Alpha）已成熟为真正可行的替代方案。
BI tool integrations (Tableau, Looker, dbt Cloud)
- 我们改用什么
- Binadit 托管云平台。Apache Superset 或 Metabase，连接至您的数据仓库。
- 工程说明
- BI 工具层通常只需更新新的连接字符串即可顺利迁移；例如从 dbt Cloud 迁移到自托管欧盟 CI 上的 dbt Core。
我们如何迁移离开 Snowflake
典型的中端市场迁移分为三个阶段进行。以下数据假设工程团队规模为 6-10 人，应用程序技术栈复杂度中等。
-
第 1-3 周
架构决策与审计
根据查询模式和数据量决定使用 ClickHouse、Trino+lakehouse 还是 PostgreSQL。清点每一个 dbt model、每一个 dashboard、每一个外部集成。架构决策主导整个时间表。
-
第 3-10 周
试点+并行运行
将具有代表性的部分工作负载迁移到EU目标环境。并行运行以进行验证。根据真实查询模式调整ClickHouse集群规模。转换dbt模型（大多数只需更换adapter即可在dbt Core上原样运行）。
-
第 10-24 周
完全切换
剩余工作负载的分阶段迁移。重新指向BI工具。缩减Snowflake账户规模。按回滚计划完成最终切换；Snowflake将在切换后保留60-90天用于归档访问。
从Snowflake迁移到ClickHouse的5年TCO：在规模化场景下通常便宜60-85%。一个每月消耗5万美元Snowflake积分的团队，往往可以用每月5000-10000欧元的欧盟ClickHouse基础设施加上托管合作伙伴费用来替代。收支平衡点大约在每月5000-10000美元的Snowflake支出；低于此水平时，迁移的工程成本可能在三年周期内超过所节省的费用。