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

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

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

作者：史翱翔 37 手游大数据平台资深开发工程师

公司介绍

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

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

痛点：自建集群组件多，架构简单，老本高

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

• 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. 资源老本：

• 机器老本高；
• 机房老本高，因为有一百台机器要有独自的机房；
• 闲暇工夫多。咱们的离线作业大部分在早晨运作，白天的工夫基本上是比拟节约的。

1. 人力老本：

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

1. 稳定性、扩展性。

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

上云需要：低成本、运维简略、可扩大

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

总体来说 37 手游上云之后，云平台有以下几个方面的变动：

1. 效率高：上云之后首先是效率的变动，不单单是机器扩大效率，还有包含开发效率。
2. 成本低：咱们也和 IDC 集群做了比照，上云之后整体老本会升高。
3. 易扩大：当初不论加存储也好、内存或者 cpu 也好，几分钟即可实现扩大。
4. 稳定性高。上云之后简直还未呈现过问题。

二、云平台大数据建设计划

云平台整体设计方案

先看一下总体方案设计

• 第一条链路是实时流，从 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，离线这一层会修改实时的数据。

实时数仓典型利用场景

接下来会讲上云后的实时数仓五个典型利用场景的具体实现。
场景 1: 实时数据入仓
咱们用到数据集成，将 MySQL 数据、Kafka 数据通过 DataWorks 的数据集成写到 Hologres，这就是数据同步。第二种形式是 MySQL 的数据能够通过 Flink CDC 个性同步到 Hologres，这个过程只是一个简略的同步，没有做任何数据的解决。

场景 2: 实时计算入仓
第二个场景会通过简略的计算，这里并未波及到数据分层，间接通过简略计算落到实时数仓。有时须要对数据进行维度的扩大，所以咱们会在 Hologres 做一个视图，视图进行数据表和配置表的关联。然而这里有一个问题就是会对性能有一个损耗，如果数据量很大，则不倡议这个形式。如果是比拟小的数据，计算不简单，能够走这个链路，最终做一个展现。

典型的利用案例如下：

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

场景 3:Flink 读 Hologres Binlog 实时数仓分层
此前的计划是把 kafka 作为两头存储，中间层 DWD、DWS 都存储在 kafka 中。这种计划的毛病是很显著的，一旦数据不统一或者数据提早，很难排查问题。目前是基于 Hologres Binlog 来做的，通过 Flink 生产 Binlog，每一层数据都会实时落进去，有问题的时候比拟容易追踪。撑持用户域、设施域、交易域、广告域、经营域、客服域、公共域等的实时数仓需要。

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

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

47 手游云平台利用场景

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

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

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

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

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

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

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

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

业务价值

先看解决了哪些问题：

• 一是数据存储的问题，以前存储组件十分多，Kylin、Druid、MySQL、Presto 等，当初对立存到 Hologres。
• 二是千万级维表变更的问题，咱们的量级十分大，大略能到 5000 万，数据要去关联 5000 万的配置表，并且要实时地做这个事件，这在之前很难做到。
• 三是查问效率的问题。对业务来说，查问的时候十分慢，这个问题能通过 Hologres 高性能的查问解决。
• 最初是老本问题，因为 IDC 集群的老本，包含保护老本，还有前期扩大老本都是很高的。

再看带来了哪些价值？

• 一是数据存储对立。突破了数据孤岛，37 域的数据是全通的。
• 二是数据更加实时。之前每天的数据会半小时或者十五分钟跑一次，当初是实时计算，所见即可得，尤其是游戏首发的时候咱们对数据的实时性要求十分高。
• 三是查问效率。旧的引擎很难撑持业务的疾速倒退，新的数据库 Hologres 在查问性能上体验极佳。
• 最初是开发流程简化。咱们之前的开发流程是很简单的，当初只须要实时计算这块写一个 SQL 就能够搞定了。

将来布局

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