1、数据可观测性概述

大家好，我是老张。今天咱们聊聊数据可观测性。说实话，这个词在圈子里火了好几年了，但很多人还是搞不清它到底是个啥。

我记得2019年刚接触这个概念时，也觉得它就是监控的另一个说法。后来踩了不少坑，才真正理解——数据可观测性不是监控的升级版，而是一套全新的数据治理思维。

什么是数据可观测性

简单说，数据可观测性就是让你能随时回答三个问题：

• 数据现在健康吗？——有没有延迟、缺失、重复
• 数据从哪来、到哪去？——整个流转链路是否清晰
• 数据出问题时，根因在哪？——能不能快速定位

我习惯把它比作汽车的仪表盘。你开车时，油量、转速、水温一目了然。数据系统也一样——你得有个仪表盘，告诉你数据管道里每一段的状态。

为什么需要数据可观测性

你想想看，传统的数据监控能做什么？

• 定时跑个数据质量检查脚本
• 出问题了发个告警邮件
• 然后运维同学开始翻日志、查代码

这套模式在数据量小、链路短的时候还行。但现在的数据环境呢？

维度	传统监控	数据可观测性
数据源	几十个表	几百个数据源、上千张表
链路长度	采集→存储→使用	采集→清洗→转换→聚合→建模→服务→消费
问题发现	被动告警	主动感知、趋势预测
根因定位	人工排查	链路追踪、自动关联

我在项目中遇到过最典型的情况：凌晨3点，ETL任务跑完了，但报表数据对不上。传统监控只会告诉你「任务成功」，但数据对不对？不知道。你只能爬起来，从源头开始一个个表查。折腾到天亮，发现是上游某个字段类型变了。

如果有数据可观测性，这种问题在数据入库那一刻就能发现。说白了，数据可观测性解决的是「数据黑盒」问题——让你不再靠猜来管理数据。

数据可观测性的三大支柱

聊完了概念和必要性，咱们进入正题。数据可观测性有三大支柱：元数据、指标、日志。这三者缺一不可。

1. 元数据——数据的「户口本」

元数据就是描述数据的数据。它包括：

• 技术元数据：表结构、字段类型、分区信息、存储位置
• 业务元数据：字段含义、业务口径、数据来源
• 操作元数据：ETL任务信息、调度依赖、运行记录
• 血缘元数据：数据从哪里来、经过哪些处理、最终流向哪里

我曾经接手过一个数据平台，光表就有3000多张。没有元数据管理，新同事入职三个月都搞不清「用户活跃表」到底用的是哪个口径。后来我们建了元数据中心，把血缘关系画出来——嗯，这才算真正把数据管起来了。

2. 指标——数据的「体检报告」

指标是衡量数据健康度的量化标准。常见的指标包括：

• 时效性指标：数据延迟时间、任务完成时间
• 完整性指标：空值率、缺失率、记录数波动
• 准确性指标：数据分布偏差、异常值比例
• 一致性指标：跨表数据对账结果、汇总与明细匹配度

我建议每个数据管道至少设置5-8个核心指标。不是越多越好，而是每个指标都要能回答一个具体问题。比如「今天的数据延迟超过30分钟了吗？」「订单表的空值率是否超过1%？」

3. 日志——数据的「行车记录仪」

日志记录了数据系统运行过程中的所有事件。它跟元数据和指标的区别在于：

• 元数据告诉你「数据长什么样」
• 指标告诉你「数据健康吗」
• 日志告诉你「刚才发生了什么」

日志包括：

• 数据采集日志（源端读取了多少条、耗时多久）
• ETL执行日志（每个步骤的输入输出、错误信息）
• 数据质量检查日志（哪些规则通过了、哪些失败了）
• 系统运行日志（CPU、内存、磁盘IO）

日志的关键在于结构化。我见过太多团队把日志写成散文——「今天数据好像有点问题，可能是网络不好」。这种日志对排查问题毫无帮助。好的日志应该像这样：

2024-01-15 03:12:45 [WARN] [ETL-ORDER-001] 
  source: kafka://order_topic
  target: hdfs://dw/order_daily
  records_read: 1,234,567
  records_written: 1,234,000
  diff: 567 (0.046%)
  reason: 3 records failed deserialization, 564 records filtered by dedup

你看，这种日志一看就知道问题在哪——反序列化失败3条，去重过滤564条。根本不用猜。

三大支柱的关系

这三者不是孤立的。我画了张图，帮你理清它们的关系：

从图上你能看到：元数据是基础，它定义了「数据是什么」；指标是度量，它告诉你「数据好不好」；日志是记录，它帮你追溯「数据怎么了」。三者形成一个闭环——定义→度量→追溯。

好了，这一章的内容就到这里。数据可观测性不是什么玄学，它就是一套让你能「看见」数据健康状况的方法论。记住三大支柱——元数据、指标、日志，后面的章节我们会逐一深入讲解每个支柱的落地实践。