副題: ビッグデータ時代の非ビッグデータ集計戦略

PHP と MySQL を使ってカジュアルに MapReduce する MyMR というものを作ってみました.
とても安直な名前ですね.

yuya-takeyama/mymr – GitHub

とりあえず試してみる

MyMR には, MapReduce のマナー (?) に従って, WordCount するためのサンプルコードとサンプルデータを同梱してみました.

map/reduce 関数は PHP で書かれています.
WordCount.php

MySQL のユーザ名・パスワード等は適宜置き換えて下さい.

見事, 入力テーブル内の単語の出現回数を集計することができました.

MyMR の特徴

  • データの入出力はいずれも MySQL のテーブル
  • 入力と出力のデータベースは同じでもいいし別でもいい
    (入力はプロダクションサービスの Slave サーバで, 出力はデータ集計用の別サーバ, とかいうこともできる)
  • map/reduce 関数を PHP で書く
  • MySQL を意識することは無く, PHP 標準の array にほげほげするだけ
  • 分散/冗長性/耐障害性などについては特に考えていないし, 考える予定も無い
    (エラー処理はちゃんとしたい)
  • 並列処理でなく直列処理
    (並列処理は出来た方がいいと思っている)

まだ「とりあえず動く」程度の状態なので, 色々足りてない状態ではありますが, ギガ/テラバイト級のデータを相手にするのであれば Hadoop とかを使うべきだと思いますし, MyMR はそのような問題を解決しようとはしていません.

モチベーション

  • MySQL に直接 MapReduce 処理を行いたい
  • GROUP BY よりはもっと複雑な処理がやりたい
  • map/reduce を LL で書きたい
  • プログラミングモデルとしての MapReduce を活用したい

DBMS 上で MapReduce をやりたいのであれば MongoDB や CouchDB という選択肢がありますし, map/reduce を LL で書きたいというのであれば Hadoop Streaming という選択肢があるでしょう.
そうなると, やはり一番のモチベーションは MySQL で MapReduce する ということに尽きるように思います.

MongoDB による MapReduce も JavaScript でカジュアルにできてとても便利です.
ですが, 自分の場合, 普段の仕事だと, そもそものデータはほとんど MySQL に入っているので,

  1. mysqldump で csv ファイルを作成
  2. mongoimport で MongoDB にインポート
  3. MongoDB 上で MapReduce

みたいな手順を踏む必要があり, 非常に面倒です.
場合によっては mongoexport で csv に出力してさらに MySQL 上にインポート, なんてことをやることもあって, 正直疲れました.

MySQL で ということの次に重要だと思うのが, プログラミングモデルとしての MapReduce です.
これについては書くと長くなりそうなのでやめておきますが, Haskell のような関数型言語をつまみ食いすることで, この辺りの魅力がわかってきたように思います.
(関数型言語における map 関数と Hadoop/MongoDB/MyMR における Map はちょっと違いますが)
伊藤直也さんの MapReduce::Lite なんかも, その辺りにモチベーションがあって作られたのではないか, と想像しています.

何故 PHP か

特に大した理由はありません.
強いていえば仕事で使いたいと思っていて, 周囲で使われているのが PHP である, というだけの話です.

ついでに挙げるなら, PHP では MySQL ドライバが標準で備わっている, というのもあります.
MyMR では PDO を使っており, 普通に構築された LAMP 環境であれば, まず問題無く使えると思います.

とはいえ, 例えば Bundler の使える環境であればそういった依存関係に悩まされることもありませんし, 正直 Ruby で書き直したい.

MyMR の仕組み

仕組みといえるほど複雑なことはやっていませんが…

1: 入力データの取得

これはとても単純で, mymr コマンドの -i (–input) オプションに渡したテーブルを全件 SELECT するのみです.

今の所全データをガバっとメモリ内に取り込むようになっているので, テーブルサイズに比例してメモリを食います.
非ビッグデータ向けのフレームワークとはいえ, これはさすがにあんまりなので, 何とかするつもりです.

あと, 未実装ですが, WHERE 条件なども指定できれば入力の段階でフィルタできて便利そうなので, やろうと思っています.

2: Map

SELECT で取得した全ての行に対して Map 処理を行います.

MyMR の map 関数では, その中で emit メソッドを実行することで, テンポラリテーブルにデータを INSERT していきます.
関数のプロトタイプは void map(array $record) というシンプルなもので, 1 レコードを表すハッシュ (PHP なので array) を受け取るだけです.

入力テーブルの定義についての制約は特にありません.
通常どんなテーブルでも入力として扱うことができます.

emit にはキーとそれに対応する値を渡すことで, 中間データがテンポラリテーブルに 1 行ずつ挿入されます.
本来は MySQL セッションが終了した時点でテーブルは消えるのですが, 先の WordCount の例でいうと以下のようなテーブルが作成されています.

emit に渡された値は自動的に JSON に変換されています.

JSON 化してるのは構造化データを扱えるようにするためで, この辺りは MongoDB の MapReduce にインスパイアされてます.

3: Shuffle/Sort (?)

Hadoop なんかで言うところの Shuffle/Sort 付近に該当する, と思っているのですが, あんまり自信ないです.
ぶっちゃけると Hadoop 自体を使ったことは無くて, ブログ記事や書籍でつまみ食いした程度の知識しかありません.
(り, りろんはしってる (知らない))

とにかく, ここでは Reduce フェーズの前の下準備として, キーが同一のものをグループ化しています.

MyMR ではカジュアルに GROUP BY と GROUP_CONCAT を使っています.

実際は GROUP_CONCAT の SEPARATOR には改行コードの LF を指定しており, 複数の JSON が改行区切りで連結されたものになります.
要するに複雑なパース無しで複数の JSON を分割できるデリミタであれば何でもよくて, 無難に LF を使っているというだけの話です.

ところで, ここで JSON の代わりに MessagePack を使えれば, それだけである程度高速化できると思うんですが, そのときのデリミタは何にすればいいんでしょう?

4: Reduce

前の Shuffle フェーズで実行したクエリの結果全行に対して, 1 行 1 行 Reduce 処理を行います.

Map と同様, reduce 関数に 1 行 1 行の値を渡していきます.
関数のプロトタイプは array reduce(string $key, array $values) となっています.
$values では GROUP_CONCAT で改行区切りとなっていた JSON を予めパースし, 値の配列として渡されます.

そして返り値のハッシュがそのまま 1 行として -o (–output) に指定されたテーブルに 1 行 1 行挿入されていきます.

また, map と違って単純な入出力モデルになっているので, テストが書きやすいという利点があります.

そしてこれも map と違って, 挿入するデータは JSON ではなく, ハッシュのキーをカラム名としてレコードにマッピングされます.
そのため, 出力テーブルの定義は reduce 処理に合わせておく必要があります.

これまた map と違って, 出力テーブルでは key という名前のカラムが, キーを格納するために予約されており, reduce 返すキーとしては避ける必要があります.
それ以外は自由ですが, key カラムにはユニークインデックスを設定しておくのが良いでしょう.

まとめ

MyMR について長々と書いてきましたが, この記事で一番主張したいのは「MySQL から直接 MapReduce できたら便利じゃないか」ということに尽きます.
そういう需要があってもよさそうなものですが, ググってみても意外とそれらしい記事は見つからず, じゃあ作ってみようということでできたのが MyMR です.

ほとんどプロトタイプみたいなもので, 作り込みはまだまだこれからですが, 「MySQL で MapReduce する」というアイディアを発表したくて, この記事を書いています.

また, 今回はたまたま MySQL でしたが, 入出力を抽象化して MapReduce をするための何かがあれば, いろいろ捗るんじゃないかなぁという妄想もあります.

ビッグデータは無くとも, ビッグデータ時代に生まれた知見を活かすことはできるんじゃないか, というお話でした.

See also

,

Zend Engine 初心者による, Zend Engine 初心者のための発表という感じで話してきました.

今年に入ってから, scribble というなぐり書き用のブログを始めました.
GitHub Pages 内で Jekyll というツールを使って書いているんですが, Markdown で書いて git commit して git push するだけでサクッと公開できるのでとても気に入っています.

今のところ主に PHP 本体や, そのコアであるところの Zend Engine のコードリーディングが中心で, 今回の発表はこれらの記事をまとめた内容です.

闇 PHP 勉強会でのその他の発表はというと, PHP 製のパーサコンビネータとか, OpenCL とか, 魔改造 PHP とか様々で, こんな中でハッシュテーブルの実装について話し手も釈迦に説法なんではないかとかいろいろ危惧しましたが, わかりやすかったという声ももらえたようでよかったです.

この発表では, 既に scribble でも紹介している hashtable_dump という PHP Extension についても紹介しています.

本当は HashDoS 問題を解決したという Perl や Ruby におけるハッシュテーブルの実装についても調べて発表したかったんですが, 今回は間に合いませんでした.
次回の闇 PHP 勉強会があれば是非それらについて発表できればと思っています.

最後に, 主催の @anatoo さん, 会場提供のアシアル株式会社さん, 楽しい勉強会をありがとうございました.

2011-01-03 19:30 追記
rack-config は現在では rack 本体の gem に含まれており, わざわざインストール必要はありませんでした.
(GitHub で送っていた Pull request も閉じてます)
ですが, この記事で紹介している Bundler についての説明は特に問題ありません.

お正月休みということでちょっとした Sinatra 製の Web アプリケーションをいじって遊んでいます.

ローカルでは Pow で開発して, Heroku へのデプロイを考えているんですが, 設定をどう管理するか迷いました.
いろいろ調べた結果, .powenv とか使う方法とかあったのですが, .powenv は Heroku 上では使えません.
どうしたものかとさらに探した結果, rack-config という gem があったのでそれをラップして何とかすることにしました.
(以降はエントリの内容から脱線するので省略. いい感じの方法があれば Twitter とかで教えていただけると幸いです.)

さっそく Gemfile を書いて必要な gem を用意しましょう.
趣味の開発ですし, rack は最新バージョンを指定して, あわよくば地雷を踏み, パッチなど書いて Pull request を送りたい, というのが人情というものでしょう.

これで bundle install を実行すると, 以下のようにエラーで中断してしまいます.

bundle install に失敗

bundle install に失敗

これは rack と rack-config の互換性による問題です.
rack-config は 2012 年 1 月 2 日現在で丸 3 年程メンテされていない状態で, 依存する rack のバージョンが ~> 0.4 と, かなり古い状態です.
(~> 0.4 というのは 0.4.0 以上 0.5.0 未満という意味です)

今回指定した rack 1.4.0 は, rack-config が依存するバージョンに含まれないため, 依存関係の解決に失敗し, エラーとなってしまいます.

といっても, これはメタ情報におけるバージョンの指定の問題で, 実際に互換性があるかどうかは別の問題です.
rack-config の実装は README よりも短くシンプルなもので, 目 rackup した限りでは間違いなく動きそうに見えます.

作者に依頼して依存関係の指定を修正してもらうという手もありますが, 今回はとりあえずの解決をするための方法を紹介します.

大まかな手順

  1. 元のプロジェクトを GitHub 上で fork してローカルに git clone する
  2. ローカルの tmp-repo ブランチ上で *.gemspec の依存関係の指定を修正する
  3. 自分のリポジトリに git push する
  4. Gemfile で自分のリポジトリを指定する

Bundler は RubyGems.org からのインストールだけでなく, Git リポジトリからのインストールにも対応しています.
それを利用し, オレオレ Rubygems パッケージリポジトリを作って, そこからインストールしよう, というものです.

今回はたまたま元のプロジェクトが GitHub 上にあったので fork するだけで済みましたが, GitHub 上に無い場合も, 手動でリポジトリさえ作れば, あとは同様の手順で実行できます.

1. 元のプロジェクトを GitHub 上で fork してローカルに git clone する

clone については省略しますが, ブランチを切るのがいいでしょう.
一時的なリポジトリということで, tmp-repo という名前にしてみました.

2. ローカルの tmp-repo ブランチ上で *.gemspec の依存関係の指定を修正する

*.gemspec というのは, Rubygems パッケージのメタ情報を定義するファイルです.
依存関係もこのファイルに記述されています.

今回の場合は rack-config.gemspec に以下のような修正を加えました.

rack-config は rack 0.4.0 以上 1.5.0 未満に依存する, ということになったので, rack 1.4.0 も含まれるようになりました.

3. 自分のリポジトリに git push する

特に説明は要らないと思いますが念のため.

4. Gemfile で自分のリポジトリを指定する

先ほどの Gemfile を以下のように書き換えました.

fork した自分のリポジトリの URL と, 今回のために作成した tmp-repo ブランチを指定しています.

あとは最初と同じように bundle install を実行するだけです.

bundle install に成功

bundle install に成功

無理矢理 bundle install することに成功しました!

蛇足: オレはこう思う

今回はオレオレリポジトリを作ってとりあえずの解決を試みる方法を紹介しましたが, せっかくなら作者にも修正を出しておくとよりいいでしょう.
今後その gem を使用するときにいちいちオレオレリポジトリを指定するのは面倒ですし, 他の人にとってもその gem がメンテされた状態で使える方が便利です.

今回の rack-config についても, 実際は以下のような手順を経ています.

  1. 元のプロジェクトを GitHub 上で fork してローカルに git clone する
  2. ローカルの develop ブランチ上で Bundler を使ってテストできるように修正する
  3. GitHub 上で Pull request を送る
  4. develop ブランチから tmp-repo ブランチを作成する
  5. ローカルの tmp-repo ブランチ上で *.gemspec の依存関係の指定を修正する
  6. 自分のリポジトリに git push する
  7. Gemfile で自分のリポジトリを指定する

修正を依頼しつつ, それとは別のブランチをオレオレリポジトリにしています.
(この Pull request が取り入れられるのかはまだわかりませんが…)

ついでに Travis CI で 0.4.0 以上 1.5.0 未満の全ての rack でテストが通ることも確認済みです.

Travis CI 用の設定ファイルは以下のようなスクリプトで, .travis.ymlgemfiles を生成しました.
Travis CI では複数の gemfiles を指定することで, それぞれで bundle install し, 複数のバージョンの gem に対してテストを行うことができます.

なお, rack は 0.4.x のあといきなり 0.9.x にバージョンが飛んでいます.

これで, 見事に全てのバージョンでテストが通ることが確認できました.
(ここまで必死になることも無いとは思いますが…)

, ,