LakeHouse

什么是LakeHouse（湖仓一体）？

Lakehouse = 云上对象存储 + 湖格式 + 湖管理平台

湖仓一体，又被称为Lake House，其出发点是通过数据仓库和数据湖的打通和融合，让数据流动起来，减少重复建设。Lake House架构最重要的一点，是实现数据仓库和数据湖的数据/元数据无缝打通和自由流动。湖里的“显性价值”数据可以流到仓里，甚至可以直接被数仓使用；而仓里的“隐性价值”数据，也可以流到湖里，低成本长久保存，供未来的数据挖掘使用。

湖仓一体是一种新型开放式架构，将数据湖和数据仓库的优势充分结合，它构建在数据湖低成本的数据存储架构之上，又继承了数据仓库的数据处理和管理功能，打通数据湖和数据仓库两套体系，让数据和计算在湖和仓之间自由流动。作为新一代大数据技术架构，将逐渐取代单一数据湖和数据仓库架构。

Lakehouse兼具数据湖的灵活性与数据仓库的成长性。目前这个方向已经逐渐走向成熟。与数据湖相比，Lakehouse集成了计算框架和SQL查询引擎，添加了数据治理能力，支持Catalog表管理和先进的作业编排。

LakeHouse需要哪些基础能力？

LakeHouse分为功能性设计要素和非功能性设计要素两类。其中：

• 功能性设计要素包括：一体化架构、存算分离、事务和数据一致性、全数据类型。
• 非功能性设计要素包括：弹性高可用、加强的数据治理、尽量少的数据冗余、高并发支持、运维可观测性、高开放性。

一体化架构

• 统一表格式（table format）
• 统一存储格式（parquet, avro, orc...）
• 统一存储介质（对象存储、块存储）
• 统一元数据和权限管理（一份数据全域使用）
• 统一计算引擎（统一批流）
• 支持多计算引擎：内置引擎路由的能力，支持离线计算引擎、实时计算引擎、交互式查询引擎等多种引擎，并支持机器学习、深度学习框架，为数据集成和开发提供多种计算环境，供客户按需选择。
• 统一应用层（提供统一SDK，以支持不同应用）
• 业务开放性，支持标准化的SQL和API，可以灵活的支持各种机器学习语言和框架
• 存算分离，支持多云部署，支持弹性伸缩容
• 提供serverless态服务，确保足够的弹性以及支持按需付费。

LakeHouse的几种常见方式？

数据库、数据仓库、数据湖、湖仓一体的区别？

数仓一体的几种方式？

Paimon

Paimon的优势

开放的数据格式

Paimon以湖存储的方式基于分布式文件系统管理元数据，并采用开放的ORC、Parquet、Avro文件格式，支持各大主流计算引擎，包括Flink、Spark、Hive、Trino、Presto、Doris、Starrocks。ORC原生支持ZSTD。

大规模实时更新

Paimon创新的结合了湖存储 + LSM + 列式格式（ORC, Parquet），为湖存储带来大规模实时更新能力，Paimon的LSM的文件组织结构如下：

• 高性能更新：LSM的Minor Compaction，保障写入的性能和稳定性
• 高性能合并：LSM的有序合并效率非常高
• 高性能查询：LSM的基本有序性，保障查询可以基于主键做文件的Skipping

数据表局部更新和跨分区更新

在数据仓库的业务场景下，经常会用到宽表数据模型，宽表模型通常是指将业务主体相关的指标、维表、属性关联在一起的模型表，也可以泛指将多个事实表和多个维度表相关联到一起形成的宽表。

Paimon的Partial-Update合并引擎可以根据相同的主键实时合并多条流，形成Paimon的一张大宽表，依靠LSM的延迟Compaction机制，以较低的成本完成合并。合并后的表可以提供批读和流读：

• 批读：在批读时，读时合并仍然可以完成Projection Pushdown，提供高性能的查询。
• 流读：下游可以看到完整的、合并后的数据，而不是部分列。

传媒场景中的很多实时大宽表业务中的Partial-Update表只有少量数据会关联上，很多非关联上的数据是不需要的，后面会引入数据淘汰策略，淘汰掉这些数据。用Paimon跨分区更新能力解决分区交界出数据漂移问题。

丰富的表类型

除了主键表之外，Apache Paimon还支持append-only表，提供有序的流式读取来替代消息队列。

主键表的三种核心能力：

• 主键表更新
• 增量数据产生机制（Changelog Producer）
• 数据合并机制（Merge Engine）

ACID事务、回滚、并发控制

ACID事务确保所有更改都成功提交或回滚。确保永远不会以不一致的状态结束。有不同的并发控制，例如保证读取和写入之间的一致性。

Schema Evolution

Spark、Flink CDC支持Schema Evolution。

Merge Into

通过Merge Into实现行级别更新，只有主键表支持这个功能，该操作不会产生UPDATE_BEFORE，所以不建议设置changelog-producer = input。

时间旅行和Tag

带时间旅行的Paimon批读可以指定一个快照或一个标签，并读取相应的数据。如果它不是一个分区表，或者不能按分区进行过滤，可以使用Time travel的流读取。

文件布局优化

随着时间的推移摄入的小文件会增加，但查询数千个小文件很慢，文件布局优化可以将文件碎片重新整理为更大的文件，从而在许多方面提高性能。

异步Compaction

LSM这种原生异步的Minor Compaction，它可以通过异步Compaction落到最下层，也可以在上层就发生一些Minor的Compaction和Minor的合并，这样压缩之后它可以保持LSM不会有太多的level。保证了读取merge read的性能，且不会带来很大的写放大。

另外，Flink Sink会自动清理过期的快照和文件，还可以配置分区的清理策略。所以整个Paimon提供了吞吐大的Append写，消耗低的局部Compaction，全自动的清理以及有序的合并。所以它的写吞吐很大，merge read不会太慢。

Read Optimized

对于主键表，这是一种"MergeOnRead"技术。读取数据时，多层LSM数据会被合并，并行数量会受到数据桶数量的限制。如果想在某些情况下快速查询，但只能找到较早的数据，可以从读优化表中查询：SELECT * FROM T$ro。

但这无法保证数据的新鲜度，因此可以在写入数据时配置full-compaction.delta-commits，以确保读取的数据具有确定的延迟。

StarRocks和其他OLAP系统将在Paimon 0.6的基础上发布一个版本，以大大提高读优化表的查询性能。

统一批流处理

数据架构无需在批处理和流式中区分，它们都以相同的表视图对外暴露，复杂性更低，速度更快。无论是从流还是批处理中读取都能获取一致的数据快照。

几款数据湖的对比

Paimon中LSM如何节省存储成本的？

LSM结构如下：

LSM典型的Minor Compaction是指：增量数据只会让前面几层的文件进行合并，只要增量数据不够多，最底层的文件是不会参与Compaction的，这就意味着多个Tag之间的最底层是完全一样，完全复用的，结合湖格式的文件管理，多个Tag并不会带来冗余的文件存储。

针对增量数据不多的情况，最底层的文件，也是最大的数据量的文件，是可以被多个Tag复用的，你不用做任何事情，Paimon的Snapshot管理会自动完成文件的复用。

StarRocks

StarRocks优势？

StarRocks适用场景

StarRocks可以满足企业级用户的多种分析需求，包括OLAP（Online Analytical Processing）多维分析、定制报表、实时数据分析和Ad-hoc数据分析等。

OLAP多维分析

利用StarRocks的MPP框架和向量化执行引擎，用户可以灵活的选择雪花模型，星型模型，宽表模型或者预聚合模型。适用于灵活配置的多维分析报表，业务场景包括：

• 用户行为分析
• 用户画像、标签分析、圈人
• 高维业务指标报表
• 自助式报表平台
• 业务问题探查分析
• 跨主题业务分析
• 财务报表
• 系统监控分析

实时数据仓库

StarRocks设计和实现了Primary-Key模型，能够实时更新数据并极速查询，可以秒级同步TP（Transaction Processing）数据库的变化，构建实时数仓，业务场景包括：

• 电商大促数据分析
• 物流行业的运单分析
• 金融行业绩效分析、指标计算
• 直播质量分析
• 广告投放分析
• 管理驾驶舱
• 探针分析APM（Application Performance Management）

高并发查询

StarRocks通过良好的数据分布特性，灵活的索引以及物化视图等特性，可以解决面向用户侧的分析场景，业务场景包括：

• 广告主报表分析
• 零售行业渠道人员分析
• SaaS行业面向用户分析报表
• Dashboard多页面分析

统一分析

• 通过使用一套系统解决多维分析、高并发查询、预计算、实时分析查询等场景，降低系统复杂度和多技术栈开发与维护成本。
• 使用StarRocks统一管理数据湖和数据仓库，将高并发和实时性要求很高的业务放在StarRocks中分析，也可以使用External Catalog和外部表进行数据湖上的分析。

产品特性

• MPP分布式执行框架
• pipeline并行执行框架
• 全面向量化执行引擎
• Global Runtime Filter
• CBO优化器
• 可实时更新的列式存储引擎
• 智能的物化视图
• 数据湖分析
• 存算分离

优点

• 单表查询和多表查询性能都很强，可以同时较好支持宽表查询场景和复杂多表查询。
• 支持高并发查询。
• 支持实时数据微批ETL处理。
• 流式和批量数据写入都能都比较强。
• 兼容MySQL协议和标准SQL。
• 能够保证数据的exactly-once
• 支持多种分布式Join方式，支持多种数据模型
• 架构简单，易于维护，无侵入式弹性伸缩与扩容
• 新版本支持存算分离，尽可能的减少依赖外部组件

StarRocks常见优化手段？

• 通过建表优化性能
  • 选择数据模型
  • 使用Colocate Table
  • 使用星型模型
  • 使用分区和分桶
  • 选择Zstd作为压缩格式
  • 使用稀疏索引和Bloomfilter
  • 使用倒排索引（Bitmap）
  • 使用物化视图
• 优化导入性能
• 优化Schema Change性能
• CBO优化器开启
• join优化，选择合理的join方式
• 利用query cache缓存中间计算结果
• Sorted streaming aggregate完成有序的排序聚合
• 存算分离，实现数据的持久化
• 中间算子罗盘
• Data Cache加速查询数据湖
• 根据业务特点和需求调整Compaction相关参数
• 参数调优（BE、FE内存配置、高并发配置、BE、FE内存，并行度、buffer缓冲大小、线程数...等)

StarRocks存算分离？

StarRocks的存算分离是基于内部StarOS实现的，在上面的架构图中可以看到StarRocks的FE和BE逐渐从有状态演变成了无状态可弹性伸缩的节点。

StarOS是一个操作系统，其核心是把云原生时代下的存储和计算进行了抽象。

存储层

将底层存储分成了高吞吐的File Store和低延时的Log Store，不同的存储介质通过StarOS抽象后将存储格式进行统一，直接提供给StarRocks使用。

计算层

通过StarOS的抽象处理，StarRocks不需要再关心计算时tablet副本的数量，以及计算资源的申请和释放。

基于StarOS提供的云上或者本地弹性的能力，可以帮助用户降低存储成本、提升计算弹性的能力。

为什么要存算分离？

• 计算和存储的增长不匹配，随着数据量变大，集群扩展不方便；
• 计算的变化弹性很大，尤其对于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，提升并发查询的能力。

开放Lakehouse架构

StarRocks具备存算分离和数据湖分析能力之后，StarRocks本身已经形成了一个分层结构的Lakehouse的架构。

• 存储层，统一采用S3、HDFS等共享存储系统
• File format层，数据湖采用Parquet、ORC等开放格式，StarRocks则有对应的Segment文件格式
• Table format层，数据湖有Hudi、Iceberge的组织格式，对应StarRocks Table的组织
• Catalog层，数据湖采用HMS，StarRocks采用FE来统一管理元数据
• 计算层，数据湖采用开源的Spark、Flink等组件，而StarRocks CN节点提供统一的计算

虽然架构理念一致，但StarRocks相比数据湖在数据格式访问优化，数据更新的能力上提供了更好的支持。

• StarRocks Segment文件支持Bloomfilter、Bitmap等各种索引来加速查询
• StarRocks Table支持通过分区、分桶、排序、colocate等策略优化数据组织，并提供实时更新的能力
• StarRocks CN通过CBO、向量化、Query Cache等技术来提升查询性能

湖仓融合架构对比

数据湖Paimon + Flink + StarRocks

在这个架构里，Paimon通过对数据的落盘和索引，弥补了上文介绍的Kappa架构中消息队列中间件在数据的修改、回溯、查询等方面的不足，从而使得这个架构的容错率更高，支持的能力也更广泛。同时在批处理方面，Paimon也可以完全兼容HIVE的能力。

物化视图连接湖仓

StarRocks物化视图的核心价值在于简化湖仓建模，并利用物化视图实现查询加速。StarRocks 3.0已经支持了比较完备的物化视图能力：

• 在物化视图的构建上，支持所有复杂查询，支持基于外部Catalog建物化视图以及嵌套物化视图。同时，物化视图可以当一张普通的表进行查询管理。
• 在物化视图刷新方面，采用异步刷新方式，支持周期性或修改触发式的刷新模式，并支持细粒度的刷新控制，以尽量减小物化视图的维护代价。
• 在查询改写上，Scan、Filter、Aggregation、Join、Union等都支持利用物化视图来自动改写查询加速。

敏捷性湖仓融合如何完成加速查询?

1. 用增量计算模式统一流、批和交互三种计算形态（增量物化视图）。
2. 用通用增量存储的统一存储形态。 在湖仓存储架构的基础上增加了通用增量存储，使得在湖仓之上能够做增量的表达，该存储需要做到以下三点：
   • 实现大通用的存储，是可以适应面向写入Throughput和查询高性能的两个维度进行优化。
   • 数据存储支撑多种更新模型（Copy-on-write、Merge-on-read、Merge-on-write多种模式），通过Compaction达到效率和成本的平衡。
   • 实现数据的开放性，最终把数据的表达变成标准化的开源Iceberg/paimon存储格式，使得其它的引擎或者平台可以很方便地对接起来。
3. 采用存算分离的架构，以支持多种应用、弹性伸缩
4. 使用DataCache加速查询数据湖
5. 中间算子罗盘
   从v3.0.1开始，StarRocks支持将一些大算子的中间结果落盘。使用此功能，您可以在牺牲一部分性能的前提下，大幅降低大规模数据查询上的内存消耗，进而提高整个系统的可用性。

目前，StarRocks支持将以下算子的中间结果落盘：

• 聚合算子
• 排序算子
• Hash join（LEFT JOIN、RIGHT JOIN、FULL JOIN、OUTER JOIN、SEMI JOIN以及INNER JOIN）算子

数据湖Paimon + 物化视图完成加速查询

它与第一个方案的区别是几乎整个系统都由StarRocks单独完成。当数据接入Paimon，使它作为ODS层之后，通过StarRocks的外表特性来读取Paimon上的数据，建立一层物化视图来作为DWD层。

StarRocks的物化视图具有一定的ETL的能力，当它作为DWD层之后，又通过第二层嵌套物化视图来作为DWS层，最终提供给数据服务层进行数据分析。

通过StarRocks的这套系统配合Paimon这个架构的两个优点是：

• 简化了运维，因为它不用再去维护各种组件，只需要StarRocks和Paimon就可以完成数据分析方案的构建；
• 查询速度快，因为StarRocks是一套从构建索引、数据存储、查询优化都自成体系的一个数据湖引擎，所以它相比上文介绍的其他各种查询引擎速度更快。

图右侧SQL是描述如何建立一个StarRocks异步物化视图。它主要有以下几个特点：

• 通过SQL定义，上手简单，方便维护；
• 预计算，降低查询延时，减少重复计算开销；
• 自动查询路由，无需改写SQL，透明加速；
• 支持异步自动刷新数据，定时刷新，智能按分区刷新；
• 支持多表构建，基表可来自内表、外表和已有的物化视图

物化视图的功能？

物化视图的语法有几个部分：

• partitionby：对物化视图分区，和StarRocks内表一样，可以按照时间等维度进行分区。分区后可以对查询裁剪，避免访问不需要的数据，比如按天分区后就只需要刷当天的数据，历史数据不需要去touch。还可以进行分区级的数据自动刷新、数据变更的自动订阅，实现比较好实时性。
• Refresh：支持全量刷新、增量刷新、定时刷新、手动刷新等多种方式。满足不同业务场景的需求。
• resourcegroup：把物化视图跟其它workload更好地整合在同一个系统、同一个集群里。因为用户的查询是一种偏前端的workload，而物化视图的维护是偏后端、资源非常密集的workload，所以如何把这两种整合到一起，稳定地跑到同一个集群里面，是一个很大的技术难点。所以我们这里选择用resource group技术来实现资源隔离。
• 查询语句：支持aggregation、join等查询语句。

对不同的查询语句类型可以使用不同的刷新方式，如果是简单的聚合查询可以增量刷新，如果有join或者更复杂的语句就要全量刷新。未来StarRocks会逐步扩展物化视图的增量刷新能力，支持更多的复杂使用场景，比如增量的join窗口，类似Flink的增量计算等等。

MV - 数仓建模

如果使用Hive等外部系统，数据可能先要过一遍Hive，中间的计算开销以及IO开销就会非常的消耗资源，然后再往下游系统写数据，它的IO又会多了几倍，一旦有很多的IO开销以及组件，整体性能就很难优化，非常消耗资源，ETL任务的实时性也很难保障。

迁移到StarRocks就可以很好地解决这些问题，主要用到下面几个关键技术：

• 支持多数据源：可以基于内表、数据湖外表和JDBC外表等创建物化视图，比如可以对MySQL、Postgres创建物化视图，把数据同步到内部来，这样就可以不用直接查外部数据了。
• 维护分区关系：对内表和外表的分区关系进行维护，使得全量刷新可以依靠分区去做更细粒度的数据刷新和物化视图维护。
• 任务调度：物化视图join表的时候可以显示声明依赖关系，被join的表更新完成后才刷新视图。如果有多张表作为事实表，还可以使用接口手动控制调度、定制业务集。
• 资源隔离：在使用物化视图替代传统数仓建模的时候，只需要添加一个新的resource-group，不需要部署新的集群，让多个workload跑在同一个系统集群中。

上图中T1是事实表，T2是维度表，列举了一些分区刷新的经典场景：

• 事实表细粒度刷新： 维度表的变化频率是相对比较低的，如果事实表做了比较细粒度的分区，比如天级、小时级或分钟级的分区，在事实表刷新之后，基于分区就可以发现物化视图对应的某一个分区也需要更新，那就只需要刷新一个分区，代价是相对比较低的。
• 维度表精准刷新： 最经典的场景是刷新整个物化视图，代价相对较大。有些业务像酒店餐饮是可以不回刷数据的，那么可以精细化的排除某些维度，不触发回刷。也有一些业务，希望回刷比如一个月的数据，那么可以精准的控制回刷几个分区。
• 自动刷新： StarRocks支持订阅外表分区的数据变更，当发现Hive等外表分区变更后，可以自动刷新物化视图对应的分区。

MV - 弹性资源隔离

StarRocks实现了统一的架构，能够同时运行Ad-hoc query、Dashboard、Realtime、Batch等多个workload。Realtime物化视图时效性要求通常比较高，比如实时看板一般是分钟级，所以资源消耗比较大。Batch物化视图允许慢一点一般是天级，通常是在半夜定时去跑，所以不需要占用非常多的资源。那么如何资源隔离，使不同的workload不会互相影响，就成为了一个难题。目前StarRocks用了资源组软性隔离和Warehouse硬性隔离两个技术来实现资源隔离。

资源组软性隔离： 用户可以使用默认资源组，或者根据业务需要创建资源组，非常细腻的控制每个视图的CPU、Memory、Disk等资源的最大配额占比。当只有1个workload时允许跑到100%，当有多个workload时，就根据配额的比例分配资源，因为是软性，所以加起来可以超过100%。

Warehouse硬性隔离： 在云原生架构实现了无状态计算节点的架构。物化视图可以放在独立的节点运行，将资源彻底隔离开来。Warehouse本身是弹性的，可以随时创建、释放。

MV - 透明查询加速

MV案例 - 实时精准去重

冷热分离

这是通过Paimon + StarRocks实现冷热分离的特性。

冷热分离的概念，是希望可以将经常查询的热数据存储到查询快的像StarRocks这种OLAP引擎上，不经常查询的冷数据存储到比较廉价的远程文件存储组件，比如OSS和HDFS。

如上图Paimon + StarRocks冷热分离的例子，如果构建了这样一个冷热分离的MV表，当查询到这张表的时候，会自动选择在StarRocks上分布的这个热数据和在Paimon分布的冷数据。然后对查询结果合并，并返回给用户。

Iceberg + StarRocks MV完成湖仓融合加速

基于Iceberg统一批流的湖仓

使用增量物化视图做增量计算，批流计算和实时计算，只需要根据不同的刷新策略满足即可。

• 实时聚合：主要面向immutable的数据，这类数据可以直接去写Lake，使用Iceberg这种数据湖的写入吞吐量会比较高。
• 实时更新：主要面向mutable的数据，数据湖目前还没有较好的实时更新能力，StarRocks primary key则可以很好的支持，所以首先会把数据写到pk表，定时下沉到Lake中，同时在此之上，可以用物化视图做实时的增量聚合。

结合实时聚合和实时更新两种场景，把全量数据存在Iceberg中，把聚合、更新数据放在StarRocks中，然后在上层构建物化视图去做面向业务的加工宽表、聚合结果，可以带来以下几方面的业务价值：

• 一是SSOT，不管是面向归档，还是面向其它查询引擎，都能直接查询数据湖，不会被封闭在一个系统里。
• 二是变成实时后，可以分摊资源，不会在凌晨出现一个业务高峰，而白天又很空闲，导致资源浪费。
• 三是可以发挥不同存储引擎的优势，StarRocks支持实时聚合、实时更新，数据湖可以存储历史数据，具有超高的写入吞吐量的优势。

Apache Iceberg + Amoro湖仓一体

StarRocks数据应用

除了提供一站式湖仓能力，StarRocks在数据管理、写入、查询等方面做了很多提升，目标是让用户构建数据应用更安全、更简单、更高效。

Role Based Access Control

数据进入到StarRocks，首先要解决的就是数据访问权限管理的问题。StarRocks在2.x提供了简单的权限管理机制，在3.0版本，StarRocks推出全新的Role Based Access Control（RBAC）权限机制。

RBAC简化了权限的授权、变更、回收等。RBAC支持细粒度权限控制，定义了40+对象，10+操作类型，用于灵活定义Role，比如数据湖上的表和StarRocks内表可以通过Catalog对象进行统一的权限管理。同时为了简化管理操作，系统内置一些常见的Role，比如DB_ADMIN、USER_ADMIN等。

RBAC采用最小权限原则，当用户拥有多个Role时，支持设置默认的Role，也可以在不同的Session里设置使用不同的Role，避免权限误用，提升安全性。

优化数据分布策略简化建表

StarRocks的表会根据分区（PARTITION BY）键，切分为多个分区，每个分区会根据分桶（DISTRIBUTED BY）键，再切成多个分桶以利用MPP的能力。在过去我们遇到的主要问题是分区策略表达比较复杂以及分桶数量难以合理设置。

在3.0版本中，StarRocks在分区分桶管理上做了优化，简化建表语句：

• 引入PARTITION BY表达式的分区能力，简化按年、月、日分区的表达，用户无需提前规划分区，而是在导入数据时，系统按需创建分区。
• 无需指定分桶的数量，建表的时候会自动根据节点资源推算，同时随着数据不断导入，还具备根据历史分区动态调整新分区分桶数量的能力。
• 在后续版本，我们还会继续对建表做简化，支持自适应的数据分布策略，以及自动的数据源类型推断等能力，让StarRocks的数据建模更简单。

主键模型update语法支持

StarRocks通过delete + insert的方式支持OLAP场景的实时update能力，在过去的2.0系列版本里，主要围绕功能、性能持续进行提升。在功能方面，支持了partial update、conditional update的能力，通过数据列的字段来标识数据操作；在性能方面，从全内存的主键索引升级为持久化的主键索引，解决主键模型内存占用的问题。

在3.0版本，StarRocks更进一步，提供了Update语法的支持，包括跨表更新、CTE等
end