Analytics With No Compromise StarRocks 湖仓一体化 多表 MV 物化视图 大数据架构
当打造一款极速湖分析产品时，我们在想些什么 https://mp.weixin.qq.com/s/jZX0h_B_n9QcejSEbFwKsA
- Schema-on-Write 架构：通过严格的建模范式约束，来支撑 BI 场景下的查询负载，但在以存算一体为主流系统架构的历史背景下，数据量膨胀带给用户高昂维护成本，同时对异构数据缺乏维护能力。
- Scheme-on-Read 架构：以 HDFS 为统一存储层，并提供基础的文件 API 来与查询层进行交互。这种架构模式虽然一定程度上保证了 TCO 和文件格式开放性，但由于应用读时才能感知数据质量，也将数据治理问题带来的成本转嫁给了下游应用。
- 云上数据湖架构：云上对象存储逐步代替 HDFS，并逐步演化成：以对象存储作为统一离线存储， 以 Warehouse 作查询加速双层架构。虽然这种双层架构同时保障了冷数据的存储成本和热数据的查询性能，但伴随而来的是多轮跨系统 ETL，也就引入了 Pipeline 构建时的工程复杂度。
重新定义物化视图，你必须拥有的极速湖仓神器！ https://mp.weixin.qq.com/s/j88BDtOIy5A2VFirgK9vKg
当今企业在进行数据分析时，面临着多重问题和挑战，而数据加工作为其中不可或缺的一环显得尤为重要。
首要的挑战在于数据加工的复杂性。从数据的产生到最终产生价值的整个链路仍然十分复杂，涉及多个环节和技术方案，这导致了技术复杂度的增加，进而带来了人力投入的复杂性。这种复杂性使得终端用户难以实现“Make Data Accessible”的目标，并限制了对数据设施的进一步资源投入。
其次，数据加工还面临性能、时效性和成本等方面的挑战。用户期望高性能、实时数据平台，同时又要求低成本。然而，技术上存在矛盾，不可能同时满足所有需求。然而，随着技术的不断演进，这种矛盾可以得到更好的权衡，不同阶段将面临不同的挑战。
为了解决这些未被满足的需求，StarRocks 3.0 推出了湖仓一体的新架构，旨在更好地帮助用户管理大规模企业级数据。在湖仓一体架构中，物化视图起到关键作用，能够进一步降低数据处理的复杂度、提高查询性能和优化数据的时效性，使得用户在数据架构升级的同时，能够享受到使用体验的升级。
本文将围绕 StarRocks 物化视图对以下几点内容进行介绍：
- 为什么你需要 StarRocks 湖仓一体新范式
- StarRocks 物化视图基础能力介绍
- StarRocks 物化视图的三种常见应用场景
- StarRocks 物化视图的迭代演进
StarRocks 湖仓一体新范式
StarRocks 3.0 推出湖仓一体的新范式，旨在进一步解决数据工程中的链路、性能复杂性问题。湖仓一体的内涵在于更好地结合了湖和仓的优势：
- 数仓的优势在于数据质量、查询性能、实时分析、数据治理；旨在通过精细化的建模和加工，提供高质量的数据
-
数据湖的优势在于生态开放、灵活统一、可扩展性、高性价比；旨在通过兼容并包的数据存储，容纳更多的数据
在这个内涵之上，湖仓一体有很多外延的体现：
- 湖和仓的统一存储和查询：明细数据、归档数据、半结构化数据存储在湖中，精细化的加工数据存储在仓中，用统一的引擎进行查询和分析
- 降低数据加工的复杂度：更多的数据加工负载能够在湖仓中运行，不再需要额外的 Hive、Spark 加工系统
- 更低成本的 Data Pipeline：数据链路能够更好地端到端打通，从数据的生产、收集、处理、价值变现，能够在湖仓的流水线运行，成本降低、时效性提高
- 更好地权衡性能、成本、数据新鲜度：融合多种数据处理技术，实时查询、增量计算、批处理得以统一，使得用户不再需要从多个割裂的系统进行选择，而是在同一个加工框架内选择参数
具体到 MV （物化视图），能够在其中发挥几方面的价值：
- MV 实现数据建模：通过物化视图进行声明式的数据建模，不再需要为了建模维护负载的 ETL 过程，从而解决湖仓一体的数据质量、查询性能问题
- MV 实现透明加速：通过物化视图实现按需的透明加速，不再需要提前对数据进行治理和建模，减少数据准备的时间和成本，从而优化湖仓一体的灵活性问题
-
MV 实现增量计算：通过物化视图实现增量流水线，提高数据的时效性、降低端到端延迟，解决湖仓一体的时效性问题
接下来，我们将详细介绍物化视图的基础能力以及它能够解决的问题。随后，我们会结合具体的应用场景，深入探讨物化视图所带来的价值和作用。
物化视图的基本能力介绍
物化视图的基本功能可以从一个样例来理解：
- Materialized （物化）：顾名思义，物化视图会将计算结果进行物化，存储到 SR 的表中，其存储结构和普通的表无异
- Partition by：对物化视图分区，例如按天分区后，可以按照天的粒度进行视图的刷新、维护、TTL（Time to Live，生存时间）；除此之外，这个分区模式也可以和 Hive/Iceberg 等外表的分区建立映射， 使其能够自动订阅外表的更新
- Refresh：所谓 Refresh 即刷新物化视图，计算并物化查询结果。当前物化视图支持自动刷新、定时刷新、手动刷新、部分场景的增量刷新等多种方式，满足不同业务场景的需求。例如用户可以使用导入数据自动触发刷新，可以选择每小时定时刷新，以及使用外部调度系统手动刷新等方式
- Resource Group：物化视图实际使用中的一个常见痛点在于如何做资源隔离，即前端的查询负载，如何与物化视图的维护隔离开来。在 StarRocks 中当前主要通过 Resource Group（资源组）的技术实现弹性的资源隔离，两种工作负载能够同时运行在一个集群中，且根据需求进行弹性地调度，使得物化视图不会影响到前端查询性能
- 查询语句：物化视图支持 aggregation、join、window 等查询语句，能够对多种场景进行计算结果的物化。其中能够支持多种数据源，包括 JDBC 外表所访问的 MySQL、PostgreSQL 等系统，以及 Lake 外表所访问的 Hive、Iceberg 等，以及 StarRocks 自身所存储的数据
表面上物化视图很简单，即能够根据用户指定的刷新模式，对查询结果进行预计算，避免后续重复计算的开销。这里体现的能力主要在于调度能力、预计算能力、增量计算能力。
在简洁的语法背后，物化视图具备查询改写的能力，即优化器可以自动匹配出能够被加速的 SQL 查询，将其改成为已经预计算的结果，从而大幅降低计算开销。这个能力释放了一个新的可能性，即用户在不改写 SQL 的前提下，能够对性能进行调优，使得能够灵活地在 Cost & Performance 之间进行权衡。
结合这样几个基础的原子能力，物化视图能够很好地回应最开始我们讨论的数据工程的两个难题，即：
- 数据加工的复杂性：
- 物化视图通过声明式的语法对数据加工的过程进行建模，用户只需要理解计算结果，不需要描述复杂的计算过程
- 通过 Refresh 来抽象数据的流向过程，不再需要在多个系统中管理数据之间的依赖关系，以及复杂的数据质量问题
- 资源隔离的问题，也通过内聚并垂直整合的方式得以大幅简化，不再需要申请额外的资源进行简单的计算
- 除此之外，透明加速的能力，使得用户不再需要提前对数据进行建模，而是根据实际需求，根据业务的演进，对数据进行建模和加速，大幅节省了管理数据的人力成本
- 数据加工的性能、时效性、成本问题
-
用户不再需要在流系统和批处理系统之间进行艰难的选择，是选择稳定低成本的批处理系统，还是选择高成本但时效性好的流系统。物化视图所提供的不同刷新模式，将这个问题简化为一个参数选择的问题，通过调参来面向不同的场景
接下来我们会结合几个具体的场景，来介绍物化视图能够发挥的价值。
物化视图的应用场景
01
场景一：数据建模
所谓数据建模，即按照合理的方式对数据进行清洗、分层、聚合、关联，得到易于使用的数据结果这一过程。为何需要进行数据建模？因为原始数据往往会存在质量问题，难以直接用于分析；原始数据过于复杂， 包含太多业务人员并不关心的指标，增加理解的复杂性；原始数据未经过聚合，使得查询性能较差，难以满足性能需求，或者耗费太多计算资源。
而现实中数据建模的常见矛盾在于，建模的过程难以跟上业务发展的速度，难以衡量数据建模的投入产出。建模的手段简单，但需要业务专家具备足够的领域知识，对其进行整理和加工，这是个复杂的过程；而业务早期往往缺乏足够的资源投入到这样的数据治理过程，且难以看到数据建模带来的价值，并且很有可能业务模型变化较快，建模方法本身也需要迭代和演进。因此，很多时候早期数据的使用者倾向于不做建模，直接使用原始数据，那么势必会导致质量问题、性能问题；而到了需要建模的时候，又遇到数据使用方式已经成型，难以重构的问题。
而通过物化视图做这件事能够很好地解决这样的矛盾：
- 简化了架构复杂度：不需要在外部维护很多的数据组件去做加工。相反，如果维护了这些数据组件，不仅要使用物理资源去部署运行，还需要额外部署调度、监控的组件，这样的架构是比较复杂的
- 简化了使用复杂度：仅需要具备基础的 SQL 知识即可，那么这一过程不再需要专业的数据工程师来实施，而是普通的数据分析师即可完成，解放了人力瓶颈
-
简化了维护复杂度：物化视图维护数据之间的血缘关系，自动管理了数据之间的依赖，不再需要一整个数据平台来做这件事
我们从分层建模和分区建模这两个基础的场景为例，介绍如何使用物化视图进行数据建模。
分层建模
在许多用户的实际业务场景中，数据源会包含多种形式，包括实时明细数据、维度数据、数据湖归档数据，而业务端则需要多样的分析方式，例如实时大屏、近实时 BI 查询、分析师 Adhoc 查询、定时报表等。不同的场景的诉求不同，有的需要灵活性，有的需要性能，有的需要低成本。
通过单一的解决方案显然无法满足这样灵活的需求，而 StarRocks 能够协同地使用 View & Materialized View 提供解决方案。其中 View 是逻辑视图，每次查询 View 时都会重新解析并执行 View 的定义；而 Materialized View 则会将计算结果物化下来，避免重复执行的开销。View 适合表达业务语义，简化 SQL 复杂度，但无法降低执行开销；Materialized View 则能够通过预计算来优化性能，适合用来简化 ETL Pipeline。
通过 StarRocks 的 View （视图） 以及 Materialized View，则可以较好地地解决这个问题：
- View 面向终端用户，提供业务语义：由于 View 本身不做预计算，可以灵活地修改，且能够提供简洁的业务语义
- View 面向实时场景：通过 View 关联起实时数据和维度数据，能够保证用户查询 View 得到最及时的结果
- MV 面向近实时场景的加速：如果计算过程非常复杂， 那么需要对其中一部分过程进行预计算，从而加速终端的查询性能
- MV 面向数据建模：数据建模不仅需要逻辑上对数据进行加工，也需要物理上处理数据
-
最终业务方可以根据时效性和性能的需求，灵活的选择 View 和 Materialized View 对数据进行分层建模
除此之外，StarRocks 提供了面向业务场景的灵活变更能力，不仅顶层的 MV/View 可以修改，底层的 MV/View 也可以根据业务需要进行调整。相对于传统的 ETL Pipeline 的牵一发动全身，View/MV 可以用非常简单的 SQL 语法完成这样的变更。
分区建模
除了分层之外，数据建模的过程往往需要根据业务语义对数据进行关联，根据时效性需求对数据设置 TTL，这一过程即涉及到分区建模。
数据之间的不同关联方式，形成星形模型、雪花模型等多种建模方式，这其中的基础概念是事实表和维度表，有的业务有多个巨大的事实表，而有的业务则有复杂的维度表和关联关系。StarRocks 的物化视图支持事实表的分区关联，即事实表进行分区，而物化视图的 Join 结果按照同样的方式进行分区。
基于这样的分区关联，可以支持多种业务场景：
- 事实表更新：事实表做细粒度的分区，比如天级或者小时级分区，在事实表刷新之后，物化视图的相应分区可以自动刷新
- 维度表更新：当维度表更新之后，往往需要触发所有关联结果的刷新，这个刷新代价通常较大，用户也可以选择忽略某些维度表的刷新，或者选择只更新最近一段时间的计算结果
- 外表自动刷新：Hive/Iceberg 等系统往往以分区的粒度进行数据变更，而 StarRocks 物化视图则可以订阅外表的数据变更，当某个分区变更后，触发视图的刷新
- TTL：对物化视图进行分区之后，可以设置 TTL，实现只保留最近一段时间的计算结果，对应的业务场景，往往是具备较强的时效性，例如只需要查询最近一周的数据，那么就没必要保留所有的历史数据
❗️小结：
在上述两种常见场景的基础上，StarRocks 物化视图提供了众多能力，帮助用户进行数据建模：
- 多数据源：物化视图可以基于内表、数据湖外表和 JDBC 外表等创建物化视图，比如可以对 MySQL、PostgreSQL 创建物化视图，也可以对 Hive/Iceberg 等数据源创建物化视图，并且物化视图能够自动管理数据依赖关系
- 分区映射：对内表和外表的分区关系进行维护，能实现分区粒度的视图刷新
- 自动刷新：物化视图可以支持在数据源变更时，自动刷新物化视图，不再需要用户手动管理
- 多层建模：支持创建多层物化视图，表达 ODS、DWD、DWS、ADS 的分层理念；支持结合使用 View & Materialized View，具备足够的灵活性
- 任务调度：支持多种调度模式，像是触发式调度、DAG 式调度、定时调度等等，表达不同的业务语义
02
场景二：透明加速
前面讲到数据建模的一个矛盾在于，数据建模难以满足业务的灵活性，且业务发展的不同时期，对建模的要求并不一样。业务早期数据量小、不确定性高，往往选择粗放地使用数据；发展后期对性能要求高、数据规模大，产生了数据建模的需求，但相关的平台和系统已经成型，导致重构的成本高。
而 StarRocks 选择用物化视图的透明加速能力，来解决这样的矛盾：
- 透明加速：用户不需要改写 SQL，优化器能够自动改写，选择合适的物化视图进行加速
- 按需创建：用户不需要提前规划数据的使用场景和查询 SQL，而是在发现性能问题之后，再对其创建物化视图做性能优化
- 建模后置：创建物化视图本质上仍然是通过预计算、数据建模来加速数据查询，但将建模的过程后置之后，能够满足不同时期的不同业务需求，不会造成业务资源的浪费
举例来说， 创建右边所示的一个物化视图，能够透明加速左边三种不同的查询模式：
- 物化视图：按照
lo_orderdate, c_city进行分组聚合，计算count - 示例 1 --聚合上卷：需要按照
lo_orderdate进行聚合，因此可以在物化视图的基础上，进一步上卷计算；由于物化视图的聚合计算已经将数据量减少了几个数量级，因此二次上卷的计算非常轻量 - 示例 2 --上卷过滤：筛选部分时段的数据，按照
c_city维度进行聚合，此时仍然可以在物化视图的基础上进行筛选并二次上卷 -
示例 3 --过滤：这个查询仅需筛选部分时段的数据进行聚合，由于物化视图已经按照
lo_orderdate进行了分组，因此可以直接筛选出结果
需要注意到，这里的各种过滤、上卷操作，完全是 StarRocks 优化器自动完成，不需要用户进行复杂的 SQL 改写，不需要用户理解 SQL 的复杂语义。除了上述的聚合改写能力之后，StarRocks 还支持多种改写能力，例如针对宽表 Join 的自动改写，针对时序数据 Union 改写。这一能力在后续的文章会做详细介绍。
基于 StarRocks 物化视图的透明加速能力，用户完全可以将数据建模的问题变成一个性能优化问题，当业务场景出现性能需求时，通过分析业务场景、分析查询需求，创建合适的物化视图进行优化。故此，数据建模这一开放性问题变成一个封闭问题，更容易衡量数据建模的价值，消除不必要的过度规划和设计。
03
场景三：湖仓一体
最后，我们要来介绍 StarRocks 如何通过物化视图，将湖仓更好地做到一体化：
- 统一存储和查询：明细数据、归档数据、半结构化数据存储在湖中，而精细化的加工数据存储在仓中。使用统一的引擎进行查询和分析，同时通过物化视图进行湖和仓的连接
- 通过物化视图进行灵活的数据建模，优化数据湖的数据质量、查询性能问题
- 通过物化视图实现按需的透明加速，不再需要提前对数据进行治理和建模，减少数据准备的时间和成本
StarRocks 物化视图的迭代演进
StarRocks 在 2.4 版本发布物化视图功能，迄今已经过多个版本的迭代：
- V2.4：发布基础能力，支持分区关联
- V2.5：支持查询改写，支持 JDBC/Hive 等多种数据源，支持 CTE/Window/Union 等 SQL 语句
- V3.0：支持分层建模场景，支持 Hive 的订阅刷新，增强易用性和观测性
在后续版本中，物化视图将围绕几个方向持续演进：
- 易用性：持续优化易用性，给用户提供一个开箱即用的方案，给具体场景提供一站式的解决方案
- 查询改写能力：支持更多的查询改写场景，支持自动推荐的能力
- 数据湖对接：支持 Iceberg/Hudi 等数据源的自动刷新，实现更实时的刷新
- 增量计算能力：支持更多场景的增量计算，进一步提高实时性
总结
StarRocks 希望通过湖仓一体帮助用户进行架构升级的同时，让物化视图来简化用户使用数据的复杂度，提高数据的性价比，挖掘出更多的数据价值。
数据库 - StarRocks 社区：从初生到两周年的进化之路 - 个人文章 - SegmentFault 思否 https://segmentfault.com/a/1190000044237611
2021 年 9 月 8 日，StarRocks 开源社区诞生。从第一天开始，我们怀揣着“打造世界一流的数据分析产品”的梦想，踏上了星辰大海的征途。
两年间，StarRocks 在 GitHub 上收获了 5.4K Stars，产品共迭代发布了 90 余个版本，288 家市值超过 10 亿美元的头部用户在生产环境中上线运行。“不止步于极速”，StarRocks 更是在短短一年内完成了从全场景 OLAP 分析进化到云原生湖仓分析的进化。
StarRocks 突飞猛进的发展都要得力于社区用户的使用反馈和开发者们不断地帮 StarRocks 添砖加瓦，使其生态体系更加完善。在过去一年内，StarRocks 发布了 v2.5、v3.0、v3.1 三个重大的里程碑版本，其中存算分离、湖仓分析、物化视图等重量级特性， 为极速统一湖仓分析新范式的落地奠定了坚实基础。
进化，永不止步
从诞生之初，StarRocks 就不断在探索关于“极速统一”之道。全面向量化引擎、CBO 查询优化器、实时更新数据模型、Pipeline 执行引擎相继发布，将 OLAP 分析性能提升到了新的高度，也引领了当前大数据分析的发展趋势。
随着各项重要功能历经 2 年、近 300 家各行业头部用户在生产环境中的打磨与完善，StarRocks 完成从 OLAP 到云原生湖仓的快速进化，通过湖仓一体让企业能基于一份数据，满足 BI 报表、多维分析、Ad-hoc 查询、实时分析等不同场景的数据分析需求， StarRocks 往 "One data，all analytics" 的目标不断前行。
湖仓一体化极速查询引擎
Presto/Trino/Impala 一直以来都是行业最好的数据湖（Hive/Hudi/Iceberg/Deltalake 等）查询引擎。但是其性能无法和将数据导入到 ClickHouse 或是 StarRocks 此类极速 OLAP 数据库/数仓相媲美，用户通常会组合使用，运维和使用都会比较复杂，StarRocks 期望彻底改变这种“组合”模式，推出更一体化的方案。StarRocks 的湖仓一体化极速查询引擎的理念是可以同时极速查询数据湖数据和 StarRocks 本地数据。从 StarRocks 2.0 到 StarRocks 3.0 版本， 经过一年半的时间和 7 个大版本的持续打磨，StarRocks 终于发布了业内第一个成熟完善的湖仓一体化极速查询引擎，让数据湖查询和本地数据查询基本持平，并且数据湖查询达到了 Presto/Trino/Impala 等系统的 3-6 倍以上的性能水平。
基于物化视图（MV）的轻量化数据建模
当前数据工程师进行数据建模时，需要通过预先构建大量 ETL 任务来生成 ODS/DWD/DWS/ADS 数据表。这种数据建模方法比较重，周期长，而且会存在很多无用 ETL。StarRocks 基于 MV 的轻量化数据建模方法提供了全新模式，将逻辑建模与物理建模分离：
- 无需预先大量 ETL，只需要用 view 来建立各层数据模型，快速交付 view 给业务查询使用
- 在业务查询使用中，随需创建多表/单表 MV 实现透明查询加速
业内 Clickhouse、Doris、Snowflake 等打造了比较好的单表 MV，缺乏完善的多表 MV 支持，不足以支持轻量级数据建模方法的落地。StarRocks 在 2.4 版本发布了多表 MV，之后经过 12 个月的时间和三个版本—— StarRocks 2.5、 StarRocks 3.0 和 StarRocks 3.1 版本的打磨，已经成为业内第一个可以同时支持复杂查询、数据湖外表和异步构建的多表 MV，可以很好的支持轻量化建模方法落地，成为用户针对数据建模和 ETL 进行降本增效的大杀器。
此外，物化视图也成为 StarRocks 3.0 的核心功能，物化视图通过声明式的方式降低了传统 ETL 中 Transform 的复杂度，通过外表物化视图可以无缝连接湖仓，通过查询改写可以透明加速，通过 spill 和分区增量刷新可以进行稳定的物化视图构建和细粒度的物化视图刷新策略。帮助用户的湖仓建模更容易。
极简存算分离架构
Snowflake 打造出了全球最好的存算分离架构，让很多云服务用户受益匪浅。但是其架构组件复杂，无法简单部署到用户的各类私有化环境。StarRocks 在存算分离上的创新初心是打破这种限制，让任何社区用户都可以将存算分离架构轻松部署到各类私有环境，获取更多降本增效的收益。StarRocks 3.0 版本发布的全新极简存算分离架构，基于原创的云原生操作系统 StarOS，整个新架构只有 FE 和 CN 两个模块，无需任何外部组件依赖，部署运维和非存算分离版本一样简单，性能一样出色。用户可以随时随地部署使用 StarRocks 存算分离架构，实现降本增效。
更加引人注目的是，3.0 版本的存算分离架构不仅学习了 Snowflake 的优点，通过内置的 StarOS，StarRocks 实现了完全无需外部组件的部署，大大简化了用户的操作。让用户在各种云上云下的环境都可以通过存算分离架构来接口存储介质，提升更好的弹性能力，实现多 AZ 甚至多云的高可用能力。大量用户的实践也证明了 StarRocks 存算分离架构已经走向成熟，将逐渐变成 StarRocks 的默认架构。
产品能力进化时间线
一文了解 StarRocks 物化视图、湖仓分析和存算分离：
重新定义物化视图，你必须拥有的极速湖仓神器！
当打造一款极速湖分析产品时，我们在想些什么
兼顾降本与增效，我们对存算分离的设计与思考
进化，不止代码
创建一个健康的开源项目需要整个社区的共同协作，在开源生态系统中，每个参与者都有机会塑造和改进软件，用户可以识别所需功能并贡献代码或用户案例。只有当整个社区和相关社区积极参与时，一个开源项目才能成功发展为一个繁荣的生态系统，这包括代码贡献者、用户、文档编写者、软件和平台供应商以及集成者等各方。
StarRocks 社区始终相信开放协作的力量，信奉 “Code is power. Community is strength. And Openness is everything. ”。代码是改变世界的力量，社区给了我们无限的可能，而这一切都只有通过开放才能实现。StarRocks 社区的价值观具体体现在：
- 对极速统一的云原生湖仓一体技术的持续探索：用户能更快、更低成本且更简单地在海量数据中挖掘数据的价值，助力业务成功。
- 与用户共同成长，彼此成就：建立产品文档、新手教程、产品特性解析、FAQ 、最佳实践和丰富的用户案例知识库，并且通过 StarRocks 城市行、开源集市、线上线下会议和微信/Slack/GitHub 等渠道与用户零距离交流。
- 开放生态，无缝衔接上下游组件：2022 年底，StarRocks 项目正式捐献给 Linux 基金会，更加中立、开放；并与开放的数据生态产品，如 Apache Flink、Apache SeaTunnel、Apache Paimon、Apache Hudi、Apache Icerberg 等社区共建现代数据栈。
蓬勃发展的用户社区
StarRocks 发展至今已有超过 288 家估值超过 10 亿美元的行业头部用户。这些用户遍布各行业，许多用户也在使用 StarRocks 后积极向社区分享了使用场景和实践经验。以下是一些具有代表性的用户案例：
互联网：芒果 TV、 滴滴、万物新生、 贝壳、同程旅行、得物、小红书、携程、美团餐饮 SaaS、360、微信
物流：顺丰、跨越速运、京东物流、达达
金融：中信建投、中欧财富 、众安保险、中原银行、信也科技
游戏：波克城市、37 手游、腾讯游戏、游族网络
汽车： 理想汽车、 蔚来汽车、、
制造/零售：大润发、华润万家、TCL、华米科技、百草味
完整的用户案例合集请见 StarRocks 公众号“StarRocks 用户案例合集” 和 StarRocks B 站！
深度参与社区共建的伙伴
StarRocks 各个代码仓库下已有超过 300 名贡献者，其中有许多人贡献了文档、函数、connector、周边生态等功能。我们由衷感谢每一位为 StarRocks 贡献力量的朋友们。特别要感谢以下深度参与社区的伙伴们，他们为 StarRocks 提供了备受用户欢迎的重要特性。
最后，感谢每一位为 StarRocks 添砖加瓦的小伙伴们：https://github.com/StarRocks/starrocks/graphs/contributors
总结与展望
过去的一年对于 StarRocks 来说是至关重要的一年，我们在产品、用户规模和社区治理模式方面不断进化，取得了飞跃式的成长。
- 产品：从原本的 OLAP 分析引擎到现在的湖仓一体，再从存算一体到存算分离，StarRocks 已发展成为极速统一云原生湖仓分析的新范式
- 用户规模：经过短短一年的时间，我们从千人规模的社区成长为超过万人的社区，拥有来自世界各地的众多知名用户积极参与并支持 StarRocks
- 社区治理：StarRocks 的社区治理也越来越开放，更多开发者能通过不同的兴趣小组（SIG）参与研发工作 ，专家们能加入技术指导委员会（TSC, Technical Steering Committee）参与 StarRocks Roadmap 的制定和培养社区优秀人才
未来， StarRocks 社区也将保持着合作、开放、共赢的信念，与用户们一同探索新一代的云原生湖仓，共同打造极速统一湖仓分析的新范式！让我们期待更加精彩的下一周年！
StarRocks | A High-Performance Analytical Database https://www.starrocks.io/
Extremely fast query performance in all scenarios
Whether you're working with a single table or multiple, you'll experience at least 300% better performance on StarRocks compared to other popular solutions.
Real-time analytics: guaranteed data freshness
From streaming data to data capture, with a rich set of connectors, you can ingest data into StarRocks in real-time for the freshest insights.
Analytics with flexibility: unleash the full potential of your data
A query engine that adapts to your use cases. Without moving your data or rewriting SQL, StarRocks provides the flexibility to scale your analytics on demand with ease.
