海量游戏日志的存储与分析了却了谁的心事？

数据、云计算改变游戏行业

我们先看一张图，这种图是国外应用市场的一个统计：统计了最近4年中，一款游戏从上架到达到90%下载量持续的时间长度，横轴代表的是年份，纵轴代表的是持续的周数。在2012年，一款游戏平均可以持续180周（也就是说到了2014年仍有人下载），但这个比例每年在持续下滑，到2015年该区间已经到了24周，也就是说用户进入了快餐式消费的时代。

不管背后的原因是什么，但从整个趋势来看游戏行业已经从卖方市场（20年前游戏卡带相互借阅，一卡难求），到现在的买房市场。以用户为中心、以需求驱动来开发游戏。

第二个趋势是：云计算改变了行业，一个显著特征是游戏部署、上线的时间缩短了。原先繁重运维工作进一步地减轻，传统意义上运维变成了运营工作。这是时代的挑战，也是全栈工程师的幸运。

刚才说两点更多的是共同面对的问题，第三点就是大数据制造的机遇了。我们来把2015年的24周打开看一下，看看机会再哪里？游戏一般有4个阶段：研发、增长、成熟、衰退。在增长阶段我们会遇到模仿者出现，抢占我们的市场份额，怎么去应对模仿者？少犯错、离用户更近一些，实时地更改自己的运营策略。

游戏行业变化激烈，但用户始终不变

虽然市场很激烈，但20多年来用户的习惯仍然不变。我们可以看下这副漫画。用户首先会尝试下载demo，之后会喜欢上游戏，和游戏朝夕相处，某些热爱的玩家会在facebook/twitter等传播游戏、引入更多的玩家，最近为游戏付费。

游戏行业变得越来越激烈，但用户始终不变

为了能够让用户一步步爱上我们的游戏，团队中不同的人在不同方面进行合力。让我们来看一些例子，不同的人会关注什么。

游戏总监：Conversion Rate，ARPU，ARPPU，UAC
运营：DAU，MAU，PCU
渠道：CTR，CVR，CPI
程序/产品：EED，XED，Outbound Message Per User，Message Conversion Rates

让我们来看一些关注的例子：

1.
FarmVille（开心农场）DAU增长下背后的原因

2.
运营眼中：推广路线，一个职业玩家的道路，一个页游玩家的道路，看看你在哪个阶段呢？

3.
FPS游戏统计各道具的平衡性，以及关卡的难度设定

收集用户行为、并优化游戏的整个过程

为了拿到以上结果，游戏团队需要做什么事情？我们可以大致拆分成三个过程：

1.
在游戏开发阶段埋点

2.
在各个渠道收集数据。

3.
对数据进行多个维度的分析，拿到结果采取行动。

在整个过程中串起用户端和服务端最重要的点就是日志数据。

事物的两种状态：切片(Snapshot)状态和增量日志

为了更好理解日志和游戏的关系，让我们来看下什么是日志数据，他和游戏之间是什么关系。

游戏在用户端看起来是两个行为的交替，行动、绘图。当移动鼠标、点击键盘时我们改变了主人公的位置和状态，之后渲染引擎进行了绘图。我们可以在一个时间点上对游戏的状态进行采样，例如10：06分，游戏中所有主人公的位置、金钱和手持武器如下。状态可以反映一个时间点下系统的全貌。

日志是状态与状态之间的变化量。例如10点-10点06分这个时间上用户做了哪些操作？日志相比状态最大的好处是，能够记录整个细节。

除了刚才提到的帮助运营、渠道更高效地运作，日志对游戏还有什么用？

1.
帮助用户：

找寻丢失：装备掉了。
修复数据：机器当机数据丢失了，可以通过日志来进行还原。

2.
定位异常：找到偷盗、作弊等行为。

3.
广告：

没有打赢Boss：缺少什么道具。
用户画像：年龄、性别、什么是你的菜？

4.
日志可以帮助运维：

用户反映卡，在什么环节。
登陆失败，背后是什么原因。

日志处理面临着多种挑战

日志有那么多的作用，那处理起来有哪些挑战呢？

第一个挑战和日志产生相关，游戏涉及到方方面面的合作。例如涉及游戏发行商、移动端、

网页端、服务器端等。因此要从多个维度、多个渠道来收集日志，对于每一种日志有独特的处理方法：例如为了分析渠道我们需要在网页埋点；为了拿到用户的行为，我们需要从移动设备、服务端等记录玩家轨迹；为了分析服务的稳定性，我们需要观察请求的延时等特点。

在这里我们需要使用一个统一的数据模型，支持各个渠道的数据通道来完成统一大事。

第二个挑战来自规模、性能和稳定性：举一个直观例子，假设每秒钟我们需要收集一个用户1KB数据，在100W同时在线的情况下，这个数字就是100MB/S处理流量。对处理的挑战难度不小。如何在数据规模增长的情况下，保持性能的稳定性，是工程师需要关注的。

第三个挑战来自于需求，在之前我们提到了游戏团队中不同的人对于需求的产出是不同的。比如对访问日志，运营的需求是统计活跃人数比例，运维关系的是延迟和访问状态，开发关心的点是哪些资源是热点，需要进行优化。因此我们需要对一份数据，支持多种处理、统计的方法。

日志服务

我们来看看阿里云日志服务怎么帮助解决这类问题。在开放在阿里云官网之前，日志服务已经在阿里巴巴内部经历了3年多的历练，达到行业领先的水平。

日志服务主要提供三个主要功能：

日志收集与实施消费的LogHub

打通日志与数据仓库的LogShipper

提供海量日志查询与分析的LogSearch

LogHub是日志服务最核心的功能，他将日志源与日志消费者通过统一数据模型串联起来。最大的一个好处是把数据管道化，标准化。这根管道是大容量、高可靠、并且弹性伸缩的，用户不用去关心数据量、如何接上等问题，就能直接使用。LogHub有10+种语言SDK，提供Agent并支持第三方Agent、Syslog，WebTracking等协议。在消费端对接了10+种下游，包括开源界非常火的Spark、Storm等流处理框架。

LogShipper提供了LogHub管道数据落地到存储的功能。目前与OSS、ODPS、OTS等海量存储系统打通。可以通过MapReduce、Hive等方式进行数据处理与分析。

LogSearch是一个附加功能，可以选择将LogHub中数据索引并查询，例如我们对App、Error等日志进行索引，可以在发生问题时进行快速定位于查询。在阿里内部我们将关键日志从几千台机器中集中式收集并索引，达到百TB规模。

LogHub（日志通道）与日志基础概念

日志是一个只能增加的，完全按照时间排序的一系列记录。看起来如下：

日志顺序由“时间”来确定，从图上可以看到日志从右到左的时间顺序，新产生的事件被记录，过去的事件渐渐远去，但它记录了什么时间发生了什么事情，这无论对于计算机、人类、还是整个世界而言，是认知与推理的基础。　　

LogHub（日志通道）数据模型

日志通道基本的概念和数据模型如下：

1. 日志（Log）：日志为日志服务中处理的最小数据单元。日志服务采用半结构数据模式定义一条日志，包含时间字段以及一个Json组成的KeyValue Pair 。

2. 日志组（LogGroup）:一组日志的集合，写入与读取的基本单位。日志组限制为：最大4096行日志，或10MB空间。

3. 分区（Shard）：每个日志库下读写基本单元，用户可以指定每个日志库下分区数目。每个分区能承载一定量的服务能力。

4. 日志库（Logstore）：日志库为日志服务中日志数据的收集、存储和查询单元。每个日志库隶属于一个项目，且每个项目可以创建多个日志库。用户可以根据实际需求为某一个项目生成多个日志库，其中常见的做法是为一个应用中的每类日志创建一个独立的日志库。例如，假如用户有一个“big-game”游戏，服务器上有三种日志：操作日志（operation_log），应用程序日志（application_log）以及访问日志（access_log），用户可以首先创建名为“big-game”的项目，然后在该项目下面为这三种日志创建三个日志库，分别用于它们的收集、存储和查询。

5. 项目（Project）：项目为日志服务中的基本管理单元，用于资源隔离和控制。用户可以通过项目来管理某一个应用的所有日志及相关的日志源。