ReaderMX.
dbaplus社群

数仓开发新模式：物化视图与逻辑数据集的应用

d钻研大数据的约 13 分钟
经过上述的分析，数据集变为宽表+维表的模式。宽表定义了一个数据集可以查询的粒度和指标，维表定义了可以拆解的维度。这样一来，每一个业务都会只会产出有限的数据集，数据集个数得到极大收拢，指标的定义也会更加清晰。
Image
这种宽表+维表的数据集，我们称之为逻辑数据集。逻辑数据集相对于 SQL 数据集来说加入了查询裁切的功能，一般情况下不同目的的查询都只会使用到宽表+部分维表，一个数据集适用的分析场景由维表数量决定，但是查询性能只和当前的分析需要有关。在保证使用范围的情况下，保证了最小的查询范围，无额外性能损耗。
但是随着数据集的通用性提升，越来越多的数据集开始应用于看板制作，相对于自助查询，看板查询的性能要求会更高，并且并发也会更大。自助查询用户会的查询比较灵活，所以对查询的耗时容忍度也更高，一般可以接受20s以内的查询性能。但是对于看板来说，一个看板中可能涉及到几十个图表，每个图表又会涉及到多个查询，相当于同时有上百个查询打到 OLAP 引擎，如果一个查询的耗时还是20s，那整个看板展现出来的时间必然很漫长。此外很多看板查询的显示周期很久，可能达到1年以上，直接查询底表大概率会导致查询失败。
因此，我们需要针对数据集建立对应的物化视图，物化视图基本可以覆盖看板中的绝大多数查询，由于物化视图的数据量较少，所以可以将单个查询的执行时间压缩到4s以内，并且可以将之前查询失败的报表查询出来。
下图是我们的实际技术架构。
Image
DWS 层的数据是进入BI工具的最后一层，这一层我们使用Iceberg存储。Iceberg 作为一种数据湖存储格式，可以使用Spark进行读写，并且也可以使用StarRocks读。实验已经证明，相同资源情况下，StarRocks on Iceberg 的查询性能在绝大场景下和 Clickhouse 相当甚至更优，并且Iceberg 不和 OLAP 引擎深度耦合，其扩展性能也更好，完全可以做到存算分离，解决存储焦虑。
在这层之上就是 RedBI（小红书内部的BI平台）中的逻辑数据集，逻辑数据集是数仓对外的“产品”。
在逻辑数据集之上就是查询加速层，查询加速层中的第一层是物化视图，一个逻辑数据集可以建立多个物化视图，需要保证覆盖大多数的看板查询。相对于传统CUBE类型的APP表，物化视图的优势主要体现在两个方面：
  • 计算复杂度低。CUBE计算本质上需要将数据复制n份（依据CUBE个数），然后进行聚合操作，如果CUBE众多，那么中间的数据膨胀会相当严重，甚至会引发执行超时和报错。而物化视图本质上是对宽表的聚合，所以不存在中间数据膨胀，执行性能会更好。
  • 通用性高。CUBE表一般属于APP表，和BI宽表数据集本身没有绑定关系，那么这个CUBE表很可能只能服务于特定的看板，当有另外的看板在用到类似的维度分析时，如果没有数仓工程师凭借丰富经验做推荐，大概率不会复用该APP表。而物化视图本身是绑定到数据集的，所以只要可以命中物化视图的查询格式，那么不论查询来自哪里，都可以进行复用。
查询加速层的第二层是缓存，尤其是在固定查询的场景下，缓存可以极大缓解对集群的查询压力。
下面着重介绍逻辑数据集和物化视图两大内容。
2、逻辑数据集
1）执行流程
Image
逻辑数据集核心包含两部分：数据集配置和查询裁切。
我们使用图形化界面对数据集进行配置，界面中的节点是一个数据集或者是一个 SQL，节点与节点中间按照关联键进行连接。配置可以告诉系统只能沿着关联键进行裁切，而不可以对节点内部进行裁切。
开启查询裁剪需要同时满足以下两个条件：
  • 节点与节点之间是 LEFT-JOIN 连接
  • 右表关联键不存在重复值
其中，右表连接键唯一性的判断，会在数据预览步骤中进行，和预览结果一起返回。调用数据预览接口时处理如下：
Image
2）查询裁切步骤
从数据集元信息中，获取可以进行裁剪的节点列表。
根据 DSL 中的维度、指标、筛选等字段，把本次查询用到的所有字段展平，把字段对应的节点 id 排除，从而得到本次查询可裁剪的节点列表。
所有的节点列表去掉可裁剪的节点，得到优化后的节点列表。
然后根据连接条件把相关的表 Join 起来，作为一个整体数据集执行BI查询。
Image
3、物化视图的技术手段
1）工具选择
StarRocks 和其他 OLAP 引擎一样，也具备物化视图的功能。StarRocks 的物化视图分为同步物化视图和异步物化视图。同步物化视图可以保证数据集的一致性，异步物化视图需要设置刷新周期。但是在应用到生产环境的时候，就会发现物化视图的调度对集群会造成很大的压力，并且也无法满足很多业务诉求。
同步物化视图的开销较大，数据只要发生变化就会进行刷新，这样在数据集每条导入的过程中就会涉及大量的新增操作，导致大量物化更新，进一步会对集群造成巨大的压力，甚至导致集群崩溃。
而异步物化视图必须设置刷新周期，对于BI数据集来说，数据基本是天级就绪，而且每天数据的就绪时间并不固定，异步物化视图要么需要设置较短的刷新周期，要么天级刷新，但是刷新时间较晚，这样无法满足业务查询性能的诉求。
此外 StarRocks 是一个 OLAP 引擎，和 Spark 不一样的是，不存在类似于 Yarn 的作业调度管理。那么当大量的物化视图开始调度的时候，很难去合理安排物化视图的调度顺序，也无法根据当前的资源情况给不同的物化作业分配不同的资源，因此在先前的 StarRocks ETL 处理中，我们会遇到因为资源抢占导致的作业失败现象。随着物化视图越来越多，物化视图的调度成功率必然也会劣化。
对于 UV 类的计算来说，需要物化成 BITMAP 类型，这就需要对消重字段进行编码，StarRocks 中没有很紧凑的编码方式，官方也建议用户自己映射编码，一方面 StarRocks 中的物化视图无法对 UV 进行物化，另一方面无法得知用户的编码表。
因此我们在 RedBI 中完成了物化视图的功能，相比于原生的物化视图：
RedBI 的物化视图可以充分利用数据平台已有的作业调度能力。
此外，看板也是在RedBI上搭建的，RedBI 本身可以获取到查询的所有信息。
RedBI 可以使用数仓的编码表生成对应的 BITMAP，进而完成对uv类指标的物化。
2）实现方案
Image
当前业界在设计物化视图功能的时候，都聚焦在了查询的改写能力方面，尽可能保证物化视图可以适应越来越多的查询场景。但是实际在生产环境中我们发现物化视图的配置和运维流程会更加重要。和物化视图相关的整套产品功能包括以下几类：物化视图配置、物化 ETL 任务生成与调度、物化查询改写、物化治理。
视图配置：通过RedBI中的物化配置 UI 界面完成视图配置。
物化运维： 监控物化视图当前的新鲜度，保证物化视图的定义依然可以被大部分查询命中。
查询改写： 对查询参数进行校验，将符合物化规则的查询请求路由到合适的物化视图表并完成查询改写。
ETL 任务生成与调度：生成物加速 ETL 任务，实现数据预计算并存储，将数据固化为更小的物化视图表。
视图配置
大多数的 OLAP 引擎的物化视图功能都假设用户已经对物化视图的结构有了清晰的设想。那这样的物化视图从根本上来说依然是数仓在建设APP表的思路，即先有模型设计，然后才会产生物理模型。但是这样的物化视图本质上并没有减轻数仓的工作量，也没有改变数仓的工作方式。如果要最大可能消灭APP层，物化视图的模型设计就不能强依赖数仓的模型设计能力。因此我们的物化视图主要是通过数据集的看板和自助分析模版来生成。
理想的状态下，物化视图可以按照数据集的看板和模版自动生成。但是完成自动化生产物化视图的过程中，我们首先要解决用户手动创建的难点。用户手动创建物化视图依赖的核心功能包括
  • 需要物化的内容。在我们的场景下，就是看板和自主分析模版。看板和自主分析模版的查询热度作为辅助指标可以使用户知晓哪些看板的物化更有价值。
  • 调试过程。用户不大可能一次性就可以创建出没有任何问题的物化视图，物化视图要想发挥价值，必然需要保证性能和命中率两个方面。
物化视图的命中率是我们依赖历史查询进行的分析生成的。如果物化视图的命中率太低，那么对于查询性能的改变就微乎其微。此外，通过看板和自主分析模版生产的物化视图结构可能因为功能不支持或者物化周期的原因命中率低，需要用户进行手动调整。
物化视图的数据量要有限制。如果用户将所有看板和自主分析模版都加入物化，必然可以保证很高的命中率，但是这样的物化视图也接近于明细了，那物化视图的查询就会变慢，物化视图查询加速的能力也就丧失了。因此调试过程中需要显示物化视图的数据量，以保证物化视图的性能。
提需过程
我们需要在什么时候决定要对什么内容创建物化视图进行加速呢？仅仅依赖数仓的经验肯定是不靠谱的，因为数据集的使用方可能是分析师、产品和运营。这些使用方往往会根据自己的需求去搭建看板，数仓是完全不清楚业务具体是怎么使用的。
数仓建设APP表的流程如下图所示。业务方（一般是分析师或产品）首先提出数据需求，然后需要和数仓进行需求对齐，使数仓可以理解业务的诉求，数仓确认需求之后就会涉及对应的 APP 模型。建设好 APP 表之后还需要和业务方进行调试，保证指标符合预期，这个过程如果不符合预期，得多次和业务方进行沟通对齐。
Image
如果物化视图依然沿用这一思路，对于数仓和业务方来说，物化视图和 APP 表就没有任何差别，因为根本上没有降低其中的沟通成本。
业务方对于看板的样式以及指标是最清楚的，一旦涉及到沟通，必然存在信息损耗。因此我们将提需流程改为了如下方式。可以看出新的提需流程是先由业务创建出看板，然后将需要物化的内容提需给数仓，数仓完成对应的物化需求。这个过程中，需求文档不再是一个充满文字和表格的文档，也不需要人工讲解，而是一个真实的看板图表。配合物化视图的配置功能，可以轻松完成物化视图的搭建。
Image
物化运维
物化视图并不是一成不变的，物化视图的变动一般来自于三个方面：
数据集中的表发生了变更，进行了数据回刷。这种情况下，物化视图本身不需要进行更改，只需要回刷即可。当上游数据集完成回刷的时候，我们会自动调度起下游的物化视图任务，回刷对应日期的实例。
看板和模版发生修改，可能会导创建的物化视图失效。这种情况下平台一方面会提醒修改人图表是否无法命中物化，另一方面会通知到数仓发生变更的看板和模版，数仓需要重新测试物化视图对这些看板模版的命中率，并且更新物化视图结构，以保证物化视图命中率。
数据集字段定义发生变更。RedBI 数据集中除了表的原始字段外，还有很多依赖原始字段生成的计算字段，这些计算字段如果发生变更，那么按照之前字段定义创建的物化视图也可能失效。因此当数据集的字段定义发生变更的时候，平台会提示数据负责人失效的物化视图和影响的看板图表，另一方面也会通知数仓更新物化视图。
查询改写
改写流程：
Image
改写采用了基于 SPJG（SELECT-PROJECT-JOIN-GROUP-BY）模式的结构信息来进行透明改写的算法，即将原表的sql查询替换成物化视图的查询。物化视图的改写基于 LodQuery，改写时基于物化配置中存储的字段表达式列表进行匹配和替换。下面是改写步骤：
用户发起查询时，BI 界面的查询配置会转化为 QueryDSL，QueryDSL 经过解析 Lod 表达式、字段拆解等，然后转化为 LodQuery 对象。

LodQuery抽象

RedBI抽象的 LodQuery 大致包括以下部分：

• dimensions：查询维度，指定了需要查询的聚合粒度

• measures：查询度量，指定了在聚合粒度为 dimensions 时需要查询的度量字段

• from：查询表信息，指定了多张原始表、自定义SQL表、逻辑数据集对应的主表和多张维表的定义及关联方式，存在嵌套结构。

•dimensionFilters：维度筛选，指定了对明细数据的筛选方式，需要指定Pill和FilterPredicate

• measureFilters：度量筛选，指定了对聚合后数据的筛选方式，需要指定Pill和FilterPredicate

• orderBy：排序，指定了查询需要按哪些字段进行排序

• offset：查询偏移量，指定了结果需要偏移多少行数据

•limit：查询数据量，指定了结果集的数据量上限

  • 基于数据集物化配置获取对应物化视图列表，并根据优先级排序进行物化命中的校验。
  • 命中物化则将 LodQuery 改写为物化查询的 MaterializedQuery。
  • 对 MaterializedQuery 进一步优化，包括谓词下推、开窗函数处理，引擎特定函数处理等，转换为为 TableQuery(抽象语法树)。

选择基于 LodQuery 而非 TableQuery 进行物化改写的原因在于虽然 TableQuery 和 LodQuery 结构大体一致，但 LodQuery 作为 RedBI 的抽象,具有更丰富的元信息。例如LodQuery 将维度(dimensions)和度量(measures)明确分离,而TableQuery则不区分 dimensions 和 measures。此外,在 LodQuery 转换为 TableQuery 之前,尚未进行各项查询优化，例如谓词下推、窗口函数处理、引擎特定函数处理等，数据结构更加精简，这为物化改写提供了更大的灵活性和可操作空间。

  • 基于 TableQuery 生成SQL， 发送到 StarRocks 进行数据查询，并返回数据。
物化ETL任务生成与调度
物化配置信息确定之后，通过 LodQuery 可以直接确定需要聚合的维度和指标，针对 SUM、COUNT、MAX、MIN 类型的指标可以直接计算，针对比值类型的指标需要分为分子分母分别进行计算，针对UV类型的指标需要将UV类的指标转化为BITMAP。
UV 计算问题：
看板中会涉及到不少UV的计算，物化视图中要实现精确的 UV 计算，就需要建立对应的 BITMAP。为了保证 BITMAP 存储大小和查询性能，消重字段的对应的数字 id 不能太零散。紧凑的编码可以提升 BITMAP 的压缩率和查询效率。
Bitmap 背后的实现基于 Roaring Bitmap，这是一种用于保存聚合后明细数据的数据结构。它通过两级索引来保存明细数据，简而言之，通过两级索引定位到具体的 container，container 中存放着聚合后的明细数据的低16位，它有三种类型：纯数组类型的 Array container、位图类型的 Bitset container 和 RunLen 编码的位图 RunLen container。
size 小于 4096用Array container， 当 size 大于 4096 的时候，显然使用 Bitset Container 更省空间。所以当整个 size 大于 4096 的时候，Container 会从 Array Container 转成 Bitset Container，再通过 Runlen 编码后能否减少空间决定是否要转为最终存储格式 RunLen Container。
消重字段我们一般分为两类：
  • 业务实体 id：比如用户 id、商家 id、商品 id等。每个业务都有核心分析的业务实体，我们针对这类实体id建立了对应的编码表，编码表可以将字符串id映射为紧凑的数字id。大部分的 UV 指标可以通过这类字段进行计算。
  • 自定义消重字段：这类字段通常是通过维度+实体 id 拼接而成，比如搜索 id+搜索词+用户，这类字段的基数很大，也很灵活，很难用固定的编码表进行映射。对于这种类型的字段，我们现在只能通过特定的sql改写来解决，本文不做详细讨论。
但是含有 BITMAP 的物化视图的性能并不总是比底表查询性能好，因为底表查询数据量虽然大，但是并发也高，倾斜的可能性较低。但是物化视图按照一些维度聚合之后，可能会造成部分 BITMAP 存储的id数量太多，太分散，从而导致 BITMAP 的 union 计算耗时增加。那针对这种情况，我们从两个方面进行优化：
  • 增加物化视图的数据条数，从而增加查询并发。
  • 降低BITMAP的倾斜程度。
我们为id编码增加分桶，比如1-100w分一个桶，100w-200w分一个桶，这样一方面增加数据条数，另一方面可以减轻数据的倾斜，并且可以有效提升BITMAP的压缩效率。
经过分桶之后的物化视图，查询性能平均可以提升5倍。

KEEP THE THREAD GOING

更多来源文章