- 博客(427)
- 资源 (1)
- 问答 (4)
- 收藏
- 关注
RSS订阅原创 从一到无穷大 #96：Embedding 模型选型——评测方法与 Memory 系统的现实约束
从 OpenRouter 的推荐出发，讨论 Embedding 模型的业务评测、chunk 与维度实验，以及 Memory 系统中的吞吐、500ms 召回时限、企业资源供给和索引存储成本。
2026-10-05 23:46:01
294
原创 从一到无穷大 #95：Cloudflare 的可观测性进展——统一查询、链路追踪与平台战略
Cloudflare 将日志、Trace、Analytics、告警和查询接口整合到统一平台。本文梳理请求追踪、SQL 查询、Agent 排障与计费的进展和限制，并讨论 AI 接入、数据飞轮、业务黏性与独立营收的可能性。
2026-10-05 23:36:26
364
原创 问津集 #25：DiTing——统一存储与查询下推的架构取舍
DiTing 提前生成 1 分钟、5 分钟、1 小时等粒度的平均值、和、最大值、最小值，减少查询时读取和返回的数据。DiTing 的统一 SQL 建立在前面的关系表模型上：Metrics、Logs、Traces 保留各自的 Schema，底层共用 co-Log，查询经同一套分层执行体系完成。三类信号之间的关联有直接的实验支撑。论文将查询组件和 Zone Storage 分开描述，但 AZ 数据实际存放在承担 Mixer、Leaf 角色的机器上，[1] 因此不能仅凭架构图就认定存储、计算已经完全独立伸缩。
2026-10-05 22:55:43
269
原创 从一到无穷大 #94：ClickHouse TimeSeries——时间线组织与 Prometheus 兼容性
整体性能和存储量还需要测试。比较时应把 Tags、索引和 Recent Samples 一起算进去，不能只看 Samples 的压缩率。2026 年 1 月融资时，ClickHouse 的估值已经达到 150 亿美元。[34] 对一家有这种资源规模和技术积累的公司，我认为这些软件问题不构成长期门槛，追赶乃至超越是时间问题。当前的兼容性和执行效率缺口，很难成为 Metrics 产品长期依赖的护城河。我在《从一到无穷大 #86》中提到，公有云里的托管 ClickHouse 团队应该有更大的野心。
2026-09-19 16:44:55
216
原创 从一到无穷大 #93：从收购看 AI 与互联网公司的能力扩张
从 OpenAI、Anthropic、智谱到 Google、AWS、微软、腾讯、字节与阿里，梳理科技公司的收购、团队引入、投资和资产退出，观察它们如何补充技术、人才、客户与基础设施能力，并结合中美创投数据理解创业公司的成长空间。
2026-09-13 16:08:55
344
原创 从一到无穷大 #92：技术人的产品思维——从工程判断到组织价值
例如以一个季度为周期，明确要改善的业务问题、验证的战略假设和降低的运营负担，同时约定投入与复查时间。业务交付看使用效果和成本变化，战略探索看真实场景、关键能力与合作是否得到验证，运营治理看重复问题和人工负担是否下降。关键假设变化时应提前复查。复查后应有资源上的变化：有效的方向追加投入，假设不成立的项目转向或停止，更合适的方案替换旧方案，并安排迁移和退役。已有投入不能成为继续投入的唯一理由。优胜劣汰应落实到方向、方案与资源分配，同时给长期探索合理的验证周期。评价机制还会影响团队怎样协作。
2026-09-12 18:07:28
254
原创 从一到无穷大 #91：从 Habitat 看存储平台的整合与分工
从 Habitat 由 Python SDK 到独立服务、再到 Rust 的演进出发，对比 InstantDB 与内部存储平台的服务范围，讨论 Agent 存储整合的机会，以及业务特化和组织分工对通用平台的约束。
2026-09-12 18:04:13
350
原创 问津集 #24：LiquidCache——面向过滤的缓存编码与计算下推
对象存储中的权威数据继续使用 Parquet，Liquid 则作为可重建的缓存副本，既可以驻留内存，也可以在淘汰时写入缓存节点的磁盘。后台转码有收益，也有可观测的代价。LiquidCache 在缓存层将 Parquet 转成 Liquid 表示，并将编码方式与过滤执行一起设计：保留较高压缩率，支持按元素访问，只解码当前过滤步骤需要的数据，适用时直接在编码上完成比较。当 Arrow 数据放不进缓存时，Liquid 的体积优势可以减少缓存未命中后的磁盘读取或回源，省下的 IO 时间可能超过新增的解码时间。
2026-09-11 23:00:01
434
原创 从一到无穷大 #90：Go 标准库补丁如何进入业务构建
本文 MR #80890 已核查的修订涉及 runtime 源码与测试，将补丁移植到固定的 Go 基线后，可以通过 overlay 随业务构建带入。[1] 标准库会按包重新编译；涉及编译器、链接器自身的修改，才需要先重建相应工具。把 patch、上游 revision 和回归用例放进仓库，固定 SDK，并让测试与构建共用同一份 overlay。发布前核对产物中的补丁特征、完成回归，保存补丁与产物摘要。等采用的官方发行版包含修复后，再移除本地补丁，用干净 SDK 重建并完成相同回归。
2026-09-10 19:54:48
149
原创 问津集 #23：Backward-Sort——时序数据的分块排序与反向归并
Backward-Sort 利用时序数据的局部乱序特征，通过区间逆序率选择块长，结合块内排序与反向归并，减少 MemTable 时间排序中的比较和重复搬动。本文梳理论文的算法、TVList 实现、实验结果，以及这一基础优化在实际系统中的适用条件。
2026-09-06 13:12:26
338
原创 问津集 #22：MCC——多列时序数据的空间放大与合并文件选择
MCC 在 Compaction 前预读 Key 和 Bitmap，估算合并收益，并通过 DAG 约束维护更新版本的可见性。本文梳理成本模型、搜索算法、实验收益与运行代价，结合共享时间戳场景讨论其工程价值，并核对公开代码与论文方案的差别。
2026-09-06 12:51:55
320
原创 问津集 #21：两阶段 LSM——乱序整理与小文件合并的分工
论文将时序数据 Compaction 拆成乱序文件整理和顺序小文件合并两个阶段：前者减少近期查询需要读取和归并的重叠文件，后者减少历史范围查询中的零碎读取。本文结合 Apache IoTDB 实验，分析其查询收益、写放大代价和调度边界。
2026-09-05 18:11:42
309
原创 从一到无穷大 #87：AgentState 的产品定位与设计取舍
最近我的一个工作重点是负责 Agent 存算分离中的 AgentState 存储，以支持国内某头部AI产品。我之前讨论过一条更彻底的部署路线：如果会话、任务进度，以及继续执行需要的文件和制品都已在云端持久化，Agent Loop——调用模型、选择工具、处理结果的循环——也可以由云端托管，本机只保留交互入口和受控的 Tool Endpoint。用户关掉电脑，云端仍能推进不依赖本机的任务；换到手机或另一台电脑，也能查看同一任务的已提交状态和制品。
2026-09-05 17:53:54
825
原创 问津集 #20：Deferred Flushing——延后刷盘如何减少乱序合并
解读 Apache IoTDB 的 Deferred Flushing：通过保留最新数据减少乱序引起的文件重叠与写放大，并分析保留区大小、写入开销和实现限制。
2026-09-05 16:15:55
360
原创 问津集 #19：Separation or Not——乱序数据分流的写放大建模与策略选择
本文围绕 IoTDB 的乱序数据分流设计，梳理单 MemTable 与顺序/乱序双 MemTable 的写放大模型、容量选择和动态策略，并结合实验讨论其进入生产系统时面临的目标函数与负载建模限制。
2026-09-05 00:24:16
382
原创 从一到无穷大 #86：ClickHouse 收购 RunReveal——可观测性竞争进入宏观调控阶段
这里的 Workload 指一组共同决定产品形态的负载与业务约束：数据由谁产生，怎样进入，Schema 如何演化，写入峰值多高，默认查询扫多少时间，哪些结果需要预计算，调查过程中会连续发出多少次查询，最后又由哪一类人为结果付费。同一个 ClickHouse Engine，跑 Infra Observability、LLM Observability 和 Security Analytics，产品形态完全不同。
2026-09-02 21:17:52
562
原创 问津集 #18：Timon——Time-partitioning Tree 的预计算与乱序数据分流
TS-LSM-Tree 不算是 Timon 的创新。去掉名字以后，它的外壳就是 TSM/LSM：MemTable、按时间组织的不可变文件，再加后台 Compaction。分离 Normal/Late MemTable 也不是多新鲜的结构，IoTDB 已经把相近思路扩展成 Sequence/Unsequence Space 和一整套 Cross-space Compaction。更值得看的还是 Time-partitioning Tree。
2026-09-02 19:33:04
352
原创 问津集 #17：Terark-DS——KV 分离后的 WAL 写入、冗余策略与 GC
Terark-DS 根据 WAL、Key SST 和 Value SST 的访问模式分别选择远端存储策略。WAL 需要控制提交延迟并支持恢复，Key SST 需要低延迟小 I/O，Value SST 更关注容量与大块吞吐，GC 则要减少无效 Value 传输和 RPC 次数。统一三副本会增加 Value SST 的容量与流量，全 EC 又会提高 Key SST 的小 I/O 延迟，因此论文分别使用 Quorum、三副本和 EC，并单独改造 WAL 与 GC 路径。
2026-09-01 22:46:34
400
原创 问津集 #15：RangeReduce——查询驱动 Compaction 收益
RangeReduce 最直接的优势是复用 Range Query 已经完成的 I/O、k-way merge、旧版本去重和 Tombstone 过滤。将这批有效 Entry 写入更深层以后，后续 Compaction 可以少读、少归并一部分数据，相同或重叠范围的查询也能少访问一些 Run。长 Range Query、查询范围反复重叠，以及更新和删除较多的负载，更容易覆盖本次写回成本。[1]它的代价也很明确：写 SST 的开销会立即进入当前查询。短而随机的 Range Query 很难复用这次整理结果；
2026-08-30 17:56:28
393
原创 从一到无穷大 #85：OpenAI × Hugging Face——一条留言如何变成 700 个 Agent 的攻击网络
一个 Agent 卡在缺失的蛋白质数据库文件上。不同训练任务之间没有通信工具，它便在 OpenAI 内部的 Artifactory 里留下一句话：[1]谁有这个文件，上传一下。一个 Agent 控制了客户托管在 Modal 上的 CyberGym 应用，随即向留言板更新进展：[2]发现 Modal 应用内的远程代码执行能力。OpenAI 没有披露下一条留言的精确时间；按官方叙述顺序，它出现在 7 月 11 日 Hugging Face Worker 被执行代码之后：[2]让整个swarm。
2026-08-30 12:22:34
343
原创 问津集 #14：CaaS-LSM——把 Compaction 变成存储侧共享服务
这套架构适合同时满足几个条件的系统：大量 LSM 实例共享远端存储，实例之间的 Compaction 强度不均匀，存储附近可以部署计算资源，而且 Compaction 输入能够被封装成独立任务。单机 NVMe、实例数量很少、顺序写以 Trivial Move 为主时，共享控制面提供不了多少收益。论文自己的顺序读写实验也是这个结果。[1]我的重点在于调度。一个 Compaction Task 默认需要多少 CPU 和内存，可以先根据参与 Compaction 的数据量给出预算，再用实际完成时间修正；
2026-08-29 17:59:34
375
原创 问津集 #13：FlexEngine—多租户的精细化 I/O 控制
我认为 FlexEngine 很优雅，原因是这套设计几乎顺着工程问题自然长出来。假设一个 Pod 承载 2000 个数据分片，删除、Checkpoint、正排与倒排索引的 Compaction 都可以直接向存储发起请求，前台读写迟早会被拖住。到了这个规模，后台任务不能再各自为政，精细化调度是必需品。上面的 2000 个分片及索引任务来自我对一般存储系统的延伸，论文没有披露这些部署细节。文中每个租户分片对应一棵独立的 LSM-tree，后台控制主要覆盖 Flush 与 Compaction。
2026-08-28 17:35:47
365
原创 从一到无穷大 #84：AWS 收购 DuckLabs——DuckDB 与分析系统正在变化的物理边界
2026 年 8 月 26 日，AWS 与 DuckLabs 签署最终收购协议，预计 9 月初完成交割。交易金额没有披露，30 余人的团队留在阿姆斯特丹，Hannes Mühleisen 与 Mark Raasveldt 继续负责团队及开源项目的技术方向。[1][2]严格来说，AWS 收购的是 DuckLabs 公司，不是 DuckDB 开源项目。DuckDB、DuckLake、Quack 的核心 IP 与商标仍由独立的 DuckDB Foundation 持有，代码继续使用 MIT 协议。
2026-08-27 21:51:36
432
原创 问津集 #12：Calcspar：相同 Paid IOPS 下的 RocksDB 尾延迟优化
我认为 Calcspar 解决的问题确实比较小。它聚焦于按 paid IOPS 计费、超限后出现显著延迟惩罚的 EBS 类云块存储，目标可以压成一句话：在相同 paid IOPS、也就是相同云盘成本下，降低 RocksDB 的平均延迟和尾延迟。论文没有给出一套通用的 LSM Compaction 算法，也没有覆盖对象存储、共享 Volume 或带宽受限设备。它处理的是一个很窄的工程切口。[1]这个小问题做得很漂亮。
2026-08-27 18:54:51
405
原创 问津集 #11：HATS——把 Replica Selection 与 Compaction 放进同一个闭环
将读一致性级别提高到 3 后，所有副本都必须读，HATS 相对 DEPART 的吞吐收益从 42.9% 缩到 24.5%，P99 收益从 48.1% 缩到 25.0%。它的风险同样直接：多个 Coordinator 依据略有滞后的延迟观测，把请求转向同一个看起来还有余量的节点，可能让被转发节点的 CPU、I/O 与查询队列继续堆积。某个副本刚 Flush 出一批 SSTable，另一个副本正在跨 Level 做 Compaction，它们面对同样的读请求，存储引擎里的查找路径与资源竞争完全不同。
2026-08-26 22:24:11
357
原创 问津集 #10：Time-Tiered Compaction
时序数据的写入通常按时间追加，更新较少，范围查询较多。LSM-tree 先在 Memtable 中缓冲写入，再顺序 Flush 为不可变 SSTable，适合这类写密集负载。随着 SSTable 数量增加，一次范围查询可能访问多个文件，Compaction 需要通过归并控制文件数量和查询开销。[1]论文将存储介质限定为 HDD，并据此提出两个现有方法的缺口：通用 LSM-tree Compaction 主要根据 Level、文件大小和容量阈值执行静态策略，没有利用时序查询的窗口长度与新数据热点。
2026-08-25 14:26:43
361
原创 从一到无穷大 #83：Codex 任务到底运行在哪里——执行 Host、跨端连续性与记忆边界
目前没有公开、统一的 Cowork MAU 统计。开头这张 AICPB 榜单适合观察单品分布，本文不把它加总成市场规模。CNNIC 给出的基线更稳：截至 2025 年 12 月，中国生成式 AI 用户达到 6.02 亿，普及率为 42.8%。[1] 这个口径比 Cowork 宽，但至少说明 AI 已经成为大规模软件入口。QuestMobile 进一步拆到了终端形态：截至 2026 年 5 月，PC 网页端 AI 应用 MAU 为 1.72 亿，PC 客户端为 1800 万，后者同比增长 20.1%。
2026-08-20 23:21:16
495
原创 从一到无穷大 #82：Agent Memory Eval 中的 Harness 选择
前面的博客里，我提出 Agent Memory 系统在发版前要先做离线评估。前文已经固定了 Memory、Model、Task 和 Environment。这一篇只看剩下的 Harness 变量：不同 Harness 在哪里调用 Memory，以及怎样选择，才能尽量减少它对 Memory 评估结果的干扰。
2026-08-17 21:45:48
310
原创 问津集 #9：Tencent WorkBuddy Bench
Tencent WorkBuddy Bench 把任务写成可移植的 Workspace，把 Verifier 放到 Episode 之后。260 是规模，背后的测试基础设施更值得带走。拿它评 Agent Memory，我会先从 Security 的调查 → 规则生成开始，再补 Code 的同仓库兄弟任务。WorkBuddy Bench 已经省下容器、Harness、Artifact 和 Verifier 这套端到端基础设施，任务之间的关系仍然要自己补。
2026-08-16 20:07:42
382
原创 从一到无穷大 #81：Agent Memory Benchmark 与Memory发版评估
一起看两个 Benchmark 任务。一个 Code Agent 被放进固定版本的开源仓库，根据一句没有给出具体文件位置的需求修改代码。它完成修改并退出容器后，评测框架才会加载一组对 Agent 隐藏的测试用例，重新构建项目、运行测试，并据此判断补丁是否正确。这类任务有repository、commit、环境镜像和 hidden tests，结果不一定容易做对，至少可以比较明确地判断做没做对。换成 RCA，情况立刻麻烦很多。
2026-08-16 18:26:25
577
原创 从一到无穷大 #78：Agent Memory Eval
写清本次改变 writer、evolution、retriever 还是 reranker，以及期望改善的场景字段和任务结果。例如 writer 提高临时 scope 的准确率，reranker 提高 Evidence Sufficiency，同时不增加敏感写入和 Negative Transfer。
2026-08-13 23:08:10
377
原创 从一到无穷大 #80：统一可观测查询到底在统一什么
下面两段查询都在算请求速率。PromQL 的rate()已经认识 Counter、Range Vector 和 Reset。SQL 认识行、窗口函数和算术，所以这些语义要进入 Schema、SQL 模板或查询作者的脑子。[1]Grafana 选择了另一条路：Mimir 用 PromQL，Loki 用 LogQL，Tempo 用 TraceQL，Pyroscope 用 FlameQL。Grafana Assistant 可以根据自然语言生成四种查询，底层语言仍然各自工作。[2]我的重点在这里。
2026-08-11 23:40:25
246
原创 问津集 #8：EROICA——把 3 GB Profiling 数据压成 30 KB
写到这里，我反而觉得不该把 ARGUS 和 EROICA 当成两条可以互相替换的生产 Profiling 路线。它们首先解决的就不是同一个问题。ARGUS 的主线是持续识别 fail-slow。L1—L3 用常驻统计发现异常，再把范围收窄到 Rank、训练阶段和 Kernel；L4、L5 保留完整 GPU Trace 与 CPU Call Stack，供工程师继续下钻细节、确认根因。EROICA 关心的是某个训练事件为什么慢，论文里的触发单位是 Iteration。
2026-08-09 21:59:36
352
原创 从一到无穷大 #77：Continuous Profiling 的文件，为什么还不是可查询的存储
再回头看开头那张表，Binary、JSON、Protobuf 决定文件怎样写；它能回答哪些问题，取决于数据模型保留了什么；它能不能在对象存储上查，取决于有没有 Block Layout、Catalog、Index、Symbol 和接得上的 Query Engine。我这次在本机用 py-spy 采到 631 个 Stack Sample。
2026-08-09 21:02:10
365
原创 从一到无穷大 #76：大模型可观测性——从性能诊断到稳定性闭环与统一数据底座
大模型可观测性还有一个论文里较少展开的落地问题。GPU 环境和司内 IDC 经常处在隔离网络中，链路也未必稳定，私有化部署很容易从一个选项变成前提。私有化又会把依赖一起拖进来：司内 Kubernetes、对象存储、Catalog、消息链路、权限和升级体系都要打包，或者逐项适配已有设施。对小团队来说，这接近再维护一套基础设施，长期的部署、升级和运维投入比实现几个诊断算法更重。Profiler 已经很擅长保存现场。
2026-08-09 18:57:02
391
原创 从一到无穷大 #75：从统一 Tag 到 UModel——可观测数据为什么还需要建模
上一篇 Gartner 可观测魔力象限的文章里，我提到了两个设计：Datadog 用统一 Tag 关联遥测，阿里云 CMS 2.0 用 UModel 描述应用、资源、拓扑、告警和变更。这篇继续往下拆，只讨论数据怎样拼起来。先看四条记录。四条记录各自都成立。告警从 Metric 开始时，系统还要判断和是否指向同一个服务，prodproduction和online也要再翻译一次。数据一多，临时 Join 很快就变成排障流程的一部分。
2026-08-08 17:39:40
363
原创 问津集 #7：ARGUS——万卡训练集群里的常驻追踪与渐进式诊断
ARGUS 留下的几个设计很实在。先按训练调用层级拆信号，避免一个 Profiler 为了完整而把所有成本都压进热路径；再把数据拆成 Metric 与 Trace 两条链路，前三层查统计结果，后两层回到完整现场；最后把 Parallelism Topology 当成诊断语义，同角色比较，逐步收窄 Rank、时间窗和 Kernel。Profiler 要在万卡集群里常驻，最后会变成一个数据基础设施问题。采集开销只是门票，后面还有表示、路由、存储、实时计算和人工确认。
2026-08-05 23:13:00
451
原创 从一到无穷大 #72：AgentLogsBench 拆解——Agent 可观测性为什么需要多种索引
回到开头那行 observation，它同时是文档、动态 JSON、Trace 节点和指标事实。这就是 Agent 日志和传统日志相比最麻烦的变化。单一物理结构很难兼顾这四种访问模式。现有系统通常用列存处理聚合，用全文索引处理大文本检索，用 keyword 倒排处理trace_id等结构化字段的等值查询，再通过动态子列承接不断变化的 payload；Trace 内部的顺序则交给排序键。全文索引与 keyword 索引底层都可以使用倒排表，只是保存的信息和查询语义不同。
2026-08-05 17:06:44
383
原创 # 从一到无穷大 #73：Gartner 2026 可观测魔力象限——标准是什么，以及阿里云、腾讯云、Datadog 差在哪
2026 年 7 月 13 日，Gartner 发布新一版《可观测平台魔力象限》（Magic Quadrant™ for Observability Platforms）。阿里云第一次进入“挑战者”象限，也是亚太地区唯一入选的厂商；腾讯云没有出现在这份名单里。我更想弄清楚的不是谁进了象限，而是这份榜单到底在考什么。本文先拆 Gartner 的几把尺子：入围门槛、强制能力清单、两轴 15 项标准，还有配套的 Critical Capabilities 用例评分。
2026-08-04 16:45:32
608
GCC 10.2 2020年7月23日发布
2020-10-01
出现内存泄露，但是用valgrind和mtrace都没办法找到泄露位置。
2020-07-02
做操作系统实验的时候编译内核出现问题，
2020-09-27
这段简单实现switch的汇编代码如何修改?
2020-06-02
TA创建的收藏夹 TA关注的收藏夹
TA关注的人