共计 6413 个字符，预计需要花费 17 分钟才能阅读完成。
2023 年 4 月，StarRocks 3.0 版本正式公布，正式开启了 StarRocks 极速对立的新篇章。从 OLAP 到 Lakehouse，从存算一体到存算拆散，从 ETL 到 ELT，通过两个大版本后 StarRocks 在为用户发明极速对立的数据分析新范式上有了更深一层的思考。本文次要从存算拆散架构、极速数据湖剖析和数据利用三个大方向全面解读 StarRocks 3.0 版本。最初，咱们会对 3.x 后续的布局做一个分享。
StarRocks 社区倒退
自 2021 年 9 月正式开源以来，StarRocks 社区始终放弃着疾速迭代的节奏。目前，StarRocks 在 GitHub 上已取得了 4300+ 个 star，超过 200 名贡献者提交了 15000+ 个 PR，并且有上万人通过 GitHub、微信社群、论坛等形式参加社区建设。同时，超过两百家 10 亿美金估值的大型企业在线上业务应用 StarRocks。
在过来的两年工夫，StarRocks 实现了 1.x、2.x 大版本的迭代。
- 在 1.x 系列版本，StarRocks 主打极速 OLAP 剖析，通过 CBO、向量化引擎、Runtime Filer 等技术做到性能业界当先。
- 在 2.x 系列版本，StarRocks 反对主键模型晋升实时剖析场景的能力、反对 Pipeline、Query Cache 来晋升高并发场景的查问能力，反对极速数据湖剖析简化湖上数据分析，帮忙用户实现极速对立的湖仓剖析。
StarRocks 3.0 简介
3.0 是 StarRocks 的一个里程碑式的大版本，实现了从计算 OLAP 剖析到对立 Lakehouse 的重大产品能力降级。数据能够批量或者流式的写入到 StarRocks 进行极速剖析，也能够在数据湖上间接应用 StarRocks 剖析减速，并通过一系列技术增强湖仓交融，实现 Lakehouse 一体化。
数据仓库 vs. 数据湖
StarRocks 要成为一个 Lakehouse，外围就是要同时具备数仓和数据湖的各项劣势。
数据仓库外围劣势次要蕴含：数据品质高（进到数仓的数据都是通过 ETL 解决）、查问性能高、具备实时剖析的能力、数据治理功能完善等。而数据湖的外围劣势则在于凋谢的生态（数据湖通常采纳凋谢的存储格局）、反对存储各种类型的数据、作为对立存储确保 single source of truth、扩展性强且存储成本低。
StarRocks 3.0 版本次要降级了存算拆散架构，以进步零碎的可扩展性和降低成本。此外，该版本还引入了湖仓交融的概念，旨在为用户提供一站式的 Lakehouse 产品能力。
存算拆散
从 shared-nothing 到 shared-data
在存算一体（shared-nothing) 的架构里，StarRocks 由 FE、BE 组成，FE 负责元数据管理，执行打算构建；BE 负责理论执行以及数据存储管理，BE 采纳本地存储，通过多正本的机制保障高可用。
StarRocks 3.0 提供了存算拆散的架构，BE 节点降级为无状态的 Compute Node（CN) 节点，数据存储从本地存储降级为共享存储，例如采纳 S3 或者 HDFS 来存储数据。
存算拆散架构
存算拆散架构的外围价值在于：存储采纳 S3 等更低成本的共享存储，计算存储独立扩大，升高整体的老本针对计算和存储系统别离进行独立设计和优化，晋升数据的可靠性，服务可用性计算节点无状态，加强零碎弹性扩大的能力
StarRocks 的存算拆散架构的特色在于基于 StarOS 形象层构建，具备很强的扩展性，能同时反对 Cloud、On-premise 的部署模式；StarOS 封装了包含 Shard 调度、Log/File 对象的治理能力，让下层利用能更加简略的构建云原生分布式的能力。
存算拆散价值
存算拆散架构下，StarRocks 的存储从三正本的 EBS（或本地盘）存储，升高为一副本的 S3 对象存储；同时 EBS 的老本个别为 S3 的 4-10 倍，综合计算降级到存算拆散架构，存储老本能够降落 90%。
存算拆散后，计算和存储系统能够别离依据各自的需要进行针对性的优化。通常，存储采纳 S3 对象存储，能够提供 99.999999999% 的数据可靠性；而计算节点则因为无状态，能够通过疾速弹性、跨可用区部署等形式来进步计算的可用性。
另外，在存算拆散架构下，StarRocks 能够不便的反对 Multi-warehouse 的能力；多个 Warehouse 共享一份数据，不同 Warehouse 利用在不同的 Workload，计算资源能够进行物理隔离，并且能够按需独立弹性伸缩。
存算拆散性能
存算拆散架构能带来很多益处，但因为拜访远端存储比拜访本地存储的延时要高很多，通常会带来一些性能的损失。能够通过 Cache 来减速热数据的查问，做到靠近本地存储的成果。以 TPC-DS 1TB 的数据集为例：
- 导入的延时相比存算一体减少 30%
- 查问的总耗时是存算一体的 3 倍；开启 local cache 命中的状况下与存算一体性能持平
湖仓交融
极速对立的湖仓新范式
StarRocks 3.0 另外一个重要的能力降级就是湖仓交融一体化的能力，用户能够抉择多种剖析范式来简化数据分析。数据能够间接入仓剖析，也能够写入数据湖后由 StarRocks 间接剖析湖上数据，无需做数据迁徙；通过物化视图的能力，能够将湖上的数据写入到数仓里减速查问，数仓的计算结果能够再写回数据湖，实现湖仓的无缝交融。
对立 Catalog 治理
为了更简略地间接剖析凋谢数据湖上的数据，StarRocks 提供了对立 Catalog 治理的能力，用户能够通过一键创立 Apache Hive/Apache Hudi/Apache Iceberg（以下简称 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 提早，提早达到拜访本地存储的程度
通过下面一系列技术，StarRocks 间接剖析数据比 Trino 均匀快 3-5 倍，大幅晋升整体的性价比。为了让用户能更不便的从 Trino 到 StarRocks 降级，升高其剖析老本，StarRocks 提供了 Trino SQL 语法兼容的能力（3.0 为预览版性能），将 Trino SQL 主动改写成 StarRocks 的 AST，充分利用 StarRocks 的高性能执行引擎。
凋谢 Lakehouse 架构
StarRocks 具备存算拆散和数据湖剖析能力之后，StarRocks 自身曾经造成了一个分层构造的 Lakehouse 的架构。
- 存储层，对立采纳 S3、HDFS 等共享存储系统
- 在 File format 层，数据湖采纳 Parquet、ORC 等凋谢格局，StarRocks 则有对应的 Segment 文件格式
- 在 Table format 层，数据湖有 Hudi、Iceberg 的组织格局，对应 StarRocks Table 的组织
- 在 Catalog 层，数据湖采纳 HMS，StarRocks 采纳 FE 来对立治理元数据
- 在计算层，数据湖采纳开源的 Spark、Flink 等组件，而 StarRocks CN 节点提供对立的计算
尽管架构理念统一，但 StarRocks 相比数据湖在数据格式拜访优化，数据更新的能力上提供了更好的反对。
物化视图连贯湖仓
借助 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 提供的对立查问入口进行查问。
一站式云原生湖仓
StarRocks 在反对一系列湖仓交融的能力之后，联合存算拆散架构，具备湖仓一体化的能力。用户能够间接将 StarRocks 作为一个 Lakehouse 应用，兼具数据仓库与数据湖的劣势：
- 无需保护两套独立的数据仓库与数据湖零碎
- 反对灵便的存储格局，采纳凋谢存储格局或者 StarRocks 针对实时剖析优化的存储格局
- 采纳计算存储拆散架构，实现 Workload 资源隔离，提供独立按需弹性
- 通过 local cache 机制，实现冷热数据的主动治理
数据利用
除了提供一站式湖仓能力，StarRocks 在数据管理、写入、查问等方面做了很多晋升，指标是让用户构建数据利用更平安、更简略、更高效。
Role Based Access Control
数据进入到 StarRocks，首先要解决的就是数据拜访权限治理的问题。StarRocks 在 2.x 提供了简略的权限管理机制，在 3.0 版本，StarRocks 推出全新的 Role Based Access Control（RBAC）权限机制。
RBAC 简化了权限的受权、变更、回收等。RBAC 反对细粒度权限管制，定义了 40+ 对象，10+ 操作类型，用于灵便定义 Role，比方数据湖上的表和 StarRocks 内表能够通过 Catalog 对象进行对立的权限治理。同时为了简化治理操作，零碎内置一些常见的 Role，比方 DB_ADMIN、USER_ADMIN 等。
RBAC 采纳最小权限准则，当用户领有多个 Role 时，反对设置默认的 Role，也能够在不同的 Session 里设置应用不同的 Role，防止权限误用，晋升安全性。
优化数据分布策略简化建表
StarRocks 的表会依据分区（PARTITION BY）键，切分为多个分区，每个分区会依据分桶（DISTRIBUTED BY）键，再切成多个分桶以利用 MPP 的能力。在过来咱们遇到的次要问题是分区策略表白比较复杂以及分桶数量难以正当设置。
在 3.0 版本中，StarRocks 在分辨别桶治理上做了优化，简化建表语句：
- 引入 PARTITION BY 表达式的分区能力，简化按年、月、日分区的表白，用户无需提前布局分区，而是在导入数据时，零碎按需创立分区。
- 无需指定分桶的数量，建表的时候会主动依据节点资源推算，同时随着数据一直导入，还具备依据历史分区动静调整新分辨别桶数量的能力。
在后续版本，咱们还会持续对建表做简化，反对自适应的数据分布策略，以及主动的数据源类型推断等能力，让 StarRocks 的数据建模更简略。
主键模型 update 语法反对
StarRocks 通过 delete + insert 的形式反对 OLAP 场景的实时 update 能力，在过来的 2.0 系列版本里，次要围绕性能、性能继续进行晋升。在性能方面，反对了 partial update、conditional update 的能力，通过数据列的字段来标识数据操作；在性能方面，从全内存的主键索引降级为长久化的主键索引，解决主键模型内存占用的问题。
在 3.0 版本，StarRocks 更进一步，提供了 Update 语法的反对，包含跨表更新、CTE 等语法的能力，使得 StarRocks 的更新应用起来更加简略。
优化复制链路，晋升写入性能
StarRocks 原来写入时的数据复制机制时 是 Leaderless replication 的形式，写入的数据由一个 coordinator 节点分发给多个正本，每个正本独立的写 memtable、排序、刷盘写成 segment 文件。在 3.0 版本，StarRocks 反对了 Single Leader Replication 策略，写入时先写到一个主正本，主正本写 memtable、排序、刷盘写成 segment 文件，而后间接将 segment 文件同步给其余的正本。
新的数据复制形式，Memtable 内存占用、数据排序、编码的开销降落到原来的 1 /3。此外，在网络传输上，从传输原始数据到传输压缩后的 Segment 文件数据，网络传输量降落到原来的 1/3 ～ 1/5。在大部分场景下，新的复制形式能晋升一倍的写入性能。
Query Cache 减速高并发查问
StarRocks 3.0 进一步欠缺了 Query Cache 的能力，用于减速高并发的实时聚合场景。在很多场景下，用户须要频繁查问最近一段时间的聚合后果，每次查问，相比上一次查问，变动的只有最近一段时间的增量；如果是分区表，分区的数据一旦不再写入，分区的聚合后果也就不再变动，将历史查问后果进行缓存能够无效的复用。在 SSB 场景下的测试中，额定的 Cache 保护开销很小，局部查问减速成果可达 5-10 倍。
算子落盘，优化内存密集型查问
StarRocks 在过来版本里，查问过程中两头后果须要全副在内存，比方 Aggregate、Join 应用的 Hash 表、ORDER BY 的两头后果。对于分布式 memory-intensive 的查问，可能就会因为内存不足而执行失败。StarRocks 3.0 反对了算子落盘的预览版性能，将计算时候的内存分成多个 Partition，查问过程中遇到内存不足时，能够将局部 Partition 内存换出到磁盘，保障查问可能顺利进行，不会因为内存不足而失败。
算子落盘的能力，晋升了物化视图构建的稳定性。此外，除了 OLAP 剖析应用 StarRocks，用户还能够将一些简略的批处理 Job、ETL 等工作放到 StarRocks 里实现，实现极速对立的数据处理。
3.x 版本后续打算
在往年后续的 3.x 系列版本里，StarRocks 会持续在云原生、湖仓交融、极速对立等方向上晋升。云原生架构将晋升弹性伸缩和实时剖析的综合能力；同时，StarRocks 将进一步晋升查问性能、欠缺算子落盘，并加强半 / 非结构化数据的解决来适应更多的数据利用场景。在批量调度的物化视图根底上，StarRocks 还将反对实时物化视图，以进一步简化实时剖析链路的构建，打造极速对立的湖仓新范式。
相干链接：
Release Notes 3.0：https://docs.starrocks.io/zh-cn/main/release_notes/release-3.0
二进制包下载地址：https://www.starrocks.io/download/community
