CDH4.1オーバービュー

CDH4.1オーバービュー

Cloudera
カスタマーオペレーションズエンジニア

嶋内　翔

2012年11月7日

1

アジェンダ

•  CDH概要とその歴史

•  CDH4での変更点

•  HDFS
HA

•  HDFS
HA(QJMベース)

•  MapReduce
v2

•  Flume
NG

2

自己紹介

•  嶋内　翔(しまうちしょう)

•  2011年4月にClouderaの最初の日本人社員として入
社

•  カスタマーオペレーションズエンジニアとしてテクニ
カルサポート業務を担当

•  email:
sho@cloudera.com

•  twiHer:
@shiumachi

3

CDH概要とその歴史

4

CDHとは何か?

•  Cloudera’s
DistribuMon
including
Apache
Hadoop

•  エンタープライズ向けに開発された100%オープン
ソースのHadoopディストリビューション

•  Apache
Hadoopを中心に、10以上のオープンソース
コンポーネントを含む

5

CDH
開発の歴史

2012/06

§ 高可用性ネームノード(NFS)
§ 複数のデータ処理フレームワーク（MR1とMR2）

Q3 2009 Q2 2011
§ etc…

2009
2010
2011
2012
2012/06
2012/09

2012/09
Q1 2010
§ 高可用性ネームノード(クォーラムベースストレージ)

§ Hue
の Oozie
ワークフローGUI
と日本語化

§ 統計分析用PigライブラリDataFu

§ etc…

6

CDHの主要コンポーネント

Webインタフェースと

HadoopとRDBMSとの連携
分散ログストリーミング処理

ビルド/テスト:
APACHE
BIGTOP

フレームワーク

APACHE
Sqoop
APACHE
Flume

Hue

クラウドでの分散処理ライブラリ
ワークフローとスケジューリング

APACHE
Whirr
APACHE
Oozie

分散協調サービス
高級言語とライブラリ

APACHE
ZooKeeper
APACHE
Hive,
APACHE
Pig,
APACHE
Mahout

分散データベース
大規模分散処理基盤

APACHE
HBase
APACHE
MapReduce

分散ファイルシステム

APACHE
HDFS

7

CDH4での変更点

8

CDH4リリース番号

•  リリース番号の表記が変わりました

•  CDH3
以前:
CDH3u0,
CDH3u1,
CDH3u2
…

•  CDH4:
CDH
X.Y.Z

•  X:
メジャーバージョン(大規模な変更を含む)

•  Y:
マイナーバージョン(CDH3以前の
update

に相当)

•  Z:
ポイントバージョン(重大なバグ修正のみ)

•  最新版は
CDH4.1.1

•  多分もうすぐCDH4.1.2が出ます

9

コンポーネントバージョン一覧

コンポーネント
CDH3u5
CDH4.1.1

Avro
1.5.4
1.5.4

FlumeOG
0.9.4
-‐-‐
(0.9.4)

FlumeNG
1.2.0
1.2.0

Hadoop

0.20.2
2.0.0

Hadoop
MRv1
-‐-‐
0.20.2

HBase
0.90.4
0.92.1

Hive
0.7.1
0.9.0

Hue
1.2.0.0
2.1.0

10

コンポーネントバージョン一覧

CDH3u5
CDH4.1.1

Mahout
0.5
0.7

Oozie
2.3.2
3.2.0

Pig
0.8.1
0.10.0

DataFu
(Pig
UDF
ライブラリ)

-‐-‐
0.0.4

Sqoop
1.3.0
1.4.1

Whirr
0.5.0
0.8.0

ZooKeeper
3.3.5
3.4.3

11

Hadoop

•  大きな変更

•  MapReduce
version
2
(YARN
というフレームワークがベース)

•  HDFS
HA(高可用
HDFS)

•  NFS共有ディレクトリ(CDH4.0)

•  クォーラムベースストレージ共有ディレクトリ(CDH4.1)

•  HDFS
フェデレーション

•  パラメータ名が大きく変更

•  例:
fs.default.name
は fs.defaultFS
に変更

•  古いパラメータ名を使っていても
deprecated
という
WARN
ログ
が出るだけで実害なし

•  既存のMapReduceアプリケーションはそのままCDH4で
使用可能

•  ただしCDH4環境で再コンパイルが必要

12

Hadoop
(続き)

•  REST
over
HTTPインタフェースの追加

•  HHpFs

•  WebHDFS

•  MapReduceシャッフルフェーズでの暗号化(CDH4.1)

•  libhdfs
でのダイレクト読み込み(HDFS-‐2834,

HDFS-‐3110)
(CDH4.1)

•  C++
クライアントからの読み込みが2-‐3倍高速になった

•  Impala
が高速な理由の一つ

13

HBase

•  コプロセッサ(HBASE-‐2000)

•  HFile
v2
(HBASE-‐3857)

•  分散ログスプリッティング

•  その他さまざまな機能追加

•  Web
UI
の表示情報量が増えた

•  ログからスロークエリを調べやすくなった

14

Hive

•  新しいデータ型のサポート

•  BINARY
(HIVE-‐2380)

•  TIMESTAMP
(HIVE-‐2272)

•  JDBC日付文字列フォーマット準拠の形式

•  ビットマップインデックス(HIVE-‐1803)

•  hHps://cwiki.apache.org/conﬂuence/display/Hive/IndexDev+Bitmap

•  プラグイン・デベロッパ・キット(PDK)(HIVE-‐2244)

•  Hive拡張を作りやすくする

•  現在UDFのみサポート

•  hHps://cwiki.apache.org/conﬂuence/display/Hive/PluginDeveloperKit

•  JDBCドライバの改善

•  Hiveserver2
(HIVE-‐2935)
(CDH4.1)

•  複数ユーザからの同時接続など、従来のHiveserverにはなかった機
能を追加

15

Pig

•  UDFでJavaScriptサポート(PIG-‐1794)

•  組み込みPig(PIG-‐1479)

•  Python,
Ruby
でもUDFを記述可能

•  hHp://archive.cloudera.com/cdh4/cdh/4/pig/udf.html

•  マクロ(PIG-‐1793)

•  deﬁne
my_macro(A,
sortkey)
returns
C
{
…
}
という形式でマクロを定義
可能

•  project-‐range
記法(PIG-‐1693)

•  col0,
col1
..
col3
と書くと、
col0,
col1,
col2,
col3
に展開してくれる

•  hHp://archive.cloudera.com/cdh4/cdh/4/pig/basic.html#expressions

•  その他の機能・改善

•  エラーメッセージの改善

•  combinerの最適化

•  ILLUSTRATE
コマンドのバグ修正

16

CDH4.1

DataFu

•  統計分析用
Pig
UDF(ユーザ定義関数)ライブラリ

•  LinkedIn
が開発

•  PageRank、セッション化といった高度なデータ解析に
役立つライブラリ集

ranks
=
FOREACH
edges
GENERATE

group
as
topic,

FLATTEN(PageRank(edges.(s,e)))
as
(source,rank);

17

Flume

•  Flume
NG
(1.x
系)

•  従来のFlume
(以下
Flume
OG)
を大きくリファクタリング

•  Flume
NG
=
New
GeneraMon
(新世代)

•  Flume
OG
=
Old
GeneraMon
(旧世代)

•  HBase
シンクのサポート(CDH4.1)

•  Flume
OG
(0.9.x
系)

•  CDH4
でもアドオンとして利用可能

18

Oozie

•  DistCp
アクションのサポート
(OOZIE-‐11)

•  「バンドル」を追加

•  コーディネートジョブ(定期実行ジョブ)をグループ化できる

•  サポートするDBの追加

•  MySQL,
Oracle
は以前から使える

•  PostgreSQL(OOZIE-‐22,
CDH3u2以降でも使用可)

19

Sqoop

•  カスタムタイプマッピング(SQOOP-‐342)

•  hHp://archive.cloudera.com/cdh4/cdh/4/sqoop/
SqoopUserGuide.html#_controlling_type_mapping

•  今までDBスキーマの型とJava/Hiveの型のマッピングは自動だったが、これにより任意のマッ
ピングを行えるようになった

•  -‐-‐map-‐column-‐java,
-‐-‐map-‐column-‐hive
オプションで指定

•  境界クエリサポート(SQOOP-‐331)

SqoopUserGuide.html#_selecMng_the_data_to_import

•  今までは
-‐-‐split-‐by
で指定した列の最大と最小の値を元に、分割するときの境界線を決めて
いた

•  -‐-‐boundary-‐query
により、境界条件を決定するためのクエリを任意に指定できるようになった

•  Date/Time
インクリメンタルアペンド(SQOOP-‐321)

SqoopUserGuide.html#_incremental_imports

•  今までは数値のみがインクリメンタルインポートの対象だったが、これにより日付型も対象に

•  IBM
DB2
コネクタのサポート(SQOOP-‐329)

•  将来のCDH4
では
Sqoop2
を追加する予定

20

Whirr

•  サポート対象サービスの追加

•  MapReduce
v2
(YARN)

•  Chef
(WHIRR-‐49)

•  Ganglia(WHIRR-‐258)

•  Mahout
(WHIRR-‐384)

•  EC2クラスタコンピュートグループのサポート(WHIRR-‐63)

(CDH4.1)

•  Chef
はメインストリームのサービスには(まだ)使われていな
い

•  今後の設定管理の自動化に期待

•  Mahout
インストールが可能に

•  CDHバージョンではないことに注意

•  CDH4
ではさらに追加設定パラメータあり

•  詳細はドキュメント参照

21

Hue

•  Hue2
にメジャーアップデート

•  UIが大きく変更。Cloudera
Manager
に近くなった

•  旧UIで問題となっていたメモリリークを解決

•  HDFS
ファイルブラウザのためにDN/NNへのプラグイン
を導入する必要がなくなった

•  OpenLDAPやAcMveDirectory
からユーザをインポートで
きるようになった

•  OozieからMapReduceジョブを実行するようになった

•  Oozie
ワークフロービルダー(CDH4.1)

•  アプリケーション単位のアクセスコントロール

•  日本語対応！

•  Hue
1.x
系の
SDK
とは非互換なので注意

22

Hue
(Hive
実行画面)

23

Hue
(ジョブ実行中画面)

24

HDFS
HA(高可用性
HDFS)

•  従来のHadoopではネームノードは単一障害点
(SPOF)だった

•  ネームノードのダウンタイム発生ケースは2種類

•  障害停止(低確率)

•  計画停止(確実に発生)

•  現在はHDFS
HA機能があるためSPOFはなくなった

•  上記のダウンタイムの問題は解決できる

•  自動フェイルオーバ可能

•  特殊なサーバを必要とせず、Hadoopと同じスペック
のノードで構築可能(CDH4.1)

26

HDFS
HA
アーキテクチャ

•  ネームノードのペアを使う

•  アクティブとスタンバイ

•  クライアントとデータノードはアクティブNNとのみ通信する

•  スタンバイNNは共有ストレージを参照してアクティブノード
の状態を取得可能

•  スタンバイネームノードはチェックポイントを行う

•  よってHAではセカンダリネームノードは不要

27

アーキテクチャ

Daemon
Daemon
リーダー選択
ZooKeeper
リーダー選択

フェイルオーバ
コントローラ
コントローラ

状態監視
editlog
状態監視

コマンド
編集ログ
コマンド

(フェンシング)

ネームノード
ネームノード
(アクティブ)
(スタンバイ)

Daemon
Daemon
データノード
ブロックレポート

28

フェイルオーバとフェンシング

•  起動時にアクティブなNNを選出

•  必ず1個のアクティブしか起動しないことを保証

•  CDH4では手動・自動フェイルオーバをサポート

•  スプリットブレイン時のデータ破壊を防ぐ

•  共有リソースのフェンシング

•  DN、及び共有ストレージ上のNNのメタデータ

•  NNのフェンシング

•  共有リソースをフェンスできなかった場合

•  クライアントフェイルオーバ

•  クライアントはフェイルオーバ後に新しいNNにアクセスで
きる

29

手動フェイルオーバの方法

•  hdfs
haadmin
-‐failover
nn01
nn02

•  手動フェイルオーバはこのコマンドで実行

•  フェンシングとスタンバイNNへのフェイルオーバを実施

30

自動フェイルオーバ

•  自動フェイルオーバはZooKeeperを使う

•  ZooKeeper
はHBaseでも使われている協調サービス

•  設定方法は以下のような流れ

1.  NNで自動フェイルオーバ用の設定を行う

2.  NNを起動する

3.  ZooKeeper
フェイルオーバコントローラ(ZKFC)デーモンを
起動する

•  ZKFCは全NNと同一ノードで起動しなければいけない

•  運用監視ソフトからもZKFCを監視するのを忘れずに

31

自動フェイルオーバの流れ

•  単純に
kill
-‐9
するだけ

•  フェイルオーバは5秒で開始される

•  デフォルト値。設定変更可能

•  ha.zookeeper.session-‐Mmeout.ms
(ミリ秒単位)

32

CDH4.1

HDFS
HA
(QJMベース)

33

HDFS
HA
での共有ストレージ

•  スタンバイNNは、アクティブNNのトランザクションロ
グ(edits)を読み込むことで名前空間を同期する

•  mkdir(/foo)
などの操作はアクティブNNによってロギング
される

•  スタンバイNNは定期的に新しいeditsを読み込み、自身の
メタデータを最新に保つ

•  よって高信頼な共有ストレージはcorrectな(正しい)
オペレーションに必須

34

共有ストレージ(フェーズ1)

•  運用者は従来の共有ストレージデバイスを設定する
(SAN,
NAS)

•  アクティブ/スタンバイの両方のNNから共有ストレー
ジをNFSマウントする

•  アクティブNNが書き込み、スタンバイNNが読み込む

35

NFSベースのアーキテクチャ

Daemon
Daemon
リーダー選択
ZooKeeper
リーダー選択

コントローラ
コントローラ
共有ストレージ(NFS)

状態監視
editlog
状態監視

コマンド
編集ログ
コマンド

(フェンシング)

ネームノード
ネームノード
(アクティブ)
(スタンバイ)

Daemon
Daemon
データノード

36

NFSベースの手法の欠点

•  カスタムハードウェア

•  多くのお客様はデータセンタにSAN/NASを持っていない

•  多くのお金、時間がかかり、高い専門性が必要

•  HDFS外から監視する別システムが必要

•  SPOFを外に出しただけで、なくしたわけじゃない

•  複雑

•  ストレージのフェンシング、NFSマウントオプション、ボン
ディング、etc.

•  NFS自身の問題

•  クライアントの実装にバグが多い、タイムアウト時の挙動
のコントロールが大変、etc.

37

ストレージの改善のための要件

•  特別なハードウェアを必要としないこと(PDU、NAS)

•  カスタムのフェンシング設定を必要としないこと

•  設定が複雑＝設定ミスしやすい

•  SPOFがないこと

•  ストレージにSPOFを丸投げするのはよくない

•  完全な分散システムが必要

38

ストレージ改善のための要件(続き)

•  耐障害性

•  Nノードクラスタが(N-‐1)/2ノードまでの耐障害性を持つこと

•  スケーラビリティを持つこと

•  書き込みは並列に行われる

•  書き込みが遅いノードを待たない

•  既存のハードウェアに共存可能であること(JT、NN、
SBNなどと共有)

39

CDH4.1

QuorumJournalManager

•  QuorumJournalManager(クライアント)

•  クォーラムジャーナルマネージャ

•  JournalManager
インタフェースの実装

•  FileJournalManager
実装の置き換え

•  JournalNode(サーバ)

•  ジャーナルノード

•  奇数ノードで稼働するスタンドアロンデーモン

•  editsの書き込み先ストレージとして機能

•  将来的には他のデーモン内部で稼働できるようにする予
定

40

CDH4.1

QJMベースのアーキテクチャ

Daemon
Daemon
リーダー選択
ZooKeeper
リーダー選択

ローカル
コントローラ
ストレージ
コントローラ

状態監視
ジャーナル状態監視

ノード

コマンド
コマンド

ネームノード
ネームノード
(アクティブ)
(スタンバイ)

Daemon
Daemon
データノード

41

CDH4.1

QJMベースのアーキテクチャ

NameNode

Quorum

JournalManager

JournalNode
JournalNode
JournalNode

ローカルディスク

42

CDH4.1

コミットプロトコル

•  NNはローカルのeditsに書き込む

•  FSEditLog.logSync()により全てのJNにHadoop
RPC
を
通じてeditsを送信する

•  CDH4からeditsは細かく分割されているためデータは小さ
い

•  過半数のノードから成功のACKが返るのを待つ

•  これにより遅いJNや障害の発生したJNがNNのレイテンシ
に与える影響を最小限にとどめることが可能

•  NNのレイテンシ
≒
JNのレイテンシの中間値

43

CDH4.1

ジャーナルノードのフェンシング

•  QJMインスタンスにはユニークなエポック番号が割り
当てられる

•  クライアントNN間での強い順序付けを提供

•  それぞれの IPC
はクライアントのエポックを持つ

•  JNは今まで見たことのある最も高いエポックをディスク上
に保持する

•  その値よりも小さいエポックからのリクエストは全て拒否
する。その値よりも大きいエポックはディスクに記録される

•  Paxos
等でも使われている手法

44

CDH4.1

エポックを使ったフェンシング

•  暗黙的にフェンシングを行う

•  NNがアクティブになると、それより前のアクティブNN
はフェンスアウトされる

•  新しいアクティブNNはより高いエポック数を持つ

•  よって一旦新しいアクティブNNからのリクエストを受け入
れたJNはエポック数を更新するため、古いアクティブNNか
らのリクエストを受けつけない

•  これにより、複雑で間違いやすいカスタムフェンシン
グの設定をなくすことができた

45

CDH4.1

セグメントリカバリ

•  通常、過半数に満たないJNは同期されない

•  障害発生後、全てのJNは異なる数のトランザクションを
持ちうる

•  例:
JN1
がダウンし、JN2はトランザクションID150が書き込まれ
る前にクラッシュした

•  JN1:
edits
なし

•  JN2:
edits
101-‐149
を持つ

•  JN3:
edits
101-‐150
を持つ

•  アクティブになる前、最後のバッチについてコンセンサス
をとる必要がある

•  コンセンサスの解決には Paxos
アルゴリズムを使ってい
る

46

MapReduce
v2
(MRv2)

•  Apache
Hadoop
0.23
系(現
2.0
系)
で開発された

•  CDH4より導入

•  汎用分散処理フレームワークYARNの上で実装

•  MapReduce以外の分散処理にも対応

•  Hamster:
MPI

•  Hama:
バルクシンクロナスプロセッシング
BSP

•  Giraph:
グラフ処理

•  超大規模クラスタを構築可能(最大10000ノード)

•  MRv1
では最大4000ノード

•  アーキテクチャが大きく変更された

•  APIは変更なし。よってMRプログラムは再コンパイルするだけで動作する

•  コミュニティ版では
MRv2
のみ使用可能だがCDH4では
MRv1、MRv2
両
方使用可能

•  CDH4.1では商用環境でMRv1の利用を推奨

•  MRv2はまだ開発用途としての利用を推奨

48

MRv1のアーキテクチャ
MapReduce Job Submission
•  MRv1
には JobTrackerとTaskTracker
の2つのサービ
スがある

  A client submits a job to the JobTracker
•  –  JobTracker assigns a job ID
JobTracker(マスタ):
1クラスタに1つ

–  Client calculates the input splits for the job
•  TaskTracker(スレーブ):
1クラスタに多数
–  Client adds job code and configuration to HDFS

Client TaskTracker

JobTracker

TaskTracker TaskTracker

TaskTracker

49

MRv2のアーキテクチャ
(cont’d)
MRv2 System Architecture

  Slave nodes run individual tasks similar to MRv1
•  ResourceManagerとNodeManager

ResourceManager(マスタ):
1クラスタに1つ

 • For each job, one slave node is Application Master
•  NodeManager(スレーブ):
1クラスタに多数

–  Manages application lifecycle
•  ジョブ毎に、スレーブノードはApplicaMonMaster
を動作させる

–  Negotiates resource “containers” from Resource Manager
•  このApploicaMonMaster
が1回のMRジョブを管理する
–  Monitors tasks running on the other slave nodes

Node Manager Node Manager
App Master - Job #2
Resource Manager

Scheduler
Application Manager
App Master - Job #1

Node Manager Node Manager

Copyright © 2010-2012 Cloudera. All rights reserved. Not to be reproduced without prior written consent. 04-27
50

Flume
オーバービュー

•  Flume
は生成される大量のデータを効率よく移動させる
ための分散サービス

•  ログデータを直接HDFSに投入するのに理想的

•  従来は
Flume
OG
がメインだった

•  CDH3
から追加

•  CDH4
ではアドオンとして利用可能だが、フェードアウトする予
定

•  Flume
NG
は
CDH4
の一部として存在

•  Flume
NG
の
API
は
Flume
OG
と非互換

•  しかし大半のコンセプトは
Flume
NG
でもそのまま使われている

•  よりわかりやすくシンプルなアーキテクチャ

•  メモリ消費量が少なくなった

52

Flume
の構成例

Webサーバ
エージェント
エージェント

メールサーバ
エージェント

エージェント

Unix
syslog
エージェント

圧縮

暗号化

Hadoop
クラスタ

53

Flume
NG
アーキテクチャ概要

•  プロデューサ・コンシューマモデル

•  多くのコンポーネントがプラガブル

機能

Agent(エージェント)
Flumeが動作するJVM。複数のソースとシンクを持つ

Source(ソース)
データをイベントの形式で生成する。個別のスレッドで動作

Sink(シンク)
チャネルからイベントを受け取る。個別のスレッドで動作

Channel(チャネル)
ソースとシンクを接続する(キューのように)

Event(イベント)
単一のデータ。例:
ログ1行、AVROオブジェクト、etc

54

まとめ

•  CDHはHadoopをエンタープライズでも使えるようにし
たオープンソースのディストリビューションです

•  CDH4ではHDFS
HAを始め、プロダクションで運用す
るための便利な機能が追加されています

Hadoop
を使うなら

まずCDH4を選びましょう

ダウンロードはこちら

hHp://www.cloudera.com/downloads/

56

CDHコミュニティ・MLの紹介

CDH
ユーザメーリングリスト(日本語)

cdh-‐user-‐jp@cloudera.org

CDH
の質問についてはこちら

Cloudera
ニュースレター

hHp://www.cloudera.co.jp/newsleHer

Cloudera
に関するニュースをお届けします

CDHの最新情報・使い方なども紹介します

57

CDH4.1オーバービュー

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à CDH4.1オーバービュー

Similaire à CDH4.1オーバービュー (20)

Plus de Cloudera Japan

Plus de Cloudera Japan (20)

Dernier

Dernier (10)

CDH4.1オーバービュー