更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【1】进入官方交流群

“幸福里”是抖音集团旗下集内容、社区、工具于一体的房产媒体综合信息平台，致力于提供多样化房产资讯、定制找房需求。随着幸福里业务发展，为了满足业务对于数据使用、指标观测等需求，团队快速落地了数仓建设。但由于早期“先建后治”，导致现阶段数据治理难题频发。

其中，异常突出的是离线数仓 SLA 延迟大，高达 13 天。对于需要实时看到数据情况的经纪人、用户等人来说，延时可能会影响到数据价值的产出。

在抖音集团内部广泛应用“0987”高质量服务评价体系，即从多个维度综合论证数据中台的价值，位列第一的“0”，指的是数据中台必须保障数据稳定，实现 SLA 故障清零。而对于幸福里团队来说，SLA 高延时显然已经成为数据治理中未解决的核心问题。

基于此背景，幸福里团队通过引入火山引擎大数据研发治理套件 DataLeap，综合推进离线数仓的 SLA 治理，将离线数仓 SLA 从 13 天降低为 0 天。本文将从策略制定、任务摸排收集、规范确定，宣贯推进等方向还原项目推进过程，期望为更多企业带来 SLA 治理思考和解决方案。

业务痛点

据相关业务同学介绍，幸福里团队与其他面临 SLA 治理难题大同小异，主要包含以下两个方面：

第一，随着楼盘、房源、经纪人、营销等数据不断增长，在数据任务开发场景中，业务多样化、数据量大、数据任务复杂等问题，导致数据任务链路依赖复杂、链路长、依赖多，具体体现在：

• 幸福里离线数仓数据源包括中台型数据，这类数据没有 SLA 保障。

• 幸福里离线数仓数据源还包括业务 DA 以及算法类数据。以算法类数据为例，数据本身在算法团队自身队列当中，由于无法分别出业务需要的重要数据，队列任务可能发生延迟、时效性不强，另外还存在任务交接或权限到期等问题，导致这些数据无法得到有效保障。

• 幸福里离线数仓 SLA 链路长。相关业务人员提到，“内部最长的链路上游包括 800 多张表，这里的上游仅局限在幸福里业务内部，还不包括中台”。由此可见，上游任务数之多，且可能涉及跨越多个团队沟通，要最终达成约定 SLA，成本将非常高。

第二，数据建设主导方变更，业务形态转变，导致历史包袱重、存量任务优化工作量大，这与幸福里离线数据建设历程强关联。在幸福里数仓 1.0 阶段，数据仓库由业务方 DA 与 RD 自建，未有明确的数仓规范，数据模型较混乱。2021 年 3 月份，幸福里业务过程及业务形态发生转变，业务主体由流量转为交易，为了满足业务高速发展需求，数据建设以快速落地、指标准确产出为主要目标，历史遗留问题治理较少。

随着业务发展逐渐稳定，数仓建设进入 2.0 阶段。由于数仓中大量线上数据和重要指标依然使用 1.0 阶段的老表，导致指标口径不统一，同时也存在历史表数据无人维护的问题，导致时效性差。另外，幸福里数仓也面临存量任务优化的问题。有些存量任务运行时间长、资源占用严重，团队亟需排查这部分问题。

解决方案

为了解决 SLA 延时问题，幸福里团队引入了火山引擎大数据研发治理套件 DataLeap，通过 DataLeap 的三大能力，形成一套连贯、可复用的治理方案，最终形成 SLA 保障全链路高效管理。具体来看：

• 通过数据治理能力，解决任务上游承诺并签署保障 SLA 的问题。数据治理平台支持任务负责人申报任务，并快速拉起上游完成 SLA 签署承诺，从而保障链路稳定性，这也是幸福里团队使用的核心功能。

• 通过数据研发能力，解决 SLA 任务的基线监控问题。在任务多，依赖关系复杂的情况下，很难查找到重要任务的所有上游任务并进行监控。如果监控所有任务，又会产生很多无用报警，导致有用报警被忽略。因此，幸福里团队通过使用 DataLeap 的数据研发能力，将下游节点作为保障任务加入基线，形成需要监控的任务链路。

• 通过数据质量监控能力，解决 Hive 表监控问题。针对某些卡点任务进行表监控，一方面保障 SLA 及时性，另一方面保证整体任务准确性。

下文三个步骤，带你还原幸福里离线数仓治理项目全过程！

第一步：圈定 SLA 保障核心任务

幸福里团队首先根据业务需求，圈定出需要被 SLA 保障的核心任务，具体包括以下三类：

• 线上核心任务，即直接展示给 B 端经纪人或 C 端用户的数据。

• 管理驾驶舱数据，包括日报、周报、月报等。

• 重点业务核心看板。例如，2022 年幸福里重点业务在福州，因此对需要对福州数据提供优先保障，确保当地经纪人、店长等业务角色能准确、快速获取数据，以便制定相应推广策略。

第二步：制定全局保障方案

幸福里团队通过引入 DataLeap 数据治理平台，推进对核心任务的 SLA 治理工作。对于任务运行中的异常数据或突发事故，基于配置基线监控的运维能力，加强报警能力，另外通过数据质量监控平台完成核心维表及核心指标表监控，以提供更加稳定的数据服务。

在 SLA 治理环节，存在核心任务 SLA 保障不足，有发生线上业务事故的隐患问题。除此之外，SLA 任务运维报警能力不足或者 SLA 签署时间不合理等，有 SLA 延迟隐患，造成破线事故。

对于新增 SLA 任务，数据治理平台【SLA 保障】-> 【SLA 管理】页面，点击【发起申报】，以申报单签署的形式达成 SLA 协议，在申报签署环节中，各个环节的变化将通过通知模块传递信息给相应负责人，实时通知降低信息交流成本，加速了 SLA 的达成。

火山引擎 DataLeap 数据治理平台 SLA 申报页面

幸福里团队任务签署 SLA 步骤

在基线报警环节，据相关业务人员介绍，只有 34%的核心任务配置了基线监控，导致有发生线上业务事故的隐患，同时无效报警较多，造成无效起夜、运维压力较大。

火山引擎 DataLeap 支持圈选核心任务，并根据任务近 30 天产出表现，根据近 30 天 75 分位产出时间，产出时间波动方差、链路最长任务平均时长、下游任务总数、业务期望产出时间等作为输入数据，产出合理基线预期产出时间及预警 buffer 配置基线，还支持校准基线监控范围。

幸福里团队基线报警治理思路

幸福里平台有一个关系到经纪人核心利益的“幸福分”指标。当经纪人完成相应任务时，幸福分值增加。但当维表中数据缺失，在前台反映的结果则是“幸福分”不更新，对经纪人造成困扰。另外，据业务同学介绍，之前还出现过这样的案例：小李在数据库中的核心维度是“经纪人”，但在维表中，可能测试数据误导入或重复数据导入，导致小李对应到多个门店或对应到错误房源。

为了解决以上问题，幸福里团队在 Hive 表监控环节，引入了火山引擎 DataLeap 数据质量监控能力。对于业务核心关注的线上任务、管理驾驶舱数据以及重点业务核心看板等数据，通过数据质量监控平台完成数据波动监控、异常报警，避免因为数据质量导致的数据失信、决策失误等事故。

数据质量整体策略

第三步：量化 SLA 效果并复盘

在 DataLeap 数据治理平台中，SLA 大盘展板支持提供当日 SLA 整体统计信息、SLA 延迟趋势分析信息、SLA 等级分布明细、任务健康度明细、团队 SLA 达成信息统计等丰富信息，是很多团队数据治理指标重要参照来源。

幸福里项目中的核心数据指标如 SLA 任务数量、报警数、起夜率等都体现在大盘展板中，量化项目推进效果，为风险判断、后续措施提供数据支持。

最终效果

自 2022 年 6 月-12 月，幸福里离线 SLA 保障已经实现 SLA 事故天数 0、SLA 延迟天数为 0，实现“0987”高质量服务评价体系目标。除此之外，线上核心任务基线覆盖率达到 97.4%（较项目启动前提升 63%）、电话报警量较项目启动前降低 28.4%，大大降低运维成本，保证数据稳定性。

火山引擎 DataLeap 不仅解决了离线 SLA 保障的燃眉之急，更为幸福里团队形成了一套标准流程和规范。在事前，使用申报流程，规范 SLA 签署；在事中，完善报警及时性和准确性，降低误报率；在事后，及时跟踪报警情况，完善问题复盘及监控机制，沉淀公共解决方案，推动幸福里 SLA 治理健康、可持续发展。

数据质量实施过程

点击跳转大数据研发治理套件 DataLeap了解更多