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

37次阅读

共计 5947 个字符,预计需要花费 15 分钟才能阅读完成。

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

  1. 云平台大数据建设背景
  2. 云平台大数据建设计划
  3. 利用实际
  4. 将来布局

点击查看原文视频 & 演讲 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 集群的状况。

  • 第一、资源老本:

    1. 机器老本高;
    2. 机房老本高,因为有一百台机器要有独自的机房;
    3. 闲暇工夫多。咱们的离线作业大部分在早晨运作,白天的工夫基本上是比拟节约的。
  • 第二,人力老本:

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

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

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

左边图是随着节点数的减少自建机房与基于阿里云的比照。在集群节点不断扩大的状况下,能够看到自建机房的单位成本逐步增高,基于阿里云的单位成本根本稳固不变。

从技术上:

  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 代替。

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

  • 一是效率高。上云之后首先是效率的变动,不单单是机器扩大效率,还有包含开发效率。
  • 二是成本低。咱们也和 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 就能够搞定了。

三、利用场景

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

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

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

上图是买量优化简略的流程图。咱们会拿到一个玩家的历史数据,而后去剖析特色,再联合经营平台的经营数据做一个预测,预测哪些是高留存玩家。而后会基于这些高留存玩家在投放平台进一步的投放相干游戏,最初基于投放成果数据进行重复的迭代模型、剖析成果等。

上图是自助剖析的场景,咱们的数据后盾大部分是给 B 端用的,此前的一个开发模式是比拟传统的,数据开发同学负责报表数据的开发,展现由前端去做页面的开发,业务从提一个需要到排期再到交付,这个过程可能要花 1-2 周。然而有了自助剖析平台,咱们用的是 Quick BI,业务提需要后只须要做数据集就能够实现自助剖析,大略半天的工夫就能够实现,甚至业务本人也能够实现一些简略的需要。

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

这是咱们用到的一个画像数据,这个画像数据其实做挺久了,从 2019 年就开始做,并且在一直的迭代,所以当初画像是很欠缺的。岂但能够剖析根底的数据,还会基于人群去做剖析。基于简单的条件圈选人群包,因为基于人群包做投放,所以还会对人群包后续的状况做一个成果的剖析,包含留存的状况,LTV 数据等。

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

四、将来布局

  • 首先,咱们在智能投放方面做得还不够好,所以想在智能方面投入更多的精力和工夫。比方 37 手游的用户数据跟媒体数据做一个买通,这样岂但能够对本人已有的画像人群剖析,还能够联合媒体画像指标做进一步剖析。有了这些数据可能对投放的成果也会有很大的晋升。
  • 第二,智能经营。当初做的事件是每个人发送代金券、礼包,其实都是对立的,咱们将来想做到千人千面,每个人发不同的代金券,不同的礼包,相似于个性化举荐,进而来进步收益。
  • 第三,智能诊断、归因剖析。在海量的数据,海量的指标中,数据稳定异样如何及时发现;发现异常后如何剖析导致异样的起因等。目前做的还是比拟初阶,这也是咱们将来重点冲破的中央,智能归因、智能诊断、智能化洞察。

公司介绍

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

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


Flink Forward Asia 2022

流动举荐

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

正文完
 0