| 编辑推荐: |
本文介绍了是如何对腾讯游戏元数据管理进行设计和构建的,构建数据质量体系的过程并探讨如何去做数据的生命周期管理，请阅读下文了解更多。
本文来自腾讯技术工程官方号，由火龙果软件Alice编辑、推荐。 |
|
数据是资产的概念已经成为行业共识。然而现实中，对数据资产的管理和应用尚处于摸索阶段，企业数据资产管理面临价值评估难、数据标准混乱、数据质量不高、数据安全威胁等诸多挑战。互娱从2013年开始启动此项工作，历经从数据管理到治理，再到资产化的转变。自年初起，我们启动实施大数据资产管理体系的建设，本文分享在此过程中的一些实践经验与思路。
数据资产管理（DAM，Data Asset Management）是指规划、控制和提供数据及信息资产的一组业务职能，包括开发、执行和监督有关数据的计划、政策、方案、项目、流程、方法和程序，从而控制、保护、交付和提高数据资产的价值。--来源《数据资产管理实践白皮书3.0》，即通过流程、制度、技术等手段，去提升数据升值能力，助力产品成功，最终提升企业的竞争力。
数据资产管理的定位及架构如上图所示，其处于大数据平台（中台）与数据应用的中间层，连接着底层的大数据平台（中台），覆盖数据全生命周期管理，同时为上层数据应用提供高质量数据的保障能力。
一、 腾讯游戏大数据运营概况
目前我们互娱增值服务部服务于50+款端游，40+款页游，还有300+多款手游，每日数据量级为17000亿条，每日数据增量约为260TB，总存储是80PB的规模。技术栈是使用自研结合开源的混合模式，采用了TEG数平的TDW（腾讯大数据仓库）来构建离线数据的计算与存储，结合自研的高性能分布式计算Bitmap技术实现多维、下钻分析。
对于具体的数据服务场景，相信大家对上图这些界面不会感到陌生。图中只是我们数据增值服务的部分呈现，包括玩家在游戏里面的历程、对战的战绩信息、个人中心、社区交友、任务系统等服务。其中，任务系统是基于我们实时能力构建起来的一个数据应用。
除此之外，我们还面向IEG内部的游戏AI、游戏反外挂系统、铁算盘、游戏助手、渠道管理等提供数据服务。
二、腾讯游戏数据资产管理体系介绍
腾讯游戏数据资产管理体系如上图所示自下而上主要分为元数据管理、资产管理四大核心组成、资产管理平台以及数据增值服务等四个层次。
最底层是元数据管理。元数据在整个资产管理体系中是最核心的一个部件。我们会定制实现整个元数据的标准化，存储的数据包含业务元数据、技术元数据，提供元数据的检索、开放等能力。
往上一层便是资产管理四大核心部分：
1、价值评估，我们定义出用于评估整个数据价值的评估模型以及数据度量报告，我们认为这是资产管理中最核心的一个点，可以协助决策者清楚了解数据的价值在哪里，到底有多大。
2、数据运营，其覆盖了整个数据生命周期管理，包含数据的安全、质量、成本等部分，我们也采用了DevOps和AIOps这些业界先进理念贯穿整个数据运营过程，参与这个职能的角色我们也叫DataOps。
3、数据治理，此概念更多强调的是数据标准化、制度、流程等这一系列的内容。这里不详细展开。
4、数据集成，从数据的采集、传输、整合、到落地存储，通过标准化去统一不同类型、格式的数据源，按指定规范去实施转换，并最终落地至统一的大数据仓库，且访问数据采用统一标准，这里采用的是TDW提供的方案。
最上层为资产平台能力。研发的思路遵循《数据资产管理实践白皮书3.0》，并结合我们的服务场景，提供多样及个性化的数据资产管理服务。最顶层则为我们提供的数据增值服务，比如我们提供数据可视化与分析、营销活动的支持、消息推送、渠道管理等一系列服务。以上便是我们数据资产管理的技术体系架构。
针对如何去评判我们整个资产管理建设的能力水平这个问题，我们总结出“三好”能力模型。首先是“用好”数据资产，二是“管好”数据资产，三是“看好”数据资产。
其中“看好” 资产属于数据安全的范畴。数据是企业里面的核心资产，也涉及了数据泄露与用户隐私等问题，一旦发生数据安全事件，对公司的损失是巨大的，甚至是灾难性的，所以我们认为“看好”
资产是重中之重。践行“三好”能力模型的过程中，我们会根据不同的角色去定义并提供相应的服务能力，我们内部资产管理平台研发与设计也是基于此评估模型。
三、腾讯游戏元数据管理介绍
元数据管理在整个数据资产管理中占有举足轻重的地位，接下来介绍我们是如何对其进行设计和构建的。首先它要具备以下几个能力特点：
1、数据的异构适配和集中存储。随着公司历经不同的发展阶段，必然会出现多种多样的技术栈，则不可避免的产生各式各样的数据类型，比如说关系型、NoSQL类型，还有一些文本的，一些业务接口、业务系统等。怎样去采集并且适配如此之多的数据类型，怎样去描述和定义数据，其难度是非常大的，因此我们定义了一个适配层，此做法和业界主流方案有些类似。具体我们构建了一个模型桥接器来实现智能转换，去适配异构和集中存储。
2、元数据到底存储了什么数据？举个例子，游戏行业是有很多指标去衡量它的运营状态。比如说7日留存率，意思是说这个玩家注册当天往后去推移7天有没有流失，有些业务平台是按注册后第二天才开始计算，这样同一个指标大家就理解不一样，自然导致计算结果不一致。所以我们将游戏内部累计两、三千个业务指标，连同它的计算逻辑等描述都存储到元数据里面去，然后再开放给所有的业务平台。比如DataMore（智能游戏运营方案）、图灵（数据挖掘分析平台），一体化（游戏指标开发平台）等内部平台，大家都采用一套标准，包括指标名称及计算逻辑，这样便可有效避免数据不一致的情况。
3、描述数据，其为元数据的本质，在元数据管理中发挥核心作用。我们会定义数据的来源，包括责任人，创建与更新时间，分区号及数据字典等一系列的描述信息，以及表与表之间的关系等。通过数据描述模型，数据使用者可以看到整个数据的全景以及数据的描述信息，可大大降低其使用数据的成本，最大化利用数据的能力，协助产品做精细化的运营，更好地完成运营KPI。
4、自动构建血缘关系链，这是一个非常重要的考核指标，后面会详细讲解。
5、扩展能力，辅助运营。元数据不仅包括业务的元数据，还包括技术的元数据、运维日常工作过程当产生的告警指标及阀值，甚至是AIOps模型的算法等，都会统统存储至元数据中，以辅助我们做好运营，提供运营策略支持。
以上是我们元数据构建的一些特点。
以上是某游戏元数据管理功能截图，包含一个数据全景及数据属性描述的功能，可以清晰看到数据责任人归属、创建时间、最后变更时间，它的表结构、字段、信息等信息，这些信息对数据的使用者而言都是非常有用的。
四、 腾讯游戏数据质量管理介绍
下面介绍我们构建数据质量体系的过程。不合格、不具备交付价值的数据则为垃圾数据，所以数据质量的保障是一个核心点。数据质量体系的构建分为以下四个步骤：
第一，定义数据的标准，包括它的格式、类型以及上报模式等均需统一标准化。我们内部通过制定好的标准去约束，比如定义一张数据表的描述，包含数据类型，表名称，字段类型与长度等，研发人员则根据此格式打日志，标准贯穿采集、传输、转换、存储全链路。
第二，定义质量规则。此部分同业界一致，我们也采用完整性、一致性、准确性及延时性等监控维度。具体介绍如下：
1、“完整性”，比较好理解，即数据不能缺失，不能出现“采集一万落地八千”的不合格情况，此指标我们采用数据对账的方式去做数据验证。
2、“一致性”，相当于数据定义的标准化，意思是怎么让内部所有人按照指定规则去理解数据，且涵盖各个技术平台、业务线系统。比如我们定义一个ipv4的IP地址是15位，定义手机号码为13位的或者国内的邮编地址为6位，这个理解上大家肯定是统一的，我们也会将这个标准存储到元数据里面去，各业务平台一起去遵循这个标准。最终达成一致性。
3、“准确性”，数据中避免出现乱码或者不是预设类型的值。
4、“及时性”，从数据的采集到数据应用，它的时效性是否满足业务的需求，比如正常打完一个对局时会收到系统推送的一条消息，内容可能是一个道具或一个金币，这个及时性要求是非常高的，绝不允许出现对局完成后两个小时再把金币推送出去，这就没有意义了。这是一项非常重要的数据质量考核指标，对应用层面的影响也是非常敏感的。
第三，质量监控。定义完这些规则和标准后，接下来便是质量监控，包括对帐、心跳、内容检查还有延迟告警等相应的保障。
第四，质量报告。我们会给产品侧输出整体数据质量的趋势报告，包括同比、环比及各个质量维度的达标率情况等，目前数据交付的质量都维持在三个九。
总结来说就是通过业务+流程+技术的手段来实现数据质量的总体保障。
五、大数据资产管理之影响评估&快速定位
上图为一个非常典型的数据实时微服务的架构，从开始的采集到传输，再到离线的计算和存储，还有一条实时分支做数据的转发、透传、会涉及到消息队列以及流式计算，然后将数据的结果写到Tredis（NoSQL）中。写到NoSQL中的数据，来源可能是实时计算或者离线计算任务。研发人员会根据业务规则开发接口逻辑，调用数据存储层，接下来研发会将接口交付至运维人员，进入完整的DevOps全链路，最终完成整个数据+业务逻辑的发布。整个应用过程会遇到几点问题：
第一点是整个数据服务涉及到的环节众多，只要其中一个环节出问题，故障的定位就非常困难。
第二点是业务层的数据异常回溯，难度更大。比如一个玩家看到战报数据，正常的话应该是20级，结果显示8级，如何快速确认数据从哪算的，经过哪个环节，属于哪个业务逻辑、哪个项目、哪个逻辑指标以及哪个计算服务集群等。
第三点就是底层数据平台故障，如何快速评估影响面。比如当离线计算平台其中一个集群挂了，如何确认影响哪个项目、哪个接口、哪些指标、哪些功能，也无从去判断跟定位。这里给出的解决方案是通过“数据”加“业务”的血缘组合来解决。
见上图，我们的血缘数据贯穿从数据采集开始到最终的数据服务整个链路。首先将采集的粒度细到IP、端口与进程，业务表ID、计算的任务ID、透传的表ID、计算业务指标以及Tredis里面的Key前缀，最终交付给接口的业务ID以及集群的ID，均上报至血缘数据库。此时整个解决问题思路清晰可见，无论从上往下还是从下至上，均可轻易地实现问题的快速定位以及影响面的快速评估。
上图为平台截图，是一张普通业务的血缘关系图。从关系图中我们可以快速了解数据从采集到应用中的全部处理过程，知道其部署资源信息、接口信息以及指标信息等。具备这些能力之后，则可运用其有效辅助运营。如，当一个计算任务出库出现延迟，运维人员通过血缘监控可快速知悉此延迟可能会影响的项目、接口以及相应具体指标，且可快速启动故障预案，如跟产品沟通，采取挂公告或补偿性的动作等预案策略。
六、大数据资产之生命周期管理
下面探讨如何去做数据的生命周期管理，首先给出一个结论：数据生命周期管理的策略与数据的在线度有关。
数据在线度即为数据的活跃度，其随时间推移，数据使用价值的降低不断衰减，用于数据的在线程度和使用衰减情况。数据在线度主要受两个方面因素影响：
第一， 其跟定义数据的重要级别有关系，我们共定义了“收入类”、“流水类”、“在线类”、“行为类”和“性能类”等。其中，“收入类”和“流水类”的重要级别比较高，故而打上四星或者五星的标签。相应的，“行为类”或运维监控日志，重要级别则相对没有那么高，为其打上一星或两星的标签。数据的重要级别由运营人员根据运营经验定义。
第二，数据的价值，主要参考数据的热度和数据的广度。
数据在线度的关联函数我们定义为：
其中V(t)为数据访问热度，W(t)为应用广度， I为数据重要等级。
七、数据价值评估思路“三度”模型
接下来介绍我们做资产价值评估的过程和方案。我们从三年前尝试做这个事情，经历了两个阶段，第一阶段是数据的成熟期，第二是研究的观察期，目前处于灰度放量阶段。
在数据价值评估具体实施方面，我们提出了从“热度”、“广度”、“收益度”等三个维度，按照价值指标、评估模型、价值表现等三大评价流程进行价值评估的架构思路。
其中，关于数据的“热度”，我们内部有一个共识，就是“只有当数据被使用了才有可能产生价值”，当然这是一个很笼统的说法。第二就是“广度”，举个例子，比如我们在国际某个机构去发布一个专利，结果发现谷歌也引用了、亚马逊也引用了，Facebook和其他国内的公司也引用了，我们就认为这个专利是有价值的，这个理论相信不少人会认同，同样我们在内部也是采用这样的思路，“广度”依赖的是我们的数据应用及功能模块，只要跟数据耦合程度越高，我们就认为它的广度就越大。第三就是“收益度”，即数据干预之后带来多大的收益，比如带来多少活跃用户、UV、PV、流水等，这些数据直接上报给平台，通过平台去做模型评估，加上每个价值点权重去计算。这里我们通过A/B
Test方案去做整个模型的训练。
做资产管理价值评估需经过三个阶段，第一是做指标的采集，第二阶段是做评估模型的定制，最后一个阶段就是价值的表现。我们会在平台上看它的整个分数区间分布。下图为某个业务的热度跟广度表现趋势的情况。
最后总结一下做数据资产评估的意义。
数据资产评估是衡量投入产出比的重要依据。通常我们希望 “价值产出”能做到无限放大，同时我们又希望成本能越小越好、甚至没有。成本核算的方法主流有“成本法”和“价值法”。其中，“成本法”是以数据成本来结算数据服务，“价值法”则认为数据服务的结算定价应该跟成本无关，跟价值有关。具体选择因场景而定。如我们服务的是IEG内部用户，数据服务结算的方式采用的是“成本法”，我们的目标是要助力产品成功，应尽可能帮助业务减少成本与支出，这样的方式可以很好提升产品的竞争力。对于面向toB、toC或toG的业务场景，这时候用价值法也是合理的，因为这样的机制有益于企业利益的最大化。
以上是在腾讯游戏实施数据资产管理整个历程的一些思路，供大家参考与借鉴。中间磕磕碰碰，也引用与总结了业界现有的概念和思路。也感谢TEG数据平台部给予我们专业的数据服务。一句话总结一下，我们还在路上，希望与大家一起共勉，谢谢大家。
|
