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

大数据数据中台数据安全

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

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

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

picture.image

在抖音集团内部广泛应用“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的达成。

picture.image

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

picture.image

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

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

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

picture.image

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

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

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

picture.image

数据质量整体策略

第三步:量化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治理健康、可持续发展。

picture.image

数据质量实施过程

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

94
0
0
0
相关产品
评论
未登录
看完啦,登录分享一下感受吧~
暂无评论