1.为什么需要数据湖架构

为什么需要数据湖？与其它技术一样，数据湖本身也是由需求而生的。早期都是离线数仓，为了应对现在数据分析中越来越多的实时性场景，以及对 ACID、事物性隔离越来越高的要求，数据湖技术应运而生。传统的数据湖三剑客为 Iceberg、Hudi 和 Delta lake，从去年开始，开源的 Apache Paimon 这个正在蓬勃发展的数据湖格式，已成为一颗冉冉升起的新星。

数据湖架构的主要优点有三大方面：

这些优势正是我们选择数据湖架构的理由。

Paimon 是一个新兴的湖格式，它可以很好地结合 Flink 和 Spark 构建实时数据湖，用于流式和批处理操作。起初它只是 Flink 内置的 Table Store 的一个格式，之后经过漫长的发展，成为了一个独立完整的项目，今年从 ASF 孵化出来，成为一个正式的顶级项目。Paimon 可以完整地支持批处理和流处理，它创新性地将 LSM Tree 与湖格式相结合，具有更高效的实时更新能力。与其它湖格式相比，有着更优的读写性能，以及更高的 compaction 效率。

Paimon 的优势主要在以下四大方面：

StarRocks+Paimon 的最大优势是查询快，可以用来替代传统的 OLAP 分析方案。

例如使用 Paimon 为底座的数据湖，假设用 Presto、Trino 或者 Impala 去查的速度作为基准，不做任何其它更改，仅是将查询引擎换成 StarRocks，就可以带来三倍的性能提升。这主要是由于 StarRocks 有着非常优秀的 CBO 优化器，以及完整的向量化执行引擎，并且在读取数据湖进行 IO 操作的时候，做了非常细粒度的管理，比如 IO 合并以及延迟物化技术等。

如果想要更大的性能提升，只需要开启 StarRocks 的本地缓存功能> 利用 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 的极速数据库分析方案，以及在构造一个湖分析方案时如何获得更高的性能。

上文提到，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，比如一些很少用到的地理计算函数或数学计算函数等，才会出现不兼容的情况。

除了最常用的 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，我们经常会推荐这个项目。

下面介绍 StarRocks 集群间的迁移。假如现在已经有了一个 StarRocks 集群，但是版本非常老，想要升级到最新版本。最好的方案就是开一个新集群，然后把数据复制过来，等数据复制完成之后，业务直接切换过去即可。如果新的集群有问题，还可以直接一键回滚。如果直接原地升级，当遇到遇到问题的时候，还得做降级，业务也得跟着中断，这样来回做一些反复的操作，对业务是有显著影响的。

这里介绍一个 StarRocks 集群间迁移的具体方法，除了做迁移，很多客户也用这个工具做热备和灾备。如上图中所示，左右两个框代表两个集群，这个工具可以把原集群所有的数据自动同步到新的目标集群，实际上就是 copy 数据，延迟大概在分钟级，可以做到准实时。在数据同步中，原集群不用做任何修改，导数、删表、加分区、删分区等 DDL 操作、导入操作带来的数据变更都会无缝地通过这个工具迁移到新集群去。这样等新集群准备好后，业务就可以直接切换了，或者干脆将其作为一个灾备系统也是可以的。

使用这个工具非常简单，下载好后，配置一些必要的参数，如配置两边集群的 IP、用户名密码等，即可开始使用。

4.使用阿里云 EMR StarRocks 构建基于 Paimon 极速实时湖仓分析架构

大家在使用 StarRocks 的时候，经常会遇到一些运维问题，接下来介绍阿里云 StarRocks 基于 Paimon 的极速实时分析架构。阿里云的 EMR Serverless StarRocks 分为三个版本，一个是存算一体，另外一个是存算分离，第三个是今天重点讲的数据湖分析。

上面是用 StarRocks 做数据湖分析的一个截图。主要包括两步：第一步，以 Paimon为例建一个 Catalog，CREATE EXTERNAL CATALOG paimon_fs_catalog，添加一个参数用来指定 paimon 数据所在对象存储的位置，最后就可以直接查询 Paimon 数据湖里的数据了。

关于前面介绍的数据加速的物化视图部分，可以参考上图中第二个红框中的代码，即 CREATE MATERIALIZED VIEW 语法创建物化视图，指定好物化视图的刷新频率，比如例子中的刷新频率是 1 分钟，保存好之后，就可以直接查询这个物化视图了。

阿里云的 EMR Serverless StarRocks 包含了各种各样运维和管控能力，例如查询分析，Profile 可视化，导入分析，用户权限分析，数据血缘分析等。

以上就是本次分享的主要内容。