OLAP(七)：StarRocks

前言

        StarRocks 是一款极速统一的Lakehouse产品，具备水平在线扩缩容，金融级高可用，兼容 MySQL 5.7 协议和 MySQL 生态，提供全面向量化引擎与多种数据源联邦查询等重要特性。StarRocks 致力于在全场景 OLAP 业务上为用户提供统一的解决方案，适用于对性能，实时性，并发能力和灵活性有较高要求的各类应用场景。接下来会从三个方面来剖析 StarRocks 的能力与特点：

• 首先我们先来看一下 StarRocks 是一款什么样的产品，他的产品定位是什么样的，他处于大数据生态什么位置上
• 接下来我们详细的看一下 StarRocks 的功能与特性，了解一下为什么说 StarRocks 是一款Lakehouse产品
• 最后我们通过解读一些基准测试的性能报测试告，看一下 StarRocks 的性能优势如何

        随着越来越多的企业都使用数据驱动决策，数据的价值也被逐步释放。但随着数据量的增长，需求的不断迭代，原有的以 Hadoop 为核心的大数据生态，在性能、实效性、运维难度及灵活性等方面都难以满足企业的需求。OLAP 数据库面临着越来越多的挑战，很难有一种数据库能够适配大部分的业务。在这种情况下，我们一般会使用不同的数据库处理不同类型的业务，充分发挥每种分析型数据库的优势，比如说：

1. •对于 T+1 的报表业务，我们一般是将数据放在 Hive 中定时跑批完成
2. •对于高并发的分析类查询，我们会使用 Druid，缓解高峰时期大量用户集中使用给系统带来的查询压力
3. •对于像固定报表业务，我们预先知道了大部分的查询请求，将可以将数据打平成宽表的，放在 ClickHouse 中，充分发挥 ClickHouse 在单表查询的性能优势
4. •对于明细数据的查询或者全文检索的需求，我们可以使用 Elasticsearch 中，发挥倒排索引的优势
5. •对于多表关联的需求，我们可以通过 Presto 跨数据源完成多表的 join 操作

        一方面，多种技术栈的堆叠确实能够解决我们的问题，另一方面这样的复杂架构也大大增加了开发与运维的成本。这也是 StarRocks 要解决的痛点问题，我们希望把简单的事情回归到简单，能够使用一种统一 OLAP 数据库完成大数据生态中分析层的构建。

一、StarRocks生态定位 

        作为一款 MPP 架构的分析性数据库，StarRocks 能够支撑 PB 级别的数据量，拥有灵活的建模方式，可以通过向量化引擎、物化视图、位图索引、稀疏索引等优化手段构建极速统一的分析层数据存储系统。

在整体的大数据生态中：

•从数据源比如像 Oceanbase 这样的事务性数据库拉过来业务数据，然后通过CloudCanal 这样的数据采集工具写入到 StarRocks 中。（OceanBase是由蚂蚁集团完全自主研发的国产原生分布式数据库）

•中间的一些 ETL 工作，我们可以放在计算引擎中，通过 Flink 或者 Spark 完成，StarRocks 也提供了相应的 Flink Connector 与 Spark Connector

•我们也可以采用 ELT 的模式，在数据加载到 StarRocks 之后，利用 StarRocks 的物化视图，实时 Join 的能力进行数据建模。在 StarRocks 中我们可以选择多种数据模型，比如说预聚合、宽表或者是灵活性比较高的星型/雪花模型

•同时借助于 iceberg、hive 外表的功能，我们打造一套湖仓一体的架构，Iceberg 或者Hive 中的有价值的数据可以流到 StarRocks 中，在 StarRocks 中进行关联查询；StarRocks 里面的隐藏价值数据，或者是价值不太高的数据，也可以流到 Iceberg 或者Hive 中，以低成本的方式长久保存数据，供未来数据挖掘使用。

在经过一系列的建模后，StarRocks 中的数据可以服务于多种业务，比如说报表业务，实时指标监控业务，智能分析业务，客圈圈选业务，自助 BI 业务。

可以说，StarRocks 重构了企业数据基础设施，把复杂的多模分析结构变得简单⽽统⼀。

StarRocks 不依赖于某⼀种技术栈，⽽又能够兼容⼤数据平台的绝⼤部分技术栈：

• 在数据导⼊层⾯上，StarRock 可以拉取 HDFS、S3、OSS 中的数据，也可以导⼊平⾯文件，或者是消费 Kafka 中的增量数据

• 对于像 MySQL 或者 Oceanbase 这样的 TP 业务库，全量数据我们可以通过 dataX， sqoop 等⼯具进⾏同步，增量数据我们可以通过 canal 这样的 CDC ⼯具实时同步。

• 如果在同步的过程中，我们需要进⾏⼀些清洗或者数据转换操作，可以使⽤ Flink 或 者 Spark

• 此外 StarRocks 还⽀持外表联邦查询，可以拉取 Hive、MySQL、ES 以及 Iceberg 中的 数据，与 StarRocks 中的表进⾏关联，避免数据孤岛的存在

• 从顶层协议来看，StarRocks 兼容了 MySQL 协议，可以轻松平稳的对接多种开源或者 商业 BI ⼯具，⽐如说 Tableau，FineBI，SmartBI，Superset 等

适用场景

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

1、OLAP 多维分析

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

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

2、实时数据仓库

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

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

3、高并发查询

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

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

4、统一分析

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

二、StarRocks架构

        StarRocks 整体上架构⽐较简单，有两层结构，黄⾊的是 FrontEnd 节点，蓝⾊的是 BackEnd 节点：

• FrontEnd 节点主要负责元数据的管理和客户端链接的管理，并且根据元数据信息进⾏ 查询的规划和查询的调度。从 MySQL 客户端发起的请求通过 FrontEnd 节点转化成分 布式的 AST，也就是我们所说的执行计划树，推送给对应的 BackEnd 节点。每⼀个 FrontEnd 节点都存储全量的元数据，通过类 Paxos 协议进⾏数据同步，这种多数派的 数据同步协议也保证了我们可以线上⽔平阔所容 FrontEnd 节点。

• BackEnd 节点主要负责数据存储及 SQL 的计算⼯作。FrontEnd 节点按照⼀定的策略 将数据分配给对应的 BackEnd 节点。在执⾏ SQL 计算时，⼀条 SQL 语句⾸先会按照 具体的语义规划成逻辑执⾏单元，然后再按照数据的分布情况拆分成具体的物理执⾏ 单元在 BackEnd 中进⾏计算。BackEnd 节点是完全对等的，数据通过 Qurom 协议进 ⾏同步。BackEnd 节点同样也⽀持在线⽔平阔缩容。

 向量化引擎

        StarRocks 执⾏器的⼀个重⼤的特性就是向量化引擎。通过向量化引擎，可以极⼤程度的提 ⾼查询性能。

        作为⼀个列存数据库，StarRocks 的数据在 BackEnd 存储层是以列的形式组织的。 在没有做向量化引擎之前，数据以列的形式存储，但以⾏的形式被加载到内存中。⽐如说我 们要计算 A 列与 B 列的和，会以⾏的维度不停的调⽤ CPU 的加指令，循环迭代 A0 + B0， A1 + B1，A2 + B2。

        有了向量化引擎之后，StarRocks 在将数据加载到内存中时，也是按照列的形式进⾏布局。 通过调⽤ CPU 的 SIMD 指令集，计算 A 列与 B 列相加，减少了连续的虚函数调⽤，避免 CPU 流⽔线被打断。

        通过向量化引擎的加速，过滤操作⼤概有 5 倍左右的性能提升，聚合操作有 15 倍的性能提 升，关联操作有⼤概 3-4 倍的性能提升。

CBO：基于代价的优化器

          CBO 也是一种非常重要的优化手段。CBO 是指基于代价的优化器。目前大部分的 MPP 计算 引擎都是使用 RBO 的模式，也就意味着我们在写 SQL 的时候，要手动的进行 SQL 的优化，比如说大表与小表谁在前谁在后，WHERE 条件中那些谓词选择性高我们要放在前面， 在比如说，我们在开发中，可能会按照业务的逻辑写一些子查询，在优化的时候，我们可能 需要将这些子查询改写为反业务逻辑的多表关联操作。有了 CBO 优化器后，我们可以将繁琐的优化操作交给 StarRocks，更多的精力放在 SQL 的业务逻辑上。

        StarRocks CBO 目前实现了表达式重写，表达式复用，谓词下推，limit 下推等功能。我们做 了 SSB 10G 的基准性能测试，使用了 CBO 相较于没有使用 CBO，查询大概有三到五倍的性 能提升。

多种分布式Join方式 

         对于实时 Join 的支持是 StarRocks 的一个非常重要的功能。我们提供了不同的 Join 的类型， 比如说小表与大表关联，可以使用 broadcast join，将小表以广播的方式推到不同 server 的内 存中进行关联操作。大表与大表的关联，可以使用 shuffle join 的模式，这也是 MPP 数据库 独有的一种 join 的模式。将数据分割后重新分发到不同的 server 上，利用每一台机器的内存 与 CPU 资源进行计算。当然，在数据 shuffle 的过程中，会带来大量的 IO 开销与网络开 销，可能会影响到查询的性能。

        此时可以人工的进行干预，选择 colocation join 的模式。比如我们在使用星型模型的时候， 预先就会计划好，事实表的 ID 列一定会与维度表的 ID 列进行关联，那么我们在数据导入的 过程中，可以人为的将两张表的 ID 列存储到同一台机器上，查询的时候就不需要进行数据 shuffle，直接在这台机器上进行 join 就可以，最大程度的减少了网络开销带来的性能影响。 通过 CBO 的优化，StarRocks 会根据表的统计信息自动选择出最为合适的 Join 类型。如果我 们对查询的性能有更高的要求，也可以手动的指定 colocation join 这种模式，进行特殊优化 的操作。

 优化数据分布策略简化建表 

        StarRocks 的表会根据分区（PARTITION BY）键，切分为多个分区，每个分区会根据分桶（DISTRIBUTED BY）键，再切成多个分桶以利用 MPP 的能力。在过去我们遇到的主要问题是分区策略表达比较复杂以及分桶数量难以合理设置。

高并发查询

        和大多数的 MPP 数据库不同，StarRocks 支持高并发查询。这得益于 StarRocks 对表的两级 分区管理。
        首先我们会根据数据的业务属性对表进行分区，一般来说我们会将时间列作为分区键，这样 做可以优化根据时间，删除过期数据所带来的性能问题，也方便了冷热数据的分级存储。 分区的下一级是分桶，StarRocks 采用 Hash 算法对分区数据进行分片管理。在同一分区内， 分桶键的哈希值相同的数据被聚集到一起，形成一个子表，我们称之为 tablet。每一个 tablet 都以多副本的形式进行数据冗余存储。同时 tablet 也是做扩容缩容，failover 与 failback 的最小物理单位。

        当表经过分区分桶后，数据的指向性有了显著的提高。如果分区分桶恰好可以有效的覆盖大 部分的查询条件的，那么就可以利用分区分桶剪裁，避免全表扫描。比如在这个例子中，我 们根据 date 列进行了分区操作，又根据 site id 列进行了分桶的操作。查询中，我们既使用 了 date 列，又使用了 site id 列进行条件过滤，通过 date 列的分区我们可能过滤了十几分之 一，再通过 site id 列分桶，又过滤了几十分之一的数据，两者相乘，扫描的数据量可能只是 全表的千分之一甚至万分之一，这样可以降低单个查询的资源消耗，从而实现业务的高并发 查询。在以往的案例中，我们经过分区分桶的操作，加上 StarRocks 的水平扩容的能力，可 以支撑万级别的并发量。

算子落盘，优化内存密集型查询

        StarRocks 在过去版本里，查询过程中中间结果需要全部在内存，比如 Aggregate、Join 使用的 Hash 表、ORDER BY 的中间结果。对于分布式 memory-intensive 的查询，可能就会因为内存不足而执行失败。StarRocks 3.0 支持了算子落盘的预览版功能，将计算时候的内存分成多个 Partition，查询过程中遇到内存不足时，可以将部分 Partition 内存换出到磁盘，保证查询能够顺利进行，不会因为内存不足而失败。

        算子落盘的能力，提升了物化视图构建的稳定性。此外，除了 OLAP 分析使用 StarRocks，用户还可以将一些简单的批处理 Job、ETL 等工作放到 StarRocks 里完成，实现极速统一的数据处理。

灵活数据建模方式 

在 StarRocks 中提供多种不同的建模方式以支撑不同的业务类型。

• 当我们需要召回明细数据的时候，可以使用明细模型
  • 与 MySQL 相同，明细模型中用户插入的数据与表中存储的数据一一对应
  • 像在最上面的例子中，有多少条 insert 的 value 值，表中就新增多少行数据
  • 明细模型底层使用 LSM Tree 数据结构进行存储，我们都知道 LSM Tree 是一 个写友好的数据结构，在 StarRocks 数据存储层，选择了一个两层结构的 LSM Tree，减少了 compaction 对系统的压力，也减少了 write stall 的影响
• 如果我们需要对数据进行预聚合操作，可以使用聚合模型
  • 通过给 value 列添加聚合函数，比如说 sum、min、max、count，在数据导入的 时候，会根据主键完成数据的相应预聚合操作
  • 像上面的例子中，我们在创建表的时候给 pv 列指定了 sum 聚合，新插入的主 键为 (1, 100) 的行会与原表中 (1, 100) 的行进行合并，最后根据 pv 列上的 sum 函数进行聚合操作
  • 对于只需要汇总结果但不需要召回明细数据的场景，我们推荐使用聚合模型
• 如果数据需要频繁的更新，可以使用主键模型
  • 主键模型会根据表中的主键进行 upsert 操作，对于已有的主键做 update 操作， 更新 value 列，没有的主键做 insert 操作
  • 在上面的例子中，新写入的主键为 (1, 100) 的行会替换原表中 (1, 100) 的行
  • 主键模型使用 insert & delete 模式，相较于 merge on read 的更新策略，可以提 供更好的查询性能

主键模型 update 语法支持 

        StarRocks 通过 delete + insert 的方式支持 OLAP 场景的实时 update 能力，在过去的2.0系列版本里，主要围绕功能、性能持续进行提升。在功能方面，支持了 partial update、conditional update 的能力，通过数据列的字段来标识数据操作；在性能方面，从全内存的主键索引升级为持久化的主键索引，解决主键模型内存占用的问题。

在 3.0 版本，StarRocks 更进一步，提供了 Update 语法的支持，包括跨表更新、CTE 等语法的能力，使得 StarRocks 的更新使用起来更加简单。

智能物化视图功能 

在数据建模的时候，我们除了可以使用 StarRocks 提供的明细模型、聚合模型以及主键模 型，也可以通过物化视图来构建数据模型。StarRocks 支持智能的物化视图，用户可以通过 创建物化视图的方式完成预聚合的操作。
我们可以说 StarRocks 的物化视图是一张透明的物化视图，这种透明表现在于两个方面:

• 从数据导入的角度来看，在基表导入数据时，物化视图自动的完成数据的汇聚，物化
  视图与基表保证强一致性数据同步，不需要手动刷新
• 从查询的角度看，在查询时，不需要显示的指定物化视图，在查询中使用基表，
  CBO 也可以将查询重写使用物化视图。在很多自助 BI 的场景，应用层使用 tableau 等报表工具通过拖拉拽的形式生成 SQL，我们无法通过改写 SQL 的方式进行优化， 此时我们可以创建一张物化视图， CBO 自动的将查询改写成使用物化视图语句，帮 助我们完成查询加速

存算分离

从 shared-nothing 到 shared-data

        在存算一体（shared-nothing) 的架构里，StarRocks 由 FE、BE 组成，FE 负责元数据管理，执行计划构建；BE 负责实际执行以及数据存储管理，BE 采用本地存储，通过多副本的机制保证高可用。

        StarRocks 3.0 提供了存算分离的架构，BE 节点升级为无状态的 Compute Node（CN) 节点，数据存储从本地存储升级为共享存储，例如采用 S3 或者 HDFS 来存储数据。

存算分离架构

存算分离架构的核心价值在于：

• 存储采用 S3 等更低成本的共享存储，计算存储独立扩展，降低整体的成本

存算分离架构下，StarRocks 的存储从三副本的 EBS（或本地盘）存储，降低为一副本的 S3 对象存储；同时 EBS 的成本一般为 S3 的 4-10 倍，综合计算升级到存算分离架构，存储成本可以下降 90%。

• 针对计算和存储系统分别进行独立设计和优化，提升数据的可靠性，服务可用性

• 存算分离后，计算和存储系统可以分别根据各自的需求进行针对性的优化。通常，存储采用 S3 对象存储，可以提供 99.99%的数据可靠性；而计算节点则因为无状态，可以通过快速弹性、跨可用区部署等方式来提高计算的可用性。

• 计算节点无状态，增强系统弹性扩展的能力

另外，在存算分离架构下，StarRocks 可以方便的支持 Multi-warehouse 的能力；多个 Warehouse 共享一份数据，不同 Warehouse 应用在不同的 Workload，计算资源可以进行物理隔离，并且可以按需独立弹性伸缩。

存算分离性能

存算分离架构能带来很多好处，但因为访问远端存储比访问本地存储的延时要高很多，通常会带来一些性能的损失。可以通过 Cache 来加速热数据的查询，做到接近本地存储的效果。以 TPC-DS 1TB 的数据集为例：

• 导入的延时相比存算一体增加 30%

• 查询的总耗时是存算一体的 3 倍；开启 local cache 命中的情况下与存算一体性能持平

StarRocks能力

实时能力

接下来我们来看一下 StarRocks 的实时能力。我们从数据摄入、数据更新、数据建模和数据 分析四个方面来剖析一下。

StarRocks 的实时数据摄入能力:

• StarRocks 可以直接订阅 Kafka 中的数据，数据在 Kafka 中微攒批，5-10s 一批进行数
  据同步，可以支撑十几万左右的 TPS
• 如果需要在数据摄入时完成 ETL 的工作，比如一些轻量级的清洗或者拼宽表操作，
  StarRocks 提供了具有 exactly once 的语义的 flink connector，可以将数据直接写入存
  储层，避免了在 FrontEnd 层产生导入瓶颈，相较于 JDBC connector 性能有明显优势
• 我们也可以使用 Flink CDC 直接捕获 TP 库的业务数据变更，简化数据链路

StarRocks 的实时数据更新能力:

• StarRocks 提供了基于 Delete & Insert 模式的主键模式，性能相比 Merge on Read 的更
  新模式提升了 3 倍多 StarRocks 的实时数据建模能力:
• 我们可以通过聚合模型完成实时的数据聚合统计
• 也可以通过 StarRocks 强大的实时多表关联能力支撑星型/雪花模型
• 物化视图的强一致性同步也能进一步加强 StarRocks 的建模能力

StarRocks 的实时数据分析能力:

• StarRocks 有多种性能优化手段，比如说稀疏索引、Bitmap 索引，分区分桶策略、智
  能物化视图
• 我们也可以使用 StarRocks 构建湖仓一体的架构，通过 Hive 外表、Iceberg 外表功能完成实时离线数据的统一融合

湖仓融合一体化的能力

         我们都知道，在湖中数据按照原有的格式进行存储，不需要事先对数据进行结构化处理。数 据湖可以存储结构化数据，半结构化数据，非结构化数据和二进制数据。为了能够满足更多 用户对于极速分析数据的需求，同时让 StarRocks 强大的分析能力应用在更加广泛的数据集上，StarRocks 社区联合阿里云开源大数据 OLAP 团队一起增强 StarRocks 的数据湖分析能力。

        在数据湖分析的场景中，StarRocks 主要负责数据的计算分析，而数据湖则主要负责数据的 存储、组织和维护。

        在 FE 节点中，不仅存储了 StarRocks 内部表的元数据，也存储了 Iceberg 外表的元数据，这样可以实现 StarRocks 与 Iceberg 的数据打通和自由流动。Iceberg 中的有价值的数据可以流到 StarRocks 中，可以在 StarRocks 中进行关联查询;StarRocks 里 面的具有隐藏价值数据，也可以流到 Iceberg 中，以低成本的方式进行长久数据存储，供未来数据挖掘使用。

        StarRocks 3.0 另外一个重要的能力升级就是湖仓融合一体化的能力，用户可以选择多种分析范式来简化数据分析。数据可以直接入仓分析，也可以写入数据湖后由 StarRocks 直接分析湖上数据，无需做数据迁移；通过物化视图的能力，可以将湖上的数据写入到数仓里加速查询，数仓的计算结果可以再写回数据湖，实现湖仓的无缝融合。

统一 Catalog 管理

        为了更简单地直接分析开放数据湖上的数据，StarRocks 提供了统一 Catalog 管理的能力，用户可以通过一键创建 Hive/Hudi/Iceberg 的 Catalog，轻松地分析湖上的所有数据，而无需逐个表进行 schema 建模。此外，通过统一的 Catalog，StarRocks 可以实现对湖上数据的统一管理。

极速数据湖分析

湖上数据分析的主要挑战在于：

• 未经优化的数据组织，例如文件小、row group、column 大小设置不合理等

• I/O 延迟高，无法利用 page cache 加速访问

StarRocks 通过下面一系列的关键技术来加速湖上数据分析性能:

• CBO、向量化引擎、Runtime Filter 等一系列查询层的技术都可以应用到湖上数据分析

• I/O 合并，减少 I/O 次数：StarRocks 实现 Column 读取合并、row group 读取合并、小文件读取合并等多级 I/O 合并机制，提升访问湖上数据的效率，降低 I/O

• 延迟物化，根据带查询条件的部分列过滤结果，再读取其他需要访问的列，减少 I/O 总量

• Local cache 降低 I/O 延迟，延迟达到访问本地存储的水平

开放 Lakehouse 架构

StarRocks 具备存算分离和数据湖分析能力之后，StarRocks 本身已经形成了一个分层结构的 Lakehouse 的架构。

• 存储层，统一采用 S3、HDFS 等共享存储系统

• 在 File format 层，数据湖采用 Parquet、ORC 等开放格式，StarRocks 则有对应的 Segment 文件格式

• 在 Table format 层，数据湖有 Hudi、Iceberge 的组织格式，对应 StarRocks Table 的组织

• 在 Catalog 层，数据湖采用 HMS，StarRocks 采用 FE 来统一管理元数据

• 在计算层，数据湖采用开源的 Spark、Flink 等组件，而 StarRocks CN 节点提供统一的计算

        虽然架构理念一致，但 StarRocks 相比数据湖在数据格式访问优化，数据更新的能力上提供了更好的支持。

• StarRocks Segment 文件支持 Bloomfilter、Bitmap 等各种索引来加速查询

• StarRocks Table 支持通过分区、分桶、排序、colocate 等策略优化数据组织，并提供实时更新的能力

• StarRocks CN 通过 CBO、向量化、Query Cache 等技术来提升查询性能

StarRocks 在支持一系列湖仓融合的能力之后，结合存算分离架构，具备湖仓一体化的能力。用户可以直接将 StarRocks 作为一个 Lakehouse 使用，兼具数据仓库与数据湖的优势：

• 无需维护两套独立的数据仓库与数据湖系统

• 支持灵活的存储格式，采用开放存储格式或者 StarRocks 针对实时分析优化的存储格式

• 采用计算存储分离架构，实现 Workload 资源隔离，提供独立按需弹性

• 通过 local cache 机制，实现冷热数据的自动管理

物化视图连接湖仓

        借助 StarRocks 的开放 Lakehouse 架构，将数据写入 StarRocks 可以提供比在数据湖上更出色的查询性能。同时，为了更好地连接湖仓数据，StarRocks 支持通过物化视图简化数据的 ETL，简化湖仓分层建模。例如，在业务上可以将数据湖作为 ODS 层，并通过建立物化视图将数据加速的数据直接存储在 StarRocks 内部。然后，进一步使用物化视图对数据进行加工处理，形成 DWS、ADS 层的数据，以便不同层级的数据为不同的应用程序提供查询服务。

StarRocks 物化视图的核心价值在于简化湖仓建模，并利用物化视图实现查询加速。StarRocks 3.0 已经支持了比较完备的物化视图能力

• 在物化视图的构建上，支持所有复杂查询，支持基于外部 Catalog 建物化视图以及嵌套物化视图。同时，物化视图可以当一张普通的表进行查询管理。

• 在物化视图刷新方面，采用异步刷新方式，支持周期性或修改触发式的刷新模式，并支持细粒度的刷新控制，以尽量减小物化视图的维护代价。

• 在查询改写上，Scan、Filter、Aggregation、Join、Union 等都支持利用物化视图来自动改写查询加速

开放数据湖构建

        StarRocks 除了支持通过物化视图将湖上数据写入 StarRocks 内部存储进行加速，在后续的 3.x 版本中还会提供直接构建数据湖的能力。通过 StarRocks 写入的数据可以直接存储为 Iceberg 等开放数据湖格式。这个能力使得热数据可以存储在 StarRocks 中，提供实时 OLAP 查询服务；而冷数据则可以归档到数据湖中进行管理，并通过 StarRocks 提供的统一查询入口进行查询。

性能测试

SSB性能测试

         Star schema benchmark(以下简称SSB)是学术界和工业界广泛使用的一个星型模型测试 集，通过这个测试集合可以方便的对比各种 OLAP 产品的基础性能指标。我们都知道， ClickHouse 在单表查询的性能上是非常优秀的，ClickHouse 官网也提供了 SSB 测试的性能 报告。Clickhouse 通过改写 SSB，将星型模型打平转化成宽表，改造成了一个单表测试 benchmark。我们也根据这种模型，进行了一个性能测试对比。

这个性能测试中，我们选取了 StarRocks、ClickHouse 与 Apache Druid，在 SSB 单表数据集 上进行对比，我们一起来看一下测试结果:

• 在 SSB 的 13 个查询上，ClickHouse 的整体查询时间是 StarRocks 的 1.7 倍，Apache Druid 的整体查询时间是 StarRocks 的 2.2 倍
• 在 StarRocks 启用 bitmap index 和 query cache 的情况下，性能更胜一筹，尤其在 Q2.2、Q2.3、Q3.3 上有显著提升。整体性能是 ClickHouse 的 2.2 倍，Apache Druid 的 2.9 倍
• 网站上提供了详细的测试报告具体操作流程以及结果，大家感兴趣的话也可以通过扫 码或者链接获取详细的文档。

TPC-H性能测试

        刚才我们看了单表的 SSB 性能测试，接下来我们来看一下多表关联的测试情况。 在这个测试中我们和 Trino 做了性能的对比，Trnio 是我们熟知的 Presto SQL 的一个分支版 本。主要用于跨数据源多表关联查询。这个性能测试中，StarRocks 与 Trino 都查询同一份 Hive 数据，数据采用 ORC 格式存储，zlib 格式压缩。同时我们也基于这个测试添加了 StarRocks 查询 Hive 外表与直接查询 StarRocks 内部表的一个性能对比。

最终，StarRocks 本地存储查询总耗时为 21s，StarRocks Hive 外表查询总耗时 92s。Trino 查 询总耗时是 StarRocks 的三倍，在 307s 左右。

所以我们可以说，StarRocks 无论在单表查询上，还是多表关联查询上，都有非常大的性能 优势。 

京东物流基于 StarRocks 的数据分析平台建设

图中是 Udata 数据分析平台的产品设计，从下往上看分为 4 个部分：

数据源，现在可以兼容的数据源包括 MySQL、Elasticsearch、ClickHouse、Hive 等,还有一些 API，覆盖了京东大部分数据源，完成了京东生态对接；

底层引擎，基于 StarRocks 打造，数据源会以外表挂载形式接入到查询引擎，底层的查询引擎分为两层：

• StarRocks 实时数仓，应用了 StarRocks 的数据快速摄入能力和高性能的数据查询能力。
• 基于 StarRocks 打造的联邦查询，实现各种数据源跨数据源跨集群的查询，只要数据接入到系统就能进行查询。

产品功能，从数据接入到数据管理、数据使用，以及数据接口编排、在线 Excel，涵盖了数据的生命周期，解决了找数用数的问题。

数据赋能，主要通过数据分析和数据服务来对外赋能，支持的业务场景包含报表分析、办公协同、数据探索、指标监控、数据大屏等等。

图中为湖仓新范式下数据全景图，从下往上看分为 4 层：

• 最下层左侧是生产系统数据区；中间是实时数据加工区，通过 Flink 接收众多系统接入的消息队列消息，然后加工到 OLAP 层；右侧是离线加工区，京东有很多历史数据都存在 Hadoop 里，我们会通过 Spark、Hive 来加工，存到 HDFS、Hive 里。
• 往上一层是 OLAP 层，包含 MySQL、Elasticsearch、ClickHouse 等数据库，另外还有 StarRocks、Paimon。右则是离线区，采用了 Hive 和 HDFS。
• 再往上是采用 StarRocks 搭建的一个支持超级联邦查询的集群引擎。
• 最上层是 Udata 对外赋能提供的能力，包括数据地图、在线分析、数据服务、办公协同等。