游族网络xStarRocks：高效助力数据查询，灵活应对多维分析

✨ 精选文章 用户案例
#1

游族网络xStarRocks高效助力数据查询灵活应对多维分析
游族网络xStarRocks高效助力数据查询灵活应对多维分析1276×544 18.7 KB

作者：刘成彬，游族网络资深大数据开发

游族网络股份有限公司（SZ.002174）成立于 2009 年，总部位于上海，在德国、新加披、日本、韩国、印度等十余个国家设有分支机构。2014 年 6 月，游族网络正式登陆中国 A 股主板。

游族网络立足全球化游戏研发与发行，成功推出了《少年三国志》系列、《女神联盟》系列、《盗墓笔记》、《权力的游戏：凛冬将至》、《圣斗士星矢：觉醒》等多款知名游戏产品，在海外积累 1000 多个合作伙伴，发行范围遍及欧美、中东、亚洲及南美等 200 多个国家及地区，全球累计近 10 亿用户。

作为中国领先的互动娱乐供应商，通过与 StarRocks 的全面深入合作，游族网络依靠 StarRocks 丰富的数据导入方式和外表让数据查询更加高效，丰富的数据模型与高并发使数据建模、对外数据提供服务更加精准便捷。

#01

业务背景下，痛点重重

—

之前在计算实时指标时，我们运用过诸多组件：

  • Presto 和 ClickHouse 用于分钟/小时级调度的指标计算；

  • 使用 Spark Streaming 或 Apache Flink（以下简称 Flink）直接从 Apache Kafka（以下简称 Kafka） 读取数据计算实时指标，结果数据写入 MySQL，报表系统直接读取 MySQL 数据作为展示；

  • Apache HBase（以下简称 HBase） 除了做计算交互，也会存储一些标签表，通过 DataAPI 的方式提供给其他系统使用，比如客服系统查询玩家标签这类场景；

  • Presto 直连 Apache Hive（以下简称 Hive）；

  • ClickHouse。

这些组件各展所长，帮助我们解决了不少问题，但从目前来看，也存在不少痛点：

  1. 维护多套组件，运维成本高；

  2. 各组件 SQL 语法存在差异，开发维护任务成本高；

  3. 在同指标数据下，需要保证不同组件计算的结果与口径都一致的成本比较高。

多维度的结果数据量大时，MySQL 的查询性能较差。为解决这些痛点，更好地适应公司实时查询需求，我们迫切需要统一 OLAP 引擎，且满足以下要求：

  1. 数据秒级写入，低延迟毫秒级响应；

  2. 复杂场景下，多表关联查询性能好；

  3. 运维简单，方便扩展；

  4. 支持高并发；

  5. 易用性强，开发便捷。对此，我们对比调研了三款存算一体的 OLAP 引擎，得出结论：

  • ClickHouse 使用和维护困难，多表关联性能比较差

  • 性能对比中，StarRocks 相比 Apache Doris （以下简称 Doris）性能更好

StarRocks 明显更能满足我们目前对 OLAP 引擎的诉求，因而最终选择了 StarRocks。

#02

六大优势，StarRocks 脱颖而出

—

基于以上需求，游族网络决定对原有数据平台中数据分析架构进行全面升级与改造，以保证数据的统一管理与高效应用，提升实时响应能力。

  1. 极致的查询性能

  • 分布式执行框架（MPP），可充分利用所有节点资源

  • 列式存储引擎，只需读取部分列数据即可完成数据查询，极大降低了磁盘IO

  • 全面向量化，实现了 SMID 的特性，当需要对一列数据进行相同的操作时，可以使用单条指令操作多条数据，是在 CPU 寄存器层面实现数据的并行操作

  • 全新自研的 CBO 优化器，在多表关联查询的复杂场景下，可选择相对最优的查询计划，从而提高多表查询速度

下图是基于把星型模型改成单表并用 SQL 查询语句进行测试的结果展示，StarRocks 性能远超 ClickHouse 与 Apache Druid（以下简称 Druid），在低基准数据聚合的查询对比方面，StarRocks 同样具备更优的查询性能。

1053×429 32.3 KB
1032×435 31.2 KB

  1. 丰富的导入方式

用户可以根据自己的实际场景选择合适的导入方式：

  • Broker Load

  • Spark Load

  • Stream Load

  • Routine Load

  • Insert into

在大多数场景下，无需借助其他工具，即可完成数据导入，极大地节省了开发时间。

1048×446 43.4 KB

  1. 运维简单：自身架构只有 FE 和 BE 两种组件，不依赖外部组件，运维简便，方便缩扩容；

  2. 丰富的数据模型：支持明细/聚合/更新/主键四种数据模型，同时支持物化视图，针对不同的场景提供灵活选择；

  3. 简单易用：兼容 MySQL 协议，支持标准的 SQL 语法，便于开发，节省学习成本；

  4. 支持多种外部表，如 MySQL、Elasticsearch、Hive 等等，无需导入就可与其他数据源进行关联操作，助力跨数据源查询分析。

#03

全面的应用场景

—

1. 实时计算场景：家长监控中心

应文化部指导与要求，为加强家长对未成年参与网络游戏的监护，提供家长监控渠道，我们研发了家长监控中心小程序。为保证家长能限制未成年的游戏时长和游戏消费，数据中心需实时提供各种账号的游戏时长与充值金额。

解决方案：使用 Flink 实时读取 Kafka 中的日志，计算后实时写入 StarRocks，通过 DataAPI 的方式提供给小程序使用。

1078×267 18.3 KB

（数据流转图）

方案优势：

  • 实时更新特性，满足高时效性要求，可实时更新每个账号的时长信息；

  • 主键模型通过 Delete and insert 方式更新数据，主键存储于内存中，无需合并版本查询，即使在频繁导入的情况下，也不会因为版本数据过多而影响查询，大大提升了查询效率；

  • 在更新频率高且删除条件复杂的情况下使用软删除，通过在删除场景下增加数据标志位，利用主键模型的更新特性来变更标志位，实现删除的目的，同时也可减少无效数据冗余。

2. 报表实时指标计算

引进 StarRocks 后，Flink 只需做简单的 ETL 操作，通过与 HBase 交互生成账号角色首登表，并给对应的日志打上首登标签，读取 MySQL 维表信息做逻辑判断和 IP 解析等等。处理后的数据会写入下级 Kafka，同时写入 Hive 和 StarRocks，最终在 StarRocks 内部做逻辑分层。通过分钟级的调度来完成数据计算，报表系统直接读取 StarRocks 结果数据，并通过 DataAPI 的形式提供对外数据。

706×640 31.3 KB

3. 数据关系模型转变

引入 StarRocks 前，由于 ClickHouse 多表 Join 性能欠佳，数据模型以大宽表为主，通过单表查询来保证查询性能，当维度发生变化时，回溯成本很高；

引入 StarRocks 后，凭借其优秀的多表 Join 能力和支持更新的主键模型，数据模型向星型模型/雪花模型转变。一方面，即使维度发生变化，也无需回溯成本；另一方面，将事实表与维度表解耦，有助于灵活应对多维分析场景。

4. 精确一次性保证

引入 StarRocks 前，ClickHouse 实时写入无法保证数据的精确一次性，在下游计算的时候，需要做各种去重操作，如日志id去重、账号去重、订单去重等等，繁琐且浪费时间。

引入 StarRocks 后，我们使用 Flink-Connector-StarRocks 的插件写入数据，经 Flink 处理数据后可保证精确一次性，可在一定程度上减少后续操作，提高开发效率。

1080×416 23.6 KB

5. 指标存储转变

引入 StarRocks 前，报表结果数据存入 MySQL，需要借助外部工具导入，如 Sqoop、dataX 或者程序写入等。

1080×434 26.1 KB

引入 StarRocks 后，以 StarRocks 为核心，存算一体，数据无需在多个组件间导入导出，还能使用多种组件的外表，提高数据流通性，便于查询分析。

922×392 28.2 KB

6. 常用数据导入方式

  1. 实时数据

  • 通过 Flink-Connector-StarRocks 插件进行导入，其内部实现是通过缓存并批量由 Stream Load 导入。

  • 通过 StarRocks 的 Label 机制来确保 Flink Sink 数据的精确一次性。

StarRocks 的 Label 机制：

  • 在 StarRocks 中，所有导入作业都有一个 Label 标识。

  • 对于相同的 Label，StarRocks 只导入一次。

  • Flink 只需保证重试的 Label 不变，即可确保数据导入是精确一次性的。

  • Label 默认三天保存时效，需做好任务监控，如果超过时效恢复，则容易导致数据重复。

  1. 离线数据

  • 创建 Hive 外表，通过 Insert into select 的方式直接写入结果表。

  • 通过使用手动刷新缓存，保证下一个导入任务执行时，缓存已更新。

StarRocks 刷新缓存有三种方式：

1）自动刷新缓存，默认是两小时刷新一次。

2）手动刷新缓存，执行刷新缓存命令，可立即刷新缓存。

3）自动增量更新元数据，更新性能更好。

7. 分区分桶选择

StarRocks 使用先分区后分桶的方式，如果不分区，则会把整张表作为一个分区。

  • 分区选择：使用 Range 的方式，从数据的管理角度来选择分区键，大多数情况下会使用时间分区，可减少扫描的数据量且实现动态分区。

  • 分桶选择：使用 Hash 的方式，通常会选择高基数的列作为分桶键，以保证数据在各个桶中尽可能均衡。

  • 分桶个数：桶的数量影响查询的并行度，需提前计算数据存储量，将每个 Tablet 设置成 500M 左右。

8. 慢查询分析

在实际场景中，我们经常会遇到表设计不合理或者 SQL 性能不够优化的场景，导致产生很多慢查询。引入 StarRocks 之后，我们可通过查看 Profile 与 Plan 查看分析慢查询的原因。

  • 可在 fe/log/fe.audit.log 中看到所有查询和慢查询信息。

  • Profile 是 BE 执行后的结果，包含了每一步的耗时和数据处理量等数据，可以通过 StarRocks Manager 的图形界面查看详细内容。

1080×409 44.5 KB

#04

未来规划

—

在未来，我们将继续以 StarRocks 为数据平台，进行数据查询分析，同时做好进一步的优化操作，以实现价值最大化。

  • 将剩余的实时场景全部迁入 StarRocks；

  • 建立以 StarRocks 为核心的统一查询分析平台；

  • DataAPI 服务全面集成 StarRocks；

  • 完善 StarRocks 监控，包括慢查询监控、任务监控、性能监控等。

京ICP备2022026421号-1