Advanced Analytics from Spark #3 協調フィルタリング #1

台風24号ヒット! この莫大な破壊的エネルギーをプラス方向に利用できないのだろうか?
こちらはとにかくSparkするということで、Advanced Analytics from Spark第二章:交互最小二乗法を用いた協調フィルタリング:要するにrecommenderのアルゴリズム
—————————————————–
まずは、もととなるlast.fmの音楽情報ファイルのダウンロードと、HDFSへのコピー。
たいていリンクが壊れているのだが、幸い以下のサイトからデータファイルをダウンロード
http://www.iro.umontreal.ca/~lisa/datasets/profiledata_06-May-2005.tar.gz
必要なファイルは以下の3つ:
user_artist_data.txt 426.8M
artist_data.txt 56M
artist_alias.txt  2.9M
巨大なテキストファイル!
ファイルの内容は、README.txtによると
user_artist_data.txt
3 columns: userid artistid playcount

artist_data.txt
2 columns: artistid artist_name

artist_alias.txt
2 columns: badid, goodid
known incorrectly spelt artists and the correct artist id.
you can correct errors in user_artist_data as you read it in using this file
(we’re not yet finished merging this data)

user_artist_data.txtは、UserID ?tab ArtistID ?tab 再生回数

artist_data.txtは、ArtistID ?tab Artist名

artisit_alias.txtには、どうやら同じアーティストの異なるIDの接続リストbadid, goodidのようだ。

単純なデータだが、巨大なテキストファイルである。
この3つのテキストファイル、つまりユーザーがどのアーティストの曲を何回選択したかという単純な情報をもとに、機械学習をさせて、あるユーザーに推奨するアーティスト名を返すというコードを構築する。
Sparkの機械学ライブラリMLlibのAlternating Least Squares(ALS)を用いて構築するわけだが、
作業としては、artisit_alias.txtを用いて間違ったIDを正しいID(finalArtistID)に置き換えることと、ALSのアルゴリズムに放り込むために、Ratingオブジェクト(userID, finalArtistID, count)に変換する。かつ、Artist IDリストを放り込めば、アーティスト名が返されるようにしたいという訳。
————————————–
まずは、巨大なテキストファイルを、HadoopのHDFSに移す。

http://localhost:9870/ でbrowseして転送されたか確かめると、

でOK。

では、Sparkの操作に移る。
大量のメモリが必要ということで、マルチコアモード&6G設定でspark-shellを立ち上げる。

まずは、データのRDDへの取り込み

UserIDやArtistIDについて統計を見ると、

UserID最大値は、2,443,548件、Artist ID最大値は10,794,401
次にArtistIDを取り込む。

アーティストIDとアーティスト名のリストを作成しておく:

重複するアーティストIDについて、”正しい”IDに紐づけするMapを作成する。

ーーーーーーーーーーーーーーーーーーーーーー
次にモデル構築に先立って、Saprk MLlibのALSの実装での抽象化オブジェクトRatingを作成しておく。Ratingは(userID, finalID, count)という配列で構成される。

いよいよALSモデル構築:

レコメンデーションを動かしてみると、