1. Databricks数据智能平台全景
在开始编写第一条批处理或流处理管道之前，需要先建立一张"平台地图"：Databricks 不是一个单一工具，而是由存储格式、元数据治理、计算引擎、编排调度四层能力叠加而成的数据智能平台。理解每一层在批流管道中扮演什么角色、彼此如何衔接，比记住产品名称更重要。本节围绕 Lakehouse 架构、Delta Lake、Unity Catalog、Workflows 与计算资源五个核心对象，说明它们各自解决什么问题、在管道中处于什么位置。
Lakehouse：把数据湖的弹性与数仓的可靠性合并
传统架构中，数据湖负责存放原始文件，数据仓库负责结构化查询与事务保证，两者之间靠 ETL 反复搬运，导致数据冗余、口径不一致、时效性差。Lakehouse 的思路是：直接在云对象存储（如 S3、ADLS、GCS）之上叠加一层具备事务、Schema 约束和索引能力的表格式，让同一份数据既能被 Spark 大规模处理，也能被 SQL 引擎高效查询，还能支撑机器学习的特征读取。
在批流管道中，Lakehouse 提供的是"统一落点"：批处理写入的历史分区表、流处理持续追加的增量表，可以放在同一套目录结构下，由同一套权限和血缘管理。这样，离线补数与实时增量不再需要两套存储，下游消费方也无需区分数据来自哪条链路。
Delta Lake：批流管道的存储底座
Delta Lake 是 Lakehouse 的默认表格式，它在 Parquet 文件之上维护一份事务日志（_delta_log），记录每次写入新增或删除了哪些文件、Schema 如何演变、有哪些提交。正是这份日志，让批流管道获得了几个关键能力：
- ACID 事务：多个写入者并发操作同一张表时，不会读到写了一半的中间状态，流式追加与批式覆盖可以安全共存。
- Schema 演进与约束：新增列可以自动合并，也可以显式拒绝不符合预期结构的写入，避免脏数据污染下游。
- 时间旅行：通过版本号或时间戳读取历史快照，便于回溯问题批次、复现某次计算。
- 流批统一读写：同一张 Delta 表既可作为流式 Source（增量读取），也可作为批式 Source（全量读取），还能作为流式 Sink 持续接收追加。
因此，在管道设计中，Delta 表通常承担"中间层"和"结果层"的双重角色：原始接入层可以用 Delta 保存落地数据，清洗后的明细层、聚合后的指标层同样用 Delta 存储，形成可追溯的分层结构。
Unity Catalog：跨工作区的统一治理层
当管道数量增多、参与人员变多时，最大的风险不是算不出来，而是"不知道数据在哪、谁能看、从哪来"。Unity Catalog 提供的是三层命名空间（Catalog → Schema → Table/View/Volume）以及围绕它的权限、血缘和审计。
对批流管道而言，Unity Catalog 的实际价值体现在三点：第一，管道读写表时使用统一的三段式名称，例如 prod_lakehouse.silver.orders_clean，避免硬编码路径；第二，表和列的访问权限集中授予，流式作业与批式作业遵循同一套授权规则；第三，表级和列级血缘自动记录，当某个上游表结构变更时，可以快速定位受影响的下游任务。这意味着管道的"可维护性"很大程度依赖治理层是否规范。
Workflows：把任务串成可调度、可重试的作业
有了存储和治理，还需要一个编排层决定"什么时候跑、按什么顺序跑、失败了怎么办"。Databricks Workflows 用 Job 和 Task 两级结构描述管道：一个 Job 代表一条完整管道，内部由多个 Task 组成，Task 之间可以设置依赖关系，形成 DAG。
典型批处理管道的 Task 编排如下：先运行一个 Notebook 或 SQL 任务完成原始数据接入，再触发清洗任务，随后并行执行多个聚合任务，最后运行数据质量校验任务。每个 Task 可以配置重试次数、超时时间、通知方式；整个 Job 可以按时间触发（如每天凌晨 2 点），也可以由文件到达事件触发。流处理作业则通常以"常驻任务"形式提交，由 Job 集群持续运行，配合自动重启策略应对节点故障。
计算资源：按负载形态选择集群
Databricks 的计算资源主要分为交互式集群、Job 集群和 SQL 仓库。批处理任务一般使用 Job 集群，任务开始前自动创建、结束后自动释放，成本可控；流处理任务需要长期运行，通常使用常驻 Job 集群并开启自动扩缩容；交互式分析和调试则使用交互式集群或 SQL 仓库。
选择计算资源时，需要关注三个参数：Worker 类型（计算密集型还是内存密集型）、最小/最大 Worker 数（决定扩缩容范围）、以及运行时的 Photon 引擎是否开启（对 SQL 和 DataFrame 操作有明显加速）。这些参数直接影响管道的吞吐和成本，是后续调优的主要抓手。
五层对象如何协同：一条管道的完整视角
把上述对象串起来看，一条典型的批流一体管道大致是这样运转的：事件源或文件到达后，由 Workflows 触发 Job，Job 在指定的计算资源上启动 Task；Task 读取 Unity Catalog 中登记的表，经过转换后写回 Delta 表；Delta 的事务日志保证写入的原子性，Unity Catalog 记录本次读写了哪些表、谁执行的；下游的批处理任务或流处理任务再以同样的方式消费这些 Delta 表。
这里有一个容易被忽略的细节：批处理和流处理并不是两条完全独立的链路。流处理写入的 Delta 表，可以被批处理任务按分区全量读取；批处理产出的维表，也可以被流处理任务以批流 join 的方式加载。真正让两者统一起来的，是 Delta 表这个共同落点，以及 Unity Catalog 这套共同命名和权限体系。