01
为什么需要湖仓融合
本章节将从三个方面循序渐进介绍湖仓融合的意义和价值，以及 StarRocks 在湖仓中发挥的作用。
1.数据湖的基本定义及价值
（1）什么是数据湖
数据湖的概念和技术实现在不同的行业也有着较大的区别：
云厂商：基于对象存储，以 S3、OSS、COS 等构建数据底座，进行统⼀存储；
互联网公司：以数据湖三剑客为主，Iceberg、Hudi、Delta lake。它们可以支持比 Hive更高层的 Upsert、Time travel、事务操作等高级特性，能基于 Hive 进行升级，解决准实时性的问题；
传统用户：以 Hadoop 集群为主，满足支持所有结构化、半结构、无结构化的数据存储即为湖。
（2）为什么要用数据湖
更低的存储成本，更高的可靠性：使用对象存储，相比于本地磁盘存储、SSD 存储或者云盘存储等，可以大幅降低存储成本，并且通过编码的方式能够在降低副本数据量的同时又能保证高可靠性，可以使用户不用担心底层数据的丢失，从而获得低成本的存储；
更好的 Table format：通过支持 ACID 事务、支持 Schema evolution，能够为用户提供更好的表格式；
更好的 File format：数据湖在文件格式上支持越来越多的半结构化 map、Struct、Json 等，并且支持越来越多的索引，进而使文件的查询和存储效率更高，并且在基于列式存储的基础上支持更多的复杂嵌套结构；
统⼀的 Catalog：通过统一的 Catalog 实现统⼀的元数据管理、权限管理、统计信息管理、入湖管理等。
2.湖上建仓的意义
基于数据湖是可以构建整个数据平台的数据底座，但是在实际过程中，用户会基于湖上建仓。在传统的架构中会将 Hive 中的数据重新导入到 StarRocks 中，或者导入到其他的 OLAP 中，做进一步的加速处理。
（1）为什么要在湖上建仓
数仓加速：基于数据湖的远程 IO 成本很高，且缺少一系列数仓加速的手段。早期的数据湖格式多样且不成熟，索引的支持不完善，查询性能有待提升。并且数据湖主要针对吞吐量的优化，关注低成本和高可靠，不适用于高性能的需求；
实时分析：传统的数据湖实时性不够，在 Iceberg 或者 Hudi 的支持下可能能解决分钟级别的时效性，但是无法解决秒级时效性的问题；
高并发查询：对于高并发查询，不管是点查还是聚合类的查询，数仓是更擅长的。比如做分桶的处理，更精细的裁剪，降低扫描的数据量，提升点查的效率。另一方面通过物化视图或者 CUBE 等相关的预聚合手段，可以提升聚合查询的性能。
（2）引入 OLAP 的问题
基于以上原因，通常会在数仓架构中会构建一个 OLAP 层，但是引入 OLAP 层会带来很多问题：首先是数据导入，从 A 到 B 如何保证数据增量的变更，如何维护不同系统间主数据和元数据的一致性，以及数据存储成本的上升进而导致管理成本成倍上升的问题。
（3）为什么要湖仓融合
降本增效：简化技术架构，增强整体架构可靠性，降低运维成本；
Single Source of Truth：统一数据存储和输出，所有数据的口径都是一致的，基于相同的数据计算，保证数据的一致性；
更完善的数据治理：湖仓融合的数据底座统一了主数据和元数据，基于此才有可能做上层统⼀的数据治理。
3.Lakehouse 分层与 StarRocks
在湖仓融合的场景下 StarRocks 也在做相应的架构转型：从传统的 OLAP 引擎加入到更加开放的 Lakehouse 生态中。Lakehouse 是天然的分层架构，中间的每个层次会有各种各样的选择，StarRocks 也会作为开放的生态加入到里面来。
① Storage：存储层，以 HDFS 和 S3 等对象存储为主；
② File format：除了传统的 Parquet、ORC、CSV 等格式外，StarRocks 也支持自身特有的文件格式；
③ Table format：StarRocks 通过自身的表引擎提供与 Iceberg、Hudi、Delta lake 类似的功能；
④ Catalog：StarRocks 的 FE 支持自有的 Catalog 元数据格式，同时也多一个能很好地支持包括 Hive Catalog 以及其他云产品的 Catalog；
⑤ Compute engine：计算引擎是 StarRocks 的核心优势。作为查询引擎，它能够很大程度地提升整个报表分析的性能，并且通过 Spark、Flink 的配合，流批处理后的数据 StarRocks 可以做报表的查询。
02
湖仓融合的难点
本章节将介绍湖仓融合的难点，以及 StarRocks 为什么适合湖仓融合的场景。
整体来说湖仓融合的难点有三个：
① 如何统一湖仓的元数据和建表语句，让用户获得一个统一数据目录和表结构。
② 如何完善湖仓的实时能力，来解决不同场景的实时性需求。
③ 如何让湖仓架构能够有超过数仓的性能。
下面分解介绍下几个点中 StarRocks 的能力和规划：
1. 湖和仓的差异—Catalog 和建表
湖仓融合的核心问题在于：把目录结构和表结构进行统一，然后暴露给用户统一的语义层。
湖仓融合对用户而言是要尽量简单的暴露一个统一的接口，StarRocks 的 Multi-catalog 能力可以让 StarRocks 支持各种各样的 catalog。但是不同的湖格式和 StarRocks 的建表差异是很大的，它们有各自的分区模式，而且在湖上是不支持分桶的，这样通过分桶（数据分布）提升点查速度就很难实现，StarRocks 通过外表物化视图可以对用户隐藏表格式的差异，让用户无缝的获得透明加速的能力，保证一个表语义的同时也可以给有调优能力的用户提供自己定义的空间。
2. 湖和仓的差异—Table format
（1）Table format 对比
对于实时更新的场景 Iceberg 和 Hudi 能够提供类似 Merge-on-read、Copy-on-write 的表，其本质是权衡数据更新场景下的读写效率。
Merge-on-read：每次数据会写入一个新的版本，在查询的时候对版本进行归并排序，返回给用户一个去重合并后唯一的结果；
Copy-on-write：对写效率一般，但是对读的性能很好。对已有数据和新数据做合并处理，这种模式很难解决中高频率写入操作的场景；
Merge on write：StarRocks 在行业内比较早的引入了 Delete and insert（Merge on write）模型。主要是通过内存里的主键索引记录所有数据的变更，每一次数据的更新只是在原有的数据上做标记删除，然后将数据存在 bitmap 中，新数据直接插入到后面；
对比 Delta store：Merge on write 的模型在读写之间做了权衡，相比 Delta store（类似 kudu 的模式）能更好的利用二级索引。
（2）StarRocks 补充秒级时效性场景
StarRocks 支持 Merge-on-read 和 Delete-and-insert 两种模式，可以更好地解决数据湖中秒级时效性的场景，可以作为实时数据湖的一个很好的补充。同时 StarRocks 外表支持 Iceberg/Hudi/ 和 Delta 的 Merge-on-read 和 Copy-on-write 模式，可以无缝对接已有的数据湖实时更新方案。因此，StarRocks 可以完成湖上不同实时性需求，同时也衍生出两种湖仓融合的模式（参见后文的模式二和模式三）。
3. 湖和仓的性能差异 — 如何让 Lakehouse 提供和数仓一样的性能
将 StarRocks 作为湖仓的查询引擎，在性能上是可以和将数据直接导入到数仓中进行媲美的，其主要优势体现在以下几个方面：
（1）本地 IO 和远程 IO
相比传统的湖仓，StarRocks 通过内嵌的 Local cache 加速 IO 的性能，可以避免远程 IO，并且内嵌的 Local cache 可以一键打开，不需要单独部署，使用起来非常简单、方便。
（2）File Format
数据类型：使用 StarRocks 作为加速引擎是有很大优势的，适配其它湖上各种数据类型（Json/Struct/Map），可以通过外表直接将数据接入。内置的文件格式支持 bitmap/Hll 等预聚合的数据类型，可以进一步实现加速效果，并且对 Fast Decimal 类型也进行了专门的优化。
索引：除了排序索引外，StarRocks 还支持聚簇索引和二级索引，相比传统湖使用更方便，效果更好。
（3）数据分布
目前 StarRocks 支持哈希分布，这样在分区的粒度上可以进一步对数据进行划分，在此基础上可以支持 colocated join、colocated aggregation 等操作。可以让数据感知到在本地存储能够让相同 tablet 的数据在本地进行 join 或者 aggregation 的操作，这样可以降低由于 join 带来 shuffle 的成本开销，同时可以提升点查的性能。
（4）查询引擎
StarRocks 相比 presto 在向量化引擎上有更大的优势，通过 MPP 执行框架在充分利用多机多核的情况下大幅度提升了性能。新版本将进一步支持 Query cache，在内存中缓存计算的中间结果来进一步提升查询的执行效率。
（5）统计信息
当前湖上的统计信息是比较基础的，而 StarRocks 本身可以提供 ndv ngram 等复杂统计信息，来进一步提升查询的性能。
4. StarRocks as a lakehouse
总结：通过上述各种的手段，StarRocks 无需用户做数据导入，就可以在统一的湖仓架构上提供一套和数仓一样查询性能和实时性要求的湖仓解决方案。
03
StarRocks 湖仓融合的四种范式
1. 湖仓融合 1：数据湖查询加速
数据存储在 Hive/Hudi/Iceberg 等传统的湖中，通过 StarRocks 作为查询引擎进行加速，并且可以通过开启 Local cache 缓存一部分数据，通过这种方式可以加速数据湖的查询。
以下是我们的测试结果：
（1）2.x 版本：
完整的支持 Hive/lceberg/Hudi/delta lake 的 Catalog 和外表查询；
通过 CBO 和向量化执行引擎的优势，外表查询相对于 Trino 或者 Presto 有 3 倍左右性能的提升；
通过开启 Local cache 可以进一步提升 2-3 倍左右的性能。（总体性能是传统数据湖的 6-9 倍）。
（2）3.x 版本：
支持 Trino/Presto 方言，可以使用户在使用上进行无缝切换。
2. 湖仓融合 2：湖仓分层建模
用户基于数据湖的底座对数据进行分层处理，类似：ODS-DWD-DWS-ADS，进而对数据做宽表或者聚合处理，为上层用户提供更简单、统一的接口。
基于 StarRocks 的 2.5X 的版本，对比以前传统的数据导入的方式，更推荐使用外表物化视图的方式。因为通过外表物化视图可以建立好整个湖上表和内部表的关系，并且基于外表物化视图可以提供以下能力：
（1）2.5 版本
数据同步：StarRocks 可以通过内置调度简化外表和内表的数据同步，不需要再通过数据同步工具实现数据同步，因为外表物化视图可以定期刷新外表和内表之间的数据，外表中的数据更新和变化可以通过刷新的方式来全量或者增量刷新到 StarRocks 内部；
智能查询改写：支持在不修改原有外表查询 SQL 的情况下自动改写逻辑，通过物化视图为上层查询加速，实现透明加速。并且在该方式下不会对数据管理增加额外负担；
加速手段：该种方式可以使用 StarRocks 内表的所有加速手段，因为通过外表物化视图连接起了湖和仓的使用模式，所以 StarRocks 内表的所有加速手段是可以使用的。
（2）3.x 版本（3.0版本的直播可以预约啦）
DataFunSummit 将在 4月19日19:00-20:00 给大家带来 StarRocks 3.0 版本全面解读
，微信搜索DataFunSummit视频号，预约直播！
① 分区粒度刷新和增量刷新；
② 更完善的 Schema change 同步；
③ 完善流算子实现流批一体的物化视图；
④ 通过算子落盘和更好的资源隔离优化物化视图构建。
3. 湖仓融合 3：实时数仓与数据湖融合
StarRocks 的一部分存储能力是支持秒级时效性的，但是实时数仓要和数据湖结合，我们希望可以暴露出一个统一的表语义，而不是给用户复杂的管理模式。
在该种模式下，StarRocks 提供了一些新的功能。比如，数据通过 Kafka 实时导入到 StarRocks 后，可以定期的将数据刷新到湖上，支持 lceberg/Hudi 等数据湖的格式，并且可以提供给用户统一的查询格式。
在腾讯游戏中，部署了一套 StarRocks FE 和 BE 存算一体的集群。数据通过 Kafka 实时写入到集群中，并且异步刷新到数据湖上。查询数据时，通过一组弹性的 Compute Note 查询 BE 和数据湖中的数据，并且暴露统一的表语义给上层。
（1）从读湖到写湖，冷数据转存成湖格式
① 新版本将继续增强 Hive/lceberg 的写入能力；
② 支持 Parquet/Orc 文件导入的能力。
（2）统一查询
① 可以一张表冷数据在湖中，热数据在仓里；
② 通过统一的 SQL 同时查询湖和仓中的数据。
4. 湖仓融合 4：StarRocks 3.0 云原生湖仓
通过 StarRocks 存算分离的架构实现云原生湖仓。
用户对湖仓的需求是有差异的，有的用户希望可以通过一站式的解决方案实现湖仓一体。此时通过 StarRocks 存算分离的架构，基于底层对象存储或者 HDFS 即可满足该需求。
在该框架下可以采用多 warehouse 的架构实现数据的读写分离，这样既可以实现资源的隔离，又能保证查询性能。
后面会对 StarRocks 云原生湖仓做更加详细的介绍。StarRocks 几种湖仓融合的模式总结如下，可以根据不同场景选择适合的模式：
① 数据湖查询加速：用户已经有比较成熟的湖仓，只需要通过 StarRocks 进行加速，此时适合 Adhoc 的场景加速；
② 湖仓分层建模：数据写入到湖仓中，通过 StarRocks 做 ELT 的加工，通过 StarRocks 的物化视图提供更交互式报表的查询，此时适合高并发低延迟的报表查询；
③ 实时数仓与数据湖融合：数据写入到 StarRocks，通过 StarRocks 解决秒级时效性的问题，并且可以对接 AI 等数据科学的生态；
④ StarRocks 3.0 云原生湖仓：完全基于 StarRocks 的一站式 Lakehouse 解决方案，适合希望通过简单架构实现湖仓建设的用户。
04
StarRocks3.0 版本预览
在介绍 StarRocks3.0 之前先来了解下 StarRock 的发展史，并且在不同的阶段 StarRocks 专攻的方向和优化的方向也不尽相同。
1. StarRocks 1.0-3.0
StarRocks 1.0：整个系列主要是做性能的优化，包括向量化引擎、CBO、低基数全局字典等性能优化。
StarRocks 2.0：更加专注解决实时性等问题，逐步完善 pprimary key 模型，解决了更多实时性的问题，并且对接了各种湖上的格式和引擎，提升了数据湖分析的能力。另外增加了资源隔离的能力，可以使不同的负载在同一个集群中做更好的融合。
StarRocks 3.0：存算分离版本发布、完整 RBAC 权限管理的功能、简化分区创建语法、支持完整的 Update 语法、在批处理场景支持算⼦落盘，解决大查询引起内存不足的问题等优化。
2. StarRocks 3.0 存算分离和 StarOS
（1）什么是 StarRocks 的存算分离和 StarOS
StarRocks 的存算分离是基于内部 StarOS 实现的，在上面的架构图中可以看到 StarRocks 的 FE 和 BE 逐渐从有状态演变成了无状态可弹性伸缩的节点。
StarOS 是一个操作系统，其核心是把云原生时代下的存储和计算进行了抽象。
存储层：将底层存储分成了高吞吐的 File Store 和低延时的 Log Store，不同的存储介质通过 StarOS 抽象后将存储格式进行统一，直接提供给 StarRocks 使用。
计算层：通过 StarOS 的抽象处理，StarRocks 不需要再关心计算时 tablet 副本的数量，以及计算资源的申请和释放。
基于 StarOS 提供的云上或者本地弹性的能力，可以帮助用户降低存储成本、提升计算弹性的能力。
（2）存算分离的目标，以及 StarRocks 存算分离的特色
为什么要存算分离：
① 计算和存储的增长不匹配，随着数据量变大，集群扩展不方便；
② 计算的变化弹性很大，尤其对于 Adhoc 场景下计算集群弹性会很大；
③ 支持多集群能力，把不同的负载分配到不同的集群上；
④ 需要适配云原生的架构，充分利用云上的池化资源能力。
StarRocks 的存算分离特色包括如下几方面：
① StarRocks 的存算分离基于 StarOS，有良好的架构设计，StarOS 定位⼀个通用的云原生基础架构，让各种应用能够快速的获得云原生的能力；
② 存算分离既能支持云上的基础设施（对象存储）也能支持自建的传统基础设施（HDFS），既可以在云上部署，也可以在本地部署；
③ StarRocks 的存算分离可以解决之前云原生数仓中实时问题解决不好的困难。让实时的数多和在底层的湖上做统⼀管理。
3. StarRocks 存算分离的价值
（1）降低存储成本
在原来存算一体的架构中，用云盘或者本地磁盘进行存储，且需要存 3 个副本。如果使用 EBS，相较于使用云上的 S3，成本大概是 4-10 倍的差异。
由于存算分离，数据是持久化到对象存储上的，本地只需要进行缓存 1 份甚至 0 份数据。所以在这两种架构对比下，存储成本大概有 10-20 倍的差异。
（2）资源隔离
为不同的负载创建不同的 warehouse，实现不同 warehouse 之间资源完全的隔离。
（3）Multi-AZ
在云上提供 Multi-AZ 的高可用性，可以跨不同的 AZ 提供高可用的服务，保证集群的高可用，并且不需要额外的成本。
（4）Multi-cluster 和弹性
通过 Multi-warehouse 的弹性为计算带来更多的可能性和场景。在存算一体的架构中，扩容是比较消耗资源的，并且会影响查询的性能。而在存算分离的架构下，可以提供集群更多的扩容方案。例如，在同一个 warehouse 中可以提供多个 cluster，提升并发查询的能力。
4. StarRocks 3.0 存算分离和 StarOS
下面介绍一下 StarRocks3.0 和 StarOS 当前的能力和未来优化的方向。
（1）当前能力
StarRocks 存算分离，支持非 PK 表的所有功能表级别的 TTL 和单副本，可以主动控制每张表在本地缓存中保持的数据规模，故障自动恢复，降低总体持有成本，适合解决日志分析场景的降本。
（2）优化方向
① 多集群支持，增强弹性能力；
② Local LogStore、FileStore，统⼀架构；
③ 实现完整的 Primary key 存算分离；
④ FE 存算分离，提升横向扩展能力。
05
问答环节
Q1：元数据单个 FE 节点是全量数据吗？接入外部 Catalog 云数据是否会存在瓶颈？
A1：现在的版本 FE 是存全量数据。
目前 Cache 外部的元数据有几种不同的策略：
FE 缓存 Catalog 的时候并不需要缓存所有的元数据。例如默认将 File 和 partition 的信息缓存到本地，同时也会提供一些 refresh 的命令，使用户可以提前主动刷新外部的元数据信息。
目前在社区也有关于 Iceberg 元数据存储方案的讨论，是否将 Iceberg 的元数据完全存储到本地磁盘进行持久化是值得讨论和探索的。
Q2：local cache 是 cache 的 Iceberg 或者 hudi 的 format 还是 cache 的 StarRocks 的 format？这几种 format 的差异有多大？
A2：在开启 local cache 的情况下，直接查询 Iceberg 或者 hudi 的表，缓存的是对应数据湖的文件格式。如果通过外表物化视图来进行构建，数据会被持久化到本地，形成 StarRocks 的文件格式。
cache 的性能，在排除特殊优化的情况下，两者的性能是相差不多的。但是 StarRocks 的文件格式和自身的引擎会更加适配，在这类场景中 cache 的性能会有差异，即 StarRocks 性能会更好些。
Q3：3.0 版本何时发布？
A3：计划是在 3 月底发布 rc01 版本，4 月份将发布正式版。
今天的分享就到这里，谢谢大家。
【直播推荐】4 月 19 日晚上 7 点，StarRocks Active Contributor 张友东将在线讲解 从 shared-nothing 到 shared-data 的湖仓分析新范式 如何帮助用户实现“极速统一”的价值。预约直播，活动临近将为您推送开播信息，赶快在微信DataFunSummit视频号预约吧！