Hudiに基づくByteDanceの機械学習アプリケーションシナリオ

統合ストリームとバッチサンプルの生成プロセスを明らかにし、Hudiカーネルの最適化と変換を共有し、データ処理分野での実際のアプリケーションと効果を探ります。

この記事の概要は次のとおりです。

• ビジネスシナリオ
• オフラインサンプルの保存と反復
• ストリームとバッチ統合サンプル生成
• 機能と最適化

1. ビジネスシナリオ

次に説明するデータ レイクに基づくサンプルの保存とサンプル生成の問題を誰もが理解しやすくするために、この記事ではまず関連する基本的な概念を簡単に紹介します。 1つ目は、機械学習システムのオフラインデータフローアーキテクチャです。機械学習システムは他のオンラインサービスシステムと似ており、サンプルに関連する役割も比較的集中しています。下の図に示すように、オフライン データ フロー アーキテクチャ全体は、ストリーミングとバッチの 2 つのタイプに分かれています。サンプル データは、特徴とラベルの 2 つの部分で構成されています。

ストリーミング アーキテクチャでは、機能はサービス提供中にオンライン推定サービスによってダンプされ、メッセージ キューに送信されます。タグはリアルタイム動作収集サービスから取得され、ログレポートなどの方法を通じて収集されます。オンライン サンプル生成サービスは、2 つのデータ ストリームを消費し、関連付けを通じて完全なサンプルを取得し、それらをモデル トレーニング用の下流のストリーミング トレーニング サービスに送信して、サンプル データの消費を完了します。

バッチ アーキテクチャは、ストリーミング アーキテクチャを補完するものです。バッチ アーキテクチャは、ストリーミング データをサブスクライブすると同時に、バッチ機能やバッチ生成ラベルも追加します。たとえば、リスク管理、不正防止、広告ビジネスでは、バッチ生成されたデータがあり、バッチ サンプル生成モジュールを使用してサンプルを生成し、それをモデル トレーニング コンポーネントで使用します。

ストリーミングおよびバッチ データ フロー アーキテクチャには、メタデータ サービスもあります。メタデータ サービスは、機能の関連メタデータを記録します。ストリーミング データ フローとバッチ データ フローはどちらも、メタデータ サービスにアクセスしてメタ情報を取得します。したがって、バッチ機能ストレージにはいくつかの特定のアクセス パターンがあります。

読み取りに関しては、スループット指標に重点を置いた大規模な毎日のバッチ読み取り、数秒以内のポイント クエリ、効率的な述語プッシュダウン クエリ機能、主キー/外部ビルドに基づく結合の存在などのデータ読み取りパターンが利用可能です。

次の書き込み機能がサポートされている必要があります: 主キーに基づくアップサート、一部のセルの挿入と更新、行/列/セルの削除、外部キーに基づくアップサート。

この文脈では、機械学習のためのオフライン データ ストリームにおける Hudi のいくつかのアプリケーション シナリオを理解します。

2. オフラインサンプルの保存と反復

設計されたサンプルのオフライン ストレージ ソリューションが、主に次の 3 つの状況を含むさまざまなシナリオに適用できることを期待しています。

まず、モデルを再トレーニングし、ストリーミング トレーニング プロセスを再生し、モデルを反復/修正するなどします。

次に、サンプル データを反復処理し、対応する機能/ラベルを追加、変更、または削除して、モデルを再トレーニングします。

3 番目は、日常のデバッグなどに使用されるサンプル OLAP クエリです。

上記のシナリオでのサンプルの保存と反復をサポートするために、私たちが提案するストレージ ソリューションの全体的なアーキテクチャは次のように設計されています。論理モデリングの観点では、サンプル ストレージの構築は、特定のパターンの Hive テーブルの構築と非常に似ています。サンプルには、主キー、パーティション キー、内部メタデータ列などの機能列が含まれ、さらにいくつかの機能列といくつかのラベル列が含まれます。物理アーキテクチャでは、ストリーミングとバッチで生成/収集された特徴データとラベルデータが複数のジョブの混合アップサートを通じて Hudi に書き込まれ、KV ストレージ内のインデックス情報が更新され、実際のデータが HDFS に書き込まれます。 Hudi の主キー/外部キーのアップサート機能により、データは自然に結合され、使用するための特徴とラベルを含む完全なサンプル データが形成されます。

写真

オフライン機能を調査する際には、不変のファイル ストレージである HDFS に基づいて、低コストで読み取り/書き込み増幅データ変更をいかにして実現するかという課題に直面します。データ レイクを使用する前は、ユーザーはサンプルをコピーして変更し、別のコピーを保存してから、オフラインで機能調査を行う必要がありました。これには膨大なコンピューティング リソースとストレージ リソースが消費されます。サンプル サイズが大きくなると、このようなソリューションは数 EB のストレージを消費し、反復処理が不可能になります。

Hudi に基づいて ColumnFamily 機能を実装しました。このソリューションは、異なるファイルを使用して異なる IO パターンでデータを保存し、不要な読み取りおよび書き込みの増幅を減らす、従来の BigTable ストレージ Apache HBase にヒントを得ています。原則としては、同じファイル グループの異なる列データを異なるファイルに保存し、読み取り時にそれらをマージします。この方法では、新しく追加された列のデータが別のファイルに保存されるため、変更や追加のコストが非常に低くなります。

調査機能列に別の CF を割り当てることで読み取り/書き込み増幅を減らし、オンライン機能の CF を他の列に再利用します。この方法では、リソースの使用は新しく追加された機能にのみ関連します。このアプローチにより、反復処理に必要なストレージが大幅に削減され、シャッフル操作も発生しません。

上記の記事では、オフライン サンプルのストレージと反復ソリューションについて紹介しました。次に、オンライン サンプル生成用のストリーム バッチ統合生成ソリューションをさらに紹介し、オンライン ストレージのコストを削減する方法について説明します。

3. ストリームとバッチ統合サンプル生成

オンラインサンプル生成サービスでは、サンプルスプライシングのニーズを満たすために、RocksDB などの KV または BigTable ストレージを使用します。このタイプのストレージは、ポイントチェックのパフォーマンスが優れており、レイテンシが低いですが、ストレージ コストも高くなります。データに明らかなホット層とコールド層がある場合、このタイプのストレージ自体はそのようなストレージのニーズを十分に満たすことができません。 Hudi は、KV セマンティクスと低ストレージ コストを備えたオフライン ストレージです。オンライン ストレージのコストを削減し、統一された読み取りおよび書き込みインターフェイスを通じて差異を保護するために、コールド データを Hudi に保存します。このアーキテクチャは、現在市場に出回っているさまざまな HSAP システムからもインスピレーションを得ています。

Hudi がより優れたポイント クエリをサポートできるようにするために、書き込み時に HBase インデックスを再利用しました。クエリ要求は、まず HBase インデックスにアクセスしてデータが配置されているファイルを見つけ、次にそのファイルに基づいてクエリを実行します。エンドツーエンドの全体的な遅延を数秒に短縮できます。ストレージ ボリュームが大きく、QPS が低いシナリオに適しています。

4. 機能性と最適化

多くのビジネス ニーズを満たすために Hudi を使用する過程で、ビジネス シナリオにより適切に対応できるようにカーネルにもいくつかの変更を加えました。

4.1 ローカルソート

単一ファイル内での主キーのソートをサポートしています。ソートはクエリのパフォーマンスを最適化するための一般的な方法です。主キーをソートすることで、次のようなメリットが得られます。

• CF を読み取るときに、ソートマージ方式を使用して複数の CF がマージされ、メモリ使用量が削減されます。
• 圧縮中にソートマージがサポートされます。スピルはトリガーされず、メモリ使用量は低くなります。以前はパフォーマンスを確保するために SSD キューを圧縮に使用していましたが、現在は安価なリソース (ディスクレス Tidal リソースなど) を圧縮に使用できるようになりました。
• 統合ストリームとバッチサンプル生成では、主キーがソートされるため、クエリを実行するときに主キーに基づく述語プッシュダウン効果が非常に優れています。ポイント クエリのパフォーマンスが向上しました。

4.2 バルクロード同時書き込み

同時並行して執筆することは、常に Hudi にとって大きな課題でした。ビジネス シナリオでは、行レベル/列レベルの書き込み競合が発生する可能性がありますが、これは楽観的ロックでは回避できません。データの競合を解決するための機械学習の必要性に基づいて、これまで MVCC 競合解決方法をサポートしてきました。さらに、Hudi が同時読み取りと書き込みをサポートできるようにするために、同時書き込みの要件を解決するために HBase の Bulkload サポートを参照します。すべての書き込みデータは正常に書き込まれ、データの競合はデータ内の mvcc によって判断されます。

まず、データ ファイルを一時バッファに生成します。各バッファはコミット要求に対応しており、一時バッファへの書き込み要求を複数同時に実行できます。データが一時バッファに完全に書き込まれた後、データ ロード要求を受け入れ、ファイルを移動してバッファから Hudi にデータをロードし、対応するコミット情報を生成する常駐タスクがあります。複数のロード要求は線形に実行され、これは Hudi Timeline のテーブル ロックによって保証されます。ただし、各ロード要求にはファイルの移動のみが含まれるため、ロード要求の実行時間は数秒単位となり、高スループットのデータ同時書き込みと最終的な一貫性が実現されます。

4.3 圧縮サービス

圧縮に関しては、Hudi コミュニティはすぐに使用できるいくつかの圧縮戦略を提供します。ただし、ビジネス要件は非常に柔軟であり、すぐに使用できる戦略に分類することはできません。そのため、ユーザーの圧縮リクエストを処理するための Compaction Service などのコンポーネントを提供し、ユーザーが積極的に圧縮をトリガーし、圧縮のデータ範囲、リソース使用量などを指定できるようにします。ユーザーは、自動データ入力の効果を実現するために、定期的に圧縮をトリガーすることもできます。

最下層では、圧縮ビジネス シナリオのためにホット キューとコールド キューを異なる層に分割しています。さまざまな SLA に従って、対応するキュー リソースを選択して圧縮タスクを実行します。圧縮の全体的なコストを削減するために使用されます。たとえば、毎日のデータ検証は、専用キューによって実行される高セキュリティの圧縮タスクです。ただし、履歴データの単一の修復によってトリガーされる圧縮は実行時間の影響を受けず、より低いコストで完了するように低優先度のキューにスケジュールされます。

データレイクのサンプル保存と生成の問題に対応するため、さまざまなシナリオに適したストレージソリューションアーキテクチャを構築し、バッチとストリームを統合したサンプル生成を実装し、Hudiカーネルに特定の変更を加えることで、実際のビジネスニーズにより適した機能設計を実現しました。