大数据处理

这里说明下当前的面临的环境困局:

• 单表可能超过2~3G/day, 主要玩家打点数据
• 多表需要关联查询, 内部带有强关联( A表依靠B|C表的数据 )
• 数据要求长持久性, 数据需要运营存底且需要保持最少三个月处理
• 已经实行分库分表, 但还是没办法提高数据查询效率

在游戏当中会出现频繁记录打点信息, 用于追踪玩家操作从而还原出玩家具体的操作流程; 特别游戏准备开服时期更加需要玩家打点信息, 如果买量推广效果好的时候单日递增打点数据是十分庞大的.

同时按照运营需求的情况, 也许需要统计玩家对于游戏活动参与度, 方便运营和策划分析总结下次构建出活动.

游戏运营的数据库相比其他更加复杂( 当然比不过更加频繁的 实时IM 方面 ), 其中涉及到:

• 分服: 游戏服务交叉很复杂, 可能涉及到 单服务器分叉多个子服 情况
• 存盘: 游戏相关数据需要保持至少一年, 且数据量及其庞大
• 检索: 关联数据查询十分频繁, 统计日活跃|月活跃|季度活跃交叉查询特别频繁

如果没有概念, 那么以简单案例说明:

# 运营需要做月度玩家盘点, 要求如下:
# 1. 需要查询30天玩家留存, 支持以下维度查询
#   1.1 起始日期( start_time, end_time )
#   1.2 可以包含 全部| 充值玩家 |不充值玩家( is_recharge )
#   1.3 可以筛选指定充值金额区间的玩家统计 ( start_recharge, end_recharge )
#   1.4 支持对应服务器Id查询( server_id )

以此说明表的大概格式如下:

这里分为静态和动态数据, 像是当日计算这种数值可以后台执行脚本实现静态入库实现, 就类似:

# 直接提取充值单数量
SELECT COUNT(`order_id`) as `total`
FROM `order_info`
WHERE ymd = '20241117'

# 获取单个玩家充值数量, 剔除重复
SELECT COUNT(DISTINCT `player_id`) as `total`
FROM `order_info`
WHERE ymd = '20241117'

# 注册玩家信息也是类似

这些静态数据获取相对容易, 但是后面需要对比指定范围批次的玩家就不容易了; 首先需要获取到 20241117 玩家注册玩家账号批次为样本, 后续的 20241118,20241119,20241120,.... 不断计算该样本每天在线活跃批次, 最后确定玩家的流失程度.

简单来说就是在 20241118 需要知道 20241117 这批人还留有多少, 20241119 还留下 20241117 多少, 最后统计该过程丢失多少玩家.

看起来也没什么复杂, 但是加上最开始说的查询条件就麻烦:

• 起始日期( start_time, end_time ) 可选, 代表每次查询该数据的统计都是需要重新抽样出样本数据
• 全部| 充值玩家 |不充值玩家( is_recharge ) 可选, 也是代表要剔除 充值|不充值玩家, 样本会进一步变动
• 筛选指定充值金额区间的玩家统计 ( start_recharge, end_recharge ) 可配置, 样本进一步压缩

那么这种复杂查询的情况, 最后没办法对数据进行静态化, 从而每次抽样数据都需要重新查询比对.

数据抽样, 这是我处理这些庞大数据体验到最符合这个过程的形容词, 立足于某一份数据来进行更加复杂筛选

同时这些数据递增也极其庞大, 可能单月就会递增 10G 左右, 这种情况下的筛选效率更加严峻.

此外这里面可以看到 server_id 情况, 这就是比较常见游戏分库处理方式, 游戏服务会把不同数据单库设定为格式如下:

• game_center_数字: 游戏中心库, 例如 game_center_1 代表 1 号服务器游戏信息存档
• game_log_数字: 游戏日志库, 例如 game_log_1 代表 1 号服务器服务器记录打点数据

有的时候需要去 game_log_xxx 精确查询指定字段条件数据, 这些数据组合起来足够让人发狂, 并且后续业务扩张出来越来越多角色和条件需要限制问题也就越来越大.

亲身涉及到业务, 需要分渠道|子渠道还要筛选不同业务数据, 同时需要筛选十多个条件并且支持同步导出等情况.