Meta は、スキーマの進化をサポートするバイナリ シリアル化プロトコルである「Tulip」を導入します。 これは、プロトコルの信頼性やその他の問題に同時に対処し、データのスキーマ化を支援します。 Tulip には複数のレガシー形式があります。 そのため、Meta のデータ プラットフォームで使用され、パフォーマンスと効率が大幅に向上しています。 Meta のデータ プラットフォームは、ウェアハウス データ ストレージや、大量のデータを交換し、サービス API を介して相互に通信するさまざまなリアルタイム システムなど、多数の異種サービスで構成されています。 これらの ML モデルのトレーニングにデータを使用する Meta のシステム内の AI および機械学習 ML 関連のワークロードの数が増加するにつれて、データ ロギング システムの効率化に継続的に取り組む必要があります。 データのスキーマ化は、メタ規模のデータのプラットフォームを作成する上で大きな役割を果たします。 これらのシステムは、すべての決定とトレードオフが信頼性、データ前処理の効率、パフォーマンス、およびエンジニアの開発経験に影響を与えるという知識に基づいて設計されています。 データ インフラストラクチャのシリアル化形式を変更することは大きな賭けですが、長期的にはプラットフォームを進化させる利点があります。
Data Analytics Logging Library は Web 層と内部サービスに存在し、これはまた、Meta が使用する永続的なメッセージ キューイング システムである Scribe を使用して、分析データと運用データをログに記録する役割も果たします。 データは Scribe から読み取られ、取り込まれます。これには、データ プラットフォームの取り込みサービスとリアルタイム処理システムも含まれています。 データ分析読み取りライブラリは、データを逆シリアル化し、構造化されたペイロードに再水和するのに役立ちます。 ロギング スキーマは、Meta の何千人ものエンジニアによって毎月作成、更新、削除されており、これらのロギング スキーマ データは毎日 Scribe を介してペタバイト規模で流れています。
過去、現在、または将来にログに記録されたメッセージを (デ) シリアライザーのバージョンに応じて、最大限の忠実度でデータ損失なしにいつでも確実に (デ) シリアライズできるようにするには、スキーマ化が必要です。 後方互換性と前方互換性による安全なスキーマの進化は、この特性に付けられた名前です。 この記事の主な焦点は、データ プラットフォームによって最終的に処理されるデータのエンコードに使用されるオンワイヤ シリアライゼーション形式にあります。 以前に使用されていた 40 つのシリアル化形式である Hive Text Delimited と JSON シリアル化と比較すると、新しいエンコーディング形式はより効率的であり、データを (逆) シリアル化するために必要なバイト数が 85 ～ 50%、CPU サイクルが 90 ～ XNUMX% 少なくなります。
ロギング ライブラリのアプリケーションは、ロギング スキーマに従ってペイロードをシリアル化するために、C++、Java、Haskell、Hack、Python などのさまざまな言語で記述されています。これらのロギング スキーマは、ビジネス ニーズに従って定義され、簡単に配信できるように Scribe に書き込まれます。 . ロギング ライブラリは、Code Generated と Generic の XNUMX つのフレーバーで利用できます。 タイプセーフな使用のためのコード生成フレーバーでは、静的に型指定されたセッターがフィールドごとに生成されます。 効率を最適化するために、後処理およびシリアル化コードも生成されます。 動的に型付けされたペイロードの (逆) シリアル化を実行するジェネリック フレーバーでは、Tulib という名前の C++ ライブラリが提供されます。 動的型付けを使用するメッセージは、ロギング スキームに従ってシリアル化されます。 この方法では、アプリケーション バイナリの再構築と再デプロイを必要とせずにメッセージのシリアル化 (非) 化が可能になるため、コード生成モードよりも柔軟性があります。
ロギング ライブラリは複数のバックエンド システムにデータを送信します。バックエンド システムは従来、独自のシリアル化ルールを指定しており、これらの形式を使用してペイロードをシリアル化する際にさまざまな問題に直面しています。
- 標準化： これまでシリアライゼーション形式の標準化はありませんでした。 各ダウンストリーム システムには独自の形式があり、保守と開発のコストが増加していました。
- 信頼性： 逆シリアル化の信頼性を維持するために、新しい列は最後にのみ追加できます。 既存の列の途中にフィールドを挿入したり、列を削除したりすると、後続のすべての列が移動し、行を逆シリアル化できなくなり、更新されたスキーマがリアルタイムでリーダーに配布されます。
- 効率性： バイナリ (デ) シリアル化と比較すると、Hive Text Delimited プロトコルと JSON プロトコルはどちらもテキストベースで非効率的です。
- 正しさ： Hive Text などのテキストベースのプロトコルでは、フィールド区切り記号と行区切り記号をエスケープする必要があります。 すべてのライターとリーダーがこれを行うため、ライブラリの作成者へのプレッシャーが高まります。 面倒な文字をエスケープするのではなく、単にこれらの文字の存在を探してメッセージ全体を拒否する、時代遅れまたは欠陥のある実装に対処することは困難です。
- 前方および後方互換性: コンシューマーに表示されるバージョンの前と後の両方で、シリアル化スキーマによってシリアル化されたペイロードを消費することが望まれます。 Hive Text Protocol は、この保証を提供しません。
- メタデータ： ペイロードへのメタデータの挿入は、Hive テキストのシリアル化では簡単にはサポートされていません。 ダウンストリーム システムがメタデータの存在から利益を得る機能を実装するには、そのデータの伝播が不可欠です。
Tulip は、サービス全体で後方互換性と前方互換性を備えた安全なスキーマ進化形式を個別の展開サイクルで提供することにより、私たちの基本的な問題である信頼性の問題を解決します。 Tulip はこれらすべての問題を一度に解決したため、利用可能な他のオプションよりも優れた投資となっています。
Thrift の TCompactProtocol は、バイナリ シリアル化プロトコルである Tulip シリアル化プロトコルでペイロードをシリアル化するために使用されます。 フィールドには、Thrift 構造体で ID を変更するときにエンジニアが期待するのと同じ方法で ID が付けられます。 エンジニアは、ロギング スキーマを作成するときにフィールド名と種類のリストを定義します。フィールド ID は、指定されたエンジニアではなく、データ プラットフォーム管理モジュールによって管理されます。 シリアライゼーション スキーマ リポジトリには、ロギング スキーマのシリアライゼーション スキーマへの変換が含まれています。 フィールド名、フィールド タイプ、関連するログ スキーマのフィールド ID、およびフィールド履歴のリストは、シリアル化構成に格納されます。 エンジニアがロギング スキーマを更新する場合、シリアル化スキーマに対してトランザクション操作が実行されます。
参考：https://engineering.fb.com/2022/11/09/developer-tools/tulip-schematizing-metas-data-platform/
忘れずに参加してください 私たちの ML Subreddit
Avanthy Yeluri は、IIT Kharagpur の二重学位の学生です。 彼女はデータ サイエンスに強い関心を持っています。その理由は、データ サイエンスがさまざまな業界にまたがる多数のアプリケーションに加えて、最先端の技術的進歩とそれらが日常生活でどのように使用されているかからです。
<!–
–>
