共计 6737 个字符，预计需要花费 17 分钟才能阅读完成。
当今企业在进行数据分析时，面临着多重问题和挑战，而数据加工作为其中不可或缺的一环显得尤为重要。
首要的挑战在于数据加工的复杂性。从数据的产生到最终产生价值的整个链路依然十分复杂，波及多个环节和技术计划，这导致了技术复杂度的减少，进而带来了人力投入的复杂性。这种复杂性使得终端用户难以实现“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 来形象数据的流向过程，不再须要在多个零碎中治理数据之间的依赖关系，以及简单的数据品质问题
- 资源隔离的问题，也通过内聚并垂直整合的形式得以大幅简化，不再须要申请额定的资源进行简略的计算
- 除此之外，通明减速的能力，使得用户不再须要提前对数据进行建模，而是依据理论需要，依据业务的演进，对数据进行建模和减速，大幅节俭了治理数据的人力老本
数据加工的性能、时效性、老本问题
- 用户不再须要在流零碎和批处理零碎之间进行艰巨的抉择 ，是抉择稳固低成本的批处理零碎，还是抉择高老本但时效性好的流零碎。 物化视图所提供的不同刷新模式，将这个问题简化为一个参数抉择的问题，通过调参来面向不同的场景
接下来咱们会联合几个具体的场景，来介绍物化视图可能施展的价值。
三、物化视图的利用场景
场景一：数据建模
所谓数据建模，即依照正当的形式对数据进行荡涤、分层、聚合、关联，失去易于应用的数据后果这一过程。为何须要进行数据建模？因为原始数据往往会存在品质问题，难以间接用于剖析；原始数据过于简单，蕴含太多业务人员并不关怀的指标，减少了解的复杂性；原始数据未通过聚合，使得查问性能较差，难以满足性能需求，或者消耗太多计算资源。
而事实中数据建模的常见矛盾在于，建模的过程难以跟上业务倒退的速度，难以掂量数据建模的投入产出。 建模的伎俩简略，但须要业务专家具备足够的畛域常识，对其进行整顿和加工，这是个简单的过程；而业务晚期往往不足足够的资源投入到这样的数据治理过程，且难以看到数据建模带来的价值，并且很有可能业务模型变动较快，建模办法自身也须要迭代和演进。因而，很多时候晚期数据的使用者偏向于不做建模，间接应用原始数据，那么势必会导致品质问题、性能问题；而到了须要建模的时候，又遇到数据应用形式曾经成型，难以重构的问题。
而通过物化视图做这件事可能很好地解决这样的矛盾：
- 简化了架构复杂度：不须要在内部保护很多的数据组件去做加工。 相同，如果保护了这些数据组件，不仅要应用物理资源去部署运行，还须要额定部署调度、监控的组件，这样的架构是比较复杂的
- 简化了应用复杂度：仅须要具备根底的 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
