本文发表于： &{ new Date(1692115200000).toLocaleDateString() }

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

首要的挑战在于数据加工的复杂性。从数据的产生到最终产生价值的整个链路仍然十分复杂，涉及多个环节和技术方案，这导致了技术复杂度的增加，进而带来了人力投入的复杂性。这种复杂性使得终端用户难以实现“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 来抽象数据的流向过程，不再需要在多个系统中管理数据之间的依赖关系，以及复杂的数据质量问题
  • 资源隔离的问题，也通过内聚并垂直整合的方式得以大幅简化，不再需要申请额外的资源进行简单的计算
  • 除此之外，透明加速的能力，使得用户不再需要提前对数据进行建模，而是根据实际需求，根据业务的演进，对数据进行建模和加速，大幅节省了管理数据的人力成本
• 数据加工的性能、时效性、成本问题
• 用户不再需要在流系统和批处理系统之间进行艰难的选择，是选择稳定低成本的批处理系统，还是选择高成本但时效性好的流系统。物化视图所提供的不同刷新模式，将这个问题简化为一个参数选择的问题，通过调参来面向不同的场景

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

物化视图的应用场景

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 希望通过湖仓一体帮助用户进行架构升级的同时，让物化视图来简化用户使用数据的复杂度，提高数据的性价比，挖掘出更多的数据价值。

后续我们将推出针对物化视图的一系列文章，深入介绍物化视图的功能和使用场景，欢迎大家加入社区和订阅公众号获得第一手消息！