趋近智
趋近智
软件工程团队长期以来一直使用应用性能监控（APM）来监控系统正常运行时间与延迟。然而，数据工程却带来不同的难题：系统可能运行良好，服务器在线，有向无环图（DAG）显示正常，任务顺利完成，但数据本身却可能是无效的。任务的成功执行不保证数据准确。
数据可观测性弥补了这一不足。它将DevOps可观测性的原则应用于数据管道，使得工程师能够根据外部信号推断数据的内部质量。与在部署前确认已知条件的单元测试不同，可观测性发现生产中的未知问题。它依靠三种基本的信号类型：指标、日志和追踪（在数据背景下通常表现为血缘关系）。
为构建一个监控系统，我们必须从数据基础设施中获取特定信号。这些信号使我们能够回答三个不同的问题：“是否存在问题？”、“问题出在哪里？”以及“为什么会发生？”。
指标是在特定时间间隔内测量的数据的数值表示。在数据背景下，这些是追踪信息形态和流动的时间序列值。它们存储高效，易于查询以用于告警。常见的数据指标包括：
日志是不可变的、带有时间戳的离散事件记录。指标告诉你趋势正在改变，而日志提供调试该事件所需的详细信息。当转换失败时，日志包含异常堆栈追踪或数据仓库返回的特定SQL错误代码。
在微服务中，追踪负责请求在服务间的跳转过程。在数据工程中，这个想法对应于数据血缘。血缘描绘了上游源、转换任务和下游表之间的关系。它提供理解事件影响范围所需的背景信息。
下图说明了这些信号如何汇集，在物理基础设施之上形成一个可观测层。
信号从物理基础设施流入可观测性平台进行分析。
主动告警的主要方式是对收集的指标进行异常检测。我们通常关注三个特定方面：新鲜度、数量和模式。
新鲜度测量自数据集上次更新以来经过的时间。它有效地追踪管道的延迟。如果一个通常在协调世界时08:00运行的任务在09:30完成，那么数据就“过时”了90分钟。
新鲜度检查具有很高的意义，因为它们发现静默故障。一个计划好的有向无环图（DAG）可能仅仅因为调度器故障而未能触发。在这种情况下，因为没有代码运行，所以没有生成错误日志。只有观察目标表的新鲜度监控器才能发现这种静默情况。
数量指正在处理的数据的大小，通常以行数或字节数衡量。数据量突然下降通常表示上游数据丢失或API故障，而突然的飙升可能表示重复数据摄取。
因为数据量自然波动（例如，周末流量较低），静态阈值常常产生误报。因此，我们使用统计基线。通过计算Z分数，我们可以确定当前数量 相对于标准差 偏离移动平均值 的程度：
当 时触发告警，其中 是一个灵敏度阈值（通常为2或3）。
下图显示了一个数量异常，其中行数显著低于预期的历史范围。
10月5日，实际值与历史基线显著偏离，触发了异常告警。
模式漂移发生在数据结构改变时。这包括列的添加、移除或重命名，以及数据类型改变（例如，整数字段变为字符串）。
尽管模式演进在敏捷开发中是很常见的，但未管理的模式改变是导致管道中断的主要原因。可观测性系统监控数据仓库的信息模式或数据湖中JSON数据块的结构。当检测到改变时，系统会将新模式与已知注册表或先前状态进行比较，以判断该改变是否会造成破坏性影响。
指标告诉你有什么问题，但血缘告诉你哪里出问题了，以及谁受到影响。
血缘通过解析查询日志或与Airflow等编排工具集成来构建。它为你的数据资产构建一个有向无环图（DAG）。当仪表板上触发新鲜度告警时，血缘允许你向后遍历图（上游）以找到根本原因。反之，如果源表损坏，血缘允许你向前遍历（下游）以通知相关方。
有效的可观测性需要结合这些支柱。指标告警触发事件。血缘隔离出损坏的组件。日志显示错误信息。这种工作流程缩短了平均解决时间（MTTR），并将数据治理从手动监督任务转变为自动化工程规范。
这部分内容有帮助吗？
© 2026 ApX Machine Learning用心打造