背景

前段时间有朋友问我关于 spring cloud 的应用在调用到 Go 的 API 之后出现 Trace 没有串联起来的问题。

完整的调用流程如下：

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

┌──────┐             
│Client│             
└┬─────┘             
┌▽──────────────────┐
│SpringCloud GateWay│
└┬──────────────────┘
┌▽──────────────┐    
│SpringBoot(app)│    
└┬──────────────┘    
┌▽──────────┐        
│Feign(http)│        
└┬──────────┘        
┌▽─────┐             
│Go Gin│             
└──────┘             

之前写过一篇 StarRocks 开发环境搭建踩坑指北之存算分离篇讲解如何在本地搭建一个可以 debug 的存算分离版本。

但最近在本地调试一个场景，需要 CN 节点是以集群的方式启动，我还是按照老方法通过 docker 启动 CN，然后 export 端口的方式让 FE 进行绑定。

比如用以下两个命令可以启动两个 CN 节点。

1

docker run -p 9060:9060 -p 8040:8040 -p 9050:9050 -p 8060:8060 -p 9070:9070 -itd --rm --name cn -e "TZ=Asia/Shanghai" starrocks/cn-ubuntu:3.5.2

1

docker run -p 9061:9060 -p 8041:8040 -p 9051:9050 -p 8061:8060 -p 9071:9070 -itd --rm --name cn2 -e "TZ=Asia/Shanghai" starrocks/cn-ubuntu:3.5.2

最近在为 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 则是运行在容器环境，避免本地打包和构建运行环境。