git-svn

移行作業にはgit-svnが必要になります。MacOSXでgit-svnを使うには、git-coreをmacportsで入れるときに、+svnのvariantsをつけてインストールしてあげるとOK。ぼくはすでにgit-coreをインストールしていたので、次のようにしてインストールしなおしました。

sudo port deactivate git-core
sudo port install git-core +svn

作業用ディレクトリの作成

作業用の適当なディレクトリを作ります。

mkdir ~/Desktop/git
cd ~/Desktop/git

authors.txtの作成

次のような内容のauthors.txtを作成。(no author)はGoogle Codeの初期設定で、名無しさんがtrunk, branches, tagsを作成しているようなので、この２行が必要になります。左辺はGoogleアカウント名、右辺はgithubに登録した名前とメールアドレスです。

ryo katsuma = ryo katsuma <katsuma@gmail.com>
(no author) = ryo katsuma <katsuma@gmail.com>

移行用レポジトリを作成

githubで移行用のレポジトリを作成します。作成はここから。

移行

ここまでくるとあとは簡単。

git svn clone -s -A ./authors.txt http://svn_repo.googlecode.com/svn repo
cd repo/
git remote add origin git@github.com:katsuma/new_repo.git
git push origin master

まとめ

Google Codeからgithubの移行は、実作業はauthors.txtを用意するくらいで、全体としてそんなに複雑なものではなかったと思います。 ちなみに今回の作業を通してTokyo-Joggingのコードを全部githubに移しました。 コード管理はもちろん、サイト全体の操作性なんかもGoogle Codeと比べてgithubの方が優れていると思うので、移行して正解だったかなーと感じています。

本書は、EC2, S3を中心とするAWSの導入、運用方がをボリュームよくまとまったかなりの良本です。

目次

• ■第1章　クラウドコンピューティングへの招待
  • 1-1 クラウドコンピューティングの隆盛
  • 1-2 クラウドコンピューティングとは何か
  • 1-3 サービス提供側から見るクラウドコンピューティング
  • 1-4 クラウドコンピューティングの3つの分類
  • 1-5 クラウドコンピューティングの主要プレイヤー
• ■第2章　Amazon EC2/S3で何をするのか
  • 2-1 Amazon EC2
  • 2-2 Amazon EC2
  • 2-3 Amazon S3
  • 2-4 料金体系
• ■第3章　Amazon EC2/S3導入手順詳細
  • 3-1 Amazon EC2/S3を使うまでの準備
  • 3-2 GUIツールからの操作（AWS Management Console）
  • 3-3 コマンドラインからの操作
  • 3-4 Amazon S3を利用する
• ■第4章　Amazon EC2使用方法
  • 4-1 Amazon EC2でLinuxを使う
  • 4-2 Amazon EC2でWindowsを使う
• ■第5章　Amazon EC2/S3の応用例
  • 5-1 Amazon EC2のオプション
  • 5-2 Amazon S3のオプション
  • 5-3 その他のオプション
  • 5-4 Amazon EC2/S3　ツール集
• ■第6章　AWSにおける運用管理
  • 6-1 運用上における物理サーバとAmazon EC2の違いとは
  • 6-2 サーバ種類別の考察
  • 6-3 AMIをゼロから作る
• ■第7章　Amazon EC2/S3ができること，できないこと
  • 7-1 相性が良い想定利用シーン
  • 7-2 相性が悪い想定利用シーン
  • 7-3 当社で起きた特殊な事件
  • 7-4 その他注意点
  • 7-5 Amazon EC2/S3は使えるのか？
• ■Appendix　コマンドリファレンス

AWS導入検討時は何よりまず読むべき

一通り読んでみて感じたことは、「僕がAWSを初めてまともに使った１年前にこの本があれば。。。」と、いうこと。導入にあたってのアカウントの作成方法、料金計算方法、Webインターフェースとコマンドツールの細かな説明から運用上の諸注意まで全部一通り掲載されてあって、AWS日本語公式サイトがまだ存在しない今だと、へたに検索して１つ１つ調べるよりよっぽど有益な情報を効率よく収集できます。

個人的に一番よかったのは、６章「AWSにおける運用管理」と７-3「当社でおきた特殊な事件」。AWSの実運用事例はまだまだ国内では少ないので、このあたりの実際に使ってみてはじめて分かる、目の当たりにする困難な点は情報として絶対量もまだまだ多くありません。その点で、これらの章は使った人にとっては「あるある！！」と思える点ばかりで、AWSユーザ視点での生の声が集まったかなり貴重な章と言えると思います。あと、Auto ScalingやElastic Load Balancingなんかは、まだ使ったことがなかったので、そのあたりの情報は普通にかなり参考になりました。

と、いうわけでAWSの導入を検討している人は当然のこと、AWSのサービスを断片的には使っているもののサービス間の連携についての知識が不十分だと思える人にとって、本書は必須な本だと思います。かなりオススメ！

当然のごとくmemcachedが最速だろう。。。と思いきや、そうでもない結果に。むしろ一番遅い結果に。なんだこれーーーと思って調べ続けていたのですが、バインディングのgemのコードを追いかけるかぎり、どうもこれはmemcache-clientの実装が原因のよう。

これは、memcache-clientの実装はpure-rubyで実装されているのに対して、TokyoCabinet/TokyoTyrantのバインディングの実装はnativeコードで実装されてあるのが原因のようです。事実、TokyoTyrantはmemcacheプロトコルを実装しているので、memcache-clientを利用してTokyoTyrantにアクセスすると両者はこんな結果になりました。

TokyoTyrantのアクセス速度は一気に遅くなりました。やっぱりRuby実装に引きづられているみたいですね。。

ちなみに、Redisもsetに限るとmemcacheプロトコルと同じプロトコルを利用できるので、そのベンチをとってみると

と、なってmemcacheクライアントを利用したときのmemcached, TokyoTyrantと比較しても圧倒的に高速だということがわかりました（おもしろい！）

まとめ

• オンメモリだからmemcachedが高速、とは限らない
• memcache-clientは遅いので注意
• 各ライブラリのオリジナルのバインディングを利用した場合、高速順に並び替えるとTokyoCabinet, TokyoTyrant, Redis, memcachedになる

と、いうわけで、memcachedが高速なことを確認するためにベンチマーク取ってみたのですが、実装によってはまったく異なる結果になることが分かって、なかなかおもしろかったです。なお、今回利用したコードはgistに掲載しています。

CDHは常にupdateしていて、現在の最新リリースであるCDH3も2010年5月5日現在ではテスト版扱いですが、これもじきにStable版としてリリースされることになるかと思います。

さて、そうるとClouderaのAMIを使っていて、特定のバージョンに上げたい、というのは結構自然な流れかと思います。このとき、バージョンを上げる流れとしては次のような流れになります。

1. Hadoopとその上モノであるHive, Pigなどをパッケージ管理ツールを利用して全てアンインストール。
2. パッケージ管理ツールのレポジトリを追加
3. パッケージ管理ツールを利用してHadoopをインストールし直し
4. パッケージ管理ツールを利用してHive, Pigなどをンストールし直し

要するに、全ソフトウェアのバージョンをまとめて上げるのではなく、Hadoopかまたはそれ以外の特定のソフトウェアについて、パッケージ管理ツールを利用してバージョンを上げる、ということが可能になります。このとき、Hadoopについては新たに設定項目がかなり多かったり、AMIを作りなおさないと試すことができなかったりと面倒なことが多いのですが、逆にHiveやPigなどHadoopの上モノについては、AMIを作り直すこともなく、その場でバージョンを上げることも結構簡単にできます。

たとえば、HiveのバージョンをCDH1→CDH2に上げる場合は次のような手順で可能です。

まず、既存にインストールされてあるHiveをアンインストールします。たとえばFedoraベースの　AMIの場合は、パッケージ管理ツールとしてはyumを利用することが可能です。

yum remove hadoop-hive

次に、CDH2用のyumのレポジトリを追加します。あとえばCDH2用のレポジトリを追加するときは、こんなかんじ。CDH3用のレポジトリを追加したい場合は、URLの最後をcloudera-cdh3.repoに変更ください。

cd /etc/yum.repos.d/
wget http://archive.cloudera.com/redhat/cdh/cloudera-cdh2.repo

これで、最新のパッケージを扱える状態になりました。ここでHiveだけCDH2仕様のver0.40系にしてみましょう。

yum -y install hadoop-hive

これで、0.40.xのHiveがインストールされました。また、設定ファイル(/etc/hive/conf/hive-site.xml)は、オリジナルのものに戻ってしまっているので、適宜直しておきましょう。ぼくは以下の箇所を変更、追加しました。

• javax.jdo.option.ConnectionURL
• javax.jdo.option.ConnectionDriverName
• javax.jdo.option.ConnectionUserName
• javax.jdo.option.ConnectionUserPassword

いかがでしたでしょうか？Hiveについては、アップグレードは非常に簡単だったかと思います。同じように、PigについてもHadoopの上モノなので同様の手順でアッグレード可能になります。これなら割と気軽にバージョン上げたりパッチ当てたりなんかもできそうですね。

また、Hadoop本体のアップグレードについても、次回は挑戦してみたいと思います。

]]> http://blog.katsuma.tv/2010/05/hive_version_up_on_cloudera_based_ami.html http://blog.katsuma.tv/2010/05/hive_version_up_on_cloudera_based_ami.html aws Thu, 06 May 2010 03:00:00 +0900 4月16, 17日に京都で「アグレッシブなクラウドの使い方」というタイトルで、会社でのクラウドの取り組みについて話してきました。

話の中身としては、僕とsasata299さんがいろんなところで話してきたクラウド系の話の総集編みたいなものになっています。あと、RDSとかPigについて話したのは今回が初になります。

発表の後のTwitterでのTLを追いかけてると、「内容がちょっと分かりづらかった」という声もちらほらあったようですが、たしかにそれは間違っていなくて、AWS系のサービスの内容とHadoopについての仕組みが一通り理解できている前提での内容でしたので、かなり難解だった方も多かったかと思います。と、いうわけで参加されていた方々は、もう一度キーワードレベルで見直していただくなりして、内容を再確認いただければ幸いです。

]]> http://blog.katsuma.tv/2010/05/aws_kyoto_predentation_201004.html http://blog.katsuma.tv/2010/05/aws_kyoto_predentation_201004.html aws Sun, 02 May 2010 02:39:29 +0900 前回のつづき。

課題の1つに挙げてた中で、「Followした瞬間に、そのユーザの過去のTweetを自分のTLに追加できていない」というのがありましたが、こんなかんじでいいのかな。自分のTLに他人のTLを混ぜて、sortしてstoreし直し。(redis-rbが0.2.0じゃないと動かないかも)

  def merge_timeline(user_id)
    my_id = @login_user[:id]
    return if @redis.type?("uid:#{user_id}:posts") == "none"

    user_statuses = @redis.lrange("uid:#{user_id}:posts", 0, 100)
    user_statuses.each do |status|
      @redis.lpush("uid:#{my_id}:home", status)
    end
    @redis.sort("uid:#{my_id}:home", :order => "desc alpha", :store => "uid:#{my_id}:home")
  end

でも、そうしたあとにremoveしたときにまた再構築し直さないと駄目なことに気づいた。。と、いうかremove面倒ですねぇ、どうするんだろう。泥臭く全statusを走査し直しなのか、それとも順序付Setとか使えば楽にremoveできるのかな。また考え直しです。

あと、このupdateについて、github上のRedTweetのコードもpushし直してますので、興味ある方はご確認ください。

]]> http://blog.katsuma.tv/2010/03/sort_timeline_by_redis.html http://blog.katsuma.tv/2010/03/sort_timeline_by_redis.html ruby Sat, 27 Mar 2010 06:10:39 +0900 前回「Mac OSXにredisをインストール」で、redisを動かす環境まではできたので、せっかくなんでテスト的に何かサービスを作ってみよう、ということでTwitterクローンのRedTweetを作ってみました。
• RedTweet

redisを使ったTwitterクローンは、PHP版のRetwisと、それをSinatraで書き直したRetwis-RBがあるのですが、サンプルコードはいくらっても世の中に少しは役立つだろうと思ってRails版で実装してみました。オンラインで動作できる環境はないので、git cloneしてscript/serverで手元の起動で確認ください、、と投げやり気味ですみません。とりあえず次の項目は一通り実装しています。

1. ユーザID発行
2. Login / Logout
3. Follow / Remove
4. 自分のTimeline, Public Timeline, 各ユーザのTimelineの閲覧

ちなみにRedTweetって名前はRedisとTweetを混ぜて直感でつけた名前で、git pushしたあとで同じ名前のサイトがあることが発覚したくらい直感でつけた名前です。

目的

さて、今回はまじめにTwitterクローンを作ることが目的ではなくて、実際は、次の項目を目的として実装してみました。

1. Retwisのデザインを読んで、それに従って一通り実装してみる
2. redisのAPIの仕様を学ぶ
3. RDBを一切使わない、NoSQLでWebサービスを作るためのノウハウを身につける

結局全て似通った話になるのですが、上記のデザイン仕様書はTwitter的なサービスを作り上げることで、KVSをどのように利用すればいいのか、がかなり分かりやすく説明されてあるので、いい勉強になりました。また、ユーザ情報はString, 各TLはList, Following/FollowerをSetで管理することで、redisの主要なAPIを網羅できたことも、redisの学習に役立ちました。

と、同時に課題もすでに見えていて、

1. スケーリングがどこまでできるかはまだ手元で理解できていない
2. やっぱりActiveRecord的にラップしたライブラリは必須
3. Followした瞬間に、そのユーザの過去のTweetを自分のTLに追加できていない

なんかが今の段階で挙げられます。1.はテストデータを作ることで解決するはず。2.はやっぱりmustだなぁ、と思えるところまでははっきりした理解で、ユーザ名をIDから引くときなど毎回決まったprefixがついたkeyから探索するのは冗長すぎてやってられません。OhmというHashとObjectのマッピングライブラリもあるので、このあたりも１度使ってみたほうが良さそうだな、というところ。3.はFollowした瞬間に一定数TweetをListにLPUSHして、そのlistの中でSORTすればいいのかな？？正直、SORTまだよくわかってません。

まとめ

というわけで、課題は多いものの、redisとRailsで最低限の動作をするものは実装できました。NoSQLでもサービスを作り上げることは理解できたので、Ohmなど、他のライブラリも使ったりすることで、 redisの利点をもっと伸ばして理解を深めたいな、というところですね。

]]> http://blog.katsuma.tv/2010/03/redtweet_by_redis_and_rails.html http://blog.katsuma.tv/2010/03/redtweet_by_redis_and_rails.html ruby Thu, 25 Mar 2010 02:04:56 +0900 Tokyo Cabinet / Tokyo Tyrantに代表されるKey-Value Storage,いわゆるKVSは多くのプロダクトが乱立してなかなか違いを理解するのも難しい状況になりつつあるのですが、ここ数日はredisに注目をしています。redisとは何ぞやというと、公式サイトには次のような特徴が挙げられています。
• memcachedのようないわゆるKVS
• valueにはStringだけではなく、List, Setも利用できる
• データに対するpush/pop, add/removeのような操作はすべてatomicな操作
• 通常はメモリ上で動作するが、定期的にデータをディスクに書き出す（常に書き出すような設定も可能）
• Master-Slaveのレプしケーションをサポート
• Ruby, Python, Perl, Java...などの各言語のバインディングを用意

と、かなり豪華なスペックで、なんでもかかってこい！なプロダクトです。国内の利用例はまだ聴いた事無いですが、海外ではgithubやCraigslistが採用したことでここ最近有名になってきました。

さて、そんなredisの開発環境を整えてみたいと思います。環境はMac OSX 10.5。

redisのインストール

ソースコードから入れてもいいのですが、Macの場合は、MacPortsでインストール可能です。

$sudo port -d sync

で、インストールリストを最新の状態にしておいて

$sudo port install redis

で、インストールされる、、はずなのですが、僕の環境だと途中で止まりました。

$ sudo port install redis
--->  Fetching redis
--->  Attempting to fetch redis-1.2.2.tar.gz from http://redis.googlecode.com/files/
--->  Verifying checksum(s) for redis
--->  Extracting redis
--->  Configuring redis
--->  Building redis
--->  Staging redis into destroot
--->  Creating launchd control script
###########################################################
# A startup item has been generated that will aid in
# starting redis with launchd. It is disabled
# by default. Execute the following command to start it,
# and to cause it to launch at startup:
#
# sudo launchctl load -w /Library/LaunchDaemons/org.macports.redis.plist
###########################################################
--->  Installing redis @1.2.2_0
--->  Activating redis @1.2.2_0
Error: Target org.macports.activate returned: couldn't open "/opt/local/var/log/redis.log": no such file or directory
Error: Status 1 encountered during processing.

なんかlogディレクトリがないみたいなので、ディレクトリ作成してから一度アンインストールしてやりなおしてみます。

$ sudo mkdir /opt/local/var/log
$ sudo port uninstall redis
$ sudo port install redis
==================================================================
* To start up a redis server instance use this command:
* 
*   redis-server /opt/local/etc/redis.conf
* 
==================================================================

--->  Cleaning redis

これで、インストールできました。サービスに登録したい場合は、途中のログに書いてあるとおり、

sudo launchctl load -w /Library/LaunchDaemons/org.macports.redis.plist

で、OKです。

Rubyのバインディングのインストール

僕は普段Rubyを使うので、Rubyのバインディングもあわせてインストールしてみることにします。gemでインストール可能です。

sudo gem install redis

redisの起動

redisを起動するときは、redis-serverを実行します。MacPortsでインストールした場合、/opt/local/bin にバイナリがインストールされてあるので

sudo /opt/local/bin/redis-server /opt/local/etc/redis.conf

で、起動します。confの中には、起動するときのポート番号や、ディスクに書き出すタイミングや条件などの設定項目があります。（ちなみに、起動時に設定ファイルのパスを与えていますが、これはビルド時？に設定しておけば、実行時に与える必要は無いようです。ただ、MacPorts利用時もそれが可能なのかどうか？は不明です）

では、実際に動作を確認してみたいとおもいます。確認するときは、redis-serverと同じ場所にあるredis-cli, またはtelnetで6379に対して接続してコマンドを入力します。（今回はtelnetで接続して生のコマンドを叩いて確認してみます）ValueをStringとして扱うときは、 set \r\nでデータをセット, get でデータを確認できます。

set foo 3
bar
+OK

get foo
$3
bar

listとして扱うときは、lpush \r\n, lrange などのコマンドを利用します。下記の例のlrangeの0は開始インデックス、-1は末尾の意味になります。

lpush artists 8
fishmans
+OK

lpush artists 9
clammbon
+OK

lpush artists 7
polaris
+OK

lrange artists 0 -1
*3
$7
polaris
$8
clammbon
$8
fishmans

Listの要素追加もStringの要素追加と同じでO(1)で実現できるのがredisのポイントですね。実際の細かなコマンドの仕様については、リファレンスを参照ください。

ここまでざっと環境構築まで確認できたので、次回はもうすこしredisを使い倒してその結果をまとめたいと思います。

]]> http://blog.katsuma.tv/2010/03/start_redis.html http://blog.katsuma.tv/2010/03/start_redis.html kvs Mon, 22 Mar 2010 02:43:04 +0900 ずいぶんまた長い間があいてしまって今年初エントリになるわけですが、きたる2/23に秋葉原で行われた第0回 AWS User Group - Japan勉強会でLTの発表をしてきました。

もともと会社でAWSを使ってることからAmazonの小島様にお声がけいただいて、JAWS-UGに参加させていただいて、その流れで今回発表することになったわけですが、５分間のLTだとなかなか話したいことも話し切れないまま時間切れみたいになってしまって若干消化不良。。と、いうわけで、当日駆け足の発表になってよくわからなかった方や、その場での発表を聞けなかった方むけに資料を掲載しておきたいと思います。

内容はHiveとバッチとの連携の話なのですが、Hiveの導入事例はなかなか国内では耳にしないので（僕が耳にしたかぎりY!Japanくらい）、導入を検討してる方々にとって参考になればな、と思います。

]]> http://blog.katsuma.tv/2010/03/jaws_ug_lt.html http://blog.katsuma.tv/2010/03/jaws_ug_lt.html Sat, 06 Mar 2010 15:58:53 +0900 少し前の情報になるのですが、楽天テクノロジーカンファレンスでTokyo-JoggingネタのLT&デモを行ってきました。



当日は、WiiリモコンだけじゃなくてバランスWiiボードと、最近対応したヌンチャクのデモも行いました。やや古いネタではあるものの、大勢の方に実際に体験いただいて、アドバイスや意見などいただけて楽しい時間を過ごすことができました。

ただ１つ残念だったのはデモブースに常駐してないとダメだったので、他の方の発表がまったく聞けなかったこと。。楽しそうな話いっぱいあったのでそこが残念でした。と、思ったら発表内容はUstreamで残っているみたいなので、あとで確認したいとおもいます。

また、ありがたいことにデモ投票では３位(!)の結果をいただけることになりました。LTでは時間切れになっちゃって消化不良だったわけですが、デモで実際に体験いただけたのがよかったのかなとおもいます。

最後に、貴重な場所と機会を提供いただいた楽天株式会社 開発部の方々、どうもありがとうございました！

]]> http://blog.katsuma.tv/2009/11/rtc2009.html http://blog.katsuma.tv/2009/11/rtc2009.html develop Sun, 08 Nov 2009 05:37:59 +0900 HiveでのSQLことHQLの小ネタ。HQLでは基本的にSQLはほぼ完璧に利用できますが、たまにハマりポイントもあります。その１つが並び替えのORDER BY。

ORDER BYとSORT BY

HQLの文法的にORDER BYは有効ですが、実際は並び替えは行われません。（無視されているような感じ）Hiveでは代わりに「SORT BY [column]」を利用することになります。

ただし、ここでも罠があって、SORT BYは結果がreducerの数に依存します。(各reducerがsort処理をしたものがマージされるものになるので、全体としてはおかしな結果を得ることになります) 通常、reducerは複数走っているはずなので、結局SORT BYを利用してもORDER BYと同等の結果を得ることができません。

では、どうするか？と言うと明示的にreducerの数を1に指定してからSORT BYを実行すればOKです。

set mapred.reduce.tasks=1;
SELECT key, value FROM table_name SORT BY key;

また、Hiveシェルを使わない場合は1ライナーで。

hive -e 'set mapred.reduce.tasks=1;SELECT key, value FROM table_name SORT BY key;'

HQL最適化

ただ、これだとreducerの数がボトルネックになって、SORT BYと条件文などが組合わさると途端に処理が遅くなることがあります。

なので、このような条件文付きSORT BYを実行するときは、

1. 複数のreducerが条件文つきHQLでデータを整形し、中間テーブルAを作成
2. 1つのreducerが、中間テーブルAを対象にSORT BYし、条件文は付けない

な、方針でHQLを分割して実行すると、高速に動作できるかと思います。

ちなみに、このテーブルを分ける（カラムを厳選した中間テーブルを作成する）のはHQLの最適化でかなり有効で、SORT BY以外でもかなり有効なケースが多くあります。このあたりの最適化の話は、また別途まとめたいと思います。

]]> http://blog.katsuma.tv/2009/10/hive_order_by.html http://blog.katsuma.tv/2009/10/hive_order_by.html hadoop Wed, 14 Oct 2009 23:57:37 +0900 前回、紹介したHiveについての続き。

Hiveは内部で扱うメタデータを「metastore」というデータで保持しています。テーブルやパーティションなどの情報、またレコードが実際に保持されてある場所などのメタデータは全部このmetastoreにまとまっています。このmetastoreは、次の3種類の方法で保存することができます。

• Embeded metastore
• Local Metastore
• Remote Metastore

Embeded metastore

Embeded metastoreは主にテスト用途に利用されます。テスト用途なので、単一プロセスからの接続しか許可されていません。 そのため、コンソールを複数起動して、それぞれのコンソールから別のMap&Reduceを走らせる...なんてことができません。ただし、Hiveは初期設定がこのEmbededモードになっているので、特に設定することなくすぐに利用するメリットはあります。

また、metastoreはmetastoreディレクトリ(hive-default.xmlのhive.metastore.urisセクションに記述されています)内の 単一のファイルに保存されることになります。メタデータのバックアップをとりたいときは、このファイルをバックアップ対象にすればOKです。

Remote Metastore

1つ飛ばして、Remote Metastoreについて。Remote Metastoreはネットワーク越しにmetastoreを扱いたい場合における設定方法です。Hiveクライアントとデータを保存するMySQLの間にThriftサーバをproxyのような形で挟むことで実現しています。Thriftプロトコルを実現できていれば通信が可能なので、実際はJavaのHiveクライアントだけではなく、異なる言語によるクライアントからも接続が可能です。たとえばPHPでの例があるみたいです。

• Making PHP talk to Hive through Thrift

Local Metastore

Local Metastoreは、上で述べた２つの形式の間の位置づけのものです。 metastoreを単一ファイルで扱わずに、Remote Metastoreの形式にようにMySQLに保存することで、同一ホスト内から同時に複数のセッションを張ることができます。 このLocal Metastoreは簡単に実現できる割にすごく便利なので、紹介しておきます。

DBの設定

まず、MySQLでmetastoreを保存する適当なDB、およびその接続ユーザを定義します。たとえばrootで接続し、次のように定義します。

create database hive;
grant all privileges on hive.* to user_hive@localhost identified by 'hive_password';
flush privileges;

この設定をHiveに反映させるために設定用xmlを編集します。

hive-site.xmlの編集

Hiveの初期設定はhive-default.xmlにまとまっていますが、この設定はhive-site.xmlという名前のファイルを同一ディレクトリに用意してあげることで上書きできます。 上記設定は次の項目を編集、または追加してあげることで反映されます。

<property>
  <name>hive.metastore.local</name>
  <value>true</value>
  <description>controls whether to connect to remove metastore server or open a new metastore server in Hive Client JVM</description>
</property>

<property>
  <name>javax.jdo.option.ConnectionURL</name>
  <value>jdbc:mysql://localhost/hive?createDatabaseIfNotExist=true</value>
  <description>JDBC connect string for a JDBC metastore</description>
</property>

<property>
  <name>javax.jdo.option.ConnectionDriverName</name>
  <value>com.mysql.jdbc.Driver</value>
  <description>Driver class name for a JDBC metastore</description>
</property>

<property>
  <name>javax.jdo.option.ConnectionUserName</name>
  <value>hive_user</value>
  <description>metastore mysql user</description>
</property>

<property>
  <name>javax.jdo.option.ConnectionPassword</name>
  <value>hive_password</value>
  <description>metastore mysql password</description>
</property>

<property>
  <name>hive.metastore.warehouse.dir</name>
  <value>/user/hive/warehouse</value>
  <description>location of default database for the warehouse</description>
</property>

どのプロパティ名も名前からどんなものかは凡そ予想はつくと思います。 ちなみにhive.metastore.warehouse.dirはHDFS上でのファイルパスになるので、ここだけ要注意です。

xmlを編集したら、hiveクライアントのシェルを立ち上げ直します。 シェル自体はEmbeded Metastoreのときとメッセージ形式も変わらないですが、同時に複数のHQLを実行することができるので、格段に使いやすくなります。 Hiveの利用を考える場合は、Local Metastoreの利用は検討してみる価値はあるのかな、と思います。

まとめ

Hiveのmetastoreの保存形式について、また、Local Metastoreの形式について、その設定方法をまとめてみました。これらの保存方式については、公式サイトにもまとまっている資料があるので、一度目を通してみるとコンポーネント間の関係が理解しやすいかと思います。

• Metastore Usage
]]> http://blog.katsuma.tv/2009/10/hive_local_metastore.html http://blog.katsuma.tv/2009/10/hive_local_metastore.html hadoop Mon, 12 Oct 2009 00:56:17 +0900 1年ぶりにTokyo-Joggingをupdateさせました。

さぼってたわけではないのですが、抜本的に通信方法を変更しようとあれこれ試行錯誤していた割に根本的に解決できない問題にぶちあたって途方に暮れていたので、路線変更で小さなバグfixとヌンチャク対応したものを一気にまとめあげてリリースしました。

Tokyo-Jogging - Downloads

Snow Leopard対応

Tokyo-Joggingでは内部でBluetoothの信号を扱うためにBlueCoveというライブラリを利用しているのですが、どうもこれがSnow Leopardではうまく動かない模様。原因を探っているとSnow Leopardでは64bit版のJavaがデフォルトで起動するのに対して、BlueCoveのバイナリが32bit用にビルドされていることが原因みたい。インストールされてあるJavaの設定を変更してもいのですが、プログラム単位で対応するためには起動オプションに

-d32

を追加すればいいみたいです。

また、BlueCoveを2.1.0にバージョン上げたら「java.lang.IllegalArgumentException: PCM values restricted by JAR82 to minimum 4097」な例外が出て、落ちてしまってたので、これも対応。起動オプションに

-Dbluecove.jsr82.psm_minimum_off=true

を付けてあげればいいみたいです。

これらの起動オプションは付属のstart-jogging.shに反映させてあるので、最新版にupdateした上で

./start-jogging.sh

で、起動することでSnow Leopard対応したオプション付きで起動できます。

Eclipseから起動する場合は、上記の２つのオプションをRun Configurationsの"VM arguments"に追記してあげればOKです。

ヌンチャク対応

地味なupdateですが、ヌンチャクを利用できるようにしました。Wiimoteを認識させた後にヌンチャクを接続するとアナログスティックで方向を変えることができます。（ヌンチャクを接続させたままWiimoteを認識させてもヌンチャクが認識されないので注意）

これで、左手にヌンチャク、右手にWiimoteなスタイルでスムーズに方向を変えつつどこでも走ることができますね！

今後はどうするの？

結構、作りっぱなしで放置しているように見られがちですが、実際はジョギング自身でやりたいことはもちろん、派生系でもまだまだやりたいことはあって、ゆっくりながらもupdateしていく予定です。あと、ここへきて外でしゃべらさせていただく機会も増えそうなので、そういうタイミングにあわせてupdateしていく予定です。（今回のupdateも実はその流れ）

]]> http://blog.katsuma.tv/2009/10/tokyo-jogging_support_snow_leopard.html http://blog.katsuma.tv/2009/10/tokyo-jogging_support_snow_leopard.html tokyo-jogging Mon, 05 Oct 2009 01:49:06 +0900

前回、JavaScriptでMap Reduceのコードが書けるHadoop Streamingについて紹介しました。 標準入出力さえサポートされてあれば、任意のコードでMap Reduuceの処理が書ける、というものでしたが、エンジニアはそもそも面倒くさがり。コードも書くのも面倒です。 と、いうわけで、今回はもうコードすら書かずにSQLライクでMap ReduceできるHiveというプロダクトについて、まとめたいと思います。

Hive

Hiveとは、簡単に言うとHadoop上で動作するRDBのようなものです。 HDFSなどの分散ファイルシステム上に存在するデータに対して、HiveQLというSQLライクな言語で操作できます。 で、面白いのがHiveQLの操作は基本的にMap Reduceのラッパーになっていること。 要するに、SELECT文実行すると裏でMap&Reduceのタスクが走り出して、分散処理されて結果を得ることができます。

そんなHiveは、もともとFacebookが開発を始めたものでした。2008年12月に、正式にHadoopプロジェクトにcontributeされて、いまはHiveの公式サイトもHadoopのサイト内でホスティングされてあります。

• Hive

では、さっそく導入方法について確認してみます。

ビルド

Hiveのビルドに先立って、Hadoopをインストールしておきます。Hadoopのインストール方法は前回のエントリにも書いてある通りです。

Hiveのビルド自体は、Subevrsionからcheckoutして、antのタスクでビルドできる簡単なものです。1ヶ月ほど前のHiveは、patchを当てないとHadoop 0.20.0用にビルドできなかったのですが、最近のtrunkのものは特に何もせずにビルドできるようです。

svn co http://svn.apache.org/repos/asf/hadoop/hive/trunk hive
cd hive
ant -Dhadoop.version="0.20.0" package

ビルドできたらbuild/distを環境変数$HIVE_HOMEとでも設定しておきます。また、あわせて$HADOOP_HOMEも設定しておきましょう。

セットアップ

ビルドが成功したら、Hive用のデータ保存領域のセットアップをHDFS上で行います。Hadoopを起動した状態で次のようにセットアップします。

$HADOOP_HOME/bin/hadoop fs -mkdir       /tmp
$HADOOP_HOME/bin/hadoop fs -mkdir       /user/hive/warehouse
$HADOOP_HOME/bin/hadoop fs -chmod g+w   /tmp
$HADOOP_HOME/bin/hadoop fs -chmod g+w   /user/hive/warehouse

すると、次のコマンドでHiveが起動されます。

$HIVE_HOME/bin/hive

テーブルの作成

では、早速Hiveで扱うテーブルを作成します。 テーブルの作成方法はMySQLなんかの一般的なRDBMSのそれとほぼ同等です。 たとえば、ユーザのアクセスログをまとめたログがあると仮定します。このログを保存するテーブルは最低限、ユーザIDとそのアクセス時間が保存されればOKなので、次のように定義できます。

CREATE TABLE user_logs(id INT, created_at STRING);

構文については見たまんまなので。理解しやすいかと思います。ちなみに、昔のバージョンだとカラムにDATETIMEなんかの型が定義できたようですが、現在はDATETIME型はなくなっているようです。（Hive/LanguageManual/DDL）

また、CSVなどの形式ですでに既存のログファイルがある場合、便利な機能があります。 Hiveではテーブル定義時に(CSVなどの)ある形式のデータを扱うことをあらかじめ指定しておくと、 CSV形式のログデータをそっくりそのままHiveのテーブルのレコードとしてロードさせることが可能です。

たとえばCSV形式のファイルを扱う場合、このような定義方法になります。

CREATE TABLE user_logs(id INT, created_at STRING) row format delimited fields terminated by ',' lines terminated by '\n';

この上で、次のようなコマンドで既存のログデータをロードできます。

LOAD DATA LOCAL INPATH '/path/to/log_20090907.csv' OVERWRITE INTO TABLE user_logs;

これで、CSVデータをHiveQLで扱えるようになりました。この時点でHDFS上にlog_20090907.csvは保存されています。/user/hive/warehouse/以下にテーブル名である「user_logs」ディレクトリが作成されてあり、該当ファイルが保存されてあります。

$ $HADOOP_HOME/bin/hadoop fs -ls /user/hive/warehouse/user_logs/
Found 1 items
-rw-r--r--   1 katsuma supergroup   17800731 2009-09-06 11:01 /user/hive/warehouse/user_logs/20090907.csv

では、ここで早速HiveQLを実行してみましょう。全件取得するときは一般的なSELECT文が利用できます。

SELECT * from user_logs;

ただし、このままだとローカルからデータをロードするだけで、ただのCSVのSQLラッパーでしかありません。 HiveQLが真価を発揮するのはいろいろ条件付けたSQLを発行してから。

ユニークユーザ数をHiveQLで算出

ここで、ユニークユーザ数(UU)を算出してみます。普通のMap Reduceの処理だと、IDごとのHashMapを作成してそのサイズからUUを算出することになりますが、HiveはSQLライクに算出することができます。つまり、こういうかんじ。

select count(distinct id) from user_logs;

すると、いきなりここからMap&Reduce処理が走り出します。 この、「SQL実行でMap&Reduceが実行される」という様子があまりにすごいので、最初これ見たときはかなりウケました。

Total MapReduce jobs = 1
Number of reduce tasks determined at compile time: 1
In order to change the average load for a reducer (in bytes):
  set hive.exec.reducers.bytes.per.reducer=
In order to limit the maximum number of reducers:
  set hive.exec.reducers.max=
In order to set a constant number of reducers:
  set mapred.reduce.tasks=
Starting Job = job_200909061015_0001, Tracking URL = http://hdp-01:50030/jobdetails.jsp?jobid=job_200909061015_0001
Kill Command = /home/katsuma/hadoop/latest/bin/../bin/hadoop job  -Dmapred.job.tracker=hdp-01:9001 -kill job_200909061015_0001
2009-09-06 10:41:27,049 map = 0%,  reduce = 0%
2009-09-06 10:42:27,520 map = 5%,  reduce = 0%
2009-09-06 10:42:28,540 map = 50%,  reduce = 0%
2009-09-06 10:42:33,594 map = 69%,  reduce = 0%
2009-09-06 10:42:34,610 map = 100%,  reduce = 0%
2009-09-06 10:42:55,748 map = 100%,  reduce = 100%
Ended Job = job_200909061015_0001
OK
21509
Time taken: 105.58 seconds

すると、結果が取得できました。上記例だと21509ユーザという結果を取得できていますね。あまりに簡単すぎてウケます。

ちなみにHiveのコンソールはサイレントモードが用意されてあって、Hiveのコンソールを起動させることなく、普段のシェルからも実行させることができます。サイレンとモードは-Sオプションをつけて実行すればよく、

$HIVE_HOME/bin/hive -S -e 'select count(distinct id) from user_logs'

と、すれば、途中経過をすっとばして結果だけ取得できます。もちろんこれはバッチ処理など、Hiveコンソールを利用せずにいろんな値を取得させたいときに利用すればよさそうですね。

Partitionを設定

Hiveの特徴的な機能としてPartitionというものがあります。 これはテーブル自体にバージョン管理の概念を持たせるもので、ログ管理にすごく便利そうなものです。

たとえばデイリーのログファイルをHiveで管理したいと思ったときに、 毎日HDFS上にログファイルを転送することになるかと思いますが、Partitionを利用することで、 ログを追記でテーブルに書き込む(=ファイルにappendする)のではなく、 日付ごとに独立したファイルのままHDFSに保存することができます。 なので、「やっぱりHiveより素のMqp&Reduce書くようなフローに戻そう」と 思ったときに、Partitionを利用してロードしておいたほうが後々都合がよいかと思います。(あと、初期のHadoopはファイルのappendができない、という制約があったので、Hive側はこの制約を回避するために、このような概念を持たせて独立したファイルを透過的に見せるような仕様で実装したんじゃないかな？と推測しています)

Partition自身は、ふだんのテーブルにおけるカラムのように扱えるので、実際は特別に何か意識する必要はありません。Partition付きテーブルはこのように定義できます。

CREATE TABLE user_logs(id INT, created_at STRING) partitioned by(dt STRING) row format delimited fields terminated by ',' lines terminated by '\n';

この場合だと、dailyの情報をpartitionに持たせるために「dt」という名前のpartitionに設定させています。その上で、このテーブルにデータをロードする場合は次のようになります。

LOAD DATA LOCAL INPATH '/path/to/20090907.csv' OVERWRITE INTO TABLE user_logs partition (dt='20090907');
LOAD DATA LOCAL INPATH '/path/to/20090908.csv' OVERWRITE INTO TABLE user_logs partition (dt='20090908');

すると、HDFS上ではバージョン情報をもったまま保存されていることが確認できます。

$ $HADOOP_HOME/bin/hadoop fs -ls /user/hive/warehouse/user_logs/
Found 2 items
drwxr-xr-x   - katsuma supergroup          0 2009-09-06 11:18 /user/hive/warehouse/user_logs/dt=20090907
drwxr-xr-x   - katsuma supergroup          0 2009-09-06 11:17 /user/hive/warehouse/user_logs/dt=20090908

これらのPartitionの情報は、もちろんHiveQL上で扱うことができて、たとえば上記例だと9月8日のUUを算出したい場合は

select count(distinct id) from user_logs where dt='20090908';

で、算出できます。また、9月7日以降のUUを算出したい場合だと

select count(distinct id) from user_logs where dt>='20090907';

な、風に書けます。直感的で便利ですよね。（この比較式はたぶん、JavaのString#compareToに従ってるんじゃないか、と推測）

まとめ

Hiveはまだ立ち上がったばっかりの若いプロジェクトですが、基本的なログ解析をするくらいの分には、かなり使えそうな印象です。上記例のように、基本的に元ファイルはそのままHDFS上に保存されているので、Hiveの不具合で何かおきた場合も自前のMap&Reduce処理に戻すことができるのも安心ですね。

今回は、あまり細かな説明までしませんでしたが、HiveQLはJoinやUnionなど割と複雑なテーブル間処理も行うことができます。このあたりも興味ある方は一度、オフィシャルのマニュアルに目を通してみてはいかがでしょうか？

• Hive/LanguageManual
]]> http://blog.katsuma.tv/2009/09/hive_introduction.html http://blog.katsuma.tv/2009/09/hive_introduction.html hadoop Mon, 07 Sep 2009 00:44:59 +0900 久々のBlog更新、というわけでリハビリがてらJavaScriptで軽く遊んでみたいと思います。

いま、巷で流行ってるMapReduceのオープンソース実装Hadoopは「Hadoop Streaming」という標準入出力でデータのやりとりができる仕組みを使って、 Hadoopの実装言語であるJavaにとらわれず、RubyやPerlなど他の言語でもMap＋Reduceの処理ができることが１つのウリになっています。 で、僕たちwebエンジニアはみんなJavaScript大好きなので、「JavaScriptでもMap Reduceやりたい！」という流れになるのは必然です。 そこで、試行錯誤でいろいろ試してみると割とさっくり出来たのでそのメモを残しておきたいと思います。

環境の整備

Mac OSX上のVMWare FusionにCentOSの仮想マシンを２台立ち上げて、環境セットアップしました。以下のような手順で環境整備しました。

仮想HWの設定

仮想マシンのイメージファイルですが、僕は毎回thoughtpoliceのサイトのものを利用しています。ここからCentOS 5.3のイメージを落としてFusionでロード。

1つハマったのが、同じイメージをコピーして複数台起動すると、MACアドレスがかぶって同時に複数台の仮想マシンがNWに接続できない点。なので、仮想マシンを最初に起動させる前にMACアドレスの設定をしておくことをおすすめします。

MACアドレスは、vmxファイルのuuid.bios値をもとに自動生成されるようで、この値を最初から全仮想マシンでバラバラにしておけばOKです。と、いっても有効な値の範囲があるので、最後の1byte値だけズラしておけばOKだと思います。たとえば、上記サイトからイメージを取得した場合、uuid.bios値の最後は「7d」になっているので、僕はこの値を「7c」「7b」なんかにズラしておきました。（Fusion上から正規の方法？で、マシンをクローンする方法がよくわからなかったので、こういう強引な方法を取っています。綺麗な方法をご存知の方いらしたらぜひ教えてください！）

ネットワーク設定

/etc/hostsを設定して２台のマシンの名前解決。細かな話ですけど、ホスト名には「_(アンダーバー)」は使えないのに要注意。最初「hdp_01」みたいなホスト名にしていて、実行時エラーが出てドはまってたときに全然気づかなかった。

• 192.168.1.15 hdp-01
• 192.168.1.16 hdp-02

SSHの設定

マシンはそれぞれ自分自身(localhopst)に対して、パスフレーズなしでSSHでログインできるように公開鍵を設定しておきます。

• ssh-keygen -t rsa -P ""
• cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
• chmod 600 ~/.ssh/authorized_keys

また、MasterのマシンからSlaveのマシンに対しても同様の設定をしておきます。今回はMasterはhdp-01, Slaveはhdp-02という設定です。hdp-01上で、次の設定をします。

• cp ~/.ssh/id_rsa.pub ~/.ssh/id_rsa_master.pub
• scp ~/.ssh/id_rsa_master.pub hdp-02:/home/katsuma/.ssh/
• chmod 600 ~/.ssh/authorized_keys

また、hdp-02上で、次の設定をします。

• cat ~/.ssh/id_rsa_master.pub >> ~/.ssh/authorized_keys

これで、Masterからlocalhost, およびSlaveに対してパスフレーズなしでログインできることを確認しておきます。

セキュリティの設定

後でハマるのが面倒なので、iptablesやSELinuxは切っておきます。必要であれば適宜設定してください。

• sudo /etc/init.d/iptables off
• sudo /etc/sysconfig iptables off
• sudo vi /etc/sysconfig/selinux
  • SELINUX=disabled に変更

Shellの設定

.bashrcなんかに以下の設定をしておくと便利です。僕はzsh派なので、.zshrcに記述しました。

# hadoop
alias cdh='cd /home/katsuma/hadoop/latest/'
alias dls='/home/katsuma/hadoop/latest/bin/hadoop dfs -ls'       # ls
alias drm='/home/katsuma/hadoop/latest/bin/hadoop dfs -rm'       # rm
alias dcat='/home/katsuma/hadoop/latest/bin/hadoop dfs -cat'     # cat
alias drmr='/home/katsuma/hadoop/latest/bin/hadoop dfs -rmr'     # rm -r
alias dmkdir='/home/katsuma/hadoop/latest/bin/hadoop dfs -mkdir' # mkdir
alias dput='/home/katsuma/hadoop/latest/bin/hadoop dfs -put'     # HDFS に転送
alias dget='/home/katsuma/hadoop/latest/bin/hadoop dfs -get'     # HDFS から転送
alias dcpfl='/home/katsuma/hadoop/latest/bin/hadoop dfs -copyFromLocal'
alias dcptl='/home/katsuma/hadoop/latest/bin/hadoop dfs -copyToLocal'

Javaのインストール

Sunのサイトに行き、 「Java SE Development Kit (JDK)」を選択して、インストーラをダウンロード。その後、以下の手順でインストールできます。

chmod +x jdk-6u7-linux-i586-rpm.bin
sudo ./jdk-6u7-linux-i586-rpm.bin

Hadoopの整備

Hadoopのインストール

Hadoopは今日時点で最新の0.20.0を利用しました。インストール場所はどこでもいいのですが、僕はホームディレクトリ直下に専用のディレクトリ掘って、いろんなバージョン試せるようにこんな感じで設置してます。ここから最新版をDLが可能です。

• cd path/to/hadoop-0.20.0.tar.gz
• tar zxvf hadoop-0.20.0.tar.gz
• mv hadoop-0.20.0 ~/hadoop/
• ln -s hadoop-0.20.0 latest

他のバージョンを試したくなったら~/hadoop/以下に展開して、シンボリックリンクを付け直すとOKですね。

Hadoopの設定

特に凝ったことはしていません。全ノードともに同じ設定である必要があるので、Masterで設定しちゃって、それをrsyncで他のSlaveと同期をとるのがよいと思います。

conf/hadoop-env.sh

export JAVA_HOME=/usr/java/latest

conf/core-site.xml

<configuration>
  <property>
    <name>hadoop.tmp.dir</name>
    <value>/home/${user.name}/hadoop/latest/tmp</value>
  </property>
  <property>
    <name>fs.default.name</name>
    <value>hdfs://hdp-01:9000</value>
  </property>
</configuration>

conf/hdfs-site.xml

<configuration>
  <property>
    <name>dfs.replication</name>
    <value>1</value>
  </property>
</configuration>

conf/mapred-site.xml

<configuration>
  <property>
    <name>mapred.job.tracker</name>
    <value>hdp-01:9001</value>
  </property>
</configuration>

conf/masters

      hdp-01

conf/slaves

      hdp-02

ここまで設定できたら、masterのイメージをrsyncしておきましょう。

cd ~/hadoop/
rsync -r hadoop-0.20.0/ hdp-02:/home/katsuma/hadoop/hadoop-0.20.0

SpiderMonkeyの導入

さて、やっとHadoopの設定が終わったので、次にJavaScriptの処理系の導入です。 Hadoop Streamingは前述の通り、標準入出力の仕掛けを使って実現されているので、さすがにブラウザの処理系をそのまま利用することができません。

そこで、FirefoxのJavaScriptのエンジンであるSpiderMonkeyを利用することにします。 SpiderMonkeyはファイルを入力としても処理できるし、irbのように対話型シェルとしても利用できるJavaScriptの処理系です。また、ブラウザを利用しないので、標準出力関数print、標準入力関数readlineが実装されてあるので、今回はこれを利用すればうまくいきそうです。

では、SpiderMonkeyを各ノードに導入します。これも最新版を導入します。あらかじめ、make, gccあたりをyumで入れておきましょう。

参考：SpiderMonkeyのインストール

• wget http://ftp.mozilla.org/pub/mozilla.org/js/js-1.8.0-rc1.tar.gz
• tar zxf js-1.8.0-rc1.tar.gz
• cd js/src
• BUILD_OPT=1 make -f Makefile.ref
• sudo install -m 755 Linux_All_OPT.OBJ/js /usr/local/bin

Map, Reduce処理のJavaScriptを記述する。

では、Map, Reduceそれぞれの処理をJavaScriptで書きます。今回はサンプルとしてよくある、ワードカウントの処理を行ってみます。

map.js

map.jsは標準入力された文章を半角スペースごとに分けて、CSVの形式に整形します。JavaScript1.7相当の機能が利用できるので、Array.prototype.forEachが利用できることもポイントです。

#!/usr/local/bin/js

var line="";
while ((line = readline())!= null){
        var words = line.split(" ");
        words.forEach(function(w){
                print(w + "," + 1);
        });
}

reduce.js

reduce.jsは、map処理されたCSV形式の入力に対して、counterオブジェクトで各単語をカウントしていきます。

#!/usr/local/bin/js

var counter = {};
var line = "";
while ((line = readline()) != null) {
        var words = line.split(",");
        var word = words[0]
        if(!counter[word]) counter[word] = 1;
        else counter[word]++;
}

for(var k in counter){
        print(k + ":" + counter[k]);
}

これらのJavaScriptファイルをhadoop/latest/script/あたりに保存しておき、全ノードで同期させておきます。

Hadoopの起動

最初にHDFSをフォーマットしておきます。Masterで次の処理を行います。

cdh
./bin/hadoop namenode -format

MasterでHadoopを起動します。

bin/start-all.sh

MapReduce用の適当な入力ファイルを作成します。こんな内容のファイルを$HADOOP_HOME/input/file1に作成します。

we are the world we change the world

このファイルをHDFSに転送します。dputは bin/hadoop dfs -putのエイリアスです。

dput input/file1 in/count

転送されてあるかどうかは、dls(bin/hadoop dfs -ls)で確認できます。

katsuma@hdp-01 ~/hadoop/latest
$ dls
Found 1 items
drwxr-xr-x   - katsuma supergroup          0 2009-07-31 02:14 /user/katsuma/in

katsuma@hdp-01 ~/hadoop/latest
$ dls in
Found 1 items
drwxr-xr-x   - katsuma supergroup          0 2009-07-31 02:56 /user/katsuma/in/count

入力用ファイルの存在が確認できたので、これでやっとMapReduce処理ができます。

./bin/hadoop jar ./contrib/streaming/hadoop-0.20.0-streaming.jar -input in/count -output out/count -mapper "js /home/katsuma/hadoop/latest/script/map.js" -reducer "js /home/katsuma/hadoop/latest/script/reduce.js"

すると、ゆったりですけど処理が進んでいきます。

packageJobJar: [/home/katsuma/hadoop/latest/tmp/hadoop-unjar4327209233542314881/] [] /tmp/streamjob4726696067913490494.jar tmpDir=null
09/07/31 10:45:05 INFO mapred.FileInputFormat: Total input paths to process : 1
09/07/31 10:45:06 INFO streaming.StreamJob: getLocalDirs(): [/home/katsuma/hadoop/latest/tmp/mapred/local]
09/07/31 10:45:06 INFO streaming.StreamJob: Running job: job_200907310237_0013
09/07/31 10:45:06 INFO streaming.StreamJob: To kill this job, run:
09/07/31 10:45:06 INFO streaming.StreamJob: /home/katsuma/hadoop/latest/bin/../bin/hadoop job  -Dmapred.job.tracker=hdp-01:9001 -kill job_200907310237_0013
09/07/31 10:45:06 INFO streaming.StreamJob: Tracking URL: http://hdp-01:50030/jobdetails.jsp?jobid=job_200907310237_0013
09/07/31 10:45:07 INFO streaming.StreamJob:  map 0%  reduce 0%
09/07/31 10:45:23 INFO streaming.StreamJob:  map 50%  reduce 0%
09/07/31 10:45:45 INFO streaming.StreamJob:  map 50%  reduce 17%
09/07/31 10:48:49 INFO streaming.StreamJob:  map 100%  reduce 17%
09/07/31 10:49:10 INFO streaming.StreamJob:  map 100%  reduce 100%
09/07/31 10:49:15 INFO streaming.StreamJob: Job complete: job_200907310237_0013
09/07/31 10:49:15 INFO streaming.StreamJob: Output: out/count

HDFS上のout/count/以下に結果が格納されたファイルができているので確認してみましょう。

katsuma@hdp-01 ~/hadoop/latest
$ dls out/count
Found 2 items
drwxr-xr-x   - katsuma supergroup          0 2009-07-31 10:45 /user/katsuma/out/count/_logs
-rw-r--r--   1 katsuma supergroup         43 2009-07-31 10:48 /user/katsuma/out/count/part-00000

katsuma@hdp-01 ~/hadoop/latest
$ dcat out/count/part-00000
are:1
change:1
the:2
we:2
world:2

まとめ

SpiderMonkeyのような処理系を用意することで、JavaScriptでもHadoopを使ってMapReduceできることが確認できました。標準入出力さえサポートされてあれば、理屈的にはどんな言語でもMapReduceできるので、MapReduceには興味あるけどJavaということで敬遠していた方は、ぜひいろんな言語で試していただければと思います。

開発のTips

なんだかんだ言って、最初開発にかなり苦労しました。と、いうのもシンタックスエラー以外は、実行しないとどうなるかよくわからないものなので、エラーで落ちたときにどうデバッグすればいいか悩みました。 ただ、よく考えれば、「標準入力→Map処理→Mapの標準出力→Reduceの入力→Reduceの標準出力」という流れになるので、たとえば今回のJavaScript実装の場合、次のように実行することでHadoopを介さなくとも動作確認は可能です。

cat input/file1 | js script/map.js | js script/reduce.js

まずは、このように手元でパイプでつないで結果を調べてみる、というのが手かと思います。実際は手元でうまく動いてもHadoop上でRuntimeエラーが起きる場合も多いので、そのときはlogディレクトリ以下にできるログファイルを調べるのがいいと思います。

また、エラーが発生するとJavaの例外のStackStraceが表示されるので、敬遠せずにそこからHadoopのソースを直接追いかけるのは何だかんだで早い解決法でした。コメントが割と充実しているので、そこからStreaming用のコードのバグを辿るのも難しくはないと思います。

]]> http://blog.katsuma.tv/2009/08/hadoop_streaming_by_javascript.html http://blog.katsuma.tv/2009/08/hadoop_streaming_by_javascript.html Javascript Sun, 02 Aug 2009 00:38:41 +0900