1. 可观测性工程与Databricks平台

在传统数据平台里，运维团队习惯用“监控”来回答一个问题：系统现在是不是活着？CPU 有没有超过 80%，作业有没有失败，集群有没有掉线。但在 Lakehouse 架构下，数据工程、数据科学和平台运维三类角色共享同一套存储、计算与调度资源，仅靠“活着/死了”的二元判断远远不够。可观测性工程要回答的是更接近根因的问题：为什么这张 Delta 表的写入延迟突然升高？为什么同一段 Notebook 在交互式集群上正常、在作业集群上却超时？为什么某个特征表的行数在凌晨 3 点出现断崖式下跌？

可观测性（Observability）源自控制论，指通过系统对外输出的信号推断其内部状态的能力。工程落地时，它被拆成三大支柱：指标（Metrics）、日志（Logs）、追踪（Traces）。三者不是三套独立工具，而是同一份“系统行为”在三个维度上的投影：指标是随时间聚合的数值，日志是离散的事件记录，追踪是带因果关系的调用链。理解它们在 Databricks Lakehouse 中的定位，是后续所有排障与容量规划工作的起点。

三大支柱在 Lakehouse 中的落点

Databricks 的 Lakehouse 由控制面（Control Plane）与数据面（Data Plane）组成。控制面负责作业调度、Notebook 管理、集群生命周期；数据面运行在客户云账号内，承载 Spark 计算、Delta 存储与 Photon 引擎。可观测性信号正是沿着这条边界分布的。

指标主要来自四个层面：集群层（CPU、内存、磁盘 I/O、网络吞吐）、Spark 层（任务数、Shuffle 读写、GC 时间、Executor 活跃数）、Delta 层（文件数、小文件比例、OPTIMIZE 耗时、版本数）以及作业层（运行时长、重试次数、排队时间）。这些指标大多可通过 Ganglia、Spark UI、Delta 事务日志和 Jobs API 采集，适合做趋势判断和阈值告警。

日志分为驱动日志、Executor 日志、集群事件日志和审计日志。驱动日志记录作业启动、异常堆栈与 SQL 执行计划；Executor 日志暴露 OOM、磁盘溢出与序列化失败；审计日志则回答“谁在什么时候对哪张表做了什么”。日志的价值在于提供上下文，但体量大、非结构化，需要配合检索与解析。

追踪在 Databricks 中相对年轻，但增长最快。一次端到端的数据管道可能跨越 Notebook、Delta Live Tables、Workflows 和外部 API。通过 OpenTelemetry 或 Spark 的查询执行监听器，可以把一次写入拆成“读取源表 → 转换 → 写入目标表 → 提交事务”的 span，从而定位是哪个阶段拖慢了整体。

可观测性与监控的本质区别

监控是“已知问题的已知答案”：提前定义好阈值，超过就告警。可观测性是“未知问题的可探索空间”：当出现从未见过的故障时，仍能通过信号组合推断原因。两者的差异体现在三个维度上。

第一，问题预设不同。监控假设故障模式可枚举，因此适合 CPU 超限、作业失败这类明确场景；可观测性假设故障模式不可完全枚举，因此强调高基数（high cardinality）与高维度数据，例如按 cluster_id、job_id、table_name、user 多维下钻。

第二，数据保留策略不同。监控指标通常做降采样，保留 15 个月但精度降低；可观测性要求原始事件可回溯，日志与追踪往往保留 7～30 天全量，以便复现一次具体的慢查询。

第三，组织协作方式不同。监控由运维团队集中负责；可观测性要求数据工程师在管道中埋点、数据科学家在 Notebook 中标注实验版本、平台运维统一采集，是一种跨角色的工程实践。

对三类角色的实际价值

对数据工程师而言，可观测性直接决定管道能否稳定交付。以一张每日增量写入的 Delta 表为例，工程师需要关注：上游源表行数是否异常波动、写入任务的 Shuffle 量是否突增、小文件数量是否超过阈值导致读取变慢。当发现某天写入耗时从 8 分钟涨到 40 分钟时，通过追踪可以定位到是某个 join 阶段发生了数据倾斜，而非盲目扩容集群。

对数据科学家而言，可观测性保障实验可复现。特征工程往往依赖多张上游表，如果上游表在实验期间被回滚或覆盖，模型结果就失去意义。通过 Delta 事务日志与版本追踪，可以记录“本次训练使用的是 feature_store 的 version 42”，并在结果异常时回溯到具体数据版本。

对平台运维而言，可观测性是容量规划与成本控制的依据。集群自动伸缩策略是否合理、哪些作业长期占用高配集群却只做轻量转换、哪些表长期无人访问却占用大量存储，这些问题的答案都藏在指标与审计日志的交叉分析中。

一个可落地的起步清单

可观测性建设不必一步到位。以下清单可作为第一个迭代周期的参考，字段与阈值需根据实际业务量调整。

起步阶段建议先打通“指标 + 日志”两条链路：用 Ganglia 或 Prometheus 采集集群指标，用 Jobs API 拉取作业运行记录，用审计日志表做访问分析。当出现一次真实故障并成功定位后，再引入追踪，把最关键的 2～3 条管道加上 Span。这样每一步都有明确的收益验证，避免一次性铺开却无人使用的局面。

回到本节的核心：可观测性工程不是监控的升级版，而是面向 Lakehouse 复杂性的新工作方式。指标回答“发生了什么”，日志回答“为什么发生”，追踪回答“在哪一步发生”。三者结合，才能让数据工程、数据科学和平台运维在同一套信号体系下协作，把“感觉不对劲”变成“可以定位并修复”。