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

波克城市：从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 方案。