◈ DB 选型参考
← 返回首页

Databricks

OLAP #Lakehouse #Delta-Lake #Apache-Spark #Unity-Catalog #Photon #DBU计费 #Serverless #多雲 #MLOps

由 Apache Spark 原班人马创立的云原生 Lakehouse 平台——"数据湖的规模 + 数仓的可靠性 + AI 的原生底座"：以 Delta Lake（ACID 事务日志）统一存储、Unity Catalog 统一治理、Photon 向量化引擎加速查询，一套平台覆盖数据工程、BI、机器学习与 AI Agent；代价是纯云上消费制计费（DBU + 云资源双账单）、Spark 调优负担、以及"数据是开放的、平台是私有的"锁定结构。

用 AI 深挖这款：
证据等级：官方文档 厂商口径 社区实测 社区共识 待验证

基本信息

项内容
厂商Databricks, Inc.（2013 年成立，总部旧金山；创始人为 UC Berkeley AMPLab 的 Apache Spark 原班团队：Ali Ghodsi、Matei Zaharia 等 7 人）
国家美国
起源2013 年由 Spark 创始团队创立；2020 年提出 Lakehouse 架构；2023 年收购 MosaicML 切入生成式 AI
许可证平台为专有商业软件（无开源版本）；Delta Lake、MLflow 等核心组件开源（Delta Lake 已捐给 Linux 基金会）
商业版说明纯消费制：按 Databricks Unit（DBU）计费，不同工作负载（数据工程/SQL 分析/机器学习）费率不同；经典计算另收底层云资源费，Serverless 含基础设施费。具体价格随云厂商/地区/合同变化，本档案不写绝对价格
托管服务本身就是全托管云服务，覆盖 AWS / Azure / GCP；2025 年后主推 Serverless 计算
主类型Lakehouse 平台（数据工程 + 数仓 + AI 统一）
兼具类型流批一体处理、ML 平台（MLOps）、AI Agent 平台（Mosaic AI / Agent Bricks）、数据共享

硬维度（47 项）

1 静态加密 / TDE 有

  • 数据实际落在客户自己的云存储（S3/ADLS/GCS），默认走云厂商服务端加密（SSE）；控制面元数据由 Databricks 加密 官方文档。
  • 支持客户管理密钥（CMK/Customer-managed keys）：密钥存客户自己的 KMS（AWS KMS / Azure Key Vault），可覆盖工作区存储与 Unity Catalog 元存储 官方文档。
  • 合规安全配置文件（Compliance Security Profile）可强制加密与密钥策略，是过 HIPAA/PCI 等认证的前置条件 官方文档。

2 TLS / 传输加密 有（TLS 1.2+ 全链路）

  • 控制面与计算面之间所有通信 TLS 加密；Secure Cluster Connectivity 走加密 WebSocket 隧道 官方文档。
  • JDBC/ODBC、REST API、Notebook 流量均为 HTTPS/TLS；官方安全基线要求 TLS 1.2 以上 社区共识。
  • 无明文回退：不存在"开了 TLS 还留着明文端口"的自建式坑，端口暴露面由云网络配置决定 社区共识。

3 审计 有

  • 审计日志记录工作区操作、数据访问、权限变更等事件，可投递到客户 S3/ADLS（建议配对象锁定防篡改）再接入 Splunk/Datadog 官方文档。
  • Unity Catalog 的 system.access.audit 系统表可 SQL 直接查"谁在何时访问了哪张表"，是数据访问审计的主入口 官方文档。
  • 注意：审计日志投递与保留策略要自己配；老工作区若未启用 Unity Catalog，表级审计粒度会打折 社区共识。

4 认证与权限 有

  • 身份：SSO（SAML/OIDC）、MFA、SCIM 用户同步；自动化用 Service Principal 而非个人账号 官方文档。
  • 授权：Unity Catalog 三级命名空间（catalog.schema.table）统一管表、文件（Volume）、模型、函数乃至 AI Agent 的权限；支持行级安全、列掩码、动态视图 官方文档。
  • 遗留坑：2023 年前建的老工作区可能是 Hive Metastore 模式，权限是另一套；迁移到 Unity Catalog 是生产合规的必经之路，迁移本身有工作量 社区共识。

5 备份恢复 部分支持

  • Delta Lake 自带时间旅行（Time Travel）：可按版本号/时间戳查询历史快照，误删/误写后可回滚到历史版本 官方文档。
  • CLONE（浅/深克隆）可快速复制表做恢复演练或测试环境；VACUUM 控制历史保留期 官方文档。
  • 但没有传统数据库式的"全库备份/时间点恢复"一键方案：数据在客户云存储上，备份策略（跨区复制、生命周期）要按云厂商最佳实践自己做；工作区配置（Job 定义、权限）的备份靠 Terraform/导出 社区共识。

6 可观测性 有

  • system schema 系统表极丰富：system.billing.usage（DBU 消费明细，可 join 价格表算钱）、system.access.audit（审计）、system.query.history（查询历史与耗时）官方文档。
  • Spark UI / Ganglia 看作业执行细节（stage、shuffle、GC）；SQL 仓库有查询历史与执行计划 官方文档。
  • 成本可观测是刚需：DBU 只显示消费量不显示"为什么"，必须靠 system 表 + 打标签（tag）做分团队 chargeback，否则账单黑盒 社区实测。

7 连接模型 有

  • BI/应用走 SQL Warehouse：标准 JDBC/ODBC、Python SQL 连接器；Serverless SQL 仓库免运维、自动启停 官方文档。
  • 编程入口：REST API、Databricks Connect（本地 IDE 连远程集群）、各语言 SDK；Notebook 支持 Python/SQL/Scala/R 多语言协作 官方文档。
  • 无传统"连接池打爆"问题：连接本身轻量，瓶颈在计算资源（DBU）配额与并发 slot；SQL 仓库的并发靠自动扩缩容 社区共识。

8 事务与隔离级别 有

  • Delta Lake 在对象存储上实现 ACID：事务日志 + 乐观并发控制，多写者并发写同一表由协议仲裁 官方文档。
  • 默认隔离级别为可串行化（Serializable）；支持 MERGE、UPDATE、DELETE 等 DML，schema 强制与演进 官方文档。
  • 注意：这是"分析型事务"（ETL 写入、 slowly changing dimensions），不是 OLTP 行级锁；高频小事务写入会有小文件与日志膨胀问题 社区共识。

9 复制与一致性 部分支持

  • 对外复制/共享：Delta Sharing 开放协议，可把实时表安全共享给外部组织（对方用任意引擎读），无需复制数据 官方文档。
  • 云内高可用：数据在云存储上天然多 AZ 冗余；计算无状态，挂了重拉 社区共识。
  • 无内置的跨区主动-主动复制：多 Region 部署的数据同步与一致性要自己设计（存储复制 + 作业调度），跨区 egress 费用是隐藏大头 社区共识。

10 扩展方式 有

  • 经典集群：按任务队列在 min/max worker 区间自动扩缩；实例池（Instance Pools）缩短冷启动 官方文档。
  • Serverless 计算：免集群管理、秒级启动、按实际用量计费，是 2025 年后官方主推方向 官方文档。
  • 边缘真相：自动扩缩的上下限配得太宽会"易上难下"，缩容滞后吃掉 DBU；Photon/Serverless 缩短的是 wall-clock，不是单价 社区共识。

11 兼容性 有

  • API：完整 Spark API（DataFrame/SQL/Streaming/MLlib），PySpark 是事实标准入口；Databricks Runtime 是优化版 Spark 官方文档。
  • 表格式：Delta Lake 底层是 Parquet + 事务日志，任何能读 Parquet 的引擎都能读数据；与 Apache Iceberg 互读能力持续增强（UniForm 等），"换引擎不搬数据"是卖点 官方文档。
  • 注意：开放的是数据格式，不是平台 API——作业调度、权限、计费都绑定 Databricks 控制面；Photon 是闭源加速引擎 社区共识。

12 许可证与商业模式 有

  • 平台专有、无开源/自建版本：必须跑在 Databricks 账号体系下（AWS/Azure/GCP 三家云），不存在"下载一个 Databricks 装到自己机房" 官方文档。
  • 计费：DBU × 时长 × 工作负载类型费率；经典计算另付云资源费，Serverless 打包；企业合同价与目录价差异大 厂商口径。
  • 开源部分：Delta Lake（Linux 基金会）、MLflow、Apache Spark 本体开源，数据不被格式锁定是相对 Snowflake 的差异化 社区共识。

13 中文资料丰富度 部分支持（英文优先，中文在增长）

  • 官方文档以英文为主，部分有机器翻译中文；Azure Databricks 有较多中文文档（微软生态）社区共识。
  • 中文博客/课程在增长（CSDN、知乎、极客时间有 Databricks 系列），但深度内容（调优、Unity Catalog 迁移实战）英文仍多一个身位 社区共识。
  • 认证体系（Data Engineer Professional 等）为英文考试 待验证。

14 性能与延迟特征 有

  • Photon 向量化引擎：官方口径称相对开源 Spark 有数倍提升（TPC-DS 类基准），是 SQL 仓库与 DLT 的默认加速 厂商口径。
  • 典型延迟：SQL 仓库交互式查询秒级（TB 级聚合常见，社区多方实测）；流处理端到端秒级；2026 年发布的 Lakehouse//RT（实时引擎 Reyden）把目标打到亚秒级并发查询 社区实测。
  • 边界：毫秒级点查/高频 OLTP 不是设计目标；冷启动（经典集群拉起）曾是主要吐槽，Serverless 大幅缓解但仍非零 社区共识。

15 合规与认证 有

  • SOC 2 Type II、ISO/IEC 27001（2022 版，覆盖 AWS/Azure/GCP 三云）、ISO 27017/27018/27701、HIPAA、PCI-DSS、FedRAMP（指定区域）官方文档。
  • 合规安全配置文件（Compliance Security Profile）一键强化：FIPS 加密模块、增强审计等，是过等保/金融合规的标配动作 官方文档。
  • 注意：部分 AI 功能（如按 token 计费的 Foundation Model API）在非 HIPAA 合规档下受限；中国区无本地云（需经全球云部署）官方文档。

16 成熟度与社区生态 有

  • 2013 年由 Spark 原班团队创立，总部旧金山，员工 8000+（2025-2026 口径）；2024 年 12 月估值 620 亿美元，2025 年底超千亿美元，仍未 IPO 社区共识。
  • Spark 本体社区与 Databricks 生态高度重叠：技术问答、第三方书籍、认证体系成熟；Delta Lake、MLflow 开源社区活跃 社区共识。
  • 风险面：未上市公司的长期定价与战略存在不确定性；平台迭代快，API/默认行为变更需要跟进 社区共识。

17 标杆用户 有

  • 公开客户：AT&T、Block、Rivian、Walgreens、Mercedes-Benz、Shell、Siemens、Toyota、Warner Bros. Discovery；国内出海与跨国企业采用多 社区共识。
  • 互联网/AI 公司是基本盘：MosaicML 被收购前就是客户，收购后成为 Mosaic AI 底座 社区共识。
  • 采用模式常见：Databricks 做 ingestion/特征/训练，BI 层接 Power BI 或 Snowflake（双平台并存很常见）社区共识。

18 生态工具链 有

  • IaC：官方 Terraform Provider（工作区、集群、UC 权限、Job 全可代码化）；CI/CD 接 GitHub Actions/Azure DevOps 社区共识。
  • 数据栈：dbt-databricks 适配器、Airflow Provider、Fivetran/Airbyte 等 ingestion 工具官方 connector 社区共识。
  • ML：MLflow（Databricks 创始捐献）实验跟踪 + 模型注册 + Model Serving 一条龙 官方文档。

19 云托管与 Serverless 有

  • 三云全覆盖：AWS / Azure（Azure Databricks 为微软一等集成）/ GCP；不支持私有化部署，专有云/本地机房只能走混合架构 官方文档。
  • Serverless SQL 仓库与 Serverless 计算：免集群运维、快速启停、按量计费；经典集群仍可用于需要深度定制（VPC 注入、特殊实例）的场景 官方文档。
  • 成本注意：Serverless 单价高于经典 DBU，省的是运维与空转，不是单价；选型要按负载画像算总账 社区共识。

20 数据接入与摄入 有

  • Auto Loader（cloudFiles）：增量检测新文件落盘（S3/ADLS/GCS），schema 推断与演进，是"文件进湖"事实标准 官方文档。
  • COPY INTO：SQL 一次性/幂等批量加载；Delta Live Tables（现 Lakeflow Declarative Pipelines）：声明式 ETL，流批统一，内建数据质量期望（EXPECTATIONS）官方文档。
  • 流式：Spark Structured Streaming 直连 Kafka/Event Hubs/Kinesis，端到端 exactly-once 语义 官方文档。
  • 边缘：小文件碎片是湖仓通病，Auto Loader + OPTIMIZE/Z-ORDER 是标准治理动作；schema 漂移处理要显式设计 社区共识。

21 外部数据访问 有

  • 对外共享：Delta Sharing 开放协议，把实时 Delta 表安全共享给外部组织，对方用任意引擎（Spark/Pandas/Power BI）读，无需复制数据 官方文档。
  • 对内联邦：Lakehouse Federation 建外部连接（Connection）+ 外部目录（Foreign Catalog），直接查询 PostgreSQL/MySQL/Snowflake/BigQuery 等源，查询下推到源端执行，走 Unity Catalog 统一鉴权审计 官方文档。
  • 边界：联邦查询适合即席探索与小结果集；大体量反复扫描、高频生产查询仍建议先入湖（延迟与源端负载不可控）；跨云 egress 费用自理 社区共识。

22 CDC 与下游同步 有

  • Delta Change Data Feed（CDF）：表级开启后，下游可增量读取行的插入/更新/删除变更，是湖内 CDC 标准机制 官方文档。
  • DLT/Lakeflow 管道：APPLY CHANGES INTO 语法直接消费上游 CDC 做 SCD Type 1/2 拉链 官方文档。
  • 新方向：Lakebase（Databricks 的 Postgres 兼容 OLTP）→ Delta 的 Lakehouse Sync 原生 CDC，无需外部作业即可把操作库变更流进数仓 厂商口径。
  • 下游：出湖仓可经 Delta Sharing、JDBC/ODBC、或写回 Kafka/对象存储；CDC 链路延迟通常在秒到分钟级，不是毫秒级同步 社区共识。

23 TTL 与数据生命周期管理 有

  • Delta 表可设保留期，VACUUM 按保留期清理旧文件版本 官方文档。
  • 流式表/物化视图的增量过期逻辑需自己写清理任务 官方文档。
  • VACUUM 默认 7 天保留期防并发读写冲突，调小有风险 社区共识。

24 在线 DDL 与 Schema 演进 部分支持

  • 只改定义：加列走 mergeSchema/schema evolution，流批写入不中断；启用 column mapping 后改名/删列是纯元数据操作，不重写 Parquet 文件 官方文档。
  • 重写数据但住哪不变：兼容类型放宽（INT→LONG 等）需开启 delta.enableTypeWidening 特性（Delta 3.2+/4.0）才是元数据操作；不兼容的改类型需 overwriteSchema 重写 官方文档。
  • 搬数据：ALTER TABLE … CLUSTER BY（Liquid Clustering）本身是元数据操作、即时在线，但只影响未来写入；历史数据保持旧布局，需显式 OPTIMIZE（FULL）重写，按集群计算计费 社区共识。
  • 验证约束：NOT NULL 与 CHECK 强制执行，违例写入直接失败；PK/FK/UNIQUE 仅信息性不强制（需 Unity Catalog 与对应 Runtime 版本），只做优化器提示与血缘 官方文档。
  • 规模：第二、三类代价 O(n)；TB 级表 OPTIMIZE FULL 是"数小时 + 集群烧钱"，小表大表两个世界 社区共识。
  • 语义：Delta 事务日志保证 DDL 单语句原子提交；读走快照隔离、写走乐观并发，DDL 不阻塞并发读写；time travel 按版本保留各自 schema，旧版本可按旧 schema 查询 官方文档/社区共识。

25 多租户与资源隔离 有

  • 工作区、集群/ SQL Warehouse 按团队隔离，Unity Catalog 做数据权限 官方文档。
  • 计算资源按集群/仓库隔离，noisy neighbor 天然规避 官方文档。
  • 成本归因到工作区/集群标签，FinOps 友好 社区共识。

26 跨地域多活 部分支持

  • Delta Sharing 可跨区/跨云共享数据读 官方文档。
  • 写仍是单工作区/单区，无多活写入语义 社区共识。
  • region 容灾靠工作区备份重建，RTO 看数据量 社区共识。

27 高可用架构与 RTO/RPO 部分支持

  • 控制平面托管高可用，计算集群故障可重建恢复 官方文档。
  • Delta Lake 的 ACID 让任务重跑不脏数据，RPO 靠检查点 社区共识。
  • SLA 是平台级，具体 RTO 看集群重建时间 厂商口径。

28 行级安全与数据脱敏 有

  • Databricks Unity Catalog 提供 Row Filters（行过滤）与 Column Masks（列掩码），SQL 定义、集中治理 官方文档
  • 支持列级权限与动态视图 官方文档
  • 仅 Unity Catalog 治理的表生效；外部表 / 旧 Hive metastore 路径是绕过面 社区实测

29 JSON 与半结构化能力 有

  • VARIANT 半结构化类型（Photon），schema-on-read，自动演进 官方文档。
  • VARIANT 查询性能弱于规整列，热点路径建议规整化 官方文档。

30 全文检索能力 部分支持

  • Databricks SQL 无传统全文索引 官方文档。
  • 文本检索靠向量搜索/AI 检索，关键词精确检索弱 社区共识。

31 存储效率与压缩 有

  • Delta Lake 基于 Parquet 列存，默认 ZSTD/Snappy 压缩，压缩比高。官方文档
  • Photon 引擎与自动 OPTIMIZE（Z-Order、自动压缩）进一步提升存储与查询效率。官方文档
  • 开放格式下压缩参数用户可调，透明度高于纯黑盒云数仓。社区实测

32 开源协议与厂商锁定风险 部分支持

  • Delta Lake、Spark 等核心技术开源（Apache 2.0），数据以开放格式（Delta/Parquet）存储，可迁出。官方文档
  • Databricks 平台（Runtime 优化、Unity Catalog、AI 功能）为闭源，深度使用后存在平台绑定。厂商口径
  • 开放格式是实质缓解：数据本身不被锁定，锁定的是计算与治理层。社区共识

33 查询优化器与计划稳定性 有

  • Photon 引擎 + Spark CBO，自适应查询执行（AQE）运行时调优 官方文档。
  • 支持 Spark SQL hint 干预计划 官方文档。
  • 计划翻转少于传统数仓，但 AQE 行为不透明难排查 社区共识。

34 参数调优与自治能力 有

  • Photon 自动向量化，Liquid Clustering 自动数据布局，调参极少 官方文档。
  • 自动优化（auto optimize/compaction）后台进行 官方文档。
  • 集群规格选择仍是成本主因 社区共识。

35 静默数据损坏防护 部分支持

  • 数据文件落云对象存储，完整性依赖云厂商底层校验与冗余。厂商口径
  • Delta Lake 提供事务日志与版本化，逻辑损坏可回滚版本，但非静默位损坏检测。官方文档
  • 无用户可配的页/块校验开关，损坏审计依赖云厂商。待验证

36 存储过程/触发器/过程语言 部分支持

  • 无传统存储过程；靠 Notebooks/Workflows 编排，DBSQL 有脚本能力 官方文档。
  • 去 O 迁移时 PL/SQL 逻辑需重写为作业流 社区共识。

37 约束与数据完整性 部分支持

  • Delta 支持 NOT NULL/CHECK（有限），主键/外键为信息性不强制 官方文档。
  • 完整性靠写入链路（DLT expectations）保证 官方文档。

38 分析 SQL 完备性 有

  • Spark SQL 窗口函数、CTE 完备，分析函数丰富 官方文档。
  • 递归 CTE 支持有限，复杂递归改写为迭代作业 社区共识。

39 被遗忘权与数据擦除 部分支持

  • Delta Lake 的 Time Travel 使被删数据在保留期（默认 7 天）内可恢复；VACUUM 可清旧文件但有最小保留限制 官方文档
  • VACUUM 默认阻止删除 7 天内的文件，“立即擦除”需调参并承担破坏并发读取的风险 官方文档
  • 备份、Delta Sharing 共享副本延长残留面 社区共识
  • 无原生擦除证明 社区共识

40 数据血缘与目录集成 有

  • Unity Catalog 提供表/列级血缘、数据发现，自动采集 官方文档。
  • 血缘覆盖 notebook/作业/SQL 全链路 官方文档。

41 存算分离 vs 存算一体 有（存算分离：云存储+弹性集群）

  • 数据存云对象存储，计算集群弹性启停、独立扩缩 官方文档。
  • Serverless SQL 仓库进一步解耦 官方文档。
  • 跨云账户存储访问需网络配置 社区共识。

42 多模能力 有

  • Delta Lake：结构化、半结构化 JSON、Vector Search、MLflow 模型 官方文档。
  • 无原生图/全文检索引擎 社区共识。

43 FinOps 成本可观测性 有

  • 按 DBU（Databricks Unit）计量，支持按工作区/集群/作业归因用量。官方文档
  • 预算策略（budget policies）可限自定义标签的支出上限，超限告警。官方文档
  • 账单可导出做 FinOps 分析，是湖仓场景的成本可观测标杆之一。社区共识

44 驱动与多语言生态 有

  • 官方 JDBC/ODBC（Simba）、databricks-sql-connector（Python）官方文档。
  • BI 工具生态（dbt/PowerBI/Tableau）完备 社区共识。

45 物化视图 有（物化视图+DLT，增量自动刷新）

  • Databricks SQL 物化视图与 DLT 管道，增量刷新、查询自动改写 官方文档。
  • 刷新按计算资源计费，频繁刷新小表注意成本 厂商口径。

46 支持跨云 有

  • 同一平台横跨 AWS/Azure/GCP，是其核心卖点 官方文档。
  • Delta Sharing 可跨云共享数据 官方文档。
  • 跨云有数据传输费，大表要算账 社区共识。

47 热点数据更新能力 部分支持

  • 并发原语为 Delta Lake 乐观并发：写者各自基于快照准备变更，通过对 _delta_log 中编号 JSON 日志文件的原子 PUT 提交，粒度是文件/分区而非行 官方文档。
  • 提交时若与已提交版本存在重叠数据（同行/同分区并发 MERGE），后来者提交失败并抛 ConcurrentAppendException 等冲突异常；内核不自动重试，重试+退避必须由应用或编排器实现 社区共识。
  • 热点打到同一分区即串行瓶颈：除胜者外所有提交全部失败重试，吞吐随冲突率线性衰减；事务日志的单点提交是全局串行化点 社区共识。
  • 未找到官方命名或文档化的热点行机制的证据；DBR 11.x 起并发写不同分区的表不再冲突，这是通过分区设计规避冲突，而非内核打散热点 待验证。
  • 推荐模式有三类：按高基数字段分区让并发作业写入不相交分区（代价是分区倾斜与 ZORDER 维护成本）、真正冲突的写用队列串行化（代价是吞吐封顶）、应用层退避重试（代价是延迟抖动）；Delta Live Tables 只是声明式微批管线，底层仍是同一套 OCC 语义，不改变点更新结论 社区共识。

招牌能力

写法要求：每个特性 = 它是什么 + 为什么是真本事 + 推到边缘会发生什么。

  1. Delta Lake：对象存储上的 ACID 与时间旅行 真本事：Parquet 文件 + 事务日志，在廉价对象存储上实现可串行化事务、schema 强制/演进、版本回溯；数据湖从此有了数仓的可靠性承诺。 边缘真相：高频小写入会产生小文件海与日志膨胀，OPTIMIZE/VACUUM 是必修运维；CDF 开久了变更日志本身成为存储与读取成本；把 Delta 当 OLTP 行级更新用是反模式。
  2. Unity Catalog：数据与 AI 资产的统一治理 真本事：三级命名空间 + 细粒度权限 + 列掩码/行过滤 + 全链路血缘 + 审计，一套模型同时管表、文件、模型、函数乃至 AI Agent；联邦查询也走同一套鉴权。 边缘真相：老工作区 Hive Metastore 迁移是真实项目制工作；权限模型配错会在"过松"与"分析师什么都查不了"之间摇摆；血缘覆盖第三方写入路径时有盲区。
  3. Photon：Spark 生态的向量化加速 真本事：C++ 重写的向量化执行引擎，对 SQL 与 DataFrame API 透明加速，TPC-DS 类查询数倍于开源 Spark；SQL 仓库默认开启。 边缘真相：UDF 密集、Python 逐行逻辑的作业吃不到 Photon 红利；加速比是 workload 相关的，官方基准数字不等于你的查询；Photon 是闭源，调优黑盒程度更高。
  4. 流批一体（Structured Streaming + DLT）：一套代码两种速度 真本事：同一套 DataFrame API 跑批也跑流，exactly-once 语义；DLT 声明式定义管道，引擎管编排、增量、数据质量期望。 边缘真相：流作业的 checkpoint 与状态后端是运维深水区；late data 与 watermark 语义配错会丢数或重数；DLT 的声明式抽象在复杂依赖面前仍要理解执行计划。
  5. Mosaic AI / Agent Bricks：湖仓之上的 AI 原生层 真本事：Vector Search、Foundation Model API、Model Serving 与 Unity Catalog 治理打通；Agent Bricks 把 Agent 当版本化资产（agent-as-a-table）构建评测部署。 边缘真相：按 token/DBU 双重计费下，大模型调用成本先算清再上线；评测基准（relevance/groundedness）配不好等于自嗨；RAG 质量最终还是取决于湖里数据的质量。

深水区

以下每条 = 领域 + 机制一句话 + 推到边缘会发生什么 + 选型含义。证据类型已标注。

深水区一：DBU 计费——账单是第二套"查询优化器"

  • 领域：成本模型。
  • 机制一句话：消费按 DBU（Databricks Unit）× 时长 × 工作负载费率，外加经典计算的底层云资源费；DBU 只计量消耗，不解释"为什么消耗"。
  • 边缘行为：交互式集群忘记关、自动终止配 2 小时、扩缩上限过宽，DBU 在空转中燃烧；月度账单只给总数，不告诉你哪个 Job、哪个用户烧的——不做标签（tag）+ system.billing.usage 分析，成本归因就是黑盒。Serverless 按量但单价更高，"省心"不等于"省钱"。
  • 选型含义：上线第一天就建 FinOps：强制 auto-termination（15–30 分钟）、Job 集群替代常驻交互集群、按团队/项目打标签 chargeback；POC 必须跑真实 workload 测 DBU/查询。
  • 来源：官方文档（计费与 system 表）+ 社区成本优化实践。

深水区二：小文件与 Delta 日志膨胀——湖仓的慢性病

  • 领域：存储与写入路径。
  • 机制一句话：每次写入生成新 Parquet 文件 + 事务日志条目；流式/高频微批写入天然产生海量小文件。
  • 边缘行为：小文件过多导致 list 开销、查询计划膨胀、合并读放大；OPTIMIZE（compaction）与 Z-ORDER 是常规药，但大表 OPTIMIZE 本身是重型作业，要和业务错峰；VACUUM 保留期设太短会删掉时间旅行需要的历史，设太长存储与 CDF 成本上升。
  • 选型含义：写入链路必须设计文件大小目标（如 Auto Loader 触发阈值）；把 OPTIMIZE/VACUUM 纳入定期运维，而不是救火。
  • 来源：官方文档 + 社区实践。

深水区三：Spark 调优负担——平台托管了机器，没托管复杂度

  • 领域：计算调优。
  • 机制一句话：Databricks 管集群生命周期，但 shuffle 分区数、数据倾斜、broadcast 阈值、Photon 是否生效，仍是用户作业的属性。
  • 边缘行为：数据倾斜的 join 在 Serverless 上一样慢，只是换了一种计费方式慢；AQP/Photon 掩盖不了糟糕的分区裁剪；从"能跑"到"跑得便宜"之间隔着 Spark UI 解读能力。小团队若无人懂 Spark，平台优势兑现度打折。
  • 选型含义：团队至少要有一名能读 Spark UI 的人；SQL 仓库 + Photon 覆盖 80% BI 场景，把"裸 Spark 调优"留给真正的重型 ETL。
  • 来源：社区共识 + 官方性能指南。

深水区四：Unity Catalog 迁移——老工作区的成人礼

  • 领域：治理与迁移。
  • 机制一句话：UC 是账号级三级命名空间治理，老工作区是工作区级 Hive Metastore；两者权限模型不互通。
  • 边缘行为：迁移要重建 catalog/schema/table 映射、重授权限、改作业引用路径；外部表（external location）的存储凭证要逐个迁移；迁移期间新老两套权限并存，最容易出"以为有权限其实没有"或反过来的事故。官方有 UCX 迁移工具，但大型工作区仍是项目制。
  • 选型含义：新上直接 UC；老用户把 UC 迁移排进路线图，合规审计（等保/金融）通常以 UC 为前提。
  • 来源：官方文档（UC 迁移指南）+ 社区迁移实践。

深水区五：跨云/跨区的数据重力——egress 是隐形税

  • 领域：多雲部署。
  • 机制一句话：Databricks 计算与存储解耦在客户云账号内，跨区/跨云读写的流量费由云厂商收，不在 DBU 里。
  • 边缘行为：多 Region 容灾、跨云联邦查询、Delta Sharing 给外部 Azure 订阅者，egress 账单可能超过 DBU 本身；"在一个云做计算、另一个云存数据"的架构在财务上通常不成立。
  • 选型含义：计算与数据同区部署是铁律；跨云场景优先用 Delta Sharing 的"就近读"而非"拉回来算"；POC 阶段就把 egress 计入 TCO。
  • 来源：社区共识 + 云厂商计费文档。

深水区六：Serverless 的边界——不是所有负载都适合

  • 领域：计算形态。
  • 机制一句话：Serverless 免运维、秒级启动、按量计费，但网络是 Databricks 托管（无 VPC 注入）、实例类型不可选、单价高于经典 DBU。
  • 边缘行为：需要 VPC 注入、私有终端、特殊合规网络隔离的场景只能用经典集群；长稳态重负载下，经典预留/竞价实例的总成本可能更低；Serverless 的"自动"在超大 shuffle 作业面前仍可能遇到配额与并发上限。
  • 选型含义：按画像选形态——BI/即席/波动负载走 Serverless，网络强管控/超大批处理走经典；不要"全 Serverless"一刀切。
  • 来源：官方文档 + 社区实践。

深水区七：AI 负载的双重计费——token 与 DBU 叠加

  • 领域：AI/ML 成本。
  • 机制一句话：Foundation Model API 按 token 计费，Model Serving 按 DBU/预置吞吐计费，Vector Search 索引同步另耗计算。
  • 边缘行为：RAG 的 embedding 回填、Agent 的多轮调用、评测集的大批量跑分，三项叠加后 AI 账单可能超过数仓账单；"先上线再看账单"的团队会被教育。
  • 选型含义：AI 功能上线前做 token 预算；评测与回填用采样/错峰；把 AI 成本单独打标签核算。
  • 来源：官方文档（Model Serving 计费）+ 社区实践。

客户经验

内核 Photon 向量化引擎

一句话
用 C++ 重写的向量化执行引擎替换 JVM 上的 Spark 执行层，SQL/DataFrame workload 快 3-8 倍——且因为跑得快，总账单反而下降。
窄场景
已有 Spark/Delta Lake 资产、不想重写 pipeline 但要降本提速的团队；Databricks SQL Warehouse 上的 BI/ETL（Photon 默认开启）。边界：UDF-heavy 的 Python workload 收益小（社区实测结论）。
机制
经典 Spark 跑在 JVM 上，行式处理 + 虚函数调用 + GC 开销；Photon 是从零写的 C++ 向量化引擎，直接操作列式批量数据、SIMD 指令，绕过 JVM。关键洞见是计费悖论：Photon 的 DBU 单价贵约 2 倍，但查询快 3-8 倍，总 DBU-hours 下降——"为性能付费结果省了钱"的反直觉案例。
生产验证
独立实测（Reliable Data Engineering，2026-01）：500M 行复杂聚合不用 Photon 4 分 23 秒 / $0.87，用 Photon 1 分 48 秒 / $0.65——快 59%，便宜 25%（https://medium.com/@reliabledataengineering/15-databricks-features-youre-paying-for-but-not-using-09b12d7dea45）；社区 FinOps 实践已是生产调优 checklist 标准条目："Turn on Photon for SQL and DataFrame-heavy ETL. It usually pays for its DBU premium in reduced runtime."（https://github.com/surfalytics/rockyourdata/blob/HEAD/src/content/blog/databricks-lakehouse-architecture.md）；Intel 白皮书 TPC-DS 快 65%/省 35% 为厂商口径，仅作对照（https://cdrdv2-public.intel.com/755539/Photon-Databricks-on-Azure-Edsv4.pdf）。
竞品差距
Spark 原生/EMR 无等价物（开源 Comet、Gluten+Velox 在追赶，但成熟度/集成度不及）；Snowflake/BigQuery 各有自己的向量化引擎，但那是"买数仓送引擎"，Photon 是 Spark 生态的加速器——存量 Spark 代码不用改；StarRocks/Doris 本身就是 C++ 向量化 MPP 但它们不是 Spark。31 款中"让存量 Spark workload 不动代码变快 3-8 倍"的方案没有第二家。
证据等级
社区共识 + 独立实测；Intel 白皮书数字为厂商口径，已标注
最后核验
2026-10-01

生态 Unity Catalog 统一治理

一句话
catalog.schema.table 三级命名空间 + 自动列级血缘 + 行过滤/列掩码，在 SQL warehouse、notebook、jobs 全链路一致执行——一套治理管住湖仓所有资产。
窄场景
受监管行业（金融/医疗/GDPR）要回答"这列 PII 被谁查过""改这列会炸掉什么"；多工作区、多团队共享同一份 S3/ADLS 数据湖但权限要隔离（prod vs dev 同代码不同 catalog）。
机制
传统 Hive metastore 只有库表两级、权限靠各引擎自己实现；Unity Catalog 把元数据、权限、血缘、审计收敛到一个控制平面：三级命名空间天然隔离环境（prod.sales.orders vs dev.sales.orders 同代码）；列级血缘自动采集（notebook→job→dashboard 全链路），这是"改列不炸"的答案；行过滤/列掩码在存储层之下统一执行，换引擎也绕不过。
生产验证
社区生产实践（surfalytics，2026）："migrating to Unity Catalog is the highest-value structural change available… Lineage, automatically. Column-level lineage across notebooks, jobs, and dashboards."（https://github.com/surfalytics/rockyourdata/blob/HEAD/src/content/blog/databricks-lakehouse-architecture.md）；选型 ADR（2026-09）："Governance settles it… On EMR I'd rebuild all of that from Lake Formation and Glue and custom code"——工程师宁愿付 DBU markup 也要买治理（https://github.com/aramisn/aws-databricks-lakehouse/blob/HEAD/docs/adr/0002-databricks-over-emr.md）。诚实备注：大规模跨国企业的独立第三方复现较少，多为实践指南与决策记录。
竞品差距
Snowflake RBAC 成熟但只管 Snowflake 内部；BigQuery IAM + policy tags 无跨引擎血缘；开源 OpenMetadata/DataHub 能做目录，但"权限执行"是护城河。"一个治理平面横跨 SQL+Python+ML+外部表"是 Databricks 独有的。
证据等级
社区共识 + 生产实践记录
最后核验
2026-10-01

生态 SQL+ML 同一数据底座

一句话
ETL、BI、notebook、模型训练、推理服务跑在同一份 Delta Lake 数据上，省掉"Snowflake+SageMaker"式跨平台搬数与双份治理——一份数据、一个权限模型、一张账单。
窄场景
ML 重度团队（特征工程、训练、推理用的就是 BI 查的那份数据）；SQL 分析师 + Python 数据科学家混编、不想维护两套平台的团队；湖仓与 AI 路线图绑定的公司；想把 ML 从 SageMaker/Vertex 搬回数据平台的团队。
机制
Snowflake 方案里 ML 要外挂（Snowpark/Cortex 在补，但训练仍多走 SageMaker/Vertex）；Databricks 里 notebook、SQL warehouse、MLflow、Model Serving 读的是同一份 S3 上的 Delta 文件，无 ETL、无数据复制、无跨平台权限重配——"SQL 和 ML 原生同构"。
生产验证
LeanOps 独立建模（2026）：Workload C（500TB Delta + 60% ML）Databricks $33K/月 vs Snowflake+SageMaker $43.5K/月，"often worth the 27% premium for ML-heavy teams"——贵的 27% 买的是运维统一性（one platform, one access model, one bill）（https://leanopstech.com/blog/snowflake-vs-bigquery-vs-databricks-vs-redshift-cost-2026/）；社区选型共识已成黑话级决策口诀："Databricks if ML and a unified lakehouse are on your two-year plan; Snowflake if you're SQL-first with no near-term ML"（cosmosthrace 2026 EMEA 指南，https://cosmosthrace.com/resources/databricks/databricks-vs-snowflake）。
竞品差距
Snowflake（Snowpark 在追，但生态成熟度差一代）、BigQuery+Vertex AI（能打，但跨两个产品面）。31 款中"SQL 和 ML 原生同构"的只有 Databricks。
证据等级
独立实测（LeanOps 建模）+ 社区共识（已成行业黑话级决策口诀）
最后核验
2026-10-01

避坑 "旋钮地狱"：自由度的代价是工程师小时

一句话
Databricks 把分布式系统的每一颗旋钮都暴露给你，代价是：配错一个参数就烧钱，而 Snowflake 用户根本见不到这些旋钮。
窄场景
谁最容易中招——从 Snowflake/BigQuery 切过来的 SQL-first 团队，低估了 Spark 运维；没人专职管集群的中小团队。
机制
一个 job cluster 的配置 JSON 里有十几个决策点（runtime 版本、node type、driver 规格、autoscale 上下界、spot 策略、shuffle partitions……），每个都直接影响账单；对照 Snowflake 的等价物只有三行（warehouse size、auto-suspend、cluster count）。社区一针见血："Databricks gives you control you may not need and charges you in engineer-hours to exercise it."
生产验证
社区对比长文完整列出 job cluster JSON vs Snowflake 三行 SQL 的对照，"the maintenance surface is the real difference"（https://github.com/noah-goodrich/claude-plugins/blob/HEAD/evals/corpus/negative-generic/anthropic-claude-opus-5-snowflake-vs-databricks.md）；生产事故模式（surfalytics）：定时任务跑在交互式 all-purpose 集群上，DBU 双倍燃烧，"This is the most expensive mistake we find, and it is a one-line fix."（链接见上）；迁移成本真相（improvado，2026）：Snowflake→Databricks 需 8-12 工程周、40-60% 查询要重写、SQL 分析师需 60-80 小时学习曲线（https://improvado.io/blog/snowflake-competitors-and-alternatives）。
竞品差距
这是招牌 1-3 的镜像代价。Snowflake/BigQuery 用户付的是"算力税"，Databricks 用户付的是"工程师小时税"。选型时必须同时称这两边。
证据等级
社区共识
最后核验
2026-10-01

用户最买账的 5 点

  1. 一套平台覆盖工程、BI、ML、AI 为什么是真的：同一份 Delta 数据，数据工程师跑 ETL、分析师跑 SQL、算法跑训练、Agent 跑 RAG，不用来回倒数据；Unity Catalog 一套权限管全。 边缘与失效条件：统一的前提是团队愿意统一——"各部门各买各的云服务"的组织拿不到协同红利；平台越全，单点议价能力越弱。 来源：官方文档 + 社区共识。观察版本：平台滚动发布（2026-09）。
  2. Delta Lake 开放格式，数据不被锁定 为什么是真的：Parquet + 事务日志，换 Trino/Snowflake（Iceberg 互操作）可读；相对 Snowflake 私有存储格式，退出成本低一个量级。 边缘与失效条件：开放的是数据，不是作业、权限与调度逻辑；迁移的真实成本在重写管道与重建治理，不在数据本身。 来源：官方文档 + 社区共识。观察版本：Delta Lake（Linux 基金会）。
  3. Photon + Serverless：BI 查询开箱即快 为什么是真的：SQL 仓库 + Photon，TB 级聚合秒级返回很常见；Serverless 免去"半夜集群挂了"的运维。 边缘与失效条件：快的是"典型 BI 查询"；超大 join、倾斜数据、UDF 重逻辑仍要调优；Serverless 单价贵，7×24 重载不如经典划算。 来源：官方口径 + 社区实测。观察版本：平台滚动发布（2026-09）。
  4. 流批一体，CDC 链路短 为什么是真的：Structured Streaming + DLT + CDF，从 Kafka 到 gold 表一条链路，exactly-once；Lakebase Sync 把 OLTP 变更原生流进湖。 边缘与失效条件：流作业的运维（checkpoint、水位线）仍是深水区；CDC 延迟是秒到分钟级，不是毫秒级。 来源：官方文档 + 社区实践。观察版本：平台滚动发布（2026-09）。
  5. MLOps 到 Agent 的完整 AI 链路 为什么是真的：MLflow 跟踪/注册/ serving、Vector Search、Agent Bricks 评测部署，都在同一治理下；做 RAG/Agent 不用另搭一套。 边缘与失效条件：AI 功能的计费（token + DBU）要单独建模；模型质量最终取决于数据质量，平台不替你洗数据。 来源：官方文档 + 社区共识。观察版本：平台滚动发布（2026-09）。

吐槽清单

分类吐槽影响版本状态
成本DBU + 云资源双账单，费用不可预测；闲置集群、过宽扩缩是最常见的烧钱姿势全版本open
成本月度账单只给总数，不做标签 + system.billing 分析就无法归因到团队/作业全版本open
成本Serverless 单价高于经典，"省心不省钱"，7×24 重载总账可能更贵全版本open
运维经典集群冷启动慢，交互式体验不如纯 Serverless 数仓全版本partially-fixed
学习Spark 调优（倾斜、shuffle、分区）负担仍在用户侧，小团队无专人则优势打折全版本open
治理老工作区 Hive Metastore 迁 Unity Catalog 是项目制工作，官方 UCX 工具也非一键迁移期partially-fixed
存储高频写入小文件海 + Delta 日志膨胀，OPTIMIZE/VACUUM 是必修运维全版本open
网络跨区/跨云 egress 费用不在 DBU 内，多 Region 架构下可能成最大单项全版本open
锁定数据格式开放，但作业调度、权限体系、计费深度绑定平台，迁移真实成本在管道与治理全版本open
合规部分 AI 功能（按 token 计费模型 API）在非 HIPAA 合规档下受限全版本open
部署无私有化/本地部署选项，强监管本地化场景只能走混合架构全版本open

判决

适合谁：云原生的数据平台团队——需要一套覆盖 ETL、BI、ML 乃至 AI Agent 的统一底座；数据量 TB~PB 级且持续增长；团队有 Spark/SQL 能力并愿意建 FinOps；看重开放表格式、不想被私有存储格式锁定。

不适合谁：只要"跑 SQL 查数"的轻量 BI 团队（Serverless 数仓可能更简单便宜）；毫秒级 OLTP 点查；强监管要求本地化部署；无专人看账单与调优、指望"开了就行"的团队；预算刚性、对可预测性要求高于弹性的组织。

迁移成本：中等。从 Hadoop/Spark 自建迁来平滑（API 兼容）；从传统数仓迁来，成本在三处：(1) 管道重写为 DLT/Structured Streaming 范式；(2) 治理重建——Unity Catalog 权限与血缘；(3) FinOps 体系——标签、预算、auto-termination。真正的长期成本不在迁移，在持续的 DBU 治理。

来源与待验证清单

  • 官方文档：Databricks 文档（Unity Catalog、Delta Lake、DBSQL、DLT/Lakeflow、计费与 system 表、安全与合规）。
  • 第三方分析：G2 Azure Databricks 评价（2026）、iomete Fortune 500 成本拆解、Fabric 对比教程（DBU 模型描述）。
  • 媒体：TechFundingNews（估值与 ARR）、Wikipedia（公司历史）、GeekWire（Row Zero 收购）。
  • 本轮明确未覆盖：各云具体 DBU 目录价（易变，未引用绝对价格）、Lakehouse//RT 正式 GA 状态——标待验证，未写入结论。
  • v1.0（2026-09-29）：首版建档。last_reviewed: 2026-09-29，评审对象为 Databricks 平台滚动发布版本（Runtime 16.x 一代）。