2025 年终总结

每次到年底就多愁善感~

工作篇

2025年,工作整体平淡但稳定。我与另一位同事共同负责多个存量项目的维护与迭代,项目规模大、历史包袱多,大部分精力只能用于满足客户日常需求、修复问题和保障系统稳定。新功能开发空间有限,几乎无法推进较大创新。

2026年:“守住底线、稳中求进”

投资篇

2025年:个人投资收益率约为78%,较2024年的130%大幅回落,但仍属于较高水平。主要原因在于本金基数较小,且积极参与今年Alpha空投活动。

全年主要投资动作:

  1. 5月清仓全部A股持仓,转为持有现金和Web3资产,主要考虑本金有限、精力不足,无法兼顾多条赛道。回头看,错过了从3000到4000这波牛市,但是不遗憾,4月还是俄乌战争、中美关税战、举国各个行业都很惨淡,谁能预知未来
  2. 9万元附近清仓比特币,1000美元以上区间陆续清仓BNB,虽然每个都没拿到最大利润,但是好在回撤相对较小。
  3. 积极参与多个Alpha项目空投活动,该部分贡献了全年收益的近一半,但已明显感受到竞争加剧、收益可持续性下降的趋势。

2026年:任何赛道一旦参与者增多,超额收益都会迅速均值回归。alpha赛道的收益已经不做期望了。2026年的投资目标是继续积累本金,保持耐心,等待合适机会低位回补,同时探索是否有新的低风险高收益路径。同時也清醒认识到,本金越大,维持高收益率的难度越高,需更加注重资产配置的稳健性(还没大到这个步骤,时机到了还是要敢于下注)。


VictoriaMetrics 存储机制逻辑分析

VictoriaMetrics 是后出的一款面向可观测指标的时序数据存储和查询引擎, 传闻比prometheus 查询性能强,存储成本还低,我们也有做指标数据平台,特来学习下

以下分析基于 v1.45.x 版本

1. 核心结论

VictoriaMetrics 的存储设计可以概括为以下几点:

  • 使用 vminsertvmstoragevmselect 分离写入、存储与查询职责;
  • 采用 Prometheus 风格的单值时序模型,每个数据点由时间戳和浮点数值组成;
  • 根据指标名和标签生成时间序列标识 TSID
  • 将标签索引与原始时序数据分开存储;
  • 原始数据按 TSID 聚合,并将时间戳和值分别进行列式压缩;
  • 数据先写入内存,刷盘后形成不可变的 Part,再通过后台 Merge 合并;
  • 按月建立数据分区,通过 smallbig 两级目录平衡近期数据的读取速度与历史数据的压缩率;
  • 索引和数据均采用分层文件结构,通过元索引缩小读取范围;
  • 不依赖传统 WAL,在异常退出时可能丢失尚未刷盘的数据。

2. 集群架构

VictoriaMetrics 集群由三个核心组件组成。

组件 主要职责
vminsert 接收写入请求,通过一致性哈希将数据分发到不同的 vmstorage 节点
vmstorage 保存标签索引和时序数据,并执行本地检索
vmselect 接收查询请求,从一个或多个 vmstorage 节点读取数据并汇总结果

三个组件可以分别扩容。vmstorage 采用 Shared-Nothing 架构:节点之间不共享数据,也不需要互相通信。这种结构降低了节点间协调成本,使扩容和故障隔离更简单。


VictoriaMetrics 写入吞吐和数据压缩比 测试

测试结果

对比项 X2.0 vectoria metircs score
写入吞吐 x 886k/s(1.66m/s)
压缩比(源json) x 0.22%

benchmark 数据源配置

pod 4c6G

数据生成速率

1
2
3
3000*1230 active time series
scrapeInterval 10秒,1230*3K/10 369k samples/sec
每10分钟 更新10% time series

数据协议,prometheus remote write

数据格式(转json 后)

1
2
3
{"metric":{"__name__":"node_scrape_collector_success","job":"node_exporter","instance":"host-2362","collector":"mdadm","replica":"0","revision":"r0","url_replica":"0"},"values":[1],"timestamps":[1724313603243]}
{"metric":{"__name__":"node_textfile_scrape_error","job":"node_exporter","instance":"host-1398","replica":"0","revision":"r5","url_replica":"0"},"values":[0],"timestamps":[1724313609919]}
{"metric":{"__name__":"node_textfile_scrape_error","job":"node_exporter","instance":"host-1902","replica":"0","revision":"r0","url_replica":"0"},"values":[0],"timestamps":[1724313604325]}

指标数据逻辑存储模型

指标数据逻辑存储模型

常见的时序数据库的数据模型,主要分成单值模型和多值模型

单值模型是根据业务指标数据建模,按照单个指标的细粒度进行数据使用和逻辑存储,如下所示,一行数据只有一个指标值,即value列。目前采用单值模型的时序数据库,有OpenTSDB、 KairosDB、Prometheus等。

1
2
3
4
单值模型:
time host metric value
2026-08-08 10:00:00 web01 cpu_usage 72
2026-08-08 10:00:00 web01 io_usage 31

多值的模型则是针对数据源建模,我们每一行数据针对的是一个数据源,它的被测量的多个指标在同一列上,如下所示,一行数据有多个指标值,即有cpu和io两列。目前采用多值模型的时序数据库,有InfluxDB、TimescaleDB等。

1
2
3
多值模型:
time host cpu_usage io_usage
2026-08-08 10:00:00 web01 72 31

可以把两者理解为:

  • 单值模型:一条时序记录只描述一个指标。
  • 多值模型:一条时序记录同时描述同一数据源在同一时刻的多个指标。

严格来说,多值模型中的多个指标是放在同一行的不同列/字段中,而不是同一列。


2024 年终总结

bye 2024 , hi 2025

写得有点晚,没有赶上新年,只能在除夕思索片刻,提笔记录下过去的一年

回顾计划

先说2023年底定的目标,2024大多都没有完成,最主要目标大致为3个:

  1. 首先是300公里的跑步,大概完成了一半,最主要是为了跑马拉松,提前2个月训练跑的,日常几乎不会去跑,倒是今年跟着同事经常去打羽毛球,
  2. 其次每个月的俩篇blog,几乎都暂停了,其实记录的很多,但是整理和发布出来太少。年底还接了5门课程的开发和录制,这个对我帮助挺大,从没有哪个会要求这么全面的了解一门技术,做课程你必须全面,所以相当于完整的复习了一遍对应的知识
  3. 最后是要点亮github 一半的格子,这个也是几乎没动了,之前还想从0开始做一款数据分析的系统软件,今年完全没有动力了,在前几年这个可能还有一定的先进性,现在来看已经意义不大,在经济下行的今天,头部的几家公司活的都很艰难,个人开发者再切入门槛这么高的领域,几乎没有成功的可能性

虽然大都没完成,今年总结时,可能是年纪大了,脸皮厚了,反而不再对自己感到内疚


macos 环境配置

应用安装

WPS 国际版、IDEA、Typora、微信、腾讯会议、阿里云盘、Chrome、Lemon、Iterm 、金山文档、QQ、VSCode、Clash Verge、企业微信..

开发环境

JAVA

SDKMan 因为它支持JVM的SDK,如Java、Groovy、Scala、Kotlin和Ceylon。还支持Gradle、Maven、Spring Boot和许多其他软件(Flink ,ActiveMQ,hadoop,spark)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
curl -s "https://get.sdkman.io" | bash
source "$HOME/.sdkman/bin/sdkman-init.sh"

# usage

sdk list java
sdk list gradle
sdk list maven

#Available Java Versions for macOS ARM 64bit
================================================================================
# Vendor | Use | Version | Dist | Status | Identifier
#--------------------------------------------------------------------------------
# Zulu | | 23.0.1.fx | zulu | | 23.0.1.fx-zulu
# 指定 Identifier
sdk install java 23.0.1.fx-zulu
sdk install maven
sdk install gradle

sdk current java
sdk uninstall scala 3.4.2

Column-Stores vs. Row-Stores

论文标题:Column-Stores vs. Row-Stores: How Different Are They Really?

论文: http://www.cs.umd.edu/~abadi/papers/abadi-sigmod08.pdf

概述

从论文的标题可以看出这篇论文不是陈述一种新的技术、架构,而更偏议论文一点,它主要的目的在于搞清楚对于分析类的查询为什么Column-Store比Row-Store好那么多?好在哪里?

一般认为原因是:

分析类查询往往只查询一个表里面很少的几个字段,Column-Store只需要从磁盘读取用户查询的Column,而Row-Store读取每一条记录的时候你会把所有Column的数据读出来,在IO上Column-Store比Row-Store效率高很多,因此性能更好。

而本文的目的是要告诉你Column-Store在存储格式优势只是一方面,如果没有查询引擎上其它几个优化措施的配合,性能也不会太好的,这篇论文认为Column-Store在查询引擎层有以下几种大的优化手段:

  • 块遍历(Block Iteration)
  • 压缩(Compression)
  • 延迟物化(Late Materialization)
  • Invisible Join

其中前三点是前人就已经总结过的、在现有Column-Store上实现过了的,而最后一点是本论文的创新。下面我们一一看一下这几种优化手段的细节,最后再看看它们优化效果的对比。


指标体系的应用场景 - 动态阈值

指标体系的应用场景 - 动态阈值

在指标体系的应用场景中,基于指标的告警也是指标数据的一个重要应用。

基于指标的告警一般有以下几种类型:

  • 静态阈值:大于/小于 某个具体的值则产生告警(对于明细数据,还可以用中位值/分位值进行阈值判断)
  • 同环比: 同比/环比 变化率/变化值 上升/下降超过多少产生告警
  • 动态阈值: 对比历史同时间段的基线值 产生告警
  • 异常检测:基于历史数据检测度量的异常行为。异常检测会检测指标的行为何时与过去不同,并考虑趋势和季节性
  • 离群点异常检测:离群点异常检测组内与其他成员相比异常的成员,主要用于判断指标的分组组合中哪些和其他组合差异过大
  • 预测告警:预测指标在未来的表现。通过在超出阈值之前发出警报

本篇主要介绍动态阈值的实现方案:


Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×