タグ別アーカイブ: hadoop

24 Interview Questions & Answers for Hadoop developersの和訳

24 Interview Questions & Answers for Hadoop developers : FromDevの和訳です。

Hadoopのアーキテクチャを良く理解していることは、Hadoopを理解するのに必要であり、Hadoopの力を活かすのに必要となる。ここでは、Hadoopデベロッパーインタビュー内で質問することができる、いくつかの重要な質問がある。これは主にHadoopアーキテクチャ、MapReduce、Hadoop API、HDFSに関連する質問をリストしている。

1. Hadoop内でのJobTrackerとは何?Hadoopクラスタ上ではいくつのJobTrackerインスタンスを起動できる?

JobTrackerはHadoop内で、MapReduceジョブを発行したりトラッキングするためのデーモンサービスである。Hadoopクラスタ内では、たった一つのJobTrackerが起動される。JobTrackerはJVMプロセス上で起動する。一般的な商用クラスタでは別のマシン上で実行する。各SlaveノードはJobTrackerのノード位置により構成される。JobTrackerはHadoop MapReduceサービスの単一障害点である。もしJobTrackerがダウンすると、すべての動いているジョブが停止する。

Hadoop上のJobTrackerは次のアクションを行う。(Hadoop Wikiから抜粋)
・クライアントアプリケーションがJobTrackerにジョブを発行
・JobTrackerはNameNodeと通信し、データの場所を決める
・JobTrackerは利用できるスロットを持つTaskTrackerノードやデータに近いTaskTrackerノードを示す
・JobTrackerは選ばれたTaskTrackerノードに仕事を割り振る
・TaskTrackerノードは監視される。もしハートビートが途切れた場合、失敗したと判断され、別のTaskTracker上で仕事がスケジューリングされる。
・タスクが失敗するとき、TaskTrackerはJobTrackerに知らせるでしょう。JobTrackerはその時どうするかを決める。ジョブをどこかに再発行するかもしれない、特定のレコードを避けるべきとしてマークするかもしれない、そして信頼できないものとしてTaskTrackerをブラックリストにさえするかもしれない。
・仕事が完了したとき、そのJobTrackerはステータスをアップデートする
・クライアントアプリケーションはJobTrakcerの除法を獲得することができる

2. どのようにJobTrackerはタスクをスケジュールする?

TaskTrackerはJobTrackerにハートビートメッセージを送っていた、通常数分ごと、JobTrackerにTaskTrackerがまだ生きていることを安心させるために。これらのメッセージはJobTrackerに利用できるスロットの数を伝えたりもし、そしてJobTrackerはクラスタの仕事を委任することができる場所を最新の状態に保つことができる。

JobTrackerがMapReduceオペレーションの間にタスクをスケジュールするためにどこかに見つけようとすると、データを保持しているDataNodeのホストと同じサーバーのカラのスロットを最初に探す、そして、もしダメであれば、同じラック内のマシンのカラのスロットを探す。

3. Hadoop内のTaskTrackerは何?Hadoopクラスタ上でいくつのTaskTrackerインスタンスが起動する?

TaskTrackerはJobTrackerからのMap、Reduce、シャッフルオペレーションタスクを受け入れる、クラスタ上のスレーブノードデーモンである。どんなHadoopスレーブノード上でも、たった一つのTaskTrackerプロセスが動作します。TaskTrackerはJVMプロセス上で実行します。

全てのTaskTrackerはスロットの集合で構成され、これらは受け入れることができるタスクの数を示します。TaskTrackerはTaskインスタンスと呼ばれる実際の仕事をするためのJVMプロセスに分離することで開始され、これはプロセスの失敗がTaskTrackerのダウンしないことを保証します。

TaskTrackerはTaskインスタンスを監視し、出力やexit codeをキャプチャします。Taskインスタンスが終了すると、成功もしくは失敗し、TaskTrackerはJobTrackerに通知します。

TaskTrackerもまた、JobTrackerにハートビートメッセージを送り、通常数分ごと、JobTrackerにTaskTrackerがまだ生きていることを安心させるために。これらのメッセージはJobTrackerに利用できるスロットの数を伝えたりもし、そしてJobTrackerはクラスタの仕事を委任することができる場所を最新の状態に保つことができる。

4. Hadoop内でのTaskインスタンスは何?それはどこで実行するの?

Taskインスタンスはそれぞれのスレーブノード上で実際のMapReduceジョブが実行される。TaskTrackerはTaskインスタンスと呼ばれる実際の仕事をするためのJVMプロセスに分離することで開始され、これはプロセスの失敗がTaskTrackerのダウンしないことを保証します。

それぞれのTaskインスタンスはJVMプロセス上で実行する。一つのスレーブノード上でタスクインスタンスのマルチ処理となるかもしれない。これはTaskTracer上で構成されるスロットの数に基づく。デフォルトでは、一つの新しいタスクインスタンスのJVMプロセスは一つのタスクによって生成される。

5. Hadoopシステム上ではどれくらいのデーモンプロセスが起動する?

Hadoopは5つの分離したデーモンで構成される。これらのそれぞれのデーモンは自分のJVM内で実行する。

マスターノード上で次の3つのデーモンが起動する

NameNode - このデーモンはHDFSのためのメタデータを保持する
Secondary NameNode - NameNodeのためのメンテナンス機能を行う
JobTracker - MapReduceジョブを管理し、独立したタスクをTaskTrackerを実行しているマシンに分配する

スレーブーノード上で次の2つのデーモンが起動する

DataNode - 実際のHDFSのデータブロックを保持する
TaskTracker - 独立したMapタスクとReduceタスクをインスタンス化し、モニタリングする責任を持つ

6. Hadoopクラスタ上で一般的なスレーブノードの構成は何?スレーブノード上でいくつのJVMを起動させる?

・TaskTrackerのシングルインスタンスは各スレーブノード上で実行する。TaskTrackerは独立したJVMプロセスとして実行する
・DataNodeデーモンのシングルインスタンスは各スレーブノードで実行する。DataNodeデーモンは独立したJVMプロセスとして実行する
・タスクインスタンスの一つもしくは複数のインスタンスは、各スレーブノードで実行する。各タスクインスタンスは独立したJVMプロセスとして実行する。タスクインスタンスの数はコンフィギュレーションによって制御できる。一般的にハイエンドマシンでは、多くのタスクインスタンスを実行するよう構成される。

7. HDFSとNASの違いは何?

HDFSはコモディティハードウェア上で動くようにデザインされたファイスシステムである。既存の分散ファイルシステムと似ている・が多くある。しかしながら、他の分散システムとの違いは重要である。

HDFSとNASの間に次の違いがある
・HDFSデータブロックはクラスタ内で、全てのマシンのローカルドライブにまたがって分散される。一方、NASデータは専用のハードウェア上で保存される
・HDFSは、計算処理がデータに移動されるため、MapReduceシステムで動作するようにデザインされている。NASは、データが計算とは別に保存されているので、MapReduceには適していない。
・HDFSはマシンの集合によって実行され、レプリケーションプロトコルを使用して冗長性を提供する。一方、NASは単一のマシンによって提供され、データ冗長性は提供しない。

8. どのようにNameNodeはDataNodeの障害を扱う?

NameNodeは定期的に各DataNodeからハートビートとクラスタ内のブロックレポートを受け取る。ハートビートを受け取ることは、DataNodeが正常に機能していることを暗に意味する。ブロックレポートはDataNode上の全てのブロックのリストを含む。

NameNodeがDataNodeから一定の時間ハートビートを受信していないことを検知すると、そのDataNodeは死んだものとしてマークされる。死んだDataNode上に保管されていたブロックは、複製されるでしょう。

NameNodeは一つのDataNodeから別のデータノードへデータブロックのレプリケーションを編成する。そのレプリケーションデータはDataNode間で直接転送され、そのデータは決してNameNodeを通過しない。

9. MapReduceプログラミングモデルはreducerがお互いにやりとりし合う方法を提供する?MapReduceジョブ内で、reducerは別のreducerと通信する?

いいえ、MapReduceプログラミングモデルはreducerがお互い通信し合うことを許可しない。redducerは独立して実行する。

10. reducerの数を0にセットできる?

はい、reducerの数を0にセットすることはHadoopでは妥当なコンフィギュレーションです。reducerを0にセットした時、reducerは一つも実行されないでしょう。そして、各mapperの出力がHDFS上の分割されたファイルとして保存されるでしょう。
[reducerを0以上にセットした時は条件が違い、mapperの出力(中間データ)は各mapperスレーブノードのローカルファイルシステム(not HDFS)に書かれる]

11. どこにmapper出力(中間key-valueデータ)は保存される?

mapper出力(中間データ)は各個別のmapperノードのローカルファイルシステム(not HDFS)に保存される。これは一般的にテンポラリディレクトリの場所であり、Hadoopアドミニストレータによるコンフィグ上でセットアップすることができる。中間データはHadoopジョブが完了後に綺麗にされる。

12. combinerって何?いつ私のMapReduceジョブないでcombinerを使うべき?

combinerはMapReduceプログラムの効率を上げるために使われる。combinerは中間map出力を集約するために使われる。combinerはreducerに転送するために必要なデータ量を減らすのを助けることができる。

あなたはreducerのコードをcombinerとして使うことができる。もし実行されるオペレーションが交換可能で、関連しているのであれば。

combinerの実行は保証されない、Hadoopはcombinerを実行するかもしれないし、しないかもしれない。また、一回しか実行しないかもしれない。したがって、MapReduceジョブはcombinerの実行に依存すべきではない。

13. WritableとWritableComparableインターフェースって何?

・org.apache.hadoop.io.WritableはJavaインターフェースである。Hadoop MapReduceフレームワーク内のどんなkeyもしくはvalueタイプも、このインターフェースを実装する。実装は、一般的に、新しいインスタンスを構築するstatic read(DataInput)メソッドの実装で、readFields(DataInput)を呼び出し、インスタンスを返す。

・org.apache.hadoop.io.WritableComparableはJavaインターフェースである。Hadoop MapReduce内のkeyとして使われるどんなタイプもこのインターフェースを実装する。WritableComparableオブジェクトはComparatorを使いお互いを比較することができる。

14. Hadoop MapReduce APIはkeyとvalueクラスにとって何か規約がある?

・keyはorg.apache.hadoop.io.WritableComparableインターフェースを実装しなければならない
・valueは org.apache.hadoop.io.Writableインターフェースを実装しなければならない

15. MapReduce内でIdentity MapperとIdentity Reducerは何?

・org.apache.hadoop.mapred.lib.IdentityMapperは固有の機能を実装し、mappingインプットを直接アウトプットする。もしMapReduceプログラマがJobConf.setMapperClassを使うMapperクラスをセットしないなら、IdentityMapperクラウはデフォルトvalueとして使用される。
・org.apache.hadoop.mapred.lib.IdentityReducerはreduceを実行せず、すべてのインプットvalueを直接アウトプットする。もしMapReduceプログラマがJobConf.setReducerClassを使用するreducerクラスをセットしない場合、 IdentityReducerクラスがデフォルトとして使用される。

16. Hadoop内での投機的実行の意味は?なざ重要なの?

投機的実行は個々のマシンパフォーマンスへの対処方法である。数百、数千台のマシンの巨大なクラスタは他のマシンと同等のパフォーマンスを持たないマシンも含まれているかもしれない。
これはたった一つのマシンがパフォーマンスがよくないというために、全てのジョブ内で遅延を引き起こすかもしれない。これを避けるために、投機的実行は同じmapもしくはreduceタスクの複数のコピーを別のスレーブノード上で実行することができる。最初に完了したノードの結果が使用される。

17. MapReduceジョブ内でいつreducerが始まるの?

MapReduceジョブ内でreducerは全てのMapジョブが完了するまでreduceメソッドが開始されない。reducerは中間key-valueペアをmapperから利用できるようになるとすぐにコピーを開始する。プログラマは全てのmapperが終了した後でreduceメソッドが呼ばれるように定義する。

18. もしreducerがすべてのmapperが完了しないと開始されないのなら、なぜMapReduceジョブの進行状況がMap(50%)、Reduce(10%)のように表示されるの?なぜreducer進捗パーセンテージはmapperがまだ終了していない時に表示されるの??

reducerは中間key-valueペアが利用できるようになるとすぐにmapperからコピーを開始します。進捗状況の計算もまたreducerプロセスによってデータ転送処理の計算が含まれ、そしてreduceの進捗状況ははmapperにとってのどの中間key-valueペアがreducerに転送できるようになるとすぐに表示を開始します。

reducerの進捗状況が更新されているが、プログラマが定義したreduceメソッドはすべてのmapperが終了した後にのみ呼ばれる。

19. HDFSは何?従来のFileSystemとはどう違うの?

HDFS、 Hadoop Distributed File System、はクラスタ上で巨大なデータを保存する責任を持ちます。これはコモディティハードウェア上で分散ファイルシステムを実行するためにデザインされている。既存の分散ファイルシステムと多くの類似点がある。しかしながら、他の分散ファイルシステムとの違いも大きい。

・HDFSは高度なフォールトトレラントであり、ローコストハードウェア上でデプロイするためにデザインされている
・HDFSはアプリケーションデータに対して大きなスループットを提供し、巨大なデータセットを持つアプリケーションに適している
・HDFSはとても大きなファイルをサポートするようにデザインされている。HDFSと互換性のあるアプリケーションでは、大規模なデータセットを扱う。これらのアプリケーションはたった一度だけ書き込みをするが、一回もしくは複数回読み込みをする。そして、ストリーミング速度を満足させる読み込みを必要とする。HDFSはファイル上の write-once-read-many動作をサポートする。

20. HDFSのブロックサイズは?既存のファイルシステムのブロックサイズとどう違う?

HDFS上では、データはブロックに分割され、クラスタ内の複数ノードに分散される。各ブロックは一般的に64MB もしくは128MBのサイズである。
各ブロックは複数回複製される。デフォルトは各ブロックは3回複製される。レプリカは違うノードに保存される。HDFSは各HDFSはブロックを一つの分割したファイルとして保存し、ローカルファイルシステムを利用する。HDFSはブロックサイズは既存のファイルシステムのブロックサイズと比較できない。

21. NameNodeは何?Hadoopクラスタ上でいくつのNameNodeインスタンスが起動するの?

NameNodeはHDFSファイルシステムの中心的存在である。ファイルシステム上の全てのファイルのディレクトリツリーを保持し、クラスタ全体でファイルデータが保持されている場所を追跡する。ファイル自体のデータは保持しない。

たった一つのNameNodeプロセスがどのHadoopクラスタ上でも実行される。NameNodeはJVMプロセス上で実行する。一般的に商用クラスタ内では、別のマシン上で実行される。

NameNodeはHDFSクラスタにとって単一障害点である。NameNodeがダウンすると、ファイルシステムはオフラインになる。

クライアントアプリケーションは、ファイルを探したいとき、もしくはファイルをadd/copymove/deleteしたいときは、いつもNameNodeに問い合わせる。NameNodeはデータが存在する、関連するDataNodeサーバーのリストを返すことにより、正常なリクエストの反応をする。

22. DataNodeは何?Hadoopクラスタ上でいくつのDataNodeインスタンスが起動するの?

DataNodeはHDFS内でデータを保持する。どのHadoopスレーブノード上でもたった一つのDataNodeプロセスがいる。DataNodeはJVMプロセス上で起動する。起動時に、DataNodeはNameNodeに接続する。DataNodeインスタンスはお互い話すことができ、これは主にデータの複製である。

23. どのようにクライアントはHDFSとコミュニケーションする?

HDFSとのクライアントコミュニケーションはHadoop HDFS APIを使うことにより起こる。クライアントアプリケーションはファイルを探したいとき、もしくはHDFS上のファイルをadd/copy/move/deleteしたいときいつでもNameNodeと通信する。NameNodeはデータが存在する関連するDataNodeサーバーのリストを返すことにより、成功したリクエストを返す。クライアントアプリケーションはDataNodeと直接通信することができ、いったんNameNodeはデータの配置を提供する。

24. どのようにHDFSブロックは複製される?

HDFSは大規模なクラスタ内でマシン間で非常に大きなファイルを確実に格納するためにデザインされている。ブロックの配列として、各ファイルを格納する;最後のブロックを除く、ファイル内のすべてのブロックは同じサイズである。

ファイルのブロックはフォールトトレラントのために複製される。ブロックサイズとレプリケーション要素は各ファイルごとに構成できる。アプリケーションはファイルのレプリカの数を特定できる。レプリケーション要素はファイル生成時間を特定することができ、後で変更されることもできる。HDFSは上のファイルはwrite-onceであり、、いつでも厳密に一つのwriterを持っている。

NameNodeはブロックの複製に関する全ての決定を行う。HDFSはユーザーは rack-aware レプリカ配置ポリシーを使う。デフォルト構成では、HDFS上には全部で3つのデータブロックのコピーがあり、2番目コピーは同じラック上のDataNodeに格納され、3番目のコピーは違うラックに格納される。
※和訳は上記の通りだが、象本では、2番目のコピーは別のラック上のDataNodeと書いてあるので、上記の記述は誤りである。
 

Hortonworks CEO Eric Baldeschwieler: Hadoop, the ‘Data Cloud’の和訳

英語の勉強も兼ねて、Hortonworks CEO Eric Baldeschwieler: Hadoop, the 'Data Cloud' – ReadWriteCloudの記事の和訳を載せておきます。まだまだ英語力が低いので、間違って訳している部分もあるかもしれませんので、原文も合わせてよむとよいかもです。また、もし誤訳があれば気軽にコメント頂けると幸いですm(__)m

以下、和訳。一部省略あり

この記事はReadWriteCloude channelの一部であり、仮想化とクラウドコンピューティングをカバーするために捧げられている。チャンネルのスポンサーはインテルとVMwareである。

最近、Oracleは世界の大多数のデータを管理したシステムを構築することに対する所有権を主張した。今年、同じ主張をしているグループはYahooからスピンオフしたものである。

インターネットサイズのデータベースやクラウドアーキテクチャの始まりは、リレーショナルデータベースの性質について困惑をもたらした、ちょうど2、3年より前には、その困惑について考えなければならないとは誰も考えていなかった。とても短い期間でこの部署はとても大きな歩みを見せ ーー 文字通りこの6月 ーー Hortonworksは新しい独立した会社となる。そしてApacheライセンスのオープンソースデータベースシステムであるHadoopを生み出す。そして最新のパートナーはMicrosoftである。今週、ReadWriteWebがHadoopの共同創始者であるHortonworksのCEO、Eric Baldeschwielerに取材した。

トピック:どのように、Windows ServerとHadoopを組み合わせていくのか;他のシステムよりHadoopが、データ構造が適しているのかどうかにかかわらず、数人のNoSQL支持者が主張として;そして、BaldeschwielerはHadoopをNoSQLの一部として把握していないという驚くべき意外な事実。これはHadoopとNoSQLがよく同等に扱われるという事実に反していることだ。

Scott Fulton, ReadWriteWeb:
Windows Server内での役割としてHadoopはどのような役割となるか理解していますか?もしくは役割に値するものはありますか?Domain Name Server やInternet Information ServerはServer Manager内での役割です。

Eric Baldeschwieler:
それは違う、Hadoopはたくさんのコンピューターが組み合わさったものだ。Windows ServerはHadoopクラスターを構築するために、完璧によいコンポーネントである。HadoopクラスターはOSが入った複数のマシンを必要とする。私はHadoopをWindowsのサービスとして考えていない。さらに言えば、Hadoopはコンピューターの集合の外側にあるものである、そしてWindowsでも組織が最も快適に使用しているどんなOSでも動作させることができる。

Microsoftとのパートナーシップというエキサイティングなことは、Windowsを好んで使用するとても多くの組織にHadoopを身近にすることを可能にする。

RWW:
Windowsの機能や単位としてというよりはむしろ、会社の機能、つまりWindowsを実行する全てのコンピューターのコレクションとして置かれるということを好むということですか?

EB:
はい。私はcloud offeringという類似した単語でそれを考えています。ある意味、Hadoopはdata cloudであると。いったん、Hadoopサービスで集めるなら、それがどんなOS上で動いているかは気にするべきではない。今、あなたはHadoopが入ったWindowsによってカスタマイズされたアプリケーションを使用することを選べるかもしれない。OSによって区別しないといけない機会があるが、HadoopはOSによって区別されない。Hadoopによって作られるサービスは、OSにとらわれることなく続けることができる。

Is cloud data different from “regular” data?

RWW:
構造化されたデータの性質に対する本質的ものは何かありますか?SQL Server, Oracle, DB2のようなRDBMSのクラスは、クラウド構成では動作しない、マルチプロセッサやデバイスに広がっていく、そしてHadoopはそれらの代替になると?

EB:
データについては何もない。Hadoopは競合が提供するものよりも、とてもとてもシンプルである。2つの目的のためにボトムアップで作られているので、本当にシンプルなレイヤーとなる。1つめが巨大なスケールアウト。伝統的などのシステムにもない、数千、数万ノードに到達できるようデザインし作られている。例えば、競合するデータベースは1ダースもしくは2ダースまで増やすことができるでしょう。だからHadoopは本当に広くスケールできるようにボトムアップから作られた。

もう一つの違いは、Hadoopはとてもローコストのコモディティハードウェアで構築できるように、ボトムアップから作られた。ハードウェアは壊れるという前提で作られている、そして、もしハードウェアが壊れても動き続けなければならない。これらの2つの目的でHadoopはデザインされている。つまり数千ノードで動けるように、そしてコモディティハードウェア上で動けるようにだ。そしてそれは伝統的なシステムとはとてもことなるデザインのポイントである。伝統的なシステムは基本的にとても複雑なハードウェアソリューションで問題を解決し、それをエクスポートしたものである。よりシンプルに解決できるとても多くの問題がある、もしあなたがスケールアウトについて考えていないのであれば。それは全く違うエコシステムから発達した2匹の動物を見ているようだ。

RWW:
NoSQLの概念 のまわりで点線を引いて 、 それの最中に真正面にHadoopの 象を置く人々がい ます。彼らはNoSQLの基本的な原理は、big dataは構造化されたクエリ言語のために決してデザインされるべきでなかった、と私に言います。単体、結合そして全ての数学的推論のために設計されるべきでなかったというわけではない。big dataはよりシンプルなはずであった、key/valueペアやkeyvalueアーキテクチャは受け入れられるべき、すべてのデータが最終的にあとに続く何かとして。部分的にでも同意してもらえますか?

EB:
述べられたものはない。まず第一に、Hadoopはあなたがリストしたプリミティブを持ついくつかのデータ処理言語をサポートする。HiveはSQLのサブセットを直接サポート。Pigも同様に古典的なテープルオペレーターを全員サポートする。joins, unions, すべてのセット、そして関係演算子を。そして我々はrelational algebraとそういう処理をすることに全く反対ではない。Hadoopは本当に処理エンジンでもある。

一般的に、あなたはNoSQLの動向を話すとき、私はMongoDB, Riak, Redisのような、多くのreal-time storeのことを考える。Hadoopはわずかに異なる獣です。これらはミリ秒以内に、どのようにクエリに反応するかを考えます。Hadoopはこれとは異なり、ミリ秒のレスポンスについては考えない。Hadoopが本当にフォーカスしているのは、バッチ処理である。Hadoopはコモディティハードウェアを使うことで、本当に少ないお金で構成できます。そして、あなたの仕事がある程度の潜在性を持つという仮定をすることによって、集中的な捜査の代わりに、まさしく集約型のデータスキャンニングができる。SQLデータベース、NoSQLストアでさえ、ある特定の行のデータをとてもとても速く引き出すことができるように設計されている。Hadoopはペタバイトのデータをとてもとても速くスキャンできるように設計されている。これらは違うデザインポイントである。

すべての事柄で、これらのシステムの多くが単純な分類を拒否すると思う。Hadoopが進化して、よりローレイテンシーの仕事ができるようになる。データベースが進化して、より大きなシステムにスケールすることができるようになる。そして、NoSQLが進化して、より複雑なクエリを扱えるようになる。

他のシステムがHadoopができることで上回ることができる場所は、high-bahdwidth random accessである。もしあなたが本当にできるだけ速くkey/valueペアをあなたのデータから取り出したいのなら、他のシステムを使うほうがよい。しかしもしあなたが昨年のデータをスキャンしたり、新しいパターンを発見したり、ユーザーにとってパーソナライズしたページを最もよい方法を暗示するための機械学習アルゴリズムを走らせたい場合、それもとてもとても多くのデータで、そして全てのデータを処理する必要がある場合、Hadoopは本当に優れている。

Complementary, not transitional

RWW:
Microsoftの人々は私に話します、彼らはシステム上で動かしており、時期にベータ版を置くでしょうと。そしてそれはユーザー移行データベースを助けるために、Hadoopを使うと。私は尋ねるつもりだった、なぜこの移行のために全てのデータベースではダメなのかと。しかし、私があなたが言っていることを正しく理解すれば、100万の中の1つを探すための分析のタイプではないかと。山積みの針で、シーケンシャルリードの代わりに。

EB:
はい、そのワークロードはHadoopよりも伝統的なデータベースのほうがよりコストパフォーマンスに優れています。それは疑いようがない。あなたは、人々がトランザクションのデータベースをHadoopにリプレイスするのをみないでしょう、彼らがトランザクションのシステムを構築しようとしているときは。ほとんど全てのケースにおいて意味をなすことは、トランザクションシステムからあるデータをコピーし、そして、それをHadoop上保存することです。それをするために増加するコストはとても小さく、Hadoopはそのデータを良くするために使うことができる。

例えば、私たちはYahooでの沢山のことを見てきている、数週間、数ヶ月、30、60、90日の期間かもしれない、トランザクションシステム上でデータが生きているということを。なぜなら、それくらいの長さが、生産ニーズを満たすのに必要となるからだ。しかし、Hadoopの中には1年、2年、それ以上の期間のデータを保持すべきである。それにより、前年比や複数年の粒度で調査することができる。それはあなたに違う方法でデータを理解させ、すべて利用可能となる。ところが、オンラインデータは全く利用できない、なぜならトランザクションシステム内のペタバイトデータは保持することは費用対効果がよくないからである。そして、たとえそれがそうであるとしても、我々が実際のユースケースでよく見るものは、そういう仕事はHadoopで行うことにより、既存システムの一つをちょうど壊すことができる。

だからあなたは人々が仕事を分割することを見る、例えば、トランザクションデータベースを必要とするユーザーリクエストを扱う生産システムと、数日間以上のユーザーのアクティビティを集計してレポートする生産システムの2つがある。何が起こっていたか、そのレポーティング機能はちょうどデータベースを停滞させていた。それはもはやトランザクション要件を時間内に満たすことはできない、負荷が上がるにつれて。だから彼らは集計処理をHadoopに移行してきた、そしてトランザクション処理はトランザクションデータベースに残したままである。今、彼らはより速くレポートを得ることができ、既存の従来のシステムを切り離し、毎秒より多くのトランザクションをさばいている。

RWW:
だから、補完的なユースケースがあるんですね、人々のために説明するだけでなく概念図が ーー どのように彼らのシステムを分割することができるか、彼らが1年から2年以上の間細い観察を必要とするときに、彼らは方法がある ーー

EB:
まさにそのとおり。同じことがビジネス分析システムにも適用できる。これらもまたあまりよくスケールしない。だから我々が見ていることは、人々はHadoopを使えるだろうと、新しいデータの見方を生み出すために、それらのシステムに役に立つ、データを調査するためのこれらのツールを教えられたアナリスト達によって使われることができる。それはYahooが多くのことをしている何かである;彼らは従来のツールを使っているデータの”segments”と呼ばれるものが好きであることを調査しているが、彼らは全てのデータの小さな断片で集団を組むことができるだけだ、データマートやキューの中で。だから彼らは見解を生み出すためにHadoopを使うでしょう、そしてHadoopをデータマートに積み込む。。。それはHadoopにリプレイスするケースではない、しかし他のシステムをよく補完する場所でHadoopを使用するケースである。
 

[Hadoop]象本第2版 9章 「Hadoopクラスタ構築」のまとめ

2010年頃における、Hadoopのデータノードやtasktrackerを動作させるマシンの典型的な構成
・プロセッサ
クアッドコアのIntel Xeon 2.0~2.5GHz x2
・メモリ
16~24GB
・ストレージ
4 x 1TB SATAディスク
・ネットワーク
ギガビットイーサネット

RAIDを使わないのはなぜ?

RAID0は、HDFSが使用するJBOD(Just a Bunch Of Disks:単純に大量のディスクを並べただけ)構成よりも低速であることがわかっている
HDFSのJBOD構成では、すべてのディスク間でHDFSブロックをラウンドロビンで配置。
RAID0がJBODよりも低速な理由は、RAID0の読み書き操作がRAIDアレイ中の最も低速なディスクによって制限されてしまうから
JBODでは、ディスクの操作は独立しているので、操作の平均速度は最も低速なディスクの速度よりも高速になる
Yahoo!のクラスタで実施されたベンチマークテスト(Re: RAID vs. JBOD – Runping Qi – org.apache.hadoop.core-user – MarkMail)においては、あるテスト(Gridmix)でJBODはRAID0より、10%高速であり、別のテスト(HDFSの書き込みのスループット)では30%高速
さらに、JOBD構成においてディスクの障害が発生した場合でも、HDFSは障害の発生したディスクを除外して動作を続けることができるが、RAIDにおいては1つのディスクの障害が、アレイ全体(したがってノードそのもの)を使用不可にする

小規模なクラスタ(10ノード程度)の場合、通常ネームノードとjobtrackerを同じマスターマシンで実行することができる

セカンダリネームノードはプライマリネームノードと同じ量のメモリを要求する

Hadoopの設定

Hadoopの設定ファイル
ファイル名 フォーマット 説明
hadoop-env.sh Bashスクリプト Hadoopを実行するためのスクリプトで使われる環境変数
core-site.xml Hadoopの設定用XML Hadoop Coreの設定。HDFSとMapReduceが共通に利用するI/Oなど
hdfs-site.xml Hadoopの設定用XML HDFSデーモンの設定。ネームノード、セカンダリネームノード、データノード用
mapred-site.xml Hadoopの設定用XML MapReduceデーモンの設定。jobtrackerとtasktracker用
masters テキスト セカンダリネームノードが実行されるマシンのリスト(1行に1台)
slaves テキスト データノードとtasktrackerが実行されるマシンのリスト(1行に1台)
hadoop-metrics.properties Javaのプロパティ Hadoopへメトリクスを公開する方法を制御するプロパティ
log-4j.properties Javaのプロパティ システムログファイル、ネームノードの監査ログ、tasktracker の子プロセスのtaskログのプロパティ

上記のファイルはすべてHadoopディストリビューションのconfディレクトリにある。

mastersというファイル名は、実際には誤解を招くファイル名で、これはセカンダリネームノードを実行するべきマシンのリスト。slavesファイルは、データノードやtasktrackerを実行するべきマシンのリスト。これらのファイルは、ネームノードやjobtrackerで実行される制御スクリプトからのみ使われるものなので、ワーカーノードへ配布する必要はない。

ネームノードやjobtrackerをどのマシンで実行するかは、スクリプトをどのマシンで実行するかによって決まるので、mastersファイルで指定する必要はない

start-dfs.shの挙動

1. ローカルマシン(このスクリプトが実行されたマシン)上でネームノードを起動
2. slavesファイルに書かれている各マシン上でデータノードを起動
3. mastersファイルに書かれている各マシン上でセカンダリネームノードを起動

start-mapred.shの挙動

1. ローカルマシン上でjobtrackerを起動
2. slavesファイルに書かれている各マシン上でtasktrackerを起動

メモリ

ワーカーノードのメモリの試算
JVM デフォルトのメモリ使用量(MB) 8プロセッサ、400MB/子(MB)
データノード 1000 1000
tasktracker 1000 1000
tasktrackerの子mapタスク 2 x 200 7 x 400
tasktrackerの子reduceタスク 2 x 200 7 x 400
合計 2800 7600

ネームノードに割り当てられるメモリ量は、hadoop-env.shのHADOOP_NAMENODE_OPTSを修正し、メモリサイズを設定するJVMのオプションを指定。
セカンダリネームノードの要求するメモリはプライマリと同様なので、ネームノードのメモリ割り当てを変更した場合は、セカンダリネームノードにも同様の修正が必要(HADOOP_SECONDARYNAMENODE_OPTSで設定)。

システムのログファイル

Hadoopが生成するシステムログファイルは、デフォルトで$HADOOP_INSTALL/logsに保存。
この場所は、hadoop-env.shのHADOOP_LOG_DIRによって変更することが可能。

マシン上で実行されているHadoopの各デーモンは、それぞれ2つのログファイルを生成。1つめはlog4jを使って出力されるログ。このファイルは.logで終わるファイル名を持っており、ほとんどのアプリケーションのログメッセージはこちらに出力されるので、診断すべき問題が生じた場合には、まずこのログを調べてみるべき。標準的なHadoopのlog4jの設定では、ログをローテートするためにDailyRolling File Appenderが使われる。古いログファイルは決して自動的には削除されないので、ローカルノードのディスク領域を使い切らないよう、定期的にそれらのファイルが削除されるか、アーカイブされるようにしてやらなければならない。

2番目のログファイルは、標準出力と標準エラー出力を集約したログ。このログファイルは.outで終わるファイル名を持ち、Hadoopがロギングにはlog4jを使うことから、通常はわずかな出力しかされないか、あるいはまったく出力されないか。このログはデーモンが再起動したときにのみローテートされ、最新の5つのログだけ残される。古いログファイルは1から5の数字がファイル名の末尾に付けられ、5が最も古いファイル。

SSHの設定

接続のタイムアウトを短くしたい時
→ConnectTimeoutオプション

新しいホストのキーが自動的にknown hostファイルに追加されるようにする
→StrictHostKeyCheckingでnoに設定

HDFS

HDFSデーモンの重要なプロパティ
プロパティ名 デフォルト値 説明
fs.default.name URI file:/// デフォルトのファイルのシステム。このURIは、namenodeのRPCサーバーが動作しているホストの名前とポート番号を定義する。デフォルトのポートは8020。このプロパティはcore-site.xmlで設定するべきである。
dfs.name.dir カンマ区切りのディレクトリ名 ${hadoop.tmp.dir}/dfs/name ネームノードが永続的にメタデータを保存するディレクトリのリスト。ネームノードは、リスト中の各ディレクトリにメタデータをコピーする。
dfs.data.dir カンマ区切りのディレクトリ名 ${hadoop.tmp.dir}/dfs/data データノードがブロックを保存するディレクトリのリスト。それぞれのブロックは、これらのディレクトリの中の1つにだけ保存される。
fs.checkpoint.dir カンマ区切りのディレクトリ名 ${hadoop.tmp.dir}/dfs/namesecondary セカンダリネームノードがチェックポイントを保存するディレクトリのリスト。セカンダリネームノードは、リスト中の各ディレクトリにチェックポイントのコピーを保存する。

dfs.name.dirは、1つないし2つのローカルディスクと(例えばNFSマウントされたディレクトリのような)リモートのディスクに書かれるように設定するのが一般的。

最大のパフォーマンスを得るためには、ストレージディスクをマウントする際にnoatimeオプションを付けるべき。この設定は、ファイルの読み込み時に最終アクセス時刻の情報を書かないようにするもので、かなりパフォーマンスが向上する。

HDFSのストレージディレクトリは、デフォルトではHadoopの一時ディレクトリの下にあることに注意。hadoop.tmp.dirプロパティで指定されており、デフォルトは/tmp/hadoop-${user.name}

MapReduce

MapReduceデーモンの重要なプロパティ
プロパティ名 デフォルト値 説明
mapred.job.tracker ホスト名とポート local jobtrackerのRPCサーバーが動作するホスト名とポート。デフォルト値のlocalに設定された場合、jobtrackerはMapReduceジョブが実行されたときに、要求に応じてインプロセスで実行される(この場合、jobtrackerデーモンを起動する必要はない。実際、このモードでjobtrackerを起動しようとするとエラーになる)
mapred.local.dir カンマ区切りのディレクトリ名 ${hadoop.tmp.dir}/mapred/local MapReduceがジョブの中間データを保存するディレクトリのリスト。それらのデータは、ジョブの実行終了時にクリアされる
mapred.local.dir カンマ区切りのディレクトリ名 ${hadoop.tmp.dir}/mapred/local fs.default.nameに対する相対ディレクトリ。ジョブの実行中、ここで指定されたディレクトリに共有ファイルが保存される
mapred.tasktracker.map.tasks.maximum int 2 任意の時点においてtasktracker上で同時に実行可能なmapタスク数
mapred.tasktracker.reduce.tasks.maximum int 2 任意の時点においてtasktracker上で同時に実行可能なreduceタスク数
mapred.child.java.opts String -Xmx200m mapタスクとreduceタスクを実行するtasktrackerの子プロセスを起動するのに使われるJVMオプション。このプロパティはジョブごとに設定することもでき、例えばデバッグのためにJVMのプロパティを設定したい場合などに便利
RPCサーバーのプロパティ
プロパティ名 デフォルト値 説明
fs.default.name file:/// HDFSのURIが設定された場合、このプロパティはネームノードのRPCサーバーのアドレスとポートを決定する。指定されなかった場合のデフォルトのポート番号は8020
dfs.datanode.ipc.address 0.0.0.:50020 データノードのRPCサーバーのアドレスとポート
mapred.job.tracker local ホスト名とポートを指定した場合、このプロパティはjobtrackerのRPCサーバーのアドレスとポートを決定する。一般的に使われるポートは8021
mapred.task.tracker.report.address 127.0.0.1:0 tasktrackerのRPCサーバーのアドレスとポート。これは、tasktrackerの子JVMがtasktrackerと通信するために使われる。この場合、サーバーがバインドするのはローカルのループバックアドレスだけなので、空いている任意のポートを使っても構わない。この設定を変更するのは、マシンがループバックアドレスを持たないときに限るべきである
HTTPサーバーのプロパティ
プロパティ名 デフォルト値 説明
mapred.job.tracker.http.address 0.0.0.:50030 jobtrackerのHTTPサーバーのアドレスとポート
mapred.task.tracker.http.address 0.0.0.:50060 tasktrackerのHTTPサーバーのアドレスとポート
dfs.http.address 0.0.0.:50070 ネームノードのHTTPサーバーのアドレスとポート
dfs.datanode.http.address 0.0.0.:50075 データノードのHTTPサーバーのアドレスとポート
dfs.secondary.http.address 0.0.0.:50090 セカンダリネームノードのHTTPサーバーのアドレスとポート

バッファサイズ

Hadoopは、I/O操作のバッファサイズとして4KB(4096バイト)を使用する。これは控えめな設定であり、近年のハードウェアやオペレーティングシステムであれば、バッファサイズを大きくすることで、パフォーマンスを改善することができる。64KBあるいは128KBが一般的な選択肢。この値は、core-site.xmlでio.file.buffer.sizeプロパティによって設定。

HDFSのブロックサイズ

デフォルトで64MBだが、多くのクラスタでは128MBあるいはさらに大きい256MBに設定して、ネームノードのメモリ負荷を軽減するとともに、mapperにより多くのデータを処理させている。この値は、hdfs-site.xmlのdfs.block.sizeプロパティで設定

Hadoopクラスタのベンチマーク

TestDFSIOを使ったHDFSのベンチマーク

TestDFSIOは、HDFSのI/O性能をテスト。ファイルを並列に読み書きするための便利な方法としてMapReduceジョブを使い、テストを実施。各ファイルは個別のmapタスクによって読み書きされ、mapタスクの出力は、処理されたばかりのファイルに関連する統計情報を収集するために使われる。この統計情報はreduceによって集計され、サマリが生成される。

以下のコマンドは、それぞれが1000MBのファイルを10個書きだす。

% hadoop jar $HADOOP_INSTALL/hadoop-*-test.jar TestDFSIO -write -nrFiles 10 -fileSize 1000

実行が完了すると、結果がコンソールに出力されると同時に、ローカルファイルにも記録(TestDFSIO_results.log)

読み込みのベンチマークを実行するには、引数に-readを使う。読み込むファイルはテストの時点で存在していなければならないことに注意。(TestDFSID -writeで書かれたファイルを使う)

% hadoop jar $HADOOP_INSTALL/hadoop-*-test.jar TestDFSIO -read -nrFiles 10 -fileSize 1000

ベンチマークが終了したら、生成されたファイルは引数-cleanを使ってHDFSから削除することができる

% hadoop jar $HADOOP_INSTALL/hadoop-*-test.jar TestDFSIO -clean

ソートを含むMapReduceのベンチマーク

ランダムデータの生成、ソートの実行、結果の検証の3ステップ。
まず、RandomWriterでランダムなデータを生成。RandomWriterはMapReduceのジョブをノードあたり10のmapで実行し、それぞれのmapは(おおよそ)10GBのランダムなバイナリデータを、様々なサイズのキーと値として生成。

以下に、RandomWriterにrandom-dataというディレクトリへ出力を書き出させる方法を示す。

% hadoop jar $HADOOP_INSTALL/hadoop-*-examples.jar randomwriter random-data

以下に、Sortプログラムを実行。

% hadoop jar $HADOOP_INSTALL/hadoop-*-examples.jar sort random-data sorted-data

最終的な動作チェックとして、sorted-dataにあるデータが、実際に正しくソートされているかどうかを確認

% hadoop jar $HADOOP_INSTALL/hadoop-*-test.jar testmapredsort -sortInput random-data -sortOutput sorted-data

その他のベンチマーク

・MRBench
小さなジョブを多くの回数実行。これは小さなジョブがレスポンスよく実行されるかどうかをテストするものなので、ソートのテストとはよい具合に対照的

・NNBench
ネームノードのハードウェアの負荷テストに便利。

・Gridmix
クラスタのリアルな負荷をモデル化するように設計されたベンチマークスイートで、現実の運用で見られる様々なデータアクセスのパターンをまねるもの。

最後にサイバーエージェントさんのスライドも載せておきます。



 

Hadoop 第2版

Tom White オライリージャパン 2011-07-23
売り上げランキング : 19904
by ヨメレバ

 

[Hadoop]象本第2版 まとめ

Hadoopのバイブル、Hadoop 第2版を自分用にまとめたものを公開しています。
まだまとめていない章は、まとめ次第公開予定です。
また、既にまとめている章も、適宜修正予定です。

1章 Hadoop事始め

2章 MapReduce

3章 Hadoop分散ファイルシステム

4章 HadoopのI/O

5章 MapReduceアプリケーションの開発

6章 MapReduceの動作

7章 MapReduceの型とフォーマット

8章 MapReduceの機能

9章 Hadoopクラスタの構築

10章 Hadoopの管理

11章 Pig

12章 Hive

13章 HBase

14章 ZooKeeper

15章 Sqoop

16章 ケーススタディ

付録A Apache Hadoopのインストール

付録B ClouderaのDistribution including Apache Hadoopについて

付録C NCDC気象情報データの準備

付録D NTTデータの実証事業におけるHadoop活用のポイント

Hadoop 第2版

Tom White オライリージャパン 2011-07-23
売り上げランキング : 19904
by ヨメレバ

 

Hadoop Conference Japan 2011 FALLで使用された資料やつぶやき #hcj11f

Hadoop Conference Japan 2011 FALLで使用された資料やつぶやきを抜粋しています。
まだ公開されていない資料もあるので、公開され次第掲載予定です。
また、既に公開されており、このエントリに載っていない資料があれば教えて頂けると幸いです。

開催情報はこちら↓
Hadoop Conference Japan 2011 Fall – Eventbrite

QAサイトはこちら↓
QuestionVOTE!! | Hadoop Conference Japan 2011 Fall

当日のつぶやきはこちら↓
#hcj11f – Topsy

講演資料や動画一覧はこちら↓
QuestionVOTE!! | Hadoop Conference Japan 2011 Fall

続きを読む

[Hadoop]象本第2版 2章 「MapReduce」のまとめ

MapReduceMapReduce / LKaestner

象本第2版 2章 「MapReduce」を自分用にまとめています。この章はサンプルコードが多いですが、記事には基本的にサンプルコードは載せていません(書くのが大変という理由なのは秘密)。詳細は象本を参照して下さい。

スケールアウト

MapReduceのジョブは、クライアントが実行を要求する作業単位。ジョブは、入力データ、MapReduceのプログラム、設定情報から構成される。

Hadoopはジョブをタスクに分割して実行する。タスクにはmapタスクとreduceタスクという二種類がある

ジョブの実行プロセスを制御するノードには、2つの種類がある
→1つだけ置かれるjobtrackerと、複数置かれるtasktracker

jobtrackerは、tasktracker郡によって実行されるタスクをスケジューリングすることで、システム上で実行されるすべてのジョブを管理

tasktrackerはタスクを実行し、進行状況のレポートをjobtrackerに送信する。jobtrackerは各ジョブの全体的な進行状況の記録を保管。タスクに障害が発生した場合、jobtrackerはそのタスクを別のtasktrackerが実行するように再スケジュール

Hadoopは、MapReduceジョブへの入力を、入力スプリット(あるいは単にスプリット)と呼ばれる固定長の断片に分割
→各スプリットに対して1つのmapタスクを生成
→mapタスクは、ユーザーが定義したmap関数を、スプリット中の各レコードに対して実行

スプリットを大量に持つ
→それぞれのスプリットの処理に要する時間が、入力全体を処理する時間に比べて比較的小さくなる
→高速なマシンは低速なマシンに比べて、多くのスプリットを処理することができるようになり、全体の処理はうまくロードバランスされる

スプリットが小さい
→全体のジョブ実行時間に占める、スプリットの管理とタスクの生成に要するオーバーヘッドの割合が大きくなる

HDFSのデフォルトのブロックサイズは64MB。

Hadoopは、入力データがHDFSに格納されているノード上でmapタスクが実行されるよう、できる限りのことをする
データローカリティ最適化処理

mapタスクはその出力を、HDFSではなくローカルディスクに書きだす
→mapの出力は中間的な出力。reduceタスクによって処理されるもので、ジョブが完了すれば廃棄される。そのため、この出力をレプリケーションを行うHDFSに保存することは、過剰な処理

reduceタスクにはデータローカリティによる利点がない
→1つのreduceタスクへの入力は、通常全mapperからの出力になる

map出力のソート→reduceタスクが実行されているノードへネットワーク経由で転送→reduceタスクのノード上でマージ→ユーザーが定義したreduce関数に渡す

reduceの出力は信頼性を考慮してHDFSに保存

複数のreducerがある場合、mapタスクはその出力をパーティション化し、それぞれのreduceタスクに対して1つのパーティションを生成。それぞれのパーティションにはいくつものキー(とそれに付随する値)が含まれることがあるが、同じキーに対するレコードは、全て単一のパーティションに格納。パーティション化の処理は、ユーザーが定義するパーティション化関数によっても制御できるが、通常はデフォルトのpartitioner(ハッシュ関数を使ってキーを割り振る)が十分うまく処理してくれる

reduceタスクが存在しない場合
→処理全体が完全に並列に行える場合で、シャッフル処理が不要な場合には適切。こういったケースでは、ノード外へのデータ転送が行われるのは、mapタスクによるHDFSへの書き出しのときのみ

Hadoopストリーミング

Haoopストリーミングは、Unix標準のストリームをHadoopと作成するプログラムとのインターフェースとするので、標準入出力での読み書きができる言語であれば、どの言語を使ってもMapReduceのプログラムを書くことができる

ストリーミングとJava MapReduce APIとの設計の違い
→JavaのAPIは、1回のmap関数の呼び出しで1つのレコードが処理されるようになっている。MapReduceフレームワークはMapperのmap()メソッドを入力中の書くレコードに対して呼び出すが、これに対してストリーミングを使った場合には、mapプログラムはどのように入力を処理するか自分で決めることができる。例えば、ストリーミングのmapプログラムは自分で読み出し方を決めることができるので、複数行を1度に読み込んで処理してしまうことも簡単ににできる。ユーザーによるJavaのmap実装はレコードを「プッシュ」で受け取るが、Mapperのインスタンス変数にそれまでの行を蓄えておくことで、複数行の一括処理を検討してみることも可能ではある。この場合、最後のレコードが読み込まれたことがわかるように、close()メソッドを実装しなければならない。それで、行の最後のグループの処理を完了させることができるようになる

RubyとPythonのサンプルプログラムが記載されているが、ここでは省略

ストリーミングに代わるものとして、PythonプログラマはDumboの利用を検討するとよい。DumboはストリーミングのMapReduceインターフェースをよりPythonらしくしてくれるもので、より使いやすくなっている

Hadoop Pipes

Hadoop Pipesは、Hadoop MapReduceへのC++のインターフェースに付けられた名前。mapおよびreduceのコードとのやりとりに標準入力を使うストリーミングとは異なり、PipesではtasktrackerがC++のmapあるいはreduce関数を実行するプロセスと通信するためのチャネルとして、ソケットを使う。JNIは使われていない。

サンプルコードは省略

Hadoop 第2版

Tom White オライリージャパン 2011-07-23
売り上げランキング : 21294
by ヨメレバ

 

[Hadoop]象本第2版 1章 「Hadoop事始め」のまとめ


Hadoop / ryochiji

象本第2版 1章 「Hadoop事始め」を自分用にまとめています。

開拓の時代には、重い物を引くのに雄牛がつかわれたものですが、1頭の雄牛が丸太を引くことができなくても、もっと大きな雄牛を育てようとはしませんでした。私達が挑戦しなければならないのは、より大きなコンピュータを作ろうとすることではなく、より多くのコンピュータからなるシステムを作ることです。

—- Grace Hopper

データ!

私たちはデータの時代に生きている。
・ニューヨーク株式市場は、1日ごとに1テラバイトの新たな取引データを生み出している
・Facebookはおよそ100億枚の写真をホストしており、これは1ペタバイトの記憶領域を占める
・The Internet Archiveはおよそ2ペタバイトのデータを保管しており、その容量は1ヶ月あたり20テラバイトのペースで増加している
・スイスのジュネーブ近郊にある大型ハドロン衝突型加速器は、年間およそ15ペタバイトのデータを生み出している

個人が生み出すデータの容量は増大する方向にあるが、より重要なのは、機械が生成するデータの量が、人の産み出すデータ量にも増して多いこと

より多くのデータはよりよいアルゴリズムを凌駕する

データの保管と分析

ハードディスクのストレージ容量は年を追うごとに大容量になっているが、アクセス速度(データをドライブから読み出す速度)は、その増加についていっていない

1テラバイトのドライブが一般的になっているが、転送速度はおよそ100MB/s

ハードウェア障害への対処
→多くのハードウェアを使うようになると、障害が起こる可能性が高くなる
→Hadoop Distributed Filesystem(HDFS) でレプリケーション

分析作業には何らかの形でデータを結合できなければならない
→MapReduceはディスクの読み書きの問題を抽象化し、キーと値の集合に対する演算処理に変換するプログラミングモデルを提供

他のシステムとの比較

MapReduceはバッチクエリプロセッサであり、任意のクエリをデータセット全体に対して実行し、その結果を合理的な時間内に得られることこそが、変化を起こす力

多くのディスクでデータベースを使って、大規模なバッチ分析をするわけにはいかないのはなぜか?MapReduceが必要なのはなぜか?
→その答えは、ディスクドライブに関するもう1つのトレンドにある
→シークタイムは、転送速度にも増してゆっくりとしか改善されない

データベース内のレコード郡のごく一部を更新するような場合には、伝統的なB-Treeはうまく働く

データベースの大部分を更新するような場合は、ソート/マージによってデータベースを再構築するMapReduceに比べて、B-Treeは効率が悪くなる

MapReduceとRDBMSとの比較
  伝統的なRDBMS MapReduce
データサイズ ギガバイト ペタバイト
アクセス インタラクティブもバッチも可 バッチ
更新 何度も読み書きされる 書き込みは一度で、読み出しは何度も行われる
構造 静的なスキーマ 動的なスキーマ
整合性 高い 低い
スケーラビリティ 非直線的 直線的

MapReduceはデータを処理する時点で解釈するように設計されているので、非構造化あるいは準構造化データの処理に適している
→言い換えれば、MapReduceに入力されるキーと値は、そのデータが本来持っている属性というわけではなく、データの分析者によって選択される

MapReduceはデータを演算ノードにあわせて配置しようとするため、データアクセスがローカルになるため高速
データローカリティと呼ばれる機能。MapReduceの中核

MapReduceは、プログラマが障害について考える必要をなくす
→タスクに障害が起きたことを検知し、代わりのタスクを健全なマシン上に再度スケジューリングする
→これが可能なのは、MapReduceがshared-nothingアーキテクチャを採用している、つまり各タスクはお互いに依存しあわないようになっているから

Hadoopの歴史

Hadoopは、Doug Cuttingによって開発

「Hadoop」という名前の由来
→Doug Cuttingの子供が黄色い象のぬいぐるみに付けたもの
→短くて、比較的簡単に綴れて発音でき、意味がなく、他のどこでも使われていない

Yahoo!のチームがHadoopを使って1テラバイトを62秒でソート(2009年5月)

Apache HadoopとHadoopエコシステム

以下は、本書で取り上げるHadoopのプロジェクト郡の簡単な説明

・Common
分散ファイルシステムと汎用的なI/O(シリアライズ、Java RPC、永続的データ構造)を提供するコンポーネントとインターフェースの集合

・Avro
効率的かつ多言語間RPCのためのシリアライゼーションシステムと、永続的データストレージ

・MapReduce
分散データ処理モデルおよびコモディティマシンで構成される大規模クラスタ上の実行環境

・HDFS
コモディティマシンで構成される大規模クラスタ上の分散ファイルシステム

・Pig
データフロー言語および超大規模データセットの調査実行環境。PigはHDFSおよびMapReduceクラスタ上で実行される

・Hive
分散データウェアハウス。HDFSに保存されているデータを管理し、そのデータに対するクエリを実行するための、SQLに基づくクエリ言語(この言語は、ランタイムのエンジンによってMapReduceのジョブに変換される)を提供

・HBase
列指向の分散データベース。HBaseは下位層のストレージとしてHDFSを使用し、MapReduceを使ったバッチ型の演算処理と、一部を読み出すクエリ(ランダムリード)をともにサポート

・ZooKeeper
高可用性分散協調サービス。分散アプリケーションを構築するのに使われる分散ロックのような基礎的な機能要素を提供

・Sqoop
リレーショナルデータベースとHDFSの間で、効率的にデータを移動させるためのツール

Hadoop 第2版

Tom White オライリージャパン 2011-07-23
売り上げランキング : 21294
by ヨメレバ