滴滴数据分级保障实践

一、背景

滴滴是一家强数据驱动型公司，在业务高速发展的过程中，数据保障方面的压力与日俱增。我们遇到了很多也许你也经历过或正在经历的问题:

A. 资源不足，优先保障谁？

B. 系统异常，凌晨接到很多计算任务报警，优先处理哪个？

C. 业务数据要做成本优化，不同数据的生命周期如何设置？

D. 业务研发系统生产的日志越来越多，频繁升级过程中如何避免重要数据出问题？

E. 如何在数据开发规范和业务支撑效率之间作平衡？

F. …

面临这些决策难题，我们的解决方案是对公司数据作全链路的分级保障。

二、分级

1、制定数据分级标准

数据分级保障首先面临的问题是数据如何进行分级？

我们选择站在数据所触达用户的角度来评估数据的重要级别。

以下为数据分级标准初稿：

我们首先选择在一条业务线进行试点，分析师同学从经验角度对业务指标一一标注了级别。然而，标注结果与预期相反，T1、T2 和 T3 的指标分布居然是倒三角形，用户潜意识认为大部分自己用过的指标都需要高优保障。怎样科学合理的识别出重要数据呢？我们最终与分析师达成一致，用数据说话，对业务数据的访问情况进行详细统计，依据对业务的影响力作分级。通过新的方式划分，最终 T1 加 T2 的数量占比 30%，覆盖 80%的业务访问需求，至此，分级保障才真正变为可行。

试点成功后，我们沉淀了一套科学合理、可落地执行的数据分级标准：

2、数据级别全链路打通

数据全链路涵盖数据需求、数据生产、数据通道、数据加工等环节，涉及团队有数据分析、业务研发、DBA、运维、数据架构、数据仓库等，对于不同环节的同学来讲数据存在的实体是不一样的

在确定数据分级标准后，如何打通数据链路不同环节、不同角色、不同实体的数据级别成为最迫切的事情。好在滴滴数据链路各团队在 2017 年的数据治理实践中已经形成了一个虚拟的联合架构组，经过数轮讨论，最终确定了数据级别打通的技术方案。如下图。

数据级别通过 Hive 表、API 方式提供查询、系统间调用等不同场景的需求。

三、 分级保障

1、保障案例

数据级别打通后，我们在做稳定性保障中所面临的很多棘手问题立马变得可解，下面看两个例子。

A. 集群资源分配问题

a) 背景：集群资源的扩容跟不上产品线 A 的业务增长速度，当集群负载过大，各团队还在竞争资源时，如何确定资源倾斜的优先级？

b) 解决方案

i. 各团队按照统一的分级标准确认数据级别

ii. 调度系统根据数据级别判断计算任务优先 级，使得 T1、T2 级任务可以优先提交集群计算

iii. 不同级别任务拆分计算队列，优先保障 T1、T2 级任务的计算队列。

iv. 根据数据级别设置报警级别，T1、T2 级数据和任务相关异常会触发电话报警

B. 核心数据备份问题

a) 背景：公司针对不同重要级别的数据规划有多级备份保障策略，各业务人工梳理出重要数据的 List 非常耗时、容易遗漏，而且相关工作定期就要重复做一次。

b) 解决方案：在分级保障项目中，每份数据的级别都是结构化存储的，可将备份策略做成系统级打通。

2、Check List

由于数据链路很长，如何让不同环节的同学一体化开展保障工作是接下来要面临的一大难题。 我们的解决方案是基于整体协作流程，制定全盘 Check List 项，不同环节的同学以此为基础进行细化、完善，让分级保障能够在各环节执行一致。

3、工具建设

在管理角度想清楚如何进行分级保障后，从落地执行角度来看最好的方式肯定是让机器来承担大部分工作，我们做了产品工具侧的打通。

工具侧的打通如下图：

4、保障能力度量体系

在此之前，公司的数据保障能力一般是根据具体发生的数据事故数来全盘评估。通过分级的制定以及在产品层面的打通，使得数据保障能力可以在事前、事中、事后进行全方位的量化评估，可以给每一环节的工作规划提供可靠参考。

5、整体框架

以下是滴滴数据分级保障体系的整体框架，在管理侧是分级的流程规范和稳定性保障支撑，在技术侧是工具层面的打通支持以及持续的优化升级。

四、总结

数据分级保障所要达成的目标是为数据管理中所面临的各种问题打开一扇窗，将数据链路上的人和事串联在一起，让机器代替人工变为可行。

本文转载自公众号滴滴技术（ID：didi_tech）。

原文链接：

https://mp.weixin.qq.com/s/8smSckeCOg7v84z7jdTxSw