Daft是一个高性能、分布式的 Python 计算引擎。相比于 Spark，它提供了原生Python 接口、更好的性能，以及对 AI 和多模态数据的原生支持。

背景：大数据的历史包袱

过去二十年，企业大数据生态基本由 JVM 系工具主导。Hadoop、Hive、Spark都诞生于那个年代，它们的设计目标是打造高可靠、高性能的面相结构化数据的SQL 分析引擎。

但时代变了。如今 80% 的 Spark 用户使用 Python（这是 Spark 联合创始人Reynold Xin 自己说的）。AI/ML数据工程师的工作语言是Python，他们处理的数据也不再只是整齐的结构化表格，而是包括图片、视频、向量等等。

一个很大的问题是，当你用 PySpark 时，Python代码本质上是在“调用”JVM，中间存在大量的序列化/反序列化开销。想在 Spark里跑一个自定义 Python UDF？那性能会比 Java/Scala 慢上5～10倍。

Daft 正是在这个背景下诞生的——它不再是对 Spark 的修补，而是一次为 AI时代的需求从头设计的分布式查询引擎。

Daft 是什么？

Daft 是一个高性能、分布式的 Python计算引擎。相比于上个时代统治地位的 Spark 以及 PySpark，Daft的核心优势在于：原生 Python 接口 + Native Code 的性能（Rust） +原生 AI 和多模态支持。稍后我们具体展开。

Daft 也有完整的单机支持——并非仅仅是一个 Worker节点运行那么简单。当你在本地运行 Daft 时，它会使用 Swordfish引擎，不依赖分布式框架；而在集群模式下，Daft 使用 Ray作为分布式调度框架，并借助 Ray 的 Shared Object Store进行节点间数据交换。

使用 Daft DataFrame API 的体验非常接近数据科学家最熟悉的 Pandas：

1
2
3
4
5
6

import daft

df = daft.read_parquet("s3://my-bucket/data/*.parquet")
df = df.where(df["label"] == "cat")
df = df.with_column("thumbnail", df["image_path"].url.download().image.decode())
df.show()

就这几行代码，Daft 完成了读取 S3 上的 Parquet、过滤行、下载 URL图片、解码图像——全部可以在分布式集群上执行。

Daft 也支持 PostgreSQL 方言的 SQL 查询，用户可以直接用 SQL来操作数据，这和 DuckDB 非常类似。

架构设计

用户接口 & 查询优化

这两层的设计与主流计算引擎（Spark、DuckDB）整体相似，不再赘述，简要说明如下：

• 用户接口（Interface）：用户通过 DataFrame API 或者SQL API 操作数据，所有操作均为惰性的（Lazy）——调用.filter() 或 .with_column()时不会立即执行，而是将操作记录进逻辑计划（LogicalPlan）。
• 查询优化（Optimizer）：在执行前对 Logical Plan做各种变换，同样是经典的先 RBO（Rule-Based Optimizer）、再CBO（Cost-Based Optimizer），完成一系列的包括谓词下推、列裁剪、Limit下推等 Rule。最后形成 Physical Plan，交给执行器执行。

本地执行引擎：Swordfish

Swordfish 是用 Rust 实现的多线程异步执行引擎。它的核心设计理念是Morsel-driven流式处理：数据不再被切成固定大小的分区，而是在运行时动态拆成小块（morsel）流式处理，让CPU 核心始终保持满负荷。

Swordfish 引擎是 Daft 性能的根基。除了 Native vs JVM带来的性能提升，Swordfish 还采用了以下几个关键技术：

• Apache Arrow 内存格式 +零拷贝：列式内存布局让数据在 Daft、PyTorch、NumPy之间可以直接共享指针，无需序列化复制
• SIMD 向量化：充分利用现代 CPU 的 SIMD指令集，对数值计算实施批量加速。作为对比，Spark 的 Tungsten 引擎基于CodeGen JIT 编译，性能已经逐渐落后于向量化加速，Gluten 项目正在尝试引入 Velox引擎来解决这个问题，但目前还处于早期阶段。
• Morsel-driven流式执行：本地执行时以小块（morsel）为单位动态调度，避免大分区带来的内存峰值，也使pipeline 中各算子可以真正并行流水
• 高性能异步 I/O：基于 Rust tokio 异步运行时的 S3/GCS下载器，官方声称是业界最快的对象存储读取实现。

分布式执行引擎：Flotilla

当数据规模超出单机极限，切换到 Flotilla（代码中也称为 RayRunner）只需一行代码：

1

daft.context.set_runner_ray(address="ray://my-cluster:10001")

Flotilla 采用经典的 Driver/Worker 架构：集群每个节点启动一个SwordfishWorker，充分利用节点全部资源（CPU、GPU、内存、磁盘、网络）；Driver 上的Flotilla Scheduler 负责任务分发、进度监控，并根据数据 locality和负载均衡决策调度。

对于需要跨节点数据移动的操作，Flotilla 提供两种 shuffle 机制：

• Ray Object StoreShuffle：数据可放入内存时优先使用，简单高效，Ray负责数据传输和内存管理（spill 等）
• Flight Shuffle（Beta）：基于 Apache Arrow FlightRPC，支持落盘（NVMe）、二进制传输、压缩和多线程并行

Daft vs Spark

关键差异：Python UDF

对 AI/ML 场景来说，Python UDF 是不可或缺的，而这也是 PySpark最被诟病的地方：

1
2
3
4
5
6

# PySpark UDF 需要序列化 Python 对象到 JVM，再反序列化
from pyspark.sql.functions import udf
@udf(returnType=FloatType())
def run_model(image_bytes):
    # 每次调用都有 JVM <-> Python 进程通信开销
    return model.predict(image_bytes)

而 Daft 的 Python UDF 完全没有这样的问题：

1
2
3
4
5

# Daft UDF 直接在 Python 进程中运行，无任何跨进程开销
@daft.udf(return_dtype=daft.DataType.float32())
def run_model(images: daft.Series) -> list:
    # 批量处理，直接操作 Arrow 内存，零拷贝传递给 PyTorch
    return model.predict(images.to_pylist())

Daft vs 其他竞品

• Daft vs Polars: Polars 是另一个 Rust 实现的DataFrame 库，性能极佳，但仅支持单机。Daft可以理解为分布式的 Polars + 多模态支持 + 补全了 SQL 查询优化能力。
• Daft vs Dask: Dask 是 Python原生的分布式计算框架，但它本质上是 Pandas 的并行包装，性能受限于Pandas，且没有查询优化器。
• Daft vs Ray Data: Ray Data 是 Ray生态内的数据处理组件，设计比较简单，数据 shuffle需要用户自行编程解决，也没有查询优化器。
• Daft vs DuckDB: DuckDB是一个嵌入式分析数据库，单机性能极佳，但不支持分布式。Daft则是为分布式场景设计的，同时也提供了单机模式。
• Daft vs Smallpond: Smallpond 是DeepSeek 开源的分布式数据处理框架，它的思路是用 DuckDB作为单机算子，基于 Ray 实现分布式调度和 shuffle。Smallpond 没有 SQL优化器，用户需要手动编写分布式执行计划。

总结

• Python 原生，无 JVM 包袱：消除了 PySpark的跨语言开销，对 Python 用户更友好
• Rust 执行引擎：Apache Arrow 内存模型、SIMD向量化、高性能异步 IO
• 单机无缝衔接分布式：单机引擎 Swordfish 与基于 Ray的分布式引擎 Flotilla 无缝切换
• 多模态原生支持：重视 AI和多模场景，将图片、音频、向量等类型作为一等公民

References

1. Daft GitHubRepository
2. DaftDocumentation - Architecture
3. Building Daft:Python + Rust = a better distributed query engine (SciPy 2024)
4. IntroducingDaft: A High-Performance Distributed Dataframe
5. Life AfterApache Spark: Why and How We’re Building the Daft Query Engine

众所周知，Apache Calcite 是为数不多的开源 Volcano/Cascades查询优化器实现之一，最早脱胎于 Hive 的优化器，后来也被 Flink等一众项目采用。

但事实上 Calcite 中的 VolcanoPlanner并非像论文中描述的那样是一个 top-down 优化器。去年阿里云 MaxCompute团队向 Calcite 提交了 PR，引入了新的 top-down优化选项，同时也弥补了之前缺失的剪枝、pass-through 等特性。

本文假设读者已经对 Apache Calcite 以及 Volcano/Cascades优化器的原理比较熟悉。

背景

Calcite 中原来的 VolcanoPlanner并非对论文的标准实现。具体来说，论文中给出的实现是一个自顶向下（top-down）的递归算法，在每个递归节点上，可以通过某些规则决定apply 规则的先后顺序。而 Calcite的实现则是一个全局的优先队列，即 apply规则的顺序由全局唯一的优先队列控制。（优先队列的实现可参见我之前的文章Calcite 对 Volcano优化器优先队列的实现）

这样做的好处是，如果不希望遍历整个搜索空间，该策略能够在给定的有限步数内给出较优解（从我个人经历来看，似乎很少有人这么用）。但代价则是代码逻辑变得十分难懂，也无法进行进行剪枝优化。从使用者的角度看，原本top-down 优化中 apply rule 一定是先父节点、后子节点，而 Calcite中的优化则是“随机”发生在 plan tree 的各个节点上，这也给编写 rule带来了一些麻烦。

2020 年 4 月阿里云 MaxCompute（ODPS）团队提出了 CALCITE-3916:Support cascades style top-down driven ruleapply，即新增一个真正意义上的 top-down优化器。这过程中还经历了一些插曲，首次提交的 PR #1950直接新增了一个 CascadesPlanner可能因为修改过大并没有被接受，之后又重构了一版 #1991，将同样的功能实现在了VolcanoPlanner 内部并提供了 TOPDOWN_OPT选项用于启用或关闭。该功能最终在 2020 年 7 月完成进入主分支。

核心逻辑：TopDownRuleDriver

为了将新旧两种优化器合并在 VolcanoPlanner 中，#1991抽象出了 RuleDriver 和 RuleQueue 两个类。当top-down 优化器开启时，VolcanoPlanner中的以下逻辑会被替换：

• RuleDriver：从 IterativeRuleDriver 替换成TopDownRuleDriver
• RuleQueue：从 IterativeRuleQueue 替换成TopDownRuleQueue

其中 TopDownRuleQueue 逻辑很简单：由于 Calcite 是在新RelNode 生成的时候对其进行匹配的，这里用一个RelNode -> Deque<VolcanoRuleMatch>的映射按照匹配的节点存放 rule match的队列，供以后递归到相应节点的时候再进行 apply。

1
2
3
4
5
6

/**
 * A rule queue that manages rule matches for cascades planner.
 */
class TopDownRuleQueue extends RuleQueue {

  private final Map<RelNode, Deque<VolcanoRuleMatch>> matches = new HashMap<>();

我们重点看 TopDownRuleDriver。它的设计参考了 Columbia优化器，其内部并非是一个简单的递归函数，而是用栈 tasks模拟了整个 top-down 的过程。

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

/**
 * A rule driver that applies rules in a Top-Down manner.
 * By ensuring rule applying orders, there could be ways for
 * space pruning and rule mutual exclusivity check.
 *
 * <p>This implementation uses tasks to manage rule matches.
 * A Task is a piece of work to be executed, it may apply some rules
 * or schedule other tasks.</p>
 */
class TopDownRuleDriver implements RuleDriver {

  /**
   * The rule queue designed for top-down rule applying.
   */
  private final TopDownRuleQueue ruleQueue;

  /**
   * All tasks waiting for execution.
   */
  private final Stack<Task> tasks = new Stack<>();

整个优化过程由下面的循环驱动：不断从栈顶取出 Task 执行，Task执行中又会产生新的Task，重复这一过程直到栈为空。本质上这和递归没什么区别。

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

/**
 * Applies rules.
 */
@Override public void drive() {
    tasks.push(
        new OptimizeGroup(
            requireNonNull(planner.root, "planner.root"),
            planner.infCost));

    // Iterates until the root is fully optimized.
    while (!tasks.isEmpty()) {
        Task task = tasks.pop();
        task.perform();
    }
}

可以看到，一切优化都是从一个名为 OptimizeGroup(root) 的task 开始的。下面我们依次看看有哪些 Task以及它们分别在干什么。在开始之前先解释一些术语：

OptimizeGroup

OptimizeGroup 用于优化一个RelSubset，类似于 Columbia 中的 O_GROUP。

1. 递归优化当前 RelSubset 中的每个 physical plan（生成OptimizeInputs）
2. 递归优化当前 RelSubset 中的每个 logical plan（生成OptimizeMExpr）

注意，这里故意先探索 physical plan 再探索 logical plan（即explore），这是因为搜索 physical plan 的过程中可能生成可行 plan从而能帮助剪枝。

OptimizeInputs以及 OptimizeInput1

OptimizeInputs 依次为调用每个子节点的OptimizeGroup，对应 Columbia 中的O_INPUTS。

OptimizeInput1 是 OptimizeInputs在只有一个子节点情况下的简化版本。

OptimizeMExpr

OptimizeMExpr 用于优化一个 logical plan，类似于 Columbia中的 E_GROUP。这里 MExpr 的命名是借鉴自Columbia 中的 M_EXPR（multi-expression）

1. 依次 explore 每个子节点 RelSubset（生成ExploreInput）
2. 在当前节点匹配所有可能的规则（生成 ApplyRules）

ExploreInput

ExploreInput 为当前 RelSubset 中的每个logical plan 生成OptimizeMExpr。不难看出，它们俩来回调用构成了整个 explore过程。

ApplyRules 以及ApplyRule

故名思义 ApplyRules 为当前节点找到所有的 rule match并生成相应的 ApplyRule，后者 apply rule 生成新的 plan。新plan 产生后必然会进入某个RelSubset，进而又会进一步触发后续的优化任务（这部分位于onProduce）：

• 如果产生的是 logical plan 则生成 OptimizeMExpr
• 如果产生的是 physical plan 则生成 OptimizeInputs

和上面 OptimizeGroup 做的事情如出一辙。

到此为止，上述这些 task 共同构成了 top-down优化的递归过程。下图是各个 task之间的调用关系，蓝色回边意味着递归进入下一层节点。

剪枝的实现

Volcano/Cascades 优化器的论文中提到，top-down 相比 bottom-up的一大优势是可以进行剪枝（pruning 或 branch-and-bound）。在 Calcite原本的 VolcanoPlanner 中这也是做不到的。

新引入的 top-down 优化器同时也带来了剪枝特性。剪枝的原理可以参见Columbia 论文 4.3.1 章节，一图以概之：

上图中的 context 在 Calcite 的实现中即是 OptimizeInputs这个 task。其中，upperBound 在 OptimizeGroup时传入 RelSubset 最后又传到这里。一旦优化中发现lowerBound > upperBound，则可以不再优化其他子节点、放弃当前RelSubset。

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

/**
 * Optimizes a physical node's inputs.
 * This task calculates a proper upper bound for the input and invokes
 * the OptimizeGroup task. Group pruning mainly happens here when
 * the upper bound for an input is less than the input's lower bound
 */
private class OptimizeInputs implements Task {

  private final RelNode mExpr;
  private final RelSubset group;
  
  private RelOptCost upperBound;
  private RelOptCost upperForInput;
  private @Nullable List<RelOptCost> lowerBounds;
  private @Nullable RelOptCost lowerBoundSum;

Pruning 发生在 OptimizeInputs 的过程中：

1. 初始化：对每个（尚未优化的）子节点通过 RelMetadataQuery中的 LowerBoundCost 接口获取最低cost。（LowerBoundCost这个接口需要额外实现，如果没有实现就是 0）
2. 每当 OptimizeGroup 优化完一个子节点，另一个任务CheckInput 会用实际的 cost 替代（抬升）之前的 lowerbound
3. 直到完成所有的子节点的 OptimizeGroup

上述 1～3 每个步骤之后都有能出现lowerBound > upperBound，进而中止当前的OptimizeInputs 过程，达到剪枝的效果。

Pass-through 和 derive

回忆一下 Volcano/Cascades 优化器中，递归调用的输入参数不仅包括logical plan，还包括上层所需的 physicalproperties。二者共同组成了动态规划的最优子结构。

但是 Calcite 原本的 VolcanoPlanner中并没有向下传递所需的 physical properties，而是通过临时放置一个AbstractConvertor 作为所需 RelSubset 的placeholder，在之后 apply rule 的过程中如果能“恰好”产生同一RelSubset 的 plan，则可能会作为 best被选出。这一过程中，apply rule 或是算子并不知道上层需要怎样的 physicalproperties，因此比较低效。

新增的 top-down 优化器引入了一个新特性，允许算子主动处理上层要求的physical properties，该特性称为 pass-through。

由于 pass-through 处理的是 physicalproperties，显然只有物理算子才需要实现pass-through，相应的接口如下：

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

/**
 * Physical node in a planner that is capable of doing
 * physical trait propagation and derivation.
 */
public interface PhysicalNode extends RelNode {

  /**
   * Pass required traitset from parent node to child nodes,
   * returns a pair of traits after traits is passed down.
   *
   * <p>Pair.left: the new traitset
   * <p>Pair.right: the list of required traitsets for child nodes
   */
  Pair<RelTraitSet, List<RelTraitSet>> passThroughTraits(RelTraitSet required);
      
  /**
   * Derive traitset from child node, returns a pair of traits after
   * traits derivation.
   *
   * <p>Pair.left: the new traitset
   * <p>Pair.right: the list of required traitsets for child nodes
   */
  Pair<RelTraitSet, List<RelTraitSet>> deriveTraits(RelTraitSet childTraits, int childId);
}

对于 Project、Filter这样的简单算子，几乎只要直接穿透就可以了。举个稍复杂的例子：EnumerableHashJoin 算子依次对 probe side 的每一行进行join，因此不会改变 probe side的顺序（collation）；如果所需的排序键恰好位于EnumerableHashJoin 的 probeside，那么可以将其直接向下穿透到 probe side 的子节点上。

有了 pass-through 之后，AbstractConvertor也就用不着了。相对的，在 top-down 过程中，一旦有新的 physical properties产生，就会调用下层各个物理算子的 pass-through 接口以及 converterrule，从中挑选出 best plan。

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

/**
 * Tries to convert the physical node to another trait sets, either by converter rule
 * or traits pass through.
 */
private RelNode convert(RelNode rel, RelSubset group) {
  if (!passThroughCache.contains(rel)) {
    RelNode passThrough = group.passThrough(rel);
    if (passThrough != null) {
      passThroughCache.add(passThrough);
      return passThrough;
    }
  }
  VolcanoRuleMatch match = /* find matched converter rule */;
  if (match != null) {
    tasks.add(new ApplyRule(match, group, false));
  }
  return null;
}

为了配合 pass-through，OptimizeGroup 中优化某个RelSubset 时不仅会检查当前 RelSubset 包含的plan，实际上它检查的是所属的 RelSet 中所有的 plan。对于其中physical properties 不同的 plan，它会调用上面的 convert方法触发 pass-through 以及 converter rule。

最后再说说 derive。我们说过，pass-through用于自上而下传递所需的 physicalproperties。但是在某些情况下这还不够。例如考虑 broadcast join的生成过程，其中 Join 算子的 distribution 需要和其中一个输入节点（例如TableScan）保持一致，另一边则通过 Exchange(broadcast) 将数据重分布到所有Join 上。注意这里 Join 算子的 distribution 来自于它的子节点TableScan，这一自下而上的传递过程就依赖 derive。

DeriveTrait 任务总是在一个 physical plan生成后被调用，用于调用 derive 接口。如果 derive 产生了新的 trait则为之生成相应的 RelSubset。

总结

新引入的 top-down 优化器实现了真正的自顶向下搜索。相比 Calcite 原来的VolcanoPlanner 实现，它具有以下优势：

1. 实现更接近论文中的描述，更加简单易懂
2. 支持 lower-bound pruning，节约优化时间
3. 支持 pass-through，改进 physical properties 相关的优化性能

References

1. Apache Calcite - Source Code
2. CALCITE-3916:Support cascades style top-down driven rule apply
3. CALCITE-3916:Support top-down rule apply and upper bound space pruning #1991
4. Efficiencyin the Columbia Database Query Optimizer - YONGWEN XU

附件：top_down_trace.zip -一个简单的两表 Join 的优化过程 trace log，包括优化过程中 plan的可视化（graphviz + svg）

Milvus是一个用于向量（Vector）存储和检索的特殊数据库，由国内的创业公司 Zilliz开发。本文内容来自 Milvus 在 SIGMOD'21 上的论文 Milvus:A Purpose-Built Vector Data Management System。

所谓向量，可以看作一个长度为 N 的元组。很多 AI/ML系统（例如推荐系统、图片相似度检测等）都有类似的需求：这些系统首先将海量数据集经过特征提取得到很多向量，使用时给定一个向量，从数据集向量中快速检索出和它最"相似"的的K个向量。相似度的定义有多种，最常见的有余弦距离、欧几里得距离等。

为了做到这一点，最 naive的方法就是让给定向量和所有数据库中的向量依次做比较，但显然这个做法太慢了。RDBMS中有索引的概念，那我们能不能为向量的相似度也建立索引呢？当然是可以的！

这个问题称为向量相似度检索（vector similaritysearch），Facebook 开源的 Faiss 就是这样一个C++ library，它内置了多种索引，例如 IVF_FLAT、IVF_FQ8、IVF_PQ等（这些算法不是本文的重点）。Milvus 基于 Faiss 开发，Milvus添加了存储组件，使之成为一个完整的数据库产品（而不仅是个libaray），同时也做了很多工程上的优化。

存储格式

Milvus 的数据模型允许每行数据（文中称为 entity）包含 1 个或多个vector 以及可选的数值属性（numericattribute）。其中数值属性一般起到过滤作用，比如年龄、身高之类的，可以作为查询过滤条件的一部分。

每个 vector 本身显然是要连续排列的（vector 一定是以整体参与运算），而vector 之间按列排列。比如一张表有 v1、v2 两个 vector 列、{A,B,C}三行数据，那么在存储上的排列就是 {A.v1, B.v1, C.v1, A.v2, B.v2, C.v2}。

数值属性的排列比较有意思，同样是先按列分开，每个列内部类似一个有序的倒排索引：属性的数值-> Row ID，通过 RowID 就可以找到相应的vector。这样的设计是为了支持高效的 point/range query（comment:但同时也意味着 select 这些属性的代价变得很高，所以估计不支持 select吧，若理解有误欢迎指正）。

存储采用类似于 LSM-Tree 的分层 compaction 设计。新写入的数据会进入MemTable，MemTable 会刷到磁盘上，同时构建索引。和很多 OLTP系统的不同之处是，Milvus并不保证写后读，除非手动调用 flush() API否则可能查不到新写入的数据（之所以这样也和后面的 shared-storage架构有关）。但是 Milvus 可以保证读到的 Snapshot是一致的（例如不会读到写了一半的数据），实现原理也很简单：在读取时记录下当前所有SS-Table 的文件集合快照，从这个快照中读取。

Milvus 的分布式架构是个基于共享 object storage的一写多读架构，有点类似于 Snowflake。writer始终只有一个，因此也不会用到分布式事务。reader 可以横向扩展，通过coordinator 可以将一个查询根据分片+路由的方式打到所有 reader上，将查询在多个节点上并行起来。每个 reader都可以利用本地的磁盘和内存缓存一些热数据。

Milvus 通过 WAL 保证原子性和持久性，WAL同样位于共享存储层上。（comment: 这样延迟可能会比较大？）

索引选择

索引的原理超出本文的 scope，这里只介绍最基本的 idea：在 build索引时，会通过聚类算法选出几个中心点（v0~v9 聚类得到图中 c0~c2三个中心点），当给定查询 q 时，算法能快速找到离 q 最近的 k个中心点（k=2，得到 c0、c1），之后只要从 c0、c1的邻居中（v0~v6）搜索即可。

显然，索引是一个和数据相关的 immutable 的数据结构，这一点和 LSMTree的结构天然契合：从 MemTable 写到磁盘的时候或者 compaction 的时候 build索引即可。

索引选择的实现是基于 cost 的：

策略A（vector不走索引，数值条件走索引）：先通过数值属性的倒排索引过滤，再在过滤出来的所有数据上扫描（逐个计算相似度，不依靠vector的索引）

策略B（vector走索引，数值条件走索引）：通过数值属性的倒排索引拿到过滤结果bitmap，然后在 vector 上利用相似度索引得所有相似的向量，根据 bitmap只留下复合过滤条件的那些，再取 TopK

策略C（vector走索引，数值条件不走索引）：在 vector上利用相似度索引得所有相似的向量，然后按数值条件过滤

策略D：基于代价在 A/B/C中选择一个，至于怎么选应该很容易想到吧 :)

策略E：是对 D 的进一步改进，也是 Milvus使用的策略。具体来说，Milvus 首先根据某个数值属性将整个 dataset分区（比如 price 可以分为 [1, 100], [101, 200], [201, 300], [301, 400]），之后，如果查询条件带有分区键，则可以进行"分区裁剪"（比如对于 pricein [50, 250]，可以直接裁剪出 [1, 100], [101, 200], [201, 300]这三个分区），并且对每个分区采取 cost-based 策略（比如中间的 [101, 200]区间不需要对 price 进行过滤，因为一定满足条件）

工程优化

• 对 Faiss 的 cache-miss 问题做了优化，性能提升 1.5x ~ 2.7x- 支持SIMD，支持根据 cpu 指令集选择最高效的 SIMD指令集（SSE/AVX/AVX2/AVX512）- 更好的 GPU 支持：允许更大的 Top k，允许多GPU- GPU & CPU 混合计算

优化效果可以参见原文 Evaluation 一节，这里不贴了。

补充：据说论文的架构是Milvus1.x的架构，2.0新架构大幅重构了，见文档 MilvusArchitecture Overview - Milvus documentation

Apache Doris 原名是Palo，由百度于 2017 年开源，Palo 这个词来自 OLAP 的反转，寓意这是一个OLAP 系统。

初次看到它的时候以为是又一个数据仓库产品，没怎么关注，直到最近才发现和我们熟悉的Greemplum、Impala 等等有不少区别，其中最有特色的是它的数据模型，借鉴自Google 2014 年公开在 VLDB 上的 Mesa。本文的前半部分也会聊聊 Doris/Mesa的数据模型是怎样的。

Mesa：预聚合数据模型

Mesa 是为了解决 Google广告业务的实时分析需求而诞生的。广告业务的特点是其数据量特别大，每次广告的展示、点击都会产生一条数据，存储这些原始数据不但会消耗大量的存储资源，也会给实时计算聚合结果（比如“某个广告主截止目前已经消费了多少预算”）带来很大困难。

Mesa为了解决上面提到的两个问题，提出了一个预聚合的存储模型。Mesa中的所有表都是预聚合表，以下图中的 Table A 为例：其中竖线之前的Date、PublisherId、Country 三列是 Key列，表示聚合的维度，语义等同于 Group-By；竖线之后的 Clicks 和Cost 列是 Value 列，表示被聚合的结果。例如第一行表示2013-12-31 这一天，ID 为 100 的 Publisher 在 US 一共发生了 10次点击、价值 32 块钱。

你可能已经发现了，上面的 Table A～D其实表示的是同一批原始数据的在四个不同维度的聚合结果，供不同的业务查询使用。是不是有点像MOLAP 或者说 Data Cube的概念？本质上是一样的，都是用预先定义和计算聚合（简称“预聚合”）来加速特定模式的查询。

和很多数仓产品一样，Mesa 只支持按 batch（或micro-batch）进行更新。更新具有原子性保证，因此不用担心上面各个表的数据不一致。每个更新版本包含这个batch 内发生的所有变化值（delta）。Mesa 要求所有的 Value列都需要定义它的聚合函数，因此 delta 就能和之前的数据进一步合并。

Mesa 在后台会异步地对每次导入的 delta 数据做 Compaction。为了让更新和Compaction 的效率更高，也为了支持一定时间范围内的历史读能力，Mesa 的Compaction 分为两层，第一层是对近期数据（比如当天的数据）的合并，称为Cumulatives，第二层是对某个时间点之前（比如今天以前的）的所有历史数据的合并，称为Base。下面是一个 Compaction 策略的例子：

这样的设计让 Mesa能够快速查询实时聚合结果，而不像传统 Data Cube那样需要在全量数据上重新Build。查询聚合结果时，我们选出最小覆盖集（spanningset）进行二次聚合即可，比如上图的例子中，为了查询版本 92的聚合结果，我们只需要读取 0-60、61-90、91、92 这 4个文件并合并即可。

个人认为论文主要的贡献就是这个预聚合数据模型的定义和实现，其他特性诸如高可用设计、存储格式、跨DC 部署架构等，有兴趣的同学请自行读论文。

Doris：混合的数据模型

一言以概之：Apache Doris = 一般 MPP 数仓 + 借鉴自 Mesa的预聚合模型

Doris 的诞生背景和 Mesa非常相似，都是来自广告业务的实时报表需求，从这篇文章看来，2012年百度从 Google 挖来一名高T，“带来了当时业界最领先的底层报表引擎技术”，带着团队做出了 Palo也就是今天的 Doris。

Doris 的数据模型稍复杂一些，支持以下三种模型的表：

1. Aggregate 表：需要定义 Key 列和 Value 列，Key列相同的数据行会自动合并，合并时 Value列的数据按预先定义好的聚合函数进行聚合
2. Duplicate 表：不会自动合并 Key相同的数据，其语义类似于其他数据库中的关系表，Key 表示表的排序键（sortkey）而不是唯一键
3. Uniq 表，Key 列相同时新的行覆盖（Replace）旧的行，本质上是一种特化的Aggregate 表

官方文档对如何选择上述 3 种模型给出的建议如下：

1. Aggregate表可以通过预聚合，极大地降低聚合查询时所需扫描的数据量和查询的计算量，非常适合有固定模式的报表类查询场景
2. Uniq表针对需要唯一主键约束的场景，可以保证主键唯一性约束。但是无法利用ROLLUP 等预聚合带来的查询优势
3. Duplicate 适合任意维度的 Ad-hoc查询。虽然同样无法利用预聚合的特性，但是不受聚合模型的约束，可以发挥列存模型的优势

这个模型给我一种缝合怪的感觉。Aggregate 模型显然直接对应于 Doris最初的使用场景（广告数据实时聚合），而另外两个 Uniq 和 Duplicate模型则是对应于其他数据仓库中的关系表。之所以这么设计，猜测是因为还有很多使用场景无法用预聚合模型表示，例如维表和明细表，它们天然地不包含聚合的语义。

Aggregate 表带来了一些令人困惑的特性。Doris 通过 SQL 接口进行查询，在SQL 语义中，Aggregate 表也会被视为普通的关系表。继续以上文 Mesa Table A为例，在 Doris 中，用户执行下面的这些语句是“正确”的：

1

SELECT SUM(Clicks) FROM PublisherClicks GROUP BY `Date`, PublisherId, Country

但是用户也完全可以执行这样的语句：

1

SELECT MAX(Clicks) /* <- 奇怪的语义 */ FROM PublisherClicks GROUP BY `Date`, PublisherId, Country

由于 Clicks 本身已经是加和的结果，对它取 MAX并没有实际的意义。更糟糕的是，计算 MAX(Clicks)的代价要比计算 SUM(Clicks) 大的多，为何会这样呢？上一小节说Mesa 的时候提到，每次导入的 delta数据不会立即和基线数据合并，而是会先以单独的文件存在，积累一定数量后再做Compaction。而计算 MAX(Clicks) 时必须基于完全合并（对每一个Key 计算 SUM(Clicks)）的数据，才能正确算出 MAX的结果，代价很高。

在文档中特别以COUNT(*)的例子阐述了这个问题，目测不少用户在这里踩过坑。

在 Mesa 中没有这个问题，Mesa仅仅提供了针对预聚合查询（MOLAP）的特殊查询接口而非SQL，如果用户需要和其他数据作关联，则需要通过 F1 Query之类的联合查询引擎。个人觉得 Doris 的 Aggregate表有点弄巧成拙的意思，语义上比较奇怪。

ROLLUP 与物化视图

Mesa允许用户指定同一份数据的多种维度的预聚合表，并能保证更新时的原子性。这一套设计同样也被搬到了Doris 中。不过，在 Mesa 中，这些更新数据是由外部系统构建的，Mesa本身仅仅提供增量聚合的能力。

而在 Doris 中，用户需要创建一个数据最详尽的 Base表，然后再在上面创建不同的 ROLLUP，以获得更 high-level 的聚合结果。这个ROLLUP 的概念和 SQL 中的 ROLLUP 语法没关系，它的语义是以另一个维度对Base 表进行进一步的聚合，当 Base 表发生更新时 Doris 也会自动地同步更新ROLLUP 数据。例如，对于上面 Mesa 的例子，我们先定义一个包含所有 Key 列和Value 列的 Aggregate 表，并在此基础上创建 ROLLUP：

创建 ROLLUP 的前提是 Base 表必须是 Aggregate 表，这样 ROLLUP才知道如何聚合各个 Value 列。ROLLUP 的 Key 列也必须被包含在 Base 表的Key 列中，但顺序可以和原来不一致。

ROLLUP 的引入是 Doris 的创新点之一，它确实简化了数据导入的流程。在Mesa 中用户还需要再构建一个 pipeline 生成增量数据，而 Doris 通过引入ROLLUP “内置” 了这一过程。但是另一方面，ROLLUP必须基于一个包含所有聚合维度的 Base 表（比如上面的 Base 表包含Date、Publisher、Advertiser、Country 这些维度），真的有必要这样吗？

为了解开 “ROLLUP 必须基于 Aggregate 表”的这个奇怪限制，Doris后来又引入了物化视图的概念，允许用户基于明细表（Duplicate表）定义预聚合。Doris的物化视图仅支持定义聚合（Group-By），并且对聚合函数也有所限定。Doris的物化视图和 ROLLUP 一样都是增量更新的，内部很有可能是相同的实现。

1
2
3
4
5
6

-- 创建 ROLLUP 的语法
ALTER TABLE ads ADD ROLLUP `PublisherRollup` (`Date`, PublisherId, Clicks, `Cost`)

-- 创建物化视图的语法
CREATE MATERIALIZED VIEW `PublisherMView` AS
SELECT `Date`, PublisherId, SUM(Clicks), SUM(`Cost`) FROM ads GROUP BY `Date`, PublisherId

个人认为，把预聚合模型抽象为物化视图要比 ROLLUP更优雅、更符合 SQL语义，可惜在文档的编排中这个功能似乎只是被当作一个辅助出现的。依我看还不如把ROLLUP 特性废弃掉算了。

如果用户的查询中用到了预聚合的值，查询优化器可以自动选择 ROLLUP或物化视图来加速查询，这部分的实现是基于规则（比如最长匹配原则）而非基于代价的，有兴趣的读者可以去看文档。

Doris as a MPP DataWarehouse

好了，至此为止，我觉得有意思的部分就讲完了。Doris的其他部分是一个类似 Impala 或 Greemplum的中规中矩的数据仓库产品，没有太多亮点。不过既然是 MPP数仓就意味着它能执行各种各样的 SQL，像 TPC-H、TPC-DS 这样的 Ad-hoc查询当然也不在话下。

快速地过一遍其他特性：

• 部署架构：分为 FE（前端）和 BE（后端）两个组件
  • FE 负责接受用户请求、优化、调度查询，由 Java 编写
  • BE 负责存储数据、执行 MPP 计划中的各个片段，类似于 Worker 的角色，由C++ 编写
  • FE 还内置了 BerkeleyDB 用于保存元数据，并通过多副本保证高可用
• 分区方式：支持逻辑和物理两层分区
  • 逻辑分区通常是时间日期，方便冷热数据分离，数据仓库标配
  • 物理分区通常是哈希，用于打散数据、均摊负载
• 存储格式：毫无疑问用的是列存，类似 ORC 格式
  • 通过 sort key 支持点查
  • 多副本保证高可用性
• 支持向量化（含 SIMD），不支持 JIT
• 支持 Online Schema Change

后记

翻看几篇 Doris 应用实践（比如这篇、这篇和这篇），发现几个有意思的共通点：

1. 业务方普遍选择将明细数据也保存在 Doris中，而不是仅有聚合数据，其用法更接近于一般数仓而不是 Mesa。
2. 预聚合模型是对 Ad-hoc的很好补充，对于实时报表等场景有极大提升。其他的实时数仓产品例如GP、Impala、ClickHouse、TiDB（雾）是否也可以借鉴一下呢？
3. Aggregate 表常被用于统计 UV（某 URL被多少个不同的用户访问过），被聚合的 Value 是用户 ID 的 bitmap，这可能是Doris 团队自己都没有想到的。

最后发表下我的观点：Doris借助物化视图等概念将预聚合（MOLAP）能力引入到 ROLAP体系中，并且通过分层合并做到快速更新、快速查询，是对实时数仓系统的一个很好的增强。

References

1. ApacheDoris 官方文档
2. Mesa:Geo-Replicated, Near Real-Time, Scalable Data Warehousing
3. ApacheDoris (Incubating) 原理与实践
4. ApacheDoris在美团外卖数仓中的应用实践
5. ApacheDoris在京东广告的应用实践
6. Apache Doris 在WeLab实时大数据平台的应用实践
7. Doris简史-为分析而生的11年

时间戳（timestamp）是分布式事务中绕不开的重要概念，有意思的是，现在主流的几个分布式数据库对它的实现都不尽相同，甚至是主要区分点之一。本文聊一聊时间戳的前世今生，为了把讨论集中在主题上，假设读者已经对数据库的MVCC、2PC、一致性、隔离级别等概念有个基本的了解。

为什么需要时间戳？

自从 MVCC被发明出来之后，那个时代的几乎所有数据库都抛弃（或部分抛弃）了两阶段锁的并发控制方法，原因无它——性能太差了。当分布式数据库逐渐兴起时，设计者们几乎都选择MVCC 作为并发控制方案。

MVCC 的全称是多版本并发控制（Multi-Version ConcurrencyControl），这个名字似乎暗示我们一定会有个版本号（时间戳）存在。然而事实上，时间戳还真不是必须的。MySQL 的 ReadView实现就是基于事务 ID 大小以及活跃事务列表进行可见性判断。

事务 ID 在事务开启时分配，体现了事务 begin 的顺序；提交时间戳commit_ts 在事务提交时分配，体现了事务 commit 的顺序。

分布式数据库 Postgres-XL也用了同样的方案，只是将这套逻辑放在全局事务管理器（GTM）中，由 GTM集中式地维护集群中所有事务状态，并为各个事务生成它们的Snapshot。这种中心化的设计很容易出现性能瓶颈，制约了集群的扩展性。

另一套方案就是引入时间戳，只要比较数据的写入时间戳（即写入该数据的事务的提交时间戳）和Snapshot的读时间戳，即可判断出可见性。在单机数据库中产生时间戳很简单，用原子自增的整数就能以很高的性能分配时间戳。Oracle用的就是这个方案。

而在分布式数据库中，最直接的替代方案是引入一个集中式的分配器，称为TSO（Timestamp Oracle，此 Oracle 非彼 Oracle），由 TSO提供单调递增的时间戳。TSO看似还是个单点，但是考虑到各个节点取时间戳可以批量（一次取 K个），即便集群的负载很高，对 TSO 也不会造成很大的压力。TiDB用的就是这套方案。

MVCC 和 Snapshot Isolation有什么区别？前者是侧重于描述数据库的并发控制实现，后者从隔离级别的角度定义了一种语义。本文中我们不区分这两个概念。

可线性化

可线性化（linearizable）或线性一致性意味着操作的时序和（外部观察者所看到的）物理时间一致，因此有时也称为外部一致性。具体来说，可线性化假设读写操作都需要执行一段时间，但是在这段时间内必然能找出一个时间点，对应操作真正“发生”的时刻。

注意不要把一致性和隔离级别混为一谈，这完全是不同维度的概念。理想情况下的数据库应该满足strict serializability，即隔离级别做到 serializable、一致性做到linearizabile。本文主要关注一致性。

隔离性（Isolation）与一致性（Consistency）

TSO时间戳能够提供线性一致性保证。完整的证明超出了本文的范畴，这里只说说直觉的解释：用于判断可见性的snapshot_ts 和 commit_ts 都是来自于集群中唯一的 TSO，而 TSO作为一个单点，能够确保时间戳的顺序关系与分配时间戳的物理时序一致。

可线性化是一个极好的特性，用户完全不用考虑一致性方面的问题，但是代价是必须引入一个中心化的TSO。我们后边会看到，想在去中心化的情况下保持可线性化是极为困难的。

TrueTime

Google Spanner 是一个定位于全球部署的数据库。如果用 TSO方案则需要横跨半个地球拿时间戳，这个延迟可能就奔着秒级去了。但是 Google的工程师认为 linearizable 是必不可少的，这就有了 TrueTime。

TrueTime 利用原子钟和 GPS 实现了时间戳的去中心化。但是原子钟和 GPS提供的时间也是有误差的，在 Spanner 中这个误差范围 \(\varepsilon\) 被设定为7ms。换句话说，如果两个时间戳相差小于 \(2\varepsilon\)，我们就无法确定它们的物理先后顺序，称之为“不确定性窗口”。

Spanner对此的处理方法也很简单——等待不确定性窗口时间过去。在事务提交过程中Spanner 会做额外的等待，直到满足 \(TT.now() -T_{start} >2\varepsilon\)，然后才将提交成功返回给客户端。在此之后，无论从哪里发起的读请求必然会拿到一个更大的时间戳，因而必然能读到刚刚的写入。

Lamport 时钟与 HLC

Lamport 时钟是最简单的逻辑时钟（LogicalClock）实现，它用一个整数表示时间，记录事件的先后/因果关系（causality）：如果A 事件导致了 B 事件，那么 A 的时间戳一定小于B。当分布式系统的节点间传递消息时，消息会附带发送者的时间戳，而接收方总是用消息中的时间戳“推高”本地时间戳：\(T_{local} = \max(T_{msg}, T_{local}) +1\)。

Lamport Clock 只是个从 0开始增长的整数，为了让它更有意义，我们可以在它的高位存放物理时间戳、低位存放逻辑时间戳，当物理时间戳增加时逻辑位清零，这就是HLC（Hybrid LogicalClock）。很显然，从大小关系的角度看，HLC 和 LC 并没有什么不同。

HLC/LC 也可以用在分布式事务中，我们将时间戳附加到所有事务相关的 RPC中，也就是 Begin、Prepare 和 Commit 这几个消息中：

• Begin：取本地时间戳 local_ts 作为事务读时间戳snapshot_ts
• Snapshot Read: 用 snapshot_ts读取其他节点数据（MVCC）
• Prepare：收集所有事务参与者的当前时间戳，记作prepare_ts
• Commit：计算推高后的本地时间戳，即 commit_ts = max{prepare_ts } + 1

HLC/LC并不满足线性一致性。我们可以构造出这样的场景，事务 A 和事务 B发生在不相交的节点上，比如事务 \(T_A\)位于节点 1、事务 \(T_B\) 位于节点2，那么这种情况下 \(T_A\)、\(T_B\)的时间戳是彼此独立产生的，二者之前没有任何先后关系保证。具体来说，假设\(T_A\) 物理上先于 \(T_B\) 提交，但是节点 2 上发起的 \(T_B\) 的 snapshot_ts可能滞后（偏小），因此无法读到 \(T_A\)写入的数据。

1
2
3

T1: w(C1)
T1: commit
T2: r(C2)   (not visible! assuming T2.snapshot_ts < T1.commit_ts)

HLC/LC 满足因果一致性（Causal Consistency）或 Session一致性，然而对于数据库来说这并不足以满足用户需求。想象一个场景：应用程序中使用了连接池，它有可能先用Session A 提交事务 \(T_A\)（用户注册），再用 Session B 进行事务\(T_B\)（下订单），但是 \(T_B\) 却查不到下单用户的记录。

如果连接池的例子不能说服你，可以想象一下：微服务节点 A负责用户注册，之后它向微服务节点 B 发送消息，通知节点 B 进行下订单，此时B却查不到这条用户的记录。根本问题在于应用无法感知数据库的时间戳，如果应用也能向数据库一样在RPC 调用时传递时间戳，或许因果一致性就够用了。

有限误差的 HLC

上个小节中介绍的 HLC物理时间戳部分仅供观赏，并没有发挥实质性的作用。CockroachDB创造性地引入了 NTP 对时协议。NTP 的精度当然远远不如原子钟，误差大约在100ms 到 250ms 之间，如此大的误差下如果再套用 TrueTime的做法，事务延迟会高到无法接受。

CockroachDB 要求所有数据库节点间的时钟偏移不能超过250ms，后台线程会不断探测节点间的时钟偏移量，一旦超过阈值立即自杀。通过这种方式，节点间的时钟偏移量被限制在一个有限的范围内，即所谓的半同步时钟（semi-synchronizedclocks）。

下面是最关键的部分：进行 Snapshot Read 的过程中，一旦遇到 commit_ts位于不确定性窗口[snapshot_ts, snapshot_ts + max_clock_shift]内的数据，则意味着无法确定这条记录到底是否可见，这时将会重启整个事务（并等待max_clock_shift 过去），取一个新的 snapshot_ts 进行读取。

有了这套额外的机制，上一节中的“写后读”场景下，可以保证读事务 \(T_B\) 一定能读到 \(T_A\) 的写入。具体来说，由于 \(T_A\) 提交先于 \(T_B\) 发起，\(T_A\) 的写入时间戳一定小于 B.snapshot_ts +max_clock_shift，因此要么读到可见的结果（A.commit_ts <B.snapshot_ts），要么事务重启、用新的时间戳读到可见的结果。

那么，CockroachDB是否满足可线性化呢？答案是否定的。Jepsen 的一篇测试报告中提到以下这个“双写”场景（其中，数据C1、C2 位于不同节点上）：

1
2
3
4
5
6
7

                        T3: r(C1)      (not found)
T1: w(C1)
T1: commit
            T2: w(C2)
            T2: commit                 (assuming T2.commit_ts < T3.snapshot_ts due to clock shift)
                        T3: r(C2)      (found)
                        T3: commit

虽然 T1 先于 T2 写入，但是 T3 却看到了 T2 而没有看到T1，此时事务的表现等价于这样的串行执行序列：T2 -> T3 ->T1（因此符合可串行化），与物理顺序 T1 -> T2不同，违反了可线性化。归根结底是因为 T1、T2两个事务的时间戳由各自的节点独立产生，无法保证先后关系，而Read Restart机制只能防止数据存在的情况，对于这种尚不存在的数据（C1）就无能为力了。

Jepsen 对此总结为：CockroachDB仅对单行事务保证可线性化，对于涉及多行的事务则无法保证。这样的一致性级别是否能满足业务需要呢？这个问题就留给读者判断吧。

结合 TSO 与 HLC

最近看到 TiDB 的 AsyncCommit 设计文档 引起了我的兴趣。Async Commit的设计动机是为了降低提交延迟，在 TiDB 原本的 Percolator 2PC实现中，需要经过以下 4 个步骤：

1. Prewrite：将 buffer 的修改写入 TiKV 中
2. 从 TSO 获取提交时间戳 commit_ts
3. Commit Primary Key
4. Commit 其他 Key（异步进行）

为了降低提交延迟，我们希望将第 3 步也异步化。但是第 2 步中获取的commit_ts 需要由第 3 步来保证持久化，否则一旦协调者在 2、3步之间宕机，事务恢复时就不知道用什么 commit_ts 继续提交（rollforward）。为了避开这个麻烦的问题，设计文档对 TSO时间戳模型的事务提交部分做了修改，引入 HLC 的提交方法：

• Prewrite：
  1. TiDB 向各参与事务的 TiKV 节点发出 Prewrite 请求
  2. TiKV 持久化 Prewrite 的数据以及 min_commit_ts，其中 min_commit_ts =本地最大时间戳 max_ts
  3. TiKV 返回 Prewrite 成功消息，包含刚刚的 min_commit_ts
• Finalize（异步）：计算 commit_ts = max{min_commit_ts }，用该时间戳进行提交
  1. Commit Primary Key
  2. Commit 其他 Key

上述流程和 HLC 提交流程基本是一样的。注意，事务开始时仍然是从 TSO获取 snapshot_ts，这一点保持原状。

我们尝试代入上一节的“双写”场景发现：由于依赖 TSO 提供的snapshot_ts，T1、T2的时间戳依然能保证正确的先后关系，但是只要稍作修改，即可构造出失败场景（这里假设snapshot_ts 在事务 begin 时获取）：

1
2
3
4
5
6
7
8

T1: begin   T2: begin   T3: begin       (concurrently)
T1: w(C1)
T1: commit                              (assuming commit_ts = 105)
            T2: w(C2)
            T2: commit                  (assuming commit_ts = 103)
                        T3: r(C1)       (not found)
                        T3: r(C2)       (found)
                        T3: commit

虽然 T1 先于 T2 写入，但 T2 的提交时间戳却小于 T1，于是，并发的读事务T3 看到了 T2 而没有看到 T1，违反了可线性化。根本原因和CockroachDB 一样：T1、T2两个事务的提交时间戳由各自节点计算得出，无法确保先后关系。

Async Commit Done Right

上个小节给出的 Async Commit 方案破坏了原本 TSO时间戳的线性一致性（虽然仅仅是个非常边缘的场景）。这里特别感谢 @Zhifeng Hu 的提醒，在 #8589中给出了一个巧妙的解决方案：引入 prewrite_ts 时间戳¹，即可让并发事务的 commit_ts重新变得有序。完整流程如下，注意 Prewrite 的第 1、2 步：

• Prewrite：
  1. TiDB 从 TSO 获取一个 prewrite_ts，附带在其中一个 Prewrite请求上发送给 TiKV
  2. TiKV 用 prewrite_ts（如果收到的话）推高本地最大时间戳 max_ts
  3. TiKV 持久化 Prewrite 的数据以及 min_commit_ts = max_ts
  4. TiKV 返回 Prewrite 成功消息，包含刚刚的 min_commit_ts
• Finalize（异步）：计算 commit_ts = max{min_commit_ts }，用该时间戳进行提交
  1. Commit Primary Key
  2. Commit 其他 Key

对应到上面的用例中，现在 T1、T2两个事务的提交时间戳不再是独立计算，依靠 TSO 提供的 prewrite_ts可以构建出 T1、T2 的正确顺序：T2.commit_ts >= T2.prewrite_ts >T1.commit_ts，从而避免了上述异常。

更进一步，该方案能够满足线性一致性。这里只给一个直觉的解释：我们将TSO 看作是外部物理时间，依靠 prewrite_ts 可以保证 commit_ts 的取值位于commit 请求开始之后，而通过本地 max_ts 计算出的commit_ts 一定在 commit 请求结束之前，故 commit_ts取值落在执行提交请求的时间范围内，满足线性一致性。

总结

1. 上述已知的时间戳方案中，仅有 TSO 和 TrueTime能够保证线性一致性；
2. Logical Clock 方案仅能保证 Session 一致性；
3. Cockroach 的 HLC方案仅能保证行级线性一致性，不保证多行事务的线性一致性；
4. TiDB Async Commit 通过引入 Prewrite时间戳保持了外部一致性；但如果去掉 Prewrite 时间戳、使用 HLC的提交方式，则不保证多行的并发事务的线性一致性。

References

1. Lamporttimestamp - Wikipedia
2. Spanner:Google’s Globally-Distributed Database - OSDI'12 Presentation
3. Jepsen:CockroachDB beta-20160829
4. LivingWithout Atomic Clocks - Cockroach Labs
5. Consistency,causal and eventual - Sergei Turukin
6. TiDBAsync Commit (initial design)
7. Async commit doesnot ensure linearizability - GitHub

Yugabyte DB是一个全球部署的分布式数据库，和国内的 TiDB 和国外的 CockroachDB类似，也是受到 Spanner论文启发，所以在很多地方这几个数据库存在不少相似之处。

与 Cockroach 类似，Yugabyte也主打全球分布式的事务数据库——不仅能把节点部署到全球各地，还能完整支持ACID事务，这是他最大的卖点。除此以外还有一些独特的特性，比如支持文档数据库接口。如果我猜的没错，Yugabyte早期被设计成一个文档数据库，后来才调整技术路线开始主打 SQL 接口。

本文信息主要来自于 Yugabyte 的官方文档 以及其 GitHub 主页。

系统架构

逻辑上，Yugabyte采用两层架构：查询层和存储层。不过这个架构仅仅是逻辑上的，部署结构中，这两层都位于TServer 进程中。这一点和 TiDB 不同。

Yugabyte 的查询层支持同时 SQL 和 CQL 两种 API，其中 CQL 是兼容Cassandra 的一种方言语法，对应于文档数据库的存储模型；而 SQL API是直接基于 PostgresQL 魔改的，能比较好地兼容 PG语法，据官方说这样可以更方便地跟随 PG新特性，有没有官方说的这么美好我们就不得而知了。

Yugabyte 的存储层才是重头戏。其中 TServer 负责存储 tablet，每个tablet 对应一个 RaftGroup，分布在三个不同的节点上，以此保证高可用性。Master负责元数据管理，除了 tablet 的位置信息，还包括表结构等信息。Master本身也依靠 Raft 实现高可用。

基于 Tablet 的分布式存储

这一部分是 HBase/Spanner 精髓部分，Cockroach/TiDB的做法几乎也是一模一样的。如下图所示，每张表被分成很多个 tablet，tablet是数据分布的最小单元，通过在节点间搬运 tablet 以及 tablet的分裂与合并，就可以实现几乎无上限的 scale out。每个 tablet有多个副本，形成一个 Raft Group，通过 Raft协议保证数据的高可用和持久性，Group Leader 负责处理所有的写入负载，其他Follower 作为备份。

下图是一个例子：一张表被分成 16 个 tablet，tablet 的副本和 Raft Groupleader 均匀分布在各个节点上，分别保证了数据的均衡和负载的均衡。

和其他产品一样，Master 节点会负责协调 tablet的搬运、分裂等操作，保证集群的负载均衡。这些操作是直接基于 Raft Group实现的。这里就不再展开了。

有趣的是，Yugabyte采用哈希和范围结合的分区方式：可以只有哈希分区、也可以只有范围分区、也可以先按哈希再按范围分区。之所以这么设计，猜测也是因为Cassandra 的影响。相比之下，TiDB 和 Cockroach 都只支持范围分区。

哈希分区的方式是将 key 哈希映射到 2 字节的空间中（即0x0000 到0xFFFF），这个空间又被划分成多个范围，比如下图的例子中被划分为16 个范围，每个范围的 key 落在一个 tablet 中。理论上说最多可能有 64K 个tablet，这对实际使用足够了。

哈希分区的好处是插入数据（尤其是从尾部 append数据）时不会出现热点；坏处是对于小范围的范围扫描（例如pk BETWEEN 1 AND 10）性能会比较吃亏。

基于 RocksDB 的本地存储

每个 TServer 节点上的本地存储称为 DocDB。和 TiDB/Cockroach一样，Yugabyte 也用 RocksDB 来做本地存储。这一层需要将关系型 tuple以及文档编码为 key-value 保存到 RocksDB中，下图是对文档数据的编码方式，其中有不少是为了兼容 Cassandra设计的，我们忽略这些，主要关注以下几个部分：

• key 中包含
  • 16-bit hash：依靠这个值才能做到哈希分区
  • 主键数据（对应图中 hash/range columns）
  • column ID：因为每个 tuple 有多个列，每个列在这里需要用一个 key-value来表示
  • hybrid timestamp：用于 MVCC 的时间戳
• value 中包含
  • column 的值

如果撇开文档模型，key-value 的设计很像 Cockroach：每个 cell（一行中的一列数据）对应一个 key-value。而 TiDB 是每个 tuple 打包成一个key-value。个人比较偏好 TiDB 的做法。

分布式事务：2PC & MVCC

和 TiDB/Cockroach 一样，Yugabyte 也采用了 MVCC 结合 2PC的事务实现。

时间戳

时间戳是分布式事务的关键选型之一。Yugabyte 和 Cockroach 一样选择的是Hybrid Logical Clock (HLC)。

HLC 将时间戳分成物理（高位）和逻辑（低位）两部分，物理部分对应 UNIX时间戳，逻辑部分对应 Lamport时钟。在同一毫秒以内，物理时钟不变，而逻辑时钟就和 Lamport时钟一样处理——每当发生信息交换（RPC）就需要更新时间戳，从而确保操作与操作之间能够形成一个偏序关系；当下一个毫秒到来时，逻辑时钟部分归零。

不难看出，HLC 的正确性其实是由 Logical Clock 来保证的：它相比 LogicalClock 只是在每个毫秒引入了一个额外的增量，显然这不会破坏 Logical Clock的正确性。但是，物理部分的存在将原本无意义的时间戳赋予了物理意义，提高了实用性。

个人认为，HLC 是除了 TrueTime以外最好的时间戳实现了，唯一的缺点是不能提供真正意义上的外部一致性，仅仅能保证相关事务之间的“外部一致性”。另一种方案是引入中心授时节点（TSO），也就是TiDB 使用的方案。TSO 方案要求所有事务必须从 TSO获取时间戳，实现相对简单，但引入了更多的网络 RPC，而且 TSO过于关键——短时间的不可用也是极为危险的。

HLC 的实现中有一些很 tricky 的地方，比如文档中提到的 Safetimestamp assignment for a read request。对于同一事务中的多次read，问题还要更复杂，有兴趣的读者可以看 Cockroach 团队的这篇博客 LivingWithout Atomic Clocks。

事务提交

毫不惊奇，Yugabyte 的分布式事务同样是基于 2PC 的。他的做法接近Cockroach。事务提交过程中，他会在 DocDB存储里面写入一些临时的记录（provisionalrecords），包括以下三种类型：

• Primary provisionalrecords：还未提交完成的数据，多了一个事务ID，也扮演锁的角色
• Transaction metadata：事务状态所在的 tabletID。因为事务状态表很特殊，不是按照 hash key分片的，所以需要在这里记录一下它的位置。
• Reverse Index：所有本事务中的 primary provisionalrecords，便于恢复使用

事务的状态信息保存在另一个 tablet上，包括三种可能的状态：Pending、Committed 或 Aborted。事务从 Pending状态开始，终结于 Committed 或 Aborted。

事务状态就是 Commit Point 的那个“开关”，当事务状态切换到 Commited的一瞬间，就意味着事务的成功提交。这是保证整个事务原子性的关键。

完整的提交流程如下图所示：

另外，Yugabyte 文档中提到它除了 Snapshot Isolation 还支持Serializable 隔离级别，但是似乎没有看到他是如何规避 Write Skew问题的。从 Release Notes 看来这应该是 2.0 GA中新增加的功能，等更多信息放出后再研究吧！

竞品对比

以下表格摘自 Compare YugabyteDBto other databases：

References

1. Yugabyte DB
2. Yugabyte DB Documents
3. LivingWithout Atomic Clocks - Cockroach Labs

在过去很长一段时间内，HotSpot JVM 的首选垃圾收集器都是 ParNew + CMS组合。直到 JDK7 中 Hotspot 团队首次公布了 G1（Garbage-First），并在 JDK9中用 G1 作为默认的垃圾收集器。我们团队最近也将用了很多年的 CMS 换成了 G1垃圾收集器。

本文主要从 G1 的论文 Garbage-FirstGarbage Collection 出发，结合其他较新的白皮书等，讲解 G1垃圾收集器的工作原理。

Motivation

关于为什么要重新设计一个 G1垃圾收集器，论文中给出的理由相当简单：现有的垃圾收集器无法满足软实时（SoftReal-time）特性：即让 GC停顿能大致控制在某个阈值以内，但是又不必像实时系统那样非常严格。这也是很多业务系统都有的诉求。

在过去的 JVM 设计中，如下图所示，堆内存被分割成几个区域 ——Eden、Survivor、Old 的大小都是预先划分好的。对于总内存 64GB 的机器，可能Old 区大小就有32GB，即使用并行的方式收集一次仍然需要数秒。近十年，随着内存越来越大，这一问题也变得更为严重。

为了达到软实时的目标，同时也是为了更好地应对大内存，G1将中不再使用上述的内存布局。

基本数据结构

首先，我们介绍 G1 种最核心的两个概念：Region 和 Remember Set。

Heap Regions

如下图所示，G1 垃圾收集器将堆内存空间分成等分的Regions，物理上不一定连续，逻辑上构成连续的堆地址空间。各个 Mutator线程（即用户应用的线程）拥有各自的 Thread-Local Allocation Buffer(TLAB），用于降低各个线程分配内存的冲突。

要特别注意的是，巨型对象（HumongousObject），即大小超过 3/4 的 Region大小的对象会作特殊处理，分配到由一个或多个连续 Region构成的区域。巨型对象会引起其他一些问题，不过这些已经超出了本文的范畴，总之记得尽量别用就好了。

默认配置下，在满足 Region Size 是 2 的整数幂的前提下，G1将总内存尽量划分成大约 2048 个 Region。

Remember Set (RSet)

为什么要把堆空间分成 Region 呢？其主要目的是让各个 Region相对独立，可以分别进行GC，而不是一次性地把所有垃圾收集掉。我们知道现代 GC算法都是基于可达性标记，而这个过程必须遍历所有 Live Objects才能完成。那问题来了，如果为了收集一个 Region 的垃圾，却完整的遍历所有Live Objects，这也太浪费了！

所以，我们需要一个机制来让各个 Region 能独立地进行垃圾收集，这也就是Remember Set 存在的意义。每个 Region 会有一个对应的 RememberSet，它记录了哪些内存区域中存在对当前 Region中对象的引用。（all locations that might contain pointersto (live) objects within the region）

注意 Remember Set 不是直接记录对象地址，而是记录了那些对象所在的 Card编号。所谓 Card 就是表示一小块（512bytes）的内存空间，这里面很可能存在不止一个对象。但是这已经足够了：当我们需要确定当前Region有哪些对象存在外部引用时（这些对象是可达的，不能被回收），只要扫描一下这块Card 中的所有对象即可，这比扫描所有 live objects 要容易的多。

实现上，Remember Set 的实现就是一个 Card 的 Hash Set，并且为每个 GC线程都有一个本地的 Hash Set，最后的 Remember Set 实际上是这些 Hash Set的并集。当 Card 数量特别多的时候会退化到 Region粒度，这时候就要扫描更多的区域来寻找引用，时间换空间。

Remember Set 的维护

维护上面所说的 Remember Set 势必需要记录对象的引用，通常的做法是在set 一个引用的时候插入一段代码，这称为 Write Barrier。为了尽可能降低对Mutator 线程的影响，Write Barrier 的代码应当尽可能简化。G1 的 WriteBarrier 实际上只是一个“通知”：将当前 set 引用的事件放到 Remember Set Log队列中，交给后台专门的 GC 线程处理。

Write Barrier 具体实现如下。当发生 X.f = Y 时，假设rX 为 X 对象的地址，rY 为 Y 对象的地址，则Write 的同时还会执行以下逻辑：

1
2
3

t = (rX XOR rY) >> LogOfRegionSize  // 对 X, Y 地址右移得到 Region 编号，并将二者做个 XOR
if (rY == NULL ? 0 : t)  // 忽略两种情况： X.f 被赋值为 NULL，或 X 和 Y 位于同一个 Region 内
   rs_enqueue(rX)        // 如果 Card(X) 还不是 dirty 的，将 X 的地址放进 Log，并把该 card 置为 dirty

这里 Dirty Bit 的作用是去除重复的 Cards，考虑到一个 Cards内经常发生密集的引用赋值（比如对象初始化），去重一下能大幅减少冗余。

最后，后台的 GC 线程则负责从 Remember Set Log不断取出这些引用赋值发生的 Cards，扫描上面所有的对象，然后更新相应Region 的 Remember Set。在并发标记发生之前，G1 会确保 Remember Set Log中的记录都处理完，从而保证并发标记算法一定能拿到最新的、正确的 RememberSet。

极端情况下，如果后台的 GC 进程追不上 Mutator 进程写入的速度，这时候Mutator 线程会退化到自己处理更新，形成反压机制。

Generational Garbage-First

G1 名字来自于 Garbage-First这个理念，即，以收集到尽可能多的垃圾为第一目标。每次收集时G1 会选出垃圾最多的几个 Region，进行一次 Stop-the-world 的收集过程。

有趣的是，另一方面 G1 又是一个 Generational（分代）的垃圾收集器，它会从逻辑上将 Region 分成 Young、Old 等不同的Generation，然后针对它们各自特点应用不同的策略。

G1 论文中提到它有一个 Pure Garbage-First的模式，但在现在的资料中已经很难看到它的踪影，我猜测实际使用中Generational 模式要效果好的多。以下我们也会只讨论 Generational模式的工作方式。

经典的内存布局中，各代的内存区域是完全分开的，而 G1 中的 Generation只是 Region 的一个动态标志，下图是一个标记了 Generation 的例子。各个Region 的 Generation 是随着 GC 的进行而不断变化的，甚至各个代有多少Region 这个比例也是随时调整的。

Evacuation

为了方便读者理解 G1 收集的过程，我们先看下 Evacuation的过程，之后再看如何做 Marking。

Generational 模式下 G1 的垃圾收集分为两种：Young GC 和 MixedGC。Young GC 只会涉及到 Young Regions，它将 Eden Region中存活的对象移动到一个或多个新分配的 Survivor Region，之前的 Eden Region就被归还到 Free list，供以后的新对象分配使用。

当区域中对象的 Survive次数超过阈值（TenuringThreshold）时，Survivor Regions的对象被移动到 Old Regions；否则和 Eden 的对象一样，继续留在 SurvivorRegions 里。

多次 Young GC 之后，Old Regions慢慢累积，直到到达阈值（InitiatingHeapOccupancyPercent，简称IHOP），我们不得不对 Old Regions 做收集。这个阈值在 G1中是根据用户设定的 GC 停顿时间动态调整的，也可以人为干预。

对 Old Regions 的收集会同时涉及若干个 Young 和 OldRegions，因此被称为 Mixed GC。Mixed GC 很多地方都和Young GC 类似，不同之处是：它还会选择若干最有潜力的 OldRegions（收集垃圾的效率最高的 Regions），这些选出来要被 Evacuate 的Region 称为本次的 Collection Set (CSet)。

Mixed GC 的重要性不言而喻：Old Regions的垃圾就是在这个阶段被收集掉的，也正是因为这样，Mixed GC是工作量最为繁重的一个环节，如果不加以控制，就会像 CMS 一样发生长时间的Full GC 停顿。这时候 Region 的设计就发挥出优越性了：只要把每次的Collection Set 规模控制在一定范围，就能把每次收集的停顿时间软性地控制在MaxGCPauseMillis 以内。起初这个控制可能不太精准，随着 JVM的运行估算会越来越准确。

那来不及收集的那些 Region 呢？多来几次就可以了。所以你在 GC日志中会看到 continue mixed GCs的字样，代表分批进行的各次收集。这个过程会多次重复，直到垃圾的百分比降到G1HeapWastePercent 以内，或者到达G1MixedGCCountTarget 上限。

对于 Young Regions，我们对它有以下特殊优化：

1. Evacuation 的时候，Young Regions 一定会被放到待收集的 Regions集合（Collection Set）中，原因很简单，绝大多数对象寿命都很短，在 YoungRegions 做收集往往绝大部分都是垃圾。
2. 由于 Young Regions 一定会被收集，我们获得了一个可观的收益：RememberSet 的维护工作不需要考虑 Young 内的引用修改（换句话说 RSet 只关心old-to-young 和 old-to-old 的引用），当 Young Region 上发生 Evacuation时我们再去扫描并构建出它的 RSet 即可。

Concurrent Marking

在 Evacuation之前，我们要通过并发标记来确定哪些对象是垃圾、哪些还活着。G1 中的Concurrent Marking 是以 Region为单位的，为了保证结果的正确性，这里用到了Snapshot-at-the-beginning（SATB）算法。

SATB 算法顾名思义是对 Marking 开始时的一个（逻辑上的）Snapshot进行标记。为什么要用 Snapshot呢？下面就是一个直接标记导致问题的例子：对象 X由于没有被标记到而被标记为垃圾，导致 B 引用失效。

如果只是对现场情况做标记，可能会漏掉某些对象

SATB 算法为了解决这一问题，在修改引用 X.f = B之前插入了一个 WriteBarrier，记录下被覆写之前的引用地址。这些地址最终也会被 Marking线程处理，从而确保了所有在 Marking 开始时的引用一定会被标记到。这个Write Barrier 伪代码如下：

1
2
3

t = the previous referenced address  // 记录原本的引用地址
if (t has been marked && t != NULL)  // 如果地址 t 还没来的及标记，且 t 不为 NULL
    satb_enqueue(t) // 放到 SATB 的待处理队列中，之后会去扫描这个引用

通过以上措施，SATB 确保 Marking 开始时存活的对象一定会被标记到。

标记的过程和 CMS 中是类似的，可以看作一个优化版的DFS：记当前已经标记到的 offset 为 cur，随着标记的进行 cur不断向后推进。每当访问到地址 < cur的对象，就对它做深度扫描，递归标记所有应用；反之，对于地址 > cur的对象，只标记不扫描，等到 cur 推进到那边的时候再去做扫描。

上图中，假设当前 cur 指向对象 c，c有两个引用：a 和 e，其中 a的地址小于 cur，因而做了扫描；而 e 则仅仅是标记。扫描 a的过程中又发现了对象 b，b 同样被标记并继续扫描。但是 b 引用的 d 在 cur之后，所以 d 仅仅是被标记，不再继续扫描。

最后一个问题是：如何处理 Concurrent Marking 中新产生的对象？因为 SATB算法只保证能标记到开始时 snapshot的对象，对于新出现的那些对象，我们可以简单地认为它们全都是存活的，毕竟数量不是很多。

References

1. Detlefs, David, et al Garbage-First GarbageCollection. Proceedings of the 4th international symposium onMemory management. ACM, 2004.
2. Printezis, Tony, and David Detlefs. A GenerationalMostly-Concurrent Garbage Collector. Vol. 36. No. 1. ACM,2000.
3. MemoryManagement in the Java HotSpot™ Virtual Machine (2006)
4. Introductionto the G1 Garbage Collector - Matt Robson - RedHat
5. Collectingand reading G1 garbage collector logs - Matt Robson - RedHat
6. GarbageFirst Garbage Collector (G1 GC): Current and Future Adaptability andErgonomics - Monica Beckwith - Slideshare
7. 详解 JVMGarbage First(G1) 垃圾收集器 - coderlius - CSDN

本文翻译自 Javadoccoding standards - Stephen Colebourne's blog

Javadoc 是 Java编程中很重要的一部分，然而却很少有人谈论如何去写好一个的Javadoc。如果想写好 Javdoc，首先最好有一份代码规范。

Javadoc 代码规范

我之前尝试过一些 Javadoc的标准。考虑到每个人喜好不同，我这里只想谈谈最基本的一些原则，不去涉及方方面面的细节。另外，我们只讨论Javadoc 的格式，其内容不在本文范围之内。

这里有一份 Oracle家的指南 要比本文详细的多，不过大部份要求都是一致的。

以下所有条目我都尽可能说的简明，并用一些例子去阐述。

让 Javadoc 像代码一样可读

当你听到 “Javadoc” 这个词的时候，你首先想到的可能是 Javadoc 生成的HTML网页，然而实际情况绝非如此。多数情况下，其他人都是在看源代码的时候用到这些Javadoc，比如你看同事的代码、或是研究第三方库的代码。时刻记住：让Javadoc 像 Java 代码一样保持可读性。

Public 和 Protected

所有 Public 和 Protected 方法都应当有相应的 Javadoc。Package 和Private 方法不强求，但是如果有帮助的话加上也很好。

如果子类覆盖了父类中的某个方法，一般来说不需要Javadoc，除非这个覆盖的实现和原有的差别很大，这时候需要用 Javadoc说明差异的那部分。@Override注解不仅标记了方法覆盖，另一方面也是暗示读者要参考原来方法上的文档一起看。

使用标准的 Javadoc 风格注释

Javadoc 以 /** 开头、以 */结尾，并且每行要以星号开头：

1
2
3
4
5
6
7

/**
 * Standard comment.
 */
public ...

/** Compressed comment. */
public ...

注意别用 **/ 作结尾。

用简单的 HTML tags 就行了，不需要 XHTML

Javadoc 用 HTML tags 来识别段落、列表等等。很多开发者可能觉得 XHTML（HTML的一种“严格版本”）会更好，其实不然。XHTML 常常会多出一些tag，这会导致代码变得更复杂了，可读性更差。

此外，Javadoc 的 parser 其实会帮你把没闭合的 tags自动闭合的，别担心。

用单个 <p> 来分割段落

Javadoc经常会需要分成好几段。所以问题来了：怎样优雅地加上段落标记？答案是，在两段之间写上一行<p> 就可以了，不用加 </p>闭合它。

1
2
3
4
5
6
7
8
9

/**
 * First paragraph.
 * <p>
 * Second paragraph.
 * May be on multiple lines.
 * <p>
 * Third paragraph.
 */
public ...

用单个 <li> 来标记列表项

列表在 Javadoc中也很常用，比如用来表示一组选项、一些问题等等。推荐的做法是用一个<li>作为每项的开头，同样不需要闭合。此外，别忘了加段落 tag：

1
2
3
4
5
6
7
8
9
10

/**
 * First paragraph.
 * <p><ul>
 * <li>the first item
 * <li>the second item
 * <li>the third item
 * </ul><p>
 * Second paragraph.
 */
public ...

首句很重要

Javadoc 的首句（用英文句号结束）也被作为这个 Javadoc的摘要，在折叠的时候只会显示这一句。因此首句必须是个总结性的描述，它最好简洁有力，不能太长。

虽然没有强制要求，我们建议首句自成一个段落，这让代码看起来更清晰。

对于英文注释，推荐使用第三人称来描述，比如 “Gets the foo”、“Sets thebar”、“Consumes the baz”。避免使用第二人称，比如 “Get the foo”。

用 “this” 指代类的对象

当你想描述这个类的一个实例（对象）的时候，用 “this” 来指代它，比如“Returns a copy of this foo with the bar value updated”

别写太长的句子

尽量让一句话能容纳在一行中，一般来说一行有 80 到 120 个字符。

新的句子就另起一行，这会让代码可读性更好，也会让以后改写 Javadoc容易很多。

1
2
3
4
5
6
7
8
9
10

/**
 * This is the first paragraph, on one line.
 * <p>
 * This is the first sentence of the second paragraph, on one line.
 * This is the second sentence of the second paragraph, on one line.
 * This is the third sentence of the second paragraph which is a bit longer so has been
 * split onto a second line, as that makes sense.
 * This is the fourth sentence, which starts a new line, even though there is space above.
 */
public ...

正确使用 @link 和 @code

很多地方的描述需要涉及到其他类或方法，这时最好用 @link 和 @code。

@link会最终变成一个超链接，它有以下几种形式：

1
2
3
4
5
6
7
8
9
10

/**
 * First paragraph.
 * <p>
 * Link to a class named 'Foo': {@link Foo}.
 * Link to a method 'bar' on a class named 'Foo': {@link Foo#bar}.
 * Link to a method 'baz' on this class: {@link #baz}.
 * Link specifying text of the hyperlink after a space: {@link Foo the Foo class}.
 * Link to a method handling method overload {@link Foo#bar(String,int)}.
 */
public ...

@code用来标记一小段等宽字体，也可以用来标记某个类或方法，但不会生成超链接。

建议在第一次提到某个类或方法的时候用 @link，此后直接用 @code 即可。

不要在首句中使用 @link

之前提到，Javadoc的首句也被用作概要，首句中的超链接会让读者感到混乱。如果一定要在第一句话中引用其它类或方法，始终用@code 而不是 @link，第二句开始再用 @link。

null、true、false 不必用 @code 标记

null、true、false 这些词在 Javadoc 中太常用了，如果每次都加上 @code，无论是对读者还是作者都是个负担。

使用 @param、@return 和 @throws

几乎所有方法都会输入几个参数、输出一个结果，@param 和 @return 就是用来描述这些输入输出参数的，@throws用于描述方法抛出的异常。

如果有多个输入参数，@param 的顺序也要和参数一致。@return 应当始终放在 @param 之后，然后才是 @throws。

为范型参数加上 @param

如果一个类或方法有范型参数（例如<T>），这些参数也应当被文档化，推荐的做法是给<T> 也加上一个 @param 说明。

在 @param之前空一行

始终在 Javadoc 的内容和 @param、@return之间留个空行，这让代码的可读性更佳。

用短语来描述 @param 和 @return

@param 和 @return后面跟的的描述是个短语，而非完整的句子，因此它得用小写字母开头（经常是the），结尾也不需要用句号。

用 if-句来描述 @throws

@throws通常跟着一个 “if” 句子来描述抛异常的情形，比如 “@throws IllegalArgumentException if the filecould not be found”。

@param的参数名之后空两格

在源代码中阅读 Javadoc的时候，如果参数名后面只有一个空格，读起来会有点困难，两个空格就好很多。另外，避免把参数按列对齐，否则参数改名、增减参数的时候会很麻烦。

1
2
3
4
5
6
7
8

/**
 * Javadoc text.
 * 
 * @param foo  the foo parameter
 * @param bar  the bar parameter
 * @return the baz content
 */
public String process(String foo, String bar) {...}

写明各参数和返回值的 null 行为

一个方法是否接受 null、会不会返回 null对于其他开发者是十分重要的信息。除非是原始类型，@param 和 @return 都应该注明它是否接受或返回null。以下标准若适用请务必遵循：

• “not null” 表明不接受 null，若输入 null 可能导致异常，例如NullPointerException
• “may be null” 表明可以传入 null 参数
• “null treated as xxx” 表明 null 值等价于某个值
• “null returns xxx” 表明如果输入 null 则一定会返回某个值

定义清楚这些之后，不要再为 NullPointerException 写@throws。

1
2
3
4
5
6
7
8

/**
 * Javadoc text.
 * 
 * @param foo  the foo parameter, not null
 * @param bar  the bar parameter, null returns null
 * @return the baz content, null if not processed
 */
public String process(String foo, String bar) {...}

有人可能想在某个地方（像是类或包的 Javadoc）集中定义 null相关行为，但我们不建议你这么做，因为这对别人并没有帮助。方法上的 Javadoc很容易就能看到，而类或包层级的 Javadoc 要去翻一遍才能找到。

其他简单的约束条件也建议写到 Javadoc 里，比如 “not empty, notnull”。原始类型也可以加上边界约束，比如 “from 1 to 5” 或 “notnegative”

给 Specification 加上 implementation notes

如果某个接口允许第三方来实现，而你为这个接口写了个正式的规格说明（specification），这时候考虑加个“implementation notes” 章节。这通常出现在类的 Javadoc上，用于描述一些不太好写在特定方法上的东西，或者一些其他人不感兴趣的东西。参考这个例子。

不要用 @author

@author用来标记类的作者，这个功能已经过时了，不要用。版本控制系统（例如git）会记住作者的。

例子

这个 ThreeTen项目里有一些更完整的例子

总结

希望这些建议能帮你写出更好的Javadoc。当然，这只是一份建议，你也可以选择其他标准来参考。

窗口函数（Window Function）是 SQL2003标准中定义的一项新特性，并在 SQL2011、SQL2016中又加以完善，添加了若干处拓展。窗口函数不同于我们熟悉的普通函数和聚合函数，它为每行数据进行一次计算：输入多行（一个窗口）、返回一个值。在报表等分析型查询中，窗口函数能优雅地表达某些需求，发挥不可替代的作用。

本文首先介绍窗口函数的定义及基本语法，之后将介绍在 DBMS和大数据系统中是如何实现高效计算窗口函数的，包括窗口函数的优化、执行以及并行执行。

什么是窗口函数？

窗口函数出现在 SELECT 子句的表达式列表中，它最显著的特点就是OVER 关键字。语法定义如下：

1
2
3
4

window_function (expression) OVER (
   [ PARTITION BY part_list ]
   [ ORDER BY order_list ]
   [ { ROWS | RANGE } BETWEEN frame_start AND frame_end ] )  

其中包括以下可选项：

• PARTITION BY 表示将数据先按 part_list进行分区
• ORDER BY 表示将各个分区内的数据按order_list 进行排序

最后一项表示 Frame 的定义，即：当前窗口包含哪些数据？

• ROWS 选择前后几行，例如ROWS BETWEEN 3 PRECEDING AND 3 FOLLOWING 表示往前 3行到往后 3 行，一共 7 行数据（或小于 7 行，如果碰到了边界）
• RANGE 选择数据范围，例如RANGE BETWEEN 3 PRECEDING AND 3 FOLLOWING 表示所有值在\([c-3,c+3]\) 这个范围内的行，\(c\) 为当前行的值

逻辑语义上说，一个窗口函数的计算“过程”如下：

1. 按窗口定义，将所有输入数据分区、再排序（如果需要的话）
2. 对每一行数据，计算它的 Frame 范围
3. 将 Frame 内的行集合输入窗口函数，计算结果填入当前行

举个例子：

1
2
3
4

SELECT dealer_id, emp_name, sales,
       ROW_NUMBER() OVER (PARTITION BY dealer_id ORDER BY sales) AS rank,
       AVG(sales) OVER (PARTITION BY dealer_id) AS avgsales 
FROM sales

上述查询中，rank列表示在当前经销商下，该雇员的销售排名；avgsales表示当前经销商下所有雇员的平均销售额。查询结果如下：

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

+------------+-----------------+--------+------+---------------+
| dealer_id  | emp_name        | sales  | rank | avgsales      |
+------------+-----------------+--------+------+---------------+
| 1          | Raphael Hull    | 8227   | 1    | 14356         |
| 1          | Jack Salazar    | 9710   | 2    | 14356         |
| 1          | Ferris Brown    | 19745  | 3    | 14356         |
| 1          | Noel Meyer      | 19745  | 4    | 14356         |
| 2          | Haviva Montoya  | 9308   | 1    | 13924         |
| 2          | Beverly Lang    | 16233  | 2    | 13924         |
| 2          | Kameko French   | 16233  | 3    | 13924         |
| 3          | May Stout       | 9308   | 1    | 12368         |
| 3          | Abel Kim        | 12369  | 2    | 12368         |
| 3          | Ursa George     | 15427  | 3    | 12368         |
+------------+-----------------+--------+------+---------------+

注：语法中每个部分都是可选的：

• 如果不指定PARTITION BY，则不对数据进行分区；换句话说，所有数据看作同一个分区
• 如果不指定ORDER BY，则不对各分区做排序，通常用于那些顺序无关的窗口函数，例如SUM()
• 如果不指定 Frame 子句，则默认采用以下的 Frame 定义：
  • 若不指定 ORDER BY，默认使用分区内所有行RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING
  • 若指定了 ORDER BY，默认使用分区内第一行到当前值RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW

最后，窗口函数可以分为以下 3 类：

• 聚合（Aggregate）：AVG(),COUNT(), MIN(), MAX(),SUM()...
• 取值（Value）：FIRST_VALUE(),LAST_VALUE(), LEAD(),LAG()...
• 排序（Ranking）：RANK(),DENSE_RANK(), ROW_NUMBER(),NTILE()...

受限于篇幅，本文不去探讨各个窗口函数的含义，有兴趣的读者可以参考这篇文档。

注：Frame 定义并非所有窗口函数都适用，比如ROW_NUMBER()、RANK()、LEAD()等。这些函数总是应用于整个分区，而非当前 Frame。

窗口函数 VS. 聚合函数

从聚合这个意义上出发，似乎窗口函数和 Group By聚合函数都能做到同样的事情。但是，它们之间的相似点也仅限于此了！这其中的关键区别在于：窗口函数仅仅只会将结果附加到当前的结果上，它不会对已有的行或列做任何修改。而Group By 的做法完全不同：对于各个 Group 它仅仅会保留一行聚合结果。

有的读者可能会问，加了窗口函数之后返回结果的顺序明显发生了变化，这不算一种修改吗？因为SQL 及关系代数都是以 multi-set为基础定义的，结果集本身并没有顺序可言，ORDER BY仅仅是最终呈现结果的顺序。

另一方面，从逻辑语义上说，SELECT语句的各个部分可以看作是按以下顺序“执行”的：

注意到窗口函数的求值仅仅位于 ORDER BY 之前，而位于 SQL的绝大部分之后。这也和窗口函数只附加、不修改的语义是呼应的——结果集在此时已经确定好了，再依此计算窗口函数。

窗口函数的执行

窗口函数经典的执行方式分为排序和函数求值这2 步。

窗口定义中的 PARTITION BY 和 ORDER BY都很容易通过排序完成。例如，对于窗口PARTITION BY a, b ORDER BY c, d，我们可以对输入数据按 \((a, b, c, d)\) 或 \((b, a, c, d)\) 做排序，之后数据就排列成Figure 1 中那样了。

接下来考虑：如何处理 Frame？

• 对于整个分区的 Frame（例如RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING），只要对整个分区计算一次即可，没什么好说的；
• 对于逐渐增长的 Frame（例如RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW），可以用Aggregator 维护累加的状态，这也很容易实现；
• 对于滑动的 Frame（例如ROWS BETWEEN 3 PRECEDING AND 3 FOLLOWING）相对困难一些。一种经典的做法是要求Aggregator不仅支持增加还支持删除（Removable），这可能比你想的要更复杂，例如考虑下MAX() 的实现。

窗口函数的优化

对于窗口函数，优化器能做的优化有限。这里为了行文的完整性，仍然做一个简要的说明。

通常，我们首先会把窗口函数从 Project中抽取出来，成为一个独立的算子称之为 Window。

有时候，一个 SELECT语句中包含多个窗口函数，它们的窗口定义（OVER子句）可能相同、也可能不同。显然，对于相同的窗口，完全没必要再做一次分区和排序，我们可以将它们合并成一个Window 算子。

对于不同的窗口，最朴素地，我们可以将其全部分成不同的Window，如上图所示。实际执行时，每个 Window都需要先做一次排序，代价不小。

那是否可能利用一次排序计算多个窗口函数呢？某些情况下，这是可能的。例如本文例子中的2 个窗口函数：

1
2

... ROW_NUMBER() OVER (PARTITION BY dealer_id ORDER BY sales) AS rank,
    AVG(sales) OVER (PARTITION BY dealer_id) AS avgsales ...

虽然这 2 个窗口并非完全一致，但是 AVG(sales)不关心分区内的顺序，完全可以复用 ROW_NUMBER() 的窗口。这篇论文提供了一种启发式的算法，能尽可能利用能够复用的机会。

窗口函数的并行执行 *

现代 DBMS大多支持并行执行。对于窗口函数，由于各个分区之间的计算完全不相关，我们可以很容易地将各个分区分派给不同的节点（线程），从而达到分区间并行。

但是，如果窗口函数只有一个全局分区（无 PARTITION BY子句），或者分区数量很少、不足以充分并行时，怎么办呢？上文中我们提到的Removable Aggregator 的技术显然无法继续使用了，它依赖于单个 Aggregator的内部状态，很难有效地并行起来。

TUM 的这篇论文中提出使用线段树（SegmentTree）实现高效的分区内并行。线段树是一个 N叉树数据结构，每个节点包含当前节点下的部分聚合结果。

下图是一个使用二叉线段树计算 SUM()的例子。例如下图中第三行的 \(12\)，表示叶节点 \(5+7\) 的聚合结果；而它上方的 \(25\) 表示叶节点 \(5+7+3+10\) 的聚合结果。

假设当前 Frame 是第 2 到第 8 行，即需要计算 \(7+3+10+...+4\)区间之和。有了线段树以后，我们可以直接利用 \(7+13+20\)（图中红色字体）计算出聚合结果。

线段树可以在 \(O(n\log{n})\)时间内构造，并能在 \(O(\log{n})\)时间内查询任意区间的聚合结果。更棒的是，不仅查询可以多线程并发互不干扰，而且线段树的构造过程也能被很好地并行起来。

References

1. EfficientProcessing of Window Functions in Analytical SQL Queries - Leis, Viktor,et al. (VLDB'15)
2. Optimizationof Analytic Window Functions - Cao, Yu, et al. (VLDB'12)
3. SQLWindow Functions Introduction - Apache Drill
4. PostgreSQL 11Reestablishes Window Functions Leadership
5. WindowFunctions in SQL Server

子查询（Subquery）的优化一直以来都是 SQL查询优化中的难点之一。关联子查询的基本执行方式类似于Nested-Loop，但是这种执行方式的效率常常低到难以忍受。当数据量稍大时，必须在优化器中对其进行去关联化（Decoorelation或 Unnesting），将其改写为类似于 Semi-Join 这样的更高效的算子。

前人已经总结出一套完整的方法论，理论上能对任意一个查询进行去关联化。本文结合SQL Server 以及 HyPer的几篇经典论文，由浅入深地讲解一下这套去关联化的理论体系。它们二者所用的方法大同小异，基本思想是想通的。

本文的例子都基于 TPC-H 的表结构，这里有一份供你参考。

子查询简介

子查询是定义在 SQL 标准中一种语法，它可以出现在 SQL的几乎任何地方，包括 SELECT, FROM, WHERE 等子句中。

总的来说，子查询可以分为关联子查询（CorrelatedSubquery）和非关联子查询（Non-correlatedSubquery）。后者非关联子查询是个很简单的问题，最简单地，只要先执行它、得到结果集并物化，再执行外层查询即可。下面是一个例子：

1
2
3
4
5
6
7
8
9
10

SELECT c_count, count(*) AS custdist
FROM (
     SELECT c_custkey, count(o_orderkey) AS c_count
     FROM CUSTOMER
     LEFT OUTER JOIN ORDERS ON c_custkey = o_custkey
     AND o_comment NOT LIKE '%pending%deposits%'
     GROUP BY c_custkey
     ) c_orders
GROUP BY c_count
ORDER BY custdist DESC, c_count DESC;

▲ TPCH-13 是一个非关联子查询

非关联子查询不在本文讨论范围之列，除非特别声明，以下我们说的子查询都是指关联子查询。

关联子查询的特别之处在于，其本身是不完整的：它的闭包中包含一些外层查询提供的参数。显然，只有知道这些参数才能运行该查询，所以我们不能像对待非关联子查询那样。

根据产生的数据来分类，子查询可以分成以下几种：

标量（Scalar-valued）子查询：输出一个只有一行一列的结果表，这个标量值就是它的结果。如果结果为空（0行），则输出一个 NULL。但是注意，超过 1行结果是不被允许的，会产生一个运行时异常。

标量子查询可以出现在任意包含标量的地方，例如 SELECT、WHERE等子句里。下面是一个例子：

SELECT c_custkeyFROM CUSTOMERWHERE 1000000 < (    SELECT SUM(o_totalprice)    FROM ORDERS    WHERE o_custkey = c_custkey)

▲ Query 1: 一个出现在 WHERE 子句中的标量子查询，关联参数用红色字体标明了

SELECT o_orderkey, (    SELECT c_name    FROM CUSTOMER    WHERE c_custkey = o_custkey) AS c_name FROM ORDERS

▲ Query 2: 一个出现在 SELECT 子句中的标量子查询

存在性检测（Existential Test）子查询：特指 EXISTS的子查询，返回一个布尔值。如果出现在 WHERE 中，这就是我们熟悉的Semi-Join。当然，它可能出现在任何可以放布尔值的地方。

SELECT c_custkeyFROM CUSTOMERWHERE c_nationkey = 86 AND EXISTS(    SELECT * FROM ORDERS    WHERE o_custkey = c_custkey)

▲ Query 3: 一个 Semi-Join 的例子

集合比较（Quantified Comparision）子查询：特指IN、SOME、ANY的查询，返回一个布尔值，常用的形式有：x = SOME(Q) （等价于x IN Q）或 X <> ALL(Q)（等价于x NOT IN Q）。同上，它可能出现在任何可以放布尔值的地方。

SELECT c_nameFROM CUSTOMERWHERE c_nationkey <> ALL (SELECT s_nationkey FROM SUPPLIER)

▲ Query 4: 一个集合比较的非关联子查询

原始执行计划

我们以 Query 1为例，直观地感受一下，为什么说关联子查询的去关联化是十分必要的。

下面是 Query 1 的未经去关联化的原始查询计划（RelationTree）。与其他查询计划不一样的是，我们特地画出了表达式树（ExpressionTree），可以清晰地看到：子查询是实际上是挂在 Filter的条件表达式下面的。

实际执行时，查询计划执行器（Executor）在执行到 Filter时，调用表达式执行器（Evaluator）；由于这个条件表达式中包含一个标量子查询，所以Evaluator 又会调用 Executor 计算标量子查询的结果。

这种 Executor - Evaluator - Executor的交替调用十分低效！考虑到 Filter上可能会有上百万行数据经过，如果为每行数据都执行一次子查询，那查询执行的总时长显然是不可接受的。

Apply 算子

上文说到的 Relation - Expression - Relation这种交替引用不仅执行性能堪忧，而且，对于优化器也是个麻烦的存在——我们的优化规则都是在匹配并且对Relation 进行变换，而这里的子查询却藏在 Expression里，令人无从下手。

为此，在开始去关联化之前，我们引入 Apply 算子：

Apply 算子（也称作 CorrelatedJoin）接收两个关系树的输入，与一般 Join 不同的是，Apply 的 Inner输入（图中是右子树）是一个带有参数的关系树。

Apply 的含义用下图右半部分的集合表达式定义：对于 Outer Relation \(R\) 中的每一条数据 \(r\)，计算 Inner Relation \(E(r)\)，输出它们连接（Join）起来的结果\({r} \otimes E(r)\)。Apply的结果是所有这些结果的并集（本文中说的并集指的是 Bag语义下的并集，也就是 UNION ALL）。

Apply 是 SQL Server 的命名，它在 HyPer 的文章中叫做 CorrelatedJoin。它们是完全等价的。考虑到 SQL Server的文章发表更早、影响更广，本文中都沿用它的命名。

根据连接方式（\(\otimes\)）的不同，Apply 又有 4种形式：

• Cross Apply \(A^{\times}\)：这是最基本的形式，行为刚刚我们已经描述过了；
• Left Outer Apply \(A^{LOJ}\)：即使 \(E(r)\) 为空，也生成一个 \(r \circ \{NULLs\}\)。
• Semi Apply \(A^{\exists}\)：如果 \(E(r)\) 不为空则返回 \(r\)，否则丢弃；
• Anti-Semi Apply \(A^{\nexists}\)：如果 \(E(r)\) 为空则返回 \(r\)，否则丢弃；

我们用刚刚定义的 Apply 算子来改写之前的例子：把子查询从 Expression内部提取出来。结果如下：

上面的例子中，我们可以肯定 Scalar Agg子查询有且只有一行结果，所以可以直接转成Apply。但某些情况下，可能无法肯定子查询一定能返回 0 或 1行结果（例如，想象一下 Query 2 如果 c_custkey 不是唯一的），为了确保 SQL语义，还要在 Apply 右边加一个 \(\textit{Max1Row}\) 算子：

\[\textit{Max1Row}(E)=\begin{cases} \textit{Null}, & \text{if}\ |E|=0 \\ E, & \text{if}\ |E|=1 \\ \textit{error}, & \text{otherwise}\end{cases}\]

理论上，我们可以将所有的子查询转换成 Apply算子，一个通用的方法如下：

1. 如果某个算子的表达式中出现了子查询，我们就把这个子查询提取到该算子下面（留下一个子查询的结果变量），构成一个\(A^{LOJ}\)算子。如果不止一个子查询，则会产生多个 \(A^{LOJ}\)。必要的时候加上 \(\textit{Max1Row}\) 算子。
2. 然后应用其他一些规则，将 \(A^{LOJ}\) 转换成 \(A^{\times}\)、\(A^{\exists}\)、\(A^{\nexists}\)。例如上面例子中的子查询结果\(X\) 被用作 Filter 的过滤条件，NULL值会被过滤掉，因此可以安全地转换成 \(A^{\times}\)。

下面这个例子中，Filter 条件表达式中包含 \(Q_1\)、\(Q_2\) 两个子查询。转换之后分别生成了对应的Apply 算子。其中 \(Q_2\)无法确定只会生成恰好一条记录，所以还加上了 \(\textit{Max1Row}\) 算子。

基本消除规则

第一组规则是最基本的规则，等式中的 \(\otimes\) 说明它不限制连接类型，可以是\(\{ \times, LOJ, \exists, \nexists\}\) 中的任意一个。

这两条规则是非常显而易见的，翻译成大白话就是：如果 Apply的右边不包含来自左边的参数，那它就和直接 Join 是等价的。

下面是对 Query 3 应用规则 (2) 的例子：

Project 和 Filter 的去关联化

第二组规则描述了如何处理子查询中的 Project 和Filter，其思想可以用一句话来描述：尽可能把 Apply 往下推、把Apply 下面的算子向上提。

注意这些规则仅处理 Cross Apply 这一种情况。其他 3 种 Apply的变体，理论上都可以转换成 CrossApply，暂时我们只要知道这个事实就可以了。

你可能会问：通常我们都是尽可能把 Filter、Project往下推，为什么这里会反其道而行呢？关键在于：Filter、Project里面原本包含了带有关联变量的表达式，但是把它提到 Apply上方之后，关联变量就变成普通变量了！这正是我们想要的。

我们稍后就会看到这样做的巨大收益：当 Apply被推最下面时，就可以应用第一组规则，直接把 Apply 变成Join，也就完成了子查询去关联化的优化过程。

下面是对 Query 2 应用规则 (3) 的例子。之后再应用规则(1)，就完成了去关联化过程。

Aggregate 的去关联化

第三组规则描述如何处理子查询中的 Aggregate（即 GroupBy）。和上一组一样，我们的指导思想仍然是：尽可能把 Apply往下推、把 Apply 下面的算子向上提。

下面等式中，\(G_{A,F}\) 表示带有Group By 分组的聚合（Group Agg），其中 \(A\) 表示分组的列，\(F\) 表示聚合函数的列；\(G_{F}^{1}\) 表示不带有分组的聚合（ScalarAgg）。

这一组规则不像之前那么简单直白，我们先看一个例子找找感觉。下面是对Query 1 运用规则 (9) 的结果：

规则 (9) 在下推 Apply 的同时，还将 ScalarAgg 变成了GroupAgg，其中，分组列就是 R 的 key，在这里也就是CUSTOMER 的主键 c_custkey。

如果 R 没有主键或唯一键，理论上，我们可以在 Scan 时生成一个。

为什么变换前后是等价的呢？变换前，我们是给每个 R 的行做了一次ScalarAgg聚合计算，然后再把聚合的结果合并起来；变换后，我们先是将所有要聚合的数据准备好（这被称为augment），然后使用 GroupAgg 一次性地做完所有聚合。

这也解释了为什么我们要用 \(A^{LOJ}\)而不是原本的 \(A^{\times}\) ：原来的ScalarAgg 上，即使输入是空集，也会输出一个 NULL。如果我们这里用 \(A^{LOJ}\)，恰好也会得到一样的行为（＊）；反之，如果用\(A^{\times}\) 就有问题了——没有对应ORDERS 的客户在结果中消失了！

规则 (8) 处理的是GroupAgg，道理也是一样的，只不过原来的分组列也要留着。

ScalarAgg 转换中的细节＊

细心的读者可能注意到，规则 (9) 右边产生的聚合函数是 \(F'\)，多了一个单引号，这暗示它和原来的聚合函数\(F\)可能是有些不同的。那什么情况下会不同呢？这个话题比较深入了，不感兴趣的同学可以跳过。

首先我们思考下，GroupAgg 以及 \(A^{LOJ}\)的行为真的和变换前一模一样吗？其实不然。举个反例：

SELECT c_custkey, (    SELECT COUNT(*)    FROM ORDERS    WHERE o_custkey = c_custkey) AS count_ordersFROM CUSTOMER

设想一下：客户 Eric 没有任何订单，那么这个查询应当返回一个['Eric', 0] 的行。但是，当我们应用了规则 (9)做变换之后，却得到了一个 ['Eric', 1] 的值，结果出错了！

为何会这样呢？变换之后，我们是先用 LeftOuterJoin准备好中间数据（augment），然后用 GroupAgg 做聚合。LeftOuterJoin 为客户Eric 生成了一个 ['Eric', NULL, NULL, ...] 的行；之后的GroupAgg 中，聚合函数 COUNT(*) 认为 Eric 这个分组有 1行数据，所以输出了 ['Eric', 1]。

下面是个更复杂的例子，也有类似的问题：

SELECT c_custkeyFROM CUSTOMERWHERE 200000 < (    SELECT MAX(IF_NULL(o_totalprice, 42)) -- o_totalprice may be NULL    FROM ORDERS    WHERE o_custkey = c_custkey)

作为总结，问题的根源在于：\(F(\emptyset)\neq F(\{\textit{NULL}\})\)，这样的聚合函数 \(F\) 都有这个问题。

变换后的 GroupAgg 无法区分它看到的 NULL 数据到底是 OuterJoin产生的，还是原本就存在的，有时候，这两种情形在变换前的ScalarAgg 中会产生不同的结果。

幸运的是，SQL 标准中定义的聚合函数 \(F(col)\) 都是 OK 的——它们都满足 \(F(\emptyset) =F(\{\textit{NULL}\})\)，我们只要对 \(F\) 稍加变换就能解决这个问题。

• 对于例子一，将 COUNT(*)替换成一个对非空列（例如主键）的 Count即可，例如：COUNT(o_orderkey)；
• 对于例子二，需要把 MIN(IF_NULL(o_totalprice, 42))分成两步来做：定义中间变量 X，先用 Project 计算X = IF_NULL(o_totalprice, 42)，再对聚合函数MIN(X) 进行去关联化即可。

集合运算的去关联化

最后一组优化规则用来处理带有 Union（对应UNION ALL）、Subtract（对应 EXCEPT ALL） 和Inner Join 算子的子查询。再强调一遍，我们的指导思想是：尽可能把Apply 往下推、把 Apply 下面的算子向上提。

下面的等式中，\(\times\) 表示 CrossJoin，\(\bowtie_{R.key}\) 表示按照\(R\) 的 Key 做自然连接：\(r \circ e_1 \circ e_2\)。和之前一样，我们假设 \(R\)存在主键或唯一键，如果没有也可以在 Scan 的时候加上一个。

注意到，这些规则与之前我们见过的规则有个显著的不同：等式右边 \(R\)出现了两次。这样一来，要么我们把这颗子树拷贝一份，要么做成一个 DAG的执行计划，总之会麻烦许多。

事实上，这一组规则很少能派上用场。在 [2] 中提到，在 TPC-H 的 Schema下甚至很难写出一个带有 Union All 的、有意义的子查询。

其他

有几个我认为比较重要的点，用 FAQ 的形式列在下面。

► 是否任意的关联子查询都可以被去关联化？

可以说是这样的，在加上少量限定之后，理论上可以证明：任意的关联子查询都可以被去关联化。

证明方法在 [1]、[3] 中都有提及。以 [1] 中为例，思路大致是：

1. 对于任意的查询关系树，首先将关联子查询从表达式中提取出来，用 Apply算子表示；
2. 一步步去掉其中非基本关系算子，首先，通过等价变换去掉 Union 和Subtract；
3. 进一步缩小算子集合，去掉 OuterJoin、\(A^{LOJ}\)、\(A^{\exists}\)、\(A^{\nexists}\)；
4. 最后，去掉所有的 \(A^{\times}\)，剩下的关系树仅包含基本的一些关系算子，即完成了去关联化。

另一方面，现实世界中用户使用的子查询大多是比较简单的，本文中描述的这些规则可能已经覆盖到99%的场景。虽然理论上任意子查询都可以处理，但是实际上，没有任何一个已知的DBMS 实现了所有这些变换规则。

► HyPer 和 SQL Server 的做法有什么异同？

HyPer 的理论覆盖了更多的去关联化场景。例如各种 Join 等算子，[3]中都给出了相应的等价变换规则（作为例子，下图是对 Outer Join的变换）。而在 [1]中仅仅是证明了这些情况都可以被规约到可处理的情形（实际上嘛，可想而知，一定是没有处理的）。

另一个细节是，HyPer 中还存在这样一条规则：

其中，\(D=\Pi_{F(T_2)\cap A(T_1)}(T_1)\)，表示对 \(T_1\) 的Distinct Project 结果（所谓的 MagicSet）。直接看等式比较晦涩，看下面的例子就容易理解了：

图中，在做 Apply 之前，先拿到需要 Apply 的列的 Distinct值集合，拿这些值做 Apply，之后再用普通的 Join 把 Apply的结果连接上去。

这样做的好处是：如果被 Apply 的数据存在大量重复，则 Distinct Project之后需要 Apply 的行数大大减少。这样一来，即使之后 Apply没有被优化掉，迭代执行的代价也会减小不少。

► 本文说的这些变换规则，应该用在 RBO 还是 CBO中呢？换句话说，去关联化后之后的执行计划一定比去关联化之前更好吗？

答案是，不一定。

直观的看，如果 Apply 的左边数据量比较少（例如，仅有 1条数据），那直接带入 Apply的右边计算反而是更好的方式。另一种情况是，右边有合适的索引，这种情况下，多次Apply 的代价也并非不可接受。

所以把这些规则放进一个 CBO的优化器是更合适的，优化器根据代价估计选出最优的计划来。甚至，在某些情况下，我们还会自右向左地运用这些等式，做“加关联化”。

这和用 HashJoin 还是 NestedLoopJoin是同样的道理。事实上，NestedLoopJoin 就是 Apply的一个特例。如果存在合适的索引，NestedLoopJoin 效率高于 HashJoin是很常见的事情。

References

1. ParameterizedQueries and Nesting Equivalencies - C Galindo-Legaria
2. OrthogonalOptimization of Subqueries and Aggregation - C Galindo-Legaria, MJoshi
3. UnnestingArbitrary Queries - T Neumann, A Kemper
4. TheComplete Story of Joins (inHyPer) - T Neumann, V Leis, A Kemper

代码生成（CodeGeneration）技术广泛应用于现代的数据系统中。代码生成是将用户输入的表达式、查询、存储过程等现场编译成二进制代码再执行，相比解释执行的方式，运行效率要高得多。

上一篇文章 代码生成技术（一）表达式编译中提到，虽然表面上都叫“代码生成”，但是实际可以分出几种粒度的实现方式，比如表达式的代码生成、查询的代码生成、存储过程的代码生成等。今天我们要讲的是查询级别的代码生成，有时也称作算子间（intra-operator）级别，这也是主流数据系统所用的编译执行方式。

本文主要参考了 HyPer 团队发表在 VLDB'11 的文章 EfficientlyCompiling Efficient Query Plans for Modern Hardware。

Volcano 经典执行模型

为什么要用编译执行？编译执行有哪几种实现？这些问题的答案都写在前一篇文章里，还有困惑的同学务必先看完前一篇文章 再回来。

今天说的主角是查询（Query）的编译执行，在讲它之前，看看经典 Volcano模型是怎么做的。Volcano模型十分简单（这也是它流行的主要原因）：每个算子需要实现一个next() 接口，意为返回下一个 Tuple。

Query 1 是一个很简单的查询，Project 会调用 Filter 的next() 获得数据，Filter 的 next() 又会调用TableScan 的 next()，TableScan读出表中的一行数据并返回。如此往复，直到数据全部处理完。

Query 2 复杂一些，它包含一个 HashJoin。我们知道HashJoin 的两个子节点是不对称的，一边称为 build-side，另一边称为 probe或 stream-side。执行时，必须等待 build-side处理完全部数据、构建出哈希表之后，才能运行stream-side。

因为这个原因，执行的过程其实被分成了两个阶段（图中浅灰色的背景）。在Volcano 模型中，这也很容易实现，我们试着写一下 HashJoin 的伪代码：

1
2
3
4
5
6
7
8
9
10

Row HashJoin::next() {
    // Stage 1: Build Hash Table (HT)
    if (HT is not built yet) // 注意：Build 仅在第一次调用 next() 时发生
        while ((r = left.next()) != END)
            ht.put(buildKey(r), buildValue(r))
    // Stage 2: Probe tuples one by one
    while (r = right.next())
        if (HT contains r)
            output joined row;
}

这个构建哈希表的过程，我们称为物化（Materialize），意味着Tuple 不能继续往上传递，而是被暂存到某个 buffer里。而大多数时候，例如执行 Filter 等算子时，Tuple是被一路传上去的，这被称为Pipeline。显然物化的代价是比较高的，我们希望尽可能多的Pipeline 而避免物化。

Query 3 中的 Aggregate 算子也有类似的情况：在Aggregate 返回第一条结果之前，我们要把下面所有的数据都聚合完成才行。

我们称 HashJoin、HashAgg 这种打断 Pipeline 的算子为 PipelineBreaker，它们的存在使得执行过程被分成了不止一个阶段。值得注意的是，这里之所以分成多个阶段，是因为HashJoin 或 HashAgg 算法本身决定的，跟 Volcano 执行模型无关。

Volcano 的性能问题

Volcano 执行模型胜在简单易懂，在那个硬盘速度跟不上 CPU的时代，性能方面并不需要考虑太多。然而随着硬件的进步，IO很多时候已经不再是瓶颈，这时候人们就开始重新审视 Volcano模型，于是产生了两种改进思路：

1. 将 Volcano 迭代模型和向量化模型结合，每次返回一批而不是一个Tuple；
2. 利用代码生成技术，消除迭代计算的性能损耗。

关于这两个方案哪个更优，这里有一篇非常棒的论文做了很详尽的实验和分析。

当然，作为今天的主题，我们只看第二个思路。就像表达式解析执行一样，Volcano其实是对算子树的解释执行，它也同样存在这些问题：

• 每产生一条结果就要做很多次虚函数调用，消耗了大量的 CPU 时间；
• 过多的函数调用导致不能很好的利用寄存器。

我们来思考一个问题，如果让你去把 Query 1写成代码来执行，会是什么样的呢？答案非常短，短的令人惊讶：

右图中用不同颜色标出了原来的算子，其中 condition = true是一个表达式，按照上一篇文章讲解的方法就能生成出代码，然后放到这边if 的条件上即可。

这两个的执行效率应该很容易看出差距吧！生成出的代码完全消除了虚函数调用，而且Tuple几乎一直在高速缓存甚至寄存器中。论文中也提到，随便找个本科生手写代码，执行性能都能甩迭代模型几条街。

再看个更复杂的例子找找感觉，以下查询（记作 Query4）混合了 Join、Aggragate 甚至子查询，之前我们说到，这些算子是PipelineBreaker，执行过程被不可避免的分成几个阶段；除此以外，我们希望其他部分尽可能地做到Pipeline 执行。

这个例子有点长，但如果你能花上两三分钟看懂它，相信你对代码生成已经有了些直觉上的理解，这对你理解掌握下一章节的内容大有帮助。

图中我用不同颜色出了 HashJoin、HashAgg三个算子各自的代码，可以看出，它们各自的代码逻辑被“分散”到了不止一处地方，甚至代码中已经很难分辨出各个算子，而是全都融合（Fusion）到一块儿了。

这就是我们想要的结果！好了，下一步终于进入了正题：如何自动生成出这样的代码呢？

很多人有个错觉，以为数据库查询过程那么复杂，生成的代码一定也很复杂吧。其实不然，查询中复杂的部分，例如HashJoin 中哈希表实现、TableScan读取数据的实现等，这些并不用生成很多代码，仅仅只是调用现有的函数即可，比如LLVM IR 可以调用已存在的任何函数。

换个角度看，生成的代码不过是把这些算子的实现以更高效的方式串联在了一起：算子自身逻辑就像齿轮，生成的代码好比连接齿轮的链条。

HyPer 的解决方案

代码生成是个纯粹的工程问题。工程问题没有什么不能解的，难就难在找到其中最漂亮的解。比如现在这个问题，为了编程的优雅，我们希望造一个可扩展的框架：不论哪个算子，只要实现某种接口（就像Volcano 模型要求实现 next()接口一样），就能参与到代码生成中。

论文中给出的解法可以说是十分优雅了，模型要求所有算子实现以下两个接口函数：

• produce()
• consume(attributes, node)

代码生成的过程总是从调用根节点的 produce() 开始；而consume()类似于一个回调函数，当下层的算子完成自己的使命之后，调用上层的consume() 来消费刚刚产生的tuples——注意这里并不是真的消费。

用例子来说明。下面是一个伪代码版本的若干算子实现。produce()和 consume()返回的类型都是生成的代码片段，这里为了方便演示直接用字符串表示。真实世界中当然要更复杂一些。

表中红色的字符串是生成的代码，黑色的则是 code-gen本身的代码。回忆一下：代码生成其实就是用各种手段拼出代码（字符串）来，没什么神秘的。

不满足于伪代码的同学可以尝试阅读 HyPer 的 论文（生成LLVM IR） 或者 Spark SQL 中的 CodeGenerator实现（生成 Java 代码），后者的代码相对更容易理解些。

思考：这是唯一的解法吗？*

为什么是 produce/consume呢？是否存在更简单的解呢？这里给出我的推导思路，你可以跳过这一段，毕竟每个人的脑回路是不一样的。

首先，如果只有一个接口函数，不妨叫它produce()，一定是不够用的。为什么这么说呢？一个函数充其量只能做出类似DFS 的效果：每个算子只会被经过一次。这对 Query 1还不是问题，但对于上文中复杂的 Query 4，HashJoin的两部分代码离得那么远，用 DFS 就很难做到了。

为了处理HashJoin，我们该增加一个怎样的函数呢？我认为它应该类似于一个回调，比如Query 4 中，当 DFS 进行到 \(\Join_{a=b}\)时，我希望通过一种某种方式告诉下面的 \(\sigma_{x=7}\)：当你拿到结果后，只要用我传给你的方法去消费这些Tuples（生成消费这些 Tuples 的代码）。这个方法，不妨叫做consume()。

顺理成章的，consume() 至少有个参数来传递需要消费的tuples有哪些列。另外，还需要一个参数用来指示：调用者是左孩子还是右孩子？这等价于传this。

以上。因此我倾向于了认为，论文提出的 produce/consume模式可能是唯一正确的方法，即使存在其他算法，我猜想也是大同小异。

References

1. EfficientlyCompiling Efficient Query Plans for Modern Hardware - VLDB'11
2. SPARK-12795 -Whole stage codegen
3. Everything YouAlways Wanted to Know About Compiled and Vectorized Queries But WereAfraid to Ask - VLDB'18

Weld 是一个用于数据计算分析的高性能Runtime（High-performance runtime for data analyticsapplications），使用 Rust编写，可以很容易地集成到各种大数据计算框架中，比如 Spark SQL、NumPy& Pandas、TensorFlow 等，带来大幅的性能提升。

除了 Weld本身的贡献，论文中提到的各种用于执行阶段的优化技术也很有意思，其中的大部分都借鉴自关系型数据库或编译器。本文除了介绍Weld 之外，也是想对这些技术做个梳理。

本文主要内容来自于 Weld 发表在 VLDB'18的论文。

整体架构

之前说到，Weld 是一个用于数据计算的Runtime，它的上层通常是一些计算框架，例如 Spark SQL、NumPy等。用户用这些计算框架编写程序，这些框架将用户需要的计算翻译成 Weld中间表示（IR），然后 Weld对其进行一系列的优化，最后生成代码并编译运行。

做个类比，这就像 LLVM的工作方式一样：各种语言的编译前端将高级语言翻译成 LLVM IR，LLVM 再对 IR做一系列的优化，最后再编译成二进制。

虽然都是 IR，但实际上 Weld IR 和 LLVM IR 有很大不同：

• Weld IR是声明式的：只表达计算流程，不包含具体的实现。比如下面会提到的Builder，上层不需要指定用什么方式构建数组或是哈希表等数据结构，这些是由Weld 优化器决定的；
• Weld IR 是 Lazy 的：只有当需要输出结果时，相应的DAG 计算才会真正开始运行。

上图是 Weld 的整体工作过程：

1. 上层调用 Weld 的 API 输入需要计算的 IR 程序，它会被解析成 AST；
2. 当需要执行时，相关的函数 IR 会被拼在一起，方便进行整体优化；
3. Weld 优化器使用一系列的启发式规则进行优化，注意结果仍然是 AST；
4. 最后生成代码并借助 LLVM 编译成二进制。

Weld 主要由两个部分组成：IR 和 Runtime，接下来我们依次进行介绍。

Weld IR

Weld IR 支持 int、float等基本数据类型、struct类型，以及两种容器类型：vec 和dict，顾名思义，分别是（变长）数组和字典。另外还支持他们的各种组合，就像JSON 那样。

和数据库的执行器不同，Weld不考虑数据拉取之类的问题。它假设输入数据都在内存中以数组形式存在，例如：int[100]、struct{int, float}[100]。

Weld IR 的计算都通过 Builder 和 Merger 来完成，由于Merger 和 Builder 的接口是一样的，Weld论文中并没有把二者区分开来。下面我们统称为 Builder。

Builder 提供两个接口方法：

• merge(b, v)：向 Builder b添加新的元素；
• result(b)：拿到 b的结果，注意之后不能再添加元素了。

下面是使用 Builder 的例子：

代码中还有个 for，它的语法是for(vector, builders, (builders, index, elem) => builders)，用来并行地对数据做处理——也就是往Builder 里加元素，这是 Weld 中唯一的计算方式。

for 还可以同时处理多个Builder，这个特性在优化的时候很有用，可以避免同一个数据扫描多次。

Weld IR 还有些别的特性（比如方便编程的macro），但不是本文的重点，有兴趣的同学自己看原文吧。

Weld Runtime

当上层输入 IR 并发出开始计算的指令时，就轮到 Weld Runtime登场了。在代码生成之前，Weld Runtime 会对 IR做优化，优化可以分为两种：

1. Rule-Based Optimizer (RBO)：和我们熟悉的 RBO优化类似，是基于规则匹配的优化；
2. Adaptive Optimizer：运行时 sample数据，然后决定用哪种算法执行，勉强可以对应 CBO。

为什么不是 CBO？关系型数据库的 CBO 是需要以统计信息为基础的，但是Weld 作为一个通用的 Runtime，上层框架不一定能提供统计信息（比如NumPy）。

Weld 应用规则是依次进行的，每次运行一种优化规则，称为一个pass。Pass 之间会进行剪枝，去掉无用的代码。以下我们逐条看看Weld 做了哪些优化。

Pipeline

Pipeline 在 OLAP 系统中很常见，最经典的是 HyPer 团队提出的 consume/produce代码生成机制，可以在代码生成时尽可能生成 Pipeline 的代码。

为什么需要 Pipeline？设想一下使用代码生成、但是不使用 Pipeline会怎么样，那么 \(R_1\) 和 \(\sigma_{x=7}\) 就会分成独立的两步，\(R_1\) (即TableScan）的结果被物化到内存中，再进行 \(\sigma_{x=7}\)（Filter）。

而 Pipeline 的代码省略了中间的物化，仅仅用了一个 if就解决了 filter，这个代价要低得多：计算 if表达式时相关数据基本还在寄存器或 Cache 里，充分利用 DataLocality，这比去内存取数据快 1～2 个数量级。

Pipeline 优化规则会在 AST 中匹配这样的模式：A 的输出就是 B的输入，对匹配到的节点应用 pipeline优化，下面是一个简单例子：

Horizontal Fusion

Fusion 意为把两段代码融合成一段更精炼的代码，刚刚说的 Pipeline也是一种 Fusion。所谓 Horizontal Fusion是找出被重复处理的数据，然后将几次处理合在一起。

例如下面图中的 IR，v0 原本被 loop over了两次，如果把两次循环合成一次，能尽可能利用 DataLocality，减少一半的内存读取代价。

硬要说的话，这个规则与关系代数优化中的 Project Merge规则最相似。论文中给了一个更好的例子来说明它的用处：像 Pandas这类的计算框架，由于 API 设计一次只能处理一列，必须借助 HorizontalFusion 实现一次处理多列。

向量化和 Adaptive 优化

向量化（Vectorization）优化也不是新鲜事，很多编译器（比如LLVM）都能自动把循环编译成 SIMD 指令，JVM 甚至可以在运行时生成 SIMD代码。

SIMD全称是单条指令、多个数据，即用一条指令处理多个数据计算，比如原本计算4 个整数加法要用 4 次加法指令，用了 SIMD 之后只要 1次。没错，就这么简单！

在这个 pass 中仅处理简单的、没有条件分支的 for循环，如果满足这一条件，优化器会将被循环的数据从 T 转换成simd[T]，最后 code-gen 的时候为其生成 SIMD 代码。

那对于带有条件分支的 for循环，能否进行向量化呢？答案是，可以，但是不一定有用。

我们先设想一下：对于有条件分支的 for循环，它向量化之后是什么样的？SIMD 指令本身是没法处理分支的（compare这种特别简单的除外），如果一定要用 SIMD，可以假设分支条件全都为true 或 false，最后根据条件表达式的计算结果（true 或false），利用 select 指令选出相应的结果。

这种方式相比普通的带分支的指令，有得有失：

• 优势：用 SIMD 指令集可以加速计算；
• 劣势：原本只要算一个分支，现在两个分支都要算。

注：另一个优势是，SIMD 去掉了条件跳转，不存在打断 CPU流水线的问题。但是论文中没有提到这一点，我猜测可能是它的影响因素比较小，或是作者没有找到一个合适的代价计算方式。

论文只给出了对 if(cond, merge(b, body), b)这样单分支条件的代价建模，有兴趣的同学可以看原论文上的式子。这里只说一个粗糙的结论：当选择率（即进入if-body 的概率）很小时，有分支的代码更优；当选择率比较大时，SIMD代码更优。

我们之前说过，Weld假设上层无法提供统计信息，因而在这一步，由于缺乏关键的选择率信息，它只能采取一种Adaptive 的思路：同时生成有分支的代码和 SIMD代码，运行时，首先对输入数据做个 Sample估算一下选择率，再决定走哪个算法。

选择率（selectivity）这个概念在数据库优化器中也很常用，比如估算 RowCount时就频繁用到了选择率估计。如果能在优化时直接拿到这个信息，想必不需要这么折腾。

Adaptive Hash Table

Weld 的 dictbuilder 和 groupbuilder中都需要构建哈希表，这里也有个 trade-off：是用 Partitioned Hash Table还是 Global Hash Table？

• Partitioned Hash Table 是将 build 过程分成两步，先各个线程本地做build，最后再 merge 成完整的结果；
• Global Hash Table只有一张全局的哈希表，通过加锁等方式做了控制并发写入。

一般而言，如果 Group by 的基数（Cardinality）比较小，Partitioned方式更有优势，因为并发冲突会很多；相反，如果基数很大，Global更占优势，因为无需再做多一次 merge。

Weld的做法很巧妙地实现了二者取折中：各线程先写到本地的哈希表，但如果大小超过阈值，就写到全局的哈希表。最后把本地数据再merge 进全局哈希表。这个实现被它称为 Adaptive Hash Table。

Misc.

Weld 中还有还有一些优化手段，比较简单：

循环展开（LoopUnrolling）是编译器中很常见的优化，如果编译期已知 for循环的次数很小（例如，对于一个 N*3 的矩阵，第二维度长度仅为3），就将循环展开，避免条件跳转指令打断 CPU 流水线。

数组预分配（Preallocation）在矩阵运算中也很有用，例如，默认vecbuiler的实现是自动生长的动态数组。如果预先知道数组长度，就能避免数组生长的拷贝代价。

评估和总结

下面是 Weld官网放出的性能评估，对于文中提到的这几个框架，的确做到了可观的性能提升。

注：这里 TensorFlow 性能是用 CPU 运行的，而非 GPU。

Weld 的最大贡献是抽象出了一个通用的执行器Runtime。这个抽象的层级要比“代码生成”中的“代码”（比如 LLVMIR）高级（high-level）不少，但又比关系代数或是线性代数低级（low-level），从而有更好的通用性。更可贵的是，WeldIR 仅仅包含 Builder 以及 for、if 这些最基本的语句，极其之简单。

上文提到的很多优化规则，不少来源于编译器或关系型数据库。例如 PipelineFusion的思想，在编译器中其实也有体现——编译器会尽可能连续的利用寄存器、避免store/load。但是 Weld IR独特的抽象层级令它能做层级更高的优化，达到和数据库的 Pipeline一样的效果。

References

1. EvaluatingEnd-to-End Optimization for Data Analytics Applications in Weld(VLDB'18)
2. EfficientlyCompiling Efficient Query Plans for Modern Hardware (VLDB'11)
3. Weld - Official Website

如果不引入任何第三方库，CompletableFuture 仍是目前 Java上最好的异步编程方式。之前一直觉得这个东西难用，直到我想明白一件事，证明了CompletableFuture虽然麻烦了点但是能做任何事情，然后用它的时候心里就没那么膈应了。

本文会以一个例子来讲解：如何把任意函数转换成异步调用风格。其实不一定要用CompletableFuture，任何语言和框架都是适用的。

这篇文章不会涉及 CompletableFuture 的用法，你可以参考 Javadoc 或者这篇文章。

证明 CompletableFuture是足够的

首先来（极不严谨地）说明一件事情，为什么 CompletableFuture是足够用的，换句话说，证明 CompletableFuture能表达一切计算流程。

如果你有一些函数式编程的基础，比如会一点Haskell，这就是一句话的事情：CompletableFuture 其实是一个 Monad ——因为它的 thenCompose 实现了 Monad 的 >>=操作符。既然 Monad 能用来表示任何计算过程，CompletableFuture当然也能。

1
2
3
4
5
6

class Applicative m => Monad (m :: * -> *) where
  (>>=) :: m a -> (a -> m b) -> m b  -- thenCompose 实现了它 
  (>>) :: m a -> m b -> m b
  return :: a -> m a
  fail :: String -> m a
  {-# MINIMAL (>>=) #-} -- 这是在说：只要实现 (>>=) 就够了

其实想想也很明白，Monad 表示一个带 context的计算过程，比如可能抛异常之类的（纯函数是不会抛异常的）。CompletableFuture也一样，他包裹一串计算过程并且处理异常。

如果看不懂上面的也没关系，我们用另一种方式再说明一下：

任何程序的流程控制都可以用 if 和 goto来组合起来。无论是 for 还是 while循环，desurge 之后不过就是 if 和 goto的组合。通过 thenCompose 就可以表达 if和 goto：

这里说的不够严谨，其实 if 也是 surge，最终会变成条件跳转指令。

1
2
3
4
5
6
7

cf.thenCompose(v -> {
    if (v < 100) {
        return doStage1(); // doStage1() 返回一个 CompletableFuture，决定下一步做什么，相当于 goto
    } else {
        return doStage2(); // 同上
    }
})

你看这个例子，if 和 goto都有了，所以无论程序的控制流多复杂，我们都能组合出来。怎么组合？别急，下面我们就来讲这个。

CompletableFuture inPractice

我们从一个普通的函数开始。考虑到复杂性和完整性，我们用 Merge 2Sorted Streams 作为演示，如果你不清楚这个是干嘛的，可以先做一下这道算法题。

下面是最普通的实现，输入两个数组，输出一个数组：

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

Stream merge(Stream inputA, Stream inputB) {
    List<Integer> results = new ArrayList<>();
    Integer headA = inputA.next();
    Integer headB = inputB.next();
    while (headA != null || headB != null) {
        if (headA == null || headB != null && headA > headB) {
            results.add(headB);
            headB = inputB.next();
        } else {
            results.add(headA);
            headA = inputA.next();
        }
    }
    return new Stream(results);
}

class Stream {
    private final Queue<Integer> numbers;
    public Stream(List<Integer> numbers) { this.numbers = new LinkedList<>(numbers); }
    public Integer next() { return numbers.poll(); }
}

这个实现有什么问题呢？作为算法足够 OK。但是从工程意义上说，如果输入的Stream 很大，包含 million 级的元素，那更好的方式是把 Stream的输入输出作为 Iterator，只在 next()的时候计算下一个需要的元素。这样内存占用是常数级的，完全不用担心数据量过大呢！

为了看清一步一步的变化过程，我们先假装 Java 有 Generator语法。标记为 Generator 的函数不再是一个函数，而是类似一个Iterator。一旦调用 next()，“函数”代码运行到yield返回一个值，然后函数似乎停在了这里。下次next()，“函数”又接着刚刚的地方运行。

如果有 Generator 的话，函数应该长下面这样，注意[yield]:

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

Stream merge(Stream inputA, Stream inputB) {
    Integer headA = inputA.next();
    Integer headB = inputB.next();
    while (headA != null || headB != null) {
        if (headA == null || headB != null && headA > headB) {
            [yield] headB;
            headB = inputB.next();
        } else {
            [yield] headA;
            headA = inputA.next();
        }
    }
    [yield] null;
}

哇，这个函数几乎没有改动，真是太方便了！（然而并没有卵用）

Function → Iterator

现在我们回到现实：Java 并没有 Generator 语法，所以我们要人肉实现一个Generator。

为了通用性，首先做一个 desurge，把 while 循环改成 if 和goto 的组合，这太简单了：

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

Stream merge(Stream inputA, Stream inputB) {
    Integer headA = inputA.next();
    Integer headB = inputB.next();
    WHILE_LOOP:
    if (headA != null || headB != null) {
        if (headA == null || headB != null && headA > headB) {
            [yield] headB;
            headB = inputB.next();
        } else {
            [yield] headA;
            headA = inputA.next();
        }
        goto WHILE_LOOP; // again，假设 Java 也有 goto
    }
    [yield] null;
}

下一步是去掉 yield，刚刚说到 Generator 的每次next()似乎会让函数停在一个地方，如何实现停在一个地方？记下来呗！加一个标记状态的变量，这个状态会告诉我下次next() 的时候从哪里继续运行。

首先画出函数的控制流图，然后做一件事：想象所有的 yield之后都有一个断点，我们在断点处切开，标记它为某个 State，这样下次next() 的时候就能从断点继续。

下图的 S0 ～ S2 是我标记好的断点，S0 就是起始位置，S1 是两个yield result 之后断下来的地方（恰好是同一个地方），S2 是yield null 之后断下来的地方。

我们按照图中的 State标记机械地把它切开，就得到了下面这个类，它就是由 merge()变换得到的 Generator：

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

class Merger implements Iterator<Integer> { 
    // Arguments
    final Iterator inputA;
    final Iterator inputB;
    
    // Internal states
    private int state = 0; // 我们加上的状态变量
    private Integer headA; // 变换前的局部变量，因为跨了多次 next() 调用，不能再是局部变量了
    private Integer headB; // 同上

    public Merger(Iterator inputA, Iterator inputB) {
        this.inputA = inputA;
        this.inputB = inputB;
    }

    public Integer next() {
        for (;;) { // 这个循环是有用的，往下看几行
            switch (state) {
            case 0:
                headA = inputA.next();
                headB = inputB.next();
                state = 1;
                break; // 这里就用上了外层的循环
            case 1:
                if (headA != null || headB != null) {
                    if (headA == null || headB != null && headA > headB ) {
                        final int result = headB;
                        headB = inputB.next();
                        state = 1; // 可以省略
                        return result; // 变换前是 yield result
                    } else {
                        final int result = headA;
                        headA = inputA.next();
                        state = 1; // 可以省略
                        return result; // 变换前是 yield result
                    }
                } else {
                    state = 2;
                    return null; // 变换前是 yield null
                }
            case 2:
                // Generator 已经终结了（变换前：函数已经走到底了）
                throw new IllegalStateException("Generator has been exhausted!");
            default:
                throw new AssertionError("Unreachable!");
            }
        }
    }
}

别急，最后我们会简化这些充满废话的代码。

阶段性总结一下：到现在为止，我们做了一件伟大的事情——把一个函数变成了Iterator，函数已经不再是函数，而是一个状态机，这个状态记录了下次调用next() 需要从哪继续。

套用一下术语：“从哪继续”就是 Continuation，把Continuation 搞出来的这个过程称为 CPS变换。

Iterator → AsyncIterator

呃…… 说好的 CompletableFuture 呢？离 CompletableFuture只有一步之遥了！

先从接口下手。想象两个 Stream Input 都是从 IO 拿到的数据，所以每次next() 其实背后都是一次 IO，应该把它用 CompletableFuture包成异步的，接口大概长这样：

1
2
3

interface AsyncIterator<T> {
    CompletableFuture<T> next();
}

类似刚刚引入 Generator 一样，我们再假装有 await关键字。await关键字表示异步地等待结果返回，有了它，函数就魔法般的暂停在等待异步 IO的地方：

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

Stream merge(Stream inputA, Stream inputB) {
    Integer headA = inputA.next();
    Integer headB = inputB.next();
    WHILE_LOOP:
    if (headA != null || headB != null) {
        if (headA == null || headB != null && headA > headB) {
            Integer result = headB;
            headB = [await] inputB.next(); // await 会魔法般地等待 next() 完成再继续运行
            [yield] result;
        } else {
            Integer result = headA;
            headA = [await] inputA.next();
            [yield] result;
        }
        goto WHILE_LOOP;
    }
    [yield] null;
}

因为 await 也会暂停这个“函数”，所以和刚刚对yield 的处理一样，我们想象 await这里有一个断点，我们也要为它设置 State 标记：

糟糕！这状态数有点多啊！好在 Java 8 提供了 Lambda 表达式，和CompletableFuture 搭配食用口味更佳。图中的大多数状态都可以借助 Lambda表达式来实现，节约了不少代码：

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

class Merger implements AsyncIterator<Integer> {
    // Arguments
    final Stream inputA;
    final Stream inputB;

    // Internal states
    private int state = 0;
    private Integer headA;
    private Integer headB;

    public Merger(Stream inputA, Stream inputB) {
        this.inputA = inputA;
        this.inputB = inputB;
    }

    public CompletableFuture<Integer> next() {
        switch (state) {
        case 0:
            return inputA.next().thenCompose(a -> { // State 1 在这里！
                headA = a;
                return inputB.next();
            }).thenCompose(b -> { // State 2 在这里！
                headB = b;
                state = 3;
                return next(); // 相当于原来的外层循环
            });
        case 3:
            if (headA != null || headB != null) {
                if (headA == null || headB != null && headA > headB) {
                    final Integer result = headB;
                    return inputB.next().thenCompose(b -> { // State 4 在这里！
                        headB = b;
                        state = 3; // 可以省略
                        return CompletableFuture.completedFuture(result);
                    });
                } else {
                    final Integer result = headA;
                    return inputA.next().thenCompose(a -> { // State 5 在这里！
                        headA = a;
                        state = 3; // 可以省略
                        return CompletableFuture.completedFuture(result);
                    });
                }
            } else {
                state = 6;
                return CompletableFuture.completedFuture(null);
            }
        case 6:
            throw new IllegalStateException("Generator has been exhausted!");
        default:
            throw new AssertionError("Unreachable!");
        }
    }
}

Refinement

上面我们只用了 thenCompose，理论上这是 OK 的，但是实际上CompletableFuture 有上百个方法，最合适的才是坠吼的。

• 如果仅仅是返回一个值（而非阶段），可以用thenApply；
• thenCombine 等待两个 CompletableFuture 都完成了再去调用BiFunction (T, U) -> R 来消费。

思考题：有兴趣的读者可以思考一下 thenCombine的实现。

整理一下上面的代码，比如这样：

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

class Merger implements AsyncIterator<Integer> {
    // States
    enum State { START, ITERATING, DONE }
    
    // Arguments
    final Stream inputA;
    final Stream inputB;
    
    // Internal states
    private State state = State.START;
    private Integer headA;
    private Integer headB;

    public Merger(Stream inputA, Stream inputB) {
        this.inputA = inputA;
        this.inputB = inputB;
    }

    private CompletableFuture<Integer> next() {
        switch (state) {
        case START:
            // 这里做了小小的优化：这两个 next() 可以并行等待
            return inputA.next().thenCombine(inputB.next(), (a, b) -> {
                headA = a;
                headB = b;
                state = State.ITERATING;
                return (Void)null;
            }).thenCompose(__ -> next());
        case ITERATING:
            if (headA != null || headB != null) {
                if (headA == null || headB != null && headA > headB) {
                    final Integer result = headB;
                    return inputB.next().thenApply(b -> { // thenCompose 某个值 <=> thenApply
                        headB = b;
                        return result;
                    });
                } else {
                    final Integer result = headA;
                    return inputA.next().thenApply(a -> { // 同上
                        headA = a;
                        return result;
                    });
                }
            } else {
                state = State.DONE;
                return CompletableFuture.completedFuture(null);
            }
        case DONE:
            throw new IllegalStateException("Generator has been exhausted!");
        default:
            throw new AssertionError("Unreachable!");
        }
    }
}

总结

任何函数都可以用 CompletableFuture 实现异步化，最通用的方式如下：

1. 在函数里加上 yield（返回下一个结果）和await（等待输入值）来标记断点；
2. 画出控制流图，注意要在 yield 和 await处断开，断开处标记为状态；
3. 实现一个状态机类，把控制流图中的代码块、状态都无脑填进去，搞定。

这一刻，我们都是（人肉）编译器。

近期尝试在搬砖专用语言 Java上实现异步，起因和过程就不再详述了，总而言之，心中一万头草泥马奔过。但这个过程也没有白白浪费，趁机回顾了一下各种异步编程的实现。

这篇文章会涉及到回调、Promise、反应式、async/await、用户态线程等异步编程的实现方案。如果你熟悉它们中的一两种，那应该也能很快理解其他几个。

为什么需要异步？

操作系统可以看作是个虚拟机（VM），进程生活在操作系统创造的虚拟世界里。进程不用知道到底有多少core多少内存，只要进程不要索取的太过分，操作系统就假装有无限多的资源可用。

基于这个思想，线程（Thread）的个数并不受硬件限制：你的程序可以只有一个线程、也可以有成百上千个。操作系统会默默做好调度，让诸多线程共享有限的CPU 时间片。这个调度的过程对线程是完全透明的。

那么，操作系统是怎样做到在线程无感知的情况下调度呢？答案是上下文切换（ContextSwitch），简单来说，操作系统利用软中断机制，把程序从任意位置打断，然后保存当前所有寄存器——包括最重要的指令寄存器PC 和栈顶指针 SP，还有一些线程控制信息（TCB），整个过程会产生数个微秒的overhead。

然而作为一位合格的程序员，你一定也听说过，线程是昂贵的：

• 线程的上下文切换有不少的代价，占用宝贵的 CPU 时间；
• 每个线程都会占用一些（至少 1 页）内存。

这两个原因驱使我们尽可能避免创建太多的线程，而异步编程的目的就是消除IO wait阻塞——绝大多数时候，这是我们创建一堆线程、甚至引入线程池的罪魁祸首。

Continuation

回调函数知道的人很多，但了解 Continuation 的人不多。Continuation有时被晦涩地翻译成“计算续体”，咱们还是直接用单词好了。

把一个计算过程在中间打断，剩下的部分用一个对象表示，这就是Continuation。操作系统暂停一个线程时保存的那些现场数据，也可以看作一个Continuation。有了它，我们就能在这个点接着刚刚的断点继续执行。

打断一个计算过程听起来很厉害吧！实际上它每时每刻都在发生——假设函数f() 中间调用了 g()，那 g()运行完成时，要返回到 f() 刚刚调用 g()的地方接着执行。这个过程再自然不过了，以至于所有编程语言（汇编除外）都把它掩藏起来，让你在编程中感觉不到调用栈的存在。

操作系统用昂贵的软中断机制实现了栈的保存和恢复。那有没有别的方式实现Continuation呢？最朴素的想法就是，把所有用得到的信息包成一个函数对象，在调用g() 的时候一起传进去，并约定：一旦 g()完成，就拿着结果去调用这个 Continuation。

这种编程模式被称为 Continuation-passing style（CPS）：

1. 把调用者 f() 还未执行的部分包成一个函数对象cont，一同传给被调用者 g()；
2. 正常运行 g() 函数体；
3. g() 完成后，连同它的结果一起回调cont，从而继续执行 f() 里剩余的代码。

再拿 Wikipedia 上的定义巩固一下：

A function written in continuation-passing style takes an extraargument: an explicit "continuation", i.e. a function of one argument.When the CPS function has computed its result value, it "returns" it bycalling the continuation function with this value as the argument.

CPS 风格的函数带一个额外的参数：一个显式的Continuation，具体来说就是个仅有一个参数的函数。当 CPS函数计算完返回值时，它“返回”的方式就是拿着返回值调用那个Continuation。

你应该已经发现了，这也就是回调函数，我只是换了个名字而已。

异步的朴素实现：Callback

光有回调函数其实并没有卵用。对于纯粹的计算工作，Call Stack就很好，为何要费时费力用回调来做 Continuation 呢？你说的对，但仅限于没有IO 的情况。我们知道 IO 通常要比 CPU 慢上好几个数量级，在 BIO中，线程发起 IO 之后只能暂停，然后等待 IO 完成再由操作系统唤醒。

1
2
3

var input = recv_from_socket()  // Block at syscall recv()
var result = calculator.calculate(input)
send_to_socket(result) // Block at syscall send()

而异步 IO 中，进程发起 IO 操作时也会一并输入回调（也就是Continuation），这大大解放了生产力——现场无需等待，可以立即返回去做其他事情。一旦IO 成功后，AIO 的 Event Loop会调用刚刚设置的回调函数，把剩下的工作完成。这种模式有时也被称为 Fireand Forget。

1
2
3
4

recv_from_socket((input) -> {
    var result = calculator.calculate(input)
    send_to_socket(result) // ignore result
})

就这么简单，通过我们自己实现的 Continuation，线程不再受 IO阻塞，可以自由自在地跑满 CPU。

一颗语法糖：Promise

回调函数哪里都好，就是不大好用，以及太丑了。

第一个问题是可读性大大下降，由于我们绕开操作系统自制Continuation，所有函数调用都要传入一个 lambda表达式，你的代码看起来就像要起飞一样，缩进止不住地往右挪（the "CallbackHell"）。

第二个问题是各种细节处理起来很麻烦，比如，考虑下异常处理，看来传一个Continuation 还不够，最好再传个异常处理的 callback。

Promise 是对异步调用结果的一个封装，在 Java 中它叫作CompletableFuture (JDK8) 或者 ListenableFuture (Guava)。Promise有两层含义：

第一层含义是：我现在还不是真正的结果，但是承诺以后会拿到这个结果。这很容易理解，异步的任务迟早会完成，调用者如果比较蠢萌，他也可以用Promise.get()强行要拿到结果，顺便阻塞了当前线程，异步变成了同步。

第二层含义是：如果你（调用者）有什么吩咐，就告诉我好了。这就有趣了，换句话说，回调函数不再是传给g()，而是 g() 返回的Promise，比如之前那段代码，我们用 Promise 来书写，看起来顺眼了不少。

1
2
3
4
5

var promise_input = recv_from_socket()
promise_input.then((input) -> {
    var result = calculator.calculate(input)
    send_to_socket(result) // ignore result
})

Promise 改善了 Callback的可读性，也让异常处理稍稍优雅了些，但终究是颗语法糖。

反应式编程

反应式（Reactive）最早源于函数式编程中的一种模式，随着微软发起ReactiveX 项目并一步步壮大，被移植到各种语言和平台上。Reactive 最初在GUI编程中有广泛的应用，由于异步调用的高性能，很快也在服务器后端领域遍地开花。

Reactive 可以看作是对 Promise 的极大增强，相比Promise，反应式引入了流（Flow）的概念。ReactiveX中的事件流从一个 Observable 对象流出，这个对象可以是一个按钮，也可以是Restful API，总之，它能被外界触发。与 Promise不同的是，事件可能被触发多次，所以处理代码也会被多次调用。

一旦允许调用多次，从数据流动的角度看，事实上模型已经是 Push而非Pull。那么问题来了，如果调用频率非常高，以至于我们处理速度跟不上了怎么办？所以RX 框架又引入了 Backpressure 机制来进行流控，最简单的流控方式就是：一旦buffer 满，就丢弃掉之后的事件。

ReactiveX框架的另一个优点是内置了很多好用的算子，比如：merge（Flow合并），debounce（开关除颤）等等，方便了业务开发。下面是一个RxJava 的例子：

CPS 变换：Coroutine 与async/await

无论是反应式还是 Promise，说到底仍然没有摆脱手工构造Continuation：开发者要把业务逻辑写成回调函数。对于线性的逻辑基本可以应付自如，但是如果逻辑复杂一点呢？（比如，考虑下包含循环的情况）

有些语言例如 C#，JavaScript 和 Python 提供了 async/await关键字。与 Reactive 一样，这同样出自微软 C#语言。在这些语言中，你会感到前所未有的爽感：异步编程终于摆脱了回调函数！唯一要做的只是在异步函数调用时加上await，编译器就会自动把它转化为协程（Coroutine），而非昂贵的线程。

魔法的背后是 CPS 变换，CPS 变换把普通函数转换成一个 CPS的函数，即 Continuation也能作为一个调用参数。函数不仅能从头运行，还能根据 Continuation的指示继续某个点（比如调用 IO 的地方）运行。

例子可以参见我的下一篇文章。由于代码太长，就不贴在这儿了。

可以看到，函数已经不再是一个函数了，而是变成一个状态机。每次call 它、或者它 call其他异步函数时，状态机都会做一些计算和状态轮转。说好的 Continuation在哪呢？就是对象自己（this）啊。

CPS 变换实现非常复杂，尤其是考虑到 try-catch之后。但是没关系，复杂性都在编译器里，用户只要学两个关键词即可。这个特性非常优雅，比Java 那个废柴的 CompletableFuture不知道高到哪去了。（更新：也没有那么废柴啦）

JVM 上也有一个实现：electronicarts/ea-async，原理和C# 的 async/await 类似，在编译期修改 Bytecode 实现 CPS 变换。

终极方案：用户态线程

有了async/await，代码已经简洁很多了，基本上和同步代码无异。是否有可能让异步代码和同步代码完全一样呢？听起来就像免费午餐，但是的确可以做到！

用户态线程的代表是 Golang。JVM 上也有些实现，比如 Quasar，不过因为JDBC、Spring 这些周边生态（它们占据了大部分 IO操作）的缺失基本没有什么用。

用户态线程是把操作系统提供的线程机制完全抛弃，换句话说，不去用这个VM 的虚拟化机制。比如硬件有 8 个核心，那就创建 8 个系统线程，然后把 N个用户线程调度到这 8 个系统线程上跑。N个用户线程的调度在用户进程里实现，由于一切都在进程内部，切换代价要远远小于操作系统Context Switch。

另一方面，所有可能阻塞系统级线程的事情，例如sleep()、recv()等，用户态线程一定不能碰，否则它一旦阻塞住也就带着那 8个系统线程中的一个阻塞了。Go Runtime接管了所有这样的系统调用，并用一个统一的 Event loop 来轮询和分发。

另外，由于用户态线程很轻量，我们完全没必要再用线程池，如果需要开线程就直接创建。比如Java 中的 WebServer 几乎一定有个线程池，而 Go 可以给每个请求开辟一个goroutine 去处理。并发编程从未如此美好！

总结

以上方案中，Promise、Reactive本质上还是回调函数，只是框架的存在一定程度上降低了开发者的心智负担。而async/await和用户态线程的解决方案要优雅和彻底的多，前者通过编译期的 CPS变换帮用户创造出 CPS式的函数调用；后者则绕开操作系统、重新实现一套线程机制，一切调度工作由Runtime 接管。

不知道是不是因为历史包袱太重，Java语言本身提供的异步编程支持弱得可怜，即便是 CompletableFuture 还是在 Java8 才引入，其后果就是很多库都没有异步的支持。虽然 Quasar在没有语言级支持的情况下引入了 CPS变换，但是由于缺少周边生态的支持，实际很难用在项目中。

References

1. Howlong does it take to make a context switch?
2. ReactiveX
3. 考不上三本也能给自己心爱的语言加上Coroutine
4. Quasar
5. The Goscheduler
6. CallbacksVS Promises VS Async/Await

代码生成（CodeGeneration）技术广泛应用于现代的数据系统中。代码生成是将用户输入的表达式、查询、存储过程等现场编译成二进制代码再执行，相比解释执行的方式，运行效率要高得多。尤其是对于计算密集型查询、或频繁重复使用的计算过程，运用代码生成技术能达到数十倍的性能提升。

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

@Override public Object visitPlus(CalculatorParser.PlusContext ctx) {
    Object left = visit(ctx.plusOrMinus());
    Object right = visit(ctx.multOrDiv());
    if (left instanceof Long && right instanceof Long) {
        return (Long) left + (Long) right;
    } else if (left instanceof Long && right instanceof Double) {
        return (Long) left + (Double) right;
    } else if (left instanceof Double && right instanceof Long) {
        return (Double) left + (Long) right;
    } else if (left instanceof Double && right instanceof Double) {
        return (Double) left + (Double) right;
    }
    throw new IllegalArgumentException();
}

1
2
3

@Override public AlgebraNode visitPlus(CalculatorParser.PlusContext ctx) {
    return new PlusNode(visit(ctx.plusOrMinus()), visit(ctx.multOrDiv()));
}

1
2
3
4
5

public interface AlgebraNode {
    DataType getType(); // Validate 和 CodeGen 都会用到
    String generateCode(); // CodeGen 使用
    List<AlgebraNode> getInputs();
}

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

@Override public DataType getType() {
    if (dataType == null) {
        dataType = inferTypeFromInputs();
    }
    return dataType;
}

private DataType inferTypeFromInputs() {
    for (AlgebraNode input : getInputs()) {
        if (input.getType() == DataType.DOUBLE) {
            return DataType.DOUBLE;
        }
    }
    return DataType.LONG;
}

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

@Override public String generateCode() {
    if (getLeft().getType() == DataType.DOUBLE && getRight().getType() == DataType.DOUBLE) {
        return "(" + getLeft().generateCode() + " + " + getRight().generateCode() + ")";
    } else if (getLeft().getType() == DataType.DOUBLE && getRight().getType() == DataType.LONG) {
        return "(" + getLeft().generateCode() + " + (double)" + getRight().generateCode() + ")";
    } else if (getLeft().getType() == DataType.LONG && getRight().getType() == DataType.DOUBLE) {
        return "((double)" + getLeft().generateCode() + " + " + getRight().generateCode() + ")";
    } else if (getLeft().getType() == DataType.LONG && getRight().getType() == DataType.LONG) {
        return "(" + getLeft().generateCode() + " + " + getRight().generateCode() + ")";
    }
    throw new IllegalStateException();
}

1

(((double)(a + (2 * 3)) - ((double)2 / x)) + java.lang.Math.log((x + (double)1)))

1
2
3
4

ExpressionEvaluator evaluator = new ExpressionEvaluator();
evaluator.setParameters(parameterNames, parameterTypes); // 输入参数名及类型
evaluator.setExpressionType(rootNode.getType() == DataType.DOUBLE ? double.class : long.class); // 输出类型
evaluator.cook(code); // 编译代码

1
2
3
4
5

class MyGeneratedClass {
    public double calculate(long a, double x) {
        return (((double)(a + (2 * 3)) - ((double)2 / x)) + java.lang.Math.log((x + (double)1)));
    }
}

1

Object result = evaluator.evaluate(parameterValues);

于是问题来了，怎样定义一个 Rule的优先级？论文中并没有给出答案。Calcite 代码中为此定义了 Importance的概念。然而相关的资料非常少，本文总结一下我自己的猜测和理解，如果你有不同的观点，欢迎留言讨论。

术语

本文假设读者已经充分理解 Volcano 优化器。对以下概念有疑问的，请参考Valcano/Cascades 原论文。

• RelSet 描述一组逻辑上相等的 RelationExpression
• RelSubset 描述一组物理上相等的 RelationExpression，即具有相同的 Physical Properties
• RuleMatch 描述一次成功的匹配，包含 Rule和被匹配的节点
• Importance 描述 RuleMatch的重要程度，越大越应该优先处理

基本原则

为了能在短时间内得到一个较优解，我们的基本原则是：尽量对代价大的做优化，从而尽可能在有限的优化次数内获得更大的收益。这又可以分成三个方面来说：

1. 优先应用 Transformation Rules 生成各式各样的关系表达式（即优先进行explore 过程）；
2. 一般来说，父节点比子节点数据量更大，所以优先处理父节点；
3. 同级的节点中，代价大的一边应该得到更多的优化。

为了达成 1，我们只要把逻辑算子的代价设为无穷大即可。为了达成2、3，我们将 importance 和 cost 关联起来——简单来说就是 cost越大、importance 也越大。

实现分析

原理上说，RuleQueue 是一个优先队列，包含当前所有可行的RuleMatch，findBestExpr()时每次循环中我们从中取出优先级最高的并 apply，再根据 apply的结果更新队列……如此往复，直到满足终止条件。

但因为性能原因，实际上 RuleQueue没有使用最大堆之类的数据结构，而是每次选出 importance最大的那个。这是因为经常需要对 RelSubset 的 importance做大量调整，用最大堆处理得不偿失。

RuleMatch 的 importance 定义为以下两个中比较大的一个：

1. 输入的 RelSubset 的 importance
2. 输出的 RelSubset 的 importance

以上参考 VolcanoRuleMatch:computeImportance

那 RelSubset 的 importance 如何决定？这边的实现比较 tricky：RuleQueue的成员变量 subsetImportances 中保存了各个 RelSubset 的importance，但这并不是 getImportance()返回的结果。为了区分清楚，我们把 getImportance()返回的结果称为调整后的 importance，把 subsetImportances里存的值称为真实 importance。

调整后的 importance定义为以下两个中比较大的一个：

• 该 RelSubset 本身的真实 importance
• 逻辑上相等的（即位于同一个 RelSet 中）任意一个 RelSubset 的真实importance 除以 2

之所以要这么做，注释中的解释是让 Conversion 尽快发生。

以上参考 RuleQueue:getImportance(RelSubset)

下一个问题，真实 importance 怎么计算呢？

• 根节点的 importance 始终是 1.0
• 否则，假设它父节点的代价是 \(c_{parent}\)，这个节点本身的代价是 \(c_{child}\)，则定义节点本身的 \(I_{child} =\frac{c_{child}}{c_{parent}}I_{parent}\)

这里说的 cost 是 RelSubset 的 cost，也就是当前这个 RelSubset 的中最佳Physical Plan 的 cost。DP 算法会保留每个 RelSubset 的最佳 plan 以及对应cost。

以上参考 RuleQueue:computeImportance(RelSubset)

这个定义又引出了下面两个问题：

1. 如果一个 RelSubset 里还没有 Physical Plan，那它的 cost是无穷大，怎么处理？

• 初始设置为 \(0.9^n\)，其中 \(n\) 是 RelSet 所在的层数（参考VolcanoPlanner:setInitialImportance）

• 其他时候，比例 \(\frac{c_{child}}{c_{parent}}\)限制最大不超过 \(0.99\)（参考RuleQueue:computeImportanceOfChild）

PS. 理论上只要是一个小于 1的系数都可以，不知道为什么这里两个系数不一样。

2. 如果某个 RelSubset 的 cost 降低了（例如找到了一种 PhysicalPlan），那么 importance 也应该相应的被更新。

• 要更新的不仅是该 Plan 本身所在的一个或多个 RelSubset，还有可能是这些RelSubset 的父节点、父节点的父节点……所以这是一个向上递归的过程。（参考RelSubset:propagateCostImprovements）

References

1. TheVolcano Optimizer Generator: Extensibility and Efficient Search - GoetzGraefe
2. The Cascades Framework for Query Optimization - Goetz Graefe
3. Apache Calcite SourceCode