中原银行：基于StarRocks构建OLAP全场景架构解决方案，迈入极速统一时代

Posted 2023-03-31 StarRocks_labs

作者：专业研究的爱分析ifenxi

近年来，随着银行业务场景的不断丰富、业务规模的不断扩张，用户线上线下交易大幅上升，数据量与数据种类愈加丰富，大量创新型数据分析和应用场景出现，对分析型数据库的存储与计算能力提出了更复杂的需求，尤其在对实时数据价值的深入挖掘、数据库查询与分析性能的提高上提出了更高要求。为满足以上需求，银行纷纷开始重塑数据库体系，对已有分析型数据库进行改造，在支撑业务需求的同时简化架构。

近日，专注于数字化市场的研究咨询机构爱分析深入调研了行业中一批国内领先的银行数字化转型实践案例，围绕实践领先型、案例创新性、应用成熟度、价值创造四个维度对多个实践案例进行评选，经过多轮评选与角逐，由StarRocks提供技术支持的“中原银行OLAP全场景架构解决方案”案例凭借其完整且个性化的实施方案、卓越的项目效果当选优秀创新实践案例。该案例中，中原银行借助StarRocks对数据分析架构进行改造升级，构建了全新的数据分析平台，从而提高用数效率，赋能银行经营管理与业务发展。

#01

数据量激增，业务场景多元化，中原银行数据平台需升级

—

中原银行成立于2014年，是河南省唯一一家省级法人银行，今年经改革重组后，该银行总资产规模已突破1.2万亿元，下辖18家分行，有400余家营业网点，2万余名员工以及17家附属机构，目前已成为河南省首家资产超万亿的城商行。

随着业务不断扩张、数据量的高速增长以及业务逻辑复杂程度的不断提升，银行需要更加快速地响应客户，为其提供更加精准的服务，即使用实时数据进行客户洞察，以帮助银行经理与业务人员做出业务决策，提高管理水平。为此，中原银行搭建了一站式商业智能BI平台，该平台分为客户行为分析系统知秋、一站式报表平台鲁班、一站式大屏平台鸿图和自助分析平台云间四大应用系统，总用户超一万人，月活用户在3000以上，月均点击次数为20万以上，用户规模大且使用频率高。

为支持BI平台的快速高效工作，中原银行还搭建了完整的数据平台。该数据平台分为数据源、数据传输、数据存储计算、数据服务与数据应用五大部分。数据源是通过Oracle数据库对核心数据、信贷数据、绩效数据等进行存储。数据传输主要依赖中原银行自主研发的百川离线同步平台与实时传输AR平台。存储计算层主要分为数据湖、离线数仓与实时数仓三部分。其中，数据湖对半结构化数据、非结构化数据和部分系统日志与历史数据进行存储；离线数仓是基于Gauss DB完成跑批作业，对数据进行层层加工传输到读集群中以供报表查询；实时数仓则是对实时数据进行处理辅助进行实时决策。数据服务主要为对存储的报表、分析计算的数据进行查询。数据应用层面向银行客户经理，包括商业智能BI平台与业绩分析等应用系统。

（中原银行改造前的OLAP平台架构）

虽然已有商业智能BI平台与大数据平台已经能够解决中原银行大部分业务问题，但随着数字化转型逐步步入深水区，各业务场景对用数效率提出了更高要求。具体体现在：

• 查询效率亟需提高。中原银行原有的基于MPP和Hadoop构建的数据平台查询效率较低，尤其是多表关联查询效率，BI平台的平均耗时超10秒，知秋系统平均耗时长达20秒以上，严重影响了对客户的深入洞察分析与对银行经营状况的管理。因此，该银行需要提高对业务、经营管理等数据的查询能力，尤其是对复杂的关联数据的查询能力，为其良好的分析性能提供保障。

• 需要升级数据平台架构，深入挖掘实时数据的价值。基于原有的数据平台架构，仅能支持T+1小时级别的准实时报表，需要等待最新的小时任务跑批完成，才可以查询最新时间的数据，难以满足银行在客户分析、风控管理等场景下的实时查询与分析需求。并且，原有架构中需要经过Oracle-AR数据传输平台-Kafka-Flink-Kafka的长链路才能实现对实时数据的查询与分析。因此，银行需要全面升级数据平台架构，尤其是数据分析层的架构，从而满足业务增长带来的实时需求。

• 需要统一数据架构，降低运维成本。原有数据平台流批链路复杂，运维成本高，且实时数据与离线数据的存储并不统一，存在冗余，造成存算资源的浪费。因此，中原银行需要简化数据平台架构，对离线数据与实时数据进行统一高效管理。 

#02

多维度综合考察，最终选择StarRocks升级OLAP架构

—

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

经过调研了市面上的主流的两款OLAP数据库产品发现，ClickHouse在单表查询和大宽表查询表现优秀，查询延迟也比较低，但是Join性能较差，且不易维护；StarRocks在固化查询和灵活分析性能表现不错，多表查询性能也比较优秀，而且同时支持实时与离线导入分析场景。与此同时，StarRocks分析型数据库具有流批一体、能够向量化执行、运维简单、查询效率高、兼容性好且能够满足高并发查询要求六大优势，恰好满足了中原银行构建极速统一的数据分析架构的业务需求。

具体而言，该数据库支持实时和批量两种数据导入方式，以实现极速统一分析；全面采用向量化技术，适配CPU的SIMD指令集等手段，充分发挥其并行计算能力；安装部署容易，高可用易拓展，且扩缩容期间无需停服；能够智能物化视图，通过智能CBO优化器提供亚秒级的多维分析能力；能兼容mysql协议语法与MySQL生态，使用者可快速上手；同时，还能为客户提供高性能高并发的交互式分析体验，查询QPS高于平均水平。六大优势相辅相成，恰好满足了中原银行构建极速统一的数据分析架构的业务需求。

（中原银行OLAP查询引擎选型对比表）

通过POC测试StarRocks分析型数据库的数据导入性能、查询响应速度、与知秋客户洞察系统匹配程度发现，该数据库能够满足极端业务的数据导入性能要求，大幅度提高知秋系统转化分析、客群分群查询、活跃用户查询等应用查询效率，且与银行原有MPP数据库相比，平均性能可以提高3.87倍。

StarRocks 以“打造新一代极速全场景 MPP 数据库，面向复杂查询、高并发、实时分析等各类场景以达成数据价值的最大化”为原则，不断打磨产品，即将面世的 StarRocks 3.0 致力于支持用户同时进行极速分析与极速数据湖分析。StarRocks还坚持发展生态，多方合作以壮大社区，阿里云计算平台事业部产品解决方案总经理陈立就曾表示“StarRocks 是阿里云在数据湖 3.0 云原生化、弹性化、实时化的重要产品之一”。截至目前，StarRocks已帮助超过170家大型企业构建了全新的数据分析能力，生产环境中运行的StarRocks服务器数目达数千台，其社区用户也已超7000人，吸引几十家国内外行业头部企业参与共建。

综合以上结果，中原银行最终选择了产品成熟度高、技术栈与银行主流技术相符、功能完善、安全性高、查询效率高、社区活跃度高的StarRocks分析型数据库。 

#03

StarRocks助力中原银行分阶段升级OLAP架构

—

完成选型后，中原银行开始进行OLAP架构改造。此项目分为三个阶段：集群搭建、离线业务实践与实时业务实践。

（数据分析架构改造路径）

集群搭建

集群搭建是改造前的准备工作，包括与离线传输平台百川、流计算平台的对接，StarRocks集群的规划与搭建，机器资源的申请与分配，此阶段为数据分析架构升级的有序进行奠定了基础。

离线业务实践

为解决对离线数据查询效率低与分析性能差的问题，中原银行将固定离线报表迁移至StarRocks，并对知秋客户行为分析系统进行改造。

该银行的固定报表分为灵活分析、透视分析、电子表格、可视化报表四种形式，共计2800多张，广泛应用于对公、零售、绩效、风险、系统指标监控多个场景下。通过更新建表语句、将原有函数转化为StarRocks内部函数，中原银行实现了固定离线报表的自动化迁移。

（固定离线报表迁移方案）

迁移后的报表具有三大特性。首先，排序列前引入了前缀索引，能够快速过滤数据，减少数据扫描量，从而快速找到起始的目标行；其次，选择了高基数的列（如唯一的ID）作为分桶键，保证了数据在各个分桶内尽可能均衡；最后，默认三副本，不同副本存储在不同BE上，保证某一机器或副本的损坏并不会影响业务查询。这三大特性既避免了数据缺失的问题，又保证了查询效率的提高。

知秋客户行为分析系统有获客分析、增长分析、留存分析、传播分析和特征分析五大分析场景，但由于其分析所需的报表多为上亿级别的大宽表，且需要多表关联查询，查询效率低，分析性能也较差。因此，中原银行将各分析场景也全部转移至StarRocks中，提高其查询响应速度；其次，对留存分析场景进行了Bitmap改造，如针对中原银行驻马店分行所应用的留存分析功能，将原有只能进行单一条件查询或全部查询的方式升级为了Bitmap取交集与并集计算的模式，大大提高了客户数据查询与分析的灵活性与时效性，也丰富了客户行为分析的种类。

实时业务实践

实时数据读写效率低下严重影响了对客户的深入洞察与经营管理查询效率，因此，中原银行在原有数据平台架构上对数据存算层与数据服务层进行改造，搭建了实时数仓。

（中原银行改造后的数据平台架构）

搭建实时数仓后，数据传输不再是统一抽取到Kafka后再进行推送，离线数据将采用broker load的方式将T+1数据直接导入StarRocks中，通过相关SQL命令进行快速分析处理；实时数据则通过Flink connector的方式导入，实现Oracle- Kafka- Flink- StarRocks的实时链路，极大地提高了实时查询与计算的效率。同时，原有的ES实时维表转变成了StarRocks 中主键模型的数据表，它支持自定义主键、指标列与秒级的导入与查询，在查询时能够返回相同组件的最新数据，也促进了实时数据使用效率的提高。

此实时数仓架构将中原银行的离线数据和实时数据进行了统一，极大程度上减少了数据的冗余，同时支持秒级的导入与查询，提高了业务的时效性和多样性。 

#04

升级平台架构，优化查询效率，实现实时响应，提升用数效率

—

目前，中原银行使用StarRocks完成了固定报表迁移、知秋系统改造与实时数仓建设，极大提高了银行的数据导入、查询与分析效率。整体改造后的具体效果如下：

固定报表迁移效率与查询效率大幅提升。70%的报表可以通过自动化迁移来完成。迁移完成后，固定报表查询效率提升为原来的 2.7 倍，所需时间下降到 3 秒以内。尤其是原耗时排行 top 10 的报表，查询效率提优化了10倍以上，提升效果明显。

实现自助客户行为分析，查询效率显著提高。目前，知秋系统内13个业务场景已全部迁移，其中，针对留存分析进行了bitmap 改造，查询效率提升了10 倍以上；其他模块查询效率平均提升3倍以上，平均查询时效为5.8秒。 

实时架构升级，实现秒级响应。通过搭建实时数仓，能够实现秒级响应最新贷款等业务数据的实时查询，管理决策用数效率从T+1小时转换为秒级。在实时存贷款报表应用中，业务人员能够查询到精准到秒级的最新数据，核对存款入账时间从平均半小时缩减至5秒钟，提升了360倍。

通过实时大屏，实时监控银行经营与管理情况。基于实时数仓，中原银行极大程度的丰富了实时大屏的应用场景。目前，智能运营增长平台可以实时监控触达转化数据；鸿图大屏能实时查看对公时点存款、对公时点贷款的余额、对公总客户数与对公的排名情况，辅助业务人员进行实时的分析决策；还能够实时查看当天各项目组DevOps研发效能流水线发版情况、发版成功率、失败率和以及排名情况。 

#05

中原银行为城商行OLAP架构升级提供创新实践典范

—

中原银行作为目前我国排名第八的城商行，此次与StarRocks合作的升级OLAP项目为其他规模相同、已有数据平台建设较完善的城商行提供了标杆。

首先，银行在改造前需深入分析业务需求，基于此进行选型。目前市面上的分析型数据库厂商众多，各产品优势不同；银行不能盲目跟风采购，需要拆解业务需求，并结合技术适配度、安全性、社区活跃度等多维度进行考察与POC测试，选择符合业务需求、适配技术框架的分析型数据库。该项目中，中原银行基于用数效率提高的核心需求，从九大维度中进行考察，最终选择了在查询效率、技术架构与兼容性有明显优势的StarRocks。

其次，项目实施过程应分阶段分场景进行改造。对于中原银行为代表的数字平台建设已经比较完善的银行来说，OLAP的升级比较复杂。因此，应该按照业务场景等逻辑进行任务拆分，有规划的分阶段进行改造，提高项目执行效率。此项目中，中原银行按照业务需求将具体执行阶段划分成离线业务改造与实时业务改造，在9个月内完成了部分系统的升级改造。

未来，中原银行还会携手StarRocks继续深入改造与优化包括数据分析平台在内的数据平台架构，挖掘更多业务场景下的实时报表，进一步探索优化OLAP性能，解决数据湖分析过程中存在IO延迟高、数据格式无法最优化等问题，从而在StarRocks上实现极速分析与极速数据湖分析以提高用数效率并赋能业务增长与银行管理，迈向极速统一3.0时代。 

关于 StarRocks 

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

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

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

得物基于 StarRocks 的 OLAP 需求实践

1. 什么是 StarRocks

• 新一代极速全场景MPP数据库，可以用 StarRocks 来支持多种数据分析场景的极速分析；

• 架构简洁，采用了全面向量化引擎，并配备全新设计的 CBO 优化器，查询速度（尤其是多表关联查询）；

• 很好地支持实时数据分析，并能实现对实时更新数据的高效查询， 还支持现代化物化视图，以进一步加速查询；

• 用户可以灵活构建包括大宽表、星型模型、雪花模型在内的各类模型；

• 兼容 MySQL 协议，支持标准 SQL 语法，易于对接使用，全系统无外部依赖，高可用，易于运维管理。

2. 系统架构

核心进程：FE（Frontend）、BE（Backend）。

注：所有节点都是有状态的。

• FE（Frontend）负责管理元数据，管理客户端连接，进行查询规划、查询调度等工作。

  • Follower

   -   Leader：Follower会通过类Paxos的BDBJE协议选主出一个Leader，所有事务的提交都是由Leader发起，并完成；
   -   Follower：提高查询并发，同时参与投票，参与选主操作。
  

  • Observer：不参与选主操作，只会异步同步并且回放日志，主要用于扩展集群的查询并发能力。

• BE（Backend）负责数据存储以及SQL执行等工作。

3. 存储架构

在StarRocks里，一张表的数据会被拆分成多个Tablet，而每个Tablet都会以多副本的形式存储在BE节点中，如下图：

Table数据划分 + Tablet三副本的数据分布：

StarRocks支持Hash分布、Range-Hash的组合数据分布（推荐）。

为了等到更高的性能，强烈建议使用Range-Hash的组合数据分布，即先分区后分桶的方式。

• Range分区可动态添加和删减；
• Hash分桶一旦确定，不能再进行调整，只有未创建的分区才能设置新的分桶数。

分区和分桶的选择是非常关键的。在建表时选择好的分区分桶列，可以有效提高集群整体性能。

以下是针对特殊应用场景下，对分区和分桶选择的一些建议：

• 数据倾斜：业务方如果确定数据有很大程度的倾斜，那么建议采用多列组合的方式进行数据分桶，而不是只单独采用倾斜度大的列做分桶。
• 高并发：分区和分桶应该尽量覆盖查询语句所带的条件，这样可以有效减少扫描数据，提高并发。
• 高吞吐：尽量把数据打散，让集群以更高的并发扫描数据，完成相应计算。

3.1 表的存储

对表进行存储时，会对表进行分区和分桶两层处理，将表的数据分散到多台机器进行存储和管理。

• 分区机制：高效过滤，提升查询性能。
  • 分区类似分表，是对一个表按照分区键进行分割，可以按照时间分区，根据数据量按照天/月/年划分等等。可以利用分区裁剪对少数访问量，也可以根据数据的冷热程度把数据分到不同介质上。
• 分桶机制：充分发挥集群性能，避免热点问题。
  • 使用分桶键Hash以后，把数据均匀的分布到所有的BE上，不要出现bucket数据倾斜的情况，分桶键的选择原则就是高基数的列或者多个列组合成为一个高基数的列，尽量将数据充分打散。
  • 注：Bucket数量的需要适中，如果希望充分发挥性能可以设置为：BE数量 * CPU core/2，最好tablet控制在1GB左右，tablet太少并行度可能不够，太多可能远数据过多，底层scan并发太多性能下降。
• Tablet：最小的数据逻辑单元，可以灵活设置并行计算资源。
  • 一张表被切分成了多个Tablet，StarRocks在执行SQL语句时，可以对所有Tablet实现并发处理，从而充分的利用多机、多核提供的计算能力。
  • 表在创建的时候可以指定副本数，多副本够保证数据存储的高可靠，以及服务的高可用。
• Rowset：每一次的数据变更就会产生一个Rowset。
  • 就是以组列存方式组织的的一些文件，每次的commit都会产生一个新的版本，每个版本包含哪些Rowset。
  • 每次写入都会增加一个版本（无论是单条、还是stream load几个G的文件）。
• Segment：如果一个Rowset数据量比较大，则拆分成多个Segment数据断落盘。

4. 需求背景

案例一：

• 业务背景

指标工厂服务主要面向业务人员，通过对业务指标的采集和处理，实时反映产品状态，为运营提供数据支撑、检测产品漏洞或服务异常、提供指标异常告警功能等。

• 业务场景分析

业务指标埋点方式多样，并不局限于某种方式，只要符合埋点标识明确、业务参数丰富、数据满足可解析的基本要求皆可作为数据源，大致可以分为：SDK、MySQL BinLog、业务日志、阿里云ODPS数据分析。

存在的挑战，各种业务场景众口难调，归纳数据特征如下：

• • 需要全量日志明细；
  • 需要数据可以始终是最新的，即满足实时更新场景；
  • 需要对数据做层级聚合的，即可能是月、周、日、小时等；
  • 需要可以承载更大的写入量；
  • 每个业务数据都要灵活的配置数据的保存时间；
  • 数据源来源多，报表定制化比较高，有多个数据源合并成一个大宽表的场景、也有多表连接的的需求；
  • 各种监控图、报表展示、业务实时查询等，即较高的并非查询。
• 引入StarRocks：

幸运的是StarRocks有比较丰富的数据模型，覆盖了上面的所有业务场景的需求，即：明细模型、更新模型、聚合模型、主键模型，同时选择更为灵活的星型模型代替大宽表的方式，即直接使用多表关联来查询。

• 明细模型：

1. 埋点数据经过结构化处理后按明细全量存储；
2. 该场景对DB在亿级数据量下查询性能有较高的要求；
3. 数据可以通过配置动态分区来配置过期策略；
4. 场景使用时从结构化数据选择个别字段维度在线聚合查询。

• 聚合模型：

1. 埋点数据数据量巨大，且对明细数据不要求溯源，直接做聚合计算，比如计算PV、UV场景；
2. 数据可以通过配置动态分区来配置过期策略。

• 更新模型：

1. 埋点数据状态会发生变动，且需要实时更新数据，更新数据范围不会跨度多个分区的，比如：订单、优惠券状态等；
2. 数据可以通过配置动态分区来配置过期策略。

基于以上业务场景的分析，这三种模型可以完美解决数据的问题。

需要实时的数据写入场景，我也沿用了业内流行的解决方案，即数据采集到 Kafka 之后，使用Flink做实时写入到StarRocks。StarRocks提供了非常好用的Flink-connector插件。

小tips：

1. 虽然StarRocks已经很好的优化了写入性能，当写入压力大，仍会出现写入拒绝，建议可适当增大单次导入数据量，降低频率，但同时也会导致数据落库延迟增加。所以需要做好一定的取舍，做到收益最大化。

2. Flink的sink端不建议配置过大，会引起并发事务过多的报错，建议每个flink任务source可以配置多些，sink的连接数不能过大。

• 小结

集群规模：5FE(8c32GB)、5BE(32c128GB)

目前该方案已支持数百个业务指标的接入，涉及几十个大盘的指标展示和告警，数据存储TB级，每日净增长上百G，总体运行稳定。

案例二：

• 业务背景

内部系统业务看板，主要服务于全公司员工，提供项目及任务跟踪等功能。

• 业务场景分析

  分析业务特点：

1. 数据变更频繁(更新)，变更时间跨度长
2. 查询时间跨度多
3. 报表需准实时更新
4. 关联维表查询多，部门/业务线/资源域等
5. 冷热数据，最近数据查询频繁

• 历史架构与痛点

当初数据库选型时，结合业务特点，用户需要动态、灵活的增删记录自己的任务，因而选择了JOSN 模型减少了应用程序代码和存储层之间的阻抗，选择MongoDB作为数据存储。

伴随着公司快速快发，当需要报表展示，特别是时间跨度比较大，涉及到多部门、多维度、细粒度等报表展示时，查询时间在MongoDB需要执行10s甚至更久。

• 引入StarRocks

调研了StarRocks、ClickHouse两款都是非常优秀的分析型数据库，在选型时，分析了业务应用场景，主要集中在单表聚合查询、多表关联查询、实时更新读写查询。维度表更新频繁，即存储在MySQL中，StarRocks比较好的支持外表关联查询，很大程度上降低了开发难度，最终决定选用StarRocks作为存储引擎。

改造阶段，将原先MongoDB中的一个集合拆分成3张表。使用明细模型，记录每天的对应人员的任务信息，按天分区，由之前的每人每天一条记录改为，以事件为单位，每人每天可以多条记录。
实现频繁更新的维表，则选择使用外部表，减少维度数据同步到StarRocks的复杂度。

• 小结

改造前，MongoDB查询，写法复杂，多次查询。

db.time_note_new.aggregate(
    [
       '$unwind': '$depart',
       '$match': 
           'depart': '$in': ['部门id'],
           'workday': '$gte': 1609430400, '$lt': 1646064000,
           'content.id': '$in': ['事项id'], 
           'vacate_state': '$in': [0, 1]
       , 
       '$group':  
           '_id': '$depart', 
           'write_hour': '$sum': '$write_hour', 
           'code_count': '$sum': '$code_count', 
           'all_hour': '$sum': '$all_hour', 
           'count_day_user': '$sum': '$cond': ['$eq': ['$vacate_state', 0], 1, 0], 
           'vacate_hour': '$sum': '$cond': ['$eq': ['$vacate_state', 0], '$all_hour', 0], 
           'vacate_write_hour': '$sum': '$cond': ['$eq': ['$vacate_state', 0], '$write_hour', 0]
           -- ... more field
       , 
       '$project': 
           '_id': 1, 
           'write_hour': '$cond': ['$eq': ['$count_day_user', 0], 0, '$divide': ['$vacate_write_hour', '$count_day_user']], 
           'count_day_user': 1, 
           'vacate_hour': 1, 
           'vacate_write_hour': 1, 
           'code_count': '$cond': ['$eq': ['$count_day_user', 0], 0, '$divide': ['$code_count', '$count_day_user']], 
           'all_hour': '$cond': ['$eq': ['$count_day_user', 0], 0, '$divide': ['$vacate_hour', '$count_day_user']]
           -- ... more field
       
    ]
)

改造后，直接兼容SQL，单次聚合。

WITH cont_time as (
    SELECT b.depart_id, a.user_id, a.workday, a.content_id, a.vacate_state
        min(a.content_second)/3600 AS content_hour,
        min(a.write_second)/3600 AS write_hour,
        min(a.all_second)/3600 AS all_hour
    FROM time_note_report AS a
    JOIN user_department AS b ON a.user_id = b.user_id
    -- 更多维表关联
    WHERE b.depart_id IN (?)  AND a.content_id IN (?) 
      AND a.workday >= '2021-01-01' AND a.workday < '2022-03-31' 
      AND a.vacate_state IN (0, 1)
    GROUP BY b.depart_id, a.user_id, a.workday, a.content_id,a.vacate_state
)
SELECT M.*, N.*
FROM ( 
    SELECT t.depart_id,
         SUM(IF(t.content_id = 14, t.content_hour, 0))   AS content_hour_14,
         SUM(IF(t.content_id = 46, t.content_hour, 0))   AS content_hour_46,
         -- ...more
    FROM cont_time t
    GROUP BY t.depart_id
) M
JOIN ( 
    SELECT depart_id                                  AS join_depart_id,
      SUM(write_hour)                                 AS write_hour,
      SUM(all_hour)                                   AS all_hour
      -- 更多指标
    FROM cont_time
    GROUP BY depart_id
) N ON M.depart_id = N.join_depart_id
ORDER BY depart_id ASC

以查询报表2021/01/01~2022/03/01之间数据对比：

• StarRocks: 1次查询聚合，可完全通过复杂SQL聚合函数计算，耗时 295ms

• Mongodb: 需分2次查询+计算，共耗时3s+9s=12s

5. 经验分享

在使用StarRocks时遇到的一些报错和解决方案（网上资料较少的报错信息）：

a.数据导入Stream Load报错：“current running txns on db 13003 is 100, larger than limit 100”

原因：超过了每个数据库中正在运行的导入作业的最大个数，默认值为100。可以通过调整max_running_txn_num_per_db参数来增加每次导入作业的个数，最好是通过调整作业提交批次。即攒批，减少并发。

b. FE报错：“java.io.FileNotFoundException: /proc/net/snmp (Too many open files)”

原因：文件句柄不足，这里需要注意，如果是supervisor管理进程，则需要将文件句柄的配置加到fe的启动脚本中。

if [[ $(ulimit -n) -lt 60000 ]]; then
  ulimit -n 65535
fi

c. StarRocks 支持使用 Java 语言编写用户定义函数 UDF，在执行函数报错：“rpc failed, host: x.x.x.x”，be.out日志中报错：

start time: Tue Aug 9 19:05:14 CST 2022
Error occurred during initialization of VM
java/lang/NoClassDefFoundError: java/lang/Object

原因：在使用supervisor管理进程，需要注意增加JAVA_HOME环境变量，即使是BE节点也是需要调用Java的一些函数，也可以直接将BE启动脚本增加JAVA_HOME环境变量配置。\\

d. 执行Delete操作报错如下：

SQL > delete from tableName partition (p20220809,p20220810) where `c_time` > '2022-08-09 15:20:00' and `c_time` < '2022-08-10 15:20:00';
ERROR 1064 (HY000): Where clause only supports compound predicate, binary predicate, is_null predicate and in predicate

原因：目前delete后的where条件不支持between and操作，目前只支持 =、>、>=、<、<=、!=、IN、NOT IN

e. 使用Routine Load消费kakfa数据的时候产生了大量随机group_id

建议：建routine load的时候指定一下group name。

f. StarRocks连接超时，查询语句报错：“ERROR 1064(HY000):there is no scanNode Backend”，当重新启动BE节点后，短暂的恢复。日志报错如下：

kafka log-4-FAIL, event: [thrd:x.x.x.x:9092/bootstrap]: x.x.x.x:9092/1: ApiVersionRequest failed: Local: Timed out: probably due to broker version < 0.10 (see api.version.request configuration) (after 10009ms in state APIVERSION_QUERY)

原因：当Routine Load连接kafka有问题时，会导致BrpcWorker线程耗尽，影响正常访问连接StarRocks。临时解决方案是找到问题任务，暂停任务，即可恢复。

6. 未来规划

接下来我们会有更多业务接入 StarRocks，替换原有 OLAP 查询引擎；运用更多的业务场景，积累经验，提高集群稳定性。未来希望 StarRocks 优化提升主键模型内存占用，支持更灵活的部分列更新方式，持续优化提升 Bitmap 查询性能，同时优化多租户资源隔离。今后我们也会继续积极参与 StarRocks 的社区讨论，反馈业务场景。

*文 /沈睿