機械学習ライブラリ(MLlib)ガイド
MLlibはSparkの機械学習(ML)ライブラリです。その目的は実用的な機械学習をスケーラブルおよび簡単にすることです。高レベルでは、それは以下のようなツールを提供します:
- ML アルゴリズム: 分類、回帰、クラスタリング、および協調フィルタリングのような一般的な学習アルゴリズム
- 特徴化: 特徴抽出、変換、次元削減、および選択
- パイプライン: 構築、評価、およびMLパイプラインのチューニングのためのツール
- 永続性: アルゴリズム、モデル、およびパイプラインの保存とロード
- ユーティリティ: 線形代数、統計、データ処理など
発表: データフレームに基づいたAPIは主要なAPIです
MLlib RDDベースのAPIは、今はメンテナンスモードにあります。
Spark 2.0の時点で、spark.mllib
パッケージ内のRDDに基づいたAPIはメンテナンスモードに入りました。Sparkのための主要な機械学習APIは、今はspark.ml
パッケージ内のDataFrameに基づいたAPIです。
何を意味するのか?
- MLlib はまだバグ修正のために
spark.mllib
内のRDDベースのAPIをサポートするでしょう。 - MLlibはRDDベースのAPIに新しい機能を追加しないでしょう。
- Spark 2.xリリースで、MlLibはRDDベースのAPIと同等の機能に手を届かすためにデータフレームベースのAPIに機能を追加するでしょう。
- 同等の機能に手が届いた後(おおざっぱにSpark2.3と推測されます)、RDDベースのAPIは非推奨になるでしょう。
- RDDベースのAPIはSpark 3.0で削除される予定です。
なぜMLlibはデータフレームに基づいたAPIに切り替わっているのか?
- データフレームはRDDよりももっと使いやすいAPIを提供します。データフレームの多くの利点は、Spark Datasources, SQL/DataFrame クエリ, Tungsten および Catalyst 最適化を含み、言語間でAPIを揃えます。
- MLlibのためのデータフレームに基づいたAPIはMLアルゴリズム間および複数の言語間で均一なAPIを提供します。
- データフレームは実践的なMLパイプライン、特に特徴の変換を容易にします。詳細はパイプライン ガイド を見てください。
"Spark ML"とは何か?
- “Spark ML” は公式の名前ではありませんが、データフレームAPIに基づいたMLlibを参照する時にしばしば用いられます。データフレームに基づいたAPIによって使われる
org.apache.spark.ml
Scala パッケージ名に大きくよるもので、“Spark ML Pipelines” という単語はパイプラインの概念を強調するために初期に使われました。
MLlibは非推奨ですか?
- いいえ。MLlib はRDDベースのAPIとデータフレームベースのAPIの両方を含みます。RDDベースのAPIは今ではメンテナンスモードです。ですが、全体としてはAPIもMLlibの両方とも非推奨ではありません。
依存
MLlib は線形代数パッケージ Breezeを使用します。これは最適化された数学処理のためにnetlib-javaに依存します。実行時にネイティブライブラリ1が利用できない場合は、警告メッセージが表示され、ピュアJVM実装が代わりに使われるでしょう。
ランタイムのプロプライエタリ バイナリのライセンスの問題で、デフォルトではnetlib-java
のネイティブ proxiesを含んでいません。システムに最適化されたバイナリを使用するために netlib-java
/ Breeze を設定するには、プロジェクトの依存としてcom.github.fommil.netlib:all:1.1.2
をインクルード(あるいはSparkを -Pnetlib-lgpl
付きでビルド)して、プラットフォームの追加のインストレーション説明のために netlib-javaドキュメントを読んでください。
Intel MKL, OpenBLASのような最も一般的な native BLASは1つの層さで複数のスレッドを使うことができます。これらはSparkの実行モデルと衝突するかもしれません。
操作のために1つのスレッドを使うようにこれらのBLAS実装を設定すると、実際にはパフォーマンス改善するかもしれません (SPARK-21305を見てください)。これを各Sparkタスクが使用するように設定されたコアの数に一致させるのが通常は最良です。これはデフォルトでは1で、一般的には1のままにされます。
これらのBLAS実装が使用するスレッドの数を設定する方法を理解するには、以下のようなリソースを参照してください: Intel MKL と OpenBLAS。
PythonでMLlibを使用するには、NumPy バージョン1.4以上が必要になるでしょう。
2.3 の見どころ
以下のリストはSpark 2.3
リリースでMLlibに追加された特徴と拡張の幾つかを強調します:
- イメージを
DataFrame
に読み込むための組み込みのサポートが追加されました (SPARK-21866)。 OneHotEncoderEstimator
が追加され、既存のOneHotEncoder
変換器の代わりに使われるべきです。新しいestimatorは複数のカラムの変換をサポートします。QuantileDiscretizer
とBucketizer
にも複数のカラムのサポートが追加されました (SPARK-22397 and SPARK-20542)- 新しい
FeatureHasher
変換器が追加されました (SPARK-13969)。 TrainValidationSplit
またはCrossValidator
を使ってクロス検証を行う時に複数のモデルを評価するためのサポートが追加されました (SPARK-19357)。- Pythonでの独自のパイプライン コンポーネントのためのサポートが改善されました (SPARK-21633 と SPARK-21542を見てください)。
- ベクトル カラムの説明的なサマリの統計のための
DataFrame
関数 (SPARK-19634)。 - Huberロスを持つ頑丈な線形回帰 (SPARK-3181)。
移行ガイド
MLlib はアクティブに開発中です。Experimental
/DeveloperApi
と印が付けられているAPIは将来のリリースで変更するかも知れません。以下の移行ガイドはリリース間の全ての変更を説明するでしょう。
2.2 から 2.3
破壊的な変更
- ロジスティック回帰モデルのサマリのためのクラスとトレイトの階層が、多数クラスサマリの追加を綺麗により良く提供するように変更されました。これは
LogisticRegressionTrainingSummary
をBinaryLogisticRegressionTrainingSummary
にキャストするユーザコードにとって破壊的な変更です。ユーザは代わりにmodel.binarySummary
メソッドを使う必要があります。詳細は SPARK-17139 を見てください (注意 これは実験的な
APIです)。これは Python のsummary
メソッドに影響しません。多項式および二項の両方でまだ正しく動作するでしょう。
非推奨と挙動の変更
非推奨
OneHotEncoder
は非推奨になり、3.0
で削除されるでしょう。新しいOneHotEncoderEstimator
によって置き換えられました (SPARK-13030を見てください)。OneHotEncoderEstimator
は3.0
でOneHotEncoder
に名前が変えられるだろうことに注意してください (しかしOneHotEncoderEstimator
はエイリアスとして保持されるでしょう)。
挙動の変更
- SPARK-21027:
OneVsRest
で使われるデフォルトの並行度は今では1に設定されます (つまり連続)。2.2
とそれ以前のバージョンでは、並行度のレベルはScalaでのデフォルトのスレッドプールのサイズに設定されていました。 - SPARK-22156:
numIterations
が1
より大きく設定された場合に、Word2Vec
のための学習レートの更新が間違っていました。これは、2.3
とそれより前のバージョンの間で訓練結果が異なるものにするでしょう。 - SPARK-21681: 幾つかの特徴が0の分散を持つ場合に多項ロジスティック回帰の結果が間違った係数になる極端な場合のバグを修正しました。
- SPARK-16957: ツリー アルゴリズムは今では分割された値の間の点を使います。これはモデルの訓練からの結果を変更するかもしれません。
- SPARK-14657: 切片無しの
RFormula
によって生成される特徴がRでの出力と矛盾した問題の修正。これはこのシナリオでのモデルの訓練からの結果を変えるかもしれません。
以前のSparkのバージョン
以前の移行ガイドはこのページに保管されています。
-
システムに最適化されたネイティブコードの恩恵とバックグラウンドについて知るために、High Performance Linear Algebra in ScalaでのSam HallidayのScalaXトークを見たいと思うかも知れません。 ↩