Snowflake 与 Databricks 商业模式报告#
从客户为什么购买、平台如何收费与扩张、合同和数据责任、留存与退出等方面，对比 Snowflake 与 Databricks 的商业模式，并讨论中国小团队可验证的服务机会。
目录
状态：正式版 v1.0
目标读者：希望理解企业数据平台合作方式的普通读者，以及为企业提供数据与AI服务的创业者
研究截止日：2026-07-10
证据原则：监管文件和正式合同优先；客户案例用于解释采用方式，不将厂商ROI宣传泛化；中国创业建议均为待验证方案。
五分钟看懂Snowflake和Databricks#
假设一家企业同时使用销售系统、财务软件、客服系统和产品后台。
月底，老板问：“这个月新增了多少付费客户？哪些客户投诉后流失了？广告带来的收入是多少？”
销售、财务和客服各自导出一份Excel，却给出三个不同答案。客户编号可能对不上，退款计算方法可能不同，数据更新时间和访问权限也可能不同。
企业刚开始时，可以让员工手工核对。业务扩大后，同样的问题每周都要重做。报表越来越慢，错误难以追查，AI助手读到的数据也互相矛盾。
这时，企业需要的不只是一个更大的数据库，而是一套能长期运行的办法：自动收集各系统数据，统一计算规则，控制谁能看什么，记录数据从哪里来，并在使用量增加时提供更多计算能力。
Snowflake和Databricks都在提供这类能力，但常见起点不同。
Snowflake更常从经营分析和报表问题进入。企业把不同系统的数据接入Snowflake，分析师继续使用熟悉的查询语言和报表工具，底层计算资源主要由Snowflake管理。
它通常帮助客户少管理一些基础设施，更快让分析团队开始工作。但客户仍要定义指标、配置权限、检查数据质量并控制费用。
Databricks通常先服务客户的数据工程和AI团队。它让客户能够在一套相互连接的平台中完成数据接入、清洗、程序开发、模型训练和任务运行，减少在多套工具之间反复搬运数据和重新配置环境。
它通常给予技术团队更大的工程空间。相应地，客户往往需要更强的数据工程和平台管理能力。Serverless计算可以减少部分机器管理，但不会自动解决业务口径和成本问题。
如果企业首要目标是尽快统一销售、财务和客服报表，Snowflake通常先服务客户的分析团队。如果企业还要建设数据管道、客户流失模型和AI客服，Databricks通常先服务承担这些工作的客户数据工程和AI团队。
这不是绝对分工。两家公司都在扩展分析、工程和AI能力，实际选择取决于现有团队、云环境、预算和工作负载。
两家公司都不是主要靠卖一套永久软件赚钱。客户使用平台进行计算、处理数据或运行AI服务，就会产生费用。任务越多、运行越久、使用的高级能力越多，账单通常越高。
客户既可以按实际使用付费，也可能承诺未来一段时间至少消费一定金额，以换取折扣或其他条件。估少了会产生超额费用；估多了可能浪费预算，部分Databricks承诺订单还可能需要期末补足。
平台公司的增长逻辑因此很清楚：先帮助一个团队解决一个问题，再让更多数据、部门和任务进入平台。客户使用范围扩大，平台收入随之增长。
客户购买的并不只有平台。正式项目还可能产生云资源费、迁移实施费、生产支持费、第三方数据费，并占用客户自己的工程、业务、安全和采购人员。
数据安全也不能只问“数据属于谁”。客户通常保留业务数据权利，但平台为了提供服务、排查问题或运行某些功能，可能在合同允许范围内处理数据。
客户还要确认数据存在哪里、谁能访问、访问为了什么、权限由谁配置、日志保留多久，以及合同结束后哪些内容会删除。
客户不会轻易离开，是因为真正需要迁移的不只是数据文件，还包括计算规则、程序、权限、报表、AI流程、下游接口和员工操作习惯。退出通常是一个迁移项目，不是点击“取消订阅”。
对中国三人创业团队而言，最值得学习的不是重新造一个平台，而是“先解决一个问题，再扩大合作”。但目标客户、报价、交付周期、续费和毛利仍需要真实访谈和付费项目证明。
一句话总结：Snowflake通常先帮助客户的分析团队更省事地使用数据；Databricks通常先服务客户的数据工程和AI项目，让客户在一套相互连接的平台中完成数据接入、清洗、程序开发、模型训练和任务运行。随着更多数据、团队和任务进入平台，两家公司获得更多使用收入，并推动客户续约和扩大合作。
一、核心结论#
- Snowflake和Databricks销售的不只是软件，而是让企业持续接入、处理、治理和使用数据的工作环境。
- Snowflake通常先服务有SQL分析、数据仓库和低运维需求的客户团队；Databricks通常先服务客户已有的数据工程、Spark和AI团队。这是典型服务顺序，不是排他定位。
- 两者都依靠既有客户扩张，但证据强度不同：Snowflake有审计财务和NRR；Databricks主要依赖公司自报运行率、留存和产品机制。
- “按量收费”不等于没有合同承诺。客户可能承担用量不足、超额消费和续约预测风险。
- 真实合作通常涉及平台厂商、云厂商、实施伙伴、经销商和客户内部多部门，而不是一张许可证合同。
- 客户保留数据权利，不等于平台永远不能处理数据。权利、存放、访问、目的、配置和删除必须分开检查。
- 开放格式只改善文件层退出。代码、权限、治理、应用和组织流程仍可能形成较深锁定。
- 中国小团队更适合验证实施和持续运营服务，不适合复制底层通用平台；该建议尚未完成市场验证。
二、企业为什么购买数据平台#
企业购买的不是“大数据库”，而是一套降低持续协作成本的机制：把不同来源的数据接入同一环境，建立共同定义和权限，让分析、工程和AI团队重复使用。
完整平台通常在以下复杂度同时上升后才值得购买：数据源和部门增加；分析、工程和AI任务并存；审计要求提高；自建基础设施和跨工具协作开始拖慢业务。
| 企业状态 | 更合理的选择 | 购买完整平台的信号 | 过早购买的风险 |
|---|---|---|---|
| 数据源少、固定报表、团队小 | 普通数据库、报表工具或托管服务 | 暂无明显信号 | 能力闲置，费用和治理负担过高 |
| 业务增长、多个系统和团队 | 轻量平台加实施与运维 | 工具整合拖慢交付，口径冲突频繁 | 过早签大额承诺或照搬大型架构 |
| 多部门、多地区、强审计 | 企业平台、云厂商、伙伴和专业支持 | 标准化、隔离、共享和规模化AI成为刚需 | 迁移复杂，合同和组织锁定加深 |
购买门槛不应只按员工数或收入判断。更有用的指标是数据源数量、任务类型、部门协作、安全要求、内部技术能力，以及现有做法造成的真实成本。
企业采购也不是技术团队单独决定。使用者决定产品能否被采用，业务负责人证明价值，CIO/CTO决定架构，财务和采购控制承诺，安全和法务具有否决权，实施伙伴影响上线结果。
三、Snowflake：低运维入口与消费扩张#
Snowflake让企业用较熟悉的SQL语言和较少的基础设施运维，运行分析、数据工程、共享、应用和AI任务。客户仍需负责数据接入、业务模型、权限和成本治理。
典型路径是：报表或迁移需求 → 部门验证 → 接入数据和报表工具 → 按需消费或购买Capacity安排 → 更多部门和任务进入 → 追加容量和续约。
FY2026，Snowflake总收入约46.84亿美元，其中产品收入约44.72亿美元，同比增长29%；RPO约97.7亿美元，NRR为125%。公司披露，FY2026和FY2025约97%的总收入来自既有客户的Capacity安排。snow-10k
这些数据支持既有客户扩张是增长核心，但不能单独证明全部增长原因。价格、客户结构和大客户消费也会影响结果。Snowflake还说明，产品收入增长主要由既有客户增加消费推动。
Capacity安排形成合同承诺和收入储备，不等于签约时立即确认产品收入。Snowflake通常在客户实际消耗计算、存储和传输资源时确认相关收入。
Snowflake将许多计算和服务用量换算为Snowflake Credits。实际价格取决于云、区域、版本、任务及订单；存储、传输和AI等还可能使用不同规则。snow-pricing snow-ai
FY2026产品毛利率为72%，专业服务及其他业务毛利率为-31%。10-K同时说明，专业服务帮助迁移、代码转换和采用，销售重点是帮助客户更快实现平台价值，而非追求专业服务利润。snow-10k
这支持专业服务是采用促进器的判断，但不表示Snowflake希望服务永久亏损。公司同时表示希望改善服务利润率。
客户可能因更多数据、部门、共享和AI任务扩大消费，也可能通过优化查询、暂停资源、缩短保留或迁走任务降低消费。低运维并不等于无需运营，Canva仍自行建设成本与工作负载监控。canva
四、Databricks：先服务数据工程与AI团队，再扩大平台使用#
Databricks通常先服务客户已有的数据工程、Spark、机器学习和AI团队。它把数据管道、Notebook、模型、SQL分析和治理放入相互连接的工作环境，让这些团队减少跨工具搬运和重复配置。
客户使用Databricks的典型扩张路径是：先完成一项工程或AI任务 → 建立Workspace和生产管道 → 沉淀代码、模型和任务 → 用Unity Catalog等能力统一治理 → 扩展到SQL、Serverless和更多AI场景 → 扩大消费或用量承诺。
这是一种机制模型，不是公开统计证明的统一客户旅程。Databricks也会服务客户的SQL、数据库或Serverless需求，不是所有客户都按“工程、治理、AI”的顺序扩大使用。
2026年2月，Databricks公司自报收入运行率超过54亿美元、Q4同比增长超过65%，AI产品收入运行率超过14亿美元，客户超过20,000家。dbx-scale
这些不是经审计年度收入。Q4同比增长也不是全年增速，AI收入运行率不能证明AI项目的生产占比、持续性或客户ROI。
Databricks用DBU、DSU和不同SKU衡量服务消费。经典计算通常同时产生Databricks平台消费和客户直接支付给云厂商的虚拟机、存储与网络费用。dbx-pricing
Serverless计算由平台管理更多底层资源，可以减少部分机器管理，但不保证总成本下降。客户仍要管理用量、权限、数据位置和业务价值，计费项目及平台依赖也可能增加。
只有订单引用Usage Commit Terms并包含相应承诺时，True-up和Burst规则才适用；订单冲突时以订单为准。未完成承诺可能产生True-up，AWS/GCP超额Burst通常按月后付。dbx-commit
Unity Catalog在机制上可通过权限、血缘和资产目录支持跨团队扩张，但公开资料不足以证明多数客户都按同一顺序采用。Delta等开放格式改善文件层可移植性，作业、Notebook、治理和团队技能仍可能锁定。
五、两种商业模式的关键差异#
| 问题 | Snowflake | Databricks |
|---|---|---|
| 常见进入点 | SQL分析、数据仓库、低运维迁移 | 数据工程、Spark、AI/ML、开放数据湖 |
| 最初拥护者 | 分析师、数仓团队、业务数据负责人 | 数据工程师、数据科学家、平台团队 |
| 第一层价值 | 隐藏更多基础设施复杂度 | 提供更灵活的工程与AI工作环境 |
| 扩张抓手 | 数据、Warehouse、部门、共享、应用与AI | 作业、治理资产、SQL、Serverless、模型与AI应用 |
| 商业承诺 | Capacity安排和续约增购 | 适用订单中的Usage Commit、True-up和Burst |
| 主要风险 | 消费失控、云与AI成本、任务流失 | 工程门槛、复合账单、AI难生产化、流程锁定 |
最简洁的理解是：Snowflake通常先帮助客户降低分析基础设施复杂度；Databricks通常先帮助客户的数据工程与AI团队把数据处理、程序开发和模型运行连接起来。两者功能覆盖重叠扩大，但服务顺序、部署、计费和用户习惯仍有明显差异。
六、客户实际上如何合作#
| 阶段 | 主要活动 | 关键文件 | 常见风险 |
|---|---|---|---|
| 需求 | 明确报表、工程、AI或治理问题 | 内部需求、预算申请 | 没定义问题就采购技术 |
| 选型 | 比较现有云、技能、迁移、成本和退出 | RFI/RFP、架构和安全评审 | 只比较功能 |
| POC | 用有限数据验证开发、权限、性能和成本 | 保密、试用条款、POC计划 | 样本不代表生产环境 |
| 商务谈判 | 确定期限、承诺、价格、Region、支持与责任 | 主协议、订单、DPA、安全附件 | 低估超额、云费和退出成本 |
| 迁移上线 | 接入数据、转换代码、配置权限、测试培训 | SOW、变更单、验收方案 | 访问过宽、范围膨胀、双平台成本 |
| 日常运营 | 管道、质量、权限、事件和预算管理 | 运行手册、支持订单、责任矩阵 | 多方推诿 |
| 扩张续约 | 增加部门、任务、支持和第三方产品 | 增购与续约订单 | 消费增长快于价值 |
| 退出 | 取回数据、迁移代码权限、切换应用、申请删除 | 终止通知、迁移SOW、删除请求 | 中断、残留和双平台费用 |
| 主体 | 提供什么 | 获得什么 | 对客户承担什么 |
|---|---|---|---|
| 平台厂商 | 软件、控制面、托管能力和标准支持 | 平台消费与支持收入 | 产品、安全措施、合同与适用SLA |
| 云厂商 | 计算、存储、网络和Region | 云资源费 | 底层基础设施责任 |
| 实施伙伴 | 选型、迁移、建模、权限、培训和运维 | 实施费和托管费 | 自有交付、人员及数据访问责任 |
| 经销商 | 授权订单和商务结算 | 经销收入 | 自有订单责任，不能替平台任意承诺 |
| 客户 | 数据、场景、预算、配置和人员 | 业务结果与内部能力 | 数据合法性、授权、配置、成本和使用责任 |
各方利益不完全一致。平台厂商和云厂商希望用量增长，实施伙伴希望扩大项目，客户则希望结果明确、成本可控且能够退出。客户必须保留架构、预算、权限和价值判断权。
七、合同栈决定合作边界#
| 文件 | 主要解决什么 | 通常没有解决什么 |
|---|---|---|
| MSA或标准服务条款 | 使用权、知识产权、付款、责任、期限和终止 | 具体购买量和实施方法 |
| Order Form | SKU、期限、承诺、价格、Region和支持等级 | 迁移步骤和业务口径 |
| DPA | 个人数据处理、指令、子处理者和删除 | 所有业务数据的内部治理 |
| Security Addendum | 厂商加密、访问、审计和事件响应 | 客户是否正确配置权限和网络 |
| 平台可用性SLA | 可用性目标、申请期限和服务补偿 | 业务损失的全面赔偿 |
| 支持政策 | 问题等级和初始响应目标 | 平台不间断或解决时限保证 |
| SOW | 实施范围、人员、访问、交付、验收和费用 | 平台长期使用权 |
| 经销/Marketplace条款 | 第三方订单、付款和责任 | 经销商替平台改变所有条款的权利 |
商业Order Form通常保密。公开主协议能说明合同骨架，不能证明客户真实折扣、最低消费、责任上限或定制承诺。
Snowflake的公开可用性SLA要求客户在适用期限内主动申请，补偿通常是后续Snowflake Credits而非现金，并存在排除事项。Databricks支持按等级提供不同初始响应目标；15分钟只适用于Mission Critical的特定严重级别。snow-sla dbx-support
平台可用性补偿和支持响应目标都不是全面业务赔偿。客户仍需自己的监控、备份、降级和事件责任分工。
八、客户总成本与按量风险#
Snowflake客户总成本通常包括：平台及AI消费、存储、跨Region或跨云传输、支持费、实施费、第三方产品费和内部治理人力。
Databricks经典计算通常包括：Databricks平台消费、云虚拟机/GPU、对象存储、网络、支持与安全附加项、实施费和内部平台人员。
Databricks Serverless计算减少客户直接管理集群的工作，但仍可能产生多类平台SKU、网络或传输费用，以及客户保留的云存储和外部服务费用。
| 消费方式 | 优势 | 风险 | 管理动作 |
|---|---|---|---|
| 即用即付 | 灵活，适合试验 | 单价较高、费用波动 | 预算告警、暂停规则、项目标签 |
| 承诺用量 | 折扣和预算安排 | 高估需求、未用或补足风险 | 依据历史分层承诺并留缓冲 |
| 超额消费 | 业务不中断 | Overage或Burst额外账单 | 月度预测和非关键任务限制 |
按量收费仍可能失控，因为启动资源的人和承担预算的人不同，平台与云账单分离，存储、复制、网络和AI费用容易被忽略，承诺还可能产生“把额度用完”的错误激励。
FinOps是持续分摊、监控和优化平台及云费用的工作。最小闭环是：标记负责人和业务场景，汇总账单，分摊用量，识别异常，执行优化，再根据真实历史调整下期承诺。
九、数据权限与安全责任#
“数据归客户所有”只回答权利问题。成熟项目还必须回答：存在哪里、谁能访问、为何处理、谁配置、终止后谁删除。
| 资产 | 控制与存放 | 谁可能访问 | 退出重点 |
|---|---|---|---|
| 客户业务数据 | 客户保留权利；位于Snowflake环境或Databricks客户/平台数据平面 | 客户授权用户；厂商在服务必要或依法场景 | 取回、历史版本和删除 |
| Usage Data | 平台依条款收集的查询日志和运行元数据 | 平台授权人员 | 保留期限和可导出性 |
| 代码、Notebook和任务 | Workspace、代码仓库或控制面 | 客户用户和授权实施伙伴 | 版本、依赖和调度重建 |
| AI输入输出 | 客户存储、平台或模型端点 | 客户、平台服务和指定模型伙伴 | 提示记录、评测数据和第三方条款 |
| 支持工单 | 厂商支持系统 | 支持人员和客户联系人 | 敏感信息误提交 |
| 审计日志 | 平台或客户日志库 | 安全管理员和平台授权人员 | 保留、导出和导出后的保护 |
Snowflake标准条款确认客户保留Customer Data权利，同时授权Snowflake在提供服务、处理技术问题或满足法律要求所需范围内处理。Usage Data可含查询日志和对象定义，并用于运营、支持和改进。snow-tos
Snowflake自身专业服务需要数据访问时，应由SOW明确；默认规则偏向项目期间、开发环境、只读和避免敏感数据。该规则不会自动约束独立实施伙伴，客户必须在自己的SOW和数据附件中另行约定。
Databricks数据平面可能在客户云账户，也可能在Databricks控制的云账户；依配置和功能，Customer Content可位于两者。dbx-security
Databricks个人数据、Workspace内容、审计日志和控制面韧性备份不能混为一谈：
- DPA规定，客户自行备份个人数据；终止后书面请求触发30天内删除或协助删除其控制的Customer Personal Data；
- Workspace取消后，其中Customer Content在30天内永久删除；
- 审计日志和系统表至少保存一年，可能包含查询文本等敏感信息；
- 控制面韧性备份只用于紧急恢复，不供客户恢复；Databricks不为Customer Content提供客户备份。dbx-dpa dbx-security
平台提供加密和身份能力，不代表客户配置自动安全。客户仍要管理账号、权限、网络、密钥、日志、离职撤权和AI功能使用范围。
十、留存、锁定与退出#
| 层级 | 锁定来源 | 退出动作 | 主要风险 |
|---|---|---|---|
| 合同 | 期限、Capacity、Usage Commit、支持和第三方订单 | 通知、处理承诺和停止订阅 | 未用承诺、True-up、支持中断 |
| 数据 | 平台存储、历史版本、备份和共享 | 导出、校验、停止共享、申请删除 | 遗漏、传输费和残留副本 |
| 代码 | SQL、dbt、Notebook、UDF、任务和模型 | 转换、重建调度、并行验证 | 语义差异和业务错误 |
| 治理 | Catalog、权限、血缘、标签和审计 | 导出元数据、重建角色与策略 | 权限错误和审计断裂 |
| 应用 | BI、营销、API和下游系统 | 切换连接、回归测试、双写双读 | 业务中断 |
| 组织 | 技能、流程、成本分摊和供应商关系 | 培训、职责调整和运维交接 | 知识丢失和效率下降 |
Snowflake标准条款规定，客户书面通知后可获得最长30天取回权；取回期间合同和适用费用仍有效，之后平台不再有义务提供Customer Data并按条款删除。实际Order可能修改适用结果。snow-tos
开放格式主要改善文件被其他引擎读取的能力，不会自动迁移权限、血缘、任务、SQL差异、模型服务、监控、成本分摊和员工知识。
最低退出准备包括：确认合同取回和删除规则；同步代码、配置和元数据；使用版本控制和自动验证；维护报表/API依赖图；预留双平台预算；结束后取得撤权、密钥轮换和删除记录。
十一、四个案例揭示什么#
1. Canva：扩张与成本治理#
Snowflake客户材料显示，Canva此前将AI/ML与分析置于不同平台，选择Snowflake的理由包括存算分离、使用计费、易用性和可靠性。厂商宣称的节省不能视为独立审计ROI。canva-vendor
Canva工程博客确认，超过三分之二员工会通过直接查询、仪表板或依赖Snowflake的下游工具等方式直接或间接交互。其外围连接S3、Fivetran、dbt、Census、Looker和Mode。canva
Canva还自行建设查询标签、成本归属、工作负载监控和多年元数据保留。这证明平台可扩展到广泛组织使用，也证明托管平台没有替客户完成全部FinOps和数据治理。
2. Tacoma市：部门采用到组织标准化#
Tacoma公开采购文件显示，Snowflake先由公用事业部门使用，2020年扩为全市企业平台并连接Tableau。2025年增加17.5万美元后，合同累计额为62.5万美元。tacoma
该案例证明部门采用可通过标准化、共享工具和组织成本理由扩展为企业合同。累计合同额不是单年消费，也不能用于推导普通客户的Credit价格和折扣。
Tacoma还估计当时更换平台需100万美元以上和至少六个月。这只是采购方在特定续约窗口的判断，不是迁移市场均值。
3. Walmart Scintilla：数据产品与技术归因#
Walmart Data Ventures把第一方零售与运营数据形成面向供应商、广告商和伙伴的数据及应用产品。Media Data Feed是API Feed，客户可批准约500项预整理数据元素给可信伙伴。walmart
Walmart与Databricks联合材料支持部分Cloud Feeds使用Delta Sharing/OpenSharing进行共享。该部分可说明Databricks帮助跨组织交付数据，但不能把Media Data Feed、Scintilla In-Store或Walmart整体数据平台全部归因于Databricks。walmart-dbx
案例真正证明的是：企业可把内部数据治理能力发展为外部数据产品，而授权、筛选和交付接口是商业模式的一部分。
4. IRS：大型受监管采购#
USAspending显示，IRS授予Databricks Federal的合同当前已义务金额约1,454万美元，潜在总额约9,063.9万美元；当前期至2027年1月，潜在至2029年1月。irs
采购内容是平台许可和支持，用于数据现代化。SAM记录还引用Databricks主协议与公共部门服务条件。该案例证明大型客户购买的是许可、支持、期限和公共部门条件的组合。
公开文件不能拆分DBU、支持、安全附加项或实施比例。潜在金额也不是已义务、已支付或已消费金额，政府采购不能代表普通商业客户。
十二、主营业务、市场地位和潜力#
Snowflake的主营业务是托管式数据与AI平台，主要从计算、AI服务、存储和相关能力的持续消费获得产品收入。上市公司财报使其收入、毛利和客户扩张机制较可验证。
Databricks的主营业务覆盖数据工程、分析、治理、机器学习、数据库和AI应用，通过DBU、DSU、不同SKU、Serverless、支持和适用订单中的Usage Commit形成收入。
两者不能用一个“总市占率”严谨排序。数据仓库、湖仓、工程、机器学习和AI平台的市场边界不同；Snowflake审计产品收入与Databricks公司自报运行率也不能计算规模差额。
| 维度 | Snowflake | Databricks | 证据限制 |
|---|---|---|---|
| 规模 | FY2026产品收入44.72亿美元 | 公司自报运行率超54亿美元 | 审计收入与运行率不可排序 |
| 增长 | 产品收入同比29% | 公司自报Q4同比超65% | 时间与披露强度不同 |
| 扩张 | NRR 125%，既有客户Capacity收入占比约97% | 公司自报留存及Commit机制 | 没有同口径公开指标 |
| 覆盖 | 分析、工程、共享、应用和AI | 工程、治理、SQL、数据库和AI | 功能重叠不等于交付方式相同 |
长期潜力来自云迁移、AI生产化、跨部门共享、外部数据产品、Serverless和伙伴生态。增长也受客户优化、云厂商与开源竞争、多平台并存、安全监管、预算失控和退出担忧约束。
本报告的谨慎判断是：两家公司都已形成大规模业务，并位于长期增长的数据与AI市场；功能覆盖重叠扩大，但未来增长质量取决于客户价值能否持续快于成本和复杂度。
十三、面向中国企业的小团队机会#
1. 当前能确认什么#
国内不缺BI、数据开发和治理产品。Quick BI、WeData、DataArts Studio及云数据库已经覆盖大量能力；政策也鼓励“小快轻准”的中小企业数字化方案。cn-platform cn-policy
这只能证明市场存在产品和转型工作，不能证明目标客户会购买三人团队的服务。
2. 待验证切口#
暂定服务是：在客户现有环境内，将分散的经营数据或AI知识来源整理成可信、可监控、可移交的资产。
员工100—1000人只是搜索边界，不是购买资格。合格线索还应满足：过去90天发生具体问题；问题重复并有不解决成本；有人裁决口径；有人批准权限；有人承担预算。
首轮学习对象可以包括多SaaS企业、SaaS/互联网、专业服务机构和企业AI团队，但不能称为已经验证的最佳市场。
3. 待验证服务闭环#
| 阶段 | 目的 | 边界 |
|---|---|---|
| 付费诊断 | 固定问题、数据源、负责人、权限和验收 | 客户是否愿意付费尚未验证 |
| 固定范围实施 | 交付首个可运行结果 | 周期和数据源数量只能在诊断后确定 |
| 月度运维 | 监控、质量、权限和小范围变更 | 需工时包、响应目标、超包和变更单 |
| 增值模块 | AI评测、FinOps、新数据源、API和退出准备 | 只在客户有明确问题时销售 |
该闭环借鉴两家公司“先进入、再扩张”的机制，但把收费对象改为有限业务结果和运行责任。
4. 最低信任门槛#
“数据留在客户环境＋最小权限”只是设计原则，不等于团队已具备企业安全能力。进入受控环境前至少需要：
- 保密协议、数据处理附件和责任上限；
- 实名账号、MFA、短期凭据、生产审批和审计日志；
- 受管设备、禁止个人存储、样例脱敏和AI工具规则；
- 人员入离场、分包商审批和最小知情范围；
- 事件通知、证据保留、恢复分工和项目结束撤权。
5. 不能当成结论的数字#
诊断、实施和月度运维价格，2—4个数据源、4—6周周期，36—42可交付人日，续费率、复用率和毛利，全部是测试假设而非市场事实。
详细价格敏感度、容量模型和90天验证方案见中国中型企业数据与AI服务创业方案。正式报告不使用这些数字预测收入。
Phase 4B至少需要验证：8家企业确认同类问题；2家产生付费；1个项目验收；1个客户续费或购买二期；取得真实成本和毛利；验证最小权限运维与第二项目复用。
6. 现阶段不做什么#
- 不自建通用数据平台、数据库或BI；
- 不未经授权转售平台；
- 不用“数据中台”“AI中台”扩大无法验收的范围；
- 不取得长期管理员权限或无限接入历史数据；
- 不把AI Agent能力当成护城河；
- 不把报价假设写成市场成交价。
十四、关键术语#
| 术语 | 白话解释 | 商业意义 |
|---|---|---|
| Snowflake Credits | Snowflake计算和部分服务的使用计量单位 | 乘合同价格构成部分账单，存储和传输可能另算 |
| DBU/DSU | Databricks不同服务的使用单位 | 经典计算还可能叠加云资源费 |
| Capacity安排 | Snowflake客户对未来使用容量的商业承诺 | 换取条件并形成收入储备，但收入通常按消费确认 |
| Usage Commit | Databricks适用订单中的用量承诺 | 可能有True-up和超额费用，不适用于所有客户 |
| True-up | 期末补足适用订单中未完成的付款承诺 | 揭示按量模式背后的最低商业义务 |
| NRR | 同一批既有客户本期收入相对上期的变化 | 高于100%表示扩张超过缩减和流失 |
| RPO | 已签合同中尚未确认为收入的金额 | 是收入储备指标，不等于现金或未用额度 |
| 收入运行率 | 将近期收入节奏年化 | 不是审计年度收入，也不能自动等同ARR |
| 控制平面 | 管理账号、权限、任务、代码和元数据的后台 | 业务数据在客户云中时，平台仍可能持有关键控制信息 |
| 数据平面 | 真正执行计算并处理数据的环境 | 所在云账户影响费用、安全和控制权 |
| 平台可用性SLA | 平台可用性的有限合同承诺 | 失败补偿通常有限且需申请 |
| 支持响应目标 | 厂商对不同严重级别问题的初始响应时间 | 不等于问题解决时限或业务赔偿 |
| SOW | 实施工作的说明书 | 决定范围、访问、交付、验收、责任和费用 |
| 元数据/血缘 | 数据结构、来源、处理路径、权限和去向 | 丢失后即使文件仍在，也需重建治理和含义 |
| Serverless计算 | 平台管理和伸缩更多底层计算 | 减少部分运维，不保证总成本下降 |
| FinOps | 持续分摊、监控和优化平台及云费用 | 按量模式把更多成本责任交给客户 |
| 开放格式 | 可被多种引擎读取的数据文件或表格式 | 降低文件锁定，不自动迁移代码和流程 |
| 数据产品 | 对明确用户持续提供、有责任人与质量标准的数据服务 | 可将内部数据变成可复用或收费产品 |
十五、研究限制#
- Snowflake采用监管文件；Databricks规模数据主要来自公司披露，二者证据强度不对称。
- 商业Order Form通常保密，无法确认所有客户的折扣、责任上限和定制承诺。
- 客户案例能证明使用方式和合作路径，不能单独证明普遍ROI。
- 数据仓库、湖仓、工程和AI平台市场边界不同，本报告不提供伪精确总市占率。
- 中国创业方案未完成访谈、付费、验收、续费和真实毛利验证。
- 产品、价格和合同会变化，实际采购需重新核验研究截止日后的最新版文件。
相关笔记#
- Snowflake 与 Databricks 项目笔记
- Snowflake 与 Databricks Phase 6 审校记录
- Snowflake 与 Databricks 证据账本
- 中国中型企业数据与AI服务创业方案