Tulip: Meta のデータ プラットフォームの最新化

移行は難しいです。 さらに、メタでは次の理由でさらに難しくなります。

移行ストーリーの詳細に入る前に、一歩下がって、この移行の動機と理論的根拠を説明したいと思います。

時間の経過とともに、企業のニーズの増大に応じて、データ プラットフォームはさまざまな形に変化してきました。 初期には控えめなデータ プラットフォームであったものが、エクサバイト規模のプラットフォームに成長しました。 小規模なシステムにサービスを提供する一部のシステムでは、増大する要求に対して不十分な兆候が見られ始めました。 最も注目すべきは、データ (デ) シリアル化に関連する信頼性と効率性に関するいくつかの具体的な問題に遭遇したことです。そのため、データのログ記録方法を再考し、これらの差し迫った問題に対処するために第一原則からの考え方を再考する必要がありました。

ロガーはデータ プラットフォームの中心です。 このシステムは、分析データと運用データを Scribe 経由で Scuba、Hive、およびストリーム処理パイプラインに記録するために使用されます。 すべての製品およびデータ プラットフォーム チームはログを操作します。 ログのデータ形式は、従来の理由により、Hive Text Delimited または JSON のいずれかでした。 これらの形式の制限については、Tulip に関する以前の記事で説明しています。

これらの制限に対処するために、従来の宛先固有のシリアル化形式を置き換える Tulip シリアル化形式が開発されました。

以下のグラフは、シリアル化形式を Tulip に変換する移行の過程をグラフィカルに示し、さまざまな段階やマイルストーンでの進捗状況を示しています。

ロギング スキーマの数はほぼ同じまま (または何らかの自然な増加が見られた) 一方で、シリアル化形式の変更により、ログに記録されたバイト数が大幅に減少していることがわかります。 フォーマット固有のバイト節約に関する詳細は、以下のセクションに表にまとめられています。

注: グラフ 2 の数値は、最大 (量ベース) の 5 つのロギング スキーマで観察された実際の節約量に基づいて (全体のトラフィックに) 推定されています。

私たちの移行の旅を、それぞれの視点を持つ 2 つの異なるフェーズとして紹介したいと思います。

移行を念頭に置いてシステムを設計すると、移行がはるかに簡単になります。 次のエンジニアリング ソリューションは、ワイヤ フォーマットを安全に切り替え、移行フェーズ中に発生する可能性のある問題をスケーラブルな方法でデバッグするために必要なツールとインフラストラクチャ サポートをチームが確実に備えられるようにするために開発されました。

ソリューションは大まかに次のカテゴリに分類されます。

課題: データのプロデューサーとコンシューマーがシリアル化形式をアトミックに切り替える必要をなくすことで、移行を容易にし、リスクを軽減するにはどうすればよいでしょうか?

解決策: 単一のロギング スキーマを切り替えて、新しい Tulip シリアル化プロトコルを使用してペイロードを書き込む場合、すべてのデータ プロデューサーを新しい形式を使用するように「アトミックに」切り替えることは不可能であるため、単一のスクライブ ストリームで混合モード ペイロードをサポートする必要がありました。 。 これにより、チームは新しい形式のシリアル化の展開を制限することもできました。

混合モード ワイヤ フォーマットは、シャドウ ロガーの概念をサポートするために重要でした。シャドウ ロガーは、大規模な展開前のエンドツーエンドの受け入れテストに広く使用されました。

混合モード ワイヤー形式の主な課題は、Hive テキストまたは JSON 形式のペイロードの既存のシリアル化を変更できないことでした。 この制限を回避するために、Tulip でシリアル化されたすべてのペイロードには、無効な utf-8 シーケンスである 2 バイト シーケンス 0x80 0x00 がプレフィックスとして付けられます。

課題: 一部のシステムでは、Hive Text (または JSON) シリアル化形式がアプリケーション コードに組み込まれ、ペイロードの消費にこの形式に依存することになりました。 これは、消費者がシリアル化形式の抽象化を突破した結果です。

解決策: 2 つの解決策がこの課題に対処しました。

リーダー (データの逆シリアル化用のロガー相当物)

Reader は、シリアル化されたペイロードを構造化オブジェクトに変換するライブラリです。 リーダー (ロガーと同様) には、(a) 生成されたコードと (b) 汎用の 2 つの種類があります。 リーダー オブジェクトは、Tulip、Hive Text、または JSON の 3 つの形式のいずれかのデータを消費し、構造化オブジェクトを生成します。 これにより、チームは移行が開始される前に、コンシューマーをリーダーの使用に切り替えることができました。 生のシリアル化された行ではなく、この構造化オブジェクトを使用するようにアプリケーション コードを更新する必要がありました。 これにより、データの消費者からワイヤー形式が抽象化されました。