寡安实时多维阐发的挑战与 StarRocks 的应用_互联网资讯__分享互联网新鲜有趣好玩的事物-云易优站长平台

导读本文将介绍寡何在实时多维阐发才能建立方面的一些理论经历，也包罗本年最新引入StarRocks 的原因以及它帮忙我们处理的一些问题。

文章次要包罗以下几大部门：

1. 实时多维阐发的应用场景

2. 问题与难点

3. 实时多维阐发在寡安的理论

4. 手艺选型的原则和思虑

分享嘉宾｜刘骋宇寡安保险大数据平台开发工程师

编纂整理｜张建闯 BOSS曲聘

出品社区｜DataFun

实时多维阐发的应用场景

我们存眷的核心问题是为什么需要实时的多维阐发，以及实时多维阐发能够应用到哪些场景，处理什么问题。

手艺的开展往往是需求来驱动的，一方面营业的在线化，催生出良多实时的场景，那些场景都对数据的时效性提出了秒级毫秒级的要求，另一方面运营的精细化和阐发的布衣化也催生出多维的阐发需求，那些场景下需要粒度出格细，维度出格丰硕的底层数据，那两部门的叠加起来就催生出了实时多维阐发的场景。

好比在实时营业监控中，需要通过颠簸的归因阐发快速定位到颠簸的原因，及时做一些应对，或者在实时的营销场景中，按照实时的用户行为来调整活动的一些战略，类似的场景良多，下面介绍两个寡安的现实例子。

起首是产物投放运营的场景，寡安实时的报表会在挪动端供给给营业方拜候，在右边如许一个首页上会有保费、保单那些关键目标的监控，以及今天和今天的数据比对。

除了首页以外，还会有右边那张图上边的差别子菜单，以及关于差别主题的更细粒度的数据，营业同窗能够通过那里实时的监控一些关键目标，也能够通过上面的一些挑选和下钻来阐发差别的媒体、产物下面的投放的数据。

在那类的场景里面，特点是和营业强相关的数据，数据量一般是中等规模的，像寡安如许非一线的大厂，每天大要是百万到万万的级别，别的那类场景是跟营业强相关的，凡是对数据的一致性要求会十分高，会要求数据和最新的数据连结一致，好比说保单发作一些修改或退保的时候，需要对汗青的数据停止更正和展现，那是一个难点我们后续还会讨论到，因为和营业强相关，对数据的处置逻辑会比力复杂，目前在寡安有十多个营业场景在运行，每天的拜候量在 1 千摆布，我们能够包管查询时间在 1s 内。

第二个场景是用户行为阐发的场景，在做线上活动的时候，运营人员需要实时查看用户活泼趋向、转化阐发、活泼度阐发等来监控活动的效果，并及时调整活动战略，那个场景和上一个场景区别是，那里次要是日记类数据，日记类数据的特点是数据量比力大，每天凡是都是万万以至上亿的级别，那里相关于营业数据来说没有那么高的一致性要求，一般来说日记多一些，反复一些，只要不丢，不同在必然范畴之内都是能够承受的。

别的，大多是明细数据，处置逻辑相对简单一些。在寡安埋点的笼盖仍是比力完美的，每天的行为日记大要有 20 亿，关于实时的比力复杂的阐发一般在 10s 以内出成果。

问题与难点

接下来介绍一下在那些场景中碰到的问题和难点。

第一个问题是数据更新的问题。

假设早上有一张保单，在晚上发作了退保，那个时候为了包管数据的一致性，需要实时修订早上的那条数据，那就需要对已经落库的某一行数据停止更新，有经历的同窗晓得，像 MySQL 那类 OLTP 的数据库能够很好地撑持更新，但阐发的性能不太行，大部门开源的 OLAP 数据库，好比 ClickHouse，它有很强的阐发才能，但是它撑持更新的代价比力大，会影响查询的性能，所以那里 AP 和 TP 的矛盾是天然的，那么那里若何连结数据的更新，同时撑持查询的性能，或者说怎么在那两者之间找到一个平衡点，是我们碰到的第一个难点。

另一个是实时和离线同时存在带来的一些遍及的问题：

计算：Flink 的 api 越来越成熟，但大部门公司离线的建筑仍然存在，关于新手艺还需要一段时间做察看离线存储：目前还没有出格成熟的处理计划，像数据湖，包罗本年的 Flink 的 table store 之类的手艺也在持续的讨论开展中查询：实时和离线的数据往往以差别的形式，存在差别的处所，若何以一个同一的 schema 对外供给查询。寡安实时多维阐发的挑战与 StarRocks 的应用第6张

那里要提一下在寡安的架构选择，在绝大部门情况下都不会有一个完美的处理计划，更多的时候需要连系其时的营业和手艺布景下，在需求、成本和效率之间选择一个适宜的计划，若何在三角形中找到最适宜的trade-off常常是需要思虑的一个问题。

实时多维阐发在寡安的理论

接下来介绍实时多维阐发计划的理论。

起首从那张图上整体的看下实时多维阐发在寡安的开展过程。

能够看到，在最起头我们是离线数据，离线阐发的阶段，数据是 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 供给对外的查询办事寡安实时多维阐发的挑战与 StarRocks 的应用第11张

关于第一个问题，其时选择的计划是利用 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的断联、超时招致的写入的失败。寡安实时多维阐发的挑战与 StarRocks 的应用第14张

前文是数据更新的处理计划，接下来看第二个问题，我们在统一个场景下实时表和离线表，因为处置的链路、处置逻辑都不不异，表构造、数据粒度和选择的引擎都可能差别，所以若是需要利用同一的 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 平台场景的多样性，以及连结通用性，我们也会持续研究物化视图等比力好的功用，看能否可以进一步提拔查询性能。

我们的架构目前仍然还有良多问题，前文中提到的一些问题也并没有完全处理，包罗存储的流批一体，存储计算别离其实都是社区围绕取舍，试图用更低的成本和更高的效率来实现数据的快准稳的测验考试，我们也会对社区的手艺和开展连结持续的存眷。

手艺选型的原则和思虑

最初分享一下我们在手艺的演进和理论中，对手艺选型的一些思虑。

一套架构不成能适用所有的场景，如今固然有了 StarRocks，但是仍然还有很多的场景在利用 ClickHouse，像在用户行为阐发中，ClickHouse 供给的丰硕的阐发的函数比力有优势。

一个好的手艺选型可以制止许多问题，好比 StarRocks 就让我们省去了良多定造化开发和运维的成本，帮忙我们处理了一些性能上的问题。

因而需要按照当前的布景和需求来选择适宜的计划，总结有以下几个原则：

简单：尽可能地连结架构的简单，尽可能不引入没必要要的新手艺，尽可能不做二次开发，若是二次开发尽可能把代码提交到社区，合并到主干里，我们最起头引入Flink的时候，其时版本还比力早，做了比力多的开发，做了两次大版本的晋级，每次都比力痛苦，包罗代码的移植，以及测试，来包管代码的兼容性。可靠：需要引入新的手艺栈的时候，必然要包管手艺的可靠性，必然要选择颠末他人验证的计划，同时本身做好完美的测试，不要急于测验考试最新的手艺，好比 ClickHouse 其实是一个更新迭代比力快的数据库，经常会有一些新的功用，那些新的功用可能会不向下兼容，带来新的 bug，所以我们凡是会选择不变的版本，尽可能降低风险，提拔可靠性。前瞻性：选择计划之前要想一想那个计划能够管用多久，提早考虑将来可能晋级和迁徙的计划，同时对新的手艺以及现有的手艺架构的选型的 roadmap 连结存眷，在适时的时候做更新。

问答环节

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 有本身的存储，应该不会再做一个纯内存的计算引擎，因而相关于一些纯内存计算引擎，他的内存利用会比力少。

今天的分享就到那里，谢谢各人。

｜分享嘉宾｜