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

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

游族网络股份有限公司(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 同样具备更优的查询性能。

  1. 丰富的导入方式

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

  • Broker Load

  • Spark Load

  • Stream Load

  • Routine Load

  • Insert into

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

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

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

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

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

#03

全面的应用场景

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

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

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

(数据流转图)

方案优势:

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

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

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

2. 报表实时指标计算

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

3. 数据关系模型转变

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

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

4. 精确一次性保证

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

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

5. 指标存储转变

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

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

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 的图形界面查看详细内容。

#04

未来规划

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

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

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

  • DataAPI 服务全面集成 StarRocks;

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