【17-E-3】Hadoop：黄色い象使いへの道～「Hadoop徹底入門」より～

Hadoop 黄色い象使いへの道
～Hadoop徹底入門より～

株式会社NTTデータ基盤システム事業本部
システム方式技術BU 課長代理
下垣徹

本日のアジェンダ

Hadoop概要
Hadoop適用事例
「Hadoop徹底入門」の読み方
黄色い象 (= Hadoop) 使いへの道
Hadoop利用時のよくある質問

Copyright © 2010 NTT DATA CORPORATION 1

Hadoopの概要


その前に・・・ Googleの基盤技術
Googleは独自の基盤技術を用いて、大規模データを対象としたサービスを展開
Googleは、自ら「クラウドコンピュータを持ってサービス展開している」という

Web検索ログ解析 Gmail Google Maps ・・・

プログラミング言語
Sawzall
分散処理フレームワークキー・バリュー型データストア
論文：
MapReduce BigTable The Google File
論文： System （2003年）
MapReduce:
Simplified Data 分散ファイルシステム
Processing on
Large Clusters Google File System （GFS）
（2004年）

独自に建造したデータセンタ

グーグルプラットフォーム

Hadoop とは？

オープンソースの大規模分散処理フレームワーク
Googleの基盤ソフトウェアのオープンソースのクローン
大きなデータを並列に読み、データのローカリティを活かしてデータ処理する
高いスケーラビリティにより、小さく始めて大きく活用できる
Bank of America、VISA、JP Morgan Chase & Co、GE （General Electric）、
AOL、CMCC(中国移動通信）、Baidu (百度)、国内テレコム事業者、
Yahoo! 、Facebook 、Twitter、eBay、楽天なども活用
ログ解析やレコメンデーションエンジン、検索エンジンなどでの活用が主流
今後は、DWH／BI領域での活用が進む

Yahoo! のHadoop環境がソート処理の世界記録を樹立
1TBのデータソートを62秒で実現 (2009年5月)

大きく2つのコンポーネントで構成される
分散ファイルシステム： HDFS （Hadoop Distributed File System）
大規模分散処理フレームワーク： Hadoop MapReduce Framework


Hadoop – クラスタの全体像

集中管理型の分散システム Hadoopマスタサーバ
分散処理ジョブやデータの管理は NameNode JobTracker
マスタサーバで実施
スレーブサーバは、分散処理の実
行やデータの実体を保存
スレーブサーバのクラスタへの
参加・離脱は自動的 L2/L3スイッチ
- 各ノードはマスターサーバに定期 Hadoopクライアント
的に通知する
L2スイッチ

HDFS
マスター： NamaNode
スレーブ： DataNode
MapReduce
マスター： JobTracker
スレーブ： TaskTracker
Hadoopスレーブサーバ (DataNode/TaskTracker)


分散ファイルシステムHDFSとMapReduceフレームワーク

低価格サーバの大量使用による故障の発生大規模分散処理向けフレームワーク
が前提の設計 Googleが検索インデックス作成のため考案
データの多重化で可用性を担保する少なくとも5000台までスケールアウトしても性能向上す
従来とは運用利便性の考え方が異なるることが知られている

Client HDFS MapReduce
NameNode
ブロックに分割して
ランダムに分散配置
MAP

SW SW SW

SHUFFLE
DataNodes

REDUCE

Rack
コピーをラックの内外に
多重作成して冗長化

Hadoopの特徴

個別設計する必要なく、分散処理を実現
従来、プログラムごとに分散処理方式を設計する必要があった
- データの配置や分散、分散処理の分割、各ノード間の通信 etc…
Hadoopでは、MapReduceフレームワークによって、プログラム個別に
分散処理ロジックを用意することなく、分散処理を気楽に利用できる
高いスケーラビリティ
サーバ台数を増やすことで、保存するデータサイズ、計算処理能力、
バッチ処理の I/O性能を柔軟に拡張できる
特にI/O性能は数台規模でも効果あり（上限の実績は～4000台）
コモディティサーバ利用を前提とした設計
IAサーバ＋Linuxなど容易に入手できるコモディティ品で構築できる
一部のサーバが故障しても、サービスの可用性に影響を及ぼさない
様々なデータに対応
どのようなデータでも格納できる
格納時ではなく利用時にデータを意味付ける


Hadoopの適用事例


Hadoopの適用領域

特に向いている領域
数10ギガバイト～テラバイト～ペタバイト級のデータを扱うシステム
バッチ処理的なアプリケーション
リアルタイム性が求められる処理の前処理

一般的な利用例
ログ解析 POSデータ解析、広告分析、トラヒック解析など
レコメンデーションクリック・ストリーム分析、関係グラフ解析など
検索転置インデックス作成、検索精度向上
データマイニング取引情報の分析・監査、不整データの抽出など
機械学習大量データのパターン分析、分類など
データ変換動画、テキスト、音楽
高度なETL

日本での利用事例も数多く報告されるようになってきた
2011/02/22 「Hadoop Conference Japan 2011」に注目！


Hadoopの適用事例

米Yahoo! 3年分のログの処理に26日→Hadoopで20分に短縮
現在82ペタバイトのデータを処理、全体で計25,000台のクラスタを有する
Facebook 4TBのデータが毎日新規に生成される/135TBのデータを毎日処理
Hadoopで処理したデータをOracle RACやMySQLに格納して利用しているものも
楽天広告のインプレッションログ解析、レコメンデーション、ランキング集計などで使用
Perlスクリプトによる処理からHadoopに移行 / 20台程度のクラスタ
VISA 過去2年間で730億ものトランザクション＝36TBのデータが生成
分析にこれまで1カ月かかっていたものが、Hadoopによって13分に
China Mobile 5億人のユーザのCDRデータを処理、5～8TB/日
商用のDB製品、DWH製品を利用していたがHadoopに移行
スケーラビリティの確保、ローコスト化・柔軟性の確保を実現
国立国会図書館国立国会図書館・公立図書館・大学図書館・等の蔵書を横断的に検索するシステム
異なるデータソースからの重複・関連したデータに対する書誌同定・グループ化をHadoop
で実施し、検索インデックスを作成
GE （Gereral Twitter・Facebook・ブログといったメディアからデータを蓄積し、顧客の感性分析を行う
Electric） MySQLで42時間かかっていた処理をHadoopを用いることで48分で完了
リクルート DWH(データウェアハウス)製品とHadoopを比較し、特性を評価
顧客動向分析のためにログなどを収集、分析するHadoopクラスタを構築中

「Hadoop徹底入門」


「Hadoop徹底入門」の読み方 (1/3)

まずは第1章～第5章・第6章まで続けて読む全437ページ
第1章 Hadoopってなんだろう？
第2章 Hadoopの導入
第3章 Hadoop分散ファイルシステム HDFS 204 234
ページページ
第4章 Hadoop MapReduceフレームワーク
- 第3章・第4章→「前半は理論、後半は使い方・管理」の構成
第5章 MapReduceプログラミング入門
- ワードカウントを例に、MRUnit・デバッグ技法まで解説
第6章 SQL的インターフェイス Hive
- JavaでMapReduceを書きたくない/全く書けないなら5章スキップも
残りの章は必要に応じて読みたいところから
第10章性能向上のためのチューニング
- SequenceFile、圧縮、メモリ/JVM/OSチューニング

「Hadoop徹底入門」の読み方(2/3)

Hadoopにおける高い信頼性および運用性の実現を補助する内容を記載
第7章：環境構築の効率化
- Kickstart、Puppet を用いた環境構築の自動化
第8章：運用監視とシステムの可視化
- Ganglia を用い、Hadoop に適した監視を実現
第9章：可用性の向上
- Heartbeat、DRBD を用いてマスターサーバの冗長化を実現


「Hadoop徹底入門」の読み方(3/3)

Hadoopの利用価値をさらに高める各種ツール群を紹介
Hive(6章)：SQL的な言語でMapReduceを実行
Pig（11.2章）：データの流れ記述する独自言語でMapReduceを実行
Mahout：Hadoop上で機械学習を容易に実行するためのライブラリ群
HBase(11.1章)：カラム指向型Key-Valueストアデータの追記や少量
データの扱いを容易に実現
Thrift(11.3章)：HDFSに対する操作を各種言語で実現

他に：
- Oozie：Hadoop上のジョブの管理を実現するワークフローエンジン
- Sqoop：DBMSからのデータ移行連携
- HUE:Hadoopに対する操作をGUIにて提供するデスクトップツール


Hive の利用

Hive で SQL的インターフェースが利用可能に！
Java によるコーディングは苦手でも、SQL なら分かるという人は多い
Hadoop利用者の裾野拡大に大きく寄与

とはいえ、あくまでも SQL 「的」なだけ → HiveQL ≠ SQL標準準拠
UPDATE 文が無い
DELETE 文が無い
INSERT INTO 文（追記）ではなく、INSERT OVERWRITE 文（上書き）
細かな構文の違いはマニュアルを見ながら慣れるしかない

次ページ以降で、HiveQL の初心者がとまどいがちな
ポイントを解説
http://wiki.apache.org/hadoop/Hive

初心者がとまどいがちな HiveQL の例(1/3)

データロード／アンロード「元データが消えた？」
なんて思わないように。
Hive外のデータの取り込み = LOAD文
- とくにHDFS内のデータからの LOAD は “mv” コマンドのイメージ！
Hive内のデータの取り出し = INSERT OVERWRITE … SELECT … 文
- INSERT は1レコードを追加するためのものではない

LOAD DATA… INSERT OVERWRITE…SELECT…

Hive テーブル

HDFS



日付時刻データの扱い → Hiveには日付時刻型がない
1. Hive へは STRING 型で格納 ‘yyyy-MM-dd HH:mm:ss’

日付時刻計算は：
A)引数が STRING の組み込みの関数を利用する：
→ 日付差分datediff() など
B)unix_timestamp(‘yyyy-MM-dd HH:mm:ss’) で UNIX タイムスタ
ンプに変換してから処理

2. もしくは初めから BIGINT 型に UNIX タイムスタンプ値を格納



データのソート
ORDER BY 句：全出力結果のソート
SORT BY 句： Reducer ごとのソート

FROM句でのテーブル名の羅列不可 → JOIN 句を利用
(×) SELECT t1.c1, t2.c2 FROM t1, t2 WHERE t1.c1 = t2.c1;
(○) SELECT t1.c1, t2.c2 FROM t1 JOIN t2 ON t1.c1 = t2.c1;

IN/EXISTS 句がない → LEFT SEMI JOIN で代用
(×)SELECT a.key, a.value FROM a
WHERE a.key IN (SELECT b.key FROM B);
(○) SELECT a.key, a.val FROM a
LEFT SEMI JOIN b on (a.key = b.key);
18

黄色い象使いへの道


黄色い象使いになるために～よくある質問～

Hadoop 初心者の方からよく質問を受ける内容をまとめてみました

1. RDBMS的な機能は無いんですか？
2. Hadoopへのマイグレーションってどう？
3. どの「Hadoop」を使えばよい？

？


1. RDBMS的な機能は無いんですか？

そもそも Hadoop は RDBMS でありません！
「トランザクションは概念は無いんですか？」
「1レコードの更新／削除をする機能は無いんですか？」
「B-Tree インデックスが無いんですか？」
…このような機能はHadoopにはありません！
RDBMSの世界で「常識」だと思われるものを捨てて、
大容量データを効率よく処理するために特化した作りだと認識すべき

Hadoopは「銀の弾丸」ではない！→ 「適材適所」の観点で
例）大量データの前処理をHadoopで＋結果をRDBMSに格納し検索しやすく

Solr NoSQL
代替手段

2. Hadoopへのマイグレーションってどう？

商用RDBMS/DWHからのマイグレーションはやれなくはないが、
それなりに工数がかかる、ことが多い
根本的に、工数がかかるのは Hadoop に限った話ではない
NTTデータではマイグレーションの障壁を下げるための取り組みを実施

Hadoopの利用を「マイグレーションによるコスト削減」だけを目的にされると
辛い、ことが多い
Hadoopの利用目的に「何かの壁をぶち破るために」があってしかるべき
「何か」＝処理時間、データ量、etc.

マイグレーション前と同じ機能/品質/SLAを求められると辛い、ことが多い
商用RDBMS/DWH と Hadoop の機能差異
RDBMSでの処理をそのまま置き換えても高速にならない
→ Hadoop に適する形＝「大量データの一括処理」へのリファクタリングが必要

Hadoopに適した処理への書き換え

RDBMSで実行中のバッチ処理をHadoopに移植する場合、Hadoopでの性能を引き出す
ようなチューニングが必要
チューニングの実施例 (RDBMS → Hadoop + Hive)
1. 既存のRDBMSでの処理
- 索引検索によって少量の件数を抽出するクエリが複数からなるバッチ処理

2. チューニングなしで処理をそのまま Hive に移植すると
- 基本的には1クエリ＝1MapReduceジョブに変換される
- MapReduceジョブ起動のオーバーヘッドが大きく、移植による性能向上が見られ
ず：1ジョブあたりのオーバーヘッド＝約20秒（本検証環境において）

3. チューニング後、既存のRDBMSの処理で2.9時間かかっていた処理を、Hiveでは0.8
時間で実現
- 並列分散処理を意識し、１回のMapReduceジョブで済むように複数の条件を一
括で処理することで性能向上

MapReduceジョブ数を極力減らすようにチューニングするのが得策！
少量データを繰り返し処理するより、一括して処理したほうが Hadoop に適する

3. どの「Hadoop」を使えばよい？

Hadoopではどのバージョン/パッケージを使うのかはやや悩ましい問題
コミュニティから提供中のコア部分の最新版は 0.21 系
2010/08/23 v0.21.0 リリース
しかしHadoop周辺プロダクトの多くは0.21系での動作を未サポート
Hive, Pig, HBase など、主要なプロダクトは 0.20 系でのみ動作可能

安定性重視
最新機能をできる限り使いたい
周辺プロダクトとの組合せ保証

コミュニティ版Hadoop Cloudera’s Distribution for Hadoop
v0.21系 (CDH) v0.20系

CDH自体は無償だが、必要に応じてサブスクリプション・サポート(有償)を利用することも可能

まとめ

Hadoopの概要について説明しました。
Hadoopの適用事例を紹介しました。

「Hadoop徹底入門」の読み方がわかりました。
これでみなさんも「黄色い象使い」になれました。

♪


【17-E-3】Hadoop：黄色い象使いへの道 ～「Hadoop徹底入門」より～

More Related Content