前段时间给 StarRocks 的物化视图新增了一个
特性
，那也是我第一次接触 StarRocks，因为完全不熟悉这个数据库，所以很多东西都是从头开始了解概念。

为了能顺利的新增这个特性（具体内容可以见后文），我需要把整个物化视图的流程串联一遍，于是便有了这篇文章。

在开始之前简单了解下物化视图的基本概念：

简单来说，视图和 MySQL 这类传统数据库的概念类似，也是用于解决大量消耗性能的 SQL 的，可以提前将这些数据查询好然后放在一张单独的表中，这样再查询的时候性能消耗就比较低了。

刷新条件

为了保证视图数据的实时性，还需要在数据发生变化的时候能够及时刷新视图里的数据，目前有这几个地方会触发视图刷新：

• 手动刷新视图，使用
  REFRESH MATERIALIZED VIEW order_mv;
  语句
• 将视图设置为 active 状态：
  ALTER MATERIALIZED VIEW order_mv ACTIVE;
• 基表数据发生变化时触发刷新。
  
  • 
• truncate 基表时触发刷新：
  truncate table trunc_db.t1;
• drop partition 时触发：
  ALTER TABLE <tbl_name> DROP PARTITION(S) p0, p1 [, ...];

这里的 truncate table 和 drop partition 目前的版本还存在 bug：当基表和物化视图不在一个数据库时不会触发自动刷新，目前已经修复了。

• https://github.com/StarRocks/starrocks/pull/52618
• https://github.com/StarRocks/starrocks/pull/52295

刷新流程

如图所示，当触发一次刷新之后主要就是需要计算出需要刷新的分区。

第一次触发刷新的时候是不会带上周期（比如时间范围），然后根据过滤计算出来的周期，默认情况下只会使用第一个周期（我们可以通过
partition_refresh_number
参数来调整单次刷新的分区数量）。

然后如果还有其余的周期，会将这些周期重新触发一次刷新任务（会带上刚才剩余的周期数据），这样进行递归执行。

通过日志会看到返回的分区数据。

新增优化参数

我们在使用物化视图的时候，碰到一个场景：

CREATE TABLE IF NOT EXISTS test.par_tbl1
(
    datekey DATETIME,
    k1      INT,
    item_id STRING,
    v2      INT
)PRIMARY KEY (`datekey`,`k1`)
 PARTITION BY date_trunc('day', `datekey`);

 CREATE TABLE IF NOT EXISTS test.par_tbl2
(
    datekey DATETIME,
    k1      INT,
    item_id STRING,
    v2      INT
)PRIMARY KEY (`datekey`,`k1`)
 PARTITION BY date_trunc('day', `datekey`);

 CREATE TABLE IF NOT EXISTS test.par_tbl3
(
    datekey DATETIME,
    k1      INT,
    item_id STRING,
    v2      INT
)
 PRIMARY KEY (`datekey`,`k1`);

但我们有三张基表，其中 1 和 2 都是分区表，但是 3 是非分区表。

此时基于他们新建了一个物化视图：

CREATE
MATERIALIZED VIEW test.mv_test
REFRESH ASYNC
PARTITION BY a_time
PROPERTIES (
"excluded_trigger_tables" = "par_tbl3"
)
AS
select date_trunc("day", a.datekey) as a_time, date_trunc("day", b.datekey) as b_time,date_trunc("day", c.datekey) as c_time
from test.par_tbl1 a
         left join test.par_tbl2 b on a.datekey = b.datekey and a.k1 = b.k1
         left join test.par_tbl3 c on a.k1 = c.k1;

当我同时更新了分区表和非分区表的数据时：

UPDATE `par_tbl1` SET `v2` = 2 WHERE `datekey` = '2024-08-05 01:00:00' AND `k1` = 3;
UPDATE `par_tbl3` SET `item_id` = '3' WHERE `datekey` = '2024-10-01 01:00:00' AND `k1` = 3;

预期的结果是只有
par_tbl1
表里修改的数据会被同步到视图（
"excluded_trigger_tables" = "par_tbl3"
已经被设置为不会触发视图刷新），但实际情况是
par_tbl1
和
par_tbl2
表里所有的数据都会被刷新到物化视图中。

我们可以使用这个 SQL 查询无刷视图任务的运行状态：

SELECT * FROM information_schema.task_runs order by create_time desc;

这样就会造成资源损耗，如果这两张基表的数据非常大，本次刷新会非常耗时。

所以我们的需求是在这样的场景下也只刷新修改的数据。

因此我们在新建物化视图的时候新增了一个参数：

CREATE
MATERIALIZED VIEW test.mv_test
REFRESH ASYNC
PARTITION BY a_time
PROPERTIES (
"excluded_trigger_tables" = "par_tbl3",
"excluded_refresh_tables"="par_tbl3"
)
AS
select date_trunc("day", a.datekey) as a_time, date_trunc("day", b.datekey) as b_time,date_trunc("day", c.datekey) as c_time
from test.par_tbl1 a
         left join test.par_tbl2 b on a.datekey = b.datekey and a.k1 = b.k1
         left join test.par_tbl3 c on a.k1 = c.k1;

这样当在刷新数据的时候，会判断
excluded_refresh_tables
配置的表是否有发生数据变化，如果有的话则不能将当前计算出来的分区（1,2 两张表的全量数据）全部刷新，而是继续求一个交集，只计算基表发生变化的数据。

这样就可以避免 par_tbl1、par_tbl2 的数据全量刷新，而只刷新修改的数据。

这样的场景通常是在关联的基表中有一张字典表，通常数据量不大，所以也不需要分区的场景。

这样在创建物化视图的时候就可以使用这两个参数
excluded_trigger_tables，excluded_refresh_tables
将它排除掉了。

整体的刷新逻辑并不复杂，主要就是几个不同的刷新入口以及刷新过程中计算分区的逻辑。

参考链接：

• https://docs.starrocks.io/zh/docs/using_starrocks/async_mv/Materialized_view/#理解-starrocks-物化视图
• https://docs.starrocks.io/zh/docs/using_starrocks/async_mv/use_cases/data_modeling_with_materialized_views/#分区建模
• https://github.com/StarRocks/starrocks/pull/52295
• https://github.com/StarRocks/starrocks/pull/52618

编译构建工具DevEco Hvigor（以下简称Hvigor）是一款基于TS实现的构建任务编排工具，主要提供任务管理机制，包括任务注册编排、工程模型管理、配置管理等关键能力，提供专用于构建和测试应用的流程和可配置设置。

DevEco Studio使用构建工具Hvigor来自动执行和管理构建流程，实现应用/服务构建任务流的执行，完成HAP/APP的构建打包。

Hvigor可独立于DevEco Studio运行，这意味着，你可以在DevEco Studio内、命令行工具或是集成服务器上构建应用。无论您从命令行工具或是DevEco Studio上构建项目，构建过程的输出都将相同。

了解任务

任务是Hvigor构建过程中的执行基本单元，任务中通常包含一段编译过程处理的可执行代码；一个任务可以依赖其他多个任务。Hvigor任务调度执行时通过解析依赖关系确定任务执行时序。

UP-TO-DATE

任务标识，表示任务未实际执行。Hvigor任务增量跳过机制，在二次执行任务时检测任务输入输出条件未发生变化，则任务跳过执行提高构建效率。例如

hvigor UP-TO-DATE ::PackageApp...

Finished

任务执行完成标识，表示任务已执行完成。例如

hvigor Finished ::PackageApp... after 310 ms

注册任务

使用HvigorNode节点对象注册任务。

1. 编辑工程下hvigorfile.ts文件。

// 导入模块
import { getNode, HvigorNode, HvigorTask } from '@ohos/hvigor';

2. 编写任务代码。

// 获取当前hvigorNode节点对象
const node: HvigorNode = getNode(__filename);

// 注册Task
node.registerTask({
    name: 'customTask',
    run() {
        console.log('this is Task');
    }
});

3. 执行任务。
   使用hvigor命令行工具执行任务。例如

hvigorw customTask

4. 查看任务执行结果。

PS D:\SDAutoTestRunInfo\AppDemo\MyApplication > hvigorw customTask
this is Task
> hvigor Finished :: customTask... after 2 ms
> hvigor BUILD SUCCESSFUL in 2 s 211 ms

一、问题

假设存在这样的时钟控制模型：

CLK1、CLK2以及系统时钟的频率与相位均不一致，我们希望在clk_sel=1时，输出CLK1,反之输出CLK2，CLK_SEL可以由系统时钟驱动，也可以由组合逻辑驱动。那么在这种情况下就会出现以下的“毛刺”问题：

可以看到，在CLK_SEL的交界处，非常容易出现CLK_OUT时钟出现毛刺的现象，从而影响系统的正常工作。

二、解决方法

（以下方法出自B站UP：皮特派）

具体思路是：1.两个时钟互斥输出，即B4、B5两个非门作为最后的A2、A4的输入；

2.S3、S6寄存器采用下降沿驱动对sel进行同步，这样就可以在延迟一拍的情况下做到两个时钟无毛刺的输出。

分析如下：当sel为0时，ali_2初始值为0，ali_1为1，A1选通，随后在CLKA的驱动下对alo信号打两拍同步，随后S3在CLKA的下降沿对打拍同步的信号进行采样，这样在下降沿到后一个上升沿之前，由于CLKA为0，CLK-OUT始终拉低，而后CLKA为高，此时由于上个下降沿已经对ai2_2进行了同步，CLKA为1，且ai2_2为1，此时CLK_OUT输出为CLKA。
本质上是用延迟换准确性。

三、代码

根据上述的RTL，代码如下：

1. RTL

// // =============================================================================
// File Name    : clk_gating_module.v
// Module       : clk_gating_module
// Function     : Burr free clock switching
// Type         : RTL
// Aythor       : Dongyang
// -----------------------------------------------------------------------------
// Update History :
// -----------------------------------------------------------------------------
`timescale 1 ns/1 ns
module  clk_gating_module(
        input            sys_clk    ,
        input            sys_rst_n  ,
  
        input            i_clka     ,
        input            i_clkb     ,
        input            i_clk_sel  ,
        output           o_clk_out  

);

//******************** siganl define ********************
wire         a1i_1        ;
wire         a1i_2        ;
wire         a3i_1        ;
wire         a1o          ;
wire         a3o          ;
wire         a3i_2        ;
wire         a2o          ;
wire         a4o          ;
reg          a4i_2    =  'b0;
reg          a2i_2    =  'b0;
reg  [1:0]   a1o_dly  =  'b0;
reg  [1:0]   a3o_dly  =  'b0;  

//******************** assign  *****************************
assign   a1i_1 =   ~i_clk_sel         ;
assign   a3i_1 =    i_clk_sel         ;
assign   a1i_2 =    ~a4i_2         ;
assign   a3i_2 =    ~a2i_2         ;
assign   a1o   =   a1i_1 & a1i_2 ;
assign   a3o   =   a3i_2 & a3i_1;
assign   a2o   =   i_clka & a2i_2;
assign   a4o   =   a4i_2 & i_clkb;
assign   o_clk_out = a2o | a4o   ;

//**********************always*********************************
// CLKA domain
always @(posedge i_clka) begin
    if(~sys_rst_n) begin
        a1o_dly <= 'b0;
    end
    else begin
        a1o_dly<= {a1o_dly[0],a1o};
    end
end

always @(negedge i_clka) begin
    if(~sys_rst_n) begin
        a2i_2 <= 'b0;
    end
    else  begin
        a2i_2 <= a1o_dly[1];
    end
end

//CLK B domain
always @(posedge i_clkb) begin
    if(~sys_rst_n) begin
        a3o_dly <= 'b0;
    end
    else begin
        a3o_dly<= {a3o_dly[0],a3o};
    end
end

always @(negedge i_clkb) begin
    if(~sys_rst_n) begin
        a4i_2 <= 'b0;
    end
    else  begin
        a4i_2 <= a3o_dly[1];
    end
end

endmodule

2. TestBench

`timescale 1 ns/1 ns
module  tb_clk_gatting();

reg    clka   = 'b0;
reg    clkb   = 'b0;
reg    sys_clk = 'b0;
reg    sys_rst_n = 'b0;
reg    clk_sel  = 'b0 ;

initial begin
clka   = 'b0;
clkb   = 'b0;
sys_clk = 'b0;
sys_rst_n = 'b0;
clk_sel  = 'b0 ;
#6
clkb   = 'b1;
#100
sys_rst_n = 'b1;
#1000
clk_sel  = 1'b1;
#756
clk_sel  = 1'b1;
#1500
clk_sel  = 1'b0;
end

always  # 10   sys_clk = ~sys_clk;    //sys_clk     50M
always  # 50   clka    = ~clka   ;    // CLKA       10M
always  # 30   clkb    = ~clkb   ;     // CLKB     16.6M
clk_gating_module  U_clk_gating_module(
        .sys_clk    (sys_clk),
        .sys_rst_n  (sys_rst_n),
        .i_clka     (clka),
        .i_clkb     (clkb), 
        .i_clk_sel  (clk_sel), 
        .o_clk_out  ()

);

endmodule

四、仿真波形

前言

推荐一款集成了超过100款控件的流行 XAML 控件库，同时提供了一系列常用的 .NET 帮助类-CookPopularUI。它可以简化开发流程，让我们能够更加专注于核心业务逻辑的实现。

让我们一起学习如何使用 CookPopularUI，并详细了解其提供的丰富控件内容。

项目介绍

CookPopularUI
不仅提供了丰富的控件选择，包括但不限于数据网格、图表、导航菜单、对话框等，还特别注重于提升开发效率。通过内置的帮助类，可以轻松处理诸如数据绑定、异步操作、文件操作等常见任务，而无需从头开始编写大量代码。

另外，该控件库对多个版本的 .NET 提供了良好的支持，无论是 .NET Framework 还是 .NET Core/.NET 5+，都能确保应用的兼容性和稳定性。

项目特点

• 丰富的控件库：CookPopularUI 包含了多种类型的控件，如数据网格、图表、导航菜单、对话框等，满足不同应用场景的需求。
• 常用 .NET 帮助类：内置了大量 .NET 帮助类，简化了数据绑定、异步操作、文件处理等常见开发任务。
• 高度可定制化：所有控件都支持高度自定义，您可以根据自己的需求调整样式和行为。
• 良好的文档和示例：提供了详细的文档和丰富的示例代码，帮助您快速上手并高效开发。
• 多版本支持：支持多个版本的 .NET，无论是 .NET Framework 还是 .NET Core/.NET 5+，都能确保兼容性和稳定性。

项目使用

1、添加Nuget包引用

<PackageReferenceInclude="CookPopularUI.WPF"Version="1.0.1-preview2" />

2、添加如下代码即可全部引用（两种方式皆可）

<Application.Resources>
    <ResourceDictionary>
          <ResourceDictionary.MergedDictionaries>
              <!--<ResourceDictionary Source="pack://application:,,,/CookPopularUI.WPF;component/Themes/DefaultPopularColor.xaml" />-->
              <!--<ResourceDictionary Source="pack://application:,,,/CookPopularUI.WPF;component/Themes/DefaultPopularControl.xaml" />-->
              <ui:PopularThemeLanguage="English"Theme="Light" />
          </ResourceDictionary.MergedDictionaries>
    </ResourceDictionary>
</Application.Resources>

项目控件

1、Border

2、DataGrid

3、Message

项目地址

Gitee：
https://gitee.com/CookCSharp/CookPopularUI

总结

本文展示了部分功能和内容，如有需求访问案例地址获取详细信息。希望本文能在WPF控件开发方面为各位提供有益的帮助。期待大家在评论区留言交流，分享您的宝贵经验和建议。

最后

如果你觉得这篇文章对你有帮助，不妨点个赞支持一下！你的支持是我继续分享知识的动力。如果有任何疑问或需要进一步的帮助，欢迎随时留言。也可以加入微信公众号
[DotNet技术匠]
社区，与其他热爱技术的同行一起交流心得，共同成长！