大咖与小白的日常:教你打造一站式高性能游戏运营分析平台

简介: 真实案例乐元素创立于2009年,是一家以游戏研发运营为主营业务的游戏公司,同时业务涵盖动画作品、授权商品、音乐、演唱会、广播剧等在内的知名互动娱乐公司 。乐元素旗下拥有《开心水族箱》、《开心消消乐》、《海滨消消乐》 《Merc Storia》、《Ensemble Stars》 等多款畅销产品,以及《...

真实案例

乐元素创立于2009年,是一家以游戏研发运营为主营业务的游戏公司,同时业务涵盖动画作品、授权商品、音乐、演唱会、广播剧等在内的知名互动娱乐公司 。乐元素旗下拥有《开心水族箱》、《开心消消乐》、《海滨消消乐》 《Merc Storia》、《Ensemble Stars》 等多款畅销产品,以及《星梦手记》动画 和卡通形象品牌“消消乐萌萌团” 。其中,《开心消消乐》更是堪称国民级三消游戏

面对多款DAU超千万的热门游戏产品,每天产生海量的游戏日志数据,如何通过数据运营获引起家对兴趣,提升游戏体验,降低用户流失成为决定游戏产品成败的关键。然而数据规模巨大、分析模式复杂,对游戏业务的运营分析数据产品形成了巨大的挑战。一方面手游产品迭代速度快、平均生命周期短,市场、运营需要快速的对玩家动态做出判断,这要求数据流转速度必须要快;另一方面,产品、用户、营销运营关注多数据面广,既需要通过宏观数据了解产品健康状况,有需要通过多种微观数据溯源问题原因,要求数据产品需要提供高灵活性的计算能力

基于此背景,乐元素数仓团队升级技术架构,通过阿里云Hologres替换开源Hive+Presto架构,支持运营分析更加高效、实时,显著提升运营效率,进一步辅助业务精细化运营。

急需一个实时、灵活、可扩展的游戏数据分析平台

在乐元素手游类产品运营分析中更加重视玩家数据的多维数据上卷、下钻分析能力。例如,运营同学在发现用户流失严重的游戏关卡时,需要迅速通过调整关卡设置,增加游戏道具等方式,保持玩家对游戏的关注度。市场、产品运营分析的主要内容涵盖以下几方面:

  1. 用户相关部分:活跃用户/设备数、用户活跃度、关卡留存率、流失率及实时在线玩家等统计指标;

  2. 推广效果分析:如抽奖活动的点击率,参与率等分析评估对活跃度、用户转化的效果;

  3. 付费分析:付费用户结构、付费用户行为等;

在数仓构建方面,手游数据主体来源于各款游戏的埋点数据、离线用户标签特征、业务数据。游戏行业数仓有别于典型的电商、广告业务的数仓模型,游戏相关数仓模型构建以玩家行为事件数据为核心,特征维度数据为辅助,同时游戏之间玩家数据关联性较弱,游戏数据彼此正交,形成如下图所示的主要数仓结构:

乐1.png

结合业务痛点,乐元素数仓研发、分析工具团队、运维团队需要为运营团队提供具有以下能力的自助分析平台:

  1. 高实时性:面对海量的日志数据,需要保障实施入库,数据产生即可用;

  2. 高灵活性:面对指标数据、多维分析等复杂场景,能提供即席计算能力和丰富的SQL生态支持;

  3. 高扩展性:产品、分析需求增长的同时能有效控制资源成本,集群规模扩充时能提供完善的监控和运维工具;

Hologres替换Hive+Presto助力实时数仓架构升级

数仓架构探索

游戏业务的数据层应用主要为产品运营、市场运营同学提供高效、灵活的即席查询能力,满足报表、分析等常规业务场景,同时在新品发布、活动推广等场景中,也需要第一时间提供用户的行为趋势,方便运营快速了解用户行为数据,而如果提供天级或者小时级的数据更新,往往不能满足业务实时性的要求。因此,在游戏业务的数据应用层中查询的灵活性、数据的实时性是核心诉求。

针对应用层特点,实时数仓探索的初期为了满足离线报表和实时查询的需求。系统架构的示意图如下:

  • 我们使用自建的HDP集群作为数据存储底座,以提供离线ETL、数据报表等需求;

  • 使用Presto读取HDP数据方式,为自助分析平台提供即席分析能力。

  • 对于实时性要求高的活动统计、流量分析业务,埋点数据通过实时数据链路,将近N分钟数据写出到指定的HDFS文件上,然后在Hive中创建分区并关联到该文件上,满足查询实时数据需求;

乐2.png

整个架构中,实时和离线采用两套链路:

  • 实时数据流:游戏服务端日志、业务系统Binlog同步到Kafka,通过Flink关联维度进行实时ETL,持久化到OSS上每分钟创建的文件中;定时将分钟级文件通过新分区方式追加到Hive的事实表分区中,在计算端通过Presto查询Hive数据提供分钟级实时能力。

  • 离线数据流:游戏服务日志、业务系统数据,离线同步至自建的HDP离线数仓,离线进行ETL用来提供历史数据分析能力;

上述架构与2019年投入生产,系统上线初期业务规模较小,运行相对稳定。但随着诸多爆款游戏的上线,数据规模迅速上涨,基于HDP的系统架构出现多次节点故障,问题排查时间较长,系统升级维护的成本很高;另一方面,计算、存储资源变得更加不匹配,系统的扩展性也面临一定挑战。总结来说,主要的问题有以下三点:

  1. 数据流转慢:受限于实时链路实现方案,实时链路端到端的延迟在分钟级左右,流量高峰时段延迟会更长;

  2. 计算性能差:Presto引擎兼容性虽好,但性能远不如其他开源OLAP引擎,如ClickHouse、Hologres等;另一方面,实时数据链路架构文件数过多,对计算性能影响较大;

  3. 运维成本高:自建HDP版本较老,出现问题排查成本高,且Hortonworks被Cloudera收购之后,后续维护计划不明朗;集群规模不断扩大,出现链路故障恢复时间长,运维成本高;

  4. 开发成本高:需要定制开发一些模块来处理实时数据加载调度等功能,需要投入一些人力开发运维;同时链路较长,监控成本也比较高;

分析引擎选型

由于历史技术架构的种种问题,我们开始调研业界实时数仓的实践模型,希望引入一个全场景的OLAP引擎,来解决数据时效性、计算性能、成本三方面问题。在一段时间的摸索后,我们进行了ClickHouse、Presto、Hologres的多方面对比,Hologres相对于另外两个引擎优势较大,主要变现在以下几方面(性能数据为业务实际测试结果):

  1. 实时写入性能较强,  单Core可以支持2万~3万RPS的写入,并且与Flink可以无缝集成,能很好的满足实时数仓的需求;

  2. 在相同规模性资源下,对业务系统中计算量较大的UV统计、留存计算、漏斗计算等场景进行压测,性能项目Presto提升了5~10倍,96核的Presto集群完全可以使用64核的Holgores集群替换;

  3. Hologres的系统能力,如资源队列、慢Query监控、连接管理等,可以大大提升管理效率;

  4. Hologres原生内置游戏行业场景化的解决方案,如留存分析、人群画像等组件支持,对业务提效有很大帮助。

OLAP 引擎

实时写入

计算性能

运维成本

业务开发成本

Presto

需要自建Kudu集群

较高

ClickHouse

较高

较高

Hologres

免运维

较低

数仓架构升级

因此,我们最终决定使用Hologres替换现有基于Hive + Presto构建的实时数仓架构,整体系统架构演化为如下结构:

  • 由Hologres作为统一的数据存储,存储Flink实时写入的数据以及离线加速的数据

  • 通过Hologres对接数据应用层,提供统一对外的数据出口,满足运营的分析需求。

乐3.png

上述系统架构在2022年5月上线,对高频计算场景优化效果明显,即席分析平均耗时降低数倍。截止目前,《海滨消消乐》、《偶像梦幻季》等游戏已经完全迁移到Hologres架构。

  • 依托Hologres数据加密的功能,我们也部署了海外机房,快速支持了海外业务扩展。总体来讲,对业务运营效率、研发迭代效率提升明显。

  • 从系统指标层面看,初期使用128core的Hologres实例,可以承载离线数据高压力导入,导入RPS约400万+;实时数据承载了当时10k ~ 20k实时读写请求,单实例数据规模目前为15~10TB左右;高频计算场景如近7天留存、近30天漏斗等计算时长均缩短至10s以下,基数运算可以在毫秒级完成。

典型的游戏行为分析场景实践

以下,我们针对一些典型的场景介绍下Hologres上的业务落地方案。选择留存分析和漏斗分析作为示例进行介绍:

留存分析

留存分析是手游中统计用户参与度、活跃情况的一种重要的分析模型,通过留存分析可以了解手游用户的留存率,流失率情况,针对流失率用户群进行其他潜在维度的上卷统计,可以进一步探索用户流失原因。

乐4.png

在留存分析中,我们针对玩家在一个时间段内的时间进行统计,指定一个初始事件和多个回访事件,通过统计玩家在指定时间段内的事件序列计算用户留存指标。初期基于Presto构建的自助分析平台,留存分析只能通过用户事件表的反复JOIN来计算, 而事件表本身数据规模非常大(百亿级别),JOIN运算开销非常大,对集群造成很大压力。

计算引擎替换成Hologres后,可以直接使用流量分析函数进行计算,函数通过对时间表的一次扫描完成留存计算,大大提升了计算效率,在典型的留存计算场景中,响应时间降低了一个数量级,同时,流量分析函数均支持延伸计算,分析师可以对对留存客群进一步分析。

例如,计算用户登录到用户进入游戏主场景的多日留存情况,并对每日的留存用户统计游戏分享次数的计算中;基于Presto我们需要通过Join来完成留存人群的过滤,再JOIN一次计算游戏分享事件次数;计算逻辑示例如下:

WITH init_events AS (
  SELECT uid, ds AS init_date
  FROM dwd_events
  WHERE ds BETWEEN '2021-07-14' AND '2021-08-13' AND event_id = 'sdk_login'
  GROUP BY 1,2
), -- 初始行为
return_events AS(
  SELECT uid, ds AS retention_date
  FROM dwd_events
  WHERE ds BETWEEN '2021-07-14' AND '2021-08-20' AND event_id = 'app_lifecycle'
  GROUP BY 1,2
), -- 回访行为
mertic_events AS (
  SELECT uid, ds
  FROM dwd_events
  WHERE ds BETWEEN '2021-07-14' AND '2021-08-20' AND event_id = 'sdk_share'
) -- 统计维度
SELECT i.init_date,
       COALESCE(COUNT(CASE WHEN r.retention_date - i.init_date = 1 THEN 1 ELSE NULL END), 0) retention__1, 
       COALESCE(COUNT(CASE WHEN r.retention_date - i.init_date = 3 THEN 1 ELSE NULL END), 0) retention__3,
       COALESCE(COUNT(CASE WHEN r.retention_date - i.init_date = 3 THEN 1 ELSE NULL END), 0) retention__7
FROM init_events i -- JOIN 事件表,关联回访行为
JOIN (
  SELECT r.*
  FROM return_events r -- 关联统计维度
  JOIN mertic_events m ON r.uid = m.uid AND r.retention_date = m.ds
) r ON i.uid = r.uid
GROUP BY i.init_date;

通过Hologres的留存函数进行延伸计算时,可以通过range_retention_count函数直接计算留存人群,该函数通过一次表扫描即可完成留存运算,效率非常高,运算逻辑示例如下:

WITH retention_detail AS (
  SELECT uid, 
         to_timestamp((unnest(detail) >> 32) * 86400)::date AS init_date,
         to_timestamp((unnest(detail) & 4294967295) * 86400)::date  AS retention_date
  FROM (
      SELECT uid, 
             public.range_retention_count(
              ds >= '2021-07-14' AND ds < '2021-08-13' AND event_id = 'sdk_login', -- 初始行为
              ds >= '2021-07-14' AND ds < '2021-08-20' AND event_id = 'app_lifecycle', -- 回访行为
              ds, 
              ARRAY[1, 3, 7],  -- 计算1、3、7天的留存
              'day', 
              'expand'
            ) AS detail
      FROM dwd_events
      WHERE ds >= '2021-07-14' AND ds < '2021-08-20'
      GROUP BY uid
  ) r
)
SELECT  r.init_date, 
        COUNT(CASE WHEN r.retention_date - r.init_date = 1 THEN 1 ELSE NULL END) AS retention_1, 
        COUNT(CASE WHEN r.retention_date - r.init_date = 3 THEN 1 ELSE NULL END) AS retention_3,
        COUNT(CASE WHEN r.retention_date - r.init_date = 7 THEN 1 ELSE NULL END) AS retention_7
FROM retention_detail r
JOIN dwd_events m ON r.uid = m.uid AND r.retention_date = m.server_time::date  -- 关联统计维度
GROUP BY r.init_date;

漏斗分析

在游戏玩家的转化率稳定阶段,漏斗分析可以应用于多个流量采渠道评估转化效果,同时对于新用户的转化过程,通过漏斗分析,可以找出转化过程中用户的流失环节,进行及时的查漏补缺。

乐5.png

初期使用老架构的自助分析平台,需要针对性的开发UDF,用来完成漏斗分析计算。计算引擎升级成Hologres 后可以直接使用windowfunnel漏斗函数进行运算。同时Hologres内表可以通过clustering_key 指定数据排序字段、通过event_time_column可以实现数据分区内更细粒度的数据过滤,诸多特性都可以直接应用在windowfunnel的计算中。替换成Hologres引擎后,漏斗分析的性能也有5倍以上的提升。

升级数仓架构,业务运营效率提升10倍+

自助分析平台交互式分析引擎底座自2022年5月投入生产以来, 运营团队、产研团队对平台都给予了很高评价;从整体数据服务角度,使用Hologres进行技术升级带来诸多好处:

  1. 运营效率显著提升:在基础的用户分群、活动分析、用户留存、漏斗分析场景中,计算耗时都有数倍的提升;其中留存、漏斗计算性能提升近10倍。

  2. 平台稳定性提升:基于Hologres的引擎,完全可以承载高峰时期实时写入压力,相对历史架构有质的改善;同时,极大降低自建系统的运维成本,高峰时期系统的弹性扩缩容能力也能在分钟级完成,大大提升数据产品的稳定性、扩展性、可运维性,产研同学得以将更多精力,投入到数据研发方面;

  3. 成本节省:升级使用Hologres为分析引擎后,整体节约约50%机器成本,年节约成本数十万元。

了解Hologres:https://www.aliyun.com/product/bigdata/hologram

相关实践学习
数据库实验室挑战任务-初级任务
本场景介绍如何开通属于你的免费云数据库,在RDS-MySQL中完成对学生成绩的详情查询,执行指定类型SQL。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
相关文章
|
1月前
|
数据安全/隐私保护
平台介绍-搭建赛事运营平台(1)
平台的一个很重要的市场方向是为企业搭建各类运营平台
|
1月前
|
存储
|
1月前
|
运维 监控 小程序
|
1月前
|
存储 缓存 前端开发
平台介绍-搭建赛事运营平台(8)
提到了字典是分级的,本篇具体介绍实现
|
1月前
|
前端开发 Java Maven
平台介绍-搭建赛事运营平台(3)
上文介绍了品牌隔离的基本原理,就是通过不同的前端和微服务来实现
|
1月前
|
存储 SQL 前端开发
平台介绍-搭建赛事运营平台(2)
平台建设的首期就有两个品牌入驻,品牌J和品牌K,第三个品牌正在协商中
|
1月前
|
存储 数据库
平台介绍-搭建赛事运营平台(4)
存储结构是赛事运营平台的核心设计内容。
|
弹性计算 运维 Shell
《泛娱乐行业技术服务白皮书》——四、泛娱乐业务保障与调优最佳实践——4.1游戏运维SRE实践——4.1.3游戏部署的自动化实践
《泛娱乐行业技术服务白皮书》——四、泛娱乐业务保障与调优最佳实践——4.1游戏运维SRE实践——4.1.3游戏部署的自动化实践
152 0