共计 8765 个字符，预计需要花费 22 分钟才能阅读完成。
作者：StarRocks PMC Chair 赵纯（本文为作者在 StarRocks Summit Asia 2022 上的分享）
一年前，StarRocks 源码凋谢，StarRocks 社区也正式成立。通过一年倒退，社区曾经取得了 3400 个 Star，7500 次的 PullRequest，200 名贡献者，7000 多名的参与者，以后已被 170 多家大型企业所采纳。前面我所讲的所有内容都离不开整个 StarRocks 社区的反对与奉献。
为了可能给用户提供更快、更灵便、更实时的剖析体验，StarRocks 过来一年在产品的性能、性能、稳定性上一直打磨。一年里，StarRocks 一共批改了 80 多万行代码，公布了近 50 个版本。其中咱们反对了物化视图 2.0、资源隔离、极速数据湖剖析等重要性能。
去年这个时候 StarRocks 公布了 Primary Key，进入了极速对立 2.0 时代，用户可能利用 StarRocks 同时进行实时数据和历史数据的剖析。往年咱们正式公布 StarRocks 数据湖剖析，让用户可能在 StarRocks 上同时进行极速 OLAP 剖析与极速数据湖剖析，咱们将它定义成极速对立 3.0。
#01
极速 OLAP
上图展现的是以后 StarRocks 相比一年前在几个规范测试集下的提高。从图中能够看到，通过一年的打磨，StarRocks 在单表 SSB、多表 SSB、TPC-H 三个规范测试集下，相比去年同期又晋升了 50%-80%。接下来我会介绍 StarRocks 几个重磅的性能。
1、物化视图
物化视图蕴含了两个维度的内容，一个维度是物化，一个维度是视图。物化这个维度指的是物化视图要将数据进行物理化存储，这样后续利用就可能间接应用，起到查问减速的成果。视图是逻辑档次的概念，表白的是一个查问的后果集，视图能够间接被用来指定进行查问。用户应用视图更多的是想做一个逻辑的形象，用来简化 SQL。
所以物化视图是两者的交融，一方面可能通过物理层的存储来减速查问，另一方面提供了逻辑层的形象，用来简化用户的 SQL 表白。之前的 StarRocks 也反对物化视图，1.0 版本的物化视图存在着以下几个方面的缺点：
- 表达能力无限，只可能反对单表聚合，不可能反对谓词过滤、简单表达式，更不能反对多表关联，这限度了物化视图应用的场景。
- 用户不可能间接指定物化视图进行查问，这样就没有方法当成一个视图来应用，无奈施展出物化视图在逻辑形象这个维度的能力。
- 物化视图 1.0 分区、分桶形式与根底表齐全绑定，这样就限度了物化视图的利用场景。比方用户想要创立一个浏览的物化视图，然而根底表是依照“天”进行分区的，那么在物化视图 1.0 版本，用户是没有方法实现这样的需要的。
- 物化视图 1.0 只反对同步更新，在根底表导入时，物化视图同步进行导入。只有当物化视图和根底表都导入胜利后，用户的数据才可见。这样有一个弊病，当物化视图数目增多时，导入的时效性就会受到肯定的影响。所以，物化视图 1.0 版本更多像是一个索引，而短少视图这方面的能力。
通过过来一年的设计与研发，StarRocks 公布了物化视图 2.0。物化视图 2.0 是一套全新的物化视图架构，与物化视图 1.0 版本齐全不同。相比于物化视图 1.0，物化视图 2.0 具备以下能力：
- 物化视图 2.0 反对所有简单的查问，包含谓词过滤、简单表达式以及多表关联查问。
- 用户能够间接指定物化视图进行查问，实现查问剖析，这样用户就能够在实现形象逻辑的同时实现剖析的减速。
- 物化视图 2.0 的分区、分桶形式能够与根底表不统一。根底表跟物化视图的分区对应关系能够是一对多、多对一或者是多对多的关系，这样用户就能够更加灵便地构建物化视图。
- 物化视图 2.0 反对异步刷新的机制，所以创立物化视图自身并不会影响数据的导入时效性。StarRocks 外部会依据根底表的变更，智能地判断出哪些物化视图的分区须要更新。StarRocks 会异步地实现物化视图的刷新。
上图展现的是用户在剖析时如何应用物化视图。
图左展现的是，用户能够间接指定物化视图进行剖析。用户在创立物化视图的时候应用较简单的逻辑用于逻辑形象，其余的用户能够间接针对形象之后的视图进行查问剖析。相比于视图，通过做物化视图可能取得更快的查问性能体验。
图右展现的是 StarRocks 可能将用户对原表的查问主动改写为对物化视图的查问。这里的物化视图起到的是一个通明减速的能力。
在传统的数仓建设中，用户不仅要设计数仓模型，更要关注整个数仓加工过程，并且在其中消耗了大量工夫与精力。如果有了物化视图，用户就能够专一在数仓模型自身，而每一层的加工过程都能够通过物化视图来实现。咱们的愿景就是通过物化视图的能力将用户从枯燥沉重的数据加工工作中解放出来，更加专一在数据分析自身。
2、资源隔离
StarRocks 讲的是极速对立。当用户用 StarRocks 来服务越来越多的业务时，就会面临一个问题：采纳什么样的形式来反对不同的业务部署？是业务独立部署还是业务混合部署？
独立部署为每一个业务独立部署一个物理集群，这样的益处不言而喻，就是业务之间互相不影响。但这样部署也会有以下缺点：
- 多个集群之间会减少运维的压力，所有的运维操作都须要进行屡次，比方降级操作。
- 从公司的角度看，独立部署的形式整体的资源利用率会偏低，因为闲置的资源并没有方法被其余的业务所复用。
- 因为物理的隔离，数据共享会变得复杂，用户想要数据共享，往往只能将数据拷贝多份。
混合部署，将所有的业务放到一个共享的集群中。在一个大集群中，运维的老本会升高，资源的利用率会升高，数据共享也会变得简略。然而最让用户头疼的一个问题就是在同样的一个集群中，业务之间会相互影响。比方某个业务不小心发了一个查问，将整个集群的资源全副吃光，那么在这个集群上，其余的业务都会被影响。
所以有没有第三种抉择呢？尤其是在以后降本增效的大环境下，既能更高效地利用资源，又可能保障业务之间互不影响。
StarRocks 提供了这样的抉择：集群内的资源隔离。用户能够为每个业务指定不同的资源组，资源隔离的机制会保障每个业务的资源组不被其余业务所影响。接下来我就为大家简略介绍一下 StarRocks 的资源隔离运行机制以及以后达到的能力。
上图展现的是 StarRocks 资源隔离运行的机制。StarRocks 外部会给资源组划分固定的资源，包含 CPU 内存、IO 等等。有些资源是软隔离，比方 CPU、IO，有些资源是硬隔离，所谓的硬隔离超过了就要失败，比方内存。除了资源分配以外，StarRocks 也反对为每个资源组设定肯定的限度，对于超过限度的申请就会予以回绝。比方每个资源组都会有最大的申请并发数，当申请的并发超过限度时，新的申请就会被资源组回绝掉。
那么资源隔离是如何失效的呢？如上图所示，StarRocks 接管到一个用户申请后，会依据申请的属性将这个申请划分到对应的资源组里。而后 StarRocks 外部就会利用资源组所调配到的资源来执行这个申请，这样一个资源组的资源就可能失去保障，不会应用其余资源组的资源，也不会被其余资源组所抢占。通过这样的机制，StarRocks 就可能保障各个业务在同一个集群内，并且相互之间不影响。
上图展现的是 StarRocks 以后资源隔离的一个运行成果。测试分两个资源组：大资源组和小资源组，大资源组取得的资源是小资源组的两倍。
图左能够看出，两个资源组运行同样的申请的状况下，大资源组运行更快，并且从执行效率上看是合乎所取得资源比例的。图右展现的是当查问运行在大资源组时，开启资源隔离与敞开资源隔离时执行效率的比照图。能够看到，当开启资源隔离后，大资源组外面执行的效率与实践计算效率较相符。通过下面这两个 case 能够看出 StarRocks 以后资源隔离的成果，我也期待资源隔离可能给更多用户带来价值。
3、Query Cache
以后数据分析越来越民主化，企业里进行数据分析的人员越来越多，对系统的压力也越来越大。在这样的场景下，如何晋升查问执行的效率呢？过来对于每一个用户的申请，StarRocks 都是残缺执行一遍，这并不是最经济最极速的形式。
比方上面这个查问要计算过来 7 天每天的 UV 值，但其实只有最近一天的数据在变更，其余 6 天的数据并没有更新。实际上过来 6 天的数据查问后果是可能被复用的。如果可能复用之前的查问后果，那查问就会执行得更快。所以很天然想到，咱们能够针对这样的查问场景设计两头后果 cache 减速查问。
为了可能最大限度地利用查问两头后果，StarRocks 反对的是 tablet 级别的 cache，并不是最终后果的 cache；为了可能更快地减速查问，StarRocks 采纳的是 sub-plane result cache；另外 StarRocks 的 cache 还反对 join、聚合等各种简单算子。查问执行时，StarRocks 会尝试去取得对应 tablet 的两头后果。如果有两头后果能够复用，那么 StarRocks 会利用这部分两头后果。如果没有两头后果能够复用，那么 StarRocks 会针对这部分 tablet 应用原打算来执行计算两头后果，而后会将所有的两头后果用于下一阶段的计算，生成最初的查问计算结果。所以通过这样的 cache 机制，StarRocks 可能最大限度地利用两头后果减速查问。
上图展现的是以后 StarRocks Query Cache 的一个效果图。图左展现的是没有命中 cache 时的工夫惩办，从中能够看到，基本上能够忽略不计。图右展现的是命中 cache 后性能的减速比，能够看到如果命中 cache 查问，性能会有 2-15 倍的晋升，这就是 QueryCache 以后的一些停顿，期待前面可能给大家带来更惊艳的剖析体验。
4、建表不须要指定 bucket
应用过 StarRocks 的同学都会面临一个问题，表的 bucket 到底要设置成多少？为什么设置适合的 bucket 会如此重要呢？如果 bucket 数目少了，StarRocks 的查问并行度与 bucket 数目绑定，过少的 bucket 数目会影响整个的查问性能。
如果 bucket 数目设置过多，那么在数据导入的时候新增的文件会比拟小。比方我要导入 100MB 的数据，然而我有 200 个 bucket，那么每个 bucket 才 500KB，这样造成小文件过多，会减少数据管理的老本，也会影响后续的查问性能。所以 bucket 的数目不能过多，也不能过小。
所以用户就会问，那么我到底应该设置成多少呢？为了解决用户的这个困扰，让用户可能更简略地应用 StarRocks，咱们做了以下两方面的工作：首先是解耦 tablet 与执行并行度之间的关系。咱们通过反对 local shuffle 这样的能力，使得查问并行度与 tablet 数目之间无关。即便只有一个 tablet，下层依然能够并行执行查问。之前 StarRocks 一个 tablet 下层只能有一个并行路来执行，但新版本的 StarRocks 能够不受 tablet 数目的限度。尽管只有一个 tablet，下层依然能够并行的执行。
从咱们的测试后果中也能够看出，如上图所示，创立一个 tablet 与创立多个 tablet 性能能够统一。这样用户在创立表的时候就不须要为查问性能而思考应该设置多少个 buckets。除此之外，StarRocks 也反对了依照历史数据大小自适应的抉择 bucket 的数目。这样通过上述两项工作，用户在创立表时就不须要花过多的精力来思考到底应该将 buckets number 设置成多少了。
5、导入优化
在导入方面，StarRocks 过来一年也在继续提高。去年咱们正式公布了 Primary Key 模型，用于反对实时更新场景下的极速剖析。但过后的 Primary Key 只可能进行全量内存加载，当零碎内存不足时并不是非常敌对。为了解决这个问题，咱们反对了 persistent Primary Key。这样用户应用时并不需要将全副主键索引加载到内存中，依然能够失常应用，从而大大降低了零碎运行的内存压力。
从上图中也能够看到，在开启了 persistent PK 时，导入性能基本上没有什么影响，但零碎占用的内存比例降落了 80%。
除了在 Primary Key 模型的优化之外，咱们还做了很多导入优化。将导入全流程接入了咱们 Pipeline 引擎，提供了 2PC 导入事务语义，反对了 Replicate Storage，可能极大晋升多正本导入的速率，优化了 Apache Kafka 导入的调度策略。以后最大规模曾经反对了 1000 亿 / 天的导入速度，实现了全面向量化解析 JSON/Parquet，晋升两者的导入速度。
上表展现的是以后 StarRocks 的导入性能。能够看到在 342 核、3 台节点的集群规模下，咱们导入 3 正本的数据：CSV、Parquet 可能达到 1GB/s 甚至更高的导入性能，JSON 能够达到 400MB/s 的导入性能，即便对于 1 万列的数据也能够达到 500MB/s 的导入性能。
因为篇幅的限度，不能在这里为大家介绍咱们的所有优化。过来一年，咱们做的优化还包含：CTE 复用、Global Runtime Filter 等等的优化。对于极速对立这件事件，StarRocks 从未进行后退的步调，置信将来会给大家带来更加极速、更加对立的剖析体验。
#02
极速数据湖剖析
往年是 StarRocks 第一次向大家介绍数据湖剖析，我来介绍下现状。
1、StarRocks 数据湖剖析现状
上图展现的是 StarRocks 数据湖剖析的整体架构。能够看到，在 Storage 层，数据都存储在 Apache Hive/Apache lceberg/Apache Hudi 这样的数据湖中。在计算层，StarRocks 的无状态节点 Compute Node 会组成多个物理集群，执行用户具体的查问申请。以后 StarRocks 曾经能够对接 K8S。物理集群可能主动依据负载状况实现主动伸缩。在管制层，StarRocks FE 实现了数据湖元数据的对接，并接入用户所有的查问申请。在整个架构层面能够看到，以后 StarRocks 的数据湖剖析曾经具备了存算拆散、弹性伸缩的能力。
提到数据湖剖析，用户总是感觉数据湖剖析的性能会不如 OLAP 快。咱们把 StarRocks 数据湖剖析叫做极速数据湖剖析。那到底有多极速呢？咱们认为为用户提供跟仓一样性能的数据湖剖析，就是极速数据湖剖析。
上图展现的是在 SSB 多表状况下，数据存储在 StarRocks 内与数据存储在数据湖内查问性能的比照。从图中能够看到，数据湖剖析的性能曾经齐全能够媲美数据在仓里的剖析性能。所以用户通过 StarRocks 进行数据湖剖析，一方面可能享受存算拆散、弹性伸缩，一方面还可能享受到与仓查问一样的极速体验。那么 StarRocks 到底在极速数据湖中做了哪些工作呢？接下来我会为大家一一揭晓。
StarRocks 在数据湖的工作次要分为以下几个维度：第一，更容易的数据接入；第二，更快的剖析性能；第三，更好的弹性；第四，更灵便的数据分析形式。数据湖剖析数据都曾经存在了各个数据湖中，那么咱们须要一个繁难的形式，可能将数据湖中的数据接入到 StarRocks 中。StarRocks 当初提供了 Web Catalog 的能力，用户只须要通过一条 SQL 命令就可能将内部数据湖整个湖的数据挂接到 StarRocks 中来，而后用户就能够在 StarRocks 中剖析湖上所有的数据。
在新的 Catalog 框架下，StarRocks 曾经反对了多种数据源，其中包含 Apache Hive、Apache Iceberg、Apache Hudi 等数据源挂载。Apache Iceberg 反对了 V1、V2 两种 format；Apache Hudi 反对了 MOR、COW 两种数据格式。上图展现的是 StarRocks 相比于 Trino 在 TPC-H 规范测试集下别离在 Apache Iceberg 以及 Apache Hudi 的性能比照。从图中能够看到，StarRocks 相比于 Trino，基本上有 3-5 倍的性能劣势。
2、数据湖极速剖析的阻碍
- 数据湖 IO 提早比拟高。数据湖上的数据通常存储在对象存储或者 HDFS 中，其单次的 IO 申请提早个别会在 20-30ms 之间，相比于本地 SSD 不到 1ms 的查问提早要高出几十倍。另外不像本地零碎一样，数据湖的 IO 拜访个别通过 RPC 的形式，很难利用到 OS 的 page cache。
- 数据湖上的数据起源比拟多，短少对数据产生者的束缚。所以有时数据湖上的数据并不是对数据分析非常无利，比方在有些场景下会有大量的小文件存在。
- 数据湖会常常被各种数据分析引擎所拜访，但自身又短少隔离机制，所以会造成相互影响，导致数据湖剖析的性能不稳固。比方某些剖析会受到一些批处理查问的影响，导致性能急剧下降。
3、极速数据湖剖析工作
那么 StarRocks 为了让用户可能应用极速数据湖剖析，做了哪些工作呢？
针对湖上单次 IO 申请延时比拟高的状况，为了可能让剖析执行地更迅速，StarRocks 反对了 Coalesce IO 用于合并小的 IO 申请，通过缩小 IO 次数，减少每次 IO 的申请量，这样就可能晋升整个查问时延。
上图展现的是聚合 IO 的执行原理。在没有这个优化之前，对于每一个列的读取都是一次 IO 申请，在实在的场景中会存在很多列很小的状况。那么在这种状况下，聚合 IO 会将几个列的 IO 合并成一次 IO 申请，某些 Row Goup 会很小，那么 Coalesce IO 会也会将 IO 进行合并。一次 IO 申请蕴含了几个 Row Goup 的内容，从而升高 IO 的申请量。在文件比拟小的状况下，聚合 IO 可能将整个 file 通过一个 IO 申请全副读取，这样能够最大水平缩小 IO 申请。通过这个优化，在极其场景下能够指数级晋升查问性能，在用户的实在场景中会有 2-3 倍的性能晋升。
Coalesce IO 是依据文件的物理属性进行 IO 优化，那么提早物化是依据查问申请的特色来进行优化，其目标依然是缩小 IO 的申请次数。像上图中第三行，这样一条 SQL 指令会扫描表中所有的列，然而有一个抉择度超低的过滤条件，在失常的执行逻辑过程中会将所有的列先扫描进去，而后实现谓词过滤。这样基本上是一个全标扫描的操作，会有大量的 IO 申请。
那么提早物化是如何实现的呢？如上图所示，提早物化会先将谓词列扫描进去，而后进行谓词计算。StarRocks 会依照谓词计算的后果将其余列读取进去。如果数据曾经被谓词过滤，那么 StarRocks 就不会读取这一行的数据。这样在抉择度极低的 SQL 语句中，提早物化能够极大的升高 IO 申请量。在这个 case 中，IO 申请量降落了 5 倍，查问性能晋升了 8 倍。
数据分析的数据都是有局部性的。尽管湖上存储了大量的数据，但常常剖析的数据占少部分的。本地 SSD 相比于湖上的存储具备提早低、没有烦扰的特点。所以 StarRocks 实现了本地 Cache，利用本地存储来减速数据湖剖析。
StarRocks 实现的本地存储是 File Block 级别的 Cache，不是 File 级别的 Cache，这样可能使 Cache 利用率更加高效。并且为了保障 Cache 命中率高，在查问调度时引入一致性哈希算法，尽可能保证数据的局部性，保障对同一份数据的查问尽可能落到同一个节点来解决，这样 Cache 的命中率更高，Cache 的资源利用率也更充沛。通过 Local Cache 这个能力，如果本地 Cache 的容量足够，那么数据湖剖析的性能齐全能够和仓的性能所媲美。
数据湖上的剖析往往具备比拟强的随机性。如果应用固定资源来反对，通常没有方法最大化利用资源的。而数据湖剖析数据往往都在湖中，那么就人造具备了存算拆散的特点。基于此，StarRocks 的数据湖剖析也实现了计算资源的弹性伸缩，是通过以下几步来实现的：第一，咱们反对了齐全无状态的节点 computer node 这样就能够可能做到疾速在集群中增删节点。第二，将 StarRocks 与 K8S 集成，通过 K8S 实现资源管理与编排，就可能实现在资源缓和的时候减少节点，在资源富余的时候开释节点，从而可能实现计算资源的弹性伸缩。另外 StarRocks 以后也反对在一个集群内创立不同的 compute node 组。用户能够指定应用不同的物理资源来执行具体的查问申请，这样可能将不同类型、不同优先级的业务在物理层面进行隔离。
数据湖上存储了大量没有解决过的数据，存在大量半结构化的数据，比方会有似 Struct、Map 等类型。为了可能让用户剖析所有的数据，StarRocks 原生地反对了常见的半结构化数据类型，包含 JSON、Array、Struct、Map。用户能够应用 StarRocks 对这些类型的数据进行极速剖析，并且 StarRocks 实现了 Java UDF 框架反对用户自定义 UDF、UDAF、UDWF、UDTF。这样用户能够很容易进行能力扩大。StarRocks 也反对了 λ 表达式，使得用户剖析更加灵便。
#03
总结与瞻望
将来 StarRocks 还将致力为用户带来更极速、更对立的剖析体验，并且 StarRocks 会全面拥抱云，坚韧不拔地向云原生方向致力。期待在不久的未来，StarRocks 可能为用户带来云原生版本的极速、对立剖析体验。
对于 StarRocks
StarRocks 创建两年多来，始终专一打造世界顶级的新一代极速全场景 MPP 数据库，帮忙企业建设“极速对立”的数据分析新范式，助力企业全面数字化经营。
以后曾经帮忙腾讯、携程、顺丰、Airbnb、滴滴、京东、众安保险等超过 170 家大型用户构建了全新的数据分析能力，生产环境中稳固运行的 StarRocks 服务器数目达数千台。
2021 年 9 月，StarRocks 源代码凋谢，在 GitHub 上的星数已超过 3400 个。StarRocks 的寰球社区飞速成长，至今已有超百位贡献者，社群用户冲破 7000 人，吸引几十家国内外行业头部企业参加共建。