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