StarRocks和ClickHouse优缺点对比及适用场景

StarRocks适用场景

StarRocks可以满足企业级用户的多种分析需求，包括OLAP（Online Analytical Processing）多维分析、定制报表、实时数据分析和Ad-hoc数据分析等。

OLAP多维分析

利用StarRocks的MPP框架和向量化执行引擎，用户可以灵活选择雪花模型、星型模型、宽表模型或预聚合模型。适用于灵活配置的多维分析报表，业务场景包括：

• 用户行为分析
• 用户画像、标签分析、圈人
• 高维业务指标报表
• 自助式报表平台
• 业务问题探查分析
• 跨主题业务分析
• 财务报表
• 系统监控分析

实时数据仓库

StarRocks设计和实现了Primary-Key模型，能够实时更新数据并极速查询，可以秒级同步TP（Transaction Processing）数据库的变化，构建实时数仓，业务场景包括：

• 电商大促数据分析
• 物流行业的运单分析
• 金融行业绩效分析、指标计算
• 直播质量分析
• 广告投放分析
• 管理驾驶舱
• 探针分析APM（Application Performance Management）

高并发查询

StarRocks通过良好的数据分布特性、灵活的索引以及物化视图等特性，可以解决面向用户侧的分析场景，业务场景包括：

• 广告主报表分析
• 零售行业渠道人员分析
• SaaS行业面向用户分析报表
• Dashboard多页面分析

统一分析

通过使用一套系统解决多维分析、高并发查询、预计算、实时分析查询等场景，降低系统复杂度和多技术栈开发与维护成本。使用StarRocks统一管理数据湖和数据仓库，将高并发和实时性要求很高的业务放在StarRocks中分析，也可以使用External Catalog和外部表进行数据湖上的分析。

产品特性

• MPP分布式执行框架
• Pipeline并行执行框架
• 全面向量化执行引擎
• Global Runtime Filter
• CBO优化器
• 可实时更新的列式存储引擎
• 智能的物化视图
• 数据湖分析
• 存算分离

优点

• 单表查询和多表查询性能都很强，可以同时较好支持宽表查询场景和复杂多表查询。
• 支持高并发查询。
• 支持实时数据微批ETL处理。
• 流式和批量数据写入能力都比较强。
• 兼容MySQL协议和标准SQL。
• 能够保证数据的exactly-once。
• 支持多种分布式Join方式，支持多种数据模型。
• 架构简单，易于维护，无侵入式弹性伸缩与扩容。
• 新版本支持存算分离，尽可能减少依赖外部组件。

缺点

• 数据导入性能：虽然StarRocks支持多种数据导入方式，但在大数据量的情况下，数据导入性能可能会成为瓶颈。
• 数据更新：StarRocks的数据更新操作相对复杂，需要通过DELETE+INSERT或者MOR的方式进行，这可能会影响到数据更新的效率或者查询效率。
• 数据一致性：在分布式环境中，保证数据的一致性是一大挑战。尽管Doris/StarRocks有一套完整的数据一致性保证机制，但在某些情况下，可能还是会出现数据不一致的问题。
• 内存消耗：Doris/StarRocks在处理大数据量的查询时，可能会消耗大量的内存，这可能会对系统的稳定性造成影响。
• ETL能力：大规模ETL能力不足。
• **flink-doris-connector写入是单并行度写入的，flink-connector-starrocks写入是可以支持多并行度写入的，多并行度情况下需要考虑如何保证数据有序性。

ClickHouse适用场景

• 用户行为分析：ClickHouse将用户行为分析表制作成一张大的宽表，减少join的形式，实现路径分析、漏斗分析、路径转化等功能。除此之外，它还能支撑广告、营销和AB实验。
• 实时BI报表：ClickHouse可以根据业务需求，实时制作及时产出，查询灵活的BI报表，包括订单分析、营销效果分析、大促活动分析等。
• 监控：ClickHouse可以将系统和应用监控指标通过流式计算引擎Flink、Spark Streaming清洗处理后，实时写入ClickHouse。结合Grafana进行可视化展示。
• 用户画像：ClickHouse可以对各种用户特征进行数据加工，制作成包含全部用户的一张或多张用户特征表，提供灵活的用户画像分析，支撑广告、圈人等业务需求。

产品特性

1. 完备的DBMS功能
2. 列式存储和数据压缩
3. 向量化执行引擎
4. 关系模型与SQL查询
5. 多样化的表引擎
6. 多线程与分布式
7. 多主架构
8. 在线查询
9. 数据分片与分布式查询

优点

• 为了高效使用CPU，数据不仅按列存储，同时还按向量进行处理。
• 数据压缩空间大，减少IO；处理单查询高吞吐量每台服务器每秒最多数十亿行。
• 索引非B树结构，不需要满足最左原则；只要过滤条件在索引列中包含即可；即使在使用的数据不在索引中，由于各种并行处理机制ClickHouse全表扫描的速度也很快。
• 写入速度非常快，50-200M/s，对于大量的数据更新非常适用。
• 很强的单表查询性能，适合基于大宽表的OLAP多维分析查询。
• 包含丰富的MergeTree Family，支持预聚合。
• 非常适合大规模日志明细数据写入分析。

缺点

• 不支持事务，事务可以是一条SQL语句或一组SQL语言或者整个程序，只要中间有任何错误这个事务的所有操作都要撤销。
• 缺少完整的UPDATE DELETE操作，对于工具自动生成的语句不支持，必须通过变通的方式来完成这两类操作，仅能用于批量删除或者修改数据。
• 部分技术支持待完善，支持有限的操作系统，驱动程序不够完善，市面主流工具对其支持不全。
• 不支持BIOB DOCUMENT类型数据，聚合结果必须小于一台机器的内存大小。
• 不支持高并发，官方建议qps为100，可以通过修改config.xml的max_concurrent_queries配置。
• 不支持二级索引。
• 有限的SQL支持，join实现与众不同。
• 不支持窗口功能。
• 元数据管理需要人工干预维护，运维起来比较麻烦。
• 多表join效率性能比较低。

StarRocks四种模型选择场景

明细模型

• 需要保留原始数据的业务，例如原始日志、原始操作记录等。
• 查询方式灵活，不需要局限于预聚合的分析方式。
• 导入日志数据或者时序数据，主要特点是旧数据不会更新，只会追加新的数据。

聚合模型

• 聚合模型会在数据导入时将维度列相同的数据根据指标列设定的聚合函数进行聚合，最终表格中只会保留聚合后的数据。
• 适合场景：
  1. 不需要原始的明细数据，只关注汇总的结果。
  2. 业务涉及的查询为汇总类查询，比如sum、min、max、count等类型的查询。
  3. 查询维度固定。

更新模型

• 建表时，支持定义主键和指标列，查询时返回主键相同的一组数据中的最新数据。
• 相对于明细模型，更新模型简化了数据导入流程，能够更好地支撑实时和频繁更新的场景。
• 适用场景：实时和频繁更新的业务场景，例如分析电商订单。

主键模型

• 主键模型与更新模型的特点比较接近，主键模型的表要求有唯一的主键，支持对表中的行按主键进行更新和删除操作。
• 适用场景：实时和频繁更新的场景，例如实时对接事务型数据至StarRocks。

StarRocks数据组织形式

StarRocks中的表由行和列构成。在StarRocks中，一张表的列可以分为维度列（也称为Key列）和指标列（也称为Value列）。

StarRocks分区分桶设计

• 分区：针对表的，是对表的数据取段。
• 分桶：针对每个分区的，会将分区后的每段数据打散为逻辑分片Tablet。
• 副本数：针对Tablet的，是指Tablet保存的份数。

StarRocks内部实时更新方案

场景：Full Row Upsert/Delete

• 对数据库里的一行（整行）进行upsert或者delete。

Merge-on-Read

• 当获取CDC数据，排序后直接写入新的文件，不做重复键检查。读取时通过Key值比较进行Merge，合并多个版本的数据，仅保留最新版本的数据返回。

Copy-on-Write

• 当获取CDC数据后，新的数据和原来的记录进行full join，检查新的数据中每条记录跟原数据中的记录是否有冲突（检查Key值相同的记录）。

Delta Store

• 基本思想是牺牲写入性能，换取更高的读性能。

Delete-and-Insert (Merge-On-Write)

• 思路也是牺牲部分写性能，极大地优化读的性能。

StarRocks导入性能对比分析

• Spark Load > Broker Load > Routine Load > Stream Load

StarRocks几种Join的场景和限制

• Shuffle Join：分别将A、B两表的数据按照连接关系都Shuffle到同一批机器上，再进行Join操作。
• Broadcast Join：通过将B表的数据全量的广播到A表的机器上，在A表的机器上进行Join操作。
• Bucket Shuffle Join：在Broadcast的基础上进一步优化，将B表按照A表的分布方式Shuffle到A表的机器上进行Join操作。
• Colocate Join：通过建表时指定A表和B表是同一个Colocate Group，意味着A、B表的分布完全一致。
• Replicate Join：StarRocks的实验性功能，当每一台A表的机器上都存在一份完整的B表数据时，直接在本地进行Join操作。

StarRocks性能优化

• 通过建表优化性能
• 优化导入性能
• 优化Schema Change性能
• CBO优化器开启
• Join优化，选择合理的Join方式
• 利用Query Cache缓存中间计算结果
• Sorted Streaming Aggregate完成有序的排序聚合
• 存算分离，实现数据的持久化
• 根据业务特点和需求调整Compaction相关参数
• 参数调优（BE、FE内存配置、高并发配置、BE、FE内存，并行度、buffer缓冲大小、线程数等）

StarRocks存算分离

• 存算分离架构：FE的功能保持不变。BE原有的存储功能被抽离，数据存储从本地存储（local storage）升级为共享存储（shared storage）。BE节点升级为无状态的CN节点，只缓存热数据。

StarRocks一条SQL的执行流程

1. SQL Parse：将SQL文本转换成一个AST（抽象语法树）。
2. SQL Analyze：基于AST进行语法和语义分析。
3. SQL Logical Plan：将AST转换成逻辑计划。
4. SQL Optimize：基于关系代数、统计信息、Cost模型，对逻辑计划进行重写、转换，选择出Cost“最低”的物理执行计划，CBO Transform。
5. 生成Plan Fragment：将Optimizer选择的物理执行计划转换为BE可以直接执行的Plan Fragment。
6. 通过查询调度器选择合适的数据副本，并将分布式物理执行计划调度到合适的计算节点进行计算。
7. 通过MPP分布式执行框架充分利用多机的资源，做到查询性能可以随着机器数量近似线性扩展。
8. 通过Pipeline并行执行框架充分利用多核资源，做到查询性能可以随着机器核数近似线性扩展。
9. 通过向量化执行引擎充分利用CPU单核资源，将单核执行性能做到极致。

StarRocks索引优化

前缀索引

• StarRocks的底层数据是按照排序键排序后存储的。前缀索引（shortkey index）是在排序键的基础上实现的一种根据给定前缀列，有效加速查询的索引方式。

压缩索引

• StarRocks支持对索引数据的压缩，可以减少磁盘空间的使用，提高查询速度。

Bitmap索引

• Bitmap索引所占的存储空间通常只有索引数据的一小部分，与其他索引技术相比，更节省存储空间。

Bloomfilter索引

• Bloom filter索引可以快速判断表的数据文件中是否可能包含要查询的数据，如果不包含就跳过，从而减少扫描的数据量。

Bitmap索引与Bloom filter索引适用场景与限制

Bitmap使用场景

• 适应场景：
  1. 非前缀过滤
  2. 多列过滤Filter
  3. 人群圈选，精确去重等

Bloomfilter适用场景

• 适应场景：
  1. 非前缀列过滤
  2. 高基数列
  3. 查询需对某列高频过滤，且查询条件是in和=
  4. 非Tinyint、Float、Double、DECIMAL类型的列

MPP架构和Hadoop架构对比

MPP架构

• 将许多单机数据库通过网络连接起来，相当于将一个个垂直系统横向连接，形成一个统一对外服务的分布式数据库系统。

Hadoop架构

• 将不同的资源管理与功能进行分层抽象设计，每层形成一类组件，实现一定程度的解耦。

Flink-StarRocks-Connector Exactly-Once保证

• 自2.4版本StarRocks开始支持Stream Load事务接口。自Flink connector 1.2.4版本起，Sink基于事务接口重新设计实现了exactly-once。

DMP平台优缺点

DMP的优点

1. 数据整合和清洗功能
2. 精准营销
3. 提高决策效率

DMP的缺点

1. 高成本
2. 数据安全问题
3. 技术门槛高

物化视图的应用场景和优缺点

使用异步物化视图场景

• 加速重复聚合查询
• 周期性多表关联查询
• 数仓分层
• 湖仓加速

物化视图缺点

• 存储预计算结果，有额外存储成本
• 基表数据更新时，有更新开销
• 物化视图查询改写能力有很多限制条件

StarRocks实时精准去重

• 方案一：使用了HypoLogLog技术模糊去重后再count distinct，数据新鲜度比较好，但结果是不精确的。
• 方案二：推荐方式，第一层在明细数据上按照城市、时间做增量聚合，可以用bitmap技术和物化视图增量更新技术，先聚合成城市粒度、分钟级的数据。

StarRocks创建外表和Catalog的区别

• StarRocks 3.0之前需要手动创建外表DDR来查询外部数据源，在表很多的时候操作非常繁琐。3.0的Catalog功能可以直接查询Hive、Iceberg、Hudi、Deltalake、ES、Mysql、Oracle、Postgres和文件等各种数据源。

StarRocks点查原理

倒排索引

• StarRocks的Bitmap Index主要包括两部分内容：字典和Bitmap索引本身。

StarRocks前缀索引加速点查

• 如果某个表的过滤条件基数很高，在StarRocks中，就不需要使用Bitmap索引，将该列设置为Sort Key，使用前缀索引过滤即可。

StarRocks RollUp || MaterializedView加速点查

• 当Bitmap索引的过滤度不大，需要Seek很多Data Page时，可以考虑进一步用空间换时间，利用StarRocks的RollUp和Materialized View将不同的过滤列都设置成Sort Key，利用前缀索引加速点查。

StarRocks Generated Column加速点查

• 当过滤的列是Json或者Map类型的Key列时，在StarRocks中，我们可以为这个Key列新增一个Generated Column，然后对Key列建立Bitmap索引，通过Bitmap索引加速点查。

StarRocks支持两级分区分桶和分区裁剪加速查询

• StarRocks支持两级分区分桶，可以首先按照具有时间属性的列分区，再按照高基数列分桶，这样在保证很好的数据本地性的同时也避免了数据倾斜。

StarRocks数据副本

名词解释

1. Tablet：Doris表的逻辑分片，一个表有多个分片。
2. Replica：分片的副本，默认一个分片有3个副本。
3. Healthy Replica：健康副本，副本所在Backend存活，且副本的版本完整。
4. TabletChecker（TC）：是一个常驻的后台线程，用于定期扫描所有的Tablet，检查这些Tablet的状态，并根据检查结果，决定是否将tablet发送给TabletScheduler。
5. TabletScheduler（TS）：是一个常驻的后台线程，用于处理由TabletChecker发来的需要修复的Tablet。同时也会进行集群副本均衡的工作。
6. TabletSchedCtx（TSC）：是一个tablet的封装。当TC选择一个tablet后，会将其封装为一个TSC，发送给TS。
7. Storage Medium：存储介质。Doris支持对分区粒度指定不同的存储介质，包括SSD和HDD。副本调度策略也是针对不同的存储介质分别调度的。

副本状态

• 一个Tablet的多个副本，可能因为某些情况导致状态不一致。Doris会尝试自动修复这些状态不一致的副本，让集群尽快从错误状态中恢复。

副本修复

• TabletChecker作为常驻的后台进程，会定期检查所有分片的状态。对于非健康状态的分片，将会交给TabletScheduler进行调度和修复。

副本均衡

• Doris会自动进行集群内的副本均衡。目前支持两种均衡策略，负载/分区。负载均衡适合需要兼顾节点磁盘使用率和节点副本数量的场景；而分区均衡会使每个分区的副本都均匀分布在各个节点，避免热点，适合对分区读写要求比较高的场景。

存算分离的好处

资源效率优化

• 资源利用率提高：计算与存储资源解耦，资源使用成本优化。
• 异构计算的资源负载混部：在统一存储平台提供面向异构计算的工作资源负载下的多维度查询分析服务。
• 存储降本：存储利用率+冷热分层，支持存储弹性扩展，能支持多种廉价的存储方式。
• 性能优化：由于存储和计算资源可以独立地进行优化和升级，存算分离架构可以更好地适应不同的计算负载和存储需求。
• 查询优化：算子落盘，缓存结果，能复用结果，加速查询。

系统稳定性提升

• SRE可靠性提升：业务稳定性-计算集群与存储集群分别高可用。
• 易于管理：存算分离架构可以简化系统管理和维护的难度。
• 安全性：存算分离架构可以更好地保护数据的安全性和隐私性。

技术创新/业务增效

• 创新数据应用：基于统一存储平台之上对多源异构数据的深度分析数据价值的挖掘，大数据+AI的整合应用，以提升数据协同应用效率。
• 硬件利旧降本：从运维的角度来讲，降低服务器的款型是降低运维难度和工作量的有效手段。
• 行业趋势：行业大数据改造升级。
  end