第三项重要工作是ELT模式的探索。数仓经过清晰的数据分层设计与ETL数据计算，链路还是挺长的。随着组件的演进和发展，ELT也是一个挺不错的解决思路，就是原始数据或者是粗加工的数据，导入到多维分析平台之后，在多维分析平台内部进行统一口径的数据转换加工处理，再对外提供服务；这种方式精简了整个数据的加工链路，组件少了，流程少了，时效就能得到提升了。

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

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

37游戏盒子有加速功能

多维分析平台的数据质量监控很重要。数据质量监控是有一套完整方法论的网页三国刷级游戏攻略，从需求调研、指标定义、开发规范、到任务和数据质量的监控，有一套完整的流程。业内很多采用数据质量治理模型DMAIC，分别是指Define、Measure、Analyze、Improve、Control；对应数据质量治理边界的定义、数据质量评估模型的建立、数据质量问题的异常发现与问题归因、数据质量改进。DMAIC模型就不展开讲了。在37手游的业务实践中，是从数据有效性、数据的一致性、准确性、完整性和时效性五个维度来进行评估数据质量的。

可视化的监控看板有很多现成的，比如StarRocks就有现成的监控看板（参考StarRocks社区）能做到开箱即用，基本够用，能够满足大多数的业务需求。

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

基于多维分析技术，把多维分析技术进行业务化和普惠化，构建了数据自助分析平台提供给业务侧进行数据分析和赋能业务决策。数据开发人员只要准备好数据集搭建数据看板，甚至可以将数据看板搭建交由业务团队自己实现，数据开发人员准备好数据集即可，如下图所示，右边是数据开发人员准备好数据集，左边的数据图表可以由业务团队来搭建。这样处理的好处是，数据开发团队可以从做报表开发中释放出来，有更多精力做业务价值更高的需求；业务团队能发挥自主能动性，利用数据自助分析平台进行数据看板制作，基于业务理解进行业务问题的下钻分析或归因分析。

数据开发团队如果整天就只开发报表或者写SQL取数，数据开发人员容易沦为：“表哥”，“表姐”（只开发报表）或者SQL Boy（只写SQL）,这样数据开发人员可能自我感觉业务价值存在感偏低；从业务团队的角度来讲，大量的取数需求要提给数据开发团队，并且希望取数需求尽快完成交付以便及时进行数据分析和业务决策，但实际情况是业务团队会觉得数据开发团队实现一张数据报表需求工时好长，取数难，取数慢，效率低。

37手游用户画像场景有四个技术诉求。第一，支持大数据量的查询；第二，数据的时效性要强；第三，可以根据任意的规则去圈选用户，再去做一些画像操作，比如聚合操作；第四，是要支持多表关联，比如画像表和用户维度表关联。其中前面的第三、第四点是我们的强需求项。

37手游业务中使用较多的是主键模型。主键模型其实和更新模型比较相似，要求每个表要有唯一的主键，支持按主键进行更新和删除操作，通过牺牲数据写入操作的部分内存，能够极大地提升查询性能。通过各种测试，StarRocks支持多并发查询，并且QPS能力比ClickHouse要好。StarRocks支持多种数据导入方式，简化了数据加工链路。另外StarRocks不依赖ZooKeeper等外部组件，只有自身的FE、BE模块，降低了运维管理难度。

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

基于37手游的业务特点和ClickHouse的使用情况，2022年开始调研StarRocks，StarRocks的特性和37手游的业务场景匹配度非常高，下面简单介绍一下StarRocks的一些重要特性。

第三个是查询SQL优化，SQL优化的很多策略，无论是列裁剪与分区裁剪，归根结底就是减少查询时的IO，减少网络传输的成本；如果业务上能接受，可以采用数据采样，或者使用simple、limit、uniqCombined等方式做近似计算来提升性能。

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

对于频繁更新的问题，将业务业务库MySQL的数据同步到ClickHouse，将Mysql的update/delete/+insert的方式变成clickhouse insert(append)，构建历史数据和新增数据的视图，进行优化合并操作，因为历史数据不会发生变化，相对比较好处理；

对于多表关联，根据相同的join key，哈希到同一个节点，以实现local join，以减少计算时数据做shuffle时的消耗；

ClickHouse还支持多服务的并行处理数据，数据保存在不同的节点不同shard上，查询可以并行地在所有shard上进行处理。

ClickHouse是列式存储，自带数据压缩，列式存储更适合OLAP场景，再加上自带的数据压缩的处理速度，能做到百倍级别的性能提升；

ClickHouse支持多样化的表引擎，包括MergeTree等20多种表引擎，基于不同的业务场景选择不同的表引擎，可以带来性能上的提升；

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

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

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

首先是单点问题，即Catalog和StateStored单点问题，虽然Catalog单点挂掉之后，对正在进行中的查询影响并不是很大，但可能拉取不到最新的元数据。

自助取数分析平台的技术底座就是基于Impala的。为什么会选择Impala？首先Impala是MPP架构的，能够处理比较大的数据操作，而且是无状态的，节点挂掉后只需重启；其次是Impala兼容Hive存储，能复用Hadoop体系的存储能力，能避免像GP一样自成一套技术体系和资源体系；第三个点是Impala的高效查询性能，支持CBO、并行计算等，Impala的data location的IO协调机制是计算和数据尽可能在一个节点，减少网络开销，尤其在大数据场景下，非常节省网络资源；Impala的算子下推的特性能够保证非常高效的查询性能；最后一个点是Impala社区活跃度高，因为比较冷门的组件社区活跃度不高，在技术选型上会来带来一些不可控的风险。

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

业务团队经常会有各种各样的取数需求，取数需求会占用数据开发人员的不少精力。从收到业务团队的取数需求，到开发人员编写SQL到跑代码获取数据返回给业务需求方，经常会遭受业务团队的吐槽和催促：为啥取个数据要这么久。

上图是Impala的读写流程，首先客户端提交一个请求后，会对应产生一个Impala请求进程，该Impala请求进程会向StateStore提交一个注册信息，StateStore就会同时产生一个StateStore存储进程来创建多个线程来处理Impala请求进程的注册信息；接下来根据用户输入的SQL语句，经过Impala服务的三个模块：Query Planner、Query Coordinator和Query Executor的词法、语法解析后，拆成各个子任务，然后分发到各个ImpalaDaemon中去执行；各个ImpalaDaemon运算后的结果返回给协调器，协调器进行汇总，最后将结果返回给客户端。

Impala是37手游用来做自助式数据提取的计算引擎，下面简单介绍一下Impala的原理和读写流程。Impala主要包含三个组件：Catalog，StateStore，和ImpalaDaemon；Catalog把元数据分发到各个ImpalaDaemon；StateStore收集各个ImpalaDaemon的信息，如进程信息，各个节点的健康信息等，同时StateStore还负责请求调度；ImpalaDaemon对本地数据进行运算后，协同其他的一些ImpalaDaemon进行运算，最终把结果返回给客户端。

下图就是37手游的数据仓库的总体架构图，数据从业务库MySQL和业务日志进来，经过中间的实时/离线数据仓库ETL 数据加工后，最终ADS层数据被推到混合OLAP查询平台，供业务查询。中间的数仓架构采用了Flink引擎，整体满足湖仓一体，流批一体的数仓架构设计思路。实时数仓使用Kafka作为存储层，实时数仓DW层会落一份数据到Hudi供数据分析使用。构建逻辑视图统一实时数仓数据表(kafka)和离线数仓表hudi（hive外部表）。通过统一逻辑视图，做到数仓流批一体存储层面的逻辑统一。其中混合OLAP查询平台，针对不同的业务场景，封装了不同的组件，不同的业务查询请求流量通过路由分发到不同的OLAP的查询引擎上。

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

在2021年到2022年期间，引入了一些第三方商业化的工具，包括公有云厂商的一些组件，阿里云ADB、Hologress等，还有最近一两年热门的StarRocks等，用于针对性地解决某些特定业务场景问题。

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

2018年以前，当时业务的数据量相对比较少，很多业务场景是报表查询，此时只需在数仓的建模后，将ADS层的数据推送到MySQL中即可，因为数据本身聚合之后数据量也不大，MySQL够用。随着业务的精细化运营以及数据量增加，MySQL就逐渐顶不住了三国杀游戏开中秋盒子，另外用户的行为数据分析，无法用MySQL支撑，因此引入了Druid来应对用户行为分析的场景。

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

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

第二个特点是维度多：广告投放很多时候要精细到特别细的一些维度steam游戏单机盒子，不仅有非常多的广告计划，还有非常多的广告创意，并且同一个广告计划里面可能会有不同的图片，不同素材，按照游戏包+广告投放渠道+广告投放计划+广告投放素材维度排列组合后就会存在一个维度爆炸的问题；另外一个点是历史快照数据更新问题，比如某个广告投放计划原来在某个投手下面，后来变更到另外一个投手下面，从广告追踪的角度来讲，需要回溯历史数据，也就是说现在的一些效果数据(如游戏充值付费)应该归因到新的投手下面时，就会存在历史数据维度更新的问题。

第一个特点是时效新：比如在广告投放的过程中，需要对广告投放消耗数据进行实时追踪，以及广告投放消耗之后的效果数据进行实时分析；还有游戏运营内部的实时分析，比如进行了某个活动投放，运营人员需要实时知道某个投放活动的效果怎么样。

37手游是一家游戏发行公司，累计运营的游戏大概有 2000 多款，月活用户在3000万左右。37手游数据需求场景特点，和很多公司都有共性，但本身业务的特殊性也导致了跟其他公司在技术选型上有差异。

专题： 游戏盒子放置三国   三国杀游戏盒子号   gm手游盒子