Стрит, Avro, ProtocolBuffers - Они все мертвы?

Question

Работа над проектом для домашних животных (cassandra, spark, hadoop, kafka) Мне нужна структура сериализации данных. Выяснив общие три структуры - Thrift, Avro и ProtocolBuffers - я заметил, что большинство из них, похоже, мертвы, имея 2 младших выпуска в год максимум.

Это оставляет меня два предположения:

• Они являются полными, как такая структура должна быть и просто отдохнуть в режиме обслуживания, пока новые компоненты не нужны
• Там нет никаких оснований существовать для таких рамок - для меня это не очевидно. Если да, то какие альтернативы там?

Если кто-нибудь может дать мне намек на мои предположения, любой ввод приветствуется.

Answer 1

Преимущество бережливость по сравнению с Protobuf является то, что бережливость предлагает полная RPC и структура сериализации. Plus Thrift поддерживает около 20 + целевых языков, и это число все еще растет. Мы собираемся включить ядро ​​.NET, и в будущем не будет поддержки Rust.

Тот факт, что в последние месяцы было не так много выпусков Thrift, наверняка есть что-то, что необходимо решить, и мы полностью осознаем это. С другой стороны, общая стабильность кодовой базы довольно хороша, поэтому можно сделать вилку Github и самостоятельно разрезать ветку от текущего мастера, конечно же, с обычными мерами качества.

Основное отличие от Avro и Thrift заключается в том, что Thrift статически типизирован, в то время как Avro использует более динамичный подход. В большинстве случаев статический подход удовлетворяет потребностям достаточно хорошо, и в этом случае Thrift позволяет вам использовать лучшую производительность сгенерированного кода. Если это не так, Avro может быть более подходящим.

Также стоит упомянуть, что помимо Thrift, Protobuf и Avro на рынке есть еще несколько решений, таких как Capt'n'proto или BOLT.

Answer 2

Относительно бережливости: насколько я знаю, это живое и ногами. Мы используем его для сериализации и внутренних API, где я работаю, и он отлично подходит для этого.

Отсутствие таких вещей, как мультиплексирование соединения и более удобные для пользователя клиенты, были добавлены через такие проекты, как Twitter's Finagle.

Хотя я бы охарактеризовал наше использование как полуинтенсивный (т. Е. Мы не смотрим на производительность в первую очередь: она должна быть простой в использовании и без ошибок), мы не столкнулись с ней любой вопрос до сих пор.

Итак, о бережливости, я бы сказал, что он попадет в вашу первую категорию. [*]

Protocolbuffers является альтернативой для сериализации части бережливости, но она не обеспечивает бережливость предложения RPC инструментов.

Я не знаю ни одного другого проекта, который бы смешивал RPC и сериализацию с таким простым в использовании и полным пакетом.

_{[*] В любом случае, как только вы начнете использовать его и увидеть все преимущества, это трудно положить его в второй категории :)}

Answer 3

Протокол Buffers - очень зрелая структура, впервые введенная почти 15 лет назад в Google. Это, конечно, не мертво: почти каждая служба внутри Google использует его. Но после столь большого использования, на данный момент, вероятно, не так много нужно изменить. Фактически, в этом году они выпустили основной выпуск (3.0), но релиз был как раз об удалении функций, как их добавлении.

Система RPC, связанная с Protobuf, gRPC, является относительно новой и в последнее время имела гораздо большую активность. (Тем не менее, он основан на внутренней системе RPC от Google, которая достигла 12 лет развития.)

Я не знаю, как много о Тритете или Авро, но они тоже были вокруг.