Fury是一个基于JIT动态编译和零拷贝的多语言序列化框架,支持Java/Python/Golang/ JavaScript/C++等语言,提供全自动的对象多语言/跨语言序列化能力,和相比JDK最高170倍的性能。
代码仓库 GitHub 地址为:https://github.com/alipay/fury
背景
序列化是系统通信的基础组件,在大数据、AI框架和云原生等分布式系统中广泛使用。当对象需要跨进程、跨语言、跨节点传输、持久化、状态读写、复制时,都需要进行序列化,其性能和易用性影响运行效率和开发效率。
静态序列化框架protobuf/flatbuffer/thrift由于不支持对象引用和多态、需要提前生成代码等原因,无法作为领域对象直接面向应用进行跨语言开发。而动态序列化框架JDK序列化/Kryo/Fst/Hessian/Pickle等,尽管提供了易用性和动态性,但不支持跨语言,且性能存在显著不足,并不能满足高吞吐、低延迟和大规模数据传输场景需求。
因此,我们开发了一个新的多语言序列化框架Fury,并正式在Github开源。通过一套高度优化的序列化基础原语,结合JIT动态编译和Zero-Copy等技术,同时满足了性能、功能和易用性的需求,实现了任意对象自动跨语言序列化,并提供极致的性能。
Fury简介
Fury是一个基于JIT动态编译和零拷贝的多语言序列化框架,提供极致的性能和易用性:
- 支持主流编程语言Java/Python/C++/Golang/JavaScript,其它语言可轻易扩展;
- 统一的多语言序列化核心能力:
- 高度优化的序列化原语;
- Zero-Copy序列化支持,支持Out of band序列化协议,支持堆外内存读写;
- 基于JIT动态编译技术在运行时异步多线程自动生成序列化代码优化性能,增加方法内联、代码缓存和消除死代码,减少虚方法调用/条件分支/Hash查找/元数据写入/内存读写等;
- 多协议支持:兼顾动态序列化的灵活性和易用性,以及静态序列化的跨语言能力。
- Java序列化:
- 无缝替代JDK/Kryo/Hessian,无需修改任何代码,但提供最高170x的性能,可以大幅提升高性能场景RPC调用、数据传输和对象持久化效率;
- 100%兼容JDK序列化,原生支持JDK自定义序列化方法writeObject/readObject/writeReplace/readResolve/readObjectNoData
- 跨语言对象图序列化:
- 多语言/跨语言自动序列化任意对象,无需创建IDL文件、手动编译schema生成代码以及将对象转换为中间格式;
- 多语言/跨语言自动序列化共享引用和循环引用,不需要关心数据重复或者递归错误;
- 支持对象类型多态,多个子类型对象可以同时被序列化;
- 行存序列化:
- 提供缓存友好的二进制随机访问行存格式,支持跳过序列化和部分序列化,适合高性能计算和大规模数据传输场景;
- 支持和Arrow列存自动互转;
序列化核心能力
尽管不同的场景对序列化有需求,但序列化的底层操作都是类似的。因此Fury定义和实现了一套序列化的基础能力,基于这套能力能够快速构建不同的多语言序列化协议,并通过编译加速等优化具备高性能。同时针对一种协议在基础能力上的性能优化,也能够让所有的序列化协议都受益。
序列化原语
序列化涉及的常见操作主要包括:
- bitmap位操作
- 整数编解码
- 整数压缩
- 字符串创建&拷贝优化
- 字符串编码:ASCII/UTF8/UTF16
- 内存拷贝优化
- 数组拷贝压缩优化
- 元数据编码&压缩&缓存
Fury针对这些操作在每种语言内部都做了大量的优化,结合SIMD指令和语言高级特性,将性能推到极致,从而方便不同协议使用。
零拷贝序列化
在大规模数据传输场景,一个对象图内部往往有多个binary buffer,而序列化框架在序列化过程当中会把这些数据写入一个中间buffer,引入多次耗时内存拷贝。Fury借鉴了pickle5、ray以及arrow的零拷贝设计,实现了一套Out-Of-Band序列化协议,能够把一个对象图当中的所有binary buffer直接抓取出来,避免掉这些buffer的中间拷贝,将序列化期间的内存拷贝开销降低到0。
下图是Fury关闭引用支持时Zero-Copy的大致序列化过程。
目前Fury内置了以下类型的Zero-Copy支持:
- Java:所有基本类型数组、ByteBuffer、ArrowRecordBatch、VectorSchemaRoot
- Python:array模块的所有array、numpy数组、pyarrow.Table、pyarrow.RecordBatch
- Golang:byte slice
用户也可以基于Fury的接口扩展新的零拷贝类型。
JIT动态编译加速
对于要序列化的自定义类型对象,其中通常包含大量类型信息,Fury利用这些类型信息在运行时直接生成高效的序列化代码,将大量运行时的操作在动态编译阶段完成,从而增加方法内联和代码缓存,减少虚方法调用/条件分支/Hash查找/元数据写入/内存读写等,最终大幅加速了序列化性能。
对于Java语言,Fury实现了一套运行时代码生成框架,定义了一套序列化逻辑的算子表达式IR,在运行时基于对象类型的泛型信息进行类型推断,然后构建一颗描述序列化代码逻辑的表达式树,根据表达式树生成高效的Java代码,再在运行时通过Janino编译成字节码,再加载到用户的ClassLoader里面或者Fury创建的ClassLoader里面,最终通过Java JIT编译成高效的汇编代码。
由于JVM JIT会跳过大方法编译和内联,Fury也实现了一套优化器,将大方法递归拆分成小方法,这样就保证了Fury生成的所有代码都可以被编译和内联,压榨JVM的性能到极致。
同时Fury也支持异步多线程动态编译,将不同序列化器的代码生成任务提交到线程池执行,在编译完成之前使用解释模式执行,从而保证不会出现序列化毛刺,不需要提前预热所有类型的序列化。
Python和JavaScript场景也是采用的类似代码生成方式,这样的生成方式开发门槛低,更容易排查问题。
由于序列化需要密切操作每种编程语言的对象,而编程语言并没有暴露内存模型的低阶API,通过Native方法调用存在较大开销,因此我们并不能通过LLVM构建一个统一的序列化器JIT框架,而是需要在每种语言内部结合语言特性实现特定的代码生成框架以及序列化器构建逻辑。
静态代码生成
尽管JIT编译能够大幅提升序列化效率,并且在运行时能够根据数据的统计分布重新生成更优的序列化代码,但C++/Rust等语言不支持反射,没有虚拟机,也没有提供内存模型的低阶API,因此我们无法针对这类语言通过JIT动态编译生成序列化代码。
对于此类场景,Fury正在实现一套AOT静态代码生成框架,在编译时根据对象的schema提前生成序列化代码,然后使用生成的代码进行自动序列化。对于Rust,未来也会通过Rust的macro在编译时生成代码,提供更好的易用性。
缓存优化
在序列化自定义类型时,会把字段进行重排序,保证相同接口类型的字段依次序列化,增加缓存命中的概率,同时也促进了CPU指令缓存,实现了更加高效的序列化。对于基本类型字段将写入顺序按照字节字段大小降序排列,这样如果开始地址是对齐的,随后的读写都会发生在内存地址对齐的位置,CPU执行起来更加高效。
多协议设计与实现
基于Fury提供的多语言序列化核心能力,我们在这之上构建了三种序列化协议,分别适用于不同的场景:
- Java序列化:适合纯Java序列化场景,提供最高百倍以上的性能提升;
- 跨语言对象图序列化:适合面向应用的多语言编程,以及高性能跨语言序列化;
- 行存序列化:适合分布式计算引擎如Spark/Flink/Dories/Velox/样本流处理框架/特征存储等;
后续我们也会针对一些核心场景添加新的协议,用户也可以基于Fury的序列化能力构建自己的协议。
Java序列化
由于Java在大数据、云原生、微服务和企业级应用的广泛使用,对Java序列化的性能优化可以大幅降低系统延迟,提升吞吐率,降低服务器成本。
因此Fury针对Java序列化进行了大量极致性能优化,我们的实现具备以下能力:
- 极致性能:通过利用Java对象的类型和泛型信息,结合JIT编译、Unsafe低阶操作,Fury相比JDK最高有170倍的性能提升,相比Kryo/Hessian最高有50~100倍的性能提升。
- 100% JDK序列化API兼容性:支持了所有JDK自定义序列化方法writeObject/ readObject/ writeReplace/readResolve/readObjectNoData的语义,保证任意场景替换JDK序列化的正确性。而已有的Java序列化框架如Kryo/Hessian在这些场景,都存在一定的正确性问题
- 类型前后兼容:在反序列化端和序列化端Class Schema不一致时,仍然可以正确反序列化,支持应用独立升级部署,独立增删字段。并且我们对元数据进行了极致的压缩和共享,类型兼容模式相比类型强一致模式做到了几乎没有任何性能损失。
- 元数据共享:在某个上下文(TCP连接)下多次序列化之间共享元数据(类名称、字段名称、Final字段类型信息等),这些信息会在该上下文下第一次序列化时发送到对端,对端可以根据该类型信息重建相同的反序列化器,后续序列化可以避免传输元数据,减小网络流量压力,同时也自动支持类型前后兼容。
- 零拷贝支持:支持Out of band 零拷贝和堆外内存读写。
跨语言对象图序列化
跨语言对象图序列化主要用于对动态性和易用性有更高要求的场景。尽管Protobuf/Flatbuffer等框架提供了多语言序列化能力,但仍然存在一些不足:
- 需要提前编写IDL并静态编译生成代码,不具备足够的动态性和灵活性;
- 生成的类不符合面向对象设计也无法给类添加行为,并不能作为领域对象直接用于多语言应用开发。
- 不支持子类序列化。面向对象编程的主要特点是通过接口调用子类方法。这类模式也无法得到很好的支持。尽管Flatbuffer提供了Union,Protobuf提供了OneOf/Any特性,这类特性需要在序列化和反序列化时判断对象的类型,不符合面向对象编程的设计。
- 不支持循环和共享引用,需要针对领域对象重新定义一套IDL并自己实现引用解析,然后在每种语言里面编写代码实现领域对象和协议对象之间的相互转换,如果对象图嵌套层数较深,则需要编写更多的代码。
结合以上几点,Fury实现了一套跨语言的对象图序列化协议:
- 多语言/跨语言自动序列化任意对象:在序列化和反序列化端定义两个Class,即可自动将一种语言的对象自动序列化为另一种语言的对象,无需创建IDL文件、编译schema生成代码以及手写转换代码;
- 多语言/跨语言自动序列化共享引用和循环引用;
- 支持对象类型多态,符合面向对象编程范式,多个子类型对象可以同时被自动反序列化,无需用户手动处理;
- 同时我们在这套协议上面也支持了Out of band 零拷贝;
自动跨语言序列化示例:
行存序列化
对于高性能计算和大规模数据传输场景,数据序列化和传输往往是整个系统的性能瓶颈。如果用户只需要读取部分数据,或者根据对象某个字段进行过滤,反序列化整个数据将带来额外开销。因此Fury也提供了一套二进制数据结构,在二进制数据上直读直写,避开序列化。
Apache arrow是一个成熟的列存格式,支持二进制读写。但列存并不能满足所有场景需求,在线链路和流式计算场景的数据天然就是行存结构,同时列式计算引擎内部在涉及到数据变更和Hash/Join/Aggregation操作时,也会使用到行存结构。
而行存并没有一个统一标准实现,计算引擎如Spark/Flink/Doris/Velox等都定义了一套行存格式,这些格式不支持跨语言,且只能被自己引擎内部使用,无法用于其它框架。尽管Flatbuffer能够支持按需反序列化,但需要静态编译Schema IDL和管理offset,无法满足复杂场景的动态性和易用性需求。
因此Fury在早期借鉴了spark tungsten和apache arrow格式,实现了一套可以随机访问的二进制行存结构,目前实现了Java/Python/C++版本,实现了在二进制数据上面直读直写,避免掉了所有序列化开销。
下图是Fury Row Format的二进制格式:
该格式密集存储,数据对齐,缓存友好,读写更快。由于避免了反序列化,能够减少Java GC压力。同时降低Python开销,同时由于Python的动态性,Fury的数据结构实现了_getattr__/__getitem__/slice/和其它特殊方法,保证了行为跟python dataclass/list/object的一致性,用户没有任何感知。
性能对比
这里给出部分Java序列化性能数据,其中标题包含compatible的图表是支持类型前后兼容下的性能数据,标题不包含compatible的图表是不支持类型前后兼容下的性能数据。为了公平起见,所有测试Fury关闭了零拷贝特性。
更多benchmark数据请参考Fury Github官方文档:https://github.com/alipay/fury/tree/main/docs/benchmarks
未来规划
- 元数据压缩和自动共享
- 跨语言序列化支持类型前后兼容
- 静态代码生成框架,用于提前生成c++/golang/rust代码
- C++/Rust支持跨语言对象图序列化
- Golang/Rust/JavaScript支持行存
- 兼容ProtoBuffer生态,支持根据Proto IDL自动生成Fury序列化代码
- 新的协议实现:AI特征存储,知识图谱序列化
- 持续改进我们的序列化基础原语,提供更高性能实现
- 标准化协议,提供二进制兼容性
- 文档和易用性改进
加入我们
我们致力于将 Fury 打造为一个开放中立、追求极致与创新的社区项目,后续的研发与讨论等工作都会在社区以开源透明的方式进行。欢迎任何形式的参与,包括但不限于提问、代码贡献、技术讨论等。非常期待收到大家的想法和反馈,一起参与到项目的建设中来,推动项目向前发展,打造最先进的序列化框架。
代码主仓库的 GitHub 地址为:https://github.com/alipay/fury
官方网站:https://furyio.org
欢迎各种 Issue、PR、Discussion。
也欢迎直接加入下面的官方交流群,和我们一起交流。
微信公众号:高性能序列化框架Fury
钉钉交流群:钉钉群号(36170003000)