Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

hadoopレポート by Mind Map: hadoopレポート
0.0 stars - reviews range from 0 to 5

hadoopレポート

背景

様々なデータの集中・蓄積。どう使うか

クラウドの発展。分散基盤

ヘテロな環境, メンテナンスによる交換, 搬入時期の違いによる

MapReduce

Map

Mapでデータを分割、分散させて処理

依存のない処理を実行

リソース消費, HDFS上データの読み出し, Map処理, Map処理結果をローカルディスクへ書き出し

Shuffle

Mapの結果を定義した条件で振り分ける

振り分けたデータをKeyでソートする

リソース消費, Map処理結果の中間ファイルを取得, 中間ファイルの結合, 結合後Keyでソート

Reduce

Mapの処理結果から同じキーを持つデータを同じサーバにて集計

依存関係が生まれるところ

Keyで配置するため、データに偏りが出る可能性

リソース消費, Reduce処理, Reduce処理結果をHDFSへ書き出し

入力データの決定

Key-Value

中間データ(MapとReduce処理の間), Reducdeでまとめる単位をKeyに, 大事

設計技法

処理のフローを分割, データフローを考える, どの処理で、どの情報が欲しいか, Map, Reduce, 中間データ

アプリケーションボトルネックの把握, 最も時間のかかる処理を見つける, 逐次処理によるシミュレーション, 時間のかかる処理(Map or Reduce)を分割, JVMヒープサイズを超えないように, シミュレーション・エミュレーション, 少量データを対象として見積もる, シミュ/エミュレータ, Numak, Gridmix3

不得意な処理

MapReduce処理が再帰的に繰り返される

前後の処理に依存するKeyを使う処理

分散ファイルシステム

HDFS

NameNode, ファイルのメタデータを管理

DataNode, データブロックを管理, 複数のノードでレプリカを保持, Rack Awareness

商用への期待

業務への適用性

スケールアウトする中で、求めるべき問題が解けるのか, 処理時間を台数でコントロールできるか

信頼性

一部は冗長構成を持たない, 冗長化させる

信頼性確保のための方針

運用性

監視, スケーラブルであること

自動設定, サーバの種類に応じた設定

基盤

環境制約

実メモリ容量制約, ジョブ毎にヒープメモリ容量を決定可能, 統一された容量。混在環境は考慮されない, メモリ容量越えはスワップの原因に繋がる

ディスク容量制約, 不足は失敗につながる, RAID-0で対応

考慮点

ネットワークコスト, 特にShuffle、ReduceのHDFS書き込み処理に負荷増大(特にShuffle)

Map Reduce同時処理数

ディスクI/Oの分散

可用性

ファイルシステムに分散されたデータ, 複数のデータレプリカ, レプリカ数の調整, 単一のメタデータ, 複数のファイルシステムに保管, SecoundaryNameNode, あくまでバックアップ, 差分保管, 障害は処理継続不可能を意味する, 冗長構成による保護, 切り替え後、一定時間safemodeになり切り替えオーバヘッドあり, 同期処理による保護, 切り替えが透過, kemari, StandbyNodeの評価, 記載なし。(紹介まで)

MapReduceで分散された処理, JobTrackerが管理, 冗長化による保護, 新規ジョブは守れるが、実行中ジョブは失敗, ジョブの再実行が必要, 同期処理による保護, 切り替えが透過, kemari, TaskTrackerが処理, 故障時の別Trackerによるフォロー, Mapの障害, Reduceの障害, 処理時間遅延, ジョブを複数回失敗するとブラックリスト入り

スレーブサーバの可用性はコストバランス比較で

ネットワーク, ラック間スイッチの障害, ラック下のすべてのスレーブサーバを失う, マスタサーバ、スレーブサーバ間のスイッチ障害, 困る, 冗長化必須

運用

特徴, 対象ノードが多い, クラスタの構成が動的に変更されることを前提に設計されている

注目点, 異なる機器が混在することを考慮, スケーラビリティ, 運用コスト, 時間的コストを基準とする観点, 運用コストの別の観点, 価格?, システム規模・構成に依存しない, 共通化, 構成の動的な変更を受け入れられる運用

方式, 構築, 完全自動化, 作業時間削減(, 作業ミス、手戻りなし, Kickstart + Puppet, サーバの決め方, Macアドレスは基準にしない, ホスト名を自動で生成しDNSに追加, 物理配置を考慮, NWSwitchポート名を基準, NWSwitchにログインしMacアドレスとI/Fの対応表を取得, スイッチのポートを意識したラッキング, 監視・障害検知, Web画面による監視, Ganglia, ジョブの実行状態の可視化, JobTracker WebUI, 設定管理, Puppet, Facterを拡張(異なるシステム構成に対応可能にする), 回復・増設, HDFSリバランス

評価・検証

アプリ実装評価

利用者が求める処理時間・処理精度の要件を満たせるか, 決められた時間内で処理を完了, 処理時間と精度のバランス, 情報の粒度のコントロール

渋滞解析, データの種類, 様々な場所から集められる, 計測ポイントの連続性, 連続性が入れ替わる場合もある、入れ替える, 解析, 短期間の情報から現状を分析し表現する, 計測ポイントの移動速度から渋滞具合を予測, 集計キーを作成, 対象日時、季節など、それぞれに対し道ID,速度,方向,, 長期間の情報から統計

基盤評価

運用スケーラビリティ, 100台までのスケールを検証, 障害発生からの増設、その際の運用負荷を作業時間を軸に検証, 自動化、Web画面集約で作業者人数、時間を削減

シナリオ実験

運用しながらどう戦えばいいか

処理時間・精度, 3段階のレベルアップを想定, 小規模⇒中規模⇒大規模, 中規模と大規模の違いは情報精度

データ量, ディスク容量不足に注意, HDFS領域以外にMapの結果を格納する領域を用意する, アプリケーションデータ, TaskTracker起動時に同期しておくなど

時間の見積もり, 少量データによるパラメータの決定(精度), 大規模データによる処理時間の見積もり

障害テスト, タスクの障害は、別のスレーブサーバで担保される, スレーブサーバの障害, 別スレーブサーバでのジョブ実行, 障害のスレーブサーバが保持していたデータのレプリカ, I/O負荷増大に注意, ラック障害, ラック内スレーブの保持するジョブ、データが別ラックに移される, 増設, 増設したスレーブサーバはすぐに処理可能なスレーブサーバとして利用(CPU負荷軽減)

今後の課題

データセンター間をまたぐ場合も考えられる

リモートからの運用作業を想定

データの収集(センサー)からクラウドへ格納するところまでにフォーカス

複数アプリケーションの実行, ジョブのスケジューリング