Hue 2.5でHBaseアプリを動かす(成功編)

昨日失敗したHue2.5、ようやく成功したので手順を書いておきます。

Hueのダウンロード

hueのソースコードは http://gethue.com からダウンロードできます。

最新版を使うため、githubにあるソースをクローンしました。昨日ダウンロードしたソースとdiffを取ってみましたが、かなり差分があるようでした。

作業ディレクトリに移動して、git cloneします。 (続きを読む)

象本3版出版記念セミナー

オライリー&Clouderaによるセミナーが7/24の夜に開催されます。

タイトル:『プログラミング Hive』 『Hadoop 第3版』刊行記念 Hadoopセミナー

申し込み、詳細:http://connpass.com/event/2944/

現時点で残り48名なので、興味のある方はお早めに!

Cloudera Impalaの言語リファレンス

Impalaの言語リファレンス

Impalaは(少なくとも現状では)SQL92に準拠していないので、サポートしていないデータタイプやクエリがあります。ドキュメントが更新されていたので、備忘録がてらリンクを貼っておきます。

ImpalaがサポートしているDML/DDL、節など (続きを読む)

Hadoop 第3版(象本3版)の発売が決定!

象本!

「象本」の愛称で有名な、O’ReillyのHadoop。(原題:Hadoop: The Definitive Guide)

第2版の日本語版は2011年7月23日に発売、2年の歳月を経て、ようやく第3版の発売が7/26に確定したとのことです。(まだウェブには公開されていません)

#思えばちょうど2年前に象本2版と徹底入門を買ったなぁ。もう2年なのかまだ2年なのかわかりませんが、懐かしい。。。

翻訳は、Hadoop関連本を含めて実績も品質も抜群な玉川さん。先月「プログラミングHive」が出版されたばかりなのに、、、寝ていないのかMapジョブを分散して仕事をしているとしか思えません。

日本語版の付録には、Clouderaの小林大輔さんが最新の高可用性HDFSとして、JournalNodeなどの寄稿をしています。

今回も「HBase」(馬本)「プログラミングHive」に続き、微力ながらレビューのお手伝いをさせていただきました。

第3版での変更点

  • 高可用HDFS
  • YARN (MapReduce v2)
  • MRUnit

大きな追加は上記ですが、それ以外にも細かいところを含め、かなりの部分がアップデートされています。書籍も700ページ弱とのことで、全部読むのはツラいので、辞書代わりに使うのがお勧めです。

以前から英語版は持っていたのですが、やはり日本語で読めるのは嬉しいですね。

その他

翔泳社からは「Hadoop徹底入門 第2版」が発売されるとのことなので、前回のブログ、「Hadoopを10分で試す」も含め、夏休みは象で遊ぶしかない!?。

Hadoopを10分で試す(まとめ)

**この記事の内容は若干古くなっています。まとめページもご覧下さい**

Hadoopを使ってみたい!

新しく何かを始めようと思った時、面倒だなぁと思うことは多いものです。書籍やブログをみて「これは役立ちそうだ」と思っても、ちょっと試すことにさえにも辿り着けず、頓挫しているものがTODOリストやPocket(旧Readitlater)に大量にあります。
#書いていて嫌な気持ちになってきた、、、

Hadoopはそんな面倒なものの一つかもしれません。書籍を読んで「よし、やってみるか」という強い決意を持ったすぐ後、

「試すにはマシンを買わないといけないのかなぁ」
「いや、EC2でいけそう。アカウントどうしようか」
「なんか仮想マシンでもできそうって書いてある」
という第一の壁があります。

運良く壁を乗り越えたあと、
「ソフトはどこからダウンロードすればいいだっけ?」
「コマンドラインでやるの?」
「設定面倒そうだなぁ」

いつやるの?ー>「今でしょ」「今度でいいや!」

というパターンになっていまうことが多いです。良質な書籍も記事も多いのですが、いかんせん最初の壁が高い印象があります。

Hadoopを10分で試す

先月書いたブログ、「Hadoopを10分で試す」シリーズでは、あらかじめ用意されている仮想マシンイメージを使い、最初の敷居を下げることを目的として書いてみました。過去に挫折したことがある方は週末にでも是非!

Hadoopを10分で試す(1)Clouderaの仮想マシンをインストール

Hadoopを10分で試す(2)Clouderaの仮想マシンを日本語化

Hadoopを10分で試す(3)HueからHiveとImpalaのクエリを実行する

Hadoopを10分で試す(4)CDH4.3にバージョンアップ

Hadoopを10分で試す(番外編)

Hadoopを10分で試す(5)Cloudera Quickstart VM 新版リリースと日本語化

Hadoopを10分で試す(6)HueからSolrを使う

Hadoopを10分で試す(7)再びHueからHiveとImpalaを使う

Hadoopを10分で試す(8)HueからSolrを使う-その2

注意

「よし、やってみよう」と言う方は(5)から始めるのが良いでしょう。(仮想マシンイメージのバージョンが新しくなったので)
(1)と(2)は(5)と並行して参照する程度、(3)は重要ですが(4)は不要です。

 

※ブログサーバの調子が悪いので、はてなブログと並行運用しています

HDFSが高速に?mmapによるzero-copyでの読み込み

本日公開されたHDFSの高速化に関連するJIRAの2つ目です。

通常、アプリケーションはread()などのシステムコール経由でファイルを読み出します。
このHDFS-4953はmmap()システムコールを使用することで、読み取り時にかかるオーバーヘッドを減らそうというもののようです。

参考までに、通常アプリケーションがファイルを読み出す場合、以下のようなフローでカーネルからの読み込み処理が行われます。

アプリからの読み込み要求
   v
fread()など (stdlib)
   v
read()システムコール(glibc)
   v
(以下カーネル空間)
   v
sys_read()
   v
vfs_read()
   v
  ….
参考資料:ページキャッシュのメモ P.12

アプリケーションからの読み出し要求によりシステムコールが呼ばれるのは上記の通りですが、問題となるのは、

  • read()が頻繁に呼びだされる場合、コンテキストスイッチが多く発生してコストがかかる※コストの計測には strace や valgrind、perfなどが利用できます
  • デバイスから読み込んだカーネル空間のデータを、copy_to_user() などによってユーザー空間にコピーする必要がある

mmap()を使用することで、ファイルをメモリにマッピングすることができるようになります。以前の@ITで面白い比較があったので、興味があればご覧になって下さい。

ということで、mmap()によりゼロコピーにする、というのがこの修正案のようです。

注意しなければならないのは、mmap()システムコール自体のコストはそれなりにかかるので、1)ファイルオープン、2)数バイト読み込み、3) クローズ、というようなアクセスパターンであれば、mmap()よりもread()の方が良いかもしれません。ただしHDFSのブロックサイズは64MB なので、mmap()の効果は期待できますね。

HDFSが高速に?キャッシュメカニズムの追加

本日公開された HDFS-4949 のJIRAは、HDFSにインメモリキャッシュ機構を導入しようというものです。

Jiraに添付されているドキュメントより興味深い点を抜粋してみます:Centralized cache management

問題点1:複数ノードでのキャッシュの利用

HDFS上のデータの読み書きの際には、ディスクから読み出されたデータは、Linuxのカーネル内のページキャッシュ(原文ではBuffer cacheとなってます)にキャッシュされます。(これにより毎回ディスクアクセスを避けることが期待できます)
しかし、ページキャッシュの情報はカーネルが持っており、ユーザーランドに公開されているわけではありません。つまり、上位のフレームワークの視点から見ると、タスクをどのノードに配置するかのために公開されているわけではないということです。(当たり前ですが、、)
その結果、HDFSにおいてはブロックの複製数が3だとすると、タスクが配置されるノードが異なる場合、3つのデータノードそれぞれのページキャッシュに 格納され、3倍のメモリが消費される可能性があります。また、せっかくページキャッシュにデータをキャッシュしているノードがあるにもかかわらず、スケ ジューラはページキャッシュにない(つまりまだディスクから読み出していない)ノードを選択してしまうことになります。

問題点2:低優先度のジョブによるキャッシュへの悪影響

次に、大規模なシングルパスかつ低優先度のワークロードが、高い優先度のジョブのキャッシュを消しさってしまうことになり得ます。ページキャッシュ はカーネルのLRUにより制御されているので、ユーザーランドからの制御を行うのは難しいです。となると、せっかくキャッシュがあったまったのにも関わら ず、どうでもいい(?)ジョブがキャッシュを乱してしまうことから、プロダクションで使用する場合のSLAに悪影響を与え、ジョブの終了時間が増えること に繋がります。

この新しいキャッシュ機構は、上記の問題を改善するために、HDFSの元の仕組みは大きく変更せずに追加しようとしているものです。

まだ詳細までは追えていませんが、この実装はHDFSの高速化に繋がることが期待できるので楽しみですね!

2013/7/5追記:
@oza_86さんにコメントいただいたので追加しておきます。HDFS-4949の元になった論文:
http://www.cs.berkeley.edu/~istoica/classes/cs294/11/papers/pacman-draft.pdf

※ブログのサーバの調子が悪いので、はてなブログに移行するかもしれません。