导读：本次从工程的角度分享一下多维分析平台在37手游的技术演进。本次分享分为以下四个模块：
- 37手游业务背景
- 37手游多维分析的实践
- 多维分析技术的业务化和普惠化
- 多维分析平台服务保障
--
01
37手游业务背景
首先介绍一下业务背景。
1. 37手游简介
37手游是一家游戏发行公司，累计运营的游戏大概有 2000 多款，月活用户在3000万左右。37手游数据需求场景特点，和很多公司都有共性，但本身业务的特殊性也导致了跟其他公司在技术选型上有差异。
- 发行的不同游戏可能对应不同游戏研发商，数据来源多样且复杂，数据格式多样；
- 广告投放对接众多外部媒体，不同媒体数据格式、数据时效、数据对接方式差异很大。
2.37手游数据分析场景特点
37手游数据分析的业务场景有如下特点和挑战。
第一个特点是时效新：比如在广告投放的过程中，需要对广告投放消耗数据进行实时追踪，以及广告投放消耗之后的效果数据进行实时分析；还有游戏运营内部的实时分析，比如进行了某个活动投放，运营人员需要实时知道某个投放活动的效果怎么样。
第二个特点是维度多：广告投放很多时候要精细到特别细的一些维度，不仅有非常多的广告计划，还有非常多的广告创意，并且同一个广告计划里面可能会有不同的图片，不同素材，按照游戏包 广告投放渠道 广告投放计划 广告投放素材维度排列组合后就会存在一个维度爆炸的问题；另外一个点是历史快照数据更新问题，比如某个广告投放计划原来在某个投手下面，后来变更到另外一个投手下面，从广告追踪的角度来讲，需要回溯历史数据，也就是说现在的一些效果数据(如游戏充值付费)应该归因到新的投手下面时，就会存在历史数据维度更新的问题。
第三个特点是大数据量：比如基于用户ID 游戏包维度 广告投放维度进行精准去重，根据用户的行为数据，登录充值等，需要归因到是哪个广告或者素材带来的，就会涉及到大量的关联操作和去重操作，计算量很大；如果此时查询并发比较高，那整个集群就很容易出现资源上的瓶颈，导致系统变慢，影响整个业务查询体验。
--
02
37手游多维分析实践
1. OLAP在37手游的演进
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的查询引擎上。
