在 11 月 17 日举行的 StarRocks Summit 2023上，StarRocks TSC Member、镜舟科技 CTO 张友东详细介绍了 StarRocks 社区的发展情况，并全面解析了 StarRocks 的核心技术与未来规划；我们特意将他的精彩演讲整理出来，以帮助大家更深入地了解 StarRocks 。
社区概览
随着数字技术的发展，数据呈爆炸式增长，数据类型越来越丰富，对数据价值挖掘的实时性要求不断提升，业务场景也越来越复杂度。在过去几年里，数据分析的需求通常采用多套系统组合的方式来完成，比如采用 Kylin 在支持 BI 报表场景，采用 Trino、Impala 支撑交互式分析场景，采用 ClickHouse、Druid 来支撑实时分析场景，StarRocks 希望通过技术创新简化数据技术栈，用户可以借助 StarRocks 一个引擎实现全场景的数据分析。
StarRocks 从2021年9月正式开源，在过去两年时间里，Github star 5700+，有近300位开发者参与社区贡献，对齐到两年的时间里，StarRocks 同类开源数据库项目里增长最快的。2022年底，StarRocks 项目正式捐赠给了 Linux Foundation，更加开源开放，希望能吸引到全世界的开发者和用户参与社区建设。
StarRocks 目前已经在各个行业的标杆用户落地，包括互联网、游戏、零售、物流、制造、金融等行业，有超过 300家市值10亿美金以上的大型用户在生产环境使用 StarRocks，场景覆盖 BI 报表、交互式探寻分析、实时分析、湖仓分析等一系列场景，其中很多用户已经采用 StarRocks 实现了全场景的数据分析架构统一。
StarRocks 开源社区非常活跃，社区开发工作由镜舟科技主导推进，贡献了70%以上的核心代码；随着社区不断的发展壮大，目前吸引了阿里云、腾讯、火山引擎、滴滴出行等头部企业的参与，从 StarRocks 2.4 版本开始，阿里、腾讯等企业开始持续给社区贡献重点特性，包括物化视图、CN 弹性节点、Pulsar 数据源、Paimon catalog 等一系列的重要特性。
StarRocks 开源至今，经历了3个大版本的迭代，分别是 1.0、2.0 以及现在正在迭代的3.0大版本，一直以‘极速统一’为中心发展。
1.0 版本主打性能，借助 CBO、向量化引擎、Runtime filter等技术，性能方面做到业界领先，这些最核心的基础 Feature 已经在生产环境稳定运行2年以上，为 StarRocks 广泛应用打下了坚实的基础。
2.0 围绕融合统一，支持了 Pipeline 引擎、主键模型、数据湖分析、物化视图、资源隔离等一系列的能力，让更多的分析 workload 能同时在 StarRocks 上运行，从而达到统一的目的，这些特性已经在生产环境稳定运行一年以上。
3.0 围绕湖仓一体，在存算分离、湖仓分析、物化视图等方向上重点突破，用户可以通过 StarRocks 轻松构建湖仓一体架构，实现 One Data，All Analytics 的湖仓分析价值。
技术进化
存算分离降本增效，弹性伸缩
StarRocks 3.0 版本开始，正式支持了存算分离架构，StarRocks 由 FE、BE 组件组成，FE 负责元数据的管理，查询计划构建，而 BE 则负责实际的数据存储和查询计划的执行；在 3.0 版本之前，数据存储在 BE 的本地，通过多副本的机制实现高可用；在 3.0 存算分离架构下，数据则存储到 S3 对象存储或者 HDFS 上，实现存算分离架构。
StarRocks 的存算分离架构优势
架构设计高度抽象，可扩展性强：StarRocks 在实现存算分离时做了一层 StarOS 的抽象，将分布式调度、存储访问、Cache 管理等逻辑进行了封装，屏蔽了底层环境差异，使得在数据库层面可以像开发单机应用一样开发分布式应用， 这也使得存算一体与存算分离的开发上能很好的统一。
极简架构，易于管理：存算分离保持极简架构，无需引入复杂的组件依赖，能够同时适应在 Cloud 与 On premise 环境里部署。
实时与分析一体：存算分离架构下依然可以实现实时的数据导入，实时数据查询的能力，同时也支持主键模型来满足数据更新的需求。
在性能方面，从存算一体架构到存算分离，I/O 从访问本地盘变成了访问远端到存储，I/O latency 上有明显的增加，存算分离架构通过将数据缓存在本地磁盘来进行查询加速，这也是业界普遍的做法。存算分离的性能在开启 Data cache 的情况下，跟存算一体的查询性能一致；在完全冷读的情况下，查询延时是存算一体的2-3倍，能满足绝大部分的场景的性能诉求。
存算分离架构给业务带来的价值主要有2个点，一是降本增效、二是灵活的弹性伸缩；
存储层面，StarRocks 的存储从三副本本地盘或云盘的存储，变成一副本的 S3/HDFS 存储，整体存储成本可以下降 80%；计算节点无状态，可以通过快速弹性来灵活应对业务波峰波谷带来的技术挑战。
在存算分离架构下，StarRocks 可以方便的支持 Multi-warehouse 的能力；多个 Warehouse 共享一份数据，不同 Warehouse 应用在不同的 Workload，计算资源可以进行物理隔离，Warehouse 内部按需独立弹性伸缩。比如你可以用一个 Warehouse 用来导入，如果是离线的场景，数据导入完，就可以临时把 Warehouse 的资源释放来降低成本，然后构建不同的 Warehouse 用来分别用来服务BI 报表与 adhoc 查询的场景，彼此间计算物理隔离，Warehouse 内部按需弹性伸缩。
极速统一的湖仓分析
StarRocks 从 2.5 版本开始支持统一 Catalog 的管理，既能高效分析导入到 StarRocks 里的数据，也能直接分析外部数据源的数据。包括开放的数据湖 Hive、Iceberg、Hudi、关系型数据库 MySQL、PostgreSQL ，Elastic search 等，并能实现跨数据源的联邦分析。
极致的数据湖分析性能
StarRocks 可以直接分析外部数据源，免除了 ETL 的负担，针对开放数据湖的数据，StarRocks 做了大量的优化，来提升查询效率。 CBO、向量化引擎、Runtime Filter、延迟物化等一系列查询层的技术都可以应用到湖上数据分析。
I/O 合并，减少 I/O 次数：通过 column、row group 合并访问等机制减少 I/O 次数。
借助 Data cache 降低 I/O 延迟，让 I/O 延迟达到访问本地存储的水平。
直观来讲，假设以 Trino 直接查询 Hive 作为基准，不做任何的数据迁移，StarRocks 直接查询数据湖在绝大部分场景下性能提升3倍，主要得益于 StarRocks 的向量化引擎、CBO 优化器，以及 C++ Native 的执行；在此基础上，如果打开 Data cache，性能可以达到 Trino 的6倍；如果性能还不满足业务需求，可以将数据写入 StarRocks 内表，借助优化的数据组织，细粒度的索引、统计信息等，查询性能相比 Trino 10+倍性能提升。
目前 StarRocks 社区已经很多用户采用 StarRocks 替换 Trino/Presto 来加速湖上的查询，为了减少用户的迁移成本，StarRocks 从 3.0 版本开始支持了 Trino 的查询方言，整体兼容度 90% 以上，使得用户可以无缝替换，获得更好的查询性能。
简化建表语句，提升数据导入效率
借助 StarRocks 极速的数据湖查询能力，能满足大部分的 OLAP 查询需求，对于实时性要求非常高的场景，则需要以 StarRocks 作为数据存储，将数据导入到 StarRocks，通过 StarRocks 主键模型的能力来支持秒级别实时更新的能力。
在分布式架构下，StarRocks 的一张表要先进行分区，每个分区根据 Hash 分成多个桶，每个桶内的数据独立存储管理，数据按指定的 Key 进行排序。StarRocks 在分区、分桶、排序等方面都做了大量的优化工作，使得用户初次建表非常简单，如果表的数据组织不满足查询性能要求，可以通过 Optimize table 来一键优化。
分区：支持根据表达式自动建分区、LIST 分区等简化分区的创建。
分桶：支持随机分桶策略，支持根据历史分区大小推断新分区的分桶数。
排序：各数据模型支持 ORDER BY 来统一制定排序键，使得排序键与列定义顺序、主键完全解耦。
在写入方面，数据写入之后为了保证高可用，数据需要复制到多个节点，StarRocks 2.5 版本开始在数据复制写入方面做了很大的提升，引入了 Single leader replication 的策略，原来的写入流程里每个副本上都要写 memtable、对数据进行排序编码，然后 Flush 成 Segment 文件；在新的方式只需要一个节点写入数据为 Segment 文件，然后将文件物理复制到其他的副本，新的写入方式在 CPU、MEMORY、I/O、NETWORK 方面的开销都明显降低，使得新的导入方式的性能提升一倍。
主键模型：数据更新与查询效率可以兼得
StarRocks 通过 delete + insert 的方式支持 OLAP 场景的实时 Update 能力，是开源数据库里最先采用该机制实现数据更新的系统。主键模型在功能上持续完善：
（1）支持全内存和持久化两种模式的索引，适应不同硬件配置的场景；
（2）支持部分列更新，能非常简单的实现多流 join 的需求；
（3）支持条件更新解决高并发写入时数据乱序写入问题。
在性能方面，StarRocks 支持了按列更新的模式，更新时只需修改对应列的数据，性能相比按行更新的模式提升10+倍，分析型数据库通常采用列存，列存部分列更新时，需要把原来所有的数据读取出来构造完成的行再重新写入，代价非常大；对于有的场景，用户只对全表少数列更新时，则可以采用 StarRocks 按列更新的模式；该特性非常有用，比如在用户画像的场景，用户可以在外部构建好用户不同维度标签的信息，然后采用列更新的模式，聚合成一张大宽表。
生成列加速半结构化数据分析
StarRocks 原生支持 JSON、ARRY、MAP、Struct 等类型方便半结构化数据的处理。半结构化数据整体存储，方便灵活访问，但查询性能不高，因为在查询过滤时需要将整个字段读出来做计算，资源开销非常大。在 StarRocks 3.1 版本里支持了生成列（Generated column ）的新特性，用来加速半结构化数据的查询。
用户可以将数据数据存成 JSON，将其中经常需要查询分析的列，以生成列的方式单独存储，查询的时候会自动改写利用生成列加速；反过来，如果原始数据是大宽表的形式存储，但有多个列或者所有列经常需要一起访问，这个时候可以将这些列组合成一个 JSON 对象以生成列的方式存储，加速整体的查询。
算子落盘突破查询内存限制
不管数据在开放数据湖还是 StarRocks 里，在 2.x 系列的版本，StarRocks 查询的中间结果必须能全部加载到内存，这样查询速度是最快的，但对于一些特别复杂的场景，以及一些对延时不敏感的 ETL 场景不太友好。
在 3.0 ，StarRocks 支持了查询中间结果落盘的机制，Aggregate、Join、Order by 的查询中间结果，遇到内存不足时，可以临时换到磁盘，保证查询不会因为内存不足而失败。算子落盘可以较好去支持物化视图构建、轻量级 ETL；目前算子落盘，在3x16c64g 节点，能稳定跑完 TPC-DS 的所有99个查询，不会出现内存不足而无法完成的情况，同等配置情况下是 Spark 效率的4.35倍。
全新物化视图，为更多场景加速
物化视图是数据库领域的经典概念，本质上是将查询结果进行物化存储，用来加速查询；物化视图在 OLTP 数据库作用相对较小，但在 OLAP 的场景，因为很多的查询比较复杂，能发挥很大的作用。在 StarRocks 早期的版本，已经有了同步的物化视图，支持单表简单聚合算子的查询；但是对于复杂的算子，以及多表 join 的场景则无法加速。
StarRocks 从 2.4 版本开始研发全新的异步物化视图，物化视图可以针对任意 SQL，极大的丰富了应用场景；支持手动、自动方式来维护物化视图与基表的一致性，做到分区粒度的刷新；由于物化视图刷新是非常耗资源的，为了减少对线上业务的影响，物化视图还支持使用资源组来限制后台刷新占用的计算资源。
物化视图主要的价值包括
通过物化视图可以简化数据分层建模，将以前通过外部调度工具完成的建模任务放到 StarRocks 里完成，简化数据技术栈。
通过物化视图可以做透明查询加速，目前 StarRocks 支持 aggregate、join、union 等大部分查询的自动改写；虽然是分区粒度的刷新，物化视图的改写也可以用在实时分析的场景，对于已经刷新的历史分区，自动利用物化视图加速，对于实时部分尚未刷新的分区，则采用物化视图来查询加速，然后将结果 Union 起来返回。
物化视图的查询加速、分层建模不仅能给与 StarRocks 的内部表，也可以在外部的 Catalog 上构建物化视图，数据在外部统一管理，确保 Single souce of truth，同时通过物化视图，按需的加工数据或加速查询。
从建模的视角，有了物化视图给 StarRocks 的用户带来了极大的便利。在物化视图之前，一般采用预建模的方式，数据工程师将各种数据表预先建模加工好，给数据分析师去使用；而现实中数据建模的常见矛盾在于，建模的过程难以跟上业务发展的速度，难以衡量数据建模的投入产出。很多时候早期数据的使用者倾向于不做建模，直接使用原始数据，最后遇到性能问题。有了物化视图之后，可以从预建模演变到后建模，分析师可以创建逻辑的 view 满足业务需求，如果遇到性能问题，再根据逻辑view 来构建物化视图加速；或者更进一步，不做任何提前的预建模，直接查询原始表，按需构建物化视图加速。
湖仓新范式
数据分析的演进趋势是湖仓一体
当前业界构建数据分析的技术栈，有两条典型的路线，一个是数仓路线，一个是数据湖的路线。
数据仓库的路线，数据先通过 ETL 统一写入到数仓进行管理，然后构建数据集市来满足 BI 分析的各种需求，优势是数据质量高、查询性能高、具备实时分析的能力、数据治理功能完善等；而数据湖的路线，通常是未经加工的数据先统一存储在数据湖，作为企业数据的 Single source of truth，然后按需的使用数据，构建数据应用，优势是通开放生态、扩展性强，性价比高。
那未来数据架构应该是建数据仓库还是建数据湖？用户之所以有现在的纠结，是因为数据仓库和数据湖各有优劣，如果能将优势兼具，用户也不必关注到底是湖还是仓。目前在业界，也在探索湖仓融合的路径，比如湖上性能不满足，采用湖上建仓的方案加速查询；再比如很多数据仓库产品，开始扩展查询外部数据湖的能力。但这些本质上都是湖仓组合的方案，我们认为发展的趋势是湖仓一体化。
Lakehouse: One Data，All Analytics
湖仓一体到底意味着什么？那就是一套架构，满足所有的分析需求，我们做了一个理念的抽象，Lakehouse 就是要实现 One Data，All Analytics 的业务价值。
湖仓架构下，数据要统一存储管理，一份数据作为 Single source of truth，避免导来导去，造成数据冗余，分析口径不一致等问题。存储层通常采用 S3/HDFS 作为数据存储底层，并采用开放数据湖，或者 私有的格式去管理数据。
有了统一的数据管理，要基于这份数据，满足所有的业务分析场景的诉求，包括 BI 报表、交互式分析、实时分析、ETL 数据加工等场景；这就要求必须要有一个足够强大的分析引擎，能同时满足这些场景的查询需求。
对于部分特别复杂的查询，部分的数据源数据组织未针对分析优化，在这样的情况下，直接分析不一定能满足查询延时的需求，这就要求 Lakehouse 具备通用的数据加工，数据查询加速的能力。 总结一下，要实现 One Data，All Analytics，需要有统一的数据存储，适应不同场景极速的查询引擎，以及按需数据加工/查询加速的能力。
基于 StarRocks 的湖仓新范式
如何采用 StarRocks 构建湖仓新范式？
用户可以将 StarRocks 当作一站式的 Lakehouse，数据统一导入进来，借助 StarRocks 存算分离的架构，实现低成本的数据存储，然后利用 StarRocks 查询引擎来服务全场景的数据分析应用。
如果用户的数据已经在开放在开放数据湖（Hive、Hudi、Iceberg、Paimon），可以通过 StarRocks 直接分析数据湖来加速交互式查询分析，也能获得极高的查询性能。
不管你的数据统一存储在 StarRocks 里还是开放数据湖里，当查询性能不足时，可以利用 StarRocks 的物化视图来加速查询性能；StarRocks 3.0 借助存算分离、湖仓分析、物化视图等关键特性，实现 OLAP 数仓 向 统一湖仓的升级，达到 One Data，All Analytics 的业务价值。
湖仓新范式正被广泛实践
StarRocks 3.0 从今年4月发布以来，已经有数十家企业在实践湖仓新范式，并取得非常好的业务效果。
芒果 TV 采用 StarRocks 存算分离作为统一的 Lakehouse，所有数据导入到 StarRocks 进行统一管理。相比原来 Hadoop 体系多系统组合的方案，架构更简单，同时查询性能提升10倍。
微信近实时的数据写入到 Iceberg，通过 StarRocks 直接分析 Iceberg 上的数据，实现近实时链路的统一；同时 Iceberg 的数据还用于其他的场景做加工处理。
携程数据统一存储在 Hive，采用 StarRocks 直接查询加速报表，对于实效性要求极高的，基于 Hive 建立物化视图查询加速；整体性能提升10倍。
在上面的3个案例里，用户分别基于 StarRocks、Iceberg、Hive 作为统一的数据存储，并以 StarRocks 作为统一的查询引擎，湖仓一体的实践不是一蹴而就的，很多企业当前已经有了大数据体系的建设，那么可以从业务层面 到 部门层面 到公司层面，逐步实践湖仓新范式，最终实现极速统一的数据分析。
未来规划
在未来一年里，StarRocks 还是会继续围绕云原生实时湖仓为重心，在云原生、实时分析、湖仓一体方面做更多的产品技术突破。
在云原生方面，主要增强弹性能力以及提升性能。在弹性能力上，增强 Multi-warehouse 能力建设，增强 time travel、schema 快速演进的能力，以及针对 FE 做存算分离，提升系统的扩展性；性能方面，则会重点优化冷读的性能，优化缓存策略，支持自动的缓存预热，提升主键模型的能力，并在存算分离架构下支持高频实时导入。
在实时链路建设上，实时分析最大的挑战就是链路太复杂，维护难度高，StarRocks 希望简化整个实时链路 Pipeline 的构建；StarRocks 在即将发布的3.2 版本已经支持了 Pipe 的功能，Pipe 可以从 S3 持续增量的导入增量文件，也可以持续增量的导出数据到 S3；后续 Pipe 也会统一支持 Kafka、关系型数据库，让数据的导入导出更加简单实时。数据实时导入之后，可以用于查询分析，如果需要加速，则可以利用实时的物化视图，实时物化视图，针对数据增量实时计算，维护物化视图的一致性。
在湖仓一体能力上，会增强 ETL Worklaod 的处理能力。目前 StarRocks 已经能很好的支持交互式分析的 Workload，再加上轻量级 ETL Workload 的支持，可以实现大部分情况下，一套系统就能解决问题。在数据的提取和写入上，主要是支持更多的开放表格式，文件格式，同时也会让 StarRocks 的私有文件格式适配到社区的生态，能通过 Spark 直接读写，提升效率；在数据处理方面，会继续增强算子落盘的能力，优化 group execution 的执行提升查询容错能力；在调度方面，完善 Task 调度框架，结合查询队列，查询自动重试等特性更好的支持 ETL Workload。
StarRocks 经过2年多的发展，已经成为了企业 OLAP 数据分析、湖仓分析的首选，StarRocks 社区的发展离不开社区所有用户、开发者，以及背后厂商的支持，感谢所有参与 StarRocks 的社区的同学，期待 StarRocks 新一年的进化。
本文由 mdnice 多平台发布