WeiboにおけるSparkベースの大規模機械学習の応用

[[195122]]

周知のとおり、Weibo のビジネスは 2015 年以降急速に成長しています。内容別に分けると、Weiboのサービスには、主要情報（フィード）フロー、人気Weibo、Weiboプッシュ、スパム対策、Weibo配信制御などが含まれます。各ビジネスには独自のユーザー構成、ビジネスの焦点、データ特性があります。膨大なユーザーベースでは、相互の注意から生まれるユーザー間の関係や、各ユーザーの個別のニーズにより、より高次の大規模な次元でユーザーを特徴付け、説明する必要があります。 Weibo のコンテンツの多さも、多様化とマルチメディア化の傾向を示しています。

Weibo は常に機械学習を利用して、ビジネス シナリオで発生するさまざまな課題を解決しようと努めてきました。この記事は、CCTC 2017 クラウド コンピューティング カンファレンスの Spark サミットで Sina Weibo の Wu Lei 氏が行った「Spark に基づく Weibo での大規模機械学習の応用」と題したプレゼンテーションの一部です。大規模機械学習の課題に直面したときに Weibo が採用したベスト プラクティスとソリューションを紹介しています。

スパーク ミリブ

約 100 億の特徴次元と約 1 兆のサンプルを持つ Weibo のモデル トレーニング要件に応えて、まず Apache Spark にネイティブに実装されているロジスティック回帰アルゴリズムを試しました。このアプローチを採用する利点は明らかで、開発サイクルが短く、試行錯誤のコストが低いことです。ビジネスニーズに応じて、さまざまなソース（ユーザー、Weibo コンテンツ、ユーザー間の関係、使用環境など）から特徴をクリーンアップ、抽出、離散化し、Libsvm 形式でトレーニング可能なサンプル セットを生成し、そのサンプルを LR アルゴリズムに送ってトレーニングします。次元が拡大する過程で、さまざまな側面で問題に遭遇し、実践を通じて解決策を提供しました。

【スタックオーバーフロー】

スタック オーバーフローの問題はネストされた関数呼び出しで非常によく発生しますが、私たちの経験では、Spark RDD 結合操作が多すぎるとスタック オーバーフローの問題が発生する可能性があることがわかりました。自然な解決策は、多数の RDD 結合を避け、代わりに他の実装方法を採用することです。

【AUC=0.5】

モデルのトレーニング プロセス中に、テスト セットの AUC が 0.5 のままになるという厄介な状況が発生しました。トレーニング パラメータを注意深く確認すると、LR の学習率を大きな値に設定すると、勾配降下法が局所最適値の周りを振れ、トレーニング済みモデルのコストが高くなり、適合性が低下することがわかります。この問題は、学習率を適切に調整することで回避できます。

[整数が範囲外です]

整数の範囲外は通常、指定されたデータ値が大きすぎて、整数 (32 ビット Int) の上限を超えていることを意味します。ただし、このシナリオでは、整数範囲外エラーの原因は特定のデータ値のサイズではなく、トレーニング サンプル データの量が大きすぎることと HDFS シャードが大きすぎることが原因で、Spark RDD の 1 つのシャード内のデータ レコード数が整数の上限を超え、範囲外エラーが発生しています。 Spark RDD のイテレータは、整数 (Int) を使用してイテレータの位置を記録します。レコード数が 32 ビット整数 (2147483647) に含まれる範囲を超えると、このエラーが報告されます。

解決策は、Spark が HDFS に Hadoop RDD をロードするときにパーティションの数を設定することです。この問題を回避するには、各シャードのデータ量が十分に小さくなるように、パーティションの数を十分に大きく設定します。適切なパーティション数は、(レコードの総数/単一シャード内のレコード数) という式で計算できます。

【シャッフルフェッチ失敗】

分散コンピューティングでは、シャッフル フェーズは避けられません。シャッフルのマップ フェーズでは、Spark はマップ出力をマシンのローカル ファイル システムにキャッシュします。マップによって出力されるデータが大きく、ローカル ファイル システムのストレージ領域が不足している場合、Shuffle 中間ファイルが失われます。これが、Shuffle フェッチ失敗エラーの一般的な原因です。しかし、私たちのシナリオでは、spark.local.dir 構成項目を手動で設定し、十分なストレージ容量と高い I/O 効率を持つファイル システムを指定しましたが、それでもこの問題が発生しました。

ログと Spark UI レコードを注意深く確認したところ、タスクの負荷が高く GC 時間が長いために、一部の Executor がドライバーとのハートビートを失っていることがわかりました。ドライバーはこれらの Executor のハートビートを感知できないため、Yarn のアプリケーション マスターにこれらの Executor を含むコンテナーを強制終了するように積極的に要求します。

スキンがなくなると、髪は取り付けられません。Executor が強制終了されると、そこに保存されている Map 出力情報は当然失われ、Reducer は Reduce フェーズ中に独自の Map 出力を取得できなくなります。解決策としては、JVM の GC 設定を適切に設定するか、spark.network.timeout 時間 (デフォルトは 60 秒) を 120 秒 (ドライバーとエグゼキューター間のハートビート通信のタイムアウト時間) に設定することです。これにより、エグゼキューターに十分な応答時間が与えられ、過剰な処理タスクのためにドライバーと通信する必要がなくなります。

さまざまな最適化を通じて、モデルの次元を数千万にまで増やしました。モデル次元が 1 億次元に達すると、Spark Mllib LR は非モデル並列として実装されるため、モデル次元が過度に高くなるとヘッセ行列が指数関数的に増加し、メモリとネットワーク I/O のオーバーヘッドが膨大になります。そのため、他の解決策を試す必要がありました。

Sparkベースのパラメータサーバー

多くの調査と予備的な試行を経て、モデルの並列処理の問題を解決するために、最終的にパラメーター サーバー ソリューションを選択しました。パラメータ サーバーは、パラメータ シャードを分散的に保存およびアクセスし、高次元モデルをパラメータ サーバー クラスター内の各マシンに均等に分散し、CPU コンピューティング、メモリ消費、ストレージ、ディスク I/O、ネットワーク I/O などの負荷とオーバーヘッドを分散します。一般的なパラメータ サーバーは、マスター スレーブ アーキテクチャを採用しています。マスターは、各パラメータ サーバーのハートビートとステータスを記録および維持する役割を担い、パラメータ サーバーは、パラメータ シャードの保存、勾配の計算、勾配の更新、レプリカの保存などの特定のタスクを担当します。図 1 は、私たちが使用するパラメータ サーバー ソリューションを示しています。

図1. Weiboパラメータサーバーのアーキテクチャ

ブルーテキスト フレームワークは、マスター スレーブ アーキテクチャを使用するパラメータ サーバー クラスターです。Yarn アプリケーションとして Yarn クラスターにデプロイされ、すべてのアプリケーションにサービスを提供します。パラメータ サーバーのクライアント側では、Yarn アプリケーションを通じて Spark タスクが開始され、LR 分散アルゴリズムが実行されます。図の緑色のテキスト ボックスでは、Spark モデル トレーニングが独立したアプリケーションとして Yarn クラスターに存在します。モデルのトレーニング プロセス中、各 Spark Executor はデータ シャードに基づいてパラメータをプル、計算、更新、プッシュします。

パラメータ サーバーの実装に関しては、業界には完全同期と完全非同期という少なくとも 2 つの実装方法が存在します。完全同期アプローチは理論的にはモデルの収束を保証できますが、分散環境では、各コンピューティング ノードの実行パフォーマンスが異なり、反復中に相互同期が必要になるため、タスクを早期に完了するノードが重いコンピューティング タスクを実行するノードを待機することになりやすく、通信境界が導入され、コンピューティング データの無駄とオーバーヘッドが発生します。完全非同期方式では、ノード間の待機や同期が不要で、各ノードのコンピューティング リソースを最大限に活用できるため、これらの問題を効果的に回避できます。モデルが収束するかどうかを理論的に検証することは不可能ですが、実践を通じて、モデルの反復速度が毎回速くなり、AUC の加速が高くなり、実際のトレーニング済みモデル効果がビジネスおよびオンラインの要件を満たすことができることがわかりました。

パラメータ サーバーを介して LR モデルをトレーニングする際に、実行パフォーマンスに影響を与える主な要因を次のようにまとめました。

【バッチサイズ】

つまり、Spark データ シャードのサイズです。前述のように、各 Spark Executor はデータ シャード単位でパラメータをプルおよびプッシュします。シャードのサイズによって、この反復で取得および通信する必要があるパラメータの数が直接決定され、パラメータの数は、ローカル反復での計算と通信の量を直接決定します。したがって、シャード サイズは、モデル トレーニング実行のパフォーマンスに影響を与える主な要因です。データ シャードが大きすぎると、単一の反復タスクが重くなりすぎて、Executor が過負荷になります。一方、シャードが小さすぎると、ネットワーク スループットを最大限に活用できますが、余分なオーバーヘッドが多く発生します。したがって、適切なバッチ サイズを選択すると、実行パフォーマンスがより効率的に向上します。以下では、バッチ サイズを例に、さまざまな設定でのモデル トレーニング実行パフォーマンスの違いを比較します。

[PSサーバー数]

パラメータ サーバーの数によって、モデル パラメータのストレージ容量が決まります。パラメータ サーバー クラスターを拡張することで、理論上はストレージ容量を無限に拡張できます。ただし、クラスターのサイズがボトルネック値に達すると、パラメータ サーバーが多すぎるために発生するネットワーク オーバーヘッドにより、全体的な実行パフォーマンスが低下したり、低下したりすることがあります。

【特徴スパース性】

必要に応じて、マッピング機能を通じて、元のビジネス特徴（ユーザー、マイクロブログコンテンツ、ユーザー間の関係、使用環境など）を高次元モデルにマッピングし、より優れた識別力で特徴を抽出できます。各反復データ シャードのデータ分布と組み合わせた特徴のスパース性により、シャードのこの反復でプルおよびプッシュする必要があるパラメーターの数が決まり、それによってこの反復に必要なコンピューティング リソースとネットワーク オーバーヘッドが決まります。

[PSパーティション戦略]

パーティション戦略は、パラメータ サーバー内のモデル パラメータの分散を決定します。適切なパーティション戦略により、モデル パラメータの分散がより均等になり、各ノードの計算負荷と通信負荷が均等に分散されます。

スパークメモリ計画

PS クライアントでは、Spark Executor は、後続のパラメータ計算と更新タスクを完了するために、シャードのこの反復に必要なパラメータ ベクトルを収容するのに十分なメモリがあることを確認する必要があります。

次の表は、異なるバッチ サイズでの実行パフォーマンス インジケーターを比較したものです。パラメータ (MB) は 1 回の反復に必要なパラメータの数を示します。Tx (MB) は 1 回の反復のネットワーク スループットを示します。Pull (ms) と Push (ms) はそれぞれ 1 回の反復でのプルとプッシュの消費時間を示します。時間 (s) は 1 回の反復の全体的な実行時間を示します。表 1 からわかるように、パラメータの数はシャード サイズに比例し、ネットワーク スループットはシャード サイズに反比例します。シャードが小さいほど、通信および処理する必要があるパラメータは少なくなりますが、PS クライアントと PS サーバーの通信頻度が高くなるため、ネットワーク スループットは高くなります。ただし、シャードが小さすぎると、追加のオーバーヘッドが発生し、パラメータのプルとプッシュに必要な平均時間と、タスクに必要な全体的な時間が増加します。

パラメータサーバーソリューションを通じて、Weiboの機械学習プラットフォーム化のプロセスにおける大規模モデルトレーニングの問題を解決しました。ご存知のとおり、機械学習のプロセスにおいて、モデルのトレーニングは最も短い部分にすぎません。機械学習のプロセスを料理に例えると、モデルのトレーニングは最終的な炒め工程です。調理時間のほとんどは、実際には材料と調味料の選択、野菜の洗浄と選択、材料のさらなる加工（さいの目切り、角切り、揚げる、予熱）などに費やされます。

Weibo の機械学習プロセスでは、元のサンプル生成、データ処理、特徴エンジニアリング、トレーニング サンプル生成、モデルの事後テスト、評価などのステップに必要な時間と労力が、プロセス全体の 80% を占めています。エンドツーエンドの機械学習フローを効率的に開発する方法、オンラインフィードバックに基づいて高識別機能をタイムリーに選択する方法、モデルを最適化し、モデルの有効性を検証する方法、モデルの反復の効率を加速する方法、オンライン要件を満たす方法など、これらはすべて解決する必要がある問題です。 『プログラマー』最新号の「Weiflow - Weibo機械学習フロー統合コンピューティングフレームワーク」では、それらの質問に一つずつお答えします。

Wu Lei 氏は Weibo アルゴリズム プラットフォームのシニア エンジニアです。主に、Spark を中核とするビッグ データ コンピューティング フレームワークと機械学習プラットフォームの設計と実装を担当しています。 IBM および Lenovo Research Institute に勤務し、データベース、データ ウェアハウス、ビッグ データ分析関連の業務に従事しました。

Zhang Tuoyu は Weibo のシステム開発エンジニアです。主な開発者および設計者として、Weibo の大規模機械学習、機能エンジニアリングなどのプロジェクトに参加しています。コンピューティング プラットフォーム パラメータ サーバーと大規模学習アルゴリズムの研究とエンジニアリング実装を担当しています。