波克城市：从Impala到StarRocks，让游戏分析焕发新活力

作者：波克城市大数据平台部门

波克科技股份有限公司（以下简称“波克城市”）成立于 2010 年，立足于精品休闲游戏的全球化研发、发行，旗下拥有《爆炒江湖》《我是航天员》《猫咪公寓》等精品休闲游戏，连续五年入选中国互联网百强。目前，波克游戏积极探索和发展“游戏+”模式，努力构建以游戏产业为核心、多产业交融发展的互联网新生态。

基于大数据和人工智能的技术，波克城市正在组建自己的数据平台，赋能各个项目组，以保障公司能在信息的洪流中持续前进。从最初的整理数据孤岛，到数据开发规范流程化，再到现在的平台化，每一个阶段都成功为公司业务赋能。如今，智能投放和用户的精细化运营已成为波克城市的主流工作方式。

面对越来越灵活和深入的数据分析要求，原有基于 Apache Impala（以下简称 Impala）和 CDH 构建的数据平台越来越无力支撑。我们基于 StarRocks 构建了全新的数据分析平台，复杂即席查询性能提升 3 倍以上，并且可以支持业务数据实时更新，运维管理成本也得到了极大降低。有了 StarRocks，波克城市的游戏分析焕发出了新的活力。

#01

原有数据平台难以应对复杂现状

—

业务内容

为了快速响应业务迭代的需求，近年来，波克城市着力于构建公司的综合数据服务平台。以现有的信息化系统为基础，开辟各种系统间的数据通道，对现在的、历史的、分散的业务数据进行钻取和整合，充分利用现有的资源，激活数据价值。

波克城市大数据平台部门借鉴了传统数仓面向主题域的数据组织方式，基于维度建模理论构建统一的数据公共层和应用层。为了服务于不同的业务组，在综合数据服务平台中，根据不同的权限可以拉取核心项目报表，完成实时数据统计、管理监控指标、抽取自助报表查询等操作。

在公司的数据平台建设中，大数据平台部门整理出以下需求：

较强的离线报表任务支撑，T+1 的报表任务必须在每天上午 7 点以前完成；
交互式自助即席查询，以 SQL 为基础进行交互式查询，响应速度要足够快（秒级别）；
用户权限管控，必须要方便且快捷；
支撑实时业务，实时指标展示达到秒级别的延迟。

原有架构落地实现

在最初架构中，我们基于 CDH 搭建了综合数据服务平台。

上游的源数据库主要是 MySQL，业务相关的数据和部分日志数据都记录在里面。我们通过 DataX 和 Sqoop 将数据库中的数据导入到 HDFS，通过 Apache Hive（以下简称 Hive）的元数据映射生成 Schema，并接入 Impala 实现数据的即席查询。数据仓库的分层和建模全部都在 Hive 中完成，借助 LDAP 和 Sentry 进行用户权限管理。

对于实时指标，我们通过 Flink CDC 和 Canal 采集 MySQL 的 Binlog 日志，解析到 Apache Flink（以下简称 Flink）中对数据进行处理建模，并关联 Apache Kafka（以下简称 Kafka）中的埋点日志数据，生成实时指标写入到 MySQL 中。该流程适用于大部分的报表需求，但是由于 MySQL 对于 OLAP 的任务执行效率较低，在单日报表超过 1 万行的情况下，一些多维分析结果可能需要 10 秒以上才能返回，非常影响报表查看体验。

我们也提供了相应的数据服务。分析师通过 JDBC 的连接方式自助对数仓数据进行查询，项目组通过数据 API 将数仓数据直接应用于一线业务，相应的 BI 报表展示也基于 Impala 计算实现。

业务现状及痛点

综合数据服务平台的业务已相对稳定，可以应付公司绝大多数数据业务，但是随着数据量的增加和业务的增长，该数据平台暴露了许多问题。

在技术实现方面，我们主要遇到了三个痛点：

1. 使用的组件过多。实现不同的需求需要不同的组件，例如批量处理需要 Hive，即席查询需要 Impala，用户权限管理依托 Sentry 和 LDAP……这些都没有统一的入口，这对于数据仓库的内部管理非常不友好。

2. 运维难度大。CDH 虽然是商业软件平台，可以界面化操作，但是大多数的组件依然需要靠自己去探索，并且官方文档缺失严重。由于 CDH 已不在中国市场提供更新，暴露出来的漏洞也越来越多，数据仓库的数据安全也面临严峻的考验。

3. 数据的增删改非常不方便。Hive 是基于对 HDFS 的文件，不支持事务性的 DML 操作。虽然本身可以支持行级别的改删，但是效率非常低。所以我们被迫对分区表都进行天级别的分区，又造成了小文件过多的问题。

在应用使用方面，我们也遇到了三个挑战：

1. 大数据量的即席查询较慢。虽然我们使用 Impala 进行加速查询，但是由于数据文件没有有效的索引，对于数据扫描量达到 10 亿行的查询，仍然需要几十秒才能返回结果。并且自身的 SQL 优化器比较粗糙，SQL 编写稍不规范，就会产生不必要的资源开销，导致查询卡死。

2. Impala 自身存在一些缺陷。在表数据或者表结构更新的情况下，需要手动刷新元数据才能查询到最新的结果，非常不方便。并且大多数 BI 系统也不兼容 Impala 数据源。

3. 任务执行经常阻塞。由于底层通过 Yarn 进行资源调度，对于集群资源的使用效率不高。随着数据任务数量的不断增多，有限的集群核心数就成为了任务并发的瓶颈。即使集群整体的 CPU 使用率很低，也无法避免小任务将资源抢占、大任务无资源可用的尴尬情况。

针对上面的问题挑战，我们的目标是寻求一个新的 OLAP 分析引擎以减少开发和运维的成本，提供优秀的读取与写入性能，并在高并发和高吞吐的场景下都可以提供较好的使用体验。

目前市面上的 OLAP 数据库产品百花齐放，如 Impala、Apache Druid（以下简称 Druid）、ClickHouse 及 StarRocks。在经过一系列的对比之后，StarRocks 高效的读写性能在众多产品中脱颖而出。同时，高度活跃的社区生态给开发者与用户带来了良好的开发与使用体验，所以我们选择了 StarRocks 来作为综合数据服务平台的数据存储引擎，替换原有的 CDH 方案。

#02

使用 StarRocks 改造综合数据服务平台

—

StarRocks 应用优势

相比于传统的大数据解决方案，StarRocks 有以下优点：

极速的大宽表和多表查询性能
支持高并发分析查询
秒级数据实时更新能力
不依赖于大数据生态，同时外表的联邦查询可以兼容大数据生态
支持在线弹性扩缩容，可以自动负载均衡
兼容 MySQL 5.7 协议和 MySQL 生态

我们在综合数据服务平台遇到的痛点问题，在 StarRocks 中都得到了解决：

灵活数据建模方式支撑

在综合数据服务平台中，部分的固定报表业务可以根据查询在数据导入时拼成宽表。但对于数据探查业务更为灵活的自助报表业务，我们很难预定义宽表的结构。

StarRocks 不仅能够很好支撑宽表模型，也可以支持预聚合与星型/雪花模型。StarRocks 提供了不同的多表关联方式，如 Shuffle Join、Broadcast Join、Colocation Join 等方式，CBO 会根据表的统计信息自动选择最优的关联方式；同时也可以通过物化视图或聚合模型完成多维度上的预聚合操作。

实时高效的数据更新能力

在 OLAP 数据库中，可变数据通常是不受欢迎的。在传统数仓中，一般我们会使用批量更新的方式处理大量数据变更的场景，很难有一种方式能够实时高效完成数据的更新操作。在 ClickHouse 中，我们可以选择基于 merge-on-read 模式的 MergeTree 引擎，但会消耗极多资源，无法保证更新性能与数据同步的强一致性。

StarRocks 的主键模型采用 delete-and-insert 的模式，避免了 merge-on-read 在查询时版本合并的开销，非常好地解决了行级别的更新操作，在我们的业务测试中，可以支撑十几万的 TPS，非常适合 MySQL 数据库实时同步到 StarRocks 需求。

简单的运维操作

StarRocks 兼容 MySQL 协议。在替换原有的方案是，标准的 SQL 支持减少了对业务的侵入性。同时，相比于维护复杂的 CDH 环境，StarRocks 不依赖于大数据生态中的某一个组件，但又能够兼容大部分的技术栈；自动化的故障恢复及在线扩缩容功能也极大程度地减少了运维成本。

极速查询性能

在进行产品选型时，我们用线上业务在 PoC 阶段进行了性能测试。在与 Impala、ClickHouse 等进行对比后，我们最终决定选择 StarRocks。在这个性能测试中，我们选择了 6 个使用最频繁的业务 SQL，其中最大基表 game_log 超过百亿记录：

SQL 1 为简单的点查操作，从 game_log 表中根据 uid 进行过滤，并通过 limit 进行分页。
SQL 2 为简单的点查操作，从 game_log 表中根据 game_id 进行过滤，未分页。
SQL 3 为根据日期进行过滤的查询语句，从 game_log 表中过滤出一天内的日志，并进行条件筛选。
SQL 4 为分类聚合查询，根据时间条件进行数据筛选后进行一个维度的聚合，六个聚合指标。
SQL 5 为分类聚合查询，根据时间条件进行数据筛选后进行三个维度的聚合，八个聚合指标。
SQL 6 为通过窗口函数进行分类聚合。

SQL	Impala	ADB	ClickHouse	StarRocks
SQL1	5.2s	0.3s	0.16s	0.12s
SQL2	5.2s	138s	0.02s	0.04s
SQL3	0.18s	6.9s	0.04s	0.05s
SQL4	41.8s	46s	18.8s	7.5s
SQL5	95s	103s	58.5s	9.5s
SQL6	47.2s	62s	33.3s	7.2s

在经过一系列的性能测试与功能对比后，我们选择了 StarRocks 作为综合数据服务平台的分析层数据存储引擎。利用 StarRocks 极速查询、多种数据建模方式以及 StarRocsk 的实时更新能力，我们将 Impala 上的业务迁移到了 StarRocks 上。

基于 StarRocks 的存储引擎改造

对于存储层的改造，我们使用 StarRocks 替换了原有的 CDH 方案。

波克城市：从Impala到StarRocks，让游戏分析焕发新活力

在数据摄入层，由于 StarRocks 本身可以承接批处理和加速查询的任务，我们将数据采集从之前的多个工具缩减到了 3 个。T+1 的业务数据通过 DataX 的 StarRocks Writer 组件直接导入 StarRocks；数据库中的日志数据通过 Canal + Routine Load 的方式实时导入 StarRocks；对于日志服务器写到 Kafka 的数据，我们在 Flink 中完成处理后通过 Flink Connector 写入。

在数据建模的过程中，绝大多数的数据开发工作都在 StarRocks 中完成。我们在 StarRocks 中对数仓进行分层，ODS 层后面的 DWD、DIM、DWS 和 ADS 均借助 StarRocks 的计算完成。CDH 组件仍在使用，但是只保留了 HDFS 和 Hive，作为数据的冷备份，一般是两年前的历史数据。

针对于权限的管控，我们不再使用操作繁琐的 Sentry + LDAP 组合，所有数据仓库的用户权限管理都通过 StarRocks 的用户鉴权。由于和 MySQL 的用户管理方式几乎一致，所以对用户的管理非常方便。我们已经将这一套用户系统集成到了自己的平台里。

业务改造收益

在引入 StarRocks 后，系统的查询性能、数据写入的实时性、技术框架对于业务的拓展性等方面，收益显著增加。通过使用 StarRocks，解决了我们大部分痛点问题：

查询速度提升 3 倍以上。即使是亿级别的表，由于存在有效的索引和独特的分区分桶机制，在多维分析的场景下依然可以做到秒级别的响应速度。相对于原有方案，性能得到了数倍提升。
运维简单。StarRocks 架构简单，其最主要的组件 FE 和 BE 提供了高可用和水平扩展的机制，即使出现单点故障问题或资源扩充的情况，对集群的稳定和数据安全造成的影响可以控制到极小。官方的文档也非常丰富，平时也有专门的人员对接解决问题，不需要太关注底层的技术方面问题。
兼容性强。由于 StarRocks 本身在很多方面都和 MySQL 的使用方式一致，所以无论是 SQL 任务开发、BI 对接还是即席查询，都不需要额外的学习和开发成本。
灵活的数据写入和 DML 操作。StarRocks 支持多种数据的写入方式，无论是离线的 DataX 还是实时的 Flink Connector 都可以完美实现。更重要的是支持 95% 以上的增删改操作，无论是行级别的还是批量的，都支持事务。