关于数据库:游族网络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 同样具备更优的查问性能。

​

​

2. 丰盛的导入形式

用户能够依据本人的理论场景抉择适合的导入形式：

• Broker Load
• Spark Load
• Stream Load
• Routine Load
• Insert into

在大多数场景下，无需借助其余工具，即可实现数据导入，极大地节俭了开发工夫。

​

3. 运维简略：本身架构只有 FE 和 BE 两种组件，不依赖内部组件，运维简便，不便缩扩容；
4. 丰盛的数据模型：反对明细 / 聚合 / 更新 / 主键四种数据模型，同时反对物化视图，针对不同的场景提供灵便抉择；
5. 简略易用：兼容 MySQL 协定，反对规范的 SQL 语法，便于开发，节俭学习老本；
6. 反对多种内部表，如 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 默认三天保留时效，需做好工作监控，如果超过时效复原，则容易导致数据反复。

2. 离线数据

• 创立 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 监控，包含慢查问监控、工作监控、性能监控等。

​

对于 StarRocks

面世两年多来，StarRocks 始终专一打造世界顶级的新一代极速全场景 MPP 数据库，帮忙企业建设“极速对立”的数据分析新范式，助力企业全面数字化经营。

以后曾经帮忙腾讯、携程、顺丰、Airbnb、滴滴、京东、众安保险等超过 170 家大型用户构建了全新的数据分析能力，生产环境中稳固运行的 StarRocks 服务器数目达数千台。

2021 年 9 月，StarRocks 源代码凋谢，在 GitHub 上的星数已超过 3400 个。StarRocks 的寰球社区飞速成长，至今已有超百位贡献者，社群用户冲破 7000 人，吸引几十家国内外行业头部企业参加共建。

​