QPS 提升 10 倍!滴滴借助 StarRocks 物化视图实现低成本精确去重

news/2024/4/20 18:28:43/文章来源:https://blog.csdn.net/StarRocks/article/details/136393695

作者:滴滴 OLAP 开发工程师 刘雨飞

小编导读:

滴滴于 2022 年引入了 StarRocks。经过一年多的努力,StarRocks 逐渐替代了原有技术栈,成为滴滴内部主要的 OLAP 引擎。截至 2023 年 12 月,滴滴已经成功建立了超过 40 个 StarRocks 集群,每日查询量在千万量级,拥有超过 3000 张数据表。这一强大的基础设施已广泛支持了滴滴公司几乎所有的业务线,包括网约车、单车、能源、货运等多个领域。

⚠️ 关于滴滴统一 OLAP 引擎的详细内容已在“StarRocks 统一 OLAP 引擎在滴滴的探索实践”进行了详细讲解,本文将着重探讨 StarRocks 物化视图在滴滴的实际应用。

高并发精准去重

实时数据洞察的拦路虎

实时数据洞察在业务管理中的重要性无可替代。在滴滴内部,网约车实时看板是公司最关键的业务监控工具之一,包含着超过 20 个重要的业务指标,如实时呼叫量、冒泡数量和 GMV 等。这些实时看板数据对于业务、数据和运营团队至关重要,提供了即时见解,帮助我们更好地了解业务的状态和趋势。

通过实时监测这些数据,我们能够迅速应对市场波动,做出及时决策,例如:

  • 实时呼叫量变化可帮助我们满足高峰需求,缩短乘客等待时间,提高司机收益;
  • 冒泡数量波动可提示哪些地区需增加司机资源,满足潜在乘客需求;
  • 然而,关键业务指标的计算通常需要大量的精确去重操作,尤其在高峰访问期间,这可能会对资源造成巨大压力,也是众多 OLAP 系统一直以来的挑战之一。为了平衡计算成本,许多系统牺牲了准确性,提供模糊去重的方法,这也是滴滴过去基于 Druid 的指标计算方案所采用的策略。

但是,模糊去重方法存在计算误差,这意味着我们可能无法完全准确地反映业务的实际情况,从而难以实现更精细化的运营决策。此外,即便为了降低资源消耗而牺牲了准确性,模糊去重节省的资源在高并发场景下仍旧是杯水车薪。在大规模促销活动期间,高并发查询可能导致 Druid 集群的稳定性问题,引发性能下降、响应时间延长甚至系统崩溃,这对一个依赖实时数据的业务来说是不可接受的。

因此,我们迫切需要一种新的解决方案,在可控的资源开销下,实现高并发的精确去重,以更好地支持业务运营和决策。StarRocks 的物化视图帮助我们实现了这一目标。

StarRocks 物化视图 让精准去重的落地和加速不再是纸上谈兵

实时看板场景具有以下显著特点:

高基数的精确去重。看板需要面对日增量上亿规模的明细数据,并针对明细数据进行大量 count(distinct()) 计算。并且,在实际应用中,精确去重的用户、订单 id 通常是字符串,这对计算资源造成了巨大挑战。

支持灵活的维度筛选。看板查询提供了多种筛选条件,包括时间、城市、业务线等超过十个维度字段的组合。每天的真实查询可能会涉及上千种维度组合。 查询并发高。尤其在大促期间,数据开发以及业务运营都会密切关注业务瞬时变化趋势,高峰时期可能有上千规模的用户盯盘。指标数据按照分钟级别刷新,每次刷新会触发大约几十次查询计算,则高峰时期可能有数百 QPS,对集群负载要求非常高。如果每次查询都直接使用原始明细数据进行计算,将消耗大量计算资源,这在成本上是难以接受的。

这样的业务场景对查询引擎提出了非常高的要求。自 2022 年起,滴滴已经在网约车、单车、能源、货运等多个领域应用了 StarRocks,我们也在密切关注社区的新功能。异步物化视图是针对透明查询加速、高并发场景研发的利器,自其发布之后,我们就开始了这个场景的测试验证。尝试物化视图主要是由于其以下几个特点:

  • 物化查询结果:物化视图可以通过 SQL 查询来将计算结果缓存下来。缓存下来的结果可以被看作是一张物理表,相比 index(同步物化视图),在高并发的场景下表现更加优秀。

  • 托管刷新流程:相较于手动维护导入任务,物化视图的刷新不仅可以定时触发,还能够根据数据变更做到分区级别的增量刷新,降低刷新成本。

  • 透明查询改写:物化视图支持智能的透明改写,能够将物化的结果更大范围的应用到更多查询加速上。用户无需感知物化视图的存在,即可加速查询体验。

StarRocks 实时精确去重最佳实践

在结合业务特点和 StarRocks 的物化视图能力,我们设计了整个看板场景的加速优化链路。以下是设计的主要思路:

alt

为了最大限度地降低去重操作对 CPU 的消耗、加速去重,我们的整体思路是:

  • 数据预处理:利用全局字典进行数据类型转换,用最小的代价做精确去重

最上游的数据来自数据仓库,经过清洗加工后,通过 Flink 实时同步到 StarRocks。在 StarRocks 内部,首先进行一次全局字典转换。特别是对需要进行去重的指标列,将其从 String 类型映射为 BIGINT 类型,以便后续使用 BITMAP 类型进行上卷计算。

  • ODS 层:利用明细模型存储原始数据

接下来,在 StarRocks 内部进行数据建模,生成原始明细表并形成 ODS 层--StarRocks 明细模型层。

  • DWD 层:利用同步物化视图构建增量聚合层

在 DWD 层,我们创建了同步物化视图对不同维度组合进行上卷去重。同步物化视图类似于索引(Index),它具有较高的时效性,并且数据满足强一致性。在精确去重场景,同步物化视图可以通过存储 BITMAP 类型的中间计算结果,使后续单次明细查询性能明显提升,同时还为下一步异步物化视图的更新提供便利。

  • ADS 层:利用异步物化视图构建透明加速层

在 ADS 层,我们创建了异步物化视图,这些视图使用定时刷新机制。虽然时效性相对较差,存在一定的数据更新延迟,但由于存储的是最终计算结果,查询速度非常快。这可以被视为持久化的查询缓存。

  • 加速策略:利用智能改写能力透明提速

通过分析历史查询模式来构建增量聚合层的同步物化视图,在此之上进一步将最高频的查询定义为透明加速层的异步物化视图。同步和异步物化视图都支持透明的查询改写,依照这样的构建逻辑,用户基于原始明细表查询时,会遵循异步物化视图->同步物化视图->原始明细表的优先级来进行查询加速,从而保证了查询整体的实效性。

接下来展开讲解每一部分是如何构建的。

数据预处理:利用全局字典进行数据类型转换,用最小的代价做精确去重

StarRocks 支持两种类型的去重方式:Hyper-loglog 和 BITMAP。对于需要精确去重的指标,我们使用 BITMAP 类型。

StarRocks 内部采用了 Roaring BITMAP 的实现方式,字段类型要求在 INT(64) 位以内,并在数据连续性较好的情况下性能表现更佳。如果数据具有连续递增的特性,相较于完全随机的 ID 性能优势可达数倍以上。因此,滴滴在 StarRocks 中实现了高基数全局字典的功能。

alt

第一步:创建全局字典表(主键模型表)

这里利用到 StarRocks 主键模型表的部分列更新以及自增列功能。文档请见:

https://docs.starrocks.io/zh-cn/latest/using_starrocks/query_acceleration_with_auto_increment

创建全局字典表:数据存储在 StarRocks 内部具有自增 ID 列的主键表中。表的主键使用需要去重的 STRING 字段,而 ID 列则是自增的 BIGINT 列。这样每一个需要被去重的 STRING 字段都会有一个对应的 BIGINT 值与之对应。

连续递增的数据生成:在写入 STRING 列数据时,自增 ID 列会自动生成连续递增的 BIGINT 值。并且,通过 StarRocks 的 partial_update 部分列更新功能,可以保证 BIGINT 列只在第一次写入时生成,后续即便写入相同的 STRING 值,对应的 BIGINT 也不会被更新。确保数据写入的幂等性,从而保证数据可以无限次地重复写入。

第二步:字典映射函数

我们实现了字典映射的函数 dict_mapping,其入参包括字典表表名和主键值。它可以在计算时实时查询字典表,并返回生成的 ID 值。为了提高性能,我们使用了 StarRocks 的主键索引进行加速,相比于基于直接扫描,性能提升非常显著。这个函数目前已经贡献回社区,欢迎大家使用。

第三步:Flink 数据写入

对 Flink 的 flink-starrocks-connector 进行改造,数据写入分为两步:

首先,将数据写入字典表,包括抽取需要写入字典表的列,以确保数据写入并落盘,同时提交事务以使其可见。

随后,将数据写入明细模型表。在写入时,StarRocks 支持设置参数和使用函数进行预处理。使用第二步的字典映射函数 dict_mapping 对需要去重的字段进行重新映射,将原本的 string 类型映射为字典表中 ID 列的值。

通过这一流程,实现了在 StarRocks 中的全局字典功能,用于高效处理需要精确去重的指标计算。这个优化方案显著提高了性能并降低了计算成本,使得处理高基数去重变得更加高效和可扩展。

DWD 层:利用同步物化视图构建增量聚合层

在增量聚合层我们创建了同步物化视图。同步物化视图同样提供了基于 BITMAP 和 HLL 算法的去重方式。我们可以方便地利用 BITMAP 聚合函数来创建同步物化视图。同步物化视图创建完成后,后续查询语句中的子查询 count(distinct order_id) 会被自动改写为 bitmap_union_count(to_bitmap(order_id)) 以便查询命中物化视图。例如:

CREATE MATERIALIZED VIEW mv_dwd AS
SELECT dt,  time_slice(`table_time`, INTERVAL 5 minute, floor) AS `ts`, city, source_type, bitmap_union(to_bitmap(order_id))
FROM base_table
GROUP BY dt, ts, city, source_type;

同步物化视图不仅可以作为异步物化视图的中间计算结果,加速异步物化视图的刷新,也可以承载一部分异步物化视图未命中的查询对其加速。

ADS层:利用异步物化视图构建透明加速层

在增量聚合层我们创建了异步物化视图。这里以简化后的订单表为例,介绍如何通过创建异步视图来实现查询加速。订单表包括分区日期、数据时间、城市、渠道、业务线等维度字段,以及需要去重的字段业务订单 ID。

在数据表中,我们使用time_slice函数将时间粒度取整为 5 分钟,并按照 5 分钟区间粒度进行数据聚合。聚合的维度包括城市、渠道等可累加的维度。这个聚合视图的好处在于,当用户需要查询 5 分钟粒度的数据,并且查询条件与视图中的聚合维度完全匹配时,可以直接使用这个视图进行查询加速,而无需查询原始底表的明细数据。示例如下:

CREATE MATERIALIZED VIEW `mv_ads`
 PARTITION BY (dt)
 DISTRIBUTED BY HASH(`ts`) BUCKETS 1
 REFRESH ASYNC START(“2023-06-28 21:00:00”) EVERY(INTERVAL 30 SECOND) PROPERTIES ( 
"partition_refresh_number" = "3" ) 
AS SELECT 
`dt`,
 time_slice(`table_time`, INTERVAL 5 minute, floor) AS `ts`, `city`,
 `source_type`,
 count(DISTINCT `order_id`) AS `order_num` 
FROM `base_table` GROUP BY 
`dt`,`ts`,`city`, `source_type`; 

同样的操作可以重复进行,设置不同的区间聚合粒度(如 1 分钟、10 分钟、30 分钟等),并按照不同的维度列组合,创建多张异步视图。这样可以满足不同用户、不同维度组合的查询需求,实现了对应实时看板的查询加速效果。 在上述过程中,需要创建的异步物化视图数量可以通过以下方式进行优化,以降低视图建设的成本:

  • 区分出可累加维度和不可累加维度

根据订单表中维度列的查询特点,可以将维度列分为可累加维度和不可累加维度。可累加维度指的是包含隶属关系的维度。例如,“城市”属于可累加维度,因为它隶属于“全国”这个概念;而订单状态是不可累加维度,因为每个订单都在不同状态之间流转。

  • 对于可累加维度,仅创建必要的异步视图

对于可累加维度,只需创建一个基于该维度的异步物化视图,不需要为每个不同的可累加维度组合创建单独的视图,因为结果是可以复用的。例如只需要创建针对“城市”聚合的物化视图,当需要计算“全国”范围的结果时,可以在城市的结果上进一步计算而来。如果所有维度都是可累加维度,则理论上只需要一张物化视图就可以解决。

  • 对于不可累加维度,根据不同组合创建异步视图

对于不可累加维度,需要根据不同的不可累加维度创建异步物化视图。这些视图将单独处理每个不可累加维度的数据,以满足特定查询条件。

通过以上优化策略,如果数据表中有 M 个可累加维度列和 N 个不可累加维度列,那么只需要创建 2^(N-M) 个异步物化视图,而不是 2^N 个。这样可以大幅减少视图数量的同时满足绝大多数查询条件的加速需求,降低了建设和维护的成本,提高了系统的可维护性和效率。

加速策略:利用智能改写能力透明提速

StarRocks 提供了物化视图的透明加速功能,使用户可以无需手动选择使用哪张表,而是通过自动改写查询来实现加速,同时保持查询的语义一致性和性能提升。

假设有以下查询示例:

SELECT 
  ts, 
  SUM(order_num) 
FROM(
    SELECT 
      time_slice(`table_time`, interval 5 minute) AS ts, 
      count(DISTINCT `order_id`) AS `order_num` 
    FROM 
      `base_table` 
    WHERE 
      (...) 
    GROUP BY 
      `dt`, 
      `ts`, 
      `city`, 
      `source_type`
  ) sub 
WHERE 
  dt = '2023-07-01' 
GROUP BY 
  ts; 

在这个查询中,内层子查询对数据进行了 5 分钟粒度的聚合,并包含了多个可累加维度。外层查询对子查询的结果进行了进一步的聚合。基于这个查询,可以建立以下三张异步视图:

视图1:包括 5 分钟粒度聚合、可累加维度分区(dt)、日期(ts)、城市(city)、渠道(source_type)。


CREATE MATERIALIZED VIEW `mv_1`
PARTITION BY (dt)
DISTRIBUTED BY HASH(`ts`) BUCKETS 1
REFRESH ASYNC START(“2023-06-28 21:00:00”) EVERY(INTERVAL 30 SECOND) PROPERTIES ( 
"partition_refresh_number" = "3" ) 
AS SELECT 
    `dt`,
    time_slice(`table_time`, INTERVAL 5 minute, floor) AS `ts`, 
    `city`,
    `source_type`,
    count(DISTINCT `order_id`) AS `order_num` 
FROM 
   `base_table` 
GROUP BY 
    `dt`, 
    `ts`, 
    `city`, 
    `source_type`;

视图2:在视图1的基础上,增加了业务线(product_line)作为可累加维度。


CREATE MATERIALIZED VIEW `mv_2`
PARTITION BY (dt)
DISTRIBUTED BY HASH(`ts`) BUCKETS 1
REFRESH ASYNC START(“2023-06-28 21:00:00”) EVERY(INTERVAL 30 SECOND) PROPERTIES ( 
"partition_refresh_number" = "3" ) 
AS SELECT 
    `dt`,
    time_slice(`table_time`, INTERVAL 5 minute, floor) AS `ts`, 
    `city`,
    `source_type`,
    `product_line`,
    count(DISTINCT `order_id`) AS `order_num` 
FROM 
   `base_table` 
GROUP BY 
    `dt`, 
    `ts`, 
    `city`, 
    `source_type`
    `product_line`;

然后,StarRocks 的透明加速功能会自动识别查询条件,将查询自动改写为适用于这些视图的形式,以保持查询结果的一致性。例如:

  • Case 1:如果 WHERE 条件为空,则命中视图1,并自动改写查询以使用该视图加速。
  • Case 2:如果 WHERE 条件包含 city IN (...),则命中视图1,并相应地改写查询。
  • Case 3:如果 WHERE 条件包含 product_line=?,则命中视图2,并自动改写查询以使用该视图。
  • Case 4:如果 WHERE 条件包含多个业务线查询,不支持累加,无法命中视图2,但如果有创建同步视图的话,可以进行上卷加速。
alt

通过这种方式,StarRocks 可以根据查询条件自动选择适当的视图进行加速,而无需用户手动介入,从而提高了查询性能并简化了用户操作。这保证了查询的语义一致性和性能提升。

总结与规划

设计方案的核心在于权衡,而方案的成功关键在于综合性能的提升。对于看板类查询,其并发性非常高,但查询模式相对固定。大多数查询都是相似甚至重复的。因此,整体方案的思路在于在一定程度上牺牲灵活性,以保障查询性能的极致提升。相较于基于明细直接计算,基于 StarRocks 物化视图对业务监控看板进行加速优化的优点显而易见:

  • 单次查询耗时降低 80%,资源消耗减少 95%;
  • 在相同规模的集群上,支持的查询 QPS 提高了 100 倍。

当前,线上通过物化视图支持了上百并发的精确去重查询,彻底解决了 Druid 仅能支持几十并发模糊去重的问题,相较于原有架构 QPS 提升了 10 倍。然而,方案也存在一些明显的不足之处,包括:

  • 数据链路相对复杂,需要人工配置视图,维护复杂度较高,成本较高;
  • 异步视图的定时刷新策略无法保证数据强一致,并且即使在没有看板访问时也会刷新,对计算资源有一定浪费

未来,我们会联合社区进一步优化物化视图,提高效率:

  • 提升 BITMAP 的计算性能。这可以包括修改 StarRocks 的 BITMAP 分桶策略为 range 分桶,从而不需要对 BITMAP 的中间结果进行 shuffle 就可以得到最终结果。另外,使用 Roaring BITMAP 的 fastunion 函数来提高大量 BITMAP 的合并速度。

  • 优化异步视图在改写计算环节的资源消耗。对于同底表相关的所有视图,在分区数据一致性和版本一致性等方面,都存在提升的空间。

  • 在易用性方面进行改进。由于看板查询都是基于平台配置的,自动生成的查询 SQL,因此通过分析历史查询记录,提取高频查询,进行物化视图的自动创建,可以减少人工参与,从而更有利于实现技术的更大规模应用和推广。这将使整个系统更加智能和用户友好。

并且,社区也在研发更加高效的全局字典,通过将字典表直接缓存在 BE/CN 的内存上,以降低查询字典时的网络开销,以满足除精确去重之外的更多场景。

本文由 mdnice 多平台发布

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.luyixian.cn/news_show_996819.aspx

如若内容造成侵权/违法违规/事实不符,请联系dt猫网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

解决:Information:java: javacTask: 源发行版 8 需要目标发行版 1.8

解决:Information:java: javacTask: 源发行版 8 需要目标发行版 1.8 先点击 Project Structure 查看jdk是否为1.8版本 我这jdk版本为1.8版本的,但还是运行还是报错 据以上错误显示以及上述配置,我选择的编译器是jdk1.8的,但是在i…

算法沉淀——动态规划之其它背包问题与卡特兰数(leetcode真题剖析)

算法沉淀——动态规划之其它背包问题与卡特兰数 二维费用的背包问题01.一和零02.盈利计划 似包非包组合总和 Ⅳ 卡特兰数不同的二叉搜索树 二维费用的背包问题 01.一和零 题目链接:https://leetcode.cn/problems/ones-and-zeroes/ 给你一个二进制字符串数组 strs…

论文阅读-高效构建检查点

论文标题:On Efficient Constructions of Checkpoints 摘要 高效构建检查点/快照是训练和诊断深度学习模型的关键工具。在本文中,我们提出了一种适用于检查点构建的有损压缩方案(称为LC-Checkpoint)。LC-Checkpoint同时最大化了…

使用 llama.cpp 在本地部署 AI 大模型的一次尝试

对于刚刚落下帷幕的2023年,人们曾经给予其高度评价——AIGC元年。随着 ChatGPT 的火爆出圈,大语言模型、AI 生成内容、多模态、提示词、量化…等等名词开始相继频频出现在人们的视野当中,而在这场足以引发第四次工业革命的技术浪潮里,人们对于人工智能的态度,正从一开始的…

LeetCode73题:矩阵置零(python3)

代码思路: 这里用矩阵的第一行和第一列来标记是否含有0的元素,但这样会导致原数组的第一行和第一列被修改,无法记录它们是否原本包含 0。因此我们需要额外使用两个标记变量分别记录第一行和第一列是否原本包含 0。 class Solution:def setZe…

STM32CubeMX学习笔记14 ---SPI总线

1. 简介 1.1 SPI总线介绍 SPI 是英语Serial Peripheral interface的缩写,顾名思义就是串行外围设备接口。是Motorola(摩托罗拉)首先在其MC68HCXX系列处理器上定义的。 SPI,是一种高速的,全双工,同步的通信总线,并且在…

前端实现一个绕圆心转动的功能

前言: 今天遇到了一个有意思的需求,如何实现一个元素绕某一个点来进行圆周运动,用到了一些初高中的数学知识,实现起来还是挺有趣的,特来分享🎁。 一. 效果展示 我们先展示效果,如下图所示&…

改进YOLO系列 | YOLOv5/v7 引入通用高效层聚合网络 GELAN | YOLOv9 新模块

今天的深度学习方法专注于如何设计最合适的目标函数,以使模型的预测结果最接近真实情况。同时,必须设计一个合适的架构,以便为预测提供足够的信息。现有方法忽视了一个事实,即当输入数据经过逐层特征提取和空间转换时,会丢失大量信息。本文将深入探讨数据通过深度网络传输…

视频编码中常用的测试YUV系列及说明

vcc最新规定的测试序列如下所示,对于RA和LD配置,所有序列的所有帧都需要测试,对于intra配置仅需测试前8帧。 每列含义如下: A1、A2测试序列在LD配置下编码时应编码帧数为帧率的三倍。 “M”表示在该配置下必须测试这条序列。 …

基于 LLaMA 和 LangChain 实践本地 AI 知识库

有时候,我难免不由地感慨,真实的人类世界,本就是一个巨大的娱乐圈,即使是在英雄辈出的 IT 行业。数日前,Google 正式对外发布了 Gemini 1.5 Pro,一个建立在 Transformer 和 MoE 架构上的多模态模型。可惜,这个被 Google 寄予厚望的产品并未激起多少水花,因为就在同一天…

根据标签出现的频次渲染不同大小的圆和文字,圆随机摆放且相互之间不重叠

效果图: 按每个标签出现的频次大小渲染出不同比例大小的圆,渲染的圆的宽度区间为 [40, 160] ,其中的文字的大小区间为 [12, 30] ,圆的位置随机摆放且不重叠。 根据已知条件可得出,标签中频次最高的对应圆的宽度(直径…

Mac Pro 突然不能双击打开文件夹

当Mac Pro 突然不能双击打开文件夹 不防右击看看这儿 有没有勾选 如果勾选就会在打开的瞬间 闪退关掉文件夹

如何恢复edge的自动翻译功能

介绍:对于英文不好的小伙伴,把英语翻译成中文是有帮助的,而edge可以直接对英文页面翻译这一功能更是受人喜爱,但是,最近发现这一项功能消失了。 原始界面: 下面展示如何恢复该功能。 1.打开edge&#xff…

docker自定义镜像与上传

alpine制作jdk镜像 alpine Linux简介 1.Alpine Linux是一个轻型Linux发行版,它不同于通常的Linux发行版,Alpine采用了musl libc 和 BusyBox以减少系统的体积和运行时的资源消耗。 2.Alpine Linux提供了自己的包管理工具:apk(注意:…

【nowcoder】NC248 左叶子之和

NC248 左叶子之和 计算给定二叉树的左叶子之和。 树上叶子节点指没有后继节点的节点,左叶子指连向父节点的左侧的叶子节点。 int sumOfLeftLeaves(struct TreeNode* root ) {if (root ! NULL) {int sum 0;if (root->left ! NULL && root->left->…

可观测性十大场景 | 关于保险行业开门红期间应用性能的端到端全栈可观测

【场景概述】 保险行业的“开门红”是每年10月份到次年2月份的业绩冲刺期,各大保险公司纷纷推出独具特色的理财产品,吸引广大客户的目光,以期在新年伊始便赢得“开门红”的吉祥兆头。这段时期,保险收入占比接近全年收入的50%&…

【UE 材质 Niagara】爆炸效果

目录 效果 步骤 一、材质部分 二、Niagara部分 效果 步骤 一、材质部分 1. 创建一个材质,这里命名为“M_Burst” 打开“M_Burst”,设置混合模式为半透明,设置着色模型为无光照,勾选双面显示 在材质图表中首先创建扰动效果 其…

CVPR 2024 | Modular Blind Video Quality Assessment:模块化无参视频质量评估

无参视频质量评估 (Blind Video Quality Assessment,BVQA) 在评估和改善各种视频平台并服务用户的观看体验方面发挥着关键作用。当前基于深度学习的模型主要以下采样/局部块采样的形式分析视频内容,而忽视了实际空域分辨率和时域帧率对视频质量的影响&am…

Vue.js+SpringBoot开发天然气工程运维系统

目录 一、摘要1.1 项目介绍1.2 项目录屏 二、功能模块2.1 系统角色分类2.2 核心功能2.2.1 流程 12.2.2 流程 22.3 各角色功能2.3.1 系统管理员功能2.3.2 用户服务部功能2.3.3 分公司(施工单位)功能2.3.3.1 技术员角色功能2.3.3.2 材料员角色功能 2.3.4 安…

[c++] 模板

c 中的模板通过将类型参数化,可以提高代码的复用性。模板并不能减少代码量,只是从开发者的角度来看,代码量减少了,复用性提高了;从二进制文件的角度看,代码量没有减小。 1 函数模板 当求两个数的和时&…