巨人肩膀
改版通知

巨人肩膀网站已全新改版。若您仍依赖旧站功能或数据，欢迎联系我们，我们会协助处理。联系我们

← 返回专栏列表

最强开源OLAP数据库你应该选择的10个理由

ckckck2025年1月10日59 浏览

编者荐语

实力大神，干货文章。诚意满满，值得好好学习。

以下文章来源于编程小梦，作者康凯森

图片1

编程小梦：有思考，有态度，有观点的价值输出

图片2

2022年即将结束，疫情持续了3年，StarRocks也创立了快3年。今天就总结下StarRocks用户侧可以感知的十大Feature和优化，也希望大家对StarRocks有一个更全面的认知。

一、极速OLAP

图片3

图中是我们官网展示的SSB单表的查询性能对比，可以看到，相比业界其他优秀的OLAP数据库，我们StarRocks在性能上有着明显的优势。不止是SSB单表查询，SSB多表、TPC-H查询、TPC-DS等复杂的多表查询，我们同样拥有极致的性能。TPC-DS查询在100G和1T规模下，StarRocks相比Snowflake有2到3倍的性能优势。

极致的性能不仅可以带来更好的用户体验，让之前难以实现的需求可以实现，更重要的是，可以节省大量的机器，为企业降本增效。

我们StarRocks能拥有极致的OLAP分析性能，是因为2年多来，我们在以下几个方面做了大量持续深入的优化：

  1. MPP分布式执行：StarRocks拥有MPP的分布式执行框架，保证了StarRocks可以充分发挥多机scale out的能力。
  2. Pipeline并行执行框架：我们从零打造了pipeline并行框架，可以让StarRocks充分发挥多核scale up的能力。
  3. 向量化执行：我们从零打造了StarRocks的向量化执行引擎，让StarRocks单核可以拥有极致的执行性能。
  4. CBO优化器：通过MPP分布式执行、Pipeline并行执行和向量化执行，我们拥有了世界领先的查询执行器。但是对于复杂的SQL，优化器产生的Plan好坏对查询性能影响更大，所以我们又从零打造了CBO优化器，让StarRocks对于复杂查询可以产生足够好的Plan，进而对于复杂查询，StarRocks也可以拥有极佳的查询性能。
  5. Global Runtime Filter：Runtime Filter对复杂的join查询影响极大，开关Runtime filter，可以有几十倍的查询，我们在Global和Local Runtime Filter上都做了挺多深度优化和创新。
  6. 全局低基数字典优化：目前主要是可以优化包含低基数字符串的各类查询，整体会有2到3倍的性能提升，面向的场景主要是业务的维表中有大量的低基数字符串列。

对上面技术原理感兴趣的可以参考我们StarRocks官方微信公众号和B站的相关技术分享。

二、极速数据湖分析

当我们拥有了一个极速的查询引擎，可以实现极速OLAP分析后，一个自然而然的想法就是，我们是不是也可以直接查询Apache Hive、Apache Iceberg和Apache Hudi等开源数据湖或数据仓库的数据上呢？答案是Yes！

这样的一个巨大好处是用户省去了数据导入或者同步这个工作，对用户的易用性大大增强。

所以从21年开始，我们就成立了专门的数据湖分析团队，致力于提供开箱即用的极速数据湖分析体验。一年多来，用户侧可以感知的优化和功能如下：

  1. 各种外部数据源接入更加简单：开发了全新的Connector框架和Catalog机制，访问外部数据源变得很容易，只需要配置下Catalog，就可以查询到对应DB下的所有表数据，而不是最初一张表一张表配置，极大提升了用户的易用性。

    图片4

  2. 更加极致的性能：除了查询引擎本身的持续性能提升，数据湖分析额外在Scan算子和外表元数据访问上做了大量优化，在有Local Cache的情况下，外表查询性能可以媲美本地的OLAP表。

    图片5

  3. 更加弹性：当BE不负责数据存储时，就变成了一个无状态的计算节点，弹性伸缩就变得十分自然和容易。而且数据湖分析大多属于Adhoc查询，查询范式不固定，相比与传统的OLAP查询，更需要弹性伸缩的能力。所以我们就新增了一种新的节点：Compute Node——将BE的存储功能移除，只保留计算模块。并和K8S结合，做到了弹性伸缩。

    图片6

  4. 更加安全：我们更好地支持了Kerberos认证，接入了云厂商托管的IAM服务。

三、主键更新

过去两年来，我们从零实现了全新的基于列存的Delete-and-Insert模式的主键更新模型，可以同时支持实时更新和极致的查询性能，在大规模实时数据写入的同时，查询性能可以做到其他行业领先OLAP数据库的3-5倍。

图片7

两年来，我们的主键模型做了如下优化：

  • 主键索引持久化：减少了主键索引的内存使用量，可以支持更大数据量的单表。
  • 部分列更新：以现有的Delete + Insert模式为基础，通过读取老版本数据，来填充缺失列。
  • 条件更新：当满足某个固定条件时才更新对应行，否则就不更新。
  • 高频导入优化：对Publish version过程，compaction过程，合并事务数等优化。
  • Update和Delete语句支持复杂表达式和子查询。
  • 主键和排序键分离。

实时化是整个数据分析的大趋势，而更新的需求也越来越多，有了StarRocks优秀的主键模型，你可以更好的支持下面的业务场景：

  1. CDC实时同步TP数据到StarRocks中，这也是使用最广泛的场景。
  2. 数据处理范式从ETL变成ELT，也需要强大的更新能力。
  3. 实时流中通过多表Join更新数据的场景，有了Partial-Update，就可以代替部分多表Join的需求。
  4. 根据某个时间戳进行条件更新。
  5. ...

四、资源隔离

在生产环境中，大家一般都会遇到大查询的问题：几个大查询吃满了整个集群的资源，影响了正常的小查询，大查询很难及时熔断和定位。针对大查询的问题，我们从2.3版本开始，基于Pipeline执行引擎，实现了资源隔离。目前StarRocks支持了内存资源的硬隔离，CPU和IO资源的软隔离。

我们引入了Work Group的概念，每个Work Group可以配置使用的CPU和IO比例，我们通过两级队列调度和类型Linux CFS调度的算法基本保证了每个Work Group在查询运行时，使用的资源可以符合配置的比例。

同时为了提高资源的利用率，在集群资源空闲时，每个work group可以使用到更多资源，对集群资源的利用率和隔离性进行了兼顾。

对一些高优业务，用户可能期望隔离性更高，我们也支持了短查询Work Group的CPU硬隔离，任何情况下，其对应的CPU资源都不会被占用。

图片8

五、物化视图

StarRocks第一版的物化视图是从Rollup转换而来，只能用来透明加速查询，不能显示直接查询某个物化视图，也就是说物化视图只有物化的语义，没有视图的语义。

我们物化视图2.0版本进行了5方面的加强：

  1. 让物化视图可以直接被查询：将物化视图也视为一张表，这样在复杂的ELT或者ELT的数据处理过程中，就可以使用物化视图来简化SQL。
  2. 在数据建模场景下，支持任意复杂的SQL：也就是说，物化视图里面可以定义任意复杂的SQL，但是不保证每个物化视图都支持透明的查询改写加速。
  3. 在透明加速场景下，支持更复杂的SQL：目前StarRocks已经可以支持Aggregate, Join, Filter, Union等复杂查询的物化视图透明改写。
  4. 支持对数据湖上的数据建立物化视图：对数据湖上的近期热点数据利用物化视图进行强有力的透明加速。
  5. 物化视图支持异步刷新和自动刷新：让物化视图的创建过程和刷新过程更加简单。

在StarRocks 3.0中，物化视图将会有一个质变，成为StarRocks的Killer Feature，大家敬请期待。

六、Tablet Level Query Cache

在实时报表分析和时序查询中，大家经常会遇到分析最近某几天的数据，或者分析今天从零点一直到现在的数据这种场景，在这类查询中，最近某几天的分区或者最近某几个小时的数据可能被高频查询到，这种场景很适合Query Cache发挥作用，StarRocks是基于Tablet粒度实现的Query Cache，具有以下亮点：

图片9
  • Cache命中率高：因为Cache粒度是Tablet粒度，比较细，不是整个查询结果集，或者某个分区的查询结果集，Cache命中率理论上会更高。
  • 支持多版本：支持多版本有多个好处，首先是可以支持高频实时导入，因为tablet旧版本的对应的Cache内容可以复用，只需要旧版本的Cache结果和新版本的增量结果合并即可。
  • 支持Join等多表复杂查询的结果集Cache：不像大多数系统只能支持单表查询的Query Cache。

StarRocks的Query Cache已经在2.5版本发布，欢迎大家使用。

七、半结构化数据分析

过去两年来，StarRocks在持续完善半结构化数据分析能力：

  1. 支持了Array, Map, Struct, Json数据类型。
  2. 支持了大量Array, Map, Struct, Json相关函数。
  3. 支持了Lateral Join和Unnest Table Function，详情可以参考Lateral Join文档。
  4. 支持了Lambda函数，详情可以参考StarRocks Lambda函数用户文档。

有了这些基础能力，你可以用StarRocks做一些更强大的事情：

  • StarRocks可以更好地支持用户行为分析（留存及漏斗分析，路径分析等）。
  • StarRocks可以更好地支持Parquet, ORC等文件导入和分析。
  • 支持Map和Json类型可以让StarRocks更容易进行Schema变更。
  • 支持Json类型让StarRocks对日志分析，事件分析等场景支持更加友好。
  • ...

StarRocks明年也会持续在半结构化数据分析上发力。

八、查询并行度自适应

StarRocks的查询一开始是Fragment并行机制，将每个查询的并行度设置交给了用户，但是这个具体的并行度值用户很难设置。简单查询串行执行时并行度高点性能会好，但是高并发时，并行度高性能反而会更差，因为旧版的执行框架，是每个fragment一个执行线程，fragment数越多，执行线程会更多，线程切换和竞争的开销会更大。

为了解决这个问题，StarRocks一年多来分三步走解决了这个问题：

  1. 实现Pipeline并行引擎：将执行线程数固定成CPU核数，查询默认的并行度改成核数的一半，用户不需要再关心并行度的设置，但是还存在一些优化空间。
  2. 单Tablet内部并行：支持单个Tablet可以并行查询，将查询的并行度和Tablet数解耦，解决了Tablet数较少时无法设置更高并行度的问题。
  3. 查询并行度自适应（下个版本支持）：根据不同的集群复杂和查询类型，自动设置最合理的并行度。默认并行度设置成为核数，当数据量比较少时或者集群负载比较高时，自动减少并行度。

经过这三步，当你在StarRocks时就再也不用自己操心查询并发度的设置了，无论是Benchmark场景，还是高并发场景，无论是复杂的大查询，还是简单的小查询，StarRocks都会自动为你提供开箱即用的极致性能体验。

九、云原生存储分离

大家都知道，Cloud Native是大势所趋，而要支持Cloud Native，StarRocks就必须从之前的Shared-Nothing架构转向存算分离架构。从21年初，StarRocks就组建了专门的Cloud团队全力打造全新的存算分离架构，历经我们Cloud团队长达两年的设计和研发，存算分离的StarRocks第一版已经开发测试完成，目前已经交付部分用户进行试用测试，有想提前尝鲜的用户也欢迎联系我们。

如上图所示（由于官方还未公开过图，我就不放了，大家可以根据《Data-Parallel Actors：千行代码构建高性能OLAP数据库》一文中的描述脑补下），是我们StarRocks新一代的全新架构，我们新一代存算分离架构的核心是StarOS，StarOS一个极具野心的项目，简单来说，StarOS会对分布式相关逻辑进行抽象和统一，对云上存储进行抽象和统一，让我们未来打造一个存算分离服务变得十分简单。具体的技术内幕大家可以期待我们Cloud团队同学之后的深度分享。

那么从用户视角来看，我们全新的存算分离架构会提供什么独特的优势呢？

  1. 在可以弹性伸缩的同时，可以提供媲美Shared-Nothing架构的性能。
  2. 依靠StarOS，同时支持云上部署和本地部署。
  3. 实时更新能力。

当然，普遍存储架构的优点我们已经或即将具备：

  1. 极致弹性。
  2. 更低成本。
  3. 多租户。
  4. 读写分离。
  5. Serverless。
  6. ...

十、SAAS BYOC

所谓云原生的存算分离，我们除了存储分离的内核，还需要在云上将数据库服务化，所以在一边打造存算分离内核的同时，我们也成立了一个专门的团队在打造SAAS服务，我们目前已经推出了BYOC的SASS模式。BYOC是bring-your-own-cloud的缩写，也就是使用用户自己的云，这样会有更好的数据隐私，更好的安全性。如图所示（由于官方还未公开过图，我就不放了），整个架构分为控制面板和数据面板，控制面板在StarRocks的VPC，数据面板在用户的VPC，目前已经有多个用户在正式使用。

我们即将迎来2023年，在新的一年里，StarRocks会带来更多的Killer Feature，也会大力提升稳定性和易用性，努力让StarRocks成为最受欢迎的OLAP数据库。

图片10
end