最近在为 StarRocks 的物化视图增加多表达式支持的能力，于是便把物化视图（MV）的创建刷新流程完成的捋了一遍。

之前也写过一篇：StarRocks 物化视图刷新流程和原理，主要分析了刷新的流程，以及刷新的条件。

这次从头开始，从 MV 的创建开始来看看 StarRocks 是如何管理物化视图的。

创建物化视图

1
2
3
4
5
6
7
8
9
10
11

CREATE
MATERIALIZED VIEW mv_test99
REFRESH ASYNC EVERY(INTERVAL 60 MINUTE)
PARTITION BY p_time
PROPERTIES (
"partition_refresh_number" = "1"
)
AS
select date_trunc("day", a.datekey) as p_time, sum(a.v1) as value
from par_tbl1 a
group by p_time, a.item_id

原文链接：[ On | No ] syntactic support for error handling

关于 Go 语言最有争论的就是错误处理：

1
2
3
4

x, err := call()
if err != nil {
        // handle err
}

if err != nil 类似于这样的代码非常多，淹没了其余真正有用的代码。这通常发生在进行大量API调用的代码中，其中错误处理很普遍，只是简单地返回错误，有些最终的代码看起来像这样：

1
2
3
4
5
6
7
8
9
10
11
12

func printSum(a, b string) error {
    x, err := strconv.Atoi(a)
    if err != nil {
        return err
    }
    y, err := strconv.Atoi(b)
    if err != nil {
        return err
    }
    fmt.Println("result:", x + y)
    return nil
}

背景

Code Review 是大家日常开发过程中很常见的流程，当然也不排除一些团队为了快速上线，只要功能测试没问题就直接省去了 Code Review。

我个人觉得再忙的团队 Code Review 还是很有必要的（甚至可以事后再 Review），好处很多：

• 跳出个人开发的思维误区，更容易发现问题
• 增进团队交流，提高整体的技术氛围
• 团队水平检测器，不管是审核者还是被审核的，review 几次后大概就知道是什么水平了

通常 Code Review 有两种场景，一种是公司内部，还有就是开源社区。

最近我们在使用 StarRocks 的时候碰到了一些小问题：

• 重启物化视图的时候会导致视图全量刷新，大量消耗资源。
  - 修复 PR：https://github.com/StarRocks/starrocks/pull/57371
• excluded_refresh_tables 参数与 MV 不在一个数据库的时候，无法生效。
  • 修复 PR：https://github.com/StarRocks/starrocks/pull/58752

而提交的 PR 是有发布流程的，通常需要间隔一段时间才会发布版本，但是我们线上又等着用这些修复，没办法就只有在本地打包了。

好在社区已经考虑到这种场景了，专门为我们提供了打包的镜像。

前段时间申请成为了 OpenTelemetry 的 Member 通过了，算是完成了一个阶段性目标；从 24 年的 2 月份的第一个 issue 到现在刚好一年的时间。

前段时间升级了生产环境的 StarRocks，从 3.3.3 升级到了 3.3.9，期间还是踩了不少坑所以在这里记录下。

因为我们的集群使用的是存算分离的版本，也是使用官方提供的 operator 部署在 kubernetes 里的，所以没法按照官方的流程进入虚拟机手动启停对应的服务。

只能使用 operator 提供的方案手动修改对应组件的镜像版本，后续的升级操作交给 operator 去完成。

这些年我一直都是按照农历新年来写年终总结的，都说不出正月都是年，前些年一直都比较规律，今年确实是时间超了一些。

主要原因还是年末接了个活，需要在年初上线，导致这段时间都没太多时间写内容。

最近事情终于告一段落后才开始码字。

前段时间碰到一个 StarRocks 物化视图的 bug: https://github.com/StarRocks/starrocks/issues/55301

但是这个问题只能在存算分离的场景下才能复现，为了找到问题原因我便尝试在本地搭建一个可以 Debug 的存算分离版本。

之前也分享过在本地 Debug StarRocks，不过那是存算一体的版本，而存算分离稍微要复杂一些。

这里提到的本地 Debug 主要是指可以调试 FE，而 CN/BE 则是运行在容器环境，避免本地打包和构建运行环境。

前段时间有朋友问我如何在 kubernetes 里搭建监控系统，恰好在公司也在维护内部的可观测平台，正好借这个机会整理下目前常见的自建监控方案。

一个完整的监控系统通常包含以下的内容：

• 指标暴露：将系统内部需要关注的指标暴露出去
• 指标采集：收集并存储暴露出来的指标
• 指标展示：以各种图表展示和分析收集到的数据
• 监控告警：当某些关键指标在一定时间周期内出现异常时，可以及时通知相关人员

对于 k8s 的监控通常分为两个部分：

• k8s 自带的系统组建
• 业务 Pod 暴露出来的监控指标

安装 Istio

最近这段时间一直在做服务网格（Istio）相关的工作，背景是我们准备自建 Istio，首先第一件事情就是要安装。

我这里直接使用官网推荐的 istioctl 进行安装：

1
2
3
4
5
6
7
8
9
10
11
12

$ cat <<EOF > ./my-config.yaml
apiVersion: install.istio.io/v1alpha1  
kind: IstioOperator  
metadata:  
  namespace: istio-1-18-5  
spec:  
  profile: minimal  
  revision: istio-1-18-5  
  meshConfig:  
    accessLogFile: /dev/stdout
EOF
$ istioctl install -f my-config.yaml -n istio-1-18-5

这里我使用的 profile 是 minimal，它只会安装核心的控制面，具体差异见下图：