翻訳：Saki Kitaoka. - Original Blog Link
データサイエンティストが機械学習ソリューションを開発する際に遭遇する一般的な課題は、サーバーのメモリに収まらないほど大きなデータセットでモデルをトレーニングすることです。これは、顧客の離反や傾向を予測するモデルをトレーニングする際に、数千万人のユニークな顧客を扱う必要がある場合に発生します。ある期間に行われた何億もの広告インプレッションに関連するリフトを計算する必要があるとき、このようなことが起こります。また、何十億ものオンラインインタラクションの異常行動を評価する必要がある場合にも、この問題が発生します。
この課題を克服するために一般的に採用されているソリューションの1つは、Apache Sparkデータフレームに対して動作するようにモデルを書き換えることです。Sparkデータフレームでは、データセットはパーティションと呼ばれるより小さなサブセットに分割され、Sparkクラスタの集団リソースに分散されます。
より多くのメモリが必要ですか？クラスターにサーバーを追加するだけです。
課題: 期待したほど速く処理できない
これは 、与えられたサーバのメモリ制限を克服するための素晴らしいソリューションのように聞こえますが、実際には、すべてのモデルが分散Sparkデータフレームを利用するように書かれているわけではありません。Spark MLlibのモデル群はデータサイエンティストが使用するコアアルゴリズムの多くに対応していますが、分散データ処理のサポートが実装されていないモデルも多くあります。
さらに、Sparkデータフレームで学習したモデルを推論（予測）に使用したい場合、そのモデルはSpark環境のコンテキストで実行する必要があります。この依存関係は、このようなモデルを展開できるシナリオを制限するオーバーヘッドを生み出します。
課題への対応
機械学習シナリオの増加にとってメモリの制限が重要な障害であることを認識し、Sparkデータフレームをサポートするように更新されるMLモデルが増加しています。これには、非常に人気のあるXGBoostモデルファミリーや、LightGBMモデルファミリーの軽量バリアントが含まれます。これら2つのモデルファミリーがSparkデータフレームをサポートすることで、多くのデータサイエンティストが分散データ処理にアクセスできるようになります。しかし、推論中のモデルのオーバーヘッドという下流の問題をどのように克服できるでしょうか？
このブログに付随するnotebook assetsでは、Sparkデータフレームを使用してXGBoostモデルとLightGBMモデルの両方を分散方式で学習し、学習した情報をモデルの非分散バージョンに転送するた めのシンプルなパターンを文書化しています。非分散バージョンはApache Sparkに依存しないため、マイクロサービスやエッジデプロイメントシナリオに適した、より軽量な方法でデプロイできます。このアプローチの背後にある正確な詳細は、以下のノートブックに記載されています：
- XGBoost
- LightGBM
このパターンが、お客様がデータの可能性を最大限に引き出す一助となることを願っています。
XGBoost on Databricksについてもっと知る