平台月活4亿，用户总量超10亿：多个爆款小游戏背后的技术本质是什么？原创

各位线上的朋友们大家好，欢迎参加腾讯云中小企业在线学堂系列直播活动，我是本次会议的主持人张小平。中小企业在线学堂围绕中小企业业务需求，聚焦企业经营管理、应用工具、技术创新、安全底座四大需求场景，推出系列直播课，全面助力中小企业数字化升级。据最新数据的统计，微信小游戏的用户总量突破十个亿，月活高达四个亿，而且现象级小游戏频频出现，而多个超级APP平台上的游戏生态也在急速发展中。如何从零到一实现一款小游戏的技术搭建？小游戏背后的技术本质是什么？能提供哪些能力和玩法？使用云开发将获得哪些技术提效？本期直播将为您一一解答。

在会议过程中，如果您有任何的疑问，欢迎您在问答区提问，嘉宾老师会在最后的QA环节为您解答，您可以通过聊天窗口发表您的意见和建议，期待您的反馈。首先有请今天的第一位分享嘉宾，游戏首席专家、架构师沈瑜。沈老师曾在腾讯互动娱乐、三七互娱等科技互联网公司任职，当前负责腾讯云游戏行业的解决方案，有超过数十年在游戏行业的技术规划和架构设计经验。今天沈老师分享的主题是全面提升小游戏能力，成就爆款腾讯云小游戏爆品分析和技术优化指南，有请。那我大家好，我是沈云然，今天要分享的主题是详细报名分析和技术优化指南。

它主要分为三个部分，就第一部分介绍一下整个小游戏的一个概况及爆品的一个现状，那第二部分是针对小游戏的用户做一个。概况的分析，以及说还有一些爆品的整个的小游戏的一个开发的案例，就是大概解读一下，就是整个小游戏的一个开发成本，以及开发的一些过程，对，那最后一部分就是针对目前很多中小公司或者是一些遇到的一些技术优化的问题，以及。怎么如何高效的去？运营小细的一些解决方案来做一个分享。二我们首先进到整个环节，第一部分就是小游戏概况和爆品分析。呃，小器是2017年十暂发布，然后正式对外开放是2018年的四暂。那截止目前已经有五年多的时间。

从整个数据上看，累计服务的用户已经有累计用户有十个多亿啊，月活已经超过了四个亿。根据中金公司的研报来看，整个的市场规模已经超过了200亿的整个的规模。而且从整个的数据来看，其实小游戏这块的市场。啊，我有做一个做了一个统计，说其实在。像。华南华北啊，还有说华东以及西南区来。西南区来看。整个。小其实大很多。头部的一些。游戏公司其实还是没有介入，像比如说像华东的莉莉丝啊，像这个米哈游啊等等，其实整个的小游戏的话还是。

处于一个蓝海的市场，当然很多人说其实说是红海，但是从数据来看，就比如说华北的或者整个华东的话，其实投入。很多经济研发小游戏的公司其实并不是特别多，或者说把小游戏作为主赛道的公司其实并不多，主要还是以传统的业务公司为主，比如说像贪玩啊，还有整个的。呃，三星互娱等公司。那从研发径上看详细的。整个的发行分为两，分为。两个路径，就第一个路径是就是传统小，传统的手游在立项的时候并没有考虑到小鸡的版本，只是说看到整个小游戏市场火爆，那是不是尝试说将原先已经立项开发完的小游戏转成？小游戏来进行开发，像这种典型单例，就比如说像那个贪玩发行，爆量研发的这个三国把兄弟，三把兄弟它其实就是一个。

原生的手游APP游戏，其实在是没有考虑到这个小游戏场，只是说小游戏场了以后我们是不是转游戏发一下，其实就从看，从最终的结果来看还是不错的，对。那另一个径就是说在立项的时候我已经考虑到了，说是小区APP和。手游APP和小机同时同时双端发行，然后其实可以减少一些重复的开发成本，那它的引擎主要是以cocos或者是以那个白鹭为主。像这种典型案例，像比如说那个三级互娱的这个叫我大掌柜，以及一玩的我是大东家等，都是这样的，就是一开始立项的时候就考虑到说后面的是APP和小西要同时发行。这样话就是。能极高的提高这个详细的收入。

那从整个的爆品来看，其实各个研发径的小游戏都有成功的案例。就比如说像。那个简油的羊和羊，他是用于cocos发行的啊，刚才提到的像爆量研发的三国把兄弟他就是采用的。用力体引擎其实在用力引擎转化，研发完了以后转成了小息来发行。那像波克城市的跃动小子，它就是采用的白鹭引擎，所以说不管是采用哪个引擎都有。成为研发的游戏都有成为爆品的一个可能。那从整个畅销榜的游戏的排面上来看，其实目前最火爆的就是盲盒家养成的游戏。就是所谓的。骑士团耐克啊，因为什么说集团，因为骑士团耐克是将这个。

是首创的这个品类，就是并且是这个品类以前是创建榜第一名，当然现在目前的畅销榜第一是那个。三七互娱的寻道大千就是所大有所谓的这个小猪砍树，其实它也是一种，呃，开箱子玩嘛，或者集团耐克的另一种。一种创新的玩法吧，应该这样说，其实大家都提到这个玩法的时候，我也跟一些游戏厂商的公司的这个技术分聊过这个事情，好像都觉得大家好像都觉得盲盒这个赛道已经过于拥挤了。特别想探索一下其他的赛道。或觉得，或者是大家都觉得说这个盲盒赛道可能已经拥挤，没有一个太成功的可能，但其实最近上线的就叫在腾讯云上线，就是灵魂序章，就是或者叫斗罗开箱子玩法的话，其实目前的整个的上线以后的发音效果是非常不错的，对，以及。啊，最近还上的玩意，就是那个叫。

幻想，幻想忍者对，其实。在这个盲盒家。养成的这个就是开销这玩法，这个这个品类上其实还是有很多可以创新，或者是通过其他的IP来进行联合的一个创新的玩法，其实还是可以不断去挖掘的，那另一个比较经典的一个品类就是割草，其实这里面代表作就比如说像那个大漠龙图的这个。侠客梦以及这个贪玩的三个把兄弟对。其实都是典型的一个。割草玩法。当然其实我也我我也在这整个的小游戏商标榜的前80名做了一个统计，其实除了这两个品类以外，还有一个品类是大家没注意到的，就是传奇类的游戏，就是整个的创业榜前80，其中。有16款是传奇类游戏，其实整个占比达到了20%以上。

那其实里面就比如说像什么那个狂龙怒斩啊，还有什么战士啊等等等，他整个的不管从。这个收入来看，还是月活来看，其实都取得了。非常大的成功。呃，接下来一部分就是我们第二部分呢，分享一下整个小区的用户分析及这个。开发案例实践的解读。那其实没有看到这个报告之前呢，我就是我天然的以为这个整个小区都是以低龄的这个用户为主，实际看到这个报告以后，其实打破了我这个原有的一个想法，其实整个小游戏的用户是。24岁以上的为主。并且20岁以上的人群占到了。整个用户基数的80%以上。

那其中四岁以上人群是占了80%。并且从这个一二线城市来看，整个一线和二线城市比是占比。是4:6，所以从整个人群的这个用户画像来看，整个人群的付费能力是非常。OK的，那其实从流水来看，其实。像整个排名从流水来看，其实月流水或者是月收入过亿的游戏已经有大概有十几款游戏了，对，所以说这个小细的市场或者是小细的。这个用户其实是。还是有非常大的一个就是深入挖掘的空间，而且目前可以看到就是在我了解到了，在华南这个区，很多公司已经投入了，都在做一些转型，因为比如说像大世界的游戏，整个的研发成本都是。

复议绩，但其实很多中小游戏公司，那么它可以整，不管是从从整个公司的研发体量还是投入成本来说，其实不可能跟那些头部的去研发大置业的公司相比，那小游戏正好就是这个比较好的一个赛道。因为从。我们可以看一个实际案例来看啊，其实这个是疯狂集团的一个案例，其实它的整个的程序的研发，我们看就在整个的DEMO阶段是三个人。啊，包括策划和运营在一起是六个人。啊，这里没有写美术，因为蜂王集团刚开始立项的时候，美术是。租调的整个其呃，租调的其他项目组的成员，所以你们可以看到，在我们可以看到在公测阶段啊，整个程序和这个美术加在一起才八个人，那么到目前为止，风光集团的整个的就包括美术集云在内一起是16个人。

那你从这个，我们从这个投入的研发人力，以及这个收入情况来看，其实目前看就是小游戏的整个的。投入产出比是非常OK的，并且相对于这个原生的APP游戏来说，从从买量成本来说也比较低，因为原生的游戏去要原生的手要下载的话，通过下载，下载完了以后还要注册，注册完了以后还要实名制，这个径是非常长的。而小游戏的话就免去了这个下载的烦恼。并且小游戏的用户已经。基本上可以达到说100%的用户已经实名制，就是免去了这个实名制已经下载这个烦恼，整个的小游戏的平均买让成本大概在20~30之间，当然有一些品类的，呃，那个小游戏我接触到的整个付费成本可以达到整个注册成本可以达到八块钱一个，就是说这个相对于传统的这种。

手游来比，其实应该很多倍的提升，你比如说传统的SOGE的手游的话，整个买浪的单个用户的买浪成本大概是在。200块左右，对你看200相对于20来说，其实是一个十倍的。下降对。啊，刚才提到的是这个整个小游戏的一个。开发开发投入的问题，那我们看一下，如果是已经开发好的游戏，那比如说Unity游戏要转成小游戏，整个的一个开发周期是多长，那你这里是。啊，比较早期的一个案例就是三个把兄弟，他其实从。我们可以看到整个的从。可以评估到接入平台能力的话，其实总共不到一个月的时间，那其实从目前来看的话，因为随着SDK的成熟，以及这个转化工具的。

进一步的演进的话，其实目前其实从可行性评估到接入平台大概也就不到两周的时间。当然这里面其实转化以后就涉及到一些这个一些玩法的调整啊，或者是一些这个。关卡的调整，这里说这里其实有一个典型的问题，就是说其实啊，像传统游戏它是分区分服的，然后进去以后要选角色或者是选服，那其实我们也可以看到，其实目前市面上很多小游戏，他进来就是不需要去分区分的直接。直进入以后就直接开完，这样能让用户嗯快速的体验到核心玩法，这样能极高的提高这个用户的粘度，然后并且进一步的提升这个用户的付费。那最后一个环节是提到就是我们今天要聊到的就是小细的技术优化和提效解决方案。

啊，最近我有跟一些这个华东的一些游戏公司做了一些这个关于性能优化的一个交流。啊，这其实有一个核心问题就是大家都在提啊，小游戏上线了，这个小游戏的手机在玩的过程中手机比较发烫，还有啊，但是提到发烫的时候，其实大家并没有给出一个说具体什么场景。或者是具体在哪种手机上发上，其实并没有给出一个定性或者是定量的一个报告，那其实如果是只是笼统的去描述说啊，这个手机发烫，或者是整个玩法上比较卡，其实很难去做一个。性能优化的，那其实。这里面就需要去首先做一个大量人工测试。这里其实一个。工具，像腾讯的这个paper dog是比较推荐的。因为它是不需要去。

通过。直接可以无无限的去进行测试。并且相应的。各个测试数据是比较完善的。然后另外一个就是像。就是除了这个性能测试以外，另外一个就是说小区上线以后，就是它需要做的这个多机型和玩法场景的兼容性测试。那这里面比较。呃，推荐的工具就是腾讯云的这个V特的工具，当然我也有跟呃一些华南的游戏公司有去做一步进一步做一做了这方面的沟通，呃他们的我之前那个玩法就是我我小戏上线之前通过。呃，买量零素导入一部分用户进行这个性能和测试，但其实相对于，因为我们举个例子啊，就单个用户的整个成本是单个用户是30，那你导入。

呃，1万个用户整个成本就是30万，其实如果去导入，从整个真人来测试的话，这个成本是非常高的，其实是不太推荐的，比较推荐的是通过小程序云测试，或者是通过来测试来去在。正是大配之前，或者是在公测之前去解决，通过这种专业的测试工具来解决小游戏的这个性能和监控测试的一个适配的问题。那小游戏上线以后，其实呃小游戏小游戏数据助手是提供了这个小游戏的一个玩家的性能采集的数据，我们可以通过性能采集的数据来进一步的分析说是哪些方面的，比如说加载或者是一些延迟等等的好，哪些方面是需要提升的。这里再进一步说一下，整个像呃，就针对单个引擎来说，怎么去做精密优化，就以cocos为例啊，其实呃，它的一个核心就是说去。

降低这个就那另一方面是空间换时间，减少这个计算量。就是整个从减少计算。从减少这个计算度的这个手段入手，当然还一个方面就是说。降低画面的质量，当然这一方面是很多人觉得比较说，哎，为什么说要去降低这个画面质量，觉得好像这个不是说这个小游戏为了这个。我进一步提高这个画面的画质，然后不是可以说去进一步的吸引更多用户嘛，其实从这个不管是从寻找大千还是灵西藏以及其他类似的比如说稻天等消息来看，其实。降低。画质它其实是，所以说可能是对一部分人群是有一定的影响，但是他能进一步的去。扩大这个。小游戏的人群，因为很多游戏的人群的整个从它的这个设备来看是比较低端的，然后。

你在用比较高质量的发质去的情况下，会进一步会引起一些什么发烫啊，以及一些卡顿的情况。那其实像灵，以灵活曲张为例，其实灵活曲张整个画质我们可以看它其实并不是特别的高精。但是呃，在。从从这个畅销的情况看，其实小游戏它整个已经收获了大量用户，并且在上榜是还是不错的，所以所以从这个线上来说，其实我们可以在小溪上其实可以做一些取舍的，就是说降低画质这个手段还是比较有效的。那除了这个。Cos方面还有一个方面就是比如说像那种微信类的，呃，上次我们之前有跟那个华东的一个公司在交流，就是说他们这个小游戏一上线，特别是I这个平台的话，会有一个发烫的问题，那跟他们讨论完以后，他们之前做的一个测试，是讨论完以后的一个结论，就是说在I上他们没有开启这个高性能模式。

那你在一个，因为其实在从相关的数据对比来看，其实is的高性能模式大概是没有开启高性能模式，普通模式的性能大概三到四倍，就是有这么。一个比较高的，比较高的一个差距的话，其实你不用小游戏的话，特别S平，很容易引起小游戏的一个卡顿以及发烫的情况。而且目前的话，Is平台下整个的高性能模式的支持度是达到93.7%。所以呃，从这个性能以及卡顿的情况看，我们为了优化这个手段，其实一个比较重要的手段就是在is平台上开启高性能模式。

那除了以上的手段，有还有哪些手段可以做一些定性定量的分析呢？那其实我们可以是对整个游戏的这个。比如说流畅度，还有性能分析啊，性能分析指标，比如说像那个扣啊，还有什么内存占比啊，还有每帧渲染的，比如说硬件的什么CPU啊，GPU，内存等啊。另外一个就是像业务数据说在哪些答辩的场景，比如说到底是这个。嗯，打怪的场景还是。还是这个射击的场景，然后另外这个场景下的一些物件的类型，还有物件的数量做一个统计，然后基于这些数据的上报情况，我们就可以根据呃这些数据上报情况，对小细的一个性能做一个定性定量的分析。当然，其实这里除了你，呃，在。除了，当然除了你用自建的这种情况下也可以用腾讯的，像推出那个paper这些。

一些SDK，一些工具来去进一步减少这个开发的成本，就是说接入即可使用就没免去了，说我需要重新啊去做SDK采集，采集完以后还要做数据的处理，数据处理以后还要做数据分析，这一长段的路径大用配的话就是一站式解决方案，就是即用即可分析对。啊，下一个就是除了就是传统的这种，就是像cos啊，或者白鹭引起的这种原生的外部H5的一些引擎以外，其实用力体的优化也是目前来说碰到了一个很大的瓶颈，那其实嗯。首先一个比较。比较常规的手段就是对这个。代码量做一个精简，那其实我们有，呃，从一些跟一些游戏厂商做交流的时候，其实大家的像Unity的话，它在这个开发的时候，会为了减少这个开发的成本，就是。

做了一个大量的代码的自动化的生成，和这个自动化生成代码里面其实包含了大量的冗余代码，就造成了整个函数的。函数数量的增加，所以这一部分其实在转型的时候是可以做一些代码量的精简的。那另外一个就是因为很多整个的小游戏，整个的小游戏的话，它能。整个小游戏的话，其实这个。呃，它的整个包体大小是有呃是有限的，所以我们呃是有限的，所以可以在转小游戏时候，可以通过外部工具来对整个小工具小游戏做一个分包的处理，这样话。提呃，提高这个加载的体验，那另外一个就是。呃，整个的。

整个游戏游戏的一个。画面的一个裁剪，其实哦，就说到一个就是小游戏引擎的，就是引擎的一个裁剪，其实像那个UN的话，针对小游戏已经推出了一个特定的。小些版本，当然现在拥弟姐她说的这个团体，其实团体已经在在五暂已经推出了，只是说没有叫团体这个名字，他的这个正版本是应该是在2021那个版本上做了一个定制化的开发，对。这里我们介绍一下一些具体的详细的优化手段。那其实。这个在整个在小细的开发文档上是有的，这个就不进一步诉说了，诉说了。呃，刚才说到这个。呃，小细的这个团建引擎版本，其实它比如说在这个流失加载啊，还有内存占用以及绘制效率上，其实做了一个大量的定制化的开发，特别是这个。

加速加快，加快这个启动速率上，嗯，就是。这个链接其实就是这个小UN专门针对小游戏的一个定制化的开发版本，它的版本应该是2021的，大概是五三的一个版本，大家可以去下载一下，对。呃，刚才说到了，呃，Unity优化的一些手段，或者是。一些径，那我们以具体的一个小Unity优化优化的案例来看，其实比如我们这是一个实际的案例啊，就是它的整个is的。包含整个原始包的函数是96000个，然后手包的话是26000个啊，其实这里是有一个推荐，就是整个手报的函数原则上是应该是在3万内个，3万内3万个以内，对，其实。另外一个就是我们看到它的整个的lur的情况是一百一百五十兆到200兆，其实这里推荐就不要超过300兆。

那你其实这里还有一个问题就是。小游戏的用体的一个那个动态热更新的问题，其实其实你用露娜也好，或者是用那个。普洱的普洱TS也好，以及用这个华佗也好，其实都是支持热加载的。但是从性能上来看。Luna的性能实际上是比这个原生的优美性能是有很多倍的差距的，所以如果是从性能方面考虑，是可以使用这个。原生拥体来去进一步提高这个性能，其实热加载方面用华佗，其实华佗的这个热加载能力也是现在是完美的，是支持整个小区的热更新的。那刚才说到还有一个问题，就是整个的压缩的美术贴图的问题，其实推荐的话，不管是安卓还是推荐使用在这个移动端，推荐使用是STC这个模式。

还有另外一个问题就是小，就整个资源的面数的问题，就是因为小游戏的上面的整个的小游戏渲染的情况来看，其实跟原生的这个APP来看，其实Unity转成这个。那G以后大概的性能差距可能是只有原先的呃1/3左右，所以在面数方面，我们需要对模型的面数进行简便。啊，就刚才举的例子啊，就比这是一个参考情况，就比如说像。一些NPC啊，主角啊，或者boss的层面，或者是这个小外传，你看一下，其实这是一个比较推荐的一个面数。那还有一些手段，就是一些比如说像这个低配设备的话，我们是要进些锁针的，对。啊，除了这些以外，其实本身的很多Unity这个小游戏的优化的话，其实核心还是。

这个代码的问题，所以在代码的这个优化上，我们可以推荐看一下这个Unity推荐的一个。官方的这个C关于C下方面的一个程序优化指南，可以去看一下那方面的一些相关的相关的一些文档，来对这个小机进行优化。呃，刚才有提到整个优化的问题，其实整个的。因为整个小游戏很多，大部分小游戏团队它的规模是比较小的，那其实怎么去利用好日志，在运营风控等方面提供一个数据支持了，其实比较推荐的场景就是用这个。腾这个腾讯云的CCS来解决这个问题，因为它原先支持支持这个C口函数，就是你不需要的啊，这里说到一个问题。其实大部分我了解到了很多，呃，有小一些公司，它的一个日存储远，如果很早之前的都通用的是用MYSQL。

那买circle的话有个很不方便的地方，就是说你需要SH连上去，连上去以后还要输过一些命令，其实这个整个的如果真的遇到问题的话，整个的操作的。呃，径是比较长的，而且你真出了问题，这么长的时间来处理的话，可能当时问题已经发生了，可能会造成一些排查上的困难，这是一方面。那还有些，还有一还有一部分公司是采用这个UK的方式，但是UK天然的有一个问题就是数据，UK的话，数据它是存三份的，并且为了这个。为了这个日志上的就是日志的一些突发会留一些，大概会留50%冗余，也就是说你实际使用的数据是一份，但是你却花费了六份的成本来去啊做。做这个。日志的。冗余的一个成本，对，那利用CS的话，CS是支持这个。

就是按使用来使用量计费，就是你使用了一份的成本，那就是一份的成本，就不需要额外的一些啊，整个数据的冗余啊，以及数据的八的一些成本。那另外一个部分就是CS，不仅说是支持这个日存储，而且将这个比如说像UK这些数据报数据的仪表盘，以及。呃，从数据的整个监控可观性，整体全面都可以解决这个问题，所以用CS的话，其实能极大程度上其实提高这个。人效并且的话，其实在，而且并且的话，另外一个核心就是说减少这个。小游戏的一个运维的成本，因为大部分小游戏公司是没有专职的运维的，或者说是小游戏的整个的专职运维团队人数是比较少的。

那你这里还有一个场景，就是，嗯，小游戏的这个流浪突发的场景就是。呃，其实。这里需要提到就是杨太阳像。去年的话，去年九暂的阳光是突然一下火爆，而且本来简邮这个团队也没有意想到这个游戏会火爆。其实。那怎么去？去应对这个场景的，当然，呃，就像很多人说我们可以提前去。去那个买一批机器囤着，但是呃，这里就涉及到一个成本问题，像比较推荐的方案就是整个游戏采用容器化的方案，只要遇到问题，我们可以动态的去做一个扩充容，然后避免了这个，而且能避免这个单点的问题，对。然后还有一部分就是小，其实还有一部分就是这个小游戏突发了以后，可能就会遇到一些啊，比如说一些友商的攻击，或者一些黑客被黑客盯上就会，呃，有一些整个的。

这个小游戏的一些。这个并发或者是被攻击引起的一些问题，其实我们推荐的一个推荐的一个产品就是wa，通过wa的话，能对这些。Buff和光对一些黑产的攻击啊，一些CC的攻击能做一个拦截，然后。能避免这种。因为。因为这个攻击而中断业务的一个情况。那最后要提到就是这个大数据的方案。因为其实整个的，其实目前看整个市面上其实大部分公司是用的采用的第三方的一个。SaaS的系统。但是。或者pass的一个系统，但是这种第三方的系统有一个天然的问题，就是特别详细的话，其实它是按数据量来付费的，就是就你在数据量比较小的时候，可能一年的付费成本大概在10万或者20万以内。

但是当你的数据。快速的膨胀或者导致这个数据量非常爆炸的时候，整个的成本可能会上升到。200万以上，这个200万的成本对于大部分的这种中小型公司来说，还是一个比较大的成本，其实我们推荐的方案就是直接通过买，然后通过数据同步的方式导入到。这个里面，然后进行接入腾讯的BI做一个分析，其实整个成本来相对于采用。第三方的这个数据产品来说，整个成本是比较低的，而且另外一个就是多的是全面的兼容，这个MYSQL语法就是。那之前的呃，一个我们提到大剧好像就提到整个哈杜普整个体系，比如说这个什么in帕A苦啊，以及多这些产品，其实嗯，现在的话，其实我们比较推荐的是多类的产品，因为多类就是人人都会数据开发，就是会买蛇，会蛇就会大数据开发，就没必要说，就没必要说采用那种厚而重的这种哈图体系，因为它有两个问题，就第一个是哈tobe的维护的成本是比较高的，另外一个就是在现在的这个市场上哈度。

的这个人才是比较难以招聘的，所以现在目前看很多公司都在进行这方面的选型。的一个转型。那今天的分析，今天的这个环节的分享到这里，然后谢谢大家的观看。好的，谢谢沈老师的精彩分享，有想和讲师交流问题的朋友可以在问答区留言，接下来有请到第二位分享嘉宾，腾讯云日志服务架构师曹风岩。曹老师负责腾讯云云日志服务解决方案，具备丰富的日志及存储解决方案经验，聚焦存储及日志服务，服务过游戏、出行、零售等行业的解决方案。欢迎查老师带来释放数据价值，提升游戏运维效率腾讯云小游戏运维解决方案的主题分享，有请。

诶，大家好，我是腾讯云日志服务的产品家构师曹凤岩，今天非常荣幸给大家带来呃释放数据价值，提升运维运营效率，就腾讯云小游戏整体运维解决方案的介绍，我们今天这个介绍整体大概分成四个部分，首先第一部分讲一下我们小游戏呃整体行业对数据的价值以及怎么样利用，以及如何来收集和处理这些数据，它会有怎样的挑战。那第二部分应对刚刚讲的，我们这关于这些挑战或者问题的话，CS有怎样的解决方案，第三部分的话，我们会根据刚刚讲的一些，呃。问题及说解决方案去整体来看，它确实实践的运维和运营场景的最佳实践。最后的话我们会介绍两个标杆客户的案例给大家看看到底是具体怎么样使用腾讯云日志服务CS的。

好，首先我们看一下目前小游戏行业对于数据的整体运用啊，其实现在游戏是一个数据驱动的行业了，尤其是小游戏，它的生命周期非常的短，迭代周期非常的快，那么游戏公司的不同角色在面对不同问题的时候，他其实需要不同维度的数据来帮助他定位以及解决问题。我们大致按照四个方向去规划，可能游戏公司它会需要接触以及使用用这些数据的方向，那第一部分我们叫他比如说是开发以及运维人员，这部分他主要是要需要去定位一些正常的错误情况啊，包括服务端的错误，客户端的错误，以及说一些呃，接口的卡顿，或者说网络的延迟情况。那第二部分的话是客服他们需要面对的是整体的这样一个消费者的一些问题以及投诉，那他就需要非常快速去定位到游戏的这个整体运营状况，或者说客户在登录以及注册购买时候的情况，以及一些当中游戏轨迹或者说游戏资产的变化，因为客户是第一时间非常紧急的，他们需要及时的有这个数据的响应和反应。

这两块的话是需要有比较实时的对数据的反应、反馈或者说定位的，那除此以外的话，还有一些比较偏运营方向的两个角色，他们会需要有一个整体大盘的概念，第一个是游戏策划，他会需要去知道比如说我这个设计的关卡关卡，或者说这个副本整体的反馈情况，以及说我这个游戏面对客户的画像，还是说看有没有一些作弊，或者说其他的情况去异常排查。最后一部分呢，可能会类似于决策者或者说老板的角色，那他们会更关注整体游戏的盈利情况，包括说一些用户以及活跃用户的情况，还有一些营收甚至是付费广告点击的情况，那其实这些数据的话，都可以从啊，我们日志或者说其他日志派封的一些数据当中去达到以及分析，那么主要问题就来了，如果我们需要这些的话呢，需要面对两个问题，首先第一是海洋的数据如何去妥善的采集，去拿到这部分的数据，第二是拿到数据以后，一般是他可能是一些半截化的数据，怎么样去能够呃按照自己想要的角度去使用，或者说得到这些数据的结果。

那整体的挑战的话，我们刚刚讲会分为两个角度，那其实每个角度的话，下面会有比较多的细分的这样一些点，那从怎么收集这个角度看的话，它主要可能有这样四项困难，首先第一点的话就是说采集比较困难，因为呃游戏的话通常数据量会比较大，尤其是一些多人在线的游戏，那么如果说像以前老式的方法，呃，比如说是在本地上去查看的话，需要预留足够的空间，甚至说需要有查询分析的能力，这样对其实本来就已经负担了游戏整体运营的机器来说是比较大的浪费。包括像刚刚沈老师讲的一些传统的解决方案erk的话，那对日志这些使用，包括存储空间也是有比较大的浪费，这块的话就会推荐使用说像CRC用类pass类的服务，那它是按量付费的，我们会按照它的量去按照呃当前的情况去收取它的对应的费用，只会存储一份数据，那除了说我们对这个空间的利用率比较高以外，还有一个比较大的情况，就是说游戏整体的数据它是波动比较大的，尤其像小游戏这样的环境，它的生命周期比较短，那游戏周期啊，其实它的波峰和波谷非常的明显，比如说在刚上线或者说活动以及说是一些更新的时候，它一定会是一个峰值的情况，那在游戏的末期，或者说正常平时平稳运行的时候，它其实数据并没有在这些峰值时候那么大。

按照我们接下来来讲，其实在这种峰值波峰和波谷对比差可能会踩到几十倍甚至数百倍的情况去，去有一个这样一个数据量的差集。那么如果说我们按照传统方案的话，我们需要按照最高点去准备这样一个空间，那其实也是一个非常大的浪费，因为传统方案它没有一些弹性的扩作用。那除此以外的话，还有一些非常实时的场景，需要我们保证能够呃妥善以及说快速采集到这些数据。这个时候也会需要考虑数数据的实时性，以及如何能够快速的收集和传输这样日志的数据，首先这是第一个采集上面的困难。

那第二部分的话就是来源上面的困难，因为啊传统的采集工具，它可能只能针对单一的一种场景，那我们小游戏的话，现在会越来越多的分布到移动端，甚至说是更多一些多端看上去的一些分化，比如说我们微信上面小程序，甚至说有一些网页页游，那它会是一种这个H5或者说是web的形式。它在不同的设备以及不同端上面的日志，那还有的话就是说，因为现在讲究一些出海游戏，所以说我们整体的游戏可能布局在全球不同的地方，那呃，从比如说美国甚至亚太欧洲传到本地，或者说在中国的点对点传输，那其实有非常大的差异，怎么样保证在世界不同各地的日志能够快速统一的收回到一个统一的入口，这也是来源上呃带来一些挑战。那还有的话，就是说日志格式本身的问题，因为呃呃，虽然说我们在进化，但是其实一些传统架构，或者说不同框架打印的日志，它的格式也好，或者不同服务的打印的格式一定是不相同的，作为一些半截化数据，怎么样能够把它格式化，去提取到有用的这个KV值。

是一个比较难的问地方，那最后的话就是一些安全问题，因为现在游戏还会要面临的监管啊，尤其是出海会有一些合规或者隐私的问题，包括数据是否能够回到国内，以及说一些客户的个人隐私啊，像我们游戏当中都会有一些隐私条款去，呃给客户一个提示，那除此以外还有一些能否能够直接采集，是否需要做一些脱敏处理，都是需要考虑的地方。OK，这是第一部分，如关于如何能把日志妥善的收集起来，那第二部分其实就是说如果我们在收集完了日志以后，那怎样去把这些日志进行转化和使用，来达到自己想要的效果，也是有比较多的困难。第一部分的话就是分析的困难，就像刚刚沈老师讲的，我们可能在传统的买SQ上去搜，这是最原始的，那还有一些更升级的层次的话，比如说我们拿到数据以后，会需要把它进行大数据以及数据或者仓去做分析，这中间的话会有这么一段地方，那我们可以依据C做一个简单的数据分析，我们提供了比较多的这种分析场景来帮大家定位，或者说计算出一些比较初级的数据的场景。

那在有了这些结果以后，其实还有问题，有展示困难，因为呃，刚刚讲了我们有这样四种不同的角色，甚至说还有更多的角色，那其实每个人需要关注的数据地方是不一样的，比如说我可能做运维，我需要看到的是一些，呃，日常定位问题的这样一些数据，那我做运营或者说决色的，我需望看到一些关于运营场景的数据，那它呃怎么样去分发到不同的人，这是一个问题。那其次的话就是说我们日志它可能只是一个统一的收集，就是一堆数据，它的数据是非常海量的，那这样的话其实不便于我们去阅读或者理解的。有没有一些比较优秀的可视化的方式，能够把这些结果呃展现出来，给他对应的角色？第三部分的话就说入口比较多，因为呃，其实现在环境比较多了，大家可能有IDC，或者说有更多的是一些多元的场景，不可能在统一的角色，还有一些的话，日志是一种，那指标又是一种，包括普罗米修斯或者其他一些方案，包括开源的方案，那我们怎么样把这些不同不一样的数据源，或者说多云的东西统一展示到一个入口，因为大家不可能说希望在定位目的时候去开多个窗口来这样做。

呃，循环往复，或者说到出不同切换来去看数据，这样确实非常不方便，我们怎样把这些统一的地方拿到一个统一的入口，能不能有一些内嵌或者说合适的方式。最后这块的话就是一些实时反馈，像一些广告归因或者说实时定位的情况下，它对实时性要求比较高，我们需要在产生日志到出结果，可能会需要在一分钟级或者更短时间去能够把数据进行呃计算出来，包括像一些活动或者推广的时候，会希望这种端到端的时间能够非常短，来响应活，来响应市场对活动的反馈。OK，下面的话就大致讲了我们怎么样去用数据，以及去收集或使用这些数据的困难。下面的话我们来看一下腾讯日志服务就CS的整体的解决方案。这个的话是我们一个解决方案的全景，这个我们可以大致的讲一下，其实分为这样三块部分，左边的话是讲我们一些数据管道进的地方，那代表着我们可以去采集或者说收集哪方面的数据，其实主要分为三大类啊，第一类就是端上面，包括说移动端啊，客户端，甚至服务端，还有一些像我们自己IDC或者其他云厂商，这是第一种。第二种的话是我们会有一些开源协议去对接一些开源生态，因为可能以前我们用了这种开源生态的方式，可能还想保留这样的采集端，我们也支持通过这样的开源生态去直接把数据推送到CS来做一个统一存储，包括我们支持卡夫卡协议，或者说一些open的一些协议，去把数据直接上报到CS。

那第三部分的话，就是云产品的这些日志，包括我们在腾讯云使用的像网络产品也好，或者说其他一些容器产品也好，我们都已经已经有呃非常完善的方式去把日志集成在这云产品当中去，你只需要点击呃收集日志一键的话，就可以开启这些云产品的日志导入。中间这部分的话主要是讲一些呃，使用方面的情况啊，除了存储以外，我们还支持刚刚讲的SQL分析，包括说一些可视化，各种各样的图表类型，待会我们都会给大家具体展示。

右边的话其实是一个生态的对接，因为包括我后面同事会给大家介绍大数据对游小游戏场景的具体使用，那我们日志数据除了以正常的运维去定位问题以外，还有一大部分会需要入到大数据的平台去做数仓，或者大数据的整体的数据分析，那我们这边会支持各种各样的数据出的生态，包括卡夫卡协议投递，或者说是一些Co类的这样存储。就是投，投递到对象存储当中去。OK，那我们来针对上面刚刚讲的具体各个问题点去看看我们有怎样的方案，首先第一点就是说我们这个采集库呢，其实采集空为空为两种地方，首先对于量大的这个问题来说，我们从两个问两个角度去解决，首先第一点是agent上面采集，其实CS是有自己的这个自研agent的，它其实已经做了这个多线程，包括说各种采集性能的优化。我们全网其实已经部署了这种百万级的实例，每天的话，像CS导游这种数十P的数据啊，无论是容器环境的，或者说是虚机环境，我们都有定向的一点的去优化，去保证我们这样采集最高一个单个机器的话，可以支持200兆B大B每秒，这样日志的产生速度能够保证实时产生，实时采集进行上传。

这是在采集A的，就是说这端去做的内容，那其次的话就是我们服务端的一些弹性扩容，既然做一个pass产品的话，其实它最大的优势就是说我们是按需使用量计费，那无论你的流量增减，或者说是有一些峰值的情况，我们都可以说自动的帮你弹性伸缩出来，你所需对应需要这样一个带宽，其实我们也接过非常这样大带宽用户，包括说游戏其实还好，主要是在一些上线或者压测的时候，那最大的包括像我们要应对像腾讯会议，甚至说有在上海疫情期间一些这种抢抢菜买菜的情况，我们可以在峰值时达到200倍的这样一个弹性扩容，无感知的。

去进行一个完整的接入，达到呃，每分钟可能GB级的这样一个100GB级别这样的一个日志的写入。那除此以外的话，还有一部分就是说小游戏客户，他可能呃团队规模比较小，有一个快速迭代，不一定有这样的运维团队，那虽然说呃，这种时候你就去部署一些开源的，可能就人力不够了，那你用pass的话，可能希望更精简的来帮你解决人力，我们针对云原生场景的话，因为现在小游戏越来越多的去拥抱容器化的这样一个场景。我们针对云源生场景的话，其实也有一些这种无感接入，或者说自动化流程优化，其实分为两种类型，一种的话就是我们所有的这些采集，甚至说是呃创建日志主题以及创建所有这些规则都是原生支持CRD的，我们可以在CICD流去直接集成我们日志的这样一个采集创建的过程，去把这样的全部的日志去接入进来，所以说我们可能再开发团队进行部署的时候，如果发布这样一个CCD流，就可以把日志的这块内容也带上，不需要再去额外投入人力去做一些运维的规则的配置或者说收集，这样就会比较方便，能提省出一大波的人力。

那说这种比较高阶，或者说原生比较完生用法的话，我们也提供一些呃傻瓜式的这种额外服务去帮助，可能他并没有这样的专业的人去发布这样自动流去做一个日志的接入，我们支持说呃，你把数据全部统一上传以后，按照自己定制的规则去进行一个分发和处理，包括说一些清洗，刚像刚刚讲的一些脱敏，然后到呃按照内容去进行分发，哎，可能A项目会进入到A的这样一个主题去供A的人员查看啊，B项目的话就进入B的主题去供B的人查看，这个我们在后面有个典型的案例会给大家详细介绍。这边我们是针对一些云原生的，能够在运维自动化的角度上去节省一些人力的，呃，优化。那第二部分的话，我们就是来解决一下，比如说这个来源比较丰富的问题，因为刚刚讲我们可能端比较多，像针对移动端的话，我们是呃提供了各种各样多种SDK去做，主要两种能呃这个信息的收集，第一种的话就是说日常的这种呃信息的收集的SDK，包括说像一些自定义的买点啊啊，或者业务情况的监控，包括异常的上报这块的话，我们是提供了一种上报方式，允许客户用这个SDK去按照自己所要想要收集的信息，把这些在移动端所需要收集的信息进行上报，汇总到日志服务。

那第二部分的话，其实比较类似于这样一种探测或者测类型，这种主要针对我们网络上面的一些痛点去做的情况，我们有四种探测方式，包括ping TCT这个root m的方式去完整的定位网络链个的这些网络情况，它可以用来看一些这种延迟，丢包，异常，包括说链的拓，以及链当中的一些呃。各种明细的这种耗时和能力。这块的话是我们针对于这种移动端啊，无论是iOS安卓，甚至说是一些小游戏，H5上面都提供了这样对应的SDK，我们去可以按需去查看它的能力一样，我们分了不同的渠道都有不同自己对应的SDK，这块可以解决我们移动端一大部分上报的问题。

第二部分的话就是服务端了，呃常景我们像游戏服务器啊，或者大厅甚至说有一些这种中转服务器，那这块的话就可以去安装我们的这个agent，就是刚刚呃上面介绍的这个agent去进行采集，我们做了这个性能优化，也做了一些呃数据化的初步处理的能力，那除此以外的话，像刚我们还支持一些开源产品的上A集这块的话，就可以满足大家，呃不同不样，不同种类，甚至多种多样的这个各种的日志上报。最后这块的话是针对刚刚讲了，可能我们这个服务分布在全球各处去做一个整体日志加速，我们针对全球多地的日志，其实我们这是全球加速的日志上传，像在亚太、欧洲或者美国都有对应的节点去提供这种网络环境，以及说企业稳定的网络接入，可以把大家从世界各地的日志妥善以及快速的去接入到自己的这样一个国内的这样一个服务器当中去。

好，刚刚讲了可能是一些日志呃收集场景对应我们所提供的方案，那下面的话其实是主要是一些分析困难场景，我们有呃日志服务，除了说把日志收集起来进行存储以外，我们还提供一些简单的或者说是终级的数据的分析能力，包括这样两种，比如第一种是定时circleq啊，其实我们日志服务也是可以支持circleq，像刚刚陈老师介绍已经有200多的这种L语句，甚至现在还有更多，那么呃在这个时候，除了说我们按照按需去进行检索得到自己结果以外，我们还可以去定时的去部署一些Q任务。这样的话就可以把一些复杂一些繁琐的半截化日志格式化，或者精简成自己想要这种结果类型，以下面这个主，以下面我们这个例子来说，可能我们每条去上传的是这个IP的情况，以及它对应的呃size的大小，那我们可能会呃想要每分钟或者说是每十分钟，每五分钟去统计一下这样的结果，同时呢，把这个结果去存起来，就不用说我们把原样的日志全部做一个妥善的保存，可能我们只需要去查看结果主题就可以。

所以我们可以按照分钟去配置这样一个定时的任务，就可以把我们这个每个IP统计数据去进行一个保存，那这样的话，首先我们这个主题的日志就可以比较保短时间的保存，或者说是一个中间态的状态，去过渡到我们这样一个结果，第一，一来去节省了这个日志存储空间，二来把我们一些复杂的日志以自己想要的结果去进行一个结果化的保存。第二部分的话是数据加工，这个的话其实说就是我们针对半结构化日志的话，可以做一些更加深度的处理，像刚刚讲的有一些安全的考虑，我们可以把客户的信息进行脱敏，这边讲就是说我们一条原始日志进来，我们可以按照自己的呃规则去把它进行铭文或者脱敏，这样两条日志的拆分，可能铭文我们就会呃不需要，或者说是做一个短期的保存，以及说做一些投递归档，去做一个冷冻，那脱敏化的日志的话，我们可以做一个流出，比如说分发给其他用户或者其他情况。

那除了这个以外的话，我们还支持一些化的能力，比如说我们需要去跟别的维表呃进行关联，像类似于呃，比如说我们用户的信息，可能这条日志里面只有用户一个ID，我们可以根据其他的表去关联客户ID对应的像，或者说是一些正常的行为去做一个用户画像。部分的话就是说一个实时处理流，我们持大概现在有100多种数据加，可以方便大家去做速的一分。来处理数据啊，或者分发数据来提供整体的分析性能。然后我们已经采到了数据，也同时处理的数据，怎么样能把整个整体数据的这个展示方式能够跟这我们自己的为数不多的人员去进行关联呢？其实我们提供两种方式，或者说更两种比较典型的方式，第一种就是这种告警的能力，因为我们不可能去盯着海洋的日志去实施监控，而且每条日志的结果可能对你来说也不是有那么意，你需要整体的进行一个运算才有能力。

那我们可以去对所有日志进行配置一个告警，那其实告警的话，其实也是依据搜款能力啊，就是刚刚我们统计IP的整体数量，我们配置一个策略，同时坚定一个触发的任务周期，比如说我们每五分钟或者每小时去统计一次，那我们当我们发现比如说这个，呃，假设刚刚统计是错误的数量，如果我们判断整体错误如果大于十次，我们把它定义为异常情况，那我们就可以做一个通知或者告警，把它通知发送出来，然后以这种被动的方式，或者说以这种。呃，就是由主动触发的方式去通知到他对应的人，让他来关注整体日志或者整体运维的情况。那其实我们监控的对象的话，就包括像日志或者指标主题，那呃，通知渠道的话就非常多样的，包括像微信企微钉钉飞书，或者说一些邮件电话短信通知都可以，然后我们可以依据告警的等级也好，或者说是轻重缓急的程度也好去以。

推送不同的渠道，甚至说如果在第一责任人没有响应后，我们会再去通知第二个责任人，以此往下类推，所以我们有比较丰富的这个行动策略可以给他配置，保证我们通过这个策略所以对应的到自己的通知渠道。那第二部分的话就是说一些丰富的这个仪表盘，自定义仪表盘，那这块的话其实就做一个可视化大盘的展示，我们支持一些订阅或者邮件的推送，可以把它啊推送到自己想要关注文章去，比如说运维，我们可以每天去收集一下自己整体运营的情况，那如果说是一些呃，重要的这种经营类的数据，我们可以支持一些短信或者邮件，甚至说是企微或者微信的方式，把它推送到领导的角度，那领导每天就会收到自己整个游戏的这样一个运营日报，确实我们也有用户去做，甚至把它做到一个大屏的方式，直接放在老板的办公室，都是做一个比较非常可以量化的状态，去给其实展现出整体游戏的一个运营状况。

那这部分的话，主要是在讲一些我们解决入口太多的问题，因为日志服务虽好，但是它可能不是大家的唯一选择啊，比如说我们有多云的情况，可能也用甚至普罗修斯类型况看种况，那是直接打通的，我们支持直接将gra发内的这个数据源配置成日志主题以及我们的或者指标主题，这样的话数据就可以直接展示到gra发当中去。如果说我们习惯以国外发展作为统一入口的话，其实日志主题也可以被晋升当中去晋升到呃国外发展当中。还有一部分的话是我们一个独有的能力叫data set，这个的话是我们非常大客户，大客非常多大客户都青睐的一个功能啊，因为呃，有这样一种情况，首先第一啊，我们的所有的人员不可能去一一配置腾讯云的账号，因为你既然用云上的体系，它不可能有这么多云的账号，第二，如果说有一些离职或者说离开的情况，那么如果这样去管理腾讯云账号是非常不方便的。第三啊，讲到我们有不同的角色，可能需要不同的权限，那比如说开发人员，我可能看的是一些服务端的日志，那有人呢，我可能需要看的是一些整体运营情况的数据。

但他们权限应该是需要隔离的。第四，我们有一些大的公司可能有自己的运营平台，日志只是当中的一部分，他可能有自己内网平台，有一个自己一套的整体的系统。他希望能够不登录腾讯云控制台，或者说不登录云控制台的方式去整体框架日志，所以我们这是一个独立部署的这个data赛的方式，他可以内嵌到客户自己的平台当中去，或者就是单独的以UURL的方式去给自己的整体的呃各种同学去查看，那这时候他也不需要依赖腾讯云的账号，我们只需要有一个角色去给不按照不同的权限去分配不同账号，就好比如说我们分配一个运营人员，那他的呃账号是operator，那他的密码可能是123，那一个开发人员他可能是一个develop的账号，那他可能密码是另一个，以这种不同账号的形式去把它分配出去，那么所有的人员就可以不需要不借助腾讯云的情况账号的情况下，按照自己的这个权限角度去登录控制台，查看对应的日志。

最后这块的话就是讲我们整体刚刚流出的一个情况，因为我们讲会有一些非常多的场景需要实时的分析，需要进入到数仓或者大数据的平台当中去，那我们在志出支持各种递讯。那这块说日志可能更多充当一个管道的角色，进把数据进行采集，然后再进行对应的初步清洗，然后分发到自己对应所需要的大数据平台当中去。那我们下面来看一下几个典型的场景，首先第一个是一个运维场景的能力，我们可以看到上面有一个完整的游戏链的。呃，接入，那它从移动端到整体的原站的话，会需要经过这样几个组件部分，包括首先是边缘加速节点，可能以腾讯的产品来说就是CDN或者是eo，那其次第二块的话是一个网络的负载均衡LB的。

呃，组件最后的话才会到落到自己游戏服务端的原站，那么如果说一个客户想要监控整体网络的情况的话，他可能会需要监控多个地方的能力，首先我们会采集啊CDN以及说LB的各种日志，其次的话我们会配置各种探测的能力去做PIN和TCP的探测，用来看移动端到。呃，整体边缘端的能力，然后用HTTP以及去搜的能力，去看整体链路当中各个节点的这样一个情况。那下面的话是整个客户在使用是一个具体的情况啊，首先他用P和TVB以及各种探测的话，去达到了整体的这样一个延时的情况，那其次的话他会查看。呃，CDN或者负载均衡的日志去看具体每个点的情况，我们就是把这所有的这些日志主题进行统一的查询，有有时候我们可能比如说直接输入用户的UID，他就或者说一个站点的信息，他可以把这所有呃六种各个日志的情况去展现到统一当中去，并且做一个图表的分析，那通过整体的一个判断的话，它大概可以了解这样的情况啊，就比如说我们TCP的链接和时间都是在正常范围内的，那它主要的耗时其实产生在服务端请求或者处理响应生成的时间。

那这边的话，除此以外的话，它可以查询一些CDN或者是LB的能力，去看到它整体响应速度是比较慢的，需要优化那负载均衡的性能其实是比较好的，有比较合理的分发策略，所以通过完整的链路，包括说去次路的去定位到具体是某一个点，也就说CDN日志的话，我们可以看到它具体的呃，产生延时的情况是在这个CD的这样一块地方，那对于这样这样一条杂链，用户就已经定位到了它需要优化的地方，可能需要去做一个预加热或者其他情况来优化它节点的这样一个分发能力。

第二块的话，其实就是说我们一些运维场景的一些触发，像刚刚讲的我们告警的话，其实可以看不不样的信息，包括说一些接口的异常缓存，异常链接的失败。或者说是一些接口数据库响应速度，那这样的话就可以通过告警去把这个渠道分发到对应的通知人，那除此以外的话，我们还可以一些指标情景，这个就是说我们会每天生成大盘，它倒不需要去以实时的通知，但是我们可以通过一些环比，或者说是这个同比的情况去查看一下到底是哪个接口突然出现异常或者毛刺情况，你比如说像这个登录接口的趋势，大家就可以发到发现在这个两点到三点之间有比较多的毛刺情况，那他再可以去进行下钻，去定位到具体什么时候出现了一些异常，包括说像这个网络求响应的时间的异常，以及说或者说是单台信上C以及内的使用差距，都会进行关联出来，我们所有的告警也好，或者仪表盘也好，都是支持下钻的，也就是说你点到对应的区域，可以去看到详细的日志，看到具体的情况去进行再进行下一步的分析。

所以我们在进行呃，常规日志的处理的时候，就可以通过一些图形或者说是通知的情况去再进行定位到具体的异常。第三部分的话，其实就是一些运营场景的具体分析了，那像刚刚讲了，我们通过游戏日志的深度分析，可以给运营提供一些决策数据的支持，包括说像呃，在线情况，像最大最小或者当前在线人数，或者登录人数，那付费情况的话，就是充值付费的变化曲线，最大充值记录，每天充值记录这些，还有一些的话就是开房间对战的这个对对战趋势以及转化结果，这些都是我们实时的配置的一些仪表盘的大盘，可以做一些运维决策的，呃。指导，如果说我们观察到嗯，同时在在线人数出现大幅的下降，或者说是一个连续下降的话，就可以判断这个游戏是不是在生命周期过渡到下一个阶段，已经需要去进行一波呃推量或者说其他的优化。还有一部分的话就是一些安全分析，因为经常会有一些恶意的玩家进行脚本，或者说其他刷刷子的这样一些行为，安全团队的话，其实可以通过一些通关次数，还有耗时情况去查看一些异常情况，比如说我们这个正常的通关平均时长在一分钟，那如果出现大量的或者说单一玩家出现过多次这个低于十秒的这个刷关情况，那一定是用了恶意的脚本或者非正常的情况，这样的话就可以做一个这个具体行为的定位。

那除此以外的话，还有一些就是合规的情况，像有一些我们需要长期保存，或者说是一些呃，更长时间加载，以及合规要求的话，我们可以把日志进行一个脱敏，或者说是进行一个筛选以后投到投递到对象图当中去做一个长时间的保存。OK，下面我讲两个这个标杆的案例，来看看具体客户是怎样使用整体日志服务的。首先第一个它是这个一个头部的消消除小游戏啊，当然他也是刚刚讲的爆火的这样一个游戏，其实他在初期的时候并没有去预想到他会有这样的火爆程度，那他一开始的诉求非常简单，因为他可能并不想投入太多人力去运营这样一条游戏，所以说他需要有一些这个简单的方便的接入，以及说面对，呃，其实如果说有些波纹波谷的话，能够自动化的适应，那第二的话，其实当他发现整体业务有一个突然上涨的时候，那他就会开始关注，呃，到底是不是有一些稳定性的情况，这时候就会去看一些接口的状态，或者说抢的请求的延时。

之后当他发现这个游戏真正爆火的时候，那他就会需要有一个长时间的运维的这个运营去维持这个游戏的热度，甚至说去观察一下这个游戏是否具有一些可复制，或者说把这个用户导流的情况，嗯，那在最后的话，他其实配置了这样一个运营大盘，去监控整体的这样一个行为分析啊，或者说些关卡的调整。所以说他其实是把我刚刚两讲的两个具体的部分去做了整体一个仪表盘的配置和监控，但是他最开始我可能只有两个人员去进行运维，我们在接入的时候也帮他做了非常多的工作，怎么样把容器场景能够快速的接入进来。

就是某一单个项目在整个完整生命过期生命周期当中去逐步使用CS的过程，从最开始的快速接入，到中期的这个运维定位问题能够及时的响应，到最后能够做一些这个运营的分析，去维持游戏的热度，或及时调整自己的游戏的情况啊在上保保证了数据的接入以及数据的一些产出的能力，这是一个呃，爆火的游戏项目，一个完整的生命周期流程。那第二个的话是我们给一个头部游戏公司提供了一个整体的这个解决方案，那这个其实的话是这个游戏公司所有的这些业务都整体运行C区统一的解决方案，我们可以看到它其实已经分布了非常多的区域，包括是在国内的话，主要是在北京上海部署了服务器，那海外的话，其实主要美东啊，以及说新加坡有呃亚亚太去做承载这个服务器的能力。那除此以外的话，因为它是呃已经完成的云原生改造过了，他所有的这些有些呃场景其实是做复用的，他比如说几个项目可能会供像游戏大厅去做登录的业务啊，甚至说有一些这个关键的这种中转服务器也是去做统一的处理，不会说在区分按项目去做一个资源浪费去做丰富。

所以说他在采集的时候，我们啊建议他按区域去把日志先进行一个统一的收集，然后像刚刚讲了，我们按照不同的业务需求去定位日志当中的日志内容，按照日志内容，比如说这个project a去把它分发到对应的业务主题A当中去，那B的话就到B当中去，甚至说我们这个规则是一次配置永久生效的，如果说我们再上线新的项目以后，他不需要去再去重新配置这个分发以及说加工的流程，它会按照新建的业务主题去帮他生成新的主题，然后按需去把内容去生啊分配到新的这个主题当中去，那这样的话，其实他的运维团队在第一次配置以后，那无论后面的游戏怎么样去上新或者更新，以及频繁，它其实这个整体的日志化的配置功能就只需要做一次，而不需要去做重复的加工或者改动。

就是日志采集的过程当中的一些情况，那其次的话就是说一些呃触发的情况，因为它这个日志量非常大，基本上在所有项目统一运行的话，每天产生的数据可能已经达到30多T了，所以这样的一个每天的日志量，不可能会说我们去实施盯盘，按照每条日志去看是否存在这样的情况，所以他们其实是一个非常呃主动的告警触发的这样一个日志运维场景，他们会针对主题一共配置了1000多条的这样告警策略，所有的异常的话，其实是会按照不同的项目组，按照不同的责任人，第一时间分渠道分项目的去通知到对应责任人啊，比如说他们其持呃，我们支持呃这个告警的分级啊，如果说最严重呢，告警他会第一时间以电话的方式通知到领导，然后以及第一责任人，甚至是在第一责任，如果五分钟没有响应的话，他会把告警升级去，再进行一些情况，再去进行分配到更关键的领导，或者说其他啊老板的角色去push实这个。

去呃，第一责任人去响应这个告警，那除此以外的话，我们这个告警还有比较多的一些功能设置，包括说像静默，甚至说是一些这个暂，这个反向静默啊，我们他们是用钉钉去收集这个告警，其实我们支持在钉钉上面去关闭这个告警，因为有时候可能是一些测试，或者说是这个呃。一些压测的情况，那他有时候这种项目时候，他不会需要你去按照对应的策略去进行告警，或者说告警比较频繁，我们已经在处理了，不想他在实时打扰，我们都可以做一些反向的静默。那除了告警去做一个整体的运维情况的话，他也配置了100多个仪表盘去看我刚刚讲的一些运维角度的数据，包括说在线人收复的情况，他们也把踏实实做了两个这个仪表盘的大盘，而且是可以支持推送到，呃，无论是老板或者说是运营级啊决策的这样一个邮件，或者说呃，自己的这个移动端的场景上去了，因为他们所有这些东西，他们现在基本上已经不需要再登录腾讯日志平台去看这些日志了，日志已经全部帮处理成了告警，以及说是这个仪表盘的情况去推送了他们移动端的设备上去，因为客户也跟我们讲，说他们现在会更多的使用移动端的办公去简化一些这个日常的情况。

这个是他们一个整体的完整的解决方案。OK，今天的分享大致就到这里结束了，谢谢大家。好的，谢谢曹曹老师的精彩分享，想和讲师交流问题的朋友请在问答区有留言，接下来有请到第三位分享嘉宾，腾讯云大数据解决方案架构师周广成。周老师有着数十年大数据产品研发以及产品解决方案经验，艳经历过华为云、阿里云大数据研发和解决方案岗位，当前在腾讯云主要负责游戏行业的大数据解决方案工作，为多个游戏客户提供过大数据架构技术支持。欢迎周老师带来小数据数据小游戏、数据分析大数据解决方案的主题分享，有请。

诶，大家好，呃，今天就是给大家分享一下这个关于小游戏的数据分析方面的一些大数据解决方案啊，呃，我是周广成，主要目前在那个呃，腾讯云大数据负责这个，呃，游戏行业的呃，大数据解决方案啊。呃，今天分享的内容呢，主要是包含两个大部分啊，第一个就是关于呃这个小游戏玩家行为，包括运营数据分析一些相关的一些技术啊，就是如果使用使用一些技术，包括呃如何做分析，嗯。那第二个呢，就是用大数据的方案啊，以及客户现在常常用的一些方案做一个对比啊对。然后我们首先看一下这个游戏相关的一些行为啊与运营数据啊，那这里面呢，就是首先看一下这样一个，呃，为什么这个数据会变得呃，变得这么重要啊。首先我们从这个行业的一个呃规模来看，包括这个游戏的一些用户规模的一些增长率啊，包括它的一些收入啊，一些增长率都基本上已经达到了瓶颈，特别这个是用户的一个数量，所以呢，这个从一个增量市场变为一个存量的市场啊，那么如何去留住这个用户，包括就挖挖掘这个用户的一个价值啊，啊延长咱们这个用户的生命周期，包括游戏的生生命周期啊，这个很多客呃，很多这个游戏公司啊，就会重点放在这方面去讨论啊，那么。

呃，那么这个游戏相关的数据啊，就会在整个生命周期里面都会涉及到啊，数据相关的一些啊，比如说在呃游戏这个产品测试的过程中，我们需要去分析一下啊，这个留存的啊一个留存情况，比如说这个是有多少人用，但是最终最终留下来的有多少，然后包括这个产呃这个游戏去做这个产品推广的时候，我们要去呃去买量，去看一下这个买量的一个效果啊，不同的渠道去投放，以及这个买量的一个效果，然后另外就是在产品迭代的过程当中，我们就要去不不停的去做一些活动啊，或者对一些这个运营或者是游戏行，呃，这个用户在游戏上的行为的一个分析啊，看一下我们产品是需要哪些改动啊，或者是啊，我们对这个用户的一些呃，访问一些数据啊，一些使用习惯，给一下什么样的一些呃投放或者是一些推荐啊，那这里面就是呃，都涉及到很多相关的一些数据，相关的一些分析啊，那最后比如说还有包括一些产品的运营。

包括我们要去对这些用户画像做一些分群啊，根据这些用户的一些行为习惯去做一些这个活动啊，那这里面呢，都会涉及到很多关于这个对游戏数据的一些分析啊，我们这边可能呃比较多的哈，两大类可以分为广告投放类，还有一个数据的一个运营分析类啊嗯。对，这是涉及到整个游戏生命周期啊，都会呃，都会用到一些相关的数据分析啊，然后这些常用的一些分析方法，这个其实都比较多了啊，包括一些呃留存分析，就是有多少人啊，一开始访问，但最终有多少人留下来啊，包括一些六斗啊，或者是分布，根据年龄的分布啊，或者是呃性别的一些分布啊，或者是区域的一些分布啊，还有一些属性当关的相关的分析啊，最常用的还有一些画像的分析，给这个游戏的用户，给一个画像的一个群体，然后针对不同的一个群体做一些呃推送啊，那这些都是常用的一些分析方法，那这些数据呢，现在有一个比较重要的特点，就是客户想要快速的做一个分析啊，就是说有数据一旦产生了之后，我立刻就要要这些数据分析，那所以对这些数据的一个分析的时效性啊，要求就会非常的高啊。

那如何我们去如何去做这些数据分析呢？啊，我们首首先看一下这个常用的一些方案啊嗯，就在没有或者是说呃呃没有用腾讯大众之前用一些客户，很多客户呢，他常用的方案主要是包含两类啊，那第一个就是在数据量没有不是很大的情况下，比如说呃，咱们单表可能只有几百万或者是更小一点啊，然后总体数据量可能在呃1TB以下啊，或者是只有几十G或者是上百G啊，那这种情况下呢，一般情况下客户其实就使用传统的一些关系数据库啊，常用的就是MYS狗这个是最多的啊，就可以能够承载度这个数据量的级别的一个分析了啊，那当有些数据量达到更大一些的，比如说会超过TB级啊啊，甚至十几TB上百TB啊，然后这种情况下呢，这个单个呃，传统数据库的单个那个实例，像MYSQL这个肯定是支撑不了的啊，性能包括性能啊，包括它的存储量也无法支持，那这种情况下客户一般有些客户可能会选择一些哈普平台去。

做这个自建啊，基于开源的或者是第三方的一些，呃，CDH这种来自建做一些这个分析啊，那这种主要也是做一些离线的分析啊，那这个可能是一些常用的一些方案啊嗯，这些常用方案呢，其实我们分析了一下里面也有一些，呃，就是一些遇到了一些这个困难点吧，啊像比如说像呃关系数据库，它的虽然性能啊，就是在数据量承受范围之内啊，它的性能是比较快的，呃。

而且它也支持那些标准的SQ啊，标准SQ使用起来也比较方便啊，运维也也也比较简单啊，但是呢，它像数据量它是成为还是有限啊呃，基本上可能是呃TBTB级别以上基本上是支持不了的啊，另外一个性能上啊，就是如果数据量一旦大之后，它查询是非常慢的啊呃，一个数据量大查询比较慢，另外一个呢，就是如果咱们会涉及到多表的一些关联这种复杂的一些呃统计的查询，那这个也是也会是比较慢的啊，这个可能是难以满足这个呃，对这个数据分析实验性的一个要求的啊，那另外一个呢，因为这个MYSQL啊，经常是用在在线业务的，就比如说和充值啊等这样的在线业务在一起的，那如果MYSQ同时也用在这个，呃，分析的场景，那可能会影响在线业务的一稳定性啊，所以这可能会遇到一些一些问题啊，那另外那个自建哈都普南这个虽然能够解决数据量的问题啊。

呃，但是呢，它也有另外一些问题，比如说它的性能，它只能做到分钟级或小时级啊，它主要是适合做一些离线计算啊，但是对于那种达到需要秒级的一个享用时间的，或者端端呃到分钟以内的，那这个自己的话，哈豆普就难以做到这个事情，那另外一个就是哈杜普的话，它呃是涉及到开源组件也比较多啊，然后需要自己去自建啊，这个技术门槛也比较高啊。嗯，比如说它哈多普，它包含了很多组件啊，包括像要SDS啊，还是样啊，还有have啊，Spark等，这组件非常多，所以它的运维工作量也是比较大的啊，那涉及到多个组件的一个联合，呃，联合运维一旦某个组件出现的问题，那可能整个平台就无法使用啊，所以这个呢，呃，常用的方案可能会面临啊这样的一些问题啊。啊，那我们腾讯云建议的方案是什么呢？啊，这个呢是一个就是在第一篇也介绍到了，这个是我们推荐的一个呃整体的一个方案啊，那这个方案呢，是主要是使用腾讯云的一些全托管的产品啊，包括ocean啊，还有应营啊，DC啊，T house-D啊，包括这个BI端端的啊，从数据的处理啊，以及数据的入仓啊，以及在仓里面提供一个实时分析，包括咱们应用使用一个呃BI工具，这个端端的情况下，呃端端这个数据处理都呃都有相应的一些工具啊，而且这些工具呢，都是支持那种全托管的，而且就是呃使用起来也是非常简单的啊，支持一些标准circle啊，那比如说咱们的数据啊，可能呃原端的数据是在my circleq里面啊，当然也可能会在其他里面，或者是在呃，卡不卡，或者是其他一些位置啊，那这个数据呢，嗯，我们需要把这个数据同步到这个数仓里面去做一些分析啊，那数据同步呢。

它就我们这边有呃，两种工具都可以做同步，一个是做这个，其实内核就是link啊，然后另外一个呢，是专门做数据同步的工具也应用啊，那这两种呢，都可以做这个呃，相应的数据同步，把它同步到收藏，那这两种区别呢，后面也会介绍到啊，然后这里同步呢，也支持这种呃，离线同步和实时同步。那什么叫离线同步呢？就比如说咱们数据可能对时间要求没那么高的，我们可以一小时同步一次，或者是一天同步一次啊，然后另外一个呢，实时同步呢，就是数据一旦产生，我立刻就要同步到数仓里面，然后去做这个分析啊，然后数仓这里面呢，也分两种，一种就是那种实时数仓啊，比如说我们要用TC house-D这个DOS，这个要提供一个实时的分析能力，而且对这个实时分析的性能也要求在秒级啊，那另外呢，对一些数据呃，分析性能要求不高的，我们可以做一些离呃离线的啊，我们就用这个DRC，我们这边其实可以支持互仓一体的，同时里面呢，可以做一些这个数据分层，嗯，然后呢，我们通过一个BI工具啊，去对接到这两个产品做一些啊，自助数自助的一些分析啊，那这个端端的包括数据啊，产生处理，存储以及分析啊，都提供了相应的大数据，呃呃，产品啊。

对，那这个我们可以打开一起看一下啊呃，首先呢，看一下这个数据处理链路啊。啊说以数链路，这刚才提到了有两个，一个是ocean，还有一个是应龙啊，那这里面它有哪些特点呢？首先呃，首先这里面像同步的功能啊，再比如说咱们MYSQL的表可能会非常多啊，可能有几百张或者是上千张啊，那客户如果自己同步来，可能一一个表去同步，这个需要很多的任务啊，维护工作量比较大，那这个呢，支持一些啊，整库同步，我们可以用一个任务把一个库里面所有表全部同步过来啊，同时呢，这个同同步呢，也不需要写代码啊，直接会写SQ就可以了啊，直接写一个SQL，那另外像应龙这个也直接提供一个界面式的，就是向导式的一个拖拽方式，就可以把数据源给同步过来啊，然后这个呃，包括同步的一些性能，就是对一些简单的同步啊，单核的性能可以到呃结万QPS也是可能啊，另外一个这个同步链路，那个计算资源也可以分布式的，就比如说咱们单核不够可以扩展到呃十核上百核都可以啊，然后。

说比如说用的常页呢，从MYQ啊同步数据到收仓这个端了，端的其实可以控制在秒级延迟啊对。那这个整个呢，这个另外一个呢，就是也是比较简单应用的，像刚才说的我们会写circle啊，就可以用这个oceans来做同步，另外呢，我们会呃，就是直接拖，通过拖拽的方式就可以在这个通过应龙完成数据一个同步啊，那这两个到底使用哪个呢？这个其实看咱们的一个实际的一个需求啊，就比如说咱们同步的时候需要写一些复杂的逻辑啊，那向导式的界面拖拖拽的方式呢，完成呃，支持不了，那我们就可以使用这个open，它可以只是写circle，甚至写代码都可以啊，那如果咱们通过简单的拖拽都可以完成这个同步，不需要对数据做一些复杂的处理，那直接用这个呃，数据同步这个应用，这个产品就可以去完成这个数据同步啊。

那这里面呢，可以看一下呃，它的一个简单的一个实例啊，那左边这一块呢，它就是那个。Ocean啊，这里面其实我们就很简单的去建一个source啊，指向原端的一个，比如说MYSQL一个表啊，指向它的一个映射，然后再再建一个这个目标表啊，然后再往目标要去插入s select into啊s select新这种方式就完成了，呃，这个数据同步的一个逻辑啊，逻辑处理啊，这直接写测后就可以了。那右边呢，这个就是一个向导式的啊，就是第一步啊，我们选一个云端啊，选一个目标端，比如说MySQL do啊，选完之后再下一步去设置各种的数据源啊，各种的表，通过哪些表啊，然后再做一些资源的一些配置，那这个通过这简单的这个呃，几步就可以完成整个像这个数据的整库同步啊，或者是单表同步啊，或者是离线同步，那这个在里面都可以啊。

那刚才是那个，呃，同步这一块，那另外一个就是实时出仓这一块，数据落到，呃，咱们这个出仓之后呢，刚才说有两种，一种是实数仓，还有一种呢，就是那种离线的离线的出仓。啊，那这个实时座仓，呃，其实我们这边的名呃，它内核其实就是到就是do瑞斯啊，我们这边呃叫提斯哈佛杠D啊，这个是兼容，完全兼容开源的那个DOS，然后我们自己做了一些呃内核的一些增强啊，那这个使用起来呃相对呃MYSQ来说有什么不一样的地方呢？呃首先呢就是呃假如说咱们之前用MY，然后再迁移到do，那这个是非常容易的，因为DOS本身它是进入MYQ协议的，那所以之前在MYS上写的一些查询的一些语法基本上是不用变的，直接可以把数据同步过来啊，我们直接呃使用之前的SQL语法就可以去做查询了啊，所以这个迁移也是呃包括业务迁移，这个是比较平滑了，使用起来习惯可以保持一致啊对，然后另外呢，就是do本身它是能够它是支持那种呃，是分布式架构的啊，就是现在的是一个MP架构啊，包括呃数据支持到PB级别都是没问题的啊。

然后对一些呃数据的一些分析性能啊，也可以做到秒级甚至压秒级都可以啊，另外呢，它也支持呃丰富的一些索引，比如说bit特MB索引或者盗版索引来加速咱们这个查询啊，可以适用咱们不同的一些场景啊。另外呢，数据从。从MY同步到DOS之后，那么咱们的数仓的分数据分析也和实时，实时这个业务做隔离了，也不会影响咱们的在线业务，嗯。那呃，另外这个到这个呃，收藏产品它本身也是一个全托管啊啊，包括集群的在线的扩缩容啊，数据的自动重分布嘛，这个都在控制台上就可以一键操作了啊，不需要咱们用户手动去呃再去到到后台去做一些操作了，所以使用起来非常非常简单啊，运维基本上也不需要什么运维啊，另外它呃和MYSQL的客户端和语法也是完全兼容的，所以这个使用起来也是呃非常简单。

啊，这个呢，我们可以看一下这个DOS它的一个架构啊，它是如何做到刚才那些点呢？包括呃，它的高口音啊，它的一些性能啊，它架构其实本质上呃，它主要是分呃呃叫一个管理节点和一个计算节点，管理节点这里面叫fe啊，计算节点叫be fe啊管理节点主要是负责一些原数据啊，原数据的一些管理，包括一些息的一个查询的一个分发啊B节点主要是负责数据的存储以及具体的一些计算工作啊那这个是做到高可用呢，它有两个方面的，一个高可用，第一个呢，就是f fe呢，本身它是支持多个节点的啊，比如说可以支持至少三台啊高可用，那其中有一台比如说挂了啊，那么另外两台在某一台会自动提供服务，所以这个服务本身是一个高可用的啊，那另外这个B节点本身它也是一个分布式的啊，可以做做到三台四台，如果不够可以继续往上加，而可以继续往下加啊，加到更多都可以啊，那里面的数据呢，也可以支持多副本的方式。

读副本的方式，比如说一份数据，咱们本身这个对数据的高考用要求比较高啊，假如说有一台节点啊，呃，挂掉了，那另外一节点的副本的数据也可以继续啊，对外提供服务啊，那这个是它的一个高可用啊，一个提供了一个技术，另外呢，就是如何去提高这个产品性能呢，这里面也有很多技术，包括一些呃，这几个大，现在几个大的，比如说这个物化视图啊，可以提前做闭合啊，也支持一些向量化的一些能力来提高产品产询性能，那这些呢，都是我们内核提供一些能力啊。呃，另外它也支持这种行存和列存，比如说对那种高并发点查的，我们可以用行存，那对那种分析比较多的，我们可以使用列存啊。

呃，这组合起来呢，能够方便咱们去做这个，嗯。呃，做这个高性能的一个分析啊。那另外一个呢，就是数据库这一块啊呃，数据库这一块呢，其实呃，它主要是呃相对那个资金哈普那块来说的啊，就是呃，如果咱们的实时数仓啊，呃实数仓满足不了啊，就是说咱们的数据量非常大，那有些而且有些数据呢，它不需要这么实时，那么呢，呃这只需要离线就够了，那么就可以选择这种啊DRC这种产品，呃可以提高呃它的离线数据的一个处理能力啊。那首先DLC呢，它呃本质上呢，它是和那个弗林可那个是可以我们内置的，我们这边腾讯云这边是做了一些联呃做了一些产品的联动啊，可以呃支持弗link实时的数据写入到DLC啊，就是虽然它是一个理性的出仓，但是呢也能够支持弗link的一个实时写入啊，而且这个端端的时延可以控制在一分一分钟以内啊，这个其实相对于哈多来说，这个是它的一个呃比较大一个特点啊，另外呢，就是呃数据库本身它是呃存算分离的啊，存在分离的加固啊，所以呢，它的存储呢，是用的是我们云上的对象这种cos。

它为什么叫护仓一体，那这个其实也是可以这个呃体现出来的啊呃它呃也可以存储，也支持iceberg蝴蝶啊，爬灰的啊等这样一些呃，这样一些呃存储格式，呃另外这个呃计算引擎也支持那种准实时的和Spark，呃像刚才说的，它这个也支持一个呃标准的一个circle口啊，标准的circle口包括存在分离啊，这个计算资源啊，包括存储资源，我们都不要去关心啊呃直接去使用就行了，也是一个全托管啊，相对于资建的话都来说，呃这个包括一些使用的易用性啊啊包括一些成本和费用啊，都会有相应的提升啊。对，这个呢，是它一个整个的一个，呃，整个的一个架构啊，呃，像刚才说的，咱们这边是一个存在分离的啊，它存储呢，默认就是放在这个地，呃下面的这个cos上面去啊，这是腾云的另外一个产品，然后计算呢，这是中间是它的一个计算的一个模块啊，里面内置的Spark和crystal啊，然后这两种计算引擎统一对外，呃，提供一个标准的circle狗，就相当于咱们啊一套circleq呢，同时可以跑在两种引擎上啊，那那这同同时呢，它也可以支持这种，呃联邦查询，什么叫联邦查询呢？就比如说咱们的数据啊，呃，不在这个。

不在这个数据库里面，我们数据可能会在其他的像MYSQ里面，那这里面如果有时候需要一个MYSQL和咱们的数据库的一个表做一个关联啊，那这个也是可以做到的，相当于它，呃做一个外表映射，在第二次里面做一个MYSQL表的一个外表映射，然后统一在MYSQL这边进行一个数据的一个关联查询啊对，这个是他大概的这样一个情况，嗯。

然后这里面做了一个对比啊，就是相对于呃呃常用的一些基于关系数据库自建的方案啊，这里面呃。呃用t house一些优优势啊，主要是体现在几个点啊，一个是呃数据量上，像关于数据库只能是相当说只能小于PB啊，甚至估计可能到白GB，应该就是比较吃力了啊，然后如果是用呃DOS的话，可以到PB级别啊，另外就是性能和音像啊，性能这方面肯定像数据量大到一定程度之后，那呃这个DOS这边可以去横向的扩展啊。呃，计算资源可以互向扩展，所以可以支持这种含量数据的一个秒级分析能力，那应性这两个其实都差不多啊，呃，都是支持标准SQ的，那另外一个呢，就是DLC，相对于资金都不来说。啊，主要是应用性这一块，呃，它使用门槛是非常低的，直接是呃接近SS化了，直接开箱就进应啊，另外一个运维的话，这个是因为全图管的也不需要，基本上不需要运维，然后包括一些性能的话，新的增强这面我们也自己做了一些很多的一些增强能力，包括一些这个呃，缓存呀，内置的一些缓存呀，一些相互的一些管理啊，啊资源弹性等这样的能力啊，这个都已经内置进去了，所以这个整体上使用成本也是比较低的啊。

这个是相对的一个优势啊，然后最后呢，我们看一下一呃一个这个呃一个客户的一个案例啊，呃这个客户呢，本来是在这个呃IDC自建的，它自建的话其实也是基于那个哈多普那一套来自建的，但是其实它数据量倒没那么大啊，但是哈多普自建的话，一个是IDC自建的话，一个是资源，呃一个是资源，一个是资源成本也是比较高，一旦扩容的话就非常麻烦啊，基本上是很难扩容的啊，那版本也无法升级，另外呢，就是数据量。呃，增长也速度也比也比较快，然后他们产品性能因为主要还是偏离线，也无法满足这个实时要求，嗯，所以呢，这个当时我们给客户交流，其实可以用云上的一个do这个产品啊，啊后面就逐渐去，呃去这个把这个整体的业务迁到云上，那这里面呢，他其实就因为他在采集数据，采集的过程当中要做一些呃数据一些关联和抽取啊，就是说有可能会多表关联打成一个宽表啊，然后有些数据呢，可能要做一些转换，会对数据做一些一条处理，所以这里面它只需要用这个ocean就可以了，用那去把一些呃直接读MYSQ的数据啊，卡夫卡的数据，嗯，是实时的读取，然后写到这个收藏里面。

然后在书藏里面呢，它通过这些circle的方式啊，去做一些呃呃，一些广告相关的一些统计率转化，包括一些日活或月活这样一些计算啊，那这个相对于原有的方案来说，一个是云上。啊，资源的扩斯容就非常简单了啊，比如说遇遇到业务高峰期可以，呃，特别是像Doris啊，其实这个直接扩容啊，它还会自动做这个数据的成分布啊，也可以做这个缩容啊，这个都是可以的，呃，相对于线下IDC来说，这个是非常方便很多啊。另外那个DOS本身它分析的性能像呃，像一级别的一级别和千万级别甚至百万级别多个表径啊，其实也都可以，呃都可以在秒级的这个呃时间的一个响应啊，整体的话，他对他们来说，嗯，他们的运维，运维成本啊，包括这个性能都得到了这个呃，就是运维成本呃降低了很多，然后同时这个查询性能也提高了很多啊对。

然后对我今天可能分析，呃，分享的主要是这些啊，谢谢大家。感谢周老师的精彩分享，有想和讲师交了问题的朋友请在问答区留言，接下来有请今天最后一位分享嘉宾腾讯安全微test产品经理君明成。周老师作为腾讯安全微test产品负责人，主要关注游戏行业客户的安全及质量需求，通服务过各个游戏大厂的王牌小游戏和手游转小游戏的品质保障需求，欢迎曲老师带来全方面守护，为玩家创造安全流畅的小游戏环境，有请。

诶哈喽，大家好，嗯，我是今天最后一个最后一个讲师，然后我今天主要是给大家分享的话，是小游戏的一个，呃，一个是安全的一个方案，另外一个的话是小游戏整体的一个质量保障的方案。嗯，整个议题的话，主要是说会给大家先介绍一下呃，目前小游戏面临的一些安全和质量的痛点，然后就然后会给大家介绍我们三个解决的方案，然后最后是一个简单的案例分享。嗯，其实Jimmy Jim米哥在之前的介绍了已经讲过，就是小游戏现在其实已经有一个非常大的一个商业板块了，我们在去年的话，微信小游戏累积的用户已经到了10亿了，然后月活的用户也会有4亿多，但而且开发者方面的话，今年微信小游戏的开发者已经达到了30万，有越来越多的呃游戏厂商也投入到了小游戏这个赛道当中啊。同时的话呢，对于小游戏玩家来说的话，是不需要下载安装游戏APP的，然后游戏本身对呃，对玩家来说占用的手机内存也比较小，然后玩家是可以即用即走的。嗯，虽然说小游戏的开发门槛和成本相对APP来说要低很多，但对小游戏玩家来说，它切换竞品的成本也很低，当他遇到有网络的问题啊，有首页的白屏黑屏啊，有崩溃的问题，或者是说占用的内存过多，CPU消耗过多，导。

导致了这个游戏是游戏玩的过程中的卡顿的话，其实会有超过70%的这种小游戏玩家会选择直接去退出这个小游戏，就不玩我们这小游戏了，或者是切换到竞品游戏上。

嗯，小游戏本身的质量痛点的话，首先会有一个小游戏的一个异常崩溃的情况，嗯，就是在进入到比如说进入到一个关卡的时候，呃，因为呃有一个异常的崩溃，它就导致了黑屏，然后退出游戏，甚至说整个微信会被呃会被强退，然后然后在小游戏本身的话，呃，可能在有些页面的加载过程中，会出现一个小游戏的加载性能问题，嗯，这个其实有的时候是兼容问题导致的，有的时候就是性能的卡顿导致的。所以常见的话会没有覆盖说，呃，我们用户常用的一些设备啊，呃部分的机型会出现黑屏或者异常的退出，然后同时的话，像微信QQ，包括抖音的一些一些，呃小小游戏的话，它会存本身自己，呃这些平台会存在多个版本，所以除了去适配设备的话，我们也要去适配平台的一些版本，如果对平台的版本存在适配问题的话，也会导致这些崩溃和卡顿的问题。然后另外的话，之前几位讲师其实也提到了，说我们小游戏的话，首屏的加载时间会过过长，然后会导致白屏的时间长，用户等待的时间久，甚至呃极端极端一点的情况下的话，用户就是我们的玩家会进不去我们的小游戏的实际的这个实际的这个界面会一直停留在这个小游戏的首屏加载界面。

嗯，在小游戏面临的安全风险上的话，其实主要是五个方面，第一方面的话，肯定是我们的核心代码和资源被盗用，会有一些仿冒山寨的小游戏，然会呃，植入一些病毒啊，广告啊，然后去做一个仿冒品，这样会给我们本身的小游戏开发者造成损失。那第二个方面的话是小游戏本身也会储存一些玩家的用户，玩家用户的一些隐私信息，比如手机号码，身份证号码这些，如果这些是没有得到安全保障的话，那这些信息是可能会被盗用和泄露的，然然后其次的话是小游戏本身的代码暴露呢，其实很容易会有一些外挂漏洞，嗯，其实一开始小游戏这刚出来的时候，外挂的这个市场并不是特别大，但是随着小游戏本身的发展，然后呃，有很多的黑产发现小游戏的这个赛道是越来越有利可图，所以他们会呃有很多的本身其本身是做手游端游的一。

些外挂的作者也会去做小游戏的一些专门的外挂啊，另外就是小游戏这里本身的一些，呃，加固的方案是比较有限的，所以就给了这些外挂或者一些可乘之机，嗯，另外的话是小游戏如果是没有说我们做一些防护的话，本身它的前端代码是可以直接阅读的，是没有安全防护的，对于这些黑产来说，做逆向分析是更。呃，这个门槛会非常低，嗯，如果有大量的接口呢，暴露在前端代码当中呢，也会给我们小游戏带来很多的风险，呃，攻击者会可以利用这些接口漏洞直接给我们的玩家造成损失。

嗯，针对上面的问题的话，我我首先可以呃，放了一个我们这里的一个整体的质量保障的解决方案，呃，针对小游戏开发的一个全景图啊，我们现在支持的话，主要是支持的是微信小游戏，然后对QQ小游戏和抖音小游戏有部分功能是可以做到支持的。嗯，首先对小游戏开发来说，就是咱们开发完之后呢，肯定要做的一个东西是一定要兼容适配啊，刚刚有提到说是有微信的或者QQ的一些版本的适配，安卓iOS的手机的适配，然后本身小游戏的页面有没有UI的异常，然后小游戏的内存占用的情况，CPU的消耗，呃，包括一些呃简单的新的数据，然后对核心的场景的话，也要去看有没有存在一些加载的问题，在部分型号上啊，尤其是有一些呃，比较比较老老旧的机型上的话，那可能有部分的我们的核心场景，尤其是有PVP的转动场景的话，可能会存在一些加载问题。

然后第二部分的话是我们小游戏这方面的话，有一个安全加固的能力啊，这里会在之后有一个详细的介绍，可以做一些防疫项，防篡改进行呃代码混淆的功能，呃同时呢，我们也可以提供现在可以提供一个小游戏的渗透测试，那我们去我们的一个测试工程师可以去模拟黑客的攻击，去对咱们的小游戏进行一个深度的漏洞挖掘啊，然后去检测是否存在一些数据隐私合规的风险，然后给到你给到小游戏的开发者这里一个修复的建议，然后我们现在还有性能测试的一个工具啊，也是刚刚Jimmy哥提到的postto，是不需要说开发者去进行呃root或者是越狱，我们通过呃微信插件，或者是通过电脑连USB连接手机，就可以直接去测试小小游戏所在的进程的性能数据，然后提供帧率啊，卡顿啊，内存，GPU，还有一些渲染。

指标的整个的性能数据，然后数据准确度是很高的，然后呃对CPU的影响是小于1%的，然后另外呢，我们现在也会有一个是说呃正在研发的马上要推出的一个新能力，是针对小游戏的异常监控，因为现在呃市面上大部分的方案呢，其实是针对于小程序的一个异常的一个监控的情况，嗯，但是小游戏和小程序不同的一点是它我们我们是存在一部分游戏引擎上的，嗯，一个适配的，所以我们现在正在做的话，是针对我们现有的小游戏的一些框架去做一个异常的监控，包括实时的监控，异常预警，异常分析，还有给到呃给到一些修复的建议，然后做到以上整个的质量保障解，呃质量质量质量保障解决之后呢，那我们的小游戏发布的话，可以说是呃一个比较安全，然后也给玩家一个比较好的体验呢，去发布了。

嗯，在性能方面的话，这里可能着重跟大家讲一下，因为呃，包括微信的一个开发开发平台，就开发平台的话，它自己本身对小游戏性能数据，这里是分为了三个部分呢，那第一部分的话是整个小游戏的性能概况，包括整个启动分析，然后你的啊FPS的均值，CPU的均值，然后你的流量的网络数据的一个性能的情况，然后第二部分的话是启动的一个性能，启动性能包括了一个总启动耗时，包括呃，就整个过程的话是从呃玩家打开呃我们的小游戏，然后我们有大码包的下载时间，然后加上我们的一个游戏GS注入，最后是有一个加载的时长，就是这个可以简单说的话，就是我们首屏启动的耗时的一个时长啊，然后后面两个的话，就是刚刚也提到，在过程中的话，两个耗时比较久的部分，一个是代码包的下载。

耗时，另外一个是尤其JS注入的一个耗时啊，最后的话是个运行的性能，就包括帧瑞的一个趋势，CPU的趋势啊，内存的一个分析的情况，渲染指标的一个性能面切换间的一个耗时，然后最后还有一个网络出入口的流量的监控，然后右边的话，其实就是我们的一个实际用pop测试小游戏进程的一个实例啊，其实可以看到就是整个游戏，呃，进入游戏页面之后，包括截图，内存啊，CPU还有呃帧率卡顿卡顿率呃的整个的情况的话，我们会有一个完整的监控，然后使用了一个我们的个微信插件的功能之后呢，那我们是可以获取到具体的呃，启动的一些耗时，还有页面的页面，比如说进入游戏场景后，回到游戏主页面的一个切页面，切换为耗时，我们可以拿到这个具体的耗时的数据。

嗯，在小游戏安全加固方案这里的话，这也是我们新推出来的一个新能力，然后我们的一个优势的话在于我们可以给小游戏配置五种不同的加固等级，然后现在有13个，呃，十三十三个加固的项，然后我们批量也可以支持批量加固，然后对我们来说，对小游戏加固的成本会比较低，因为一般来说咱们的小游戏也不可能是做出来之后就只发一个版本嘛啊，然后最后的话是可以支持一个跨平台的兼容性，然后现在的加固模式主要是使用本地的命令行工具，然后之后的话也会支持说在一个平台上可以进行一个可视化的加固啊，我们现在支持一些加固项的话，就包括防调试，防篡改，防逆项，代码的膨胀代码，压缩代码混淆啊，包括说呃，代码的虚拟化了，控制流的平坦化，代码的编码式加密和算法式加密，然后也会有函数的内存地址保。

静态的字符串保护以及数字的标志符生成。嗯，针对小游戏的引擎适配的话，其实主流的小游戏的引擎我们安全的加构方案都是可以支持的哦，主要是有不同的平台我们可以支持不同的方案，微信小游戏上的话，我们对引擎的适配是最好的，嗯，这里Unity Co，呃，微信原声的小游型引擎liar和和ere我们都是可以支持的，那QQ抖音的话，因为是有部分的一些限制，所以我们支持的。呃，也不会，也没有说微信这么完善，但是主流的游戏引擎像coco这样的我们都是可以支持到的。

嗯，这里的话是我们对我们的小游戏安全加固方案做了一个效果演示，左边的话是我们的一个冗余代码注入的一个，呃。冗余代码注入的一个演示就是冗易代码，像像冗余代码注入的话，其实呃，主要是帮助我们是说呃。嗯。在就是保持我们原始代码的一个逻辑不变的一个前提下的话，我们可以去解析原始代码的语法结构，然后去通过一个算法增加冗于相似代码的一个干扰，这样可以降低我们核心代码的可分辨，可分辨性就提高我们这个被啊，我们就前端的这些核心代码被逆向分析的一个难度，然后像右边的话，也是我们一个比较高级的一个加固功能是代码虚拟化啊，代码虚拟化的话，其实这里的话就是像我们用一些自定义的一些字节服务，然后把原始的代码会编译为一个动态的VMP虚拟机的指令，可以运行在VMP虚拟机上，这样可以也是说增加一个我们被逆向分析的一个难度，然后就最大程度的保障我们核心代码的安全性。

嗯，最后的话就可能是做一个案例的分享吧，呃，就因为因为其实有些就包括我们本身跟微信小游戏也是在它的性能，性能测试上，我们也是做了一些合作，就是为什么需要去做一个微信小游戏的，就性能的评测，我们需要改善微信小游游戏，就我们小游戏的一个性能的一个问题呢，嗯，其实初衷就是希望能帮助开发者去优化相关的一个性能数据，去提升一个玩家的体验，然后我们本身的评测标准呢，是根据小游戏整体的性能数据表现，玩家体验的评价，然结合操作的系统进行分档，网络条件等等多种维度建立的，这也是之前分享的一个我们的性能小游戏性能的一个呃，评测的一个框架啊，同时的话，因为小游戏这里的开发特点，就我们其实嗯，在今年的时候，呃，跟跟一些开游戏的一些开发开发厂商去。

搞小游戏开发这件事情上，呃发现其实是由今年的话，这个小游戏开发是有两个趋势的，那第一个趋势的话，就是我一个是说吉米哥提到的说之前已经有的一些IP，包括手游和端游，也就有些IP，老IP，我们通过小游戏，然后年轻的年轻化，然后给他一个，呃，算是一个新版本。然后另外一种呢，就是说我们现在有一个手游上的一个玩法的概念，我们希望先去试跑一下这个玩法是不是符合玩家的预期，那可能会先推出一个小游戏的版本，然后进行一个玩法的试跑啊，如果这个玩法通过了的话，那我们再去做一个APP的一个，呃，比较重度一点的开发啊，这是第一种情况，那第二种情况呢，就是呃是我开发了一个版本，我本身是想游戏和手游是同时同时进行的，但是我在小游戏上呢，那我会同时开发多个版本，可能有多个美术风格，我去看哪一个可能更。

符合市场的口味，嗯，在这两种情况下呢，其实一般来讲的话，小游戏都不是只存在一个版本的，我们是有多个版本去并行去去去进行的，而且整个开发的迭代的速度会非常快，呃之前我们其实跟cocos的呃这边小游戏的团队去聊过，整个小游戏的生生存周期的话，生命周期平均生命周期是三个月左右，嗯，但是会存在非常多的是这我一批小游进行结束之后，我可能会换一个美术风格去重新再跑一遍，嗯，所以对开发者来说的话，很怎么去在一个很快速的开发迭代期，而且是在一个试跑期，我们是快速的定位到小游戏的性能瓶颈也是很重要的，因为呃对第一种第一种的这种游戏开发商来说，我们是其实是想跑说这个概念和玩法能不能呃成功能不能符合市场的需求，能不能呃匹配我们市场定位，那在这种情况下的话，我们。

不希望说因为性能的问题，导致我们我们的目标玩家进去游戏来放弃我们的小游戏，这样我相当于我们导导入的流量和呃买的一些玩家，呃引入的一些玩家的玩家的一些用户的话，嗯，相当于没有办法正正常进入到就成功进入到我们小游戏的这个玩法当中去，看他是否真的是喜欢我们这个玩法的，那对第二种来说的话，我们同时线下存在多个版本，我们其实是要试跑的，那试跑的时候的话，那我们也是想看呃具体这个小游戏的问题是在哪里，因为之前的话有遇到过，呃有一家呃比较大厂嘛，然后他的小游戏当时同时发了两个版本，A版本的话是表现是比较好的，整个线上的话，嗯也崩溃啊，反馈的一些卡顿问题也是比较少的，但是B版本玩家呢，就反馈是闪退特别严重，嗯，所以针对他的这个情况呢，当时是呃给他去呃用这个to，然后去帮助他去做了一个性能上的。

一个分析啊，其实就是在同一个呃性能玩法就是同同一个核心的玩法，核心的场景，整个的测试流程都一致，然后用同一台手机去跑的情况下呢，我们是给他选了呃不同的分档，就是高档中档低档三档不同的机型，然后分为不同的系统啊，有鸿蒙，安卓和IOS3个系统，然后去跑整个的相同的流程，然后每个流程呢，会留存截图啊啊内存的峰值啊，快快视率啊，CPU占用啊，帧率卡顿率啊，然后卡顿的话会分为比较严重的卡顿，微小的卡顿啊，然后去去帮他去定位整个的呃测试就是测试它整个的玩法流程当中性能的一个表现，呃除了说跑它AB版本的话，我们也是说跟呃项目组去沟通了一个他的竞品的一个竞品的一个数，呃呃，有一个竞品的一个小游戏，然后也跑了一个同时间段同。

手机的一个竞品数据的一个对比，然后其实是发现说在B版本的话，嗯，这个性能问题主要是发发生在它，在它从这个主战斗界面啊去切回切换回主页面的时候，它这个呃版本的加载会超载，就是会加载时间过长，导致卡顿升多啊升高，而且是主要表现在啊某某一某几台手机上，就是某一个特定品牌的手机上的啊，所以这其实是通过一个呃比较直观的去对比，然后去帮呃项目组就直接去定位到这个小游戏上的一个新的瓶颈是发生在哪里。

啊，我今天的分享的话就到这里，然后看一下呃。我把时间还给主持人。好的，谢谢鞠老师的精彩分享，现在我们进入到QA环节，有请四位老师为我们解答观众的问题，麻烦四位老师开一下摄像头。嗯，有同学问周老师啊，如果把数据从关系型数据库实时同步到实时数仓DOS，有哪些要注意的事项呢？周老师。啊能听到啊啊这里面同步的话，其实主要是呃，要考虑那个同步里面要做的一些那个批次啊，就是一个是每一每一行数据过来就要写，另外一个就是像展批的写，一般情况下这种呃，要注意要通过展批的方式来去写，来减少后端数据库的一个压力。

OK，好，下一个问题，实时数仓在创建库表有哪些建议呢？啊，这个因为do瑞它的鉴别方式和那个有点不同，它这里面有多种表模型，还有有聚合模型啊，还有那个。和一键模型，或者是那个重复的模型，那这个客户可以根据自己实际的情况来去分别去选择适合自己的那个间隔引擎啊，来达到一个最好的一个性能。好的，感谢周老师，下面请问沈老师有哪些畅销的小游戏已经在使用？腾讯云都采用了哪些能力？呃，像那个杨了个杨啊，除了腾讯自研游戏以外啊，就是像杨了个羊啊，灵魂勋章啊，侠客梦啊，葫芦娃大作战等都部署在腾讯上，那除了常规的主机容器和这个数据外，一般都会采用像微test的进行一些性能和兼容分析，还有加固能力，当然也会使用挖和高防来防止一些黑客的攻击，对。

了解下一个问题，Unity支持自动调节吗？呃，用力体是这样的，就是你任何的一些自动化的工具，其实或者进行调节的话，只能得到一个还行的结果，要想得到完美的结果，还是需要进行手动手工的一些设置。而简面工具方面，我个人比较推荐的是那个森共对。好的。嗯，请问沈老师对于小开发的团队有什么推荐的技术和游戏方向呢？呃，推荐小小游戏引擎的话，个人比较推荐cocos，因为相对于其他的一些工具链成熟的引擎的话，Coco的话具备这个手报更小的优势，这样的话游戏可以更快的速度进行加载。

而且像这个像巡逻大千啊，还有骑士团啊，以及杨和杨都是采用cos开发的。说游戏方向方面啊，个人啊，个人对个人比较推荐的是女性向的游戏，因为像整个的这个游戏群体方面，女性是占到了一半，但是关门为女性开发的游戏相对来说还是比较少的。对，而且这个赛道像你比如说像一些传统的小游戏大厂，比如说像奥腾加科那个三七贪玩这些并没有开发行十个品类的作品。当然，具体的情况还要视团队的情况而定。谢谢沈老师。有同学问曹老师啊，游戏数据如何进行有效分析？日志数据如何确保时效性及安全性，请曹老师。好，那个首先说后面啊日志数据如何确保实时性和安全性，其实实时性来说主要是看采集的性能，以及就是接收端，对于这个接收的呃，延迟以及落盘的情况，这样的话，其实我们主要是做一个可能说资源的冗余，以及说是新配进的性能的一些优化以及重试去保证实时性，那去安全性来说的话，其实进入到呃，云创资源安全性已经有了基本的这个云上统一的权限隔离，以及说是这个防篡改或者防修改的内容，包括C日志数据也不会说去修改用户的数据，那其实关于到如何进行有效分析，这个可能就比较了哈，因为像我刚刚讲的，可能主要从两个方面考虑，就一个是运维角度，一个是运营角度，那运维角度的话，可能主要关注了一些像错误或者时呃接口的时效这样的情况，那运营角度的话，可能是关注一些比如说充值登录的情况，那然后这个只是说方向性的内容，这个其实可能在游戏厂商自己会有自己的那一套逻辑，呃，基本上也是。

同小异的，那落到日志上，怎么样把这些数据跟业务的情况进行关联的话，其实我们是会去进行一个那个相当于数据的转换啊，举个例子来讲，比如说像呃，我们要统计每天的充值情况，那我们应该会在这个游戏的每个充值记录会产生一条日志，那我们当中可能会有个字段，比如说保存的充值，呃，充值的这个费用的字段，比如说是1万，2万或几千，我们可以按照这个天数去进行一个聚合sum的情况，那萨出每一天当有多少日志，呃，每每天多少这个充值，把这数值进行相加，就是我们可能充值情况的一个统计，那一样的比如说。

可以count一下这段时间一个小时之内出现错误error情况的数量，那这样的话也是我们一个错误的情况，对，这是大概整体的分析，首先需要按照角度去呃，看到自己关注的哪些数值，这些数值可能在游戏当中会对应到一个字段，那么然后再通过这个字段，通过circle进行函数加工，得到自己想要的结果，一个时间范围内的整体的数据。嗯，了解下一个问题，日志怎么快速采集，有哪些工具呢？

啊，这个是这样，可能分为两端，首先第一端是样服务端的这些工具，就是呃，就比如说我们已经进入服务器了，那这时候会区分需不需要落盘，因为落盘可能会对自己的空间有一定的影响，如果是落盘的日志的话，我们建议使用自己我们腾讯云自己的CS agent落类呢去进行采集，因为它其实已经有一个比较长这个商业化的运作有一戏，呃具体像刚刚讲的时效性和安全性都会有自定的优化和保证，那除此以外，可能有些用户也可以参考一些市面上比较开源的这些采集工具，比如说体系的像或者容器环境的这样子开源组件，这些组件可能已经是较市化的方案了，他们也可以通过我们支持C志况些是像落日志SD，腾讯的网上找到应SDK，我们现在有iOS包种程序都有，这样的话可能就会需要把升到自己的这个戏库当。

啊，每当触发时候进行上传，这是我们大概提供一些工具。好，嗯，有同学还问哈，如何找到一个可快速部署的小游戏工程例子，熟悉腾讯云以及腾讯云的解决方案，可以帮助用户实现精细化运营吗？呃，首先第一个问题，可能说整体来小游戏工程利益的熟悉腾讯云的话，可能会有腾讯云自己专业的介绍，那就日志这部分而言的话，其实像我刚刚讲的，比如说我们这样iOS和安卓里面都已经有DEMO，这个DEMO的话，大家可以拿回去在本地环境试跑一下，就是可以快速去做上传这部分的适应，那然后精细化运营和这个熟悉的话，其实是第二部分的内容，怎么样快速的能够对这个数据进行一个有效的可视化，或者说是分析，其实像我刚刚答了，像我刚刚讲的那些啊流程步骤啊，就是说主要就是说从啊定义角度，呃，定位数据，然后再到搜QL分析，那就是刚刚的一套流程，那怎么样能够快速去做的话，C做了一些入情况，我们在呃C控制其实都有览个数据，我们提供类型的例子，包括啊，仪表盘有预值仪表盘，然后告警也可能有预值的告警的条件，那这样的话可以方便大家去熟悉一下，当我们正式接入时候，也可以去对比我们DEMO当中去修改一下啊如。

说可能我们在呃DEMO里面是叫某个字段的名字，在我们日志当中有可能是另一个字段，需要替换一下名字，就可以把这套方案完整的去copy过来，也提供了一些复制或者说载入的能力，这些都可以方便大家能够快速去熟悉和实践起来。感谢陈老师，最后一个问题有请鞠老师解答，小游戏上线前推荐要做哪些测试呢？嗯，一般推荐的话，肯定还是要做下兼容测试的，然后另外的话就是要测一下性能的基本的一些指标，包括专利啊，卡顿内存什么的啊，然后如果是测出来有问题的话，包括兼容测试有出现了问题的话，也建议说开发者作为修改之后再做一轮回归测试，然后其他的话就看游戏的类型啊，比如说可能有戏有PVP场景的话，也推荐说做一下渗透测试，这样。

好的，嗯，本次的问答环节到此结束，感谢各位老师带来的精彩回答和分享，本期活动也进入到了尾声，再次感谢大家的参与，关注我们，下期活动再见。