演讲实录 | MaxCompute 智能物化视图

本文根据《Data+AI融合趋势下的智能数仓平台建设》线下meetup演讲实录整理而成

作者：吴谋 - 阿里云计算平台技术专家

MaxCompute 智能数仓简介

MaxCompute 智能数仓本质上是一个具备自我学习能力且开箱即用的优化功能集合。尽管 MaxCompute 智能数仓的优化功能针对的是相对独立的场景，但它们遵循一致的逻辑和思路。我们可以通过架构图来解析一下。

当用户提交 Query 后，首先经过 Optimizer，然后进到编译器，生成一个执行计划，随后被传递到执行引擎，在执行过程中收集 statistics 信息和历史信息。这些统计信息和历史信息会被输入到智能数仓的分析模型中进行深入分析。分析结果通过控制台输出到 DataWorks 和 TopConsole。同时，这些优化后的数据能力反哺到元仓，作为基础数据再次进入优化器。这样，当用户的下一个 Query 进来，就能得到一个较好的调优结果。这就是整个智能数仓的大致思路。

最终效果是，MaxCompute 智能数仓对用户来说是一个无需人工干预的系统，并且具备自我学习的能力。基于此，我们提炼出了六个关键的优化方向：资源分配优化、执行计划优化、智能物化视图、增量计算、数据排布和作业管理。下面我将围绕这几个方向，基于 MaxCompute 智能数仓核心能力图展开讲解，便于大家对 MaxCompute 智能数仓能力有更好的了解。

首先，我们要讨论的是智能调优 Intelligent Tuning。传统作业提交至执行引擎时，为了优化其性能，通常需要了解作业背后执行元表的数据排布涉及的特征，例如需要知道作业适合做 Merge Join 还是 Map Join，通过手动设置，还需要了解 Stage 并发度，CPU、Memory 分配等。然而，借助智能调优功能，在MaxCompute 平台上首次运行后，系统能够自动学习并生成最优执行计划，确保后续相同或类似任务均能在最佳配置下高效执行，从而极大地简化了用户操作流程。

接下来是本次介绍的核心——物化视图，其主要优化场景是重复计算部分。针对不同应用场景，我们提供了两种策略：一是精确匹配 Auto MV 能力，自动帮用户创建物化视图；二是对于模糊匹配，可能存在风险的物化视图，我们会通过推荐方式输出给用户。通过以上两种方式，基本可以覆盖用户对于物化视图功能的全面需要。

此外，我们也拥有强大的自动改写能力，允许用户无需修改原有SQL代码即可利用已创建的物化视图优化作业，提升查询效率。

数据排布方面，我们支持 Auto Cluster，针对用户适合的表推荐做 Cluster 表，转换之后可以大幅减少 Shuffle 计算。除了Auto Cluster，我们还支持 Z-Order 索引及布隆过滤器等，以进一步减少 Shuffle 带来的开销。

作业智能诊断方面，MaxCompute 智能数仓平台会监测用户作业是否存在长尾 worker 或数据倾斜等情况，帮助用户更好地了解作业情况并进行 SQL 调优。

最后，在智能管理层面，MaxCompute 智能数仓平台可以根据作业特征自动路由到 service mode、离线mode 或短查询 mode。

MaxCompute 智能物化视图

接下来进入今天的主题，智能物化视图。正如前面所说，物化视图主要应用的场景就是重复计算场景。为了更好地阐述这一点，我将通过一个简单的例子说明物化视图是如何进行优化的。

如下图是两个非常简单的查询，其中公共重复计算部分用黄色高亮标注了，黄色的部分就是对 source 表中的 key 列和 value 列执行了聚合。当公共查询识别出后，就可以在上面创建物化视图。物化视图执行语句可能如下所示（简单示例，非完整版）。一旦建立了物化视图，再进行两个查询的计算，自动改写能力会将第一个查询进行改写，省掉数据聚合部分计算。这种改写不仅提高了查询性能，还有效减少了所需的计算资源。同样地，第二个查询也会经历类似的转换处理，最终达到同样的优化效果。

基于我们在实际生产环境中积累的数据表明，在我们的计算集群里，重复计算作业比例达到近30%，消耗的计算资源达到50%。这意味着解决重复计算问题十分必要且重要。

上述提到的改写能力只是一个简单的例子。在实际生产环境中，SQL 查询的改写场景往往十分复杂。为了应对这种复杂性，我们提供了两种改写策略：基于替换规则的改写策略和基于语义结构的改写策略。这两种策略分别适用于不同的场景，并具有各自的优缺点。基于替换规则的改写策略，支持广泛的算子类型，包括但不限于 AGG、Window Function、UNION、SORT、LIMIT等。然而，它的局限性在于补偿能力较弱，只支持谓词补偿级别能力的改写，具体来说，当物化视图中的谓词语句与查询语句相差较大时，此策略可能无法有效处理。相比之下，基于语义结构的改写策略则更加灵活和强大。即使MV中的语句语义与作业语句语义之间存在较大的差距，也能够实现有效的改写。但其劣势是支持算子类型少，主要集中在 JOIN 和 AGG 上。综上所述，通过结合这两种互补的改写策略，我们能够满足用户在大多数情况下的改写需求。

在下图中，我们对比了 MaxCompute 与当前市场上主流数仓产品在查询改写能力方面的表现。在图表中，“Y”表示支持该场景，“N”则代表不支持；“Y*”意味着部分支持；而蓝色横线则表明我们在公开资料中未能找到明确信息。从整体上看，MaxCompute 的改写功能相较于竞品而言处于领先地位。对于目前尚未支持的功能，我们已经制定了长期的规划。例如，Join Back 和 View Delta Join 这两种场景，由于它们在实际应用中的出现频率较低，并且即使实现了自动改写也不一定能显著提升性能，因此我们暂时没有提供支持，但未来会纳入考虑范围。此外，派生 Join 类型（即物化视图中的作业类型和查询的作业类型不一致）的改写也在排期中。同样地，针对 AGG 中较为复杂的操作如 Grouping Sets、Push Down 等，我们也正在评估并计划逐步引入支持。总之，我们的目标是最终能够全面满足用户的各种自动改写需求。

物化视图在数据库中是一块经典且内容丰富的领域，除了自动改写能力，我们在物化视图领域还进行了大量的支持工作。例如，针对直接读物化视图场景，我们提供自动穿透功能。在物化视图的维护方面，我们支持多种刷新策略，如果物化视图的数据过期，可能会导致查询结果不准确。因此，我们提供自动设置更新时间、手动更新、分区级别增量更新等一系列更新策略。此外，在分区物化视图、聚簇物化视图、外表物化视图等方面，我们都提供支持。由于时间关系，更多细节不再赘述，总之，我们致力于提升MaxCompute 智能物化视图完备且成熟的产品能力，以满足各种复杂的数据管理和查询需求。

物化视图智能推荐

在构建了相对完备的物化视图基础能力后，我们开始考虑如何让用户真正用上物化视图。正如开篇所说，离用户真正用上物化视图还有一段距离，最显著的一个挑战就是物化视图发现。物化视图发现过程中的主要难点在于识别数据仓库中存在的大量重复计算，手动寻找这些重复计算耗时费力，还有一定技术门槛。基于此前提，我们自然衍生了开发物化视图推荐功能的想法。

以一个简单的场景为例：假设如下图所示是您的工作流，第一阶段跑三个作业，第二阶段跑另外两个作业，我们用图形进行简单抽象，其中相同图形代表重复计算。那么在这个模型中，我们可以观察到第二阶段的两个作业，存在椭圆和菱形两个重复计算，将抽象成物化视图插入到两个工作流之间，就可以实现计算复用，原先需要执行两次的查询操作，引入物化视图之后，通过改写能力执行一次即可。这就是物化视图推荐的典型场景，旨在解决以下几个关键痛点问题：

查询写法多样：用户的查询作业SQL写法大相径庭，难以人工识别重复计算的模式

样本规模大：用户的查询作业规模庞大，动辄千万级的作业量，搜索过程如大海捞针

结构复杂：用户的工作流中，查询作业之间的依赖关系错综复杂，甚至涉及级联的场景，从中查找重复计算也相当困难

为了解决上述痛点，我们推出了智能化视图推荐功能。接下来，我将简单通过图表来阐述 MaxCompute 智能物化视图推荐功能的整体思路。需要注意的是，这里讨论的是离线推荐链路，而不涉及在线查询链路。

当用户查询进来后，会被存到元数据仓库即历史查询仓库。随后，这些历史查询将进入推荐流程。在此过程中，历史查询会被查询计划的回放模块回放成查询计划。所谓“回放”，是指模拟用户查询在MaxCompute 环境中经过编译器和优化器处理后的执行计划。这一操作确保了离线推荐链路所获取的查询计划与实际在线运行时生成的查询计划保持高度一致，从而解决了不同 SQL 语句表达形式差异导致的重复计算识别难题。生成查询计划之后，就进入到了推荐主链路。第一步是对计划进行拆分，得到里面所有的子查询并进行规划，以消除 SQL 改写产生的差异，然后再将相同的公共子查询进行合并，再利用算法评估每个公共子查询是否适合作为物化视图。最终，基于分析生成物化视图推荐结果，结果就可以提交给企业内部负责成本管理和优化的相关团队，以便他们据此实施进一步的性能调优措施。综上所述，就是我们在设计智能化视图推荐功能时遵循的核心思路。

在介绍改写能力时提到过，MaxCompute 物化视图改写能力支持物化视图和查询相差较大的场景。为了更好地利用这一能力，我们的物化视图推荐能力同样支持，针对不完全相同的两个作业，也能抽象成重复计算，我们将其称为模糊物化视图推荐。下面通过两个简单的例子进行说明。

示例1：

SELECT key, cnt,sum(value)
FROM src
GROUP BY key, cnt;

SELECT key, value, sum(cnt)
FROM src
GROUP BY key, value;

SELECT key, value, cnt
FROM src
GROUP BY key, value, cnt;

以上两个查询语义不同，一个是 group by key 和 count，一个是 group by key 和 value，对其进行模糊物化视图推荐，会得到结果1，该结果可以进一步改写成上述查询语句，这个过程就是模糊物化视图推荐。然而，需要注意的是，并非所有情况都适合采用模糊物化视图策略。

示例2：

SELECT key, value, cnt
FROM src
WHERE cnt < 50;

SELECT key, value, cnt
FROM src
WHERE cnt > 100;

SELECT key, value, cnt
FROM src
WHERE cnt < 50 OR cnt > 100;

例如，如上两个查询谓语不同，在处理这两个查询时，即使可以通过构建 or 将其推荐成模糊物化视图，但这种做法其实并不好。因为后续做改写还要增加一个谓语，这不仅增加了复杂性，还会导致存储资源的浪费，这种场景就不适合做模糊物化视图推荐。

与模糊物化视图推荐相对的就是精确物化视图推荐，这两种策略之间各有优劣，在实际应用中需要进行权衡取舍。精确物化视图推荐的优势在于命中作业的优化效果更好，劣势在于其覆盖作业数量有限，导致整体利用率较低。模糊物化视图推荐则能把握更多优化机会，但劣势是一些情况会造成性能回退。比如当遇到物化视图覆盖数据特别多，形成所谓的宽表的情况下，对其做改写可能造成性能回退和存储开销。

综上所述，精确物化视图推荐与模糊物化视图推荐之间需要达到一个平衡。我们在这一平衡关系中进行了大量研究和优化。

跟大家分享一个数据，我们已经在阿里集团内部的项目空间中接入了物化视图推荐，通过应用物化视图，根据当前公共云的计费标准，我们可以估算出最终收益率在9%到10%。需要注意的是，这一数据仅为平均值，实际效果会因不同业务特性而有所差异。为了进一步说明物化视图推荐的实际效益，可以参考一个表现较为突出的项目。该项目的日均开销为18K CU，通过应用物化视图智能推荐结果和优化后，日均节省约6K CU，收益率达到了30%左右。

在成功开发物化视图推荐之后，我们也希望将物化视图推荐分享给公共云客户。为此，我们特别设计了可视化页面，旨在高效地呈现物化视图推荐的结果。下面我将简单介绍下这个可视化页面。

当您打开该页面时，首先需要选择您所管理的项目空间，系统会针对选定的项目空间进行分析，预估物化视图优化效果。以图中数据为例，当所选项目空间把物化视图建出来之后，有344个项目会被影响，此外，还会预估这些项目所占 CU 数、计算量、以及物化视图建出后所占存储等，便于用户做决策。页面下方是推荐创建的物化视图列表，我们会依据可优化的作业数、扫描量、计算复杂度等因素对其进行打分排序。

我们还支持直接在可视化控制台一键创建物化视图，无需额外跳转至产品控制台手动配置。点击创建物化视图之后，可以看到物化视图创建语句，设置更新频率。物化视图创建成功以后，会有一个页面展示管理及收益。比如图中有两个物化视图收益，明显可以看出第一个效果比较好，它每天能节省很多资源。第二个物化视图则可能因为作业变化等原因没有命中，因为物化视图推荐是基于历史的。针对这种情况，可以在页面上直接删除该物化视图。

在物化视图推荐领域，我们仍有许多可以优化和拓展的空间。首先，我们希望引入 AI 模型来处理复杂的决策任务，例如更智能的模糊合并和选择策略。其次，在自动改写方面，我们也需要进一步提升以支持更广泛的应用场景，同时，实现更为精准的代价、收益预估，比如直接且明确地告知用户可以节省多少成本。最后，为了增强用户体验，我们也致力于改进现有的用户界面，使其变得更加直观易用。

AutoMV

有了物化视图推荐之后，用户虽然可以直接创建物化视图，但实际应用过程中仍存在诸多挑战。首先，用户需要根据推荐结果选择创建哪些物化视图；其次，物化视图的更新策略也至关重要，若更新不及时，下游无法获取最新数据，就会导致所建视图失去价值；最后，创建后的视图需要维护，无效或低效的物化视图需及时删除，以免浪费存储资源。为应对上述痛点，我们提出了 AutoMV，支持自动选择效果最好的物化视图，支持自动创建和更新物化视图，支持自动清理和自适应管理存储上限，有效解决了手动物化视图实践痛点。

接下来顺着数据流转方向，介绍一下 AutoMV 的整体框架。在日调度离线部分，物化视图推荐生成结果之后，AutoMV 会自动创建物化视图，创建之后，这些数据都存储在元数据模块。用户查询作业提交后会得到一个执行计划，如果未命中新建的MV，就会执行原计划，如果第一次命中，就会尝试往物化视图中写数据，最后计划会传递到执行引擎。这样一来，Join 就自动用上了 AutoMV。

值得注意的是，首次命中物化视图得到的计划和后面几次命中得到的计划是不同的。这个是 AutoMV 的一个重要设计。例如，当我们为用户创建了一个名为 sys_automv_mv 的自动物化视图时，与之前的物化视图不同，它多了一个关键词：build deferred。这一关键词意味着该物化视图在创建之后，是一个空表。只有当查询进来第一次命中 MV 后，才会将公共子查询部分的数据写到该 MV 中。考虑一个场景，MV 创建时，部分重复计算就已经算了一遍，因为一些原因如作业变化导致第二天未使用该 MV，那么之前的计算就浪费了。有了这个设计，即使创建的 MV 未被使用，因为它是一个空表，没有产生任何开销，就不会造成资源浪费。而且就算只命中一次，也不会浪费。因为当查询作业命中后，等价语句会变成如图两个语句，第一步会先将查询语句写入目标表，第二步会将公共子表达式写入 MV。这两个步骤实际上是同步进行的，因此重复计算只发生一次，结果就写入到两个表中，其中一个就是 MV 表。在后续的查询中，如果再次命中，MV 就能被使用并进行自动改写，这时候只需读取 MV 表，而无需读取原表，就实现了计算加速和资源节省。简而言之，首次命中 MV 后，MV 就有数据；即使第二次未命中，也不会造成资源浪费，如果第二次命中，就实现了资源节省。这一设计使我们能够自信地推动 AutoMV 功能。

AutoMV 的第二个重要设计是，Auto MV 的改写是精确改写，而非模糊改写。如图所示，不精确的改写可能会导致多读数据列，造成性能回退。为了避免此类情况发生，AutoMV 只做精确改写。

基于上述两项核心设计，AutoMV 可以自动为用户创建物化视图，并带来直接收益。

费用问题是许多用户比较关注的一个方面。在此，我们明确表示，AutoMV 功能本身不收取任何费用，唯一可能产生的额外费用来自于存储费用，因为 MV 会占用一定的存储空间。然而，我们可以保证，AutoMV 所占用的存储空间在您的项目中所占的比例非常有限。我们还支持手动设置 AutoMV 的最大存储容量。经过实际经验计算得出，AutoMV 存储开销账单占节省计算账单的0.004。以一个真实项目为例，开启 AutoMV 后，日均节省约670.2CU，消耗存储约1.99TB，即节省费用为5066.4元，开销账单为8.15元。由此可见，AutoMV 不仅能够大幅降低用户的计算成本，而且带来的额外存储开销极低，可以为用户提供显著的成本效益。

跟物化视图推荐一样，我们也在为 AutoMV 开发可视化页面，不久的将来就会上线，在此，我向大家先展示一下大致效果。用户进入项目空间后，可以选择开启或关闭该项目空间的 AutoMV 功能。一旦开启，用户可以设置 AutoMV 所允许占用的最大存储。启用后将生成一个可视化页面，显示AutoMV为该项目空间带来的具体效益，包含您的项目被 AutoMV 命中的次数、节省的时间、节省的CU时、节省的计算量、节省的账单费用等指标，还会展示 AutoMV 占的存储、收益趋势，租户下面所有项目通过 AutoMV 得到的收益占比，每个 AutoMV 的收益等。更进一步地，用户能够深入查看哪些作业受到了 AutoMV 的影响。

AutoMV 在阿里集团内部已经得到了广泛的应用，根据我们的统计数据显示，它能够为被优化的作业节省16.8%的计算资源。此外，AutoMV 对查询计划的加速效果也非常显著。然而，由于作业执行时间受到多种因素的影响，因此在这一方面的数据我们并未进行详细统计。出于数据敏感原因，我们无法提供具体的绝对值，但上述提到的比例是可以公开分享的。

关于 AutoMV 的未来发展方向，我们有以下几个规划：

支持跨项目：当前版本的 AutoMV 尚不支持跨项目的操作。如果您的公共重复查询分布在多个项目中，AutoMV 暂时还无法识别，未来我们计划支持租户级别的项目内物化视图互用。

支持模糊改写：为了使 AutoMV 能够支持更多类型的作业，我们正在考虑支持模糊改写，把握好模糊程度与性能收益之间的平衡

优化工作流编排：目前，AutoMV 是在首次命中时进行物化处理。这意味着，如果您的作业按批次运行，且两批作业之间的时间间隔较短，则可能无法充分利用 AutoMV 的优势。为此，我们计划优化工作流编排，以确保更高效地利用已生成的物化视图。

支持动态更新：现有版本的 AutoMV 生命周期较短，依赖重建更新，我们期望未来可以支持动态更新。

产品化：最后，我们希望提供一个更加友好、直观的可视化界面，提升用户体验。