最具影响力的数字化技术在线社区

168大数据

 找回密码
 立即注册

QQ登录

只需一步,快速开始

1 2 3 4 5
开启左侧

[实践案例] 腾讯:腾讯游戏数据质量管理实践

[复制链接]
发表于 2019-9-25 18:00:39 | 显示全部楼层 |阅读模式

马上注册,结交更多数据大咖,获取更多知识干货,轻松玩转大数据

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
本文根据刘天斯先生在【DQMIS 2019第三届数据质量管理国际峰会】现场演讲内容整理而成。来源:数据质量管理智库

640.jpg
图1.1  腾讯游戏大数据管理负责人--刘天斯

演讲嘉宾介绍 - 刘天斯


  • 腾讯游戏大数据管理负责人;
  • 开放运维联盟(OOPSA)大数据顾问组成员及金牌作者、华章最有价值作者、中国十大杰出IT博主、WOT十大优秀讲师、OpsWorld金牌讲师、TOP100优秀出品人;
  • 从事互联网技术运营工作近15年,曾参与国家《数据资产管理实践白皮书(4.0版)》标准编写;
  • 热衷开源技术的研究,包括大数据资产管理及云计算、Kubernetes、AIOps、Docker、DevOps等领域,擅长大数据治理及大规模集群的运维工作,尤其在自动化运维方面有着非常丰富的经验;

  • 并积极关注互联网前沿技术的研究,活跃在国内社区、业界技术大会,充当一名开源技术的传播与分享者,曾发表个人著作《python自动化运维:技术与实践》、《循序渐进学Docker》,个人发明专利6个。



演讲目录


  • 腾讯游戏大数据运营概况
  • 面临问题与痛点
  • 数据质量体系架构

  • 总结



刘天斯:各位领导、各位专家,以及各位来宾,大家下午好!首先感谢组委会的邀请,让我有机会过来跟大家一起探讨数据质量这个话题。我今天带来的分享主题是腾讯游戏大数据质量的实践案例。

我叫刘天斯,从事互联网行业15年,现在是腾讯游戏大数据管理负责人。

图1.2

图中为整个腾讯游戏当前的业务运营数据,目前我们服务了500多款的端游、手游以及页游。这么多款游戏,日传输约17000亿流水,每日260TB的数据增量,以及100PB+的存储量级,占整个集团约26%的规模。

我们在做整个数据管控的过程中,在数据质量这块也面临了诸多的困难和挑战,这里罗列的比较多,我简单总结三点:

图1.3

第一点,数据标准不一致,就导致我们在做数据集成的时候难度特别大,因为每个业务线都有自己的日志规范,或者是习惯,我们要去适配它的时候,往往针对不同的格式要做特性的适配,一开始还能吃得消,但是慢慢随着时间的推移,带来的问题和挑战也越来越多。

第二点,业务的理解不一致,我们相同的指标大家理解的不太一样,可能计算出来的结果往往出现这样一个差异。我们服务的组件众多,体量大,在这个背景之下,我们要做数据质量的管控,发现质量的问题,这也是一个很大的挑战。

第三点,我们服务的数据链路很长,大数据异常的时候,我们如何快速的发现问题,以及定位问题,这个也是我们面临的一个难点。

基于以上的难点,经过6年时间,我们分为以下四个阶段来解决:

图1.4

第一阶段,统一职能。在整个职能里面,数据孤岛慢慢的在形成,所以我们必须要做整体调整,每个业务线数据的上报,或者对接的协议,我们都必须要做统一的管理,以便于我们现在把这块的数据接入工作全部收归到当前的数据中心下面,这是我们第一阶段解决的问题。

第二阶段,数据的标准与集成。这个阶段我们定制了内部的标准,要求我们各个业务线必须按我们的标准和协议来对接上报,如果是针对异构类型的数据,要求必须按我们的标准先做转化,转化之后才能上报。

第三个阶段,数据质量体系的建设。这个阶段,我们前面提到了数据的组件非常多,链路很长,必须要构建一个非常完备的数据质量体系来保障整个数据交互的顺畅。因此我们就围绕着数据的完整度、准确性、一致性展开数据质量体系的建设工作。

四个阶段,构建血缘体系。我们数据链路长,出现异常的时候很难定位问题,因此我们通过构建数据血缘和业务血缘的组合来提升发现问题的能力。

总结一下,我们针对数据质量的管理思路就是不断的去提高发现问题、分析问题以及解决问题的能力。当然我们最终追求的是提前规避问题,这也是最难的,能够做到这一点,也是我们追求的目标。再通过流程、制度,还有技术等手段,提升我们数据交互的总体质量,帮助业务去提升它的竞争力。

图1.5

这是我们总体数据质量建设的体系图。我们从底下往上看,最底层跟上午嘉宾介绍的类似,我们还是以元数据管理作为一个非常核心非常重要的基点,其中我们定义了元数据的标准、提供了元数据的分类、存储以及开放等能力。

再往上走,我们可以看到刚才提到的,我们分为四个阶段解决问题,涵盖了数据的集成、数据的标准化,还有整个监控体系的建设。我们也引用了AI的能力,来辅助我们做这个领域的体系建设。最后一个就是血缘关系链的构建。

再往上走就是我们这个平台各式各样的报表、质量报告、分析报告、预测的报告,优化的策略等等,这是我们平台的能力。

最上层则面向我们真正服务的对象,比如我们的效果分析、活动营销、消息推送等等。

图1.6

接下来介绍一下我们是如何管理元数据的。元数据本身是一个小数据,它不是大数据,元数据本身就是描述数据的数据。元数据的分类我们跟业界是一致的,根据服务对象及其相应存储数据的特点来进行划分,目前分为业务元数据和技术元数据。

业务元数据更多的是面向我们的业务侧,比如我们的产品策划、产品负责人、制作人等。他们可以看到整个数据的结构、业务指标的说明等,这些我们全部归类到业务元数据中。

技术元数据也是这么分类的,主要面向我们的开发人员、运维人员、测试人员,涵盖了我们的信息、网络的分布、模型数据的参数,以及一些技术指标等。

我们整个元数据的结构体系,大家可以看这张图,我们也是从底下往上看。

图1.7

最底层为各类异构数据源,那这个异构数据源怎么产生的?也是随着我们整个企业技术栈的不断演变,就会出现各种各样数据库的类型,这也是一个正常的现象,比如有关系型的,接口、文本、外部接口、业务系统,如此等等各种异构数据。我们设计之初,就考虑要适配这些异构数据,因此我们设计了一个模型桥接器,完成各类异构数据源的元数据信息的适配转换。

适配之后,则进入元数据的采集与存储阶段,存储之前我们会做简单的分类,分类的类别则为前面提到的技术元数据和业务元数据。存储之后,则进入使用的阶段,因为数据如果没有被使用,数据就没有价值,所以一定要发挥数据的价值,把它用起来。同样,元数据也是这个道理,我们会做元数据的开放,如图所示,我们会面向实时系统、iData系统等应用,实现共享元数据。

什么叫共享元数据?比如,游戏里面有一个指标,叫七日留存率,在这个指标里面,刚开始的时候有些数据分析人员或者一些平台认为这个数据应该从用户注册当天开始计算,有些平台说应该从注册之后隔一天计算,这样第二天老板看报表的时候就傻眼了,我在A平台看到的数据长这个样子,B平台看到的数据是另一个样子,所以比较困惑。因此我们在这个位置就体现出元数据的优势,我们会定义T,就是这个元数据的一个名称,Y就是元数据的逻辑定义,有可能是计算的公式,也有可能是一段代码。通过共享元数据,我们所有平台引用该指标的时候就可以保持一致,有效避免出现我刚才提到的指标不一致,结果不一样的情况。

再往上则为我们元数据的应用了,如元数据检索、数据一体化、质量监控、资源管理等应用,元数据开放的时候也会尽可能跟所有应用平台对接。

我们还做了一些尝试,通过元数据的能力去辅助运营。我等会会讲到这个案例,这里先卖个关子。

图1.8

上图为我们的数据目录视图。这个对用户来讲有什么价值?比如说我们对普通的数据使用者而言,他能够迅速感知到,我到底有哪些数据?数据存储在哪里?数据长什么样子?它的体量有多大?它运营的信息是怎样的?当然还有下面很多,就是能够知道它数据用的怎么样?或者真正能够给用户带来哪些好处?都会通过报表可视化的方式呈现出来。

比如作为一个数据使用者,我要去用数据的话,我必须要关注这个数据的责任人是谁?它是什么时候创建的?什么时候更新的?这个表结构是什么样子的?因为我要用它的话,我不了解它这些信息没法去用,这样的话,数据也不能发挥它的价值出来。这也是元数据很典型的一个应用场景。

图1.9

下面介绍下我们如何做数据的集成,图中为我们的采集架构。我们的数据源分为两类,一类是客户端的,直接上报。第二类是服务器端的对接。对接目前支持的协议还是比较丰富的,包括UDP、TCP、HTTP等协议。服务器端也比较丰富,如RPC、FileI/O、KCP等。数据会先落到临时的存储区,它可以帮助我们做数据的补录与修复,这是第一个好处。第二个好处是可以做布道。第三个好处是可以做实时的检索。从多个维度去考虑,从成本的因素,我们检索文件就可以了,而且能够快速返回。我们有没有这样的经验,我们跟研发人员做对接和沟通的时候,研发人他们更倾向于原始的状态日志,而不是其他人给他做各式各样的可视化,把日志搞的很漂亮,各种报表,他不希望看到这种,他看到的是原状,包括颜色背景,开发人员还是有情节的,我们这一点就很好的去满足他这个需求,基于文件的方式落地。再下一个步骤的话,就是数据传输的通道,真正的进入数据仓库了。

右侧为我们服务的能力,包括我们单机的能力,吞吐量等,此处不详细展开。

前面提到过数据标准化的重要性,我们在实际场景中做标准化的时候如何实施,如何设计,思考的方向是怎么样的?这里我简单的介绍,主要分为两点:
一是数据标准服务,二是数据标准管理。

图1.10

数据标准管理过程中,考虑更多的流程、规范、制度,以及维护这个标准是否具备可持续性,是否可以不断迭代的,这个很关键。如图所示,则为我们的数据标准服务,更多贴近我们技术层面的东西,比如说里面含有数据项标准和指标项标准两种类别,其中数据项标准含业务属性、技术属性、管理属性。

举例说明,如对于业务属性,业务上报时,数据长什么样子?比如说结构是什么样子的?如对于技术属性,就是你上报的格式是什么样子?到底是日志的格式?还是其他格式?对于管理属性更多的是强调我们在未来怎么做变更,或者迭代新版本的时候,如何对接这个协议,这部分更多是强调这个点。

指标则更好理解,即指标的命名、指标值域以及生成逻辑等。其中较为关键的则为指标的值域,如“1”代表QQ的渠道,“0”代表微信的渠道,最终保证整个数据的一致性。

对于应用侧而言,提供一个易懂的标准描述方式,如XML格式,用于描述整个表的结构说明、字段等。用户需要做变更时,实施图中右下角的接入流程即可。如此,整个流程就形成一个闭环。

我们实施数据标准是通过在源头处解决部分质量的问题,即标准不一致带来的数据问题,只能解决源头部分的数据质量问题。但我们整个数据服务的全链路周期性是很长的,即依赖数据标准不能解决往后这一段的质量问题。我们要保证整个数据交互的质量,势必要覆盖整个数据流转或者是服务的生命周期,这涵盖了采集、传输、计算、存储,以及最终的应用。

图1.11

我们的思路是在每一个层级都有相应的监控覆盖,实现无死角的监控。如图所示,高亮的部分是每个阶段我们最在意的部分。举个例子,我们数据采集的时候我们更在意它的对账问题;到最终数据应用的时候,我们更在意它整个应用全链路的链路跟踪,尤其在微服务里面这是最关键的。我们的数据质量保障工作围绕着数据完整度、一致性、准确率、及时性展开。

图1.12

如图中例子所示,虽然整个链路的质量都覆盖了,但是面临新的挑战问题。如右侧的这个微服务架构图,为我们的流式计算服务流程图,从数据的起点到最终的应用,中间经过的环节是非常多的。如从采集到传输,传输结束后,分两条路,一条路会进入数据透传,另外一条路会进入离线存储,其上层还有微服务的框架,提供数据应用服务。整个链路这么长,问题就会出来了。

服务节点非常多,任何一个环节出问题如何做到快速定位?第二个挑战点是我们数据应用出现故障,回溯数据的问题也有很大难度。举一个例子,比如我们做王者荣耀战绩查询的时候,一个玩家反馈他的战绩是12级,为什么查出来是8级,是不对的,我们就要有这样一种机制去响应这个反馈,如何快速知道这个指标是怎么来的?他到底是走哪一个接口?走哪个计算?走哪个集群?它的模型是哪个?如果没用这种解决方案的话,很难定位问题。

第三个挑战是我们的数据平台出现异常了,如何快速响应?同样也是以这个例子来说,比如我们消息队列,A集群出现故障了,我们如何快速告诉管理员,告诉他们到底影响了哪些项目,影响了哪些接口,影响了哪些指标,如果我们没有很好的机制的话,我无从查起,只能看到英雄联盟的有故障,谈到王者荣耀有故障,这么多业务有故障了,不能快速评估出来我到底影响了哪些用户,影响了哪些指标。

因此我们给出了一个方案,这里分了五个层级,事实上我们采集了整个数据流向的这五个层级之间,每个层级之间上下游的关系,这里当然涵盖了数据+业务的血缘,然后就会构建一个非常完备的血缘关系链,数据层、业务层全部串起来,这样采集完之后,我们就可以看到,有了这个数据就可以做可视化了,它都把整个网状或者竖状都呈现出来,这是可视化方面的应用。

图1.13

更有价值的一点,就是把它应用到质量这块,质量监控。当业务人员收到告警马上可以知晓,这些故障影响到哪些接口,哪些应用,哪些项目,哪些指标,提前跟业务做沟通,提前告知,如果这个问题不能够短期内解决的话,业务要挂公告,挂公告我们要告诉他具体影响哪个业务,因为每个业务载体不一样的。如果是王者荣耀的话,登录的时候弹一个弹窗,你必须精准的判断到底影响了哪些业务,因为指标直接影响到你应用里面的哪些窗口点,因此游戏的策划也是可以精准的去跟业务做准确的解释。

接下来这个案例更多的是强调,我们通过技术元数据去驱动计算资源的动态调度。先简单介绍下项目背景,因为我们整个互动娱乐事业群共享一个大的计算仓库。但是业务的发布,或者发版本都有其周期,或者是我们的数据分析需求也有各自的规律。这样势必会造成一个后果,就是整个hadoop集群的计算资源利用率偏低,据统计,优化前整年的资源利用率只有58%左右,是偏低的。

图1.14

如图所示,集群计算资源使用存在空闲时段,并且两个资源池相互错峰,如何解决这个问题?我刚刚已经抛出答案了,我们直接看解决思路。

图1.15

如图所示为我们的第一个模型,首先必须有上限跟下限的保障,即资源调度的期间保证上限跟下限。同时我们这里有一个预测的基线,这个模型最终的目的就是通过预测的基线去修正当前的参考值,当前参考值就是hadoop里面系统给出来的参考值,但是我们通过预测的手段更贴近业务的方式去修正这个参考值。

我们具体怎么做呢?首先我们是采集历史的15个点-20个点,比如现在是2点10分,我们采昨天的2点10分和前天的2点10分这个历史数据,看这15-20个历史数据的变化,它无非有三种特征:
  • 它可能是按天的变化,我们就直接采用均值法。
  • 如果它是按天的增长趋势,每天都增长,我们就直接获取它增长趋势的变化。
  • 存在波动性的样本,它有大的波动点,我们会采用聚类算法,寻找最大的一个值限点,把一些毛刺或者是异常给抛开。


我们会看这三种算法哪一种最适合它?哪一种数据的效果最好,我们就会采用哪种。

这一步完成之后,第二步进行真正的分配,我们会拿预测的这个值,放到实际分配的大层面,主要算它所占的比例,这样的话可以得出它应该在下一个点的时候,提前去分配多少资源。这样这个模型就有一个很好的特点了,包括上下限的保护,包括刚刚前面提到了,我们不会扩容也不会缩容,因为很多时候都是在月初,或者每个月的31号晚上,大家都会进入前面半年整个密集的时间点,所以这时候我们不会做相应的操作的。

图1.16

第三,动态分配之后,下一个需求点需要的资源数我们提前告诉你,提前分配给你,所以基本上是针对它的需求点进行推荐,非常精准。这样的话,我们为整个集群提升了52%以上,这还不是最新的数据,因为整个算法我们也在不断的去迭代调优。然后所有资源都会得到按需的分配,大家可以看到前后的对比,很明显。

整个时间窗口做了精准的推荐,这是一个特性支持。空闲资源也得到了充分的盘活,因为整个集群的资源都盘活了,资源消费能力肯定是快的。因此我们的计算任务从平均27.5分钟,下降到大概8分钟就交付结果了。这是我们通过技术元数据去驱动在线应用的案例。

最后做个简单的总结,前面提到的我们数据质量管理实践的四个阶段:
  • 统一服务意识,在这个阶段我们避免了数据孤岛的问题。
  • 数据标准与集成,我们从源头去规避数字质量的问题。
  • 监控体系建设,在过程中发现数据质量的问题。
  • 构建血缘体系,定位并解决数据质量的问题。


好,我的分享到此结束,谢谢!


楼主热帖
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

关于我们|小黑屋|Archiver|168大数据 ( 京ICP备14035423号|申请友情链接

GMT+8, 2024-3-29 07:19

Powered by BI168大数据社区

© 2012-2014 168大数据

快速回复 返回顶部 返回列表