1. Databricks平台架构总览

Databricks 的核心定位，是把数据工程、数据分析与机器学习统一到同一套湖仓（Lakehouse）底座上。理解它的架构，关键不是记住产品清单，而是看清三条主线：数据如何以开放格式沉淀在对象存储中，控制平面与数据平面如何分工，以及计算资源如何按负载类型被拆分和调度。这三条主线共同决定了大规模 AI 数据处理时的性能、成本与治理边界。

Lakehouse：在对象存储上叠加事务与元数据

传统数据仓库把存储与计算耦合在一起，数据以私有格式存放，扩展成本高；数据湖虽然便宜开放，却缺少事务、Schema 约束和高效索引。Lakehouse 的思路是：底层仍然使用云对象存储（如 S3、ADLS、GCS）保存 Parquet 等开放格式文件，在其上通过 Delta Lake 增加事务日志（_delta_log）、ACID 语义、时间旅行与 Schema 演进能力。表不再是“一堆文件”，而是“文件 + 事务日志 + 元数据”的组合。

Delta 表的一次写入会先生成新的 Parquet 数据文件，再向 _delta_log 追加一条 JSON 提交记录，记录新增/删除的文件、统计信息与操作类型。读取时引擎先读日志确定当前快照涉及哪些文件，再只扫描必要文件。这个“日志先行”的机制，是并发写入、回滚与增量读取的基础。对 AI 场景而言，它意味着特征表、训练样本表、向量索引底表可以共享同一份存储，同时被不同计算引擎读取。

控制平面与数据平面

Databricks 采用控制平面与数据平面分离的架构。控制平面由 Databricks 托管，负责 Notebook、作业调度、集群管理、Unity Catalog 元数据、Web 终端与 API；数据平面运行在客户云账号内，负责实际的计算与数据读写。这种分离带来两个直接结果：数据始终留在客户自己的存储账户中，控制平面只保存元数据与配置；计算资源可以在客户 VPC/VNet 内创建，网络出口与合规边界更清晰。

需要区分的是“经典数据平面”与“Serverless 数据平面”。经典模式下，集群虚拟机运行在客户云账号，客户可见并可配置网络；Serverless 模式下，计算由 Databricks 账号托管，启动更快、运维更少，但网络与存储访问需通过服务端配置的私有连接或凭据打通。选择哪种，取决于合规要求、启动时延敏感度和运维投入。

计算资源类型与选择逻辑

Databricks 的计算资源按使用模式分为几类，选择时主要看“谁在用、用多久、要不要 GPU”。通用计算集群（All-Purpose）面向交互式开发，多人共享，常开或自动停止，适合 Notebook 探索与调试；作业集群（Job Cluster）由作业触发创建、结束即销毁，隔离性好、成本可控，适合生产 ETL；SQL 仓库面向 BI 与即席查询，支持 Serverless 快速启动；GPU 集群用于模型训练、微调和批量推理，需要关注 GPU 型号、显存与节点间通信。

对大规模 AI 数据处理，一个常见误区是用通用集群跑所有任务。更合理的做法是：数据清洗与特征工程用作业集群或 Serverless，训练用 GPU 集群，推理用可弹性伸缩的 GPU 或 Serverless 推理端点。集群配置中，Worker 数量、实例类型、自动伸缩上下限、Spark 配置（如 shuffle 分区数）都会直接影响作业时长与费用。

Unity Catalog：统一元数据与权限

Unity Catalog 是跨工作区的统一治理层，采用三级命名空间 catalog.schema.table。它管理表、视图、Volume（非结构化文件）、函数、模型等对象，并统一控制权限。权限模型上，账户级有 Metastore，下面挂 Catalog、Schema、Table，权限可继承也可显式授予。对 AI 场景，Volume 让图像、音频、文本等原始文件也能被目录化管理，模型则通过 MLflow 注册到 Unity Catalog，实现版本与权限的统一。

一个典型授权示例：

GRANT USE CATALOG ON CATALOG ai_lake TO `data_team`;
GRANT USE SCHEMA ON SCHEMA ai_lake.features TO `data_team`;
GRANT SELECT ON TABLE ai_lake.features.user_embedding TO `data_team`;
GRANT READ VOLUME ON VOLUME ai_lake.raw.images TO `data_team`;

这样，数据团队只能看到被授权的对象，且所有访问都经过统一审计。血缘信息也会自动记录，便于追踪特征从哪张原始表来、被哪些模型消费。

大规模 AI 数据处理的工程挑战与设计原则

把上述架构放到 AI 场景，会暴露几个典型挑战。第一，数据规模与格式异构：训练数据可能是 TB 级 Parquet，也可能是百万级小图像文件，小文件会拖垮读取性能，需要合并或使用 Volume + 并行读取。第二，特征一致性：训练与推理必须使用同一套特征计算逻辑，否则会出现训练-服务偏差，实践中常把特征写入 Delta 表并统一由特征工程管道产出。第三，GPU 利用率：训练任务常受 I/O 与数据加载瓶颈限制，需要合理设置并行度、预取与缓存。第四，成本与治理：计算资源按需启停、权限最小化、元数据统一，是长期可运维的前提。