37手游云平台基于Flink+Hologres大数据建设实践

本文涉及的产品
实时数仓Hologres,5000CU*H 100GB 3个月
简介: 本文介绍37手游云平台基于Flink+Hologres大数据建设实践

1. 公司介绍

37手游是37互娱的子公司,主要负责运营,也就是发行业务。在中国大陆地区37手游以10%占有率仅次于腾讯和网易排第三。现在在非中国大陆地区也已经进入月收入过亿的俱乐部,成功发行了包括《永恒纪元》、《一刀传世》、《斗罗大陆》这几款游戏,当前已经累计4亿用户。
37手游之前是自建的大数据集群,考虑到集群未来的扩展性、稳定性以及成本问题,决定大数据全部上云,本次workshop的分享就是基于IDC集群上云的建设实践。

1.1 37手游云平台大数据建设背景

1.1.1 痛点:自建集群组件多,架构复杂,成本高

首先看一下这张图,做大数据的同学对这些组件应该都很熟悉,刚开始我们也一样,像动物园一样,管理了很多 “小动物”。
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. 资源成本:
  • 机器成本高;
  • 机房成本高,因为有一百台机器要有单独的机房;
  • 空闲时间多。我们的离线作业大部分在晚上运作,白天的时间基本上是比较浪费的。
  1. 人力成本:
  • 组件多,运维成本高。一个人要负责三四个组件的维护;
  • 组件学习成本高,一些业务开发的同学会使用我们提供的组件,对于他们来说,会有一定的学习成本;
  • 开发成本高。
  1. 稳定性、扩展性。
  • IDC 集群做扩容时流程很复杂,从申请,到机器的采购,再到部署、上线等,至少要一个月的时间,扩展性很差;
  • 机房部署周期长;
  • 故障率较高。

上云需求:低成本、运维简单、可扩展

基于IDC集群的综合评估,跟上云在技术和业务做了综合对比。下图是随着节点数的增加自建机房与基于阿里云的对比。在集群节点不断扩大的情况下,可以看到自建机房的单位成本逐渐增高,基于阿里云的单位成本基本稳定不变。
3
从技术上:

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

从业务上:

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

从下图的对比可以看出,上云之后我们的大数据组件变得更加简化了。

  1. 流计算将Flink社区版、Spark、Storm直接用阿里云实时计算Flink替代。
  2. 离线计算之前用Hadoop、hive、Spark,现在统一使用MaxCompute。
  3. OLAP数据库查询,之前使用ClickHouse、Presto、Kylin、Druid等复杂的组件,现在全部用Hologres 替代。

4

总体来说37手游上云之后,云平台有以下几个方面的变化:

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

5

2. 云平台大数据建设方案

2.1 云平台整体设计方案

先看一下总体方案设计
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,离线这一层会修正实时的数据。

2.2 实时数仓典型应用场景

接下来会讲上云后的实时数仓五个典型应用场景的具体实现。

2.2.1 场景1:实时数据入仓

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

2.2.2 场景2:实时计算入仓

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

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

img

2.2.3 场景3:Flink读Hologres Binlog实时数仓分层

此前的方案是把 kafka 作为中间存储,中间层 DWD、DWS 都存储在 kafka 中。这种方案的缺点是很明显的,一旦数据不一致或者数据延迟,很难排查问题。目前是基于 Hologres Binlog来做的,通过Flink消费Binlog,每一层数据都会实时落进去,有问题的时候比较容易追踪。支撑用户域、设备域、交易域、广告域、运营域、客服域、公共域等的实时数仓需求。
img

2.2.4 场景4:Flink宽表merge

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

场景5:Flink维表关联
第五个场景是Flink维表关联Hologres做成大宽表。刚刚提到的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,可以直接通过这个能力去查这个表。

img

3. 47手游云平台应用场景

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

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

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

3.1 场景1:买量优化

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

3.2 场景2:自助数据分析

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

3.3 场景3:精细化运营

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

3.4 场景4:画像分析

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

3.5 场景5:智能诊断

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

4. 业务价值

16

4.1 先看解决了哪些问题

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

4.2 再看带来了哪些价值

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

5. 未来规划

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

23

了解Hologres
合集.png

相关实践学习
数据库实验室挑战任务-初级任务
本场景介绍如何开通属于你的免费云数据库,在RDS-MySQL中完成对学生成绩的详情查询,执行指定类型SQL。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
相关文章
|
1月前
|
监控 大数据 Java
使用Apache Flink进行大数据实时流处理
Apache Flink是开源流处理框架,擅长低延迟、高吞吐量实时数据流处理。本文深入解析Flink的核心概念、架构(包括客户端、作业管理器、任务管理器和数据源/接收器)和事件时间、窗口、状态管理等特性。通过实战代码展示Flink在词频统计中的应用,讨论其实战挑战与优化。Flink作为大数据处理的关键组件,将持续影响实时处理领域。
270 5
|
15天前
|
数据采集 运维 Cloud Native
Flink+Paimon在阿里云大数据云原生运维数仓的实践
构建实时云原生运维数仓以提升大数据集群的运维能力,采用 Flink+Paimon 方案,解决资源审计、拓扑及趋势分析需求。
17368 24
Flink+Paimon在阿里云大数据云原生运维数仓的实践
|
27天前
|
存储 SQL 消息中间件
Hologres+Flink企业级实时数仓核心能力介绍
通过Hologres+Flink构建易用、统一的企业级实时数仓。
|
6天前
|
分布式计算 关系型数据库 MySQL
MaxCompute产品使用合集之用flink mysql的数据同步到mc的Transaction Table2.0,时间会比mysql的时间多8小时,是什么导致的
MaxCompute作为一款全面的大数据处理平台,广泛应用于各类大数据分析、数据挖掘、BI及机器学习场景。掌握其核心功能、熟练操作流程、遵循最佳实践,可以帮助用户高效、安全地管理和利用海量数据。以下是一个关于MaxCompute产品使用的合集,涵盖了其核心功能、应用场景、操作流程以及最佳实践等内容。
|
7天前
|
消息中间件 NoSQL Kafka
实时计算 Flink版产品使用问题之在处理大数据量时,checkpoint超时,该如何解决
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
8天前
|
消息中间件 SQL 大数据
实时计算 Flink版产品使用问题之Flink+DataHub+Hologres相比于Flink+Hologres加入了DataHub组件,有什么优势
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
1月前
|
Java 数据处理 Apache
实时计算 Flink版产品使用问题之lookup Join hologres的维表,是否可以指定查bitmap
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
1月前
|
JSON 关系型数据库 MySQL
实时计算 Flink版产品使用问题之在使用CDAS语法同步MySQL数据到Hologres时,如果开启了字段类型宽容模式,MySQL中的JSON类型会被转换为什么
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
29天前
|
消息中间件 分布式计算 Kafka
深度分析:Apache Flink及其在大数据处理中的应用
Apache Flink是低延迟、高吞吐量的流处理框架,以其状态管理和事件时间处理能力脱颖而出。与Apache Spark Streaming相比,Flink在实时性上更强,但Spark生态系统更丰富。Apache Storm在低延迟上有优势,而Kafka Streams适合轻量级流处理。选型考虑延迟、状态管理、生态系统和运维成本。Flink适用于实时数据分析、复杂事件处理等场景,使用时注意资源配置、状态管理和窗口操作的优化。
|
1月前
|
SQL Java 流计算
实时计算 Flink版操作报错合集之遇到报错:Caused by: com.aliyun.odps.tunnel.TunnelException:,该怎么办
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。

热门文章

最新文章

相关产品

  • 实时数仓 Hologres