Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Hadoopの概念と基本的知識
Similar to Hadoopの概念と基本的知識 (20)
More from Ken SASAKI
More from Ken SASAKI (20)
Hadoopの概念と基本的知識
- 3. わかりやすいHadoop
- 5. わかりにくいHadoop
- 6. Apache Hadoopは大規模データの分散処理を支えるJavaソフトウェアフレー ムワークであり、フリーソフトウェアとして配布されている。[2]Hadoopはアプリ ケーションが数千ノードおよびペタバイト級のデータを処理することを可能とし ている。HadoopはGoogleのMapReduceおよびGoogle File System(GFS)論 文に触発されたものである。 Apache Hadoop (wikipediaより) よくわからん！！！ 今回説明するのは、こっちね。
- 7. Hadoopがわかりにくい点 ● ソフトウェアフレームワーク？？、なにそれ？？ ● Googleと関係あるの？？ ● MapReduceって何？？ ● 用語やツールが沢山ありすぎる？？ ● Hadoopエコシステム？？地球にやさしい？ ● 具体的に何をするものなのかわからない
- 8. なぜ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資料から引用)
- 9. なぜ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
- 11. ＨＤＦＳ
- 12. HDFSの概要 ● GFS(Google File System)をベースにしている ● 膨大なデータ量を格納可能 ● シンプルなアーキテクチャ ● ライトワンス ● 低レイテンシーではない。（応答は遅い) ● データスループット指向。 ● データは標準で3重化。 ● データは128MB毎（以前のバージョンは64MB)に分割。分散配置される。(ブロックサイズ 大きめ) ● データの格納先(メタデータ)を保持するNameNodeはシングルポイント。（※シングルポイン トの問題を回避する方法は後で説明) ● HDFSクライアントを使ってアクセスする。 ● HTTP、FTP、Fuseなどからもアクセスできる（専用のHDFSクライアント経由)。
- 17. HDFSのトラフィックのポイント ● データ通信はNameNodeを経由しない。 ● 読み込み時のデータ通信はHDFS Clientと DataNodeの間の通信。 ● 書きこみ時の複製はDataNode間の通信 ● DataNode障害時は、DataNode間の通信。 NameNodeのトラフィックは ボトルネックにならない。 DataNodeを増やせばトラ フィック上限を増やせる
- 19. 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 コマンドでも同じことができます。
- 20. ＭａｐＲｅｄｕｃｅ
- 21. MapReduce処理のイメージ UNIX の wc コマンド wc -w <ファイル名> 単語の数を数える 超巨大なファイル ファイルを分割 分割されたファイル毎に単語の数を数える 集計 全体の単語の数がわかる 巨大なファイルのまま単語の数を数えるより高速 ※実際にMapReduce処理のサンプルとして使われるWord Count とは違うことに注意。
- 23. MapReduceのバージョン ● MapReduceには、Version 1と2がある。 ● Version2では、YARNというリソースマネジメントの 仕組みが加わった。 MapReduce V1 MapReduce V2 YARN
- 24. MapReduce V1のシステム構成 TaskTracker DataNode TaskTracker DataNode TaskTracker DataNode TaskTracker DataNode NameNodeJobTracker クライアント 1筐体上で DataNode と TaskTracker が動く
- 25. MapReduce V1 の動作 TaskTracker DataNode TaskTracker DataNode TaskTracker DataNode TaskTracker DataNode NameNodeJobTracker クライアント 1.タスク依頼 2.MAP 3.Reduce 元データ、中間データ、最終データは、すべてHDFS上に置かれる
- 26. YARN+MapReduce V2のシステム構成 NodeManager DataNode NameNode Resource Manager クライアント 1筐体上で DataNode と NodeManager が動く Job Trackerの代わりにResource Managerを使う 履歴を管理するための Job History Server が追加 NodeManager DataNode NodeManager DataNode NodeManager DataNodeJob History Server
- 27. NodeManagerの機能 ● Mapタスク、Reduceタスクを実行するコンテナとし て動作する ● Application Masterとして機能する
- 28. YARN+MapReduce V2の動作 1 NodeManager DataNode NameNode Resource Manager クライアント Jobを投入されたNodeManagerは、Application Masterになる Application MasterはResource Managerにリソースを要求し 割り当てられたリソースにMAPタスクを投入する NodeManager DataNode NodeManager DataNode NodeManager DataNodeJob History Server 1.タスク依頼 2.Job投入 Application Master3.リソース要求 4.MAP
- 29. YARN+MapReduce V2の動作 2 NodeManager DataNode NameNode Resource Manager クライアント Application MasterはResource Managerにリソースを要求し 割り当てられたリソースにReduceタスクを投入する 処理完了後履歴を記録する 元データ、中間データ、最終データは、すべてHDFS上に置かれる NodeManager DataNode NodeManager DataNode NodeManager DataNodeJob History Server Application Master5.リソース要求 6.Reduce 7.履歴記録
- 30. なんか複雑に なってきたぞ。。。
- 31. シングルポイントはなんとかしたい NameNodeを冗長化 DataNode DataNode DataNode DataNode Zookeeper Zookeeper Zookeeper JournalNode JournalNode JournalNode NameNode Quorum Journal Manager Zookeeper Failover Controller NameNode Quorum Journal Manager Zookeeper Failover Controller
- 33. Hadoopエコシステム ● Hadoopの関連ツール – データ投入: Sqoop、Flume – データ処理: Spark – データ分析: Hive、Pig、Impala – データ探索: Solr – 機械学習: Mahout、Oryx – ユーザインターフェイス: Hue – ワークフロー管理: Oozie – クラスタ管理: Cloudera Manager等 Hadoopはこういうプログラム経由で利用される
- 35. (参考)Googleは今はMapReduceを使っていない ● 「Google I/O 2014」（2014年6月25日）で、 「Google Cloud Dataflow」を発表 ● 基調講演で「Google社内でMapReduceをほとんど 使っていない」と語る ● Googleは並列パイプライン処理技術である 「FlumeJava」や大規模ストリーム処理技術である 「MillWheel」など新しい技術を次々と開発している。 ※その1ヶ月後、やっぱりMapReduceも使ってるよ、と別の人が言ってるけどね →Appendix参照
- 36. Hadoopも進化している ● Hadoop 2 リリース(2013年10月) – MapReduce以外の処理にも対応 – DAGエンジンを使うことで100倍高速化も実現 – SparkはDAGエンジンの1つ ● HDFSの性能向上、別のファイルシステムへの移行 – HDFSのAPI、MapReduceのAPIを維持できれば内部構造 は柔軟に変更できる。 – HDFS以外のファイルシステムも、HDFS、MapReduceの APIを実装してきている。
- 38. Hadoopのディストリビューション 沢山ある。 これらを使えば楽にインストールと管理が可能。 ● Cloudera CDH ● MapR ● Hortonworks HDP ● Pivotal ● IBM Biginsights ● Microsoft HDinsight 笑っちゃうぐらい便利！！
- 40. どんなシステム開発でも共通のこと ● このへんはちゃんと決めておく（仮説でもOK) – システムのオーナー – 目的 – 体制 – 運用プラン – システムの寿命 – KPI – コスト これがはっきりしてないシステム開発は要注意！！
- 42. それ自前Hadoopでいいの？ ● 自前でHadoopを構築する以外にも選択肢はある。 ● Amazon Redshift 等も有力。 ● ログ解析だったら、Fluentd+Riakを使うとか。 ● Treasure Data のような便利なASPもある。 Hadoop以外の技術を使う、自前でやらない、 という選択肢も捨てるべきではない。 それでも自前でやるメリットはあるぞ。
- 43. ハードウェア選定等
- 45. SlaveNodeの推奨ハードウェア ● 筐体は2Uのサーバ等、ハードディスクが沢山載るもの。R720と か。 ● メモリは多め。 ● ハードディスクはRAIDを組まない。 – OS部分はRAID1とかのほうが良いかも。 – OSはSDカードから起動してハードディスクは全部データ領域とかも。 ● ネットワークは最低1G、できれば10G。 ● CPUは動かすプログラムによるが6コア程度でOK。 ● コストパフォーマンスが良い筐体を選ぶ。
- 46. SlaveNodeの非推奨事項 ● 仮想サーバはできればNG。共有リソースがボトル ネックになる可能性がある。 ● ブレードサーバもNG。共有部分がボトルネックにな る可能性がある。 ● RAID構成もNG。遅くなる可能性がある。
- 48. その他注意点 ● ハードディスクはLVM等も使わず素の状態で1台ず つmountする ● Java は Oracle Java を使う。 ● Chef等の構成管理、自動化ツールは必需品 ● IPv6は無効化する!!!
- 50. セキュリティに関しての考慮事項 ● Hadoopの各システム間は通信できる必要がある。 ● Hadoopのセキュリティ機能はあてにできない。 ● データの中には大事なものが含まれる、と考える。 ● MySQL等のデータベースと同じぐらい大事。 ● アクセスできる人をネットワーク的に制限すべき。 ● Hadoopの各システムはウェブインターフェイスを 持っており、ウェブアクセスできたほうが運用は楽
- 51. どう設計するか（案) ● データベースと同等のセキュリティレベルを持つ隔離され たセグメント中に構築する。 ● そのセグメントの中へウェブアクセスできるような仕組みを 作る。 – セグメント中にRDP端末を用意しそのRDP端末へのログインを 制限する or – 認証機能を持つプロキシサーバを設置する ● ユーザには、必要なHadoopクライアントのインターフェイス を公開し、そこを通してHadoopを使ってもらうようにする。
- 52. Hadoopの運用
- 53. ハードウェア障害時 ● SlaveNodeのハードディスク障害時の対応。 – ハードディスクが故障するとが自動的にクラスタから外れ、別の筐体に データが複製される。 – ハードディスクが故障してもすぐに直さず1週間ぐらい放っておいて、まと めて修理させても問題はない。 – 新たに投入した筐体内のデータはなくなる。 – 偏りが生じた場合にはリバランス処理を行なう。 ● SlaveNode障害時の対応 – ハードディスク障害と同じようにまとめて修理でOK。 ● MasterNodeの障害対応 – すみやかに直すべき。
- 55. Hadoopエコシステムを構成する ソフトウェアの特徴 ● ほとんどはJavaで書かれている – Javaのお作法を知ってれば管理が楽 ● 起動オプションによるメモリ管理 ● XMLで記述された設定ファイル ● 各プログラムがウェブインターフェイスを持っている – ステータスやログをウェブから確認できる
- 57. Special Thanks ● Cloudera 川崎さん – Hadoop管理者向けトレーニング↓では大変お世話に なりました。 ● http://www.cloudera.co.jp/university/courses/administrator -training.html
- 58. おしまい
- 59. （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
- 60. （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/