2024-05-18 08:00:00

在 Linux 中调用一个脚本有多种方式，例如 fork，exec 和 source。其中 fork 为 Linux 系统调用，exec 和 source 均为 bash 内部命令。下面以 parent.sh 和 child.sh 两个脚本演示不同调用方式的区别。

parent.sh 内容如下：

#!/bin/bash

echo "--------------------------------------------------"
echo "Before calling child.sh"
echo "--------------------------------------------------"
echo "PID for parent.sh: $$"

var="parent"
export var

echo "In parent.sh, set var=$var"
echo "In parent.sh, variable var=$var"

echo "--------------------------------------------------"
case $1 in
    exec)
        echo "Call child.sh using exec"
        exec ./child.sh ;;
    source)
        echo "Call child.sh using source"
        source ./child.sh ;;
    *)
        echo "Call child.sh using fork"
        ./child.sh ;;
esac

echo "After calling child.sh"
echo "--------------------------------------------------"
echo "PID for parent.sh: $$"
echo "In parent.sh, variable var=$var"
echo "--------------------------------------------------"

child.sh 内容如下：

#!/bin/bash

echo "--------------------------------------------------"
echo "PID for child.sh: $$"
echo "In child.sh, variable var=$var from parent.sh"

var="child"
export var

echo "In child.sh, set var=$var"
echo "In child.sh, variable var=$var"
echo "--------------------------------------------------"

为了确保脚本可执行，需为其添加执行权限：

chmod +x parent.sh child.sh

fork

fork 通过进程复制来创建一个新进程，新进程称为子进程，当前进程称为父进程。在 fork 之后，子进程拥有父进程的副本，但两者的 PID 不同，同时子进程也拥有父进程的所有属性，例如：环境变量、打开的文件描述符等。

通过 fork 调用是最普遍的方式。在当前终端中通过 ./run.sh 执行时，终端会新建一个子 shell 执行 run.sh，子 shell 执行时，父 shell 仍在运行，当子 shell 运行完毕后会返回父 shell。

运行如下命令进行 fork 方式调用测试：

./parent.sh fork

测试结果如下：

--------------------------------------------------
Before calling child.sh
--------------------------------------------------
PID for parent.sh: 7149
In parent.sh, set var=parent
In parent.sh, variable var=parent
--------------------------------------------------
Call child.sh using fork
--------------------------------------------------
PID for child.sh: 7150
In child.sh, variable var=parent from parent.sh
In child.sh, set var=child
In child.sh, variable var=child
--------------------------------------------------
After calling child.sh
--------------------------------------------------
PID for parent.sh: 7149
In parent.sh, variable var=parent
--------------------------------------------------

exec

exec 与 fork 不同，其不需要开启一个新的 shell 执行子脚本。使用 exec 执行一个新脚本后，父脚本中 exec 后的内容将不再执行。

运行如下命令进行 exec 方式调用测试：

./parent.sh exec

测试结果如下：

--------------------------------------------------
Before calling child.sh
--------------------------------------------------
PID for parent.sh: 9629
In parent.sh, set var=parent
In parent.sh, variable var=parent
--------------------------------------------------
Call child.sh using exec
--------------------------------------------------
PID for child.sh: 9629
In child.sh, variable var=parent from parent.sh
In child.sh, set var=child
In child.sh, variable var=child
--------------------------------------------------

source

source 同 exec 类似，也不需要开启一个新的 shell 执行子脚本。使用 source 执行一个新脚本后，父脚本中 source 后的内容可以继续执行。

运行如下命令进行 source 方式调用测试：

./parent.sh source

测试结果如下：

--------------------------------------------------
Before calling child.sh
--------------------------------------------------
PID for parent.sh: 10274
In parent.sh, set var=parent
In parent.sh, variable var=parent
--------------------------------------------------
Call child.sh using source
--------------------------------------------------
PID for child.sh: 10274
In child.sh, variable var=parent from parent.sh
In child.sh, set var=child
In child.sh, variable var=child
--------------------------------------------------
After calling child.sh
--------------------------------------------------
PID for parent.sh: 10274
In parent.sh, variable var=child
--------------------------------------------------

2024-05-12 08:00:00

输入输出文件描述符

在 Linux 启动后，init 进程会创建 3 个特殊的文件描述符分配给输入输出。

默认情况下，程序经由标准输入（stdin）从键盘读取数据，并将标准输出（stdout）和标准错误（stderr）显示在屏幕上。

在 Linux 中，init 是所有进程的父进程，所有子进程均会继承父进程的文件描述符。因此在 Linux 中执行的所有程序都可以从 stdin 获取输入，并将结果打印到 stdout 中，同时将错误信息打印到 stderr 中。

重定向

当我们不希望从键盘获取标准输入或将标准输出和标准错误显示在屏幕上时，则需要采用重定向。

输出重定向

输出重定向的使用方式如下：

cmd [1-n]> [文件/文件描述符/设备等]

假设当前目录下存在一个名为 yes.txt 的文件，且不存在名为 no.txt 的文件。执行如下命令：

ls yes.txt no.txt

由于 yes.txt 存在，这部分结果将输出到 stdout，同时由于 no.txt 不存在，这部分结果将输出到 stderr。命令的输出结果为：

ls: cannot access 'no.txt': No such file or directory
yes.txt

执行如下命令：

ls yes.txt no.txt 1> success.log 2> fail.log

此时屏幕上将不再显示任何信息，当前目录下会生成 success.log 和 fail.log 两个文件。其中 1> success.log 表示将 stdout 重定向至 success.log，2> fail.log 表示将 stderr 重定向至 fail.log。因此 success.log 中的内容为 yes.txt，fail.log 中的内容为 ls: cannot access 'no.txt': No such file or directory。

重定向过程中，stdout 的文件描述符 1 可以省略，但 stderr 的文件描述符 2 不可以省略。因此，当只重定向 stdout 时，可简写为：

ls yes.txt no.txt > success.log

此时屏幕上依旧会显示 stderr 的内容 ls: cannot access 'no.txt': No such file or directory，而 stdout 的内容则被重定向至 success.log 文件中。

在 Linux 中 &- 和 /dev/null 是两个特殊的输出设备，均表示为空，输出到该设备相当于抛弃输出。因此如下两行命令分别会抛弃 stdout 和 stderr 的内容：

ls yes.txt no.txt 1>&-
ls yes.txt no.txt 2> /dev/null

& 可以表示当前进程中已经存在的描述符，&1 表示 stdout，&2 表示 stderr。因此我们可以将 stdout 和 stderr 重定向到相同文件：

ls yes.txt no.txt > out.log 2> out.log
ls yes.txt no.txt > out.log 2>&1

在上述两种方式中，第一种会导致 out.log 文件被打开两次，stdout 和 stderr 内容会相互覆盖。第二种由于 stderr 重定向给了 stdout，stdout 重定向给了 out.log，因此 out.log 仅被打开了一次。

使用 > 进行输出重定向时会先判断文件是否存在，如果存在会先删除再创建，不存在则直接创建，无论命令是否执行成功均会创建。使用 >> 进行重定向时，如果文件存在则会以添加方式打开，不存在则直接创建。

输入重定向

输入重定向的使用方式如下：

cmd [1-n]< [文件/文件描述符/设备等]

例如：

cat > out.txt < in.txt

此时命令将从 in.txt 文件中获取输入而非 stdin，并将结果重定向到 out.txt 文件中。

Here Document

Here Document 是一种特殊的重定向方式，可以用来将多行输入传递给命令，使用方式如下：

cmd << delimiter
    ...
delimiter

这会将中间的内容 ... 传递给命令。需要注意结尾处的 delimiter 的前后均不能包含任何字符，起始处的 delimiter 的前后空白字符将被忽略。最为常用的 delimiter 为 EOF，但这不是必须的，例如：

wc -l << SOMETHING
第一行
第二行
第三行
SOMETHING

上述命令的输出结果为：

3

管道

管道 | 可以将一个命令的 stdout 作为下一个命令的 stdin 使用，但无法对 stderr 进行处理。因此管道也可以理解为重定向的一种特殊形式。

假设存在一个如下内容的 test.txt 文档：

Here is a test in line 1.
Here is another test in line 2.
Here is something else in line 3.

利用如下命令可以过滤出包含 test 字符的行并显示行号：

cat test.txt | grep -n "test"

上述命令的输出结果为：

1:Here is a test in line 1.
2:Here is another test in line 2.

如果希望同时将 stdout 和 stderr 重定向到下一个命令的 stdin，可以采用如下方式：

ls yes.txt no.txt 2>&1 | grep "No such file or directory"

上述命令的输出结果为：

ls: no.txt: No such file or directory

上述命令也可以简写为：

ls yes.txt no.txt |& grep "No such file or directory"

2024-04-14 08:00:00

随着深度神经网络模型的复杂度越来越高，除了训练阶段需要大量算力外，模型推理阶段也较多的资源。在深度学习落地应用中，受部署环境的影响，尤其是在边缘计算场景中，有限的计算资源成为了复杂模型的应用壁垒。

复杂模型的部署问题突出表现在三个方面，如下图所示：

1. 速度：实时响应效率的要求，过长的响应耗时会严重影响用户体验。
2. 存储：有限的内存空间要求，无法加载超大模型的权重从而无法使用模型。
3. 能耗：移动场景的续航要求，大量的浮点计算导致移动设备耗电过快。

针对上述三类问题，可以从模型压缩和推理加速两个角度出发，在保持一定模型精度的情况下，让模型速度更快、体积更小、能耗更低。

模型压缩

常用的模型压缩方法有如下几种类型：

剪裁

剪裁（Pruning）的核心思想是在尽量保持模型精度不受影响的前提下减少网络的参数量，例如减少网络中连接或神经元的数量，如下图所示：

剪裁最常用的步骤如下：

1. 训练：在整个剪裁过程中，该步骤主要为预训练过程，同时为后续的剪裁工作做准备。
2. 修剪：通过具体的方法对网络进行剪裁，并对网络重新进行评估以确定是否符合要求。
3. 微调：通过微调恢复由于剪裁对模型带来的性能损耗。

对网络进行剪裁的具体方法可以分为非结构化剪裁和结构化剪裁。

非结构化剪裁是细粒度的剪裁方法，一般通过设定一个阈值，高于该阈值的权重得以保留，低于该阈值的权重则被去除。非结构化剪裁虽然方法简单、模型压缩比高，但也存在诸多问题。例如：全局阈值设定未考虑不同层级的差异性，剪裁信息过多有损模型精度且无法还原，剪裁后的稀疏权重矩阵需要硬件层支持方可实现压缩和加速的效果等。

结构化剪裁是粗粒度的剪裁方法，例如对网络层、通道、滤波器等进行剪裁。在滤波器剪裁中，通过评估每个滤波器的重要性（例如：Lp 范数）确定是否保留。结构化剪裁算法相对复杂、控制精度较低，但剪裁策略更为有效且不需要硬件层的支持，可以在现有深度学习框架上直接应用。

量化

神经网络中的计算通常采用浮点数（FP32）进行计算，量化（Quantization）的基本思想是将浮点计算替换为更低比特（例如：FP16，INT8 等）的计算，从而降低模型体积加快模型推理速度。

数值的量化可以看做一个近似过程，主要可以分为两类：

1. 定点近似：通过缩小浮点数表示中指数部分和小数部分的位宽实现。映射过程不需要额外的参数，实现相对简单，但针对较大数值的精度损失较大。
2. 范围近似：通过统计分析，经过缩放和平移映射浮点数。映射过程需要存储额外的参数，计算时需要先反量化，计算相对复杂，但精度更高。

范围近似又可以分为线性映射和非线性映射两种。

线性映射将浮点数映射到量化空间时采用如下计算公式：

$$ \begin{aligned} r &= S \left(q - Z\right) \\ q &= round \left(\dfrac{r}{S} + Z\right) \end{aligned} $$

其中，$r, q$ 分别表示量化前和量化后的值，$S, Z$ 为量化系数。一般化的非对称映射如下图所示：

其中，

$$ \begin{aligned} S &= \dfrac{r_{max} - r_{min}}{q_{max} - q_{min}} \\ Z &= q_{min} - \dfrac{r_{min}}{S} \end{aligned} $$

非线性映射考虑了数据本身的分布情况。以分位量化方法为例，其基本思想是通过分位点对数据进行划分，使得各个区间之间的数据量相等，然后将同一个区间的数据映射为相同值，从而实现量化。

量化粒度是指控制多少个待量化的参数共享一组量化系数，通常粒度越大，精度损失越大。以 Transformer 模型为例，不同粒度的量化方式如下图所示：

其中，$d$ 为模型大小与隐层维度之比，$h$ 为多头自注意中的头数。

模型量化分为两种：

1. 权重量化：即对网络中的权重执行量化操作。数值范围与输入无关，量化相对容易。
2. 激活量化：即对网络中不含权重的激活类操作进行量化。输出与输入有关，需要统计数据动态范围，量化相对困难。

根据是否进行训练可以将量化方法分为两大类，如下图所示：

1. 训练后量化（Post Traning Quantization，PTQ）：方法简单高效，无需重新训练模型。根据是否量化激活又分为：
   • 动态：仅量化权重，激活在推理阶段量化，无需校准数据。
   • 静态：量化权重和激活，需要校准数据。
2. 量化感知训练（Quantization Aware Traning，QAT）：方法相对复杂，需要在模型中添加伪量化节点模拟量化，需要重新训练模型。

三种不同量化方法之间的差异如下图所示：

神经结构搜索

神经结构搜索（Network Architecture Search，NAS）旨在以一种自动化的方式，解决高难度的复杂神经网络设计问题。根据预先定义的搜索空间，神经结构搜索算法在一个庞大的神经网络集合中评估结构性能并寻找到表现最佳的网络结构。整个架构如下图所示：

近年来基于权重共享的结构搜索方法受到广泛关注，搜索策略和性能评估高度相关，因此两者往往合为一体表示。

搜索空间包含了所有可搜索的网络结构，越大的搜索空间可以评估更多结构的性能，但不利于搜索算法的收敛。搜索空间从搜索方式角度分为两种：

1. 全局搜索空间：通过链式、跳跃链接、分支等方式搜索整个网络结构。
2. 基于结构单元的搜索空间：仅搜索结构单元，减少搜索代价，提高结构的可迁移性。

搜索策略即如何在搜索空间根据性能评估选择最优的网络结构。具体包含随机搜索、贝叶斯优化、进化算法、强化学习和基于梯度的方法。

性能评估最简单的方法就是对数据划分验证集，针对不同的网络结构重新训练并评估其在验证集上的表现。但这种方法所需的计算成本很高，无法在实践中落地应用。一些基于权重共享的结构搜索方法能够一定程度地加速搜索，因此考虑搜索策略和性能评估任务的相关性，在当前架构中往往将这两部分统一表述为搜索策略。

知识蒸馏

知识蒸馏（Knowledge Distillation，KD）是一种教师-学生（Teacher-Student）训练结构，通常是已训练好的教师模型提供知识，学生模型通过蒸馏训练来获取教师的知识。它能够以轻微的性能损失为代价将复杂教师模型的知识迁移到简单的学生模型中。

知识蒸馏架构如下图所示：

上半部分为教师模型，下半部分为学生（蒸馏）模型。将教师模型的输出作为软标签与学生模型的软预测计算蒸馏损失，将真实的硬标签与学生模型的硬预测计算学生损失，最终将两种损失结合训练学生模型。

论文 ¹ 给出了软标签的计算公式：

$$ q_i = \dfrac{\exp \left(z_i / T\right)}{\sum_j \exp \left(z_j / T\right)} $$

其中，$T$ 为温度系数，用来控制输出概率的软化程度。不难看出当 $T = 1$ 时，公式的输出即为网络输出 $Softmax$ 的类概率。$T$ 越大，$Softmax$ 的类概率分布越平滑，这可以让学生模型学习到教师模型对负标签的归纳信息。

参考

可供使用的模型压缩库有：

1. PyTorch：剪裁，量化，神经网络搜索，知识蒸馏
2. TensorFlow：剪裁，量化
3. PaddleSlim：支持剪裁、量化、神经网络搜索、知识蒸馏，适配 PaddlePaddle 框架。
4. PocketFlow：支持剪裁、量化，适配 TensorFlow 框架。
5. NNI：支持剪裁、量化、神经网络搜索，适配 TensorFlow、PyTorch 等框架。
6. TinyNeuralNetwork：支持剪裁、量化，适配 PyTorch 框架。
7. DeepSpeed：支持剪裁、量化，适配 PyTorch 框架。
8. Intel Neural Compressor：支持剪裁、量化、知识蒸馏，适配 TensorFlow、PyTorch、ONNX 等框架。
9. Neural Network Compression Framework：支持剪裁、量化，适配 TensorFlow、PyTorch、ONNX、OpenVINO 等框架。

推理加速

硬件加速

硬件加速是指将计算交由专门的硬件以获得更快的速度。在深度学习领域最简单的体现就是利用 GPU 进行推理会比利用 CPU 更快。除此之外，在给定的硬件环境中，利用针对性优化的推理框架可以更充分的利用硬件特性提升预测效率。

并行计算

并行计算是指将计算的过程分解成小部分，以并发方式运行实现计算效率的提升。在模型训练和推理阶段，主流的并行方式有：

1. 数据并行（Data Parallel）：将数据集切分为多份，每个设备负责其中一部分。
2. 流水线并行（Pipeline Parallel）：将模型纵向拆分，每个设备只包含模型的部分层，数据在一个设备完成计算后传递给下一个设备。
3. 张量并行（Tensor Parallel）：将模型横向拆分，将模型的每一层拆分至不同设备，每一层计算都需要多个设备合作完成。

参考

可供使用的推理加速库有：

本文未对模型压缩和推理加速进行深入展开，仅作为工业实践的基础概念解释。本文参考了大量前人之作，在此一并引用 ^{2 3 4 5 6 7}。

2024-02-09 08:00:00

编程语言「只是」达成目标的工具，这是我一直推崇的说法，因为我认为达成目标更重要的在于个人思考，编程语言不过是个「工具」，选哪个并没有那么重要。现在我越来越认为这个「工具」的选择还是很重要的，因为编程语言之于目标实现的可能性和效率都制约了目标的最终达成。

以个人数据科学的工作背景，结合我的编程语言学习路径，尝试回答一下我们需要多少种编程语言这个问题。我的编程语言学习路径大致如下：

• 小学时代：Logo
• 初高中时代：Basic，HTML，CSS
• 本科时代：C，C++
• 研究生时代：Matlab，R，Python，SQL
• 工作时代：Markdown，Java，JavaScript，TypeScript，Rust

语言分类

在我的编程语言学习路径中，各个编程语言之间还是存在很大差异的，以最早接触的 Logo 为例，其除了教学目的之外似乎就真的没有什么大用途了。这些编程语言可以大致划分为如下三种类型：

• 通用编程语言（General-purpose Programming Language，GPL）：Basic，C，C++，Python，JavaScript，TypeScript，Java，Rust
• 领域特定语言（Domain-Specific Language，DSL）：Logo，CSS，Matlab，R，SQL
• 标记语言（Markup Language）：HTML，Markdown

领域特定语言和标记语言就不用多说了，其应用范围有限。通用编程语言虽然定义为通用，但各自也有擅长和不擅长的领域，需要针对实际场景进行选择。

领域偏好

领域偏好是指你所从事的领域内大家对编程语言的使用偏好，这对于语言的选择至关重要，因为靠一己之力改变领域内大多数人的选择还是相当有难度的，从众可以极大地充分利用前人的成果降低工作的成本。

数据科学

数据科学可选的编程语言有 Python、R 和 Matlab 等，从技多不压身的角度出发肯定是掌握的越多越好，但精力终归是有限的。Matlab 在版权、仿真等方面具有一定的特殊性，Python 和 R 在数据科学中的竞争可谓是旷日持久，相关对比也数不胜数 ^{1 2 3}。

如果非要二选一我现在会选择 Python，因为其作为通用编程语言在将数据科学和工程代码结合时会展现出更多的优势。但在一些特定领域，例如生物信息学，R 的采用率会更高。一些新起之秀例如 Julia 和 Mojo 仍需要进一步观测其发展，过早地大面积使用新语言可能会面临各种风险。

后端

企业级后端应用中 Java 应该是首选，对一些高性能场景 C/C++、Rust 可能更加适合。

在实际工作中，Python 依旧可以作为一个不错的后端语言选择。Python 在 HTTP 和 RPC 接口、高并发、开源组件 SDK 支持等方面都不错的表现。Python 作为一种解释型语言，时常被诟病运行慢，这确实是解释型语言的一个问题。不过现在很多流行扩展包都是基于 C/C++ 构建，并且从 3.13 版本开始已经可选去除全局解释锁，这些都会使 Python 的性能变得越来越好。个人认为 Python 运行慢的另一个原因是使用者对其理解仍不够深入，使用的技巧仍有待提升，《流畅的 Python》可以让你对 Python 有更深入的认识。

前端

前端是程序与用户进行交互的必经之路，HTML，CSS 和 JavaScript 可以算得上前端三剑客了，分别负责元素的定义、样式和交互。随着 Node.js 的发展，JavaScript 也可以作为后端语言使用。TypeScript 作为 JavaScript 的超集，扩展了 JavaScript 的功能和特性，同时随着 React 和 Vue 框架的出现，前端的发展可谓是盛况空前。

Python 此时就真的很难插入一脚了，不过话无绝对，基于 WebAssembly 技术 Python 也可以在前端运行。WebAssembly 设计的目的是为了提升前端代码的运行效率，而在这方面从实践上 ⁴ 来看 Rust 更受青睐。

客户端

在 Apple 和 Google 两大移动阵营中，iOS（iPadOS 和 tvOS）系统的首选语言为 Swift，Android 系统的首选语言为 Kotlin。在 Apple 和 Microsoft 两大桌面阵营中，macOS 系统的首选语言为 Swift，Windows 系统的首选语言为 .Net。原生语言可以让应用更好的适配对应的系统，但引入的问题就是相同应用针对不同系统适配的成本增加。针对大公司的核心应用确实有这个必要，但是普通场景，「跨平台」则会更吸引人。

在之前的博客中有对桌面端的跨平台框架作简要分析，但结合当下移动端的市场占比，基于前端技术的跨平台解决方案会是一个不错的选择。

脚本

脚本可以说就只是程序员自己为了方便而产生的需求，不出意外它应该只会出现在命令行的黑框框中。在类 Unix 系统中，Shell 是一个通用且不需要额外安装扩展的不错之选。除此之外，什么 Python、Perl、Ruby、Lua 都在不同的场景中发光发热，相信我们将处于并将长期处于脚本语言的五代十国中。

嵌入式

早期的嵌入式我认为是一个相对专业垂直的领域，由于操作的对象更加底层，所以使用的语言也会更底层一些，例如 C/C++。随着硬件的不断发展，开发板、智能设备、机器人都在逐步走入更多程序员的视野，硬件性能的提升也使得 Python 等高级语言可以作为嵌入式开发的工具。

个人偏好

领域偏好是站在客观的角度指导我们如何选择语言，但谁还没有些小脾气呢？以自己为例，最早接触的数据分析语言是 Matlab，我的本科和研究生的论文都是用 Matlab 完成的，当时是由于实验室都在用它（领域偏好），但我个人并不很喜欢它。虽然上面我也承认在 Python 和 R 的大战中，如果非让我选一个我会选择 Python，但这也剥夺不了我对 R 的钟爱。R 的管道符 |> 用起来就是舒服，虽然 Python 第三方也提供了类似的扩展包 siuba，但模仿终归还是模仿。

在一定程度上坚持自己的个性还是可能会有些益处的。仍以自己为例，钟爱 R 的我在了解到 RMarkdown 之后让我喜欢上了可重复性研究（更多细节可参见之前的博客）。再到之后的 Quarto，最终我将这些内容融入工作之中，开发工作中适用的产品。可以说如果仅是基于领域偏好彻底拥抱 Python 而抛弃 R，那么我会错过不少优秀的项目和工具。还有不得不提的 ggplot2，图形语法的最好践行者，Python 中 Matlab 的遗留瑰宝 matplotlib 我只能说很强大但我不喜欢用，至于 Python 第三方提供的类似扩展包 plotnine，模仿终归还是模仿。

真实需要

聊了这么多，到底我们需要多少种编程语言？这取决于你到底想要啥？

如果想作为一个安分守己的数据科学工作者，Python 能撑起你 90% 的需求，多花一些时间去了解业务可能比你多学一门编程语言的收益要大得多。

如果你不够安分，不想深藏于后端，甚至有技术变现的想法，那么前端交互自然不可缺失。此时 JavaScript/TypeScript 应该是个不错的选择，毕竟你不是要成为一个专业的前端或 APP 开发人员，跨平台才应该是我们应该偏好的重点，毕竟一套代码处处可用，变现的速度就可以杠杠的了。

当然我相信除了眼前的这些苟且，大家还是有更远大抱负的，那么在这条布满荆棘的路上你会遇到更复杂的问题。性能的提升我会选择 Rust，毕竟人家除了能提升后端还能提升前端，何乐而不为呢？

综上所述，作为数据科学工作的从业者，我将以并将长期以如下四句作为我编程语言选择的重要指导方针：

2024-01-07 08:00:00

一画胜千言（A picture is worth a thousand words）是我个人很推崇的一个指引，不过前提是这得是一张「好图」，否则容易过犹不及。

数据可视化是一门复杂的学问，在动态文档生成中，秉承规范、统一和实用的理念，我认为是快速提高数据可视化质量的不错之选。

设计规范

在之前的文章「设计语言初探」中探讨过产品的设计语言，在此针对各大企业的数据可视化规范并结合中文文档生成和个人偏好做简要分析。各大企业的数据可视化规范如下：

各家的设计理念有所不同，但我相信其目标是一致的，就是让用户可以更好更快地理解数据并从数据中获取洞见。上面的大多数数据可视化规范依旧是以面向产品设计为主，不过我认为大部分理念是可以迁移到文档中的可视化，尤其是 HTML 格式的动态文档。

Apple、Google、Microsoft 三大家的规范在自家系统的平台上针对简单的可视化场景可以说是最适用的，毕竟原生设计毫无违和感。但针对复杂的可视化场景，三家并没有给出更细的指引，不过也能理解针对商业数据可视化和科技绘图等复杂场景，确实更适合由上层（例如：库、应用等）去根据实际情况作出相应规范。

所以，站在规范和统一的视角，我个人更倾向于选择适合中国宝宝体质的 Ant Vision。给出些我认为靠谱的理由：

1. 设计体系基于具有更悠久历史的 Ant Design 衍生，具有完善的设计规范指引。
2. 针对简单场景（例如：统计图表等）和复杂场景（例如：地图、关系图表等）都有较好的覆盖。
3. 科学的色彩体系，在萝卜青菜各有所爱的配色之上给到了科学的指引。
4. 最后也是我认为最重要的特点，开源，且有丰富的中文文档。

从规范和统一的角度，可以说 Ant Vision 是最优选择，有关 Ant Vision 的更多资料除了官网以外，还可以参见语雀上的 AntV 文档。

工具选择

由于是面向动态文档生成为主，基于各种可视化工具的绘图很难嵌入自动化流水线中，因此本节主要讨论相关扩展包，不涉及专用的可视化工具（例如：Tableau，Power BI 等）。常用的可视化扩展包及其支持的语言和图类型，如下表所示：

上述扩展包是我个人在实际项目中真实会使用到的，此时此刻就不难发现 Ant Vision 最大的问题就是对科学编程几乎 ⁷ 没有官方支持。

用于可视化的扩展包远不止上述的这 8 种，但我们不可能去学习使用所有的扩展包，这样于自己需要投入大量的学习成本，于团队也不利于项目的维护。即便就这 8 种扩展包，其语法也大不相同。

我接触的第一门绘图语言应该是 Logo，不过 Logo 是一门教学语言，所以在科学编程中使用的最早的是 Matlab 的绘图功能，Matplotlib 从名称上就不难看出是源自 Matlab。不过个人而言不是很喜欢 Matplotlib 的 API 风格，或者说我认为其 API 更偏底层一些。谈到这里就不得不谈一下「The Grammar of Graphics」，这也是我个人认为绘图「最舒服」的 ggplot2 扩展包背后的理论。在上述扩展包中，ggplot2 算是先驱者，plotnine 是 ggplot2 的 Python 复刻，Plotly 的 R 绑定可以支持直接将 ggplot2 对象绘制成 plotly 绘图，Ant Vision 则在该核心理论的基础上做了更多探索。所以当掌握了图形语法的理论基础后，对这些包的学习就相对会简单不少。由于长尾需求还是会存在，所以掌握不同可视化包的使用就成了技多不压身，我认为上述 8 种扩展包覆盖 99% 的可视化需求应该不成问题。

上述 8 种可视化包中，前 4 种都是以 JS/TS 库为基础，部分由官方或三方实现了 Python 和 R 的绑定，所以前 4 种天然就支持可交互绘图。利用 Python 的 Jupyter Widgets 和 R 的 htmlwidgets 实现在网页和 Notebook 中的可交互绘图。D3 背后的 Observable JS 也被当下流行的动态文档生成工具 quarto 所支持。后 4 种则只能创建不可交互的静态绘图，Matplotlib 作为 Python 绘图的重要可视化扩展包提供了丰富的绘图 API，seaborn 和 plotnine 均基于其开发，seaborn 简化了 API，plotnine 提供了 ggplot2 语法支持，而 ggplot2 则是 R 语言中数据可视化的不二之选。

讲了这么多并不是要在各个扩展包之间分个孰优孰劣，而是需要其特性和需求场景选择合适的扩展包。在此个人愚见如下：

1. 动态绘图：Plotly > ECharts > D3 > Ant Vision，理由：多语言支持优先。
2. 动态绘图（复杂场景，例如：地图、关系图等）：Ant Vision > D3 > ECharts > Plotly，理由：交互性能优先。
3. 静态绘图：ggplot2 = plotnine > seaborn > Matplotlib，理由：语法简单易于理解优先。
4. 静态绘图（长尾需求，例如：示意图等）Matplotlib，理由：较为底层的绘图 API，使用更为灵活。

实用建议

根据规范，为了保证利用不同的工具绘图的视觉效果一致，我们需要在布局、色板、字体等多个角度进行自定义配置。下表展示了扩展包在不用语言绑定中样式的可自定义特性：

其中，✅表示支持自定义样式，且支持修改全局默认样式；☑️表示支持自定义样式，不支持修改全局默认样式，但支持通过函数一次性设置自定义样式；❌表示支持自定义样式，但需要每次手动配置所有样式细节。

布局

在 Ant Vision 设计语言中一个图应该包含标题、轴、图形、标签、注解、提示信息、图例等信息，如下图所示：

大多数扩展包支持绝大多数元素，但对于一些相对特殊的元素（例如：注解，尤其是富文本的注解）支持较为有限。同时不同扩展包对于相同元素的样式控制也存在差异，这就导致很难将在不同扩展包之间做到完全统一，只能是尽可能相似。

色板

色板（配色）是影响统一的另一大重要因素，相比布局其更好做到不同扩展包之间的统一。根据 Ant Vision 的设计语言，色板分为：分类、顺序、发散、叠加、强调、语义共 6 大色板，如下图所示：

不同扩展包不一定能覆盖所有类型色板（视其绘图能力而定）。除了选择合适的统一色板之外，不同类型色板在使用时也有各自的注意事项，虽然这无关样式统一，但却会从很大程度上影响数据可视化的效果。

字体

根据 Ant Vision 的设计语言，数据可视化字体应当具备三个条件：数字等宽、识别度高、混排美观，如下图所示：

针对文档生成，个人总结了能够覆盖大部分文档场景且商用免费的字体，如下表所示：

为了满足 Ant Vision 对字体的要求，在 Word 和 PDF 格式文档中的静态绘图可以使用更纱黑体。针对 HTML 格式文档，由于不会内嵌字体，为了适配不同的操作系统同时考虑不同字体的可用性，可以将交互式绘图字体设置为多个值：

{
  font-family: Iosevka, 'Iosevka Nerd', Consolas, 'Lucida Console', Menlo, Monaco, 'Andale Mono', 'Ubuntu Mono', 'Source Han Mono SC', 'Source Han Mono TC', 'Source Han Mono', 'Noto Sans Mono SC', 'Noto Sans Mono TC', 'Noto Sans Mono', monospace, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol' !important;
}

尺寸 & 响应式

错误的尺寸选择或不良的元素位置摆放都会导致可视化效果变差。PDF 和 Word 格式文档，以及 PC 端的 HTML 格式文档，通过限制页面宽度，可以相对统一的规范到标准的可读内容宽度。此时图片的最大宽度是已知的，可视化时仅需要考虑合适的宽高比即可。

针对移动端的 HTML 文档，由于可读内容宽度较小，绘图的尺寸则需要有针对性地进行调整。此时，使用交互式绘图则比静态绘图有更有优势，利用交互式绘图本身的响应式能力，可以减少人工调整的工作量，也更容易实现一套绘图代码处处可用的效果。

在动态文档生成过程中，我们很难预估数据的真实场景，一些极端情况往往可能会导致可视化结果完全不可用。因此在编写绘图代码时应充分考虑到数据类别的数量、数据类别名称的长度、数据分布等多种因素，同时将绘图中的不同元素摆放在合适的位置。编写出适应性更好的绘图代码才能保证动态文档的高可用性，当然这个过程不是一蹴而就的，随着真实数据中极端情况的积累，绘图代码也会越来越完善越来越鲁棒。

2023-12-17 08:00:00

故事要从昨晚的事故说起，在软路由中删除了一个 Docker 容器，想着相关配置和数据目录也都用不到了就删掉吧。进入目录后「聪明」的我就执行了 rm -rf *，等回头去看命令执行情况已然为时已晚。为什么说我「聪明」呢，因为自从知道一个空格引起的 /usr 被删除的血案后，在做删除动作时我都会谨慎再谨慎，然而这次的悲剧在于目录下通过 NFS 挂载了 NAS 上的远程目录，删除前忘记取消挂载了，结果就是 NAS 上 4 块盘里面的影视资料被我一键清空了。

想着十多个 TB 的影视资料就这么没了，到也没有太伤感，毕竟技术男认为总还是可以恢复的，无非就是费些时间的问题。所以做的第一件事就是把 NAS 关机了，因为一旦再写入新的数据，被删除的数据可能就真的无法恢复了。关机后就开始找 SATA 线（NAS 里面是 3.5 寸的机械硬盘，使用 SATA 口通信），发现没有就赶紧买了一根第二天可以到的，至此第一笔 60 大洋（3.5 寸的硬盘还得单独供电，好不容易找到一个便宜的带电源的套装）损失就出去了。然后就开始各种找资料，NAS 里面的硬盘格式是 Btrfs 的，可用的恢复工具一下子就少了，翻着翻着发现就已经凌晨一点。怀着一丝丝担忧还是决定先睡了，明天早起再说吧，反正 SATA 线最快也得下午才能到。

喜新

这一切的一切要往前捯就只怪我「喜新厌旧」。搬到新家利用软路由和 NAS 搭建了一套家庭影音中心，老老实实看就得了呗，非要瞎鼓捣。在 Jellyfin 中显示的影视信息读取的元信息文件有些问题，提的 PR 也是做了各种测试才成功合并到主干，尽管只是改了一行代码的位置，但维护人员的严谨还是很让我受教的。虽然合并到了主干，但由于大版本更新发布还未确定时间，当时自己就临时针对当前版本调整了代码编译部署到了自己的软路由上先用起来了。

后续稳定版本也发布了几个修复问题的小版本更新，但合并的代码并不在更新范围内，自己懒了也就没再更新 Docker 镜像。直到昨天晚上也许就是闲来无事，想着要不就更新到非稳定版本用吧，同时一不做二不休还把刮削用的 tinyMediaManager 也更新下吧，然后就没有然后了，事故就发生了。

我是一个比较喜欢尝鲜的人，每天到公司不执行一下 brew update & brew upgrade 就不舒服。而且还不能搞成定时任务，就得手动执行，然后看着相关工具更新到最新版本就会很舒服。我承认在一些「大型」项目中，兼容和稳定才是第一追求，但我认为我还真么参与到过那种「大」到处处都要为兼容和稳定考虑的项目中过，所以我还是很喜欢尝试新的特性。当然工作中尝鲜用到的也得至少是正式发布的版本。最近的一次大迁移就是把我所有的 Python 项目都从 3.7 升级到了 3.10，为啥不是 3.11 呢，因为有些依赖包没我走得快，对 3.11 还不支持。我大部分是在做数据和算法工作，少部分时间也会用 Python 写一些工程性质的代码，在这个领域我认为「喜新」是一件好事，这会让你在面对一个问题时更有可能说出「我行」。

怀旧

我其实还挺两面派的，刚刚还在「喜新厌旧」，现在又说「怀旧」。老人经常说人要有个「念想」，但此时此刻我发现我的「念想」有点儿多了，多到可能束缚到了我的前行。NAS 是我大概 6 年前买的了，去年淘汰了里面两块老旧的小硬盘，又补上了两块 8TB 的。里面存的都是从 PT 站下载的高清影视资料，今年也终于成功的将 PT 站的账号升到了永久保号的等级，看了看上传量也近 20TB 了。文件被删掉的那一刻都是在想怎么恢复，但当发现恢复有一定的难度后，我突然有在想要不要恢复。

其实这么多年下载了这么多高清的影视资料，真正回过头再去看的次数不算多，一是没那么多时间，二是有新的内容可以选择。所以这么多「怀旧」的东西可能并不是「念想」，而只是满足「占有欲」的电子榨菜。这就和买书与读书是一回事儿，不是买了书有了书，知识就是你的了。多年前的我认识到了这个问题，但好像改进的并不理想，尤其是疫情这几年，身体没空去旅行，然而思想也没有在路上。不过感觉近期有所改善，至少近几个月快读完三本书了。

中午眯了会儿醒来还是决定把四块硬盘重新格式化了，也正好把之前一个磁盘和存储空间顺序不一致的问题做了纠正，如实让我这个强迫症选手舒服了一些。后面把原来移动硬盘中的照片重新又备份了一份到 NAS 中，「念想」这东西有点儿就够了。弄完了，心情一下子轻松了不少，毕竟不用再为恢复数据发愁了，尤其是在这种你还不知道能不能恢复的情况下。唯一还有些心疼的就是花 60 大洋买的 SATA 线，看了看快递小哥已经送上货了，就留着吧，万一将来有啥用呢。

再出发

后疫情时代的第一年马上就要过去了，这一年的种种个人感觉都不尽如人意，也正是不如人意才会让我去思考更多，改变更多。变革不一定会创造机会，哪怕创造了机会能不能抓住也难说，但对变革的思考和自身的改变是可以主动发起的。抛下一些陈旧的包袱，再去想想你真正想要的，透彻一些，会发现变革不一定是坏事。

大家都在往前走，这是我们认为的，也是我们想要的，至少是我想要的。可我真的在往前走吗？或许慢慢地陷入了舒适圈，或许被过往的「念想」不知不觉牵绊住了，所以不经意的一个变数，或好或坏，都给了我们重新审视自我和世界的机会。停下来，思考片刻，再出发，来得及，也值得。

2023-07-30 08:00:00

色域

在当我谈修图时，我谈些什么 - 色彩篇 Part 1 中已经介绍过什么是色彩空间，在显示领域通常会使用 RGB 色彩模型，在印刷领域通常会使用 CMYK 色彩模型。而在颜色感知领域，CIE 1931 色彩空间 则是在设计之初便要求包含普通人眼可见的所有颜色的标准色彩空间。

人类眼睛有对于短、中和长波的感光细胞，色彩空间在描述颜色时则可以通过定义三种刺激值，再利用值的叠加表示各种颜色。在 CIE 1931 色彩空间中，这三种刺激值并不是指对短、中和长波的反应，而是一组约略对应红色、绿色和蓝色的 X、Y 和 Z 的值。X、Y 和 Z 的值并不是真的看起来是红色、绿色和蓝色，而是使用 CIE XYZ 颜色匹配函数计算而来。

在颜色匹配实验中，如下图 ¹ 所示：

受试者通过观察单一光源的颜色和三原色光源的混合颜色是否相同，得到光谱三刺激值曲线如下图 ² 左所示。为了消除负值对数据处理带来的不便，通过转换得到了三个新的值 $X$、$Y$ 和 $Z$ 的曲线如下图 ² 右所示。

在 CIE 1931 色彩空间中，所有可视颜色的完整绘图是三维的，$Y$ 可以表示颜色的明度 ³。$Y$ 表示明度的好处是在给定 $Y$ 值时，XZ 平面将包含此明度下的所有色度。通过规范化 $X$、$Y$ 和 $Z$ 的值：

$$ \begin{aligned} x &= \dfrac{X}{X + Y + Z} \\ y &= \dfrac{Y}{X + Y + Z} \\ z &= \dfrac{Z}{X + Y + Z} = 1 - x - y \end{aligned} $$

色度可以使用 $x$ 和 $y$ 来表示。CIE 1931 的相对色度图 ⁴ 如下所示：

外侧曲线边界是光谱轨迹，波长用纳米标记。不同色域（Color Gamut）标准之间的对比如下图 ⁵ 所示：

对于一个显示设备来说，不可能产生超过其色域的颜色。通常情况下，讨论一台摄影设备的色域并没有意义，但使用什么样的色彩空间进行编码则需要重点关注。

色彩深度

色彩深度，简称色深（Color Depth），即存储一个像素的颜色所需要的位数。若色彩深度为 $n$ 位，则代表一共包含 $2^n$ 种颜色。例如我们常说的真彩色，即 24 位，对应 RGB 三个通道，每个通道 8 位（即 0-255），共可以表示 16,777,216 种颜色。

从上述对比图 ⁶ 中不难看出，色深越大，图像的效果越好，图像内容之间的过度越自然，与此同时占用的存储也会越多。

在视频拍摄中，我们通常说的 8bit 和 10bit 指的是位深（Bit Depth），即每个通道的位数。设备在拍摄素材时，记录更大位数的信息会更有利于后期调色等处理。

在显示器的特性中，我们也经常会遇见 8bit 和 10bit，以及 8bit FRC 这个概念。FRC 是 Frame Rate Control 的缩写，即帧率控制，是一种时间维度的像素抖动算法。以灰度图像为例，如下图所示，当渲染一个图像包含多个帧时，可以让帧在明暗之间进行切换，从而产生中间灰度。

相应的空间维度的像素抖动算法（Dither）如下图所示：

所以，一块原生 10bit 屏幕优于 8bit FRC 10bit 的屏幕优于原生 8bit 的屏幕。

色度抽样

在拍摄视频时，除了 8bit 和 10bit 位深的区别外，我们还经常听到 4:2:2 和 4:2:0 等比值，这代表色度抽样。由于人眼对色度的敏感度不及对亮度的敏感度，图像的色度分量不需要有和亮度分量相同的清晰度，在色度上进行抽样可以在不明显降低画面质量的同时降低影像信号的总带宽。

抽样系统通常用一个三分比值表示：$J : a : b$，其中：

• $J$ 为水平抽样的宽度
• $a$ 为第一行 $J$ 个像素中色度的抽样数量
• $b$ 为第二行 $J$ 个像素中色度的抽样数量

不同的比值色度抽样对比图 ⁷ 如下所示：

动态范围

动态范围（Dynamic Range）是可变信号（例如声音或光）最大值和最小值的比值。在相机中，设置不同的 ISO 会影响到动态范围在记录高光和暗部时的噪点表现。

高动态范围（High Dynamic Range，HDR）相比与标准动态范围（Standard Dynamic Range，SDR）具有更大的动态范围，简而言之 HDR 可以让画面中亮的地方足够亮暗的的地方足够暗。HDR 需要采集设备和显示设备同时支持才能够得以正常的显示，下图 ⁸ 展示了 HDR 和 SDR 从场景采集到显示还原的过程：

最终 SDR 和 HDR 成像的区别如下图 ⁹ 所示（模拟效果）：

在摄影过程中，如下两种方式都可以得到不错的 HDR 照片：

1. 针对 RAW 格式照片，其存储的不同明暗数据已经足够多，针对高光降低一些曝光，暗部增加一些曝光即可获得 HDR 照片。
2. 前期进行包围曝光，即在拍摄时同时拍摄多张具有不同曝光补偿的照片，后期再利用曝光合成技术得到一张 HDR 照片。

在摄像过程中，上述的两种方案就变得不太可行了，如果对于视频的每一帧都保存 RAW 信息会导致视频素材体积过大。此时我们会采用一种名为 Log 曲线的方式对视频的每一帧图像进行处理。

首先我们需要了解一下什么是曝光量（Photometric Exposure）和曝光值（Exposure Value，EV）。曝光量是指进入镜头在感光介质上的光量，其由光圈、快门和感光度组合控制，定义为：

$$ H = Et $$

其中，$E$ 为影像平面的照度，$t$ 为快门的曝光时间。影像平面照度与光圈孔径面积成正比，因此与光圈 $f$ 值的平方成反比，则有：

$$ H \propto \dfrac{t}{N^2} $$

其中，$N$ 为光圈的 $f$ 值。$\dfrac{t}{N^2}$ 这个比例值可以用于表示多个等效的曝光时间和光圈 $f$ 值组合。此比值具有较大的分母，为了方便使用反转该比值并取以 $2$ 为底的对数则可以得到曝光值的定义：

$$ EV = \log_2{\dfrac{N^2}{t}} = 2 \log_2{\left(N\right)} - \log_2{\left(t\right)} $$

在现实中，随着光线强度（类比曝光量）的成倍增加，人眼对于光的感应（类比曝光值）大约成线性增长。同时，摄像机器对于光线强度的记录是线性的，也就是说当光线强度翻倍时，转换后存储的数值也会翻倍。

以 8bit 为例，对于高光部分（7 - 8 档曝光值）会使用 128 位存储相关信息，而对于暗部（0 - 1 档曝光值）则仅使用 8 位存储相关信息，如下图左所示。此时由于高光部分看起来亮度变化并不大，使用的存储位数比暗部多得多，这种非均衡的的存储容易丢失图像的暗部细节。通过对曝光量进行 Log 处理，可以得到均衡的对应关系，如下图右所示。

在真实场景中，各个相机厂商的所搭载的 Log 曲线并不完全相同，都会为了实现某种效果进行调整修改。但整体来说其目的还是为了让每一档曝光值之间存储的信息量大致相同。颜色矫正后和原始应用 Log 曲线的对比图像 ¹⁰ 如下所示：

2023-05-03 08:00:00

CSS 中的布局 display 和定位 position 可以说是两个最基本的属性，其控制着元素在网页中的显示方式。之前对布局和定位可谓是一知半解，最终奏不奏效全凭一顿乱试😂，想了想还是应该细致地了解下，后面虽不妄想写起代码来事半功倍，但至少不会再暴力遍历破解了。

盒模型

在介绍布局和定位之前，首先回顾一下 CSS 的盒模型。CSS 盒模型从外到内由外边距 margin、边框 border、内边距 padding 和内容 content 共 4 部分组成，如下图所示：

元素的宽度 width 为内容的宽度 + 左边框 + 有边框 + 左内边距 + 右内边距，上例中为 $360+10+10+10+10=400$；元素的的高度 height 为内容的高度 + 上边框 + 下边框 + 上内边距 + 下内边距，上例中为 $240+10+10+20+20=300$。在实际中，我们并不能直接设定内容的宽度和高度，只能设置元素的宽度和高度，而显示区域的宽度和高度则通过计算自动设定。

在 CSS 中广泛使用的有两种盒子模型：块级盒子（block box） 和 内联盒子（inline box）¹。

块级盒子有如下表现行为：

• 盒子会在内联方向上扩展并占据父容器在该方向上的所有可用空间，在绝大数情况下意味着盒子会和父容器一样宽。
• 每个盒子都会换行。
• width 和 height 属性可以发挥作用。
• 内边距、外边距和边框会将其他元素从当前盒子周围“推开”。

除非特殊指定，诸如标题 (<h1> 等) 和段落 (<p>) 默认情况下都是块级的盒子。

内联盒子有如下表现行为：

• 盒子不会产生换行。
• width 和 height 属性将不起作用。
• 垂直方向的内边距、外边距以及边框会被应用但是不会把其他处于 inline 状态的盒子推开。
• 水平方向的内边距、外边距以及边框会被应用且会把其他处于 inline 状态的盒子推开。

<a> 、<span>、<em> 以及 <strong> 都是默认处于 inline 状态的。

布局

在 CSS 中使用 display 属性控制元素的布局方式，上文中的 block 和 inline 是最常用的两种布局方式。除此之外还有一种介于块级盒子和内联盒子之间的布局方式，即 inline-block，其具有如下表现行为：

• 盒子不会产生换行。
• width 和 height 属性可以发挥作用。
• 内边距、外边距和边框会将其他元素从当前盒子周围“推开”。

上图分别展示了 display: inline 和 display: inline-block 两种布局 span 元素的显示差异。

弹性布局

弹性布局（Flexbox Layout，Flexible Box Layout） 旨在提供一种更加有效的方式来布局、对齐和分配容器中元素之间的空间，即使元素的大小是未知或动态的，这也就是称为“弹性”的原因。

弹性布局是一套完整的模块而非一个单一的属性，其中一些属性要设置在父元素（flex container） 上，一些属性要设置在子元素（flex items） 上。常规布局是基于块级元素和内联元素的的流向，而弹性布局是基于弹性流向（flex-flow directions）。下图展示了弹性布局的基本思想：

父元素属性

display

该属性启用弹性容器，为其子元素开启弹性上下文。

.container {
  display: flex; /* 或 inline-flex */
}

flex-direction

该属性定义了弹性流向，即基本思想中的 main-axis。

.container {
  flex-direction: row | row-reverse | column | column-reverse;
}

• row（默认）：ltr 时从左至右，rtl 时从右至左
• row-reverse：ltr 时从右至左，rtl 时从左至右
• column：从上至下
• column-reverse：从下至上

flex-wrap

默认情况下会将子元素放置在一行中，该属性用于设置换行模式。

.container {
  flex-wrap: nowrap | wrap | wrap-reverse;
}

• nowarp（默认）：所有子元素放置在一行中。
• wrap：允许换行，从上至下。
• wrap-reverse：允许换行，从下至上。

flex-flow

该属性是 flex-direction 和 flex-wrap 两个属性的简写。

.container {
  flex-flow: column wrap;
}

justify-content

该属性用于设置主轴（main axis）方向的对齐方式。

.container {
  justify-content: flex-start | flex-end | center | space-between | space-around | space-evenly | start | end | left | right ... + safe | unsafe;
}

• flex-start（默认）：将子元素排列在 flex-direction 起始位置。
• flex-end：将子元素排列在 flex-direction 结束位置。
• center：将子元素沿着 flex-direction 方向居中排列。
• space-between：将子元素沿着 flex-direction 方向均匀排列，第一个子元素位于起始位置，最后一个子元素位于结束位置。
• space-around：将子元素沿着 flex-direction 方向均匀排列，每个子元素周围分配相同的空间。
• space-evenly：将子元素沿着 flex-direction 方向均匀排列，每个子元素之间的间隔相同。

align-items

该属性用于设置交叉轴（cross axis）方向的对齐方式。

.container {
  align-items: stretch | flex-start | flex-end | center | baseline | first baseline | last baseline | start | end | self-start | self-end + ... safe | unsafe;
}

• stretch（默认）：拉伸并填充容器（仍遵守 min-width 和 max-width）。
• flex-start / start / self-start：子元素被放置在交叉轴的起始位置。
• flex-end / end / self-end：子元素被放置在交叉轴的结束位置。
• center：子元素在交叉轴上居中对齐。
• baseline：子元素沿着他们的基线对齐。

align-content

该属性用于设置当交叉轴上有额外的空间时容器多行的内部对齐方式，类似 justify-content 设置主轴上子元素的对齐方式。

.container {
  align-content: flex-start | flex-end | center | space-between | space-around | space-evenly | stretch | start | end | baseline | first baseline | last baseline + ... safe | unsafe;
}

• normal（默认）：子元素被放置到容器的默认位置。
• flex-start / start：子元素被放置到容器的起始位置。
• flex-end / end：子元素被放置到容器的结束位置。
• center：子元素被放置到容器的居中位置。
• space-between：子元素均匀分布，第一行在容器的起始位置，最后一行在容器的结束位置。
• space-around：子元素均匀分布，每行元素周围分配相同的空间。
• space-evenly：子元素均匀分布，每行元素之间的间隔相同。
• stretch：子元素拉伸占用剩余空间。

gap, row-gap, column-gap

该属性用于控制子元素之间的间距，其仅用于非边缘子元素之间的间距。

.container {
  display: flex;
  ...
  gap: 10px;
  gap: 10px 20px; /* row-gap column gap */
  row-gap: 10px;
  column-gap: 20px;
}

该属性产生的行为可以认为是子元素之间的最小间距。

子元素属性

order

默认情况下，子元素按照代码顺序排列。该属性可以控制子元素在容器中的顺序。

.item {
  order: 5; /* 默认为 0 */
}

flex-grow

该属性定义了子元素在必要时的扩张能力，其接受一个整数比例值用于设定子元素占用容器的空间。如果所有子元素的 flew-grow 都设置为 1，则所有子元素将评分容器的剩余空间；如果一个子元素的 flex-grow 设置为 2，则该子元素将尝试占用其他子元素 2 倍大小的空间。

.item {
  flex-grow: 4; /* 默认为 0 */
}

flex-shrink

该属性定义了子元素在必要时的收缩能力。

.item {
  flex-shrink: 3; /* 默认为 1 */
}

flex-basis

该属性定义了分配剩余空间之前子元素的默认大小。其可以为例如 20%、5rem 之类的长度或一个关键字。

.item {
  flex-basis:  | auto; /* 默认为 auto */
}

flex

该属性是 flex-grow、flex-shrink 和 flex-basis 三个属性的简写。

.item {
  flex: none | [ <'flex-grow'> <'flex-shrink'>? || <'flex-basis'> ]
}

align-self

该属性可以覆盖由 align-items 指定的对齐方式。

.item {
  align-self: auto | flex-start | flex-end | center | baseline | stretch;
}

网格布局

网格布局（Grid Layout） 是一种基于网格的布局系统，相比于沿轴线 一维布局 的弹性布局，网格布局可以看做是一种 二维布局。

核心概念

网格容器

网格容器即属性 display 为 grid 的元素，其为所有网格项目的直接父级。如下示例中，container 即为网格容器：

<div class="container">
  <div class="item item-1"> </div>
  <div class="item item-2"> </div>
  <div class="item item-3"> </div>
</div>

网格项目

网格项目为网格容器的直接后代。如下示例中，item 即为网格项目，但 sub-item 不是：

<div class="container">
  <div class="item"> </div>
  <div class="item">
    <p class="sub-item"> </p>
  </div>
  <div class="item"> </div>
</div>

网格线

网格线即构成网格结构的分界线。其可以是位于行或列任意一侧的垂直或水平线。如下示例中，黄色的线为一条列网格线：

网格单元

网格单元即两个相邻行和两个相邻列之间的区域。如下示例中，黄色区域为行网格线 1 和 2 以及列网格线 2 和 3 之间的单元格：

网格轨道

网格轨道即 2 条相邻网格线之间的区域，可以将其视为网格的行或列。如下示例中，黄色区域为第 2 行和第 3 行网格线之间的网格轨道：

网格区域

网格区域即 4 条网格线包围的区域，一个网格区域可以由任意数量的网格单元组成。如下示例中，黄色区域为行网格线 1 和 3 以及列网格线 1 和 3 之间的网格区域：

父元素属性

display

该属性启用网格容器，为其子元素开启网格上下文。

.container {
  display: grid | inline-grid;
}

grid-template-columns, grid-template-rows

该属性通过空格分隔的值列表定义网格的列和行，值代表轨道的大小。值列表包括：

• <track-size>：轨道大小，可以为长度、百分比等。
• <line-name>：网格线名称，可以为任意值。

.container {
  grid-template-columns: ...  ...;
  /* 例如：
      1fr 1fr
      minmax(10px, 1fr) 3fr
      repeat(5, 1fr)
      50px auto 100px 1fr
  */
  grid-template-rows: ... ...;
  /* 例如：
      min-content 1fr min-content
      100px 1fr max-content
  */
}

网格线默认将会被分为正整数（-1 作为最后一个的替代值）。

同时也可以明确指定这些线的名称，请注意括号命名语法：

.container {
  grid-template-columns: [first] 40px [line2] 50px [line3] auto [col4-start] 50px [five] 40px [end];
  grid-template-rows: [row1-start] 25% [row1-end] 100px [third-line] auto [last-line];
}

请注意，一个行或列可以有多个名称：

.container {
  grid-template-rows: [row1-start] 25% [row1-end row2-start] 25% [row2-end];
}

使用 repeat() 可以简化重复项：

.container {
  grid-template-columns: repeat(3, 20px [col-start]);
}

上述代码等效于：

.container {
  grid-template-columns: 20px [col-start] 20px [col-start] 20px [col-start];
}

如果多行或多列共享相同的名称，可以通过行名或列名和计数来引用它们：

.item {
  grid-column-start: col-start 2;
}

fr 单位允许将轨道的大小设置为网格容器可用空间的一定比例。例如，如下示例将每个项目设置为容器宽度的三分之一：

.container {
  grid-template-columns: 1fr 1fr 1fr;
}

可用空间是在所有非弹性项目之后计算得到。在上述示例中，fr 单位的可用空间总量不包括 50px：

.container {
  grid-template-columns: 1fr 50px 1fr 1fr;
}

grid-template-areas

该属性通过引用网格区域的名称 grid-area 来定义网格。重复网格区域名称会导致内容跨越这些单元格。句点表示一个空单元格。语法本身提供了网格结构的可视化。

• <grid-area-name>：网格区域的名称。
• .：空网格单元。
• none：未定义的网格区域。

.container {
  grid-template-areas: 
    "<grid-area-name> | . | none | ..."
    "...";
}

.item-a {
  grid-area: header;
}
.item-b {
  grid-area: main;
}
.item-c {
  grid-area: sidebar;
}
.item-d {
  grid-area: footer;
}

.container {
  display: grid;
  grid-template-columns: 50px 50px 50px 50px;
  grid-template-rows: auto;
  grid-template-areas: 
    "header header header header"
    "main main . sidebar"
    "footer footer footer footer";
}

上述示例将创建一个 4 列 3 行的网格。整个顶部为 header 区域，中间一行由 main 和 sidebar 两个区域和一个空单元格组成，最后一行为 footer。

声明中的每一行都需要有相同数量的单元格。可以使用任意数量的句点声明一个空单元格，只要句点之间没有空格，就代表一个单元格。

注意使用此语法仅可以命名区域，不可命名线。使用此语法时，区域两端的线会自动命名，如果网格区域名称为 foo，那么该区域的起始行线和起始列线名称为 foo-start，该区域的终止行线和终止列线名称为 foo-end。这意味着某些线可能有多个名称，上述示例中最左边的行线将有 3 个名称：header-start、main-start 和 footer-start。

grid-template

该属性是 grid-template-rows、grid-template-columns 和 grid-template-areas 三个属性的简写。

.container {
  grid-template: none | <grid-template-rows> / <grid-template-columns>;
}

其接受更复杂但更方便的语法来指定这三个值，例如：

.container {
  grid-template:
    [row1-start] "header header header" 25px [row1-end]
    [row2-start] "footer footer footer" 25px [row2-end]
    / auto 50px auto;
}

上述代码等效于：

.container {
  grid-template-rows: [row1-start] 25px [row1-end row2-start] 25px [row2-end];
  grid-template-columns: auto 50px auto;
  grid-template-areas: 
    "header header header" 
    "footer footer footer";
}

由于 grid-template 并不会重置网格的隐含属性（grid-auto-columns、grid-auto-rows 和 grid-auto-flow）。因此，建议使用 grid 属性而非 grid-template。

column-gap, row-gap, grid-column-gap, grid-row-gap

该属性用于指定网格线的大小，你可以将其看做列和行之间的间距。

.container {
  /* standard */
  column-gap: <line-size>;
  row-gap: <line-size>;

  /* old */
  grid-column-gap: <line-size>;
  grid-row-gap: <line-size>;
}

.container {
  grid-template-columns: 100px 50px 100px;
  grid-template-rows: 80px auto 80px; 
  column-gap: 10px;
  row-gap: 15px;
}

间距仅在列和行之间创建，不在边缘创建。注意，带有 grid- 前缀的属性将被废弃。

gap, grid-gap

该属性为 row-gap 和 column-gap 两个属性的简写。

.container {
  /* standard */
  gap: <grid-row-gap> <grid-column-gap>;

  /* old */
  grid-gap: <grid-row-gap> <grid-column-gap>;
}

.container {
  grid-template-columns: 100px 50px 100px;
  grid-template-rows: 80px auto 80px; 
  gap: 15px 10px;
}

如果未指定 row-gap，则它将被设置为与 column-gap 相同的值。注意，带有 grid- 前缀的属性将被废弃。

justify-items

沿 inline（行）轴对齐网格项（与沿 block（列）轴对齐 align-items 相反）。该属性将应用于容器内所有网格项。

• stretch（默认值）：将网格项填充至整个单元格宽度。
• start：将网格项与单元的起始边缘对齐。
• end：将网格项与单元的结束边缘对齐。
• center：将网格项与单元的中心对齐。

.container {
  justify-items: stretch | start | end | center;
}

.container {
  justify-items: stretch;
}

.container {
  justify-items: start;
}

.container {
  justify-items: end;
}

.container {
  justify-items: center;
}

align-items

沿 block（列）轴对齐网格项（与沿 inline（行）轴对齐 align-items 相反）。该属性将应用于容器内所有网格项。

• stretch（默认值）：将网格项填充至整个单元格高度。
• start：将网格项与单元的起始边缘对齐。
• end：将网格项与单元的结束边缘对齐。
• center：将网格项与单元的中心对齐。
• baseline：将网格项沿文本基线对齐。

.container {
  align-items: stretch | start | end | center;
}

.container {
  align-items: stretch;
}

.container {
  align-items: start;
}

.container {
  align-items: end;
}

.container {
  align-items: center;
}

通过 align-self 属性可以在单个网格项上覆盖由 align-items 指定的对齐方式。

place-items

该属性在单次声明中同时设置 align-items 和 justify-items 属性。

• <align-items> / <justify-items>：省略第二个值则将第一个值分配给两个属性。

.center {
  display: grid;
  place-items: center;
}

justify-content

当所有网格项均使用非弹性的单位（例如 px）来确定大小，则网格的总大小可能小于网格容器的大小。在这种情况下，可以在网格容器内设置网格的对齐方式。该属性沿 inline（行）轴（与沿 block（列）轴对齐 align-content 相反）对齐网格。

• start：将网格与网格容器的起始边缘对齐。
• end：将网格与网格容器的结束边缘对齐。
• center：将网格与网格容器的中心对齐。
• stretch ：调整网格项的大小使网格填充网格容器的整个宽度。
• space-around：每个网格项均匀分布，每个网格项周围分配相同的空间。
• space-between：每个网格项均匀分布，第一个网格项在起始位置，最后一个网格项在结束位置。
• space-evenly：每个网格项均匀分布，每个网格项之间的间隔相同。

.container {
  justify-content: start | end | center | stretch | space-around | space-between | space-evenly;    
}

.container {
  justify-content: start;
}

.container {
  justify-content: end;
}

.container {
  justify-content: center;
}

.container {
  justify-content: stretch;
}

.container {
  justify-content: space-around;
}

.container {
  justify-content: space-between;
}

.container {
  justify-content: space-evenly;
}

align-content

当所有网格项均使用非弹性的单位（例如 px）来确定大小，则网格的总大小可能小于网格容器的大小。在这种情况下，可以在网格容器内设置网格的对齐方式。该属性沿 block（列）轴（与沿 inline（行）轴对齐 justify-content 相反）对齐网格。

• start：将网格与网格容器的起始边缘对齐。
• end：将网格与网格容器的结束边缘对齐。
• center：将网格与网格容器的中心对齐。
• stretch ：调整网格项的大小使网格填充网格容器的整个高度。
• space-around：每个网格项均匀分布，每个网格项周围分配相同的空间。
• space-between：每个网格项均匀分布，第一个网格项在起始位置，最后一个网格项在结束位置。
• space-evenly：每个网格项均匀分布，每个网格项之间的间隔相同。

.container {
  align-content: start | end | center | stretch | space-around | space-between | space-evenly;    
}

.container {
  align-content: start;    
}

.container {
  align-content: end;    
}

.container {
  align-content: center;    
}

.container {
  align-content: stretch;    
}

.container {
  align-content: space-around;    
}

.container {
  align-content: space-between;    
}

.container {
  align-content: space-evenly;    
}

place-content

该属性在单次声明中同时设置 align-content 和 justify-content 属性。

• <align-content> / <justify-content>：省略第二个值则将第一个值分配给两个属性。

grid-auto-columns, grid-auto-rows

该属性指定自动生成的网格轨道（也称为隐式网格轨道）的大小。当网格项多于网格中的单元格或当网格项放置在显示网格之外时，将创建隐式网格轨道。

• <track-size>：可以为长度、百分比或可用空间的比例（使用 fr 单位）。

.container {
  grid-auto-columns: <track-size> ...;
  grid-auto-rows: <track-size> ...;
}

.container {
  grid-template-columns: 60px 60px;
  grid-template-rows: 90px 90px;
}

上述代码将生成一个 2x2 的网格：

使用 grid-column 和 grid-row 来定位网格项：

.item-a {
  grid-column: 1 / 2;
  grid-row: 2 / 3;
}
.item-b {
  grid-column: 5 / 6;
  grid-row: 2 / 3;
}

.item-b 从第 5 列线开始到第 6 列线结束，但由于并未定义第 5 列线和第 6 列线，因此创建了宽度为 0 的隐式轨道用于填充间隙。使用 grid-auto-columns 和 grid-auto-rows 可以指定这些隐式轨道的宽度：

.container {
  grid-auto-columns: 60px;
}

grid-auto-flow

如果有未明确放置在网格中的网格项目，自动放置算法会自动放置这些网格项目。此属性用于控制自动放置算法的工作方式。

• row（默认）：依次填充每一行，并根据需要添加新行。
• column：依次填充每一列，并根据需要添加新列。
• dense：将可能较晚出现的较小的网格项优先填充在网格中。

.container {
  grid-auto-flow: row | column | row dense | column dense;
}

注意 dense 仅会改变网格项目的视觉顺序，这可能导致顺序混乱且不利于访问。

考虑如下示例：

<section class="container">
  <div class="item-a">item-a</div>
  <div class="item-b">item-b</div>
  <div class="item-c">item-c</div>
  <div class="item-d">item-d</div>
  <div class="item-e">item-e</div>
</section>

定义一个包含 5 列和 2 行的网格，并将 grid-auto-flow 设置为 row：

.container {
  display: grid;
  grid-template-columns: 60px 60px 60px 60px 60px;
  grid-template-rows: 30px 30px;
  grid-auto-flow: row;
}

将网格项目放置在网格中时，只需要为其中两个指定位置：

.item-a {
  grid-column: 1;
  grid-row: 1 / 3;
}
.item-e {
  grid-column: 5;
  grid-row: 1 / 3;
}

因为将 grid-auto-flow 设置为了 row，未放置的三个网格项目（item-b、item-c 和 item-d）如下所示：

.container {
  display: grid;
  grid-template-columns: 60px 60px 60px 60px 60px;
  grid-template-rows: 30px 30px;
  grid-auto-flow: column;
}

如果将 grid-auto-flow 设置为 column，未放置的三个网格项目（item-b、item-c 和 item-d）如下所示：

grid

该属性为 grid-template-rows、grid-template-columns、grid-template-areas、grid-auto-rows、grid-auto-columns 和 grid-auto-flow 属性的简写。

• none：将所有子属性设置为初始值。
• <grid-template>：同 grid-template。
• <grid-template-rows> / [ auto-flow && dense? ] <grid-auto-columns>?：设置 grid-template-rows 为指定值。如果使用 auto-flow 关键字，则设置 grid-auto-flow 为 colomn。如果额外使用 dense 关键字，则自动放置算法将使用 dense 算法。如果省略 grid-auto-columns，则其被设置为 auto。
• [ auto-flow && dense? ] <grid-auto-rows>? / <grid-template-columns>：设置 grid-template-columns 为指定值。如果使用 auto-flow 关键字，则设置 grid-auto-flow 为 row。如果额外使用 dense 关键字，则自动放置算法将使用 dense 算法。如果省略 grid-auto-rows，则其被设置为 auto。

如下示例中的代码是等效的：

.container {
  grid: 100px 300px / 3fr 1fr;
}

.container {
  grid-template-rows: 100px 300px;
  grid-template-columns: 3fr 1fr;
}

.container {
  grid: auto-flow / 200px 1fr;
}

.container {
  grid-auto-flow: row;
  grid-template-columns: 200px 1fr;
}

.container {
  grid: auto-flow dense 100px / 1fr 2fr;
}

.container {
  grid-auto-flow: row dense;
  grid-auto-rows: 100px;
  grid-template-columns: 1fr 2fr;
}

.container {
  grid: 100px 300px / auto-flow 200px;
}

.container {
  grid-template-rows: 100px 300px;
  grid-auto-flow: column;
  grid-auto-columns: 200px;
}

它还接受更复杂但更方便的语法来一次性设置所有内容。如下示例中的代码是等效的：

.container {
  grid: [row1-start] "header header header" 1fr [row1-end]
        [row2-start] "footer footer footer" 25px [row2-end]
        / auto 50px auto;
}

.container {
  grid-template-areas: 
    "header header header"
    "footer footer footer";
  grid-template-rows: [row1-start] 1fr [row1-end row2-start] 25px [row2-end];
  grid-template-columns: auto 50px auto;    
}

子元素属性

grid-column-start, grid-column-end, grid-row-start, grid-row-end

该属性通过网格线来设置网格项在网格中的位置。grid-column-start 和 grid-row-start 为网格项起始的线，grid-column-end 和 grid-row-end 为网格项结束的线。

• <line>：指代网格线的数字编号或名称。
• span <number>：该网格项跨越的网格轨道数。
• span <name>：该网格项跨越直到它抵达该名称网格线的下一个网格线。
• auto：表示自动放置、自动跨度或一个默认跨度。

.item {
  grid-column-start: <number> | <name> | span <number> | span <name> | auto;
  grid-column-end: <number> | <name> | span <number> | span <name> | auto;
  grid-row-start: <number> | <name> | span <number> | span <name> | auto;
  grid-row-end: <number> | <name> | span <number> | span <name> | auto;
}

.item-a {
  grid-column-start: 2;
  grid-column-end: five;
  grid-row-start: row1-start;
  grid-row-end: 3;
}

.item-b {
  grid-column-start: 1;
  grid-column-end: span col4-start;
  grid-row-start: 2;
  grid-row-end: span 2;
}

如果 grid-column-end 或 grid-row-end 未声明，则该网格项将默认跨越一个轨道。网格项目之间可以相互重叠，使用 z-index 可以控制它们的重叠次序。

grid-column, grid-row

分别是 grid-column-start + grid-column-end 和 grid-row-start+ grid-row-end 的简写。

• <start-line> / <end-line>：接受非简写版本相同的值，包括 span。

.item {
  grid-column: <start-line> / <end-line> | <start-line> / span <value>;
  grid-row: <start-line> / <end-line> | <start-line> / span <value>;
}

.item-c {
  grid-column: 3 / span 2;
  grid-row: third-line / 4;
}

如果未设置结束线的值，则该网格项将默认跨越一个轨道。

grid-area

为一个网格项命名以便它可以使用 grid-template-areas 属性创建的模板引用。此属性可以作为 grid-row-start + grid-column-start + grid-row-end + grid-column-end 的简写。

• <name>：选用的名称。
• <row-start> / <column-start> / <row-end> / <column-end>：可以为数字编号或线名称。

用作为网格项分配名称：

.item-d {
  grid-area: header;
}

用作 grid-row-start + grid-column-start + grid-row-end + grid-column-end 的简写：

.item-d {
  grid-area: 1 / col4-start / last-line / 6;
}

justify-self

沿 inline（行）轴对齐单元格内的网格项（与沿 block（列）轴对齐 align-self 相反）。该属性仅应用于单个单元格内的网格项。

• stretch（默认）：填充单元格的整个宽度。
• start：将网格项与单元格的起始边缘对齐。
• end：将网格项与单元格的结束边缘对齐。
• center：将网格项与单元格的中心对齐。

.item {
  justify-self: stretch | start | end | center;
}

.item-a {
  justify-self: stretch;
}

.item-a {
  justify-self: start;
}

.item-a {
  justify-self: end;
}

.item-a {
  justify-self: center;
}

通过 justify-items 属性可以为容器中所有的网格项设置对齐方式。

align-self

沿 block（列）轴对齐单元格内的网格项（与沿 inline（行）轴对齐 justify-self 相反）。该属性将仅应用于单个单元格内的网格项。

• stretch（默认）：填充单元格的整个高度。
• start：将网格项与单元格的起始边缘对齐。
• end：将网格项与单元格的结束边缘对齐。
• center：将网格项与单元格的中心对齐。

.item {
  align-self: stretch | start | end | center;
}

.item-a {
  align-self: stretch;
}

.item-a {
  align-self: start;
}

.item-a {
  align-self: end;
}

.item-a {
  align-self: center;
}

place-self

place-self 可以在单次声明中同时设置 align-self 和 justify-self。

• auto：默认对齐方式。
• <align-self> / <justify-self>：省略第二个值则将第一个值分配给两个属性。

.item-a {
  place-self: center;
}

.item-a {
  place-self: center stretch;
}

定位

定位允许我们将一个元素放置在网页的指定位置上。定位并非是一种用来做主要布局的方式，而是一种用于微调布局的手段。通过 position 属性在特定的布局中修改元素的定位方式，该属性有 static、relative、fixed、absolute 和 sticky 共 5 种可选值。

为了展示不同 position 的效果，在此采用相同的 HTML 进行比较：

<h1>XXX 定位</h1>

<p>这是一个基本块元素。</p>
<p class="position">这是一个基本块元素。</p>
<p>这是一个基本块元素。</p>

默认样式为：

body {
  width: 400px;
  margin: 0 auto;
}

h1 {
  text-align: center;
}
  
p {
  margin: 10px;
  padding: 10px;
  background-color: #916cad;
  border: 2px #523874 solid;
  border-radius: 3px;
}

静态定位

静态定位（static） 是 position 属性的 默认值，它表示将元素放置在文档布局流的默认位置上。

静态定位样式为：

.position {
  position: static;
}

渲染效果如下：

相对定位

相对定位（relative） 表示相对于 静态定位 的默认位置进行偏移，其需要搭配 top、bottom、left 和 right 四个属性使用。

相对定位样式为：

.position {
  position: relative;
  top: 30px;
  left: 30px;
  background-color: #c7fba5cc;
  border: 2px #adf182cc solid;
}

渲染效果如下：

绝对定位

绝对定位（absolute） 表示相对于 上级元素 的位置进行偏移，其需要搭配 top、bottom、left 和 right 四个属性使用。绝对定位的定位基点不能为 static 定位，否则定位基点将变成网页根元素 html。

绝对定位样式为：

.position {
  position: absolute;
  top: 30px;
  left: 30px;
  background-color: #c7fba5cc;
  border: 2px #adf182cc solid;
}

渲染效果如下：

固定定位

固定定位（fixed） 表示相对于 视窗（viewport，即浏览器窗口） 进行偏移，其需要搭配 top、bottom、left 和 right 四个属性使用。利用固定定位可以实现元素位置不随页面滚动而发生变化。

为了演示固定定位，修改 HTML 代码如下：

<h1>固定定位</h1>

<p>这是一个基本块元素。</p>
<p class="position">固定</p>
<p>这是一个基本块元素。</p>
<p>这是一个基本块元素。</p>
<p>这是一个基本块元素。</p>
<p>这是一个基本块元素。</p>
<p>这是一个基本块元素。</p>

固定定位样式为：

.position {
  position: fixed;
  top: 30px;
  left: 30px;
  background-color: #c7fba5cc;
  border: 2px #adf182cc solid;
}

渲染效果如下：

粘性定位

粘性定位（sticky） 可以理解为 静态定位（static） 和 固定定位（fixed） 的 混合。当指定一个元素的 position 属性为 sticky 后，它会在正常布局流中滚动，直至它出现在设定的相对于容器的位置，此时它会停止滚动，表现为固定定位。

为了演示粘性定位，修改 HTML 代码如下：

<h1>粘性定位</h1>

<p>这是一个基本块元素。</p>
<p class="position">这是一个粘性定位元素。</p>
<p>这是一个基本块元素。</p>
<p>这是一个基本块元素。</p>
<p>这是一个基本块元素。</p>
<p>这是一个基本块元素。</p>
<p>这是一个基本块元素。</p>
<p>这是一个基本块元素。</p>
<p>这是一个基本块元素。</p>

粘性定位样式为：

.position {
  position: sticky;
  top: 30px;
  left: 30px;
  background-color: #c7fba5cc;
  border: 2px #adf182cc solid;
}

渲染效果如下：

2023-04-22 08:00:00

文本是「当我谈」系列的第一篇博客，后续「当我谈」系列会从程序员的视角一起科普认知未曾触及的其他领域。

色彩空间

色彩空间是对色彩的组织方式，借助色彩空间和针对物理设备的测试，可以得到色彩的固定模拟和数字表示。色彩模型是一种抽象数学模型，通过一组数字来描述颜色。由于“色彩空间”有着固定的色彩模型和映射函数组合，非正式场合下，这一词汇也被用来指代色彩模型。

RGB

红绿蓝（RGB）色彩模型，是一种加法混色模型，将红（Red）、绿（Green）、蓝（Blue）三原色的色光以不同的比例相加，以合成产生各种色彩光。三原色的原理不是出于物理原因，而是由于生理原因造成的。

RGB 色彩模型可以映射到一个立方体上，如下图所示：

红绿蓝的三原色光显示技术广泛用于电视和计算机的显示器，利用红、绿、蓝三原色作为子像素组成的真色彩像素，透过眼睛及大脑的模糊化，“人类看到”不存在于显示器上的感知色彩。

CMYK

印刷四分色模式（CMYK）是彩色印刷中采用的一种减法混色模型，利用色料的三原色混色原理，加上黑色油墨，共计四种颜色混合叠加，形成所谓的“全彩印刷”。四种标准颜色分别是：

• Cyan：青色或“水蓝”
• Magenta：洋红色或“紫色”
• Yellow：黄色
• Key plate：因实务上多使用黑色，所以也可以简单视为 blacK

CMY 叠色的示意图如下所示：

利用 $0$ 到 $1$ 的浮点数表示 $R, G, B$ 和 $C, M, Y, K$，从四分色向三原光转换公式如下：

$$ \begin{aligned} R &= \left(1 - C\right) \left(1 - K\right) \\ G &= \left(1 - M\right) \left(1 - K\right) \\ B &= \left(1 - Y\right) \left(1 - K\right) \end{aligned} $$

从三原光向四分色转换公式如下：

$$ \begin{aligned} C &= 1 - \dfrac{R}{\max \left(R, G, B\right)} \\ M &= 1 - \dfrac{G}{\max \left(R, G, B\right)} \\ Y &= 1 - \dfrac{B}{\max \left(R, G, B\right)} \\ K &= 1 - \max \left(R, G, B\right) \\ \end{aligned} $$

HSL 和 HSV

HSL 和 HSV 都是一种将 RGB 色彩模型中的点在圆柱坐标系中的表示法。这两种表示法试图做到比基于笛卡尔坐标系的几何结构 RGB 更加直观。HSL 即色相、饱和度、亮度（Hue，Saturation，Lightness），HSV 即色相、饱和度、明度（Hue，Saturation，Value），又称 HSB，其中 B 为 Brightness。另种色彩空间定义如下图所示：

色相

色相（Hue）指的是色彩的外相，是在不同波长的光照射下，人眼所感觉到的不同的颜色。在 HSL 和 HSV 色彩空间中，色相是以红色为 0 度（360 度）、黄色为 60 度、绿色为 120 度、青色为 180 度、蓝色为 240 度、洋红色为 300 度。如下图所示：

饱和度

饱和度（Saturation）指的是色彩的纯度，饱和度由光强度和它在不同波长的光谱中分布的程度共同决定。下图为红色从最小饱和度到最大饱和度的示例：

亮度和明度

明度值是与同样亮的白色物体相比，某物的亮的程度。如果我们拍摄一张图像，提取图像色相、饱和度和明度值，然后将它们与不同色彩空间的明度值进行比较，可以迅速地从视觉上得出差异。如下图所示，HSV 色彩空间中的 V 值和 HSL 色彩空间中的 L 值与感知明度值明显不同：

差异

HSV 和 HSL 两者对于色相（H）的定义一致，但对于饱和度（S）和亮度与明度（L 与 B）的定义并不一致。

在 HSL 中，饱和度独立于亮度存在，也就是说非常浅的颜色和非常深的颜色都可以在 HSL 中非常饱和。而在 HSV 中，接近于白色的颜色都具有较低的饱和度。

• HSV 中的 S 控制纯色中混入白色的量，值越大，混入的白色越少，颜色越纯。
• HSV 中的 V 控制纯色中混入黑色的量，值越大，混入的黑色越少，明度越高。
• HSL 中的 S 和黑白没有关系，饱和度不控制颜色中混入白色和黑色的多少。
• HSL 中的 L 控制纯色中混入白色和黑色的多少。

以 Photoshop 和 Afiinity Photo 两款软件的拾色器为例：

两个软件分别采用 HSV 和 HSL 色彩空间，其横轴为饱和度（S），纵轴分别为明度（V）和亮度（L）。不难看出，在 Photoshop 拾色器中，越往上混入的黑色越少，明度越高；越往右混入的白色越少，纯度越高。在 Afiinity Photo 拾色器中，下部为纯黑色，亮度最小，从下往上，混入的黑色逐渐减少，直到 50% 位置处完全没有黑色混入，继续往上走，混入的白色逐渐增加，直到 100% 位置处完全变为纯白色，亮度最高。

直方图

图像直方图是反映图像色彩亮度的直方图，其中 $x$ 轴表示亮度值，$y$ 轴表示图像中该亮度值像素点的个数。以 $8$ 位图像为例，亮度的取值范围为 $\left[0, 2^8-1\right]$，即 $\left[0, 255\right]$。以如下图片为例（原始图片：链接）：

在 Lightroom 中直方图如下所示：

利用 Python 绘制的直方图如下所示：

import cv2

import numpy as np
import matplotlib.pyplot as plt

gray_img = cv2.imread('demo.jpg', cv2.IMREAD_GRAYSCALE)
img = cv2.imread('demo.jpg')
img_channels = cv2.split(img)
height, width = gray_img.shape
gray_img_hist = cv2.calcHist([gray_img], [0], None, [256], [0, 256])
img_channels_hist = [cv2.calcHist([img_channel], [0], None, [256], [0, 256])
                     for img_channel in img_channels]

fig, ax = plt.subplots(1, 1)

ax.plot(gray_img_hist, color='0.6', label='灰')

for (img_channel_hist, color, label) in zip(
  img_channels_hist, ['#6695ff', '#70df5f', '#f74048'], ['蓝', '绿', '红']):
    ax.plot(img_channel_hist, color=color, label=label)

segments = [0, 28, 85, 170, 227, 255]
segments_text = ['黑色', '阴影', '曝光', '高光', '白色']

for (left_border, right_border, segment_text) in \
        zip(segments[:-1], segments[1:], segments_text):
  if left_border != 0:
    ax.axvline(x=left_border, ymin=0, color='black')
  
  ax.annotate(
      segment_text,
      xy=((left_border + right_border) / 2, np.max(img_channels_hist) / 3),
      ha='center')

ax.legend(loc='upper center')
plt.xlim([0, 256])
ax.set_xticks([0, 32, 64, 96, 128, 160, 192, 224, 256])
ax.axes.get_yaxis().set_visible(False)

plt.tight_layout()
fig.set_size_inches(8, 4)
plt.savefig('demo-image-histgram.png', dpi=100)

直方图以 $28, 85, 170, 227$ 为分界线可以划分为黑色、阴影、曝光、高光、白色共 5 个区域。其中曝光区域以适中的亮度保留了图片最多的细节，阴影和高光对应了照片中较暗和较亮的区域，黑色和白色两个部分则几乎没有任何细节。当整个直方图过于偏左时表示欠曝，过于偏右时则表示过曝。

色温

色温（Temperature）是指照片中光源发出相似的光的黑体辐射体所具有的开尔文温度。开尔文温度越低光越暖，开尔文温度越高光越冷，如下图所示：

针对图片分别应用 5000K 和 10000K 色温的对比结果如下图所示：

import math
import cv2

import numpy as np


def __kelvin_to_rgb(kelvin: int) -> (int, int, int):
  kelvin = np.clip(kelvin, min_val=1000, max_val=40000)
  temperature = kelvin / 100.0

  # 红色通道
  if temperature < 66.0:
      red = 255
  else:
      # a + b x + c Log[x] /.
      # {a -> 351.97690566805693`,
      # b -> 0.114206453784165`,
      # c -> -40.25366309332127
      # x -> (kelvin/100) - 55}
      red = temperature - 55.0
      red = 351.97690566805693 + 0.114206453784165 * red \
            - 40.25366309332127 * math.log(red)

  # 绿色通道
  if temperature < 66.0:
      # a + b x + c Log[x] /.
      # {a -> -155.25485562709179`,
      # b -> -0.44596950469579133`,
      # c -> 104.49216199393888`,
      # x -> (kelvin/100) - 2}
      green = temperature - 2
      green = -155.25485562709179 - 0.44596950469579133 * green \
              + 104.49216199393888 * math.log(green)
  else:
      # a + b x + c Log[x] /.
      # {a -> 325.4494125711974`,
      # b -> 0.07943456536662342`,
      # c -> -28.0852963507957`,
      # x -> (kelvin/100) - 50}
      green = temperature - 50.0
      green = 325.4494125711974 + 0.07943456536662342 * green \
              - 28.0852963507957 * math.log(green)

  # 蓝色通道
  if temperature >= 66.0:
      blue = 255
  elif temperature <= 20.0:
      blue = 0
  else:
      # a + b x + c Log[x] /.
      # {a -> -254.76935184120902`,
      # b -> 0.8274096064007395`,
      # c -> 115.67994401066147`,
      # x -> kelvin/100 - 10}
      blue = temperature - 10.0
      blue = -254.76935184120902 + 0.8274096064007395 * blue \
             + 115.67994401066147 * math.log(blue)

  return np.clip(red, 0, 255), np.clip(green, 0, 255), np.clip(blue, 0, 255)


def __mix_color(v1, v2, ratio: float):
  return np.array((1.0 - ratio) * v1 + 0.5).astype(np.uint8) \
      + np.array(ratio * v2).astype(np.uint8)


def __keep_original_lightness(original_image, image):
  original_l = cv2.cvtColor(original_image, cv2.COLOR_BGR2HLS)[..., 1]
  h, l, s = cv2.split(cv2.cvtColor(image, cv2.COLOR_BGR2HLS))

  return cv2.cvtColor(cv2.merge([h, original_l, s]), cv2.COLOR_HLS2BGR)


def apply_temperature(
        image,
        temperature,
        keep_original_lightness: bool = True):
  b, g, r = cv2.split(image)
  n_b = np.clip(b.astype(np.single) - temperature, 0, 255).astype(np.uint8)
  n_r = np.clip(r.astype(np.single) + temperature, 0, 255).astype(np.uint8)
  ret_image = cv2.merge([n_b, g, n_r])

  return __keep_original_lightness(image, ret_image) \
      if keep_original_lightness else ret_image


def apply_kelvin(
        image,
        kelvin: int,
        strength: float = 0.6,
        keep_original_lightness: bool = True):
  b, g, r = cv2.split(image)
  k_r, k_g, k_b = __kelvin_to_rgb(kelvin)
  n_r, n_g, n_b = __mix_color(r, k_r, strength), \
      __mix_color(g, k_g, strength), __mix_color(b, k_b, strength)
  ret_image = cv2.merge([n_b, n_g, n_r])

  return __keep_original_lightness(image, ret_image) \
      if keep_original_lightness else ret_image


img = cv2.imread('demo.jpg')
cv2.imwrite('demo-color-temperature-cold.jpg', apply_kelvin(img, 5000))
cv2.imwrite('demo-color-temperature-cold.jpg', apply_kelvin(img, 10000))

色调

色调（Tint）允许我们为了实现中和色偏或增加色偏的目的，而将色偏向绿色或洋红色转变。针对图片分别应用 -30 和 +30 色调的对比结果如下图所示：

import cv2

import numpy as np


def __keep_original_lightness(original_image, image):
  original_l = cv2.cvtColor(original_image, cv2.COLOR_BGR2HLS)[..., 1]
  h, l, s = cv2.split(cv2.cvtColor(image, cv2.COLOR_BGR2HLS))

  return cv2.cvtColor(cv2.merge([h, original_l, s]), cv2.COLOR_HLS2BGR)


def apply_tint(image, tint, keep_original_lightness: bool = True):
  b, g, r = cv2.split(image)
  n_g = np.clip(g.astype(np.single) + tint, 0, 255).astype(np.uint8)
  ret_image = cv2.merge([b, n_g, r])

  return __keep_original_lightness(image, ret_image) \
    if keep_original_lightness else ret_image


img = cv2.imread('demo.jpg')
cv2.imwrite('demo-color-tint-negative.jpg', apply_tint(img, -30))
cv2.imwrite('demo-color-tint-positive.jpg', apply_tint(img, +30))

2023-03-19 08:00:00

本文主要面向希望在游戏空闲时段将显卡用于科学事业的朋友们😎。

更新于 2024-05-19

终端

工欲善其事必先利其器，开发离不开那个黑框框，所以我们需要把这个黑框框变得更好看更好用些。Windows 终端是一个新的支持 PowerShell 和 WSL bash 的应用，通过应用商店 直接进行安装。

建议安装最新版的 PowerShell 作为命令行环境，相关下载和配置详见官网。

为了更好的在终端中显示中英文和图标，推荐使用 Sarasa Term SC Nerd 作为终端显示字体。

网络

为了方便使用，网络设置采用桥接模式。桥接模式需要在 Windows 中启用 Hyper-V（仅 Windows 专业版支持）。通过启用或关闭 Windows 功能开启 Hyper-V，然后重启电脑生效。

在 Hyper-V 中创建一个新的交换机，在连接类型中选择外部网络，并根据电脑的网络连接情况选择对应的桥接网卡。

通过 Get-VMSwitch -SwitchType External 可以查看创建的交换机：

Name SwitchType NetAdapterInterfaceDescription
---- ---------- ------------------------------
WSL  External   Realtek Gaming 2.5GbE Family Controller

在 Home 目录创建 .wslconfig 文件，并添加如下内容：

[wsl2]
networkingMode=bridged
vmSwitch=WSL
ipv6=true

其中，vmSwitch 填写创建的交换机的名称。

WSL

以管理员模式打开 PowerShell 或 Windows 命令提示符，输入如下命令，并重启计算机：

wsl --install

此命令会启用 WSL 并安装 Ubuntu 发行版 Linux。通过 wsl -l -o 可以查看所有 Linux 的发行版：

以下是可安装的有效分发的列表。
请使用“wsl --install -d <分发>”安装。

NAME                                   FRIENDLY NAME
Ubuntu                                 Ubuntu
Debian                                 Debian GNU/Linux
kali-linux                             Kali Linux Rolling
Ubuntu-18.04                           Ubuntu 18.04 LTS
Ubuntu-20.04                           Ubuntu 20.04 LTS
Ubuntu-22.04                           Ubuntu 22.04 LTS
Ubuntu-24.04                           Ubuntu 24.04 LTS
OracleLinux_7_9                        Oracle Linux 7.9
OracleLinux_8_7                        Oracle Linux 8.7
OracleLinux_9_1                        Oracle Linux 9.1
openSUSE-Leap-15.5                     openSUSE Leap 15.5
SUSE-Linux-Enterprise-Server-15-SP4    SUSE Linux Enterprise Server 15 SP4
SUSE-Linux-Enterprise-15-SP5           SUSE Linux Enterprise 15 SP5
openSUSE-Tumbleweed                    openSUSE Tumbleweed

通过 wsl --install -d <发行版名称> 可以安装其他发行版 Linux，本文以 Ubuntu 22.04 为例。通过 wsl -l -v 可以查看当前运行的 WSL 版本：

  NAME                   STATE           VERSION
* Ubuntu-22.04           Running         2

通过 wsl 新安装的 Linux 默认已经设置为 WSL 2。

进入 Ubuntu 命令行，输入如下命令安装必要的系统依赖：

sudo apt install gcc

安装 zsh 作为 Ubuntu 默认的 Shell：

sudo apt install zsh

安装 Oh My Zsh 来提升 zsh 的易用性。

显卡

驱动

从 Nvidia 官网（https://www.nvidia.cn/geforce/drivers）下载适用于 Windows 的最新驱动并安装。进入 Windows 命令行，输入 nvidia-smi 命令查看显卡状态：

Ubuntu 中不再需要额外安装显卡驱动，进入 Ubuntu 命令行，输入 nvidia-smi 命令查看显卡状态：

不难看出，出了 nvidia-smi 工具版本不同外，显卡驱动和 CUDA 版本均是相同的。

CUDA

从 Nvidia 官网（https://developer.nvidia.com/cuda-toolkit-archive）下载适用于 WSL Ubuntu 的 CUDA，在此选择的版本为 11.8.0（具体请参考例如 Tensorflow 等所需工具的依赖版本），相关平台选项如下：

• Operating System：Linux
• Architecture：x86_64
• Distribution：WSL-Ubuntu
• Version：2.0
• Installer Type：runfile (local)

下载完毕后运行如下命令进行安装：

chmod +x cuda_11.8.0_520.61.05_linux.run
sudo ./cuda_11.8.0_520.61.05_linux.run --toolkit

其中 --toolkit 表示仅安装 CUDA 工具箱。

在弹出的 EULA 界面输入 accept 进入安装选项界面：

仅保留 CUDA Toolkit 11.8 即可，切换到 Install 并按回车键进行安装。

将如下内容添加到 ~/.bashrc 文件尾部：

export PATH=/usr/local/cuda/bin:$PATH
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda/lib64:/usr/local/cuda/extras/CUPTI/lib64

通过 source ~/.bashrc 或 source ~/.zshrc 使路径立即生效。输入 nvcc -V 查看 CUDA 编译器驱动版本：

cuDNN

从 Nvidia 官网（https://developer.nvidia.com/rdp/cudnn-archive）下载适用于 Linux 和上述安装 CUDA 版本的 cuDNN，在此选择的版本为 v8.8.0 for CUDA 11.x，安装包格式为 Local Installer for Linux x86_64 (Tar)。

注意：cuDNN 需要注册账户后方可进行下载。

下载完毕后运行如下命令进行解压：

tar -xvf cudnn-linux-x86_64-8.9.7.29_cuda11-archive.tar.xz

运行如下命令将其移动到 CUDA 目录：

sudo mv cudnn-*-archive/include/cudnn*.h /usr/local/cuda/include
sudo mv cudnn-*-archive/lib/libcudnn* /usr/local/cuda/lib64
sudo chmod a+r /usr/local/cuda/include/cudnn*.h /usr/local/cuda/lib64/libcudnn*

机器学习环境

Python

Ubuntu 22.04 系统已经安装了 Python 3.10 版本，Python 3.10 在常用机器学习库上具有较好的兼容性。因此，以 Python 3.10 版本为例，使用 venv 创建机器学习虚拟环境。在系统层面安装 venv 并创建虚拟环境：

sudo apt install python3-venv
mkdir ~/SDK
python3.10 -m venv ~/SDK/python310
source ~/SDK/python310/bin/activate

PyTorch

输入如下命令安装 PyTorch：

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118

安装完毕后发现 PyTorch 内嵌了 CUDA 和 cuDNN。内嵌的好处是可以做到安装即用，但如果和其他包依赖的系统 CUDA 和 cuDNN 版本不一致，容易出现各种意想不到的问题。在 Python 中运行如下命令验证 PyTorch 是否可以正常调用显卡：

import torch

# PyTorch 版本
torch.__version__
# 2.3.0+cu118

# CUDA 是否可用
torch.cuda.is_available()
# True

# GPU 数量
torch.cuda.device_count()
# 1

# GPU 名称
torch.cuda.get_device_name(0)
# NVIDIA GeForce RTX 3070 Ti

Tensorflow

输入如下命令安装 Tensorflow（2.14.1 版本支持 CUDA 11.8）：

pip install tensorflow==2.14.1

在 Python 中运行如下命令验证 Tensorflow 是否可以正常调用显卡：

import tensorflow as tf

# Tensorflow 版本
tf.__version__
# 2.15.1

# GPU 设备
tf.config.list_physical_devices('GPU')
# [PhysicalDevice(name='/physical_device:GPU:0', device_type='GPU')]

# GPU 名称
tf.test.gpu_device_name()
# /device:GPU:0

PyCharm

配置 PyCharm 使用 WSL 中的 Python 请参见 Configure an interpreter using WSL。

2023-03-11 08:00:00

文学编程

文学式编程（Literate Programming）是由高德纳提出的编程方法，希望能用来取代结构化编程范型。正如高德纳所构想的那样，文学编程范型不同于传统的由计算机强加的编写程序的方式和顺序，而代之以让程序员用他们自己思维内在的逻辑和流程所要求的顺序开发程序。文学编程自由地表达逻辑，而且它用人类日常使用的语言写出来，就好像一篇文章一样，文章里包括用来隐藏抽象的巨集和传统的源代码。文学编程工具用来从文学源文件中获得两种表达方式，一种用于计算机进一步的编译和执行，称作“绕出”（tangled）的代码，一种用于格式化文档，称作从文学源代码中“织出”（woven）。虽然第一代文学编程工具特定于计算机语言，但后来的工具可以不依赖具体语言，并且存在于比编程语言更高的层次中 ¹。

如高德纳在论文 ² 中所示，相同的源文件经过“tangle”可以编译为机器代码，经过“weave”可以编译为文档。

文学编程历史

从高德纳提出文学编程的概念后，各家各派都在将这个编程范式付诸实践。我接触文学编程已经比较晚了，算是从 R Markdown 和 knitr 开始，开始时写写分析报告和做做幻灯片，慢慢的在更多场景我发现这很适合。

WEB, CWEB & noweb

WEB 是一种计算机编程语言系统，它由高德纳设计，是第一种实现他称作“文学编程”的语言。WEB 包含了 2 个主要程序：TANGLE，从源文本生成可编译的 Pascal 代码，以及 WEAVE，使用 TeX 生成格式漂亮可打印的文档。CWEB 是 WEB 的 C 语言新版本，noweb 是另外一种借鉴了 WEB 的文学编程工具，同时与语言无关 ³。

以 wc.nw 为例，其为 Unix 单词统计程序 wc 的 noweb 版本重写，原始的 CWEB 版本可以在高德纳的《文学编程》一书中找到。noweb 源代码中包含 TeX 代码和 C 语言代码，每个 C 语言代码片段都以一个 <<代码片段名称>>= 开头，以 @ 结尾，程序的入口为 <<*>>=。在某个代码片段中调用其他代码片段只需要输入 <<代码片段名称>> 即可。

安装 noweb，通过如下命令可以将 wc.nw 编译为 C 语言代码 wc.c：

notangle -L wc.nw > wc.c

通过如下命令可以将 wc.nw 编译为 TeX 源代码：

noweave -autodefs c -index wc.nw > wc.tex

Org Mode

Org Mode 是由 Carsten Dominik 于 2003 年发明的用于文本编辑器 Emacs 的一种支持内容分级显示的编辑模式。这种模式下可以创建待办列表，日志管理，做笔记，做工程计划或者写网页。Org Mode 通常启用于后缀名为 org 的纯文本文件，使用星号标记有层次的内容（如文章大纲、话题与子话题、嵌套代码），并提供一组函数用于读取并展示这类标记以及操纵内容（如折叠大纲内容、移动元素、更改待办项状态）⁴。

在 Org Mode 中使用 #+BEGIN_SRC 和 #+END_SRC 来标记代码块，在 #+BEGIN_SRC 后指定嵌入的代码类型，例如嵌入 C 语言源代码：

#+BEGIN_SRC c
int main(void) {
  return 0;
}
#+END_SRC

更多关于在 Org Mode 中的文学编程应用可以参见 lujun9972/emacs-document。

Sweave & knitr

Sweave 是 R 语言的 WEB 实现，为什么是 Sweave 而不是 Rweave，没有仔细去找解释，但我猜测是由于 R 语言的前身为 S 语言吧。既然有了 Sweave 为什么没有 Stangle 呢？也是猜测，或许 Sweave 的作者在创作之初就更侧重于将 R 代码及其运行结果嵌入，“织出”最终阅读友好的文档吧。当然，由于 R 是一门统计分析语言，将所有 R 代码提取出来编译成可执行文件并不是它的优势，我猜这应该也是没有 Stangle 的一个原因吧。当然，也并不是没有人打算这么做，fusen 是一个基于 R Markdown 直接生成 R 扩展包的扩展包，从一定程度上应该算是 tangle 的理念实现吧。

Sweave 是基于 R 和 LaTeX 的实现，但 LaTeX 的学习曲线相对比较陡峭，knitr 的出现拓展了 Sweave 的功能，例如：内容方面增加支持了 Markdown 等，代码方面增加支持了 Python 等。除此之外，也衍生出了多种多样的文档格式，例如：幻灯片（xaringan），图书（bookdown）和博客（blogdown）等等。

在 R Markdown 中使用如下方式嵌入代码，在 {} 中指定嵌入代码的类型，例如嵌入并执行 R 语言源代码：

```{r}
add <- function(a, b) {
  return(a + b)
}

print(add(1, 1))
```

在同一个 R Markdown 文件中可以同时插入 R 和 Python 等多种不同语言的源代码，通过 reticulate 甚至可以实现 R 和 Python 之间的数据交互。

Jupyter

Jupyter 是从 IPython Notebook 发展而来，基于 Python 语言的强大优势，其在业界迅速占领了一大片应用市场，后来 Jupyter 也逐渐支持其他语言。虽然现在 R Markdown 也支持在 RStuido 等编辑器中逐行运行，但个人认为 Jupyter 的最大优势就在于边写边运行，这也使得 Jupyter 在教育等需要实时运行的领域应用最为广泛。

Jupyter 仍以 .ipynb 为扩展名，其底层为 JSON 格式的文本文件。原生 Jupyter 针对一个文件仅支持一种 Kernel，即运行一种类型的代码，当通过一些技巧也可以实现同时运行多种类型的代码。

Quarto

Quarto 是 Posit（RStudio 的新公司名）开发的一个基于 Pandoc 的开源技术出版系统。Quarto 的目标是改进科学和技术文档的创建和协作过程，其希望将 R Markdown、bookdown、distill、xaringan 等功能统一到一个系统中。

Quarto 的工作流程同 R Markdown 类似，如下图所示：

所以，Quarto 的到来是否意味着 R Markdown 的消失呢？官方 FAQ 给到了否定的答案。不过我认为 Quarto 「一统天下」的野心还是有的，只是基于现状可能这条路还需要再走一阵子。如下是我从当先（2023 年初）现状和个人的一些需求，认为 Quarto 和 R Markdown 之间存在的一些区别：

• 博客方面，个人需要动态输出的场景不多，blogdown 是基于 Hugo 的实现，动态文档是利用 knitr 将 R Markdown 直接渲染为 HTML 再交由 Hugo 处理。支持 Hugo 的自动化部署（例如：Cloudflare Pages，Netlify，Vercel 等）对比 Quarto 的自动化部署选择要更多些。
• 幻灯片方面，xaringan 是基于 remark.js 实现的，Quarto 是基于 reveal.js。两者没有孰优孰劣，接触 remark.js 更久一些，更熟悉一些，可能就更偏好一些，不过 remark.js 目前处于非活跃开发状态，这可能是 Quarto 选择 reveal.js 的一个原因吧。
• 书籍方面，这个不得不说 Quarto 真的是赞了。我认为书籍输出格式是所有格式中最复杂的一个，这也使得在代码执行参数、扩展组件 等方面比 bookdown 支持更灵活的 Quarto 在实践中更好用些。

还是很希望 Quarto 在未来能够做更好的统一，这也会让我们面对不同输出场景中复用更多相同的知识和技巧。

当我谈文学编程时我谈些什么

高德纳提出了文学编程的理念，Peter Seibel 也存在不同的看法：编码并非文学。其实这两者并不是对立的，只是角度不同而已。我认为文学编程更适合数据分析型工程，针对功能系统型工程确实很难融入文学编程。以当下的实践来看，从 R Markdown，到 Jupyter，再到 Quarto，无一例外是针对技术和科学等场景提供数据分析功能，而针对系统工程开发，更多还是遵循着产品文档和工程代码分离。

文学编程是一种理念，类似一门新的语言，从客观上能解决一些特定领域的问题，也能在某些场景中提高效率。但整个生态的发展离不开真正「喜欢」的人参与，不断改善和大力推广才能保证生态的持续发展。除了商业团队的主推以外，我认为开源精神和社区参与也很重要，真正的繁华从来不是一家独大而是全民参与。

可重复性研究

可重复性研究的范畴要比文学编程更广泛，文学编程主要围绕计算机相关科学展开，可重复性研究则是面向全部科学的。可重复性研究指的是科学结果应该在其推论完全透明的方式记录下来 ⁵。

上图生动地描述了可重复性研究的重要性。在此我们依旧围绕计算机相关科学讨论可重复性研究。文学编程通过将代码嵌入文档中实现了代码结果的可重复性动态生成，但除了代码之外，可重复性研究还需要关注代码的运行环境和使用的数据等，这些同样会影响研究的最终结果。

运行环境

硬件、内核、操作系统、语言、扩展包等代码运行环境都会对最终的研究结果产生影响，如下图所示：

硬件问题在苹果推出基于 arm 架构的 M1 芯片时一度带来了不少的麻烦，虽然 macOS 提供了转义工具，但在推出的早起仍出现大量软件兼容问题。不过随着这几年的发展，软件的兼容性问题已经得到了极大的改善，因此在硬件这一层几乎不再会有太多问题。

内核和操作系统可以粗略的认为是同一层级，这也是在日常研究中会经常遇到的问题。有时候在自己电脑系统上跑地好好的代码，拿到别人电脑上就会出现各种问题。在工程部署阶段，通过 docker 等虚拟化技术是可以保证代码运行的系统环境是相同的，但在分析研究阶段这并不好用。在这个层面感觉比较好的解决方案就是使用多系统兼容的软件、语言、扩展包等，如果确实需要使用指定系统的工具，在代码层面实现兼容或提示兼容问题会是不错的选择。

语言和扩展包层面的问题在真实场景中遇到的并不多，我们不必非要在 Python 和 R 中二选一，也不必非要在 PyTorch 和 Tensorflow 中二选一。但至少要保证使用相关研究领域中常用的工具、语言和扩展包，当然这些最好甚至应该是开源的，这样其他人才能够无障碍的获取相关代码依赖。

数据公开

在可重复性研究中，数据公开也很重要，没有研究的输入数据，哪怕分析代码全部公开，也无法得到相同的研究结果。最理想的情况就是完全公开所用的原始数据，但这个在涉及到私有域数据时往往又是不现实的。针对这个问题有多种可以尝试解决的方案：

1. 数据脱敏。例如：针对涉及隐私的 ID 可以转换为无意义的 ID，一般情况不会对研究产生影响。例如：针对涉及商业机密的价格或销量可以添加扰动量或进行分箱处理，但这会对研究产生一定的影响。
2. 人造数据。针对所需的数据格式完全人工创造虚拟数据，不过在复杂场景下其成本较高，甚至无法实现。

2023-01-24 08:00:00

历史尝试

入手 NAS 已经近 5 年的时间了，最初只是用来挂 PT 下载，然后在各种设备上通过 SMB 共享播放上面的视频。后面也尝试在利用 Plex 搭建家庭影音中心，但由于 Plex 的高级功能需要付费也就作罢。今年搬家后整体对各种硬件做了升级，换了软路由，做了基于 AC+AP 的全屋 WiFi，NAS 换了更大的硬盘，客厅和卧室各安装了一个投影机，入了 Apple TV 4K 和 Chromecast with Google TV 4K 两个盒子。购买 Apple TV 时买了有 Infuse 的套餐，果然没有花钱的不是，Infuse 无论是从 UI 还是体验上都算优秀，但由于仅限于苹果生态，且可玩性较差，最终也只是沦为了 Apple TV 上的本地播放器。

秉着「付费虽美丽，免费更开心」的原则，最终选择了基于 Jellyfin 的方案。由于 NAS 的 CPU 性能并不高，为了不给 NAS 其他功能带来过多压力，同时考虑软路由性能过剩，因此决定将 Jellyfin 安装在软路由上，再将 NAS 的资源挂载到软路由来实现整体解决方案。

在做 Jellyfin 选型时，其吸引我的最大优点就是开源，同时各个平台的客户端也都在官方应用商店有上架，这极大的简化了客户端的安装流程。付费解决方案，例如：Plex，Emby（在 3.5.3 之后闭源），由于有更多资金的支持，肯定在一些方面会优于 Jellyfin。其他的免费解决方案，例如：NAS 自带的 Video Station，Kodi（大学时代就曾在电脑上安装过）等在不同方面也各有差异。关于不同解决方案的一些差异在此就不再做深入探究，有兴趣的同学可以自行 Google，不过也要注意很多文章时间会比较久了，与当下的实际情况会有部分出入。

硬件设备

服务端设备

NAS 通过有线网络与主路由直连，虽然主路由网口为 2.5G，但由于 NAS 网口仅为 1000M，而且又懒于把 NAS 上的双网口做链路聚合，因此实际通讯也就限制为 1000M，但对于家庭影音中心也基本够用了。主路由上游使用了运营商提供的光猫，虽然已经改了桥接模式，但由于运营商提供的光猫 LAN 口也是 1000M 的，因此外网也无法突破千兆限制，当然还是由于 10G EPON 的万兆光猫太贵，压制了我鼓捣的欲望。

NAS 自带的内存为 2G，后面加了一条 4G 的内存扩容到 6G，最初也是计划用 NAS 玩一玩 Docker 的。但碍于 J3355 这颗 CPU 性能一般，运行太多东西给 NAS 的基本功能会带来不小压力，我想这也是群辉官方并没有给 DS418play 这款 NAS 提供 Docker 应用的主要原因吧。软路由当时买了非裸机的丐版，但由于并没有用其做太多事情，空闲内存基本上还有 3.5G 左右，因此为了充分利用 N5105 这颗 CPU，最终决定将需要视频解码这类耗 CPU 的任务交给软路由了。不过买的这款软路由是被动散热，正常待机就干到 60 摄氏度左右了，CPU 占用上来了估计有望突破 100 摄氏度😂。

客户端设备

所有客户端通过 H3C 的 1000M AC+AP 采用有线或无线间接连接到主路由。综上所述，家里各种内外部线路就都是 1000M 的理论带宽了。

客户端设备几乎覆盖了所有常用的系统，Jellyfin 在各个系统上均提供了客户端，而且可以在官方商店直接安装，这也是最终确认选择 Jellyfin 的关键一点。毕竟服务端搞得再好，客户端安装费劲的不行也是很痛苦的，尤其是在苹果生态中，官方商店的支持会让你泪大喜奔的。

NAS 准备

由于 Jellyfin 安装在软路由上，因此需要将 NAS 上的媒体文件夹通过 NFS 映射到软路由上，首先需要在 NAS 上配置客户端。进入 NAS，打开 控制面板，进入 文件服务，确保 启用 NFS 服务，最大 NFS 协议选择 NFSv4.1：

进入 共享文件夹，选择需要通过 NFS 共享的文件夹：

单击 编辑 进入共享文件夹设置：

在 NFS 权限 标签页单击 新增 添加新客户端：

相关配置如图所示，其中 服务器名称或 IP 地址 为客户端 IP 地址（即软路由 IP 地址）。依次为所有需要共享的文件夹进行相同配置。

OpenWrt 准备

软路由自带了 128G 的 NVME 固态硬盘，系统采用了 eSir 编译的高大全版本。为了后续安装扩展包和 Docker，对硬盘重新进行分区。

通过 系统 > TTYD终端 在输入用户名（root）和密码后可以进入软路由命令行，输入 fdisk -l 可以查看所有可用块设备的信息：

Disk /dev/nvme0n1: 119.24 GiB, 128035676160 bytes, 250069680 sectors
...

Device               Start       End   Sectors  Size Type
/dev/nvme0n1p1         512     33279     32768   16M Linux filesystem
/dev/nvme0n1p2       33280   1057279   1024000  500M Linux filesystem
/dev/nvme0n1p128        34       511       478  239K BIOS boot

Partition table entries are not in disk order.

输入 cfdisk /dev/nvme0n1 进入分区工具：

使用上下键选择分区，左右键选择要操作的选项。选中 Free space，使用 [New] 选项建立新的分区，输入分区大小，例如：32G：

本例计划为 overlay 分配 32G，为 docker 分配 32G，剩余全部分配给 data：

使用 [Write] 选项将结果写入分区表，并在确认处输入 yes 提交：

提交完毕后使用 [Quit] 选项退出分区工具。再次输入 fdisk -l 可以查看所有可用块设备的信息：

Disk /dev/nvme0n1: 119.24 GiB, 128035676160 bytes, 250069680 sectors
...

Device               Start       End   Sectors  Size Type
/dev/nvme0n1p1         512     33279     32768   16M Linux filesystem
/dev/nvme0n1p2       33280   1057279   1024000  500M Linux filesystem
/dev/nvme0n1p3     1058816  68167679  67108864   32G Linux filesystem
/dev/nvme0n1p4    68167680 135276543  67108864   32G Linux filesystem
/dev/nvme0n1p5   135276544 250068991 114792448 54.7G Linux filesystem
/dev/nvme0n1p128        34       511       478  239K BIOS boot

Partition table entries are not in disk order.

分别对新分区进行格式化：

mkfs.ext4 /dev/nvme0n1p3
mkfs.ext4 /dev/nvme0n1p4
mkfs.ext4 /dev/nvme0n1p5

将 /dev/nvme0n1p3 挂载至 /mnt/nvme0n1p3：

mount /dev/nvme0n1p3 /mnt/nvme0n1p3

将 /overlay 分区数据全部复制到 /mnt/nvme0n1p3 中：

cp -R /overlay/* /mnt/nvme0n1p3/

以上完成后，进入 OpenWrt 管理后台，在 系统 > 挂载点 菜单的 挂载点 处，单击 添加 按钮添加挂载点，将 /dev/nvme0n1p3 挂载为 /overlay，将 /dev/nvme0n1p4 挂载为 /opt，将 /dev/nvme0n1p5 挂载为 /data：

单击 保存&应用 后重启路由器，重启完毕后在命令行输入 df -h 可以看出所有分区均成功挂载：

Filesystem                Size      Used Available Use% Mounted on
...
/dev/nvme0n1p3           31.2G     87.9M     26.6G   0% /overlay
overlayfs:/overlay       31.2G     87.9M     26.6G   0% /
/dev/nvme0n1p4           31.2G    356.0K     29.6G   0% /opt
/dev/nvme0n1p5           53.6G     24.0K     50.8G   0% /data
...

在 /data 目录中创建用于字体的目录：

mkdir /data/fonts

下载 CJK 相关字体至该目录，例如：Noto Sans CJK。

在 /data 目录中创建用于 Jellyfin 的目录：

mkdir /data/docker
mkdir /data/docker/jellyfin
mkdir /data/docker/jellyfin/config
mkdir /data/docker/jellyfin/config/fonts
mkdir /data/docker/jellyfin/cache
mkdir /data/docker/jellyfin/media
mkdir /data/docker/jellyfin/media/nas
mkdir /data/docker/jellyfin/media/nas/disk1
mkdir /data/docker/jellyfin/media/nas/disk2
mkdir /data/docker/jellyfin/media/nas/disk3
mkdir /data/docker/jellyfin/media/nas/disk4

由于在 Docker 中需要使用 1000:1000 作为 UID 和 GID 运行 Jellyfin，需要将 jellyfin 目录修改为对应所有者：

chown -R 1000:1000 /data/docker/jellyfin/

进入命令行，输入如下命令将 NAS 上配置好的共享文件夹挂载到 Jellyfin 的相关目录：

mount.nfs -w 192.168.5.10:/volume1/Disk1 /data/docker/jellyfin/media/nas/disk1 -o nolock
mount.nfs -w 192.168.5.10:/volume2/Disk2 /data/docker/jellyfin/media/nas/disk2 -o nolock
mount.nfs -w 192.168.5.10:/volume3/Disk3 /data/docker/jellyfin/media/nas/disk3 -o nolock
mount.nfs -w 192.168.5.10:/volume4/Disk4 /data/docker/jellyfin/media/nas/disk4 -o nolock

为了保证每次启动软路由时能够自动挂载，请将上述内容添加至 系统 > 启动项 菜单下的 本地启动脚本 文本框的 exit 0 之前：

Jellyfin 部署

在 OpenWrt 上安装 Jellyfin 需要使用 Docker 进行部署。首先在 Docker > 镜像 菜单的 拉取镜像 处填写 jellyfin/jellyfin:latest，然后单击 拉取：

拉取完毕后即可在 镜像概览 处查看已下载的镜像：

进入软路由命令行，输入 ls /dev/dri，如果输出如下则表示 CPU 支持硬件加速：

card0       renderD128

为了确保在 Docker 中其他用户可以使用该设备，输入如下命令设置设备权限：

chmod 777 /dev/dri/*

通过 Docker > 容器 菜单，单击 添加 按钮添加容器。单击 命令行 并复制如下内容，单击 提交 解析命令行：

docker run -d \
 --name=jellyfin \
 --hostname=jellyfin \
 --pull=always \
 --privileged \
 --volume /data/docker/jellyfin/config:/config \
 --volume /data/docker/jellyfin/cache:/cache \
 --volume /data/docker/jellyfin/media:/media \
 --volume /data/fonts:/usr/local/share/fonts \
 --user 1000:1000 \
 --net=host \
 --restart=unless-stopped \
 --device /dev/dri/renderD128:/dev/dri/renderD128 \
 --device /dev/dri/card0:/dev/dri/card0 \
 jellyfin/jellyfin

相关参数说明如下：

如果 总是先拉取镜像 未成功自动勾选，可以手动勾选确保运行前拉取最新镜像。单击 提交 创建容器。创建完毕后容器列表即出现 Jellyfin 容器：

勾选 Jellyfin 容器，单击 启动 按钮启动容器：

Jellyfin 配置

通过 http://192.168.5.1:8096 进入 Jellyfin，首选显示语言 选择 汉语（简化字）：

单击 下一个，根据个人情况设置 用户名 和 密码：

单击 下一个，设置媒体库：

单击 + 添加媒体库：

根据实际情况进行配置：

1. 选择 内容类型 并填写 显示名称。
2. 在 文件夹 中添加所有包含当前类型媒体的文件夹。
3. 首选下载语言 选择 Chinese。
4. 国家/地区 选择 People's Republic of China。
5. 取消勾选 元数据下载器 和 图片获取程序 中所有选项。
6. 其他设置暂时保持默认。

单击 下一个，设置首选元数据语言：

单击 下一个，设置远程访问：

单击 下一个，完成设置：

单击 完成 进入登录界面：

进入系统后，单击左侧菜单按钮，选择 管理 > 控制台 菜单。进入 控制台 后，选择 服务器 > 播放 菜单。将 转码 中的 硬件加速 选择为 Video Acceleration API (VAAPI)，注意确认 VA-API 设备 是否为 /dev/dri/renderD128，并在 启用硬件解码 勾选所有媒体类型。注意确认 硬件编码选项 中的 启用硬件编码 选项已勾选。

在 服务器 > 播放 菜单中，勾选 启用备用字体，将 备用字体文件路径 设置为 /usr/local/share/fonts。

TMM 刮削

tinyMediaManager 是一个用 Java/Swing 编写的媒体管理工具，它可以为多种媒体服务器提供元数据。TMM 提供了多个平台的客户端，但为了多客户端刮削时数据共享，本例也使用 Docker 进行安装。

在软路由 /data 目录中创建用于 TMM 的目录：

mkdir /data/docker/tinymediamanager
mkdir /data/docker/tinymediamanager/config
mkdir /data/docker/tinymediamanager/media
mkdir /data/docker/tinymediamanager/media/nas
mkdir /data/docker/tinymediamanager/media/nas/disk1
mkdir /data/docker/tinymediamanager/media/nas/disk2
mkdir /data/docker/tinymediamanager/media/nas/disk3
mkdir /data/docker/tinymediamanager/media/nas/disk4

进入命令行，输入如下命令将 NAS 上配置好的共享文件夹挂载到 TMM 的相关目录：

mount.nfs -w 192.168.5.10:/volume1/Disk1 /data/docker/tinymediamanager/media/nas/disk1 -o nolock
mount.nfs -w 192.168.5.10:/volume2/Disk2 /data/docker/tinymediamanager/media/nas/disk2 -o nolock
mount.nfs -w 192.168.5.10:/volume3/Disk3 /data/docker/tinymediamanager/media/nas/disk3 -o nolock
mount.nfs -w 192.168.5.10:/volume4/Disk4 /data/docker/tinymediamanager/media/nas/disk4 -o nolock

为了保证每次启动软路由时能够自动挂载，请将上述内容添加至 系统 > 启动项 菜单下的 本地启动脚本 文本框的 exit 0 之前。

在 Docker > 镜像 菜单的 拉取镜像 处填写 romancin/tinymediamanager:latest-v4，然后单击 拉取。

通过 Docker > 容器 菜单，单击 添加 按钮添加容器。单击 命令行 并复制如下内容，单击 提交 解析命令行：

docker run -d \
 --name=tinymediamanager \
 --hostname=tinymediamanager \
 --pull=always \
 --privileged \
 --volume /data/docker/tinymediamanager/config:/config \
 --volume /data/docker/tinymediamanager/media:/media \
 --user root:root \
 --env ENABLE_CJK_FONT=1 \
 --publish 5800:5800 \
 --restart=unless-stopped \
 romancin/tinymediamanager:latest-v4

如果 总是先拉取镜像 未成功自动勾选，可以手动勾选确保运行前拉取最新镜像。单击 提交 创建容器。勾选 TMM 容器，单击 启动 按钮启动容器。

安装完毕后重启容器。通过 http://192.168.5.1:5800 进入 TMM：

根据向导进行配置，设置中文界面后需要重启容器生效。

根据个人喜好配置好 TMM 后即可对媒体文件进行刮削了，在此不再详细展开刮削过程。由于原始文件的命名可能导致自动获取的信息有误，因此建议对每一个媒体文件刮削结果进行人工复核。

4.0 之后版本的 TMM 免费版不再支持自动下载字幕，由于 TMM 采用 Open Subtitles，对于有需要双语字幕和特效字幕的同学并不友好。建议还是自行手动下载字幕并放置在媒体文件中，在此提供几个不错的字幕下载网站：

• 伪射手：https://assrt.net
• SubHD：https://subhd.tv/sub/new
• 字幕组（需注册）：https://www.yysub.net/subtitle

测试

经过 TMM 刮削后，Jellyfin 即可自动识别元数据，示例电影的详细信息如下如所示：

单击播放后，通过播放信息查看，已经可以使用 Jellyfin 实现转码在线播放：

测试完成后即可在各个终端安装相应的的客户端：

1. iPhone & iPad & Apple TV：建议使用 Swiftfin，官方应用，原生界面体验，应用商店直接下载安装。
2. Android 手机：建议使用 Findroid，第三方应用，原生界面体验，应用商店直接下载安装，非原生 Android 系统可以在 Github 页面下载离线 apk 文件安装。
3. Android TV：建议使用 Jellyfin for Android TV，官方应用，应用商店直接下载安装，非原生 Android 系统可以在 Github 页面下载离线 apk 文件安装。

可以在官方客页面探索更多官方和第三方客户端。在电视盒子等仅用于播放视频的设备上，可以尝试启用 Direct Play，当然也需要根据电视盒子的特性进行调整，避免部分格式的视频和音频无法正常解析。

2022-09-11 08:00:00

适当的自私，但不应贪婪。

学了这么多年管理，除了印象最深且还能在工作中不时提起的马斯洛需求层次理论之外，还有就是亚当斯密的经济人假设了。经济人假设每个人都以自身利益最大化为目标，我称这即为自私。社会人假设人的最大动机是社会需要，我认为这也没有逃离自私的范畴，只是需求的类型有些差异而已。苟且和远方，不分贵贱，亦可兼得，但想要的太多，抑或不劳而获，甚至痴心妄想，那这就是贪婪。

自私

不像会纠结到底是人性本善还是人性本恶，我认为人天生就是自私的。社会是由一个个人组成，脱离个体谈集体是无效的，当个体都无法被满足时，集体的功能不可能正常。我无法做到囚徒困境在神学院学生所做出的选择 ¹，那是一种超脱的信仰的力量，我肃穆敬仰，但恕我如实做不到。

不为恶

不为恶是我毕生的信条，执行起来不易。通俗些就是不给别人添堵，但并不是麻烦别人就是添堵，有时候就是需要去麻烦别人，我称这样的人为朋友。我认为不为恶是自私的底线，切莫损人利己，损人不利己就更可恨了。正道成功很难，邪门歪道却很容易让你误入歧途，但弯道超车未尝不可，至少我认为适合我这种在一些专业领域并不是专业的人。

诗和远方的动力

自私会是一种动力，而且不与社会主流价值观相违背。例如：我想买一辆越野车（这是真话，真的想买）和我要为世界和平奋斗终身（这也不是假话）。理想不分贵贱，看起来第一个是满足我一己私欲，第二个是利他主义，很有可能两者对于当下我的要求都是努力提升个人的专业素养，但第一个会更能促进我达成提高个人能力的目的。因为从提升个人能力到诗和远方，第一个离我会更近些，来的更实在些，更会让我更有动力些。同时，我认为这些“自私”的小目标积累起来有助于我达成“宏伟”的大目标。

贪婪

我想我并不贪婪，说实话要不是最近遇到一些事情，我都从来没认真审视过“贪婪”二字。当你脑海中都没有这么一个概念，你怎么可能会有这种想法呢。遇到的那件小事告诉我，贪婪容易出现在当你获得一定成就时，或许是被喜悦冲昏了头脑，在荷尔蒙的激发下会让我们变得更胆大妄为。我认为保持冷静，时不时的多给自己泼几盆冷水，多照照镜子，会让你更清楚你是谁。

原罪

七宗罪中有贪婪，没有自私。我想是因为贪婪是一种“过分”的追求，而自私并不是那么“过分”。我有很多想要的东西，至少我认为不过分，但我也会知足，因为知足常乐，人生嘛，最重要的就是开心。我会把贪婪和机会主义并列在一起，一方面机会主义的行为常常就是不顾及他人感受的添堵或为恶，另一方面机会主义所展现出的形势并不一定是“机会”。抓住机会很重要，但审视机会也不容小觑，莫让“机会”冲昏了头脑。

量力而为

贪婪是无休止的自私，不切实际的自私，贪得无厌描述的恰到其实。士兵突击中团长对许三多说的话我觉得放在这很贴切：“想要和得到，中间还有两个字，那就是要做到，你只有做到，你才能得到嘛”。认清自己，量力而为，清楚想要什么需要付出多少，然后去奋斗，去努力，才有可能得到。也许有人会说，你不做，怎么知道做不到？这句话我也挑不出什么毛病，但我想一个人的能力除了能够洞察机会，能认清现实也是很牛的一批。

我的选择

适当的自私。有底线，通过自我认知和自我实践，拼搏奋斗，承担责任，包容利他。有底线是明确大是大非，不为恶。自我认知和实践是认清自己和所处的环境，切莫空想和冲动。拼搏奋斗是说要去做，努力去做，才有机会自我实现。承担责任是说不要什么都是“关我屁事”和“关你屁事”，我们是自己，也是社会的一员，有权利，也有义务和责任，该承担还是要承担，这才像个爷们。包容利他我想必然就会是这样做之后超越极端自私的结果。

2022-05-22 08:00:00

在之前的博客「投票公平合理吗？」中已经得到了一个令人沮丧的结论：只有道德上的相对民主，没有制度上的绝对公平。投票是对不同选项或个体的排序，在投票中我们关注更多是相对位置这样定性的结论，例如：积分前三名的同学才能进入下一环节。但有的时候我们不光想知道不同选项之间的先后顺序，还想了解不同选项之间的差异大小，这时我们就需要设计更精细的方法进行定量分析。

基础评分和排名

直接评分

从小到大被评分最多的应该就是考试了，100，120 或是 150，这三个数字应该从小学一年级一直“陪”我们走过十几载青春。考试的评分算法简单且容易区分，整个系统设置了一个总分，根据不同的表现进行加分或扣分，统计最终得分作为最后的评分。一般情况下成绩是一个近似正态分布的偏态分布，如下图所示。

如果成绩近似正态分布（如上图-中），则说明本次考试难度分布较为均衡；如果成绩分布整体向左偏（如上图-左），则说明本次考试较为困难，学生成绩普遍偏低；如果成绩分布整体向右偏（如上图-右），则说明本次考试较为容易，学生成绩普遍偏高。

除此之外，也可能出现双峰分布，以及峰的陡峭和平缓都能反应考试的不同问题，在此就不再一一展开说明。一般情况下，考试的最终成绩已经能够很好地对学生的能力进行区分，这也正是为什么一般情况我们不会对考试分数做二次处理，而是直接使用。

加权评分

在现实生活中，不同的问题和任务难易程度不同，为了保证「公平」，我们需要赋予困难的任务更多的分数。这一点在试卷中也会有体现，一般而言判断题会比选择题分数更低，毕竟随机作答，判断题仍有 50% 的概率回答正确，但包含四个选项的选择题却仅有 25% 概率回答正确。

加权评分在问题和任务的难易程度与分值之间通过权重进行平衡，但权重的制定并不是一个容易的过程，尤其是在设置一个兼顾客观、公平、合理等多维度的权重时。

考虑时间的评分和排名

Delicious

最简单直接的方法是在一定的时间内统计投票的数量，得票数量高的则为更好的项目。在旧版的 Delicious 中，热门书签排行榜则是根据过去 60 分钟内被收藏的次数进行排名，每 60 分钟重新统计一次。

这种算法的优点是：简单、容易部署、更新快；缺点是：一方面，排名变化不够平滑，前一个小时还排名靠前的内容，往往第二个小时就一落千丈，另一方面，缺乏自动淘汰旧项目的机制，某些热门内容可能会长期占据排行榜前列。

Hacker News

Hacker News 是一个可以发布帖子的网络社区，每个帖子前面有一个向上的三角形，如果用户觉得这个内容好，点击一下即可投票。根据得票数，系统自动统计出热门文章排行榜。

Hacker News 使用分数计算公式如下：

$$ Score = \dfrac{P - 1}{\left(T + 2\right)^G} \label{eq:hacker-news} $$

其中，$P$ 表示帖子的得票数，减去 $1$ 表示忽略发帖人的投票；$T$ 表示当前距离发帖的时间（单位为小时），加上 $2$ 是为了防止最新的帖子分母过小；$G$ 为重力因子，即将帖子排名被往下拉的力量，默认值为 $1.8$。

在其他条件不变的情况下，更多的票数可以获得更高的分数，如果不希望“高票数”帖子和“低票数”帖子之间差距过大，可以在式 $\ref{eq:hacker-news}$ 的分子中添加小于 $1$ 的指数，例如：$\left(P - 1\right)^{0.8}$。在其他条件不变的情况下，随着时间不断流逝，帖子的分数会不断降低，经过 24 小时后，几乎所有帖子的分数都将小于 $1$。重力因子对于分数的影响如下图所示：

不难看出，$G$ 值越大，曲线越陡峭，排名下降的速度越快，意味着排行榜的更新速度越快。

Reddit

不同于 Hacker News，Reddit 中的每个帖子前面都有向上和向下的箭头，分别表示"赞成"和"反对"。用户点击进行投票，Reddit 根据投票结果，计算出最新的热点文章排行榜。

Reddit 关于计算分数的代码可以简要总结如下：

from datetime import datetime, timedelta
from math import log

epoch = datetime(1970, 1, 1)

def epoch_seconds(date):
    td = date - epoch
    return td.days * 86400 + td.seconds + (float(td.microseconds) / 1000000)

def score(ups, downs):
    return ups - downs

def hot(ups, downs, date):
    s = score(ups, downs)
    order = log(max(abs(s), 1), 10)
    sign = 1 if s > 0 else -1 if s < 0 else 0
    seconds = epoch_seconds(date) - 1134028003
    return round(order + sign * seconds / 45000, 7)

分数的计算过程大致如下：

1. 计算赞成票和反对票的差值，即： $$ s = ups - downs $$
2. 利用如下公式计算中间分数，即： $$ order = \log_{10} \max\left(\left|s\right|, 1\right) $$ 其中，取 $\left|s\right|$ 和 $1$ 的最大值是为了避免当 $s = 0$ 时，无法计算 $\log_{10}{\left|s\right|}$。赞成票与反对票差值越大，得分越高。取以 $10$ 为底的对数，表示当 $s = 10$ 时，这部分为 $1$，只有 $s = 100$ 时才为 $2$，这样设置是为了减缓差值增加对总分的影响程度。
3. 确定分数的方向，即： $$ sign = \begin{cases} 1 & \text{如果} \ s > 0 \\ 0 & \text{如果} \ s = 0 \\ -1 & \text{如果} \ s < 0 \end{cases} $$
4. 计算发贴时间距离 2005 年 12 月 8 日 7:46:43（Reddit 的成立时间？）的秒数，即： $$ seconds = \text{timestamp}\left(date\right) - 1134028003 $$
5. 计算最终分数，即： $$ score = order + sign \times \dfrac{seconds}{45000} $$ 将时间除以 $45000$ 秒（即 12.5 个小时），也就是说当前天的帖子会比昨天的帖子多约 $2$ 分。如果昨天的帖子想要保持住之前的排名，则 $s$ 值需要增加 $100$ 倍才可以。

Reddit 评分排名算法决定了 Reddit 是一个符合大众口味的社区，而不是一个适合展示激进想法的地方。因为评分中使用的是赞成票和反对票的差值，也就是说在其他条件相同的情况下，帖子 A 有 1 票赞成，0 票反对；帖子 B 有 1000 票赞成，1000 票反对，但讨论火热的帖子 B 的得分却比 帖子 A 要少。

Stack Overflow

Stack Overflow 是世界排名第一的程序员问答社区。用户可以在上面提出各种关于编程的问题，等待别人回答；可以对问题进行投票（赞成票或反对票），表示这个问题是不是有价值；也可以对这个回答投票（赞成票或反对票），表示这个回答是不是有价值。

在 Stack Overflow 的页面上，每个问题前面有三个数字，分别为问题的得分、回答的数量和问题的浏览次数。

创始人之一的 Jeff Atwood 公布的评分排名的计算公式如下：

$$ \dfrac{4 \times \log_{10}{Q_{views}} + \dfrac{Q_{answers} \times Q_{score}}{5} + \sum \left(A_{scores}\right)}{\left(\left(Q_{age} + 1\right) - \left(\dfrac{Q_{age} - Q_{updated}}{2}\right)\right)^{1.5}} $$

其中：

1. $4 \times \log_{10}{Q_{views}}$ 表示问题的浏览次数越多，得分越高，同时利用 $\log_{10}$ 减缓了随着浏览量增大导致得分变高的程度。
2. $\dfrac{Q_{answers} \times Q_{score}}{5}$ 表示问题的得分（赞成票和反对票之差）越高，回答的数量越多，分数越高。采用乘积的形式意味着即使问题本身的分数再高，没有人回答的问题也算不上热门问题。
3. $\sum \left(A_{scores}\right)$ 表示问题回答的总分数。回答总分采用了简单的加和，但实际上一个正确的回答要胜过多个无用的回答，简答的加和无法很好的区分这两种不同的情况。
4. $\left(\left(Q_{age} + 1\right) - \left(\dfrac{Q_{age} - Q_{updated}}{2}\right)\right)^{1.5}$ 可以改写为 $\left(\dfrac{Q_{age}}{2} + \dfrac{Q_{updated}}{2} + 1\right)^{1.5}$，$Q_{age}$ 和 $Q_{updated}$ 分别表示问题和最近一次回答的时间（单位为小时），也就是说问题时间越久远，最近一次回答时间约久远，分母就会越大，从而得分就会越小。

Stack Overflow 的评分排名算法考虑了参与程度（问题浏览次数和回答次数）、质量（问题分数和回答分数）、时间（问题时间和最近一次回答时间）等多个维度。

不考虑时间的评分和排名

上文中介绍的评分和排名方法多适用于具有时效性的信息，但是对于图书、电影等无需考虑时间因素的情况而言，则需要其他方法进行衡量。

威尔逊区间算法

在不考虑时间的情况下，以「赞成」和「反对」两种评价方式为例，通常我们会有两种最基础的方法计算得分。第一种为绝对分数，即：

$$ \text{评分} = \text{赞成票} - \text{反对票} $$

但这种计算方式有时会存在一定问题，例如：A 获得 60 张赞成票，40 张反对票；B 获得 550 张赞成票，450 张反对票。根据上式计算可得 A 的评分为 20，B 的评分为 100，所以 B 要优于 A。但实际上，B 的好评率仅有 $\dfrac{550}{550 + 450} = 55\%$，而 A 的好评率为 $\dfrac{60}{60 + 40} = 60\%$，因此实际情况应该是 A 优于 B。

这样，我们就得到了第二种相对分数，即：

$$ \text{评分} = \dfrac{\text{赞成票}}{\text{赞成票} + \text{反对票}} $$

这种方式在总票数比较大的时候没有问题，但总票数比较小时就容易产生错误。例如：A 获得 2 张赞成票，0 张反对票；B 获得 100 张赞成票，1 张反对票。根据上式计算可得 A 的评分为 $100\%$，B 的评分为 $99\%$。但实际上 B 应该是优于 A 的，由于 A 的总票数太少，数据不太具有统计意义。

对于这个问题，我们可以抽象出来：

1. 每个用户的投票都是独立事件。
2. 用户只有两个选择，要么投赞成票，要么投反对票。
3. 如果投票总人数为 $n$，其中赞成票为 $k$，则赞成票的比例 $p = \dfrac{k}{n}$。

不难看出，上述过程是一个二项实验。$p$ 越大表示评分越高，但是 $p$ 的可信性取决于投票的人数，如果人数太少，$p$ 就不可信了。因此我们可以通过计算 $p$ 的置信区间对评分算法进行调整如下：

1. 计算每个项目的好评率。
2. 计算每个好评率的置信区间。
3. 根据置信区间的下限值进行排名。

置信区间的本质就是对可信度进行修正，弥补样本量过小的影响。如果样本足够多，就说明比较可信，则不需要很大的修正，所以置信区间会比较窄，下限值会比较大；如果样本比较少，就说明不一定可信，则需要进行较大的修正，所以置信区间会比较宽，下限值会比较小。

二项分布的置信区间有多种计算公式，最常见的「正态区间」方法对于小样本准确性较差。1927 年，美国数学家 Edwin Bidwell Wilson 提出了一个修正公式，被称为「威尔逊区间」，很好地解决了小样本的准确性问题。置信区间定义如下：

$$ \frac{1}{1+\frac{z^{2}}{n}}\left(\hat{p}+\frac{z^{2}}{2 n}\right) \pm \frac{z}{1+\frac{z^{2}}{n}} \sqrt{\frac{\hat{p}(1-\hat{p})}{n}+\frac{z^{2}}{4 n^{2}}} $$

其中，$\hat{p}$ 表示样本好评率，$n$ 表示样本大小，$z$ 表示某个置信水平的 z 统计量。

贝叶斯平均算法

在一些榜单中，有时候会出现排行榜前列总是那些票数最多的项目，新项目或者冷门的项目很难有出头机会，排名可能会长期靠后。以世界最大的电影数据库 IMDB 为例，观众可以对每部电影投票，最低为 1 分，最高为 10 分，系统根据投票结果，计算出每部电影的平均得分。

这就出现了一个问题：热门电影与冷门电影的平均得分，是否真的可比？例如一部好莱坞大片有 10000 个观众投票，一部小成本的文艺片可能只有 100 个观众投票。如果使用威尔逊区间算法，后者的得分将被大幅拉低，这样处理是否公平，是否能反映电影的真正质量呢？在 Top 250 榜单中，IMDB 给到的评分排名计算公式如下：

$$ WR = \dfrac{v}{v + m} R + \dfrac{m}{v + m} C $$

其中，$WR$ 为最终的加权得分，$R$ 为该电影用户投票的平均得分，$v$ 为该电影的投票人数，$m$ 为排名前 250 电影的最低投票数，$C$ 为所有电影的平均得分。

从公式中可以看出，分量 $m C$ 可以看作为每部电影增加了评分为 $C$ 的 $m$ 张选票。然后再根据电影自己的投票数量 $v$ 和投票平均分 $R$ 进行修正，得到最终的分数。随着电影投票数量的不但增加 $\dfrac{v}{v + m} R$ 占的比重将越来越大，加权得分也会越来越接近该电影用户投票的平均分。

将公式写为更一般的形式，有：

$$ \bar{x}=\frac{C m+\sum_{i=1}^{n} x_{i}}{C+n} $$

其中，$C$ 为需要扩充的投票人数规模，可以根据投票人数总量设置一个合理的常数，$n$ 为当前项目的投票人数，$x$ 为每张选票的值，$m$ 为总体的平均分。这种算法称为「贝叶斯平均」。在这个公式中，$m$ 可以视为“先验概率”，每新增一次投票，都会对最终得分进行修正，使其越来越接近真实的值。

比赛评分和排名

Kaggle 积分

Kaggle 是一个数据建模和数据分析竞赛平台。企业和研究者可在其上发布数据，统计学者和数据挖掘专家可在其上进行竞赛以产生最好的模型。用户以团队形式参加 Kaggle 的比赛，团队可以仅包含自己一人，根据在每场比赛中的排名不断获取积分，用做 Kaggle 网站中的最终排名。

早期 Kaggle 对于每场比赛的积分按如下方式计算：

$$ \left[\dfrac{100000}{N_{\text {teammates }}}\right]\left[\text{Rank}^{-0.75}\right]\left[\log _{10}\left(N_{\text {teams }}\right)\right]\left[\dfrac{2 \text { years - time }}{2 \text { years }}\right] $$

在 2015 年对新的排名系统做了调整，新的比赛积分计算公式调整为：

$$ \left[\dfrac{100000}{\sqrt{N_{\text {teammates }}}}\right]\left[\text{Rank}^{-0.75}\right]\left[\log _{10}\left(1+\log _{10}\left(N_{\text {teams }}\right)\right)\right]\left[e^{-t / 500}\right] $$

其中，$N_{\text{teammates}}$ 为团队成员的数量，$\text{Rank}$ 为比赛排名，$N_{\text{teams}}$ 为参赛的团队数量，$t$ 为从比赛结束之日起过去的时间。

第一部分可以视为基础分，团队成员越少，所获得的基础分越多。从调整的文档来看，Kaggle 认为团队合作每个人的贡献程度会大于 $1 / N_{\text {teammates}}$，为了鼓励大家团队合作，Kaggle 减少了对团队人数的基础分惩罚力度。

第二部分则是根据用户在比赛中的排名得到一个小于等于 1 的系数。下图显示了不同的指数以及 $1 / \text{Rank}$ 之间的区别：

从图中可以看出，通过调节指数的大小可以控制系数随排名下降而下降的速度。整体来说，Kaggle 更加重视前几名，对于 10 名开外的选手，系数均小于 $0.2$，且差异不大。

第三部分可以理解为通过参赛的队伍数量来衡量比赛的受欢迎程度（或是在众多参赛队伍中脱颖而出的难易程度）。以 100 和 1000 支参赛队伍对比为例，根据之前的计算公式，这一部分为：

$$ \begin{equation} \begin{aligned} \log_{10} \left(100\right) &= 2 \\ \log_{10} \left(1000\right) &= 3 \end{aligned} \end{equation} $$

但随着 Kaggle 本身比赛流行度越来越高，官方认为赢得一场 1000 人的比赛并不需要比赢得一场 100 人的比赛需要多 $50\%$ 的技能，因此通过调整后的算法，这个比例调整至大约为 $25\%$。

$$ \begin{equation} \begin{aligned} \log_{10} \left(\log_{10} \left(100\right) + 1\right) &\approx 0.47 \\ \log_{10} \left(\log_{10} \left(1000\right) + 1\right) &\approx 0.6 \end{aligned} \end{equation} $$

第四部份为时间衰减项，调整为新的计算公式后可以消除原来通过设置 2 年时限导致的积分断崖。如果任何一对个体都没有采取任何进一步的行动，那么排名不应该在任何一对个体之间发生变化。换句话说，如果整个 Kaggle 用户群停止参加比赛，他们的相对排名应该随着时间的推移保持不变。选择 $1 / 500$ 的原因是可以将旧的 2 年断崖延长到更长的时间范围，并且永远不会变为 0。

Elo 评分系统

Elo 评分系统（Elo Rating System）是由匈牙利裔美国物理学家 Arpad Elo 创建的一个衡量各类对弈活动水平的评价方法，是当今对弈水平评估公认的权威标准，且被广泛用于国际象棋、围棋、足球、篮球等运动。网络游戏的竞技对战系统也常采用此评分系统。

Elo 评分系统是基于统计学的一个评估棋手水平的方法。Elo 模型原先采用正态分布，但实践显明棋手的表现并非正态分布，所以现在的评分计分系统通常使用的是逻辑分布。

假设棋手 A 和 B 的当前评分分别为 $R_A$ 和 $R_B$，则按照逻辑分布，A 对 B 的胜率期望值为：

$$ E_{A}=\frac{1}{1+10^{\left(R_{B}-R_{A}\right) / 400}} $$

类似的有 B 对 A 的胜率期望值为：

$$ E_{B}=\frac{1}{1+10^{\left(R_{A}-R_{B}\right) / 400}} $$

假如一位棋手在比赛中的真实得分 $S_{A}$（胜 1 分，和 0.5 分，负 0 分）和他的胜率期望值 $E_{A}$ 不同，则他的评分要作相应的调整：

$$ R_{A}^{\prime} = R_{A} + K\left(S_{A}-E_{A}\right) $$

公式中 $R_{A}$ 和 $R_{A}^{\prime }$ 分别为棋手调整前后的评分。$K$ 值是一个极限值，代表理论上最多可以赢一个玩家的得分和失分，$K / 2$ 就是相同等级的玩家其中一方胜利后所得的分数。国际象棋大师赛中，$K = 16$；在大部分的游戏规则中，$K = 32$。通常水平越高的比赛中其 $K$ 值越小，这样做是为了避免少数的几场比赛就能改变高端顶尖玩家的排名。$E_A$ 和 $E_B$ 中的 $400$ 是让多数玩家积分保持标准正态分布的值，在 $K$ 相同的情况下，分母位置的值越大，积分变化值越小。

Glicko 评分系统

Glicko 评分系统（Glicko Rating System）及 Glicko-2 评分系统（Glicko-2 Rating System）是评估选手在比赛中（如国际象棋及围棋）的技术能力方法之一。此方法由马克·格利克曼发明，原为国际象棋评分系统打造，后作为评分评分系统的改进版本广泛应用 ¹。

Elo 评分系统的问题在于无法确定选手评分的可信度，而 Glicko 评分系统正是针对此进行改进。假设两名评分均为 1700 的选手 A 和 B 在进行一场对战后 A 获得胜利，在美国国际象棋联赛的 Elo 评分系统下，A 选手评分将增长 16，对应的 B 选手评分将下降 16。但是假如 A 选手是已经很久没玩，但 B 选手每周都会玩，那么在上述情况下 A 选手的 1700 评分并不能十分可信地用于评定其实力，而 B 选手的 1700 评分则更为可信。

Glicko 算法的主要贡献是“评分可靠性”（Ratings Reliability），即评分偏差（Ratings Deviation）。若选手没有评分，则其评分通常被设为 1500，评分偏差为 350。新的评分偏差（$RD$）可使用旧的评分偏差（$RD_0$）计算：

$$ RD = \min \left(\sqrt{RD_0^2 + c^2 t}, 350\right) $$

其中，$t$ 为自上次比赛至现在的时间长度（评分期），常数 $c$ 根据选手在特定时间段内的技术不确定性计算而来，计算方法可以通过数据分析，或是估算选手的评分偏差将在什么时候达到未评分选手的评分偏差得来。若一名选手的评分偏差将在 100 个评分期间内达到 350 的不确定度，则评分偏差为 50 的玩家的常数 $c$ 可通过解 $350 = \sqrt{50^2 + 100 c^2}$，则有 $c = \sqrt{\left(350^2 - 50^2\right) / 100} \approx 34.6$。

在经过 $m$ 场比赛后，选手的新评分可通过下列等式计算：

$$ r=r_{0}+\frac{q}{\frac{1}{R D^{2}}+\frac{1}{d^{2}}} \sum_{i=1}^{m} g\left(R D_{i}\right)\left(s_{i}-E\left(s \mid r_{0}, r_{i}, R D_{i}\right)\right) $$

其中：

$$ \begin{equation*} \begin{aligned} & g\left(R D_{i}\right) = \frac{1}{\sqrt{1+\frac{3 q^{2}\left(R D_{i}^{2}\right)}{\pi^{2}}}} \\ & E\left(s \mid r, r_{i}, R D_{i}\right) = \frac{1}{1+10\left(\frac{g\left(R D_{i}\right)\left(r_{0}-r_{i}\right)}{-400}\right)} \\ & q = \frac{\ln (10)}{400}=0.00575646273 \\ & d^{2} = \frac{1}{q^{2} \sum_{i=1}^{m}\left(g\left(R D_{i}\right)\right)^{2} E\left(s \mid r_{0}, r_{i}, R D_{i}\right)\left(1-E\left(s \mid r_{0}, r_{i}, R D_{i}\right)\right)} \end{aligned} \end{equation*} $$

$r_i$ 表示选手个人评分，$s_i$ 表示每场比赛后的结果。胜利为 $1$，平局为 $1 / 2$，失败为 $0$。

原先用于计算评分偏差的函数应增大标准差值，进而反应模型中一定非观察时间内，玩家的技术不确定性的增长。随后，评分偏差将在几场游戏后更新：

$$ R D^{\prime}=\sqrt{\left(\frac{1}{R D^{2}}+\frac{1}{d^{2}}\right)^{-1}} $$

Glicko-2 评分系统

Glicko-2 算法与原始 Glicko 算法类似，增加了一个评分波动率 $\sigma$，它根据玩家表现的不稳定程度来衡量玩家评分的预期波动程度。例如：当一名球员的表现保持稳定时，他们的评分波动性会很低，如果他们在这段稳定期之后取得了异常强劲的成绩，那么他们的评分波动性就会增加 ¹。

Glicko-2 算法的简要步骤如下：

计算辅助量

在一个评分周期内，当前评分为 $\mu$ 和评分偏差为 $\phi$ 的玩家与 $m$ 个评分为 $\mu_1, \cdots, \mu_m$ 和评分偏差为 $\phi_1, \cdots, \phi_m$ 的玩家比赛，获得的分数为 $s_1, \cdots, s_m$，我们首先需要计算辅助量 $v$ 和 $\Delta$：

$$ \begin{aligned} v &= \left[\sum_{j=1}^{m} g\left(\phi_{j}\right)^{2} E\left(\mu, \mu_{j}, \phi_{j}\right)\left\{s_{j}-E\left(\mu, \mu_{j}, \phi_{j}\right)\right\}\right]^{-1} \\ \Delta &= v \sum_{j=1}^{m} g\left(\phi_{j}\right)\left\{s_{j}-E\left(\mu, \mu_{j}, \phi_{j}\right)\right\} \end{aligned} $$

其中：

$$ \begin{equation*} \begin{aligned} &g(\phi)=\frac{1}{\sqrt{1+3 \phi^{2} / \pi^{2}}}, \\ &E\left(\mu, \mu_{j}, \phi_{j}\right)=\frac{1}{1+\exp \left\{-g\left(\phi_{j}\right)\left(\mu-\mu_{j}\right)\right\}} \end{aligned} \end{equation*} $$

确定新的评分波动率

选择一个小的常数 $\tau$ 来限制时间的波动性，例如：$\tau = 0.2$（较小的 $\tau$ 值可以防止剧烈的评分变化），对于：

$$ f(x)=\frac{1}{2} \frac{e^{x}\left(\Delta^{2}-\phi^{2}-v^{2}-e^{x}\right)}{\left(\phi^{2}+v+e^{x}\right)^{2}}-\frac{x-\ln \left(\sigma^{2}\right)}{\tau^{2}} $$

我们需要找到满足 $f\left(A\right) = 0$ 的值 $A$。解决此问题的一种有效方法是使用 Illinois 算法，一旦这个迭代过程完成，我们将新的评级波动率 $\sigma'$ 设置为：

$$ \sigma' = e^{\frac{A}{2}} $$

确定新的评分偏差和评分

之后得到新的评分偏差：

$$ \phi^{\prime} = \dfrac{1}{\sqrt{\dfrac{1}{\phi^{2}+\sigma^{\prime 2}}+\dfrac{1}{v}}} $$

和新的评分：

$$ \mu^{\prime} = \mu+\phi^{\prime 2} \sum_{j=1}^{m} g\left(\phi_{j}\right)\left\{s_{j}-E\left(\mu, \mu_{j}, \phi_{j}\right)\right\} $$

需要注意这里的评分和评分偏差与原始 Glicko 算法的比例不同，需要进行转换才能正确比较两者。

TrueSkill 评分系统

TrueSkill 评分系统是基于贝叶斯推断的评分系统，由微软研究院开发以代替传统 Elo 评分系统，并成功应用于 Xbox Live 自动匹配系统。TrueSkill 评分系统是 Glicko 评分系统的衍伸，主要用于多人游戏中。TrueSkill 评分系统考虑到了个别玩家水平的不确定性，综合考虑了各玩家的胜率和可能的水平涨落。当各玩家进行了更多的游戏后，即使个别玩家的胜率不变，系统也会因为对个别玩家的水平更加了解而改变对玩家的评分 ²。

在电子竞技游戏中，特别是当有多名选手参加比赛的时候需要平衡队伍间的水平，让游戏比赛更加有意思。这样的一个参赛选手能力平衡系统通常包含以下三个模块：

1. 一个包含跟踪所有玩家比赛结果，记录玩家能力的模块。
2. 一个对比赛成员进行配对的模块。
3. 一个公布比赛中各成员能力的模块。

能力计算和更新

TrueSkill 评分系统是针对玩家能力进行设计的，以克服现有排名系统的局限性，确保比赛双方的公平性，可以在联赛中作为排名系统使用。TrueSkill 评分系统假设玩家的水平可以用一个正态分布来表示，而正态分布可以用两个参数：平均值和方差来完全描述。设 Rank 值为 $R$，代表玩家水平的正态分布的两个参数平均值和方差分别为 $\mu$ 和 $\sigma$，则系统对玩家的评分即 Rank 值为：

$$ R = \mu - k \times \sigma $$

其中，$k$ 值越大则系统的评分越保守。

上图来自 TrueSkill 网站，钟型曲线为某个玩家水平的可能分布，绿色区域是排名系统的信念，即玩家的技能在 15 到 20 级之间。

下表格给出了 8 个新手在参与一个 8 人游戏后 $\mu$ 和 $\sigma$ 的变化。

第 4 名 Darren 和第 5 名 Eve，他们的 $\sigma$ 是最小的，换句话说系统认为他们能力的可能起伏是最小的。这是因为通过这场游戏我们对他们了解得最多：他们赢了3 和 4 个人，也输给了 4 和 3 个人。而对于第 1 名 Alice，我们只知道她赢了 7 个人。

定量分析可以先考虑最简单的两人游戏情况：

$$ \begin{aligned} &\mu_{\text {winner }} \longleftarrow \mu_{\text {winner }}+\frac{\sigma_{\text {winner }}^{2}}{c} * v\left(\frac{\mu_{\text {winner }}-\mu_{\text {loser }}}{c}, \frac{\varepsilon}{c}\right) \\ &\mu_{\text {loser }} \longleftarrow \mu_{\text {loser }}-\frac{\sigma_{\text {loser }}^{2}}{c} * v\left(\frac{\mu_{\text {winner }}-\mu_{\text {loser }}}{c}, \frac{\varepsilon}{c}\right) \\ &\sigma_{\text {winner }}^{2} \longleftarrow \sigma_{\text {uninner }}^{2} *\left[1-\frac{\sigma_{\text {winner }}^{2}}{c} * w\left(\frac{\mu_{\text {winner }}-\mu_{\text {loser }}}{c}, \frac{\varepsilon}{c}\right)\right. \\ &\sigma_{\text {loser }}^{2} \longleftarrow \sigma_{\text {loser }}^{2} *\left[1-\frac{\sigma_{\text {loser }}^{2}}{c} * w\left(\frac{\mu_{\text {winner }}-\mu_{\text {loser }}}{c}, \frac{\varepsilon}{c}\right)\right. \\ &c^{2}=2 \beta^{2}+\sigma_{\text {winner }}^{2}+\sigma_{\text {loser }}^{2} \end{aligned} $$

其中，系数 $\beta^2$ 代表的是所有玩家的平均方差，$v$ 和 $w$ 是两个函数，比较复杂，$\epsilon$ 是平局参数。简而言之，个别玩家赢了 $\mu$ 就增加，输了 $\mu$ 减小；但不论输赢，$\sigma$ 都是在减小，所以有可能出现输了涨分的情况。

对手匹配

势均力敌的对手能带来最精彩的比赛，所以当自动匹配对手时，系统会尽可能地为个别玩家安排可能水平最为接近的对手。TrueSkill 评分系统采用了一个值域为 $(0, 1)$ 的函数来描述两个人是否势均力敌：结果越接近 0 代表差距越大，越接近 1 代表水平越接近。

假设有两个玩家 A 和 B，他们的参数为 $(\mu_A, \sigma_A)$ 和 $(\mu_B, \sigma_B)$，则函数对这两个玩家的返回值为：

$$ e^{-\frac{\left(\mu_{A}-\mu_{B}\right)^{2}}{2 c^{2}}} \sqrt{\frac{2 \beta^{2}}{c^{2}}} $$

$c$ 的值由如下公式给出：

$$ c^{2}=2 \beta^{2}+\mu_{A}^{2}+\mu_{B}^{2} $$

如果两人有较大几率被匹配在一起，仅是平均值接近还不行，还需要方差也比较接近才可以。

在 Xbox Live 上，系统为每个玩家赋予的初值是 $\mu = 25$，$\sigma = \dfrac{25}{3}$ 和 $k = 3$。所以玩家的起始 Rank 值为：

$$ R=25-3 \frac{25}{3}=0 $$

相较 Elo 评价系统，TrueSkill 评价系统的优势在于：

1. 适用于复杂的组队形式，更具一般性。
2. 有更完善的建模体系，容易扩展。
3. 继承了贝叶斯建模的优点，如模型选择等。

本文主要参考了阮一峰的系列文章「基于用户投票的排名算法」和钱魏的「游戏排名算法：Elo、Glicko、TrueSkill」。

2022-04-10 08:00:00

一眨眼已经四月了，第一季度穿插着反反复复的疫情、说干就干的战争和悲痛万分的空难就这么过去了。还在用生活不易、活着真好的话宽慰自己的时候，互联网迎来了一大波裁员浪潮。说实话其实每年都在陆陆续续的传出各大厂的裁员消息，可今年这一波着实动静大了些。翻看已经有两三篇待完成的博客躺在草稿箱中有个把月了，工作和生活的各种乱七八糟的事情扰得自己完全没有动笔的欲望。算是为了不让博客列表页有太长断档吧，小记一下最近的心情，也让自己冷静下来思考二三。

人都去哪儿了？

在这波裁员浪潮之前，工作上除了项目本身以外，最重要的就是招聘。从最初组建团队一直到现在招聘就像一个看似永远完不成的项目。摆在我面前的招聘三大问题：我看上的人家不一定看得上我，看得上我的我不一定看得上人家，都看上了的因为各种各样的不可控因素最后还是没谈成。

有时候从源头上就捞不到人，没有简历，约不上面，不可否认一些岗位的门槛和稀缺性注定这就是一场艰难的战役。但从个人主观感受上来看，逃离互联网的人可能正在增长。这个观点没有任何调研为依据，单纯的从身边的案例有感，不具备统计显著性，但也不接受反驳。为什么要逃离，或许逃离这个词用的就不好，应该说是「离开」更好些，不然显得当下的互联网有多么水深火热一样。因为大环境、家庭、亦或是躺平的心态，都很难说，自己没处在这么一个情景中，也说不出个四五到六来。

很难说未来自己会不会离开互联网这个圈子，如果离开也很难说这个时点有多近还是多远，无论主动还是被动。只能说当下的互联网仍旧在不断给予我机会和挑战，在没有被困难打倒之前，我应该还是会在这条路上拼杀几载吧。

每天都在忙些啥？

我属于一个不太喜欢开会的人，可能我的层次还不太高吧，我认为大部分事情都没法在相对正式的会议上达成很好的决策，我更喜欢非正式的沟通和正式的记录配合达成目标。所以排除开会，每天到底都在忙些啥？

想要的太多，不舍得放手的太多

人总是贪婪的，虽说给永远比拿快乐，但有时候就喜欢圈起来个一亩三分地，当然圈的越多也越好。其实道理自己都清楚，东西太多可能哪个都做不好，但有时候执念上来了，拦都拦不住。和当年的关不掉的浏览器标签页一样，不舍得放手。还是得多学会放手，一方面是给自己减负，另一方面也是给别人机会，这怎么说得我好像有多大权力似的😂。

时间管理

为真，是一个需要相对长远看待的问题，没有哪个真理是三两天就弄出来的。为需，才是第一重要的事情，光想着要做的多大多完美，不想想再不做点为所需的东西，团队都快没了，还谈什么理想。以一个明星项目养活俩仨探索项目，是我有时候会偷偷使用的小伎俩，先把本职的活儿干好，如果再时不时的整两个惊喜出来岂不美哉。就算没弄出来惊喜，只要没搞出来惊吓，至少我把分内的事儿做的没啥大毛病，老板也不会过来挑你啥。

但我坚信，创新才是第一动力，太本分不好。

努力不被「淘汰」？

有时候说被「淘汰」未免过分了些，组织淘汰人是「组织」认为「你」不再适合「组织」了，就像搞对象一样，「我」说「你」不是「我」喜欢的，还是有主观性的，没准儿人家到了别处还是顶梁柱嘞。怎么才能成为一代海王呢，个人观点，永无止境的学习是很重要的。

学啥？大点儿来说别学坏就好，当然好与坏，这又是个问题。我想表达的意思是，学些和工作有关的和学些和工作无关的都挺好的。两者之于工作都是有正向作用的，就比如这一年，我的这辆小摩托帮我结交了几个不错的朋友，帮我在不开心的时候变开心，开心的时候变得更开心，这还不够吗？学些和工作相关的技能那就更有益了，自己这点做的还是不太好，虽然能跟得上前沿的脚步，但也都是略知皮毛，开拓深耕些不熟悉的地方还是挺费力费时的。

怎么学？还记得之前大学时候管理学课上老师总说的一句话：读万卷书不如行万里路，行万里路不如交万名友。对于社牛症患者，Social 大可不必多说。对于有交通便利的朋友（比如有辆小摩托🏍的我😎），多和大自然接触接触还是舒服的，切记，安全第一。所有里面，效果相对不足的可能就是读书了，读书真的是成本很低的事情，时间可能是最需要消耗的东西，读书又确确实实是一件性价比很高的事情。这一年读的不多，暂且就拿客观因素当当借口吧。对于读书有一点我很受用，就是总结整理，吸进来些东西，消化消化，再创造些东西，不一定非要有多深的思考，哪怕是简单的归纳整理，写出来感觉一下子就不一样了。

活到老，学到老，这话在理。

万一万一，退路在哪里？

我是一个不太喜欢承受高风险的人，所以往往做事之前我都会尽可能想到最差的情况，多想想退路，好像也没什么毛病，是吧？万一万一，命运不济，有此一劫，我又该如何度过？一些具有高不可替代性的人不知道会不会思考这个问题，他们出现万一万一的概率太小了，我自认为还不是他们那种人，换句话，公司没了我照样转，往小了说，部门没了我照样转，最多卡个把月。

真正的退路也是需要很多客观条件支持的，比如雄厚的家庭资产，那我会选择回家继承我的百亩良田。再比如另一门硬手艺，大不了我换个行业，依旧可以做的风风火火。很不幸，这俩我都不符合，之前有时会也会问自己，如果有一天不能写代码了，我还能干点啥？我的菜属实做的还不错，开个饭馆没准儿能凑合，然而你抵挡不了天灾，疫情对餐饮、旅游、文娱的冲击真的不小。

那怎么办，没能力躺平，没实力单干，就只能坐等幸运女神眷顾了吗？作为一个「普通」人，我想也还是有些法子的，至少能让我们在遇见万一万一的时候可以更加从容的面对，快速顺利的找到下家，度过去，这不也是一条好路吗。时刻保持警惕感、夯实自己的核心能力、关注行业前沿动态、拓展个人认知范围，几点看似废话的东西我认为挺有用的，重点看你怎么去落实了。

光说不练假把式。

2022-01-27 08:00:00

本文主要参考自 SIFT meets CNN: A decade survey of instance retrieval ¹ 和 Deep Learning for Instance Retrieval: A Survey ²。

基于内容的图像检索（Content-based image retrieval，CBIR），属于图像分析的一个研究领域。基于内容的图像检索目的是在给定查询图像的前提下，依据内容信息或指定查询标准，在图像数据库中搜索并查找出符合查询条件的相应图片 ³。

根据不同的视觉表示方法，可以将基于内容的图像检索方法分为两类：基于 SIFT 特征的和基于深度学习的。基于 SIFT 特征的方法分为如下 3 类：

1. 使用小型编码本：视觉词汇少于几千个，紧凑向量在降维和编码之前生成。
2. 使用中型编码本：考虑到 BoW 的稀疏性和视觉词汇的低区分度，使用倒排索引和二进制签名方法。准确率和效率之间的权衡是该算法的主要影响因素。
3. 使用大型编码本：考虑到 BoW 直方图的稀疏性和视觉词汇的高区分度，在算法中使用了倒排索引和存储友好型的签名方式。在编码本生成和编码中使用了类似的方法。

基于深度学习的方法分为如下 3 类：

1. 混合型方法：图像块被多次输入到 CNN 中用于特征提取。编码与索引方法和基于 SIFT 的检索方法类似。
2. 使用预训练的模型：通过在类似 ImageNet 的大数据集预训练的 CNN 模型进行单通道特征提取，同时使用紧凑编码和池化技术。
3. 使用微调的模型：在图像与目标数据具有相似分布的训练集上对 CNN 模型进行微调。通过端到端的方法利用 CNN 模型进行单通道特征提取。这种视觉表示方法可以提升模型的区分能力。

各类模型的异同点如下表所示：

基于内容的图像检索里程碑节点如下图所示：

基于 SIFT 的图像检索

基于 SIFT 的图像检索流程如下图所示：

1. 局部特征提取：假设有一个包含 $N$ 张图片的集合 $\mathcal{G}$。指定一个特征检测器，从稀疏的兴趣点或密集的图像块中提取局部描述符。我们用 $D$ 表示局部描述符，$\left\{f_{i}\right\}_{i=i}^{D}, f_{i} \in \mathbb{R}^{p}$ 表示图像中被检测的区域。
2. 编码本训练：基于 SIFT 的方法需要离线训练一个编码本。编码本中的每个视觉词汇位于子空间的中心，称为 Voronoi Cell。一个更大的密码本对应一个更精细的划分，进而产生更有区分性的视觉词汇，反之亦然。假设存在一个用无标注数据集训练的局部描述符池 $\mathcal{F} \equiv\left\{f_{i}\right\}_{i=1}^{M}$，一个基准方法是利用 K-means 将 $M$ 个点聚类成 $K$ 个簇，这 $K$ 个视觉词汇则构成了大小为 $K$ 的编码本。
3. 特征编码：一个局部描述符 $f_{i} \in \mathbb{R}^{p}$ 通过特征编码过程 $f_{i} \rightarrow g_{i}$ 被映射到嵌入特征 $g_{i} \in \mathbb{R}^{l}$。当使用 K-means 聚类时，$f_i$ 可以根据其与视觉词汇的距离进行编码。

局部特征提取

Harris 角点检测

特征点在图像中一般有具体的坐标，并具有某些数学特征，如局部最大或最小灰度、以及某些梯度特征等。可以通过加权的差值平方和来形式化的比较一个图像的两个区块：

$$ \label{eq:e_u_v} E\left(u, v\right) = \sum_{x, y} w\left(x, y\right)\left[I\left(x + u, y + v\right)-I\left(x, y\right)\right]^{2} $$

其中，$I$ 为待比较的图像，$\left(u, v\right)$ 为平移向量，$w\left(x, y\right)$ 是在空间上变化的权重。

根据泰勒展开，窗口平移后图像的一阶近似为：

$$ \begin{aligned} I(x + u, y + v) &= I(x, y) + I_{x}(x, y) u + I_{y}(x, y) v + O\left(u^2, v^2\right) \\ & \approx I(x, y) + I_{x}(x, y) u + I_{y}(x, y) v \end{aligned} $$

其中，$I_{x}$ 和 $I_{y}$ 是图像 $I(x, y)$ 的偏导数，那么式 $\ref{eq:e_u_v}$ 可以简化为：

$$ \begin{aligned} E\left(u, v\right) & \approx \sum_{x, y} w(x, y)\left[I_{x}(x, y) u + I_{y}(x, y) v\right]^{2} \\ &=\left[\begin{array}{ll} u & v \end{array}\right] M(x, y)\left[\begin{array}{c} u \\ v \end{array}\right] \end{aligned} $$

其中，

$$ M=\sum w(x, y)\left[\begin{array}{cc} I_{x}^{2} & I_{x} I_{y} \\ I_{x} I_{y} & I_{y}^{2} \end{array}\right] $$

通过求解 $M$ 的特征向量，我们可以获得 $E(u, v)$ 最大和最小增量的方向，对应的特征值则为实际的增量值。Harris 角点检测方法对每一个窗口定义了一个 $R$ 值：

$$ R = \operatorname{det} M - k (\operatorname{trace} M)^{2} $$

其中，$\operatorname{det} M = \lambda_1 \lambda_2$ 是矩阵 $M$ 的行列式，$\operatorname{trace} M = \lambda_1 + \lambda_2$ 是矩阵 $M$ 的迹，$\lambda_1$ 和 $\lambda_2$ 为矩阵 $M$ 特征值，$k$ 为经验常数，通常取值为 $[0.04, 0.06]$。特征值决定了当前区域是一个角、边还是平坦区域。

1. 当 $\lvert R \rvert$ 比较小时，$\lambda_1$ 和 $\lambda_2$ 均比较小，则区域为平坦区域。
2. 当 $R < 0$ 时，$\lambda_1 \gg \lambda_2$ 或 $\lambda_1 \ll \lambda_2$，则区域为边。
3. 当 $R$ 较大时，$\lambda_1$ 和 $\lambda_2$ 都很大且 $\lambda_1 \sim \lambda_2$，则区域为角。

Harris 角点检测方法具备如下性质：

1. $k$ 影响被检测角点数量：增大 $k$ 将减小 $R$，从而减少被检测角点的数量，反之亦然。
2. 对亮度和对比度的变化不敏感：Harris 角点检测对图像进行微分运算，微分运算对图像密度的拉升或收缩和对亮度的抬高或下降不敏感。
3. 具有旋转不变性：Harris 角点检测算子使用的是角点附近区域的灰度二阶矩矩阵。而二阶矩矩阵可以表示成一个椭圆，椭圆的长短轴正是二阶矩矩阵特征值平方根的倒数。当特征椭圆转动时，特征值并不发生变化，所以判断角点的 $R$ 值也不发生变化。
4. 不具有尺度不变性：如下图所示，当左图被缩小时，在检测窗口尺寸不变的前提下，在窗口内所包含图像的内容是完全不同的。左侧的图像可能被检测为边缘或曲线，而右侧的图像则可能被检测为一个角点。

利用 Harris 方法检测角点的效果如下图所示（代码详见这里）：

尺度空间极值检测

为了使检测到的特征点具备尺度不变性，使能够在不同尺度检测到尽可能完整的特征点或关键点，则需要借助尺度空间理论来描述图像的多尺度特征。相关研究证明高斯卷积核是实现尺度变换的唯一线性核。因此可用图像的高斯金字塔表示尺度空间，而且尺度规范化的 LoG 算子具有尺度不变性，在具体实现中，可用高斯差分（ DoG）算子近似 LoG 算子，在构建的尺度空间中检测稳定的特征点。

在图像处理模型中引入一个被视为尺度的参数，通过连续变化尺度参数获取多尺度下的空间表示序列，对这些空间序列提取某些特征描述子，抽象成特征向量，实现图像在不同尺度或不同分辨率的特征提取。尺度空间中各尺度图像的模糊程度逐渐变大，模拟人在由近到远时目标在人眼视网膜上的成像过程。而且尺度空间需满足一定的不变性，包括图像灰度不变性、对比度不变性、平移不变性、尺度不变性以及旋转不变性等。在某些情况下甚至要求尺度空间算子具备仿射不变性。

图像的尺度空间 $L(x, y, \sigma)$ 可以定义为图像 $I(x, y)$ 与可变尺度的高斯函数 $G(x, y, \sigma)$ 的卷积：

$$ \begin{aligned} L(x, y, \sigma) &= G(x, y, \sigma) * I(x, y) \\ G(x, y, \sigma) &= \frac{1}{2 \pi \sigma^{2}} e^{-\frac{x^{2}+y^{2}}{2 \sigma^{2}}} \end{aligned} $$

其中，$\sigma$ 是尺度变化因子，大小决定图像的平滑程度，值越大图像越模糊。大尺度对应图像的概貌特征，小尺度对应图像的细节特征。一般根据 $3 \sigma$ 原则，高斯核矩阵的大小设为 $(6 \sigma+1) \times(6 \sigma+1)$。

尺度归一化的高斯拉普拉斯函数 $\sigma^{2} \nabla^{2} G$ 可以提取稳定的特征，高斯差分函数（Difference-of-Gaussian，DoG） ⁴ 与尺度归一化的高斯拉普拉斯函数近似：

$$ \begin{aligned} LoG &= \sigma^{2} \nabla^{2} G \\ DoG &= G(x, y, \sigma_2) - G(x, y, \sigma_1) \end{aligned} $$

利用差分近似替代微分，有：

$$ \sigma \nabla^{2} G=\frac{\partial G}{\partial \sigma} \approx \frac{G(x, y, k \sigma)-G(x, y, \sigma)}{k \sigma-\sigma} $$

因此有：

$$ G(x, y, k \sigma)-G(x, y, \sigma) \approx(k-1) \sigma^{2} \nabla^{2} G $$

其中，$k - 1$ 是个常数，不影响极值点的检测，DoG 和 LoG 的对比图如下：

在使用高斯金字塔构建尺度空间时，主要包括两部分：对图像做下采样，以及对图像做不同尺度的高斯模糊。对图像做降采样得到不同尺度的图像，也就是不同的组（Octave），后面的 Octave（高一层的金字塔）为上一个 Octave（低一层的金字塔）下采样得到，图像宽高分别为上一个 Octave 的 1/2 。每组（Octave）又分为若干层（Interval），通过对图像做不同尺度的高斯模糊得到，如下图所示：

在由图像金字塔表示的尺度空间中，Octave 由原始图像的大小和塔顶图像的大小决定：

$$ Octave = \log_2 \left(\min\left(w_b, h_b\right)\right) - \log_2 \left(\min\left(w_t, h_t\right)\right) $$

其中，$w_b$ 和 $h_b$ 分别为原始图像的宽和高，$w_t$ 和 $h_t$ 分别为金字塔顶部图像的宽和高。

尺度参数 $\sigma$ 的取值与金字塔的组数和层数相关，设第一组第一层的尺度参数取值为 $\sigma \left(1, 1\right)$，一般取值为 $1.6$，则第 $m$ 组第 $n$ 层的取值为：

$$ \sigma(m, n)=\sigma\left(1, 1\right) \cdot 2^{m-1} \cdot k^{n-1}, \quad k=2^{1/S} $$

其中，$S$ 为金字塔中每组的有效层数，$k=2^{1/S}$ 是变化尺度因子。在检测极值点前对原始图像的高斯平滑会导致图像高频信息的丢失，所以在建立尺度空间之前，先利用双线性插值将图像扩大为原来的两倍，以保留原始图像信息，增加特征点数量。

为了寻找 DoG 尺度空间的极值点，每一个采样点要和其所有邻域像素相比较，如下图所示，中间检测点与其同尺度的 8 个邻域像素点以及上下相邻两层对应的 9×2 个像素点一共 26 个点作比较，以确保在图像空间和尺度空间都能检测到极值点。一个像素点如果在 DoG 尺度空间本层及上下两层的 26 邻域中取得最大或最小值时，就可以认为该点是图像在该尺度下的一个特征点。

在极值比较的过程中，每一组差分图像的首末两层是无法比较的，为了在每组中检测 $S$ 个尺度的极值点，则 DoG 金字塔每组须有 $S+2$ 层图像，高斯金字塔每组须有 $S+3$ 层图像。另外，在下采样时，高斯金字塔中后一组（Octive）的底层图像是由前一组图像的倒数第 3 张图像（$S+1$ 层）隔点采样得到。这样也保证了尺度变化的连续性，如下图所示：

关键点定位

在 DoG 尺度空间检测到的极值点是离散的，通过拟合三元二次函数可以精确定位关键点的位置和尺度，达到亚像素精度。同时去除低对比度的检测点和不稳定的边缘点（因为 DoG 算子会产生较强的边缘响应），以增强匹配稳定性，提高抗噪声能力。

离散空间的极值点并不是真正的极值点，如下图所示一维函数离散空间得到的极值点与连续空间极值点的差别。利用已知的离散空间点插值得到的连续空间极值点的方法叫做子像素插值（Sub-pixel Interpolation）。

假设在尺度为 $\sigma$ 的尺度图像 $D(x, y, \sigma)$ 检测到一个局部极值点，空间位置为 $(x, y, \sigma)$。根据上图直观可知，它只是离散情况下的极值点，而连续情况下，极值点可能坐落在 $(x, y, \sigma)$ 附近，设连续情况的正真极值点偏离 $(x, y, \sigma)$ 的坐标为 $(\Delta x, \Delta y, \Delta \sigma)$。则对 $D(x + \Delta x, y + \Delta y, \sigma + \Delta \sigma)$ 在 $D(x, y, \sigma)$ 处进行泰勒展开（保留二阶），有：

$$ \begin{split} & \ D(x+\Delta x, y+\Delta y, \sigma+\Delta \sigma) \\ \approx & \ D(x, y, \sigma)+\left[\begin{array}{lll} \frac{\partial D}{\partial x} & \frac{\partial D}{\partial y} & \frac{\partial D}{\partial \sigma} \end{array}\right]\left[\begin{array}{c} \Delta x \\ \Delta y \\ \Delta \sigma \end{array}\right] \\ & +\frac{1}{2}\left[\begin{array}{lll} \Delta x & \Delta y & \Delta \sigma \end{array}\right]\left[\begin{array}{lll} \frac{\partial D^{2}}{\partial x^{2}} & \frac{\partial D^{2}}{\partial x \partial y} & \frac{\partial^{2} D}{\partial x \partial \sigma} \\ \frac{\partial D^{2}}{\partial y \partial x} & \frac{\partial D^{2}}{\partial y^{2}} & \frac{\partial D^{2}}{\partial y \partial \sigma} \\ \frac{\partial D^{2}}{\partial \sigma \partial x} & \frac{\partial D^{2}}{\partial \sigma \partial y} & \frac{\partial D^{2}}{\partial \sigma^{2}} \end{array}\right]\left[\begin{array}{c} \Delta x \\ \Delta y \\ \Delta \sigma \end{array}\right] \end{split} $$

将上式写成矢量形式如下：

$$ D(X+\Delta X)=D(X)+\frac{\partial D^{\top}(X)}{\partial X} \Delta X+\frac{1}{2} \Delta X^{\top} \frac{\partial^{2} D(X)}{\partial X^{2}} \Delta X $$

上式对 $\Delta X$ 求导，并令其等于零，可以得到极值点的偏移量：

$$ \Delta X=-\frac{\partial^{2} D(X)}{\partial X^{2}}^{-1} \frac{\partial D^{\top}(X)}{\partial X} $$

通过多次迭代（Lowe SIFT 算法里最多迭代 5 次），得到最终候选点的精确位置与尺度 $\hat{X}$。当超出所设定的迭代次数或者超出图像边界的范围时应删除该点，如果 $\lvert D(\hat{X}) \rvert$ 小于某个阈值则将该极值点也应该删除。

高斯差分函数有较强的边缘响应，对于比较像边缘的点应该去除掉。这样的点的特征为在某个方向有较大主曲率，而在垂直的方向主曲率很小。主曲率可通过一个 $2 \times 2$ 的 Hessian 矩阵求出：

$$ H=\left[\begin{array}{ll} D_{x x} & D_{x y} \\ D_{x y} & D_{y y} \end{array}\right] $$

$D$ 的主曲率和 $H$ 的特征值成正比，令 $\alpha$ 为较大的特征值，$\beta$ 为较小的特征值，$\alpha = \gamma\beta$，则有：

$$ \begin{aligned} \operatorname{trace}(H) &= D_{x x}+D_{y y}=\alpha+\beta \\ \operatorname{det}(H) &= D_{x x} D_{y y}-\left(D_{x y}\right)^{2}=\alpha \beta \\ \frac{\operatorname{trace}(H)^{2}}{\operatorname{det}(H)} &= \frac{(\alpha+\beta)^{2}}{\alpha \beta}=\frac{(\gamma+1)^{2}}{\gamma} \end{aligned} $$

上式的结果只与两个特征值的比例有关，而与具体特征值无关。当两个特征值相等时，$\dfrac{(\gamma+1)^{2}}{\gamma}$ 的值最小，随着 $\gamma$ 的增加，$\dfrac{(\gamma+1)^{2}}{\gamma}$ 的值也增加。设定一个阈值 $\gamma_t$（Lowe SIFT 算法里最 $\gamma_t = 10$），若：

$$ \frac{\operatorname{trace}(H)^{2}}{\operatorname{det}(H)}<\frac{\left(\gamma_{t}+1\right)^{2}}{\gamma_{t}} $$

则认为该关键点不是边缘，否则予以剔除。

关键点方向指定

为了使特征描述符具有旋转不变性，需要利用关键点邻域像素的梯度方向分布特性为每个关键点指定方向参数。对于在 DoG 金字塔中检测出的关键点，在其邻近高斯金字塔图像的 3𝜎 邻域窗口内计算其梯度幅值和方向，公式如下：

$$ \begin{aligned} &m(x, y)=\sqrt{(L(x+1, y)-L(x-1, y))^{2}+(L(x, y+1)-L(x, y-1))^{2}} \\ &\theta(x, y)=\arctan ((L(x, y+1)-L(x, y-1)) /(L(x+1, y)-L(x-1, y))) \end{aligned} $$

其中，$L$ 为关键点所在尺度空间的灰度值，$m(x, y)$ 为梯度幅值，$\theta(x, y)$ 为梯度方向。对于模值 $m(x, y)$ 按照 $\theta = 1.5 \theta_{oct}$ 邻域窗口为 $3 \theta$ 的高斯分布加权。在完成关键点的梯度计算后，使用直方图统计邻域内像素的梯度和方向，梯度直方图将梯度方向 $\left(0,360^{\circ}\right)$ 分为 36 个柱（bins），如下图所示（为简化，图中只画了八个方向的直方图），直方图的峰值所在的方向代表了该关键点的主方向。

梯度方向直方图的峰值代表了该特征点处邻域梯度的主方向，为了增强鲁棒性，保留峰值大于主方向峰值 80% 的方向作为该关键点的辅方向。因此，在相同位置和尺度，将会有多个关键点被创建但方向不同，这可以提高特征点匹配的稳定性。

关键点特征描述符

在经过上述流程后，检测到的每个关键点有三个信息：位置、尺度以及方向，接下来就是为每个关键点建立一个描述符，用一组向量将这个关键点描述出来。这个特征描述符不但包括关键点，还包括其邻域像素的贡献，而且需具备较高的独特性和稳定性，以提高特征点匹配的准确率。SIFT 特征描述符是关键点邻域梯度经过高斯加权后统计结果的一种表示。通过对关键点周围图像区域分块，计算块内的梯度直方图，得到表示局部特征点信息的特征向量。例如在尺度空间 $4 \times 4$ 的窗口内统计 8 个方向的梯度直方图，生成一个 $4 \times 4 \times 8 = 128$ 维的表示向量。

特征描述符与特征点所在的尺度有关，因此，对梯度的求取应在特征点对应的高斯图像上进行。将关键点附近的邻域划分为 $d \times d$ 个子区域 $(d = 4)$，每个子区域做为一个种子点，每个种子点有 8 个方向。每个子区域的大小与关键点方向分配时相同，即每个区域边长为 $3 \theta_{oct}$。考虑到实际计算时需要进行三线性插值，采样窗口区域半边长设为 $\dfrac{3 \theta_{oct} (d + 1)}{2}$，又考虑到旋转因素（坐标轴旋转至关键点主方向），这个值需要乘以 $\sqrt{2}$，最后所需的图像区域半径为：

$$ \text{radius} = \dfrac{3 \sigma_{oct} \times \sqrt{2} \times(d+1)}{2} $$

将坐标轴旋转至关键点主方向，以确保旋转不变性。如下图所示：

旋转后采样点的新坐标为：

$$ \left[\begin{array}{l} x^{\prime} \\ y^{\prime} \end{array}\right]=\left[\begin{array}{cc} \cos \theta & -\sin \theta \\ \sin \theta & \cos \theta \end{array}\right]\left[\begin{array}{l} x \\ y \end{array}\right] \quad(x, y \in[\text {-radius, radius }]) $$

在图像半径区域内对每个像素点求其梯度幅值和方向，并对每个梯度幅值乘以高斯权重：

$$ w=m(u+x, b+v) \times e^{-\frac{x^{\prime 2}+y^{\prime 2}}{2 \sigma_{w}^{2}}} $$

其中，$u$ 和 $v$ 表示关键点在高斯金字塔图中的位置坐标，$x$ 和 $y$ 为旋转坐标轴至关键点主方向之前相对关键点的偏移量，$x^{\prime}$ 和 $y^{\prime}$ 为旋转坐标轴至关键点主方向之后相对关键点的偏移量。

将旋转后的采样点坐标分配到对应的子区域，计算影响子区域的采样点的梯度和方向，分配到 8 个方向上。旋转后的采样点 $(x^{\prime}, y^{\prime})$ 落在子区域的下标为：

$$ \left[\begin{array}{l} x_{d} \\ y_{d} \end{array}\right]=\frac{1}{3 \sigma_{o c t}}\left[\begin{array}{c} x^{\prime} \\ y^{\prime} \end{array}\right]+\frac{d}{2}, \quad x_{d}, y_{d} \in[0, d] $$

将采样点在子区域的下标进行三线性插值，根据三维坐标计算与周围子区域的距离，按距离远近计算权重，最终累加在相应子区域的相关方向上的权值为：

$$ w^{\prime} = w \cdot\left[d_{r}^{i} \cdot\left(1-d_{r}\right)^{1-i}\right] \cdot\left[d_{c}^{j} \cdot\left(1-d_{c}^{1-j}\right)\right] \cdot\left[d_{o}^{k} \cdot\left(1-d_{o}\right)^{1-k}\right] $$

其中，$i, j, k$ 取值为 0 或 1，$d_r, 1- d_r$ 是对相邻两行的贡献因子，$d_c, 1- d_c$ 是对相邻两列的贡献因子，$d_o, 1- d_o$ 是对相邻两个方向的贡献因子。插值计算每个种子点八个方向的梯度，最终结果如下图所示：

得到 128 维特征向量后，为了去除光照变化的影响，需要对向量进行归一化处理。非线性光照变化仍可能导致梯度幅值的较大变化，但对梯度方向影响较小。因此对于超过阈值 0.2 的梯度幅值设为 0.2 ，然后再进行一次归一化。最后将特征向量按照对应高斯金字塔的尺度大小排序。至此，SIFT 特征描述符形成。

利用 SIFT 方法检测关键点的效果如下图所示（代码详见这里）：

SIFT 方法的优点如下：

1. 局部：SIFT 特征是图像的局部特征，其对旋转、尺度缩放、亮度变化保持不变性，对视角变化、仿射变换、噪声也保持一定程度的稳定性。
2. 独特：信息量丰富，适用于在海量特征数据库中进行快速、准确的匹配。
3. 大量：即使少数的几个物体也可以产生大量的 SIFT 特征向量。
4. 高效：经优化的 SIFT 匹配算法甚至可以达到实时的要求。
5. 可扩展：可以很方便的与其他形式的特征向量进行联合。

SIFT 方法的缺点如下：

1. 默认算法的实时性不高。
2. 部分情况下特征点较少。
3. 对边缘光滑的目标无法准确提取特征点。

对于 SIFT 的改进可以参考 SURF ⁵ 和 CSIFT ⁶。

本小节参考：

1. https://docs.opencv.org/5.x/dc/d0d/tutorial_py_features_harris.html
2. https://docs.opencv.org/5.x/da/df5/tutorial_py_sift_intro.html
3. https://lsxiang.github.io/Journey2SLAM/computer_vision/Harris/
4. https://lsxiang.github.io/Journey2SLAM/computer_vision/SIFT/

特征编码

BoF

BoF（Bag of Features, Bag of Visual Words）^{7 8} 借鉴了文本中的 BoW（Bag of Words）模型的思路。从图像抽象出很多具有代表性的「关键词」，形成一个字典，再统计每张图片中出现的「关键词」频率，得到图片的特征向量。BoF 算法的流程如下：

1. 局部特征提取：利用上文中的 SIFT 等类似方法提取图片的局部特征，每个图片提取的特征数量不同，但每个特征的维度是相同的（例如：128 维）。
2. 构建视觉词典：利用 K-means 等算法将所有图片的所有特征向量进行聚类，得到 $K$ 个聚类中心，即 $K$ 个视觉词汇（Visual Word）。由于特征数量可能非常大，使用 K-means 算法聚类会相当耗时。
3. 生成 BoF 特征：对于一个图像中的每一个特征，都可以在视觉词典中找到一个最相似的视觉词汇，因此可以对该图像统计得到一个 $K$ 维的直方图，每个值表示图像中局部特征在视觉词典中相似视觉词汇的频率。针对该步骤可以利用 TF-IDF 的思想获取加权的 BoF 特征结果。

BoF 算法的一些缺点也比较明显：

1. 在使用 K-means 进行聚类时，$K$ 和初始聚类中心的选取对结果敏感。字典过大，词汇缺乏一般性，对噪声敏感；字典过小，词汇区分性较差，无法充分表示图片。对于海量数据计算所需的时间和空间复杂度都比较高。
2. 将图像表示成一个无序的特征，丢失了图片中的空间信息，表示上存在一定局限。

VLAD

VLAD（Vector of Local Aggregated Descriptors）⁹ 方法同 BoF 类似，但在生成特征时采用如下公式：

$$ V(j, k)=\sum_{i=1}^{N} \operatorname{sign}_{k}\left(x_{i}\right)\left(x_{i}(j)-c_{k}(j)\right), \quad k \in K, j \in D $$

其中，$K$ 为词典大小，$N$ 为图片的局部特征数量，$D$ 为每个局部特征的维度，$x_i$ 表示第 $i$ 个局部特征，$c_k$ 表示第 $k$ 个聚类中心，$\operatorname{sign}_k$ 是一个符号函数，如果 $x_i$ 不属于聚类中心 $c_k$ 则为 $0$，反之则为 $1$。

从上式中可以看出 VLAD 累加了每个聚类的所有特征残差，通过 $x_i - c_k$ 将图像本身的局部特征分布差异转换为聚类中心的分布差异，通过归一化和降维等手段得到最终的全局特征。

FV

FV（Fisher Vector）¹⁰ 本质上是用似然函数的梯度向量表示一幅图像。梯度向量的物理意义就是描述能够使模型更好地适应数据的参数变化方向，也就是数据拟合中参数调优的过程。在 FV 中我们采用高斯混合模型（Gaussian Mixture Model，GMM）。

高斯混合模型是由多个高斯模型线性叠加而成，公式如下：

$$ p(x)=\sum_{k=1}^{K} \pi_{k} N\left(x \mid \mu_{k}, \Sigma_{k}\right) $$

其中，$p(x)$ 表示数据 $x$ 出现的概率，$K$ 表示高斯模型个数，$\pi_k$ 表示第 $k$ 个高斯模型的权重，$\mu_k$ 表示第 $k$ 个高斯分布的均值，$\Sigma_k$ 表示第 $k$ 个高斯分布的方差。理论上，只要 $K$ 足够大，GMM 可以逼近任意一种概率分布。

GMM 的目标是求解参数 $\pi_k, \mu_k, \Sigma_k$ 使得它确定的概率分布生成这些给定数据的概率最大，即 $\Pi_{i=1}^{N} p\left(x_{i}\right)$ 最大。假设各个数据点之间满足独立同分布，可以将其转换成对数似然函数：

$$ \sum_{i=1}^{N} \log \left(p \left(x_i\right)\right) $$

假设 GMM 模型包含 $K$ 个高斯模型，则模型的参数集合为 $\lambda = \left\{w_i, \mu_k, \Sigma_k, k = 1, \cdots, K\right\}$，假设共有 $T$ 个特征向量，则似然函数可以表示为：

$$ \mathcal{L} (x \mid \lambda)=\sum_{t=1}^{T} \log \left(p\left(x_{t} \mid \lambda\right)\right) $$

其中的高斯分布是多个基高斯分布的混合：

$$ \label{eq:fv_gmm} p\left(x_{t} \mid \lambda\right)=\sum_{k=1}^{K} w_{k} * p_{k}\left(x_{t} \mid \lambda\right) $$

每个基高斯分布又可以表示为：

$$ p_{k}\left(x_{t} \mid \lambda\right) = \dfrac{1}{\left(2 \pi\right)^{\frac{D}{2}} \lvert\Sigma_k\rvert^{\frac{1}{2}}} e^{-\frac{1}{2} \left(x - \mu_k\right)^{\prime} \Sigma_k^{-1} \left(x - \mu_k\right)} $$

由贝叶斯公式可知，描述符 $x_t$ 数据第 $i$ 个高斯模型的概率为：

$$ \gamma_{t}(i)=\frac{w_{i} u_{i}\left(x_{t}\right)}{\sum_{k=1}^{K} w_{k} u_{k}\left(x_{t}\right)} $$

则公式 $\ref{eq:fv_gmm}$ 的梯度分量为：

$$ \begin{aligned} \frac{\partial \mathcal{L}(X \mid \lambda)}{\partial w_{i}} &=\sum_{t=1}^{T}\left[\frac{\gamma_{t}(i)}{w_{i}}-\frac{\gamma_{t}(1)}{w_{1}}\right] \text { for } i \geq 2, \\ \frac{\partial \mathcal{L}(X \mid \lambda)}{\partial \mu_{i}^{d}} &=\sum_{t=1}^{T} \gamma_{t}(i)\left[\frac{x_{t}^{d}-\mu_{i}^{d}}{\left(\sigma_{i}^{d}\right)^{2}}\right], \\ \frac{\partial \mathcal{L}(X \mid \lambda)}{\partial \sigma_{i}^{d}} &=\sum_{t=1}^{T} \gamma_{t}(i)\left[\frac{\left(x_{t}^{d}-\mu_{i}^{d}\right)^{2}}{\left(\sigma_{i}^{d}\right)^{3}}-\frac{1}{\sigma_{i}^{d}}\right] . \end{aligned} $$

由于概率空间和欧氏空间的归一化方式不同，在此引入 Fisher Matrix 进行归一化：

$$ \begin{aligned} f_{w_{i}} &=T\left(\frac{1}{w_{i}}+\frac{1}{w_{1}}\right) \\ f_{\mu_{i}^{d}} &=\frac{T w_{i}}{\left(\sigma_{i}^{d}\right)^{2}}, \\ f_{\sigma_{i}^{d}} &=\frac{2 T w_{i}}{\left(\sigma_{i}^{d}\right)^{2}} . \end{aligned} $$

归一化后即为 Fisher 向量：

$$ \begin{aligned} \mathscr{G}_{\alpha_{k}}^{X} &= f_{w_i}^{1/2} \frac{\partial \mathcal{L}(X \mid \lambda)}{\partial w_{i}} =\frac{1}{\sqrt{w_{k}}} \sum_{t=1}^{T}\left(\gamma_{t}(k)-w_{k}\right), \\ \mathscr{G}_{\mu_{k}}^{X} &= f_{\mu_i^d}^{1/2} \frac{\partial \mathcal{L}(X \mid \lambda)}{\partial \mu_{i}^{d}} =\frac{1}{\sqrt{w_{k}}} \sum_{t=1}^{T} \gamma_{t}(k)\left(\frac{x_{t}-\mu_{k}}{\sigma_{k}}\right), \\ \mathscr{G}_{\sigma_{k}}^{X} &= f_{\sigma_i^d}^{1/2} \frac{\partial \mathcal{L}(X \mid \lambda)}{\partial \sigma_{i}^{d}} =\frac{1}{\sqrt{w_{k}}} \sum_{t=1}^{T} \gamma_{t}(k) \frac{1}{\sqrt{2}}\left[\frac{\left(x_{t}-\mu_{k}\right)^{2}}{\sigma_{k}^{2}}-1\right] \end{aligned} $$

其中 $\mathscr{G}_{\alpha_{k}}^{X}$ 同 BoF 有类似效果，$\mathscr{G}_{\mu_{k}}^{X}$ 同 VLAD 有类似效果。

图像检索

倒排索引

倒排索引是一种提高存储和检索效率的算法，它常被用于大/中等规模的编码本中，结构如下图所示：

倒排索引是一个一维结构，其中每一个条目对应编码本中的一个视觉词汇。每一个视觉词汇都包含一个倒排表，每个倒排表中的索引被称为索引特征或者记录。倒排索引很好地发挥了大规模编码本词汇直方图稀疏性的特点。

ANN

基于近似最近邻搜索（Approximate Nearest Neighbor Search，ANN）的方法，请参考之前的博客。

基于深度学习的图像检索

基于深度学的图像检索流程如下图所示：

1. 网络前馈方式：将图片输入 DCNN 的方式有两种：单路和多路。单路将整个图片作为输入，多路依赖区域提取，例如空间金字塔模型（Spatial Pyramid Models）和区域候选网络（Region Proposal Networks，RPN）。
2. 深度特征提取：基于整个图像或部分区块的输入，网络的激活值可以用作原始的特征。全连接层提供了一个全局的视野，将一整个图片表示为单个向量。
3. 特征嵌入和集成：基于图片级别或区块级别的描述符，构造全局或局部特征时包含两个重要步骤，通常为 PCA 和白化。特征嵌入将独立的局部特征映射到一个高维向量，特征集成则将多个映射的向量合并成一个单一向量。
4. 特征匹配：特征匹配用来衡量图片之间特征的相似度。全局匹配可以通过欧式、汉明或其他距离度量进行高效计算。对于局部特征，可以通过 RANSAC ¹¹ 和近期的一些改进方法对局部特征进行相似度汇总来评估相似性。

关于卷积神经网络的细节介绍，请参考之前的博客。

网络前馈方式

单路前馈方法

单路前馈方法是将整个图片直接输入模型来提取特征。由于仅将图片输入模型一次，该方法效率较高。对于这类方法，全连接层和最后一个卷积层可以作为特征提取器。

多路前馈方法

相比于单路前馈方法，多路前馈方法由于需要将生成的多个图像块输入到模型中，因此相对耗时。这类方法通常包含两个步骤：图像块识别和图像块描述。使用不同方法可以获得不同尺度的图像块，如下图所示：

其中，(a) 为固定窗口大小划分的区块，(b) 为空间金字塔模型（Spatial Pyramid Model，SPM）划分的区块，(c) 为稠密采样的区块，(d) 为通过区域候选网络（Region Proposal Network，RPN）获得的候选区块。

深度特征选择

特征选择决定了提取特征的表达范围，例如：从全连接层可以获得全局级别特征，从卷积层可以获得区块级别特征。

从全连接层提取

将全连接层作为全局特征提取器，通过 PCA 降维和标准化后可以用于度量图像的相似性。但由于这一层是全连接的，每个神经元都会产生图像级别的描述符，这会导致两个明显的缺陷：包括无关信息和缺少局部几何不变性。

针对第一个缺陷，可以通过多路前馈方法来提取区块级别特征。针对第二个缺陷，缺乏几何不变性会影响图像变换（如：裁剪、遮挡）时的鲁棒性，通过使用中间卷积层可以来解决。

从卷积层提取

从卷积层（通常是最后一层）提取的特征保留了更多的结构细节，这对实例检索尤为有利。卷积层的神经元仅同局部区域相连接，这样较小的视野确保所生成的特征包含更多局部结构信息，同时对于图像变换更为鲁棒。

加和/平均和最大池化是用于生成全局特征的两个简单的集成方法，一些其他的集成方法，例如：MAC ¹²，R-MAC ¹³，GeM polling ¹⁴，SPoC ¹⁵，CroW ¹⁶ 和 CAM+CroW ¹⁷ 如下图所示：

特征融合策略

层级别融合

通过层级别融合，可以在深度网络中融合多个全连接层。全连接层的特征保留了全局高层级语义信息，卷积层的特征保留了局部中低层级的信息。因此，全局特征和局部特征在测量语义相似度时相辅相成，可以在一定程度上保证检索的效果。

模型级别融合

融合不同模型的特征也是可行的，这种融合方式关注于模型之间的互补性质，其可以分为：intra-model 和 inter-model 两类。intra-model 融合方式建议使用多个具有相似性或者结构上高度兼容的模型，而 inter-model 融合方式则使用结构上具有很大不同的模型。

inter-model 和 intra-model 融合同模型选择有关。融合候选模型的所有特征，然后根据拼接的特征学习得到一个度量，这种方式称为 early fusion 策略。或者对每个模型的特征学习各自的最优度量，然后组合这些度量用于最终的检索排名，这种方式称为 late fusion 策略。

特征嵌入和集成

特征嵌入和集成的主要目的是进一步提高从 DCNN 中提取的特征的区分能力，来生成用于检索特定实例的最终全局或局部特征。

匹配全局特征

全局特征可以从全连接层中提取，然后进行降维和标准化，通常情况下没有进一步的聚合过程。卷积特征也可以被集成到全局特征中，简单的方式是通过加和/平均或最大池化。卷积特征可以作为局部区域的描述符，因此可以利用基于 SIFT 的图像检索中提到的 BoF，VLAD，FV 等模型对其进行编码，然后再将他们聚合为一个全局描述符。

匹配局部特征

尽管全局特征匹配对于特征提取和相似度计算都具有很高的效率，但全局特征与空间验证和对应估计不兼容，这些是实例级别检索任务的重要过程。在匹配过程中，全局特征只匹配一次，而局部特征匹配通过汇总所有单个局部特征的相似性来评估（即多对多匹配）。

注意力机制

注意力机制可以看作是一种特征聚合，其核心思想是突出最相关的特征部分，通过计算注意力映射来实现。获取注意力映射的方法可以分为两类：非参数和参数，如下图所示，主要区别在于注意力映射中的重要性权重是否可学习。

非参数加权是一种突出特征重要性的直接方法，相应的注意力映射可以通过通道或空间池化获得，如 (a) 和 (b) 所示。参数注意力映射可以通过深度网络学习，其输入可以是图像块或特征映射，这些方法通常用于有监督的度量学习，如 (c) 和 (d) 所示。

哈希嵌入

深度网络提取的实值特征通常是高维的，不太适合检索。因此，将深层特征转换为更紧凑的编码具有重要意义。由于其计算和存储效率，哈希算法已被广泛用于全局和局部描述符。

哈希函数可以作为一个层插入到深度网络中，以便可以通过有监督或无监督的方式同时训练和优化哈希码和深度网络。哈希函数训练时，相似图像的哈希码嵌入会尽可能的接近，不相似图像的哈希码嵌入会尽可能的分离。

模型微调

微调方法已被广泛研究以学习更好的检索特征。在基于图像分类的数据集上预训练的 DCNN 对类间可变性非常稳健，随后将成对的监督信息引入排名损失中，通过对检索表示进行正则化来微调网络。具有清晰且定义良好的真实标签的标准数据集对于微调深度模型以执行准确的实例级检索是必不可少的，否则就需要开发无监督的微调方法。在网络微调之后，可以将特征作为全局或局部来进行检索。

有监督微调

下图展示了不同类型的有监督微调方法：

下图展示了不同类型的有监督微调损失函数：

无监督微调

由于成本等问题可能导致监督信息不足，从而监督网络微调变得不可行。因此，用于图像检索的无监督微调方法是非常必要的。对于无监督微调，两个方向是通过流形学习和聚类技术挖掘特征之间的相关性。具体细节不再展开讨论，详细内容请参见原文。

开放资源

• Stanford Online Products Retrieval Leaderboard
• CARS196 Retrieval Leaderboard
• CUB-200-2011 Retrieval Leaderboard
• In-shop Clothes Retrieval Leaderboard
• Image Retrieval - Paper with code

2021-10-17 08:00:00

什么是 A/B 测试

A/B 测试是一种随机测试，将两个不同的东西（即 A 和 B）进行假设比较。A/B 测试可以用来测试某一个变量两个不同版本的差异，一般是让 A 和 B 只有该变量不同，再测试目标对于 A 和 B 的反应差异，再判断 A 和 B 的方式何者较佳 ¹。A/B 测试的前身为双盲测试 ²，在双盲测试中人员会被随机分为两组，受试验的对象及研究人员并不知道哪些对象属于对照组，哪些属于实验组，通过一段时间的实验后对比两组人员的结果是否有明显差异。在各种科学研究领域中，从医学、食品、心理到社会科学及法证都有使用双盲方法进行实验。

一个简单的 A/B 测试流程如下：

1. 对目标人群进行随机划分，以进行有效的独立随机实验。
2. 对不同分组应用不同的策略。
3. 在确保实验有效的前提下，对不同分组的结果进行分析，以确定不同策略的优劣。

A/B 测试的主要目的是帮助我们更加科学的判断不同策略的优劣性，避免拍脑门的决策，不给杠精们互相 BATTLE 的机会。同时我们也需要认识到 A/B 测试只是一个工具，它能够帮助我们对产品和策略进行不断优化，但对产品和策略的创新更多还是需要洞察力。它可以让我们在已达到的山上越来越高，却不能用它来发现一座新的山脉。一句话：A/B 测试不是万能的，但离开 A/B 测试是万万不能的。

A/B 测试的科学性

流量分配

进行 A/B 测试的第一个问题就是如何划分用户，如果采用上面简单五五开的方式我们一次只能做一个实验，当我们需要同时做多个实验时就无法满足了。如果对用户分成多个桶，当桶的数量过多时，每个桶中的用户数量就会过少，从而会导致实验的置信度下降。

为了保证可以使用相同的流量开展不同的实验，同时各个实验之间不能相关干扰，我们需要采用正交实验。正交实验的思想如下：

每个独立实验为一层，层与层之间的流量是正交的，流量经过一层实验后会再次被随机打散。

有些情况下实验并不是独立的，例如同时对按钮和背景的颜色进行实验，按钮和背景颜色之间并不是独立的（即有些按钮和背景颜色搭配从设计角度是不可行的，没有必要进行实验），这种情况下我们需要采用互斥实验。互斥实验的思想如下：

实验在同一层进行流量拆分，不同组之间的流量是没有重叠的。

在 A/B 测试中，当多个实验内容相互影响应选择互斥方法分配流量，当多个实验内容不会相互影响应选择正交方法分配流量。更加精细的流量分类和控制可以参考 Google 的论文 Overlapping Experiment Infrastructure: More, Better, Faster Experimentation ³。

评价指标选择

在设计实验之前我们需要明确实验的目标，根据目标才能确定合理的评价指标。更多情况下我们应该从业务的视角出发选择合适的评价指标，我们以风险策略模型实验为例，我们可以从技术和业务角度选择不同的评价指标：

1. 技术角度：准确率和召回率
2. 业务角度：客诉率和追损金额

单纯从技术角度出发我们会忽视很多现实问题，例如两个策略的准确率和召回率差不多，但识别的结果人群不一样，这些人造成的损失也可能不一样。因此能够帮助我们追回更多损失同时有更小的客诉率才是更优的策略。

在进行实验时结果指标至关重要，但有时我们也应该关注一些过程指标。以页面优化实验为例，可能的过程指标和结果指标有：

1. 过程指标：页面平均停留时间，页面跳出率等
2. 结果指标：商品加购率，商品转化率等

策略和模型最终都是要为业务服务的，因此我们应常关注业务指标，一些常用的业务指标有：点击率（CTR）、转化率（CVR）、千次展示收入（RPM）等。

有效性检验

当实验完成得到结果后，我们还需要判断实验结果是否有效，这部分主要依靠统计学中的假设检验进行分析。针对两个实验在确定合理的统计量后，需要构建如下两个假设：

• 原假设 $H_0$：两个实验的统计量无差异
• 备选假设 $H_1$：两个实验的统计量有差异

对于假设检验只可能有两种结果：一个是接受原假设，一个是拒绝原假设。在进行假设检验过程中，容易犯两类错误：

第一类错误（弃真）即原假设为真时拒绝原假设，犯第一类错误的概率为 $\alpha$，即显著水平。第二类错误（取伪）即原假设为假时未拒绝原假设，犯第二类错误的概率为 $\beta$。

在进行有效性检验时我们有多个指标可以参考：

1. P 值。P 值就是当原假设为真时，比所得到的样本观察结果更极端的结果出现的概率。如果 P 值很小，说明原假设情况的发生的概率很小，而如果出现了，根据小概率原理，我们就有理由拒绝原假设，P 值越小，我们拒绝原假设的理由越充分。
2. 置信区间。置信区间就是分别以统计量的置信上限和置信下限为上下界构成的区间。置信水平是指包含总体平均值的概率是多大，例如：95% 的置信水平表示，如果有 100 个样本，可以构造出 100 个这样的区间，有 95% 的可能性包含总体平均值。在 A/B 测试时，如果置信区间上下限的值同为正或负，则认为存在有显著差异的可能性；如果同时有正值和负值，则认为不存在有显著差异的可能性。
3. 统计功效。一般情况下我们希望拒绝原假设，得到新的结论，即在进行 A/B 测试时希望实验组的效果优于对照组。也就是我们希望不要出现在应该拒绝原假设时却没有拒绝的情况，即犯第二类错误。统计功效就是我们没有犯第二类错误的概率 $1 - \beta$，在进行 A/B 测试时表示当两个策略之间存在显著差异时，实验能正确做出存在差异判断的概率。

综上，我们可以认为当 A/B 测试实验数据在 95% 的置信水平区间内，P 值小于0.05，功效大于 80% 的情况下，实验结果是可信赖的。

A/A 测试

在做 A/B 测试的时候，有时尽管我们发现 A/B 两组有明显差异，但我们依旧无法确认这种差异是由于实验条件不同还是 A/B 两组用户本身的差异带来的。尽管 A/B 两组用户是随机抽样，但两组用户在空跑期（即实验条件一致）也会出现显著差异。因此为了避免这个问题，我们会选择进行 A/A 测试，即在正式开启实验之前，先进行一段时间的空跑，对 A/B 两组用户采用同样的实验条件，一段时间后，再看两组之间的差异。如果差异显著，数据弃之不用，重新选组。如果差异不显著，记录两组之间的均值差，然后在实验期结束时，用实验期的组间差异减去空跑期的组间差异得到最终实验结果。

A/A 测试也会存在一些局限，在实际情况中，组间差异是一定存在。因此在这个前提下，可以用统计方式来衡量差异大小，在计算实验效果的时候，把差异考虑在内即可。差异产生的主要原因就是“随机性”，我们同样可以利用置信度和置信区间来描述 A/A 实验的波动。在进行实验时直接进行 A/B 测试，不需要考虑 A/A 测试，在分析结果时，需要考虑 A/B 测试实验之间的差异要大于 A/A 测试实验之间的差异。

2021-10-06 08:00:00

之前

三十岁了，不小了，一些事情再不做就不知道会拖到什么时候了。自从之前看到朋友发的一段摩旅的视频，就一直念念不忘，有机会一定要来一次，虽然不一定如视频中那般潇洒。最后证明确实不一样，尽管谈不上是一场修行，但遇到的人事物都是独特且难以忘记的。

有了出发的勇气，但拖延症还是很严重，各种准备和规划直到出发前一晚才简单搞定，当然这也给后面的遇到的问题埋下了伏笔。本来规划了 5 天的行程，最后一天赶到大同见朋友一面再返回北京，但一场冷雨让我在第 4 天直接折返北京。

第一天

折腾了好久，费劲扒拉才把后座包绑好。出门还没上高速，碰见一个骑复古车的哥们，问了我去哪里，我说自己去内蒙古，一句注意安全，一句感谢。出发前才掉了一格油，就没有去加，距离丰宁还 20 多公里，油表灯就闪了，好在还是坚持到了丰宁，成功续满了油。路上断断续续发现成队的、独行的骑士，还有一个书包和后座包都贴了实习标志的哥们，应该都是追逐自由的人吧。

到丰宁前中途停下检查了后座包，发现有一侧绑的不合理，卡口会被后轮摩到，都快要磨断了，幸好检查了下，改造一番绑好继续上路。从丰宁出发没多久，隐约闻道一股烧焦的味道，没当回事儿，以为是路上其他汽车的尾气。中间休息的时候又检查了一下后座包，才发现从丰宁出发时有一侧绑的有点松，后座包倒向了排气那边。奈何我帅气的双排气在上面，就把包烫了一个大洞，一并倒霉的还有带了但一次还没来得及穿过的冬款骑行服和骑行裤。不过好在底下放的是衣服，如果我把相机、电脑、无人机、充电宝放在那边低下…..都不敢想会有什么事儿。这就是没有提前做好功课如何绑后座包的后果，当然闻道异味没有第一时间检查也很不好。

包和衣服被烫了之后，心情一下就不好了，虽然一再自我安慰，但还是缓了很久才勉强不伤心了。由于中途发生了不少事情，整体耽误了一个小时左右，赶到塞罕坝这边酒店的时候已经是六点半了，天已经完全黑下来了，后面一个多小时的路程真的是又累又冷。万幸的是我把我夏季骑行服里面的内胆加上了，不然估计到酒店就冻成狗了。

第二天

早起退房碰见一对儿摩旅的，男生骑了一辆 ADV，小姐姐骑了一辆 Ninja 400。一清早晴空万里，阳光明媚，昨日的不开心一下子全都消散了。虽然秋天已经来了好一阵儿了，不过路两旁的风景还是很漂亮的。

骑进乌兰布统，越往后走人越少，路上碰见了好多次牛马拦路。从乌兰布统去到多伦的路上风景很好，选择下道骑行是明智的，一路上草原、小河、树林，遇到太多美景。

赶着中午骑到了多伦湖，简单吃过饭后就开始了环湖之旅，一路上走走停停。到了一处小高峰，把摩托骑了上去，太适合给我的小摩托来一张照片了。刚拍上就碰到了俩大哥，帮我和我的小摩托来了本次摩旅的第一张合照，聊了会儿道谢之后就开始往回返。

回到环湖起点时间还早，简单搜了下发现往北一点儿就是「滦河」源，小时候家乡人口中的滦河（唐山话：láng hé）原来是从这里流下去的。往滦河源的路不是很好走，骑到一半发现一条土路，骑过去是一个小平台，望向四周很美。后面跟过来好多越野车，也纷纷下来拍照，发现我骑了摩托过来就一个个站在旁边拍起了照片。我过去车上拿我的相机，说道慢慢拍不着急，小姐姐问我可不可以坐上去，我说没问题。后来我也拜托他们帮我和我的小摩托拍了第二张合照，我也成了几个阿姨的摄影师。

快乐是什么？一路上美丽的风景，一路上美丽的人，还有多少能带给他人快乐的我和我的小摩托。果然不敢路的一天是轻松的，从滦河源下来之后就早早赶到多伦的酒店休息了。

第三天

早起的阳光不错，虽然空气有些凉，但是太阳照着还是暖洋洋的，耳机里恰巧响起了赵照的「在冬天和奶奶一起晒太阳」，有些惬意。走着走着云多了起来，中午赶到了太仆寺旗，吃上一口热乎的麻辣烫。

中午微信群里有哥们说北京下大雨了，我心底还在暗暗窃喜这几天出行的天气都还不错，然而这 Flag 还是立早了……下午在去往张北的路上碰见了一波从北京来的摩旅队伍，什么车都有，有 ADV，有踏板，可见是真友谊，ADV 还能带着小踏板一起愉快的玩耍。前半程的风景很不错，路两旁的树叶开始泛黄飘落，一条直路望不见头。

天气渐渐阴沉了下来，肉眼可见前方有积雨云，但还是朝着前方骑了下去。突然天空飘起了小雨，但很快又没了，停在一个加油站打开雷达云图，发现云应该已经从要走的路上飘过去了，简单休息了一下又继续往前走。

路上淅淅沥沥的飘落几滴雨，但路面已经湿透了，之前应该是下了一阵。走着走着发现大腿有点凉，想着应该是雨水溅落到裤子上了。找了个地方停下一看，我去，车子、衣服、后座包已经被黒黑的泥水沾满，躲过了雨水，躲不过泥巴……水越溅越多，身体也越来越冷，万幸还是撑到了张北。找了个肯德基，点了一大杯热拿铁，喝完天已经放晴，看看时间不早了，再不走估计到乌兰察布得很晚了，简单把车擦了下就又启程了。

前半程的国道一路都是风景，但从张北到乌兰察布的后半程除了大车和尘土啥都没有。天彻底放晴，一股暖意上来，还好老天没太折磨我，停下来特意给我脏了吧唧但不离不弃的小摩托照了张像，纪念有史以来最脏的一次。

上了高速就快多了，大概 6 点半多赶到了酒店，卸下行囊第一件事就是去找了个洗车店把我的小摩托好好冲一冲，拿过老板的水枪就开始了自助洗车，洗完之后，我漂亮的小摩托又回来了！

第四天

一早起来天气有些阴冷，不过早有预期，昨天看天气，相比其他地方至少没有下雨。先走了国道去火山，路不太好，一路上身体到不是很冷，冷的是手，夏季的手套还真实漏风，走走停停，冷的受不了就带着手套放在发动机上「烤烤火」。

快到火山了发现一条岔路，还有警察叔叔在摆一个大牌子，「火山旅游路线」，问了后果断选择了指向的新路，新路好走的不要不要的。来到六号火山，人还不少，阴天更是给这里增添了一份外星感。摩托的好处是能骑上平台，转到北面发现人比较少，借来的大疆终于能派上用场了，虽然最后感觉拍的并不好。

往下走看到有几辆越野车爬上了小山丘，心里想来都来了，不在土路上骑一遭怎么对得起我这「越野版」的小狮子。

转完火山发现时间不是很晚，导航了下发现应该能在 7 点前赶回北京，想了想北京这几天都有雨，应该怎么都躲不过，一番权衡之下打算今天直接回北京。上了高速很快就到了集宁服务区，已经快 2 点了，正好吃午饭，这时天也下上了小雨。吃完之后再次权衡，还是决定继续往北京走，如果下大了不行就找最近的口下。一路上，雨不算大也不算小，这就让人很纠结，每到一个服务区就停下来看看云图，最终还是在晚上 10 点前回到了北京。陪了我五年的手机最终在进入地库前因为进水太多失灵然后宕机了，万幸坚持到了回家。

这段雨中经历感觉能回忆一辈子，不是因为勇敢，也不是因为幸运。敢这么走下来，还是评估了环境没有那么恶劣，对自己的驾驶技术也有一定把握，当然最重要的是量力，人永远不要同自然和生命开玩笑。所以每一个服务区都停下来，要么吃点东西，要么喝点热水，休整好后继续往前走。如果说知道 10 点才能到北京，让我再选择一次的话，我想我会选择在中途歇上一晚，虽然第二天也躲不开雨，但能骑得更从容些。

之后

真的要感谢我靠谱的小摩托，一直不离不弃，也要感谢这一路上遇到的陌生人的祝福和帮助。服务区遇到的摩托情侣，问我衣服是不是穿得太少，我没好意思说烫坏了，就只说带少了。餐厅拼桌吃饭的一家，男主人在深圳上班，自己不玩摩托，但工作的地方挨着交管局，见到太多扣查的摩托（深圳全市禁摩），分别时一个握手，一句平安。高速路上，三车道，我在最右侧，中间车道的一辆大车超我时特意变到左侧，掀起的水花完全没溅到我，这一定是个可爱的司机大叔吧。

旅行的意义在哪里？形形色色的人，真实且普通，慢下来，你能看到自己的更多面，也能看到陌生人的一面，或好或坏，无所谓，世界不就是这样吗。

2021-08-08 08:00:00

设计语言（Design Language）或设计语言系统（Design Language System, DLS）是一套用于指导产品设计的整体风格方案 ¹。设计语言把设计作为一种“沟通的方式”，用于在特定的场景内，做适当的表达，进行特定的信息传递。设计语言在建筑、工业设计和数字产品等领域都有广泛的应用，本文仅围绕数字产品进行初探。

为什么构建设计语言？

统一

通过设计语言可以在整个平台中统一颜色、字体、组件、动效等各种规范，避免由于设计师的个人特点导致产品风格不一致。

体验

优秀的设计语言符合大众审美，可以提高产品的可用性和易用性。设计语言可以使用户能够与具备一致性的应用进行交互，让用户在使用过程中获得愉悦，提升用户体验。

效率

优秀的设计语言使得设计和开发团队能够快速、经济、高效地进行开发、重构和迭代产品。通过不断更新和完善的文档库，可以改善团队之间的协作，提高生产力。

品牌

设计语言的构建可以传达一个统一的公司品牌形象。设计语言让产品具有自己的身份，使其在市场上的众多产品中更容易被识别出来，加深用户对品牌的印象。

设计语言构建

在此我们借助语言学的角度来讨论数字化产品的构建 ²。在语言应用中，我们通常会涉及语法、语素、语句、语义、语境、语气、语素和响度等维度，通过不同的组合达成应景的表达和适时的沟通。

语法

设计语言中的语法即设计价值观和设计原则，这是构建设计语言系统的起点，用于传达品牌主张或设计理念，它将指引业务设计执行的方向。

制定设计原则时，首先研究用户特性，聚焦产品核心价值，然后通过脑暴等形式选择有特点的维度，结合用户体验与品牌属性将其视觉化，最后用简要的语言归纳出来。

Ant Design 设计价值观 ³

	自然 数字世界的光速迭代使得产品日益复杂，而人类意识和注意力资源有限。面对这种设计矛盾，追求「自然」交互将是 Ant Design 持之以恒的方向。
	确定性 界面是用户与系统交互的媒介，是手段而非目的。在追求「自然」交互基础上，通过 Ant Design 创造的产品界面应是高确定性、低合作熵的状态。
	意义感 一个产品或功能被设计者创造出来不只是用户的需要，而更多是承载用户的某个工作使命。产品设计应充分站在工作视角，促成用户使命的达成；同时，在「自然」、「确定」之上，兼顾用户的人性需求，为工作过程创造富有意义感的人机交互。
	生长性 企业级产品功能的增长与用户系统角色的演变相生相伴。设计者应为自己创造的产品负责，提升功能、价值的可发现性。用发展的眼光做设计，充分考虑人、机两端的共同生长。

Ant Design 设计原则 ⁴

亲密性

如果信息之间关联性越高，它们之间的距离就应该越接近，也越像一个视觉单元；反之，则它们的距离就应该越远，也越像多个视觉单元。亲密性的根本目的是实现组织性，让用户对页面结构和信息层次一目了然。

对齐

正如「格式塔学派」中的连续律（Law of Continuity）所描述的，在知觉过程中人们往往倾向于使知觉对象的直线继续成为直线，使曲线继续成为曲线。在界面设计中，将元素进行对齐，既符合用户的认知特性，也能引导视觉流向，让用户更流畅地接收信息。

对比

对比是增加视觉效果最有效方法之一，同时也能在不同元素之间建立一种有组织的层次结构，让用户快速识别关键信息。

重复

相同的元素在整个界面中不断重复，不仅可以有效降低用户的学习成本，也可以帮助用户识别出这些元素之间的关联性。

直截了当

正如 Alan Cooper 所言：「需要在哪里输出，就要允许在哪里输入」。这就是直接操作的原理。eg：不要为了编辑内容而打开另一个页面，应该直接在上下文中实现编辑。

足不出户

能在这个页面解决的问题，就不要去其它页面解决，因为任何页面刷新和跳转都会引起变化盲视（Change Blindness），导致用户心流（Flow）被打断。频繁的页面刷新和跳转，就像在看戏时，演员说完一行台词就安排一次谢幕一样。

简化交互

根据费茨法则（Fitts’s Law）所描述的，如果用户鼠标移动距离越少、对象相对目标越大，那么用户越容易操作。通过运用上下文工具（即：放在内容中的操作工具），使内容和操作融合，从而简化交互。

提供邀请

很多富交互模式（eg：「拖放」、「行内编辑」、「上下文工具」）都有一个共同问题，就是缺少易发现性。所以「提供邀请」是成功完成人机交互的关键所在。

邀请就是引导用户进入下一个交互层次的提醒和暗示，通常包括意符（eg：实时的提示信息）和可供性，以表明在下一个界面可以做什么。当可供性中可感知的部分（Perceived Affordance）表现为意符时，人机交互的过程往往更加自然、顺畅。

巧用过渡

人脑灰质（Gray Matter）会对动态的事物（eg：移动、形变、色变等）保持敏感。在界面中，适当的加入一些过渡效果，能让界面保持生动，同时也能增强用户和界面的沟通。

即时反应

「提供邀请」的强大体现在 交互之前 给出反馈，解决易发现性问题；「巧用过渡」的有用体现在它能够在 交互期间 为用户提供视觉反馈；「即时反应」的重要性体现在 交互之后 立即给出反馈。

就像「牛顿第三定律」所描述作用力和反作用一样，用户进行了操作或者内部数据发生了变化，系统就应该立即有一个对应的反馈，同时输入量级越大、重要性越高，那么反馈量级越大、重要性越高。

虽然反馈太多（准确的说，错误的反馈太多）是一个问题，但是反馈太少甚至没有反馈的系统，则让人感觉迟钝和笨拙，用户体验更差。

Alibaba Fusion 设计价值观 ⁵

化繁为简的交互模式

面对互联网产品高迭代节奏和复杂的中后台场景，将复杂的业务组件抽象为用户标准认知层的交互方式，这套组件库来自于阿里巴巴上百个中后台场景的抽象结果，试图建立中后台 web 设计标准。

驾驭技术

你用的所有设计资料，小到 sketch 样式工具中的颜色、字体、字号、投影、边框、尺寸；再到组件，大到一套完整的中后台产品系统，均能找到其对应的代码，完整的释放整个团队的前端生产力。

追求新鲜，潮流

设计风格每年都会更新换代，由于 Alibaba Fusion 设计系统中的颜色、字体、字号、投影等样式均可通过线上配置修改，这也决定了它可以快速（甚至 15 分钟内）完成整套设计系统的样式迭代。

聚变/裂变

通过在 Alibaba Fusion 设计系统原则下，变换样式、多维度定制组件交互形式，可瞬间获取属于自己业务属性的设计系统；我们期待有无数业务线能够通过 Alibaba Fusion 的设计系统原则聚变出符合各类业务场景的 Fusion 生态系统。

效率

Alibaba Fusion Design 希望构建一套提升设计与开发之间 UI 构建效率的工作方式，让 UED 的工作能够尽可能多的投入在 UE（User Experience）的用户调研、用户体验、商业思考，而在 D（Design）的过程中更多的投入与创意而非日复一日的重复绘图。

腾讯 Q 语言理念 ⁶

	统一体验 QQ 作为一个社交平台，会容纳多样性的功能与体验，为了降低用户在不同场景功能下的学习成本，并提升易用性，统一体验是提升平台易用性的关键基础。同时有助于提升各角色间的协作效率。
	基因体现 当今同质化的社交应用越来越多，QQ 作为横跨多时期多平台的社交应用，一方面需紧贴时代趋势，在众多应用中脱颖而出，另一方面有足够的历史底蕴，应强化自身基因特征，提升整体品牌认知。
	社交向善 社交应用会融入琳琅满目的娱乐化规则与玩法，但吸引年轻人的不应只是单纯娱乐消费，需要考虑社交娱乐的本质初心，QQ 更倡导用户在一个积极健康，安全贴心，触动情感的环境进行社交，并最终导人向善。
	高效娱乐 伴随信息传播便利性提升，用户需要更高浓度的信息和更快的娱乐方式。用户时间愈加宝贵，偏向消费耗时较短的短视频、信息流等内容，希望更快找到喜欢的内容，以及更高浓度的内容。
	兴趣细分 互联网使用场景更细分，兴趣爱好更加细分深入。各种兴趣圈、游戏圈、粉丝圈等年轻用户基于互联网衍生出来的圈子，需要有更细分深入的功能场景去承载。线上和线下联动是细分圈子持续活跃的关键。
	社交压力 互联网信息传播的扩散效应，以及社会的复杂性给用户带来更多社交压力，原创越来越少。可以通过丰富的形象建立和维护体系增强用户的社交动力，引导产生更多原创内容和互动。

腾讯 Q 语言原则 ⁷

	活力灵动 对年轻人有吸引力，传递积极乐观情感，有怦然心动的感觉。
	亲和自然 体验过程犹如与朋友打交道，亲和自然，懂我所想。
	自我有范 用户能无压力表达自我，满足不同人群个性诉求。

语素

视觉基础是构成设计语言的最小单位，就像语素是语言中最小的音义结合体。在原子设计理论中，它属于最小粒度的元素，通常包括：色彩、布局、字体、图标等。

色彩

无论 UI 还是平面，颜色是视觉传达的最核心也是最基本的语言，不同的主色，会给人不同的视觉感受，同样的主色不同的配色，视觉感受也会不同。通常一款产品的色彩体系包含：品牌色、功能色、中立色三个部分：

品牌色：代表品牌形象及 VI 识别的色彩，品牌色的数量可以一个也可以多个，用于主按钮、主 icon 等需要突出品牌特征的地方。

功能色：代表明确的信息以及状态，如成功、出错、失败、提醒等。功能色的选取需要遵守用户对色彩的基本认知，如绿色代表成功，红色代表警示或失败。

中立色：灰或饱和度低的颜色，用于界面设计中的字体、背景、边框、分割线等，中立色通常是按照透明度的方式实现。

布局

空间布局是体系化视觉设计的起点，和传统的平面设计的不同之处在于，UI 界面的布局空间要基于「动态、体系化」的角度出发展开。在中后台视觉体系中定义布局系统，可以从 5 个方面出发：统一的画板尺寸、适配方案、网格单位、栅格、常用模度。

统一画板：为了尽可能减少沟通与理解的成本，有必要在组织内部统一设计板的尺寸。

适配：在设计过程中还需要建立适配的概念，根据具体情况判断系统是否需要进行适配，以及哪些区块需要考虑动态布局。

左右布局的适配方案：常被用于左右布局的设计方案中，常见的做法是将左边的导航栏固定，对右边的工作区域进行动态缩放。

上下布局的适配方案：常被用于上下布局的设计方案中，做法是对两边留白区域进行最小值的定义，当留白区域到达限定值之后再对中间的主内容区域进行动态缩放。

网格单位：通过网格体系可以实现视觉体系的秩序。网格的基数为 8，不仅符合偶数的思路同时能够匹配多数主流的显示设备。通过建立网格的思考方式，还能帮助设计者快速实现布局空间的设计决策同时也能简化设计到开发的沟通损耗。

栅格：以上下布局的结构为例，对内容区域进行 24 栅格的划分设置，如下图所示。页面中栅格的 Gutter 设定了定值，即浏览器在一定范围扩大或缩小，栅格的 Column 宽度会随之扩大或缩小，但 Gutter 的宽度值固定不变。

模度：模度是为了帮助不同设计能力的设计者们在界面布局上的一致性和韵律感，统一设计到开发的布局语言，减少还原损耗。

字体

字体是界面设计中最基本的构成之一。通过定义字体在设计上的使用规则，从而在阅读的舒适性上达到平衡。确定字体主要从下面四个方面出发：字体家族、主字体、字阶与行高、字重。

字体家族：优秀的字体系统首先是要选择合适的字体家族。提供一套利于屏显的备用字体库，来维护在不同平台以及浏览器的显示下，字体始终保持良好的易读性和可读性，体现了友好、稳定和专业的特性。在中后台系统中，数字经常需要进行纵向对比展示，将数字的字体 font-variant-numeric 设置为 tabular-nums，使其为等宽字体。

主字体：基于电脑显示器阅读距离（50 cm）以及最佳阅读角度（0.3），将自私设置为 14，以保证在多数常用显示器上的用户阅读效率最佳。

字阶与行高：字阶和行高决定着一套字体系统的动态与秩序之美。字阶是指一系列有规律的不同尺寸的字体。行高可以理解为一个包裹在字体外面的无形的盒子。

字重：字重的选择同样基于秩序、稳定、克制的原则。多数情况下，只出现 regular 以及 medium 的两种字体重量，分别对应代码中的 400 和 500。在英文字体加粗的情况下会采用 semibold 的字体重量，对应代码中的 600。

图标

图标是 UI 设计中必不可少的组成。通常我们理解图标设计的含义，是将某个概念转换成清晰易读的图形，从而降低用户的理解成本，提升界面的美观度。在我们的企业级应用设计范围中，图标在界面设计的诸多元素中往往只占了很小的比重，在调用时也会被缩到比设计稿小很多倍的尺寸，加上在图形素材极度丰富并且便于获取的今天，在产品设计体系中实现一套美观、一致、易用、便于延展的图标体系往往会被不小心忽略掉。

语句

组件就像由若干个语素组成的语句，比如一个基础按钮，通常就是由颜色、字体、边距等元素组成。而我们平时所说的组件库，其实就是一部词典，其中包含了设计系统中所需的基础组件与用法，在界面设计中也具有较高的通用性。

语义

符号是语言的载体，但符号本身没有意义，只有被赋予含义的符号才能够被使用，这时候语言就转化为信息，而语言的含义就是语义。在视觉传达设计中也一样，使用的图标或图形，需具备正确的语义属性。如果商场导视设计中非要使用「裙子」图标来代表「男厕」入口，如此混淆语义挑战公众认知，那就等着被投诉吧。

语境

语境包含 3 个维度：一是流程意义上的上下文，二是产品属性中的语境，三是用户当下所处的环境。

当设计需要对上下文进行特别处理时，有可能对话的层级次序是受限于屏幕稀缺性，通常可采用 z-depth 叠加（Material Design 属性）、步骤条、元素关联转场动效等方式。举个常见的例子，当用户发起一个删除数据的请求时，界面会弹出一个二次确认的模态会话，用户点击确认之后才会执行删除操作。

针对用户当下所处的环境来适配界面语境，常见通过界面换肤的手法来实现，比如微信读书等阅读应用为用户提供白天模式或黑夜模式的选择。用户所处的外部环境因素可以很大程度上决定界面语言的应用，就好像在菜市场买东西要靠吼，在图书馆借书仅需要用肢体语言便能达成。

语气

交互界面通常需要使用说明或提示文案来指导用户完成操作，大多数情况下都是使用第二人称，就像在与用户对话，从以用户为中心的角度上讲，建议保持谦逊、友善的语气，尽可能避免使用晦涩的专业术语，谨慎使用带有强烈情感属性的感叹号，或过于口语化的语言。另外，语气的拿捏也将直接影响到与用户的距离感，以及当下的应景度。

语速

语速在这里指的是界面的信息密度，在不同的场合对语速的控制能够提升接受者的体验，视觉设计也同样需要注意把握间距与留白，网格系统在这里可以起到「节拍器」的作用，借助节拍器可以让设计更具节奏感。而交互意义上的语速，更多体现在操作路径的长度，以及动效的速率。

下图分别展示了 QQ 音乐和富途牛牛两种不同场景的「语速」：

响度

其实就好像我们说话可以通过音量大小来控制信息的可感知程度，希望接受者听清楚的就说大声一点。汤姆奥斯本（Tom Osborne）的视觉响度指南（Visual Loudness Guide）是一个如何系统地处理按钮和链接的例子，它们不是单独列出，而是作为一个套件呈现，并且根据每个元素的视觉冲击力会相应的拥有一个「响度」值。我们在构建设计语言系统时，也同样需要设置梯级「响度」的按钮、字重等组件来满足不同场景的表达需求。

设计语言列表

2021-06-19 08:00:00

文本使用的软件版本分别为：

1. JDK：1.8.0_291，下载地址。
2. Scala：2.12.14，下载地址。
3. Hadoop：3.2.2，下载地址。
4. Spark：3.1.2，下载地址。
5. Python：3.9，Miniconda3，下载地址。

按照虚拟环境准备 (Virtual Environment Preparation) 准备虚拟机。

按照 Hadoop 集群搭建 (Hadoop Cluster Setup) 搭建 Hadoop 集群。

本文以 Spark on YARN 模式介绍 Spark 集群的搭建。

Scala 配置

将 Scala 安装包解压缩到 /opt 目录并创建软链接：

cd /opt
tar -zxvf scala-2.12.14.tgz
ln -s /opt/scala-2.12.14 /opt/scala

将如下信息添加到 /etc/profile 中：

# Scala
export SCALA_HOME=/opt/scala
export PATH=$PATH:$SCALA_HOME/bin

方便起见可以使用 rsync 命令同步 Scala：

rsync -auvp /opt/scala-2.12.14 leo@vm-02:/opt
rsync -auvp /opt/scala-2.12.14 leo@vm-03:/opt

Spark 配置

将 Spark 安装包解压缩到 /opt 目录并创建软链接：

cd /opt
tar -zxvf spark-3.1.2-bin-hadoop3.2.tgz
ln -s /opt/spark-3.1.2-bin-hadoop3.2 /opt/spark

将如下信息添加到 /etc/profile 中：

# Spark
export SPARK_HOME=/opt/spark
export PATH=$PATH:$SPARK_HOME/bin

复制环境变量文件：

cp /opt/spark/conf/spark-env.sh.template /opt/spark/conf/spark-env.sh

在 spark-env.sh 结尾添加如下内容：

export JAVA_HOME=/opt/jdk
export SCALA_HOME=/opt/scala
export HADOOP_HOME=/opt/hadoop
export HADOOP_CONF_DIR=$HADOOP_HOME/conf
export YARN_CONF_DIR=$HADOOP_HOME/conf
export SPAKR_HOME=/opt/spark
export SPARK_CONF_DIR=$SPAKR_HOME/conf

export SPARK_EXECUTOR_CORES=1
export SPARK_EXECUTOR_MEMORY=1G
export SPARK_DRIVER_MEMORY=1G
export SPARK_HISTORY_OPTS="-Dspark.history.retainedApplications=10"

复制配置文件：

cp /opt/spark/conf/spark-defaults.conf.template /opt/spark/conf/spark-defaults.conf

修改 spark-defaults.conf 文件内容如下：

spark.eventLog.enabled              true
spark.eventLog.compress             true
spark.eventLog.dir                  hdfs://vm-01:9000/logs/spark
spark.history.fs.logDirectory       hdfs://vm-01:9000/logs/spark
spark.yarn.historyServer.address    vm-01:18080
spark.yarn.jars                     hdfs://vm-01:9000/spark/jars/*

复制 Worker 节点列表文件：

cp /opt/spark/conf/workers.template /opt/spark/conf/workers

修改 workers 文件内容如下：

vm-01
vm-02
vm-03

在 HDFS 上创建目录，并上传 Spark 相关 JAR 包：

hdfs dfs -mkdir -p /spark/jars
hdfs dfs -put /opt/spark/jars/* /spark/jars/

方便起见可以使用 rsync 命令同步 Spark：

rsync -auvp /opt/spark-3.1.2-bin-hadoop3.2 leo@vm-02:/opt
rsync -auvp /opt/spark-3.1.2-bin-hadoop3.2 leo@vm-03:/opt

启动 Spark

在 vm-01，vm-02 和 vm-03 上启动 Zookeeper：

zkServer.sh start

启动 Hadoop：

/opt/hadoop/sbin/start-dfs.sh
/opt/hadoop/sbin/start-yarn.sh

获取并切换 YARN Resource Manager 的状态：

yarn rmadmin -getServiceState rm1
yarn rmadmin -getServiceState rm2

yarn rmadmin -transitionToActive rm1 --forcemanual

在 HDFS 上创建相关目录：

hdfs dfs -mkdir /logs
hdfs dfs -mkdir /logs/spark

启动 Spark：

/opt/spark/sbin/start-all.sh

通过 http://vm-01:8081 可以进入 Spark Web 页面：

启动 Spark History Server：

/opt/spark/sbin/start-history-server.sh

执行 PI 示例程序：

spark-submit \
  --class org.apache.spark.examples.SparkPi \
  --master yarn \
  --deploy-mode cluster \
  --executor-memory 1G \
  --num-executors 3 \
  /opt/spark/examples/jars/spark-examples*.jar \
  10

在 YARN 中，通过 Application ID 查看对应的 Container 的 stdout 日志，可以得到示例程序的运行结果：

Pi is roughly 3.1424791424791425

通过 http://vm-01:18081 可以进入 Spark History Server 页面：

NFS 配置

安装 NFS 相关软件：

sudo apt install nfs-kernel-server nfs-common

在 vm-01，vm-02 和 vm-03 上创建 MFS 文件夹并设置权限：

sudo mkdir /nfs
sudo chown -R leo:leo /nfs

在 vm-01 上修改 /etc/exports 文件，配置 NFS 共享目录：

/nfs 192.168.56.1/24(rw,sync,no_root_squash,no_subtree_check)

相关参数定义可以通过 man nfs 获取。

导出共享目录并重启 NFS 服务：

sudo exportfs -a
sudo service nfs-kernel-server restart

在 vm-02 和 vm-03 上挂在 NFS：

sudo mount vm-01:/nfs /nfs

在 /etc/fstab 中添加如下内容实现开机自动挂载：

vm-01:/nfs /nfs nfs rw

Python 配置

安装 Miniconda3 到 /nfs/miniconda3 目录：

sh Miniconda3-py39_4.9.2-Linux-x86_64.sh

在安装过程中安装选项如下：

Miniconda3 will now be installed into this location:
/home/leo/miniconda3

  - Press ENTER to confirm the location
  - Press CTRL-C to abort the installation
  - Or specify a different location below

[/home/leo/miniconda3] >>> /nfs/miniconda3

Do you wish the installer to initialize Miniconda3
by running conda init? [yes|no]
[no] >>> yes

修改 ~/.condarc 更改 Anaconda 镜像：

channels:
  - defaults
show_channel_urls: true
default_channels:
  - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main
  - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/r
  - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/msys2
custom_channels:
  conda-forge: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
  msys2: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
  bioconda: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
  menpo: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
  pytorch: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
  simpleitk: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud

创建用于 Spark 的 Python 环境：

conda create -n spark python=3.9

分别在 vm-02 和 vm-03 中将如下信息添加到 /etc/profile 中：

# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$('/nfs/miniconda3/bin/conda' 'shell.bash' 'hook' 2> /dev/null)"
if [ $? -eq 0 ]; then
    eval "$__conda_setup"
else
    if [ -f "/nfs/miniconda3/etc/profile.d/conda.sh" ]; then
        . "/nfs/miniconda3/etc/profile.d/conda.sh"
    else
        export PATH="/nfs/miniconda3/bin:$PATH"
    fi
fi
unset __conda_setup
# <<< conda initialize <<<

分别在 vm-01，vm-02 和 vm-03 中将如下信息添加到 /etc/profile 中：

# Python 3.9 for Spark
conda activate spark

PySpark 测试

输入 pyspark 进入 PySaprk Shell：

Welcome to
      ____              __
     / __/__  ___ _____/ /__
    _\ \/ _ \/ _ `/ __/  '_/
   /__ / .__/\_,_/_/ /_/\_\   version 3.1.2
      /_/

Using Python version 3.9.5 (default, Jun  4 2021 12:28:51)
Spark context Web UI available at http://vm-01:4040
Spark context available as 'sc' (master = local[*], app id = local-1623876641615).
SparkSession available as 'spark'.
>>>

执行 PI 示例程序：

from random import random
from operator import add

partitions = 3
n = 100000 * partitions

def f(_):
    x = random() * 2 - 1
    y = random() * 2 - 1
    return 1 if x ** 2 + y ** 2 <= 1 else 0

count = spark.sparkContext.parallelize(range(1, n + 1), partitions).map(f).reduce(add)
print("Pi is roughly %f" % (4.0 * count / n))

运行结果如下：

Pi is roughly 3.147160

2021-06-14 08:00:00

文本使用的软件版本分别为：

1. JDK：1.8.0_291，下载地址。
2. Hadoop：3.2.2，下载地址。
3. Hive：3.2.1，下载地址。
4. MySQL：8.0.25，使用 apt install mysql-server 安装。
5. MySQL JDBC Connector：8.0.25，下载地址。

按照虚拟环境准备 (Virtual Environment Preparation) 准备虚拟机列表如下：

按照 Hadoop 集群搭建 (Hadoop Cluster Setup) 搭建 Hadoop 集群。

MySQL 安装和配置

通过如下命令安装 MySQL：

sudo apt install mysql-server mysql-client libmysqlclient-dev

安装完毕后，使用如下命令初始化 MySQL：

sudo mysql_secure_installation

在密码安全性校验步骤，输入 N 关闭密码安全性校验：

VALIDATE PASSWORD COMPONENT can be used to test passwords
and improve security. It checks the strength of password
and allows the users to set only those passwords which are
secure enough. Would you like to setup VALIDATE PASSWORD component?

Press y|Y for Yes, any other key for No: N

输入新密码：

New password: *********
Re-enter new password: *********

在删除匿名用户环节，输入 Y 删除匿名用户：

By default, a MySQL installation has an anonymous user,
allowing anyone to log into MySQL without having to have
a user account created for them. This is intended only for
testing, and to make the installation go a bit smoother.
You should remove them before moving into a production
environment.

Remove anonymous users? (Press y|Y for Yes, any other key for No) : Y

输入 N 允许远程登录 root 用户：

Normally, root should only be allowed to connect from
'localhost'. This ensures that someone cannot guess at
the root password from the network.

Disallow root login remotely? (Press y|Y for Yes, any other key for No) : N

输入 N 保留 test 数据库：

By default, MySQL comes with a database named 'test' that
anyone can access. This is also intended only for testing,
and should be removed before moving into a production
environment.

Remove test database and access to it? (Press y|Y for Yes, any other key for No) : N

输入 Y 应用设置并生效：

Reloading the privilege tables will ensure that all changes
made so far will take effect immediately.

Reload privilege tables now? (Press y|Y for Yes, any other key for No) : Y

修改 MySQL 配置文件：

sudo vi /etc/mysql/mysql.conf.d/mysqld.cnf

将绑定地址替换为 0.0.0.0：

bind-address            = 0.0.0.0
mysqlx-bind-address     = 0.0.0.0

重启 MySQL 服务：

sudo service mysql restart

在本地通过如下命令并输入密码进入 MySQL：

sudo mysql -uroot -p

在 MySQL 命令行中输入如下语句为 root 用户配置允许远程访问：

CREATE USER 'root'@'%' IDENTIFIED BY '**********';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;
EXIT;

之后在宿主机通过如下命令即可登录虚拟机中的 MySQL：

mysql -h192.168.56.101 -uroot -p

为 Hive 创建数据库和用户，并设置相关权限：

CREATE DATABASE hive;
CREATE USER 'hive'@'%' IDENTIFIED BY '**********';
GRANT ALL PRIVILEGES ON hive.* TO 'hive'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;
EXIT;

Hive 安装和配置

将 Hive 安装包解压缩到 /opt 目录并创建软链接：

cd /opt
tar -zxvf apache-hive-3.1.2-bin.tar.gz
ln -s /opt/apache-hive-3.1.2-bin /opt/hive

将如下信息添加到 /etc/profile 中：

# Hive
export HIVE_HOME=/opt/hive
export PATH=$PATH:$HIVE_HOME/bin

复制环境变量文件：

cp /opt/hive/conf/hive-env.sh.template /opt/hive/conf/hive-env.sh

修改 hive-env.sh 内容如下：

export JAVA_HOME=/opt/jdk
export HADOOP_HOME=/opt/hadoop
export HIVE_HOME=/opt/hive
export HIVE_CONF_DIR=$HIVE_HOME/conf

创建配置文件：

vi /opt/hive/conf/hive-site.xml

修改 hive-site.xml 内容如下：

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
  <property>
    <name>javax.jdo.option.ConnectionURL</name>
    <value>jdbc:mysql://vm-01:3306/hive</value>
  </property>
  <property>
    <name>javax.jdo.option.ConnectionDriverName</name>
    <value>com.mysql.cj.jdbc.Driver</value>
  </property>
  <property>
    <name>javax.jdo.option.ConnectionUserName</name>
    <value>hive</value>
  </property>
  <property>
    <name>javax.jdo.option.ConnectionPassword</name>
    <value>*********</value>
  </property>
</configuration>

将 MySQL JDBC Connector 解压缩到 /opt/hive/lib 中：

cd /opt
tar -zxvf mysql-connector-java-8.0.25.tar.gz
mv /opt/mysql-connector-java-8.0.25/mysql-connector-java-8.0.25.jar /opt/hive/lib
rm -rf /opt/mysql-connector-java-8.0.25

修正不兼容的依赖包：

mv /opt/hive/lib/log4j-slf4j-impl-2.10.0.jar /opt/hive/lib/log4j-slf4j-impl-2.10.0.jar.bak
mv /opt/hive/lib/guava-19.0.jar /opt/hive/lib/guava-19.0.jar.bak
cp /opt/hadoop/share/hadoop/common/lib/guava-*.jar /opt/hive/lib

初始化元数据：

schematool -dbType mysql -initSchema

出现如下输出时表示元数据初始化成功：

Metastore connection URL:	 jdbc:mysql://vm-01:3306/hive
Metastore Connection Driver :	 com.mysql.cj.jdbc.Driver
Metastore connection User:	 hive
Starting metastore schema initialization to 3.1.0
Initialization script hive-schema-3.1.0.mysql.sql
......
Initialization script completed
schemaTool completed

启动 Hive

执行如下命令启动 Hive：

hive

出现如下输出时表示启动成功：

Hive Session ID = f3edb53b-5037-47c3-b318-75854e2328c5

Logging initialized using configuration in jar:file:/opt/apache-hive-3.1.2-bin/lib/hive-common-3.1.2.jar!/hive-log4j2.properties Async: true
Hive Session ID = 3331472a-a171-47be-843a-378611233f18
Hive-on-MR is deprecated in Hive 2 and may not be available in the future versions. Consider using a different execution engine (i.e. spark, tez) or using Hive 1.X releases.
hive>

2021-06-13 08:00:00

文本使用的软件版本分别为：

1. JDK：1.8.0_291，下载地址。
2. Zookeeper：3.7.0，下载地址。
3. Hadoop：3.2.2，下载地址。

按照虚拟环境准备 (Virtual Environment Preparation) 准备虚拟机列表如下：

系统配置

将 /opt 目录所有者赋予当前用户：

sudo chown -R leo:leo /opt

在根目录建立 data 目录，并将其所有者赋予当前用户：

sudo mkdir /data
sudo chown -R leo:leo /data

JDK 配置

将 JDK 安装包解压缩到 /opt 目录并创建软链接：

cd /opt
tar -zxvf jdk-8u291-linux-x64.tar.gz
ln -s /opt/jdk1.8.0_291 /opt/jdk

将如下信息添加到 /etc/profile 中：

# JDK
export JAVA_HOME=/opt/jdk
export PATH=$PATH:$JAVA_HOME/bin

方便起见可以使用 rsync 命令同步 JDK：

rsync -auvp /opt/jdk1.8.0_291 leo@vm-02:/opt 
rsync -auvp /opt/jdk1.8.0_291 leo@vm-03:/opt 

Zookeeper 配置

将 Zookeeper 安装包解压到 /opt 目录并创建软链接：

cd /opt
tar -zxvf apache-zookeeper-3.7.0-bin.tar.gz
ln -s /opt/apache-zookeeper-3.7.0-bin /opt/zookeeper

将如下信息添加到 /etc/profile 中：

# Zookeeper
export ZOOKEEPER_HOME=/opt/zookeeper
export PATH=$PATH:$ZOOKEEPER_HOME/bin

在 /data 目录下创建 zookeeper 文件夹：

mkdir /data/zookeeper

在 /data/zookeeper 目录中创建 myid 文件：

echo 1 > /data/zookeeper/myid    # 仅在 vm-01 上执行
echo 2 > /data/zookeeper/myid    # 仅在 vm-02 上执行
echo 3 > /data/zookeeper/myid    # 仅在 vm-03 上执行

复制 Zookeeper 配置文件：

cd /opt/zookeeper/conf
mv zoo_sample.cfg zoo.cfg

修改 zoo.cfg 文件内容如下：

# the directory where the snapshot is stored.
# do not use /tmp for storage, /tmp here is just
# example sakes.
dataDir=/data/zookeeper

# servers
server.1=vm-01:2888:3888
server.2=vm-02:2888:3888
server.3=vm-03:2888:3888

方便起见可以使用 rsync 命令同步 Zookeeper：

rsync -auvp /opt/apache-zookeeper-3.7.0-bin leo@vm-02:/opt 
rsync -auvp /opt/apache-zookeeper-3.7.0-bin leo@vm-03:/opt 

Hadoop 配置

将 Hadoop 安装包解压到 /opt 目录并创建软链接：

cd /opt
tar -zxvf /hadoop-3.2.2.tar.gz
ln -s /opt/hadoop-3.2.2 /opt/hadoop

将如下信息添加到 /etc/profile 中：

# Hadoop
export HADOOP_HOME=/opt/hadoop
export PATH=$PATH:$HADOOP_HOME/bin

在 /data 目录下创建如下文件夹：

mkdir /data/hadoop
mkdir /data/hadoop/tmp
mkdir /data/hadoop/pid
mkdir /data/hadoop/logs
mkdir /data/hadoop/hdfs
mkdir /data/hadoop/hdfs/journalnode
mkdir /data/hadoop/hdfs/namenode
mkdir /data/hadoop/hdfs/datanode

编辑 /opt/hadoop/etc/hadoop/core-site.xml 内容如下：

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
  <property>
    <!-- HDFS 的 nameservice -->
    <name>fs.defaultFS</name>
    <value>hdfs://ns1/</value>
  </property>
  <property>
    <!-- Hadoop 临时目录 -->
    <name>hadoop.tmp.dir</name>
    <value>/data/hadoop/tmp</value>
  </property>
  <property>
    <!-- Zookeeper 地址 -->
    <name>ha.zookeeper.quorum</name>
    <value>vm-01:2181,vm-02:2181,vm-03:2181</value>
  </property>
</configuration>

编辑 /opt/hadoop/etc/hadoop/hdfs-site.xml 内容如下：

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
  <property>
    <!-- HDFS 的 nameservice -->
    <name>dfs.nameservices</name>
    <value>ns1</value>
  </property>
  <property>
    <!-- namenode 列表 -->
    <name>dfs.ha.namenodes.ns1</name>
    <value>nn1,nn2,nn3</value>
  </property>
  <property>
    <!-- nn1 的 RPC 通信地址 -->
    <name>dfs.namenode.rpc-address.ns1.nn1</name>
    <value>vm-01:9000</value>
  </property>
  <property>
    <!-- nn2 的 RPC 通信地址 -->
    <name>dfs.namenode.rpc-address.ns1.nn2</name>
    <value>vm-02:9000</value>
  </property>
  <property>
    <!-- nn3 的 RPC 通信地址 -->
    <name>dfs.namenode.rpc-address.ns1.nn3</name>
    <value>vm-03:9000</value>
  </property>
  <property>
    <!-- nn1 的 HTTP 通信地址 -->
    <name>dfs.namenode.http-address.ns1.nn1</name>
    <value>vm-01:50070</value>
  </property>
  <property>
    <!-- nn2 的 HTTP 通信地址 -->
    <name>dfs.namenode.http-address.ns1.nn2</name>
    <value>vm-02:50070</value>
  </property>
  <property>
    <!-- nn3 的 HTTP 通信地址 -->
    <name>dfs.namenode.http-address.ns1.nn3</name>
    <value>vm-03:50070</value>
  </property>
  <property>
    <!-- namenode 在 journalnode 上的存放位置 -->
    <name>dfs.namenode.shared.edits.dir</name>
    <value>qjournal://vm-01:8485;vm-02:8485;vm-03:8485/ns1</value>
  </property>
  <property>
    <!-- journalnode 在磁盘上的存放位置 -->
    <name>dfs.journalnode.edits.dir</name>
    <value>/data/hadoop/hdfs/journalnode</value>
  </property>
  <property>
    <!-- 开启 namenode 失败自动切换 -->
    <name>dfs.ha.automatic-failover.enabled</name>
    <value>true</value>
  </property>
  <property>
    <!-- 配置失败自动切换实现方式 -->
    <name>dfs.client.failover.proxy.provider.ns1</name>
    <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
  </property>
  <property>
    <!-- 配置隔离机制方法，多个机制用换行分割，即每个机制暂用一行 -->
    <name>dfs.ha.fencing.methods</name>
    <value>sshfence</value>
  </property>
  <property>
    <!-- 使用 sshfence 隔离机制时需要 ssh 免密登陆 -->
    <name>dfs.ha.fencing.ssh.private-key-files</name>
    <value>/homt/leo/.ssh/id_rsa</value>
  </property>
  <property>
    <!-- 配置 sshfence 隔离机制超时时间 -->
    <name>dfs.ha.fencing.ssh.connect-timeout</name>
    <value>30000</value>
  </property>
  <property>
    <!-- journalnode HTTP 通信地址 -->
    <name>dfs.journalnode.http-address</name>
    <value>0.0.0.0:8480</value>
  </property>
  <property>
    <!-- journalnode RPC 通信地址 -->
    <name>dfs.journalnode.rpc-address</name>
    <value>0.0.0.0:8485</value>
  </property>
  <property>
    <!-- HDFS 副本数量 -->
    <name>dfs.replication</name>
    <value>1</value>
  </property>
  <property>
    <!-- namenode 在磁盘上的存放位置 -->
    <name>dfs.namenode.name.dir</name>
    <value>/data/hadoop/hdfs/namenode</value>
  </property>
  <property>
    <!-- datanode 在磁盘上的存放位置 -->
    <name>dfs.datanode.data.dir</name>
    <value>/data/hadoop/hdfs/datanode</value>
  </property>
  <property>
    <!--开启 webhdfs 接口访问 -->
    <name>dfs.webhdfs.enabled</name>
    <value>true</value>
  </property>
  <property>
    <!-- 关闭权限验证，hive 可以直连 -->
    <name>dfs.permissions.enabled</name>
    <value>false</value>
  </property>
</configuration>

编辑 /opt/hadoop/etc/hadoop/yarn-site.xml 内容如下：

<?xml version="1.0"?>
<configuration>
  <property>
    <!-- 开启 resourc emanager 高可用 -->
    <name>yarn.resourcemanager.ha.enabled</name>
    <value>true</value>
  </property>
  <property>
    <!-- 指定 resourc emanager 的 cluster id -->
    <name>yarn.resourcemanager.cluster-id</name>
    <value>leo</value>
  </property>
  <property>
    <!-- 指定 resourc emanager 的名字 -->
    <name>yarn.resourcemanager.ha.id</name>
    <value>rm1</value>
  </property>
  <property>
    <!-- 指定 resourc emanager 的名字 -->
    <name>yarn.resourcemanager.ha.rm-ids</name>
    <value>rm1,rm2</value>
  </property>
  <property>
    <!-- 指定 resourc emanager 1 的地址 -->
    <name>yarn.resourcemanager.hostname.rm1</name>
    <value>vm-01</value>
  </property>
  <property>
    <!-- 指定 resourc emanager 2 的地址 -->
    <name>yarn.resourcemanager.hostname.rm2</name>
    <value>vm-02</value>
  </property>
  <property>
    <!-- 指定 zookeeper 集群地址 -->
    <name>yarn.resourcemanager.zk-address</name>
    <value>vm-01:2181,vm-02:2181,vm-03:2181</value>
  </property>
  <property>
    <name>yarn.nodemanager.aux-services</name>
    <value>mapreduce_shuffle</value>
  </property>
</configuration>

编辑 /opt/hadoop/etc/hadoop/mapred-site.xml 内容如下：

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
  <property>
    <name>mapreduce.framework.name</name>
    <value>yarn</value>
  </property>
  <property>
    <name>mapreduce.application.classpath</name>
    <value>
        /opt/Hadoop/share/hadoop/common/*,
        /opt/hadoop/share/hadoop/common/lib/*,
        /opt/hadoop/share/hadoop/hdfs/*,
        /opt/hadoop/share/hadoop/hdfs/lib/*,
        /opt/hadoop/share/hadoop/mapreduce/*,
        /opt/hadoop/share/hadoop/mapreduce/lib/*,
        /opt/hadoop/share/hadoop/yarn/*,
        /opt/hadoop/share/hadoop/yarn/lib/*
    </value>
  </property>
</configuration>

修改 /opt/hadoop/etc/hadoop/hadoop-env.sh 内容如下：

export JAVA_HOME=/opt/jdk
export HADOOP_LOG_DIR=/data/hadoop/logs
export HADOOP_PID_DIR=/data/hadoop/pid

修改 /opt/hadoop/etc/hadoop/yarn-env.sh 内容如下：

export JAVA_HOME=/opt/jdk

在 /opt/hadoop/sbin/start-dfs.sh 和 /opt/hadoop/sbin/stop-dfs.sh 开始位置添加：

HDFS_NAMENODE_USER=leo
HDFS_DATANODE_USER=leo
HDFS_JOURNALNODE_USER=leo
HDFS_ZKFC_USER=leo

在 /opt/hadoop/sbin/start-yarn.sh 和 /opt/hadoop/sbin/stop-yarn.sh 开始位置添加：

YARN_RESOURCEMANAGER_USER=leo
YARN_NODEMANAGER_USER=leo

修改 /opt/hadoop/etc/hadoop/workers 内容如下：

vm-01
vm-02
vm-03

方便起见可以使用 rsync 命令同步 Hadoop：

rsync -auvp /opt/hadoop-3.2.2 leo@vm-02:/opt 
rsync -auvp /opt/hadoop-3.2.2 leo@vm-03:/opt 

启动集群

启动 zookeeper

分别在 vm-01，vm-02 和 vm-03 上执行如下操作：

zkServer.sh start

当所有虚拟机 zookeeper 启动完毕后，执行如下操作：

zkServer.sh status

可能得到如下输出：

ZooKeeper JMX enabled by default
Using config: /opt/zookeeper/bin/../conf/zoo.cfg
Client port found: 2181. Client address: localhost. Client SSL: false.
Mode: leader

或

ZooKeeper JMX enabled by default
Using config: /opt/zookeeper/bin/../conf/zoo.cfg
Client port found: 2181. Client address: localhost. Client SSL: false.
Mode: follower

启动 journalnode

分别在 vm-01，vm-02 和 vm-03 上执行如下操作：

hdfs --daemon start journalnode

格式化 namenode

在 vm-01 上执行如下操作：

hdfs namenode -format

将格式化之后的元数据到其他 namenode：

rsync -auvp /data/hadoop/hdfs/namenode/current vm-01:/data/hadoop/hdfs/namenode/current
rsync -auvp /data/hadoop/hdfs/namenode/current vm-02:/data/hadoop/hdfs/namenode/current

在 vm-01 格式化 zookeeper：

hdfs zkfc -formatZK

停止 journalnode

分别在 vm-01，vm-02 和 vm-03 上执行如下操作：

hdfs --daemon stop journalnode

启动 hadoop

在 vm-01 启动 DFS：

/opt/hadoop/sbin/start-dfs.sh

会得到如下输出：

Starting namenodes on [vm-01 vm-02 vm-03]
Starting datanodes
Starting journal nodes [vm-01 vm-03 vm-02]
Starting ZK Failover Controllers on NN hosts [vm-01 vm-02 vm-03]

在 vm-01 启动 YARN：

/opt/hadoop/sbin/start-yarn.sh

会得到如下输出：

Starting resourcemanagers on [vm-01 vm-02]
Starting nodemanagers

通过 http://vm-01:50070 可以进入 Hadoop Web 页面：

通过 http://vm-01:8088 可以进入 YARN 页面：

2021-06-12 08:00:00

本文以 VirtualBox 和 Ubuntu Server 为例，介绍在 macOS 下搭建 3 台虚拟机集群过程。

安装 VirtualBox

从官网下载最新版本的 VirtualBox 和 VirtualBox Extension Pack，本文以 6.1.22 版本为例。根据安装向导安装 VirtualBox。

双击下载好的 .vbox-extpack 安装文件安装 VirtualBox Extension Pack。

通过 File -> Host Network Manager... 为 VirtualBox 添加一块网卡。

安装 Ubuntu Server

虚拟机配置

从官网下载最新版本的 Ubuntu Server，本文以 20.04.2 LTS 版本为例。在 VirtualBox 通过 New 按钮添加新的虚拟机，首先为虚拟机配置名称，存储路径和内存大小等基本信息：

单击 Create 后为虚拟机配置磁盘类型和大小：

单击 Create 完成创建。创建完毕后，在左侧列表中选择创建好的虚拟机，通过 Settings 按钮打开设置对话框，在 System - Motherboard 标签页去除掉软盘启动 Boot Order - Floppy，同时也可以再次调整内存大小：

在 System - Processor 标签页可以调整虚拟机使用 CPU 的数量：

在 Display - Acceleration 标签页可以调整使用的现存大小：

在 Network - Adapter 1 标签页选择 NAT 网络类型，该网卡用于虚拟机连接外部网络：

在 Network - Adapter 2 标签页选择 Host-only Adapter 网络类型，名称选择上文 VirtualBox 配置的 vboxnet0，该网卡用于虚拟机连接内部网络：

在 Network - Adapter 2 标签页为光驱选择挂载的磁盘镜像：

添加下载好的 Ubuntu Server ISO 磁盘镜像：

Ubuntu Server 安装配置

单击 Start 按钮启动虚拟机，启动后等待片刻，在语言选择页面选择 English：

在键盘布局页面采用默认配置，Done 进入下一步：

在网络配置页面，上文中配置了两块网卡，在此我们需要对于 Host-only Adapter 网卡 enp0s8 进行配置，NAT 网卡 enp0s3 采用默认即可：

进入配置后选择手动 Nanual，在 Subnet 中输入 192.168.56.0/24（参考上文中 VirtualBox 添加的网卡设置），在 Address 中输入 192.168.56.1，在 Gateway 中输入 192.168.56.1，Save 进行保存：

配置完后，结果如下，Done 进入下一步：

在镜像配置页面，根据实际情况选择一个合适的镜像地址，本文采用清华大学的镜像地址 https://mirrors.tuna.tsinghua.edu.cn/ubuntu/，Done 进入下一步：

在存储配置页面，为了方便起见选择使用整个磁盘，Done 进入下一步：

确认磁盘配置信息，Done 进入下一步：

在用户信息配置页面，输入用户名和密码等信息，Done 进入下一步：

在 SSH 配置页面，选择安装 OpenSSH server，Done 进入下一步：

在软件包配置页面，跳过安装，Done 进入下一步：

安装完毕后，Reboot Now 重启虚拟机：

配置 Ubuntu Server

克隆虚拟机

重启后，输入用户名和密码即可进入系统：

通过如下命令更新系统软件到最新版本：

sudo apt update
sudo apt upgrade
sudo apt autoremove

输入以下命令进行关机：

sudo shutdown now

右键单击虚拟机 Ubuntu Server 1，选择 Clone 对虚拟机进行克隆，选择为所有网卡重新生成 MAC 地址，然后单击 Continue：

选择 Full clone 模式，单击 Continue 完成克隆：

配置网络

分别进入虚拟机 2 和 3，修改固定 IP 地址为 191.168.56.102 和 191.168.56.103。

sudo vi /etc/netplan/00-installer-config.yaml

# This is the network config written by 'subiquity'
network:
  ethernets:
    enp0s3:
      dhcp4:true
    enp0s8:
      addresses:
      - 192.168.56.101/24
      gateway4: 192.168.56.1
      nameservers:
        addresses: []
        search: []
  version: 2

将配置文件中 00-installer-config.yaml 的 192.168.56.101 修改为对应的 IP。然后执行：

sudo netplan apply

让配置生效。

为三台虚拟机修改主机名为 vm-01，vm-02 和 vm-03：

sudo hostnamectl set-hostname vm-0x

为三台虚拟机设置 IP 和主机名映射：

sudo vi /etc/hosts

在结尾添加：

# VM
192.168.56.101 vm-01
192.168.56.102 vm-02
192.168.56.103 vm-03

配置 SSH

分别进入三台虚拟机并生成密钥：

ssh-keygen -t rsa

这会在 ~/.ssh 目录生成一对密钥，其中 id_rsa 是私钥，id_rsa.pub 是公钥。

将三台机器中的 id_rsa.pub 导出合并到 ~/.ssh/authorized_keys 文件中，为了方便可以将自己电脑的 id_rsa.pub 也合并到其中实现免密登录。

登录任意每台虚拟机，通过如下命令测试是否可以免密登录：

ssh vm-01
ssh vm-02
ssh vm-03

2021-05-23 08:00:00

在日常工作中，数据处理和分析在研发、产品和运营等多个领域起着重要的作用。在海量数据处理和分析中，SQL 是一项基础且重要的能力。一个优秀的 SQL Boy 和茶树姑的 SQL 代码除了保持简单、可读和易于维护的样式风格外，还需要具备良好的执行性能，准确且高效的计算出结果才能让你在工作中决胜于千里之外。

影响 SQL 执行性能的主要因素可以总结为如下几项：

1. 计算资源量（CPU，内存，网络等）
2. 计算数据量（输入和输出的记录数）
3. 计算复杂度（业务逻辑复杂程度和对应的 SQL 实现和执行）

计算资源量是一个前置制约因素，理论上更多的资源能够带来更快的计算效果。计算数据量也可以认为是一个前置制约因素，理论上更大的数据量会导致计算速度降低，但对于复杂的计算逻辑，通过合理的 SQL 可以更好的控制计算过程中的数据量，从而提升 SQL 性能。计算复杂度是影响 SQL 性能的关键因素，复杂的业务逻辑必然比简单的业务逻辑处理时间要长，相同业务逻辑的不同 SQL 实现也会影响运行效率，这就要求我们对业务逻辑进行全面的理解，对实现 SQL 进行合理优化，从而提升计算速度。

执行引擎

SQL 是用于一种用于数据定义和数据操纵的特定目的的编程语言 ¹。SQL 虽然有 ISO 标准 ²，但大部分 SQL 代码在不同的数据库系统中并不具有完全的跨平台性。不同的执行引擎也会对 SQL 的语法有相应的改动和扩展，同时对于 SQL 的执行也会进行不同的适配和优化。因此，脱离执行引擎的 SQL 性能优化是不可取的。

Hive

Apache Hive 是一个建立在 Hadoop 架构之上的数据仓库。可以将结构化的数据文件映射为一张数据库表，并提供简单的 SQL 查询功能，可以将 SQL 语句转换为 MapReduce 任务进行运行。因此 MapReduce 是 Hive SQL 运行的核心和根基。

我们以 Word Count 为例简单介绍一下 MapReduce 的原理和过程，Word Count 的 MapReduce 处理过程如下图所示：

1. Input：程序的输入数据。
2. Splitting：讲输入数据分割为若干部分。
3. Mapping：针对 Splitting 分割的每个部分，对应有一个 Map 程序处理。本例中将分割后的文本统计成 <K,V> 格式，其中 K 为单词，V 为该单词在这个 Map 中出现的次数。
4. Shuffling：对 Mapping 的相关输出结果进行合并。本例中将具有相同 K 的统计结果合并到一起。
5. Reducing：对 Shuffling 合并的结果进行汇总。本例中讲相同 K 的 V 值进行加和操作并返回单个统计结果。
6. Merged：对 Reducing 的结果进行融合形成最终输出。

Spark

Apache Spark 是一个用于大规模数据处理的统一分析引擎，Spark SQL 则作为 Apache Spark 用于处理结构化数据的模块。

Spark 中常见的概念有：

1. RDD：Resilient Distributed Dataset，弹性分布式数据集，是分布式内存中一个抽象概念，提供了一种高度受限的共享内存模型。
2. DAG：Directed Acyclic Graph，有向无环图，反应了 RDD 之间的依赖关系。
3. Driver Program：控制程序，负责为 Application 创建 DAG，通常用 SparkContext 代表 Driver Program。
4. Cluster Manager：集群管理器，负责分配计算资源。
5. Worker Node：工作节点，负责具体计算。
6. Executor：运行在 Worker Node 上的一个进程，负责运行 Task，并为 Application 存储数据。
7. Application：Spark 应用程序，包含多个 Executor。
8. Task：任务，运行在 Executor 上的工作单元，是 Executor 中的一个线程。
9. Stage：一组并行的 Task，Spark 一般会根据 Shuffle 类算子（例如：reduceByKey 或 join 等）划分 Stage。
10. Job：一组 Stage 的集合，一个 Job 包含多个 RDD 及作用于 RDD 上的操作。

相关概念构成了 Spark 的整体架构，如下图所示：

在 Spark 中，一个任务的执行过程大致分为 4 个阶段，如下图所示：

1. 定义 RDD 的 Transformations 和 Actions 算子 ³，并根据这些算子形成 DAG。
2. 根据形成的 DAG，DAGScheduler 将其划分为多个 Stage，每个 Stage 包含多个 Task。
3. DAGScheduler 将 TaskSet 交由 TaskScheduler 运行，并将执行完毕后的结果返回给 DAGScheduler。
4. TaskScheduler 将任务分发到每一个 Worker 去执行，并将执行完毕后的结果返回给 TaskScheduler。

Spark 相比于 Hadoop 的主要改进有如下几点：

1. Hadoop 的 MapReduce 的中间结果都会持久化到磁盘上，而 Spark 则采用基于内存的计算（内存不足时也可选持久化到磁盘上），从而减少 Shuffle 数据，进而提升计算速度。
2. Spark 采用的 DAG 相比于 Hadoop 的 MapReduce 具有更好的容错性和可恢复性，由于 Spark 预先计算出了整个任务的 DAG，相比于 MapReduce 中各个操作之间是独立的，这更有助于进行全局优化。

Presto

Presto 是一种用于大数据的高性能分布式 SQL 查询引擎。Presto 与 Hive 执行任务过程的差异如下图所示：

Presto 的优点主要有如下几点：

1. 基于内存计算，减少了磁盘 IO，从而计算速度更快。
2. 能够连接多个数据源，跨数据源连表查询。

虽然 Presto 能够处理 PB 级数据，但并不代表 Presto 会把 PB 级别数据都放在内存中计算。而是根据场景，例如 COUNT 和 AVG 等聚合操作，是边读数据边计算，再清理内存，再读取数据计算，这种情况消耗的内存并不高。但是连表查询，可能产生大量的临时数据，从而速度会变慢。

性能调优

本节关于 SQL 性能调优的建议主要针对 Hive，Spark 和 Presto 这类大数据 OLAP 执行引擎设计，其他执行引擎不一定完全适用。

下文性能调优中均以如下两张表为例进行说明：

CREATE TABLE IF NOT EXISTS sku_order
(
  order_id STRING '订单 ID',
  sku_id STRING '商品 ID',
  sale_quantity BIGINT '销售数量' 
)
COMMENT '商品订单表'
PARTITIONED BY
(
  dt STRING COMMENT '日期分区'
)
;

CREATE TABLE IF NOT EXISTS sku_info
(
  sku_id STRING '商品 ID',
  sku_name STRING '商品名称',
  category_id STRING '品类 ID',
  category_name STRING '品类名称'
)
COMMENT '商品信息表'

减少数据量

• 限定查询分区。对于包含分区的数据表（例如：日期分区），通过合理限定分区来减少数据量，避免全表扫描。
• 限定查询字段。避免使用 SELECT *，仅选择需要的字段。SELECT * 会通过查询元数据获取字段信息，同时查询所有字段会造成更大的网络开销。
• 在关联前过滤数据。应在进行数据表关联之前按照业务逻辑进行数据过滤，从而提升执行效率。

数据倾斜

在 Shuffle 阶段，需要将各节点上相同的 Key 拉取到某个节点（Task）上处理，如果某个 Key 对应的数据量特别大则会产生数据倾斜。结果就是该 Task 运行的时间要远远大于其他 Task 的运行时间，从而造成作业整体运行缓慢，数据量过大甚至可能导致某个 Task 出现 OOM。

在 SQL 中主要有如下几种情况会产生数据倾斜：

• JOIN 导致的数据倾斜：两表关联，关联字段的无效值（例如：NULL）或有效值过多，可能会导致数据倾斜。
• GROUP BY 导致的数据倾斜：当 GROUP BY 的字段（或字段组合）中，Key 分布不均，可能会导致数据倾斜。
• DISTINCT 导致的数据倾斜：当 DISTINCT 的字段（或字段组合）中，Key 分布不均，可能会导致数据倾斜。

对于不同的数据倾斜情况，解决方案如下：

• 对于 JOIN 中的无效值进行过滤。

  SELECT
    category_name,
    SUM(sale_quantity) AS sale_quantity
  FROM
    (
      SELECT
        sku_id,
        sale_quantity
      FROM
        sku_order
      WHERE
        dt = '20210523'
        AND sku_id IS NOT NULL
    ) AS sku_order_filtered
  LEFT JOIN
    sku_info
  ON
    sku_order_filtered.sku_id = sku_info.sku_id
  GROUP BY
    category_name
  ;
  

• 对于 JOIN 开启 Map Join 或 Broadcast Join 策略，将小表广播到每个 Executor 上来避免产生 Shuffle，从而使得 JOIN 能够快速完成。

set spark.sql.autoBroadcastJoinThreshold=10485760;

• 对于 JOIN 中存在数据倾斜的 KEY 进行打散处理。

  SELECT
    category_name,
    SUM(sale_quantity) AS sale_quantity
  FROM
    (
      SELECT
        IF(sku_id IN (0000, 9999), CONCAT(sku_id, '_', CEIL(RAND() * 10)), sku_id) AS sku_id,
        sale_quantity
      FROM
        sku_order
      WHERE
        dt = '20210523'
    ) AS sku_order_modified
  LEFT JOIN
    (
      SELECT
        sku_id,
        category_name,
      FROM
        sku_info
      WHERE
        sku_id NOT IN (0000, 9999)
      UNION ALL
      SELECT
        CONCAT(sku_id, '_', suffix) AS sku_id,
        category_name
      FROM
        (
          SELECT
            sku_id,
            SPLIT('1,2,3,4,5,6,7,8,9,10', ',') AS suffix_list,
            category_name
          FROM
            sku_info
          WHERE
            sku_id IN (0000, 9999)
        ) sku_info_tmp LATERAL VIEW EXPLODE(suffix_list) sku_info_suffix AS suffix
    ) sku_info_all
  ON
    sku_order_modified.sku_id = sku_info_all.sku_id
  GROUP BY
    category_name
  ;
  

• 对于 GROUP BY 导致的数据倾斜采用两步聚合。

  SELECT
    IF(sku_is_null = 1, NULL, sku_id) AS sku_id,
    SUM(sale_quantity) AS sale_quantity
  FROM
    (
      SELECT
        sku_id,
        sku_is_null,
        SUM(sale_quantity) AS sale_quantity
      FROM
      (
        SELECT
          IF(sku_id IS NULL, CONCAT(sku_id, CEIL(RAND() * 10)), sku_id) AS sku_id,
          IF(sku_id IS NULL, 1, 0) AS sku_is_null,
          sale_quantity
        FROM
          sku_order
        WHERE
          dt = '20210523'
      ) sku_order_modified
      GROUP BY
        sku_id,
        sku_is_null
    ) sku_order_group
  GROUP BY
    IF(sku_is_null = 1, NULL, sku_id)
  ;
  

• 对于 DISTINCT 导致的数据倾斜，可以改写为 GROUP BY 实现，从而通过多个 Task 计算避免数据倾斜。

  /* COUNT DISTINCT */
  SELECT
    COUNT(DISTINCT sku_id) AS cnt
  FROM
    sku_order
  WHERE
    dt = '20210523'
  ;
  
  /* GROUP BY */
  SELECT
    COUNT(1) AS cnt
  FROM
    (
      SELECT
        sku_id
      FROM
        sku_order
      WHERE
        dt = '20210523'
      GROUP BY
        sku_id
    ) AS sku_stats
  ;
  

其他建议

• 使用 Common Table Expressions (CTEs) 而非子查询。WITH 语句产生的结果类似临时表，可以重复使用，从而避免相同逻辑业务重复计算。

• 使用 LEFT SEMI JOIN 而非 IN 和子查询。Hive 在 0.13 后的版本中才在 IN 和 NOT IN 中支持子查询。

  /* BAD */
  SELECT
    order_id,
    sku_id,
    sale_quantity
  FROM
    sku_order
  WHERE
    sku_id IN (SELECT sku_id FROM sku_info)
  ;
  
  /* GOOD */
  SELECT
    order_id,
    sku_id,
    sale_quantity
  FROM
    sku_order
  LEFT SEMI JOIN
    sku_info
  ON
    sku_order.sku_id = sku_info.sku_id
  ;
  

参数调优

除了 SQL 本身逻辑的优化外，执行引擎的相关参数设置也会影响 SQL 的执行性能。本小节以 Spark 引擎为例，总结相关参数的设置及其影响。

动态分区

/* 以下 Hive 参数对 Spark 同样有效 */

/* 是否启用动态分区功能 */
set hive.exec.dynamic.partition=true;

/* strict 表示至少需要指定一个分区，nonstrict 表示可以全部动态指定分区 */
set hive.exec.dynamic.partition.mode=nonstrict;

/* 动态生成分区的最大数量 */
set hive.exec.max.dynamic.partitions=1000;

资源申请

/* 每个 Executor 中的核数 */
set spark.executor.cores=2;

/* Executor 的内存总量。YARN 中 Container 的内存限制为 spark.executor.memory + spark.yarn.executor.memoryOverhead <= 16G。 */
set spark.executor.memory=4G;

/* Executor 的堆外内存大小，由 YARN 控制，单位为 MB。YARN 中 Container 的内存限制为 spark.executor.memory + spark.yarn.executor.memoryOverhead <= 16G。 */
set spark.yarn.executor.memoryOverhead=1024;

/* Driver 的内存总量，主要用于存放任务执行过程中 Shuffle 元数据，以及任务中 Collect 的数据，Broadcast 的小表也会先存放在 Driver 中。YARN 中 Container 的内存限制为 spark.executor.memory + spark.yarn.executor.memoryOverhead <= 16G。 */
set spark.driver.memory=8G;

/* Driver 的堆外内存，由 YARN 控制，单位为 MB。YARN 中 Container 的内存限制为 spark.executor.memory + spark.yarn.executor.memoryOverhead <= 16G。 */
set spark.yarn.driver.memoryOverhead=1024;

/* storage memory + execution memory 占总内存（java heap-reserved memory）的比例。executor jvm 中内存分为 storage、execution 和 other 内存。storage 存放缓存 RDD 数据，execution 存放 Shuffle 过程的中间数据，other 存放用户定义的数据结构或 Spark 内部元数据。如果用户自定义数据结构较少，可以将该参数比例适当上调。 */
set spark.memory.fraction=0.7;

动态分配

开启动态分配，Spark 可以根据当前作业负载动态申请和释放资源：

set spark.dynamicAllocation.enabled=true;

同时需要设置同一时刻可以申请的最小和最大 Executor 数量：

set spark.dynamicAllocation.minExecutors=10;
set spark.dynamicAllocation.maxExecutors=100;

小文件合并

/* 小文件合并阈值，如果生成的文件平均大小低于阈值会额外启动一轮 Stage 进行小文件的合并，默认不合并小文件。 */
set spark.sql.mergeSmallFileSize=67108864;

/* 	设置额外的合并 Job 时的 Map 端输入大小 */
set spark.sql.targetBytesInPartitionWhenMerge=67108864;

/* 设置 Map 端输入的合并文件大小 */
set spark.hadoopRDD.targetBytesInPartition=67108864;

在决定一个目录是否需要合并小文件时，会统计目录下的平均大小，然后和 spark.sql.mergeSmallFileSize 比较。在合并文件时，一个 Map Task 读取的数据量取决于下面三者的较大值：spark.sql.mergeSmallFileSize，spark.sql.targetBytesInPartitionWhenMerge，spark.hadoopRDD.targetBytesInPartition。

Shuffle 相关

当大表 JOIN 小表时，如果小表足够小，可以将小表广播到所有 Executor 中，在 Map 阶段完成 JOIN。如果该值设置太大，容易导致 Executor 出现 OOM。

/* 10 * 1024 * 1024, 10MB */
set spark.sql.autoBroadcastJoinThreshold=10485760;

设置 Reduce 阶段的分区数：

set spark.sql.shuffle.partitions=1000;

设置过大可能导致很多 Reducer 同时向一个 Mapper 拉取数据，导致 Mapper 由于请求压力过大而挂掉或响应缓慢，从而 fetch failed。

一些其他 Shuffle 相关的配置如下：

/* 同一时刻一个 Reducer 可以同时拉取的数据量大小 */
set spark.reducer.maxSizeInFlight=25165824;

/* 同一时刻一个 Reducer 可以同时产生的请求数 */
set spark.reducer.maxReqsInFlight=10;

/* 同一时刻一个 Reducer 向同一个上游 Executor 拉取的最多 Block 数 */
set spark.reducer.maxBlocksInFlightPerAddress=1;

/* Shufle 请求的 Block 超过该阈值就会强制落盘，防止一大堆并发请求将内存占满 */
set spark.reducer.maxReqSizeShuffleToMem=536870911;

/* Shuffle 中连接超时时间，超过该时间会 fetch failed */
set spark.shuffle.io.connectionTimeout=120;

/* Shuffle 中拉取数据的最大重试次数 */
set spark.shuffle.io.maxRetries=3;

/* Shuffle 重试的等待间隔 */
set spark.shuffle.io.retryWait=5;

ORC 相关

ORC 文件的格式如下图所示：

其中，Postscript 为文件描述信息，包括 File Footer 和元数据长度、文件版本、压缩格式等；File Footer 是文件的元数据信息，包括数据量、每列的统计信息等；文件中的数据为 Stripe，每个 Stripe 包括索引数据、行数据和 Stripe Footer。更多有关 ORC 文件格式的信息请参见 ORC Specification v1 。

在读取 ORC 压缩表时，可以控制生成 Split 的策略，包括：

• BI：以文件为力度进行 Split 划分
• ETL：将文件进行切分，多个 Stripe 组成一个 Split
• HYBRID：当文件的平均大小大于 Hadoop 最大 Split 值时使用 ETL 策略，否则使用 BI 策略

对于一些较大的 ORC 表，可能其 Footer 较大，ETL 策略可能会导致从 HDFS 拉取大量的数据来切分 Split，甚至会导致 Driver 端 OOM，因此这类表的读取建议采用 BI 策略。对于一些较小，尤其是有数据倾斜的表（即大量 Stripe 存储于少数文件中），建议使用 ETL 策略。

一些其他 ORC 相关的配置如下：

/* ORC 谓词下推，默认是关闭 */
set spark.sql.orc.filterPushdown=true;

/* 	开启后，在 Split 划分时会使用 Footer 信息 */
set spark.sql.orc.splits.include.file.footer=true;

/* 设置每个 Stripe 可以缓存的大小 */
set spark.sql.orc.cache.stripe.details.size=10000;

/* 当为 true 时，Spark SQL 的谓语将被下推到 Hive Metastore 中，更早的消除不匹配的分区。 */
set spark.sql.hive.metastorePartitionPruning=true;

/* 读 ORC 表时，设置小文件合并的阈值，低于该值的 Split 会合并在一个 Task 中执行 */
set spark.hadoop.mapreduce.input.fileinputformat.split.minsize=67108864;

/* 读 ORC 表时，设置一个 Split 的最大阈值，大于该值的 Split 会切分成多个 Split。 */
set spark.hadoop.mapreduce.input.fileinputformat.split.maxsize=268435456;

/* 文件提交到HDFS上的算法：1. version=1 是按照文件提交。2. version=2 是批量按照目录进行提交，可以极大节约文件提交到 HDFS 的时间，减轻 NameNode 压力。 */
set spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version=2;

自适应执行

/* 开启动态执行 */
set spark.sql.adaptive.enabled=true;

当自适应执行开启后，调整 spark.sql.adaptive.shuffle.targetPostShuffleInputSize，当 Mapper 端两个 Partition 的数据合并后小于该值时，Spark 会将两个 Partition 合并到一个 Reducer 进行处理。

set spark.sql.adaptive.shuffle.targetPostShuffleInputSize=67108864;

当自适应执行开启后，有时会导致过多分区被合并，为了防止分区过少影响性能，可以设置如下参数：

set spark.sql.adaptive.minNumPostShufflePartitions=10;

一些其他自适应执行相关的配置如下：

/* 开启动态调整 Join */
set spark.sql.adaptive.join.enabled=true;

/* 设置 SortMergeJoin 转 BroadcastJoin 的阈值，如果不设置该参数，该阈值和 spark.sql.autoBroadcastJoinThreshold 值相等。 */
set spark.sql.adaptiveBroadcastJoinThreshold=33554432;

/* 是否允许为了优化 Join 而增加 Shuffle，默认是 false */
set spark.sql.adaptive.allowAddititionalShuffle=false;

/* 开启自动处理 Join 时的数据倾斜 */
set spark.sql.adaptive.skewedJoin.enabled=true;

/* 控制处理一个倾斜 Partition 的 Task 个数上限，默认值是 5 */
set spark.sql.adaptive.skewedPartitionMaxSplits=100;

/* 设置一个 Partition 被视为倾斜 Partition 的行数下限，行数低于该值的 Partition 不会被当做倾斜 Partition 处理。 */
set spark.sql.adaptive.skewedPartitionRowCountThreshold=10000000;

/* 设置一个 Partition 被视为倾斜 Partition 的大小下限，大小小于该值的 Partition 不会被当做倾斜 Partition 处理。 */
set spark.sql.adaptive.skewedPartitionSizeThreshold=536870912;

/* 设置倾斜因子，当一个 Partition 满足以下两个条件之一，就会被视为倾斜 Partition：1. 大小大于 spark.sql.adaptive.skewedPartitionSizeThreshold 的同时大于各 Partition 大小中位数与该因子的乘积。2. 行数大于 spark.sql.adaptive.skewedRowCountThreshold 的同时大于各 Partition 行数中位数与该因子的乘积。*/
set spark.sql.adaptive.skewedPartitionFactor=10;

推测执行

/* Spark 推测执行开关，默认是 true */
set spark.speculation=true;

/* 开启推测执行后，每隔该值时间会检测是否有需要推测执行的 Task */
set spark.speculation.interval=1000ms;

/* 当成功 Task 占总 Task 的比例超过 spark.speculation.quantile，统计成功 Task 运行时间中位数乘以 spark.speculation.multiplier 得到推测执行阈值，当在运行的任务超过这个阈值就会启动推测执行。当资源充足时，可以适当减小这两个值。 */
set spark.speculation.quantile=0.99;
set spark.speculation.multiplier=3;

2021-05-04 08:00:00

代码样式指南主要用于规范项目中代码的一致性，使得代码简单、可读和易于维护，从一定程度上也影响代码的质量。一句话概括如何评价代码的质量：

衡量代码质量的唯一有效标准：WTF/min – Robert C. Martin

Google 针对大多数编程语言（例如：C/C++，Java，JavaScript，Python，R 等）都整理了相关的代码风格，但对于 SQL 这种用于数据库查询特殊目的的编程语言并没有整理对应的风格。同其他编程语言代码风格一样，没有哪种风格是最好的，只要在项目中采用统一合理的风格即可。

本文参考的 SQL 样式指南有如下几种：

1. https://www.sqlstyle.guide/zh/
2. https://about.gitlab.com/handbook/business-technology/data-team/platform/sql-style-guide/
3. https://docs.telemetry.mozilla.org/concepts/sql_style.html
4. https://github.com/mattm/sql-style-guide

本文给出的 SQL 样式指南基于上述几种进行整理和修改。

一般原则

• 使用一致的、描述性名称。
• 使用空格（2 个或 4 个，项目中保持一致），避免使用 TAB 缩进。
• 在 SQL 中加入必要的注释，块注释使用 /* */，行注释使用 --，并在末尾换行。
• 使用单引号 ' 作为被引号包裹的标识符。
• 运算符前后添加空格，逗号 , 后添加空格，避免行尾有空格。
• 每行代码不超过 80 个字符。

命名惯例

• 避免名称和保留字一样。
• 关键词、函数名称采用大写，字段名、表名采用小蛇式（lower snake case）命名。
• 名称要以字母开头，不能以下划线结尾，名称中仅可以使用字母、数字和下划线。
• 不要在名字中出现连续下划线 __，这样很难辨认。
• 尽量避免使用缩写词。使用时一定确定这个缩写简明易懂。
• 字段名总是使用单数。

对齐和换行

• 避免川流式对齐代码。

  /* Good */
  SELECT id
  FROM table_name
  WHERE column = "test"
  ;
  

  /* Bad */
  SELECT id
    FROM talbe_name
   WHERE column = "test"
  ;
  

• 多个元素组合无法呈现在一行中时，应将第一个元素另起一行。

  /* Good */
  SELECT
    CASE postcode
      WHEN 'BN1' THEN 'Brighton'
      WHEN 'EH1' THEN 'Edinburgh'
    END AS city
  FROM table_name
  ;
  

  /* Bad */
  SELECT
    CASE postcode WHEN 'BN1' THEN 'Brighton'
                  WHEN 'EH1' THEN 'Edinburgh'
    END AS city
  FROM table_name
  ;
  

• 由括号构成的多行，结尾括号应单独一行。

  /* Good */
  SELECT id
  FROM table_name
  WHERE postcode IN (
    'looooooooooooooooooooooooong_BN1',
    'loooooooooooooooooooooooooog_EH1'
  )
  

  /* Bad */
  SELECT id
  FROM table_name
  WHERE postcode IN ('looooooooong_BN1',
                     'looooooooong_EH1')
  

• 多行采用右侧逗号和左侧关键字连接。

  /* Good */
  SELECT
    id,
    name
  FROM
    talbe_name
  WHERE
    id > 1
    AND name LIKE "%Tom%"
  ;
  

  /* Bad */
  SELECT
    id
    , name
  FROM
    table_name
  WHERE
    id > 1 AND
    name LIKE "%Tom%"
  ;
  

• 根关键词建议单独一行，多个参数单独一行。

  /* Good */
  SELECT
    id,
    name
  FROM
    table_name
  WHERE
    id > 1
    AND name LIKE "%Tom%"
  LIMIT
    10
  ;
  

  /* Acceptable */
  SELECT
    id,
    name
  FROM table_name
  WHERE
    id > 1
    AND name LIKE "%Tom%"
  LIMIT 10
  ;
  

  /* Bad */
  SELECT id, name
  FROM table_name
  WHERE
    id > 1
    AND name LIKE "%Tom%"
  LIMIT 10
  ;
  

明确指定

• 使用 AS 明确指定别名，而非隐式。

  /* Good */
  SELECT
    table_name_1.id AS user_id,
    table_name_2.name AS user_name
  FROM
    looooooooong_table_name_1 AS table_name_1
  LEFT JOIN
    looooooooong_table_name_2 AS table_name_2
  ON
    table_name_1.id = table_name_2.id
  ;
  

  /* Bad */
  SELECT
    table_name_1.id user_id,
    table_name_2.name user_name
  FROM
    looooooooong_table_name_1 table_name_1
  LEFT JOIN
    looooooooong_table_name_2 table_name_2
  ON
    table_name_1.id = table_name_2.id
  ;
  

• 避免使用隐式关联。

  /* Good */
  SELECT
    table_name_1.id,
    table_name_2.name
  FROM
    table_name_1
  INNER JOIN
    table_name_2
  ON
    table_name_1.id = table_name_2.id
  ;
  

  /* Bad */
  SELECT
    table_name_1.id,
    table_name_2.name
  FROM
    table_name_1,
    table_name_2
  ON
    table_name_1.id = table_name_2.id
  ;
  

• 明确关联类型。

  /* Good */
  SELECT
    table_name_1.id,
    table_name_2.name
  FROM
    table_name_1
  INNER JOIN
    table_name_2
  ON
    table_name_1.id = table_name_2.id
  ;
  

  /* Bad */
  SELECT
    table_name_1.id,
    table_name_2.name
  FROM
    table_name_1
  JOIN
    table_name_2
  ON
    table_name_1.id = table_name_2.id
  ;
  

• 明确指定分组列。

  /* Good */
  SELECT
    submission_date,
    normalized_channel IN ('nightly', 'aurora', 'beta') AS is_prerelease,
    COUNT(*) AS count
  FROM
    telemetry.clients_daily
  WHERE
    submission_date > '2019-07-01'
  GROUP BY
    submission_date,
    is_prerelease
  ;
  

  /* Bad */
  SELECT
    submission_date,
    normalized_channel IN ('nightly', 'aurora', 'beta') AS is_prerelease,
    COUNT(*) AS count
  FROM
    telemetry.clients_daily
  WHERE
    submission_date > '2019-07-01'
  GROUP BY
    1, 2
  ;
  

子查询

• 尽量使用 Common Table Expressions (CTEs) 而非子查询。

  /* Good */
  WITH sample AS (
    SELECT
      client_id,
      submission_date
    FROM
      main_summary
    WHERE
      sample_id = '42'
  )
  
  SELECT *
  FROM sample
  LIMIT 10
  

  /* Bad */
  SELECT *
  FROM (
    SELECT
      client_id,
      submission_date
    FROM
      main_summary
    WHERE
      sample_id = '42'
  )
  LIMIT 10
  

• 尽量在 CTEs 中处理查询而非主语句中。

  /* Good */
  WITH backings_per_category AS (
    SELECT
      ...
  ), backers AS (
    SELECT
      backings_per_category.backer_id,
      COUNT(backings_per_category.id) AS projects_backed_per_category
    INNER JOIN ksr.users AS users ON users.id = backings_per_category.backer_id
    GROUP BY backings_per_category.backer_id
  ), backers_and_creators AS (
    ...
  )
  SELECT * FROM backers_and_creators;
  

  /* Bad */
  WITH backings_per_category AS (
    SELECT
      ...
  ), backers AS (
    SELECT
      backer_id,
      COUNT(backings_per_category.id) AS projects_backed_per_category
  ), backers_and_creators AS (
    ...
  )
  SELECT *
  FROM backers_and_creators
  INNER JOIN backers
  ON backers_and_creators
  ON backers.backer_id = backers_and_creators.backer_id
  

其他

• 尽量使用 != 而不是 <> 表示不等于。
• 尽量使用 BETWEEN 而不是多个 AND 语句。
• 尽量使用 IN() 而不是多个 OR 语句。
• 尽量避免使用 SELECT *。
• 尽量避免使用无意义的别名，例如：a, b, c。

2021-04-03 08:00:00

理论篇请参见：进程，线程和协程 (Process, Thread and Coroutine) - 理论篇

本文将介绍进程，线程和协程在 Python 中的实现，代码详见这里，部分参考自「Python 并发编程」 ¹:。

进程和线程

在 Python 中可以使用 multiprocessing.Process 和 threading.Thread 来实现进程和线程。我们采用CPU 密集型、磁盘 IO 密集型、网络 IO 密集型和模拟 IO 密集型任务类型来测试单线程，多线程和多进程之间的性能差异。

import requests

# CPU 密集型
def cpu_bound_task(x=1, y=1):
    c = 0

    while c < 1500000:
        c += 1
        x += x
        y += y

# 磁盘 IO 密集型
def disk_io_bound_task():
    with open('tmp.log', 'w') as f:
        for idx in range(5000000):
            f.write('{}\n'.format(idx))

# 网络 IO 密集型
def web_io_bound_task():
    try:
        requests.get('https://www.baidu.com')
    except Exception as e:
        pass

# 模拟 IO 密集型
def simulation_io_bound_task():
    time.sleep(2)

为了方便统计运行时间，定义如下一个运行时间装饰器：

import time

def timer(task_mode):
    def wrapper(func):
        def decorator(*args, **kwargs):
            task_type = kwargs.setdefault('task_type', None)
            start_time = time.time()
            func(*args, **kwargs)
            end_time = time.time()
            print('耗时（{} - {}）: {}'.format(
                task_mode, task_type, end_time - start_time))
        return decorator
    return wrapper

单线程，多线程和多进程的测试代码如下：

from threading import Thread
from multiprocessing import Process

@timer('单线程')
def single_thread(func, task_type='', n=10):
    for idx in range(n):
        func()


@timer('多线程')
def multi_threads(func, task_type='', n=10):
    threads = {}

    for idx in range(n):
        t = Thread(target=func)
        threads[idx] = t
        t.start()

    for thread in threads.values():
        thread.join()


@timer('多进程')
def multi_processes(func, task_type='', n=10):
    processes = {}

    for idx in range(n):
        p = Process(target=func)
        processes[idx] = p
        p.start()

    for process in processes.values():
        process.join()

运行测试

# 单线程
single_thread(cpu_bound_task, task_type='CPU 密集型任务')
single_thread(disk_io_bound_task, task_type='磁盘 IO 密集型任务')
single_thread(web_io_bound_task, task_type='网络 IO 密集型任务')
single_thread(simulation_io_bound_task, task_type='模拟 IO 密集型任务')

# 多线程
multi_threads(cpu_bound_task, task_type='CPU 密集型任务')
multi_threads(disk_io_bound_task, task_type='磁盘 IO 密集型任务')
multi_threads(web_io_bound_task, task_type='网络 IO 密集型任务')
multi_threads(simulation_io_bound_task, task_type='模拟 IO 密集型任务'

# 多进程
multi_processes(cpu_bound_task, task_type='CPU 密集型任务')
multi_processes(disk_io_bound_task, task_type='磁盘 IO 密集型任务')
multi_processes(web_io_bound_task, task_type='网络 IO 密集型任务')
multi_processes(simulation_io_bound_task, task_type='模拟 IO 密集型任务')

可以得到类似如下的结果：

从测试结果来看，不难得出如下结论：

1. 多线程和多进程相比单线程速度整体上有很大提升。
2. 对于 CPU 密集型任务，由于 GIL 加锁和释放问题，多线程相比单线程更慢。
3. 多线程更适合在 IO 密集场景下使用，例如：爬虫等。
4. 多进程更适合在 CPU 密集场景下使用，例如：大数据处理，机器学习等。

创建线程有两种方式：

利用函数创建线程

Python 中的 threading.Thread() 接受两个参数：线程函数，用于指定线程执行的函数；线程函数参数，以元组的形式传入执行函数所需的参数。

import time
from threading import Thread

# 自定义函数
def func(name='Python'):
    for idx in range(2):
        print('Hello, {}'.format(name))
        time.sleep(1)

# 创建线程
thread_1 = Thread(target=func)
thread_2 = Thread(target=func, args=('Leo', ))

# 启动线程
thread_1.start()
thread_2.start()

可以得到如下输出：

Hello, Python
Hello, Leo
Hello, Python
Hello, Leo

利用类创建线程

利用类创建线程需要自定义一个类并继承 threading.Thread 这个父类，同时重写 run 方法。最后通过实例化该类，并运行 start() 方法执行该线程。

# 自定义类
class MyThread(Thread):
    def __init__(self, name='Python'):
        super(MyThread, self).__init__()
        self.name = name

    def run(self):
        for idx in range(2):
            print('Hello, {}'.format(self.name))
            time.sleep(1)

# 创建线程
thread_1 = MyThread()
thread_2 = MyThread('Leo')

# 启动线程
thread_1.start()
thread_2.start()

可以得到同上面一样的输出：

Hello, Python
Hello, Leo
Hello, Python
Hello, Leo

线程的一些常用方法和属性如下所示：

# 创建线程
t = Thread(target=func)

# 启动线程
t.start()

# 阻塞线程
t.join()

# 判断线程是否处于执行状态
# True: 执行中，False: 其他
t.is_alive()

# 这是线程是否随主线程退出而退出
# 默认为 False
t.daemon = True

# 设置线程名称
t.name = 'My Thread'

锁

在一段代码中加锁表示同一时间有且仅有一个线程可以执行这段代码。在 Python 中锁分为两种：互斥锁和可重入锁。利用 threading.Lock() 可以获取全局唯一的锁对象，使用 acquire() 和 release() 方法可以获取和释放锁，注意两个需成对出现，否则可能造成死锁。

互斥锁

例如定义两个函数，并在两个线程中执行，这两个函数共用一个变量 C：

import time
import random

from threading import Thread

# 共用变量
C = 0

def job1(n=10):
    global C

    for idx in range(n):
        C += 1
        print('Job1: {}'.format(C))

def job2(n=10):
    global C

    for idx in range(n):
        C += 10
        print('Job2: {}'.format(C))

t1 = Thread(target=job1)
t2 = Thread(target=job2)

t1.start()
t2.start()

运行结果如下：

Job1: 1
Job2: 11
Job2: 21
Job1: 22
Job1: 23
Job2: 33
Job2: 43
Job1: 44
Job2: 54
Job1: 55
Job2: 65
Job1: 66
Job2: 76
Job2: 86
Job1: 87
Job1: 88
Job2: 98
Job1: 99
Job2: 109
Job1: 110

两个线程共用一个全局变量，两个线程根据自己执行的快慢对变量 C 进行修改。在增加锁后：

import time
import random

from threading import Lock

# 全局唯一锁
LOCK = Lock()

# 共用变量
C = 0

def job1_with_lock(n=10):
    global C, LOCK

    LOCK.acquire()

    for idx in range(n):
        C += 1
        print('Job1: {}'.format(C))
        time.sleep(random.random())

    LOCK.release()


def job2_with_lock(n=10):
    global C, LOCK

    LOCK.acquire()

    for idx in range(n):
        C += 10
        print('Job2: {}'.format(C))
        time.sleep(random.random())

    LOCK.release()

t1 = Thread(target=job1_with_lock)
t2 = Thread(target=job2_with_lock)

t1.start()
t2.start()

运行结果如下：

Job1: 1
Job1: 2
Job1: 3
Job1: 4
Job1: 5
Job1: 6
Job1: 7
Job1: 8
Job1: 9
Job1: 10
Job2: 20
Job2: 30
Job2: 40
Job2: 50
Job2: 60
Job2: 70
Job2: 80
Job2: 90
Job2: 100
Job2: 110

此时，由于 job1_with_lock 先拿到了锁，所以当执行时 job2_with_lock 无法获取到锁，就无法对 C 进行修改。只有当 job1_with_lock 执行完毕释放锁后，job2_with_lock 才能执行对 C 的修改操作。为了避免忘记释放锁，可以使用 with 上下文管理器来加锁。

可重入锁

在同一个线程中，我们可能会多次请求同一个资源，这称为嵌套锁。如果使用常规的方式：

from threading import Lock

def lock_with_lock(n=10):
    c = 0
    lock = Lock()

    with lock:
        for idx in range(n):
            c += 1
            with lock:
                print(c)

t = Thread(target=lock_with_lock)
t.start()

则无法正常运行，因为第二次获取锁时，锁已经被同一线程获取，从而无法运行后续代码。由于后续代码无法运行则无法释放锁，从而上述的嵌套锁会造成死锁。

为了解决这个问题，threading 模块提供了可重入锁 RLock：

from threading import RLock

def rlock_with_lock(n=10):
    c = 0
    lock = RLock()

    with lock:
        for idx in range(n):
            c += 1
            with lock:
                print(c)
  
t = Thread(target=rlock_with_lock)
t.start()

运行结果如下：

1
2
3
4
5
6
7
8
9
10

全局解释器锁

全局解释器锁（Global Interpreter Lock，GIL），是计算机程序设计语言解释器用于同步线程的一种机制，它使得任何时刻仅有一个线程在执行。

任何 Python 线程执行前，必须先获得 GIL 锁，然后，每执行 100 条字节码，解释器就自动释放 GIL 锁，让别的线程有机会执行。这个 GIL 全局锁实际上把所有线程的执行代码都给上了锁，所以，多线程在 Python 中只能交替执行，即使 100 个线程跑在 100 核 CPU 上，也只能用到 1 个核。

通信

Python 中实现线程中通信有如下 3 中方法：

Event 事件

threading.Event 可以创建一个事件变量，多个线程等待这个事件的发生，在事件发生后，所有线程继续运行。threading.Event 包含如下三个函数：

event = threading.Event()

# 重置 event，使得所有该 event 事件都处于待命状态
event.clear()

# 等待接收 event 的指令，决定是否阻塞程序执行
event.wait()

# 发送 event 指令，使所有设置该 event 事件的线程执行
event.set()

例如：

import time

from threading import Thread, Event

class EventThread(Thread):
    def __init__(self, name, event):
        super(EventThread, self).__init__()

        self.name = name
        self.event = event

    def run(self):
        print('线程 {} 启动于 {}'.format(self.name, time.ctime(time.time())))
        self.event.wait()
        print('线程 {} 结束于 {}'.format(self.name, time.ctime(time.time())))

threads = {}
event = Event()

for tid in range(3):
    threads[tid] = EventThread(str(tid), event)

event.clear()

for thread in threads.values():
    thread.start()

print('等待 3 秒钟 ...')
time.sleep(3)

print('唤醒所有线程 ...')
event.set() 

运行结果如下：

线程 0 启动于 Thu Apr  1 23:12:32 2021
线程 1 启动于 Thu Apr  1 23:12:32 2021
线程 2 启动于 Thu Apr  1 23:12:32 2021
等待 3 秒钟 ...
唤醒所有线程 ...
线程 0 结束于 Thu Apr  1 23:12:35 2021
线程 1 结束于 Thu Apr  1 23:12:35 2021
线程 2 结束于 Thu Apr  1 23:12:35 2021

可见线程启动后并未执行完成，而是卡在了 event.wait() 处，直到通过 event.set() 发送指令后，所有线程才继续向下执行。

Condition

threading.Condition 与 threading.Event 类似，包含如下 4 个函数：

cond = threading.Condition()

# 类似 lock.acquire()
cond.acquire()

# 类似 lock.release()
cond.release()

# 等待指定触发，同时会释放对锁的获取,直到被 notify 才重新占有琐。
cond.wait()

# 发送指定，触发执行
cond.notify()

以一个捉迷藏的游戏为例：

import time

from threading import Thread, Condition

class Seeker(Thread):
    def __init__(self, condition, name):
        super(Seeker, self).__init__()

        self.condition = condition
        self.name = name

    def run(self):
        time.sleep(1) # 确保先运行 Hider 中的方法

        self.condition.acquire()

        print('{}: 我把眼睛蒙好了'.format(self.name))
        self.condition.notify()
        self.condition.wait()
        print('{}: 我找到你了'.format(self.name))
        self.condition.notify()

        self.condition.release()
        print('{}: 我赢了'.format(self.name))


class Hider(Thread):
    def __init__(self, condition, name):
        super(Hider, self).__init__()

        self.condition = condition
        self.name = name

    def run(self):
        self.condition.acquire()

        self.condition.wait()
        print('{}: 我藏好了'.format(self.name))
        self.condition.notify()
        self.condition.wait()
        self.condition.release()
        print('{}: 被你找到了'.format(self.name))

condition = Condition()

seeker = Seeker(condition, 'Seeker')
hider = Hider(condition, 'Hider')

seeker.start()
hider.start()

运行结果如下：

Seeker: 我把眼睛蒙好了
Hider: 我藏好了
Seeker: 我找到你了
Seeker: 我赢了
Hider: 被你找到了

可见通过 cond.wait() 和 cond.notify() 进行阻塞和通知可以实现双方动作交替进行。

Queue 队列

从一个线程向另一个线程发送数据最安全的方式是使用 queue 库中的队列。创建一个被多个线程共享的队列对象，通过 put() 和 get() 方法向队列发送和获取元素。队列的常用方法如下：

from queue import Queue

# maxsize=0 表示不限大小
# maxsize>0 且消息数达到限制时，put() 方法会阻塞
q = Queue(maxsize=0)

# 默认阻塞程序，等待队列消息，可设置超时时间
q.get(block=True, timeout=None)

# 发送消息，默认会阻塞程序至队列中有空闲位置放入数据
q.put(item, block=True, timeout=None)

# 等待所有的消息都被消费完
q.join()

# 通知队列任务处理已经完成，当所有任务都处理完成时，join() 阻塞将会解除
q.task_done()

# 查询当前队列的消息个数
q.qsize()

# 队列消息是否都被消费完，返回 True/False
q.empty()

# 检测队列里消息是否已满
q.full()

以老师点名为例：

import time

from queue import Queue
from threading import Thread

class Student(object):
    def __init__(self, name):
        super(Student, self).__init__()

        self.name = name

    def speak(self):
        print('{}: 到'.format(self.name))


class Teacher(object):
    def __init__(self, queue):
        super(Teacher, self).__init__()

        self.queue = queue

    def call(self, student_name):
        if student_name == 'exit':
            print('老师: 点名结束，开始上课')
        else:
            print('老师: {}'.format(student_name))

        self.queue.put(student_name)


class CallManager(Thread):
    def __init__(self, queue):
        super(CallManager, self).__init__()

        self.students = {}
        self.queue = queue

    def put(self, student):
        self.students.setdefault(student.name, student)

    def run(self):
        while True:
            student_name = self.queue.get()

            if student_name == 'exit':
                break
            elif student_name in self.students:
                self.students[student_name].speak()
            else:
                print('学生: 老师，没有 {} 这个人'.format(student_name))

queue = Queue()

teacher = Teacher(queue=queue)
s1 = Student(name='张三')
s2 = Student(name='李四')

cm = CallManager(queue)
cm.put(s1)
cm.put(s2)

cm.start()

print('开始点名')
teacher.call('张三')
time.sleep(1)
teacher.call('李四')
time.sleep(1)
teacher.call('王五')
time.sleep(1)
teacher.call('exit')

运行结果如下：

开始点名
老师: 张三
张三: 到
老师: 李四
李四: 到
老师: 王五
学生: 老师，没有 王五 这个人
老师: 点名结束，开始上课

除了先进先出队列 queue.Queue 外，还有后进先出队列 queue.LifoQueue 和优先级队列 queue.PriorityQueue。

进程池和线程池

池是一组资源的集合，这组资源在服务器启动之初就被完全创建好并初始化，这称为静态资源分配。当服务器进入正式运行阶段，即开始处理客户请求的时候，如果它需要相关的资源，就可以直接从池中获取，无需动态分配。很显然，直接从池中取得所需资源比动态分配资源的速度要快得多，因为分配系统资源的系统调用都是很耗时的。

池的概念主要目的是为了重用：让线程或进程在生命周期内可以多次使用。它减少了创建创建线程和进程的开销，以空间换时间来提高了程序性能。重用不是必须的规则，但它是程序员在应用中使用池的主要原因。

Python 中利用 concurrent.futures 库中的 ThreadPoolExecutor 和 ProcessPoolExecutor 创建线程池和进程池。示例如下：

import time
import threading

from concurrent.futures import ThreadPoolExecutor, ProcessPoolExecutor, as_completed


def print_func(n=3):
    for idx in range(n):
        print('运行 {}-{}'.format(threading.get_ident(), idx))
        time.sleep(1)


def return_func(n=3):
    res = []

    for idx in range(n):
        res.append('{}-{}'.format(threading.get_ident(), idx))
        time.sleep(1)

    return res


def test_thread_pool_print(n=3, m=12):
    with ThreadPoolExecutor(max_workers=n) as executor:
        for _ in range(m):
            executor.submit(print_func)


def test_process_pool_print(n=3, m=12):
    with ProcessPoolExecutor(max_workers=n) as executor:
        for _ in range(m):
            executor.submit(print_func)


def test_thread_pool_return(n=3, m=12):
    with ThreadPoolExecutor(max_workers=n) as executor:
        futures = [executor.submit(return_func) for _ in range(m)]

        for future in as_completed(futures):
            print(future.result())


def test_process_pool_return(n=3, m=12):
    with ProcessPoolExecutor(max_workers=n) as executor:
        futures = [executor.submit(return_func) for _ in range(m)]

        for future in as_completed(futures):
            print(future.result())


line_sep = '-' * 60

print(line_sep)
print('测试线程池')
print(line_sep)
test_thread_pool_print()
print(line_sep)

print(line_sep)
print('测试进程池')
print(line_sep)
test_process_pool_print()
print(line_sep)

print(line_sep)
print('测试线程池')
print(line_sep)
test_thread_pool_return()
print(line_sep)

print(line_sep)
print('测试进程池')
print(line_sep)
test_process_pool_return()
print(line_sep)

运行结果如下：

------------------------------------------------------------
测试线程池
------------------------------------------------------------
运行 123145462505472-0
运行 123145479294976-0
运行 123145496084480-0
运行 123145496084480-1
运行 123145462505472-1
运行 123145479294976-1
运行 123145496084480-2
运行 123145462505472-2
运行 123145479294976-2
运行 123145462505472-0
运行 123145479294976-0
运行 123145496084480-0
运行 123145479294976-1
运行 123145462505472-1
运行 123145496084480-1
运行 123145479294976-2
运行 123145462505472-2
运行 123145496084480-2
------------------------------------------------------------
------------------------------------------------------------
测试进程池
------------------------------------------------------------
运行 4545199616-0
运行 4545199616-1
运行 4545199616-2
运行 4545199616-0
运行 4545199616-1
运行 4545199616-2
运行 4663131648-0
运行 4663131648-1
运行 4663131648-2
运行 4663131648-0
运行 4663131648-1
运行 4663131648-2
运行 4633173504-0
运行 4633173504-1
运行 4633173504-2
运行 4633173504-0
运行 4633173504-1
运行 4633173504-2
------------------------------------------------------------
------------------------------------------------------------
测试线程池
------------------------------------------------------------
['123145496084480-0', '123145496084480-1', '123145496084480-2']
['123145479294976-0', '123145479294976-1', '123145479294976-2']
['123145462505472-0', '123145462505472-1', '123145462505472-2']
['123145479294976-0', '123145479294976-1', '123145479294976-2']
['123145496084480-0', '123145496084480-1', '123145496084480-2']
['123145462505472-0', '123145462505472-1', '123145462505472-2']
------------------------------------------------------------
------------------------------------------------------------
测试进程池
------------------------------------------------------------
['4791307776-0', '4791307776-1', '4791307776-2']
['4588228096-0', '4588228096-1', '4588228096-2']
['4654599680-0', '4654599680-1', '4654599680-2']
['4791307776-0', '4791307776-1', '4791307776-2']
['4588228096-0', '4588228096-1', '4588228096-2']
['4654599680-0', '4654599680-1', '4654599680-2']
------------------------------------------------------------

其中，submit() 方法用于提交要执行的任务到线程池或进程池中，并返回该任务的 Future 对象。Future 对象的 done() 方法用于判断任务是否执行完毕，通过 result(timeout=None) 方法获取返回结果。利用 concurrent.futures.as_completed() 方法可以返回一个包含指定 Future 实例的迭代器，这些实例在完成时生成 Future 对象。

生成器和迭代器

容器是一种把多个元素组织在一起的数据结构，容器中的元素可以逐个迭代获取，可以用 in 或 not in 判断元素是否包含在容器中。常见的容器对象有：

list, deque, ...
set, frozensets, ...
dict, defaultdict, OrderedDict, Counter, ...
tuple, namedtuple, ...
str

可迭代对象

很多容器都是可迭代对象，此外还有更多的对象同样也可以是可迭代对象，比如处于打开状态的 file 和 socket 等。凡是可以返回一个迭代器的对象都可称之为可迭代对象，例如：

from collections import deque
from collections.abc import Iterable

print(isinstance('Leo Van', Iterable))
print(isinstance([1, 2, 3], Iterable))
print(isinstance({'k1': 'v1', 'k2': 'v2'}, Iterable))
print(isinstance(deque('abc'), Iterable))

运行结果如下：

True
True
True
True

迭代器

迭代器是一个带有状态的对象，通过 next() 方法可以返回容器中的下一个值。任何实现 __iter__() 和 __next__() 方法的对象都是迭代器。其中，__iter__() 方法返回迭代器本身，__next__() 方法返回容器中的下一个值，如果容器中没有更多元素了，则抛出 StopIteration 异常。例如：

class MyList(object):
    def __init__(self, end):
        super(MyList, self).__init__()

        self.end = end

    def __iter__(self):
        return MyListIterator(self.end)

    def __repr__(self):
        return '[{}]'.format(', '.join([str(ele) for ele in self]))


class MyListIterator(object):
    def __init__(self, end):
        super(MyListIterator, self).__init__()

        self.data = end
        self.start = 0

    def __iter__(self):
        return self

    def __next__(self):
        while self.start < self.data:
            self.start += 1
            return self.start - 1

        raise StopIteration

my_list = MyList(3)

print('MyList: {}'.format(my_list))
print(isinstance(my_list, Iterable))
print(isinstance(my_list, Iterator))

for ele in my_list:
    print(ele)

my_list_iterator = MyListIterator(3)

print('MyListIterator: {}'.format(my_list_iterator))
print(isinstance(my_list_iterator, Iterable))
print(isinstance(my_list_iterator, Iterator))

my_iterator = iter(my_list)

print('MyIterator: {}'.format(my_iterator))
print(isinstance(my_iterator, Iterable))
print(isinstance(my_iterator, Iterator))

while True:
    try:
        print(next(my_iterator))
    except StopIteration as e:
        return

运行结果如下：

MyList: [0, 1, 2]
True
False
0
1
2
MyListIterator: <__main__.MyListIterator object at 0x7fc9602b2100>
True
True
0
1
2
MyIterator: <__main__.MyListIterator object at 0x7fc9602b2fa0>
True
True
0
1
2
Stop

生成器

生成器非常类似于返回数组的函数，都是具有参数、可被调用、产生一系列的值。但是生成器并不是构造出数组包含所有的值并一次性返回，而是每次产生一个值，因此生成器看起来像函数，但行为像迭代器。

Python 中创建生成器有两种方法：使用类似列表方式或 yield 关键字：

from collections.abc import Generator
from inspect import getgeneratorstate

a_list = [x for x in range(10)]
print(a_list)
print(isinstance(a_list, Generator))

a_generator = (x for x in range(10))
print(a_generator)
print(isinstance(a_generator, Generator))

def my_yield(n):
    now = 0

    while now < n:
        yield now
        now += 1

    raise StopIteration

gen = my_yield(4)
print(gen)
print(isinstance(gen, Generator))

运行结果如下：

[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
False
<generator object <genexpr> at 0x7fdf84a8a430>
True
<generator object my_yield at 0x7fdf86a03f20>
True

由于生成器并不是一次生成所有元素，而是每次执行后返回一个值，通过 next() 和 generator.send(None) 两个方法可以激活生成器，例如：

def my_yield(n):
    now = 0

    while now < n:
        yield now
        now += 1

    raise StopIteration

gen = my_yield(4)
print(gen.send(None))
print(next(gen))
print(gen.send(None))
print(next(gen))

运行结果如下：

0
1
2
3

生成器在其生命周期中共有 4 种状态：

• GEN_CREATED：已创建
• GEN_RUNNING：正在执行（只在多线程应用中能看到该状态）
• GEN_SUSPENDED：暂停中
• GEN_CLOSED：已关闭

例如：

from collections.abc import Generator
from inspect import getgeneratorstate

def my_yield(n):
    now = 0

    while now < n:
        yield now
        now += 1

    raise StopIteration

gen = my_yield(4)
print(gen)
print(getgeneratorstate(gen))

print(gen.send(None))
print(next(gen))
print(getgeneratorstate(gen))

print(gen.send(None))
print(next(gen))
print(getgeneratorstate(gen))

gen.close()
print(getgeneratorstate(gen))

运行结果如下：

GEN_CREATED
0
1
GEN_SUSPENDED
2
3
GEN_SUSPENDED
GEN_CLOSED

生成器在不满足生成元素的条件时，会抛出 StopIteration 异常，通过类似列表形式构建的生成器会自动实现该异常，自定的生成器则需要手动实现该异常。

协程

yield

协程通过 yield 暂停生成器，可以将程序的执行流程交给其他子程序，从而实现不同子程序之间的交替执行。例如：

def jump_range(n):
    idx = 0

    while idx < n:
        jump = yield idx
        print('[idx: {}, jump: {}]'.format(idx, jump))

        if jump is None:
            jump = 1

        idx += jump

itr = jump_range(6)
print(next(itr))
print(itr.send(2))
print(next(itr))
print(itr.send(-1))
print(next(itr))
print(next(itr))

运行结果如下：

0
[idx: 0, jump: 2]
2
[idx: 2, jump: None]
3
[idx: 3, jump: -1]
2
[idx: 2, jump: None]
3
[idx: 3, jump: None]
4

yield idx 将 idx 返回给外部调用程序，jump = yield 可以接受外部程序通过 send() 发送的信息，并将其赋值给 jump。

yield from 是 Python 3.3 之后出现的新语法，后面是可迭代对象，可以是普通的可迭代对象，也可以是迭代器，甚至是生成器。yield 和 yield from 的对比如下：

a_str = 'Leo'
a_list = [1, 2, 3]
a_dict = {'name': 'Leo', 'gender': 'Male'}
a_gen = (idx for idx in range(4, 8))

def gen(*args, **kwargs):
    for item in args:
        for ele in item:
            yield ele

new_gen = gen(a_str, a_list, a_dict, a_gen)
print(list(new_gen))

a_gen = (idx for idx in range(4, 8))

def gen_from(*args, **kwargs):
    for item in args:
        yield from item

new_gen = gen_from(a_str, a_list, a_dict, a_gen)
print(list(new_gen))

运行结果如下：

['L', 'e', 'o', 1, 2, 3, 'name', 'gender', 4, 5, 6, 7]
['L', 'e', 'o', 1, 2, 3, 'name', 'gender', 4, 5, 6, 7]

在实现生成器的嵌套时，使用 yield from 可以比使用 yield 避免各种意想不到的异常。使用 yield from 时，需要关注如下几个概念：

• 调用方：调用委托生成器的代码
• 委托生成器：包含 yield from 表达式的生成器函数
• 子生成器：yield from 后面的生成器函数

如下是一个计算平均数的例子：

# 子生成器
def average_gen():
    total = 0
    count = 0
    average = 0

    while True:
        num = yield average

        if num is None:
            break

        count += 1
        total += num
        average = total / count

    return total, count, average

# 委托生成器
def proxy_gen():
    while True:
        total, count, average = yield from average_gen()
        print('计算完毕，共输入 {} 个数值，总和 {}，平均值 {}'.format(
            count, total, average))

# 调用方
calc_average = proxy_gen()
next(calc_average)
print(calc_average.send(10))
print(calc_average.send(20))
print(calc_average.send(30))
calc_average.send(None)

运行结果如下：

10.0
15.0
20.0
计算完毕，共输入 3 个数值，总和 60，平均值 20.0

委托生成器的作用是在调用方和子生成器之间建立一个双向通道，调用方通过 send() 将消息发送给子生成器，子生成器 yield 的值则返回给调用方。yield from 背后为整个过程做了很多操作，例如：捕获 StopIteration 异常等。

asyncio

asyncio 是 Python 3.4 引入的标准库，直接内置了对异步 IO 的支持。只要在一个函数前面加上 async 关键字就可以将一个函数变为一个协程。例如：

from collections.abc import Coroutine

async def async_func(name):
    print('Hello, ', name)

coroutine = async_func('World')
print(isinstance(coroutine, Coroutine))

运行结果如下：

True

利用 asyncio.coroutine 装饰器可以将一个生成器当作协程使用，但其本质仍旧是一个生成器。例如：

import asyncio

from collections.abc import Generator, Coroutine

@asyncio.coroutine
def coroutine_func(name):
    print('Hello,', name)
    yield from asyncio.sleep(1)
    print('Bye,', name)


coroutine = coroutine_func('World')
print(isinstance(coroutine, Generator))
print(isinstance(coroutine, Coroutine))

运行结果如下：

True
False

asyncio 中包含如下几个重要概念：

• event_loop 事件循环：程序开启一个无限的循环，协程将注册到事件循环上，当满足事件发生时，调用相应的协程函数。
• coroutine 协程：一个使用 async 定义的协程函数，它的调用不会立即执行，而是会返回一个协程对象。协程对象需要注册到事件循环上，由事件循环控制调用。
• future 对象：代表将来执行或没有执行的对象。它和 task 对象没有本质上的区别。
• task 对象：一个协程对象是一个原生可以挂起的函数，任务是对协程的进一步封装，其中包含任务的各种状态。Task 对象是 Future 的子类，它将 coroutine 和 Future 联系在一起，将 coroutine 封装成为一个 Future 对象。
• async / await 关键字：async 定义一个协程，await 用于挂起阻塞的异步调用接口。

协程完整的工作流程如下：

import asyncio

async def hello(name):
    print('Hello,', name)
    
# 定义协程
coroutine = hello('World')

# 定义事件循环
loop = asyncio.get_event_loop()

# 创建任务
task = loop.create_task(coroutine)

# 将任务交由时间循环并执行
loop.run_until_complete(task)

运行结果如下：

Hello, World

await 用于挂起阻塞的异步调用接口，其作用在一定程度上类似于 yield。yield from 后面可接可迭代对象，也可接 future 对象或协程对象；await 后面必须接 future 对象或协程对象。

import asyncio
from asyncio.futures import Future

async def hello(name):
    await asyncio.sleep(2)
    print('Hello, ', name)

coroutine = hello("World")

# 将协程转为 task 对象
task = asyncio.ensure_future(coroutine)

print(isinstance(task, Future))

运行结果如下：

True

异步 IO 的实现原理就是在 IO 高的地方挂起，等 IO 结束后再继续执行。绝大部分情况下，后续代码的执行是需要依赖 IO 的返回值的，这就需要使用回调。

回调的实现有两种，一种是在同步编程中直接获取返回结果：

import asyncio
import time

async def _sleep(x):
    time.sleep(x)
    return '暂停了 {} 秒'.format(x)

coroutine = _sleep(2)
loop = asyncio.get_event_loop()
task = asyncio.ensure_future(coroutine)

loop.run_until_complete(task)
print('返回结果：{}'.format(task.result()))

运行结果如下：

返回结果：暂停了 2 秒

另一种是通过添加回调函数来实现：

import asyncio
import time

async def _sleep(x):
    time.sleep(x)
    return '暂停了 {} 秒'.format(x)

def callback(future):
    print('回调返回结果：{}'.format(future.result()))

coroutine = _sleep(2)
loop = asyncio.get_event_loop()
task = asyncio.ensure_future(coroutine)

task.add_done_callback(callback)
loop.run_until_complete(task)

运行结果如下：

回调返回结果：暂停了 2 秒

asyncio 实现并发需要多个协程来完成，每当有任务阻塞时需要 await，然后让其他协程继续工作。

import asyncio

async def do_some_work(x):
    print('等待中 ...')
    await asyncio.sleep(x)
    print('{} 秒后结束'.format(x))
    return x

# 协程对象
coroutine1 = do_some_work(1)
coroutine2 = do_some_work(2)
coroutine3 = do_some_work(4)

# 任务列表
tasks = [
    asyncio.ensure_future(coroutine1),
    asyncio.ensure_future(coroutine2),
    asyncio.ensure_future(coroutine3)
]

loop = asyncio.get_event_loop()
loop.run_until_complete(asyncio.wait(tasks))

for task in tasks:
    print('任务结果：{}'.format(task.result()))

运行结果如下：

等待中 ...
等待中 ...
等待中 ...
1 秒后结束
2 秒后结束
4 秒后结束
任务结果：1
任务结果：2
任务结果：4

协程之间可以进行嵌套，即在一个协程中 await 另一个协程：

import asyncio

async def do_some_work(x):
    print('等待中 ...')
    await asyncio.sleep(x)
    print('{} 秒后结束'.format(x))
    return x

async def out_do_some_work():
    coroutine1 = do_some_work(1)
    coroutine2 = do_some_work(2)
    coroutine3 = do_some_work(4)

    tasks = [
        asyncio.ensure_future(coroutine1),
        asyncio.ensure_future(coroutine2),
        asyncio.ensure_future(coroutine3)
    ]

    dones, pendings = await asyncio.wait(tasks)

    for task in dones:
        print('任务结果：{}'.format(task.result()))

loop = asyncio.get_event_loop()
loop.run_until_complete(out_do_some_work())

如果使用 asyncio.gather() 来获取结果，则需要对获取结果部分做如下修改：

results = await asyncio.gather(*tasks)
for result in results:
    print('任务结果：{}'.format(result))

asyncio.wait() 返回 dones 和 pendings，分别表示已完成和未完成的任务；asyncio.gather() 则会把结果直接返回。

运行结果如下：

等待中 ...
等待中 ...
等待中 ...
1 秒后结束
2 秒后结束
4 秒后结束
任务结果：1
任务结果：4
任务结果：2

协程（准确的说是 Future 或 Task 对象）包含如下状态：

• Pending：已创建，未执行
• Running：执行中
• Done：执行完毕
• Cancelled：被取消

测试代码如下：

coroutine = _sleep(10)
loop = asyncio.get_event_loop()
task = loop.create_task(coroutine)

print('Pending')

try:
    t = Thread(target=loop.run_until_complete, args=(task, ))
    t.start()
    print('Running')
    t.join()
except KeyboardInterrupt as e:
    task.cancel()
    print('Cancel')
finally:
    print('Done')

执行顺利的话，运行结果如下：

Pending
Running
Done

如果在启动后按下 Ctrl + C 则会触发 task.cancel()，运行结果如下：

Pending
Running
Cancelled
Done

asyncio.wait() 可以通过参数控制何时返回：

import random
import asyncio

async def random_sleep():
    await asyncio.sleep(random.uniform(0.5, 6))

loop = asyncio.get_event_loop()
tasks = [random_sleep() for _ in range(1, 10)]

dones, pendings = loop.run_until_complete(asyncio.wait(
    tasks, return_when=asyncio.FIRST_COMPLETED))
print('第一次完成的任务数：{}'.format(len(dones)))

dones, pendings = loop.run_until_complete(asyncio.wait(
    pendings, timeout=2))
print('第二次完成的任务数: {}'.format(len(dones)))

dones, pendings = loop.run_until_complete(asyncio.wait(pendings))
print('第三次完成的任务数：{}'.format(len(dones)))

运行结果如下：

第一次完成的任务数：1
第二次完成的任务数: 4
第三次完成的任务数：4

2021-04-01 08:00:00

Python 实现篇请参见：进程，线程和协程 (Process, Thread and Coroutine) - 实现篇

进程，线程和协程

**进程（Process）**是计算机中已运行的程序 ¹。**线程（Thread）**是操作系统能够进行运算调度的最小单位。大部分情况下，线程被包含在进程之中，是进程中的实际运作单位。一条线程指的是进程中一个单一顺序的控制流，一个进程中可以并发多个线程，每条线程并行执行不同的任务 ²。

进程和线程之间的主要区别在于：

1. 线程共享创建其进程的地址空间，进程使用自己的地址。
2. 线程可以直接访问进程的数据，进程使用其父进程数据的副本。
3. 线程可以同其进程中其他线程直接通信，进程必须使用**进程间通讯（inter-process communicate, IPC）**与同级进程通信。
4. 线程开销较小，进程开销较大。
5. 线程的创建较为容易，进程需要复制其父进程。
6. 线程可以控制相同进程的其他线程，进程只能控制其子进程。
7. 对于主线程的修改（例如：取消、优先级修改等）可能会影响进程中的其他线程，对于父进程的修改不会影响其子进程。

单线程进程和多线程进程之间的对比如下图所示：

一个关于进程和线程的形象类比如下 ³：

1. 计算机的核心是 CPU，它承担了所有的计算任务。它就像一座工厂，时刻在运行。
2. 假定工厂的电力有限，一次只能供给一个车间使用。也就是说，一个车间开工的时候，其他车间都必须停工。背后的含义就是，单个 CPU 一次只能运行一个任务。
3. 进程就好比工厂的车间，它代表 CPU 所能处理的单个任务。任一时刻，CPU 总是运行一个进程，其他进程处于非运行状态。
4. 一个车间里，可以有很多工人。他们协同完成一个任务。
5. 线程就好比车间里的工人。一个进程可以包括多个线程。
6. 车间的空间是工人们共享的，比如许多房间是每个工人都可以进出的。这象征一个进程的内存空间是共享的，每个线程都可以使用这些共享内存。
7. 可是，每间房间的大小不同，有些房间最多只能容纳一个人，比如厕所。里面有人的时候，其他人就不能进去了。这代表一个线程使用某些共享内存时，其他线程必须等它结束，才能使用这一块内存。
8. 一个防止他人进入的简单方法，就是门口加一把锁。先到的人锁上门，后到的人看到上锁，就在门口排队，等锁打开再进去。这就叫“互斥锁”（Mutual Exclusion，Mutex），防止多个线程同时读写某一块内存区域。
9. 还有些房间，可以同时容纳 $n$ 个人，比如厨房。也就是说，如果人数大于 $n$，多出来的人只能在外面等着。这好比某些内存区域，只能供给固定数目的线程使用。
10. 这时的解决方法，就是在门口挂 $n$ 把钥匙。进去的人就取一把钥匙，出来时再把钥匙挂回原处。后到的人发现钥匙架空了，就知道必须在门口排队等着了。这种做法叫做“信号量”（Semaphore），用来保证多个线程不会互相冲突。不难看出，Mutex 是 Semaphore 的一种特殊情况（$n = 1$ 时）。也就是说，完全可以用后者替代前者。但是，因为 Mutex 较为简单，且效率高，所以在必须保证资源独占的情况下，还是采用这种设计。
11. 操作系统的设计，因此可以归结为三点：(1). 以多进程形式，允许多个任务同时运行；(2). 以多线程形式，允许单个任务分成不同的部分运行；(3). 提供协调机制，一方面防止进程之间和线程之间产生冲突，另一方面允许进程之间和线程之间共享资源。

协程（Coroutine）是计算机程序的一类组件，推广了协作式多任务的子例程，允许执行被挂起与被恢复。相对子例程而言，协程更为一般和灵活，但在实践中使用没有子例程那样广泛。协程更适合于用来实现彼此熟悉的程序组件，如协作式多任务、异常处理、事件循环、迭代器、无限列表和管道。

子例程（Subroutine），是一个大型程序中的某部分代码，由一个或多个语句块组成。它负责完成某项特定任务，而且相较于其他代码，具备相对的独立性。

协程和子例程的执行过程对比如下：

• 子例程可以调用其他子例程，调用者等待被调用者结束后继续执行，故而子例程的生命期遵循后进先出，即最后一个被调用的子例程最先结束返回。协程的生命期完全由对它们的使用需要来决定。
• 子例程的起始处是惟一的入口点，每当子例程被调用时，执行都从被调用子例程的起始处开始。协程可以有多个入口点，协程的起始处是第一个入口点，每个 yield 返回出口点都是再次被调用执行时的入口点。
• 子例程只在结束时一次性的返回全部结果值。协程可以在 yield 时不调用其他协程，而是每次返回一部分的结果值，这种协程常称为生成器或迭代器。

协程类似于线程，但是协程是协作式多任务的，而线程是抢占式多任务的。这意味着协程提供并发性而非并行性。协程超过线程的好处是它们可以用于硬性实时的语境（在协程之间的切换不需要涉及任何系统调用或任何阻塞调用），这里不需要用来守卫临界区段的同步原语比如互斥锁、信号量等，并且不需要来自操作系统的支持。

通信

进程间通信

管道

管道（Pipeline）是一系列将标准输入输出链接起来的进程，其中每一个进程的输出被直接作为下一个进程的输入。 例如：

ls -l | less

ls 用于在 Unix 下列出目录内容，less 是一个有搜索功能的交互式的文本分页器。这个管道使得用户可以在列出的目录内容比屏幕长时目录上下翻页。

命名管道

命名管道是计算机进程间的一种先进先出通信机制。是类 Unix 系统传统管道的扩展。传统管道属于匿名管道，其生存期不超过创建管道的进程的生存期。但命名管道的生存期可以与操作系统运行期一样长。

信号

信号（Signals）是 Unix、类 Unix 以及其他 POSIX 兼容的操作系统中进程间通讯的一种有限制的方式。它是一种异步的通知机制，用来提醒进程一个事件已经发生。当一个信号发送给一个进程，操作系统中断了进程正常的控制流程，此时，任何非原子操作都将被中断。如果进程定义了信号的处理函数，那么它将被执行，否则就执行默认的处理函数。

例如，在一个运行的程序的控制终端键入特定的组合键可以向它发送某些信号：Ctrl + C 发送 INT 信号（SIGINT），这会导致进程终止；Ctrl + Z 发送 TSTP 信号（SIGTSTP），这会导致进程挂起。

消息队列

消息队列提供了异步的通信协议，每一个贮列中的纪录包含详细说明的资料，包含发生的时间，输入设备的种类，以及特定的输入参数，也就是说：消息的发送者和接收者不需要同时与消息队列交互。消息会保存在队列中，直到接收者取回它。

消息队列本身是异步的，它允许接收者在消息发送很长时间后再取回消息。和信号相比，消息队列能够传递更多的信息。与管道相比，消息队列提供了有格式的数据，这可以减少开发人员的工作量。

信号量

信号量（Semaphore）又称为信号标，是一个同步对象，用于保持在 0 至指定最大值之间的一个计数值。当线程完成一次对该 Semaphore 对象的等待（wait）时，该计数值减一；当线程完成一次对 Semaphore 对象的释放（release）时，计数值加一。当计数值为 0，则线程等待该 Semaphore 对象不再能成功直至该 Semaphore 对象变成 signaled 状态。Semaphore 对象的计数值大于 0，为 signaled 状态；计数值等于 0，为 nonsignaled 状态.

共享内存

共享内存指可被多个进程存取的内存，一个进程是一段程序的单个运行实例。在这种情况下，共享内存被用作进程间的通讯。

伯克利套接字

伯克利套接字（Internet Berkeley Sockets），又称为 BSD 套接字是一种应用程序接口，主要用于实现进程间通讯，在计算机网络通讯方面被广泛使用。

线程间通信

锁机制

• 互斥锁：互斥锁（Mutual Exclusion，Mutex）是一种用于多线程编程中，防止两条线程同时对同一公共资源（比如全局变量）进行读写的机制。
• 条件锁：读写锁是计算机程序的并发控制的一种同步机制，用于解决读写问题。读操作可并发重入，写操作是互斥的。
• 条件变量：条件变量是利用线程间共享的全局变量进行同步的一种机制，主要包括两个动作：一个线程等待“条件变量的条件成立”而挂起；另一个线程使“条件成立”（给出条件成立信号）。为了防止竞争，条件变量的使用总是和一个互斥锁结合在一起。
• 自旋锁：自旋锁是用于多线程同步的一种锁，线程反复检查锁变量是否可用。由于线程在这一过程中保持执行，因此是一种忙等待。一旦获取了自旋锁，线程会一直保持该锁，直至显式释放自旋锁。

信号

同上文。

信号量

同上文。

2021-03-14 08:00:00

CNN 的缺陷

卷积神经网络（CNN）在图像领域取得了很大的成功，但同时也存在一定的缺陷。卷积层中的卷积核对输入图像利用卷积运算提取其中的特征。卷积核以一个较小的尺寸并以一定的步长在图像上移动得到特征图。步长越大，特征图的尺寸就越小，过大的步长会丢失部分图像中的特征。池化层作用于产生的特征图上，使得 CNN 可以在不同形式的图像中识别出相同的物体，为 CNN 引入了空间不变性。

CNN 最大的缺陷就是忽略了不同特征之间的相对位置，从而无法从图像中识别出姿势、纹理和变化。CNN 中的池化操作使得模型具有空间不变性，因此模型就不具备等变性。以下图为例，CNN 会把第一幅和第二幅识别为人脸，而将第三幅方向翻转的图识别为不是人脸。池化操作造成了部分信息的丢失，因此需要更多的训练数据来补偿这些损失。

等变和不变

对于一个函数 $f$ 和一个变换 $g$，如果有：

$$ f \left(g \left(x\right)\right) = g \left(f \left(x\right)\right) $$

则称 $f$ 对变换 $g$ 有等变性。

例如，变换 $g$ 为将图像向左平移若干像素，函数 $f$ 表示检测一个人脸的位置。则 $f \left(g \left(x\right)\right)$ 表示先将图片左移，我们将在原图的左侧检测到人脸；$g \left(f \left(x\right)\right)$ 表示先检测人脸位置，然后将人脸位置左移。这两者的输出结果是一样的，与我们施加变换的顺序无关。CNN 中的卷积操作使得它对平移操作具有等变性。

对于一个函数 $f$ 和一个变换 $g: g \left(x\right) = x'$，如果有：

$$ f \left(x\right) = f \left(x'\right) = f \left(g \left(x\right)\right) $$

则称 $f$ 对变换 $g$ 有不变性。

例如，变换 $g$ 为旋转或平移，函数 $f$ 表示检测图中是否有黑色，那么这些变换不会对函数结果有任何影响，可以说函数对该变换具有不变性。CNN 中的池化操作对平移操作具有近似不变性。

逆图形

计算机图形学根据几何数据的内部层次结构来构造可视图像，该表示的结构将对象的相对位置考虑在内。软件采用层次的表示方式将其渲染为屏幕上的图像。人类大脑的工作原理则与渲染过程相反，我们称其为逆图形。大脑中对象的表示并不依赖于视角。

例如下图，人眼可以很容易的分辨出是自由女神像，只是角度不同，但 CNN 却很难做到，因为它不理解 3D 空间的内在。

胶囊网络

胶囊

在引入“胶囊”这个概念的第一篇文献 Transforming Auto-encoders ¹ 中，Hinton 等人对胶囊概念理解如下：

人工神经网络不应当追求“神经元”活动中的视角不变性（使用单一的标量输出来总结一个局部池中的重复特征检测器的活动），而应当使用局部的“胶囊”，这些胶囊对其输入执行一些相当复杂的内部计算，然后将这些计算的结果封装成一个包含信息丰富的输出的小向量。每个胶囊学习辨识一个有限的观察条件和变形范围内隐式定义的视觉实体，并输出实体在有限范围内存在的概率及一组“实例参数”，实例参数可能包括相对这个视觉实体的隐式定义的典型版本的精确的位姿、照明条件和变形信息。当胶囊工作正常时，视觉实体存在的概率具有局部不变性——当实体在胶囊覆盖的有限范围内的外观流形上移动时，概率不会改变。实例参数却是“等变的”——随着观察条件的变化，实体在外观流形上移动时，实例参数也会相应地变化，因为实例参数表示实体在外观流形上的内在坐标。

人造神经元输出单个标量。对于 CNN 卷积层中的每个卷积核，对整个输入图复制同一个内核的权重输出一个二维矩阵。矩阵中每个数字是该卷积核对输入图像一部分的卷积，这个二维矩阵看作是重复特征检测器的输出。所有卷积核的二维矩阵堆叠在一起得到卷积层的输出。CNN 利用最大池化实现不变性，但最大池化丢失了有价值的信息，也没有编码特征之间的相对空间关系。

胶囊将特征检测的概率作为其输出向量的长度进行编码，检测出的特征的状态被编码为该向量指向的方向。当检测出的特征在图像中移动或其状态发生变化时，概率仍然保持不变（向量的长度没有改变），但它的方向改变了。

下表总结了胶囊和神经元的不同：

		Capsule	Traditional Neuron
Input from low-level capsule/neuron		$\text{vector}\left(\mathbf{u}_i\right)$	$\text{scalar}\left(x_i\right)$
Operration	Affine Transform	$\widehat{\mathbf{u}}_{j \mid i}=\mathbf{W}_{i j} \mathbf{u}_{i}$	-
	Weighting	$\mathbf{s}_{j}=\sum_{i} c_{i j} \widehat{\mathbf{u}}_{j \mid i}$	$a_{j}=\sum_{i} w_{i} x_{i}+b$
	Sum
	Nonlinear Activation	$\mathbf{v}_{j}=\dfrac{\left\|\mathbf{s}_{j}\right\|^{2}}{1+\left\|\mathbf{s}_{j}\right\|^{2}} \dfrac{\mathbf{s}_{j}}{\left\|\mathbf{s}_{j}\right\|}$	$h_{j}=f\left(a_{j}\right)$
Output		$\text{vector}\left(\mathbf{v}_j\right)$	$\text{scalar}\left(h_j\right)$

人造神经元包含如下 3 个计算步骤：

1. 输入标量的加权
2. 加权标量的求和
3. 求和标量到输出标量的非线性变换

胶囊可以理解为上述 3 个步骤的向量版，同时增加了对输入的仿射变换：

1. 输入向量的矩阵乘法：胶囊接受的输入向量编码了低层胶囊检测出的相应对象的概率，向量的方向编码了检测出的对象的一些内部状态。接着将这些向量乘以相应的权重矩阵 $\mathbf{W}$，$\mathbf{W}$ 编码了低层特征（例如：眼睛、嘴巴和鼻子）和高层特征（例如：面部）之间的空间关系和其他重要关系。
2. 向量的标量加权：这个步骤同人造神经元对应的步骤类似，但神经元的权重是通过反向传播学习的，而胶囊则使用动态路由。
3. 加权向量的求和：这个步骤同人造神经元对应的步骤类似。
4. 求和向量到输出向量的非线性变换：胶囊神经网络的非线性激活函数接受一个向量，然后在不改变方向的前提下，将其长度压缩到 1 以下。

动态路由

胶囊网络使用动态路由算法进行训练，算法过程如下 ²：

\begin{algorithm}
\caption{Routing 算法}
\begin{algorithmic}
\PROCEDURE{Routing}{$\widehat{\mathbf{u}}_{j | i}, r, l$}
\STATE for all capsule $i$ in layer $l$ and capsule $j$ in layer $\left(l + 1\right)$: $b_{ij} \gets 0$
\FOR{$r$ iterations}
  \STATE for all capsule $i$ in layer $l$: $\mathbf{c}_i \gets \text{softmax} \left(\mathbf{b}_i\right)$
  \STATE for all capsule $j$ in layer $\left(l + 1\right)$: $\mathbf{s}_j \gets \sum_{i} c_{ij} \widehat{\mathbf{u}}_{j | i}$
  \STATE for all capsule $j$ in layer $\left(l + 1\right)$: $\mathbf{v}_j \gets \text{squash} \left(\mathbf{s}_j\right)$
  \STATE for all capsule $i$ in layer $l$ and capsule $j$ in layer $\left(l + 1\right)$: $b_{ij} \gets b_{ij} + \widehat{\mathbf{u}}_{j | i} \cdot \mathbf{v}_j$
\ENDFOR
\RETURN $\mathbf{v}_j$
\ENDPROCEDURE
\end{algorithmic}
\end{algorithm}

1. 第 1 行表示算法的输入为：低层 $l$ 中所有胶囊的输出 $\widehat{\mathbf{u}}$，以及路由迭代计数 $r$。
2. 第 2 行中的 $b_{ij}$ 为一个临时变量，其值在迭代过程中更新，算法运行完毕后其值被保存在 $c_{ij}$ 中。
3. 第 3 行表示如下步骤将会被重复 $r$ 次。
4. 第 4 行利用 $\mathbf{b}_i$ 计算低层胶囊的权重向量 $\mathbf{c}_i$。$\text{softmax}$ 确保了所有权重为非负数，且和为一。第一次迭代后，所有系数 $c_{ij}$ 的值相等，随着算法的继续，这些均匀分布将发生改变。
5. 第 5 行计算经前一步确定的路由系数 $c_{ij}$ 加权后的输入向量的线性组合。该步缩小输入向量并将他们相加，得到输出向量 $\mathbf{s}_j$。
6. 第 6 行对前一步的输出向量应用 $\text{squash}$ 非线性函数。这确保了向量的方向被保留下来，而长度被限制在 1 以下。
7. 第 7 行通过观测低层和高层的胶囊，根据公式更新相应的权重 $b_{ij}$。胶囊 $j$ 的当前输出与从低层胶囊 $i$ 处接收到的输入进行点积，再加上旧的权重作为新的权重。点积检测胶囊输入和输出之间的相似性。
8. 重复 $r$ 次，计算出所有高层胶囊的输出，并确立路由权重。之后正向传导就可以推进到更高层的网络。

点积运算接收两个向量，并输出一个标量。对于给定长度但方向不同的两个向量而言，点积有几种情况：$a$ 最大正值；$b$ 正值；$c$ 零；$d$ 负值；$e$ 最小负值，如下图所示：

我们用紫色向量 $\mathbf{v}_1$ 和 $\mathbf{v}_2$ 表示高层胶囊，橙色向量表示低层胶囊的输入，其他黑色向量表示接收自其他低层胶囊的输入，如下图所示：

左侧的紫色输出 $\mathbf{v}_1$ 和橙色输入 $\widehat{\mathbf{u}}_{1|1}$ 指向相反的方向，这意味着他们的点积是一个负数，从而路由系数 $c_{11}$ 减少；右侧的紫色输出 $\mathbf{v}_2$ 和橙色输入 $\widehat{\mathbf{u}}_{2|1}$ 指向相同的方向，从而路由系数 $c_{12}$ 增加。在所有高层胶囊及其所有输入上重复该过程，得到一个路由系数集合，达成了来自低层胶囊的输出与高层胶囊的输出的最佳匹配。

网络架构

胶囊网络由 6 层神经网络构成，前 3 层是编码器，后 3 层是解码器：

1. 卷积层
2. PrimaryCaps（主胶囊）层
3. DigitCaps（数字胶囊）层
4. 第一全连接层
5. 第二全连接层
6. 第三全连接层

编码器

编码器部分如下图所示：

卷积层用于检测 2D 图像的基本特征。PrimaryCaps 层包含 32 个主胶囊，接收卷积层检测到的基本特征，生成特征的组合。DigitCaps 层包含 10 个数字胶囊，每个胶囊对应一个数字。

对于 $k$ 个类别的数字，我们希望最高层的胶囊当且仅当一个数字出现在图像中时具有一个长的实例化向量。为了允许多个数字，对于每个 DigitCap 使用一个独立的损失函数：

$$ L_{k}=T_{k} \max \left(0, m^{+}-\left\|\mathbf{v}_{k}\right\|\right)^{2}+\lambda\left(1-T_{k}\right) \max \left(0,\left\|\mathbf{v}_{k}\right\|-m^{-}\right)^{2} $$

DigitCaps 层的输出为 10 个 16 维的向量，根据上面的公式计算每个向量的损失值，然后将 10 个损失值相加得到最终损失。

在损失函数中，当正确的标签与特定 DigitCap 的数字对应时 $T_k$ 为 1，否则为 0。加号前一项用于计算正确 DigitCap 的损失，当概率值大于 $m^{+} = 0.9$ 时为 0，当概率值小于 $m^{+} = 0.9$ 时为非零值；加号后一项用于计算错误 DigitCap 的损失，当概率值小于 $m^{-} = 0.1$ 时值为 0，当概率值大于 $m^{-} = 0.1$ 时为非零值。公式中的 $\lambda = 0.5$ 用于确保训练中数值的稳定性。

简单来说，低层的胶囊用于检测一些特定模式的出现概率和姿态，高层的胶囊用于检测更加复杂的图像，如下图所示：

解码器

解码器部分如下图所示：

解码器从正确的 DigitCap 中接收一个 16 维向量，并学习将其解码为数字图像。解码器接收正确的 DigitCap 的输出作为输入，并学习重建一张 $28 \times 28$ 像素的图像，损失函数为重建图像与输入图像之间的欧式距离。

2021-01-17 08:00:00

只有道德上的相对民主，没有制度上的绝对公平，求同存异才能长治久安。

无处不在的投票

在古代雅典城邦有一项政治制度称之为陶片放逐制，是由雅典政治家克里斯提尼于公元前 510 年创立。雅典人民可以通过投票强制将某个人放逐，目的在于驱逐可能威胁雅典的民主制度的政治人物。投票者在选票——陶罐碎片较为平坦处，刻上他认为应该被放逐者的名字，投入本部落的投票箱。如果选票总数未达到 6000，此次投票即宣告无效；如果超过 6000，再按票上的名字将票分类，得票最多的人士即为当年放逐的人选。

美国总统选举的方式称为选举人团，是一种间接选举，旨在选出美国总统和副总统。根据《美国宪法》及其修正案，美国各州公民先选出该州的选举人，再由选举人代表该州投票。不采用普选制度的原因，主要是由于美国是联邦制国家，并考虑到各州的特定地理及历史条件，制宪元老决定采取选举人团制度，保障各州权益，所以美国没有公民直选的总统。

离我们最近的可能就是朋友聚会吃什么这个问题了，烧烤还是火锅，这是个问题。当然，只要你想要，还可以：蒸羊羔、蒸熊掌、蒸鹿尾儿、烧花鸭、烧雏鸡、烧子鹅 ……

投票制度

多数制

多数制（Plurality Voting System）的原则是“胜者全取”，又被称为多数代表制（Majoritarian Representation），分成相对多数（Relative Plurality）和绝对多数（Absolute Majority）。相对多数制即不论票数多少，得票最多的候选人便可当选。绝对多数制指候选人需要得到指定的票数方可当选，门槛在设定上须达有效票之过半数、三分之二、四分之三或五分之四等多数，亦可以是更高的比例或数字。

多数制的优点在于简单易行，缺点在于当选票分散的越平均，投票结果的争议性就会越大。例如：有 10 人参与投票，有 3 人选择吃火锅，有 3 人选择吃烧烤，有 4 人选择吃家常菜。根据多数制规则，最终的选择为吃家常菜，但会有 6/10 的人没有得到满意的结果。

波达计数法

波达计数法（Borda Count）是通过投票人对候选者进行排序，如果候选者在选票的排第一位，它就得某个分数，排第二位得一个较小的分数，如此类推，分数累计下来最高分的候选者便取胜。

波达计数法相比于多数制不容易选出比较有争议的选项。假设有一场选举，共 4 位候选人，共收集到有效选票 100 张，选票统计结果（理论山可能出现的选票类型为 $4! = 24$ 种可能，简单起见，示例中仅有 4 种可能）如下：

选举采用排名第 $n$ 位得 $4 - n$ 分的准则，每个人的分数如下：

• 张三：$51 \times 3 + 5 \times 0 + 23 \times 0 + 21 \times 0 = 153$
• 李四：$51 \times 1 + 5 \times 2 + 23 \times 3 + 21 \times 1 = 151$
• 王五：$51 \times 2 + 5 \times 3 + 23 \times 2 + 21 \times 2 = 205$
• 马六：$51 \times 0 + 5 \times 1 + 23 \times 1 + 21 \times 3 = 91$

按照多数制应该是张三获胜（得到第 1 名的票数最多，共计 51 票）。不过通过波达计数法可以发现大家对张三的喜好比较极端：只有特别喜欢（排名第 1）和特别不喜欢（排名第 4）两种情况，所以张三是一个具有争议的人。但王五不同，虽然其获得第 1 的选票并不多，但是获得第 2 的选票很多，说明大部分人都是比较能接受王五的。

波达计数法同时也存在几个问题：

1. 不同的权重的计分规则，可能得到不同结果。以下表为例：

   #	2 票	3 票	4 票	#
   2 分	A	A	C	5 分
   1 分	B	C	B	2 分
   0 分	C	B	A	1 分

   采用左边权重的计分结果为：A：10 分，B：6 分，C：11 分，则 C 胜出。采用右边权重的计分结果为：A：29 分，B：15 分，C：28 分，则 A 胜出。不难看出，多数投票制是波达计数法的一个特例，即第 1 名的权重为非零值，其余名次权重均为零。

2. 容易出现恶意投票局面。参与的人在投票时往往会掺杂个人情感，假设存在这样一次选举：张三、李四、王五三人竞选班长，张三和李四是最有希望竞争班长的人员，而王五则表现平庸。参与投票的同学几乎近一半的人支持张三，近一半的人支持李四，很少人支持王五。参与投票的同学自认为都很“聪明”，担心自己不支持的人（假设为李四）担任班长，同时认为王五没希望竞选成功，因此在排序时会把王五排在第 2 名，把李四排在第 3 名。此时，张三和李四都变成了具有争议的人，那么选举的结果就很有可能是王五获胜。

孔多赛投票制

波达计数法还存在一个严重的问题是，当其中一个选项退出后，投票的结果会发生变化。仍然以上文中的例子为例：

在包含选项 B 时，投票结果为：A：10 分，B：6 分，C：11 分，C 获胜。当把选项 B 去掉后，投票结果为：A：5 分，C：4 分，A 获胜。去掉选项 B，规则没有发生变化（不同排名之间权重相差为 1），投票人的意愿也没有发生变化（候选人的相对名次没有发生变动），但投票结果却截然不同。

为了解决这个问题，孔多赛提供了采用两两对决的方式进行投票。投票人依旧按照类似波达计数法对候选人进行排序，但与波达计数法不同的是并不进行计分而是需要统计出所有两两对决的情况。上面这个例子中两两对决的情况有 6 种：A > B，B > A，B > C，C > B，A > C，C > A，对决的统计结果如下表所示：

由于 A > B 有 5 次，B > A 有 4 次，因此在 A 和 B 的两两对决中获胜的是 A。同理可得，在 A 和 C 的两两对决中获胜的是 A，在 B 和 C 的两两对决中获胜的是 C。当存在很多选项时，假设选项 A 在与任何其它选项的两两比较中都能胜出，那 A 称为孔多塞胜利者。

如果你对 Facebook 历史有了解，早期扎克伯格在哈佛大学就读学士期间，写了一个名为 Facemash 的网站程序，根据哈佛校内报纸《The Harvard Crimson》，Facemash 会从校内的网络上收集照片，每次将两张照片并排后让用户选择“更火辣”的照片。Facemash 就采取了类似孔多塞投票的方法对女生进行投票，下图是电影社交网络中这个原型的截图：

孔多塞投票制由于统计比较麻烦，现实生活中使用的情况不多。同时，孔多塞投票也存在一个问题，即孔多塞循环。假设 A 和 B 对决的优胜者为 A，B 和 C 对决的优胜者为 B，C 和 A 对决的优胜者为 C，则没有一个选项打败其他所有选项，那么这样就无法得到投票的结果。这称之为孔多塞悖论（投票悖论），在这个假想情况中，集体倾向可以是循环性的，即使个人的倾向不是。

所以呢？

所以什么样的投票才算是公平合理的投票呢？肯尼斯·阿罗给出了一个解答。

有 $N$ 种选择，有 $m$ 个决策者，他们每个人都对这 $N$ 个选择有一个从优至劣的排序。我们要设计一种选举法则，使得将这 $m$ 个排序的信息汇总成一个新的排序，称为投票结果。我们希望这种法则满足以下条件：

1. 一致性（Unanimity）。或称为帕累托最优（Pareto Efficiency），即如果所有的 $m$ 个决策者都认为选择 $A$ 优于 $B$，那么在投票结果中，$A$ 也优于 $B$。
2. 非独裁（Non-Dictatorship）。不存在一个决策者 $X$，使得投票结果总是等同于 $X$ 的排序。
3. 独立于无关选项（Independence of Irrelevant Alternatives，IIA)）。如果现在一些决策者改了主意，但是在每个决策者的排序中，$A$ 和 $B$ 的相对位置不变，那么在投票结果中 $A$ 和 $B$ 的相对位置也不变。

如果选项 $N \geq 3$，投票人数 $m \geq 2$ 时，没有任何一种投票规则能够满足以上 3 点，这就是阿罗悖论。所以只有道德上的相对民主，没有制度上的绝对公平，求同存异才能长治久安。

本文参考自《投票公平合理吗？为什么没有绝对的公平？阿罗不可能定理》。

2021-01-01 08:00:00

本文为《复杂网络系列》文章

图存储

语义网络与 RDF 存储

1968 年 Ross Quillian 在其博士论文中最先提出语义网络（Semantic Web），把它作为人类联想记忆的一个显式心理学模型，并在他设计的可教式语言理解器 TLC（Teachable Language Comprehenden）中用作知识表示方法。

语义网络的基本思想是在网络中，用“节点”代替概念，用节点间的“连接弧”（称为联想弧）代替概念之间的关系，因此，语义网络又称联想网络。它在形式上是一个带标识的有向图。由于所有的概念节点均通过联想弧彼此相连知识推导。

一个语义网络的基本构成如下：

• 语义网络中的节点：表示各种事物、概念、情况、属性、动作、状态等，每个节点可以带有若干属性，一般用框架或元组表示。此外，节点还可以是一个语义子网络，形成一个多层次的嵌套结构。
• 语义网络中的弧：表示各种语义联系，指明它所连接的节点间某种语义关系。
• 节点和弧都必须带有标识，以便区分各种不同对象以及对象间各种不同的语义联系。

之后 Tim Berners-Lee 又提出了语义网堆栈（Semantic Web Stack）的概念。语义网堆栈利用图示解释是不同层面的语言所构成的层级结构，其中，每一层面都将利用下游层面的能力，语义网堆栈如下图所示：

资源描述框架（Resource Description Framework，RDF）是用于描述网络资源的 W3C 标准，比如网页的标题、作者、修改日期、内容以及版权信息。

RDF 使用 Web 标识符来标识事物，并通过属性和属性值来描述资源。

对资源、属性和属性值的解释：

• 资源是可拥有 URI 的任何事物，比如 http://www.w3school.com.cn/rdf
• 属性是拥有名称的资源，比如 author 或 homepage
• 属性值是某个属性的值，比如 David 或 http://www.w3school.com.cn（请注意一个属性值可以是另外一个资源)

下面是一个 RDF 示例文档（这是一个简化的例子，命名空间被忽略了）：

<?xml version="1.0"?>

<RDF>
  <Description about="http://www.w3school.com.cn/RDF">
    <author>David</author>
    <homepage>http://www.w3school.com.cn</homepage>
  </Description>
</RDF>

资源、属性和属性值的组合可形成一个陈述（被称为陈述的主体、谓语和客体)。上述的 RDF 文档包含了如下两个陈述：

• 陈述：The author of http://www.w3school.com.cn/rdf is David
  • 陈述的主体是：http://www.w3school.com.cn/rdf
  • 谓语是：author
  • 客体是：David
• 陈述：The homepage of http://www.w3school.com.cn/rdf is http://www.w3school.com.cn
  • 陈述的主体是：http://www.w3school.com.cn/rdf
  • 谓语是：homepage
  • 客体是：http://www.w3school.com.cn

更多 RDF 介绍请参见：https://www.w3school.com.cn/rdf/index.asp 。

Apache Jena 是一个用于构建语义网络（Semantic Web）和链接数据（Linked Data）应用的开源 Java 框架。Jena 提供了 3 大部分功能：

1. RDF
   • RDF API：提供构建和读取 RDF 图的核心 API，并利用 RDF/XML 或 Turtle 等数据类型序列化数据。
   • ARQ（SPARQL)：提供一种 SPARQL 1.1 的编译引擎 ARQ 用于查询 RDF。
2. Triple store
   • TDB：提供一种原生高效的 Triple 存储 TDB，全面支持 Jena APIs。
   • Fuseki：提供 REST 风格的 RDF 数据交互方式。
3. OWL
   • Ontology API：通过 RDFS，OWL 等为 RDF 数据添加更多语义信息。
   • Inference API：通过内置的 OWL 和 RDFS 语义推理器 构建个性化的推理规则。

下面以 Graph of The Gods 的关系图对 Jena 的基本功能进行说明。Graph of The Gods 是一张描述希腊神话相关事物之间关系的图，其中顶点的类型有：titan（泰坦，希腊神话中曾经统治师姐的古老神族)，god（神)，demigod（半神)，human（人)，monster（怪物)，location（地点)；关系的类型有：father（父亲)，brother（兄弟)，mother（母亲)，battled（战斗)，lives（居住)。

以 Apache Tomcat 作为容器来安装 Apache Jena Fuseki，下载最新版的 Apache Jena Fuseki 并解压，将其中的 fuseki.war 复制到已经安装并运行的 Apache Tomcat 的 webapps 路径下。安装完毕后，进入 http://127.0.0.1:8080/fuseki 即可使用 Apache Jena Fuseki。

在导入 Graph of The Gods 数据后，执行如下查询语句可以获得 jupiter 的所有兄弟：

PREFIX gods: <http://leovan.me/gods/>

SELECT DISTINCT ?god
WHERE {
  ?god gods:brother gods:jupiter
}

查询结果为：

图数据库

图数据库是一个使用图结构进行语义查询的数据库，它使用节点、边和属性来表示和存储数据。不同于关系型数据库，图数据库为 NoSQL（Not Only SQL）的一种，属于联机事务处理（OLTP）的范畴，可以解决现有关系数据库的局限性。

下图展示了近年来不同类型数据库的流行度趋势，不难看出近年来越来越多的人开始关注图数据库。

截止到 2020 年 12 月，图数据库的排名如下图所示：

其中，Neo4j、JanusGraph、Dgraph、TigerGraph、Nebula Graph 均为时下常用的图数据库。从下图的流行度趋势角度来看，JanusGraph、Dgraph、TigerGraph 和 Nebula Graph 等后起之秀发展迅速。

不同的图数据库有着不同的优劣势，用户可以根据实际业务场景选择合适的图数据库。下面给到一些较新的图数据库对比和评测：

1. 主流开源分布式图数据库 Benchmark
2. 图数据库对比：Neo4j vs Nebula Graph vs HugeGraph
3. 图分析系统基准测试报告
4. 图数据平台产品测试报告

查询语言

图查询语言（Graph Query Language，GQL）是一种用于图数据库的查询语言，类比于关系型数据库的查询语言 SQL。2019 年 9 月，GQL 被提议为一种新的数据库查询语言（ISO/IEC WD 39075），目前仍处于开发当中，因此市面上还没有统一的图查询语言标准。

Gremlin

Gremlin 是 Apache TinkerPop 框架下的图遍历语言。Gremlin 适用于基于 OLTP 的图数据库以及基于 OLAP 的图分析引擎，支持命令式和声明式查询。支持 Gremlin 的图数据库有：Neo4j、JanusGraph 等。

Cypher

Cypher 是一种声明式图查询语言，这使得在不必编写遍历逻辑的情况下可以实现高效的查询。支持 Cypher 的图数据库有：Neo4j、RedisGraph、Nebula Graph 等。

nGQL

nGQL 是一种声明式的图查询语言，支持图遍历、模式匹配、聚合运算和图计算等特性。支持 nGQL 的图数据库有：Nebula Graph。

比较

针对 3 种不同的查询语言，对于图中相关概念的表示也略有不同，如下表所示：

更多不同查询语言之间的详细对比可以参见如下资料：

1. 一文了解各大图数据库查询语言 | 操作入门篇
2. 文档解读 ｜ SQL vs. nGQL

图计算

图计算框架

GraphX

GraphX 是一个基于 Spark 大规模图计算框架。GraphX 通过引入一个包含带有属性的顶点和变的有向图对 Spark 的 RDD 进行了扩展。通过 subgraph、joinVertices 和 aggregateMessages 等算子实现了 PageRank、连通子图、LPA 等图算法。

Plato

Plato 是由腾讯开源的高性能图计算框架。Plato 主要提供两方面的能力：离线图计算和图表示学习，目前支持的图算法如下：

在计算性能上，Plato 与 Spark GraphX 在 PageRank 和 LPA 两个算法上的计算耗时与内存消耗对比如下图所示：

GraphScope

GraphScope 由有阿里巴巴开源的一个统一的分布式图计算平台。GraphScope 提供了一个一站式环境，可以通过用户友好的 Python 接口在集群内对图进行操作。GraphScope 利用一系列开源技术使得集群上的大规模图数据的多阶段处理变得简单，这些技术包括：用于分析的 GRAPE、用于查询的 MaxGraph 、用于图神经网络计算的 Graph-Learn 和用于提供高效内存数据交换的 vineyard。GraphScope 的整体架构如下图所示：

GraphScope Interactive Engine（GIE）是一个用于探索性分析大规模复杂图结构数据的引擎，它通过 Gremlin 提供高级别的图查询语言，同时提供自动并行执行功能。

GraphScope Analytical Engine（GAE）是一个基于 GRAPE ¹ 提供并行图算法的分析引擎。除了提供基础的内置算法以外，GAE 允许用户利用 Python 基于 PIE ¹ 编程模型编写自定义算法，PIE 编程模型的运行方式如下图所示：

GraphScope 还提供以顶点为中心的 Pregel 模型 ²，用户可以使用 Pregel 模型来实现自定义算法。

GraphScope Learning Engine（GLE）是一个用于开发和训练大规模图神经网络的分布式框架。GLE 提供基于全量图（用于 GCN、GAT 等算法）和采样子图（用于 GraphSAGE，FastGCN、GraphSAINT 等算法）两种不同方式训练图模型。整体架构如下图所示：

Galileo

Galileo 是由京东零售研发的图计算平台，提供离线和在线图计算和图数据服务能力。目前 Galileo 暂未开源，待开源后补充相关信息。

图神经网络

关于图神经网络内容，请参见之前的博客 图嵌入 (Graph Embedding) 和图神经网络 (Graph Neural Network)。

:tada::tada::tada: Happe New Year! :tada::tada::tada:

2020-12-12 08:00:00

本文为《复杂网络系列》文章
本文内容主要参考自：《网络科学引论》¹

网络基础算法

最短路径

最短路径（shortest path）算法是寻找两个顶点之间的最短路径，寻找网络中最短路径的标准算法称为广度优先搜索（breadth-first search）。算法的基本思想如下图所示：

根据广度优先搜索的基本思想，不难证明距 $s$ 最短距离为 $d$ 的每个顶点都有一个到 $s$ 的最短距离为 $d - 1$ 的邻居顶点。一个简单的实现方式是，创建一个有 $n$ 个元素的数组存储从源顶点 $s$ 到其他所有顶点的距离，同时创建一个距离变量 $d$ 来记录当前在搜索过程中所处的层数，算法的具体流程如下：

1. 遍历距离数组，查找到 $s$ 的距离为 $d$ 的所有顶点。
2. 查找上述顶点的所有邻居顶点，如果同 $s$ 的距离未知，则距离置为 $d + 1$。
3. 如果距离未知的邻居顶点数量为零，则停止算法，否则将 $d$ 的值加一并重复上述过程。

这种方法在最坏的情况下时间复杂度为 $O \left(m + n^2\right)$，考虑多数网络的直径只随 $\log n$ 增长，算法运行的时间复杂度为 $O \left(m + n \log n\right)$。

上述算法中步骤 1 是最耗时的部分，通过使用队列的数据结构我们可以避免每次都遍历列表来找到距离源顶点 $s$ 距离为 $d$ 的顶点。构造一个队列，一个指针指向下一个要读取的元素，另一个指针指向要填充的空位，这样距离为 $d + 1$ 的顶点就会紧跟在距离为 $d$ 的顶点后面，队列如下图所示：

通过队列可以将算法的时间复杂度降至 $O \left(m + n\right)$，对于 $m \propto n$ 的稀疏网络而言，$O \left(m + n\right)$ 相当于 $O \left(n\right)$，所以算法的时间复杂度同顶点数量成正比。

通过对算法进行进一步修改则可以得到源顶点 $s$ 到其他任何顶点的最短路径。方法是在原来的网络上构建一个新的有向网络，该网络代表最短路径，称为最短路径树（shortest path tree），通常情况下，该网络是一个有向非循环网络，而不是树。

对于加权网络，利用广度优先搜索无法找到最短路径，这里需要用到 Dijkstra 算法 ² 进行求解。算法将图中的顶点分成两组 $S$ 和 $U$，整个算法过程如下：

1. 初始状态，$S$ 仅包含源顶点，即 $S = \left\{v\right\}$，$U$ 包含其余顶点。如果 $v$ 与 $U$ 中的顶点 $u$ 为邻居，则距离为边的权重，否则为无穷大。
2. 从 $U$ 中选择一个距离 $v$ 最短的顶点 $k$，并把 $k$ 加入到 $S$ 中。
3. 若从源点 $v$ 经过顶点 $k$ 到达 $u$ 的距离比之前 $v$ 到 $u$ 的距离短，则将距离修改为这个更短的距离。
4. 重复步骤 2 和 3，直至所有顶点都包含在 $S$ 中。

整个算法过程的可视化效果如下图所示：

Dijkstra 算法的时间复杂度为 $O \left(m + n^2\right)$，通过二叉堆的数据结构可以将时间复杂度优化至 $O \left(\left(m + n\right) \log n\right)$。

Dijkstra 算法虽然能够处理加权网络，但不能处理存在负权重的网络，需要利用 Floyd-Warshall 算法 ³ 进行求解。更多 Floyd-Warshall 算法的细节请参见之前的博客计算复杂性 (Computational Complexity) 与动态规划 (Dynamic Programming)。

最大流和最小割

对于连接给定顶点 $s$ 和 $t$ 的两条路径，若没有共享边，则这两条路径是边独立的；若除 $s$ 和 $t$ 外不共享任何其他顶点，则这两条路径是顶点独立的。顶点之间的边连通度和顶点连通度分别是顶点之间边独立路径数和顶点独立路径数。连通度是度量顶点之间连通鲁棒性的简单参数。假设一个网络是一个管线网络，其中每个管线的容量均为单位流量，那么边连通度等于从 $s$ 流向 $t$ 的最大流。

增广路径算法（Ford-Fulkerson Algorithm，FFA）是计算最大流最简单的算法。基本思想是：首先利用广度优先搜索算法找到一条从源 $s$ 到目标 $t$ 的路径。该步骤“消耗”了网络中的一些边，将这些边的容量填充满后，它们不再承载更多流量。之后在剩余边中找到从 $s$ 到 $t$ 的另一条路径，重复该过程直到找不到更多的路径为止。

但这还不是一个有效的算法，如下图中的 (a) 所示，如果在 $s$ 和 $t$ 之间运用广度优先搜索，可以发现黑色标记的路径。一旦这些边的容量被填充满，就不能在剩余边中找到从 $s$ 到 $t$ 的更多路径，但很明显，从 $s$ 到 $t$ 有两条边独立路径（上下各一条）。

解决该问题的一个简单修正方法是允许网络流量在一条边中能够同时在两个方向流动。更一般地，因为一条边容许承载的最大流是在任意方向的单位流量，那么一条边可以有多个单位流量，只要保证他们能够相互抵消，并且最终每条边承载不超过一个单位流量。

增广路径算法的实现利用了剩余图（residual graph），这是一个有向网络，该网络中的有向边连接原网络中相应的顶点对，并在指定方向承载一个或多个单位流量。例如上图中 (c) 和 (d) 就是对应 (a) 和 (b) 的流量状态的剩余图。算法的正确性在这里就不过多展开说明，该算法在计算两个顶点之间的最大流的平均时间复杂度为 $O \left(\left(m + n\right) m / n\right)$。

在图论中，去掉其中所有边使一张网络不再连通的边集为图的割，一张图上最小的割为最小割。通过对增广路径算法进行改动即可以寻找到边独立路径、最小边割集和顶点独立路径。

图划分和社团发现

图划分（graph partitioning）和社团发现（community detection）都是指根据网络中的边的连接模式，把网络顶点划分成群组、簇或社团。将网络顶点划分成群组后最常见的属性是，同一群组内部的顶点之间通过边紧密连接，而不同群组之间只有少数边。

图划分

最简单的图划分问题是把网络划分成两部分，有时也称其为图对分（graph bisection）。图对分是把一个网络中的顶点划分成为两个指定规模的非重叠群组，使得不同群组之间相互连接的边数最小。群组之间的边数称为割集规模（cut size）。 利用穷举搜索解决该问题是极为耗时的，通过启发式算法我们可以找到较好的网络划分。

Kernighan-Lin 算法

Kernighan-Lin 算法是由 Brian Kernighan 和 Shen Lin 在 1970 年提出的 ⁴，是图对分问题中最简单、最知名的启发式算法之一，如下图所示。

先以任意方式将网络顶点按指定规模划分成两个群组，对于任何由分属不同群组的顶点 $i$ 和顶点 $j$ 组成的顶点对 $\left(i, j\right)$，交换 $i$ 和 $j$ 的位置，并计算交换前后两个群组之间割集规模的变化量。在所有顶点对中找到使割集规模减小最多的顶点对，或者若没有使割集规模减小的顶点对，则找到使割集规模增加最小的顶点对，交换这两个顶点。重复这个过程，同时保证网络中的每个顶点只能移动一次。

继续算法，每一步都交换最大程度减少或最小程度增加群组之间边数的顶点对，直到没有可以变换的顶点对，此时本轮算法停止。在完成所有交换后，检查网络在此过程中经过的每一个状态，然后选择割集规模最小的状态。最后，重复执行上述整个过程，每次始于上次发现的最优网络划分，直到割集规模不在出现改善。

Kernighan-Lin 算法的主要缺点是运算速度缓慢，采用一些技巧来改善算法也只能使时间复杂度降至 $O \left(n^3\right)$，因此该算法仅适用于有几百或几千个顶点的网络，而不适用于更大规模的网络。

谱划分

请先了解附录中的拉普拉斯算子和拉普拉斯矩阵等相关概念。

考虑具有 $n$ 个顶点 $m$ 条边的网络，将其划分为两个群组，称为群组 1 和群组 2。可以把该划分的割集规模，也就是两个群组之间的边数表示为：

$$ \label{eq:r_1} R = \dfrac{1}{2} \sum_{i, j \text{ 属于不同群组}} A_{ij} $$

对于每个网络划分，定义有参数 $s_i$ 组成的集合，集合中每个元素对应于一个顶点 $i$，则有：

$$ s_i = \left\{\begin{array}{ll} +1 & \text{顶点 } i \text{ 在群组 1 中} \\ -1 & \text{顶点 } i \text{ 在群组 2 中} \end{array}\right. $$

那么：

$$ \dfrac{1}{2} \left(1 - s_i s_j\right) = \left\{\begin{array}{ll} 1 & \text{顶点 } i \text{ 和 } j \text{ 在不同的群组中} \\ 0 & \text{顶点 } i \text{ 和 } j \text{ 在相同的群组中} \end{array}\right. $$

则式 \ref{eq:r_1} 可以改写为：

$$ \begin{aligned} R & = \dfrac{1}{4} \sum_{ij} A_{ij} \left(1 - s_i s_j\right) \\ & = \dfrac{1}{4} \left(k_i \delta_{ij} - A_{ij}\right) s_i s_j \\ & = \dfrac{1}{4} \sum_{ij} L_{ij} s_i s_j \end{aligned} $$

其中，$\delta_{ij}$ 是克罗内克函数，$L_{ij}$ 是图拉普拉斯矩阵的第 $ij$ 个元素。写成矩阵的形式有：

$$ R = \dfrac{1}{4} \mathbf{s}^{\top} \mathbf{L} \mathbf{s} $$

由于每个 $s_i$ 的取值只能是 $\left\{+1, -1\right\}$，所以在给定 $\mathbf{L}$ 时求解 $\mathbf{s}$ 使其割集规模最小时并不容易。具体求解方法的推导在此不再展开说明，最终谱划分算法的过程如下所示：

1. 计算图拉普拉斯矩阵的第二小特征值 $\lambda_2$，称为网络的代数连通度（algebraic connectivity），及其对应的特征向量 $\mathbf{v}_2$。
2. 按从大到小的顺序对特征向量的元素进行排序。
3. 把前 $n_1$ 个最大元素对应的顶点放入群组 1，其余放入群组 2，计算割集规模。
4. 把前 $n_1$ 个最小（注意：中文译本中有错误）元素对应的顶点放入群组 2，其余放入群组 1，并重新计算割集规模。
5. 在两种网络划分中，选择割集规模较小的那个划分。

谱划分方法在稀疏网络上的时间复杂度为 $O \left(n^2\right)$，这比 Kernighan-Lin 算法时间复杂度少了一个因子 $n$，从而使该算法能应用于更大规模的网络。

社团发现

社团发现（社区发现，社群发现，Community Detection）的基本目的与图划分类似，即把网络分成几个节点点群组，并使节点群组之间的连接较少。主要的差别就是群组的数量和规模是不确定的。社团发现的算法分类和具体实现很多，本文仅介绍几个常用的算法，更多方法及其细节请参见如下开放资源：

1. Community Detection in Graphs ⁵
2. Deep Learning for Community Detection: Progress, Challenges and Opportunities ⁶
3. 复杂网络社团发现算法研究新进展 ⁷
4. benedekrozemberczki/awesome-community-detection

Fast Unfolding (Louvain)

Fast Unfolding (Louvain) ⁸ 是一种基于模块度的社团发现算法，通过模块度来衡量一个社团的紧密程度。算法包含两个阶段：

1. 历遍网络中所有的节点，通过比较将节点给每个邻居社团带来的模块度变化，将这个节点加入到使模块度增加最大的社团中。
2. 对于步骤 1 的结果，将属于同一个社团的节点合并成为一个大的节点，进而重型构造网络。新的节点之间边的权重是所包含的之前所有节点之间相连的边权重之和，然后重复步骤 1。

算法的两个步骤如下图所示：

Label Propagation Algorithm (LPA)

标签传播算法（Label Propagation Algorithm，LPA）是一种基于半监督学习的社团发现算法。对于每个节点都有对应的标签（即节点所隶属的社团），在算法迭代过程中，节点根据其邻居节点更新自身的标签。更新的规则是选择邻居节点中最多的标签作为自身的标签。

标签传播的过程中，节点的标签更新方式分为同步更新和异步更新两种方式。同步更新是指对于节点 $x$，在第 $t$ 步时，根据其所有邻居节点在 $t - 1$ 步时的标签对其进行更新，即：

$$ C_{x}(t)=f\left(C_{x_{1}}(t-1), C_{x_{2}}(t-1), \cdots, C_{x_{k}}(t-1)\right) $$

同步更新对于一个二分或者近似二分的网络来说可能会出现标签震荡的现象。对于异步更新方式，更新公式为：

$$ C_{x}(t)=f\left(C_{x_{i 1}}(t), \cdots, C_{x_{i m}}(t), C_{x_{i(m+1)}}(t-1), \cdots, C_{x_{i k}}(t-1)\right) $$

其中，邻居节点 $x_{i1}, \cdots, x_{im}$ 的标签在第 $t$ 步时已经更新过，而 $x_{i(m+1)}, \cdots, x_{ik}$ 的标签还未更新。

附录

拉普拉斯算子（Laplace operator，Laplacian）是由欧式空间中的一个函数的梯度的散度给出的微分算子，通常写作 $\Delta$，$\nabla^2$ 或 $\nabla \cdot \nabla$。

梯度（gradient）是对多元导数的概括，函数沿着梯度的方向变化最快，变化率则为梯度的模。假设二元函数 $f \left(x, y\right)$ 在区域 $G$ 内具有一阶连续偏导数，点 $P \left(x, y\right) \in G$，则称向量：

$$ \nabla f = \left(\dfrac{\partial f}{\partial x}, \dfrac{\partial f}{\partial y} \right) = \dfrac{\partial f}{\partial x} \mathbf{i} + \dfrac{\partial f}{\partial y} \mathbf{j} $$

为函数 $f$ 在点 $P$ 处的梯度，其中 $\mathbf{i}$ 和 $\mathbf{j}$ 为单位向量，分别指向 $x$ 和 $y$ 坐标方向。

散度（divergence）将向量空间上的一个向量场对应到一个标量场上，记为 $\nabla \cdot$。散度的意义是场的有源性，当 $\nabla \cdot F > 0$ 时，表示该点是发源点；当 $\nabla \cdot F < 0$ 时，表示该点是汇聚点；当 $\nabla \cdot F = 0$ 时，表示该点无源，如下图所示。

拉普拉斯离散化后即为拉普拉斯矩阵（laplacian matrix），也称为调和矩阵（harmonic matrix）。离散化的拉普拉斯算子形式如下：

$$ \begin{aligned} \Delta f & = \dfrac{\partial^2 f}{\partial x^2} + \dfrac{\partial^2 f}{\partial y^2} \\ & = f \left(x + 1, y\right) + f \left(x - 1, y\right) - 2 f \left(x, y\right) + f \left(x, y + 1\right) + f \left(x, y - 1\right) - 2 f \left(x, y\right) \\ & = f \left(x + 1, y\right) + f \left(x - 1, y\right) + f \left(x, y + 1\right) + f \left(x, y - 1\right) - 4 f \left(x, y\right) \end{aligned} $$

从上述离散化后的拉普拉斯算子形式可以看出，拉普拉斯矩阵表示的是对矩阵进行微小扰动后获得的收益。

设图 $G$ 有 $n$ 个节点，节点的邻域为 $N$，图上的函数 $f = \left(f_1, f_2, \cdots, f_n\right)$，其中 $f_i$ 表示节点 $i$ 处的函数值。对 $i$ 进行扰动，其可能变为邻域内的任意一个节点 $j \in N_i$：

$$ \Delta f_{i}=\sum_{j \in N_{i}}\left(f_{i}-f_{j}\right) $$

设每一条边 $e_{ij}$ 的权重为 $w_{ij}$，$w_{ij} = 0$ 表示节点 $i$ 和节点 $j$ 不相邻，则有：

$$ \begin{aligned} \Delta f_i & = \sum_{j \in N} w_{ij} \left(f_i - f_j\right) \\ & = \sum_{j \in N} w_{ij} f_i - \sum_{j \in N} w_{ij} f_i \\ & = d_i f_i - W_{i:} f \end{aligned} $$

对于所有节点有：

$$ \begin{aligned} \Delta f & = \left(\begin{array}{c} \Delta f_{1} \\ \vdots \\ \Delta f_{N} \end{array}\right)=\left(\begin{array}{c} d_{1} f_{1}-W_{1:} f \\ \vdots \\ d_{N} f_{N}-W_{N:} f \end{array}\right) \\ & = \left(\begin{array}{ccc} d_{1} & \cdots & 0 \\ \vdots & \ddots & \vdots \\ 0 & \cdots & d_{N} \end{array}\right) f-\left(\begin{array}{c} W_{1:} \\ \vdots \\ W_{N:} \end{array}\right) f \\ & = diag \left(d_i\right) f - W f \\ & = \left(D - W\right) f \\ & = L f \end{aligned} $$

令图 $G$ 的邻接矩阵为 $W$，度矩阵为 $D$，从上式可知拉普拉斯矩阵 $L = D - W$，其中：

$$ L_{ij} = \left\{\begin{array}{ll} \deg \left(v_i\right) & \text{如果 } i = j \\ -1 & \text{如果 } i \neq j \text{ 且 } v_i \text{ 与 } v_j \text{ 相邻} \\ 0 & \text{其他情况} \end{array}\right. $$

以下面的图为例：

邻接矩阵为：

$$ \left(\begin{array}{llllll} 0 & 1 & 0 & 0 & 1 & 0 \\ 1 & 0 & 1 & 0 & 1 & 0 \\ 0 & 1 & 0 & 1 & 0 & 0 \\ 0 & 0 & 1 & 0 & 1 & 1 \\ 1 & 1 & 0 & 1 & 0 & 0 \\ 0 & 0 & 0 & 1 & 0 & 0 \end{array}\right) $$

度矩阵为：

$$ \left(\begin{array}{cccccc} 2 & 0 & 0 & 0 & 0 & 0 \\ 0 & 3 & 0 & 0 & 0 & 0 \\ 0 & 0 & 2 & 0 & 0 & 0 \\ 0 & 0 & 0 & 3 & 0 & 0 \\ 0 & 0 & 0 & 0 & 3 & 0 \\ 0 & 0 & 0 & 0 & 0 & 1 \end{array}\right) $$

拉普拉斯矩阵为：

$$ \left(\begin{array}{rrrrrr} 2 & -1 & 0 & 0 & -1 & 0 \\ -1 & 3 & -1 & 0 & -1 & 0 \\ 0 & -1 & 2 & -1 & 0 & 0 \\ 0 & 0 & -1 & 3 & -1 & -1 \\ -1 & -1 & 0 & -1 & 3 & 0 \\ 0 & 0 & 0 & 1 & 0 & 1 \end{array}\right) $$

开放资源

常用网络算法包

不同扩展包之间的性能比较如下表所示 ⁹：

常用网络可视化软件

不同可视化软件之间的比较如下表所示 ¹⁰：

其中，⭑ 表示较弱、⭑⭑ 表示中等、⭑⭑⭑ 表示较好、⭑⭑⭑⭑ 表示优秀。

2020-11-28 08:00:00