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


作者: 康凯森

日期: 2022-12-13

分类: OLAP


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

一 极速 OLAP

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

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

我们 StarRcoks 能拥有极致的 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 下的所有表数据,而不是最初一张表一张表配置,极大提升了用户的易用性。

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

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

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

三 主键更新

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

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

  • 主键索引持久化:减少了主键索引的内存使用量,可以支持更大数据量的单表
  • 部分列更新:以现有的 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 资源都不会被占用。

五 物化视图

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,具有以下亮点:

44ebdb2c-950e-400f-8b68-aca5e7c8aa76

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,详情可以参考 https://docs.starrocks.io/zh-cn/latest/using_starrocks/Lateral_join
  4. 支持了 Lambda 函数, 详情可以参考 StarRocks Lambda 函数用户文档

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

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

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 数据库。


欢迎来知识星球和我交流