当今企业在进行数据分析时，面临着多重问题和挑战，而数据加工作为其中不可或缺的一环显得尤为重要。

首要的挑战在于数据加工的复杂性。从数据的产生到最终产生价值的整个链路仍然十分复杂，涉及多个环节和技术方案，这导致了技术复杂度的增加，进而带来了人力投入的复杂性。这种复杂性使得终端用户难以实现“Make Data Accessible”的目标，并限制了对数据设施的进一步资源投入。

其次，数据加工还面临性能、时效性和成本等方面的挑战。用户期望高性能、实时数据平台，同时又要求低成本。然而，技术上存在矛盾，不可能同时满足所有需求。然而，随着技术的不断演进，这种矛盾可以得到更好的权衡，不同阶段将面临不同的挑战。

为了解决这些未被满足的需求，StarRocks 3.0 推出了湖仓一体的新架构，旨在更好地帮助用户管理大规模企业级数据。在湖仓一体架构中，物化视图起到关键作用，能够进一步降低数据处理的复杂度、提高查询性能和优化数据的时效性，使得用户在数据架构升级的同时，能够享受到使用体验的升级。

本文将围绕 StarRocks 物化视图对以下几点内容进行介绍：

• 为什么你需要 StarRocks 湖仓一体新范式
• StarRocks 物化视图基础能力介绍
• StarRocks 物化视图的三种常见应用场景
• StarRocks 物化视图的迭代演进

一、StarRocks 湖仓一体新范式

StarRocks 3.0 推出湖仓一体的新范式，旨在进一步解决数据工程中的链路、性能复杂性问题。湖仓一体的内涵在于更好地结合了湖和仓的优势：

• 数仓的优势在于数据质量、查询性能、实时分析、数据治理；旨在通过精细化的建模和加工，提供高质量的数据
• 数据湖的优势在于生态开放、灵活统一、可扩展性、高性价比；旨在通过兼容并包的数据存储，容纳更多的数据

在这个内涵之上，湖仓一体有很多外延的体现：

• 湖和仓的统一存储和查询： 明细数据、归档数据、半结构化数据存储在湖中，精细化的加工数据存储在仓中，用统一的引擎进行查询和分析
• 降低数据加工的复杂度： 更多的数据加工负载能够在湖仓中运行，不再需要额外的 Hive、Spark 加工系统
• 更低成本的 Data Pipeline： 数据链路能够更好地端到端打通，从数据的生产、收集、处理、价值变现，能够在湖仓的流水线运行，成本降低、时效性提高
• 更好地权衡性能、成本、数据新鲜度： 融合多种数据处理技术，实时查询、增量计算、批处理得以统一，使得用户不再需要从多个割裂的系统进行选择，而是在同一个加工框架内选择参数

具体到 MV （物化视图），能够在其中发挥几方面的价值：

1. MV 实现数据建模： 通过物化视图进行声明式的数据建模，不再需要为了建模维护负载的 ETL 过程，从而解决湖仓一体的数据质量、查询性能问题
2. MV 实现透明加速： 通过物化视图实现按需的透明加速，不再需要提前对数据进行治理和建模，减少数据准备的时间和成本，从而优化湖仓一体的灵活性问题
3. 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 来抽象数据的流向过程，不再需要在多个系统中管理数据之间的依赖关系，以及复杂的数据质量问题
  • 资源隔离的问题，也通过内聚并垂直整合的方式得以大幅简化，不再需要申请额外的资源进行简单的计算
  • 除此之外，透明加速的能力，使得用户不再需要提前对数据进行建模，而是根据实际需求，根据业务的演进，对数据进行建模和加速，大幅节省了管理数据的人力成本
• 数据加工的性能、时效性、成本问题
  • 用户不再需要在流系统和批处理系统之间进行艰难的选择，是选择稳定低成本的批处理系统，还是选择高成本但时效性好的流系统。物化视图所提供的不同刷新模式，将这个问题简化为一个参数选择的问题，通过调参来面向不同的场景

接下来我们会结合几个具体的场景，来介绍物化视图能够发挥的价值。

三、物化视图的应用场景

场景一：数据建模

所谓数据建模，即按照合理的方式对数据进行清洗、分层、聚合、关联，得到易于使用的数据结果这一过程。为何需要进行数据建模？因为原始数据往往会存在质量问题，难以直接用于分析；原始数据过于复杂， 包含太多业务人员并不关心的指标，增加理解的复杂性；原始数据未经过聚合，使得查询性能较差，难以满足性能需求，或者耗费太多计算资源。

而现实中数据建模的常见矛盾在于，建模的过程难以跟上业务发展的速度，难以衡量数据建模的投入产出。 建模的手段简单，但需要业务专家具备足够的领域知识，对其进行整理和加工，这是个复杂的过程；而业务早期往往缺乏足够的资源投入到这样的数据治理过程，且难以看到数据建模带来的价值，并且很有可能业务模型变化较快，建模方法本身也需要迭代和演进。因此，很多时候早期数据的使用者倾向于不做建模，直接使用原始数据，那么势必会导致质量问题、性能问题；而到了需要建模的时候，又遇到数据使用方式已经成型，难以重构的问题。

而通过物化视图做这件事能够很好地解决这样的矛盾：

• 简化了架构复杂度：不需要在外部维护很多的数据组件去做加工。 相反，如果维护了这些数据组件，不仅要使用物理资源去部署运行，还需要额外部署调度、监控的组件，这样的架构是比较复杂的
• 简化了使用复杂度：仅需要具备基础的 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 式调度、定时调度等等，表达不同的业务语义

场景二：透明加速

前面讲到数据建模的一个矛盾在于，数据建模难以满足业务的灵活性，且业务发展的不同时期，对建模的要求并不一样。业务早期数据量小、不确定性高，往往选择粗放地使用数据；发展后期对性能要求高、数据规模大，产生了数据建模的需求，但相关的平台和系统已经成型，导致重构的成本高。

而 StarRocks 选择用物化视图的透明加速能力，来解决这样的矛盾：

• 透明加速： 用户不需要改写 SQL，优化器能够自动改写，选择合适的物化视图进行加速
• 按需创建： 用户不需要提前规划数据的使用场景和查询 SQL，而是在发现性能问题之后，再对其创建物化视图做性能优化
• 建模后置： 创建物化视图本质上仍然是通过预计算、数据建模来加速数据查询，但将建模的过程后置之后，能够满足不同时期的不同业务需求，不会造成业务资源的浪费

举例来说， 创建右边所示的一个物化视图，能够透明加速左边三种不同的查询模式：

• 物化视图：按照 lo_orderdate, c_city 进行分组聚合，计算 count
• 示例 1 ——聚合上卷：需要按照 lo_orderdate 进行聚合，因此可以在物化视图的基础上，进一步上卷计算；由于物化视图的聚合计算已经将数据量减少了几个数量级，因此二次上卷的计算非常轻量
• 示例 2 ——上卷过滤：筛选部分时段的数据，按照 c_city 维度进行聚合，此时仍然可以在物化视图的基础上进行筛选并二次上卷
• 示例 3 ——过滤：这个查询仅需筛选部分时段的数据进行聚合，由于物化视图已经按照 lo_orderdate 进行了分组，因此可以直接筛选出结果

需要注意到，这里的各种过滤、上卷操作，完全是 StarRocks 优化器自动完成，不需要用户进行复杂的 SQL 改写，不需要用户理解 SQL 的复杂语义。除了上述的聚合改写能力之后，StarRocks 还支持多种改写能力，例如针对宽表 Join 的自动改写，针对时序数据 Union 改写。 这一能力在后续的文章会做详细介绍。

基于 StarRocks 物化视图的透明加速能力，用户完全可以将数据建模的问题变成一个性能优化问题，当业务场景出现性能需求时，通过分析业务场景、分析查询需求，创建合适的物化视图进行优化。故此，数据建模这一开放性问题变成一个封闭问题，更容易衡量数据建模的价值，消除不必要的过度规划和设计。

场景三：湖仓一体

最后，我们要来介绍 StarRocks 如何通过物化视图，将湖仓更好地做到一体化：

• 统一存储和查询：明细数据、归档数据、半结构化数据存储在湖中，而精细化的加工数据存储在仓中。使用统一的引擎进行查询和分析，同时通过物化视图进行湖和仓的连接
• 通过物化视图进行灵活地数据建模，优化数据湖的数据质量、查询性能问题
• 通过物化视图实现按需的透明加速，不再需要提前对数据进行治理和建模，减少数据准备的时间和成本

四、StarRocks 物化视图的迭代演进

StarRocks 在 2.4 版本发布物化视图功能，迄今已经过多个版本的迭代：

• V2.4：发布基础能力，支持分区关联
• V2.5：支持查询改写，支持 JDBC/Hive 等多种数据源，支持 CTE/Window/Union 等 SQL 语句
• V3.0：支持分层建模场景，支持 Hive 的订阅刷新，增强易用性和观测性

在后续版本中，物化视图将围绕几个方向持续演进：

• 易用性：持续优化易用性，给用户提供一个开箱即用的方案，给具体场景提供一站式的解决方案
• 查询改写能力：支持更多的查询改写场景，支持自动推荐的能力
• 数据湖对接：支持 Iceberg/Hudi 等数据源的自动刷新，实现更实时的刷新
• 增量计算能力：支持更多场景的增量计算，进一步提高实时性

总结

StarRocks 希望通过湖仓一体帮助用户进行架构升级的同时，让物化视图来简化用户使用数据的复杂度，提高数据的性价比，挖掘出更多的数据价值。
后续我们将推出针对物化视图的一系列文章，深入介绍物化视图的功能和使用场景，欢迎大家加入社区和订阅公众号获得第一手消息！

StarRocks Feature Group-MV：

对 StarRocks 物化视图功能感兴趣的小伙伴们欢迎加入我们的 “StarRocks 物化视图用户小组” 。在这里你可以和同样对物化视图感兴趣的用户们和核心开发者们沟通无阻！
下方扫码添加小助手，回复关键字 “物化视图” 即可加入，从此告别复杂的数据处理！👇

https://wx.focussend.com/weComLink/mobileQrCodeLink/33412/9c312