字节跳动开源 dynamicgo ：基于原始字节流高性能 + 动态化 Go 数据处理

InfoQ 10-01 5572

前言：

现在大家对“go 数据处理”大体比较关心，我们都需要分析一些“go 数据处理”的相关资讯。那么小编在网上收集了一些关于“go 数据处理””的相关内容，希望兄弟们能喜欢，我们一起来了解一下吧！

作者 | 字节跳动技术团队

策划 | 凌敏

仓库地址：

背景

当前，Thrift 是字节内部主要使用的 RPC 序列化协议，在 CloudWeGo/Kitex 项目中优化和使用后，性能相比使用支持泛型编解码的协议如 JSON 有较大优势。但是在和业务团队进行深入合作优化的过程中，我们发现一些特殊业务场景并不能享受静态化代码生成所带来的高性能：

动态反射：动态地读取、修改、裁剪数据包中某些字段，如隐私合规场景中字段屏蔽；数据编排：组合多个子数据包进行排序、过滤、位移、归并等操作，如某些 BFF (Backend For Frontent) 服务；协议转换：作为代理将某种协议的数据转换另一种协议，如 http-rpc 协议转换网关；泛化调用：需要秒级热更新或迭代非常频繁的 RPC 服务，如大量 Kitex 泛化调用（generic-call）用户。

不难发现，这些业务场景都具有难以统一定义静态 IDL 的特点。即使可以通过分布式 sidecar 技术规避这个问题，也往往因为业务需要动态更新而放弃传统代码生成方式，诉诸某些自研或开源的 Thrift 泛型编解码库进行泛化 RPC 调用。

我们经过性能分析发现，目前这些库相比代码生成方式有巨大的性能下降。以字节某 BFF 服务为例，仅仅 Thrift 泛化调用产生的 CPU 开销占比就将近 40%，这几乎是正常 Thrift RPC 服务的 4 到 8 倍。因此，我们自研了一套能动态处理 RPC 数据（不需要代码生成）同时保证高性能的 Go 基础库 —— dynamicgo。

设计与实现

首先要搞清楚当前这些泛化调用库性能为什么差呢？其核心原因是：采用了某种低效泛型容器来承载中间处理过程中的数据（典型如 thrift-iterator 中的 map[string]interface{}）。众所周知，Go 的堆内存管理代价是极高的（GC +heap bitmap），而采用 interface 不可避免会带来大量的内存分配。但实际上相当多的业务场景并不真正需要这些中间表示。比如 http-thrift API 网关中的纯协议转换场景，其本质诉求只是将 JSON（或其它协议）数据依据用户 IDL 转换为 Thrift 编码（反之亦然），完全可以基于输入的数据流逐字进行翻译。

同样，我们也统计了抖音某 BFF 服务中泛化调用的具体代码，发现真正需要进行读（Get）和写（Set）操作的字段占整个数据包字段不到 5%，这种场景下完全可以对不需要的字段进行跳过（Skip）处理而不是反序列化。而 dynamicgo 的核心设计思想是：基于原始字节流和动态类型描述原地（in-place）进行数据处理与转换。为此，我们针对不同的场景设计了不同的 API 去实现这个目标。

动态反射

对于 thrift 反射代理的使用场景，归纳起来有如下使用需求：

有一套完整结构自描述能力，可表达 scalar 数据类型，也可表达嵌套结构的映射、序列等关系；支持增删查改（Get/Set/Index/Delete/Add）与遍历（ForEach）；保证数据可并发读，但是不需要支持并发写。等价于 map[string]interface{} 或 []interface{}

这里我们参考了 Go reflect 的设计思想，把通过 IDL 解析得到的准静态类型描述（只需跟随 IDL 更新一次）TypeDescriptor 和原始数据单元 Node 打包成一个完全自描述的结构——Value，提供一套完整的反射 API。

// IDL 类型描述type TypeDescriptor interface {    Type()          Type // 数据类型    Name()          string // 类型名称    Key()           *TypeDescriptor   // for map key    Elem()          *TypeDescriptor   // for slice or map element    Struct()        *StructDescriptor // for struct}// 纯TLV数据单元type Node struct {    t Type // 数据类型    v unsafe.Pointer // buffer起始位置    l int // 数据单元长度}// Node + 类型描述descriptortype Value struct {    Node    Desc thrift.TypeDescriptor}

复制代码

这样，只要保证 TypeDescriptor 包含的类型信息足够丰富，以及对应的 thrift 原始字节流处理逻辑足够健壮，甚至可以实现数据裁剪、聚合等各种复杂的业务场景。

协议转换

协议转换的过程可以通过有限状态机（FSM）来表达。以 JSON->Thrift 流程为例，其转换过程大致为：

预加载用户 IDL，转换为运行时的动态类型描述 TypeDescriptor；从输入字节流中读取一个 json 值，并判断其具体类型（object/array/string/number/bool/null)：如果是 object 类型，继续读取一个 key，再通过对应的 STRUCT 类型描述找到匹配字段的子类型描述；如果是 array 类型，递归查找类型描述的子元素类型描述；其它类型，直接使用当前类型描述。基于得到的动态类型描述信息，将该值转换为等价的 Thrift 字节，写入到输出字节流中；更新输入和输出字节流位置，跳回 2 进行循环处理，直到输入终止（EOF）。

图1 JSON2Thrift 数据转换流程

整个过程可以完全做到 in-place 进行，仅需为输出字节流分配一次内存即可。

数据编排

与前面两个场景稍微有所不同，数据编排场景下可能涉及数据位置的改变（异构转换），并且往往会访问大量数据节点（最坏复杂度 O(N) )。在与抖音隐私合规团队的合作研发中我们就发现了类似问题。它们的一个重要业务场景：要横向遍历某一个 array 的子节点，查找是否有违规数据并进行整行擦除。这种场景下，直接基于原始字节流进行查找和插入可能会带来大量重复的 skip 定位、数据拷贝开销，最终导致性能劣化。

因此我们需要一种高效的反序列化（带有指针）结构表示来处理数据。根据以往经验，我们想到了 DOM （Document Object Model），这种结构被广泛运用在 JSON 的泛型解析场景中（如 rappidJSON、sonic/ast），并且性能相比 map+interface 泛型要好很多。

要用 DOM 来描述一个 Thrift 结构体，首先需要一个能准确描述数据节点之间的关系的定位方式 —— Path。其类型应该包括 list index、map key 以及 struct field id 等。

type PathType uint8 const (    PathFieldId PathType = 1 + iota // STRUCT下字段ID    PathFieldName // STRUCT下字段名称    PathIndex // SET/LIST下的序列号    PathStrKey // MAP下的string key    PathIntkey // MAP下的integer key    PathObjKey// MAP下的object key)type PathNode struct {    Path            // 相对父节点路径    Node            // 原始数据单元    Next []PathNode // 存储子节点 }

复制代码

在 Path 的基础上，我们组合对应的数据单元 Node，然后再通过一个 Next 数组动态存储子节点，便可以组装成一个类似于 BTree 的泛型结构。

图2 thrift DOM 数据结构

这种泛型结构比 map+interface 要好在哪呢？首先，底层的数据单元 Node 都是对原始 thrift data 的引用，没有转换 interface 带来的二进制编解码开销；其次，我们的设计保证所有树节点 PathNode 的内存结构是完全一样，并且由于父子关系的底层核心容器是 slice，我们又可以更进一步采用内存池技术，将整个 DOM 树的子节点内存分配与释放都进行池化从而避免调用 go 堆内存管理。测试结果表明，在理想场景下（后续反序列化的 DOM 树节点数量小于等于之前反序列化节点数量的最大值——这由于内存池本身的缓冲效应基本可以保证），内存分配次数可为 0，性能提升 200%！（见【性能测试-全量序列化/反序列化】部分）。

性能测试

这里我们分别定义简单（Small)、复杂（Medium) 两个基准结构体分别在比较不同数据量级下的性能，同时添加简单部分（SmallPartial）、复杂部分（MediumPartial）两个对应子集，用于【反射-裁剪】场景的性能比较：

Small：114B，6 个有效字段SmallPartial：small 的子集，55B，3 个有效字段Medium: 6455B，284 个有效字段MediumPartial: medium 的子集，1922B，132 个有效字段

Small：

Medium：

SmallPartial：

MediumPartial：

其次，我们依据上述业务场景划分为反射、协议转换、全量序列化/反序列化三套 API，并以代码生成库 kitex/FastAPI、泛化调用库 kitex/generic、JSON 库 sonic 为基准进行性能测试。其它测试环境均保持一致：

Go 1.18.1CPU intel i9-9880H 2.3GHZOS macOS Monterey 12.6

kitex/FastAPI：

kitex/generic：

sonic：

反射

1. 代码

dynamicgo/testdata/baseline_tg_test.go

2. 用例

GetOne：查找字节流中最后 1 个数据字段GetMany：查找前中后 5 个数据字段MarshalMany：将 GetMany 中的结果进行二次序列化SetOne：设置最后一个数据字段SetMany：设置前中后 3 个节点数据MarshalTo：将大 Thrift 数据包裁剪为小 thrift 数据包（Small -> SmallPartial 或 Medium -> MediumParital）UnmarshalAll+MarshalPartial：代码生成/泛化调用方式裁剪——先反序列化全量数据再序列化部分数据。效果等同于 MarshalTo。

3. 结果

简单（ns/OP）复杂（ns/OP）

4. 结论

dynamicgo 一次查找+写入开销大约为代码生成方式的 2 ~ 1/3、为泛化调用方式的 1/12 ~ 1/15，并随着数据量级增大优势加大；dynamicgo thrift 裁剪开销接近于代码生成方式、约为泛化调用方式的 1/10～1/6，并且随着数据量级增大优势减弱。协议转换

1. 代码

JSON2Thrift: dynamicgo/testdata/baseline_j2t_test.goThriftToJSON: dynamicgo/testdata/baseline_t2j_test.go

2. 用例

JSON2thrift：JSON 数据转换为等价结构的 thrift 数据thrift2JSON：将 thrift 数据转换为等价结构的 JSON 数据sonic + kitex-fast：表示通过 sonic 处理 json 数据（有结构体），通过 kitex 代码生成处理 thrift 数据

3. 结果

简单（ns/OP）复杂（ns/OP）

4. 结论

dynamicgo 协议转换开销约为代码生成方式的 1～2/3、泛化调用方式的 1/4～1/9，并且随着数据量级增大优势加大；全量序列化/反序列化