Перейти на PRO

Что такое Protobuf и как проектируются его схемы?

Тип вопроса: Архитектура Вероятность: 10% Категория: Python Разработчик

Ответ

Protobuf (Protocol Buffers) — это язык-независимый, платформенно-нейтральный, расширяемый механизм сериализации структурированных данных, разработанный Google. Его файлы (.proto) описывают структуру данных (сообщения, сервисы), на основе которой генерируется код для работы с этими данными на различных языках программирования.

Почему Protobuf? Protobuf используется для эффективной сериализации данных, обеспечивая компактный бинарный формат, что приводит к уменьшению размера передаваемых данных и повышению скорости их обработки по сравнению с текстовыми форматами, такими как JSON или XML. Он идеально подходит для межсервисного взаимодействия (RPC) и хранения данных.

Пример простого .proto файла (syntax proto3):

syntax = "proto3";

package myapp.data;

message Person {
  string name = 1;
  int32 age = 2;
  repeated string emails = 3;
  bool is_active = 4;
}

message Address {
  string street = 1;
  string city = 2;
  string zip_code = 3;
}

Ключевые особенности проектирования схем:

  • Синтаксис: Используется proto2 или proto3 (рекомендуется proto3 за его упрощенный синтаксис и отсутствие required полей).
  • Сообщения (message): Определяют структуру данных, аналогично классам или структурам.
  • Поля: Каждое поле имеет тип (скалярный, такой как int32, string, bool, или составной, как другое сообщение), имя и уникальный числовой тег (например, name = 1). Теги используются для идентификации полей в бинарном формате и должны быть стабильными.
  • Типы полей: singular (одно значение), repeated (список значений), map (словарь).
  • Генерация кода: Компилятор protoc использует .proto файл для создания классов или структур на выбранном языке (Python, Java, C++, Go и др.), которые позволяют легко сериализовать и десериализовать данные.

Пример использования в Python после компиляции: (Предполагается, что protoc --python_out=. person.proto был выполнен)

import person_pb2 # Сгенерированный модуль

# Создание объекта сообщения
person = person_pb2.Person(
    name="Alice", 
    age=30,
    emails=["alice@example.com", "alice.work@example.com"],
    is_active=True
)

# Сериализация в бинарный формат
serialized_data = person.SerializeToString()
print(f"Serialized data: {serialized_data}")

# Десериализация из бинарного формата
new_person = person_pb2.Person()
new_person.ParseFromString(serialized_data)

print(f"Deserialized name: {new_person.name}")
print(f"Deserialized age: {new_person.age}")
print(f"Deserialized emails: {new_person.emails}")

Проектирование Protobuf схем требует внимательности к обратной совместимости, так как изменения в схеме могут повлиять на уже развернутые системы.

Ответ 18+ 🔞

Ну, слушай, давай я тебе на пальцах объясню, что за зверь такой этот Protobuf. Представь, что тебе нужно переслать кучу данных из одного сервиса в другой, но так, чтобы они занимали мало места и летели быстрее пули. JSON и XML — это как перевозить мебель на «Жигулях»: вроде работает, но места мало и тащится медленно. А Protobuf — это фура-трансформер, которая эту же мебель упаковывает в вакуумные пакеты и гонит по автобану.

А зачем он вообще нужен, этот Protobuf? Да чтобы не тратить время и трафик на ерунду! Вместо человекочитаемого текста с кучей кавычек и скобок, он ужимает всё в бинарник, который и места мало занимает, и парсится со скоростью света. Идеально для микросервисов, которые между собой болтают, или для сохранения данных, где каждый байт на счету.

Вот, смотри, как выглядит описание данных в .proto файле (берём современный proto3):

syntax = "proto3";

package myapp.data;

message Person {
  string name = 1;
  int32 age = 2;
  repeated string emails = 3;
  bool is_active = 4;
}

message Address {
  string street = 1;
  string city = 2;
  string zip_code = 3;
}

На что тут смотреть, чтобы не облажаться:

  • Синтаксис: Есть старый proto2 и новый proto3. Бери proto3 и не мучайся — там проще, и нет этих ёбаных required полей, из-за которых потом вся обратная совместимость летит в пизду.
  • Сообщения (message): Это как чертеж твоего будущего объекта. Типа класса, только для данных.
  • Поля: У каждого поля есть тип (число, строка, булевское или другое сообщение), имя и, внимание, циферный тег (вот этот = 1, = 2). Этот тег — святое! Он как номер в твоём паспорте в мире Protobuf. Меняешь его — получаешь пиздец при десериализации старых данных. Выдал раз — носи до конца жизни схемы.
  • Разновидности полей: Обычное (singular), список (repeated) или словарик (map).
  • Магия генерации: Берёшь этот .proto файл, пишешь в консоли protoc --python_out=. person.proto (или для другого языка), и он, блядь, генерирует тебе готовые классы на Python/Java/Go/C++! Не нужно вручную этот бинарник разбирать, всё уже сделано.

А вот как этим потом в Python'е пользоваться (после того как код сгенерировали):

import person_pb2 # Вот этот самый сгенерированный модуль

# Создаём объект, как будто так и надо
person = person_pb2.Person(
    name="Alice", 
    age=30,
    emails=["alice@example.com", "alice.work@example.com"],
    is_active=True
)

# Пакуем в бинарную строку — сжимается, блядь, в разы!
serialized_data = person.SerializeToString()
print(f"Serialized data: {serialized_data}")

# Распаковываем обратно из этой компактной хуйни
new_person = person_pb2.Person()
new_person.ParseFromString(serialized_data)

print(f"Deserialized name: {new_person.name}")
print(f"Deserialized age: {new_person.age}")
print(f"Deserialized emails: {new_person.emails}")

Главное, чувак, когда схему проектируешь — думай на три шага вперёд. Потому что если ты завтра поле удалишь или теги переставишь, все твои старые клиенты, которые ещё на прошлой версии схемы сидят, просто охуеют и перестанут понимать, что ты им шлёшь. Обратная совместимость — это святое, иначе будет волнение ебать и доверия ноль.

© ХакСобесов, 2026
support@hacksobesov.com