后使用快捷导航没有帐号？
　论坛入口：
　　|　　　|　　　　|　　　|　
查看: 6722|回复: 1
游戏数据分析流程
本帖最后由 小篱 于
11:23 编辑
7_副本.jpg (83.23 KB, 下载次数: 3)
11:13 上传
　　文 / 于洋 TalkingData高级咨询总监
　　游戏数据分析的流程
　　游戏数据分析整体的流程将分为几个阶段，这几个阶段则是反映了不同企业数据分析的水平，从另一个角度，也是在解析作为一名数据分析人员究竟该如何参与到游戏数据分析业务中，与之有关的游戏数据分析师的工作我们将在1.4节重点阐述。
　　如图1-2所示，对于游戏数据分析系统及数据的利用，我们分为了五个阶段，方法论、数据加工、统计分析，提炼演绎、建议方案。从工程技术、统计分析、数据挖掘以及用户营销几个方面进行了覆盖和研究。
1.jpg (77.36 KB, 下载次数: 10)
11:12 上传
图1-2游戏数据分析流程
　　方法论
　　方法论是数据分析的灵魂，是解决问题的普遍原则，贯穿分析始终的思想指导。这个阶段决定了我们如何埋点数据，如何设计分析指标，如何采集，如何组织数据。
　　方法论多数是将业务进行了抽象，形成了一套可以解决若干业务问题的思路。就游戏业务来说，从游戏数据分析角度，目前已经存在几套方法论，比如游戏早期市场提及的是PRARA，在进入移动游戏领域，以TalkingData的AARRR模型则提及得最多，这套方法论综合了PRARA、网站分析、社交网络分析等诸多分析的特色，结合移动游戏市场的情况，加以整理并提出的。在后续的章节中，我们会重点介绍AARRR模型。
　　方法论存在的意义就是要去解决问题，是对于问题、目标、方法和工具的概述。一方面解决业务问题，另一方面则是分析思维的指导。在后续有关游戏数据分析师的描述中，我们强调对分析思想的锻炼及方法的驾驭，学会基于不同角度和领域去看待业务问题，这需要高度的抽象和概括能力。从图1-2我们也可以看到，方法论的确立，决定了我们在游戏数据分析方向上要解决的问题、采取的方法和使用的工具等。
　　当我们缺少这样的体系支撑时，即使我们确立目标，但是在实践操作时将会变得非常缓慢，效率低下。因为在整个的过程中，我们要完成游戏数据分析的工作，需要开发人员、设计人员和运营人员的参与，当大家无法在统一的思想和方法的指导下，就无法进行有效地任务分配和需求理解，进而导致今天我们看到这种现象：在很多的游戏公司，运营人员与开发人员的沟通中频频会出现各种数据标准理解的不统一，分析功能开发得南辕北辙。这些问题的出现不仅仅是沟通的问题，更是对于游戏数据分析的体系和思想未形成一致的认识造成的。在方法论的阶段有如下的两点是需要重点关注和解决的。
　　(1)业务需求
　　方法论是对业务需求的最高层级的抽象，涉及具体业务时，在方法论的指导下，我们需要对业务需求进行拆解，而这个阶段，从数据分析的角度来看，就是该如何进行数据埋点。
　　数据埋点就是通过客户端或者服务端，通过在某些游戏位置追踪玩家游戏行为而得到的相关数据。这些位置则是未来对特定业务分析的基础数据支撑。比如，我们在进行用户注册分析时，需要在用户注册的相关代码和逻辑位置进行数据采集点的设计，这样当游戏有玩家参与时，我们就可以通过采集到的数据，进行整理，形成可计算的指标。
　　经过长期的发展后，基本上已经形成了一些特定的数据指标，而这些指标也可以涵盖大部分的业务数据分析。多数时候，我们常常会苦恼于如何进行数据埋点，如何进行基础的数据分析，实际上，我们通过一些行业通用的数据指标白皮书就可以在短时间内明确该如何进行数据的埋点和基础数据统计分析，这方面可以参考TalkingData在2012年发布的《移动游戏运营数据指标白皮书》。
　　(2)指标体系
　　当我们形成了基本的数据指标后，我们要形成完整的指标体系，并且要建立在方法论的指导基础之上。在多数情况下，指标具有很强的业务导向性和监测作用。比如在我们进行数据日报的制作过程中，我们就需要按照一定的逻辑组织我们的数据，用户类数据，收益类数据，渠道数据等等。与此同时，在这些指标基础之上，数据分析人员可根据需要，进一步加工和变换指标，从而完成深度分析，比如我们对于新增付费用户的研究，用户生命周期价值的探讨等，就需要在基础数据的指引下，进一步建立新的数据规划和指标拆解。
　　这部分指标工作看似是最基础的部分，但是最重要。理清了业务需求，我们需要基于目标驱动构建指标体系，在类似AARRR模型的指导下，整体构建并不会有太多的特殊性，但重要的一点是，所构建的指标体系需要能够和业务匹配起来，比如更具业务需要，重点予以关注的指标数据，或者关键业务的评估需要微型的指标体系来实施。这一类是在方法论指导原则下完成的。
　　在指标体系中，指标重在理解和标准化，如果在构建指标体系阶段，定义的指标标准不够清晰，那么在具体的开发实施阶段，就会产生很多问题，最终造成了类似统计数据不准确等问题。此外，在此阶段定义的指标不是越多越好，所以要加深对于指标的深入理解，借助数据分析来解决问题，而不是罗列数据，在构建的指标体系内，每一个指标都将具备实际的分析价值和能够反映特定的问题，并且当问题得以解决时，我们还可以从该指标或者几个指标的组合中评估效果。
　　数据加工
　　对数据进行处理使其最终变成信息，这个阶段统称为数据加工.在数据加工阶段，我们重点要去解决的问题有两点。
　　(1)业务理解
　　系统最终是需要技术开发的，在选定技术和工具之前，最重要的是要充分理解需求和标准定义。在开发人员完成开发后，如果发现其数据处理的结果并非是分析师或者业务人员所需要的，那么就浪费了很多的时间和资源，因此是否形成一直的指标定义认识，是否明确统一需求，需要分析师、业务人员与开发团队共同商议，形成统一的认识，否则将面临重复开发，需求更改等等一系列的问题。在所有人员在这些问题达成一致后，接下来就要解决的是技术开发问题。
　　(2)技术开发
　　确立使用什么技术和架构来完成整体的数据分析平台的建设，这是需要技术人员去评估的，而评估的一个重要参考就是前一个阶段所确立的内容，技术人员对于业务分析需要的理解，决定了未来构建的数据平台的很多因素，比如高安全性、高效性、高可靠性、高可用性、高可扩展性和可管理性，等等。
　　在数据采集层级，我们需要解决数据的发送机制、采集内容和存储方式等。就目前的移动互联网游戏来说，主要采取在游戏客户端植入统计分析SDK的方式来完成数据的采集，当然，在部分公司中，也采取了游戏服务器端完成数据的采集。两种方式各自具备优势，通过SDK植入游戏客户端的采集方式，在有关游戏用户终端设备的信息，用户会话时间等方面具备优势，而通过服务器端的数据采集，则在游戏内诸如等级分析、关卡任务分析方面具备优势，但是对于游戏用户在客户端设备上一些行为则无法做到采集和分析。比如，如图1-4所示，在移动游戏客户端的错误日志中，多数情况下无法通过服务器端获得的宝贵数据。
2.jpg (61.84 KB, 下载次数: 0)
11:12 上传
图1-4游戏客户端错误日志
　　而这些数据，经过采集后，则是可以快速了解目前产品的问题，比如新增用户很多，但是活跃时间和留存质量很低，分析错误日志则是一个很好的方式。这一点在移动游戏数据分析方面是非常必要的，因为移动游戏环境和场景的多样性，使得我们必须重视解决看似很小的问题。
　　在数据处理层级要对采集到的原始数据进行抽取、清洗和加载，对杂乱的数据进行标准化、映射、排重以及纠错等操作，最终将数据加载到数据仓库中。在这个阶段需要完成的工作量是非常庞大的，尤其是在移动游戏领域，当用户终端的设备变得更加多样，地域更加分散后，数据的处理工作相比之前的端游和页游，变得更加的重要，依赖程度更高。移动游戏需要更加快速的响应和迭代能力，当我们通过数据发现了游戏在某些设备上存在问题时就要迅速的进行解决，而此时，关键任务在于我们如何发现这些问题并进行分析。我们需要依托设备的标准化和纠错去发现不同用户群的设备分布情况。在同样情况下，我们也可以分析比如付费用户更加倾向哪些分辨率的手机，或者使用iPhone5的付费用户的ARPPU是多少，这些分析都要依托于强大的数据处理能力才能够实现。
　　在数据计算层级，要进行实时的运算，定义多维数据模型、业务模型，比如基于时间维度、地域维度、用户群维度、区服维度和渠道维度等，按照小时、日计算任务，根据业务要求进行数据运算，并把结果集数据输入到数据库中。
　　在业务信息层级，则需要将经过采集、处理并计算的数据最后经过接口变成可被查询的信息，如果从开发层面解释，就是庞大的报表系统，即直接面向最终分析师的数据产品。
　　实际上数据加工阶段的最终目的就是将数据转化为可用的信息。从这点来看，第三阶段的统计分析则是与业务信息阶段是结合非常紧密的，统计分析要基于已经加工好的数据，进一步深入地透过更加多元的数据或者信息分析方法，挖掘特征。
　　统计分析
　　统计分析包含了统计和分析。统计分析是商业智能的一方面，商业智能应用还包括决策支持系统(DSS)、查询和报告、在线分析处理(OLAP)、预测和数据挖掘，统计分析则是整理数据和分析数据的综合。
　　此前我们需要收集数据，但是目的都是整理数据且最终要进行分析数据，数据向信息转化的过程。为此需要描述数据的性质和研究数据关系，并通过一定的模型来变换角度解析数据内在的联系，而如果整体系统的开发度更高，则可以就模型本身进行有效性的验证。在部分公司提供的统计分析系统上，我们已经能够看到部分的预测分析，这也是向下个阶段提炼演绎的重要过渡。
　　对于游戏数据分析师来说，我们需要学习的更多的统计的思想、方法和解题思路。统计分析最关键的就是要分析数据，因为对于经过整理和加工的数据，如何提炼有用的决策信息，一方面是依托于系统的数据采集和整理，另一方面则需要分析师最终进行分析才会发挥价值。分析师的最大要求就是理解每一个方法背后的原则、范围和思想。统计学的思维将我们对于事物的解读能力提升到了一个更高的层次。
　　在进行一些游戏数据分析时经常使用集中趋势或者离散程度的指标，而这些指标所代表的不只是一个计算方式，更重要的是在最初诞生时，就是为了解决某一类问题而设计的解决办法，这是我们在分析基于计算方法下分析数据所最需要关心的事情，比如在描述统计分析中，我们经常使用集中趋势，它反映的是一组数据所有具有的共同趋势。
　　统计分析阶段对分析师来说是非常重要的考验，尤其是基本的分析能力。当然，作为一名分析师只具备在挖掘数据特征和分析数据方面的能力还不足以证明分析师的价值，数据分析本身是辅助决策的，因此，能够挖掘提炼和演绎，与业务有效结合，形成结论则是非常重要的。所有的分析师不是为了分析数据而分析数据，崇尚数据，信仰数据，但不要盲目。
　　提炼演绎
　　事实上，每一次数据分析都要经过长期的准备和努力，曾有文章指出在整个数据分析环节中有80%以上的时间是在整理数据，所以如何有效形成方法和经验就变得更加重要。
　　可以预见的是，当数据分析由系统来实现时，我们需要对关键业务具备数据的归纳和业务分析的模型组织，比如在游戏数据分析中，我们会针对鲸鱼做分析，对留存做专门的分析。这些都是通过业务的提炼才得以实现的。
　　在很多情况下，经过积累，需要将一些重要业务和分析进行归纳，总结出长期可以使用的分析模块和数据采集体系，如此当我们每一次面临新游戏需要数据统计分析时，则不需要更多的额外开发成本。
　　以移动游戏统计分析为例，在经过不断的业务提炼和模型演绎后，从分析角度来看，如图1-6所示的几个模块是最为关心的。
3.jpg (53.74 KB, 下载次数: 0)
11:12 上传
图1-6游戏数据分析模块
　　以上是经过不断的提炼总结出来的一些重要分析模块，基于这些模块，我们需要记录和完成的数据采集，并且在参数设计上需要形成可以复用的接口。在如今移动游戏市场，服务于第三方游戏统计分析服务的平台提供了标准的数据接口，从数据采集的角度，我们可以确立如图1-7所示的标准统计接口。
4.jpg (45 KB, 下载次数: 4)
11:12 上传
图1-7游戏数据采集标准接口设计
　　下面我们将通过TalkingDataGame Analytics在iOS平台的数据统计接口设计的为例，来描述具体的具体设计方法，其中涉及的标准接口有6个。
　　(1)游戏启动和关闭
　　用于准确追踪用户的游戏次数、游戏时长和初始渠道等信息：
5.jpg (20.84 KB, 下载次数: 4)
11:12 上传
　　(2)统计用户账户
　　用于定义一个玩家，更新玩家最新属性信息：
6.jpg (77.04 KB, 下载次数: 0)
11:12 上传
　　(3)跟踪用户充值
　　跟踪玩家充值现金而获得虚拟币的行为，充入现金反映至游戏收入中：
7.jpg (48.32 KB, 下载次数: 0)
11:12 上传
　　(4)跟踪用户消费点
　　跟踪游戏中全部使用的虚拟币的消费点，如购买道具、VIP服务等。
8.jpg (33.59 KB, 下载次数: 0)
11:12 上传
　　(5)任务关卡或副本
　　跟踪玩家任务、关卡、副本情况。
9.jpg (41.24 KB, 下载次数: 0)
11:12 上传
　　(6)任务自定义事件
　　跟踪和统计任何期望分析的数据，如功能按钮的点击、填写输入框、广告出发情况等。
10.jpg (18.92 KB, 下载次数: 0)
11:12 上传
　　以上是从数据采集和具体分析两个角度阐述了提炼演绎的重要性，作为分析师，其提炼演绎的能力不仅仅是完成分析，还在于优化和完善分析系统的结构和设计。这个阶段的业务模型和分析师见解，一方面影响了下一步的方案形成和指导决策，另一方面，也决定了其提供的经验在后续的产品运营过程中是否可以作为可持续使用的方法。
　　在西内启所著的《看穿一切数字的统计学》有一句话：
　　“实际上分析结果本身并没有价值，如何活用分析结果，最终得到的价值也是不同的。”
　　价值的挖掘还体现在最终的建议和方案上，因为最终数据分析要以解决问题为先，建议方案则是最终诉求。
　　建议方案
　　前面几个过程是从数据平台、标准分析系统、产品运营和精细化几个关键词在描绘游戏数据分析的流程，而数据分析的最终是要形成方案或者决策指导，因为分析结果体现不了价值，最终还是要和业务结合，真正体现价值的是如何运用结果。
　　建议方案就是解决如何有效利用分析结果。在很多情况下，你会发现最能够体现利用分析结果就是在获取用户和经营用户两个方面。在获取用户方面，我们需要针对那些还不是我们用户的用户进行转化，到达特定的用户群，即那批我们真正想要转化的人，而如何选择受众、选择媒体需要充分利用分析结果。对于广告主来说永远希望投放效果最大化，对于媒体来说则是收益效果最大化，为此在最近的几年我们看到了诸如DSP、DMP、SSP和RTB等概念的出现，一定程度上就是利用我们不断丰富的数据和分析结果，不断优化我们在广告方面的投放，不得不说这印证了西内启的那一句话。
　　另一点，从经营用户的目的来看，因为每一个用户的获取都需要成本，在产品有限的生命周期内，期望与每一个获取的用户生命周期也足够长久，如此可以获取更多的价值。而这一点，在游戏领域也被逐渐利用起来。
　　在以往的游戏数据分析领域，我们会发现，经过数据分析后，方案一旦形成，我们很难将这个方案执行下去，并且无法评估最终的效果，因为在整个数据分析环节中，参与的部门的人员众多，数据分析结果与方案执行往往很难做到一致。不过在最近的移动游戏市场，已经有很多的公司或者分析师慢慢注意到这一点，因为移动设备可以更加精准地定位一个用户，同时移动提供了更加方便和快捷的消息推送和内容下发机制，这使得我们至少从游戏运营层面可以做到根据设备、地域、渠道、游戏行为、付费行为等更加准确和快速地对目标用户进行营销，从一个层面已经可以做到数据分析结果的最大化利用。
　　比如一款游戏，如果一个活跃用户连续三天不进入游戏，则从游戏中流失的概率增加10%，此时我们就需要精确定位这样一个群体，进行目标用户的营销和召回计划。划分的目标用户如图1-8所示。
11.jpg (56.07 KB, 下载次数: 0)
11:12 上传
图1-8目标用户划分
　　根据分析结果，最终通过A/B test等方式将运营消息和活动下发到用户移动设备上，使得目标用户的转化得以提升。这是对数据分析结果的最佳利用，同时也是在不断积累运营经验，从长远来看，会形成一系列的运营模型，从此不必在摸着石头过河，也不必每一次运营活动和执行都是通过感性认知完成。
　　建议方案是整个游戏数据分析的重要一环，因为最终我们还要进行效果的检验，并且通过和分析目标进行比较，是否达到了预期。整个数据分析过程其实一个循环，只不过在这一步是把分析结果的价值通过一定的手段和方式发挥出来，最终经过检验和不断修正，形成经验和原则。游戏数据分析师其实最需要突破的也恰恰是这一步，从方案执行的实时性和分析师职能的突破两个方面来看，都将产生深远的影响，当然刚才提到的借助于内容推荐只是达成这一目标的一种方式而已。
via：TalkingData
声明：游资网登载此文出于传递信息之目的，绝不意味着游资网赞同其观点或证实其描述。
大部分内容比较空游戏行业，大数据该如何应用？ - 知乎388被浏览30017分享邀请回答805 条评论分享收藏感谢收起/p/21335157这里提到一个例子，STG《宇宙巡航机》有一个革命性的设计，每关的场景风格都不一样，遭到公司置疑，“这样搞岂不是风格不统一了？”，因为之前所有成功的STG，关卡风格都是一样的。而最终这游戏成了STG类游戏的里程碑。业界总是存在一些看似有理实则狗屁不通的条框。6219 条评论分享收藏感谢收起查看更多回答【图文】游戏数据分析及其运营方法_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
游戏数据分析及其运营方法
大小：1.88MB
登录百度文库，专享文档复制特权，财富值每天免费拿！
你可能喜欢　　过关类游戏在单机类游戏中出现会比较多，但多以休闲为主，比如《CandyCrush》、《AngryBirds》、《PVZ》、《小鳄鱼顽皮爱洗澡》、《TinyThief》等经典休闲游戏，鉴于很多圈内人士预测2014年是手游爆发年，且重点在ARPG类型，似乎会冒出很多横版过关或者全3D的过关动作类游戏，我们就针对此类型的游戏进行分析。　　首先，此类型的游戏需要关注的是每关卡的独立玩家数量，即玩家ID数量，目的是为了监测玩家主要集中在哪个阶段。比如，　　游戏刚推出阶段，玩家主要集中在前面部分的关卡(如图一所示);　　推出一段时间之后，玩家主要集中在中部关卡阶段，如果期间有拉新活动推出，不排除前、中部分关卡处于一个玩家数量比较持平的表现(如图二所示);　　如果运营很久，玩家主要都会集中在关卡中后期，或者是一个缓慢上升的曲线，又或者是一个较持平的曲线(如图三所示)。　　以上假设的前提都是游戏在运营状况比较良好的情况下进行分析的。　　其次，我们需要关注的是关卡难度的节奏问题，如果设计的难度太低，玩家很快就会因为游戏毫无挑战性而流失;如果设计的难度太大，会带给玩家挫败感太强，也会容易因为灰心丧气而流失。所以，我们一定要把握好每个关卡内以及关卡与关卡之间的难度节奏。那么，这两个方面的难度节奏怎么从数据方面来统计和展现呢?　　为了解决这个问题，首先要找到哪些关卡阻止了玩家继续前进。我们的解决方式是把每次玩家在某个关卡失败后退出游戏的行为进行记录，找出玩家在哪个关卡失败后不继续进行游戏而是选择退出游戏，并把这个指标定义为“关卡退出率”，计算公式为：　　关卡退出率=此关卡失败后退出玩家游戏的次数÷游戏启动次数　　除了这个指标，还要统计每关卡的失败率，目的是为了与上个指标对比查看此关卡是不是设计的难度太高，计算公式为：　　关卡失败率=当前关卡未成功通过的次数÷此关卡的总启动次数　　这两个指标进行对比后，我们就可以看出关卡的难度是不是设计的太高而不合理。如下图所示：　　过关类游戏的难度曲线(也就是关卡失败率)理论上应该是波浪曲线逐渐上升的形状，但游戏刚开始运营的时候肯定会有偏差，需要根据上图的实际表现情况来不断进行调整。云上游戏数据分析实践
发表于 11:40|
作者李俊涛
摘要：从游戏发展的角度来看，不管是端游、页游，还是现在发展迅猛的手游，其生命周期与盈利情况都与数据分析能力息息相关。同时数据分析对游戏的运维也起到了至关重要的作用。
从游戏发展的角度来看，不管是端游、页游，还是现在发展迅猛的手游，其生命周期与盈利情况都与数据分析能力息息相关。同时数据分析对游戏的运维也起到了至关重要的作用。精确的数据分析有助于在做游戏运营时推出合理的新手引导，在及时的渠道推广和丰富的消费场景设计，这些将极大地影响游戏玩家对游戏的关注度，从而延长游戏的生命周期，并从中更好盈利。游戏数据分析特点分析是建立在数据上的，数据的特点决定了分析的方向和方法。游戏数据的特点主要表现在以下四个方面。第一，数据量大。以手机游戏为例，一款中型规模手游的日均数据量增长在几十GB。在这种情景下，做常见的月活、季活等游戏指标分析所面对的就是TB级别的海量数据。第二，数据类型丰富。从游戏数据的种类来看，分为结构化数据和非结构化数据。从数据存放的位置来看，可以分为文本数据、缓存数据库数据、关系型数据库数据等。&第三，分析维度多样。由于游戏指标不同，所以游戏分析的维度有很大差异。例如，游戏指标通常玩家指标、性能指标和过程指标三类。第四，实时性强。数据分析分为四个层次，数据量少实时性低，数据量少实时性高，数据量大实时性低，数据量大实时性高。这四个数据分析的层次对技术难度的要求是逐渐提高的。而游戏数据分析的特点可以划定在最后一档即数据量大实时性高，所以海量游戏数据分析对技术能力和软件需求提出了极大的挑战。游戏数据分析现状及瓶颈我们曾拜访了近百家游戏客户，深入了解游戏开发商如何处理和分析数据，发现目前数据分析在不同游戏行业中使用程度不同，主要表现在游戏规模越大，使用的数据分析维度越广，程度越深；中小型游戏数据分析使用程度一般。总体来说，游戏数据分析的现状如下。第一，不做数据分析。这种类型的游戏客户在小型页游和大厅类游戏中比较常见，只是出于备份的需要将数据从生产环境中定时批量备份出来，用单独的硬盘或者服务器做数据存储。第二，数据库级别执行SQL查询。大多数的游戏客户将生产数据备份出来，导入到专有的数据库中做离线数据分析，采用的方法是使用SQL语言和第三方报表工具做基本的数据查询。但基于数据库对数据量的限制，当单表记录到千万甚至上亿级别后，这种分析方法就基本行不通了。第三，使用成熟的数据仓库产品。在中大型游戏客户中，数据规模已达到一定的数量级别，游戏运维离不开数据分析的支撑。这种情况下，用户会选用数据仓库产品，将数据库中的数据经过ETL后导入到数据仓库中做数据分析，或者用户利用物理机集群自建大数据分析平台，例如Hadoop，Spark等分布式大数据分析框架，结合具体应用场景做大数据分析。在数据分析中，当数据量达到海量级别后，上述三种情况都会遇到相应的瓶颈：除了海量数据处理能力问题之外，用户在自建Hadoop等分布式大数据分析框架中也会遇见技术难度高、框架维护成本高等问题。阿里云产品和服务选型在协助游戏客户将数据分析上云之前，我们仔细分析了目前用户的数据分析方式。他们的数据目前主要以两种形式存在，文本日志数据和数据库关系型数据。上述两种类型的数据都会被批量导入到数据仓库中，进行数据分析。在技术选型上，客户给我们提出了两点要求。面对客户的需求，我们在选择阿里云服务时，首先想到了大数据分析服务ODPS（Open Data Processing Service，开放数据处理服务），然后我们选择了对文本日志数据支持较好的SLS（Simple Log Service，简单日志服务）。SLS为大量服务器日志文件的收集提取提供了一种监听实时抽取的服务，此外SLS和ODPS底层是打通的，所有存放在SLS服务器上的日志数据会被自动离线备份到ODPS中，方便用户做进一步的数据分析。除了ODPS和SLS服务，我们的方案中还使用了RDS（Relational Database Service，关系型数据库服务）以及DPC（Data Process Center，采云间）控制台工具。利用上述提到的阿里云服务，游戏数据分析方案中的架构如图1所示。SLS通过安装在游戏服务器ECS上的Logtail客户端，建立一种类似心跳的方式监听文本日志文件，并按照用户指定的格式将数据抽取后以键值对的形式存放到SLS服务器。每条记录包含了时间、来源ECS IP地址和抽取的键值对信息。ODPS在游戏数据分析中可以被当成是一个大数据分析平台，可以将SLS和RDS数据导入到ODPS中，利用ODPS强大的数据分析能力分析游戏数据。DPC在游戏数据分析中充当IDE角色，除了应用在数据的导入导出，ODPS任务管理，还可以用来做最后的数据分析结果展示。图1 &阿里云游戏分析架构图图2 &游戏数据分析详细步骤接下来详细介绍上述场景中，游戏数据分析的具体步骤，参见图2。我们可以看到，游戏应用服务器在运行期间产生了大量的数据，接下来分别介绍文本数据和关系型数据导入至ODPS的实现步骤，然后结合数据分析的具体场景介绍在ODPS中做数据分析的实现方式。第一，SLS处理文本日志详细步骤。在游戏服务器运行过程中，按照业务逻辑规划，一部分数据将直接写入到文本日志里进行保存。文本日志数据生成在本地指定目录文件中，且文件名按照时间命名，路径格式为/var/log/game/${serverid}/${YYYYMM}/{DD}/{YYYYMMDD.HH24}.log，产生的一条日志记录如下所示：Logtail是ECS上的监听程序，可以配置监听目录和提取的日志内容，例如对上文的文本内容用自定义正则表达式提取出来，内容如图3所示。图3 &SLS Logtail匹配文本日志内容日志被提取出来后，会按照（key：value）键值对的方式保存至SLS指定Category。日志被提取到SLS服务器后，除了每条SLS日志记录被提取的文本内容，还会记录一个时间和IP，这里时间是指数据写入文本日志的时间，IP记录了文本日志来源的游戏服务器IP地址。同时，已经保存在SLS服务器的数据会自动离线保存到ODPS用户指定的Project里面，如图4所示。图4 &SLS自动离线归档到ODPSSLS Category存放的所有记录会自动离线保存到ODPS中，首次数据备份在6个小时内完成，以后每小时SLS的数据会被增量备份至ODPS。第二，RDS处理关系型数据详细步骤。关系型数据是游戏服务器在运行过程中，对用户角色创建和用户消费行为数据的记录，直接通过业务逻辑写到RDS数据库中保存。RDS里面的数据，可以通过阿里云DPC工具，将数据批量定时地导入到ODPS指定Project里，如图5所示。图5 &RDS数据导入ODPSRDS数据导入经过基础配置、列筛选、数据筛选三个步骤后，就可以发布导入计划时间，可以分为每日、每周、每月进行数据导入。关于导入的数据筛选和导入时间的设置，完全取决于用户的使用场景。例如，用于游戏消费数据信息这种实时分析要求较高的数据建议选择每日非活跃时间段定时导入。任务发布后，可以继续通过DPC控制台对任务的执行情况进行查看。第三， ODPS数据分析详细步骤。在游戏服务器产生的文本数据和关系型数据都集中导入到ODPS之后，接下来可以利用ODPS平台本身的产品特性，开始做用户自定义的数据分析。ODPS中常用的数据分析有以下几种方法。ODPS SQL语句查询，能查询满足用户绝大多数的数据分析需求，如图6所示。图6 &DPC 任务执行日志发布自定义UDF任务。UDF是指用户自定义函数处理，例如做一个游戏描述的大小写转换函数，用Java代码编写好函数后，打包成Jar文件发布到ODPS中，然后SQL语句里面就可以直接调用函数功能。发布MapReduce任务。阿里云ODPS MapReduce和UDF功能在Eclipse开发工具中有相应的开发插件，在插件完成安装后，创建MapReduce功能。在创建MapReduce文件后，根据实际游戏数据分析任务，分别完成Map函数和Reduce函数的编码，然后通过Driver类设置运行资源和格式。在Eclipse中完成的MapReudce任务可以打包成为一个Jar文件发布到ODPS指定Project。第四，DPC数据展示。目前DPC的图形化数据展示功能还没有开放，本节将使用表格化数据举例说明DPC数据处理结果。发布任务后，DPC控制台提供查看操作日志的功能，如图6所示。目前，所有子任务执行成功后，数据分析的结果会以表格的形式展现，同时这些数据分析结果也可以通过DPC工具保存至RDS。在RDS中数据的交互性更强，可以利用第三方报表工具做多维度的数据展示。总结阿里云发展到现在已经提供了20多种云产品和服务。这些服务功能选择性多，稳定性好，性能优异，节省了用户使用成本。希望阿里云能推出更多稳定可靠的产品和服务给技术人员更多的选择。玩家指标，一般用于计算与收入相关的指标，如用户平均消费指标（ARPU，average revenue per user ）和每日活跃用户（DAU，daily active users ），也可以用于调查人们如何与游戏系统交互，如用户游戏时间和用户的游戏内好友平均数。性能指标，针对游戏技术和软件框架性能，一般包含游戏在用户硬件平台上运行的帧速率，也被用来在观察打补丁或升级时对用户造成的操作影响。过程指标，针对游戏开发实际过程中的数据指标。TB/PB级别的数据分析耗时太长；时间跨度大的数据分析耗时太长；SQL无法满足所有数据分析需求；海量数据的存储问题。文本日志数据记录的是玩家实时战斗信息、晶钻消费信息和登录状态信息。这些数据在每个游戏服务器上都会产生，遵循用户自定义的数据格式。用户有一组专门的日志服务器和自定义程序在游戏服务器上定时批量抽取这些文本数据存放到日志服务器上。存放在数据库中的关系型数据增长速度通常会比较快。要保证上云后数据分析的效率，因为基于目前使用数据仓库分析的方式，分析日活、月活等信息时平均耗时在几十分钟级别。要提高数据分析的实时性，上云之前，对类似晶钻消费等数据做分析存在至少1个小时的延时，用户希望上云后能得到更加实时的分析结果。
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章