手游清除数据会怎么样吗,手机游戏清除数据后会怎么样

网上有很多关于手游清除数据会怎么样吗,手机游戏清除数据后会怎么样的知识拓展，也有很多人为大家解答关于手游清除数据会怎么样的问题，今天开拓网(www.kaituohao.cn)为大家整理了关于这方面的知识，让我们一起来看下吧!

手游清除数据会怎么样

导读：本次从工程的角度分享一下多维分析平台在37手游的技术演进。本次分享分为以下四个模块：

37手游业务背景37手游多维分析的实践多维分析技术的业务化和普惠化多维分析平台服务保障

37手游业务背景

首先介绍一下业务背景。

1. 37手游简介

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

发行的不同游戏可能对应不同游戏研发商，数据来源多样且复杂，数据格式多样；广告投放对接众多外部媒体，不同媒体数据格式、数据时效、数据对接方式差异很大。

2.37手游数据分析场景特点

37手游数据分析的业务场景有如下特点和挑战。

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

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

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

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的查询引擎上。

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运算后的结果返回给协调器，协调器进行汇总，最后将结果返回给客户端。

以上就是Impala的一个简单读写流程。

4. Impala在自助取数平台的应用

介绍一下Impala在37手游的自助取数平台的应用。

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

为了提高日常业务团队取数类需求的交互效率，37手游构建了自助取数平台。

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

5. Impala的优点

自助取数分析平台的技术底座就是基于Impala的。为什么会选择Impala？首先Impala是MPP架构的，能够处理比较大的数据操作，而且是无状态的，节点挂掉后只需重启；其次是Impala兼容Hive存储，能复用Hadoop体系的存储能力，能避免像GP一样自成一套技术体系和资源体系；第三个点是Impala的高效查询性能，支持CBO、并行计算等，Impala的data location的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还支持多服务的并行处理数据，数据保存在不同的节点不同shard上，查询可以并行地在所有shard上进行处理。

8. ClickHouse在广告自动化投放平台的应用

37手游将ClickHouse应用在广告自动化投放平台来做查询的加速。37手游的广告投放平台需要对媒体广告投放效果进行实时监控（比如在头条或腾讯的媒体上投放广告），广告投放之后就有广告费用消耗，同时也会拉来一些用户注册（即对应的广告效果），根据广告效果来调整自动化投放策略。未引入ClickHouse之前，面临着两个技术挑战：

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

（2）多表关联的问题：广告投放资源的消耗需要关联上效果数据，还要关联各种各样的广告数据，多表关联的效率就会比较低。

针对这些问题使用了ReplicatedMergeTree表引擎。

对于多表关联，根据相同的join key，哈希到同一个节点，以实现local join，以减少计算时数据做shuffle时的消耗；对于频繁更新的问题，将业务业务库MySQL的数据同步到ClickHouse，将Mysql的update/delete/+insert的方式变成clickhouse insert(append)，构建历史数据和新增数据的视图，进行优化合并操作，因为历史数据不会发生变化，相对比较好处理；对于T-1或T的新增数据，只有一天的数据，数据量比较小，在进行更新操作时，取最近一条数据，然后两份数据合起来，我们曾考虑过用默认的replace来进行表更新，通过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集群缺乏Resharding机制，集群扩容节点比较麻烦。从数据更新角度看，数据Replacing使用merge-on-read模式，类似MOR的表模式，当多个数据版本存在时，不管是直接取数还是合并后取数，要取最新的一条数据，容易存在性能问题；另外ClickHouse不支持删除数据，需要通过表引擎增加删除标识位或TTL来变相实现数据删除的操作，这样就会拖慢性能。

11. StarRocks的重要特征

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

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

37手游业务中使用较多的是主键模型。主键模型其实和更新模型比较相似，要求每个表要有唯一的主键，支持按主键进行更新和删除操作，通过牺牲数据写入操作的部分内存，能够极大地提升查询性能。通过各种测试，StarRocks支持多并发查询，并且QPS能力比ClickHouse要好。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运算支持人群圈选等需求，性能相当高。

37手游多维分析技术业务化和普惠化

1.数据分析与决策存在痛点

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

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

2. 多维分析技术业务化与普惠化

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

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

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

1.平台服务健康度监控

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

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

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

3. 数据质量监控

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

4. 多维分析平台数据质量监控预警系统

37手游构建了一套数据质量监控预警系统来监控数据质量。

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

5. 多维分析平台数据质量监控预警信息

根据异常告警等级，告警信息通过短信、微信或者电话的方式来发送给业务方或者是属主。上图是企业微信上收到的一个告警信息截图。

6. 未来规划

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

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

第二项重要工作就是SaaS产品的引入，不管是社区还是公共云，都有一些比较好一点的组件和37手游的业务场景非常匹配，比如说阿里云的hologress，一个组件就能够解决用户画像场景中Hbase+StarRocks两个组件组合才能解决的的业务问题，无论K-V点查询、还是OLAP查询，hologess的性能都挺强；如果公司可以使用公共云，hologress也是一个挺不错的解决方案。

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

今天的分享就到这里，谢谢大家。

分享嘉宾：闫铁 37手游数据架构师

编辑整理：易双凤 vivo

出品平台：DataFunTalk

01/分享嘉宾