• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Hadoopによる大規模分散データ処理
 

Hadoopによる大規模分散データ処理

on

  • 8,266 views

産業技術大学院大学 InfoTalk 第16回

産業技術大学院大学 InfoTalk 第16回
2010年3月19日
http://pk.aiit.ac.jp/index.php?InfoTalk

Statistics

Views

Total Views
8,266
Views on SlideShare
8,080
Embed Views
186

Actions

Likes
7
Downloads
176
Comments
0

5 Embeds 186

http://www.slideshare.net 87
http://www.itg.hitachi.co.jp 62
http://pk.aiit.ac.jp 34
http://webcache.googleusercontent.com 2
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Hadoopによる大規模分散データ処理 Hadoopによる大規模分散データ処理 Presentation Transcript

    • 2010年3月19日 第16回InfoTalk@産業技術大学院大学 Hadoopによる 大規模分散データ処理 東京大学情報基盤センター 学術情報研究部門 助教 清田陽司 (兼 株式会社リッテル 上席研究員) Twitter: @kiyota_yoji 1
    • Agenda • Hadoop登場の背景 • Hadoopのしくみ – MapReduce – 分散ファイルシステムHDFS • Hadoopで何ができる? – 活用事例紹介 • RDBMSとの違い 2
    • 情報爆発 • 世界中に流通している情報量は爆発的に増大 • IDCのレポート (2008) – デジタル化されたデータ量 2006年 180Ebytes (1800億Gbytes) 2011年 1.8Zbytes (1兆8000億Gbytes) – 5年間に10倍のペースで増加 • 情報オーバーロード問題 – 必要な情報が埋もれてしまう – 必要な技術を特定する技術が必要! 3
    • 学術研究における コンピュータの活用 • 莫大なデータが入手可能になった – Web: ブログ、ニュース、画像、動画、… – 時系列: アクセスログ、ライフログ、株価、… – 自然現象: 気象、地震、宇宙、… • 莫大なデータを対象とすること自体に価値 – Webを対象とした研究では、膨大なデータを保有する 企業との連携がほぼ必須? • 莫大なリソースが必要 – サーバ、ディスク、メモリ、ネットワーク、設置スペース、 電力、管理の手間 4
    • スケールアップとスケールアウト 1台のコンピュータ の性能 性能を上げようとすると コストが飛躍的に 増大してしまう この領域をうまく 使いたい コスト 5
    • スケールアウトの課題 データをたくさんの台数のコンピュータで分散処 理するのは難しい • 故障の確率が上がる – 1台の故障率 1%/1年 => 1000台の故障率は?! – どこか故障しても計算を続けたい • 有限のリソースの効率的な配分 – プロセッサ時間、メモリ、ハードディスク空き容量、 ネットワーク帯域 • データの同期 – プログラミングがめちゃくちゃ大変 6
    • ハードディスク読み書き速度の壁 • 市販のハードディスク(ATA規格)のスペック – 容量: 2TBytes (cf. 5年前 300GBytes) – 転送速度: 110MBytes/秒 (cf. 5年前 50MBytes/秒) – 全部の読み出し: 5時間 (cf. 5年前 1時間40分) → 読み書き速度がボトルネックに! • 解決策: 多数のハードディスクに分散読み書き – 2TBytes HDDを積んだPC 1000台 → 2TBytesの読み出しに20秒! 7
    • 分散読み書きの課題 • ハードディスクの障害 – データのミラーリングやRAIDなどの障害対策 • 障害対策のコスト – 大規模なRAIDは高くつく • 障害対策自体がボトルネックになる – RAIDコントローラーが制約要因 • 処理結果の結合 – 別々のディスクにあるデータ同士を結びつけるの は難しい 8
    • Googleによる解決策 Google File System論文、MapReduce論文 • 冗長化 – どこか壊れることを前提とした構成 • 汎用ハードウェアの利用 – 市場のスケールメリットを最大限に生かす • 分散ファイルシステム – 複数台のマシンが協調してファイルを管理 • 分散処理のための専用フレームワーク – MapReduceアルゴリズム 9
    • Hadoopの登場 • Nutch(オープンソースWeb検索エンジン)の開発 者がGoogle論文のアイディアをJavaで再実装 • Hadoop開発の目的 – Nutchが直面していたスケールアウト問題の解決 – さまざまなデータに応用できる「汎用性」の実現 → 多くの開発者を巻き込み、プロジェクトが急激に成 長 • 現在は多くの企業が自社サービスに活用 – 特に米Yahoo!とFacebookは多数の開発者が参加 – 10000台以上、ペタバイト規模のクラスタとして実用 10
    • Hadoopとは何か? A large-scale distributed batch processing infrastracture • Large-scale = Web規模のデータを扱える • 1TBytes(1兆バイト)~1PBytes(1000兆バイト) • Distributed = 分散型システム • Batch = バッチ処理専用 (高速な処理) • Infrastructure = インフラとしてのシステム • つまり意識せずに使える 11
    • Hadoopを支える2つの柱 • MapReduce – 互いに並列処理可能な形に処理を分解 →スケールアウトしやすい – 関数型言語の考え方を巨大データに適用 – map関数(=射影)とreduce関数(=畳み込み) • HDFS (Hadoop分散ファイルシステム) – 巨大なファイルブロック (MapReduceに最適化) – 同一のファイルブロックのコピーを複数のノードが 保持 12
    • Hadoopクラスタの構成 • マスタ – クラスタ全体の「親分」となる1台のPCサーバ – JobTracker (MapReduce担当)とNameNode (HDFS担 当)の2つのデーモンを動かす • スレーブ – クラスタの「子分」となる多数のPCサーバ – TaskTracker (MapReduce担当)とDataNode (HDFS担 当)の2つのデーモンを動かす ※クライアント – MapReduce、HDFSを利用する「お客さん」 – 必要に応じてマスタ・スレーブと通信 13
    • HDFSクライアントJVM Hadoopスレーブサーバ#1 HDFS DataNode HDFS API HDFSストレージ クライアント デーモン(JVM) 子JVM HDFS TaskTracker map/reduce クライアント デーモン(JVM) 子JVM HDFS SecondaryName Node デーモン Hadoopクラスタ map/reduce クライアント (JVM) Hadoopマスタサーバ Hadoopスレーブサーバ#2 HDFS メタ NameNode DataNode HDFSストレージ データ DB デーモン(JVM) デーモン(JVM) 子JVM HDFS map/reduce TaskTracker クライアント デーモン(JVM) 子JVM HDFS JobTracker map/reduce クライアント デーモン(JVM) ・・ ・ Hadoopスレーブサーバ#N MapReduceクライアントJVM DataNode HDFSストレージ デーモン(JVM) (6)入出力ファイルを HDFSで読み書き MapReduce 子JVM HDFS JobConf プログラム TaskTracker map/reduce クライアント デーモン(JVM) 子JVM HDFS (5)タスクを実行する map/reduce 14 クライアント 子JVMをfork起動
    • MapReduceとは? • データ処理を関数型言語の考え方で表現 – map関数(射影)とreduce関数(畳み込み) • ひとつの大きな処理(ジョブ)を細かな処理単 位(タスク)に分解 • 耐障害性: いずれかのスレーブが壊れても正 常に動き続ける • JobTrackerとTaskTrackerが連携して動作 – JobTracker: ジョブ全体の管理、タスクの割り当て – TaskTracker: タスクの処理 15
    • MapReduceのイメージ map reduce map map reduce map reduce map × 射影 畳み込み 16
    • MapReduceのデータモデル 東京タワー バナナ 放送塔 2 k key-valueペア v (k, v) 東京タワー みかん 観光名所 3 k key-valuesペア v1 東京タワー (k, list(v)) v1 放送塔 v1 観光名所 v1 17
    • MapReduceのデータの流れ key-valueペア key-valueペア key-valuesペア key-valueペア (k, v) (k’, v’) (k’, list(v’)) (k’’, v’’) 並行するmap関数、 reduce関数どうし はお互いに独立 B k1 3 map A ファイル v1 k’’1 C 2 reduce v’’1 ファイル 5 4 データ ベース データ k2 A ベース map Amazon v2 2 B S3 reduce φ Amazon 3 S3 MapReduce MapReduce の出力 k’’2 の入力 C C v’’2 ・・ ・・ k3 1 ・ map 1 reduce ・ v3 k’’3 A 5 4 v’’3 (1)mapフェーズ (2)shuffle & sort (3)reduceフェーズ 18 フェーズ
    • MapReduceの多段適用 (アクセスログ集計処理の例) k 110.0.146.55 - - [12/Jan/2010:06:00:10 +0900] v "GET /linux/ HTTP/1.0" 302 1102 110.0.240.244 - - k 5 /article/COLUMN/2006022 v [12/Jan/2010:06:19:29 +0900] 4/230573/ "GET /article/COLUMN/20060224/23 3 /linux/image/cover_small_ 0573/ HTTP/1.1" 200 82242 110.0.240.244 - - MapReduce k MapReduce 1002.jpg [12/Jan/2010:06:20:23 +0900] v 3 /linux/image/logo10.jpg "GET /article/COLUMN/20060224/23 (grep-search) (grep-sort) 2 0573/ HTTP/1.1" 200 82242 k /linux/image/cover_small_ 110.0.43.6 - - [12/Jan/2010:06:26:20 +0900] v 1002.jpg "GET /linux/ HTTP/1.1" 302 1102 110.0.43.6 - - ・・ [12/Jan/2010:06:26:20 +0900] (k, v) ・ (k, v) "GET /linux/image/cover_small_1002. = (null, アクセスログの1行) = (URL, アクセス頻度) k jpg HTTP/1.1" 304 0 (k’, v’) (k’, v’) = (URL, 1) v = (アクセス頻度, URL) (k’’, v’’) (k’’, v’’) (k, v) = (URL, アクセス頻度) = (null, 行の文字列) = (URL, アク セス頻度) map関数: map関数: URLを正規表現で抜き出す URLとアクセス頻度をひっくり返し、 reduce関数: keyをアクセス頻度にする URL毎の頻度をカウントする reduce関数: 行の文字列を生成する 19
    • MapReduceデモ 20
    • HDFSとは? • クラスタ全体でひとつの大きな仮想ファイルシ ステムを実現 • FATやe3fsと同様、ファイルとブロックの概念 – ブロックサイズが巨大 (64Mbytes~) • 耐障害性 – 同一ブロックが複数のスレーブに存在 – 障害発生時は自動的にブロックを複製 • NameNodeとDataNodeが連携して動作 21
    • HDFSのイメージ /file/X.txt NameNode /file/X.txt-0 64MB 64MB /file/X.txt-1 HDFSメタデータデータベース 64MB ファイル名 ブロック DataNode /file/X.txt-2 番号 /file/X.txt 0 A, D, F /file/Y.txt 1 B, D, E /file/Y.txt-0 64MB 2 A, C, F 64MB /file/Y.txt 0 B, D, E /file/Y.txt-1 1 A, C, E /file/X.txt-0 /file/X.txt-1 /file/X.txt-2 /file/X.txt-0 /file/X.txt-1 /file/X.txt-0 /file/X.txt-2 /file/Y.txt-0 /file/Y.txt-1 /file/X.txt-1 /file/Y.txt-0 /file/X.txt-2 /file/Y.txt-0 /file/Y.txt-1 /file/Y.txt-1 DataNode A DataNode B DataNode C DataNode D DataNode E DataNode F 22
    • HDFSのファイル読み込み (1)/file/Y.txt を (2)/file/Y.txt の各ブ (3) 全部読み込み ロックを持っている ブロック0 → B, D, E たい DataNodeを教えて NameNode ブロック1 → A, C, E にあるよ HDFSクライアントJVM HDFSメタデータデータベース ファイル名 ブロック DataNode HDFS 番号 HDFS API クライアント /file/X.txt 0 A, D, F (5)E君、/file/Y.txt の 1 B, D, E ブロック1ちょうだい 2 A, C, F /file/Y.txt 0 B, D, E (6)お待たせ! 1 A, C, E /file/Y.txt-0 (4)B君、/file/Y.txt の /file/Y.txt-1 ブロック0ちょうだい /file/X.txt-0 /file/X.txt-1 /file/X.txt-2 /file/X.txt-0 /file/X.txt-1 /file/X.txt-0 /file/X.txt-2 /file/Y.txt-0 /file/Y.txt-1 /file/X.txt-1 /file/Y.txt-0 /file/X.txt-2 /file/Y.txt-0 /file/Y.txt-1 /file/Y.txt-1 DataNode A DataNode B DataNode C DataNode D DataNode E DataNode F 23
    • HDFSのファイル書き込み (4)OK!それではまずB君に (3)B君, C君, F君は まだ空きがたくさん あるな。よし、 (1)/file/Y.txt に 書き込んでね。そのとき、C /file/Y.txtのブロック (2)/file/Y.txt に追加 君, F君にもコピーを渡すよ 2は彼らに割り当て 追加書き込みし 書き込みさせてよ たいんだけど NameNode うに伝言しておいて。終わっ たら教えてね よう HDFSメタデータデータベース HDFSクライアントJVM ファイル名 ブロック DataNode 番号 HDFS /file/X.txt 0 A, D, F HDFS API クライアント 1 B, D, E (6)B君、これを書き込んでお (12)終わったよ 2 A, C, F いて。 (5)これを書き込ん /file/Y.txt 0 B, D, E でね /file/Y.txt-2 1 A, C, E それから、C君、F君にもコ 2 B, C, F ピーを渡しておいて。終わっ (11)終わったよ たら教えてね /file/X.txt-1 /file/X.txt-2 /file/X.txt-0 /file/Y.txt-0 /file/Y.txt-1 (8)F君、これを書き込 /file/X.txt-2 んでおいて。 /file/Y.txt-2 /file/Y.txt-2 /file/Y.txt-2 /file/Y.txt-2 終わったら教えてね DataNode B DataNode C DataNode F (7)C君、これを書き込んで おいて。 /file/Y.txt-2 それから、F君にもコピーを (10)終わったよ (9)終わったよ 24 渡しておいて。終わったら 教えてね
    • DataNodeの障害時 NameNode (1)あれ、C君死んだ?! HDFSメタデータデータベース (2)C君が持っていた Live Nodes ブロックは ファイル名 ブロック 番号 DataNode A B C D E F /file/X.txt-2と /file/Y.txt-1だな。よ /file/X.txt 0 A, D, F し、空き容量が多い 1 B, D, E B君、F君にコピーし てもらおう 2 A, C, F, B Dead Nodes /file/Y.txt 0 B, D, E (3)A君、きみが持っている 1 A, C, E, F C /file/X.txt のブロック2をB君 (5)E君、きみが持っている にもコピーしておいてね /file/Y.txt のブロック1をF君 にもコピーしておいてね /file/X.txt-0 /file/X.txt-1 /file/X.txt-2 /file/X.txt-0 /file/X.txt-1 /file/X.txt-0 /file/X.txt-2 /file/Y.txt-0 /file/Y.txt-1 /file/X.txt-1 /file/Y.txt-0 /file/X.txt-2 /file/Y.txt-0 /file/Y.txt-1 /file/Y.txt-1 /file/Y.txt-1 /file/X.txt-2 DataNode A DataNode B DataNode C DataNode D DataNode E DataNode F (4)B君、これを書 (6)F君、これを書 き込んでおいてね き込んでおいてね 25 /file/X.txt-2 /file/Y.txt-1
    • MapReduceとの親和性 • mapタスクはブロック単位で作られる • 可能な限り各々のタスクはブロックが存在す るスレーブに割り振られる →通信コストが最小化される =スケールアウトしやすい 26
    • HDFSデモ 27
    • インフラとしてのHadoop • インフラとは? – 道路・鉄道・水道・電気・ガス・電話・インターネット… – さまざまなトラブルを解消するしくみを備えている – 非常に複雑なシステム、維持は大変! – 存在を意識せずに利用できる • Hadoop = 莫大データバッチ処理のインフラ – 耐障害性の確保に重点がおかれている – なかみは非常に複雑 – 利用者は意識しなくても使える 28
    • Hadoopで何ができる? • 莫大なデータのバッチ処理に威力を発揮 • SQLでは記述しにくい複雑な処理に向いている – 時系列処理 – 検索インデックス作成 – レコメンデーション – 画像処理 – DNAシーケンスマッチング – 言語モデル生成 (音声認識、機械翻訳、…) 29
    • リッテルでの活用事例 (1) • サーバ構成 – NameNode 2台 • Dual Core CPU (2.66GHz), 4GBytes RAM, 750GBytes HDD – DataNode 20台 • Dual Core CPU (2.4GHz), 4GBytes RAM, 1.5TBytes HDD • 総ストレージ量 15TBytes (冗長化) – 1TBあたり単価は16万円程度 • 大量のWebアクセスログのマイニングに利用 • ベンチマーク – 3億4000万レコード (63GBytes) の時系列処理 → 約12分で完了 30
    • 時系列処理の例 アクセスログより、google等で検索した直後にどのサイトを訪れているかを抽出 し、検索語と関連性の高いURLを取り出す ID URL access time 00001 www.yahoo.co.jp 2008-08-20 11:10 www.google.co.jp/?search=XXXXXXX 2008-08-20 11:11 www.dentsu.co.jp 2008-08-20 11:12 ・・・・・・・ ・・・・・・・・ この検索後を投入した人(ID)が、その直後、例えば5分以内に どのサイトを訪れているのか、URLの一覧を取得する N分間 時間 検 訪問したURL 索 検索語に非常に関連性の高いURLとして見なす 31
    • リッテルでの活用事例 (2) • クローリングしたブログを1時間ごとに解析し、 急上昇ワードを抽出 • 変化率を計算するため、莫大なデータを毎時 処理する必要がある • Hadoopクラスタ – DataNode 3台 (QuadCore CPU) • 数十Gbytesのデータを20分ほどで解析 32
    • Trend Navigator 33
    • 2009 sort benchmark • 巨大データのソート速度を競うコンテスト • 米Yahoo!のグループがHadoopで参加し、2部門 で優勝 • GraySort部門: 1分あたりのソートデータ量 – 0.578TBytes/min (100 TB in 173 minutes ) – 3452 nodes x (2 Quadcore Xeons, 8 GB memory, 4 SATA) • MinuteSort部門: 1分以内にソートできる最大 データ量 – 500 GB – 1406 nodes x (2 Quadcore Xeons, 8 GB memory, 4 SATA) 34
    • 分散RDBMSとの比較 Andrew Pavlo et al. A Comparison of Approaches to Large-Scale Data Analysis, In Proc. of SIGMOD 2009, pp. 165-178. • Hadoopと2種類の商用分散RDBMS (Verticaと 某製品)を比較 • データの搭載はHadoopが高速 • 特定のカラムを対象とした検索処理は分散 RDBMSが高速 • どちらを選択すべきかは用途に応じて決める べき 35
    • データ搭載所要時間の比較 (1TBytes) 36
    • 正規表現によるフィールド文字列の 検索 (1レコード90Bytes) 37
    • 分散RDBMSの限界 • 設定すべきパラメータがたくさん – セットアップは大変 – チューニングは困難 • どうインデキシングするかをあらかじめ決め ておく必要がある – 多様な分析の切り口を提供しづらい • 耐障害性の確保には高いコストがかかる • SQLでは記述が困難なロジックがマーケティン グ領域では必要とされる – 複雑なBoolean条件 – 時系列集計 (時間的な前後関係の考慮) 38
    • まとめ • Hadoopの特徴はマーケティング領域におけ るデータ解析ニーズにフィットする – データ搭載のスループットが重要 – 多面的な解析が必須 – 複雑なBoolean式や時系列集計などでもパフォー マンスを発揮できる • 低コストで耐障害性を確保できる – MapReduceの単純なプログラミングモデルの御 利益 • スケーラビリティの担保は生命線 – 性能が台数に比例しなければ早々に破綻 39