37手游基于云平台的大数据建设实践

摘要：本文整理自 37 手游大数据平台资深开发工程师史飞翔在实时数仓 Workshop · 广州站的演讲。主要内容包括：

云平台大数据建设背景
云平台大数据建设方案
应用实践
未来规划

Tips：点击「阅读原文」查看原文视频&PPT～

首先介绍一下背景。我们之前是自建的大数据集群，考虑到集群未来的扩展性、稳定性以及成本问题，决定大数据全部上云，今天的分享就是基于 IDC 集群上云的建设实践。

云平台大数据建设背景

首先看一下这张图，做大数据的同学对这些组件应该都很熟悉，刚开始我们也一样，像动物园一样，管理了很多 “小动物”。

2019 年，我们的很多离线作业是基于 Hadoop 集群做的。基于这个集群之上，我们有一些 OLAP 查询场景，当时可选的组件不多，于是我们用了 Kylin、Druid。但是这只能应对一些简单的场景，复杂的场景还是没办法直接基于这些组件对外提供服务。
2020 年，引入了实时计算，当时用的是社区版 Flink，其中 ClickHouse 跟 ADB 主要是做 OLAP 的查询，另外的 ElasticSearch 是用来存储画像的数据。
2021 年，随着业务场景的需要，我们用到的组件也越来越多，所以不得不选用基于多数据源的查询引擎，于是引入了 Presto，这个时候可以基于 Presto 做一些联邦查询，Hive、MySQL、ADB、ClickHouse 等做一个打通关联。基于 Presto，我们会在上层做一个报表的查询。
2022 年，我们大数据全部上云了，只需要用到三个重要组件：MaxCompute、Hologres、Flink。

以上是我们大数据演进的过程，下面先分析一下 IDC 集群的情况。

第一、资源成本：

机器成本高；
机房成本高，因为有一百台机器要有单独的机房；
空闲时间多。我们的离线作业大部分在晚上运作，白天的时间基本上是比较浪费的。

第二，人力成本：

组件多，运维成本高。一个人要负责三四个组件的维护；
组件学习成本高，一些业务开发的同学会使用我们提供的组件，对于他们来说，会有一定的学习成本；
开发成本高。

第三，稳定性、扩展性：

IDC 集群做扩容时流程很复杂，从申请，到机器的采购，再到部署、上线等，至少要一个月的时间，扩展性很差；
机房部署周期长；
故障率较高。

基于IDC集群的综合评估，跟云上做了一个对比。主要是两个方面：一是技术，二是业务。

右边图是随着节点数的增加自建机房与基于阿里云的对比。在集群节点不断扩大的情况下，可以看到自建机房的单位成本逐渐增高，基于阿里云的单位成本基本稳定不变。

从技术上：

上云后用到的组件很少，维护成本低。
统一套件，统一开发流程，极大的提高开发效率。
实时计算开发更便捷。上面也讲到了，实时计算只需写一条 SQL 就可以了，快捷。
监控齐全。以前任务出现问题很难发现，现在有了配套的监控就可以及时的发现。

从业务上：

可以空出更多的时间做更有业务价值的东西，数据赋能业务。
数据的时效性。之前有的 15 分钟、30 分钟跑一次，现在是实时的，这是很明显的对比。

从上图的对比可以看出，上云之后我们对组件做了简化。

从流计算开始，Flink 社区版、Spark、Storm 直接用实时计算 Flink 替代。
第二是离线计算，之前用 Hadoop、hive、Spark，现在统一存在 MaxCompute。
最后一个是 OLAP 数据库，包括之前的 ClickHouse、Presto、Kylin、Druid 等，现在全部用 Hologres 替代。

总体来说有以下几个方面的变化：

一是效率高。上云之后首先是效率的变化，不单单是机器扩展效率，还有包括开发效率。
二是成本低。我们也和 IDC 集群做了对比，上云之后整体成本会降低。
三是易扩展。现在不管加存储也好、内存或者 cpu 也好，几分钟即可完成扩展。
四是稳定性高。上云之后几乎还未出现过问题。

云平台大数据建设方案

先看一下总体方案设计：

第一条链路是实时流，从 Kafka 过来，经过实时计算，实时计算之后会落到 Hologres。但是有一些场景需要扩展维度，实时计算时会用到配置表，是在 Hologres 基于行存来存储的配置表，通过点查的能力，把配置信息取出来做实时关联，最终落到 Hologres。
第二条链路，可能也是大家常用的（传统的数据库还是要保留），我们会把传统的 MySQL 数据库通过 DataWorks 数据集成同步到 Hologres。
最后一条链路是离线的，Kafka 数据通过 DataWorks 写到 MaxCompute，写完之后会在 MaxCompute 每天定时跑任务来修整第一条线的实时数据，也就是做一个离线的修正。另外我们会把 MaxCompute 里画像数据推到另外两个组件。这里说明一下，这两个组件是为了考虑到双云部署，所以我们考虑到开源的组件，StarRocks 和 HBase，这两块主要是用在画像上。

最后一层是用到 Quick BI 做展示，包括用户画像也是基于 StarRocks 和 HBase 做一个查询。以上是整体的方案，下面讲一下具体的实时数仓和离线数仓。

上面是实时数仓，可以看到主要来源于两个地方，一个是 MySQL，一个是 Kafka。两块数据是通过 Flink 落到 Hologres，从 DWD 到 DWS 再到 ADS 逐层清洗，最终落到 Hologres。
下面是离线数仓，通过 MySQL、Kafka 落到 MaxCompute，在 MaxCompute 逐步分层，最终落到 Hologres，离线这一层会修正实时的数据。

接下来会讲五个场景。

第一个场景，我们用到数据集成，将 MySQL 数据、Kafka 数据通过 DataWorks 的数据集成写到 Hologres，这就是数据同步。第二种方式是 MySQL 的数据可以通过 Flink CDC 特性同步到 Hologres，这个过程只是一个简单的同步，没有做任何数据的处理。下面这些是日常开发的任务。

第二个场景会经过简单的计算，这里并未涉及到数据分层，直接通过简单计算落到实时数仓。有时需要对数据进行维度的扩展，所以我们会在 Hologres 做一个视图，视图进行数据表和配置表的关联。但是这里有一个问题就是会对性能有一个损耗，如果数据量很大，则不建议这个方式。如果是比较小的数据，计算不复杂，可以走这个链路，最终做一个展示。

看一下应用案例：

第一是运营中台的活动，我们在做一个游戏活动时，可能会分 A、B 两个人群做代金券或者礼包的发放，对 A、B 两批人在不同阶段（登录、激活、充值等）进行统计分析，进而分析这个活动效果与收益。
二是苹果后台的数据，通过实时计算得到不同阶段的转化率，包括从展示到购买，从查看到购买，从展示到查看等转化率。
最后是 SDK 埋点，做了一个漏斗的模型，也是看转化过程。从下载、激活、到登录等一系列流程转化率的展示。

这是第三个场景：

此前的方案是把 kafka 作为中间存储，中间层 DWD、DWS 都存储在 kafka 中。这种方案的缺点是很明显的，一旦数据不一致或者数据延迟，很难排查问题。
目前是基于 Hologres 来做的实时数仓，每一层数据都会实时落进去，有问题的时候比较容易追踪。

我们的数仓大致分了这几个域，分别是用户域、设备域、交易域、广告域、运营域、客服域、公共域，以上是数仓分域情况。

第四个场景：

如右上图，多指标合并此前我们会通过双流 Join 来做，假设想通过这个表来看用户登录、激活，但它有两条流，登录是一条流，激活是一条流。我们之前可能是要把这两条流用 Flink SQL 写出来做一个 join，但是这个性能不太好，计算也会翻倍。
新的方案是基于 Hologres 的主键做局部更新，登录这条链路就只做登录分析，激活就只做激活的统计。source 是两个，但是 sink 到同一张表，基于 Hologres 宽表 merge 的能力来实现这个业务需求。

第五个场景，就是刚刚提到的 Kafka 数据有时维度不够，要做维多扩展。所以我们会去 Hologres 里面取行存表，行存表点查的能力很强，通过行存表补充维度信息，最终落到 Hologres 宽表。

上图是 Lookup 的场景：

第一是运营维度的拆解。如何理解右边黑色的部分？在一款游戏发行之后，我们会基于某一个维度做下钻的分析，看某一个游戏，比如 A 游戏下哪个联运商的占比比较高，再根据这个联运商做进一步的下钻分析。
二是游戏首发时，我们可以实时地关注这个游戏的玩家动向。
最后是广告效果的数据，当投放一个广告，我们要知道这个广告后期的留存情况、LTV，以及媒体测的曝光、点击、下载等数据。

上图是一个实践方式：

首先，上游是 Kafka 的源表。首先需要建一个 kafka 的源表，其次是建立 Hologres 目标表，最后是写一条业务逻辑 SQL，把数据 insert 到目标表，实时计算过程就完成了。
还有宽表 merge 场景，上面提到我们的源是有两个 Kafka，kafka 1 和 kafka 2，分别从两个 source 端读数据，然后 sink 到同一个 Hologres 的目标表，但是一定要保证主键是相同的。
第三是通过 Flink 消费 Hologres Binlog 的能力，这种场景一般是应用到充值类、订单类的数据。因为这种数据会变更，所以不像 Kafka 里面日志类的数据那么简单的处理，这时会用到 Hologres 的 Binlog，等于把 MySQL 的 Binlog 做了同步，所以 Hologres 也可以拿到 Binlog，可以直接通过这个能力去查这个表。

最后，看一下实时数仓对我们有哪些影响。

先看解决了哪些问题：

一是数据存储的问题，以前存储组件非常多，Kylin、Druid、MySQL、Presto 等，现在统一存到 Hologres。
二是千万级维表变更的问题，我们的量级非常大，大概能到 5000 万，数据要去关联 5000 万的配置表，并且要实时地做这个事情，这在之前很难做到。
三是查询效率的问题。对业务来说，查询的时候非常慢，这个问题能通过 Hologres 高性能的查询解决。
最后是成本问题，因为 IDC 集群的成本，包括维护成本，还有后期扩展成本都是很高的。

再看带来了哪些价值？

一是数据存储统一。打破了数据孤岛，37 域的数据是全通的。
二是数据更加实时。之前每天的数据会半小时或者十五分钟跑一次，现在是实时计算，所见即可得，尤其是游戏首发的时候我们对数据的实时性要求非常高。
三是查询效率。旧的引擎很难支撑业务的快速发展，新的数据库 Hologres 在查询性能上体验极佳。
最后是开发流程简化。我们之前的开发流程是很复杂的，现在只需要实时计算这块写一个 SQL 就可以搞定了。

应用场景

上图是关于游戏的生命过程。

一个游戏的诞生首先是从创意开始，怎样策划一个游戏。
策划完第二步就是做研发，一个游戏能不能长期留住玩家，这一步是最关键的，包括关卡设置，关卡难度，游戏画面等等。
第三步是游戏发行，研发完成后即是游戏推广了，不然就算这个游戏再好玩，没人知道、没人玩也是没有收益的，酒香也怕巷子深。
发行完后最关键的就是如何留住玩家，如何长期留住玩家，在线游戏运营是重要的一个环节，维护一个良好的游戏生态。
最终是获益。

因为我们是一个发行公司，所以我们主要在做买量优化、异常检测、高价值玩家的预测、用户画像、效果分析等等，重点是在推广和运营。接下来重点讲买量优化以及游戏运营。

上图是买量优化简单的流程图。我们会拿到一个玩家的历史数据，然后去分析特征，再结合运营平台的运营数据做一个预测，预测哪些是高留存玩家。然后会基于这些高留存玩家在投放平台进一步的投放相关游戏，最后基于投放效果数据进行反复的迭代模型、分析效果等。

上图是自助分析的场景，我们的数据后台大部分是给 B 端用的，此前的一个开发模式是比较传统的，数据开发同学负责报表数据的开发，展示由前端去做页面的开发，业务从提一个需求到排期再到交付，这个过程可能要花 1-2 周。但是有了自助分析平台，我们用的是 Quick BI，业务提需求后只需要做数据集就可以完成自助分析，大概半天的时间就可以完成，甚至业务自己也可以完成一些简单的需求。

上图是精细化运营，当我们做一个活动，比如发放代金券或者礼包的时候，会跟踪发放的后续情况。这里做了 AB 测试，我们先圈选一部分人，再分成 AB 两个批次，每批次 50%，后续会对这些人做触达，比如发短信，或者在游戏里发代金券等。做完这些活动之后再去统计分析活动效果，右边就是统计的结果，看看做这个活动对玩家会产生怎样的影响。

这是我们用到的一个画像数据，这个画像数据其实做挺久了，从 2019 年就开始做，并且在不断的迭代，所以现在画像是很完善的。不但可以分析基础的数据，还会基于人群去做分析。基于复杂的条件圈选人群包，因为基于人群包做投放，所以还会对人群包后续的情况做一个效果的分析，包括留存的情况，LTV 数据等。

上图是智能诊断，大家应该也会遇到这样的问题，如果数据有问题，一般得等到业务发现之后才进行反馈。而我们在做的这个事情，可以比业务更早发现异常的数据，这就是智能化的诊断。像右边红色部分那里一样，自动检测出异常点。比如发行了一个游戏后，某一天或者某一刻充值突然下滑（当然也有可能是上升），想知道哪些指标的影响比较大，就可以基于异常点做一个更详细的归因分析，比如我们分析出这个游戏是《斗罗大陆》或者《云上城》导致的，可以自动分析出来每个维度对游戏指标产生价值的排名，看哪些维度对这个影响最大。

未来规划

首先，我们在智能投放方面做得还不够好，所以想在智能方面投入更多的精力和时间。比如 37 手游的用户数据跟媒体数据做一个打通，这样不但可以对自己已有的画像人群分析，还可以结合媒体画像指标做进一步分析。有了这些数据可能对投放的效果也会有很大的提升。
第二，智能运营。现在做的事情是每个人发送代金券、礼包，其实都是统一的，我们未来想做到千人千面，每个人发不同的代金券，不同的礼包，类似于个性化推荐，进而来提高收益。
第三，智能诊断、归因分析。在海量的数据，海量的指标中，数据波动异常如何及时发现；发现异常后如何分析导致异常的原因等。目前做的还是比较初阶，这也是我们未来重点突破的地方，智能归因、智能诊断、智能化洞察。