Tulip: Модернизация платформы данных Meta

Миграции — это сложно. Более того, в Мете им становится намного сложнее из-за:

Прежде чем углубляться в подробности истории миграции, мы хотели бы сделать шаг назад и попытаться объяснить мотивацию и обоснование этой миграции.

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

Logger лежит в основе платформы данных. Система используется для регистрации аналитических и операционных данных в Scuba, Hive и конвейерах потоковой обработки через Scribe. Каждая команда разработчиков продуктов и платформ данных взаимодействует с журналированием. По причинам устаревшего формата данных для журналирования был либо текст с разделителями Hive, либо JSON. Ограничения этих форматов описаны в нашей предыдущей статье о Tulip.

Чтобы устранить эти ограничения, был разработан формат сериализации Tulip, который заменил устаревшие форматы сериализации для конкретных мест назначения.

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

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

Примечание. Цифры на диаграмме 2 экстраполированы (на общий трафик) на основе фактической экономии, наблюдаемой для пяти крупнейших (по объему) схем журналирования.

Мы хотели бы представить наш миграционный путь как два отдельных этапа со своими собственными перспективами.

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

Решения примерно распределились по следующим категориям:

Задача: как можно облегчить миграцию и снизить риск, не требуя от производителя(ов) и потребителя(ов) данных атомарного переключения форматов сериализации?

Решение: при переключении единой схемы журналирования на использование нового протокола сериализации Tulip для записи полезных данных требовалась поддержка полезных данных смешанного режима в одном потоке записи, поскольку было невозможно «атомарно» переключить всех производителей данных на использование нового формата. . Это также позволило команде ограничить скорость развертывания сериализации нового формата.

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

Основной проблемой для смешанного режима проводного формата была невозможность изменить существующую сериализацию полезных данных ни в формате Hive Text, ни в формате JSON. Чтобы обойти это ограничение, каждая сериализованная полезная нагрузка Tulip имеет префикс 2-байтовой последовательности 0x80 0x00, которая является недопустимой последовательностью utf-8.

Проблема: в некоторых системах формат сериализации Hive Text (или JSON) проник в код приложения, который в конечном итоге стал использовать этот формат для потребления полезных данных. Это результат того, что потребители преодолевают абстракцию формата сериализации.

Решение: Эту проблему решили два решения.

Reader (аналог регистратора для десериализации данных)

Reader — это библиотека, которая преобразует сериализованную полезную нагрузку в структурированный объект. Reader (как и logger) поставляется в двух вариантах: (a) генерируемый код и (b) универсальный. Объект чтения принимает данные в любом из трех форматов — Tulip, Hive Text или JSON — и создает структурированный объект. Это позволило команде переключить потребителей на использование читалок до начала миграции. Код приложения пришлось обновить, чтобы он мог использовать этот структурированный объект вместо необработанной сериализованной строки. Это абстрагировало формат передачи данных от потребителей данных.