分布式系统中的一致性模型的强弱和之前讲的事物的隔离级别层次有一些共通之处，比如在性能和隔离性/一致性间做取舍。

什么是分布式系统中的一致性？


# 如何在 NebulaGraph 里增加一种数据类型


NebulaGraph 内核所自带的数据结构其实已经很丰富了，比如 List、Set、Map、Duration、DataSet 等等，但是我们平时在建表和数据写入的时候，可以用到的数据结构其实比较有限，复杂结构目前仅支持以下几种：
`enum PropertyType {
    UNKNOWN = 0,
    ...             // 基础类型

    TIMESTAMP = 21,
    DURATION = 23,
    DATE = 24,
    DATETIME = 25,
    TIME = 26,
    GEOGRAPHY = 31,} (cpp.enum_strict)`

所以，有时候因为业务需求，我们需要能存入一些定制化的数据类型，比如机器学习中经常用到的 Embedding 的数据类型，工程上经常会有直接存储二进制数据 Binary 的需求，这就需要开发者自己去添加一个数据类型来满足自己的业务开发需求。

本文将手把手教你如何在 NebulaGraph 中增加一种数据类型，直到可以建表使用并插入对应数据以及查询。

下面我们以一个简单的二进制类型 Binary 的添加步骤来讲解整个流程。


## 01 命令设计


在实现新增 Binary 类型之前我们先想好要用怎么样的命令去使用这个类型，我们可以参考 NebulaGraph 已有的数据类型的使用


### schema 创建命令


`// 创建点表
create tag player(name string, image binary)
// 创建边表
create edge team(name string, logo binary)`

上面我们设计新建 schema 时使用 binary 关键字来表示设置二进制类型的属性字段。


### 插入数据


这里有一个问题就是，命令只能以字符串形式传输，所以我们如果通过命令来插入二进制数据的话，就需要转码。这里我们以选用 Base64 编码为例。

`insert vertex player values "p1":("jimmy", binary("0s=W9d...."))`

我们在插入命令里面同样以一个 binary 关键字来表示插入的是二进制数据的字符串而不是普通的字符串。


###  查询数据


其实正常的设计，或者现有的 NebulaGraph 代码上面来看，查询语句并不需要做改变，直接按照像读其他数据一样读取 Binary 字段就可以了，只是这里我们需要考虑一个问题，客户端没适配的话怎么办？像 nebula-console、nebula-java、nebula-cpp 这些客户端，我们暂时没法一一去适配新增的类型，所以为了测试的时候使用 nebula-console 能够正常读取到数据，我们需要提供转换函数，将新增的 Binary 类型转换为现有客户端能读取的数据格式。

`fetch prop on player "p1" yield base64(player.image) as img_base64`

这里我们定义了一个 base64() 的转换函数，将存储的二进制数据再以 Base64 的格式输出。（兜兜转转回到原点了(:≡）
定义好命令之后，我们来看看怎么实现这些内容，首先我们需要实现这个 Binary 的数据结构。


## 02 定义数据结构

在服务端 C++ 代码中，我们可以以一个 Bytes 数组来表示二进制的数据结构

`struct Binary {
    std::vector<std::byte> values;

    Binary() = default;
    Binary(const Binary &) = default;
    Binary(Binary &&) noexcept = default;
    explicit Binary(std::vector<std::byte> &&vals);
    explicit Binary(const std::vector<std::byte> &l);

    // 用于直接从命令行的字符串中解析出二进制
    explicit Binary(const std::string &str);
    
    ... // 其他接口`

一个简单的数据结构定义好之后，我们需要将这个结构添加到 Value 的 union 中：

Value 这个数据结构在 Value.cpp 中定义，它是 nebula 中所有数据结构的一个基类表示，每个新增的数据结构想要和之前其他数据结构一起混用的话，需要在 Value.cpp 里面对各个接口做适配

这个 Value 的数据结构里面有很多的接口定义，像赋值构造、符号重载、toString、toJson、hash 等接口，都需要去适配。

好在这不是什么难事，参考其他类型的实现就行。唯一要注意的是要细心！


### 定义 thrift 的数据结构

因为我们的数据结构还需要进行网络传输，所以我们还需要定义 thrift 文件里面的结构类型并实现序列化能力。

`// 新增的数据类型
struct Binary {
    1: list<byte> values;
} (cpp.type = "nebula::Binary")

// 在Value union中增加Binary类型
union Value {
    1: NullType                                 nVal;
    2: bool                                     bVal;
    3: i64                                      iVal;
    4: double                                   fVal;
    5: binary                                   sVal;
    6: Date                                     dVal;
    7: Time                                     tVal;
    8: DateTime                                 dtVal;
    9: Vertex (cpp.type = "nebula::Vertex")     vVal (cpp.ref_type = "unique");
    10: Edge (cpp.type = "nebula::Edge")        eVal (cpp.ref_type = "unique");
    11: Path (cpp.type = "nebula::Path")        pVal (cpp.ref_type = "unique");
    12: NList (cpp.type = "nebula::List")       lVal (cpp.ref_type = "unique");
    13: NMap (cpp.type = "nebula::Map")         mVal (cpp.ref_type = "unique");
    14: NSet (cpp.type = "nebula::Set")         uVal (cpp.ref_type = "unique");
    15: DataSet (cpp.type = "nebula::DataSet")  gVal (cpp.ref_type = "unique");
    16: Geography (cpp.type = "nebula::Geography")   ggVal (cpp.ref_type = "unique");
    17: Duration (cpp.type = "nebula::Duration")     duVal (cpp.ref_type = "unique");
    18: Binary (cpp.type = "nebula::Binary") btVal (cpp.ref_type = "unique");
} (cpp.type = "nebula::Value")`

另外我们还需要在 common.thrift 文件中的 PropertyType 该枚举中增加一个 BINARY 类型。

`enum PropertyType {
    UNKNOWN = 0,
    ...             // 基础类型

    TIMESTAMP = 21,
    DURATION = 23,
    DATE = 24,
    DATETIME = 25,
    TIME = 26,

    GEOGRAPHY = 31,
    BINARY = 32,} (cpp.enum_strict)`


###  实现 Binary 的 thrift rpc 格式的序列化


这里的代码就不展示了，同样可以参考其他类型的实现。最相近的可以参考 src/common/datatypes/ListOps-inl.h 的实现


## 03 命令行实现

数据结构定义好之后，我们可以开始命令行的实现，首先打开 src/parser/scanner.lex，我们需要新增一个关键字 BINARY：

`"BINARY"                    { return TokenType::KW_BINARY; }`

接着打开 src/parser/parser.yy 文件，将关键字声明一下：

`$token KW_BINARY`

为了尽量减少命令行的影响，我们将 binary 关键字添加到非保留关键字的集合中：

`unreserved_keyword
    ...
    | KW_BINARY             { $$ = new std::string("binary"); }`

接下来我们要将 BINARY 关键字添加到建表命令的词法树中：

`type_spec
    ...
    | KW_BINARY {
        $$ = new meta::cpp2::ColumnTypeDef();
        $$->type_ref() = nebula::cpp2::PropertyType::BINARY;
    }`

最后我们实现插入命令：

`constant_expression
    ...
    | KW_BINARY L_PAREN STRING R_PAREN {
        $$ = ConstantExpression::make(qctx->objPool(), Value(Binary(*$3)));
        delete $3;
    }`

就这样，我们就简单实现了上面命令设计里面的创建 binary schema 和插入 binary 数据的命令。


## 04 storaged 服务的读写适配


上面我们搞定了数据结构定义和 rpc 序列化以及命令行适配，一个新增的数据结构通过命令创建后，由 grapd 服务接收到请求并传输给 storaged 服务端。然而 storaged 服务端存储实际的数据是经过编码之后的 string，我们需要为这个新增的数据结构写一个编解码的代码逻辑。


### RowWriterV2 写适配

在代码文件 src/codec/RowWriterV2.cpp 中，有以下几个函数需要适配的。

`RowWriterV2::RowWriterV2(RowReader& reader) // 构造函数中适配新增的类似

WriteResult RowWriterV2::write(ssize_t index, const Binary& v) // 新增一个Binary的编码写入函数`

这里我直接将 Bytes 数组写入 String 中

`WriteResult RowWriterV2::write(ssize_t index, const Binary& v) noexcept {
  return write(index, folly::StringPiece(reinterpret_cast<const char*>(v.values.data()), v.values.size()));
}`


### RowReaderV2 读适配


在代码文件 src/codec/RowReaderV2.cpp 中，同样有以下函数需要适配

`Value RowReaderV2::getValueByIndex(const int64_t index) const {
    ...
    case PropertyType::VID: {
      // This is to be compatible with V1, so we treat it as
      // 8-byte long string
      return std::string(&data_[offset], sizeof(int64_t));
    }
    case PropertyType::FLOAT: {
      float val;
      memcpy(reinterpret_cast<void*>(&val), &data_[offset], sizeof(float));
      return val;
    }
    case PropertyType::DOUBLE: {
      double val;
      memcpy(reinterpret_cast<void*>(&val), &data_[offset], sizeof(double));
      return val;
    }
    ...
        
    // code here
    case PropertyType::BINARY: {
        ...
    }
}`

需要注意的是：读和写必须映射上，怎么写的就怎么读。
至此，在 NebulaGraph 里新增一个数据类型的流程就结束了。


# 看看效果


![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231206-1.png)

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231206-2.png)

----
**谢谢你读完本文**(///▽///)

如果你想尝鲜图数据库 NebulaGraph，记得去 GitHub 下载、使用、(^з^)-☆ star 它 -> [GitHub](https://github.com/vesoft-inc/nebula)；如果你有更高的性能、易用性、运维实施等方面的需求，你也可以随时 [联系我们](https://www.nebula-graph.com.cn/contact)，获取进一步的帮助哦~





一个新增的数据结构通过命令创建后，由 grapd 服务接收到请求并传输给 storaged 服务端。然而 storaged 服务端存储实际的数据是经过编码之后的 string，我们需要为这个新增的数据结构写一个编解码的代码逻辑。

手把手教你如何在 NebulaGraph 中新增一种数据类型

本文整理自 NebulaGraph 核心开发 Yee 在直播《聊聊执行计划这件事》中的主题分享。

 # Part 01.一条 Query 的一生
在开始正式地解读执行计划之前，我们先来了解在 NebulaGraph 中，一条查询语句（Query）是如何被校验、生成语法树，到最后被转为逻辑 / 物理的执行计划。而这个 Query 生命周期，无论是 NebulaGraph 原生查询语言 nGQL 或者是从 v2.x 开始兼容的 openCypher，都会经历从字符串到执行计划的过程。这个过程对应到编程语言，是一个编译的过程。

查询语句的生命周期大概有以下几个阶段：
![NebulaGraph](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231205-1.png)

同大多数的数据库类似，一个 Query 的字符串会经过 Parser（词法语法解析器），转成一个 AST（抽象语法树）。而抽象语法树中，不同的查询语句会转成不同的抽象语法树节点。再经过一道 Validator（校验器），进行语句的合法性校验。校验阶段，主要是根据创建点边元素的 Schema 信息（元数据信息）。**由于 NebulaGraph 查询语言设计之初是 schema-based 的设定，因此在语句查询时可（基于语句上下文关系）事先进行相关推导，比如某个查询会用到哪些（Schema）类型。**

这里插个知识点，在 NebulaGraph 中需要注意两个关键类型：EdgeType（Edge）和 Tag（Vertex），像每条 Edge 对应的边类型 EdgeType，其包含的边类型属性都是有具体的 Data Type。此外，便是每个点 Vertex 的属性，每个点的属性都会归类放到对应的 Tag 中，变成其对应的点类型属性 Tag property。类比关系型数据库的话，Tag 相当于是一张表。在 NebulaGraph 中，点和边的属性虽然受到 Schema 约束，但是对某个边的两端点对应的类型是不作约束。因此，插入点或者是修改点，是通过 ID（VID）进行相关操作，与点类型无关。

回到上面的 Query 生命周期，在进行语句校验之后，将之前的词法转成 NebulaGraph 中包含特定算子的执行计划 Execution Planner。随后，执行计划会经过一道优化，通过优化器 Optimizer 变成更优的执行计划，再交由调度器去执行。在传统的数据库中，执行计划分为逻辑计划和物理计划，但在 NebulaGraph 中目前只存在一种计划，便是物理计划，像上面流程图中，Optimizer 处理的计划便是一个物理计划。因此，经过 Optimizer 优化过的 optimized plan，其实是一个可直接执行的物理计划。

而执行计划的运行，主要是由上图的 Executor（其他数据库可能叫 Operator）完成。在执行这层，会涉及到接口交互，例如：同 storage 层“打交道”，会调用 rpc 接口；同 graph 层交互，会调用一些计算算子，像上图加粗的 Project、Filter 这种纯计算算子。除此之外，执行还会涉及到执行模型，比如多线程、Runtime 等问题。社区中大家遇到的一些执行性能问题，可能就同它们有关。

 # Part 02.执行计划示例

`GO 3 STEPS FROM "player100" OVER follow WHERE $$.player.age > 34 YIELD DISTINCT $$.player.name AS name, $$.player.age AS age | ORDER BY $-.age ASC, $-.name DESC;`

示例出处：《nGQL 简明教程 vol.02 执行计划详解与调优》🔗 网址：https://discuss.nebula-graph.com.cn/t/topic/12010

这是一个典型的 nGQL 查询语句，通过 GO 子句遍历，再通过 WHERE 子句进行过滤，最后经由 ORDER BY 排序输出。

下图是上面查询语句生成的执行计划：

![NebulaGraph](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231205-2.png)

如上所示，这个执行计划还是相对比较复杂的。它同大家见惯的关系型数据库的执行计划不大一样，像右下角的 Loop，左上角单依赖的 LeftJoin 可能同大家之前接触的都不大一样。

从结构上看，同 Neo4j 的树 Tree 结构不同，NebulaGraph 中的执行计划，不仅有方向，还有环。为什么 NebulaGraph 的执行计划结构如此不同呢？

`explain format="dot" {
 $a=go 2 steps from "Tim Duncan" over like yield like.likeness as c1;
 $b=go 1 steps from "Tony Parker" over like yield like.likeness as c1;
 $c=yield $a.c1 as c1 union yield $b.c1 as c1;
}`

我们来看一下上面这个例子，这里定义了 a、b、c 变量。a 和 b 之间不存在任何关系，都是几跳遍历之后，输出结果。而 c 则是对这两个变量进行了 union 操作。我们来看看这三条语句对应的执行计划：

![NebulaGraph](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231205-3.png)

可以看到，第一条语句跟第二条语句，还有第三条语句，在执行依赖上是一个顺序依赖：以上图黄色圈为分界线，黄色圈以下为 a 的 plan，黄色圈以上、Union_11 以下为 b 的 plan，Union_11 及其以上为 c 的 plan。

而数据依赖可以看箭头部分，Project_9 的数据依赖输入为 a，它是由 Project_4 提供的，而非顺序上下方的 PassThrough_13，同理，Project_10 数据依赖是 Project_8 的输出变量 b。

这里需要花点时间区分的是：执行依赖和数据依赖。执行依赖就是上图黑色箭头的顺序依赖，而数据依赖则要看算子对应的 inputVar 来自哪里。因此，数据依赖可能同执行依赖是同一个逻辑顺序，也可能是不同的顺序。

造成上述情况的原因是，nGQL 这个查询语言本身是非常灵活的。不同于 SQL 将 a、b、c 分别生成执行计划，生成 3 个执行计划，在 NebulaGraph 中，像上面这种 a、b 没有数据依赖关系，c 依赖 a、b，在生成 plan 的时候，会将其当成拥有一定顺序 subsequential 的语句进行处理。一条执行计划便可完成多条语句的执行，当然非常灵活，但也变相地增加了语句调优的难度。

再来看一个 openCypher 的例子：
`match (v:player)
with v.name as name
match (v:player)--(v2) where v2.name = name
with v2.age as age
match (v:player) where v.age>age
return v.name`

在这个多 MATCH 的例子中，每个 MATCH 都可以作为一个 Pattern。像这条语句中第一个 MATCH 的输出结果传递给下面的第二个 MATCH 变成过滤输入，而第三个 MATCH 的过滤输入则来源于第二个 MATCH 的输出。每个 MATCH 通过 WITH 进行连接，它不同 nGQL，存在 Subquery 的概念，在 openCypher 这里，数据依赖关系是线性，非常自然地通过一个个 WITH 传递给下一个 Pattern 的。如果第一个 WITH 没有将结果带到第二个 MATCH，第三个 MATCH 便无法完成。

正是因为这种线性关系，Neo4j 的执行计划是树状的；而 nGQL 因为查询灵活性的缘故，生成执行计划中有向有环图。

 # Part 03.执行计划的优化

目前，NebulaGraph 只做了 RBO 优化，即：Rule-Based Optimization 基于规则的优化。NebulaGraph 的 RBO 是基于业界流行的实现方法，有些许的差异化，用户可以基于之前的经验或者相关规则，进行 plan 的优化（变形）。

NebulaGraph 的 RBO 是以 memo + bottom up 方式进行的。

![NebulaGraph](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231205-4.png)

在 NebulaGraph 中，每个 plan 的 plan node 会放到一个小组 group 中，每个 group 中的 plan node 语义上等价，上一个 group node 连接到下一个 group，而下一个 group 中有多个 plan node 的话，便可变化出多个 plan。

整个优化的过程，其实是一个迭代的过程，优化器会找到每个 plan 中最叶子的 plan node，同规则集进行匹配，规则集可以查看这里：https://github.com/vesoft-inc/nebula/tree/master/src/graph/optimizer/rule。如果规则匹配上，则将两个 subplan 进行变形，生成新的 subplan，并插入到相关的 group 中。

比如上图左侧的 Filter 算子，它和 GetNeighbors 算子通过某个 rule 匹配上了，便会生成新的 GetNeighbors node，它带有 Filter。新的 GetNeighbors node 会插入到之前的 Filter 所在的 group，因为 memo 的原因，新的 GetNeighbors 便可同之前的 GetNeighbors 连接的 subplan Start 进行连接。

基于 RBO 默认如果匹配上规则，则匹配上规则之后生成的新的 plan 是优于之前的 plan，新的 plan 会直接替代旧的 plan。因此，这个执行计划最后会变成右侧这样。

# Part 04.几个执行计划调优的 flag

上文提到过，执行计划中会有个 Runtime 阶段，下面参数主要是影响 graph 这边 Runtime 阶段的执行效率。

- max_job_size: 每个算子内部并发的最大 job 数；

- min_batch_size: 算子内部并发执行时，切分任务时的最小 batch 行数；

- optimize_appendvertices：AppendVertices 算子内部的性能优化控制，当没有悬挂边时可以打开该项减少 RPC 调用。

max_job_size 主要控制 graph 部分算子的并发程度，同 min_batch_size 配合使用。这和 NebulaGraph 的物化模型有关，在 NebulaGraph 中每个算子在被执行完之后，其结果会被物化到内存中，在下一次迭代的时候去对应内存中捞取数据，而不是通过 Pipeline 的方式进行计算。max_job_size 和 min_batch_size 这两个 flag 控制了迭代过程中每个线程可处理的 batch 数量，从而达到优化的效果。

optimize_appendvertices 参数主要是用来服务 MATCH 语句的，当我们使用 MATCH 时，可能会常遇到一个情况：用 MATCH 去做路径查找时，希望这个路径中是不存在悬挂边的。假如，你知道你的数据中不存在悬挂边，可以设置 optimize_appendvertices 为 true，这样就无需再同 storage 交互去验证是否这条边的起始点存在，从而会节约执行时间。

 # Part 05.执行计划如何看
上面说了些原理，下面可以实操下，教你看懂执行计划，以及如何去优化它。

将 PROFILE 或者是 EXPLAIN 加在对应的语句前面，即可得到相关的执行计划。像这样：

`profile GET SUBGRAPH 5 STEPS FROM "Yao Ming" OUT like where like. likeness > 80 YIELD VERTICES AS nodes, EDGES AS relationshipis;`

`explain GET SUBGRAPH 5 STEPS FROM "Yao Ming" OUT Like where like. likeness > 80 YIELD VERTICES AS nodes, EDGES AS relationshipis;`

如果你不知道数据量的情况下，用 EXPLAIN 可查看对应的执行计划构成，它不包括该语句各个算子的执行时间。

在社区中，常会到一类问题：我通过 SUBGRAPH 进行条件过滤时，是不是每一跳都会应用到边过滤。相信通过这个例子，你就能知道是不是每跳都会应用到条件过滤了。

`Execution Plan (optimize time 41 us)`

生成在终端的这个执行计划是表结构的，通过 id 和 dependence 可查看到对应的依赖关系，从而解决之前提到过的执行计划中有环这种问题。

先看看当中 subgraph 算子信息，我们可以 edge_filter 中带有表达式，如果 edge_filter / tag_filter 中带有表达式，则表示该表达式被计算下推了。

下面是通过 PROFILE 查看到的更具体的执行计划。
![appendvertices](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231205-5.png)

DataCollect 算子有这些参数：

- execTime：graphd 的处理时间；

- rows：返回的数据条数；

- totalTime：从算子起始到到算子退出时间；

- version：像前面章节提到过的 LOOP，其实 LOOP 里面有一个 LOOP body，对应也是一个 subplan。而这个 subplan 则是会被重复执行，且数据放在同一个变量当中，而这个变量则会有多个版本，即 version。假如算子不在 LOOP body 内，则只有一个 verison。默认为 0；

Subgraph 算子有这些参数（同上面已讲解参数去重）：

- resp[]：每个 storage 节点执行的结果；

- exec：storaged 的处理时间，同上面的 graphd 处理时间的 execTime；

- storage_detail：storage 信息，由于 subgraph 需要同 storage 交互，因此由这个字段用来记录 storage 这边 plan node 的执行时间；

- total：storage client 接收到 graphd 请求到 storage client 发送请求的时间，即 storaged 本身的处理时间加上序列化和反序列化的时间；

- vertices：该语句涉及的点的数据；

- total_rpc_time：graphd 调用 storage client 发出请求到接收到请求时间；

 # Part 06.生成执行计划的格式

在刚开始的时候展示的执行计划和实操时展示的执行计划格式并不相同，profile format="" 来完成格式指定，默认为表结构，可通过格式指定，指定为 .dot 格式，在终端复制出来执行计划，前往在线网站：https://dreampuf.github.io/GraphvizOnline/#digraph 进行格式渲染。

以上，便是一个全方位的执行计划讲解。当然你可以通过阅读思为的《nGQL 简明教程 vol.02 执行计划详解与调优》，了解更多的例子从而掌握执行计划。

----
**谢谢你读完本文**(///▽///)

如果你想尝鲜图数据库 NebulaGraph，记得去 GitHub 下载、使用、(^з^)-☆ star 它 -> [GitHub](https://github.com/vesoft-inc/nebula)；如果你有更高的性能、易用性、运维实施等方面的需求，你也可以随时 [联系我们](https://www.nebula-graph.com.cn/contact)，获取进一步的帮助哦~

同大多数的数据库类似，一个 Query 的字符串会经过 Parser（词法语法解析器），转成一个 AST（抽象语法树）。而抽象语法树中，不同的查询语句会转成不同的抽象语法树节点。

从真实案例出发，全方位解读 NebulaGraph 中的执行计划

如果你没有习惯于应对分布式系统环境，可能会对由上述问题引起的异常感到十分困惑。

分布式系统中的麻烦事（下）：真相由多数派定义？

时钟它为什么又是靠不住的。时钟（clocks）和时间（time）都很重要。

分布式系统中的麻烦事（中）：为什么时钟它不可靠？

构建分布式系统和单机软件完全不同。在分布式系统中，系统有一千种奇妙的出错方法，本章将会探讨其中的一部分。

分布式系统中的麻烦事（上）：系统故障，以及不可靠的网络

![开源之夏梅开二度的周子轶](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231123-1.png)

这期 nStar 的专访对象是连续两届翻了 NebulaGraph 牌，和 NebulaGraph 一起完成开源之夏项目的周子轶。去年的他，是一个接口工，完成 NebulaGrpah 和 DataX 的集成，为大家提供了图数据库的实时数据同步功能。而今年的他，依旧是做着和数据相关的事项，这次他把目光瞄准了社区最受欢迎的数据导入工具——NebulaGraph Exchange，为它提供批量删除能力。

而在定专访主题的过程中，NebulaGraph 的运营人员发现他是边忙实习工作，边完成开源之夏的项目任务。而他本人对应届生实习也颇有心得。于是乎，除了常规的开源理解之外的，围绕**实习、开源之夏项目投递**的学生可复制路径专访就此展开。

在开始找项目，找实习之前，我们先看看周子轶眼中的自己：

# 那个名叫周子轶的人

**nebula：正文开始之前，来介绍下自己，让大家了解下你。**

**子轶**：哈喽，大家好，我是周子轶，目前就读于新加坡国立大学计算机专业，之前在某互联网大厂实习，很荣幸两次参加 NebulaGraph 的开源之夏项目，收获颇多。

去年还在校园的我对开源比较懵懂，对 git 使用还很笨拙，但是觉得能够参加开源是很酷的一件事。在浏览众多新颖有趣的社区和项目后，偶然发现图数据库 NebulaGraph 社区，感觉很有意思。因为之前从来没有接触过图数据库，所以，在好奇心的驱使下详细了解了图数据库的应用和基本原理，感觉非常有意思，最后果断 all in 了项目计划书，最终在与导师的沟通指导下顺利结项。

在那次开源之夏，也有幸到 NebulaGraph 社区的公司 vesoft 参观，对公司的氛围和整体环境非常感兴趣，所以萌生了今年继续参加开源之夏，为 NebulaGraph 社区贡献代码。所以，今年又一次报名参加了 NebulaGraph 的开源之夏项目，在实习之后再参加开源工作，感觉整体流程和开发规范上有了很大的提升，整体的开发进度也较为顺利地推进。非常感谢能和 NebulaGraph 二次结缘，期待未来能继续为社区贡献代码，参加开源。

# 找项目？找实习，我有可复制的心得可以和你分享

**nebula：我们循序渐进，先从你熟悉的开源之夏讲起吧。作为两届开源之夏选手，在项目申请这块你有什么心得分享么？**

**子轶**：目前来看，其实开源之夏整体上还挺卷的，可能是受到现在就业形势的影响。我也和同事聊过这个事情，开源之夏经常同一个项目有多人申请。（笑）去年我的 DataX 项目也有 5、6 个人申请。

这种情况下，导师面对这么多申请人的话，他其实主要是根据你的简历，或者是你对这个项目的理解来选人。因此，你对这个项目理解是最关键，怎么体现你的理解？你可以**把申请书，好好写一写，和老师好好沟通下。**

除了项目申请之外，我也想讲讲后期的项目开发的注意事项。

有一点很关键，**项目前期一定要做好时间安排**。当然我是个反面教材，在这开源之夏项目因为是在实习期，整个节奏没太把控好。除了实习之外，学校这边也有零零碎碎的琐事。这导致我和导师安祺约定好的一些事情没有及时地完成。无论什么时候，和人交流就是打造自己的口碑。准时、守信是很重要的，虽然这个过程我和导师安祺也致歉，并解释了缘由，但是这种事情能避免尽量避免。合理的安排时间，遵守和导师的约定是非常重要的。这会让导师觉得你是个守约、可靠的人。

为什么提到守约这种**契约精神**呢？因为开源不像去公司实习，天然有一种约束。做开源之夏项目的话，一般和导师都是线上联系，毕竟远程协作，很有可能项目进度突然就失控了，导致后期做着做着就不想做了。因此，你一定要和导师沟通清楚整个项目，你打算怎么做，什么时间节点交付什么东西。尽早和导师沟通清楚你这边的开发进度，好让他安排后期的任务。

回到开源之夏项目申请这个话题，你可以根据你已有的开发经验，再选择同它相关的项目，申请被通过的概率也高点。

最后，回归兴趣，你要对这个技术栈或者是社区有兴趣，申请书认真好好地写。

**nebula：你之前在实习，现在应届生找实习是不是挺难的？**

**子轶**：感觉上，今年好像觉得比去年要好一些，整体环境或者是开放岗位要多一些，去年确实不太好找。这次找实习，我一共经历了 20 场面试。大厂的话，除了字节跳动应该都面过，像是拼多多、蚂蚁金服这种基本上都面了。当然，有些可能面得不是很好，面挂了。

在**找实习过程中，当时主要是逛北邮人论坛，和 BOSS 直聘。还有一个不能忽视的就是，学长和学姐的内推、朋友圈**。在 3 月之前集中投递一波简历，4 月开始面试，5、6 月基本上实习就定下来了。如果大家要找实习的话，可以 2、3 月就开始看起来，这样差不多赶得上春招实习。 

**nebula：在校大学生的话，可能平时在校园做的项目会比较少，你在实习过程中有什么实习心得可以和其他学生分享下的么？**

**子轶**：其实，我觉得实习和做开源、开源之夏项目有一点很像。以我为例，在想到具体方案之前，个人会觉得这个项目（产品）逻辑会特别很复杂。一旦开始着手去调研，或者是看看相关的源码，再分析一下需求，比如说面向产品的需求，你可以把这个产品需求跟产品经理和 mentor（实习的导师）对清楚，就大概能知道它的一个可实践的技术方案是什么。

像是开源之夏的话，学生一开始是需要提交申请书的。 如果你足够认真去准备的话，通过 Google / 百度 / Bing 其实能搜到一些资料，再基于这些资料可以初步拟定一个方案。但即便没有这些方案，你和项目的导师聊聊你对这个 Project 的理解，也是不错的方式。这点和实习中同 mentor 沟通需求有点相似，你要同 mentor 谈你的需求理解，在此基础上，mentor 会纠正理解或者是延伸下，让实习生了解更多的技术细节。

可能大家在学校的时候，实际开发经验不是很足，没关系的，很多开发任务落实到实际开发的时候，相对来说并没有那么复杂，平时我们也可以从一些简单的项目入手，培养下实操能力。

其实，实习也好，开源之夏做项目也好，整个过程有点像垒积木，你一点一点地开发，开发出来一部分，再自测一下，自测完之后看看和预期符不符合。等开发完所有模块之后，做一个整体的通路测试，这种开发流程还是比较既定的。

**nebula：除了平时可以做做小项目增加实操技能之外，面试的时候，你准备过哪些事情可以和大家分享下的呢？**

**子轶**：比较常规的就是刷面经，一般来说我会**面向技术栈去刷个对应面经**。比如说，这家公司我发现用 C++ 技术栈比较多的，那我就去刷一些 C++ 相关的题。而比较通用的算法题，就会看看哪些是常考的点。此外，计算机基础知识或者是计算机面试的八股文，都是需要去了解下的。但是面试八股文内容比较多，假如你面试准备的时间比较少，就抓最重要的东西，看下哪些内容出现得比较高频。此外，就是因人而异的简历准备了。只要是你简历里面涉及到的项目以及技术点，都得深入去了解、学习下，看看网上的博客或者是视频教程，巩固下技术点，这样即便实习面试的时候，面试官问得深入点，也能应答上。因为常见的面试流程中，面试官一般会让你介绍下自己做的项目，再问一些这个项目中他比较感兴趣，或者是关心的点，可能会再深入地问些技术细节。

# 开源之夏，让我体会到了极客精神

**nebula：其实你已经在实习了，照理来说，实习应该挺忙的，为什么要去做开源之夏的项目？**

**子轶**：怎么说呢，我感觉在做开源之夏之前，我的编程或者说编程概念或者是什么，其实是不太行或者不太合格。我觉得真正地做完开源之夏项目之后，我的能力得到了一个特别大的提升，也很增强自信。因为，其实做项目的第一步就是把环境搭起来，这一点（环境搭建）其实就可以劝退很多人。而当你要去做一个东西的时候，第一点也是不能避免的便是你得会用这个东西，在用之前的话，一套软件运行环境是必须的，有这么一套环境才能做后续的开发。

其实我在本科期间也尝试做过一些项目，好多时候就是不太会搭建项目，接着就是做着做着就放弃了。去年也有这样一个项目，我当时也是在搭环境的时候踩了很多坑。但是最终看博客资料，读一些日志，以及和我的导师去讨论，逐渐把环节搭起来，实现第一步之后，后续就感觉不是那么困难了。

此外，看源码也让我受益良多。像是一些比较大型的开源项目，我要直接给他做一个做开源贡献的话，我会觉得很难，它太复杂了。像去年那个题目 nebula 支持 DataX，因为没有现成的实现方案，当时一点思路也没有。但是和导师沟通之后，去阅读 DataX 集成相关的代码，通过代码了解 DataX 集成其他项目的实现逻辑，以及相关的代码实现，挖掘当中的共同点，最终还是把项目做完了。这个经验，也影响了我现在一些开发习惯，**如果遇到不会的项目，可以去读读相关的源码，加上自己的理解去完成自己的项目。**

所以，今年实习忙之余还去参加这个开源之夏，也是因为觉得开源之夏的话也是一个更好的拓展，因为公司的项目相对来说可能是实习生在打杂。除了这点，我作实习生做的这个东西相对来说比较私密（公司内部系统），面试或者其他交流的话，大家未必能看得到。但是开源之夏的项目的话就不同了，我做的项目里面的代码、实现逻辑大家都能看到，可以进一步地交流。

最后一点是，我觉得做开源之夏的项目，让我感受到了一种极客精神，非常有意思。

**nebula**：你说到做项目，先遇到的难点是环境搭建。所以，（狗头）**你这次又来申请 NebulaGraph 的开源之夏项目是因为环境去年已经搭好了么？**

**子轶**：（微笑）一部分原因是，另外一部分原因是我的确觉得 NebulaGraph 社区很好，产品在大厂里也很有口碑。大家都是基于 NebulaGraph 做二次开发，或者是借鉴一些思路。我跟同学也聊过，如果是图数据库领域的话，NebulaGraph 做的很好，生态也很完善，社区也很不错。（此处应该安排上广告费）

**nebula**：看样子你还是很满意 NebulaGraph 和你的合作。去年是你第一次做开源之夏项目，可能首次实践可能会难一点，但是你过了那道坎之后，现在已经有一定的实践基础了。**你觉得今年做的项目和去年比，会不会更加简单点？**

**子轶**：感觉今年的项目实现起来要比去年要简单，因为有去年的基础。首先，最明显的一点是我有环境，直接就可以用。而代码开发这块的话，今年在实习以及去年的开发经验，让我读代码的能力进一步加强，所以读下相关的代码实现，开发起来也算是得心应手。在读代码的过程中，我也发现其实我很喜欢开源这个模式，开放的代码让我可以不断地深挖，了解作者的实现思路，以及他是如何编写代码的。

# 这些开源作者 / 公司为什么会做开源这件事？

**nebula**：（狗头）**你觉得 NebulaGraph 的导师如何？**

**子轶**：去年 DataX 项目是由志鹏老师带的，他实力很强，人也很耐心（我那时候还是个萌新），包括当时线下去见他，感觉他整个人都很有吸引力，在实际开发中指导也很到位。今年的导师是安祺老师，对整个 Exchange 的项目整体的发展和把控非常清晰，正是因为如此，她可以在现有的任务基础上延伸出来其他的开发事项，让我可以更加了解 Exchange 这个项目，做一些相关的项目优化。

**nebula**：感觉和 NebulaGraph 的导师配合还挺好的样子。其实 NebulaGraph 也是一款开源项目，你在开源之夏的任务开发过程中也会接触相关的开源事项，可能是基本的 git 操作熟悉，或者是提 pr 的礼仪。**你觉得今年和去年，对“开源”这个词，理解有什么不同么？**

**子轶**：去年的理解可能略显浅薄，因为那时候我没有实习经历，算是一个纯小白做和开源相关的事情。当时整个感觉就是：大家都好酷。而当时我们专业厉害的同学，也经常在 GitHub 上写代码。我看过一些国内外知名开源项目，当时就感觉大家都在自愿维护开源项目，而国内有些公司也会把项目代码开源出来，非常诧异：为什么这些开源作者 / 公司会把项目开源出来？尤其是那时候我看到阿里云的一个项目，觉得这个项目实现起来也不容易，开源出来干嘛？甚至会觉得，开源出来是不是会有点亏了。

随着参加开源之夏项目，我接触多了开源项目，慢慢地我开始理解这些项目开源的原因。也许不一定正确，我觉得这些选择开源的公司，它们其实是在维护一个生态，当把那些开源项目建立起来，再逐渐去完善生态的话，可以吸引更多的人去参与进来，不断地去迭代这个社区或者是完善这个项目。按照现在的话，就是这个产品会更加健壮。

**丰富生态、迭代产品、一起建设开源社区**，这是我去年的理解。

今年的理解，因为进现在公司实习之后，我发现其实公司用到了很多开源组件。遇到什么开发任务，有现成的开源解决方案，大家也会直接拿来用，或者是进行部分二开工作。现在我觉得，**开源是一种基石，我们站在之前人的肩膀上，可以走得更远**。

同去年的理解不同，现在我觉得开源不只是丰富、完善某个单一产品，而是开源它可以帮助整个相关行业去进步。对某个行业不是很了解、熟悉的话，通过勘察代码就可以快速入门这个行业，了解现有的行业技术，它是处于什么水平。

以上，周子轶的专访接近尾声，下面进入“Talk is cheap, Show you code”环节：

- 离线数据同步工具 datax-plugin：**https://github.com/nebula-contrib/nebula-datax-pluginNebula-exchange**

- 批量删除数据：

  - **https://github.com/vesoft-inc/nebula-exchange/pull/151**

  - **https://github.com/vesoft-inc/nebula-exchange/pull/154**



----
**谢谢你读完本文**(///▽///)

如果你想尝鲜图数据库 NebulaGraph，记得去 GitHub 下载、使用、(^з^)-☆ star 它 -> [GitHub](https://github.com/vesoft-inc/nebula)；如果你有更高的性能、易用性、运维实施等方面的需求，你也可以随时 [联系我们](https://www.nebula-graph.com.cn/contact)，获取进一步的帮助哦~

这期 nStar 的专访对象是连续两届翻了 NebulaGraph 牌，和 NebulaGraph 一起完成开源之夏项目的周子轶。

开源之夏梅开二度的周子轶，他的实习、找项目之旅

我们在这篇文章中探讨了知识图谱，特别是图数据库 NebulaGraph，是如何结合 LlamaIndex 和 GPT-3.5 为 Philadelphia Phillies 队构建了一个 RAG。

7 种查询策略教你用好 Llama Index 和 NebulaGraph 探索知识图谱

*以下文章来源于开源之夏OSPP ，作者ospp*

![NebulaGraph](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231116-1.png)

本期专访采访人物来自开源之夏 2023 活动 NebulaGraph 社区中选学生——宋昊成同学，他所承担的项目是 NebulaGraph-rust 实现点边扫描接口。

项目链接：
https://summer-ospp.ac.cn/org/prodetail/231190185

![开源之夏 2023 活动 NebulaGraph 社区](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231116-2.png)

# # 关于宋昊成

**OSPP**：请简单介绍一下自己。

**宋昊成**：大家好，我是来自南京航空航天大学的宋昊成，参与了 OSPP 2022 和 OSPP 2023 两届活动，现在在为 NebulaGraph 社区编写 Rust 客户端。业余时间喜欢多接触新的事物，不局限于计算机专业本身。

**OSPP**：最开始是怎么接触到开源之夏的呢？你眼中的开源是什么样的？

**宋昊成**：最开始是受到我的好朋友茂林的影响，他参与了 OSPP 2021。听完他的经历后，我对开源项目产生浓厚兴趣，关注了开源之夏公众号，留意报名和申请时间，并积极申请参与项目。

我眼中的开源是个贴近工业界前沿项目和用户实际问题的活动。我发现很多开源项目的发布，原因是学术界发布了一个新的模型或者算法，社区想集成到自己的框架中。也有用户发现了使用过程中的问题，在 Issue 提出自己的需求或者改进意见，社区发布相应的开源任务。当然，还有很多其他类型的开源项目，但是我觉得都离不开应用价值和实际需求这两个核心方面。

**OSPP**：你有着非常丰富的项目实践、实习与赛事参与经验，可以简单为我们介绍一下么？这些经历在学习或其他方面给你带来了什么？

**宋昊成**：我参与过挑战杯、互联网+、数学建模等比赛，同时也参与了很多项目的开发。这些实践都是我难忘的经历。首先，通过参加各种竞赛教会了我从“不可能”到“可能”的心态转变。很多竞赛从刚接触的不知所云到后期的小有所成，关键在主动学习和不畏困难的态度，坚持下去大部分竞赛其实都能取得比较好的成绩。其次，通过竞赛和项目开发，我认识了来自不同专业的优秀同学，扩展了我的社交圈。最后，这些过往经历在我升学和实习的过程中，也为我提供了不小助力。

# # 参与开源之夏与开源

**OSPP**：这已经是你第二次参与开源之夏活动了，两次参与体验如何？又是什么吸引你再次参加活动的？

**宋昊成**：第一次参加是大四的时候，临近毕业，事情比较多，就匆忙申请了一个项目，可惜申请书还是打磨不够，落选了。今年第二次参加，准备的更加充分，把将近 600 个项目都认真了解了一遍，选定了几个合适的项目，认真撰写申请书。最终，我成功的中选了其中一个项目。被吸引参加活动的原因，还是想亲自感受一下工业界项目的开发，而且能看到自己的项目落地，是很有成就感的事。

**OSPP**：请简单介绍一下你在本届活动中承担的开源项目。

**宋昊成**：我承担的开源项目是《NebulaGraph-rust 实现点边扫描接口》。这个项目的主要目标是开发 NebulaGraph-rust 项目，以支持 NebulaGraph 数据库的 StorageClient 中的 ScanVertex 和 ScanEdge 接口。NebulaGraph 是一个高性能的分布式图数据库，下图是 NebulaGraph 集群的经典架构。NebulaGraph 由三种服务构成：Graph 服务、Meta 服务和 Storage 服务，是一种存储与计算分离的架构。

目前，NebulaGraph-rust 仅支持部分 GraphClient 的接口，访问的是图中的Graph Service。我需要开发一个 StorageClient，访问 Storage Service，并根据返回的 response 实现 ScanVertex 和 ScanEdge 接口。

![参与开源之夏与开源](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231116-3.png)

OSPP：在开发过程中有遇到什么困难或挑战么？你又是如何克服的呢？

宋昊成：开发的过程最大困难是对 Rust 不熟悉吧，当时选这个项目是想借这个机会学习一下 Rust，了解一下这个新兴的语言。不少程序语言编写有很多相似之处，如果会一门其他的很快就可以迁移过去，但是 Rust 的所有权、trait、生命周期等概念，让你按以前的编程习惯编写代码会出现很多问题，所幸最后都解决了（就是 debug 过程有点折磨）。

克服的话，我采取一种渐进的方法。我首先从实现一个最基本的功能开始，确保它能够正常工作，然后在此基础上逐步扩展，最终形成我想要的 mod（模块）或者 crate（包）。此处赞扬一下 Rust 的强大的编译器，出错时会给出非常详细的报错原因和解决方案，大部分问题，按着报错提示修改便可以解决 。在开发过程中，随着对 Rust 的不断学习，也慢慢感受到了 Rust 的魅力。

OSPP：你眼中的 NebulaGraph 是一个什么样的开源社区？之后是否打算继续参与开源社区或开源项目？为什么？

宋昊成：NebulaGraph 在我眼中是个年轻、善于交流、开创性、友善的社区，以前接触的几位社区导师都是很年轻且有实力的开发者。搜索问题中，接触到 NebulaGraph 社区的论坛，上面有很多活跃用户互相交流解决问题，求助者的问题都能很快被解答。开发过程中，社区的导师和助手姐姐都很 nice，反馈的问题都能很快解决，暑假还收到了社区送的礼物和明信片。

之后会继续参与开源社区的活动，毕竟自己开发的项目，会有用户提出 lssues，要根据提出的问题积极维护和完善 Rust 客户端。有机会的话也想参与社区的其他项目，多向社区的大佬学习，成为一个合格的 contributor。

# 关于 NebulaGraph 技术社区


> NebulaGraph 社区是由一群图技术爱好者组成的技术社区，社区主要讨论话题为图分析与数据挖掘、自然语言处理与知识图谱、图数据库 NebulaGraph。而 NebulaGraph 是一款开源分布式图数据库，主项目采用 C++ 编写而成。自 2019 年开源以来，NebulaGraph 在近 300 名国内外 contributor 一起努力之下先后发布了 3 个大版本，提交了过 3.5k+ 次 commit，并获得了 9.5k+ star。
GitHub 地址：https://github.com/vesoft-inc/nebula


>在本次开源之夏活动中，得到开源之夏优秀学子的帮助，实现了在图算法、可视化、数据批处理等方向的优化项目。
开源之夏社区主页：https://summer-ospp.ac.cn/org/orgdetail/119ef0d9-7aac-431d-bb9f-d39864c168ff


**OSPP**：在参与社区贡献的过程中有遇到什么令你印象深刻的事情么？导师和其他社区成员有为你带来什么帮助么？

**宋昊成**：最深刻的是因为我暑假比较忙，时间规划没做好，导致项目开发进度非常缓慢，感觉后续工作量还很多，一度觉得结不了项。此处感谢我的导师米泽双（github: Milittle），他平时工作非常忙，但还是周日抽空跟我开了个会，我们彻聊了一晚上，我提出的问题都给我解答了，也给出了项目基本的实现顺序。

![开源之夏活动](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231116-4.png)

先不用做到尽善尽美，做一个最简单、基础的版本出来，后续再改进。开完会后，因为思路清晰，中间和米导沟通顺畅，我大概写了十天就完成了基本功能。后面又花了几天加上了错误处理和部分代码重构，完成了第一个可交付的版本。

**OSPP**：参加开源之夏活动为你带来了哪些收获？

**宋昊成**：收获最多是自信的增长，做之前会觉得很难，一些名词或者相关技术领域没听说过。但是真正开始去开发项目，伴随着查资料和与导师不断讨论，很多问题也没想象中那么难，重要的是敢于尝试。

# # 寄语

**OSPP**：你身边了解和参与开源项目的同学多吗？你认为参与开源之夏和社区贡献对于在校生的学习和专业提升、就业选择方面有哪些帮助？

**宋昊成**：身边了解开源项目的同学还是比较少，普遍认为离自己比较远，看项目各种技术栈看不懂，望而却步。今年开源之夏走进我们学校宣传，也看到了周围有几位同学参加，能感受到近几年开源的影响在慢慢变大，但是还任重道远。

参与开源之夏和社区贡献，对在校生各方面提升是显而易见的，现在学校科班教授的知识偏研究、系统，脱离工业界所需的技能，参与开源之夏可以亲自感受一个完整的工业界项目是怎么样开发的。在开发过程中，收集资料、学习、和导师沟通，并且独立的完成项目的开发和测试，整个流程下来能很好的锻炼自己。同时今年的不少大厂实习、秋招，招聘信息中都会说明有开源经历是加分项，对找工作是很有帮助的。

**OSPP**：有什么话想对计划参加开源之夏活动的学弟学妹们说?
宋昊成：敢于迈出第一步是成功的一半。我身边不少朋友想参加，看到琳琅满目的项目及陌生的技术栈就退缩了，但其实很多东西都是边学边做，心态要放轻松。

首先应该找到自己感兴趣或者相近的技术栈的项目。在自己写申请书的过程中，思考项目开发过程中的难点和用到的技术，然后根据自己能力评估一下自己能否完成，最后确定是否申请这个项目。我觉得合适的项目，是在不耽误项目结项的前提下能给自己学习到新的东西，带给自身成长的。



----
**谢谢你读完本文**(///▽///)

如果你想尝鲜图数据库 NebulaGraph，记得去 GitHub 下载、使用、(^з^)-☆ star 它 -> [GitHub](https://github.com/vesoft-inc/nebula)；如果你有更高的性能、易用性、运维实施等方面的需求，你也可以随时 [联系我们](https://www.nebula-graph.com.cn/contact)，获取进一步的帮助哦~

本期专访采访人物来自开源之夏 2023 活动 NebulaGraph 社区中选学生——宋昊成同学，他所承担的项目是 NebulaGraph-rust 实现点边扫描接口。

专访｜NebulaGraph 宋昊成：敢于迈出第一步是成功的一半

如果两个事务修改的数据没有交集，则可以安全的并发；否则，就会出现竞态条件。

DDIA精读｜分布式系统中的事务之那些事务隔离级别

*以下文章来源于木鸟杂记 ，作者穆尼奥*

![分布式系统](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231109-1.jpg)

本文先讨论事务的基本概念，快照隔离和可串行化将在后续与你见面。

目录

- 棘手的概念
  - ACID 的含义
    - 原子性（Atomicity）
    - 一致性（Consistency）
    - 隔离性（Isolation）
    - 持久性（Durability）
  - 单对象和多对象操作
    - 单对象写入
    - 界定对多对象事务的需求
    - 故障和终止

在分布式数据系统中，任何问题都有可能发生：

1. 系统侧：数据库系统和硬件系统任何时间都有可能发生故障。

2. 应用侧：使用数据库的应用程序任何时刻都有可能故障。

3. 网络侧：应用程序和数据库间，数据库的多个节点间，随时都有可能断开连接。

4. 多个客户端：并发写入时，可能会有竞态条件和相互覆盖。

5. 半读：一个客户端可能会读到部分更新的数据库。

复杂度不会凭空消失，只会发生转移。如果数据库对这些故障不做任何处理，应用层就需要处理上述所有相关问题，会极大增加应用侧编程复杂度。事务，就是数据库为了解决类似的问题，所提供的一种保证，以简化应用层的编程模型。

简单来说，事务就是将一组语句（或者说操作）打包成一个逻辑单元进行执行，并提供一种保证，这一组操作要么全部成功（ commit，应用到数据库里），要么全部失败（被动 abort，或者主动 rollback），而不会存在只执行了一半的中间状态。此外，如果多个客户端的事务并发执行，会涉及到隔离性的问题，一般来说，数据库允许用户在隔离级别和性能之间做选择。

也可以从时间和空间两个角度来理解事务，从生命周期（时间）来讲，事务要保证一组操作的整体性；从并发控制（空间），事务要做好多个事务间的并发控制。

有了这种语义上的保证，用户在发现事务失败后，可以放心的进行重试，直到成功，就可以确定事务中的所有操作都生效了。但任何便利性都是有代价的，事务便是在一定程度上牺牲了性能和可用性。

这里仅作事务的基本概念讨论，下篇开始针对隔离级别（并发控制）做详细探讨，包括读已提交、快照隔离和可串行化。事务保证和是否分布式在概念上相对正交，但在实现上，分布式系统中事务的实现难度要大的多。

# 棘手的概念

一般来说，现代关系型数据库和一些非关系型数据库，所支持的事务，大多都遵循第一个 SQL 数据库—— IBM System R 所引入的规范。

但近些年来，NoSQL 的发展对事务的概念造成了一些冲击。2000 年后，为了支持大规模分布式数据的存储，NoSQL 引入了分区、冗余，同时部分放弃了对原事务的完整支持，但通过重新定义”事务“，仍然号称支持事务。或者为了商业的宣传，引入相近的名词。

于是出现了两种极端的观点，一是认为事务与可伸缩性不可兼得，大型分布式系统都必须放弃事务支持以保持高可用性和高性能；一是提出事务是保证高要求的应用不丢数据的必要条件。

两种观点都有失偏颇，和任何技术一样，事务有其优点和局限性，为了理解事务背后相关权衡，有必要探究下事务的详细内涵。

## ACID 的含义

说到事务，大家第一反应是 Theo Härder 和 Andreas Reuter 于 1983 提出的 ACID。虽然 ACID 最初提出是为了为数据库中的容错保证给出一种相对精确的描述，但不同数据库对 ACID 的支持并不相同，尤其是 Isolation —— 隔离性。如今，ACID 更多的沦为一个 PR 术语。

下面，将逐一探究 Atomicity、Consistency、Isolation 和 Durability 的精确含义，以此来对事务所要做出的保证建立一个基本的认识。

-  **原子性（Atomicity）**

“原子”一般指最小单位，不可再分。在并发编程中，原子性通常和可见性关联，即一个线程无法看到另一个线程执行的原子操作的中间结果。

但，ACID 的隔离性是描述多个客户端并发的所需要解决的问题，而原子性更多的是描述单个客户端\线程内，一组操作可以被原子的执行，如果执行到一半失败，已经执行的操作可以被全部回滚。

因此，ACID 中原子性所提供的保证是：在发生错误时，会回滚该事务所有已经写入的变更。

这个保证很重要，否则用户在执行到一半出错时，很难知道哪些操作已经生效、哪些操作尚未生效。有了此保证，用户如果发现出错，可以安全的进行重试。

- **一致性（Consistency）**

一致性，是一个被广泛使用的词，在不同上下文中，有不同含义：

1. 多副本，前面讨论了多副本一致性，以及最终一致性的问题。

2. 一致性哈希，是一种分区和调度的方式，在增删机器后，可以较小代价的进行副本迁移和均衡。

3. CAP 定理，一致性指的是线性一致性，是多副本间一致性的一种特例。

4. ACID，数据库在应用程序的视角处于某种”一致性的状态“。

因此，我们使用该术语时，一定要明确其所属上下文，进而明确其含义。具体到 ACID 中，一致性是对某些不变性（invariants） 的维持，所谓不变性，即某些约束条件。如，在银行账户中，在任何时刻，账户余额须等于收入减去支出。

不同于 ACID 中其他性质，一致性是需要应用侧和数据库侧共同维护的：

1. 应用侧需要写入满足应用侧视角约束要求的数据。

2. 数据库侧需要保证多次写入前后，尤其是遇到问题时，维持该约束。

因此，一致性可以表述为，应用侧依赖数据库提供的原子性、隔离性来实现一致性。可见，一致性并非数据库事务本身的一种特性，更多的是应用侧的一种属性。据此，乔・海勒斯坦（Joe Hellerstein）认为，在 Härder 与 Reuter 的论文中，“ACID 中的 C”是“用来凑数的”。

- **隔离性（Isolation）**

多个客户端并发访问数据库时，如果访问的数据没有交集，是可以随意并发的。但如果有交集，则会产生并发问题，或称竞态条件（race condition）。

![隔离性](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231109-2.png)

设有一个计数器，且数据库没有内置原子的自增操作，有两个用户，各自读取当前值，加 1 后写回。如图，期望计数器由 42 变为 44，但由于并发问题，最终变成了 43。

ACID 中隔离性是指，每个事务的执行是互相隔离的，每个事务都可以认为自己是系统中唯一正在运行的事务，因此传统上，教科书将事务隔离形式称为：可串行化（Serializability）。即，如果所有事务都串行执行，则任意时刻必然只有一个事务在执行，从而在根本上消除任何并发问题。

但在实践中，很少用这么强的隔离性，实际上隔离性强弱类似于一个光谱，数据库系统提供商一般会实现其中几个，用户可以根据业务情况在隔离性和性能间进行选择。

下一篇，会详细讨论除可串行化外的几种弱隔离级别。

- **持久性（Durability）**

持久性是一种保证，即事务一旦提交，即使服务器宕机重启、甚至发生硬件故障，已经提交的事务所写入的数据就不会丢失。

在单机数据库中，持久性意味着以数据页（Page）或日志形式（WAL）写入了非易失性存储。在多副本（Replication）数据库中，持久性意味着写入了多数节点。

但，持久性都只能做到某种程度的保证，而非绝对保证，比如：

1. 对于单机，可以容忍宕机。但磁盘坏了就完犊子。

2. 对于多机，可以容忍少数副本损坏，但是多数副本完后也没辙。

因为在现实世界中，存储所涉及到的所有环节，都不是完美的：

- 写入磁盘后宕机，虽然数据没丢，但机器修复或磁盘转移前，数据服务都是不可用的。但冗余（Replication）系统可以解决该问题。

- 一个关联性故障，如软件 bug 或者机房断电，可以同时摧毁一个机房中的所有副本。因此多副本的内存数据库仍要定期持久化到外存。

- 异步复制系统中，当主副本不可用时，由于没来得及同步到多数节点，最近的写入主副本成功的数据可能会丢失。

- 当突然断电时，固态硬盘可能不能保证数据已完整刷盘，甚至用户显式调用 fsync 也无济于事。此外，硬盘驱动可能也会有 bug。

- 磁盘上的数据可能会随着时间逐渐损坏，甚至副本数据也可能同时损坏，此时就只能依赖于备份了。

在实践中，要通过多种手段，比如强制刷盘、校验码、异地复制、定时备份等多种手段来保证数据的持久性，但也只能做到大概率的保证（比如五个九），而非绝对保证。

## 单对象和多对象操作

总结来说，在 ACID 中，原子性和隔离性是数据库对用户进行多个写入时需要提供的保证，并且它们通常假设一个事务中会同时修改多个对象（rows、documents 和 records）。相比单对象事务（single-object transaction），这种多对象事务（multi-objects transaction）是一种更强的保证，且更常用，因为通常多个写入不会只针对单个对象。

设有电子邮件情景，邮箱首页需要如下语句来展示未读邮件数：


```
SELECT COUNT(*) FROM emails WHERE recipient_id = 2 AND unread_flag = true
```

如果邮件过多，为了加快查询，可以使用额外字段将未读邮件数存储存储起来（术语：denormalization），但每次新增、读过邮件之后都要更新该计数值。

如下图，用户 1 插入一封邮件，然后更新未读邮件数；用户 2 先读取读取邮件列表，后读取未读计数。但邮箱列表中显示有新邮件，但未读计数却显示 0。

![单对象和多对象操作](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231109-3.png)

隔离性可以避免此问题，使用户 2 要么看到用户 1 的所有更新，要么看不到任何更新。

下图，说明了原子性保证。如果是事务执行过程中发生错误，原子性会保证如果计数器更新失败，新增的邮件也会被撤销。

![原子性保证](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231109-4.png)

在多对象事务中，一个关键点是如何确定多个操作是否属于同一事务：

- **从物理上来考虑**：可以通过 TCP 连接来确定，在同一个连接中，BEGIN TRANSACTION 和  COMMIT语句之间的所有内容，可以认为属于同一个事务。但会有一些 corner case，如在客户端提交请求后，服务器确认提交之前，网络中断，连接断开，此时客户端则无从得知事务是否被成功提交。

- **从逻辑上来考虑**：使用事务管理器，为每个事务分配一个唯一标识符，从而对操作进行分组。

实际中基本上使用第二种方法。

有一些非关系型数据库，虽然提供 Batch 操作接口，但它们并不一定有事务语义，即可能有些对象成功，另外一些对象操作却失败。

- **单对象写入**

当只更改单个对象时，仍会面临原子性和隔离性的问题。假设，在文档数据库中，你正在写入一个 20 KB 的 JSON 文档：

1. 如果发送了前 10 kb 数据后，网络断开，数据库是否已经存储了这不完整的 10k 数据？

2. 如果该操作是正在覆盖一个老版本同 id 数据，覆盖一半时电源发生故障，数据库是否会存在一半旧值一半新值？

3. 如果有另一个客户端同时在读取该文档，是否会看到半更新状态？

这些问题都非常棘手，如果数据库不提供任何保证，用户侧得写很多的错误处理逻辑。因此，一般的数据库哪怕不支持完整的事务，也会提供针对单个对象的原子性和隔离性。比如，可以使用写前日志来保证原子性，使用锁来保证隔离性。

其他一些数据库，也会提供更复杂的原子支持，如原子的自增操作，从而避免图 7-1 中的交错更新。另一种更泛化的原子性保证是提供单个对象上的 CAS 操作，允许用户原子的执行针对单个对象的 read-modify-write 操作。当然，如果咬文嚼字一下，原子自增（atomic increment），在 ACID 中应该是属于隔离性（Isolation）的范畴，此处的原子自增其实是多线程的概念。

有的 NoSQL 数据库将上述支持宣传为”轻量级事务“，甚而 PR 成”ACID”。但这是极其不负责任的，通常来说，事务是一种将针对多个对象的多个操作封装为一个执行单元的机制。

- **界定对多对象事务的需求**

由于跨机器的分布式事务很难实现、且非常损失性能（可能在一个数量级），很多分布式数据库选择不支持多对象事务。但有些场景确实需要多对象事务，因此一些数据库多将是否打开事务设为一个开关。

因此，在用户侧，在数据库选型时，有必要审视一下是否真的需要多对象事务，键值对模型和单对象事务是否能够满足需求。一些情况下，是足够的，但更多的情景，需要协同更新多个对象：

- 在关系型数据库中，一些表通常会有一些外键。在更新时，需要进行同步更新。

- 在文档型数据库中，相关的数据通常会放到一个文档中，但由于大部分文档数据库不支持 Join，因此不得不使用前文提到的 denormalization 对信息进行冗余存储，便产生了同步更新需求。

- 在支持次级索引的数据库中，数据和对应的多个索引需要进行同步更新。

如果没针对多对象事务，上述保证只能在应用侧实现，徒增复杂度，而且容易出错。

- **故障和终止**

如前所述，事务的一个重要特点是在执行到一半时，可以安全的终止并重试。事务的设计哲学是：当出现违反原子性、隔离性和持久性的危险时，就丢弃而非保留已经发生的修改。

但，另一些场景，如多副本中的无主模型，就采用了“尽力而为”的模型，即尽可能的保证完成任务，如不能完成，也不会回滚已经发生的修改。因此，应用侧需要处理这种半完成的状态。

尽管无脑重试被终止的事务简单且有效，但并不万能：

1. 事务已经被成功提交，但返回给用户时出错。用户如果简单重试，就会使该事务中的操作执行两次，从而造成数据冗余，除非用户在应用代码侧进行去重（如多次执行这些语句，效果一样）。

2. 由于系统负载过高，而造成事务执行失败。如果无脑重试，会进一步加重系统负担。此时可以使用指数后退方式重试，并且限制最大重试次数。

3. 一些临时错误，如死锁、异常、网络抖动和故障切换时，重试才有效；对于一些永久故障，重试是没有意义的。

4. 某事务在数据库之外如有副作用，重试事务时，会造成副作用的多次发生。如果某个事务的副作用是发送邮件，则肯定不希望事务每次重试时都发送一次电子邮件。如果想进行多个系统间的协同，可以考虑两阶段提交。

5. 如果客户端在写入数据时故障，则所有该客户端正在执行的事务所涉及的数据修改都会丢失。


----
**谢谢你读完本文**(///▽///)

如果你想尝鲜图数据库 NebulaGraph，记得去 GitHub 下载、使用、(^з^)-☆ star 它 -> [GitHub](https://github.com/vesoft-inc/nebula)；如果你有更高的性能、易用性、运维实施等方面的需求，你也可以随时 [联系我们](https://www.nebula-graph.com.cn/contact)，获取进一步的帮助哦~

复杂度不会凭空消失，只会发生转移。如果数据库对这些故障不做任何处理，应用层就需要处理上述所有相关问题，会极大增加应用侧编程复杂度。

DDIA精读｜分布式系统中的事务之那些棘手的概念们

*以下文章来源于木鸟杂记 ，作者穆尼奥*

![性能好的编码如何设计](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231114-1.jpg)

上文[《数据库底层到底是如何处理查询和存储？》](https://www.nebula-graph.com.cn/posts/nebulagraph-oltp)讲了存储引擎，本章继续下探，探讨编码相关问题。

所有涉及跨进程通信的地方，都需要对数据进行编码（Encoding），或者说序列化（Serialization）。因为持久化存储和网络传输都是面向字节流的。序列化本质上是一种“降维”操作，将内存中高维的数据结构降维成单维的字节流，于是底层硬件和相关协议，只需要处理一维信息即可。

编码主要涉及两方面问题：

1. 如何编码能够节省空间、提高性能。

2. 如何编码以适应数据的演化和兼容。

第一小节，以几种常见的编码工具（JSON，XML，Protocol Buffers 和 Avro）为例，逐一探讨了其如何进行编码、如何进行多版本兼容。这里引出了两个非常重要的概念：

1. 向后兼容（backward compatibility）：当前代码可以读取旧版本代码写入的数据。

2. 向前兼容（forward compatibility）：当前代码可以读取新版本代码写入的数据。

*翻译成中文后，很容易混淆，主要原因在于“后”的歧义性，到底指身后（过去），还是指之后（将来），私以为还不如翻译为，兼容过去和兼容将来。但为了习惯，后面行文仍然用向后/前兼容。*

其中，向后兼容比较常见，因为时间总是向前流逝，版本总是升级，那么升级之后的代码总要处理历史积压的数据，自然会产生向后兼容的问题。向前兼容比较少见，书中给出的例子是多实例滚动升级，但其持续时间也很短。

下一篇文章会结合几个具体的应用场景：数据库、服务和消息系统，来分别谈了相关数据流中涉及到的编码与演化。

# 数据编码的格式

![数据编码的格式](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231114-3.jpg)

编码（Encoding）有多种称谓，如**序列化**（serialization）或**编组**（marshalling）。对应的，**解码**（Decoding）也有多种别称，**解析**（Parsing），**反序列化**（deserialization），**反编组** (unmarshalling）。

- 为什么内存中数据和外存、网络中的会有如此不同呢？在内存中，借助编译器，我们可以将内存解释为各种数据结构；但在文件系统和网络中，我们只能通过 seek\read 等几个有限的操作来流式地读取字节流。那 mmap 呢？

- 编码和序列化撞车了？在事务中，也有序列化相关的术语，所以这里专用编码，以避免歧义。

- 编码（encoding）和加密（encryption）？研究的范畴不太一样，编**码是为了持久化或者传输，着重点在格式和演化；而加密是为了安全，着重点在于安全、防破解**。

# 编程语言内置

很多编程语言内置了一些缺省的编码方法：

1. Java 有  java.io.Serializable

2. Ruby 有  Marshal

3. Python 有  pickle

如果你确定你的数据只会被某种特定的语言所读取，那么这种内置的编码方法很好用。比如深度学习研究员因为基本都用 Python，所以常会把数据以 pickle 的格式传来传去。

但这些编程语言内置的编码格式有以下缺点：

1. 和特定语言绑定

2. 安全问题

3. 兼容性支持不够

4. 效率不高

# JSON、XML 及其二进制变体

JSON，XML 和 CSV 属于常用的文本编码格式，其好处在于肉眼可读，坏处在于不够紧凑，占空间较多。

JSON 最初由 JavaScript 引入，因此在 Web Service 中用的较多，当然随着 Web 的火热，现在成为了比较通用的编码格式，比如很多日志格式就是 JSON 的。

XML 比较古老了，比 JSON 冗余度还高，有时候配置文件中会用，但总体而言用的越来越少了。

CSV（以逗号\TAB、换行符分割）还算紧凑，但是表达能力有限。数据库表导出有时会用。

除了不够紧凑外，文本编码（text encoding） 还有以下缺点：

1. **对数值类型支持不够**。CSV 和 XML 直接不支持，万物皆字符串。JSON 虽区分字符串和数值，但是不进一步区分、细分数值类型。可以理解，毕竟文本编码嘛，主要还是面向字符串。

2. **对二进制数据支持不够**。支持 Unicode，但是对二进制串支持不够，可能会显示为乱码。虽然可以通过 BASE64 编码来绕过，但有点做无用功的感觉。

3. **XML 和 JSON 支持额外的模式**。模式会描述数据的类型，告诉你如何理解数据。配合这些模式语言，虽然可以让 XML 和 JSON 变得强大，但是大大增加了复杂度。

4. **CSV 没有任何模式**。

凡事讲究够用，很多场景下需要数据可读，并且不关心编码效率，那么这几种编码格式就够用了。

## 二进制编码

如果数据只被单一程序读取，不需要进行交换，不需要考虑易读性等问题。则可以用二进制编码，在数据量到达一定程度后，二进制编码所带来的空间节省、速度提高都很可观。

因此，JSON 有很多二进制变种：MessagePack、BSON、BJSON、UBJSON、BISON 和 Smile 等。

对于下面例子，


```
{
  "userName": "Martin",
  "favoriteNumber": 1337,
  "interests": ["daydreaming", "hacking"]
}
```

如果用 MessagePack 来编码，则为：

![用 MessagePack 来编码](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231114-4.png)

可以看出其基本编码策略为：使用类型，长度，bit 串，顺序编码，去掉无用的冒号、引号、花括号。

从而将 JSON 编码的 81 字节缩小到了 66 字节，微有提高。

# Thrift 和 Protocol Buffers

Thrift 最初由 Facebook，ProtoBuf 由 Google 在 07~08 年左右开源。他们都有对应的 RPC 框架和编解码工具。表达能力类似，语法也类似，在编码前都需要由接口定义语言（IDL）来描述模式：


```
struct Person {
    1: required string       userName,
    2: optional i64          favoriteNumber,
    3: optional list<string> interests
}
```


```
message Person {
    required string user_name       = 1;
    optional int64  favorite_number = 2;
    repeated string interests       = 3;
}
```

IDL 是编程语言无关的，可以利用相关代码生成工具，可以将上述 IDL 翻译为指定语言的代码。即，集成这些生成的代码，无论什么样的语言，都可以使用同样的格式编解码。

这也是不同 service 可以使用不同编码语言，且能够互相通信的基础。

此外，Thrift 还支持多种不同的编码格式，常用的有：Binary、Compact、JSON。可以让用户自行在：编码速度、占用空间、可读性方便进行取舍。

![Thrift 和 Protocol Buffers](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231114-5.png)

可以看出其特点：

1. **使用 field tag 编码**。field tag 其实蕴含了字段类型和名字。

2. **使用类型、tag、长度、bit 数组的顺序编码**。

![使用 field tag 编码](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231114-6.png)

相比 Binary Protocol，Compact Protocol 由以下优化：

1. filed tag 只记录 delta。

2. 从而将 field tag 和 type 压缩到一个字节中。

3. 对数字使用变长编码和 Zigzag 编码。

ProtoBuf 与 Thrift Compact Protocol 编码方式很类似，也用了变长编码和 Zigzag 编码。但 ProtoBuf 对于数组的处理与 Thrift 显著不同，使用了 repeated 前缀而非真数组，好处后面说。

![ProtoBuf](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231114-7.png)

## 字段标号和模式演变

**模式**，即有哪些字段，字段分别为什么类型。

随着时间的推移，业务总会发生变化，我们也不可避免的增删字段，修改字段类型，即**模式演变**。

在模式发生改变后，需要：

1. **向后兼容**：新的代码，在处理新的增量数据格式的同时，也得处理旧的存量数据。

2. **向前兼容**：旧的代码，如果遇到新的数据格式，不能 crash。

ProtoBuf 和 Thrift 是怎么解决这两个问题的呢？

**字段标号 + 限定符（optional、required）**

1. 向后兼容：新加的字段需为 optional。这样在解析旧数据时，才不会出现字段缺失的情况。 

2. 向前兼容：字段标号不能修改，只能追加。这样旧代码在看到不认识的标号时，省略即可。

## 数据类型和模式演变

修改数据类型比较麻烦：只能够在相容类型中进行修改。

如不能将字符串修改为整型，但是可以在整型内修改：32 bit 到 64 bit 整型。

ProtoBuf 没有列表类型，而有一个 repeated 类型。其好处在于兼容数组类型的同时，支持将可选（optional）单值字段，修改为多值字段。修改后，旧代码在看到新的多值字段时，只会使用最后一个元素。

Thrift 列表类型虽然没这个灵活性，但是可以嵌套呀。

# Avro 

Apache Avro 是 Apache Hadoop 的一个子项目，专门为数据密集型场景设计，对模式演变支持的很好。**支持 Avro IDL 和 JSON 两种模式语言**，前者适合人工编辑，后者适合机器读取。


```
record Person {
    string                userName;
    union { null, long }  favoriteNumber = null;
    array<string>         interests;
}
```


```
{
  "type": "record",
  "name": "Person",
  "fields": [
    { "name": "userName", "type": "string" },
    { "name": "favoriteNumber", "type": ["null", "long"], "default": null },
    { "name": "interests", "type": { "type": "array", "items": "string" } }
  ]
}
```

可以看到 Avro 没有使用字段标号。

仍是编码之前例子，Avro 只用了 32 个字节，为什么呢？他没有编入类型。

![Avro](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231114-8.png)

因此，Avro 必须配合模式定义来解析，如 Client-Server 在通信的握手阶段会先交换数据模式。

## 写入模式和读取模式

没有字段标号，Avro 如何支持模式演进呢？答案是显式的使用两种模式。

即，在对数据进行编码（写入文件或者进行传输）时，使用模式 A，称为写入模式（writer schema）；在对数据进行解码（从文件或者网络读取）时，使用模式 B，称为读取模式（reader schema），而两者不必相同，只需兼容。

也就是说，只要模式在演进时，是兼容的，那么 Avro 就能够处理向后兼容和向前兼容。

向后兼容：新代码读取旧数据。即读取时首先得到旧数据的写入模式（即旧模式），然后将其与读取模式（即新模式）对比，得到转换映射，即可拿着此映射去解析旧数据。

向前兼容：旧代码读取新数据。原理类似，只不过是需要得到一个逆向映射。

在由写入模式到读取模式建立映射时有一些规则：

1. **使用字段名来进行匹配**。因此写入模式和读取模式字段名顺序不一样无所谓。

2. **忽略多出的字段**。

3. **对缺少字段填默认值**。

![写入模式和读取模式](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231114-9.png)

## 模式演变规则

那么如何保证写入模式的兼容呢？

1. 在增删字段时，只能添加或删除具有默认值的字段。

2. 在更改字段类型时，需要 Avro 支持相应的类型转换。

Avro 没有像 ProtoBuf、Thrift 那样的 optional 和 required 限定符，是通过 union 的方式，里指定默认值，甚至多种类型：


```
union {null, long, string} field;
```

注：默认值必须是联合的第一个分支的类型。

更改字段名和在 union 中添加类型，都是向后兼容，但是不能向前兼容的，想想为什么？

## 如何从编码中获取写入模式

对于一段给定的 Avro 编码数据，Reader 如何从其中获得其对应的写入模式？

这取决于不同的应用场景。

1. **所有数据条目同构的大文件**：典型的就是 Hadoop 生态中。如果一个大文件所有记录都使用相同模式编码，则在文件头包含一次写入模式即可。

2. **支持模式变更的数据库表**：由于数据库表允许模式修改，其中的行可能写入于不同模式阶段。对于这种情况，可以在编码时额外记录一个模式版本号（比如自增），然后在某个地方存储所有的模式版本。解码时，通过版本去查询对应的写入模式即可。

3. **网络中发送数据**：在两个进程通信的握手阶段，交换写入模式。比如在一个 session 开始时交换模式，然后在整个 session 生命周期内都用此模式。

## 动态生成数据中的模式

Avro 没有使用字段标号的一个好处是，不需要手动维护字段标号到字段名的映射，这对于动态生成的数据模式很友好。

书中给的例子是对数据库做导出备份，注意和数据库本身使用 Avro 编码不是一个范畴，此处是指导出的数据使用 Avro 编码。

在数据库表模式发生改变前后，Avro 只需要在导出时依据当时的模式，做相应的转换，生成相应的模式数据即可。但如果使用 PB，则需要自己处理多个备份文件中，字段标号到字段名称的映射关系。其本质在于，Avro 的数据模式可以和数据存在一块，但是 ProtoBuf 的数据模式只能体现在生成的代码中，需要手动维护新旧版本备份数据与 PB 生成的代码间的映射。

## 代码生成和动态语言

Thrift 和 Protobuf 会依据语言无关的 IDL 定义的模式，生成给定语言的编解码的代码。这对静态语言很有用，因为它允许利用 IDE 和编译器进行类型检查，并且能够提高编解码效率。

**上述思路本质上在于，将模式内化到了生成的代码中**。

但对于动态语言，或者说解释型语言，如 JavaScript、Ruby 或 Python，由于没有了编译期检查，生成代码的意义没那么大，反而会有一定的冗余。这时 Avro 这种支持不生成代码的框架就节省一些，它可以将模式写入数据文件，读取时利用 Avro 进行动态解析即可。

# 模式的优点

**模式的本质是显式类型约束，即，先有模式，才能有数据**。

相比于没有任何类型约束的文本编码 JSON，XML 和 CSV，Protocol Buffers，Thrift 和 Avro 这些基于显式定义二进制编码优点有：

1. 省去字段名，从而更加紧凑。

2. 模式是数据的注释或者文档，并且总是最新的。

3. 数据模式允许不读取数据，仅比对模式来做低成本的兼容性检查。

4. 对于静态类型来说，可以利用代码生成做编译时的类型检查。

以上为 DDIA 精读的第四章上篇：编码，在下篇将会同大家分享几种主流的数据流模型。

----
**谢谢你读完本文**(///▽///)

如果你想尝鲜图数据库 NebulaGraph，记得去 GitHub 下载、使用、(^з^)-☆ star 它 -> [GitHub](https://github.com/vesoft-inc/nebula)；如果你有更高的性能、易用性、运维实施等方面的需求，你也可以随时 [联系我们](https://www.nebula-graph.com.cn/contact)，获取进一步的帮助哦~

序列化本质上是一种“降维”操作，将内存中高维的数据结构降维成单维的字节流，于是底层硬件和相关协议，只需要处理一维信息即可。

文章

标签