从“13天”到“0天”延时，揭秘幸福里离线SLA保障最佳实践

 更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【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了解更多