ApacheDoris统一OLAP在游戏业务的
探索
演讲人：黄思恩（Iris）
关于沐瞳
业务背景
架构升级-ApacheDoris
落地迁移解决方案
近期规划
QA
关于沐瞳
01
沐瞳简介
上海沐瞳科技有限公司成立于2014年。公司总部位于上海，在新加坡、秘鲁、马来西亚、菲
律宾、印尼等地设有分支机构。
公司创立之初便立足于全球化游戏的开发，通过领先的研运优势，打造全球发行体系，已成功
推出多款在海外具有高知名度的移动游戏产品，是最早一批致力于游戏出海的中国公司，也是
拥有最多海外玩家的中国游戏公司之一。旗下产品包括《MagicRush:Heroes》《Mobile
Legends:Adventure》《MobileLegends:BangBang》《WatcherofRealms》等。
业务背景
02
业务场景-数据服务
?Ad-Hoc查询平台（SQL查询平台）
业务分析或技术开发人员按照业务需求在该平台SQL编写获取数据进行数据分析
?BI看板
技术人员按照业务需求对数据进行ETL过程形成的固定数据指标看板
?定制的分析需求
基于特定业务场景，比如说业务数据逻辑比较复杂，技术开发人员定制化开发数据需求，随着特定需求的增加，业务场景管理
过于混乱
业务场景-数据系统架构
根据业务需求沐瞳的数据层架构分为离线和实时部分
?离线系统
主要采用定时批处理的计算方式
?实时链路
保证数据的实时性、准确性
业务场景-系统架构痛点
由架构图可知，游戏日志数据主要通过实时和离线两条链路进行加工处理。在离线查询接口层面，主要使用Spark、Impala、Presto进行
数据查询，实时查询接口层面，主要是Clickhouse、Hbase、mysql进行数据存储和查询。这一架构在使用过程中逐渐暴露其局限和问题。
?运维成本高
涉及组件多，架构组件冗余，导致，运维复杂度高
?研发成本高
1.组件多随之而来的，会有不同多作业开发，比如Spark作业、Impala作业等，增加了开发成本
2.实时链路自研Logexport，数仓开发人员接入成本比较高，Flink作业和LogExport链路割裂
3.由于组件过多，业务分析人员需要学习组件SQL差异，增加了学习成本
?查询并发受限
1.数据量查询比较大的时候，OLAP调动集群资源过大，导致整体集群并发下降，其他业务查询受影响
2.报表高QPS查询、指标标签联合Join，Clickhouse查询表现不够理想
架构升级-ApacheDoris
03
架构2.0-目标
号召将数据应用效率最大化，同时兼顾研发、生产、运维成本最小化
?首要，能够低成本集成到现有的Lambda架构下的离
线和实时链路架构上
?同时能够支持OLAP场景和数据服务场景，减少组件
数量
?数据报表、实时业务数据能够支持高并发、高效的数
据更新
架构2.0-目标
落地迁移解决方案
04
落地迁移解决方案-BI报表引擎升级
?BI产品工具的性能要求
1.高QPS和ms响应时长要求
2.指标汇总，对大量数据复杂Join也提出一定要求
?clickhouse扩缩容操作过于复杂，运维工作压力大
落地迁移解决方案-BI报表引擎升级
落地迁移解决方案-BI报表引擎升级
?BI报表在新架构上的挑战
1.实时数据频繁写入BE异常退出
2.bucket不合理设置导致tablet过多，偶尔出现分区修改超时的情况
3.特定报表场景查询加速
?BI报表Doris上基础解决思路
1.版本过多-降低写入频次和提高批次量
2.根据Hive表格数据情况，约定bucket数量设置
3.前缀索引（高频过滤字段如国家定义）+bitmap索引（如国家区域）索引组合
落地迁移解决方案-BI报表引擎升级
?离线标签服务的挑战
1.数据导入压力挑战
2.标签回溯压力挑战
3.