Hadoop Hack Night Vol. 2

  • 5,513 views
Uploaded on

新たな情報インフラとしてのHadoopの活用

新たな情報インフラとしてのHadoopの活用

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
5,513
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
123
Comments
0
Likes
17

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 技術評論社/ヤフー 共催 Hadoop Hack Night Vol. 2 2010年8月4日 新たな情報インフラとしての Hadoopの活用 株式会社リッテル 上席研究員 清田 陽司 (兼 東京大学情報基盤センター 学術情報研究部門 助教) Twitter: @kiyota_yoji
  • 2. Hadoop活用の壁 • 実績がまだまだ少ない • ○○という機能がない • ファイルシステムとして備えるべき機能(アクセス権制 御など) • マスタサーバの多重化 • Hadoopってよくわからないんだけど • RDBMSとの違いは? • どういう処理でメリットがあるの? • Hadoopってクラウドなの?(←そもそもクラウドって何 よ?)
  • 3. Agenda • Hadoopをインフラとして理解する • Hadoopの使いどころ – RDBMS、分散KVSとの使い分け • 開発事例紹介 – Hadoopが効果を発揮する用途 – 開発手法
  • 4. Hadoopを理解するポイント インフラとして理解する • シンプルなインタフェース+複雑な中身 – ブラックボックスとしてとらえる • なくてはならない存在 – なぜ必要とされているかを理解する • 現実的な「割り切り」 – ○○という機能がない理由を理解する
  • 5. ひねる 蛇口 水が出る 課金 請求書 水を捨てる 流し
  • 6. ひねる 蛇口 メータ 水道管 配水施設 浄水施設 取水施設 水が出る 水漏れの 水圧の 水質の管理 水位の管理 防止 コントロール 河川 水利権の調整 料金集計 メータ 渇水への対処 ダム 課金 請求書 システム 検針 発電・治水との 調整など マン 水を捨てる 流し ホール 下水管 沈砂池 沈殿池 消毒施設 詰まりの防止 除砂 水質の管理 メンテナンス 汚泥処理 河川 インタフェース 中身
  • 7. Hadoopのインタフェースと中身 データブロックの送受信 Hadoopスレーブサーバ#1 NameNodeへの状態通知 HDFSの全体統括 DataNode HDFS ファイルの データブロックの管理 デーモン ストレージ 書き込み 異常発生時の復元処理 子JVM TaskTracker map/reduce ファイルの Mapタスク/Reduceタスクの起動 HDFS デーモン 子JVM 読み込み JobTrackerへの状態通知 API map/reduce ファイルの 管理 Hadoop Hadoopスレーブサーバ#2 (複製、移動、 マスタサーバ DataNode HDFS NameNode デーモン ストレージ 削除、…) デーモン 子JVM TaskTracker map/reduce JobTracker バッチ処理 デーモン 子JVM デーモン map/reduce ジョブの投入 ・・ バッチ処理 ・ ジョブの Map Reduce Hadoopスレーブサーバ#N 状態取得 API DataNode HDFS バッチ処理 デーモン ストレージ ジョブの 子JVM 管理 バッチ処理ジョブの進行状況管理 map/reduce TaskTracker (キャンセル、 Mapタスク/Reduceタスクの割り振り デーモン 子JVM 異常発生時のバックアップタスク実行指示 優先度 map/reduce 設定、…) インタフェース 中身
  • 8. ブラックボックスとしてとらえる • インタフェースはシンプル – ファイルシステム系(HDFS) – ジョブ管理系(MapReduce) • 中身はイメージで理解する&伝える – ファイルシステム系とジョブ管理系が複雑にから みあっている • お互いが連携していることがHadoopの価値 – 1台のマスタサーバ+多数台のスレーブサーバ
  • 9. なぜ必要とされているか • 定型処理 → 非定型処理 への流れ – 処理すべきデータ量の増大 – スケール・アウトが必然 • 存在の「空気」化 – 水道や電気を使っていることを普段から意識して いる人はいない
  • 10. ○○という機能がない?! • アクセス権制御が不十分 • ファイル追記ができない • マスタサーバが二重化されていない – SecondaryNameNodeについての誤解 ファイルシステム/バッチ処理システムとして備 えるべき機能という観点ではまだまだ不足
  • 11. インフラとしての「割り切り」 • 既存のインフラとは目的が異なる – 大量データバッチ処理の高速化に特化した構成 – 組織内システム(インハウス)での利用を想定 • 優先順位が低い機能は潔くあきらめている • 既存のインフラの役割を完全に置き換えるも のではない – 高速道路は一般道路を代替できない
  • 12. Hadoopの使いどころ • Hadoopは何ができて、何ができないのか? • RDBMSとの使い分けは?
  • 13. 情報インフラとしてのRDBMS • ブラックボックス化 – あらゆるデータ操作をSQLで標準化 • トランザクション処理 – 複数ユーザによる読み書きが発生する環境で データの矛盾発生を防ぐ cf. 銀行口座間の資金移動 • インデックス – 指定されたデータを一瞬で検索
  • 14. RDBMSの課題 • データ処理のニーズの変化 – 定型処理から非定型処理へ • スケールアウトしづらい – CAP定理
  • 15. 定型処理と非定型処理 • 定型処理 – 給与計算、売上集計、伝票処理など – 人間が介在しない完全な自動化が可能 – 厳密さが求められる – データ量はせいぜいGbytesオーダー • 非定型処理 – 統計データ作成、検索、データ・マイニングなど – 人間の介在が必要 – 厳密さよりカバレッジ重視 (データ量が重要) – データ量はTbytes~Pbytesオーダーになり得る
  • 16. ブリュワーのCAP定理 Eric Brewer@UCBが2000年に提唱 以下の3つのシステム要件を同時に満たすのが 不可能であることを証明 • C: Consistency (一貫性) → トランザクション • A: Availability (可用性) → 耐障害性 • P: Partition Tolerance (分割耐性) → スケール・ アウト性 RDBMS: CAを満たすがPを満たさない Hadoop, 分散KVS: APを満たすがCを満たさない
  • 17. リアルタイム処理要求 応答 ユーザインタフェース アプリケーションサーバ(リアルタイム処理) RDBMS ログファイル 分散KVS 分散ファイル・システム(HDFS) スレーブ・サーバーのハードディスクを束ねて構成 外部入力ファイル 外部出力ファイル Hadoopクラスタ(バッチ処理)
  • 18. Hadoopが効果を発揮する用途例 • 検索インデックスの生成 • 大量のテキストデータの継続的解析 – ブログからの急上昇ワード抽出 • 時空間上のバスケット解析 – Webアクセスログを用いたマイニング – 地図情報マイニング
  • 19. ブログからの急上昇ワード抽出 • クローリングしたブログを1時間ごとに解析し、 急上昇ワードを抽出 • 変化率を計算するため、莫大なデータを毎時 処理する必要がある • Hadoopクラスタ規模 – DataNode 3台 (QuadCore CPU) • 数十Gbytesのデータを20分ほどで解析
  • 20. Trend Navigator
  • 21. 時空間上のバスケット分析 (例) あるキーワードで検索してから10分以内に 訪れたURLを抽出 キーワード ページ 検索 訪問
  • 22. 時空間上のバスケット分析 (例2) A社のコンビニから半径500m以内にある 他社のコンビニを全て抽出 (例3) 都内で開催されたコンサート会場近辺で 携帯からサイトにアクセスした顧客を抽出 RDBMSでは処理が難しい → MapReduceで効率的に処理可能!
  • 23. 処理ロジックの実装 • MapReduceの直接実装 – 習熟するまでが大変 – コスト高 – 自由度が大きい • HiveやPig Latinなどのメタ言語利用 – 習熟は楽 – コスト安 – 自由度が小さい
  • 24. まとめ • Hadoopのメリットの伝え方 – 新しいインフラなのでわかりにくくて当然! – 詳しい仕組みよりも、具体的な利用方法を • できることとできないことをきちんと区別する – 他のソリューションで十分なケースもたくさんある – 既存手法と組み合わせることで問題解決可能 • DRBD+Heartbeatによるマスタサーバの多重化 • 埋もれているニーズはまだたくさんある