Hadoopの概念&基本的知識

Hadoopの 概念＆基本的知識 2015/1/6 DMM.comラボ勉強会資料

今回の勉強会の目標 1.Hadoopがどんなものかなんとなく理解する 2.Hadoopシステムをどう作れば良いか学ぶ 3.Hadoopとどう付き合うか考える 全部で60ページあるので、飛ばし気味でいきます。

わかりやすいHadoop

＋パンチ HADOO Punch

わかりにくいHadoop

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

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-so sp2003.pdf http://static.googleusercontent.com/media/research.google.com/ja//archive/mapred uce-osdi04.pdf

• 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は1台 注意！！！ Secondary NameNodeは バックアップではない。 編集ログを元にメタ データを再構成するた めのもの。 DataNode DataNode DataNode DataNode DataNode DataNode ※古典的じゃないのは後で説明する Secondary NameNode DataNode DataNode DataNode DataNode DataNode 〜 〜 実データを格納する DataNodeは沢山 NameNode DataNode

HDFSへのアクセス(READ) 1:格納先問い合わせ HDFS Client NameNode 2:格納先を返答 DataNode DataNode DataNode DataNode 3:データ取得依頼 DataNode DataNode DataNode DataNode DataNode DataNode 〜 〜 4:データ転送 DataNode DataNode

HDFSへのアクセス(Write) 1:格納先問い合わせ NameNode ラック配置等を考慮 して格納先を決める 2:格納先を返答 HDFS Client DataNode DataNode 3:データ投入 DataNode 4:書きこみ成功 DataNode DataNode DataNode DataNode DataNode DataNode 〜 〜 DataNode DataNode DataNode 5:DataNode間 での複製 標準だと3重化

DataNodeでの障害 1:ハートビートおよびチェックサム による障害検知 NameNode DataNode DataNode 欠損したブロックが保持してい たデータを、他のDataNodeから 複製することで、3重化を保つよ うにする。 DataNode DataNode DataNode DataNode DataNode DataNode DataNode DataNode 〜 〜 DataNode 2:格納位置を再設定、 データ複製指令 DataNode 3:データ複製

HDFSのトラフィックのポイント ● ● データ通信はNameNodeを経由しない。 読み込み時のデータ通信はHDFS Clientと DataNodeの間の通信。 ● 書きこみ時の複製はDataNode間の通信 ● DataNode障害時は、DataNode間の通信。 NameNodeのトラフィックは ボトルネックにならない。 DataNodeを増やせばトラ フィック上限を増やせる

NameNodeでの障害 1:格納場所問い合わせ NameNode HDFS Client DataNode DataNode シングルポイント。 アクセス不能になってしまう。 DataNode中のデータは無事。 DataNode DataNode DataNode DataNode DataNode DataNode DataNode 〜 〜 メタデータがバックアップしてあ れば、NameNodeを作り直して 復旧できる DataNode DataNode DataNode

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のシステム構成 クライアント JobTracker TaskTracker DataNode TaskTracker DataNode TaskTracker DataNode TaskTracker DataNode 1筐体上で DataNode と TaskTracker が動く NameNode

MapReduce V1 の動作 クライアント TaskTracker DataNode TaskTracker DataNode TaskTracker DataNode TaskTracker DataNode 2.MAP 1.タスク依頼 JobTracker 3.Reduce 元データ、中間データ、最終データは、すべてHDFS上に置かれる NameNode

YARN+MapReduce V2のシステム構成 クライアント NodeManager DataNode NodeManager DataNode Resource Manager NodeManager DataNode Job History Server NodeManager DataNode 1筐体上で DataNode と NodeManager が動く Job Trackerの代わりにResource Managerを使う 履歴を管理するための Job History Server が追加 NameNode

NodeManagerの機能 ● ● Mapタスク、Reduceタスクを実行するコンテナとし て動作する Application Masterとして機能する

YARN+MapReduce V2の動作 1 クライアント 4.MAP 1.タスク依頼 Resource Manager DataNode NodeManager DataNode 2.Job投入 3.リソース要求 Job History Server NodeManager NodeManager DataNode Application Master NodeManager NameNode DataNode Jobを投入されたNodeManagerは、Application Masterになる Application MasterはResource Managerにリソースを要求し 割り当てられたリソースにMAPタスクを投入する

YARN+MapReduce V2の動作 2 クライアント 6.Reduce Resource Manager 5.リソース要求 Job History 7.履歴記録 Server NodeManager DataNode NodeManager DataNode NodeManager DataNode Application Master NodeManager NameNode DataNode Application MasterはResource Managerにリソースを要求し 割り当てられたリソースにReduceタスクを投入する 処理完了後履歴を記録する 元データ、中間データ、最終データは、すべてHDFS上に置かれる

なんか複雑に なってきたぞ。。。

シングルポイントはなんとかしたい NameNodeを冗長化 Zookeeper Zookeeper Failover Controller Zookeeper Zookeeper JournalNode Zookeeper Failover Controller JournalNode NameNode JournalNode Quorum Journal Manager DataNode NameNode Quorum Journal Manager DataNode DataNode DataNode

冗長性確保のために こんなに複雑に。。。 シンプルさはどこへ。。。

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のハードディスク障害時の対応。 – – – – ● SlaveNode障害時の対応 – ● ハードディスクが故障するとが自動的にクラスタから外れ、別の筐体に データが複製される。 ハードディスクが故障してもすぐに直さず1週間ぐらい放っておいて、まと めて修理させても問題はない。 新たに投入した筐体内のデータはなくなる。 偏りが生じた場合にはリバランス処理を行なう。 ハードディスク障害と同じようにまとめて修理で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

• 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/hado op.html

• 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 使われる頻度は減っているようだが、レガシーな処理では相変わらず現役っぽい。 http://blog.cloudera.com/blog/2014/07/jeff-deans-talk-at-cloudera/

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