Мы часто сталкиваемся с вариантами использования, когда нам нужно собирать данные из распределенных программных компонентов. Программное обеспечение может распространяться, поскольку они обслуживают разные географические границы или функционально разделены. В целях мониторинга и анализа использования и производительности системы мы по-прежнему хотели бы видеть систему в целом. Это потребует от нас сбора данных о производительности каждого из этих компонентов для отправки в централизованную систему. Данные должны быть обогащены и сохранены в базе данных, что может обеспечить эффективную аналитическую обработку.

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

Когда дело доходит до кодирования, у нас есть широкий спектр вариантов, начиная от JSON, сериализации объектов, AVRO, протокольных буферов и Thrift и т. д. JSON является самым простым, он не компактен и очень медленно обрабатывается. Сериализация объектов использует встроенные функции языка программирования и делает решение привязанным к конкретному языку. AVRO и ProtoBuf обеспечивают хороший баланс гибкости и эффективности. Итак, каковы будут критерии выбора между двумя, AVRO и Protobuf. Давайте посмотрим, как эти два работают с параметрами, перечисленными в таблице ниже.

Как видно из таблицы, и protobuf, и AVRO поддерживают большинство необходимых функций. Подробнее обсудим далее в статье. Давайте сравним различные аспекты кодирования с этими форматами. Я оставлю некоторый указатель для более глубокого исследования того, как эти функциональные возможности достигаются в этих протоколах.

Сравнение

Кодирование и сжатие

Лучший способ сравнить скорость кодирования — попробовать тестовую программу и сгенерировать закодированные данные несколько тысяч раз. В своем тесте, написанном на Java, я создал образец схемы с 6 атрибутами. Размер необработанных данных в формате JSON составлял 439 байт. В следующей таблице перечислены результаты выполнения.

Эта статья подробно сравнивает различные схемы кодирования, их размеры и скорость кодирования. Выбор языка и библиотек может повлиять на производительность кодирования и декодирования.

Обратная совместимость

Из-за того, как данные закодированы в AVRO, если вышеперечисленное не будет выполнено, AVRO потребуется точно такая же схема для анализа данных. Однако преимущество AVRO заключается в том, что при использовании для хранения объектов в файлах определения сахема могут быть прикреплены к файлу. Версия схемы может быть аннотирована и использована с репозиторием схемы для разрешения схемы.

Поддержка типов данных

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

Заключение

Protobuf подходит для кодирования небольших сообщений в тех случаях, когда получателю не нужно иметь дело с несколькими схемами одновременно. Protobuf поставляется с мощной поддержкой библиотек на разных языках от Google. Protobuf очень хорошо работает с эффективным протоколом gRPC. Это делает его идеальным для написания программного обеспечения клиент-серверной архитектуры и транзакционных рабочих нагрузок. В целом, для связи один на один Protobuf может оказаться более подходящим, поскольку он обеспечивает статическую привязку с высокой скоростью кодирования и декодирования. Protobuf предоставляет хорошую документацию, и Google постоянно работает над улучшением протоколов.

В тех случаях, когда мы не ожидаем, что производитель и потребитель будут полностью связаны, AVRO кажется подходящим, в то время как у нас есть связанные производитель и потребитель. Kafka и ее экосистема хорошо поддерживают AVRO, особенно реестр схем очень полезен для автоматизации работы с данными с использованием инструментов Kafka. AVRO обычно лучше подходит для аналитических рабочих нагрузок, когда вам нужно сериализовать огромное количество записей. В этом случае сериализация схемы часто незначительна, а сериализация AVRO немного компактнее. Тем не менее, AVRO имеет хорошую поддержку Java, тогда как поддержка других языков ограничена.