本文根据《Data+AI融合趋势下的智能数仓平台建设》线下meetup演讲实录整理而成
游杰-爱橙科技湖仓技术专家
今天，从三个角度分享爱橙科技如何基于 MaxCompute 智能物化视图进行计算成本优化。首先，是弹内 MaxCompute 物化视图实践；其次，我将介绍物化视图帮助我们在数据模型层进行的优化，也就是公共层挖掘；最后是物化视图如何与 Quick BI 等产品进行联动。
弹内 MC 物化视图实践
在弹内，基于利润最大化的考量，我们主要采用的是模糊物化视图。精确物化视图虽然能够提供更精确的结果，但其带来的收益相对有限。首先，精确物化视图可能会推荐更多数量的物化视图；其次，模糊物化视图整体收益通常高于精确物化视图，通过将多个相似的视图合并为一个模糊物化视图，我们可以减少计算次数，从而实现下游所有节点或任务的复用。
尽管如此，选用模糊物化视图就不能使用 AutoMV 技术，无法自动生成物化视图，这将是未来优化的重点方向之一。那么，在实际应用中，我们如何去利用模糊物化视图呢？最为关键的一点是，生成模糊物化视图推荐后，我们需要确定何时创建它，以确保下游节点能够充分利用该视图。我们选择在调度作业阶段进行创建，因为弹内大部分用户都在DataWorks上开发自己的任务节点，这些节点会构成调度DAG或Pipeline。以下图节点E为例，只有当A和B节点的任务成功运行完毕后，E节点才会被调度起来。
基于上述观察，我们可以得出结论，当平台向我们推荐一个模糊的物化视图时，该物化视图实际上是E、F、G三个作业的公共查询构建出来的物化视图。因此，只需要在E、F、G这三个节点的上游创建一个物化视图节点，将其作为三个任务的前提条件。这意味着，只有当该物化视图运行完成之后，下游的E、F、G任务才能运行。通过这种方式，我们就解决了何时创建物化视图的问题。
将调度链路修改成下图所示以修改调度依赖：在保持ACD节点逻辑不变的前提下，在节点B的下游挂载一个物化视图，就可以通过依赖调度 DAG，自然地确保MV感知到源表的产出。也就是只需创建一个节点，挂载上下游依赖，就能确保物化视图被下游的三个节点使用。
 |
|---|
上述改造的核心是通过修改用户的原始调度 DAG，确保物化视图的运行时间，并合理延缓下游任务的运行，从而保证物化视图在被下游任务使用之前就已经成功创建。那么这种设计是否会因延缓时间而导致整体任务的运行变慢？答案是否定的。从逻辑层面分析，该物化视图本质上是下游任务的一个子查询，节点E、F和G要完成任务，本身就要把物化视图的 SQL 任务执行一遍。因此，"延缓时间"是可接受的。此外，根据我们的实际观察，这种设计不仅不会延缓下游任务的产出时间，反而会有一定加速。原因在于，在大多数生产链路中，节点E、F和G的不要可能同时运行。例如，节点E可能较早启动，而节点F和G则相对较晚。在这种情况下，物化视图运行对F和G的执行几乎不构成影响，反而由于物化视图预先完成了部分计算逻辑，减少了重复计算的开销，从而实现提速。
这种设计还有一个好处，就是用户可以显示感知任务的变化。使用 Auto MV 可能在执行计划层直接对用户的查询逻辑进行了优化，不习惯看 LogView 的用户就无法感知任务变化。而通过修改原始调度 Dag 的改造方式，用户可以更直观地感知到系统对其任务链路所施加的优化手段，有助于进行问题排查。
从成本角度来看，如果采用 Auto MV 的方式，无论是否命中都不会产生额外的开销，实际上就是零成本。而采用模糊物化视图方案，因为在用户实际使用之前便前置性地加了一个额外任务，因此会产生额外的计算成本。所以，如何在保证用户体验的同时，最大化物化视图带来的性能收益，并最小化潜在的资源开销，是我们接下来需要深入考虑的问题。
在计算物化视图的收益时，我们可以通过一个简单的计算公式来评估：（下游复用 MV 的次数 - 1） * 计算消耗(MV)- 存储消耗(MV)。由于使用了模糊物化视图，本身计算无法省略，因此即使在最优情况下，计算资源的节省也无法达到完全抵消。这意味着，尽量保证MV的下游任务数量大于或等于二，就能在计算层面实现收益。那如何优化掉MV 的存储消耗呢？
我们设计了轮训机制。在该计算中，假设物化视图推荐是比较理想化的，即能够将物化视图的收益完全体现在推荐数据中并传递给用户。在此背景下，我们识别到一个关键的时间节点：当EFG节点在调度DAG中运行完成时，MV的存储实际上就没有作用了，可以进行回收。基于此，我们设计了一个轮训接口，监测所有在线MV的下游任务是否已完成，一旦完成就会立即回收该MV所占用的存储资源。这种存储使用形式本质上有点像 Cache 存储，不再常驻于磁盘，避免了长时间占用存储的问题。即使我们将MV的生命周期设置为1天，它仍然会占用24小时存储资源。而通过上述方式，下游任务的平均生命周期通常不会超过3小时，因此MV的存储资源可以在任务完成后迅速释放，从而大幅提升存储资源的利用率并降低不必要的开销。
DAG 的修改本质是侵入了用户的开发链路。因为无法预知系统 BUG 导致的"报错"，MV 作业依旧可能存在"卡壳"。因此，我们还额外设计了几个功能以保障保障：
- 超时查杀：基于历史MV 运行时长设定一个阈值，及时杀掉卡壳的MV 任务确保用户的任务流顺利执行。
- 强制成功：实时感知MV 的运行状态，一旦报错强制MV 成功。
- 任务保护：删除MV 会带来不可控的冲突，需感知冲突，及时修正。
物化视图自2023年4月上线，随着 MaxCompute 团队研发了多个新功能，替换算子也更加全面，截至目前阿里集团接入了114个空间，涵盖15个BU，包括淘系、天猫以及搜推等核心业务。我们之所以将优化重点放在计算调度任务上，是因为计算调度任务占比大概在70%-80%。我们优化范围覆盖约45万CU，整体收益率在9%-10%，每日节省的计算资源约4万CU。
物化视图-公共层挖掘
除了计算资源优化之外，我们还致力于深入挖掘利用公共子查询这一特性，探索更多优化和改造场景。其中，一个核心方向是基于物化视图的持久化。这一方向与数据仓库团队所熟悉的One Data体系密切相关。即将数仓分为几个层次，包括数据采集层（ODS或DIM层）、中间层（DWD和DWS层），以及应用层（ADS层）。其中，中间层的概念与物化视图的核心目标比较类似。在早期业务规模较小、数据团队相对集中的阶段，专业的数据团队会通过数据建模的方式，将可能被复用的计算逻辑抽象出来，并将其固化在中间层中。这种做法的本质是通过预先计算和存储中间结果，避免下游应用重复构建相同的数据链路，从而提升整体效率并降低冗余计算的成本。这便是传统中间层存在的核心意义。然而，随着业务规模的快速扩张以及数据团队的分散化，实现一个统一且高效的公共中间层变得愈发困难。主要原因在于不同团队对数据质量的要求存在显著差异。
为了节省成本，我们必须考虑到，如果在全部都使用物化视图的情况下，实际上难以实现整体数据资产聚集。在这种情况下，举一个有代表性的例子，在实际使用场景中，每天生成的物化视图结果通常会被定期回收或删除，以节省存储资源。然而，这种操作会引发一个关键问题：当下游任务需要回刷上游更长生命周期的数据时，由于物化视图已被清理，就无法达到预期收益。
因此，我们需要根据推荐的物化视图的整体链路，识别什么情况下要将一个 MV 沉淀为一个公共层的表。当涉及下游回刷场景多；计算逻辑复杂（存在 in/out 大、有大字段解析 UDF、有较多复杂算法等）；下游复用数量多等场景，我们通常认为物化视图值得长期保留。
通过对上述场景的综合分析，我们可以判断，当 物化视图上游属于 DWD/DWS层，且含有聚合 SQL 或者复杂 UDF 时，将物化视图的 SQL 沉淀为公共层的表，会带来更大收益。久而久之，也会实现原先逐渐发散的公共层将演进为较为收敛的公共层。
物化视图-FBI加速方案
另一个我们希望与 MaxCompute 团队合作的方向，是将物化视图应用到在线场景。以 FBI 场景为例，这是一个典型的报表分析应用场景。我们通常会在离线数据加工好一系列复杂逻辑后，构建数据集并通过一些组件展现到报表，供用户使用。值得注意的是，这些数据集的逻辑本质上与离线计算的逻辑是一致的，由一系列 SQL 任务构成，但这些任务是由报表平台提交至 MaxCompute 而非通过调度任务。
物化视图推荐会将有重复计算、收益比较高的物化视图推荐给到用户，但实际上我们希望平台能够把物化视图全部推荐给我们，并且拆解成类似任务调度 DAG 的形式给到我们。我们就可以将平台所有的临时查询构建成一个虚拟的调度结构，六个数据集对应的 SQL 全部都拆解成了最原始的状态，这些状态全部都是由 MV 构成的类似于 Pipeline 的结构。
数据集的底层已经变成下图所示，所有的计算子过程只会计算一次。当用户新增一个 query 时候，它会动态拆解，计算出需要先构建 MV 的地方，放到数据库中进行缓存，以此实现报表加速。
