众安实时多维分析的挑战与 StarRocks 的应用
导读： 本文将介绍众安在实时多维分析能力建设方面的一些实践经验，也包括今年最新引入StarRocks 的原因以及它帮助我们解决的一些问题。
文章主要包括以下几大部分：
-
实时多维分析的应用场景
-
问题与难点
-
实时多维分析在众安的实践
-
技术选型的原则和思考
分享嘉宾｜刘骋宇 众安保险 大数据平台开发工程师
编辑整理｜张建闯 BOSS直聘
出品社区｜DataFun
01/实时多维分析的应用场景
我们关注的核心问题是为什么需要实时的多维分析，以及实时多维分析可以应用到哪些场景，解决什么问题。
技术的发展往往是需求来驱动的，一方面业务的在线化，催生出很多实时的场景，这些场景都对数据的时效性提出了秒级毫秒级的要求，另一方面运营的精细化和分析的平民化也催生出多维的分析需求，这些场景下需要粒度特别细，维度特别丰富的底层数据，这两部分的叠加起来就催生出了实时多维分析的场景。
比如在实时业务监控中，需要通过波动的归因分析快速定位到波动的原因，及时做一些应对，或者在实时的营销场景中，根据实时的用户行为来调整活动的一些策略，类似的场景很多，下面介绍两个众安的实际例子。
首先是产品投放运营的场景，众安实时的报表会在移动端提供给业务方访问，在左边这样一个首页上会有保费、保单这些关键指标的监控，以及今天和昨天的数据比对。
除了首页以外，还会有右边这张图上边的不同子菜单，以及关于不同主题的更细粒度的数据，业务同学可以通过这里实时的监控一些关键指标，也可以通过上面的一些筛选和下钻来分析不同的媒体、产品下面的投放的数据。
在这类的场景里面，特点是和业务强相关的数据，数据量一般是中等规模的，像众安这样非一线的大厂，每天大概是百万到千万的级别，另外这类场景是跟业务强相关的，通常对数据的一致性要求会非常高，会要求数据和最新的数据保持一致，比如说保单发生一些修改或退保的时候，需要对历史的数据进行更正和展示，这是一个难点我们后续还会讨论到，因为和业务强相关，对数据的处理逻辑会比较复杂，目前在众安有十多个业务场景在运行，每天的访问量在 1 千左右，我们可以保证查询时间在 1s 内。
第二个场景是用户行为分析的场景，在做线上活动的时候，运营人员需要实时查看用户活跃趋势、转化分析、活跃度分析等来监控活动的效果，并及时调整活动策略，这个场景和上一个场景区别是，这里主要是日志类数据，日志类数据的特点是数据量比较大，每天通常都是千万甚至上亿的级别，这里相对于业务数据来说没有那么高的一致性要求，一般来说日志多一些，重复一些，只要不丢，差别在一定范围之内都是可以接受的。
另外，大多是明细数据，处理逻辑相对简单一些。在众安埋点的覆盖还是比较完善的，每天的行为日志大概有 20 亿，对于实时的比较复杂的分析一般在 10s 以内出结果。
--
02/问题与难点
接下来介绍一下在这些场景中遇到的问题和难点。
第一个问题是数据更新的问题。
假设早上有一张保单，在晚上发生了退保，这个时候为了保证数据的一致性，需要实时订正早上的那条数据，这就需要对已经落库的某一行数据进行更新，有经验的同学知道，像 MySQL 这类 OLTP 的数据库可以很好地支持更新，但分析的性能不太行，大部分开源的 OLAP 数据库，比如 ClickHouse，它有很强的分析能力，但是它支持更新的代价比较大，会影响查询的性能，所以这里 AP 和 TP 的矛盾是天然的，那么这里如何保持数据的更新，同时支持查询的性能，或者说怎么在这两者之间找到一个平衡点，是我们遇到的第一个难点。
另一个是实时和离线同时存在带来的一些普遍的问题：
- 计算：Flink 的 api 越来越成熟，但大部分公司离线的建筑依然存在，对于新技术还需要一段时间做观察
- 离线存储：目前还没有特别成熟的解决方案，像数据湖，包括今年的 Flink 的 table store 之类的技术也在持续的讨论发展中
- 查询：实时和离线的数据往往以不同的形式，存在不同的地方，如何以一个统一的 schema 对外提供查询。
这里要提一下在众安的架构选择，在绝大部分情况下都不会有一个完美的解决方案，更多的时候需要结合当时的业务和技术背景下，在需求、成本和效率之间选择一个合适的方案，如何在三角形中找到最合适的trade-off常常是需要思考的一个问题。
--
03/实时多维分析在众安的实践
接下来介绍实时多维分析方案的实践。
首先从这张图上整体的看下实时多维分析在众安的发展历程。
可以看到，在最开始我们是离线数据，离线分析的阶段，数据是 T+1 的，报表是静态的，这个阶段主要是依赖阿里云的 MaxCompute 引擎，以及 CDH 生态来完成的。
在 2018 年，引入 ClickHouse 为交互式多维分析提供了底层的计算能力，这个时候数据依然是离线的，但是可以看到报表不再是静态的，可以自由添加一些筛选和下钻来交互式地分析数据。
在 2019 年 ，引入 Flink，并使用 Flink+MySQL 完成了最初的实时多维分析场景的落地，这时我们进入了实时数据在线多维分析的阶段。在这之后 我们的方案又快速的演变到 Flink+ClickHouse 这样一个相对比较成熟的方案，运行了比较长的时间后，又在2022年初时引入了 StarRocks 解决了一些基于 ClickHouse 分析的痛点，使得实时在线分析更加快速和简单。
在介绍实时之前先介绍一些离线的多维分析架构。离线的架构和技术的建设是我们设计实施方案时比较重要的一个考虑因素，在 2018 年引入 ClickHouse 时，大部分报表都还是静态的报表，没办法自由的动态下钻分析，动态的报表就需要额外的定制化开发，当时为了解决这个问题，建设了一个支持交互式统一的 BI 平台，就是集智平台。
整个平台主要分成两部分：
- 底层的 OLAP 引擎：当时调研过 ClickHouse、Kylin、Druid 还有其他的方案，最后是从性能和长远的技术发展考虑，选定了 ClickHouse。
- 应用层的平台建设：平台可以分为这样几部分，元数据层可以分为元数据和生命周期的管理，查询层会有一些查询 SQL 的动态拼接、数据权限处理、缓存处理，最上层是前端的可视化层，包括拖拽的报表建设和交互式分析的一些逻辑。
当时在元数据层和查询层都做了一些抽象的设计，使得可以更加灵活的适配不同的引擎，最后是相对来说还是比较常见比较标准的离线架构，离线的数据会在数仓里面 T+1 的加工好，以宽表的形式加工到 ClickHouse，最后以集智平台对外提供可视化的数据分析的能力，目前平台已经有 5000+ 的报表与自主创建的分析图表，使用人数超过了 3000+，离线的数据响应的 95 线也是在 3s 内，可以比较好的满足用户的交互式分析需求。
2019 年的时候引入了实时多维分析，当时的使用场景和我们产品投放运营的场景非常类似。在业务初期，当时数据量比较小，业务也比较简单，当时遇到的难点是业务的状态变化需要实时更新业务数据和当时的时间比较紧张，因为没有实时的看板，对于已经上线的活动，业务需要等到第二天才能看到数据，对于投放的效果回收和策略的调整周期会比较长，所以需要短时间内就把实时的看板搭建起来。
在这样的背景下，我们使用 Flink+MySQL 这个方案，一方面是在小数据量下 MySQL还是可以满足我们对数据的更新需求和性能需求，另外 MySQL 是大家最熟悉的数据库，可以在短时间内上线，最后通过平台的一些可视化能力，我们在一周内完成了上线，快速的交付了 10 多张报表。
Flink+MySQL 并不是一个长久的解决方案，随着数据量的增加，实时离线合并的需求，以及越来越多的实时多维分析的需求，需要一个统一的解决方案，我们当时梳理了一下实时和离线两条数据链路，确定了接下来要解决的两个问题：
- 大数量下，如何在支持数据的更新、回撤的同时，保持查询性能
- 离线、实时的数据怎么以统一的 schema 提供对外的查询服务
对于第一个问题，当时选择的方案是使用 ClickHouse 提供的 ReplacingMergeTree 这个引擎，当时主要出于几点考虑：
- ReplacingMergeTree 引擎，在某种程度上提供了单行数据使用主键的更新能力，对于同一个主键的数据，查询的时候使用 final 关键字可以返回最新的数据，只要不断的写入最新数据，并提高版本号就可以完成数据的更新，ClickHouse 后台会不定期的 merge 清理掉历史版本的数据，当时做了一些性能的测试，对于超过千万数据量级的表，查询性能还是可以满足需求的；
- 当时的离线数据都是放在 ClickHouse 里面的，如果引入其他的计算引擎，在实时离线数据需要合并去做一些实时分析的场景，就需要一些比如说外表的方式来查询在 ClickHouse 里面的离线数据，这样会对性能造成比较大的损耗，而且需要对架构和数据做一些迁移，也会产生一些额外的不必要的成本。
这两种方式都不是特别好的选择，但 ClickHouse 在当时对于我们来说比较熟悉，引入其他组件势必会带来一些其他的问题，所以选择 ClickHouse 是一个比较稳妥的选择。
ClickHouse 提供的 ReplacingMergeTree 引擎只是在某种程度上提供了数据更新的基础能力，对于生产可用还是有一定的距离，这里是说在Flink端，在 ClickHouse 当中平台的查询层怎么样相互合作，最终有一个可以落地的方案，对于数据的更新，带上最新的时间作为版本号就可以了，但是对于数据的删除，我们是复用更新的逻辑，更新数据的一列，来标记删除，对于删除，ClickHouse 并不会真正的删除掉这条数据，这样可能会导致表里数据量越来越大，影响到数据的查询性能，所以我们还会通过 ClickHouse 的 ttl 机制给数据添加一个过期时间，这样就能在后台自动清除掉这些数据。
总的来说，我们在 ClickHouse 中选择 ReplacingMergeTree 引擎，建表时指定主键，并预留版本列，标记删除列，过期时间列三列，在平台端，查询的时候添加 final 关键字，并且通过过期时间标记已经删除的数据。
在方案落地过程中，也有一些需要注意的点，首先 ClickHouse 的 merge 操作都是local的，也就是数据只有在同一分片的同一个分区才能合并，这对我们来说，在写入的时候同一个主键的数据必须写入到同一个分片同一个分区，不然查询的时候，数据就会有不一致的情况，我们做了下面几件事情：
- 建表时默认通过按天分区，并且把分区键加入主键，保证同一主键写入同一分区。
- 数据写入时，把每行数据按主键 hash，保证同一主键数据写入同一分片。
- ClickHouse 集群在扩容时，新增的节点会让数据按主键 hash 的分发的规则和之前不一致，导致新老数据被分发到不同的分片，所以集群扩容的时候，需要把老数据按照新的规则 rebalance 重新分发的新的分片。
对于数据写入的稳定性，ClickHouse 本身就不适合高频写入，接入 Flink 的实时写入之后，会对自身的 merge 和 zookeeper 的压力都比较大，这里有几个方式来提升写入的稳定性：
- 写入 local 表，减轻 zk 的稳定性。
- 加入写入的频控和最小的间隔避免高频的实时的写入，给集群造成压力。
- 通过重试的机制避免zk的断联、超时导致的写入的失败。
前文是数据更新的解决方案，接下来看第二个问题，我们在同一个场景下实时表和离线表，由于处理的链路、处理逻辑都不相同，表结构、数据粒度和选择的引擎都可能不同，所以如果需要使用统一的 schema 对外提供服务，很自然的想法就是在查询层做一个逻辑的视图，把这两张表进行合并，以视图的形式对外提供查询，最简单的做法是通过一个时间分区的字段，用 ClickHouse 里提供的 today 函数来判断取哪张表的数据。细心的同学会发现这么做可能会有一个问题，在当天的凌晨到离线的任务处理完的时间内，离线表是没有昨天的数据的，因为任务还没跑完，那么视图就会缺少昨天的数据，我们会通过动态更新的占位符来判断取哪张表的数据，查询层在每次查询的时候会动态的替换这个参数，这样就可以做到离线和实时数据的无缝切换。
这就是最终的 Flink+ClickHouse 的实时多维分析的架构，这套架构在今天也依然在被使用，最多可以支持到千万级别的数据的实时更新，支持了 100 多张报表，日均查询量有 10w+，查询 95 线相比离线来说稍微慢了点，但是也能满足大部分查询需求。
Flink+ClickHouse 这样的一个解决方案可以解决大部分的查询需求，但是依然存在一些问题：
- 架构和逻辑都比较复杂，不论是 Flink 的 connector，还是应用层都做了很多定制开发去完成这些事情；
- 用到的 ReplacingMergeTree 本身的数据量级和查询瓶颈是始终存在的。
熟悉 ClickHouse 的同学都知道，ClickHouse 运维起来是不怎么愉快的，稳定性、大查询抢占资源的问题，DDL 卡死的问题，以及对 zookeeper 的依赖，再加上定制化的开发，整个运维的成本是相对较高的。
随着业务的增长，这套架构的问题，也越来越凸显出来，我们其实也一直在持续的寻找一些解决方案，比如 Presto+Kudu 这样的一些实时更新的方案，甚至对 ClickHouse 定制的查询优化，但是在最后都没有落地，原因是这些方案都不太适合我们当时的场景。直到去年底，我们看到 StarRocks 在 1.19 版本发布的 PrimaryKey 主键模型。
在这里我们看到了一个开源的 OLAP 引擎，支持实时更新的一个新的解决方案，再加上 StarRocks 列存设计，使用方式、适用的场景、支持的数据模型的类型，物化视图之类的功能，其实都和 ClickHouse 比较相像，除了主键模型之外，对多表关联和多并发的能力也比较强，而且运维起来比较简单，加上我们寻找的 OLAP 引擎都可以匹配，最后我们决定投入更多的时间调研和测试，在架构中引入 StarRocks 的可行性。
StarRocks 的 PrimaryKey 主键模型是一种 Merge on Read 的方式，其采用了 delete+insert 的方式，在内存中为每个 tablet 维护了一个主键的索引和一个主键删除的 bitmap，通过 delete 和 insert 来完成这样的操作，这样相对于 Merge on Read 来说，同样可以支持比较频繁的更新，并且在查询的时候避免合并的操作，更重要的是他因为去掉了合并的步骤，去掉了 SQL 中的一些谓词下推和索引依然可以生效，相当于通过牺牲微小的写入性能和内存占用来获取比较大的查询性能的提升。
上图展示了当时我们测试的结果，对于 StarRocks 和 ClickHouse 的查询和写入包括实时更新的场景，都做了对比的测试。首先在标准的查询测试中，单表无并发的场景下 StarRocks 基本和 ClickHouse 是持平的；在其他的比如多并发或者多表关联的场景里面 StarRocks 基本都比 ClickHouse 快不少；但是在写入的测试里面，结果显示StarRocks 比 ClickHouse 要慢 20%~30%；最后在实时更新的场景里，StarRocks的主键模型要比 ClickHouse 的 ReplacingMergeTree 引擎快 3~10 倍，并且查询的性能更加稳定。
这里 StarRocks 的版本使用的是 2.0，ClickHouse 使用的是 21.9 版本，后续 StarRocks 又做了一些优化，估计比这个版本的性能还要好一些。这里测试的结果基本上符合我们的预期，StarRocks 主键模型可以解决在实时更新场景遇到的一些性能问题，所以最后我们决定在基础框架中引入 StarRocks。
引入 StarRocks 之后，OLAP 层替换成了 StarRocks，前面提到在查询层和元数据层都对数据做了抽象，可以快速的完成 StarRocks 的适配，以及快速做 StarRocks 到 ClickHouse 的迁移。最终的效果是，最复杂最耗时的一个实时看板，加载时间从 10s 降低到了 3s 内，并且目前的方案也可以支持更高的数据量级的数据更新。
整体的方案要比之前的更加快速和简单了。
最后，展示一些集智平台集成 StarRocks 的开发流程，只需要三步就可以快速搭建出一个实时的多维分析报表。
在平台上定义好 StarRocks 的模型相关的元数据信息，schema、主键、数据分部键，包括模型的引擎。
在详情页可以直接拿到 FlinkSQL 的建表语句，可以直接在第二步新建一个实时任务，把这个语句直接粘进去，点击运行之后就有数据落入 StarRocks 中了。
定义好模型之后就可以在看板搭建的页面，直接开始搭建数据看板了。
回顾落地整个 Flink+StarRocks 方案的过程中，遇到的一些需要注意的点：
- StarRocks 和 ClickHouse 比较大的区别是动态分区的概念不太一样，StarRocks 的动态分区其实是按照指定的规则，自动创建一些分区，而不是像 ClickHouse 在数据写入的时候，自动创建一些不存在的分区，所以在写入的时候要注意数据是否超过已有分区范围，在建表的时候要预留分区，也要指定分区规则，另外实时写入的时候要提前过滤掉这些超出分区的数据。
- 性能对数据的分布敏感，在前期做性能测试的时候，分桶数的不同可能会带来2倍以上的性能差距，所以对于数据量大，性能要求又比较高的表可以调整一下分桶数这个参数。
主键模型的内存消耗一定的常驻内存开销，对于数据量较大的表，需要预先设计主键并预估内存的占用，避免内存溢出的发生，这里 StarRocks 也在不断的做优化，2.3 版本应该提供了一些参数，可以通过持久化部分索引的方式来降低对内存的消耗。
对于 StarRocks，后期我们也会持续关注社区的一些发展方向，探索用户行为数据分析，用户画像的一些应用，以及 StarRocks 和数据湖的集成。不论是 StarRocks 还是 ClickHouse，为了适应 BI 平台场景的多样性，以及保持通用性，我们也会持续研究物化视图等比较好的功能，看是否能够进一步提升查询性能。
我们的架构目前依然还有很多问题，前文中提到的一些问题也并没有完全解决，包括存储的流批一体，存储计算分离其实都是社区围绕取舍，试图用更低的成本和更高的效率来实现数据的快准稳的尝试，我们也会对社区的技术和发展保持持续的关注。
--
04/技术选型的原则和思考
最后分享一下我们在技术的演进和实践中，对技术选型的一些思考。
一套架构不可能适用所有的场景，现在虽然有了 StarRocks，但是依然还有不少的场景在使用 ClickHouse，像在用户行为分析中，ClickHouse 提供的丰富的分析的函数比较有优势。
一个好的技术选型能够避免许多问题，比如 StarRocks 就让我们省去了很多定制化开发和运维的成本，帮助我们解决了一些性能上的问题。
因此需要根据当前的背景和需求来选择合适的方案，总结有以下几个原则：
- 简单：尽可能地保持架构的简单，尽可能不引入不必要的新技术，尽可能不做二次开发，如果二次开发尽可能把代码提交到社区，合并到主干里，我们最开始引入Flink的时候，当时版本还比较早，做了比较多的开发，做了两次大版本的升级，每次都比较痛苦，包括代码的移植，以及测试，来保证代码的兼容性。
- 可靠：需要引入新的技术栈的时候，一定要保证技术的可靠性，一定要选择经过别人验证的方案，同时自己做好完善的测试，不要急于尝试最新的技术，比如 ClickHouse 其实是一个更新迭代比较快的数据库，经常会有一些新的功能，这些新的功能可能会不向下兼容，带来新的 bug，所以我们通常会选择稳定的版本，尽可能降低风险，提升可靠性。
- 前瞻性：选择方案之前要想一想这个方案可以管用多久，提前考虑未来可能升级和迁移的方案，同时对新的技术以及现有的技术架构的选型的 roadmap 保持关注，在适时的时候做更新。
--
05/问答环节
Q1：Flink 在众安主要做哪些工作？
A1：Flink 除了实时 BI 分析，还会用在其他的实时用户标签、实时营销、实时风控等类似的场景。
Q2：多维分析的情况下，StarRocks 相比 Kylin 有哪些差异？
A2：首先 StarRocks 和 Kylin 虽然都是 OLAP 的引擎，但底层的逻辑其实是不一样的，Kylin 主要是基于预计算的，StarRocks 主要是基于 MPP 架构的引擎。性能方面，对于 Kylin 来说，只要预先定义好的一些维度指标，预先计算好的，如果命中了，性能肯定是比临时计算的要快，但是对于一些没有命中的查询，那就需要一些谓词的下推，会推到底层的 HDFS 上重新做临时的计算，性能就会比较差。我们最开始使用离线分析的架构也考虑过 Kylin，相比 ClickHouse 也会有维度爆炸的问题，所以当时我们最终也选择了 ClickHouse。
Q3：现在的链路还是Flink计算，然后用 StarRocks 查询吗？
A3：现在的链路还是偏 lambda 架构的链路，Flink 主要负责一些简单的计算，比如维度的扩充，基本上就是 DWD 层的数据会直接落入到 StarRocks 里面，基本就是以一张大宽表的形式对外提供查询的服务。
Q4：StarRocks 和 ClickHouse 各自的适用场景是哪些？
A4：StarRocks 和 ClickHouse 使用场景比较相像，适用的场景也提到过了，高频的实时更新的场景，StarRocks的主键模型会比较有优势，ClickHouse 相对于 StarRocks 的优势是有比较丰富的函数，比如各种关于数组的方法，还有漏斗、留存以及路径分析的函数，比如在用户的行为分析中，ClickHouse 会比较有优势，StarRocks 在最近的版本也支持了漏斗、留存等这样的函数。
Q5：StarRocks 的优化经验可以分享一下吗？
A5：数据的分布对性能影响比较大，推荐是对表设计一个合理的分区、分布键和分桶，分区需要使用比较常用的一些字段，比如时间，第二个是分布键和分桶，分布键通常会使用基数比较大的来做分布键，这样可以使数据分布的更加均匀。关于分桶数大家可以去看 StarRocks 文档上的一些推荐的准则，另一方面 StarRocks 也会有一些类似 ClickHouse 的前缀索引相关的概念，可以将查询最常用的字段放在前缀索引里面，这样在查询的时候可以命中索引，减少读取的数据。
Q6：有没有考虑过将 StarRocks 替换 Hive？
A6：StarRocks 支持一些外表的方式直接查询 Hive 的数据，以及 Hudi 和 Iceberg等数据湖的技术，我理解 Hive 和 StarRocks 适用的场景不同，Hive 还是真正的支持一些离线的超大型的计算，有不同的 stage 和 shuffle 机制，可以很好的把比较大的计算任务分散成比较小的计算任务去完成。StarRocks 目前还是适用于一些 OLAP 的场景，可能并不适用于这种处理离线任务的场景，换句话说用 Hive 做一些 OLAP 的查询，那么性能就会不如 StarRocks，所以综合来说 StarRocks 和 Hive 的适用场景不太一样，所以也没考虑过用 StarRocks 替换掉 Hive。
Q7：在咱们场景中用到了哪几种模型？
A7：StarRocks 相关的模型主要是主键模型和明细模型，通常偏明细的数据或者说是不需要做修改变更的数据，比如日志类数据，另外是实时的场景，如果有实时更新的需求会使用到主键模型，当然 StarRocks 还提供了很多其他的模型，比如聚合模型，刚刚也提到了平台的通用性，所以暂时并没有很多场景需要用到这些模型。
Q8：StarRocks 只当成计算引擎么，Flink 查询的维表是什么提供的？
A8：维表会有很多场景，通常放在 MySQL 或 HBASE、Redis 里面，通常来说不会放在 StarRocks 里面，也不是不可以，StarRocks 通常并不适用于点查的场景，所以通常来说维表不会用 StarRocks 作为引擎，在 Flink 里面使用。
Q9：会有实时数据和离线数据进行关联么，这个是怎么做的？
A9：这里不太清楚是 Flink 处理时的关联还是查询时的关联，查询时候的关联我们其实是用一个视图的方式来完成的，离线会有一张离线的表，实时会有一张实时的表，会有一个Flink表实时更新这里的数据，最后通过视图的方式来 union 这两个表的数据，对外提供一个统一的查询。
Q10：StarRocks 能加速 Hive 的查询，数据保存在 Hive 中，但是 Hive 查询慢，不知道能不能通过 StarRocks 加速查询？
A10：首先这个我们并没有尝试过，不过大家可以看 StarRocks 的官方文档发布的一些测试，外表使用的 Hive，当时也和 Presto，现在叫 Trino，做了一些性能对比的测试，性能会比 Trino 好一些，所以我觉得是可以加速 Hive 的一些查询的。
Q11：ClickHouse 新版本支持更新和删除？
A11：我不太清楚是哪个新的版本，我之前一直理解 ClickHouse 本身的更新和删除并不是一个真正意义上的更新和删除，虽然 ClickHouse 也支持一些 delete 的语法，但是本质上在后台上做的一些操作，做的是把数据分块重新的生成了新的数据块，把需要剔除的数据剔除掉，这样的一个形式来做到的，按我的理解这种的方式并不是一个真正意义上的更新和删除，首先性能不太好，而且还是一个后台异步执行的任务，并不是做了更新的操作就立即能看到结果的一个方式。
Q12：直接查询 StarRocks 的 BI 软件可以推荐一下吗？
A12：首先集智平台就可以，另外也可以关注一下 StarRocks 的公众号，定期也会发布一些和其他 BI 厂商认证的兼容报告。
Q13：StarRocks 可以支持对象存储，存算分离吗？
A13：StarRocks 本身是不支持对象存储的，本身计算和存储的节点要在同一个节点上，当然现在也可以使用 Iceberg 或 Hudi 这样的外表进行查询，所以我理解可以间接的支持一些对象存储的查询，至于存算分离，目前 StarRocks 还不支持，不过大家可以关注一下他们 GitHub 上的 roadmap。
Q14：StarRocks 哪些场景是不擅长的？
A14：不擅长也就是说 StarRocks 有哪些缺点，函数相比于 ClickHouse 不够丰富。
Q15：StarRocks 使用的是开源版本还是商业版本？
A15：目前使用的是 StarRocks 的开源版本，目前开源和商业版本在底层数据结构和功能上并没有太大的区别。
Q16：Hudi 也能主键更新，统一存储，Spark 查询，这样的劣势是什么？
A16：查询引擎支持更新通常有这样几种方式，比如 ClickHouse 的 Merge on read，Hudi 可能除了 Merge on read 还支持 copy on write，Merge on read 这种方式写的时候比较快，而查询的时候需要做版本的合并，性能就不太好，copy on write 是在写的时候比对历史的数据，重新写一份新的数据，这样就写的性能不太好，读的性能好一些。
Q17：统计历史 N 天数据，和实时数据合并的场景是如何解决的？
A17：有一个视图将历史数据和实时数据进行 union 对外提供查询的服务，这个是为了保证平台的通用性和灵活性的方案，为了性能考虑的话可以把两个数据放在同一张表中，这样其实对性能更加友好一些。
Q18：StarRocks 建议的数据量规模是多大？
A18：这个和集群的配置相关，如果有更多的内存、CPU 和硬盘，可以支持更多的数据，一般来说有中等配置，16C 或 24C 的配置，支持亿级数据的秒级查询是没有问题的。
Q19：一个集群的一个FE节点支持的 QPS 有多少？
A19：QPS 需要看具体的查询场景和数据量级，单纯从 FE 节点，不考虑 BE 计算的问题的话，官方给出的结果是可以支持一万以上的 QPS。
Q20：StarRocks 和 Doris 选型的依据是什么？
A20：我们选择 StarRocks 的原因主要是主键模型，另外 Doris 并没有一个特别完善的向量化查询的能力，以及一些 CPU 的优化器，所以在一些场景中 Doris 的性能是不如 StarRocks 的。
Q21：使用 StarRocks 而不是用 spark 或 impala 之类的引擎，主要优势是因为快是吗？
A21：有这样几点，第一点首先是从性能上考虑，大家也可以看一看别人，包括官网上给出的一些性能测试，在不同的场景下，不同的计算引擎，表现是不一样的，这里可能需要关注一些具体的场景，但整体来看 StarRocks 的性能还是比较优秀的，另一方面来看像 Spark，Impala 这类的引擎还是比较占用内存的资源的，另外还要考虑社区的活跃度，社区的支持，包括自己本身的一些技术储备。
Q22：StarRocks 和其他内存计算引擎相比，资源占用情况如何？
A22：按我理解，StarRocks 有自己的存储，应该不会再做一个纯内存的计算引擎，因此相对于一些纯内存计算引擎，他的内存使用会比较少。
今天的分享就到这里，谢谢大家。
分享嘉宾
刘骋宇｜众安保险 大数据平台开发工程师
先后从中山大学与北京大学毕业，拥有计算数学相关专业学位。曾在 SAP 中国研究院从事内存数据库与高性能机器学习算法的研发工作。现负责众安集智BI数据分析平台、实时计算平台、机器学习平台等系统平台的规划和研发，有丰富的多维分析实践经验。
DataFun新媒体矩阵
关于DataFun
专注于大数据、人工智能技术应用的分享与交流。发起于2017年，在北京、上海、深圳、杭州等城市举办超过100+线下和100+线上沙龙、论坛及峰会，已邀请超过2000位专家和学者参与分享。其公众号 DataFunTalk 累计生产原创文章900+，百万+阅读，16万+精准粉丝。
