讲师：焦明烨 阿里云计算平台事业部OLAP引擎开发工程师
主要内容：
- StarRocks数据湖能力介绍
- 使用阿里云EMR StarRocks构建基于Paimon的极速实时湖仓
- StarRocks + Paimon的最新进展
- StarRocks + Paimon未来规划
我的分享将分为以下四个部分。首先，会介绍一下StarRocks的数据湖能力，也就是回答为什么要用StarRocks来进行数据湖分析这个问题；接下来，简单讲一下阿里云上的EMR Serverless Serverless StarRocks是什么样的、该怎么用它来构建Paimon湖仓；然后介绍近期在StarRocks访问Paimon这个方向，我们实现了哪些新功能、做了哪些优化，分别起到什么样的作用，会在哪些方面为使用者赋能；最后，我会将我们正在进行中的工作提前透个底，告诉大家哪些新特性将会在未来上线。
一、StarRocks数据湖能力介绍
StarRocks从3.x版本开始，一直在着力打造数据湖分析的新范式，期望能利用好自己在warehouse上的优势，积极拥抱各种湖格式，在湖上为使用者提供不输给数仓的使用体验。StarRocks社区有一个非常专业的DLA Team，专门负责开发和优化StarRocks的数据湖场景，因此打造了一款非常优秀的数据湖分析引擎。StarRocks数据湖分析的特点，我总结了两个关键词，也就是极速统一和简单易用。
- 极速统一
StarRocks作为一个向量化引擎，具备全面的向量化执行能力；此外StarRocks拥有现代化的CBO，全面兼容多种湖格式，无论是Hive Paimon还是Iceberg Hudi Delta Lake等等，都可以使用StarRocks进行查询；不仅如此，StarRocks还实现了IO合并，优化对象存储的读取，综合下来相对Trino能给带来3倍以上的性能提升。
- 简单易用
StarRocks建立与数据湖的连接非常方便快捷，是能够做到开箱即用的；与此同时，StarRocks能够兼容Trino的语法、关键字、函数转义等，迁移便利快速，具有九成以上的兼容度。最后，StarRocks能够通过Audit Log、Profile等多种方式对执行的查询进行分析和处理，方便业务侧进行治理和优化。下面我会详细介绍这两个方面。
StarRocks优势：极速统一
前面已经说过，StarRocks具有自己在warehouse上的诸多优势，因此希望也能将类似的体验带给湖上用户。先来看左边这幅图，StarRocks内部有统一的Catalog机制，不论是StarRocks的内表，多种格式的湖上外表，还是JDBC外表，在逻辑上都是这样一个Catalog的概念。也就是说，StarRocks单一引擎就能够同时访问包括但不限于内表、Paimon为代表的湖上外表、MySQL为代表的JBBC外表等多种数据源，并且能够支持跨数据源的Join。只要用户需要，任意一个数据源的数据都可以写入StarRocks内表，实现统一的数据加工和处理，非常方便。此外内外表的数据访问还能够通过StarRocks的RBAC机制进行统一的权限管理。当然，如果还想使用湖上常用的权限管理方案比如Ranger，StarRocks也是支持的。上面就体现了StarRocks“统一”的地方所在。那么极速体现在哪里呢？我们来看右边这张图。右图的上半部分是StarRocks的架构，可以看到FE的查询优化器、BE的查询执行器与IO引擎等等等等，唯独少了什么？少了存储对吧。在这个场景下，湖就是StarRocks的存储。也就是说，我们可以理解为，StarRocks做到了把数据留在HDFS或者对象存储上，在读取的时候从这些文件系统中获取需要的数据，后续的查询与分析过程都和内表别无二致。作为一款实现的很优秀的查向量化引擎，根据我们的实测，即使只替换查询引擎将Trino换成StarRocks，其他什么都不做，速度就能提高3倍。不仅如此，StarRocks还提供了多种多样的特性，来对查询进行加速，比如内存和磁盘的两级Data Cache缓存，物化视图等。也就是说，对于需要经常执行的湖上热数据的查询，StarRocks能够做到更快。
StarRocks优势：简单易用
我直接举例子说明吧。先来看上面的两幅图。如果有熟悉Trino的观众应该知道Trino想要新建一个连接器是怎么做的，我们是不是需要按照一定规范写一个properties文件，把这个文件分发到包括cooridinator和全部worker在内的所有节点，然后重启整个集群？不仅如此，一旦有一个配置配错了，Trino直接拒绝服务了，启动都起不来。也就是说，Trino的Catalog管理和配置校验是server启动的时候做的,对系统维护者来说是一个考验。虽然Trino最近也做了Dynamic Catalog，但这个功能默认是关的，还是static的，Trino的人说他有安全问题。并且，Trino的Catalog是插件形式的，即使用了Dynamic Catalog，只要之前用这个Catalog执行过查询，就还是会出现资源释放不掉的情况，这个体验显然是非常不好的。StarRocks这边就不一样，我们的外表Catalog默认就是动态创建和配置的，可以做到开箱即用，只要我们保证网络是畅通的，就可以在客户端通过写SQL的方式直接创建一个外表Catalog，我们看到上面我创建了一个type是Paimon的Catalog，这个Catalog和Paimon自己的那个Catalog是一一对应的，我设置了type是DLF，然后配置了DLF的ID，上面全部的操作和show出来这个catalog里面的全部数据库，加起来总共花了还不到一秒，是非常简单易用的。StarRocks也支持对查询进行分析，这里就以最常用的profile为例，看这幅小图，我故意构造了一个执行可能会比较慢的情境，我们可以看到一个简单的select count(1)花了4秒，数据量也只有一万条，这显然是不合理的。但是只要我们拿到这个查询的ID，并且开启了profile功能，我们就可以获取这个查询对应的profile。拿到query id的方式有很多，包括从系统表里查找、翻找Audit LOG等等，这里只是其中一个方式，就是调用函数查询。右边的图就是这个profile的文本，当然profile很长啊，通常会有成百上千行，这里只截取了一个开头，但从开头已经可以看到Analyze这个步骤花了2.6秒，占总时间的一半还多了，时间都花在这了，我们就可以看看为什么Analyze要用这么久，从而优化我们的查询业务。
数据湖分析常见场景
聊完了StarRocks数据湖分析的特点，我们再来说说几个常见的场景，我就挑了这四个，分别是数据湖分析加速、湖仓分层建模、冷热融合以及全链路ELT。我会以Paimon为例，说说这些场景分别是干什么用的、怎么用。
场景一：数据湖分析加速
第一个场景是最基础的数据湖分析加速场景。我们对比的基准都是Trino。Trino也是一个非常优秀的MPP查询引擎，非常稳定而高效。刚刚也提到过StarRocks是能够兼容Trino的语法函数和关键字的，也就是我们把Trino的语法解析器包了起来，Trino的SQL传进来以后被我们转成了StarRocks能看懂的的AST，后面的流程，包括生成执行计划和查询这些就和StarRocks原生语法都一样了。开启的方式也很简单，就是设置一个session变量sql_dialect =“Trino”只要开启了这个，StarRocks一秒变身成Trino。具体的使用案例可以看阿里云EMR Serverless StarRocks的文档，里面有实际的演示，包括开启前怎么提示函数解析错误查询失败，开启后怎么得到结果等等。根据我们多家用户的生产环境实际测试，可以保证兼容度高达90%以上，大多数常见的场景是都能兼容的。可能Trino有一些特殊的函数，比如正则什么的，StarRocks这边没有，这些也还在适配，可能有一些已经适配完成了。
可以看到，以Trino等引擎为基准，StarRocks什么都不做，直接平替就能带来3倍的性能提升，如果更进一步开启Data Cache，在缓存盘足够大、缓存能够大量命中的前提下，提升更是来到了6倍。新版本的Data Cache也是先进了很多，增加了主动的缓存预热功能，并且增加了多项可观测性的指标，这个功能之前是关的，现在也是默认打开了。如果觉得还是不够快，还想要再进一步的提升，就需要后面的一些场景用到的手段了，我这里列举了一些，后面都会一一涉及到。
场景二：湖仓分层建模
第二个场景是湖仓分层建模。我们先来思考一个问题，直接查湖和内表相比，慢在哪里呢？我们前面说过，查内表和查湖逻辑上只有存储是不一样的，那么答案也就显而易见，IO会是天然的第一道瓶颈。因为我们需要把数据从远端，通常是对象存储，拉取到查询引擎本地。在读数据的时候，经常会遇到网络带宽打满的情况，即使带宽没打满，也会有各种各样的IO问题。有人说，我把数据从湖导入到内表不就可以了，但是其一，本地存储是很昂贵的，远远比对象存储要贵，因此warehouse中往往不能存放全量的数据；其二，导入毕竟是要花时间花资源的，也需要专人来维护，等到导入完成了，查到的是什么时候的数据就不好说了，这就局限了使用的情境。于是，StarRocks就打造了这样一个场景，即湖仓分层建模。可以从图上看到，StarRocks可以用物化视图的形式，对对象存储中存放的湖上数据进行分层。物化视图就相当于内表，查物化视图会比直接查湖快很多。并且，物化视图是可以嵌套的，在物化视图之上又能构建一个物化视图，每层物化视图都是一次聚合，每一层应对不同的场景，越往上的数据越精炼，所有数据都可以访问到。物化视图可以做到在分区粒度刷新，比如我们以天为粒度刷新，刷新的成本也是比较可控的。这样一来，每层之间的依赖关系的维护，数据的异步刷新，以上这些所有工作，都只需要StarRocks一个引擎就可以完成了。这样，业务侧就可以查到实时与近实时的数据，并且速度也是非常快的。
场景三：冷热融合
下一个场景叫做冷热融合，这个场景也是依赖物化视图的。我们实际业务中，数据可能是会有冷热之分的，冷数据就是那些可能很久才会查一次的数据，热数据就是近期经常要查询的数据，如果数据全都在湖上，那冷热数据可能就没什么区别了，查的速度都差不多。这个时候，我们在创建物化视图的时候就可以指定热数据的周期，比如我这里设置了是三天，这样物化视图里就只会保留最近3天的数据。然后，StarRocks还支持物化视图改写的功能，也就是说业务侧不用改SQL，SQL写的查询的还是原表，但是StarRocks会自动判断这个SQL命中了物化视图中的数据。当业务频繁访问这三天的数据的时候，实际上访问的都是物化视图，这样速度就会很快。如果查询融合了冷热数据，StarRocks支持自动将冷热分区合并，可以看右下的这个图，热数据会从MV中获取，冷数据还是从湖上获取，然后StarRocks内部会先做一个Union，然后再执行后续的处理。这也能加快查询速度，但可能加快的没有那么多。
场景四：全链路ETL
今天我想介绍的最后一个场景是全链路ELT。StarRocks不仅是一个查询引擎，他也是能够写的。换句话说，StarRocks具有一定的轻量ETL能力。首先StarRocks近期对Spill，也就是当内存不足时将查询的中间结果向磁盘溢写这个能力进行了大幅度的优化，这可以说是ETL必备的能力了。然后StarRocks可以通过VVP也就是Flink进行CTAS或CDAS，导入各种数据，打造适合大批量数据的全链路的实时数仓，不止如此，StarRocks也是可以写湖的，社区对Iceberg和Hive支持的比较好，也可以直接将ORC或者Parquet文件写到文件系统中。我们呢，近期也支持了写Paimon。这样一来，StarRocks拥有非常完善的Connector Sink，可以读内表或者湖上的数据，再写回湖，实现降冷操作，写的速度也很快，写HDFS的速度端到端能够达到Trino的3倍，对象存储由于IO的影响很大快不了这么多但也是快的。这样一来，就可以由StarRocks这一个引擎，完成一个全链路的轻量ELT。
二、使用阿里云EMR StarRocks构建基于Paimon的极速实时湖仓
阿里云EMR Serverless StarRocks的特点我这里列举了很多条，大家可以自己看一下。其中有些是社区版就有的能力，有些是我们自己的增强。我们做的优化一方面是易用性上的，可以看最右边这一列，阿里云的EMR Serverless StarRocks是完全云原生的，可以做到免运维的即开即用，弹性能力也很好；另一方面是生态上的，针对我们云上的产品做了各种各样的集成，非常便利。对内核我们根据情况也做了一些改进，这里我就不一一列举了，感兴趣的大家欢迎来体验。
可以看到，我们的产品是分为三个版本的。存算一体就是比较传统的，大家最常遇到的那个版本，数据都存放在云盘或本地盘上，好处是读写性能非常高，适合追求高效率和高并发的大数据分析的用户；存算分离是指存储在OSS上，能够节约大量存储成本，并且存算分离集群的缓存做的也是很不错的，对于经常访问的热数据，能够做到查询性能对齐存算一体；前不久我们产品的存算分离版本也是摘掉了beta版的标识，意味着基本稳定，可以放心使用了。数据湖分析版本则是纯数据湖查询的版本，和今天我们讲的场景关系比较密切；如果大家想找一个Trino集群的平替，就想把一个Trino集群平迁过来，选择数据湖分析版本是不会有错的，当然，这并不是说其他版本就不能查外表了，也能查，但毕竟专业的人做专业的事，如果用户只有湖分析的需求，选这个版本是更好的。
接下来我会用几张图来展示一下EMR Serverless StarRocks产品层面的一些功能与亮点。可以看到，这是一个即开即用的SQL Editor，伴随着新建集群会自动创建好。我们想要执行任何SQL，比如我这里的Create external catalog，只需要写在这里然后用鼠标选中，就可以运行了。这个SQL也是可以持久保留的，不会丢。这里建好后，左边数据库管理这里就能过看到我们创建的Catalog，可以看到这个Catalog下有哪些数据库哪些数据表，甚至可以展开看到每张表的结构是什么样的。我们如果想创建物化视图也是一样的，可以看到这个CREATE MATERIALILZED VIEW语句，我们设置刷新间隔INTERNAL为1小时，这个物化视图就会异步的以一小时一次的频率去刷新当然也可以手动刷新，相关的命令有很多，大家可以参考文档。
前面还提到了StarRocks的Profile，这是一个非常常用且好用的工具，但是我们也看到了，打印出来的profile是一大长串文本，虽然兼容并包，但里面各种各样的指标实在太多太长了，非常不清晰，可能光是找哪个地方慢都要找半天还不一定能找到。于是我们就产品化了一个分析诊断工具，就是图上的这个，我们Manager里是能看到所有查询的，然后我们会把所有慢查询单拎出来，默认是执行了5秒以上的就是慢查询，当然也可以自己调。对于执行缓慢的查询，在开启profile后，我们会提供一个可视化的profile查看页面，就像这幅图的右半部分，执行越慢的算子就越红。我这里是查了一个Paimon外表，然后做了一个两表join，可以看到这个查询中执行最慢的就是Connector Scan也就是扫描表的时候慢，我们如果想要优化就可以考虑加缓存等等。总之这里就可以非常直观的看到查询的瓶颈在什么地方，方便我们进行针对性的优化。
最后再简单看一下监控。监控不止能看到集群的概况，也就是CPU内存磁盘使用率这些，也能看到集群使用的相关信息，我图里展示的只是很小的一部分，这是一个我自己的测试集群啊所以可能使用率不是很高，这里对查询数、查询延迟等大家关注的很多指标都进行了统计，并且这个界面是十分简洁的，一眼就能看清楚。
三、StarRocks + Paimon的最新进展
接下来是第三部分，我会介绍一下StarRocks集成Paimon这块，最近上新了什么东西，也就是一个简短的Release Note，告诉大家我们支持了这些新特性。
首先一个比较重要的是，我们支持了读Paimon的Deletion Vector，目前还只支持了主键表，这类表相比传统的MOR主键表，读性能会好非常多。其次，我们支持了物化视图改写，前面提到的很多场景都是建立在物化视图改写之上的，没有这个功能，我们之前聊的场景二和场景三都没办法实现，所以改写也是非常重要。第三，我们把Paimon也接入了StarRocks的unified catalog，关于这个是什么我后面会说。最后，我们之前也提到过，StarRocks现在也能写Paimon了，虽然这个功能现在还没发布，但是我可以告诉大家，现在已经具备这个能力了。
说Deletion Vector很多人可能一脸懵，不知道这是个什么，接下来简单讲讲。Append表的Deletion Vector Paimon那边也在做，但是现在，Deletion Vector还是一种特殊的主键表。传统的主键表都是MOR的，也就是在读的时候，会根据元数据对Upsert了的文件进行Merge也就是合并，每次读都要Merge。而Deletion Vector则是用Bitmap来标记，我数据文件中的哪些列是被Upsert掉了需要删除的，也就不需要合并，只要跳过就可以了。右边是我随便找了一个Deletion Vector表的文件结构。如果大家对PK表的目录结构比较熟悉应该一眼就能看出来，和传统的PK表相比多了什么？多了一个index路径，以及manifest路径下面多了一个index manifest。左边这幅图是摘自Paimon的官方网站，index就是哪个bitmap，用来标记哪些行是需要被删掉的，index meta则是index的元数据，用来表示index里的这段bitmap对应的是哪个数据文件等等。这和Iceberg的Position Delete在思想上是差不多的，只是实现方式不太一样。很多人的业务实际使用中，由于查全量PK表太慢，都是查ro表也就是做了Full Compaction的那一部分，这样当然会比较快，但是也就丧失了实时性。改用Deletion Vector后会怎么样呢？我们来看实测。
下面的图这是我们的实际测试结果。构造了一个表，共有5亿行数据，其中主键的范围是0到10亿，但由于主键是随机的肯定会出现碰撞，这样构造的表的独立主键数，也就是如果我们进行FullCompaction剩下的条数大概3.9亿多不到4亿。然后为了能看出来差异我故意搞了个最小的集群，一台FE一台BE，并且每个节点都只有8CU，这已经不能再小了，用这个集群，可以看右边，相比传统的MOR表，Deletion Vector执行这种简单的聚合查询会有6～8倍不等的性能提升，这可以说是非常可观的。Deletion Vector的缺点是写速度会比MOR慢一些，因为毕竟写的时候要写Index，做的事情更多了，只要能接受这个缺点，大家使用PaimonPK表的时候，我们都会推荐开启Deletion Vector。
然后是物化视图改写，我们前面说了那么半天其实大家可能已经知道改写是什么了。我这里再描述一下。直接看左边吧，这是一个TPCH的例子，我创建了一个t1 t2 join的物化视图，之后我执行了一个t1 t2 t3三个表join的查询，查的是原表。这种情况下，StarRocks发现，这个查询中有一个join命中了物化视图，然后这一部分的查询就会自动被改写到物化视图上，这个过程用户是不感知的，也就是所谓透明加速。目前来说，支持的改写类型有我右边列出来的这些。分别是完全匹配，部分匹配也就是表命中了但是join没命中，以及query delta也就是左边的这种情况。
物化视图包含3表join，查一个两表join这个场景也就是View delta Join目前还命中不了，我们也在努力支持中。
然后是Unified Catalog。有人可能会觉得，我所有湖格式的外表都在一个统一的Metastore里，我要给每种湖格式都建一个catalog，我觉得这还是太麻烦了，怎么办？StarRocks提供了Unified Catalog这个功能，专门就针对这种情况，这是一个特殊的外表catalog，里面什么表都有，只要元数据一样，就都能查。Paimon也是支持了unified catalog，目前支持的元数据类型是hms和dlf，filesystem算是Paimon特有的，目前确实还不太能支持。
最后来说说Paimon Sink，所谓Sink就是写入，业务中常常用来降冷。目前，我们把Paimon也接入了StarRocks的Connector Sink框架，可以说基本的写入功能已经具备了。但是当前版本的限制还比较多，因为我们是用JNI实现了一个Writer，导致不但速度比较慢，内存消耗还很大。所以当前版本的Paimon Sink我们还没有对外正式发布。我们下一步会对接StarRocks的Native Writer，争取将一个完备的Paimon Sink，在测试充分之后带给用户们。
四、StarRocks + Paimon未来规划
最后一部分，请允许我小小的剧透一下未来的规划，其中每一项都是现在进行时，我们来看看都有什么。
首先是元数据缓存。Paimon的物化视图改写现在有个痛点，就是每次改写的时候都会去重新确认一下分区的最后更新时间来判断分区是否过期，这个过程是要访问远端文件系统的，这就导致了当数据量很小的时候，可能开了改写比不开还要慢。我们会实现一个Catalog级别的缓存，这个据我所知应该是在Paimon里实现了的，这能够减少远端文件读取，有效提高响应速度。第二是一个分布式Plan，这适用于Big Meta Data场景，因为StarRocks在查询的时候FE是单点的，我们知道Paimon的元数据都是文件系统中的实体文件，虽然文件不大但是需要FE这边来进行反序列化和解析，这种多生产者单消费者的场景很容易导致FE成为瓶颈乃至Full GC。所以我们就在想能不能用BE来做这件事。这在Iceberg那边已经实现了，Paimon也正在进行中。第三点是Paimon最近支持了索引，有Bloom Filter和Bitmap两种，这两个我们也都会支持。第四，StarRocks+Paimon是我们DLF 2.0云上统一湖仓的主力，这个场景未来会用的越来越多，希望能够尽快给大家带来喜讯。最后，上面这些工作在Paimon和StarRocks两边都会有涉及，欢迎有意愿的开发者来共创。
最后大家如果对刚才介绍的阿里云EMR StarRocks感兴趣的话，可以登录我们的官网开通，我们有免费试用以及一些资源包供大家开通体验，使用中有什么问题也可以加群和我们交流。
