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

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
简介: 37手游大数据平台资深开发工程师史飞翔在实时数仓 Workshop 广州站的演讲。

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

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

点击查看原文视频 & 演讲PPT

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

一、云平台大数据建设背景

1

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

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

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

2

  • 第一、资源成本:

    1. 机器成本高;
    2. 机房成本高,因为有一百台机器要有单独的机房;
    3. 空闲时间多。我们的离线作业大部分在晚上运作,白天的时间基本上是比较浪费的。
  • 第二,人力成本:

    1. 组件多,运维成本高。一个人要负责三四个组件的维护;
    2. 组件学习成本高,一些业务开发的同学会使用我们提供的组件,对于他们来说,会有一定的学习成本;
    3. 开发成本高。
  • 第三,稳定性、扩展性。

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

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

3

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

从技术上:

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

从业务上:

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

4

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

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

5

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

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

二、云平台大数据建设方案

6

先看一下总体方案设计:

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

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

7

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

接下来会讲五个场景。

img

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

img

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

img

看一下应用案例:

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

img

这是第三个场景:

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

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

img

第四个场景:

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

img

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

img

上图是 Lookup 的场景:

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

img

上图是一个实践方式:

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

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

16

先看解决了哪些问题:

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

再看带来了哪些价值?

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

三、应用场景

17

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

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

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

18

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

19

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

20

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

21

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

22

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

四、未来规划

23

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

公司介绍

37 手游是 37 互娱的子公司,主要负责运营,也就是发行业务。在中国大陆地区 37 手游以 10% 占有率仅次于腾讯和网易排第三。现在在非中国大陆地区也已经进入月收入过亿的俱乐部,成功发行了包括《永恒纪元》、《一刀传世》、《斗罗大陆》这几款游戏,当前已经累计 4 亿用户。

点击查看原文视频 & 演讲PPT


Flink Forward Asia 2022

img

img

活动推荐

阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启活动:
99 元试用 实时计算Flink版(包年包月、10CU)即有机会获得 Flink 独家定制卫衣;另包 3 个月及以上还有 85 折优惠!
了解活动详情:https://www.aliyun.com/product/bigdata/sc

image.png

相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
相关文章
|
2月前
|
数据采集 数据可视化 大数据
Python在大数据处理中的应用实践
Python在大数据处理中扮演重要角色,借助`requests`和`BeautifulSoup`抓取数据,`pandas`进行清洗预处理,面对大规模数据时,`Dask`提供分布式处理能力,而`matplotlib`和`seaborn`则助力数据可视化。通过这些工具,数据工程师和科学家能高效地管理、分析和展示海量数据。
75 4
|
1月前
|
数据采集 运维 Cloud Native
Flink+Paimon在阿里云大数据云原生运维数仓的实践
构建实时云原生运维数仓以提升大数据集群的运维能力,采用 Flink+Paimon 方案,解决资源审计、拓扑及趋势分析需求。
18418 54
Flink+Paimon在阿里云大数据云原生运维数仓的实践
|
1月前
|
存储 机器学习/深度学习 大数据
参与开源大数据Workshop·杭州站,共探企业湖仓演进实践
Apache Flink 诚邀您参加 7 月 27 日在杭州举办的阿里云开源大数据 Workshop,了解流式湖仓、湖仓一体架构的最近演进方向,共探企业云上湖仓实践案例。
148 12
参与开源大数据Workshop·杭州站,共探企业湖仓演进实践
|
9天前
|
SQL 监控 大数据
"解锁实时大数据处理新境界:Google Dataflow——构建高效、可扩展的实时数据管道实践"
【8月更文挑战第10天】随着大数据时代的发展,企业急需高效处理数据以实现即时响应。Google Dataflow作为Google Cloud Platform的强大服务,提供了一个完全托管的流处理与批处理方案。它采用Apache Beam编程模型,支持自动扩展、高可用性,并能与GCP服务无缝集成。例如,电商平台可通过Dataflow实时分析用户行为日志:首先利用Pub/Sub收集数据;接着构建管道处理并分析这些日志;最后将结果输出至BigQuery。Dataflow因此成为构建实时数据处理系统的理想选择,助力企业快速响应业务需求。
33 6
|
17天前
|
存储 运维 Cloud Native
"Flink+Paimon:阿里云大数据云原生运维数仓的创新实践,引领实时数据处理新纪元"
【8月更文挑战第2天】Flink+Paimon在阿里云大数据云原生运维数仓的实践
180 3
|
22天前
|
存储 搜索推荐 数据建模
阿里巴巴大数据实践之数据建模:构建企业级数据湖
阿里巴巴通过构建高效的数据湖和实施先进的数据建模策略,实现了数据驱动的业务增长。这些实践不仅提升了内部运营效率,也为客户提供了更好的服务体验。随着数据量的不断增长和技术的不断创新,阿里巴巴将持续优化其数据建模方法,以适应未来的变化和发展。
|
29天前
|
机器学习/深度学习 算法 搜索推荐
从理论到实践,Python算法复杂度分析一站式教程,助你轻松驾驭大数据挑战!
【7月更文挑战第22天】在大数据领域,Python算法效率至关重要。本文深入解析时间与空间复杂度,用大O表示法衡量执行时间和存储需求。通过冒泡排序(O(n^2)时间,O(1)空间)与快速排序(平均O(n log n)时间,O(log n)空间)实例,展示Python代码实现与复杂度分析。策略包括算法适配、分治法应用及空间换取时间优化。掌握这些,可提升大数据处理能力,持续学习实践是关键。
34 1
|
23天前
|
分布式计算 关系型数据库 数据处理
美柚与MaxCompute的数据同步架构设计与实践
数据处理与分析 一旦数据同步到MaxCompute后,就可以使用MaxCompute SQL或者MapReduce进行复杂的数据处理和分析。
|
23天前
|
分布式计算 运维 大数据
混合云模式下 MaxCompute + Hadoop 混搭大数据架构实践。
除了资源效率和成本的优势外,混合云模式还为斗鱼带来了可量化的成本、增值服务以及额外的专业服务。阿里云的专业团队可以为斗鱼提供技术咨询和解决方案,帮助斗鱼解决业务难题。此外,计算资源的可量化也使得斗鱼能够清晰地了解资源使用情况,为业务决策提供依据。
|
2月前
|
存储 大数据 分布式数据库
使用Apache HBase进行大数据存储:技术解析与实践
【6月更文挑战第7天】Apache HBase,一个基于HDFS的列式存储NoSQL数据库,提供高可靠、高性能的大数据存储。其特点是列式存储、可扩展至PB级数据、低延迟读写及多版本控制。适用场景包括大规模数据存储、实时分析、日志存储和推荐系统。实践包括集群环境搭建、数据模型设计、导入、查询及性能优化。HBase在大数据存储领域扮演关键角色,未来有望在更多领域发挥作用。

热门文章

最新文章