GIAC | 大数据分析系统在游戏领域的迭代与实践

导语：6月23日，腾讯游戏数据分析系统负责人周东祥在 "GIAC全球互联网架构大会" 的分享了主题为《大数据分析系统在游戏领域的迭代与实践》的内容，具体的分享视频和PPT可以在大会官网下载和观看。这里主要以陈述的角度把个人的分享的主要观点和概要内容分享给大家，欢迎大家来交流，指正。

给大家说下，我今天分享主要内容，分为三个主要内容：

1. 分析系统在游戏分析的背景和要解决的问题

2. 大数据分析引擎在游戏领域的迭代与实践

3. 分享的总结和未来规划

以数据分析角度来讲，这个是当时大数据技术最原始的技术驱动力。

在业界来讲，不同的行业不同技术环境，数据分析的碰到的问题、所要解决的问题，都有些“共性”和“差异”的方面。

以作为业界最大的游戏运营方的腾讯游戏的数据分析来讲，我们也会碰到“共性”和“差异”问题。

“共性”问题：

数据量大、增量快。腾讯游戏日新增的玩家行为、游戏运行、安全等日志记录数据来讲：日新增 300TB 2W亿条；

“差异”问题：

在互联网行业的运营的APP或者产品来讲，数据维度相对比较固定。因为，产品上的用户行为相对变化小。

但是，区别单一运营的APP，腾讯游戏来讲，一个游戏就是一个APP，一个复杂的、大信息量的APP。

海量玩家同时在线，产生了跟游戏内容相关的独有的、海量的维度。比如：射击游戏、对战游戏、棋牌游戏等，都是由独立、特有的数据维度和数据空间。一个游戏一个世界，数据模型复杂度高。

我们通常曾经一个大型MMOG PC游戏有1300张表；一个王者荣耀的5V5对战表具有430个字段，上百的独立维度和度量，

如果维度组合膨胀将更加可怕，给到大数据分析场景中带来的多维分析也是非常有挑战的。

那么，如何利用大数据分析技术帮助解决游戏业务“共性”和“差异”性问题，使得游戏产品快速、有效的实现游戏精细化运营。

具体来讲，我们通过构建腾讯游戏数据分析服务产品iData 来践行游戏场景的大数据分析系统。

大数据分析系统，在业界经典的构建的来讲，现在已经认知从 BI 到 ABI，进一步提升到 ABI + Science Platform.

那么，iData游戏数据分析产品和平台，我们也提出自己平台的大数据分析能力模型。

核心的理念就是从分析的思路、效率以及专业的层层递进的方式来构建。

具体来讲分析思路提供能力是：

数据可视化：信息整合、描述性分析
数据分析引擎：诊断性、交互性分析
数据科学实验室：预测性、探索性分析

具体的分析思路，我这就不详细讲了。这次，我主要给大家分享iData的

数据分析引擎：诊断性、交互性分析

主要以技术的角度，给大家分享iData的核心自研构建的分析引擎能力，总结一些自我实践的经验，给到大家一些分享。希望对大家有些帮助。

我开始这次分享主要核心内容， 大数据分析引擎的迭代与实践介绍。

以 iData大数据分析能力组成来讲，我们构建了4个核心的分析场景。

离线多维分析
画像分析
跟踪分析
实时多维分析

离线多维分析：用户分群、多维提取、交叉分析、自定义指标能力等。当然，传统意义来讲的OLAP来讲，更多的是指的多维聚合计算也是支持的。因为对于用户来讲，用户更多希望诊断性、交互性分析，是有一个分析流程，而不是简单一个多维聚合形成一个统计图表就结束了。这里就没有特别列出，我更愿意把它划分为信息整合、描述性分析里。个人观点，仅供参考。

画像分析：从用户画像描述、下钻分析、漏斗分析、透视分析。下钻分析相对业界比较统一认知。但是透视分析来讲，是我们独有的定义，其实目前更多以类似 “热力图”方式来表现。

跟踪分析：用户往往希望把每天、常例的分析路径、分析指标等作为每日、每小时来跟踪实现。来代替传统意义上，人每天点击同样的路径的交互分析。同时，我们在分析并发内容上，进行扩展，可以同时扩展近800个指标同时跟踪。

实时多维分析：这个部分更多是以把“离线多维分析”中多维聚合统计+ “跟踪分析” 更加实时化。但随着我们进一步和业务的使用中发现，也希望具备“实时探针”、“实时预测” 能力。把当前实时数据进一步从“实时监测” 升级成为 “实时预测” 能力。

进一步讲，如何把离线多维分析、画像分析、跟踪分析、实时多维分析构建出完整的数据分析的链路。

直接帮助游戏产品自助化、交互式的完成全链路的诊断性分析。

具体iData游戏数据的分析应用场景视图如下：

第一步：我们首先会利用数据分析师们构建大量用户的多维特征多维指标等，以多维筛选、聚合、来实现“用户分群”提取、“明细数据”提取。

第二步：选择用户分群群体，可以有两个方向，一个方向，直接选取跟踪分析的用户指标、特征等。进行常例化的跟踪分析。

当然，可以进行“离线”+“实时”的同时跟踪，这样做的主要目的，就是可以对比用户分群+总体用户的特征、指标等主要差异。

另外一个方向，直接进入画像分析流程，主要进行交互性、诊断性的自助分析，不断以各个数据内容维度进行下钻、透视分析。

最终，探究预期的分析结论。

第三步：可以提取用户对象的多维明细数据，进行与跨团队的数据应用，类似我上面图所讲的DataMore，DataMining，推荐系统进行关联规则投放。同时，投放的数据分析跟踪效果，可以以跟踪分析的方式进行数据分析效果回馈。

当然，是不是就“固化”死了整个分析场景；其实并不是，这里面的分析引擎，你可以自由组合。

比如：

多维跟踪分析到可视化图表
下钻分析到多维提取
透视分析到多维提取
.........

只要数据对象的分析输入输出可以对接，就可以进行自助化的交互性、诊断性分析。

大家可以看到，整个分析路径里就会用到大数据分析引擎，主要用到了三个引擎

离线多维分析引擎 - TGMars
在线画像分析引擎 - TGFace
实时多维分析引擎 - TGDruid

那么为什么是这三个引擎划分？三个引擎怎么样在数据流向上配合的呢？

根据上面的分类，我经过多年的实践经验，自我总结了，现在业界大数据分析引擎的一些分类方法。以便能够在实际场景中，用合适的技术解决实际问题。而不是拿来即用。

大数据分析，尤其现在特别指OLAP来讲，一般都是以时间维度+空间维度来做区分。

以时间轴+维度轴来看：

离线多维分析 - 高维度+远时间
在线多维分析 - 低维度+远时间（因为是不断下钻的过程）
实时多维分析 - 高维度+Now+近时间

这就是这三个引擎划分的理论依据。

那么，我们进一步看三个引擎怎么样在数据流向上配合的呢？

具体来讲，三个引擎怎么样在数据流向上配合。

大家看下面的图就一目了然。

业界数据来源对接大数据分析引擎来讲，基本分两类

实时数据流（kafka以及各种MQ为主，只要实时流动即可）
离线块数据（以HDFS、RDS、文件等）

后面

离线多维分析引擎 - TGMars
在线画像分析引擎 - TGFace
实时多维分析引擎 - TGDruid

三个引擎如何配合，数据流转方向上一些视图，这里就不一一细讲了。大家自己看图很容易理解。

紧接着，我们进入主要技术刨析环节。给到我们多年的技术优化的经验，希望大家有所收获。

首先，介绍下，

离线多维分析引擎 - TGMars

讲这个引擎的具体技术时候，一定有一个具体技术背景或者叫解决技术问题的出发点。

在游戏数据分析领域，我们面临的是每天每个游戏“亿级”海量用户数据。通常来讲，游戏策划和产品需要进行大量“多维分析计算”，尤其以多维提取+多维跟踪分析为主。往往这些，采用业界通用的HADOOP也好，还是Kylin、Clickhouse等流行的OLAP引擎，都无法解决。

jion 操作现在流行的OLAP都不支持。
采用Hadoop MR计算即使支持，也是分钟，小时级别，无法实现“秒级”在线多维分析。

因此，我们研发了离线多维分析引擎 - TGMars 来解决这两痛点。

首先，我们要实现亿级数据在线秒级多维提取分析。

如果以传统的MR计算方式，我们要经历：

从数据加载、Map过滤、内容多维聚合、再shuffling、再Map过滤聚合、Reduce的最终去重。

一个漫长的数据处理过程，根本无法实现秒级。当时我们就思考，如何减少整个流程环节，缩短处理流程。同时，另外一个场景也来了。

如果，我们的用户自己把区分好的用户，进行“多维交叉”的跟踪分析。如果是MR来计算需要做的工作流程将更加繁琐，具体如下：

加载提交用户分群数据、跟所有的以及亿级数据全集进行join的walkthrough的全遍历、再才会进行正常MR流程、Map过滤、内容多维聚合、再shuffling、再Map过滤聚合、最后再Map聚合去重结果。

整个“漫长”过程会做了大量无用计算：

大小数据集的冗余全遍历
过滤聚合经过大量的shuffing
多次的聚合去重

我们根据这两个场景，思考如何解决链条过长问题？如何解决多次shuffling计算问题？

这里面，我分享下，我们解决问题的2个经验。

经验1：

预处理机制
内容分片存储与计算绑定机制

预处理机制：我们把一个游戏的所有亿级用户，做成排序集合，然后按照一定Hash数据切片；例如，我们切分20个分片。

那么每个分片内部也是有序的。同时，用户的多维标签信息也都会绑定和用户存储一起切分到20个分片上。

这样做的好处：

不会再有shuffing过程，
也不会有Map的聚合过程（Group By的过程）；
join操作，也不会全遍历O(N)空间复杂度。
最后Reduce操作也不会有去重。

具体优化策略的好处，我就不一一累述，各位看图。

经验2：

位图索引加速
物化视图

可以这么说，经验一是空间上的优化。虽然有“计算”+“存储”的绑定与分离的业界之争论，我觉得要看实际技术解决场景而论。

位图技术，应该是大数据计算的常用技术，我们采用它也是主要为了加速计算

位操作、计算快速性
更新位图的速度要比内容更新块得多

同时，针对无法进行位图存储的度量操作，更多以位图索引+内容文件方式，做到“动态按需加载计算”。具体看图~ 就不一一说明了。

物化视图，应该是现在数据库技术中的常用方案。

其实OLAP大量的维度聚合、度量统计，都是可以利用物化视图，解决内容大范围加载，数据重复高频率计算。算是OLAP缓存一个思路。

具体，我们的做法是:

时间维度聚合指标值。比如：虽然按天计算维度，可以进一步聚合出每周，月，年的度量计算值。
空间维度规则聚合。比如：是否消费，是否连续消费，最近8天消费等等。减少到日级别位图+内容中进行检索查看，位图直接命中计算即可。

最终，实现效果如下图：

多维提取、多维跟踪分析都实现了秒级别。

总结经验如下：

大家看图，不做累述。

第二个部分，我给大家分享

在线画像分析 - TGFace

同样，首先介绍下，需要解决的背景问题。

在线交互式下钻分析
在线交互式透视分析

首先，我们来看下钻分析，其实，这个部门各个公司、业界都有不同种实现方案。说简单点就是再维度上，不断的做筛选和聚合。那么，我们做的经验分享给到大家。

这里讲到，下钻分析，是否可以“减少冗余数据加载”？

这里构建了基于多维数据的分布式计算画像分析引擎TGFace。

这里分享下，我们的实践经验：

逃不掉的“列示存储”，减少行数据的冗余加载，提升计算效率

还是那个百试百灵的“位图索引”
但是，下钻需要缓存，我们构建了缓存的"动态位图索引"，进一步减少内存加载冗余数据

再次，我们看什么叫做在线交互式透视分析，以及实践经验。

在线交互式下钻分析
在线交互式透视分析

前面的下钻分析，是"维度深度下钻问题"

这里透视分析，是"维度广度并发问题"

对付这个问题，我们唯有一招，快速计算，还是要快。

经验1

两次MR计算（本地优先计算+最后Reduce聚合）
JIT编译SQL加速，字节码执行

最终，我们实现了：

1亿数据6维度1.25秒下钻分析
1亿数据10维度3.4秒透视分析

实现了真正的在线交互

最后一个，我们讲下：

实时多维分析 - TGDruid

这个是我们iData 实时多维分析的结果页面。

希望提供给游戏业务 “更快、更实时的观测分析数据”。

正如我们前面所述，我们希望把当前实时数据进一步从“实时监测” 升级成为 “实时预测” 能力。

因此，我们最近基于FaceBook Prophet 实时预测引擎做实时预测能力。

后面有机会给大家分享iData在实时预测方面的进展，欢迎大家一起交流！

我们在实时多维引擎-TGDruid的实践经验来看，最主要的就是在开源的druid的实时多维分析计算引擎上进行整合优化。

具体优化经验如下：

数据分片数优化
近似UV的统计框架（精确也可）
数据结果自动化索引
大维度计算错误检测
数据自助补录（数据回放）
实时数据跟踪分析能力
基于Prophet实时预测

最后，给大家，把这次分享内容小结下。

我这次分享的是 iData大数据分析引擎的实践内容，我们还有iDataCharts、iDataLab等内容。后续有机会再细化给大家分享。

分享的三个主要的大数据分析引擎：

离线多维分析引擎 - TGMars
在线画像分析引擎 - TGFace
实时多维分析引擎 - TGDruid

未来规划，三个引擎会做升级

大数据生态化、体系化改造，以支持可以开放能力
开源协同，腾讯内外都会，预计下半年在腾讯内
分析引擎可以加科学化、预测可以引导形成决策化

今天就分享这么多，感谢大家！欢迎大家随时找iData和asher交流！