Thrift,Avro,Protocolbuffers - 他们都死了吗?

dom*_*nik 22 serialization hadoop thrift protocol-buffers avro

在一个宠物项目(cassandra,spark,hadoop,kafka)上工作我需要一个数据序列化框架.检查常见的三个框架 - 即Thrift,Avro和Protocolbuffers - 我注意到它们中的大多数似乎都死了,最多每年有2个小版本.

这让我有两个假设:

  • 只要不需要新功能,它们就像这样的框架一样完整,只需在维护模式下休息
  • 对于这样的框架没有理由存在 - 对我来说不明白为什么.如果是这样,有什么替代品?

如果有人能给我一些暗示我的假设,欢迎任何意见.

Ken*_*rda 28

Protocol Buffers是一个非常成熟的框架,近15年前在谷歌首次推出.它当然没有死:Google内部几乎所有服务都使用它.但经过这么多的使用后,目前可能没有太多需要改变的地方.事实上,他们今年做了一个主要版本(3.0),但发布的内容与删除功能一样多.

Protobuf的相关RPC系统gRPC相对较新,最近有更多的活动.(但是,它基于谷歌的内部RPC系统,已经有12年的发展历史.)

我不太了解Thrift或Avro,但他们已经有一段时间了.


Jen*_*nsG 14

与Protobuf相比,Thrift的优势在于Thrift提供了完整的RPC和序列化框架.Plus Thrift支持大约20多种目标语言,而且这个数字还在增长.我们即将包含.NET核心,并且在不远的将来会有Rust支持.

在过去几个月中没有那么多Thrift版本的事实肯定是需要解决的问题,我们完全了解它.另一方面,代码库的整体稳定性非常好,因此可以做一个Github分支,并从当前的主服务器上自己切割一个分支 - 当然还有通常的质量措施.

Avro和Thrift之间的主要区别在于Thrift是静态类型,而Avro使用更动态的方法.在大多数情况下,静态方法非常符合需求,在这种情况下,Thrift可以让您从生成的代码的更好性能中受益.如果不是这样,Avro可能更适合.

另外值得一提的是,除了Thrift,Protobuf和Avro之外,市场上还有更多的解决方案,例如Capt'n'proto或BOLT.

  • 是的,我很清楚Protobuf是在2008年开源的,因为我是领导该项目的人,谢谢.Protobuf最初是在2001年和2003年的RPC系统中构思出来的.不幸的是,当我开源Protobuf时,我没有足够的资源为公开发布准备RPC实现,所以直到后来才真正发生.然而,事实证明它们是一起发展的. (31认同)
  • 我不同意.gRPC和Protobuf的设计和构建非常融洽.事实上它们是正确的模块化和可分离的 - 这样你可以避免RPC系统的膨胀,如果你不需要它 - 是一个功能,而不是一个bug. (9认同)
  • "Thrift提供了完整的RPC和序列化框架." - Protobuf也是如此:http://grpc.io (8认同)
  • 但这是附加组件,而不是核心协议。使用Thrift可以得到OOTB。 (2认同)
  • “*gRPC 和 Protobuf 是一起设计和构建的*”——[pbuf ~ 2008(或更早)](http://stackoverflow.com/a/40989644/499466) 与 [gRPC ~ 2015](https: //heise.de/-2862634)。好吧,至少是在同一世纪。 (2认同)
  • @JensG您能否解释一下“ Avro和Thrift之间的主要区别在于Thrift是静态类型的”这一段的意思?这是Thrift的描述语言:https://thrift.apache.org/docs/idl您是说这与Avro模式中表达的内容有根本不同吗?Avro使用类型信息来实现比Thrift更有效的数据编码。“未标记的数据:由于在读取数据时存在模式,因此需要用数据编码的类型信息要少得多,从而导致较小的序列化大小。” (2认同)
  • 您可以从架构生成代码:https://avro.apache.org/docs/1.8.2/gettingstartedjava.html#Compiling+the+schema 或者您可以从代码中的类型生成架构。您是否正在考虑 GenericRecord 接口?提供静态对象的动态视图并不意味着底层对象是静态的。您始终可以将对象中的字段转换为 Map<String, Object> - 如果您愿意,您可以为 Thrift 生成的对象提供相同的内容。 (2认同)