37款手游多维度数据分析平台技术演进

01

37手游商业背景

首先，一些商业背景。

1. 37款手游介绍

37手游是一家游戏发行公司，运营超过2000款游戏，月活跃用户约3000万。 37 手游数据需求场景的特点与很多公司相似，但自身业务的特殊性也导致了与其他公司在技术选型上的差异。

广告与众多外部媒体相连，不同媒体的数据格式、数据时效、数据对接方式差异很大。 2.37 移动游戏数据分析场景特点

37 移动游戏数据分析的业务场景具有以下特点和挑战。

第一个特点是新的时效性：比如在广告投放过程中，需要实时跟踪广告消费数据，对广告消费后的效果数据进行实时分析；还有游戏运营内部的实时分析，比如当某个活动上线时，运营商需要实时了解某个活动的效果。

第二个特点是维度多：广告往往需要细化到非常精细的维度。广告方案不仅有很多，而且广告创意也有很多，而且同一个广告方案可能会有不同的画面。当不同的素材按照游戏包+广告渠道+广告策划+广告素材的维度进行排列组合时，就会出现维度爆炸问题；还有一点是历史快照数据更新的问题。例如，某个广告计划原本是在某个A投手，后来换到另一个投手，从广告跟踪的角度来说，需要追溯历史数据，也就是说，当当前的一些表现数据（比如游戏充值和支付）应该归属于新投手，那么更新历史数据维度就会出现问题。

第三个特点是数据量大：比如基于用户ID+游戏包维度+广告投放维度的精准去重。根据用户的行为数据、登录充值等，需要归因于哪个广告或素材带来的。涉及大量的相关操作和去重操作，需要大量的计算量；如果此时查询并发比较高，整个集群很容易出现资源瓶颈，导致系统变慢，影响整个业务查询体验。

--

02

37 手游多维分析实践

一、37手游OLAP的演变

37款手游多维分析的架构选型是根据公司业务发展特点而演变的。为了保证系统性能和SLA，新的业务场景需要引入新的组件来解决特定的业务场景问题。在架构演进过程中，架构和组件的选择主要从计算能力、查询性能、架构简单性、可扩展性、稳定性、可维护性等维度来考虑。

2018年之前，业务数据量比较小，很多业务场景都是报表查询。这时候只需要将数据仓库建模后将ADS层数据推送到MySQL即可，因为数据本身聚合后，数据量并不大，MySQL就够用了。随着业务的精细化运营和数据量的增加，MySQL逐渐不堪重负。另外MySQL无法支持用户行为数据分析，所以引入了Druid来处理用户行为分析场景。

2019年以后，部分业务场景使用Impala进行数据分析，后面会详细讲解。

2020年之后，之前的架构无法支撑业务发展，于是引入了Clickhouse。从最初的单机Clickhouse到ClickHouse集群，主要应用于报表查询、自动投递等业务场景。

2021-2022年会引入一些第三方商业化工具，包括公有云厂商、阿里云ADB、Hologress等的一些组件，还有近一两年流行的StarRocks，来解决有针对性的问题。一些具体的业务场景问题。

2. OLAP平台和数据仓库

说到多维分析和OLAP，就不得不提到数据仓库。通常通过ODS到DWD，再到DWS，再到ADS层数据建模，经过一系列ETL操作，最终将ADS层数据推送到OLAP查询层进行应用层查询。

下图是37手游数据仓库的整体架构图。数据来自业务数据库MySQL和业务日志。经过中间实时/离线数据仓库ETL数据处理后，最终ADS层数据推送到混合OLAP查询平台进行业务查询。中间的数据仓库架构采用了Flink引擎，整体符合湖仓一体、流批一体的数据仓库架构设计思想。实时数仓采用Kafka作为存储层，实时数仓DW层会将数据落一份到Hudi进行数据分析。构建逻辑视图，统一实时数仓数据表（kafka）和离线数仓表hudi（hive外部表）。通过统一逻辑视图，可以实现数据仓库、流批综合存储层面的逻辑统一。其中，混合OLAP查询平台针对不同的业务场景封装了不同的组件，不同的业务查询请求流量通过路由分发到不同的OLAP查询引擎。

3.Impala读写流程

Impala是37手游用于自助数据提取的计算引擎。下面简单介绍一下Impala的原理和读写过程。 Impala主要由三个组件组成：Catalog、StateStore、ImpalaDaemon； Catalog将元数据分发到每个ImpalaDaemon； StateStore收集每个ImpalaDaemon的信息，比如进程信息、每个节点的健康信息等。同时StateStore还负责请求调度； ImpalaDaemon本地数据计算完成后，会与其他一些ImpalaDaemon配合进行计算，最后将结果返回给客户端。

上图是Impala的读写过程。首先，客户端提交请求后，会相应生成一个Impala请求流程。 Impala请求进程会向StateStore提交注册信息，StateStore会生成StateStore存储进程，创建多个线程来处理Impala请求进程的注册信息；接下来，根据用户输入的SQL语句，经过Impala服务的三个模块：查询规划器（Query Planner）、查询协调器（Query Coordinator）和查询执行器（Query Executor）的词法和语法分析，被拆分成各个子任务，然后分布在各个ImpalaDaemon中执行； ImpalaDaemon每次操作的结果都会返回给协调器，协调器进行汇总，最后将结果返回给客户端。

4.Impala在自助点餐平台中的应用

下面介绍一下Impala在37手游自助检索平台中的应用。

业务团队经常有各种各样的数据检索需求，而数据检索需求占用了数据开发人员大量的精力。从收到业务团队的数据检索需求，到开发人员编写SQL，到运行代码获取数据并返回给业务请求者，我们经常会遇到业务团队的抱怨和催促：为什么检索数据需要这么长时间。

为了提高日常业务团队找号需求的交互效率，37手游搭建了自助找号平台。

用户首先在自助数据检索平台上筛选维度、选择指标和统计口径。自助数据检索平台根据用户选择的条件分析生成代码和任务。自助数据检索平台调度并执行任务，SQL代码发送到Impala集群执行。任务执行成功后，会生成一个文件供用户下载。对于业务团队来说，他们只需要在自助平台上进行一些选择，等待数据检索任务被调度并执行，然后下载并获取数据。非常方便快捷；对于数据开发团队来说，减少了80%以上的数量检索需求。可以从SQL Boy低效的工作中解脱出来，极大地解放生产力，从而腾出精力去做更高价值的事情。

5.Impala的优点

自助数据分析平台的技术基础基于Impala。为什么选择黑斑羚？首先，Impala基于MPP架构，可以处理比较大的数据操作，而且是无状态的。某个节点挂掉后，只需要重新启动即可。其次，Impala兼容Hive存储，可以复用Hadoop系统的存储能力，避免GP的问题。拥有自己的一套技术体系和资源体系；第三点是Impala高效的查询性能，支持CBO、并行计算等。Impala的数据定位的IO协调机制是尽可能将计算和数据存储在一个节点上，减少网络开销。特别是在大数据场景下，节省网络资源； Impala的运算符下推功能可以保证非常高效的查询性能；最后一点是Impala社区活跃度很高，因为不太受欢迎的组件在社区中的活跃度不高。技术选择会带来一些不可控的风险。

6.Impala的缺点

在使用Impala的过程中，我也发现了Impala的缺点。

第一个是单点问题，即Catalog和StateStored的单点问题。虽然Catalog的单点故障不会对正在进行的查询造成太大影响，但可能无法获取到最新的元数据。

二是资源隔离问题。资源隔离不准确，无法通过YARN统一资源管理进行资源调度，无法实现Impala、Spark、Hive等组件的动态资源共享。

第三个问题是元数据更新问题，无法检测HDFS操作。每当新记录/文件添加到HDFS 中的数据目录时，都需要手动刷新元数据。第四个重要点是Impala是基于内存计算的，速度非常快，但是存在内存溢出的风险，内存溢出会导致任务挂起。另外，Impala的并发能力比较有限，QPS稍高，查询性能下降明显。

7. ClickHouse为什么快？

2019年后，37手游开始引入ClickHouse。当时ClickHouse是一个比较现象级的产品，速度非常快。为什么ClickHouse 这么快？

ClickHouse实现了单机多核并行，还支持分布式计算、SIMD指令等，可以压榨机器的性能，提高查询速度； ClickHouse支持多种表引擎，包括MergeTree等20多种表引擎，根据不同的业务场景选择不同的表引擎可以提高性能； ClickHouse的索引机制包括主键索引和稀疏索引，可以提高查询性能； ClickHouse的矢量化引擎可以在存在多个数据流时提高上层应用程序的性能。大大提高； ClickHouse是一个内置数据压缩的列式存储。基于列的存储更适合OLAP场景。再加上内置的数据压缩处理速度，可以实现百倍的性能提升； ClickHouse支持多核并行处理。单个SQL的执行会利用尽可能多的CPU核心，挤占CPU资源以提高执行效率； ClickHouse还支持多个服务并行处理数据。数据存储在不同节点、不同分片上，查询可以并行化。在所有分片上进行处理。 8、ClickHouse在自动化广告投放平台中的应用

37手游将ClickHouse应用于自动化广告投放平台，加速查询。 37手游的广告平台需要实时监控媒体广告的效果（例如在今日头条或腾讯媒体上投放广告）。广告投放后，会消耗广告费用，也会吸引部分用户注册（即相应的广告效果），根据广告效果调整自动化投放策略。在引入ClickHouse 之前，我们面临两个技术挑战：

（1）业务数据的更新频率非常高，因为媒体广告发布时，投放资源一直在消耗，需要实时拉取。

(2)多表关联的问题：广告资源的消耗需要与效果数据以及各种广告数据进行关联，因此多表关联的效率会比较低。

ReplicatedMergeTree表引擎就是用来解决这些问题的。

对于多表关联，根据相同的join key散列到同一个节点，实现本地join，减少计算时数据shuffle的消耗；针对频繁更新的问题，将业务数据库MySQL的数据同步到ClickHouse，将Mysql的update/delete/+insert方式改为clickhouse insert(append)，构建历史数据和新数据的视图，并进行优化的合并操作，因为历史数据数据不会改变并且相对容易处理；对于T -1 或T 的新数据只有一天的数据，数据量比较小。执行更新操作时，会取出最新的一条数据，然后将这两个数据组合起来。我们考虑过使用默认的替换来更新表。数据合并是通过ClickHouse本身的一些机制来完成的。但由于业务数据插入频率高、数据量大，ClickHouse数据合并是异步的，很容易Merge失败。当然，可以通过一些手段来进行优化，例如强制合并的optimize和final，但由于optimize不是常规操作，所以不能太频繁。查询时，使用final进行合并会影响查询性能，尤其是在ClickHouse的早期版本中。它是单线程的，性能不好。因此，最终采用了ReplicatedMerge表引擎和视图。

9.ClickHouse使用体验

我在使用ClickHouse的过程中有一些体会。

第一个是根据应用场景合理选择ClickHouse，避免“让举重运动员参加长跑比赛”（避免让ClickHouse做它不擅长做的事情），多做短查询，避免大量合并数据或频繁更新；数据仓库最好将表中的数据建一张大宽表，在写入之前预先聚合，批量写入Clickhouse。

二是建表和索引的优化。

第三是查询SQL优化。 SQL优化的很多策略，无论是列剪枝还是分区剪枝，最终都是为了减少查询时的IO，降低网络传输成本。如果业务可以接受，可以使用数据采样或者simple、limit、uniqCombined等方法进行近似计算，以提高性能。

第四是调整系统参数，比如单个查询的最大执行时间max_execution_time。如果执行某条SQL超过这个时间，业务可能会认为该SQL有问题，可以执行降级操作，停止任务；还有一些参数，例如单个服务器上单个查询的max_memory_usage、单个服务器上所有查询的max_memory_usage_for_all_queries 以及合并线程的数量。这些参数需要在具体的业务运行过程中进行调整，以达到ClickHouse性能的最优。

10.使用ClickHouse时的痛点

在使用ClickHouse的过程中，痛点也非常明确。

从查询性能来看，ClickHouse的高并发能力不足，多表相关查询性能较差。从运维角度来看，ClickHouse集群严重依赖ZooKeeper，增加了运维的复杂度； ClickHouse集群缺乏重新分片机制，扩展集群节点容量比较麻烦。从数据更新的角度来看，数据替换采用的是merge-on-read模式，与MOR表模式类似。当存在多个数据版本时，无论是直接取数据还是合并后取数据，都可以轻松取到最新的数据。性能问题；另外，ClickHouse不支持删除数据。需要通过表引擎添加删除标志或者TTL来变相实现数据删除操作，这样会降低性能。

11. StarRocks 的重要特点

基于37手游的业务特点以及ClickHouse的使用情况，我们在2022年开始对StarRocks进行调研。StarRocks的特点与37手游的业务场景非常吻合。这里简单介绍一下StarRocks的一些重要功能。

StarRocks目前有四种数据模型：详细模型、聚合模型、更新模型和主键模型。根据不同的业务场景使用不同的数据模型可以提高查询性能。

37 主键模型多用于手游业务。主键模型实际上与更新模型类似。它要求每个表有唯一的主键，并支持通过主键进行更新和删除操作。通过牺牲部分内存用于数据写入操作，可以大大提高查询性能。通过各种测试，StarRocks 支持多个并发查询，并且具有比ClickHouse 更好的QPS 能力。 StarRocks支持多种数据导入方式，简化数据处理环节。此外，StarRocks 不依赖ZooKeeper 等外部组件。只有自己的FE和BE模块，降低了运维管理难度。

12、StarRocks在37个手游人像场景中的应用

37 手游用户画像场景有四点技术诉求。第一，支持大数据量的查询；第二，数据要及时；第三，可以根据任意规则选择用户，然后执行一些分析操作，例如聚合操作；第四，支持多表关联，比如画像表和用户维度表的关联。上面的第三点和第四点是我们的强烈需求。

13.37手游肖像StarRocks解决方案

以前37手游的用户画像都使用了ES，但ES的成本比较高，并发能力不如StarRocks+Hbase方案，而且ES有时会出现读写超时的情况（业务读和写）写入延迟要求）。因此，切换到了现在的StarRocks+Hbase方案，以前的痛点都解决了。 StarRocks解决方案中，用户画像表采用宽表+多表的数据设计方案。对应的表模式是主键模型+聚合模型，可以处理宽表和多表；通过使用StarRocks的to_bitmap将user_id转换为Bitmap类型，后续的Bitmap操作用于支持人群选择等需求，性能相当高。

--

03

37手游多维度分析技术商业化、普及

1、数据分析和决策存在痛点

在做数据开发工作时，经常会遇到以下痛点。

如果数据开发团队整天只开发报表或者写SQL检索数据，那么数据开发人员很容易变成：“表弟”、“表弟”（只开发报表）或者SQL Boy（只写SQL）。这样一来，数据开发者可能会觉得商业价值的存在性低；从业务团队的角度来看，需要向数据开发团队提交大量的数据访问需求，并希望尽快交付数据访问需求，以便及时进行数据分析和业务决策但实际情况是，业务团队会感觉数据开发团队实现数据报表时间长，获取数据困难，获取数据慢，效率低。

2.多维分析技术的商业化和通用化

针对以上痛点，37手游数据开发团队采取的策略是：

基于多维分析技术，将多维分析技术商业化、通用化，搭建自助数据分析平台，为业务方提供数据分析，赋能业务决策。数据开发人员只需准备数据集即可构建数据仪表板。他们甚至可以将数据看板建设留给业务团队自己。数据开发者可以准备数据集，如下图所示。右边，数据开发者已经准备好了数据集。左边的数据图表可以由业务团队构建。这种方式的优点是数据开发团队可以从报表开发中解放出来，有更多的精力去满足更高的业务价值需求；业务团队可以发挥自己的主观能动性，利用数据自助分析平台，根据业务理解制作数据仪表板。对业务问题进行深入分析或归因分析。

--

04

37款手游多维度分析平台服务保障

1. 平台服务健康度监控

很多时候，分析问题比解决问题更重要。只要发现问题，定位到问题的原因，解决问题就水到渠成，只是解决问题的难度或者成本不同。多维度分析平台的服务健康度监控实际上是问题发现的前置过程。过程分为以下几个阶段：一是监测数据的收集；二是监测数据可视化；第三，异常数据的发现和报警。监控数据采集阶段包括服务器日志的采集以及多维度分析平台性能指标的采集，如查询错误率低于95%、99%、异常趋势等；数据可视化是基于Promtheus+Grafana的可视化监控解决方案；根据实际业务场景，通过配置指标、添加触发报警的阈值，以及利用一些智能手段（如时序数据异常检测算法等）辅助检测异常数据，可以实现多维分析平台的健康监测和报警意识到了。

2. 平台服务健康度监控仪表板

有许多现成的可视化监控仪表板。例如，StarRocks 有现成的监控仪表板（参考StarRocks 社区），可以开箱即用，基本足以满足大多数业务需求。

3. 数据质量监控

多维分析平台的数据质量监控很重要。数据质量监控有完整的方法论，从需求调研、指标定义、开发规范，到任务和数据质量监控，都有完整的流程。业界很多采用数据质量治理模型DMAIC，分别指Define、Measure、Analyze、Improv、Control；对应数据质量治理边界的界定、数据质量评估模型的建立、数据质量问题的异常发现与问题归因、数据质量。提升。我不会详细介绍DMAIC 模型。在37手游的业务实践中，数据质量从数据有效性、数据一致性、准确性、完整性和及时性五个维度进行评估。

4、多维度分析平台数据质量监测预警系统

37手游搭建了数据质量监控预警系统，对数据质量进行监控。

下图是数据质量监控的流程图，主要包括四个模块。第一个是调度模块，第二个是后端服务模块，第三个是执行引擎模块，第四个模块是报警服务。整个系统主要是在多维分析平台上检测和发现数据质量问题，然后提供监控和报警。调度器发起监控任务后，后端服务模块将作业任务提交给执行引擎。执行引擎将从多维分析平台拉取数据，然后在执行引擎中进行计算，或者将计算下推到多维分析平台执行。然后将计算结果返回给后端服务。后端服务判断返回的结果数据是否存在问题或异常。如果出现问题，就会启动报警服务。

5、多维度分析平台数据质量监测预警信息

根据异常报警级别，通过短信、微信或电话将报警信息发送给业务方或业主。上图是企业微信收到的报警消息截图。

6. 未来规划

下面介绍一下未来的计划。

前面介绍了37手游OLAP计算引擎的架构演变：从MySQL、Druid，到Impala，到ClickHouse，最后到StarRocks。组件太多，维护工作量非常大，所以接下来的重要任务之一就是对现有组件进行一些减法，汇聚组件，用尽可能少的组件来满足更多的业务场景，减少运维维护压力。

第二个重要任务是SaaS产品的推出。无论是社区还是公有云，都有一些比较好的组件非常适合37手游的业务场景。比如阿里云的hologgress，一个组件就可以解决用户画像的问题。场景中，只能通过Hbase+StarRocks组件组合才能解决的业务问题，无论是K-V点查询还是OLAP查询，Hologess的性能都很强；如果公司可以使用公有云，Hologess也是一个非常好的解决方案。

第三个重要任务是ELT模式的探索。数据仓库有清晰的数据分层设计和ETL数据计算，环节还是蛮长的。随着组件的演进和发展，ELT也是一个很好的解决方案。将原始数据或粗加工后的数据导入多维分析平台后，在多维分析平台内部进行统一口径的数据转换和处理，然后将数据导出到外界。提供服务；该方法简化了整个数据处理环节。通过更少的组件和更少的流程，可以提高及时性。

制作平台：DataFunTalk

严铁37手游数据架构师