想象你是一家连锁餐厅的厨师长。每天凌晨，供应商的货车把蔬菜、肉类、酱料送到后门，这些全是做菜的原料。原料经过配菜、切洗、烹饪、装盘，最后端到顾客桌上。若有一批牛肉变质，顾客吃了不舒服，你第一反应是查：肉从哪家农场来？冷链车温度记录有没有异常？哪个环节最可疑？数据世界里，原料就是数据，做菜链路就是一个个数据加工流程。数据来自不同系统，经过层层清洗、合并、转换，最终变成报表和模型。一旦下游结果出错，想找到源头常常如同大海捞针。要解决这个难题，需要三样厨房里常见的东西：一张质检检查表，把原料分成几类逐项打分，得出健康分数，这就是“数据质量评分卡”；一个对顾客的承诺，比如“三十分钟上齐菜，超时免单”，这就是监控和保障数据按时按质交付的“SLA 约定”；还有一本从农场到餐桌的详细台账，记录每份原料的来龙去脉，方便出问题时彻底追溯，这就是“数据血缘”。三者配合，后厨才能对每一道菜负责，数据团队也才能对每一份数据负责。

岗位关联

学完本节，你将掌握为数据系统建立“可量化的质量度量 + 可承诺的服务协议 + 可追溯的源头证据”的能力，这是数据治理与 MLOps 中衡量专业度的重要分水岭。

目录
  1. 可视化演示
  2. 评分卡概念
  3. 质量维度
  4. 权重设计
  5. SLA制定
  6. 监控预警
  7. 血缘关联
  8. 治理实践
  9. 工具落地
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

展示完整性准确性等六维质量评分卡雷达图与加权求和综合分、到位时间与质量门槛双维SLA契约分层及探针采集架构、以及P0至P2分级告警与违约处置闭环响应流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

六维质量评分卡 完整性准确性一致性及时性唯一性有效性六维 加权求和聚合为可比较综合分数 ΣWi×Si 六维加权求和综合评分

评分卡概念

你在医院拿到的体检报告，不会只写一句“身体还行”，而会先列出血常规、肝功能、血压等十几项指标，再给出一段总体健康评估。数据质量评分卡做的事情完全一样：把抽象的数据质量拆成一组可测量的指标，汇总成一张让人一目了然的“健康报告单”。

数据质量评分卡（Data Quality Scorecard）是数据治理中最常用的量化工具。它将数据的各个质量维度分别打分，再按业务影响加权，最后输出一个综合得分与等级。它既可以是每日自动运行的操作性评分卡，用于日常巡检；也可以是每周或每月跑一次的分析性评分卡，用于审视长期质量趋势。

一张评分卡通常包括维度定义、打分规则、权重配置和阈值等级。业务方先确认哪些字段关键、哪些指标可接受，平台再按规则引擎执行。下面的公式就是评分卡的核心骨架。

在厨房里，这张评分卡就像把“食材是否新鲜、份量是否达标、台账是否清晰”汇总成一张总检单，厨师长扫一眼便知道今天是否适合营业。数据团队负责人拿到评分卡后，也能在 30 秒内判断某个数据资产该“放行”还是“待整改”。

S=∑i=1nwi×di\displaystyle S = \sum_{i=1}^{n} w_i \times d_i
一句话理解：综合得分等于每个维度得分乘上对应的业务权重，再把所有乘积加起来。
  1. 列出质量维度把数据质量拆成可量化的检查项目，例如完整性、准确性、一致性、及时性。
    {d1,d2,…,dn}\displaystyle \{d_1, d_2, \dots, d_n\}
  2. 获取维度得分每个维度通过规则引擎得到 0 到 1 之间的量化得分，得分越高代表该项越健康。
    di∈[0,1]\displaystyle d_i \in [0, 1]
  3. 分配业务权重依据业务重要性为每个维度分配权重，并确保所有权重数值相加等于 1。
    ∑i=1nwi=1\displaystyle \sum_{i=1}^{n} w_i = 1
  4. 加权求和将权重与得分相乘并累加，得到最终的综合质量得分，供管理层快速决策。
    S=∑i=1nwi×di\displaystyle S = \sum_{i=1}^{n} w_i \times d_i

质量维度

质检员从四个角度检查一份牛排：克重是否足够（完整性）、牛排是否煎到要求的熟度（准确性）、菜单与实物是否一致（一致性）、上桌温度是否达标（及时性）。这四个维度就像体检的四大项，任何一项亮红灯，菜品就不能上桌。

数据质量维度是评分卡里的“检查项”。业界最常用的四个核心维度是：完整性关注记录和字段是否存在；准确性要求数据值与真实业务一致；一致性强调同一实体的数据在不同系统中保持统一语义；及时性则指数据能否在约定时间内到位。

以“完整性”为例，平台会扫描目标表，统计总记录数 total_i 以及缺失或空值的记录数 bad_i，再用下面的公式计算出该维度得分。

就像对一盘牛排检查“份量、熟度、配菜、温度”四关，数据平台在每日例行巡检时也依次对每个维度打分，凡低于 0.8 的维度即时标红，为后续触发告警和责任人整改提供依据。

di=1−baditotali\displaystyle d_i = 1 - \frac{\text{bad}_i}{\text{total}_i}
通俗理解：维度得分就是“没出问题的记录比例”。若 1000 条记录中有 20 条缺失，完整性得分为 0.98。
  1. 统计记录总量先确定该维度检查覆盖的目标表和字段，统计总记录数。
    totali\displaystyle \text{total}_i
  2. 统计坏记录数扫描数据，统计不满足质量规则的记录数量，例如缺失、超出值域。
    badi\displaystyle \text{bad}_i
  3. 计算错误率并取补错误率为坏记录数除以总记录数，用 1 减去错误率即得到该维度得分。
    di=1−baditotali\displaystyle d_i = 1 - \frac{\text{bad}_i}{\text{total}_i}

权重设计

同样是检查，厨师长眼里“食材变质”比“摆盘不够漂亮”严重得多。如果两项同分并简单平均，就会掩盖致命问题。所以质检表要为不同检查项设不同权重：食品安全权重 40%，口味 30%，摆盘 20%，出餐速度 10%。

数据评分卡也一样。对金融风控系统，准确性和及时性往往共占 70% 权重；而对营销客户画像，完整性可能更重要。权重设计的基本原则是让权重真实反映业务对每种数据缺陷的容忍程度。

业务方给出的通常是原始权重，例如（0.5，0.3，0.1，0.1），但不同团队的评分习惯不同，需要先做归一化，确保最终总和为 1。归一化公式如下。同时，业务方还会设定阈值分级：得分 ≥ 0.9 为优秀，0.8 至 0.9 为良好，0.6 至 0.8 为需改进，低于 0.6 为不合格。

厨房质检表的权重来自厨师长和店长共同复盘：哪些质量问题客诉最多，就给最高权重。数据团队也应按季度与业务方复盘权重，让评分卡跟着业务变化动态调优，而不是一套配置用一年。

wi′=wi∑j=1nwj\displaystyle w'_i = \frac{w_i}{\sum_{j=1}^{n} w_j}
通俗理解：把每个原始权重“按比例缩放”，使全部权重相加刚好等于 1，从而保证综合得分落在 0 到 1 之间。
  1. 保留原始重要性业务方先根据经验给出各维度的原始权重，例如准确性最重要就给它最高分。
    wi\displaystyle w_i
  2. 求权重总和把所有维度的原始权重相加，得到权重分母。
    ∑j=1nwj\displaystyle \sum_{j=1}^{n} w_j
  3. 归一化处理每个原始权重除以总和，得到新的归一化权重，保证所有维度权重之和恰好为 1。
    wi′=wi∑j=1nwj\displaystyle w'_i = \frac{w_i}{\sum_{j=1}^{n} w_j}

SLA制定

顾客刚落座，服务员热情地说：“您点的菜 30 分钟内上齐，超时的菜我们免单。”这并非一句空话，而是一份有数字、有惩罚的承诺。在数据服务里，这份承诺就是 SLA（Service Level Agreement，服务级别协议）。它把“数据到底有多靠谱”变成可以检验的合同。

数据 SLA 通常包含三个核心部分：可用性（服务在统计周期内正常运行的时长比例）、就绪时间（批处理任务完成的截止时刻）、数据质量约束（例如核心字段完整性不低于 99%）。数据团队与业务方在制定 SLA 时，要协商业务真实需求、基础设施当前能力、中间留多少余量，而不是单方面拍脑袋。

可用性的量化公式最直观。假设统计周期为 30 天共 720 小时，其中数据服务正常提供查询与写入的时间为 719 小时，则可用性约为 99.86%。

承诺写得越具体，执行才越有抓手。就像餐厅把“超时免单”写清楚从下单到上齐菜的时间阈值，数据 SLA 也要把可用性、就绪时间、质量阈值和责任人写清楚，否则违约时就只能扯皮。

A=TupTtotal\displaystyle A = \frac{T_{\text{up}}}{T_{\text{total}}}
通俗理解：按一年 365 天算，99.9% 可用性意味着全年最多不可用 8.76 小时；99.99% 则只有 52.6 分钟。
  1. 确定统计周期先明确 SLA 统计的总时间窗口，例如 30 天或 1 年。
    Ttotal\displaystyle T_{\text{total}}
  2. 累计可用时长统计系统或数据任务在正常服务状态下的总时长。
    Tup\displaystyle T_{\text{up}}
  3. 计算可用比可用时长除以总时长，得到百分比形式的 SLA 可用性指标。
    A=TupTtotal\displaystyle A = \frac{T_{\text{up}}}{T_{\text{total}}}

监控预警

厨房里挂着一块电子看板，实时刷新每张餐桌从下单到出菜的时间。一旦某桌超过 25 分钟，看板会闪起红灯并提示“2 号桌即将超时”。厨师长不需要一直盯表，系统自动提醒。

SLA 监控就是数据系统的电子看板。它按固定周期（如每分钟或每 30 秒）采集数据管线的时延、任务完成状态等指标，与已定义的 SLA 目标比对，并绘制成趋势图。一旦指标滑落到阈值以下，监控平台就按严重程度发出通知。

SLA 满足率的计算是监控告警的核心：在某个滑动窗口内，将达标的监控点数量除以总监控点数量，就得到该窗口的满足率。

电子看板的告警让后厨从被动灭火变为主动改进：一旦满足率连续两小时低于 95%，自动通知责任人和值班群，并附上受影响的数据链路，把问题消灭在顾客察觉之前。

Rsla=NokNtotal\displaystyle R_{\text{sla}} = \frac{N_{\text{ok}}}{N_{\text{total}}}
通俗理解：如果一小时内采集了 120 个监控点，其中 118 个满足时延目标，那么该窗口的 SLA 满足率为 98.3%。
  1. 采集监控点每隔固定周期采集一次 SLA 指标，得到总监控点数量。
    Ntotal\displaystyle N_{\text{total}}
  2. 判定是否达标把每个监控点的数值与 SLA 阈值比较，满足条件的标记为达标。
    Nok\displaystyle N_{\text{ok}}
  3. 计算满足率用达标监控点数除以总监控点数，得出窗口内满足率；低于阈值即触发告警。
    Rsla=NokNtotal\displaystyle R_{\text{sla}} = \frac{N_{\text{ok}}}{N_{\text{total}}}

血缘关联

顾客投诉沙拉里有异物，厨师长立刻翻开台账：这盒生菜来自晨光农场 2 号大棚，冷链车 5 号，9 点整入库，洗菜员小李 10 点完成清洗。有了台账，追溯责任只需 5 分钟，而不是把全厨房盘问一遍。

数据血缘（Data Lineage）就是数据世界的台账，它记录每张表、每个字段从哪个源系统产生，经过哪些清洗任务和加工脚本，最后进入哪些报表或模型。血缘通常以有向无环图（DAG）展示，节点是数据资产，边代表加工和依赖关系。

当评分卡发现某张表的一致性得分骤降时，血缘图谱能在数秒内回答“谁影响了它”“它又影响了谁”。向上游定位属于源头追溯，向下游分析用于评估变更的影响范围。下游影响集合可用下面的形式表达。

台账让后厨不再靠个人记忆追责；血缘让数据团队从“满世界查脚本”变成“双击节点看全链路”。评分卡告诉你有问题，血缘告诉你问题出在哪、波及到哪。

Impact=⋃v∈downstream(t)v\displaystyle \text{Impact} = \bigcup_{v \in \text{downstream}(t)} v
通俗理解：把出问题的表当作起点，顺着依赖关系一直往下游走，把所有遇到的节点收集起来，就是受影响面。
  1. 定位问题节点找到发生质量问题的表或字段，作为血缘图遍历的起点。
    t\displaystyle t
  2. 向下游遍历沿血缘边向输出方向移动，得到所有直接或间接依赖该节点的集合。
    downstream(t)\displaystyle \text{downstream}(t)
  3. 合并影响集合把遍历到的所有下游节点合并为一个影响范围集合，供变更评估使用。
    Impact=⋃v∈downstream(t)v\displaystyle \text{Impact} = \bigcup_{v \in \text{downstream}(t)} v

治理实践

厨房质检发现问题不会停在告警。专业后厨会开出一张“问题整改单”，写明责任人、完成时限、复查结果，并贴在看板上，直到问题关闭。质检员不会把单据收进抽屉便了事。

数据治理实践强调同样的闭环：发现质量问题 → 登记工单 → 数据 Owner 指定责任人 → 完成整改 → 复审验证 → 关闭工单。缺失任一环节，监控就会变成“只报警、不处理”，最终导致告警疲劳。

衡量治理执行力的核心指标是“问题闭环率”。例如 11 月累计登记 120 个数据质量问题，105 个已完成整改并验证关闭，则闭环率为 87.5%。这一数字会出现在周报中，用于比较各团队治理力度。

厨房里最怕“查了不改、改了又复发”；治理实践就是一套让问题从发现、整改到验收都有据可查的机制。加上定期复盘，数据质量才能在一次次循环中稳步提升。

CloseRate=NclosedNraised\displaystyle \text{CloseRate} = \frac{N_{\text{closed}}}{N_{\text{raised}}}
通俗理解：闭环率就是“问题进来之后有多大概率被彻底解决”，数值越接近 1，说明治理体系越健康。
  1. 登记问题工单监控或评审发现问题后，将其登记为待处理问题，记录负责团队和优先级。
    Nraised\displaystyle N_{\text{raised}}
  2. 跟踪整改关闭责任人按要求整改并验证通过后，在平台上关闭工单。
    Nclosed\displaystyle N_{\text{closed}}
  3. 计算闭环率已关闭数量除以已登记数量，得到治理闭环率，并进入月度复盘。
    CloseRate=NclosedNraised\displaystyle \text{CloseRate} = \frac{N_{\text{closed}}}{N_{\text{raised}}}

工具落地

质检全凭人工，一天只能抽检几十份食材；现代化中央厨房用传送带上的检测仪，每分钟能检查上千份食材。数据质量工具就是流水线检测仪，把人工经验固化成自动执行的规则和平台。

当前常见工具包括开源社区的数据质量组件（如 Great Expectations、dbt tests、Deequ）和数据血缘平台（如 DataHub、OpenMetadata），也可在企业数据中台上自行封装。工具落地的关键在于把规则配置、评分计算、SLA 监控和血缘图谱统一到同一个平台界面，让问题出现时横向打通。

对超大表，全量校验耗时巨大，实践中常采用抽样评估。抽样数由统计公式决定，保证误差可控的同时降低计算成本。

质检从“人眼抽查”进化到“机器全检”，数据质量从“手工报表”进化到“平台看板”。当评分卡、SLA、血缘三者能在同一套工具里闭环流转，数据治理才真正完成了工程化落地。

n=Z2×p×(1−p)E2\displaystyle n = \frac{Z^2 \times p \times (1-p)}{E^2}
通俗理解：想达到 95% 的置信度、允许 2% 的误差，并预估错误率 5%，代入公式约需抽检 456 条记录，而不是扫描整张亿级表。
  1. 确定置信水平根据质量监控的置信度要求选择 Z 值，例如 95% 置信度下取 1.96。
    Z=1.96\displaystyle Z = 1.96
  2. 预估问题比例参考历史数据给出目标维度的错误率估计，例如 5%。
    p=0.05\displaystyle p = 0.05
  3. 设定误差边界确定可接受的抽样误差，例如 2%，越小则需要样本越多。
    E=0.02\displaystyle E = 0.02
  4. 计算样本量将参数代入公式，得出需要抽查的最小样本量，从而降低全量扫描成本。
    n=Z2×p×(1−p)E2\displaystyle n = \frac{Z^2 \times p \times (1-p)}{E^2}

AI 应用场景

金融风控数据质量监管

阶段：数据治理与 MLOps 监控（模型输入层）

解决的问题：传统人工抽查难以及时发现客户主数据缺失、滞后等问题，导致风控模型输入偏差、坏账预估失真。

具体案例：某银行数据平台为“客户主数据”配置评分卡，权重为完整性 0.3、准确性 0.4、及时性 0.3，每天凌晨自动打分。SLA 要求批处理在 02:00 前完成，若完成时间超过 02:30 或任一维度得分低于 0.85，触发 P1 告警并自动附上受影响的下游风控模型清单，基于血缘图谱定位根因。

电商大促实时链路 SLA 保障

阶段：在线特征管线监控

解决的问题：大促期间价格、库存、推荐特征链路延迟会导致用户看到过期信息，人工盯屏无法及时扩容和定位。

具体案例：某电商平台将“订单 → 特征更新 → 推荐调用”的 SLA 定为 3 分钟。监控组件每 30 秒获取一次链路耗时，用 30 分钟滑动窗口计算达标率；低于 95% 时自动扩容计算资源，并通过血缘定位耗时节点，优先处理单点瓶颈。

医疗数据治理质量闭环

阶段：数据治理与合规审计

解决的问题：电子病历字段缺失、诊断编码不一致，影响科研分析和卫生统计上报。

具体案例：某医院数据中心对 20 个核心表建立质量评分卡，结合血缘定位缺失源，发现门诊录入系统存在必填项校验漏洞。修复后核心表完整性从 82% 提升到 98%，并输出季度治理报告。

Python 演示

python75 行
"""数据质量评分卡与SLA监控示例"""from datetime import datetime, timedelta  class DqScorecard:    """按维度加权计算数据质量综合得分"""     def __init__(self, dim_config):        self.dim_config = dim_config        self.history = []     def dimension_score(self, bad, total):        if total == 0:            return 0.0        return 1.0 - bad / total     def evaluate(self, checks):        total_score = 0.0        dim_scores = {}        for name, weight in self.dim_config.items():            item = checks[name]            score = self.dimension_score(item["bad"], item["total"])            dim_scores[name] = round(score, 4)            total_score += weight * score        self.history.append(total_score)        return {"dim": dim_scores, "overall": round(total_score, 4)}  class SlaMonitor:    """在滑动时间窗口内统计 SLA 满足率"""     def __init__(self, window_minutes=60):        self.window = timedelta(minutes=window_minutes)        self.events = []     def record(self, time, ok):        self.events.append((time, ok))     def satisfaction(self, now):        cutoff = now - self.window        total = 0        ok_count = 0        for time, ok in self.events:            if time >= cutoff:                total += 1                if ok:                    ok_count += 1        if total == 0:            return 0.0        return ok_count / total  if __name__ == "__main__":    card = DqScorecard({        "完整性": 0.3,        "准确性": 0.3,        "一致性": 0.2,        "及时性": 0.2,    })    checks = {        "完整性": {"total": 1000, "bad": 12},        "准确性": {"total": 1000, "bad": 8},        "一致性": {"total": 1000, "bad": 45},        "及时性": {"total": 1000, "bad": 5},    }    result = card.evaluate(checks)    print("维度得分:", result["dim"])    print("综合得分:", result["overall"])     now = datetime.now()    monitor = SlaMonitor(window_minutes=30)    for i in range(40):        ok = (i % 10) < 8  # 80% 时段满足 SLA        monitor.record(now - timedelta(minutes=(40 - i) * 2), ok)    print("SLA满足率:", round(monitor.satisfaction(now), 4))
目的：演示数据质量评分卡加权计算和 SLA 满足率统计的完整流程，可直接扩展为每日质量巡检脚本。
  1. class DqScorecard:定义评分卡类，保存各维度权重配置与历史得分。
  2. self.dim_config = dim_config保存每个维度的业务权重，驱动后续加权计算。
  3. return 1.0 - bad / total维度得分等于 1 减去坏数据占比，即“没问题比例”。
  4. for name, weight in self.dim_config.items():遍历每个维度，逐项计算得分并累加。
  5. total_score += weight * score加权累积，实现综合得分的核心公式。
  6. self.history.append(total_score)保留历史综合分，为后续趋势分析提供数据。
  7. class SlaMonitor:定义 SLA 监控类，采用滑动窗口统计满足率。
  8. cutoff = now - self.window计算出 30 分钟滑动窗口的起始时刻。
  9. if time >= cutoff:只统计窗口内的事件，窗口外旧数据自动忽略。
  10. ok_count / total用达标次数除以总次数，得到 SLA 满足率。

常见误区

误区数据质量评分应该追求 100 分，做不到满分就是不合格。我平时都要求团队把所有质量指标设成 100%。

正解数据质量满分的成本极高且往往无必要。评分卡的价值在于把质量量化并与业务目标对齐：设定可接受的阈值（例如核心字段 98%）并持续监控趋势，及时处理低于阈值的项。厨房质检不会要求所有菜肴零投诉，而是在可接受范围内持续改进。

为何常见：把“质量”等同于“绝对完美”，忽略了质量是与成本、业务影响相权衡的工程决策。

误区四个维度都很重要，那每个维度权重一样不就好？简单省事，而且看起来很公平。

正解不同业务对质量维度的敏感度差异很大。风控系统最怕数据不准确、不及时，权重应偏向准确性和及时性；客户画像体系更重视完整性。权重应由业务方和数据团队按业务损失、监管要求共同制定，不能默认平均分配。

为何常见：简单平均是最快的决策方式，但忽略了业务差异和场景优先级。

误区SLA 监控就是看系统是否在线，只要集群不宕机，就算 SLA 达标。

正解数据 SLA 不仅包含基础设施可用性，还包含数据就绪时间（批处理是否按时完成）、数据质量维度（字段完整性、准确性）和端到端时延。好比餐厅承诺是否兑现，不只看餐厅开着门，还要看 30 分钟内菜是否真正上齐。

为何常见：沿用传统运维以基础设施为中心的视角，忽略了数据服务承诺的业务结果。

误区数据血缘就是画几张 DAG 拓扑图，给领导汇报用的，对实际开发没什么帮助。

正解血缘的价值在于可操作：变更影响分析能提前评估下游风险，质量问题能顺着血缘快速定位源头，合规审计能通过血缘证明数据来源与去向。没有血缘时定位问题靠猜，有血缘时定位问题靠图。

为何常见：只看过血缘可视化展示，没有结合具体问题场景使用过影响分析和追溯能力。

误区告警发出就完成监控任务了，剩下就是值班维护人员自己看着办。

正解SLA 监控必须与治理闭环结合：告警后要登记问题、指定责任、整改验证、关闭工单，否则监控会退化成“狼来了”式的告警疲劳。数据质量治理首先是一个流程问题，然后才是工具问题。

为何常见：团队只考核监控覆盖率，不考核问题闭环率，忽略了告警后行动的价值。

面试题

Q1. 数据质量评分卡最主要的作用是？

单选题 · easy

  • A.提升数据仓库的存储容量
  • B.量化评估数据质量水平← 正确答案
  • C.加速 SQL 查询计算速度
  • D.替代数据加密与安全策略

答案：B。评分卡将数据质量拆分为多个维度，经过打分和加权得到综合得分，核心是量化评估。存储容量属于数据规模问题，SQL 性能属于查询优化，加密安全属于风险控制，都不是评分卡的首要目标。

Q2. “完整性”维度衡量什么？

单选题 · easy

  • A.数据记录是否缺失← 正确答案
  • B.数据格式是否统一
  • C.数据来源是否可靠
  • D.数据存储是否持久

答案：A。完整性衡量的是“有没有”，即记录和字段是否存在缺失，就像食材是否短斤缺两。格式统一描述一致性，来源可靠更像是可信度或准确性范畴，持久性属于存储可达性，均不属于完整性。

Q3. 若完整性的 total=1000、bad=20，则完整性得分为？

单选题 · easy

  • A.0.020
  • B.0.200
  • C.0.980← 正确答案
  • D.1.000

答案：C。将 20 条坏数据除以 1000 条总量得到 0.02 的错误率，再用 1 减去错误率得到 0.98。选项 A 是把错误率当得分，B 是计算错误，D 忽略了坏数据的影响。

Q4. 在加权平均评分中，各维度权重之和通常应为？

单选题 · mid

  • A.数值等于 1← 正确答案
  • B.数值小于 0
  • C.数值大于 10
  • D.取接近无穷大

答案：A。为使综合得分保持在 0 到 1 之间，所有维度权重归一化后相加必须等于 1。权重小于 0 没有业务解释，权重大于 1 和无穷大会扭曲总分。就像菜谱中各种配料的比例合计必须等于 100%。

Q5. SLA 为 99.9% 时，一年最多不可用约多久？

单选题 · mid

  • A.约 8.76 小时← 正确答案
  • B.约 52.6 分钟
  • C.约 3.65 天
  • D.约 36.5 天

答案：A。99.9% 的不可用比例是 0.1%，一年 8760 小时乘以 0.1% 等于 8.76 小时。52.6 分钟对应 99.99%，3.65 天和 36.5 天分别对应 99% 和 90% 的不可用时长。

Q6. 下列哪些属于数据质量的核心维度？

多选题 · mid

  • A.数据完整性← 正确答案
  • B.数据准确性← 正确答案
  • C.数据一致性← 正确答案
  • D.系统耗电量

答案：ABC。完整性、准确性、一致性加上及时性和唯一性共同构成数据质量评分框架。系统耗电量属于基础设施运行指标，与数据本身的质量属性无关。

Q7. 数据血缘最直接的价值是什么？

单选题 · mid

  • A.追踪数据来龙去脉← 正确答案
  • B.压缩数据存储空间
  • C.提升 SQL 并发能力
  • D.自动生成业务报表

答案：A。数据血缘通过有向无环图记录数据从源头到最终消费的流转路径，核心价值是追踪来龙去脉、辅助影响分析和问题追溯。压缩空间、提升并发、生成报表属于存储、查询和 BI 方向，与血缘无直接关系。

Q8. 关于“5个9”（99.999%）可用性，正确的理解有哪些？

多选题 · hard

  • A.约 5 分钟不可用← 正确答案
  • B.极高级别的正常服务← 正确答案
  • C.故障恢复时间必为 0
  • D.运维与灾备可取消

答案：AB。99.999% 可用性意味着全年不可用约 5.26 分钟，确实是极高可用级别，但并不等于故障为零，也不代表灾备可以取消。高可用恰恰依赖冗余与监控体系，C、D 都是错误推断。

Q9. 治理闭环中“问题闭环率”的正确定义是？

单选题 · hard

  • A.关闭问题数除以提出问题数← 正确答案
  • B.告警次数除以任务总数
  • C.数据表数量除以业务数量
  • D.上线版本数除以回滚数

答案：A。闭环率等于已关闭问题数除以已提出问题数，衡量从发现到整改完毕的完成比例。其他选项分别混淆了告警密度、表数量比例和版本回滚率，都与质量问题整改的闭环机制无关。

Q10. 设计数据 SLA 时，优先考虑哪些要素？

多选题 · extreme

  • A.数据就绪时间窗口← 正确答案
  • B.数据质量维度阈值← 正确答案
  • C.用无限资源追求零缺陷
  • D.明确责任人与补救动作← 正确答案

答案：ABD。数据 SLA 设计重点是就绪时间、质量阈值、责任人与补救动作。无限追求零缺陷会导致成本失控，并不现实。SLA 是服务和业务之间的承诺与权衡，而不是不切实际的吹牛比赛。