腾讯游戏大数据管理负责人刘天斯：大数据资产管理在腾讯游戏的实践
来源：中国IDC圈
2018 年 12 月 13 日，2018 数据资产管理大会在北京国家会议中心举行。会腾讯游戏大数据管理负责人、高级工程师刘天斯发表了 “大数据资产管理在腾讯游戏的实践” 的演讲，以下为演讲实录：
腾讯游戏大数据管理负责人、高级工程师刘天斯
今天跟大家探讨的是大数据资产管理在整个腾讯游戏的一个实践，在正式开始之前，来一个简单的自我介绍，我叫刘天斯，目前就职于腾讯互动娱乐，负责大数据管理，右边是我个人的两本著作，大家有兴趣的话可以关注一下。
最近一段时间我比较关注大数据管理还有云计算、包括 DevOps 和 AIOps 领域，如果大家有一样的兴趣点，可以扫码微信，我们可以做深入探讨和交流。
开始之前，我们先了解一下整个腾讯游戏概况，我们的体量大家可以简单看一下，现在我们服务 100 款端游，90 款页游，还有 300 多款手游，每天的量级是 17000 亿条，每天增量大概是 260TB，总的存储是 80P。我们采用的基础架构还是基于这样的资源、开源这样一个混合的方式，从立足我们的 TDW，同样我们通过自研的方式，通过 Bitmap 这样的技术进行多元分析，它也是一个分布式计算的集群。
我们具体的服务场景是什么，大家对这个界面应该不会感到很陌生，如果大家也有玩腾讯游戏的话，对这样的界面应该是很熟悉的，这也算我们数据整个增值服务的一些呈现，包括玩家在游戏里面的历程、对战的战绩信息、个人中心、社区交友、任务系统，任务系统是基于我们实时能力构建起来的一个数据应用。
除此之外，对内部还有游戏的对账系统，游戏内的经济监控等一系列产品，我们整个资产管理体系这个架构图，大家可以看一下。
首先它分为几个层次，第一，最底层的元数据管理，大家知道元数据在整个资产管理是最核心的部分跟一个组件，我们会定制整个元数据的标准化，然后存储数据包含的业务元数据、技术元数据以及元数据的检索、开放等等，再往上就是资产管理，我们认为的四个核心部分，一个是增值评估，会定义跟评估整个数据价值的一个模型以及它呈现出来的数据报告，我们认为这是资产管理中非常核心的一个点。
第二个是数据的运营，这里涵盖了整个数据生命周期管理，包含数据的安全、质量、成本，同样我们也会采用 DevOps 和 AIOps 概念覆盖整个数据管理。
第三部分是数据治理，更多强调的是标准化、制度、流程等这一系列的内容。
最后一点就是数据的集成，从数据的采集、传输、整合、落地、存储，是整个生命周期管理，这里面我们涵概了从游戏上线开始一系列的标准化到最终落地整个生命周期的管理。
再往上一层就是我们的平台能力，既有的能力模型大家简单看一下，最顶层就是我们真正交给用户、交给我们内部用户的一些产品，比如我们做一些可视化的分析、营销活动的支持、消息推送、渠道管理等一系列的数据平台，这是我们整体的一个体系架构。
今天由于时间关系，我会重点抽这四点来跟大家进行探讨。（见图）。
怎么去评估我们整个资产管理建设的能力水平，我们这边基于能力模型总结出来一个 “三好”，首先我们认为你要用好数据资产，二是管好数据资产，三是看好数据资产。
“看好” 就是安全这个领域，数据是企业里面的核心资产，刚刚前面几位专家也提到了数据泄露或者出现敏感数据都被脱库了，这样对企业的损失是巨大的，甚至是灾难性的，所以我们认为看好是非常重要的一个点，所以今天我们单独把它抽出来说。我们会根据不同的职能业务定义提供相应的服务能力，相当于我们内部的平台建设都是参考这样的一个评估模型去建设的。
刚刚提到元数据的管理是非常重要的，在整个数据资产管理中是一个举足轻重的地位，我们来简单分享一下我们是怎么构建和设计的。首先我们定义好它的几个能力特点：一是它的异构适配集中存储，应用企业不同的发展阶段不同的时期肯定会出现各式各样的技术障碍，就会不可避免的会有各式各样的数据类型会随着整个企业的发展孵化出很多数据类型，比如说关系型的、NoSQL 类型的，还有一些文本的，一些业务接口、业务系统等类似的非常多，怎样去采集并且适配这么多的类型，怎么对它做描述和定义难度是非常大的，所以我们定义了一层，这个做法和业界很多方案通用性是一样的。这里面我们会构建一个模型的桥接器实现智能转换，去适配和存储。
二是元数据里面存什么数据？举个例子，大家知道游戏行业有很多指标去衡量它的运营状态。比如说留存率，正好来说这个用户注册当天往后去推移他有没有流失，就这么一个指标。有些业务注册之后第二天才会计算，这样大家就理解为不一样指标的计算结果就不一致了，所以我们也把游戏内部大概两、三千个业务指标以及它的一个逻辑描述都通过定义连接起来，存储到数据里面去，然后开放给所有的业务平台，比如说这里面看到的 DataMore、潘多拉，这都是我们的数据平台，大家都统一采用这样的指标来计算逻辑，这样的话就不会出现数据不一致的情况了。
三是描述数据，这是元数据的一个本质，也是它本身的一个作用。我们也会定义它的表的来源，包括责任是谁，最后更新时间等一系列的描述以及表跟表之间的关系，有这种业务模型的联系在里面，这样的话我们定义清楚以后，使用数据的人可以看到整个数据的全景以及数据的描述，降低数据使用的成本，他可以通过很低的成本使用数据，利用数据的能力帮他做精细化的应用，更好地完成应用的 KPI。
四是自动构建血缘关系链，这是一个非常重要的考核指标，后面我会详细地讲。
最后一点就是扩展能力，辅助我们运营。元数据不单单只是存储业务的元数据，同样也存储技术的元数据，运维过程当中的告警指标甚至是 AI 模型的算法，我们都统统存储到元数据里面去，能够辅助我们做一些应用、提供一些策略支持。
以上是我们元数据构建的一些特点。
这是一个功能截图，这是一个数据全景的功能截图，大家可以简单看一下，这是它的一个描述截图，就是定义它这个数据责任是谁，什么时候创建的，它的最后变更时间，它的表结构、字段、信息等，这些所有信息对使用而言是非常有帮助的。
接下来讲到构建质量的体系，因为刚刚几位专家提到了数据质量如果不合格、不具备交付的能力那它就是垃圾、就是没用的数据、就是垃圾数据，所以质量的保障是一个核心，我们这个方面的构建分为四个步骤：第一，我们要定义数据的标准，包括它的格式、它的类型、上报的模式，这个必须统一规范类型。这是一个截图，这是我们内部定义的一个标准格式，通过 TGlog 的方式去定义，比如定义一个表，就是这个样子，数据类型就是这样，表名字段描述都统统定义好了，研发人员根据这样的格式打日志，通过采集、传输、存储、落地这么一个过程。
第二点我们要定义这个质量的规则，这个基本上跟业界是同步的，我们会采用完整性、一致性还有准确性。完整性，比较好理解，数据不能缺失，不能采集的时候是一万行，落地的是八千行，明显是不合格的，这里面我们采用数据对账的方式去做数据的把关。一致性，相当于数据的标准，就是你怎么去理解数据，各个平台、各个业务线怎么定义数据，比如我们定义一个 IP 地址肯定是 15 位的，定义手机号码肯定是 13 位的或者是邮编，这个理解上大家肯定是统一的，我会将这个标准存储到元数据里面去，各业务平台一起去遵循这个标准。最终能够达到一致性。另外就是准确性，不可能出现乱码或者不是预设的值，另外一点就是及时性，从数据的采集到使用的时候，它的时效性是否满足业务的需求，不知道大家有没有玩过游戏，比如说我们打完一个对局的时候通常会推送一个消息给我，或者送我一个道具或者一个金币，这个及时性是非常强的，打完以后马上给我推送，不可能打完以后两个小时再把金币推送出去，这就没有意义了。这是比较重要的考核指标，而且对应用层面来讲是非常敏感的。
当我们定义完这些规则和标准以后，第三步我们就要有一个质量监控的覆盖了，就是有这种对帐、心跳、内容检查还有延迟告警等相应的保障。
最后一点就是质量报告，我们也会去输出整个质量的一个趋势，同比、环比，然后让各个业务线的负责人能够看到信息，让他知道那个数据当前的质量是怎么样的，让他心里也有数。目前我们是能够达到三个九的质量的，就是数据交付的时候能做到三个九。
总结来讲就是通过业务的手段加上流程加上技术三个维度组合来实现这个质量方面的保障。
刚刚提到数据质量的保障，不得不提到一个非常核心的点，就是影响评估，影响评估在质量管理中也是特别强调的一点。大家可以看我们右边的架构图，它是一个非常典型的数据实时微服务的架构图，从开始的采集到传输，再到离线的计算和存储，这里有一个分支，一条往实时、一条往离线存储，实时这条线会做数据的转发、透传、会涉及到消息队列以及流失计算，然后将数据的结果写到里面去。我们用的是 Tredis，数据会写到 NoSQL 里面去，来源于实时计算或者离线计算任务都有可能。我们研发人员会根据业务规则开发接口逻辑，调用数据，最终交付运维做发布，然后做整个的流程。
问题就出来了，第一个问题整个数据服务涉及到的环节非常多，只要一个环节出问题，这个定位故障就会非常困难。
第二业务存在故障回溯，数据难度更大。举个例子，比如说一个玩家看到报告说正常的话应该是 20 级的战绩报告，结果写的是 8 级，投诉过来了，我怎么知道数据在哪里算，经过哪个环节，是属于哪个逻辑、哪个项目、哪个逻辑指标、哪个业务集群等完全不知道，这个回溯数据难度非常大。这是从上往下的。
第三点就是数据平台异常，怎么影响评估面。比如离线平台一个集群挂了，我怎么知道影响哪个项目、哪个接口、哪些指标、哪些功能，也无从去判断跟定位，然后我们给出的方案就是通过数据加业务的血缘组合来解决。
大家看这个图，就是通过采集开始到最终的服务，我们将采集的粒度细到 IT 端口进程，然后中间经过转发表，表 ID、计算的任务 ID、透传的表 ID、计算业务指标以及 Tredis 里面的 P 的前缀，最终交付给接口的业务 ID 以及集群的 ID，这样的力度上报到血缘数据库，整个思路是不是就出来了？这时候无论从上往下还是从下往上都可以轻易地实现问题的快速定义以及影响面的快速评估，这是我们实现的一个思路。
大家看这个截图，是我们平台的截图，这是普通业务的血缘关系图，是很简单的。我们可以轻易地知道从采集到中间的处理过程，知道它用了哪些资源、哪些接口、哪些指标，当我们有了这些能力之后，就应用这些能力做一些辅助我们的事情，包括告警。这个例子是说我们一个计算机任务出现出库延迟，它会马上告诉这个延迟可能会影响到哪个项目、哪个接口、哪个指标，我们就可以做一个预案，我们跟产品沟通说影响的面这么大，是要挂公告还是做一些补偿就 OK 了，辅助我们的策划人员。
接下来跟大家探讨一下如何去做数据的生命周期管理，这个主题我简单地给大家一个结论，就是生命周期管理的策略和数据的在线度是有关系的，什么是数据的在线度？通俗来理解数据的在线度就是数据的活跃度，它也是随着整个游戏的发展、整个生命周期的变化随之变化的。数据的在线度又受哪些因素影响？我认为有两个方面，第一， 跟定义数据的级别是有关系的，我们总共定义了五大级别，比如收入类的、流水类的、在线类的，我们认为这个级别是很高的，给四星或者五星的评价。同样如果是行为类的运维日志类的，我们认为这个级别可能没有那么高，我们一般就给一星、两星这样一个级别。就是数据的话我们做分级告诉它的重要程度是人为定义它的重要级别，这是一个维度。第二个维度就是我们看到它的一个价值，怎么衡量它的价值，我们从两个方面去看：一个是他的热度、一个是他的广度，等一下也会简单介绍一下这个评估。这是他们三者之间的关系。（见图）。
这里就会提到怎么去做资产架构的评估，这里我们从三年前尝试做这个事情，我们也经历过两个阶段，第一阶段是数据的成熟期，而且业务的认可度也很高。第二是研究的观察期，应该在灰度阶段。第一数据的热度、第二数据的广度，我们内部有一个共识，当数据被使用了，就是热度，这是很笼统的说法。第二就是广度，我举个例子，比如我们在国际某个机构去发布一个专利，结果发现谷歌也引用了、亚马逊也引用了，Facebook 和其他国内的公司也引用了，我们就认为这个专利是有价值的，这个理论我相信在座的大部分都会认同这个观点，同样我们在内部也是采用这样的方式，广度就依赖到我们的数据应用，只要跟数据耦合越高越大我们就认为它的广度越大，这是我们内部的思路。 第三就是收益度，数据干预之后带来多大的收益，比如带来多少活跃用户等，这些数据直接上报给我，我直接在平台里面通过模型评分，加上你的权重做这个定义。当然我们通过 A/B Test 做整个模型整个过程的训练。
做资产管理方面，价值评估经过了三个阶段，第一是做指标的采集，第二阶段我们会做评估模型的定制，最后一个阶段就是价值的表现，我们会在平台上看它的整个分布，整个评分。大家可以看一下我们的系统截图，某个业务的热度跟广度表现趋势的一个情况。
最后我总结一下做数据资产的意义在哪里，我认为是很好地去衡量投入产出比的，这里我认为分了两个阶段，从价值产出我们希望它无限放大，但是从另外一个极端讲就是成本，我们希望它越小越好、甚至没有。所以说内部我们是服务内部，在我们结算的时候采用的也是成本法，但是有另外一个观点，这个观点是说数据服务的结算定价应该跟成本无关，那跟什么有关？跟价值有关，一定程度来讲我认为这个观点没有错，但是我们的看法是这样的，针对服务内部的客户我认为比较适用的原因是为了助力我们的业务能够成功，我们尽可能帮助业务减少更多的负担，包括成本也好，当我们做得很好了以后产品有竞争力了包括跟外面的产品比较有竞争力，才会立足于整个的业界和市场。假如说我们面向的是 2B、2C，这时候用价值法是合理的，因为它可以最大化地争取企业的利益。
以上是我的分享以及在腾讯游戏怎么去实施整个数据资产管理的一些思路和不一定正确的一些方法，我们从 2011 年、2013 年做这个事情，中间磕磕碰碰，也总结了业界的很多概念和思路，一句话总结一下，我们还在路上，希望大家一起共勉，谢谢大家。
未来的制造业要的不是石油，它最大的能源是数据.