2. Databricks AI平台架构速览

要理解 Databricks AI 平台上的可观测性与质量治理，不能只盯着某一个监控面板或某一张指标表，而要先看清平台各组件在“数据—特征—模型—服务—反馈”这条链路上分别承担什么职责。可观测性本质上是对这条链路的每个环节建立“可测量、可追溯、可告警”的能力；质量治理则是对每个环节定义“合格标准”，并让标准可执行、可验证。本节先建立整体架构认知，明确 Lakehouse、Unity Catalog、MLflow、Model Serving、Feature Store、Workflows 等组件在其中的位置与作用。

一、从数据到服务的分层结构

Databricks AI 平台可以按数据流方向理解为若干层次。最底层是 Lakehouse，它用 Delta Lake 表统一承载原始数据、清洗后数据、特征表和推理日志。Delta 的事务日志（_delta_log）天然提供了版本、时间旅行和变更数据捕获能力，这是可观测性的第一手素材：数据新鲜度、行数变化、schema 漂移都可以从表的历史版本中计算出来。

其上是 Feature Store，它把离线特征表与在线特征表关联起来，保证训练与推理使用同一套特征定义。Feature Store 的关键治理点是特征血缘和特征一致性：某个特征由哪张源表、哪段代码生成，训练时和线上服务时取值是否一致。特征漂移监控通常就落在这一层。

MLflow 负责实验追踪与模型注册。每次训练运行的参数、指标、产物、代码版本都记录在 MLflow Tracking 中，模型进入 Model Registry 后带有版本、阶段（Staging/Production）和审批记录。可观测性在这里体现为“模型可追溯”：线上出问题时，能反查到具体是哪个 run、哪份数据、哪组超参产出的模型。

Model Serving 是模型对外提供推理的端点，它暴露延迟、吞吐、错误率、请求/响应样本等运行时指标。它是可观测性最直接的前线，也是质量治理中“服务级 SLO”的落点。

Unity Catalog 横跨以上各层，统一管理数据、模型、函数、特征表的权限、血缘和审计日志。它不直接产生业务指标，但它是“谁在什么时候访问了什么”的治理底座，是合规与安全可观测性的来源。

Workflows（含 Jobs 与 Delta Live Tables 管道）负责调度数据加工、特征刷新、模型训练和批推理。它的运行历史、任务耗时、失败重试是链路健康度的脉搏。

二、各组件在可观测性中的具体落点

把架构图落到可观测性上，每个组件都有明确的“观测对象”和“治理动作”。Lakehouse 层关注数据质量指标：表的新鲜度（最近一次写入距今多久）、行数波动（与过去 7 天均值比较）、空值率、schema 是否发生不兼容变更。这些指标可以从 Delta 表的历史版本和 DESCRIBE HISTORY 中提取，配合 Workflows 定时计算。

Feature Store 层关注特征一致性。一个典型检查是：对同一实体主键，离线特征表在某个时间点的取值，与在线特征服务返回的值是否一致。若不一致，说明特征刷新链路或时间窗口定义有问题。特征漂移则通过比较训练集特征分布与近期线上特征分布（如 PSI、KL 散度）来判断。

MLflow 层关注模型可追溯性。每个生产模型版本应关联到具体的 run_id、训练数据版本、代码 commit 和评估指标。当线上指标下降时，可以快速定位是数据问题、特征问题还是模型本身退化。

Model Serving 层关注服务级指标：P50/P95/P99 延迟、QPS、5xx 错误率、超时率。这些指标通常接入 Prometheus 或 Databricks 自带的 Serving 指标端点。质量治理上，需要为每个端点定义 SLO，例如 P95 延迟小于 300ms、错误率低于 0.5%。

Workflows 层关注任务健康度：任务成功率、平均耗时、重试次数、上游依赖是否就绪。它是链路可观测性的“心跳”，一旦特征刷新任务失败，下游模型服务可能仍在用旧特征，这种隐性故障必须靠任务告警来暴露。

三、质量治理的协同关系

这些组件不是孤立的。Unity Catalog 提供统一血缘，让“某张源表变更影响了哪些特征、哪些模型、哪些服务”可以一键追溯。Workflows 负责按节奏执行质量检查任务，把检查结果写入监控表。Model Serving 的推理日志回流到 Lakehouse 后，又成为下一轮漂移检测和模型再训练的输入。这样就形成了一个闭环：数据质量影响特征质量，特征质量影响模型效果，模型效果通过服务指标和推理日志被观测，观测结果再驱动数据与特征的修复。

四、一个可执行的质量检查示例

下面给出一个在 Workflows 中定时运行的数据质量检查片段，用于检测核心特征表的新鲜度和空值率。示例参数为合理假设，实际阈值需根据业务节奏调整。

from pyspark.sql import functions as F
from datetime import datetime, timedelta

# 假设特征表为 ml.features.user_activity，主键 user_id
feat = spark.table("ml.features.user_activity")

# 1. 新鲜度检查：最近分区日期距今不超过 1 天
latest = feat.agg(F.max("event_date")).collect()[0][0]
freshness_hours = (datetime.now() - datetime.combine(latest, datetime.min.time())).total_seconds() / 3600
assert freshness_hours < 24, f"特征表过期: {freshness_hours:.1f} 小时"

# 2. 空值率检查：关键特征 null 比例低于 5%
total = feat.count()
null_rate = feat.filter(F.col("activity_score").isNull()).count() / total
assert null_rate < 0.05, f"activity_score 空值率过高: {null_rate:.2%}"

# 3. 行数波动检查：与 7 天均值偏差不超过 30%
today_cnt = feat.filter(F.col("event_date") == latest).count()
avg_cnt = feat.filter(F.col("event_date") >= latest - timedelta(days=7)) \
              .groupBy("event_date").count().agg(F.avg("count")).collect()[0][0]
deviation = abs(today_cnt - avg_cnt) / avg_cnt
assert deviation < 0.3, f"行数波动异常: {deviation:.2%}"

这段检查若失败，Workflows 会标记任务失败并触发告警；检查结果同时写入 monitor.data_quality_log 表，供后续趋势分析。判断依据很直接：新鲜度超过 24 小时说明上游写入中断；空值率超过 5% 说明采集或加工逻辑异常；行数偏差超过 30% 说明数据量突变，可能是重复写入或漏写。三者结合，就能在模型效果下降之前先发现数据侧的问题。

五、组件角色小结