Meta представляє «Tulip», протокол двійкової серіалізації, який допомагає зі схематизацією даних, звертаючись до надійності протоколу для робочих навантажень ШІ та машинного навчання

Meta представляє «Tulip», протокол двійкової серіалізації, що підтримує еволюцію схеми. Це одночасно вирішує питання надійності протоколу та інші проблеми та допомагає нам у схематизації даних. Tulip має кілька застарілих форматів. Таким чином, він використовується в платформі даних Meta і має значне підвищення продуктивності та ефективності. Платформа даних Meta складається з численних різнорідних служб, таких як сховище даних і різноманітні системи реального часу, які обмінюються великими обсягами даних і спілкуються між собою через сервісні API. Оскільки в системі Meta зростає кількість робочих навантажень, пов’язаних із ШІ та машинним навчанням ML, які використовують дані для навчання цих моделей ML, необхідно постійно працювати над тим, щоб зробити наші системи реєстрації даних ефективними. Схематизація даних відіграє величезну роль у створенні платформи для даних у масштабі Meta. Ці системи розроблені на основі знання того, що кожне рішення та компроміс впливають на надійність, ефективність попередньої обробки даних, продуктивність і досвід розробника інженера. Зміна форматів серіалізації для інфраструктури даних — це велика ставка, але вона дає переваги в довгостроковій перспективі, які змушують платформу розвиватися з часом.

Бібліотека реєстрації даних Analytics присутня на веб-рівні та у внутрішніх службах, і вона також відповідає за реєстрацію аналітичних і оперативних даних за допомогою Scribe – довговічної системи черги повідомлень, яку використовує Meta. Дані зчитуються та приймаються з Scribe, який також включає службу прийому даних платформи та системи обробки в реальному часі. Бібліотека читання аналітики даних допомагає десеріалізувати дані та регідратувати їх у структуроване корисне навантаження. Схеми журналювання створюються, оновлюються та видаляються щомісяця тисячами інженерів Meta, і ці потоки даних схеми журналювання в петабайтах змінюються щодня через Scribe. 

Схематизація необхідна, щоб гарантувати, що будь-яке повідомлення, зареєстроване в минулому, теперішньому або майбутньому, залежно від версії (де)серіалізатора, може бути надійно (де)серіалізовано в будь-який час з максимальною точністю та без втрати даних. Безпечна еволюція схеми за допомогою зворотної та прямої сумісності — це назва цієї характеристики. Основна увага статті зосереджена на форматі дротової серіалізації, який використовується для кодування даних, які остаточно обробляються платформою даних. Порівняно з двома форматами серіалізації, що використовувалися раніше, Hive Text Delimited і JSON, новий формат кодування є ефективнішим, оскільки для (де)серіалізації даних потрібно на 40–85 відсотків менше байтів і на 50–90 відсотків менше циклів ЦП.

Програми бібліотеки журналювання написані різними мовами, такими як C++, Java, Haskell, Hack і Python, щоб серіалізувати корисне навантаження відповідно до схеми журналювання, і ці схеми журналювання визначаються відповідно до потреб бізнесу та записуються в Scribe для полегшення доставки . Бібліотека журналювання доступна у двох варіантах, а саме: створений код і загальний. У варіанті Code Generated для безпечного використання статично типізовані сеттери генеруються для кожного поля. Для оптимальної ефективності також генерується код постобробки та серіалізації. Тоді як у загальній версії для проведення (де)серіалізації динамічно типізованих корисних даних пропонується бібліотека C++ під назвою Tulib. Повідомлення, яке використовує динамічну типізацію, серіалізується відповідно до схеми журналювання. Оскільки він дозволяє (де)серіалізацію повідомлень без необхідності перебудови та повторного розгортання двійкового файлу програми, цей метод більш гнучкий, ніж режим генерації коду.

Бібліотека журналювання надсилає дані до кількох внутрішніх систем, кожна з яких традиційно визначає власні правила серіалізації, і під час використання цих форматів для серіалізації корисних даних виникають різноманітні проблеми.

• Стандартизація: У минулому стандартизації форматів серіалізації не було; кожна наступна система мала свій власний формат, що призводило до збільшення витрат на обслуговування та розробку. 
• Надійність: Нові стовпці можна додавати лише в кінці, щоб підтримувати надійність десеріалізації. Будь-яка спроба вставити поле в середину існуючого стовпця або видалити стовпець призведе до зміщення всіх наступних стовпців, що унеможливить десеріалізацію рядка, а оновлена ​​схема поширюється читачам у режимі реального часу. 
• Ефективність: У порівнянні з двійковою (де)серіалізацією протоколи Hive Text Delimited і JSON є текстовими та неефективними.
• Правильність: Для текстових протоколів, як-от Hive Text, роздільники полів і рядків мають бути екранованими та неекранованими. Це робить кожен письменник і читач, що посилює тиск на авторів бібліотек. Важко мати справу із застарілими або недосконалими реалізаціями, які просто шукають присутність цих символів і відхиляють усе повідомлення, замість того, щоб уникнути проблемних символів.
• Пряма і зворотна сумісність: Бажано споживати корисні навантаження, які були серіалізовані за схемою серіалізації як до, так і після версії, яку бачить споживач. Протокол Hive Text Protocol не надає такої гарантії.
• Метадані: Серіалізація тексту Hive не підтримує вставлення метаданих у корисне навантаження. Щоб подальші системи могли реалізувати функції, які отримують прибуток від присутності метаданих, розповсюдження цих даних є важливим.

Tulip вирішує нашу фундаментальну проблему, проблему надійності, забезпечуючи безпечний формат еволюції схеми, який є як зворотно, так і прямо сумісним між службами з різними циклами розгортання. Tulip вирішив усі ці проблеми одним махом, зробивши його кращою інвестицією, ніж інші доступні варіанти. 

TCompactProtocol від Thrift використовується для серіалізації корисного навантаження в протоколі серіалізації Tulip, який є двійковим протоколом серіалізації. Поля нумеруються ідентифікаторами так само, як очікується від інженера під час зміни ідентифікаторів у структурі Thrift. Інженери визначають список імен і типів полів під час створення схеми журналювання, а ідентифікаторами полів керує модуль керування платформою даних, а не вказані інженери. Репозиторій схем серіалізації містить трансляцію схеми журналювання в схему серіалізації. Списки імен поля, типу поля, ідентифікатора поля для пов’язаної схеми журналювання та історії полів зберігаються в конфігурації серіалізації. Коли розробник хоче оновити схему журналювання, транзакційна операція виконується на схемі серіалізації.

Посилання: https://engineering.fb.com/2022/11/09/developer-tools/tulip-schematizing-metas-data-platform/

Будь ласка, не забудьте приєднатися Наш ML Subreddit

Аванті Єлурі є студентом подвійного диплому в IIT Kharagpur. Вона дуже зацікавлена ​​в Data Science через його численні застосування в різних галузях, а також передові технологічні досягнення та те, як вони використовуються в повсякденному житті.

<!–

->