一、StarRocks 和 Paimon 湖能力的介绍
1. 为什么需要数据湖架构
为什么需要数据湖？与其它技术一样，数据湖本身也是由需求而生的。早期都是离线数仓，为了应对现在数据分析中越来越多的实时性场景，以及对 ACID、事物性隔离越来越高的要求，数据湖技术应运而生。传统的数据湖三剑客为 Iceberg、Hudi 和 Delta lake，从去年开始，开源的 Apache Paimon 这个正在蓬勃发展的数据湖格式，已成为一颗冉冉升起的新星。
数据湖架构的主要优点有三大方面：
- 首先是湖仓一体的管理能力。它具有完整的ACID 事务能力，Schema Evolution 以及扩展性强，且很适应大规模数据的处理，同时它也有具有完整的版本管理以及 Time Travel。
- 第二大优点就是开源开放统一存储，不像一些闭源的软件，格式都是其自己的，很容易 Lock in 到某些厂商去。在实际应用中，Apache Paimon 作为一个开源格式，与其它所有开源格式一样可以使用不同的底层存储，也可以适配不同的计算引擎，比如可以使用Flink 做流计算，Spark 做批计算，OLAP 做实时分析等等。
- 第三大优点就是成本和性能之间的平衡。如果在云上，可以构建在低廉的对象存储上，与流的结合还可以更好地提升时效性。另外，它还支持丰富的索引，从而提升查询性能。
这些优势正是我们选择数据湖架构的理由。
2. Paimon 概述
Paimon 是一个新兴的湖格式，它可以很好地结合 Flink 和 Spark 构建实时数据湖，用于流式和批处理操作。起初它只是 Flink 内置的 Table Store 的一个格式，之后经过漫长的发展，成为了一个独立完整的项目，今年从 ASF 孵化出来，成为一个正式的顶级项目。Paimon 可以完整地支持批处理和流处理，它创新性地将 LSM Tree 与湖格式相结合，具有更高效的实时更新能力。与其它湖格式相比，有着更优的读写性能，以及更高的 compaction 效率。
3. Paimon 优势
Paimon 的优势主要在以下四大方面：
- 第一是实时更新。它支持流式更新，最低 1 分钟的时效性，而且很灵活，可以支持部分列更新以及聚合更新，同时它也可以产生变更日志，给下游进行流读。
- 第二是流写流读。Paimon 就是从 Flink 的内置格式中诞生的，所以它与 Flink 的配合非常好，支持 Flink 流读流写。现在与 Spark 的结合很成熟，是 Spark 最佳的批计算组合。
- 第三是高性能查询。支持高性能 OLAP、提供点查以及丰富的索引。完备的索引支持是 Paimon 社区正在大力发展的特性之一，如 bitmap、布隆过滤器等。
- 第四是大规模离线处理能力。Paimon 支持传统的超大规模的数据量，并对 Append 表提供了完整支持。
4. StarRocks+Paimon 极速数据湖分析
StarRocks+Paimon 的最大优势是查询快，可以用来替代传统的 OLAP 分析方案。
例如使用 Paimon 为底座的数据湖，假设用 Presto、Trino 或者 Impala 去查的速度作为基准，不做任何其它更改，仅是将查询引擎换成 StarRocks，就可以带来三倍的性能提升。这主要是由于 StarRocks 有着非常优秀的 CBO 优化器，以及完整的向量化执行引擎，并且在读取数据湖进行 IO 操作的时候，做了非常细粒度的管理，比如 IO 合并以及延迟物化技术等。
如果想要更大的性能提升，只需要开启 StarRocks 的本地缓存功能 Data Cache，BE 端配置一下本地缓存的磁盘路径，就可以使用了。在启动缓存之后，可以得到 6 倍的性能提升。
利用 StarRocks 外表的物化视图功能，还可以得到更快的查询速度。使用该功能，StarRocks 会把湖上的数据转换成自己的格式存起来，当成是自己的内表进行存储、索引构建，这样就可以得到 10 倍的性能提升。
同时，Paimon 物化视图可以支持多种查询特性，比如透明加速，即查询表的时候，用户可以不感知物化视图的存在，而是将其当成 StarRocks 的一个外表就可以了，SQL 里是 StarRocks 的外表，但 StarRocks 会将查询自动路由到物化视图，用物化视图去加速查询并返回数据。
Paimon 物化视图还支持查询改写，物化视图的构建很多时候是与查询 pattern 紧密相关的。例如，查询 pattern 是三个表的 join，对这三个表做了物化视图之后，又想查其中两个表的 join 结构，StarRocks 的查询改写可以不需要再重复建两个表的物化视图，支持自动把这两个表的 join 改写到原来基于三个表的物化视图上，达到查询加速度的目的。
物化视图也支持嵌套分层，在一个物化视图在上面再加一层物化视图，也就是可以起到数据建模的作用。
Paimon 还具备冷热分离的功能。业务的数据量是一直上涨的，很多离线加工任务积攒了多年的数据，但实际 OLAP 查询最多也就查近几年、近几个月或者近几天的数据。StarRocks 冷热分离功能，配置物化视图只存近几天的数据，剩下的数据都在廉价对象存储上。用户只要写一个 SQL，不需要关心数据从哪来，StarRocks 会自动去解析这个 SQL、做一些合理的 plan，自动判断哪些数据可以直接从物化视图读，哪些数据到湖格式上读，然后把这两个部分的结果 union 出来，最后返回到最终结果里。冷热分离的效果，相当于热数据查询永远都很快，因为直接命中物化视图，但冷数据依然可以保存在廉价存储的外表里，达到降本增效的目的。
以上，就是 StarRocks+Paimon 的极速数据库分析方案，以及在构造一个湖分析方案时如何获得更高的性能。
二、迁移 StarRocks 方案介绍
1. Trino/Presto 迁移
上文提到，Trino 直接换成 StarRocks 就有 3 倍的性能提升，但对于业务来说直接迁移引擎不可避免地会带来业务的改造和改 SQL 的情况，如果 SQL 很大很长，改起来会比较麻烦。接下来将分享如何减少业务迁移的痛点。
如果业务是从 Presto 或者 Trino 迁移到 StarRocks，这是最简单的，不需要任何改动，因为 StarRocks 已经内置了 Trino 的语法解析器。只要在 StarRocks 里设置 set sql_dialect=“Trino”，原来 Trino 的 SQL 直接放进 StarRocks 就可以自动完成解析，将 Trino 语法的 SQL 转换成 StarRocks 自己的逻辑计划以及物理执行计划，最后执行返回。我们在多家客户的实际案例中测试，对 Trino 和 Presto 的兼容度基本在 90% 以上。剩下的就是一些 Corner Case，比如一些很少用到的地理计算函数或数学计算函数等，才会出现不兼容的情况。
2. Hive/Spark-SQL/Impala/Doris/Clickhouse 迁移
除了最常用的 Trino、Presto，大家还会用到一些其它的计算引擎，比如传统的 Impala、Doris、ClickHouse、Hive、Spark SQL 等，如果想往 StarRocks 迁移，可以参考一个开源项目——SQLGlot，它相当于一个 SQL 转换器，支持各种 SQL 的转换，使用特别简单，本质上是一个 python 程序，下载下来就可以直接用。
如上图中所示，转换方法就是填写三个参数，第一个参数是要转换的 SQL，第二个参数是 read 参数，告诉它这个 SQL 是什么引擎的 SQL 语法，比如例子中的是“duckdb”，第三个参数是 write 参数，告诉它要转换成什么引擎的 SQL 语法，例子中的是“hive”。最后运行一下，就可以完成 SQL 转换。
这个项目除了 SQL 转换，还有 SQL 优化、SQL 格式化、SQL 语法检查等功能。当我们的客户想把其它引擎迁移到 StarRocks 的时候，尤其是 Impala，我们经常会推荐这个项目。
3. StarRocks 集群间迁移
下面介绍 StarRocks 集群间的迁移。假如现在已经有了一个 StarRocks 集群，但是版本非常老，想要升级到最新版本。最好的方案就是开一个新集群，然后把数据复制过来，等数据复制完成之后，业务直接切换过去即可。如果新的集群有问题，还可以直接一键回滚。如果直接原地升级，当遇到遇到问题的时候，还得做降级，业务也得跟着中断，这样来回做一些反复的操作，对业务是有显著影响的。
这里介绍一个 StarRocks 集群间迁移的具体方法，除了做迁移，很多客户也用这个工具做热备和灾备。如上图中所示，左右两个框代表两个集群，这个工具可以把原集群所有的数据自动同步到新的目标集群，实际上就是 copy 数据，延迟大概在分钟级，可以做到准实时。在数据同步中，原集群不用做任何修改，导数、删表、加分区、删分区等 DDL 操作、导入操作带来的数据变更都会无缝地通过这个工具迁移到新集群去。这样等新集群准备好后，业务就可以直接切换了，或者干脆将其作为一个灾备系统也是可以的。
使用这个工具非常简单，下载好后，配置一些必要的参数，如配置两边集群的 IP、用户名密码等，即可开始使用。
4. 使用阿里云 EMR StarRocks 构建基于 Paimon 极速实时湖仓分析架构
大家在使用 StarRocks 的时候，经常会遇到一些运维问题，接下来介绍阿里云 StarRocks 基于 Paimon 的极速实时分析架构。阿里云的 EMR Serverless StarRocks 分为三个版本，一个是存算一体，另外一个是存算分离，第三个是今天重点讲的数据湖分析。
- 存算一体就相当于 StarRocks 内表的一个版本，用 StarRocks 自己的格式去存数据，用于高并发和实时数据分析查询。
- 存算分离版本，数据是存到 OSS 等对象存储上，BE/CN 可以支持动态伸缩，并支持多 Warehouse。存算分离集群支持资源硬隔离、读写分离、Cache 管理能力。
- 数据湖分析版本，兼容 Trino/Presto 语法，适用于数据湖、数据仓库分析的场景，如果有外部数据存储在 HDFS 或者 OSS 上，开通之后就可以做即席查询，无需任何配置。
上面是用 StarRocks 做数据湖分析的一个截图。主要包括两步：第一步，以 Paimon为例建一个 Catalog，CREATE EXTERNAL CATALOG paimon_fs_catalog，添加一个参数用来指定 paimon 数据所在对象存储的位置，最后就可以直接查询 Paimon 数据湖里的数据了。
关于前面介绍的数据加速的物化视图部分，可以参考上图中第二个红框中的代码，即 CREATE MATERIALIZED VIEW 语法创建物化视图，指定好物化视图的刷新频率，比如例子中的刷新频率是 1 分钟，保存好之后，就可以直接查询这个物化视图了。
阿里云的 EMR Serverless StarRocks 包含了各种各样运维和管控能力，例如查询分析，Profile 可视化，导入分析，用户权限分析，数据血缘分析等。
三、StarRocks + Paimon 未来规划
- 第一部分是支持 Paimon 元数据缓存，这是目前最高优、最重要的任务之一。为何特别重要，是因为 StarRocks 物化视图刷新是支持按分区刷新的，按分区刷新需要感知外表哪些分区有更新，只刷新有更新的分区。感知分区刷新就是获取元数据的过程，外表一般数据量都很大，获取元数据的成本也比较高，而且把元数据都缓存下来，也可以给后续查询直接复用，提高整体查询效率。
- 第二部分是完善 Paimon 统计信息和索引支持。目前重点在索引支持，主要包含两个方面：一个是布隆过滤器，另一个是 bitmap 索引。StarRocks 也需要能够处理这些索引格式，在 reader 中高效地利用这些索引数据。
- 第三部分是支持 Paimon 表格式的写入，希望直接用 StarRocks 去写 Paimon 的表格式。
- 第四部分是大规模数据表的读取性能优化，这个主要是内存优化。内存优化主要是拉取元数据或者读数据的时候可以尽量减少内存的消耗。
以上就是本次分享的主要内容。
