Hadoopの概念＆基本的知識

2015/1/6

DMM.comラボ勉強会資料

今回の勉強会の目標

1.Hadoopがどんなものかなんとなく理解する

2.Hadoopシステムをどう作れば良いか学ぶ

3.Hadoopとどう付き合うか考える

全部で60ページあるので、飛ばし気味でいきます。

わかりやすいHadoop

＋パンチ

HADOO Punch

わかりにくいHadoop

Apache Hadoopは大規模データの分散処理を支えるJavaソフトウェアフレームワークであり、フリーソフトウェアとして配布されている。[2]Hadoopはアプリケーションが数千ノードおよびペタバイト級のデータを処理することを可能としている。HadoopはGoogleのMapReduceおよびGoogle File System(GFS)論文に触発されたものである。

Apache Hadoop (wikipediaより)

よくわからん！！！

今回説明するのは、こっちね。

Hadoopがわかりにくい点

● ソフトウェアフレームワーク？？、なにそれ？？● Googleと関係あるの？？

● MapReduceって何？？● 用語やツールが沢山ありすぎる？？● Hadoopエコシステム？？地球にやさしい？

● 具体的に何をするものなのかわからない

なぜHadoopが必要になったか 1

● 生み出されるデータはどんどん増える。

● データから価値を得るためには処理をしなきゃいけない。

● データを格納するためのハードディスクの容量はどんどん増えて値段も下がっている。

● ところが転送レートは容量に追随できていない。

年 容量(GB) 転送レート(MB/s) ディスク読み込み時間

1997 2.1 16.6 126秒

2004 200 56.6 59分

2014 3,000 210 3時間58分

(Cloudera Administrator Training資料から引用)

なぜHadoopが必要になったか 2

● 巨大なデータを1台のマシンで処理しようとするとバス幅がボトルネックになる

● データ処理はデータを保持しているノード毎に行なって、それを集計すれば良さそう？

● GoogleがMapReduceおよびGoogle File System(GFS)論文を発表。

● インスパイア！！！（Googleのものとは違う!!)

（参考) Googleの論文

http://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf

http://static.googleusercontent.com/media/research.google.com/ja//archive/mapreduce-osdi04.pdf

Hadoopの超訳的説明

● 巨大なデータを格納するHDFS● 分散処理技術MapReduce

この2つの技術を軸とするフレームワーク

膨大な量のデータを処理する道具の集合体（→Hadoopエコシステム)

ＨＤＦＳ

HDFSの概要

● GFS(Google File System)をベースにしている● 膨大なデータ量を格納可能● シンプルなアーキテクチャ● ライトワンス● 低レイテンシーではない。（応答は遅い)● データスループット指向。● データは標準で3重化。

● データは128MB毎（以前のバージョンは64MB)に分割。分散配置される。(ブロックサイズ大きめ)

● データの格納先(メタデータ)を保持するNameNodeはシングルポイント。（※シングルポイントの問題を回避する方法は後で説明)

● HDFSクライアントを使ってアクセスする。

● HTTP、FTP、Fuseなどからもアクセスできる（専用のHDFSクライアント経由)。

古典的HDFS構成図

NameNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

〜

〜メタデータを格納するNameNodeは1台

実データを格納するDataNodeは沢山

SecondaryNameNode

注意！！！Secondary NameNodeはバックアップではない。編集ログを元にメタデータを再構成するためのもの。

※古典的じゃないのは後で説明する

HDFSへのアクセス(READ)

NameNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

〜

〜

HDFS Client

1:格納先問い合わせ

2:格納先を返答

3:データ取得依頼

4:データ転送

HDFSへのアクセス(Write)

NameNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

〜

〜HDFS Client

1:格納先問い合わせ ラック配置等を考慮して格納先を決める

3:データ投入

4:書きこみ成功5:DataNode間での複製

標準だと3重化

2:格納先を返答

DataNodeでの障害

NameNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

〜

〜

1:ハートビートおよびチェックサムによる障害検知

2:格納位置を再設定、データ複製指令

3:データ複製

欠損したブロックが保持していたデータを、他のDataNodeから複製することで、3重化を保つようにする。

HDFSのトラフィックのポイント

● データ通信はNameNodeを経由しない。

● 読み込み時のデータ通信はHDFS ClientとDataNodeの間の通信。

● 書きこみ時の複製はDataNode間の通信

● DataNode障害時は、DataNode間の通信。

NameNodeのトラフィックはボトルネックにならない。DataNodeを増やせばトラフィック上限を増やせる

NameNodeでの障害

NameNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

〜

〜

シングルポイント。アクセス不能になってしまう。

DataNode中のデータは無事。

メタデータがバックアップしてあれば、NameNodeを作り直して復旧できる

HDFS Client

1:格納場所問い合わせ

HDFSへのアクセス(hadoop fsコマンド)

● シェルからhadoop fsコマンドでアクセスできる

● UNIXを知ってる人なら直感的に操作可能

$ hadoop fs -cat /user/pochi/test.txt$ hadoop fs -mkdir /report$ hadoop fs -ls /user$ hadoop fs -get log.txt log.txt$ hadoop fs -put log.txt log.txt$ hadoop fs -rm /user/pochi/test.txt$ hadoop fs -chown pochi /user/pochi$ hadoop fs -chmod 777 log.txt

※ hadoop fs コマンドの代わりに hdfs dfs コマンドでも同じことができます。

ＭａｐＲｅｄｕｃｅ

MapReduce処理のイメージ

UNIX の wc コマンド

wc -w <ファイル名> 単語の数を数える

超巨大なファイル

ファイルを分割

分割されたファイル毎に単語の数を数える

集計

全体の単語の数がわかる

巨大なファイルのまま単語の数を数えるより高速

※実際にMapReduce処理のサンプルとして使われるWord Count とは違うことに注意。

MapReduceと相性が良いHDFS

• ファイルが128MB毎に分割され、複数の筐体に格納されている。

• 格納先は通常のサーバ。そのCPUを分散処理に利用できる。

データがあるノードで処理を行なうことができる

MapReduceのバージョン

● MapReduceには、Version 1と2がある。

● Version2では、YARNというリソースマネジメントの仕組みが加わった。

MapReduce V1 MapReduce V2

YARN

MapReduce V1のシステム構成

TaskTracker DataNode

TaskTracker DataNode

TaskTracker DataNode

TaskTracker DataNode

NameNodeJobTracker

クライアント

1筐体上で DataNode と TaskTracker が動く

MapReduce V1 の動作

TaskTracker DataNode

TaskTracker DataNode

TaskTracker DataNode

TaskTracker DataNode

NameNodeJobTracker

クライアント

1.タスク依頼

2.MAP

3.Reduce

元データ、中間データ、最終データは、すべてHDFS上に置かれる

YARN+MapReduce V2のシステム構成

NodeManager DataNode

NameNodeResourceManager

クライアント

1筐体上で DataNode と NodeManager が動くJob Trackerの代わりにResource Managerを使う履歴を管理するための Job History Server が追加

NodeManager DataNode

NodeManager DataNode

NodeManager DataNodeJob HistoryServer

NodeManagerの機能

● Mapタスク、Reduceタスクを実行するコンテナとして動作する

● Application Masterとして機能する

YARN+MapReduce V2の動作 1

NodeManager DataNode

NameNodeResourceManager

クライアント

Jobを投入されたNodeManagerは、Application MasterになるApplication MasterはResource Managerにリソースを要求し割り当てられたリソースにMAPタスクを投入する

NodeManager DataNode

NodeManager DataNode

NodeManager DataNodeJob HistoryServer

1.タスク依頼

2.Job投入

Application Master3.リソース要求

4.MAP

YARN+MapReduce V2の動作 2

NodeManager DataNode

NameNodeResourceManager

クライアント

Application MasterはResource Managerにリソースを要求し割り当てられたリソースにReduceタスクを投入する処理完了後履歴を記録する元データ、中間データ、最終データは、すべてHDFS上に置かれる

NodeManager DataNode

NodeManager DataNode

NodeManager DataNodeJob HistoryServer

Application Master5.リソース要求

6.Reduce

7.履歴記録

なんか複雑に

なってきたぞ。。。

シングルポイントはなんとかしたいNameNodeを冗長化

DataNode DataNode DataNode DataNode

Zookeeper Zookeeper Zookeeper

JournalNode

JournalNode

JournalNodeNameNode

QuorumJournal Manager

ZookeeperFailover

Controller

NameNode

QuorumJournal Manager

ZookeeperFailover

Controller

冗長性確保のために

こんなに複雑に。。。

シンプルさはどこへ。。。

Hadoopエコシステム

● Hadoopの関連ツール

– データ投入: Sqoop、Flume

– データ処理: Spark

– データ分析: Hive、Pig、Impala

– データ探索: Solr

– 機械学習: Mahout、Oryx

– ユーザインターフェイス: Hue

– ワークフロー管理: Oozie

– クラスタ管理: Cloudera Manager等

Hadoopはこういうプログラム経由で利用される

さらにHadoopに足りない機能

• ちゃんとしたセキュリティの仕組み• 統合管理のための仕組み

(参考)Googleは今はMapReduceを使っていない

● 「Google I/O 2014」（2014年6月25日）で、「Google Cloud Dataflow」を発表

● 基調講演で「Google社内でMapReduceをほとんど使っていない」と語る

● Googleは並列パイプライン処理技術である「FlumeJava」や大規模ストリーム処理技術である「MillWheel」など新しい技術を次々と開発している。

※その1ヶ月後、やっぱりMapReduceも使ってるよ、と別の人が言ってるけどね→Appendix参照

Hadoopも進化している

● Hadoop 2 リリース(2013年10月)– MapReduce以外の処理にも対応

– DAGエンジンを使うことで100倍高速化も実現

– SparkはDAGエンジンの1つ

● HDFSの性能向上、別のファイルシステムへの移行

– HDFSのAPI、MapReduceのAPIを維持できれば内部構造は柔軟に変更できる。

– HDFS以外のファイルシステムも、HDFS、MapReduceのAPIを実装してきている。

素朴に手作業でインストールするのは

無茶！！！

Hadoopのディストリビューション

沢山ある。

これらを使えば楽にインストールと管理が可能。

● Cloudera CDH● MapR● Hortonworks HDP● Pivotal● IBM Biginsights● Microsoft HDinsight

笑っちゃうぐらい便利！！

Hadoopシステムを作るにあたって考えるべきこと

どんなシステム開発でも共通のこと

● このへんはちゃんと決めておく（仮説でもOK)– システムのオーナー– 目的– 体制– 運用プラン– システムの寿命– KPI– コスト

これがはっきりしてないシステム開発は要注意！！

Hadoopで考慮すること

● どんなデータを溜めるのか？● 容量はどのぐらい？、どのぐらいの容量で増加する？● システムを段階的に増強していく？、作ったシステムはそのまま？● データのバックアップはどうする？● そのデータをどう処理する？● データを誰が使う？● アプリケーション開発者との連携はどうする？● Hadoopの技術サポート体制をどうする？

これらにより用意するデータセンター、ネットワーク、ハードウェア、が変わってくる。

それ自前Hadoopでいいの？

● 自前でHadoopを構築する以外にも選択肢はある。

● Amazon Redshift 等も有力。

● ログ解析だったら、Fluentd+Riakを使うとか。

● Treasure Data のような便利なASPもある。

Hadoop以外の技術を使う、自前でやらない、という選択肢も捨てるべきではない。

それでも自前でやるメリットはあるぞ。

ハードウェア選定等

ハードウェア選定のポイント

● MasterNode（NameNode、ResourceManager等)と、SlaveNode（データを格納するストレージ)は、特性が異なる。

SlaveNodeの推奨ハードウェア

● 筐体は2Uのサーバ等、ハードディスクが沢山載るもの。R720とか。

● メモリは多め。● ハードディスクはRAIDを組まない。

– OS部分はRAID1とかのほうが良いかも。

– OSはSDカードから起動してハードディスクは全部データ領域とかも。

● ネットワークは最低1G、できれば10G。

● CPUは動かすプログラムによるが6コア程度でOK。● コストパフォーマンスが良い筐体を選ぶ。

SlaveNodeの非推奨事項

● 仮想サーバはできればNG。共有リソースがボトルネックになる可能性がある。

● ブレードサーバもNG。共有部分がボトルネックになる可能性がある。

● RAID構成もNG。遅くなる可能性がある。

MasterNodeの推奨ハードウェア

● コモディティハードウェアじゃなく、キャリアクラスハードウェアを選ぶ。

● ハードウェアで冗長化できるところは冗長化する。● 電源冗長化。● ハードディスクはRAIDを組む。● ネットワークはボンディング構成。● メモリは沢山積む。

その他注意点

● ハードディスクはLVM等も使わず素の状態で1台ずつmountする

● Java は Oracle Java を使う。

● Chef等の構成管理、自動化ツールは必需品

● IPv6は無効化する!!!

Hadoopを配置するネットワークセグメントのセキュリティについて

セキュリティに関しての考慮事項

● Hadoopの各システム間は通信できる必要がある。

● Hadoopのセキュリティ機能はあてにできない。● データの中には大事なものが含まれる、と考える。● MySQL等のデータベースと同じぐらい大事。● アクセスできる人をネットワーク的に制限すべき。● Hadoopの各システムはウェブインターフェイスを

持っており、ウェブアクセスできたほうが運用は楽

どう設計するか（案)

● データベースと同等のセキュリティレベルを持つ隔離されたセグメント中に構築する。

● そのセグメントの中へウェブアクセスできるような仕組みを作る。

– セグメント中にRDP端末を用意しそのRDP端末へのログインを制限する or

– 認証機能を持つプロキシサーバを設置する

● ユーザには、必要なHadoopクライアントのインターフェイスを公開し、そこを通してHadoopを使ってもらうようにする。

Hadoopの運用

ハードウェア障害時

● SlaveNodeのハードディスク障害時の対応。– ハードディスクが故障するとが自動的にクラスタから外れ、別の筐体に

データが複製される。– ハードディスクが故障してもすぐに直さず1週間ぐらい放っておいて、まと

めて修理させても問題はない。– 新たに投入した筐体内のデータはなくなる。– 偏りが生じた場合にはリバランス処理を行なう。

● SlaveNode障害時の対応

– ハードディスク障害と同じようにまとめて修理でOK。

● MasterNodeの障害対応– すみやかに直すべき。

なんらかのアラート発生時

● 管理ツール等からステータスを確認する– 原因がわかったら、その原因を修正する。

● パラメータチューニングとか● プログラムの修正とか● ハードウェアの増強とか

● MySQLの運用なんかと同じように、知識は必要。

Hadoopエコシステムを構成するソフトウェアの特徴

● ほとんどはJavaで書かれている

– Javaのお作法を知ってれば管理が楽● 起動オプションによるメモリ管理● XMLで記述された設定ファイル

● 各プログラムがウェブインターフェイスを持っている– ステータスやログをウェブから確認できる

どうやって勉強するか？

● 概要がわかったらいじってみれば良いかと。● 1つのサーバにすべてのプログラムを入れて動かして

みることも可能。

● Cloudera主催のHadoop管理者研修のハンズオン演習は、Hadoopエコシステムを構成する各プログラムを手で1つずつインストールしていく、という地味な演習。仕組みを理解するには一番わかりやすいかも。

Special Thanks

● Cloudera 川崎さん

– Hadoop管理者向けトレーニング↓では大変お世話になりました。

● http://www.cloudera.co.jp/university/courses/administrator-training.html

おしまい

（Appendix) Hadoopの名前の由来

The name my kid gave a stuffed yellow elephant. Short, relatively easy to spell and pronounce, meaningless, and not used elsewhere: those are my naming criteria. Kids are good at generating such. Googol is a kid's term.

私の子供が付けた黄色い象のぬいぐるみの名前から来てるよ。短くて、スペルと発音が簡単で、意味がなくて、他で使われてない、というのが命名の基準。子供はそういうの考えるのうまいよね。Googolも子供が作った言葉だし。

http://weblogs.java.net/blog/tomwhite/archive/2006/02/hadoop.html

（Appendix) GoogleではまだMapReduceを使ってる

2014/7に、Google Senior Fellow の Jeff Dean’s がこんなことを喋ってる。

Jeff also spent some time addressing how MapReduce, Bigtable, and other familiar technologies are being used at Google today.

For example, Jeff told us that more than 1 million MR jobs run at Google daily, although use of the native API was largely dropped in favor of FlumeJava (the inspiration for Apache Crunch) and other abstractions some time ago

使われる頻度は減っているようだが、レガシーな処理では相変わらず現役っぽい。1日に100万個のMapReduceのJobが走ってるとのこと。

http://blog.cloudera.com/blog/2014/07/jeff-deans-talk-at-cloudera/