测试和实现，永远只改一边。

“交作业”的问题

目前很多人用 Agent 的手法就是照搬一个”交作业式”的 Agent workflow：

• 整理好需求/spec，例如”开发一个数据获取框架，要求实现功能 1 2 3 4 5”
• 把 spec 发给 Agent 做实现
• 审核 Agent 实现的代码
• 然后做对比实验/回放验证，争取”敢上线”
• 一旦发现问题，再回到上一轮循环

刚开始用的时候体验确实很好——AI 在很短时间里生成了大量代码，看起来还挺符合预期。但很快瓶颈会集中在三件事上：

• Code Review 困难：审查不是自己亲手写的上千行代码非常消耗心力
• 缺乏信心：即使 review 完，依然不敢放心上线，还得花大量时间做手动对比实验
• 痛苦的返工：一旦在对比中发现问题，又要重新迭代那个开发-Review-测试的循环

最后一复盘，往往发现整体浪费的时间可能比自己实现更久。要想迭代快，关键不再是更快地产出代码，而是更便宜、更稳定地得到验证反馈。

软件开发中，瓶颈永远在人的注意力。当 coding 被 Agent 解放后，验证就成了新的卡脖子环节。本文从代码正确性开始：我们如何用低验证成本确保 Agent 产出的代码是正确的、可靠的、符合预期的？

交替迭代：不再 review 全量代码，只看变化”残差”

交替迭代的底层逻辑非常简单：既然人的注意力是稀缺的，那我们就不去看代码本身，而去看代码变化的”残差”。实践上表现为，测试和实现永远只改一边。

flowchart TD    Start([开始]) --> ModeA{只动测试，不动实现}    ModeA -->|测试失败| FixTest[Agent 自修]    FixTest --> ModeA    ModeA -->|测试通过| ModeB{只动实现，不动测试}    ModeB -->|功能失败| FixImpl[Agent 自修]    FixImpl --> ModeB    ModeB -->|功能通过| Residual[✓ 残差确认]    Residual --> ModeA        style ModeA fill:#e1f5fe    style ModeB fill:#fff3e0    style Residual fill:#e8f5e9

它把”写代码”拆成两种模式，并让 Agent 在两种模式之间交替切换：

• 模式 A：只动测试，不动实现。
  基于当前现有的工程，让 Agent 去完善测试框架、补充测试用例。此时实现代码尽量不动（最多只在接口层做少量必要调整，保证好 review）。
  如果新增测试跑不过，默认不是”实现错了”，而是测试没准确刻画现有行为——让 Agent 自己把测试修到能稳定反映现状。

• 模式 B：只动实现，不动测试。
  基于现有测试框架做工程需求/性能迭代，目标是在完全不修改测试框架（最多只修改少量必要用例）的情况下实现功能并通过测试。
  如果跑不过，默认就是新实现有问题——让 Agent 自己修到满足所有测试。

在这个过程中，开发者本人参与的部分依然很少——测试框架是 Agent 写的，测试用例是 Agent 添加的，功能也是 Agent 迭代的。开发者依然只 review 了部分关键测试样例和少量关键实现代码。这并不像传统 TDD 一样需要开发者投入大量精力编写测试，但 review 心力大幅减少，对代码的信心反而增加。

增益来自哪里？这套方法为工程迭代引入了一个不动点：我们可以永远沿用”上一个版本是好用的”这个关键信息来保证工程项目的可靠性和传递性，而开发者需要审核的仅仅是新功能的迭代和优化——也就是”残差”的那部分。

将该原则具体化为两条约束:

• 写测试的时候，保持代码不变（或者只在接口层变动，非常好 review）。如果 Agent 写的测试跑不过，那说明是测试写错了，它就得自己改，直到测试能准确反映现有代码的行为。
• 写功能的时候，保持测试框架不变，最多根据功能变更修改少量用例。如果 Agent 写的功能跑不过测试，那说明是新代码有问题，它就得自己改，直到新功能满足所有测试的要求。

这样，Agent 就不再是一个只会”交作业”的代码生成器，而是一个可以在每个阶段自我修正的”开发者”了。

接下来问题就变成：这个”不动点”怎么铸造？怎么让它覆盖足够多的情况、又足够稳定，同时还保持能高效迭代？

确定性与快照：迭代的”不动点”

上一章我们引入了一个关键概念：不动点。在交替迭代的 workflow 中，我们永远假设一件事成立——上一个版本是好用的，并以此作为下一次迭代的基准。

要让这个”不动点”真的可用，它至少需要满足两个条件：

• 它必须覆盖到足够多的情况；
• 它必须在版本之间足够稳定。

乍一看，这似乎又回到了传统工程里那些熟悉的词汇：分支覆盖率、功能覆盖率、测试完备性……
但当测试本身的规模也被 Agent 放大之后，Code Review 又成了新的瓶颈——大量测试即使交给 Agent 编写，人工逐条 review 依然极其消耗心力。于是我们不得不接受一个听起来有点危险的结论：

• 不动点并不要求”正确”，它只要求”行为在版本迭代上的连续性”。

如果测试记录的行为本身就是正确的，那当然更好；但即便它并不完美，只要老版本是可用的，新版本至少不应该出现我们没有意识到的 regression——这就已经把工程迭代的风险压缩进了一个可控范围。

这个观点在传统的软件工程叙事中并不”政治正确”。我们习惯强调交付结果的可靠性，而”允许存在未完全验证正确性的测试”，听起来像是在”让生产环境帮你测”。但这里的关键不是放弃正确性，而是用廉价的 token 换取功能迭代的行为连续性——正确性有别的手段来保证（后文会讲）。

在深入之前，我们先要引入两个好用的工具：确定性测试与快照测试

确定性测试（Deterministic Testing）

确定性测试对这种 workflow 至关重要。我们必须消除测试中的”噪音”：如果输出本来就不稳定，snapshot diff 只会把人逼疯。

在单线程程序中，这相对简单，主要关注几点：

• 固定 random seed
• 注意 hashmap 这类无序数据结构的遍历顺序（往往内置了一个 random seed）
• 将获取系统时间戳之类的接口”hook”在最外层，作为输入参数传入

但在多线程程序中，这事儿会变得非常复杂，这里不过多展开，有兴趣的可以看一下 Foundation DB 的文章，或者 madsim、miri 这样的库。

快照测试（Snapshot Testing）

在保证测试程序有了确定性的输出之后，Snapshot Testing 的作用就是快速地把测试的输出结果 dump 下来并保存到 Git 与测试的结果对齐。快照的输出可以是非常大量的、难以肉眼验证正确性的，比如一整天的服务器日志聚合结果、API 响应数据流、推荐系统产出的排序结果等。

在 Python 中我们可以非常简单的用 syrupy 无脑引入一堆 Snapshot Testing（已经投入实践）。核心目标是，只要代码上我们关心的行为发生了任何变化——数值异常、顺序变化、类型调整——都一定要影响到输出的结果。

1
2
3
4
5
6
7
8

def test_user_events(snapshot):
    df = read_data("2025-12-01", "user_events")
    assert df == snapshot
    # 或者嫌弃输出实在太庞大的话
    assert df.describe() == snapshot
    assert df.shape == snapshot
    assert df.dtype == snapshot
    assert (df.index.min(), df.index.max()) == snapshot

用快照构建回归测试（Regression Testing，简称 RT）

如何用有限的注意力管理海量的测试？把 Snapshot Testing 作为 RT 的实现方式。

回归测试由 Agent 大量生成，开发者可以不逐条 review 测试的行为：

• 目标不是证明”输出一定正确”，而是把当前版本的行为固化成基线；
• 后续任何改动只要让行为发生变化，就一定会在 diff 上暴露；
• 人只在 diff 出现时介入，判断”这次变化是否符合预期/是否可接受”；
• 回归测试消耗的仅仅是 token：让 Agent 多跑、多 dump、多存档；开发者的注意力投入接近 0。

具体实践模板包括：

• 大输出回放的统计快照：对大规模数据集的统计摘要，如日志量、响应时间分布等，snapshot df.shape、dtypes、describe()、分位数等摘要。不需要证明这些摘要”绝对正确”，但只要发生”悄悄变坏”的 drift，diff 一定会抓住它。
• Schema / 接口契约快照：对外 API 返回的字段集合、类型、空值约束、错误码等做 snapshot。这类变化通常比数值变化更致命，Code Review 非常适合兜底。
• 边界输入的行为连续性：让 Agent 枚举大量 edge cases（空数据、极端区间、乱序、重复 key、缺失字段、非法编码……），记录”输出摘要/错误类型/日志摘要”的 snapshot。不追求”正确”，只确保行为变化一定会被 diff 提醒，我们再决定要不要把这个 case 升级成核心测试去严格定义正确性。

RT 的根本目的是让 Agent 从”上一个版本还不错”这个事实中获取信息。通过快照测试，我们将这个信息固化下来，Agent 的每次修改都必须以不破坏这个不动点为前提。如果快照有变动，那么这个变动就是我们所说的”残差”，是需要重点审查的部分。

核心测试（CT）与回归测试（RT）

flowchart LR    subgraph CT[核心测试 CT]        C1[人工挑选关键路径]        C2[输出清晰可控]        C3[人工确认正确性]        C4[消耗注意力 💰]    end        subgraph RT[回归测试 RT]        R1[Agent 批量生成]        R2[固化行为基线]        R3[diff 时介入]        R4[消耗 token 🪙]    end        CT -->|保证| Correct[正确性 ✅]    RT -->|保证| Cont[连续性 🔄]        style CT fill:#ffebee    style RT fill:#e8f5e9    style Correct fill:#fff8e1    style Cont fill:#fff8e1

通过上文的方法，我们用近乎零注意力成本的方式构建了大量回归测试，但还有一个问题没回答：RT 不关注正确性，那交付质量谁来保证？

答案很简单：继续保留需要关注正确性的测试，我们称之为核心测试（CT）。CT 就是原来该怎么测试现在还怎么测试：

• 人工挑选最值得测试的关键路径/关键行为
• 输出尽量”小而清晰”
• 编写测试可以交给 Agent，但开发者一定要确认 expected output 的正确性
• CT 消耗的关键资源就是注意力：我们要看它”对不对”

既然 RT 的构建过程完全不消耗注意力，引入 RT 就不会影响我们在 CT 上的资源投入。所以结论是：CT 保证了不低于传统开发 workflow 的正确性，RT 额外换来了功能迭代的行为连续性。

另外一个实用的实践：一旦 RT 中的某个 diff 反复出现，说明它测试的行为是经常改动的关键路径，很值得被”提纯”为 core test（补上语义断言 + 人工认可的 expected output）。注意力永远花在刀刃上。

工程上怎么区分这两类测试？

实践上不需要很复杂，最朴素的约定就够了，关键是让”review 与否的约定”可执行：

• 目录分层：
  • tests/core/：core behavior tests
  • tests/regression/：regression tests（快照为主）
• 迭代时两类都跑，但变更的 review 规则不同：
  • core：PR 必须人工确认断言语义/expected output；
  • RT：PR 不要求逐条阅读 baseline，只在 snapshot diff 出现时人工判断”变更是否合理”。

结语：验得起才是真的快

Agent 让 coding 带宽变得几乎不稀缺，于是开发的主战场从”写得快”转向了”验得起”。

很多人会把瓶颈归因到 Code Review：Agent 像风一样产出几千行代码，人当然看不过来。但这更像是误诊——在很多严肃场景里（比如核心业务系统迭代），真正最费时间的往往不是 review，而是为了”敢上线”去做的对比实验、回放验证、以及线上问题的定位成本。验证才是最贵的那一段。

交替迭代 + 不动点，让 Agent 在边界内自我修正；CT + RT，让正确性和连续性各归各位。token 不是瓶颈，人脑才是——把注意力从”逐行审查”挪到”审查残差”，验证成本才能真正降下来。

算法

谈到算法面试，首先想到的是 LeetCode，这不是我想的，是 Copilot 想的。

算法是讨论到面试绕不开的话题，我懒得考古，但这股“歪风”应该是从硅谷几家 Big-name Tech 带起来的。这个选择是非常明智的，算法竞赛作为面试的核心部分有非常多的好处：

• 形式上标准化，可以避免很多不必要的争议（但也只在形式上）
• 题库非常大以至于不可能全靠死记硬背。通过面试的候选人下限有保证，具备能写 CRUD 的基础 coding 能力，有行动力且愿意花时间刷题，具有一个螺丝钉必要的品质
• 面试官完全不需要提前准备，在题库中随机 Pick 一道题就能面试，减少公司面试的成本

印象最深的是我校招时 Airbnb 北京的面试，面试官甚至不会给时间自我介绍。任何关于项目的沟通都必须在解完题目之后。那天有一面我状态不好，以至于我和面试官没有哪怕一分钟的时间交流题目外的内容。

但当将算法面试应用于 Senior 招聘的时候，事情就变得抽象了起来，算法面试事实上衡量的是一个人算法能力相对大学的退化程度。最能做算法题的人，一大半是现役高中生（或者本科生），而剩下的一小半，是曾经的最强算法高中生。90% 的 Senior 工程师，算法做不过 Junior 时候的自己，这是一个应该考察人成长的阶段，但是结果是人吃老本的水平，很难说是一个有效面试。这个道理曾经的我也不懂，刚毕业在旷视工作的时候 Leader 经常让我作为一面考察一些 Senior 的 coding，我常常讶异于他们为什么算法那么菜，直到最近我“接雨水”写了四十分钟才写出来 :(。

一个曾经我很认同的观点是，做 Infrastructure 对算法能力的要求更高，相比 CRUD 来说，各个系统都需要用到一些复杂的算法，因此，在这种情况下，算法面试就变得尤为重要。这个观点的前提是对的，但结论是错的。Infra 需要用到的算法很难，特别是在 RisingWave 工作的这段时间，许多常用算子的增量算法往往都要想不少时间。但这在整个 feature 落地的过程中无论是消耗的时间还是复杂度都占比不到 10%。同时，在 30-40 分钟里切题的能力和有充分的时间去思考工程上真正需要解决的问题和方案，中间也存在着巨大的 gap。

System Design

System Design 作为面试形式的上下限差异极大，事实上，对面试官提出了很高的要求。面试官必须有丰富的系统设计经验，且本身对题目已经有非常完善的思考了，甚至最好是项目上真实遇到的需求。System Design 的答案本身就是开放性的，更多的是对交流过程中思路的考察，互相之间的启发，而不仅仅是对答案。在之前的一场面试中，我遇到了一道性能优化的题目，它的背景大约是使用一台 8GB RAM 和 1TB 硬盘的服务器，优化某种场景的查询。而当我追问硬盘是什么类型，是 SSD 或者 HDD，读写性质是什么样的，面试官的回答是不知道。我猜测这不在那道题的考察点上，但在我看来这种去匹配答案的形式完全不适用于 System Design 的考察形式。

如果像算法题一样，面试官仅仅是从题库中 Pick 一道题并阅览一下参考答案就去面候选人，那么最终的面试效果甚至还不如算法题。一方面，候选人很多合理的设计思路会因为面试官的短视而被否定，另一方面，由于 System Design 的题库相比算法题要小很多，如果面试官不会做任何的变通，很容易被刷穿题库的候选人轻松拿到 Strong yes，而实际上完全无法达到水平考察的目的。

“共享面试”

“共享面试”是一个不存在的形式，确实一个客观存在的概念。在你投一家公司的第一天，HR 就会问你现在的总包作为参考，有些公司甚至会有一些离谱的规定，比如不允许给候选人涨幅超过一个固定比例。同时，HR 们也会互相追问友商给你的工资（尽管他们还会同时你 Offer 需要保密），作为一个基数来决定或者调整 offer。

这在很大程度上，就是因为一家公司三到四轮的面试太短，以及可能形式上存在上面所说的种种问题，很难真正地确定候选人的能力和匹配程度，因此借用了候选人的上家，以及其他认可的友商的面试成果，一种事实上的“共享面试”出现了。

而这个明面上不存在的面试形式，却是决定候选人最终 offer 的关键因素。

乍一看，“共享面试”并不是一个糟糕的 idea，解决了一家公司能占用候选人的时间过短的问题，从概率意义上增加了候选人匹配的程度，然而这是一种非常低效且不确定的形式。每家公司的面试方式是高度雷同的，相当于把在与 GPT 的对话中 temperature 调得很低然后多次询问试图提高结果的准确性，实际上的效果非常存疑。

Assignment

这是一种一直不温不火的面试形式，不火的原因是占用候选人过多时间，太容易被候选人挂上脉脉，被骂剽窃候选人的劳动力。这里也分两种，一种是将公司内项目的一些任务提炼一下得到一份脱敏版本，作为候选人的 assignment。另一种则是一些开源项目的商业公司，直接将 issue assign 给候选人，然后在 review 的同时对候选人能力做一个评估，顺便清理一些项目里低优先级的 backlog issue。

相比于 Assignment 本身，我更认可 Co-work 的面试方式。在这个任务的完成过程中，面试官也应该花费同等的时间，与候选人协作，通过保持连线甚至直接使用一些协作编辑的方式，共同完成这个 feature。在这个过程中，观察候选人习惯的阅读、编码、调试、解决问题等的方式；当候选人遇到一些项目本身的不足带来的困难时也及时给予指正，免得浪费无谓的时间。观察候选人是否能用合适的方式与同事沟通（例如请求是否足够清晰，让被求助人最快理解问题），获取帮助，也是工作内容中相当重要的一部分。

除此之外，作为候选人，在一些 Assignment 的完成过程中，我遇到的更多问题往往是 quick start 文档缺失、调试困难、一些配置项隐藏过深等。完整的审视一个新人参与项目中遇到的困难，对拥抱开源的项目来说也是很好的补充。

Show your contribution

面试始终是对工作内容的抽样调查，无论如何高效地利用，想在若干小时内对一个人的工作能力全面了解都是不可能的。这就是给开源项目打工的重要魅力之一。一个好的 GitHub 主页，是对个人能力的最好展示。我作为面试官时，如果候选人贴了 GitHub 链接且有一些个人项目或者对重要项目有贡献，我都会挑一些我比较感兴趣的 PR，真正地从一个 reviewer 的视角去过一遍。如果说那么好的面试就可以对候选人的工作能力了解达到 20% 以上，那候选人如果有开源的全职工作经历，了解程度就能达到 60% 以上。

不要吝惜时间

从一个候选人的视角来说，对于真正感兴趣的公司，我并不介意面试花费更多的时间去做一个自我证明。我反而会觉得只通过写两道题来了解我是相当可惜的，有很多信息可以互相沟通了解，而不希望最终拿到好 offer 的原因是另一个好的友商给了一个不错的 compete offer。

从公司的视角来说，用更少的成本快速找到合格的螺丝钉固然是 Big-name tech 的核心需求，却并不适用于大部分公司，让面试官在一个候选人身上多花费一些成本来提高匹配程度，对很多公司来说是很划算的。

这里可以看出面试官在面试过程中的重要程度，然而好的面试无论如何都需要面试官花费更多的时间去准备，从公司层面再细分来说，更详尽的面试对 Leader 来说自然是利益趋同的，但对普通的技术面试官来说，就未必愿意占用自己完成工作的时间来准备。这也是为什么标准化面试受欢迎的一个原因。如何设计对面试官的反馈机制是一个难题，这篇文章作为一篇碎碎念就不赘述了，等我理解加深的时候再来补充。

写在最后

面试形式与效果是非常多的 big tech、独角兽思考过的难题，同时它也像 system design 一样，是真正的开放性难题，根据不同的场景、需求自然会有不同的结论，所以这篇碎碎念没有答案，只是剖析一下现有的面试形式作为一些个人思考，也希望无论作为面试官还是候选人都能从中找到一些共鸣。

1
2
3
4
5
6
7
8
9
10
11

new_lru_cache(|mut perm, mut cache| {
    cache.put("a", "b".to_string(), &mut perm);
    cache.put("b", "c".to_string(), &mut perm);
    cache.put("c", "d".to_string(), &mut perm);
    let x = cache.get(&"a", &perm).unwrap().as_str();
    let y = cache.get(&"b", &perm).unwrap().as_str();
    let z = cache.get(&"c", &perm).unwrap().as_str();
    [x, y, z].join(" ");

    (perm, cache)
});

这里的主要问题是，LruCache 必须通过一个 closure 创建，且携带了一个 'brand 生命周期，如果想存在某个 ADT 里，会将生命周期泛型向上传染。

在我的朋友的提示下，我发现我们可以将 LruCache 的数据和对它的操作分离，为此，我设计了一套新的 scope API。

首先，在原本的代码之上，我们将 'brand 从 LruCache 上删除，然后引入一个新的结构体 CacheHandle：

1
2
3
4
5
6
7

pub struct LruCache<K, V> {
    _marker: PhantomData<(K, V)>,
}
pub struct CacheHandle<'cache, 'brand, K, V> {
    _lifetime: InvariantLifetime<'brand>,
    cache: &'cache mut LruCache<K, V>,
}

很显然，LruCache 可以通过常规的方式构建：

1
2
3

impl LruCache {
    pub fn new(cap: usize) -> Self { todo!() }
}

这里 CacheHandle 替代了我们上一篇文章中 LruCache 的职责，需要与 ValuePerm 深度绑定，为此我们引入了 LruCache::scope API，替代了原来的 new_lru_cache。

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

impl<K, V> LruCache<K, V>
    pub fn scope<'cache, F, R>(&'cache mut self, fun: F) -> R
    where
        for<'brand> F: FnOnce(CacheHandle<'cache, 'brand, K, V>, ValuePerm<'brand>) -> R,
    {
        let handle = CacheHandle {
            _lifetime: Default::default(),
            cache: self.into(),
        };
        let perm = ValuePerm {
            _lifetime: InvariantLifetime::default(),
        };
        fun(handle, perm)
    }
}

这个函数接受的是 &mut LruCache，保证了同一时间只有一个 handle进行操作。

这里的回调签名 for<'brand> F: FnOnce(CacheHandle<'cache, 'brand, K, V>, ValuePerm<'brand>) -> R，对比于上一篇文章，这里不再需要把 handle 和 perm 返回，因为 CacheHandle::cache 仅仅是对 LruCache 的可变引用，即使对 handle 提前 drop，scope 内对 value 的引用仍然是合法的。

我们将上一篇文章中的方法分别实现在 CacheHandle 上：

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

impl<'cache, 'brand, K: Hash + Eq, V> CacheHandle<'cache, 'brand, K, V> {
    pub fn put<'handle, 'perm>(
        &'handle mut self,
        k: K,
        mut v: V,
        _perm: &'perm mut ValuePerm<'brand>
    ) -> Option<V> { todo!() }
    pub fn get<'handle, 'perm>(
        &mut self,
        k: &K,
        _perm: &'perm ValuePerm<'brand>,
    ) -> Option<&'perm V> { todo!() }
    pub fn peek_mut<'handle, 'key, 'perm>(
        &'handle self,
        k: &'key K,
        _perm: &'perm mut ValuePerm<'brand>,
    ) -> Option<&'perm mut V> { todo!() }
}

这些 API 的正确性，上一篇文章已经论述过，这里不再重复，有了这些 API 以后，我们就可以这样用我们的 LruCache。

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

let mut cache = LruCache::new(2);
cache.scope(|mut cache, mut perm| {
    assert_eq!(cache.put("apple", "red", &mut perm), None);
    assert_eq!(cache.put("banana", "yellow", &mut perm), None);
    assert_eq!(cache.put("lemon", "yellow", &mut perm), Some("red"));
    let colors: Vec<_> = ["apple", "banana", "lemon", "watermelon"]
        .iter()
        .map(|k| cache.get(k, &perm))
        .collect();
    assert!(colors[0].is_none());
    assert_opt_eq(colors[1], "yellow");
    assert_opt_eq(colors[2], "yellow");
    assert!(colors[3].is_none());
});

由于 cache 现在是 Owned type，不借用任何生命周期，我们可以非常自由地将它存在任何地方。而只需要在修改的时候创建一个 scope 即可。

更近一步的，我们甚至可以将 LruCache 原来的方法添加回来，当我们不需要 reference stability 时，可以不需要引入额外的代码复杂度。

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

impl<K, V> LruCache<K, V> {
    pub fn put(&mut self, k: K, v: V) -> Option<V> {
        self.scope(|mut cache, mut perm| cache.put(k, v, &mut perm))
    }

    pub fn get<'cache>(&'cache mut self, k: &K) -> Option<&'cache V> {
        // SAFETY: We actually hold `&'cache mut self` here, so the only reference should always be valid.
        // We can extend its lifetime to the cache easily.
        self.scope(|mut cache, perm| unsafe {
            std::mem::transmute::<_, Option<&'cache V>>(cache.get(k, &perm))
        })
    }
}

我们可以像正常的 collection API 一样来使用它：

1
2
3
4
5
6

let mut cache = LruCache::new(2);
cache.put("apple", "red", &mut perm);
let data = cache.get("apple");
// We can't call `get` twice when `data` reference is still valid.
// cache.get("lemon");
dbg!(data);

我添加了一大堆 UI Test，来覆盖各种使用场景和应该编译失败的场景，感兴趣的朋友可以看一下这些 test case。

Conclusion

上一篇文章的末尾，我们提到了这套 API 较差的易用性可能限制了它的应用空间，那么这篇文章的改进在我看来，如果可以证明其 soundness，甚至达到了可以合并到标准库的程度（我会尝试给标准库的 LinkedList、VecDeque 等提 Reference Stability 的 RFC）。这个将数据和操作分离的 API 改进，我们只需要在原本的数据结构上单独添加一个 scope API，并且在对应的 closure 内遵循权限分离的设计。而在不需要 reference stability 的场景，我们不会引入任何额外的代码复杂度，真正地做到了 “pay as you needed”，这非常符合 Rust 的设计哲学。

Rust 有个 crate lru 实现了这个数据结构，这里摘取了几个关键方法：

1
2
3
4
5
6
7
8

impl<K: Eq + Hash, V> LruCache<K, V> {
    pub fn new(cap: usize) -> LruCache<K, V> {todo!()}
    pub fn len(&self) -> usize {todo!()}
    pub fn put(&mut self, k: K, v: V) -> Option<V> {todo!()}
    pub fn get<'a>(&'a mut self, k: &K) -> Option<&'a V> {todo!()}
    // get the mutable reference of an entry, but not adjust its position.
    pub fn peek_mut<'a>(&'a mut self, k: &K) -> Option<&'a mut V> {todo!()}
}

相比于 lru，这里对函数签名做了一些简化，省去了与 Borrow trait 有关的优化。

可以看到，与常规数据结构不同的是，这里的 get 方法，也需要接受 &mut self，这给使用者带来很多困扰。例如我们可能希望同时持有多个 V 的不可变引用，这可以允许我们减少不必要的 copy，或者并发地使用他们。

1
2
3
4

let x = cache.get(&"a").unwrap().as_str();
let y = cache.get(&"b").unwrap().as_str();
let z = cache.get(&"c").unwrap().as_str();
[x, y, z].join(" ");

我们会得到如下报错：

1
2
3
4
5
6
7
8
9

error[E0499]: cannot borrow `cache` as mutable more than once at a time
   |
20 |     let x = cache.get(&"a").unwrap().as_str();
   |             ----- first mutable borrow occurs here
21 |     let y = cache.get(&"b").unwrap().as_str();
22 |     let z = cache.get(&"c").unwrap().as_str();
   |             ^^^^^ second mutable borrow occurs here
23 |     [x, y, z].join(" ");
   |      - first borrow later used here

很显然，LruCache::get 使用了 &mut cache 导致 x 已经占有了 cache 的可变引用，而后面尝试创建 y、z 多个 &mut cache 同时存在违背了 Rust 的 borrow checker。

那么 Borrowck 认为是错的，就是错的吗？如果我们再看一眼上图演示的 LruCache 在 get 过程中的调整，我们会发现这个限制是完全没有道理的。get 确实会调整 LruCache 的结构，但并不会影响 val 的指针，第二次 get 完全不会让第一个 get 获得的 &V 失效。

那么反正实现是 unsafe 的，我们可以将 get 改成接受 &self 吗？

1

pub fn get<'a>(&'a self, k: &K) -> Option<&'a V> {todo!()}

这显然是错的，接受 &self 意味着我们可以并发调用 get 方法，链表就会被彻底破坏导致 UB，除非我们使用 Arc<Mutex<_>> / AtomicPtr 等同步原语保护链表节点引入不必要的 overhead，或者将 LruCache 标记为 !Sync，这与我们原本的目的背道而驰了。

我们希望有一种接口设计，它不允许我们并发调用 get 方法，但 get 返回的 &V 不独占整个 cache，从而允许我们合法地同时持有多个 &V.

1

pub fn get<'cache, 'key>(&'cache self, k: &'key K) -> Option<&'? V> {todo!()}

这个函数目前有两个生命周期参数，一个是对 cache 的引用 'cache（前文中的 'a） ，另一个则是完全无关，甚至可能非常短的 'key （在前文中我们利用 rust 的规则省略了这个参数）。这两个都不可能描述我们返回值的生命周期，我们需要一个更好的生命周期参数，基于这个思路，我们尝试引入了一个新的生命周期：'token。

1
2

pub struct Token;
pub fn get<'cache, 'key, 'token>(&'cache self, k: &'key K, token: &'token Token) -> &'token V { todo!() }

这样我们之前同时持有多个 &V 的代码就能编译通过了！Happy Ending？

1
2
3
4
5
6

let token = Token;
let x = cache.get(&"a", &token).unwrap().as_str();
let y = cache.get(&"b", &token).unwrap().as_str();
let z = cache.get(&"c", &token).unwrap().as_str();
cache.put("a", "b".to_string());
[x, y, z].join(" ");

我们很快发现在修改了 get 的签名后，我们在 safe rust 中，在 &V 仍然合法时调用 put。这个方法会覆盖现有的 value，或者淘汰最旧的 entry。被覆盖的 entry 会在返回后被 drop。在此之后我们继续访问 x 就会导致 UB。办法也非常简单，我们只需要修改 put 的签名即可。

1

pub fn put<'cache,'token>(&mut self, k: K, v: V, token: &'token mut Token) -> Option<V> {todo!()}

1
2
3
4
5

let x = cache.get(&"a", &token).unwrap().as_str();
let y = cache.get(&"b", &token).unwrap().as_str();
let z = cache.get(&"c", &token).unwrap().as_str();
cache.put("a", "b", &mut cache, &mut token);
[x, y, z].join(" ");

由于 put 需要 &mut Token 作为参数，而 &Token 已经被 x/y/z 不可变引用了，这里会编译失败。

现在我们可以给 Token 一个更好的名字了，不难发现，Token 其实是对 value 本身的读写权限。我们将它重命名为 ValuePerm。

• 持有 &self，代表对 LruCache 的结构有读权限。
• 持有 &mut self，代表对 LruCache 的结构的结构有写权限。
• 持有 &perm，代表对 LruCache 的 value 有读权限。
• 持有 &mut perm，代表对 LruCache 的 value 有写权限。

1
2
3
4
5
6
7
8

impl<K: Eq + Hash, V> LruCache<K, V> {
    pub fn new(cap: usize) -> LruCache<K, V> {todo!()}
    pub fn len(&self) -> usize {todo!()}
    pub fn put<'cache, 'perm>(&'cache mut self, k: K, v: V, perm: &'perm mut ValuePerm) -> Option<V> {todo!()}
    pub fn get<'cache, 'perm>(&'cache mut self, k: &K, perm: &'perm ValuePerm) -> Option<&'perm V> {todo!()}
    // get the mutable reference of an entry, but not adjust its position.
    pub fn peek_mut<'cache, 'perm>(&'cache self, k: &K, perm: &'perm ValuePerm) -> Option<&'perm mut V> {todo!()}
}

我们选取的函数是非常典型的四种用例。一个意外的收获是，由于 peek_mut 不持有 &mut self，它返回的引用可以和 len 同时调用，虽然这可能是个没什么用的 feature。

1
2
3

let val_mut = cache.peek_mut(&"a", &mut perm);
let len = cache.len();
dbg!(val_mut);

下一个要解决的问题是唯一性。很显然，一个 LruCache 只能被一个 Token 操纵，这里我借鉴了 Ghost Cell 和 std::thread::scope 的思路。利用 invariant lifetime 构造了一个唯一的 ID。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

type InvariantLifetime<'brand> = PhantomData<fn(&'brand ()) -> &'brand ()>;
pub struct ValuePerm<'brand> {
    _lifetime: InvariantLifetime<'brand>,
}
pub struct LruCache<'brand, K, V> {
    _lifetime: InvariantLifetime<'brand>,
    _marker: PhantomData<(K, V)>,
}
impl<'brand, K: Eq + Hash, V> LruCache<'brand, K, V> {
   // ...
}
pub fn new_lru_cache<K, V, F>(fun: F)
where
    F: for<'brand> FnOnce(ValuePerm<'brand>, LruCache<'brand, K, V>),
{
    let perm = ValuePerm {
        _lifetime: InvariantLifetime::default(),
    };
    let cache = LruCache::<K, V> {
        _lifetime: Default::default(),
        _marker: Default::default(),
    };
    fun(perm, cache);
}

我们移除了 LruCache::new 方法，强制通过 new_lru_cache 创造一个 scope，并且在 scope 内使用。LruCache 和 ValuePerm 共享一个唯一的生命周期作为 ID。

1
2
3
4
5
6
7
8
9

new_lru_cache(|mut perm, mut cache| {
    cache.put("a", "b".to_string(), &mut perm);
    cache.put("b", "c".to_string(), &mut perm);
    cache.put("c", "d".to_string(), &mut perm);
    let x = cache.get(&"a", &perm).unwrap().as_str();
    let y = cache.get(&"b", &perm).unwrap().as_str();
    let z = cache.get(&"c", &perm).unwrap().as_str();
    [x, y, z].join(" ");
});

实现到这里的时候，我发现我忘了一个非常致命的问题，我可以修改所有的方法来接受 &mut Perm，但没法修改 Drop ，这可能导致 cache 早于 &V 被释放。而使用 'cache: 'perm 作为 constraint 会导致 &V 再次被 &'cache mut self 限制。

1
2
3
4
5
6
7
8
9
10

new_lru_cache(|mut perm, mut cache| {
    cache.put("a", "b".to_string(), &mut perm);
    cache.put("b", "c".to_string(), &mut perm);
    cache.put("c", "d".to_string(), &mut perm);
    let x = cache.get(&"a", &perm).unwrap().as_str();
    let y = cache.get(&"b", &perm).unwrap().as_str();
    let z = cache.get(&"c", &perm).unwrap().as_str();
    drop(cache);
    [x, y, z].join(" "); // Boom
});

如果 Rust 有 linear type 支持的话，我们可以阻止 LruCache 被 drop，必须通过类似 consume(self, &mut ValuePerm) 之类的方法来销毁，很遗憾的是 linear type 属于有生之年系列，因此我这里用了另一个 workaround：

1
2
3

pub fn new_lru_cache<K, V, F>(fun: F)
where
    F: for<'brand> FnOnce(ValuePerm<'brand>, LruCache<'brand, K, V>) -> (ValuePerm<'brand, LruCache<'brand, K, V>>),

这里要求 new_lru_cache 接受的回调必须将 perm 和 value 的所有权返回再统一 drop。由于 'brand 的唯一性，回调必须将变量返回而无法提前销毁。

1
2
3
4
5
6
7
8
9
10
11

new_lru_cache(|mut perm, mut cache| {
    cache.put("a", "b".to_string(), &mut perm);
    cache.put("b", "c".to_string(), &mut perm);
    cache.put("c", "d".to_string(), &mut perm);
    let x = cache.get(&"a", &perm).unwrap().as_str();
    let y = cache.get(&"b", &perm).unwrap().as_str();
    let z = cache.get(&"c", &perm).unwrap().as_str();
    [x, y, z].join(" ");
    
    (perm, cache)
});

至此我们的接口设计就大功告成了，具体实现几乎可以完全从 lru copy，反正 unsafe 可以操纵一切，我们只要保证上层接口足够安全就行。

我实现了一个简单的完整可用版本，开源在 https://github.com/TennyZhuang/ref-stable-lru，并且已经发布到 crates.io ref-stable-lru，感兴趣的可以试玩一下，特别是提出一些 unsound 的宝贵意见。

Reference Stability in C++ STL

熟悉 C++ 的朋友都知道，C++ STL 有一个非常黑暗的概念，叫 reference/iterator stability，或者叫 reference/iterator invalidation。在 cppreference 中，我们可以找到这样一张图，它描述了各个 containers 在各种操作下的行为。

这个 feature 是 C++ UB 的重灾区之一，主要原因是只在 doc 里提到，完全没法在签名上约束。而 Rust 完全阻止了相关的行为，Rust 标准库的所有 collection，只要你持有任何一个 reference，你都无法对这个结构进行任何操作，这其实浪费了 collection 的很多特性。这篇文章的设计思路是将 collection 的操作权限分散到各个 Perm 上，从而提供细粒度的读写权限控制，这个思想高度借鉴了 Ghost Cell。用类似的思路，我们也可以实现一些其他常用的数据结构，例如持有引用的同时可以 push 的 VecDeque。

RisingWave 是近期开源的一款 Rust 写的云原生流数据库产品。今天根据下图简单介绍一下 RisingWave 中的状态管理机制：

Hummock Overview

在 RisingWave 的架构中，所有内部状态和物化视图的存储都是基于一套名为 Hummock 的存储来实现的。Hummock 并不是一个 storage system，而是一个 storage library。Hummock 目前支持兼容 S3 协议的存储服务作为其后端。

从接口上，Hummock 提供了类似 Key-Value store 的接口：

• get(key, epoch)：获取一个 value
• iter(range, epoch)：扫描一个范围的 key-value pairs
• batch_ingest(key-value batch)：插入一批 key-value pairs

可以看到，与一般的 key-value store 接口不同，Hummock 没有提供正常的 put 接口，而是只提供了 batch 的输入接口。同时所有的操作都带了 epoch 的参数。这与 RisingWave 基于 epoch 的状态管理机制有关。

Epoch-based checkpoint

RisingWave 是一个基于固定 epoch 的 partial synchronized system。每隔一个固定的时间，中心的 meta 节点会产生一个 epoch，并会向整个 DAG 的所有 source 节点发起 InjectBarrier 请求。source 节点收到 barrier 后，将其注入到当前数据流的一个切片。

1
2
3
4
5
6
7
8
9

message Barrier {
  Epoch epoch = 1;
  oneof mutation {
    NothingMutation nothing = 2;
    StopMutation stop = 3;
    UpdateMutation update = 4;
    AddMutation add = 5;
  }
}

对于 DAG 中间的任何一个算子，如果收到了一个 barrier，需要依次做一些事情：

1. 如果是一个多输入流的算子（Join、Union)，那么需要等待其它流的 barrier，直到收集齐所有输入流的同一个 barrier 以后才处理。
2. 如果有需要操作的 mutation（用于 scale-out，create mview，drop mview），那么 apply 对应的 conf change。
3. dump local state (async checkpoint)

3 是本文想介绍的重点。简单来说，RisingWave 既不是一个 local state backend，也不是 remote state backend，而是一个混合形态。只有最新的 barrier 之后的 state 才是算子自身维护的 local state，而之前的数据则是 remote state。当且仅当收到 barrier 的时候，算子才会选择 dump 状态到 hummock store。这也就是 hummock store 只提供 ingest batch 接口的原因 ———— 算子只会在收到 barrier 的时候将 local state dump 到 hummock 中去。

Async Checkpoint

前文中我们提到，算子在收到 barrier 时，会选择 dump 数据到 Hummock，但我们也提到了 barrier 是随着数据流一起流动的，如果每个算子都需要同步地将等待状态被上传到 shared storage（目前是 S3），那么数据处理就会 blocking 一整个上传的 Round trip。如果 DAG 中有 N 个有状态算子的话，那么 barrier 在整个传递过程中就会被 delay N 个 round trip，这对整个系统的处理能力会产生很大的影响。因此，我们将 barrier 的处理流程几乎全异步化了。有状态算子在收到 barrier 后需要做的唯一一件事，就是将当前 epoch 的 local state 同步地 std::mem::take 走，重置为一个空的 state，让算子可以接着处理下一个 epoch 的数据。这也引入了一系列的问题：

• 这个 epoch 的 local state 被 take 到哪里去了？
• 既然 local state 并没有同步地上传到 S3，那么针对这段时间数据的查询应该怎么处理呢？
• 在异步上传的时候，算子 crash 了怎么办，如何知道 checkpoint 是否成功？

为了解答上面的这些问题，我们引入了 Shared Buffer。

Shared Buffer

Shared Buffer 是一个 Compute Node 的所有算子共享的一个后台任务，当有状态算子收到 barrier 之后，local state 会被 take 到 Shared Buffer 里。

Shared Buffer 主要负责以下事情：

1. （可选）部分算子的状态可能会很小，如 SimpleAgg。根据 local state 的大小，适当地在不同算子的 state 在文件粒度上之间做切分和合并。
2. 将算子本地的状态上传到 shared storage 上。
3. 向 meta service 注册已经成功上传成功的 state 记录。
4. 服务来自算子内部对尚未上传成功的 local state 的查询。

这里的 3 和 4 很好地回答了上一小节提的问题。

• 从用户的视角，只有一个 epoch 内所有算子的 local state 全部上传完成并在 meta service 注册成功，才认为这个 checkpoint 是完成的，无论是正常 query 还是 recover，都会基于最新的完整 checkpoint。
• 从内部算子的视角，在读自己 state 的时候，必然是要求读到完整最新状态的，那么事实上内部算子需要的是 remote state + shared buffer + local state merge 后的结果。这里 RisingWave 也提供了 MergeIterator 来做这个泛化。

Local Cache

由于大部分状态在 remote state 中，RisingWave 可以很简单地实现 scale-out，然而带来的代价也是很明显的。相比于 Flink 这种 local state 的设计，RisingWave 需要多很多 remote lookup。

我们以 HashAgg 为例，当 HashAgg 算子收到 Barrier 后，它会把当前 barrier 的统计结果 dump 到 shared buffer，将算子本地的 state 重置为空。然而在处理下一个 epoch 数据的时候，最近处理过的 group key 很可能依然就是热点，我们不得不重新从 shared buffer 甚至 remote state 重新将对应的 key 捞回来。因此我们的选择是，在算子内部不再将之前 epoch 的 local state 重置清空，而是将其标记为 evictable，当且仅当内存不足时，再清理 evictable 的数据记录。

基于这个设计，在内存充足的情况下，或者对于状态非常小的算子（如 simple agg 仅有一条记录），它的所有状态都在内存里，且都由当前线程去操作，达到了最大化的性能，而 dump 仅用于 recovery 和 query。对于内存不足的情况下，或者对于有明显冷热特征的算子（如 TopN），那么既能保证正确运行（冷数据去 remote lookup），又能充分榨干每一分内存，

Compaction

State 并不是上传到 shared storage 就不再修改了，RisingWave 会有后台的 compaction 任务。

Compaction 主要有以下目的：

1. 回收垃圾：部分算子会产生 DELETE 记录，这也会产生一条 tombstone 记录，在 compaction 的时候需要删除记录。同时覆盖写也需要被合并，回收空间。
2. 整理数据：部分算子在上传的时候会倾向于将同一个 epoch 内不同算子的 state 合并，以减少写放大。然而为了面向后续查询的优化，compaction 会倾向于将同一个算子不同 epoch 的 state 合并，减少读放大。另外，RisingWave 倾向于将计算分布和存储分布尽可能对齐，因此发生 scale-out 后也需要 compaction 来整理数据，这里之后有机会介绍 scale-out 设计的时候再展开，本文不赘述。

执行 compaction 任务的 Compactor 可以灵活部署，既可以挂载在计算节点，也可以由独立进程启动，未来在云上也会支持 serverless 任务来启动。Compaction 任务的调度可以根据用户的需求来调节。如同 Napa 里提到的，如果用户同时需要 freshness 和 query latency，那么理应付出更多的 cost 来执行更频繁的 compaction 任务，反之的话则可以帮用户来省钱。

Conclusion

如果我们重新 review 一下整个 state store 的设计的话，就会发现这是一颗基于 cloud 的大 LSM 树。每个算子的 local state 和 shared buffer 对应于 memtable（允许 concurrent write，因为所有 stateful 算子保证了 distribution），而 shared storage 里存储的则是 SSTs，meta service 则是一个中心化的 manifest，作为 source of truth，并且根据元信息触发 compaction 任务。

本文简单介绍了 RisingWave State Store 的基本架构和设计上的 trade off。核心思路是尽可能利用云上 shared storage 的能力，享受 remote state 的优势 – scalability 和更强的弹性扩缩容能力，又希望在 hot state 较小的场景依然能达到 local state 的性能。当然这一切并非毫无代价，而在云原生的架构下，我们可以让这个 trade-off 由用户来选择。

RisingWave 是一个活跃开发的项目，设计也在活跃迭代中，目前我们也在上述设计之上引入了 Shared State，以减少存储的状态，之后有机会展开介绍。更多的设计文档，可以在 RisingWave 的 repo 找到。

简介

全世界有几千种编程语言，任何一个系统学过编译原理的本科生，都可以设计出自己的 toy language 并实现一个 mini compiler。大部分语言都会设计自己喜欢的语法去表达一些通用的基础设施：基础类型、字符串、变量、条件分支、循环、函数、结构体，这些都是朝三暮四、朝四暮三的区别，也不会成为一个语言本质的创新。 本文不会介绍 Zig 的基础语法，而是想安利一下 Zig 的一个重要 feature —— comptime。

C++ 有非常强大的编译期运算能力，meta programming 的魔法层出不穷，且在每个 C++ 版本越迭代越博大精深，然而对于学习者来说，是非常陡峭的学习曲线。Meta Programming 完全是内置于 C++ 编译器的另一套语法非常复杂、报错非常不友好的函数式编程语言。曾经看到过一个观点（来源请求），如果只是为了在编译期生成足够高效的代码，与其将元编程做得越来越复杂，不如直接引入 Python 作为编译期的胶水语言。那么 Zig 就做出了一个类似的选择：Zig 在编译期引入 Zig 自身作为胶水语言来生成代码，这就是 Zig comptime。

我们将以迟先生的类型体操（上篇） 中实现的一些例子来学习一下 zig。

例子

迟先生的类型体操中实现的 Array 本质上是 Apache Arrow 内存格式 的一种实现，我们也可以尝试在 Zig 中实现一下。

实现 FixedArray

原文中PrimitiveArray 存的是可空的定长元素组成的数组，我们不妨将它改名为 FixedArray，由一个代表是否为空的 Bitmap 和存储元素的 collection （这里是 ArrayList）组成。而 StringArray（这里简化成 BytesArray）是存储变长字符串的集合，由 Bitmap、偏移量数组、和拍平的字符串内容组成。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

const std = @import("std");
const ArrayList = std.ArrayList;
const DynamicBitSet = std.bit_set.DynamicBitSet;

fn FixedArray(comptime T: type) type {
    return struct {
        const Self = @This();
        data: ArrayList(T),
        validity: DynamicBitSet,

        pub const Ref = T;

        pub fn deinit(self: *Self) void {
            self.data.deinit();
            self.validity.deinit();
        }

        pub fn value(self: *const Self, idx: usize) ?Self.Ref {
            if (self.validity.isSet(idx)) {
                return self.data.items[idx];
            } else {
                return null;
            }
        }

        pub fn len(self: *const Self) usize {
            return self.data.len();
        }
    };
}

可以看到，在 Zig 中，””泛型类型 FixedArray 本质上就是一种接受一个类型，返回一个结构体的函数而已。在这个函数里，我们可以执行任意的表达式检查输入类型参数的合法性，甚至可以根据输入参数用 if else 返回不同的结构体。不妨假设我们添加了一个需求：对于 FixedArray，如果每个元素大于 8 个字节，也应该返回引用而非值本身。我们可以改少数代码完成这个需求：

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

// ...
const sizeLarge = (@sizeOf(T) > 8);
pub const Ref = if (sizeLarge > 8) *T else T;
// ...
pub fn value(self: *const Self, idx: usize) ?Self.Ref {
    if (self.validity.isSet(idx)) {
        if (sizeLarge) {
            return &self.data.items[idx];
        } else {
            return self.data.items[idx];
        }
    } else {
        return null;
    }
}

@This 很像一般语言里的 receiver，但它其实只是一个的编译器内置的函数，返回了正在定义中的类型参数实例，我们用 Self 为它起了个别名。既然类型只是一种编译期变量，那么相应的 Associated type 也只是结构体上的一个编译期常量而已，我们根据编译期计算的 @sizeOf(T) 来确定 Ref 的类型。这里 @sizeOf 是一个例子，如果想要，我们也可以用斐波那契数来确定 Ref 的类型 :(

实现 BytesArray

原文中实现了 StringArray 作为变长数组的例子，这里我们简化为 BytesArray。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

const BytesArray = struct {
    const Self = @This();

    data: ArrayList(u8),
    offsets: ArrayList(u32),
    validity: DynamicBitSet,

    pub const Ref = []u8;

    pub fn value(self: *Self, idx: usize) ?Self.Ref {
        if (self.validity.isSet(idx)) {
            const start = self.offsets.items[idx];
            const end = self.offsets.items[idx + 1];
            return self.data.allocatedSlice()[start..end];
        } else {
            return null;
        }
    }

    pub fn deinit(self: *Self) void {
        self.data.deinit();
        self.offsets.deinit();
        self.validity.deinit();
    }

    pub fn len(self: *Self) usize {
        return self.offsets.len() - 1;
    }
};

这里更直接了，BytesArray 就是个类型为 type 的常量。我们也定义了 Ref 常量来模拟 BytesArray 的『关联类型』。通过将 Ref 定义为切片（[]u8），我们轻松实现了返回引用而非拷贝数据。

实现 BytesArrayBuilder

我们需要一个 Builder 来构造不可变的 array，构造的过程跟读取是类似的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

const BytesArrayBuilder = struct {
    const Self = @This();

    pub const Array = BytesArray;

    data: ArrayList(u8),
    offsets: ArrayList(u32),
    validity: DynamicBitSet,

    pub fn init(allocator: Allocator) !Self {
        var offsets = try ArrayList(u32).initCapacity(allocator, 1);
        offsets.appendAssumeCapacity(0);
        return Self{
            .data = ArrayList(u8).init(allocator),
            .offsets = offsets,
            .validity = try DynamicBitSet.initEmpty(allocator, 0),
        };
    }

    fn append(self: *Self, v: Self.Array.Ref) !void {
        try self.data.appendSlice(v);
        try self.offsets.append(@intCast(u32, self.data.items.len));
        try self.validity.resize(self.validity.capacity() + 1, true);
    }

    fn append_null(self: *Self) !void {
        try self.offsets.append(@intCast(u32, self.data.items.len));
        try self.validity.resize(self.validity.capacity() + 1, false);
    }

    pub fn finish(self: Self) BytesArray {
        return BytesArray{
            .data = self.data,
            .offsets = self.offsets,
            .validity = self.validity,
        };
    }
};

这里有一些小问题，比如标准库的 DynamicBitSet 并不能高效地 append 一个 bool，不过可以暂时忽略。我们将 ArrayBuilder 和 Array 通过 ArrayBuilder::Array 关联起来，当然我们也可以顺着 Array 再找到 Ref，如 fn append(self: *Self, v: Self.Array.Ref)。我们也可以在 Array 的结构体中添加对应的 Builder

1

pub const Builder = BytesArrayBuilder;

关联数据库逻辑类型与物理类型

这个对应于 用 Rust 做类型体操 (下篇)，得益于 comptime 的简单设计，我们直接逃课了类型体操的大部分。

在原文中，作者用了非常复杂的 macro，用类似 callback 的编程范式来实现了逻辑类型和物理类型的关联，而在类型即编译期变量的 Zig 里，这一切都非常自然。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// 定义 DataType，假设我们支持五种类型。
const DataType = union(enum) {
    SmallInt: void,
    Integer: void,
    BigInt: void,
    Varchar: void,
    Char: u16, // Char 的长度

    // 关联逻辑类型和物理类型
    fn ArrayType(self: DataType) type {
        return switch (self) {
            DataType.SmallInt => FixedArray(i16),
            DataType.Integer => FixedArray(i32),
            DataType.BigInt => FixedArray(i64),
            DataType.Varchar => BytesArray,
            DataType.Char => BytesArray,
        };
    }
};

同样，基于 comptime，我们也可以用非常流畅的逻辑将表达式的类型和 DataType 的数组直接映射到表达式的实现，不过这篇 blog 已经太长了，暂时不过多展开了。

std.MultiArrayList

事实上，Zig 已经在标准库里内置了类似 Multi-dimentional FixedArray 的东西，且非常灵活。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

const ally = testing.allocator;
const Foo = struct {
    a: u32,
    b: []const u8,
    c: u8,
};
var list = MultiArrayList(Foo){};
defer list.deinit(ally);
try list.ensureTotalCapacity(ally, 2);
list.appendAssumeCapacity(.{
    .a = 1,
    .b = "foobar",
    .c = 'a',
});
list.appendAssumeCapacity(.{
    .a = 2,
    .b = "zigzag",
    .c = 'b',
});
try testing.expectEqualSlices(u32, list.items(.a), &[_]u32{ 1, 2 });
try testing.expectEqualSlices(u8, list.items(.c), &[_]u8{ 'a', 'b' });
try testing.expectEqual(@as(usize, 2), list.items(.b).len);
try testing.expectEqualStrings("foobar", list.items(.b)[0]);
try testing.expectEqualStrings("zigzag", list.items(.b)[1]);
try list.append(ally, .{
    .a = 3,
    .b = "fizzbuzz",
    .c = 'c',
});

可以看到，使用体验都跟 ArrayList 几乎完全一模一样，但是内部确实按字段列存储的，它的内部实现大量使用了编译期反射生成友好的代码。这对 Data-oriented Programming 的场景是非常友好的。

总结

• Zig 的 const function 非常完善，大部分函数和类型都是 const evaluable 的，这也就意味着编译期 zig 可以无缝对接运行时 Zig。相比之下，Rust feature(const_eval) 至今都不支持 heap allocation，只要一个函数用到了 Vec, Box, String 等任何堆上分配的资源，都不能被标记为 const fn。
• Zig 有非常完善且原生支持的编译期反射。在 rust 中，https://github.com/dtolnay/reflect 是目前唯一的尝试，且使用起来还是非常不直观。
• Zig comptime 是图灵完备的语言，我们可以自由地实现想要的所有 pattern。
• Zig 可能会面临缺乏类型约束导致编译器报错栈很深的问题，相对来说不是特别友好，但实际体验上，zig comptime 的 stack 还是非常易懂的，而且这可以后续引入 constraints 来解决。

对比一些其他的方案

对比 C++ template：

• C++ meta programming 非常强大，图灵完备，绝对可以做到 zig comptime 同等的能力
• C++ meta programming 和 C++ 本身是两套语言
• C++ meta programming 运行非常慢
• C++ meta programming 可读性非常差
• 会 C++ 的人很可能学不会 C++ meta programming（比如我）
• Zig comptime 和 Zig 完全是一套语言，会 zig 就会 zig comptime，而且可以复用几乎所有的基础设施（参考上文）

对比 External generator（ go generate 或 build.rs） 等方案：

• 编译器内置支持而不仅仅是工具链支持
• 基于字符串的复用在造库的时候编程体验比较差
• 由于完全是由工具链（如 cargo）驱动的两个过程，在 compile 和 runtime 互相引用也只能基于字符串作为约定，很不安全。

对比 rust proc-macro：

• 与 zig 相似，proc-macro 也可以用原生 rust 进行开发
• proc-macro 基于语法树开发，相比于大部分抽象需要的信息来说过于底层，coner case 非常多，且很容易 break change。
• zig comptime 拿到的是更上层的信息，@TypeOf, @field 等都可以拿到非常开箱即用的信息。

对比 Generics：

• 相比于语言本身，都没有引入很高的复杂度
• Zig 图灵完备，能够 zero overhead 实现的抽象非常多，且不需要引入复杂的设计和学习成本。
• 不用类型体操
• 报错会更晦涩，安全性检查上会更弱（可以引入 constraint）。

如果要用一个合适的词形容 zig comptime 的话，我觉得『大道至简』是一个非常好的描述。这不仅仅是在玩梗，而是一种真实的感受。

作为大道至简的代表，Golang 在 1.18 之前一直不支持泛型广为人诟病，但 Golang 设计之初就是不希望引入过高的复杂度和学习负担，我其实可以理解这个选择（这不妨碍我不想写 Golang）。在最新的版本里，Golang 引入了一个非常残废的 Generics，支持的功能非常有限。而如果想支持更多的抽象需求，不可避免的要引入一些相对复杂的设计如 covariance，partial specification，甚至 higher kinded type，这也背离了 Golang 的设计初衷。也许对于 Golang 来说，在 1.17 的 IF 线里，选择从 go generate 进化到 comptime 是更好的选择 —— 用更低的复杂度和学习成本换来了非常强大的抽象能力。

Zig 依然是个比较早期的语言，没有发布 1.0 版本。相比于 Zig，我也更喜欢使用 Rust，但 Zig 依然有一些非常惊艳的 feature，comptime 只是其中之一。同时 Zig 也有非常好的交叉编译基础设施，我很期待 Zig 能成为未来系统编程语言中 C 的一个重要替代品。

1
2
3
4
5
6
7
8

struct A (i64, i8);
struct B (i64, i8, bool);
fn main() {
    dbg!(std::mem::size_of::<A>());
    dbg!(std::mem::size_of::<Option<A>>());
    dbg!(std::mem::size_of::<B>());
    dbg!(std::mem::size_of::<Option<B>>());
}

在这个 Rust Playground 里可以看到结果。

Rust enum 本质是一种 tagged union，对应代数数据类型中的 sum type，这里不过多展开。在 Rust enum 的实现中，通常用一个 byte 来存储 type tag（大部分 enum 不会超过 256 种类型，更多地会相应扩展），也就是说，理想情况下，以下两个结构体是等价的：

1
2
3
4

enum Attr {
    Color(u8, u8, u8),
    Shape(u16, u16),
}

1
2
3
4
5
6
7
8
9

struct Color { uint8_t r, g, b };
struct Shape { uint16_t w, h };
struct Attr {
    uint8_t tag;
    union {
        Color color;
        Shape shape;
    }
}

在这个实现下，enum 在很多场景下并不是 zero overhead 的。幸运的是，Rust 从未定义过 ABI，而带有数据的 enum 甚至是无法被 repr(C) 表示的，这给了 Rust 充分的空间对 enum memory layout 进行细粒度的优化。这篇文章会涉及一些在 rustc 1.60.0-nightly 下相关优化的介绍。

在开始具体的探索之前，我们需要准备一个辅助函数，来帮我我们查看变量的内存结构：

1
2
3
4
5

fn print_memory<T>(v: &T) {
    println!("{:?}", unsafe {
        core::slice::from_raw_parts(v as *const _ as *const u8, std::mem::size_of_val(v))
    })
}

以上面的 Attr 为例：

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

print_memory(&Attr::Color(1, 2, 3));
// [0, 1, 2, 3, 0, 0]
//  ^  ^  ^  ^  ^^^^
//  |  |  |  |    |
//  |  |  |  |    --- padding
//  |  |  |  -------- b
//  |  |  |---------- g
//  |  |------------- r
//  ----------------- tag

print_memory(&Attr::Shape(257, 258));
// [1, 0, 1, 1, 2, 1]
//  ^  ^  ^^^^  ^^^^
//  |  |    |     |
//  |  |    |     --- h, 256 + 2
//  |  |    --------- w, 256 + 1
//  |  |------------- padding
//  ----------------- tag

Option<P<T>>

P 是常见的智能指针类型，包括 &/&mut/Box。这应该是关于 enum layout 优化里最著名的一个例子了。Rust 推荐使用 Option<P<T>> 来处理可空指针，这实现了 null safety.

Option<T> 在 rust 中被表示为一种 enum：

1
2
3
4

pub enum Option<T> {
    None,
    Some(T),
}

如果不作任何优化的话，显然是存在不必要的 overhead 的，空指针可以完整地表示 None 的语义。由于这种情况太过常见，rustc 不仅针对性地做了优化，而且将其标准化了。

If T is an FFI-safe non-nullable pointer type, Option is guaranteed to have the same layout and ABI as T and is therefore also FFI-safe. As of this writing, this covers &, &mut, and function pointers, all of which can never be null.

1
2
3
4
5

let p = Box::new(0u64);
print_memory(&p);
// [208, 185, 38, 40, 162, 85, 0, 0]
print_memory(&Some(p));
// [208, 185, 38, 40, 162, 85, 0, 0]

一个不算太冷的冷知识是，这种 hack 并不是针对 Option 的，而是针对指针类型的。任何自定义的 enum 满足条件也可以达到相同的效果。

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

enum MyOption<T> {
    MySome(T),
    MyNone,
}

let p = Box::new(0u64);
print_memory(&MyOption::MySome(p));
// [208, 185, 38, 40, 162, 85, 0, 0]
// The address of `p`.
print_memory(&MyOption::<Box<u64>>::MyNone);
// [0, 0, 0, 0, 0, 0, 0, 0]
// Use nullptr to represent `MyNone`.

Option<P<T>> 可以优化的根本原因是，P 的内存表示下有一个永远非法的值，而相应的 enum 仅需要表示一个额外的值来表达多余的类型。超出这个约束就会导致这个优化失效。

1
2
3
4
5
6
7
8
9
10
11

enum MyOption2<T> {
    MySome(T),
    MyNone,
    MyNone2,
}

let p = Box::new(0u64);
print_memory(&MyOption2::MySome(p));
// [0, 0, 0, 0, 0, 0, 0, 0, 208, 185, 38, 40, 162, 85, 0, 0]
print_memory(&MyOption2::<Box<u64>>::MyNone2);
// [2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

bool, Ordering

rust 中的 bool 占用一个 byte，且仅有两个合法的值，True 和 False，对应的内存表示为 1u08 和 0u08。我们可以理解为 bool 有 254 个非法值可以供 type tag 挥霍。

1
2
3
4
5
6

print_memory(&Some(false));
// [0]
print_memory(&Some(true));
// [1]
print_memory(&(None as Option<bool>));
// [2]

更进一步地，我们可以更给力一点：

1
2
3
4
5
6
7
8

print_memory(&Some(Some(false)));
// [0]
print_memory(&Some(Some(true)));
// [1]
print_memory(&(Some(None) as Option<Option<bool>>));
// [2]
print_memory(&(None as Option<Option<bool>>));
// [3]

对应的，Ordering 有三种合法值，同样适用于这个优化。

1
2
3
4
5
6
7
8

print_memory(&Some(std::cmp::Ordering::Less));
// [255]
print_memory(&Some(std::cmp::Ordering::Greater));
// [1]
print_memory(&Some(std::cmp::Ordering::Equal));
// [0]
print_memory(&(None as Option<std::cmp::Ordering>));
// [2]

Enum

事实上，编译器并没有对 bool、Ordering 进行特判，任何种类少于 256 的 enum 本身都满足被优化的条件，即 type tag 里会有 (256 - kinds) 个空位。

1
2
3
4
5
6
7
8
9

enum ShapeKind { Square, Circle }
print_memory(&Some(ShapeKind::Square));
// [0]

print_memory(&MyOption::MySome(MyOption::MySome(1u8)));
// [0, 1]
print_memory(&(MyOption::MyNone as MyOption<MyOption<u8>>));
// [2, 0]
// 尽管 u8 本身没有空位，但是 MyOption 的 type tag 有 254 个空位，因此外层的 MyOption 的 typetag 被优化掉了。

Struct、Tuple

Struct、Tuple 等都属于 Product type。在实现中，往往是将所有字段依次存下来，并做额外的 padding。那么一个理所当然的优化是，如果 struct 的其中一个字段有空位，那么就可以将 enum tag 塞进去。

1
2
3
4
5
6
7

struct A1 (i8, bool);
print_memory(&Some(A1(1, false)));
// [1, 0]
print_memory(&Some(A1(1, true)));
// [1, 1]
print_memory(&(None as Option<A1>));
// [0, 2]

我们再回到文章开头的例子。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

struct A (i64, i8);
struct B (i64, i8, bool);

dbg!(std::mem::size_of::<A>());
// 16
dbg!(std::mem::size_of::<Option<A>>());
// 24
dbg!(std::mem::size_of::<B>());
// 16
dbg!(std::mem::size_of::<Option<B>>());
// 16

print_memory(&Some(A(1, 1)));
// [1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0]
//  ^  ^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^^ ^  ^^^^^^^^^^^^^^^^^^^
//  |           |                      |            |           |
//  |           |                      |            |           ------------ padding
//  |           |                      |            ------------------------ .1
//  |           |                      ------------------------------------- .0
//  |           ------------------------------------------------------------ padding
//  ------------------------------------------------------------------------ tag

A 和 B 由于 padding，都需要占用 16 个 byte，而 Option<B> 由于存在一个 bool 字段 .2，tag 被优化进 bool 了，因此也只需要 16 个 byte。反而 Option<A> 实打实地用了 24 个 byte。

一个很容易想到的优化是，使用 padding 中未定义的内存来存储 type tag。比较遗憾的是，A 的 layout 是在编译 A 自身时确定的，而 Option<A> 在 A 的 padding 中存储的数据是未定义行为。这也导致了一个比较滑稽的结果，多存了一个字段，Option 占用的空间反而减少了。

当然，使用 padding 存储数据是完全可能的，但前提是不能影响子数据结构的 memory layout。如果我们将 A 在 Option 中手动展开：

1
2
3
4
5
6

use std::mem::size_of;
struct A(i64, i8);
enum OptionA { Some(i64, i8), None }
dbg!(size_of::<A>()); // 16
dbg!(size_of::<Option<A>>()); // 24
dbg!(size_of::<OptionA>()); // 16

这种情况下，由于 OptionA 的数据直接保存在 Some 内，实例化的时候完全可以使用 padding 存储 type tag，而不会引起潜在的未定义行为。

优化自定义结构的可能性

目前，所有 enum layout 相关的优化都适合由编译器针对特定的类型进行 hack 来实现的，我们无法自己控制我们自定义的 struct 在 enum 中的 layout。为了优化一些常用场景，rust 又提供了 NonZero* 等辅助结构体，用来表示非 0 的整数，与此同时编译器会让 size_of::<Option<NonZeroU8>> == size_of::<u8>。但这只能由标准库 case by case 处理，而真实的需求是非常复杂的，比如有时候我们可能需要 NonMaxU64，或者例如使用了第三方库的 Option<ordered_float::NotNan<f64>> 就无法被优化。

针对自定义接口的优化需要引入非常复杂的机制，在编译期告诉编译器一个类型非法的内存结构有哪些。我目前感觉一个可能的实现是 const trait + const iterator，给编译器提供潜在的非法值的迭代器。不过目前没有看到相关的 RFC。

这篇文章所有的 example 可以在 Rust Playground 找到。

即将迎来 25 岁生日，随便记录一些想法

加入与离开阿里

时间飞逝，回忆起决定加入阿里的日子，仿佛没有过去多久一样。

因为真的没有过去多久

我在阿里的这段经历大约一年半，从个人体验来说，甚至可以用远超预期来形容（毕竟外界对阿里的风评太差了导致我的预期非常低），我发现阿里也有很多不 PUA，踏踏实实做事的 leader 和氛围健康的组，仅仅因为阿里就贴死标签是不可取的，想来大厂做数据库的同学欢迎找我内推，极力推荐。

在阿里工作的这段时间，为我们组的产品做了一些还算有意思的 feature，有兴趣的可以看我们组的专栏中跟事务有关的文章。

之所以选择那么快离开，更多的是对自己的一些成长焦虑：比如感觉做的东西都是非常 trivial 的东西，明明花了不到一个月就完全搞懂了，却需要花费十倍以上的时间在跟一些历史包袱作斗争上；做事情很难，推事情很难；还有很多很多

我一度把这种成长焦虑误以为这是职级焦虑，毕竟某个scope内最年轻的P7听起来是个很好听的title，也带来了巨大的对保持快速晋升的渴望，看不到合适的机会是令人焦虑的。但我很快就发现这只是表象，在我观察了许多P8，发现他们能做的事情甚至可能还不如我之前作为一个 new grad 在旷视能做的事情多后，我明白这与职级无关，是一种对成长停滞的焦虑，这样的P8也并非是我现在想追求的东西（当然他们的package还是很动人的）。

在内部听过一个高P的经验分享，谈他们的成长经历，我发现他描述的几年前野蛮生长中的阿里云更符合我的期待，而这样的机会随着阿里云各个生态位的补足，已经非常稀缺了。现在的阿里云有很强的数据库团队，但没有我的机会。

新的征程

熟悉的朋友应该都已经猜到了，在经过多方比较以后，我最终选择了加入一家姚班学长创立的明星 startup，希望在一个新赛道能做出一些事情。虽然跟之前的方向不太 match，但我很看好这个新方向，也十分相信自己的能力。预期下周就会加入～

在跟 leader one one 的时候，我能感受到他的遗憾，其实我也十分遗憾，我们聊了很多事情，从团队，到阿里，到行业。在最后的最后，leader 叹了一口气，我跟他说，比起遗憾，你更应该祝我早日财富自由 ( ´ ▽ ` )ﾉ

在 leader 的祝福中，我结束了这段旅程。对于阿里这家公司，我没有什么好感（当然相比加入之前好很多），我更相信“一鲸落，万物生”。但对于团队的很多人，我还是非常感激与祝福。

在阿里的最后一个月，除了交接工作以外，我把之前积压下来想读的七八篇 paper 都看了一遍，写了好几篇文章，又看了不少 compiler 有关的东西，感觉停滞了一段时间的姿势水平又开始 +1s +1s 地流动了。

一次生日与另一次生日

每次生日都是非常开心的事情，但既满怀忐忑又充满希望的上一次生日应该是发生在八年前。

八年前的纯弟弟在一所野鸡区重点放弃学业一个人花了一年自学竞赛，这是他人生中第一次证明自己的考试前的一个生日。这次生日过后纯弟弟成了全校前后几十年唯一一个清北（按照当年人人网友的说法，二本变清华）。恭喜纯弟弟 🎉

那么这次纯哥哥也请相信自己的选择吧！

Abstraction

从最简单的概念来说，Noria 就是一个异步的增量物化视图，每条更新被异步地推送到用户创建的每个 External View 上用于查询，这些是计算图的叶子节点。

这跟 Streaming system 也比较像，唯一的区别是它本身就是个数据库，因此它持久化了 Base Table。主体不记录了，主要讲讲它的一些特殊设计。

Join

Window Join 是 Flink 的算子之一，Window Join 的两个上游算子的输入流仅在一个时间窗口内的才会被合并，而一些变体如 Interval Join，只不过是把这个时间窗口从一个矩形变成了三角形或者梯形。这种流式 Join 跟传统数据库的 Join 有很大区别，仅能处理一部分场景。很多 Join 往往并不是在一个窗口发生的，比如老用户和新订单之间的 Join 就无法通过这种 Window Join 完成，而需要借助一些其他的系统，比如维度表。当然 Flink 只是个流式计算引擎，不可能在 join 算子维护太多的状态，只支持一个窗口是正常的。Noria 的定位则是一个流式数据库，它希望解决所有的 Join 需求。Noria 会在 Base Table 上保存所有数据，而 Join 算子上仅保存部分状态。在 Join 无法匹配成功时，通过递归的 upquery 向上查找，直到落到 Base Table 为止。（这其实很类似 TP 里增量物化视图的做法了）

Partial State && Upquery

Partial State 和 Upquery 是贯穿 Noria 整个系统的，而不仅仅是为了解决 join 的问题。当我们在 Noria 里新建一个物化视图时，这个视图以及所有新建的算子都是 Empty State 的。这也就给 Noria 带来了一个好处，算子变更非常地简单且快速。在有对这个视图的查询到来时，会通过 Upquery 向上 Upquery 查询数据（直到 Base Table），并一路向下填充每个算子的状态。而当整个系统状态过多时，又会通过一些策略 Evict 掉一些算子的部分状态，在需要的时候重新 upquery 计算。这样整个系统的空间占用就是 bounded 的。

一致性

Noria 提供了 eventually consistency 的语义保障。对 Noria 的每个算子来说，会有两个操作：来自上游的 Update 和来自下游的 Upquery，Upquery 本身不会修改这个算子的状态，但 Upquery 的结果是会用于计算更下游算子的更新数据的（类似读后写），因此也会影响最终一致性。Noria 的做法是在每个算子上提供 Update/Upquery 的 Ordering，类似于 Lock Based 的思路，而不是引入 MVCC。脑补了一下，如果是基于 MVCC 的实现，Upquery 会查到一个 snapshot 的数据来更新下游，那么就会稳定产生 write skew，而达不成 eventually consistent。

一些个人看法

我觉得 Noria 最大的亮点是这个设计把 Streaming 和 Query 做到了同一个引擎里，区别仅仅是在计算图上流向的区别 —— Query 是从叶结点（External View）到根节点（Base Table）向前地 Pull 数据并选择性地缓存，而 Streaming 则是从根节点向叶结点 Push 数据的更新。从另一个角度看，Noria 的每个 External View 都是 Logical View 和 Materialized View 按照一定比例混合的结果，而 Eviction 策略调整两者的比例，我们考虑两种情况：

1. Evict All：所有算子都被当成 Stateless 的，这种情况下所有的查询都会走 upquery，等于典型的 AP 查询。
2. Evict None：所有算子都保存 Full State，所有查询都只走叶子节点的 External View。

实际的状态则是多个维度 trade off 过的 Partial State：

1. 访问频率更高、重新计算代价更高、状态存储占用更低的状态更倾向于被保留。
2. 访问频率更低、重新计算代价更低、状态存储占用更搞的状态更倾向于被淘汰。

这种 Partial State 符合大量应用的特征，很多分析往往是更关注头部用户的分析结果，头部用户无论是产出内容还是粉丝数交互数都更多，相同的查询重新计算的代价也高。而应用的不活跃用户往往查询频率很低，且重新从 Base Table 计算代价也很低，用跟头部用户相同的状态（空间、写放大）为他们维护所有 View 是很不划算的事情。Noria 可以全自动地做这个事情。

从这个结果来看，Noria 在开头对自己的定位就非常精准了，它是一个 eventually consistency、near realtime、以及非常易于使用的 Redis 替代品，用户可以像直连数据库一样达到缓存的效果，同时还有更好的缓存语义。

这套设计可以极大改进现在应用开发者对数据库地使用方式，举个实践上更强的例子，现在网站对内容点赞、评论等的计数往往是需要业务手动维护：

1
2
3
4

BEGIN;
INSERT INTO `likes` (`user_id`, `tweet_id`) VALUES ("zty0826", "496733277274013696");
UPDATE `tweets` SET `like_count` = `like_count` + 1 WHERE `tweet_id` = "496733277274013696";
COMMIT; 

除了简单的业务逻辑，我们还需要维护各个缓存的状态，like_count 只是最简单的状态之一。基于 Noria，我们可以用物化视图的方式去做这个：

1
2

CREATE MATERIALIZED VIEW `tweet_likes` AS
SELECT `tweet_id`, count(1) FROM `likes` GROUP BY `tweet_id`;

不同于经典物化视图的是，Noria 里的 tweet_likes 表可以仅维护远远少于 tweets 表量级的状态。像 496733277274013696 这种热门、常看常新的 tweet 状态肯定会被长期缓存在 tweet_likes 表里，而大量冷门的、过期的甚至从来没有人看过的 tweet 则只会存在于 Base Table（likes）中，即使偶尔需要，查询代价也非常低，当一个冷门 tweet 114514114514 因为某种未知原因被查询，tweet_likes 表里早就淘汰了对应的数据时，Noria 会自动 Upquery，等效于对 Base Table 执行了一个查询：

1

SELECT count(1) FROM `likes` WHERE `tweet_id` = "114514114514";

这个案例听起来更像 ”HSTP“（自造词） 而不是 HSAP？总之，大量复杂的逻辑都被 Noria 接管了，因此业务代码只需要维护最简单的逻辑就够了，通过一套系统处理这些还是很 fancy 的。

上面是从数据库物化视图的角度看待这个系统，接下来从 streaming system 的角度来看它解决的问题（主要是有 Base Table 就能做很多事情）：

1. 有对历史数据查询的能力，解决了 Join 算子语义不足的问题。
2. Paper 中没提，但根据我的想象，对 Watermark 的策略可以更激进和自动化，反正如果 Lateness 多了就可以 evict 掉中间算子的状态，重新从 Base Table 算。

吹完喜欢的点，聊聊局限性：

1. 状态维护：Incremental materialized view 的状态维护逻辑本身就非常复杂，对所有 SQL 算子完整支持的复杂度远超查询引擎，而 Noria 为这个本来已经非常复杂的状态维护又引进了 Partial State。从 Noria 开源的代码来看，它的算子支持是非常有限的。
2. 操作支持：很多算子对 Update/Delete 的支持是非常难的，比如 min/max/distinct/…，Noria 直接绕过了这个问题（暂时只支持 Insert）。
3. 确定性：基于这个设计，系统可以调整的参数太多，一个查询的不确定性更高，非常依赖于每个算子的 Eviction 策略，一旦预测错误就会引起大量查询甚至雪崩，这个要做好 QoS 的挑战也更大。
4. 数据库本身的复杂性：Noria 也做了一些其他的工作，包括 Scalability 和容错，不过相比于其他数据库产品做得非常一般，这些都是一个完整的产品需要重复造轮子的部分。

Noria 这篇 paper 做了一个开源实现，是一个 45k 行代码的 toy，而且我并没有 run 起来，疑似已经停止维护了。相对于真正可以使用的数据库产品，还有很多复杂的情况需要处理，不过这个设计思想还是给了很大的想象空间。

首先 brief 一下 Napa 这篇 paper 有比较有意思的点：

1. 精细的成本管理，把 trade off 的权利交给用户的同时避免了很繁琐的细节配置。
2. 引入了类似 Watermark 的一个新概念 QT (Queryable Timestamp) 的来向用户描述 freshness（但跟 watermark 有区别）。

Napa 的核心概念

Napa 是 Google 用来替代 Mesa 的新一代数仓，向 Google 的广告客户以及内部用于分析。一个最重要的变更是引入了 Materialized view 的概念来加速查询。有几个重要的指标是 Napa 关心的：

1. Ingestion throughput：导入数据的速度是至关重要的
2. Query performance：查询请求的性能（延迟）
3. Data freshness：查询到的数据是否更新？一分钟内的数据还是几小时内的数据都行？
4. Resource Cost：每导入一定量数据需要的各种资源。

当然除此之外，Durability 和 Fault tolerance 肯定是必要的。

Ingestion throughput 是不可放弃的选择（数据都导不进去谈什么查询），剩下的都可以交给客户端来 trade off。

LSMT

Napa 中直接导入数据的表称为 base table，而每个 base table 会有若干关联的 materialized view（n to m 的关系，每个 materialized view 也可能不止关联一个 table）。每个 Materialized view 的结构类似一颗 LSM Tree，一条外部数据从其他系统导入到 Napa 需要经过一系列过程：

1. Ingestion
   对应到 LSM Tree 里应该就是 write memtable + WAL 的过程，不过这里不需要写 memtable，这个类似 WAL 的结构叫做 non-queryable delta，由于更新是 apply 到 base table 上的，所以这个数据只需要写一份 base table，就可以认为 ingestion 成功了，保证了 durability。Ingestion 的过程也会在多个机房同步。
2. Compation and view aintenance: Napa 的 Compaction 混合了好几个概念，我们一个个抽出来：
   • Non-queryable delta -> View Queryable delta
     根据我们上面的描述，Non-queryable delta 只是 base table 的 WAL，那么我们首先需要把这个 log 中的每一项更新读出来，并根据每个 Materialized view 定义的算子进行转换，确定是否要 apply 到对应的 view 中。同时我们也会做一些排序、索引的工作，最后生成的是 n 个 queryable delta（对应于 LSM 中 SST 的概念），n 为需要更新的 view 的数量。
   • Queryable delta merge: 与 LSM 的 merge 完全相同，定期将一部分 Queryable delta 合并为一个更大的 Queryable delta。

而对一个 view 进行一次 query 的过程跟 LSM 也完全相同，即并行地在若干个 delta 进行查询，并将结果合并。

而几个关键的指标基本都受到这套体系的影响：

1. Ingestion throughput：如同 LSM Tree 一样，ingestion 成功即导入成功，高度写优化，导入飞快。
2. Query performance，取决于两个要素：
   • view 的数量，view 的查询性能会比 base table 更好
   • 查询的时候需要对多少个 delta file 查询，越多性能越差
3. Data freshness：Non-queryable 的数据是完全不可读的，因此查询的结果至少会延迟到 non-queryable delta 的合并。除此之外，我们还可以自己选择仅读取一部分的 queryable delta，这样会牺牲 freshness，但是能提高 query performance。
4. Resource costs：Base Table 的更新是必要的，因此可以认为完全是 view 的维护成本，取决于 view 的数量和 compaction 的频率。

Queryable Timestamp

QT 是一个表示 freshness 的概念，Now() - QT 代表了 frsehness 的 bound。QT 有一个上限，就是不能超过 Non-queryable delta 里的下界（因为 Non-queryable delta 完全不可查询），QT 是受到用户配置影响的。查询时会合并到 QT 为止所有的 delta（而不是全部的 delta）。

tradeoff query performance

要 data freshness，但 query 可以慢点儿

1. 少建 view，慢慢查
2. 少做 view aintenance task（delta file 会特别多）
3. QT 设置得足够高（查询时会合并所有的 delta file 中的结果）

tradeoff data freshness

需要 query performance，但是读到的数据可以旧点儿

1. 少做 view aintenance（delta file 会特别多）
2. QT 设置得足够低（查询时需要合并的 delta file 特别少）

tradeoff resource costs

既要 query performance，又要 data freshness。

没有什么是充钱解决不了的。

1. 多建 view。
2. 频繁做 view aintenance。
3. QT 设置得足够高

外部系统

Google 的 infra 是真的强，所以我感觉其实 Napa 做的最重要的事情就是上面这个 LSMT 了，其他的都通过外部系统解决。Napa 使用了 Colossus（下一代 GFS）做文件存储，并且用 F1 query 做了物化视图的 Planner 和 Optimizer（我觉得是工程量最大的一部分），以及面向客户端的 query servering。Napa 自身更多负责视图的维护。

Others

物化视图的自动淘汰

文中提了很多 challenges，但其中我感觉比较关键的一点，物化视图的及时淘汰。对用户来说，QT 是个 database 级别的概念，如果有一个物化视图的更新比较慢（也许是视图太复杂，或者 plan 优化不够），那么 Now() - QT 就会越来越大，freshness 无法保证，需要及时淘汰掉这些 view（读到这里的时候我才发现原来 view 可能不是用户指定创建的，居然还是可以自动加减的。。就离谱）。

为什么 QT 不是 Watermark？

回收一个开头的疑问，因为 Napa 并不是一个 streaming system，它的输入是 Ordering 的（或者说完全基于 Process time 而非 Event time）。Watermark 描述的是 query 的 completeness（即 query time < watermark 代表一定能读到完整的结果），而 QT 描述的是 freshness（即 query time < QT 可以获得符合预期的性能）。

Napa 提供了怎么样的一致性？

从我个人的 taste 来看，一个让人用得舒服的数据库，无论是 TP 还是 AP，提供 atomic batch update 和 global snapshot read （即使是 stale snapshot）是必要的选择。这篇 paper 关于一致性的描述非常少，不过两点观察：

1. Mesa 内置了 MVCC，提供了 strong consistency，Napa 作为 Mesa 的 drop-in replacement 不提供的话我感觉用户不会买帐？
2. LSMT 的架构下做 MVCC 是非常简单的事情。

Summary

总体来说感觉还是比较中规中矩的一些 idea，不过也可以看出 Google 对工程细节的把控非常深了。比如同样是 LSMT 的架构，我怀疑换成 TiDB 的话，robust query performance 可能更取决于查询线程池的调度、gRPC 各种不确定因素而非 delta file 的数量。只有在工程细节上优化得足够好，才能在各个指标上更加可控的 trade off configuration。

数据库服务需要很强的确定性，相比于 auto driven 来说，这种 trade off configuration 说不定对用户是个更好的选择。（然后我准备去看另一篇 PVLDB auto driven 了）

彩蛋：blog.zhuangty.com 终于用上 Google analytics 了，说不定 tygg 在看报表的时候也用上 napa 了

分页功能是网站常见的需求之一，对应到数据库中的实现，通常会用 LIMIT ? OFFSET ? 的子句来实现，然而这是很多网站被攻击的潜在原因之一。在主流的数据库实现中，这种查询的效率往往非常的低下。本文脑洞了一种高效支持 OFFSET LIMIT 的方法。

首先让我们看看到底有多慢。以 MySQL 为例：

首先我们在 mysql 中创建一张简单的表，并用 sysbench 导入 10M 条数据：

1

sysbench --mysql-host=127.0.0.1 --mysql-db=test --mysql-user=root oltp_point_select prepare --table-size=10000000

这并不是很大的一个数据量，然后我们执行一条简单查询：

1
2
3
4

select * from test.sbtest1 limit 10 offset 9000000;

10 rows in set
Time: 7.993s

这样一个简单的查询需要花费 8 秒左右的时间，而且当我用 sysbench 去压这条 SQL 的时候它直接挂了。在具体的实现，OFFSET LIMIT 这种操作基本都是通过扫描来实现的，很难跳过前序的行数，而 OFFSET 越大意味着需要扫描的数据越多。一个正常的用户通常只会刷前几页的数据，但是被 hack 的时候就很难说了，也许只需要把 url 里的 pageNo=1 改成 pageNo=10000 并且高并发请求一下，一些网站就挂了，当然现在这种场景已经很少了。

很难跳过不代表无法跳过，我们从 MySQL 底层的索引数据结构 B+ 树说起。

上图是一个简单的两层4阶 B+ 树，由一个非叶节点和四个叶节点组成，叶节点之间通过链表连接，用于提高 scan 性能。

我们想做一个分页查询

1

SELECT * FROM t OFFSET 4 LIMIT 2;

对应到存储结构上，就是希望找到这个索引树上第四个到第五个元素 btree.range(4, 6)，20 和 24。目前的实现里，我们显然只能左到右扫描，在无意义地访问了连个不需要的节点后，我们才能找到正确的节点和对应的数据。很显然，如果我们在每个非叶节点上实时维护所有子树的 count 的话，我们就能更快地找到结果。

通过非叶节点上的 count 记录，我们就可以先通过 root 节点的 count，确认第四条纪录从第三个叶节点开始，然后直接找到数据并开始扫描，总体时间是 $log(n)$ 的复杂度。当然，这会导致我们每次插入或者删除数据的时候也需要更新一整条树路径上的所有非叶节点。

MVCC

在支持事务的数据库里，往往使用 MVCC 来减少读写之间的锁冲突。MVCC 在叶节点中的数据，存的是一串链表（O2N），代表了数据的更新记录，而 seq 代表了。支持了 MVCC 后，我们很快发现我们的 count-B+ tree 不好使了。

我们分别进行了一次插入，一次修改和一次删除，这也就导致了我们查询不同 version 的时候，正确的结果是不一样的。

1
2
3

insert(18, "j1", version=3)
update(16, "d2", version=5)
delete(20, version=7)

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

SELECT * FROM t OFFSET 4 LIMIT 2; // version = 2
|key|value|
|20 |e1   |
|24 |f1   |
SELECT * FROM t OFFSET 4 LIMIT 2; // version = 4
|key|value|
|18 |j1   |
|20 |e1   |
SELECT * FROM t OFFSET 4 LIMIT 2; // version = 8
|key|value|
|18 |j1   |
|20 |e1   |

我们的计数只能支持对最新数据的查询，而在修改发生之前已经创建好的 ReadView，我们就无能为力了。

多版本计数

既然数据可以做多版本，那么我们的计数理所当然也可以。

在多版本计数上，我们“如愿以偿”地查到了我们想要的结果。

B+ 树的分裂

1

insert(37, "k1", version=9)

上面的思路依然是死路一条，我们考虑 B+ 树的分裂和合并，多版本计数是完全不可维护的。

可持久化数据结构

我们先直接看一下我们用可持久化 B+ 树优化后的结果，为了简化做图，我们假设我们仅做了两次插入：

1
2

insert(18, "j1", version=2)
insert(37, "k1", version=3)

可以看到，相比于原来的 B+ 树，我们引入了两个变化：

1. 不再就地修改数据。
2. 删除了叶节点之间的指针（这删了还能叫 B+ 树吗？-_-）

在第一次进行插入后，我们直接 copy 了一份根节点和第二个叶节点，并插入数据，新的节点（黄色）另外三个指针依然指向原来的叶节点，只有第二个指针指向了新的节点。

而第二次插入直接引发了分裂，因此我们一共创建了五个新节点， 包括：

1. 原先的第四个节点分裂后的新的叶节点（30，37 开头）
2. 原先的 root 节点分裂后的两个非叶节点上（10、30 开头的绿色节点）
3. 新的 root 节点

可以看到一波操作之后，我们拥有了三个版本的 B+ 树！每个版本都是一个符合我们预期的全局快照，我们查找的时候可以先快速找到需要的版本，然后在每个版本上快速地进行符合我们优化预期分页查询。与此同时，我们也并没有占用三倍的空间，理论的空间复杂度是 $n+m log(n)$ 其中 n 是树的大小，m 是维护的版本数。

可持久化数据结构 是一个数据结构上的概念，但跟 MVCC 不谋而合。而当我们尝试在数据库上使用了可持久化B+树后，我们事实上是把 MVCC 做到了整个索引的数据结构里，而非行记录里。整个索引结构从 BPTree<Key, PersistentList<Value>> 转变为了 List<PersistentBPTree<Key, Value>>。

另一个问题是，为什么我把叶节点之间的连接指针删掉了，因为不删没法做，原因可以留给读者思考一下，这也是可持久化数据结构的局限性之一。

Mixing mode

考虑到这种实现的 clone 代价还是太高，也许可以混合三种方式做这个优化：

1. UPDATE 时，只添加行记录，做行级 MVCC。
2. INSERT/DELETE 但不涉及树的结构变更时，使用多版本计数（可以记在内存里，反正可以恢复出来）。
3. 发生树结构的变更时，直接创建一个新版本的 B+ 树。

查询时：

1. 先通过全局的版本链表找到一个 B+ 树。
2. 通过 B+ 树非叶节点上的多版本计数，快速定位到行记录。
3. 通过行记录上的多版本 MVCC，定位到需要读取的数据。

（实现上想想就很恶心，所以连图都不想画了）

后记

后来还写了个 Rust 的实现，但写得不太好不想开源了，反正可持久化数据结构无脑 Arc 就对了

分页其实是个很小众的需求，在数据库支持不佳的情况下，业务上也有了很多替换解决方案，完全没有必要花很大代价去做优化，所以这篇文章还是搞笑为主的（不搞笑我肯定发 paper 了谁写 blog 啊），但仔细想想发现这个 idea 居然还挺 novel 的。。。

1. 一种不同于 LSM 的 append only B+ 树存储引擎方案
2. 不修改数据结构，天然无锁并发，不需要处理 B+ 树复杂的细粒度锁逻辑
3. 可以在非叶节点上支持很多满足事务隔离要求的预聚合，不局限于分页
4. 做 interval GC 很容易

当然代价也是很明显的，写放大和空间放大前所未有的大，所以还是没有意义 ：）

好玩为主，很久没有 follow 过存储引擎的东西了，idea 如有雷同都是巧合（

Builder Pattern

Builder Pattern 是 rust 在复杂对象构造上推荐的一种设计模式，一个常见的 Builder 实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

pub struct A {
    a: i32,
    b: i32,
    c: i32,
}

#[derive(Default)]
pub struct ABuilder {
    a_: i32,
    b: i32,
    c: i32,
}

impl ABuilder {
    pub fn a(self, a1: i32) -> Self {
        self.a = a1;
        self
    }

    pub fn b(self, b1: i32) -> Self {
        self.b = b1;
        self
    }

    pub fn c(self, c1: i32) -> Self {
        self.c = c1;
        self
    }

    pub fn finish(self) -> A {
        A {
            a: self.a,
            b: self.b,
            c: self.c,
        }
    }
}

#[cfg(test)]
mod tests {
    use crate::ABuilder;
    #[test]
    fn it_works() {
        let _a = ABuilder::default().a(0).c(0).b(0).finish();
    }
}

必选参数

这时候我们接到了一些奇怪的需求，要把 a 和 b 作为必选参数（那为什么不把 a 和 b 传进 ABuilder::new 的参数呢，小编也很好奇，但是这么写就水不了文章了）。

我们可以为 ABuilder 引入三个 bit 的常量状态，标识每个参数是否被设置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

#![feature(const_generics)]
#![feature(const_evaluatable_checked)]

enum Assert<const COND: bool> {}

trait IsTrue {}

impl IsTrue for Assert<true> {}

struct A {
    a: i32,
    b: i32,
    c: i32,
}

#[derive(Default)]
struct ABuilder<const S: u64> {
    a: i32,
    b: i32,
    c: i32,
}

impl<const S: u64> ABuilder<S> {
    fn a(self, a1: i32) -> ABuilder<{S | 1}> {
        ABuilder::<{S | 1}> {
            a: a1,
            b: self.b,
            c: self.c,
        }
    }

    fn b(self, b1: i32) -> ABuilder<{S | 0b10}> {
        ABuilder::<{S | 0b10}> {
            a: self.a,
            b: b1,
            c: self.c,
        }
    }

    fn c(self, c1: i32) -> ABuilder<{S | 0b100}> {
        ABuilder::<{S | 0b100}> {
            a: self.a,
            b: self.b,
            c: c1,
        }
    }
}

impl<const S: u64> ABuilder<S> where Assert::<{S & 0b110 == 0b110}>: IsTrue {
    fn finish(self) -> A {
        A {
            a: self.a,
            b: self.b,
            c: self.c,
        }
    }
}

#[cfg(test)]
mod tests {
    use crate::ABuilder;
    #[test]
    fn it_works() {
        let _a = ABuilder::<0>::default().a(0).c(0).b(0).finish();
        let _b = ABuilder::<0>::default().a(0).c(0).finish(); // Compilation failed
    }
}

迫于无奈，我们开了两个 incomplete feature 来做这个需求，一路顶着 warnings 编译成功了。

在上面的实现里，我们通过一个 Assert 的 trick，允许我们在 impl 的 block 上为常量参数 S 添加条件判断，而 S 本质上就是一个 bitflags，标识了某一个参数是否被设置过，为此我们仅为 ABuilder<S> where Assert::<{S & 0b110 == 0b110}>: IsTrue 实现 finish 方法，这就满足了我们的需求。

报错大概长这样

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

error[E0599]: the method `finish` exists for struct `ABuilder<{S | 0b100}>`, but its trait bounds were not satisfied
  --> src/lib.rs:70:62
   |
4  | enum Assert<const COND: bool> {}
   | ----------------------------- doesn't satisfy `Assert<{S & 0b110 == 0b110}>: IsTrue`
...
17 | struct ABuilder<const S: u64> {
   | ----------------------------- method `finish` not found for this
...
70 |         let _b = ABuilder::<0>::default().a(0).c(0).finish();
   |                                                     ^^^^^^ method cannot be called on `ABuilder<{S | 0b100}>` due to unsatisfied trait bounds
   |
   = note: the following trait bounds were not satisfied:
           `Assert<{S & 0b110 == 0b110}>: IsTrue`

只能传递一次的参数

此时我们又对 c 提了一些奇怪需求，我们希望 c 是可选参数，但是最多只会被传递一次（即 0 或 1 次）：

举一反三，这个需求太好改了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

#![feature(const_generics)]
#![feature(const_evaluatable_checked)]

enum Assert<const COND: bool> {}

trait IsTrue {}

impl IsTrue for Assert<true> {}

struct A {
    a: i32,
    b: i32,
    c: i32,
}

#[derive(Default)]
struct ABuilder<const S: u64> {
    a: i32,
    b: i32,
    c: i32,
}

impl<const S: u64> ABuilder<S> where Assert::<{S & 1 == 0}>: IsTrue {
    fn a(self, a1: i32) -> ABuilder<{S | 1}> {
        ABuilder::<{S | 1}> {
            a: a1,
            b: self.b,
            c: self.c,
        }
    }

    fn b(self, b1: i32) -> ABuilder<{S | 0b10}> {
        ABuilder::<{S | 0b10}> {
            a: self.a,
            b: b1,
            c: self.c,
        }
    }
}

impl<const S: u64> ABuilder<S> where Assert::<{S & 0b100 == 0}>: IsTrue {
    fn c(self, c1: i32) -> ABuilder<{S | 0b100}> {
        ABuilder::<{S | 0b100}> {
            a: self.a,
            b: self.b,
            c: c1,
        }
    }
}

impl<const S: u64> ABuilder<S> where Assert::<{S & 0b110 == 0b110}>: IsTrue {
    fn finish(self) -> A {
        A {
            a: self.a,
            b: self.b,
            c: self.c,
        }
    }
}

#[cfg(test)]
mod tests {
    use crate::ABuilder;

    #[test]
    fn it_works() {
        let _a = ABuilder::<0>::default().a(1).b(1).c(1).finish();
        // let _b = ABuilder::<0>::default().a(1).c(1).c(1).b(1).finish();
        // let _c = ABuilder::<0>::default().a(1).c(1).finish();
    }
}

总结

这确实是一篇搞笑文章，所有需求都是我在学习 const generics 先进语法的时候随便做的实验，事实上 Builder Pattern 并不适用于这些奇怪的需求，而且用到了 const_evaluatable_checked 这种纸糊的 feature 也不可能用于生产。有一个真正用于生产的 crate typed-builder 思路跟我类似，不过直接生成了一个长度为 n （n 为 fields 的数量）的 tuple 来记录状态，更合理一些。不过基于 const_evaluatable_checked 可以实现很多奇奇怪怪的需求，比如可以做编译期状态压缩 DP（rustc 爆炸中），还可以做一些奇奇怪怪的限制（比如限制一个方法最少被调用 n 次，最多被调用 m 次，完全想不到什么场景需要），可以认为是对 Rust typesafe state machine 能力的一个强化了，对于一些比较相似的状态转换过程，我们可以直接基于 const generics 来减少重复代码（DRY）。

上午摸鱼的时候，读了雷宇哥哥的文章 I beat TiDB with 20 LOC，这篇文章非常有意思，推荐 go 吹/go 黑都可以读一读，通过这篇文章，我发现了 cgo 比想象的要快很多，以及 go 编译器比想象更烂，以至于 cgo 的 overhead 完全抵消了还不够。在学习 TiDB 先进经验的时候，看到了一段有意思的代码：

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

func (b *builtinArithmeticPlusIntSig) plusSS(result *chunk.Column, lhi64s, rhi64s, resulti64s []int64) error {
    for i := 0; i < len(lhi64s); i++ {
        if result.IsNull(i) {
            continue
        }

        lh, rh := lhi64s[i], rhi64s[i]
        if (lh > 0 && rh > math.MaxInt64-lh) || (lh < 0 && rh < math.MinInt64-lh) {
            return types.ErrOverflow.GenWithStackByArgs("BIGINT", fmt.Sprintf("(%s + %s)", b.args[0].String(), b.args[1].String()))
        }

        resulti64s[i] = lh + rh
    }
    return nil
}

要理解这段代码，首先我们需要理解什么是 chunk。chunk 是一种列式内存格式，是 Apache Arrow 的一种实现，具体可以参考 TiDB 源码阅读系列文章（十）Chunk 和执行框架简介。对于这里的 Int 类型，Column 的内部其实是一个 int64 array 和一个 bitmap。

这段代码的目的就是将 lhi64s 和 rhi64s 加和的结果保存到 resulti64s 中。为了彻底理解这段代码，我们还需要关注一下调用它的函数 builtinArithmeticPlusIntSig.vecEvalInt：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

func (b *builtinArithmeticPlusIntSig) vecEvalInt(input *chunk.Chunk, result *chunk.Column) error {
n := input.NumRows()

// ...
// Calculate lh and rh
result.MergeNulls(lh)
result.MergeNulls(rh)

lhi64s := lh.Int64s()
rhi64s := rh.Int64s()
resulti64s := result.Int64s()

isLHSUnsigned := mysql.HasUnsignedFlag(b.args[0].GetType().Flag)
isRHSUnsigned := mysql.HasUnsignedFlag(b.args[1].GetType().Flag)

switch {
case isLHSUnsigned && isRHSUnsigned:
err = b.plusUU(result, lhi64s, rhi64s, resulti64s)
case isLHSUnsigned && !isRHSUnsigned:
err = b.plusUS(result, lhi64s, rhi64s, resulti64s)
case !isLHSUnsigned && isRHSUnsigned:
err = b.plusSU(result, lhi64s, rhi64s, resulti64s)
case !isLHSUnsigned && !isRHSUnsigned:
err = b.plusSS(result, lhi64s, rhi64s, resulti64s)
}
return err
}

这段代码主要是根据加法算子两侧表达式的类型，决定调用具体的实现，而 plusSS 则是其中的一种（两个有符号整数相加）。但在调用具体的实现之前，已经对 lh 和 rh 分别调用了 result.MergeNulls()，因此在 plusSS 中只需要对 result 是否为空进行判断，决定是否跳过计算。

1
2
3

if result.IsNull(i) {
    continue
}

1
2
3

if (lh > 0 && rh > math.MaxInt64-lh) || (lh < 0 && rh < math.MinInt64-lh) {
    return types.ErrOverflow.GenWithStackByArgs("BIGINT", fmt.Sprintf("(%s + %s)", b.args[0].String(), b.args[1].String()))
}

理解剩下的代码就非常直观了，做一个 overflow 判断，然后返回相加的结果。这也是针对不同符号的 Plus 函数最大的区别。

在 MySQL 大部分 expression 的逻辑，对于输入参数包含 NULL 的情况，输出参数往往也是 NULL，TiKV 为了 DRY，使用宏简化了这个逻辑。

1
2
3
4
5
6

#[rpn_fn]
pub fn like<C: Collator>(target: BytesRef, pattern: BytesRef, escape: &i64) -> Result<Option<i64>> {
    Ok(Some(
        like::like::<C>(target, pattern, *escape as u32)? as i64
    ))
}

这段代码进行宏展开后和上面的 go 代码类似，如果参数有 null 的情况会直接跳过真实 like 的调用。但对于 Plus 这种基础的数学运算函数，事情就有了一些变化。一个常识是，分支的代价其实比 add 这种基础指令大很多，在高效的列式执行逻辑里，这里引入了两个 branch 操作，相比于运算（一次 add）本身来说，这两个 branch 才是最大的 overhead。

且这两个 branch 是必要的 check，同时也是 unlikely 的（大概率会走 else 分支）。在完全不改变代码逻辑的情况下，我们可以将它们优化成一个 branch。

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

func (b *builtinArithmeticPlusIntSig) plusSS(result *chunk.Column, lhi64s, rhi64s, resulti64s []int64) error {
for i := 0; i < len(lhi64s); i++ {
lh, rh := lhi64s[i], rhi64s[i]

if (lh > 0 && rh > math.MaxInt64-lh) || (lh < 0 && rh < math.MinInt64-lh) {
if result.IsNull(i) {
continue
}
return types.ErrOverflow.GenWithStackByArgs("BIGINT", fmt.Sprintf("(%s + %s)", b.args[0].String(), b.args[1].String()))
}
}
}

是的，代码改动只有三行，且只是原封不动 Copy & Paste（点题），我们来看看 benchmark 的结果。TiDB 非常贴心地提供了表达式模块的 benchmark 脚本，我们可以直接使用：

可以看到，四种函数的提升都是非常可观的。其中第一个 Case 更是直接性能翻倍。

这个优化的原理是非常简单的，Plus 这种基础函数满足两个特性：

1. 运算本身比 check 轻量。
2. 运算不会 crash，且没有副作用。

那么我们可以直接删除 null check 的三行代码，因为 null 的结果已经被写到 result 的 bitmap 里了，这里无脑做一下计算就可以。但由于 overflow check 的存在，我们不能返回非预期的 overflow 错误（可以说 plus 运算本身无状态，overflow check 引入了状态），因此如果发生了 overflow 的话，我们得确认本身不是 null，如果确认不是 null 的话，才返回错误。从某种意义上，这个优化可以认为是手动帮 CPU 做流水线执行。

上面的 PR 是我花十分钟写的，我是想再给力一点的，但是懒（躺），下面只说失败的尝试和思路。

首先是想办法优化掉 overflow check 的 branch，我先把 overflow check 的 branch 提取到外侧：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

func (b *builtinArithmeticPlusIntSig) plusSS(result *chunk.Column, lhi64s, rhi64s, resulti64s []int64) error {
+       var hasOverflow int64 = 0
        for i := 0; i < len(lhi64s); i++ {
                lh, rh := lhi64s[i], rhi64s[i]

-               if (lh > 0 && rh > math.MaxInt64-lh) || (lh < 0 && rh < math.MinInt64-lh) {
-                       if result.IsNull(i) {
-                               continue
-                       }
-                       return types.ErrOverflow.GenWithStackByArgs("BIGINT", fmt.Sprintf("(%s + %s)", b.args[0].String(), b.args[1].String()))
-               }
-
+               hasOverflow |= (b2i(lh > 0) & b2i(rh > math.MaxInt64-lh)) | (b2i(lh < 0)&b2i(rh < math.MinInt64-lh))&b2iNot(result.IsNull(i))
                resulti64s[i] = lh + rh
        }
+
+       if uint64(hasOverflow) > 0 {
+               return types.ErrOverflow.GenWithStackByArgs("BIGINT", "overflow")
+       }
        return nil
 }

这个优化对逻辑是有变更的，因为报错信息里没法输出正确的数字了，但也不是完全没有办法，考虑到 overflow 是小概率事件，我们可以发现 overflow 以后再循环一次，拿到具体 overflow 的数字。

b2i 和 b2iNot 大概就是 bool2Int，具体懒得贴了，反正大道至简不需要解释。实测效果大概 benchmark 低了一倍，我又懒得看汇编调优（下次高兴了再水一篇 blog）。猜测有几个原因：

1. Overflow check 比较重，原来可以短路求值的计算现在强制计算了，代价超过了 branch 运算。
2. Go 的优化比较拉，我写的位运算也比较拉。

但总之想优化掉 overflow check 是一件 non-trivial 的事情，

既然解决不了问题，我们不妨解决提问题的人。对于 AP 性能有极致追求的用户，我们可以提供某种 non-strict sql_mode，允许整型 overflow，结果是未定义的，这样我们就能自由地去掉 check 了。

1
2
3
4
5
6
7
8

// 这里已经不需要四种符号的版本了
func (b *builtinArithmeticPlusIntSig) plusNonStrict(result *chunk.Column, lhi64s, rhi64s, resulti64s []int64) {
        for i := 0; i < len(lhi64s); i++ {
                lh, rh := lhi64s[i], rhi64s[i]
                resulti64s[i] = lh + rh
        }
        return nil
}

能啊，直接看雷宇哥哥文章的 SIMD 版本 I beat TiDB with 20 LOC。

只能说，TiDB 的 Executor 还有很长的路要走（

你是不是标题党？这哪里提升两倍了？

是，expression 的 benchmark 翻倍，但在整个 SQL 的生命流程中只是微不足道的一部分，特别是 TP 的请求。即使对于复杂的 AP 请求，除非是完全从本地节点的 cache memory engine 中读取的数据，否则相同的数据量网络开销大概率也会超过这部分的优化效果（特别是 TiDB 和 TIKV 交互还用的 gRPC，那就更拉了）。

说好的福利（伪）：我改完 Plus 就懒得改了，目测 Sub/And/Or/Not/Xor/… 肯定都能提升的，Mul/Div/Mod 可能需要 benchmark 一下才知道有没有提升，同时 TiKV 上也可以水一堆，感兴趣的可以去水一个 PR 薅 TiDB 的 new contributor 周边杯子。有能力的也可以把 non-strict Plus 实现一下（也很 trivial，就是要思考一下用户接口）。

• 更新Blog主题的底层逻辑
• 利用 vercel serverless 赋能 blog 的 slogan
• 打好 hexo-fluid-theme 和 cusdis 的组合拳
• 反哺 cusdis 的生态

🐶狗头保命

更新 blog 主题是一个比写 blog 文章快乐多了的事情，这也是 blog 新手常常陷入的一个陷阱 —— 精心配置一整天的主题、评论、评论、插件，然后写下一篇 类似于 Hello World 的《使用XXX 搭建 blog》之后从此吃灰。为了避免自己陷入这个陷阱，我搭 blog 的时候给自己定下了一个规则 —— 每次写一篇文章才能更新一次与文章无关的 blog 配置。

最终的结果是 —— 我既没有保持合适的更新频率，也没机会折腾主题，直接使用了烂大街的 hexo next，没有评论，没有 Analytics，甚至连 Hello World 都没写，创造了一个三无 blog。

直到今年开始，我成功更新了两篇文章（这里非常感谢 Taio App，让我在手机上也能快乐地写 blog），适当地让 blog 更易用一些也提上了日程

第一件事情自然是喜闻乐见的换皮，选了
hexo-fluid-theme，就觉得挺好看的，配置也比较完善，代码也不复杂，看了看感觉如果有必要的话（其实很快就有必要了），我自己也改得动。

配置的过程中，遇到了两个麻烦，一个是这个主题必须配置一个 banner_img，而且默认的太丑了，于是为了提高辨识度，我随手画了一个更丑的，以后有机会再优化（下次一定）。另一个是主页上要求写一个 slogan，我想把 迟语录 chi_corpus 随机显示在主页上，但是 hexo-fluid-theme 只支持 json 格式，即使我 commit 一个 json 格式上去，也没法做到随机返回，独立维护一个转换服务又会极大增加我的运维负担，因此动了薅 vercel 羊毛的心思。翻了翻 vercel serverless 的使用文档，感觉使用起来非常简单，而事实上也是如此。仅仅是花了五分钟，添加一个四十行的 go 文件，我就轻松达到了我的目的。可以在首页观看效果。赞美 vercel（*1）！

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

const CHI_CORPUS_URL = "https://raw.githubusercontent.com/TennyZhuang/Chi-Corpus/master/common.txt"

type Data struct {
Content string `json:"content"`
}

func fetchChiCorpus() (*Data, error) {
resp, err := http.Get(CHI_CORPUS_URL)
if err != nil {
return nil, err
}
defer resp.Body.Close()
body, err := ioutil.ReadAll(resp.Body)
if err != nil {
return nil, err
}
content := string(body)
lines := strings.Split(content, "\n")
line := lines[rand.Intn(len(lines))]
return &Data{
Content: line,
}, nil
}

func Handler(w http.ResponseWriter, r *http.Request) {
data, err := fetchChiCorpus()
if err != nil {
w.WriteHeader(http.StatusInternalServerError)
w.Write([]byte(err.Error()))
} else {
w.Header().Set("Content-Type", "application/json; charset=utf-8")
json.NewEncoder(w).Encode(data)
}
}

本来鸽子博主已经决定更新到这里结束了，看了推友 @frostming90 的 blog（别人的 blog 真好看啊），于是进行了一番抄作业。再吹一次，vercel 真的好用（*2），无脑就把一个 blog 后台跑起来了，而且还是白嫖。这次遇到一个新问题，就是 hexo-fluid-theme 支持了许多 comment plugin，但还不支持 cusdis。顺手 fork 了一个支持了一下，顺便提了个 PR https://github.com/fluid-dev/hexo-theme-fluid/pull/474。目前 console 里还有个奇妙的报错 Function called outside component initialization，但似乎不影响 plugin 的使用，有知道怎么修的也可以带带我，前端技能不太熟练了：（

目前对 cusdis 还有一些小小的问题，比如评论仅支持审核后显示，似乎不支持默认显示的方式，使用起来比较麻烦，后续考虑 contribute 一下。欢迎试用新整的评论系统～

个人搭建并维护 blog 还是比较麻烦的事情，一个关键技巧是在掌控数据的前提下尽可能依赖第三方服务。这次的整套组合拳打下来基本也就花了半天的时间在折腾（没有 vercel 可能一天起步了，点赞*3），但数据是以可以掌控的格式（postgresql，可以自己备份）存储的。考虑到 Donald Trump 被封禁到搭建了自己的个人博客，可见 blog 这种去中心化的组织形式还是有必要的。

彩蛋

尽管是完全与安全方向无关的主题，但我们随手取了个队名 ‘ or 0=0 or ‘（读作「引号or零等于零or引号」），除了可以卖萌，而且还能用于 SQL 注入，感兴趣的可以看看万能密码这个 topic。很意外的是还引发了 hackathon 过程中一个有趣的小插曲，在看到我们的队名后东旭和姚老板纷纷吐槽太有年代感了：

但仅仅过了半天，在我们 hack 的途中，我们的队友 breeswish 就无意中发现 TiDB 的内部 SQL 存在原始的字符串拼接参数且没有校验参数合法性，成功地进行了一次提权攻击 ：D

我们想做什么？

UDF 是每届 TiDB Hackathon 的常客，每次都会有 UDF 的 proposal，这里面也包括我在 2018 年参赛时实现的基于 lua 的 UDF。当时的实现非常粗糙，我们在 TiDB/TiKV 上直接起了一个 lua vm，然后允许用户以 CREATE FUNCTION 的语法把 lua 函数上传到 TiDB 并保存在 PD，同时支持用户通过 call_lua(fn_name, args) 的语法来调用 UDF。TiDB/TiKV 的执行器会从 PD 加载函数 body，并通过 lua vm 执行。这个方案有许多问题，以至于只能是一个 demo，始终无法落地：

1. lua 生态较差，仅适用于实现一些功能简单的函数。而类似方法支持更多语言需要 TiDB 内置多种 vm。
2. 与 vm 的交互开销较高，UDF lua 相比 native 函数，执行效率偏低。

lua UDF 这个项目也因此很遗憾没有拿奖。一个没被采用的队名：MAKE UDF GREAT AGAIN!

这次重新捡起了 UDF 这个 topic，主要是时机相比与 18 年已经成熟了，有两个重要的情况发生了变化：

1. VM 生态：我在 18 年选择使用 lua 做 UDF 是无奈之选。大部分系统的扩展能力都是通过 lua 实现的，因为缺少一个兼具安全性、高性能、通用性的轻量 VM。而 Wasm 的到来很好地帮我们解决了这个问题。很多 infra 项目比如 Envoy、OpenShift 也开始用 Wasm 作为扩展的 runtime。
2. 云原生时代：UDF 是满足用户自定义需求的一个重要能力。在私有化部署的 TiDB 上，用户可以通过修改开源版本代码的方式实现各种自定义需求，但随着云原生时代的到来，更多的用户选择基于云的 DBaaS 方案使用 TiDB，云上标准化的 TiDB 需要一个完善的标准 UDF 方案。同时基于云的 UDF 也可以跟用户云上其他生态实现互通，比如可以用 UDF 实现对对象存储数据的读取，达到异构存储的目的，或者利用 UDF 调用一些机器学习模型进行人脸识别，再拿识别的结果与其他数据表进行匹配（join）。基于 UDF 的能力，这些需求都可以在 TiDB 内部完成。

这次再用同一个 topic 参赛，但我们不再是 idea driven hackathon，更多关注的是方案可落地，让 UDF 这个选题从未来的 TiDB Hackathon 中消失，在设计之初，我们就定下了若干目标：

1. 灵活性：应该支持更多的编程语言进行 UDF 的编写。不同人对编程语言的喜好大相庭径，强迫 TiDB 的用户使用 lua 编写 UDF 并不是一种优美的做法。
2. 安全性：数据库的安全性至关重要，应该保证函数在沙箱环境运行，不能造成权限泄漏，也应该尽可能减少对业务稳定性的影响。
3. 高效性：性能接近 Native 函数，用户不需要担心额外的 overhead。
4. 功能：在保证安全的前提下，提供数据库内部的 API 以及对外的网络 API 到 UDF 的沙箱环境，同时这些 API 也在权限控制的管理下。

我们做了什么？

为了不引入过多过重的 runtime，增加维护的心智负担，我们选择了 Wasm 作为解决方案。Wasm 本身我不过多介绍了，感兴趣的同学可以在很多地方找到详细的介绍。最关键的是，Wasm 拥有我们想要的所有 feature。Wasm 是面向浏览器的沙箱环境安全执行设计的一种 low-level 指令，同时也兼备接近 native 代码的高性能，之后也被扩展到非浏览器的平台运行。（其实我觉得这玩意早该有了，但确实还是要依赖各大巨头合作才能定义出一套大家都接受的标准）

选定了 Wasm 作为技术方案以后，剩下的工作就是选择一个合适的 runtime，并且嵌入到 TiDB/TiKV 的执行器中。由于同时需要兼容 C、Go、Rust 语言，我们选择了 Wasmer 作为我们 demo 时的 runtime，并且使用了 llvm backend 达到了接近 native 的性能。

使用

1
2
3
4
5
6
7

#include <emscripten/emscripten.h>
#include <stdint.h>

uint64_t EMSCRIPTEN_KEEPALIVE
udf_main(uint64_t a, uint64_t b) {
    return a + b;
}

假设用户先基于 emscripten 工具链实现了一个简单的函数 aplusb，由于这里的类型完全是 Wasm 原生类型，因此也不需要做任何额外的处理。

1
2
3
4

$ emcc aplusb.c -O3 -o aplusb.wasm --no-entry -s ERROR_ON_UNDEFINED_SYMBOLS=0
# 由于 Wasm 是一种 binary 的格式，我们做了一些简单的处理
$ cat aplusb.wasm | od -v -t x1 -A n | tr -d ' \n'
0061736d010000000117056000017f60000060017f0060017f017f60027e7e017e0307060104000203000405017001020205060101800280020609017f01419088c0020b077a08066d656d6f72790200087564665f6d61696e0001195f5f696e6469726563745f66756e6374696f6e5f7461626c6501000b5f696e697469616c697a650000105f5f6572726e6f5f6c6f636174696f6e000509737461636b5361766500020c737461636b526573746f726500030a737461636b416c6c6f6300040907010041010b01000a30060300010b0700200020017c0b040023000b0600200024000b1000230020006b4170712200240020000b05004180080b

用户可以通过 CREATE FUNCTION 命令将这段 wasm bytecode 传给 TiDB：

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

mysql> CREATE FUNCTION aplusb WASM_BYTECODE x"0061736d010000000117056000017f60000060017f0060017f017f60027e7e017e0307060104000203000405017001020205060101800280020609017f01419088c0020b077a08066d656d6f72790200087564665f6d61696e0001195f5f696e6469726563745f66756e6374696f6e5f7461626c6501000b5f696e697469616c697a650000105f5f6572726e6f5f6c6f636174696f6e000509737461636b5361766500020c737461636b526573746f726500030a737461636b416c6c6f6300040907010041010b01000a30060300010b0700200020017c0b040023000b0600200024000b1000230020006b4170712200240020000b05004180080b";
Query OK, 0 rows affected (0.33 sec)

mysql> SELECT aplusb(1, 4);
+--------------+
| aplusb(1, 4) |
+--------------+
|            5 |
+--------------+

mysql> SELECT aplusb();
ERROR 1582 (42000): Incorrect parameter count in the call to native function 'aplusb'

创建后，UDF 的 Wasm bytecode 会被存在一张系统表中，在某个节点首次执行后会被编译执行并且缓存在该节点上。

当然对于大段的 bytecode，这种方式其实不友好，可能后续需要提供一些上传工具。（不过这并不是 hack 需要考虑的事情

高性能

我们分别用 Wasm UDF 和 TiDB/TiKV native code 实现了一个叫 [nbody](add builtin nbody · tidb-hackathon-2020-wasm-udf/tidb@bbcf0d5 (github.com)) 的函数用作性能测试。我们很意外地发现 UDF nbody 比 rust nbody 大致相近（符合预期），但居然比 go nbody 快一些 （说明 golang 辣鸡），猜测是 allocator 的问题。这个实验也充分证明了 UDF 的高性能。

灵活性

这其实是我们在 Wasm 上踩坑最多的地方，Wasm 的接口比较 low level，因此一些高级语言的数据结构（其实从需求上来说主要就是 string）映射到 Wasm ABI 会有不同的表示，我们还是需要为每种语言定制一下工具链来生成符合我们预期的 Wasm bytecode。

我们分别用 rust/golang/C 实现了 UDF 的功能，在尝试 Java 时，我们踩了比较大的坑，感觉 Java compile to Wasm 的工具链都比较不成熟。目前来看，Wasm 生态比较好的其实是运行时更轻量的静态语言。

安全性

Wasm 本身是个安全的沙箱执行环境，我们可以主动提供一些 API 给用户调用，并且配合权限认证。为了演示这个功能，我们实现了一个 HTTPGet 的函数，同时对接了 TiDB 本身的 Privilege 系统 —— 有 UDFNetworkPrivilege 权限的用户才能顺利创建和执行这个函数。这其实给 TiDB 与云生态结合提供了很大的想象空间。

最后我们在 Demo 的时候演示了一个非常 fancy 的东西：我们复用了上一届 Hackathon 二等奖的一个成果，他们做的是基于 Wasm 让TiDB 运行在浏览器里，然后我们直接复用他们的 Wasm 实现了让 TiDB 跑在 TiDB 里

1
2
3

# TiDB 套娃
SELECT wasm_tidb('SELECT tidb_version();');
SELECT wasm_tidb('use test; create table t1 (id int primary key); insert into t1 values (1); select * from t1;');

Not only UDF

我们的参赛主题写的是 TOT（TiDB over TIDB），事实上我一开始是想展示三种 TOT 的 demo（很遗憾的是我们最后只实现了两种）：

1. TiDB 通过 UDF 访问云上的另一个 TiDB，展示 UDF 可以提供受沙箱限制的网络能力，为云上和其他服务联动提供想象空间。
2. TiDB 通过 UDF 运行另一个编译成 Wasm 的 TiDB，展示 wadm 强大的可扩展性，我们甚至可以把 TiDB 本身移植上去（见上文）。
3. 在 UDF 中暴露受控的合适的内部接口，例如执行一些查询/修改，达到类似存储过程的效果。

至少在互联网公司的数据库应用中，存储过程已经是基本被抛弃的功能。存储过程有很多众所周知的缺点：

• 语法和主流语言有差异，且缺乏统一标准，难以 port 到其他架构
• 通常表达能力较弱，容易写错
• 难以根据业务模型封装
• 占用数据库计算资源，难以控制存储过程的复杂度，容易把 DB 打挂
• ……

而基于 Wasm 的存储过程，可以基本避免上面提到的缺点：

• 不再拘泥于特定的 DSL，凡是能编译到 Wasm 的语言都能运行在 DB 上，业务很容易 port 代码，且 GPL（general purpose language）的表达能力通常比 DSL 强大很多。
• 运行在各种架构上，一处编码处处运行（JVM：？）
• 借助 jit 达到接近 native 的性能，特别是如果 DB 本身是基于 query compilation 的执行器的话，可以把整个 query 的完整执行逻辑直接编译成媲美手写的最佳性能。（当然 TiDB 不行）
• 借助 Wasm 本身的沙盒机制保证安全性。

这样自由又强大的 ”存储过程“ 已经接近于数据库内部的 Serverless 了，相比直接用 Serverless ，做在数据库内部有什么好处，这又是另一个很大的 topic 了，下次有灵感了再写（🕊）。

最近经常学习 Manjusaka 老师的 Blog，感受了 ePBF 给内核可观测性带来的变化。事实上 Wasm 也可以做到类似的事情。除了实现存储过程，Wasm 还可以用于用户自定义 Trigger。这个 Trigger 不仅仅可以在数据修改时执行，在如获取 TSO，下推计算、数据复制，等所有具有观测价值的地方都可以进行一些埋点对 UDF 调用，而在 UDF 内部可以灵活高效地采集监控信息，甚至可以通过受限 API 跟用户生态或者云生态内的其他系统汇报采集到的信息，这可以给数据库系统带来巨大的可观测性提升。

总结

总的来说是一次非常充实的 Hackathon，在一次 Hack 的过程中我们不仅需要跟 TiDB、TiKV 打交道，还了解了各个语言工具链特别是大量 Wasm 周边生态有关的知识，工作量非常的大，感谢队友大腿们 breeswish，Fullstop000 和 Hawkingrei 的带飞。

在给评委答辩画饼的时候，事实上我也感受到了 Wasm+Wasi 在服务器领域的巨大潜力，如果 Wasm 能在更多系统中大规模落地的话，能在保证数据安全的前提下给用户带来更强更灵活的定制能力。这个 Hackathon 项目也是为这个过程做了一点微小的贡献~

Protobuf 是 Google 整的一个序列化/反序列化框架，性能不算很好不过用的人比较多，各个语言的实现也比较全，其中 golang 的版本是 google 官方维护的 golang/protobuf，但由于比较保守，对各种新 feature request 不太感兴趣，所以社区广泛使用的是一个 fork 的版本 gogo/protobuf，gogo 版本不仅在性能上做了很多优化，而且提供了很多 extensions，可以让生成的代码更符合 go 开发的习惯。

这篇 blog 记录的是在使用 stdtime extension 中遇到的一个性能问题排查过程和修复方案。stdtime extension 可以把 Google 提供的一个公共库中 Timestamp 的类型定义转化为 golang 标准库 time.Time 的定义。

线上开发某个服务的时候用了 gRPC 和 gogo/protobuf，然后其中的 message 定义大概是：

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

import "github.com/gogo/protobuf/gogoproto/gogo.proto";
import "google/protobuf/timestamp.proto";

message A {
    // ...
    google.protobuf.Timestamp created_at = 1 [(gogoproto.stdtime) = true];
}

message B {
    repeated A as = 1;
}

message Empty {}

service S {
    rpc RPC (Empty) returns (B) {}
}

大概有几千个服务会调这个 RPC，每次返回的 as 的长度大约是 10000 左右。在测试时，从客户端观察，几乎每个请求都要耗时 20 秒以上，但在服务端观察到每个请求的处理时间在 100ms 以下。在排除了网络故障的可能性以后，我开始怀疑是 RPC Framework 的问题。

Golang 自带的 profile 框架 pprof 是非常好用的，简单跑了个 mutex profile 以后，观察到

发现阻塞时间基本在 proto 包里的一个 Mutex 上。

简单翻了一下代码

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

var (
marshalInfoMap  = map[reflect.Type]*marshalInfo{}
marshalInfoLock sync.Mutex
)

// getMarshalInfo returns the information to marshal a given type of message.
// The info it returns may not necessarily initialized.
// t is the type of the message (NOT the pointer to it).
func getMarshalInfo(t reflect.Type) *marshalInfo {
marshalInfoLock.Lock()
u, ok := marshalInfoMap[t]
if !ok {
u = &marshalInfo{typ: t}
marshalInfoMap[t] = u
}
marshalInfoLock.Unlock()
return u
}

看起来是为了让每个 Message Type 都只会产生一个 *marshalInfo，用了一个全局的 map 和一个全局的 Mutex 来保护。产生大量 message 的时候，这个 Mutex 成为了瓶颈。这段代码在 gogo/protobuf 和 golang/protobuf 同时存在。

当时觉得已经定位到了问题，并且修复方案也很简单，用 RWMutex 做个 double check 就好了，测试过优化明显后，顺手给 golang/protobuf 交了一个 PR。

很不幸的是 golang/protobuf 的 maintainer argue 这个函数只会被调用少数次，有几个 message 定义就回被调用几次，与运行时产生的 message 数量无关。并且给出了复现例子，于是只好继续深入定位问题。

在 demo 中做了若干次详细的试验以后，发现这个 bug 确实只能用 gogo/protobuf 复现，并且必须打开 [(gogoproto.stdtime) = true] 的选项才会产生。

在打开这个特性开关后，gogo/protobuf 需要引用 google Timestamp 的定义来反序列化数据，再转化为 time.Time，Timestamp 的定义是由 protoc-gen-gogo 生成的，包路径为 github.com/gogo/protobuf/types，然而所有生成的代码都需要反过来依赖 github.com/gogo/protobuf/proto，所以会形成循环依赖。为了解决这个问题，gogo/protobuf 在 github.com/gogo/protobuf/proto 包里 mock 了一个 timestamp，只通过 struct tag 定义了最基本的序列化格式，而缺失了一些关键的方法，导致没有满足 newMarshaler 和 Marshaler 的 interface，同时 protobuf 为了满足向后兼容性，入口函数 Marshal 依然接受不满足 newMarshaler，Marshaler 的参数，只是走了最慢的路径。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

func Marshal(pb Message) ([]byte, error) {
if m, ok := pb.(newMarshaler); ok {
siz := m.XXX_Size()
b := make([]byte, 0, siz)
return m.XXX_Marshal(b, false)
}
if m, ok := pb.(Marshaler); ok {
// If the message can marshal itself, let it do it, for compatibility.
// NOTE: This is not efficient.
return m.Marshal()
}
// in case somehow we didn't generate the wrapper
if pb == nil {
return nil, ErrNil
}
var info InternalMessageInfo
siz := info.Size(pb)
b := make([]byte, 0, siz)
return info.Marshal(b, pb, false)
}

由于同时涉及了代码生成和循环依赖问题，这个问题的正确修复方式可能需要涉及到很大的重构，比较简单的 Workaround 有：

• 使用 RWMutex 来优化这个全局 map，目前我 fork 的版本就是这么干的。
• 在 github.com/gogo/protobuf/proto 中依赖 github.com/golang/protobuf/ptypes 中的 Timestamp 来避免循环依赖，但会导致 gogo/protobuf 依赖 golang/protobuf，仍然不是好的解决方案。
• 从生成的 github.com/gogo/protobuf/types.Timestamp 中 copy 更多代码到 mock 的 github.com/gogo/protobuf/proto.timestamp 中

目前提了一个 issue，不过 gogo/protobuf 的维护也不太活跃，在这个 issue 解决之前，建议不使用可能会触发该 bug 的 stdtime，stdduration，customtype 等 extension。

Haystack 和 F4 是 Facebook 为了解决照片存储的场景开发的一套小文件存储系统。整个设计非常简洁（褒义，虽然简洁到让人怀疑这也能发 OSDI），但是却把每个部分的设计和考虑解释得非常清楚。读完 GFS 会感觉有不少未解之谜在 paper 中没交代清楚，但读完 Haystack 和 F4 就感觉异常通顺。Facebook 一开始开发了 Haystack 是为了覆盖整个照片存储场景，后来发现了温存储场景可以优化的地方，又开发了 F4 将冷数据从 Haystack 中剥离出来，单独存储，并且 F4 的 paper 中描述了整套 BLOB Storage 系统同时修改了一些 Haystack 的设定，因此将这两篇放在一起讲。F4 也分享了很多 Facebook 在这套系统的设计和使用上的很多经验，值得学习。

Haystack

Needle in a haystack

Needle 是 Haystack 中的基本存储单位，英文翻译是针，Haystack 的英文翻译是草垛。出于好奇 Facebook 为什么取了这个名字的目的去搜了一下，发现这是一句类似于“大海捞针”（草垛里捞针）的常用短语，这么理解的话这个名字对于一个存储海量小文件的存储系统就非常形象了~

场景

在开发 Haystack 之前，Facebook 使用基于 NFS 的设计方案。每个小文件直接对应 NFS 上的一个物理文件，在 CDN Cache Miss 的文件会直接通过 Photo Server 落到 NFS 上读，这种方案的缺陷非常明显，就是小文件给文件系统带来的太多元数据。POSIX 文件系统在文件节点上存储了大量 Facebook 的场景下不需要的信息（如权限信息等），每个 INode 都要占据大约 500 byte 的空间，导致在大量小文件的场景下，文件系统无法将元信息全部缓存到自己的内存中，访问数据的时候，除了必须要的一次数据读取的磁盘 IO，在获取元数据以定位真实数据位置的过程中也需要经过若干次磁盘 IO，这是基于 NFS 的系统导致图片访问慢的主要原因。

Haystack 的优化目标非常明确，就是砍掉无用的元信息，压缩元信息到足够小并全部加载到内存中，将对单张图片的访问精确地缩减为一次磁盘 IO。

Haystack 的优化思路也非常的简单，既然小文件的元信息太多，那么就把大量小文件打包成大文件再存，自己维护小文件需要的少量 元信息。在 Haystack 中，存储的小文件及其元信息称为 Needle，而打成的大文件包称为 Volume。Haystack 的核心部分其实就是这个单机的小文件存储引擎。

架构

Haystack Cache

Facebook 的架构里用户除了访问 CDN 以外，也可以跳过 CDN 直接访问数据，这两种请求最终都会由 Haystack Cache 处理（猜测区别仅仅是内部和外部 Cache）。Haystack Cache 就是个很平凡的 Cache 逻辑，以 Photo ID 为 key 维护了一个分布式哈希表，如果请求的照片没有缓存，就从底层的 Haystack Store 读取数据，并且对满足一定条件的查询结果进行缓存。

这块唯一需要注意一些的就是这个缓存条件，当且仅当满足两个条件的时候，Haystack Cache 才会进行缓存：

1. 直接来自用户，而非来自 CDN 的请求。对于一般的来自 CDN 的请求，Haystack 直接将缓存的任务交给对方。从这个角度来看，Haystack Cache 的定位基本就等于一个系统内部的 CDN。
2. 照片存在 write-enabled 节点上的。这个跟之后提到的照片热度的 Timezone 有关，可以简单理解为从 Facebook 的场景来看，上传了很长一段时间以后的照片没有缓存价值。

Haystack Store

Haystack Store 是最核心的模块，也就是 Haystack 的存储节点。Haystack 放弃了原生的 POSIX 作为小文件存储的接口，但沿用了 POSIX 文件系统的底层，自己基于这个底层开发了一个单机的小文件存储系统，并运行在每块 Disk 或者每个节点上、

每个 Volume 有唯一的 Volume ID，标识一个 Logical Volume，但为了数据可靠性，每个 Logical Volume 在集群内会有三个副本，这些 Volume 实体称为 Physical Volume，在单机的存储引擎中。这些 Physical Volume 是真实的 POSIX 文件系统下的文件单位，分散在 Haystack Store 的节点中。

每个 Volume 会存储数百万张照片，并由三个文件组成，Data file 和 Index file 和 Journal file（后续加入）。Data file 由连续的 Needle 组成，每个 Needle 除了存储图片本身的数据以外，还存储了一些额外的元信息，其中比较 重要的有照片的 key 和 alternate key，图片的 size 和 checksum，以及一个删除标志位。

key 和 alternate key 用于 Facebook 场景下的二层索引，因为 Facebook 对每张照片存了四种不同 size 的图片（包括缩略图，小图，大图，原图），因此每张照片有一个主键，然后再通过 alternate key 对应到需要的尺寸的图片。

根据 key 和 alternate key，Haystack store 的每个节点在内存中为每个 volume 构建了一个双层的索引，用于快速找到对应的 Needle 在 data file 中的偏移量，并缓存了 size 信息减少一次读取元信息的 IO。而 Index file 是这个索引文件的一个快照。

一个 Volume 支持数据粒度的 Read，Write 和 Delete 操作，实现在了解数据的定义之后都非常的 trivial，直接通过下面的伪代码展示，但有一些场景需要考虑。

Index file 是定期 dump 到磁盘中的，因此宕机时会丢失数据，需要恢复，对于新写入的数据这非常简单，因为遗失的数据总是在 data file 的尾部，从 index 中最高的 offset 开始从 data file 恢复这些 meta 信息即可。但是对于删除的数据无法简单地恢复，在旧版本的 Haystack（即 Haystack paper）中，删除是通过修改 data file 中 needle 的标志位来完成持久化的，而在新版本（F4 paper 中提到的 Haystack），每次删除文件仅需要在 journal file 中添加一条记录，这是磁盘 append 操作因此非常快，而 Index 在宕机恢复时仅需要将 Journal file 和 Index file 做一个 merge 即可。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102

type Needle struct {
    header       [4]byte // 标识 Needle 开头，恢复数据的时候比较有用
    cookie       uint64  // 我也不知道是干嘛的，据说是反爬虫用的
    key          uint64  
    alternateKey uint64  
    flags        uint8   // 目前看起来只标志 deleted，并且在后续不再需要这个 deleted flag
    size         uint16
    data         []byte
    footer       [4]byte // 标识 needle 结尾，恢复数据的时候比较有用
    checksum     uint32
}

type needleMeta struct {
    offset uint64
    size   uint16
}

type indexItem struct {
    needleMeta
    key          uint64
    alternateKey uint32
}

type Volume struct {
    index        map[uint64]map[uint32]*needleMeta
    dataFile     *os.File
    journalFile  *os.File
    indexFile    *os.File
    indexCache   []indexItem
}

func (v *Volume) dump() {
    // 定期执行
    v.indexFile.Write(binary.Encode(v.indexCache))
    v.indexCache = make([]indexItem, 0)
}

func (v *Volume) Recover() {
    v.indexFile.Seek(0)
    var it *indexItem
    for {
        *it, err = Read(v.indexFile, sizeof(indexItem)
        if err != nil { break }
        v.index[it.key][it.alternateKey] = v.needleMeta
    }
    var offset uint64
    if it == nil { offset = 0 } else { offset = it.offset }
    v.dataFile.Seek(offset)
    for {
        needle, offset, err := Read(v.dataFile, sizeof(needle))
        if err != nil { break }
        it := indexItem{offset, needle.size, needle.key, needle.alternateKey}
        v.indexCache = append(v.indexCache, it)
        index[it.key][it.alternateKey] = it.needleMeta
    }
    v.jornalFile.Seek(0)
    for {
        key, alternateKey, offset, err := Read(v.jornalFile, 64+32+64)
        if err != nil { break }
        meta, ok := v.index[key][alternateKey]
        if ok && meta.offset <= offset {
            delete(v.index[key], alternateKey)
        }
    }
}

func (v *Volume) Read(key uint64, alternateKey uint32) ([]byte, error) {
    meta, ok := v.index[key][alternateKey]
    if !ok { return nil, errNotFound }

    return Pread(v.dataFile, meta.offset, meta.size)
}

func (v *Volume) Write(key uint64, alternateKey uint32, data []byte) error {
    n := Needle {
        header:       [4]byte("NEED"),
        cookie:       rand.Uint64(),
        key:          key,
        alternateKey: alternateKey,
        flags:        0,
        size:         len(data),
        data:         data,
        footer:       [4]byte("DEEN"),
        checksum:     crc32(data),
    }
    offset, err := v.dataFile.Write(binary.Encode(&n))
    if err != nil { return err }
    v.index[key][alternateKey] = &needleMeta{
        offset: offset,
        size:   len(data),
        flags:  0,
    }
    v.indexCache = append(v.indexCache, indexItem{...})
}

func (v *Volume) Delete(key uint64, alternateKey uint32) error {
    meta, ok := v.index[key][alternateKey]
    if !ok { return nil }
    delete(v.index[key], alternateKey)
    // 这里需要持久化记录 offset，避免恢复 index file 的时候将删除操作之后新添加的同一个 key 的数据也删除
    return v.journalFile.Write(binary.Encode(key, alternateKey, meta.offset))
}

为了避免垃圾数据过多，volume 还会根据一定条件触发 Compaction，回收已经被 Delete 或者被 Write 覆盖的数据。

除了单个 volume，我们考虑一下如何在多个 Physical volume 之间保持一致性，Haystack 的答案似乎就是根本不管。由于 Write 和 Delete 非常幂等，并且 Photo Store 稍微不一致也不是特别要紧，Haystack 选择添加监控并且手动处理一些不一致的异常情况。

Haystack Directory

这是个 paper 笔墨很少，但十分重要的组件，它存储了所有的元信息，比如 volume ID 到 physical volume 位置的映射。它负责调度用户的请求，包括负载均衡写请求的 logical volume，负载均衡读请求打到哪个 physical volume 等的调度。为了避免一个 volume 无限增长造成运维困难，directory 会在 volume 大小达到一定容量时将 volume 标记为 read-only。

Pitchfork

这个就是个健康检测后台任务，定期给所有存储节点发请求，观测到一个 volume 发生异常时标记为 read-only 并找运维人肉处理。这不会影响服务的整体可用性，因为写请求可以打到任意一个 volume。

F4

F4 是 Facebook 在 Haystack 之后又搞的一个 Warm blob store，这个 warm 就比较魔性，让人想起星巴克的中杯、大杯和超大杯。不过事实上，F4 存储的确实不是冷存储，而是 Facebook 的一些 long tail 的照片，他们仍然会被获取，但是频率较低，也很少被覆盖或删除。相比于一些获取数据需要以天为单位的真正的 cold storage，F4 仍然要求对数据的获取在百毫秒级的时间内完成响应。

F4 和 Haystack 的关系

在 Haystack 中的数据因为三副本的原因有比较高的存储成本，F4 的设计目标主要是在保证数据安全的情况下降低数据的存储成本。一点可以利用的性质是从 Haystack 导入 F4 的照片很少会被删除，我们可以认为整个 Volume 都是不可变数据。

Haystack 和 F4 的接口完全保证一致，通过 router tier 对用户隐藏具体实现。

在数据导入的时间点上，Haystack 基于底层硬件设备（HDD）的读写能力和 BLOB 的使用情况统计进行设计，以 80 IOPS/TB 作为分界线对统计结果进行划分，并确定了三个月的分界线，即对于 Facebook 的大部分 BLOB 数据来说，在经过三个月的时间以后，访问频率就会降到显著低于 80 IOPS/TB，以至于使用廉价的 HDD 作为存储介质依然可以提供不影响用户体验的服务。这个设计过程也是充分地利用了软硬件一体的设计思想。

设计

为了减少空间的使用，F4 引入了 EC（erasure coding）的技术。n:m 的 EC 可以将一份数据切为 n 份，并且构造 m 个冗余块。在这 (n+m) 个块中任意丢失 m 块数据，都能通过剩下 n 个块恢复。因此保障数据安全仅需要 (n+m)/n 的空间。Facebook 选择了 10:4 的比例，比起三副本来说，可以节约大量的空间。为了异地灾备，Facebook 在两个不同的集群之间再次通过对两个 Volume XOR 编码，并将这份冗余块备份到第三个集群中，通过 1.4 * 1.5 = 2.1 倍的空间完成了异地灾备级别的数据可靠性。

在 F4 中，一个从 Haystack 导入的 Volume 前会经过 compaction。在 F4 中，Volume 里较小的 index file 仍然通过三副本，但是占 Volume 主体的 data file 完全通过 EC 来保障数据的可靠性和可用性。每个 data file 会按固定的大小（1GB 左右）切成连续的 data block，然后为每 n 个 data block（称为 strip），生成 m 个 parity block，不足 n 个的部分填零补全。每个 Strip 对应的 n+m 个 block 会被分布在不同的机架中，来保证机架级别的容错域。

架构

架构上分为了五种类型的节点，并将这些节点打包成了一个 F4 Cell。

1. Name Node：管理了 Volume -> Strip -> Block 的 Mapping 关系的 NameNode，这个功能非常简单直接忽略其实现。
2. Storage Node：Storage Heavy 的节点，应该配有大量的 HDD，存储 Block，并管理对 Block 的读取操作。
3. Backoff Node：CPU Heavy 的节点，在部分 data blocks 损坏时，在 parity blocks 继续读取数据对外提供服务保证可用性。
4. Rebuilder Node：在有 data block 或者 parity block 损坏时，负责恢复数据。由于 F4 paper 中没有提到 Volume 如何从 Haystack 中入库到 F4 中，猜测初始化 parity block 这部分也是由 Rebuilder Node 负责。
5. Coordinator Node：一个 Cell 的任务调度节点。进行一些定期检查，容错域调度等维护任务的调度。

Others

删除

虽然 F4 不支持修改数据，但为了用户数据的隐私，允许对数据进行删除。

在最开始的设计中，F4 的开发者计划在 F4 中保留 Haystack 中的 Jornal file 作为文件的删除记录，并保留 compaction 的策略。很快他们发现在 F4 设计中留这个可变的因素会大大增加设计复杂度。因此 F4 换了个删除的思路，将所有 BLOB 在导入 F4 前用每个 BLOB 唯一的秘钥加密，并将秘钥存在外部数据库中，如果需要删除数据，只需要在外部数据库中删除这个秘钥，就能让加密的 BLOB 无法通过任何手段恢复原来的数据，从逻辑上做到了 BLOB 的删除。

effective-replication-factor

这个词翻不太来，大约是指备份的数据相比原始数据的比例。在 Haystack 中这个数字是 3.6，由三备份和 1.2 倍的 RAID 组成，在 F4 中，这个数字被降低到了 2.1。不过这个可以节约空间的前提是建立在 F4 中的数据删除比例比较少，根据 Facebook 的统计结果，对于大于三个月的 BLOB，这个结论成立。

这是 CPython 源码阅读系列的第一篇，我也不知道能坚持多久，或许连这篇都写不完（如果你能在网上看到这句话，说明至少第一篇写完了）。

Python 是一门非常强大的动态语言，语法特性多且优美，非常符合人类直觉，是我最喜欢的语言之一，再加上 CPython 做的优化非常少（笑），不像某些 JS 引擎如 V8，为了性能各种 hack 技巧太多不适合阅读学习。

CPython 源码链接

对 Python 比较精通以后，自然而然会产生疑问，那么强大的 Python，是怎么通过一门语法特性非常少的静态语言 C 来实现的呢？

当然，阅读 CPython 源码的第一步，就是让你抛弃 C 语言是静态类型的错觉。

本系列无明显顺序，更类似于个人阅读中的笔记，可能有错误，欢迎指出。

本系列文章要求阅读者：

• 了解 C 语言的特性，特别是强制转换时的行为
• 了解 Python 语言本身的基本行为和高级特性

作者开始阅读源码时，使用的 Python 版本是 Python 3.7.0a0，最新的 commit 号为 984eef7d6d78e1213d6ea99897343a5059a07c59。

本文涉及的核心文件是

• Include/object.h
• Objects/object.c

PyObject

一切都要从 Hello World 开始，CPython 源码阅读的 Hello World，当然是从 PyObject 开始。

首先，在 object.h 里找到 PyObject 的定义：

1
2
3
4
5

typedef struct _object {
    _PyObject_HEAD_EXTRA
    Py_ssize_t ob_refcnt;
    struct _typeobject *ob_type;
} PyObject;

Python 中的一切对象，都至少保存了以上属性，这也是为什么在 Python 中，哪怕是一个简单的 0，也比 C 语言占用了更多内存的原因。

_PyObject_HEAD_EXTRA 这个宏是全空的，应该是为了未来可能的修改而保留修改空间，可以先忽略它。

观察一下 ob_refcnt 和 ob_type。

引用计数

Python 是一门自带 GC 的语言，而 Python 的 GC 是以引用计数机制为主的，ob_refcnt 保存了 Python 每个对象被引用的次数。

在 object.c 中实现了一个函数 Py_IncRef，这个是暴露给 Python runtime embedders 的管理 PyObject 引用计数的接口，而源码内部的实现基本调用的是 Py_XINCREF（附录 0） 和 Py_INCREF 这两个宏。

1
2
3
4
5
6
7
8
9
10
11

/* Macros to use in case the object pointer may be NULL: */
#define Py_XINCREF(op)                                \
    do {                                              \
        PyObject *_py_xincref_tmp = (PyObject *)(op); \
        if (_py_xincref_tmp != NULL)                  \
            Py_INCREF(_py_xincref_tmp);               \
    } while (0)

#define Py_INCREF(op) (                         \
    _Py_INC_REFTOTAL  _Py_REF_DEBUG_COMMA       \
    ((PyObject *)(op))->ob_refcnt++)

我们先假装没看到一系列的强制转换，那么这两个宏的作用就分别是 safe 和 unsafe 地增加一个 PyObject 的引用计数。

关于 ob_refcount 还定义了一些别的宏，具体的运用方式想放在 GC 的章节一起看。

ob_refcount 的类型是 Py_ssize_t，这个类型在我的系统上等价于 long，再加上为了为了效率，维护引用计数的时候显然不会作边界检查，这就意味着如果你的一个对象引用超过 LONG_MAX 的话应该会溢出，然而虽然很想尝试一下，但我并不知道怎么在爆 Memory Overflow 前让一个对象的引用计数超过 long。

PyVarObject

ob_type 显然保存着对象的类型信息，然而在观察其具体实现之前，我们可以看一下紧跟着 PyObject 的另一个结构体的定义，PyVarObject。

根据注释，PyVarObject 用来存储变长的 python 对象（如 list 等），熟悉 C++ 的同学可能已经忍不住脑补出以下代码：

1
2
3
4
5

// fake PyVarObject
class PyVarObject : public PyObject {
public:
    Py_ssize_t ob_size;
};

那我们再来看它在 CPython 中的实现：

1
2
3
4

typedef struct {
    PyObject ob_base;
    Py_ssize_t ob_size; /* Number of items in variable part */
} PyVarObject;

看起来非常反人类的做法，难道每次想操作 PyVarObject 中 ob_type 的时候都要多一层 ob_base 吗？

然后就是一个比较神奇的操作，而且唯有 C 这种结构体严格映射内存结构的语言才能做到（附录 1），对于 C 来说，PyObject ob_base; 的内存结构和 _PyObject_HEAD_EXTRA Py_ssize_t ob_refcnt; struct _typeobject *ob_type; 是完全等价的，那么可以直接把 PyVarObject* 类型的对象强制转换成 PyObject* 类型的对象，然后直接当成 PyObject* 类型操作。

现在我们可以回过去看代码中对于 PyObject 某段注释：

Nothing is actually declared to be a PyObject, but every pointer to
a Python object can be cast to a PyObject*. This is inheritance built
by hand. Similarly every pointer to a variable-size Python object can,
in addition, be cast to PyVarObject*.

PyObject 不是 Python 中的任何一种类型，但是任何任何 Python 对象的指针都能被 cast 成 PyObject*，相当于手动实现了继承（附录 2）。同理如 PyVarObject*。

为了方便之后 Python 中对象的定义，object.h 中定义了两个宏

1
2

#define PyObject_HEAD                   PyObject ob_base;
#define PyObject_VAR_HEAD      PyVarObject ob_base;

利用这两个宏来达到继承 PyObject 和 PyVarObject 的作用。

（看到这里，你可以再思考一下 C 究竟是不是静态语言，至少有没有被人当静态语言用）

为了获取 PyObject 和 PyVarObject 中的基础变量，object.h 定义了三个宏

1
2
3

#define Py_REFCNT(ob)           (((PyObject*)(ob))->ob_refcnt)
#define Py_TYPE(ob)             (((PyObject*)(ob))->ob_type)
#define Py_SIZE(ob)             (((PyVarObject*)(ob))->ob_size)

任何 Python 中的对象都能通过这些宏来获取对应的信息来进行读写。

PyTypeObject

Python 中一切皆为对象，类型也不例外。

现在让我们回到被我们跳过的 ob_type，这是一个指向 PyTypeObject 对象的指针。

1
2
3
4
5
6
7

typedef struct _typeobject {
    PyObject_VAR_HEAD
    const char *tp_name; /* For printing, in format "<module>.<name>" */
    Py_ssize_t tp_basicsize, tp_itemsize; /* For allocation */
    
    // ...
};

PyTypeObject 继承了 PyVarObject，这个对象非常的复杂，在之后的文章再详细介绍。

附录

[0]: 关于 do ... while(0) 的解释，之后的贴代码的时候可能会省略该部分。

[1]: 参见 https://stackoverflow.com/questions/2748995/c-struct-memory-layout

[2]: 虽然 C 语言里没有继承的语法，不过这个概念完全是继承，再加上作者钦定了，所以之后将直接用「继承了 PyObject」 这种语言来描述这种行为。

HaScheme 基于 Stack 构建了项目，如经典的解释器架构一样，将项目主要划分为了三个模块，Lexer，Parser 和 Interpreter，输入的 Scheme 代码首先通过 Lexer 转为 token 序列，然后通过 Parser 将 tokens 转换为 AST，最后由 Interpreter 解释 AST 执行。

HaScheme 参考了很多 Write yourself a Scheme in 48 hours 这个教程的内容，这个教程非常初学者友好，不过这个教程实现的文法作用域有一些 bug。HaScheme 中修复了文法作用域的问题，并且扩展了语法特性。

Lexer and Parser

Lexer 和 Parser 是写的最舒服的一部分了，主要是 ParseC 实在太好用了，可以用原生 Haskell 代码直接描绘语法生成式的结构，并通过 Parser Monad 很轻松的转换为想要的数据结构。

ParseC 是自顶向下分析的，遇到不匹配的情况需要用 try 回溯，比较遗憾的是对于需要回溯的情况，ParseC 无法正确地输出报错信息，对于这部分我也没有特别处理，所以 Parser 的报错系统非常简陋。

文法作用域的实现

Haskell 原生的数据结构就是 AST 的形式，配合 Pattern Match 解释起来简直爽到起飞，不过 Immutable 的特性就不那么令人愉快了，应该是我姿势水平不足的缘故，不少操作（如 define，set!）在解释的过程中是会对环境造成影响的，一开始我尝试用 State Monad 来实现环境，大概思路是

1
2
3

import Control.Monad.State

schemeDefineVar :: String -> SchemeValue -> State Environment ()

不过这样的话，非常困扰于文法作用域的实现，因为对于一个作用域，必须能引用父级作用域的中的变量，也可以支持 Variable Shadowing 而不对父级作用域造成影响。

最终的实现参考了教程，即基于 Data.IORef 来实现变量。

1
2
3
4

import Data.Map
import Data.IORef

type Environment = IORef (Map String (IORef SchemeValue))

等于在命令式语言中保存了变量实体的指针，这样在新建一个子级作用域的时候，可以简单的拷贝当前环境，子级作用域也能对当前环境的变量进行读写，同时在新增变量时只对新的环境进行修改而不影响父级作用域的环境。

这部分就是教程实现错误的地方，教程中，对于 define 一个同名变量

1
2
3
4
5
6
7
8
9
10

defineVar :: Env -> String -> LispVal -> IOThrowsError LispVal
defineVar envRef var value = do
     alreadyDefined <- liftIO $ isBound envRef var
     if alreadyDefined
        then setVar envRef var value >> return value
        else liftIO $ do
             valueRef <- newIORef value
             env <- readIORef envRef
             writeIORef envRef ((var, valueRef) : env)
             return value

他会简单的修改修改变量的值为新的值，这回导致对父级作用域的变量进行修改，而这时候正确的行为是掩蔽父级作用域的同名变量，即新建一个 IORef 替换当前的 IORef 而非修改当前的 IORef。

教程中的实现会产生如下 bug

1
2
3
4
5

(define (f x y)
  (+ ((lambda (x)
    (+ x 1)) y) x)

(f 2 4)

正确的输出应该是 7，然而执行的结果却是 9，因为嵌套内部的函数参数 x 修改了外部 x 的值。

在我的实现中

1
2
3
4
5
6
7

defineVar :: Environment -> String -> SchemeValue -> IOThrowsError SchemeValue
defineVar envRef varname val = do
  env <- liftIO $ readIORef envRef
  liftIO $ do
    valRef <- newIORef val
    writeIORef envRef (Map.insert varname valRef env)
    return val

删去了变量是否存在的判断，一律插入新的 IORef，修复了这个 bug。

命令式语言特性的实现

Haskell 是支持一部分命令式的语法的，所以我实现了 begin 语句 和 while 语句，不过在我的实现方法中很难正确的实现 while 语句，所以我用了一个很 Hack 的实现，在 Parser 的阶段将 while 语句 parse 成 if 语句和 尾递归调用的语法糖，这种实现有很多问题比如栈溢出等，所以其实没有正确实现这个特性。

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

parseWhile :: Parser Expr
parseWhile = do
  char '('
  reserved "while"
  spaces
  cond <- parseExpr
  spaces
  body <- parseExpr
  char ')'
  return . BeginExpr $ ListExpr [
    DefineVarExpr "`whilerec" (
      LambdaFuncExpr [] (
        IfExpr cond (BeginExpr $ ListExpr [
          body,
          FuncCallExpr (SymbolExpr "`whilerec") (ListExpr [])
        ]) cond)
    ),
    FuncCallExpr (SymbolExpr "`whilerec") (ListExpr [])]

REPL

没有 REPL 的解释器是不完整的，这里非常感谢 Haskeline 的作者，借助 Haskeline 强大的 API，实现了很好用的 REPL。

实现了历史记录、自动补全、语法树查看等特性。

CamusAPI 这个项目的初衷是希望建立一个清华内部的校园开放 API 平台，供校园应用的开发者使用，不需要处理复杂的爬虫逻辑和页面逻辑，将学校的系统封装成一层清晰完整的 RESTful API 系统。

由于本来就有比较丰富的开发经验，知道架构对整个项目的重要性，所以一开始的项目架构是我独立完成的，将项目根据功能划分成了好几个模块，尽可能地减少模块间的耦合。此外，考虑到去年开发紫荆之声时代码风格的丑陋和整个团队开发风格的不一致，我又提前配置了 ESLint 和 travis-ci，确保整个团队的代码风格完全统一且严谨，对诸如每个函数的行数，每个文件的行数，最大缩进层数也做出了严格的限制，不通过 ESLint 的 commit 不会被合并到主分支，虽然这会增加一些开发时的成本，但是比起团队成员互相维护代码，以及可能的重构时带来的便利，这些成本是微不足道的，也很感谢组员的配合。

之前的开发中经常遇到本地开发完到最后不会部署的情况，所以这次在架构完一开始就配置好了 Docker，并且每天从 master 分支部署一次，这样对联合调试也帮助很大。

测试是软件工程中非常重要的一环，比较遗憾的是我们组由于开发周期非常紧以及测试相对来说困难，没能采用 TDD 的开发模式，不过在最后的一周我们补全了必要的测试，我们核心模块的测试覆盖率超过 95%。不过这次被坑的是性能测试，由于对 NoSQL 数据库的原理不够了解，一开始设计数据库的时候踩了坑，使用了不合适的组织方式，也因为没有提前性能测试，直到接近 ddl 的时候才发现性能很差，经过重重排查后发现是数据库的锅，连夜重构，索性前期架构模块划分合理，数据库操作被包在一个模块里，所以重构没有遇到很大的困难，吸取的教训是每添加一个功能都该进行一次性能测试，这样既能实时 profile，也能及时发现不合理的操作避免无谓的重构。

作为 API 小组，我们的文档非常重要，不过我们组都不是很擅长写文档，这里感谢马子俊同学承包了几乎所有的文档工作，写出了完整的接口文档供其他组的同学使用，并受到了好评。

不过担任 API 小组也让人体会到了甲方的坑爹之处，毕竟别的组的项目都是自己提需求，自己伪装成用户，可以什么好做做什么。起初我组只打算给一到两组提供 API，甚至没有的话完全可以自己搭建客户端来展示，后来在老师的要求下为其他所有组提供相关的 API，不得不说这并不是个愉快的体验，我组面临二十来个甲方提需求不堪重负，甚至相当一部分需求是受限于学校系统无法完成的，虽然让他们自己做他们也完不成，但是要求我们提供的时候丝毫没有觉悟。此外我们原来希望联合的小组开发进度不要太快，这样我们可以比较优雅地组织我们的代码，但部分强力的组加入后我们不得不赶工。出于尽可能让他们能够稳定开发的目的，我组不得不先以功能为第一目的，在安全性、性能等原本很重要的地方做一些让步以适应他们的开发。而且人多口杂需求多，在某些新加入的组的要求下被迫做出一些对已经稳定的 API 修改接口的行为，从某种程度上来说我们拉低了他们的开发进度，他们拉低了我们的代码质量。

这个项目从功能上来讲并不是我开发过的最复杂的应用，实现的功能也比较基本，但是从组织模式上来说是最工程化的，也在合作中收获了很多，感谢软工课给我的机会。最后，对课程的建议主要是前期文档实在有点多，很多实现细节不可能在开发前就确定，文档也随着每个迭代更新或许更合理。