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: [email protected] •  twiHer: @shiumachi

3

CDH概要とその歴史

4

CDHとは何か?

•  Cloudera’s DistribuMon including Apache Hadoop •  エンタープライズ向けに開発された100%オープン

ソースのHadoopディストリビューション •  Apache Hadoopを中心に、10以上のオープンソース

コンポーネントを含む

5

Q2 2011

2009 2010 2011 2012 2012/06 2012/09

Q1 2010

Q3 2009

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

2012/06

CDH 開発の歴史

§ 高可用性ネームノード(クォーラムベースストレージ) § Hue の Oozie ワークフローGUI と日本語化 § 統計分析用PigライブラリDataFu § etc…

2012/09

6

CDHの主要コンポーネント

分散ファイルシステム APACHE HDFS

大規模分散処理基盤 APACHE MapReduce

分散データベース APACHE HBase

高級言語とライブラリ APACHE Hive, APACHE Pig, APACHE Mahout

ワークフローとスケジューリング APACHE Oozie

クラウドでの分散処理ライブラリ APACHE Whirr

分散協調サービス APACHE ZooKeeper

Webインタフェースとフレームワーク

Hue

HadoopとRDBMSとの連携 APACHE Sqoop

分散ログストリーミング処理 APACHE Flume

ビル

ド/テ

スト: A

PACH

E BIGT

OP

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/confluence/display/Hive/IndexDev+Bitmap

•  プラグイン・デベロッパ・キット(PDK)(HIVE-‐2244) •  Hive拡張を作りやすくする •  現在UDFのみサポート •  hHps://cwiki.apache.org/confluence/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) •  define 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

DataFu

•  統計分析用 Pig UDF(ユーザ定義関数)ライブラリ •  LinkedIn が開発 •  PageRank、セッション化といった高度なデータ解析に

役立つライブラリ集

ranks = FOREACH edges GENERATE group as topic, FLATTEN(PageRank(edges.(s,e))) as (source,rank);

CDH4.1

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) •  hHp://archive.cloudera.com/cdh4/cdh/4/sqoop/

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

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

•  Date/Time インクリメンタルアペンド(SQOOP-‐321) •  hHp://archive.cloudera.com/cdh4/cdh/4/sqoop/

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

25

HDFS HA(高可用性 HDFS)

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

•  ネームノードのダウンタイム発生ケースは2種類 •  障害停止(低確率) •  計画停止(確実に発生)

•  現在はHDFS HA機能があるためSPOFはなくなった •  上記のダウンタイムの問題は解決できる

•  自動フェイルオーバ可能 •  特殊なサーバを必要とせず、Hadoopと同じスペック

のノードで構築可能(CDH4.1)

26

HDFS HA アーキテクチャ

•  ネームノードのペアを使う •  アクティブとスタンバイ •  クライアントとデータノードはアクティブNNとのみ通信する •  スタンバイNNは共有ストレージを参照してアクティブノード

の状態を取得可能

•  スタンバイネームノードはチェックポイントを行う •  よってHAではセカンダリネームノードは不要

27

アーキテクチャ

Daemon Daemon データノード

ネームノード (アクティブ)

ネームノード (スタンバイ)

Daemon Daemon ZooKeeper

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


editlog

ブロックレポート

編集ログ (フェンシング)


コマンドコマンド

リーダー選択リーダー選択

状態監視状態監視

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

HDFS HA (QJMベース)

CDH4.1

33

HDFS HA での共有ストレージ

•  スタンバイNNは、アクティブNNのトランザクションログ(edits)を読み込むことで名前空間を同期する •  mkdir(/foo) などの操作はアクティブNNによってロギング

される •  スタンバイNNは定期的に新しいeditsを読み込み、自身の

メタデータを最新に保つ

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

34

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

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

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

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

35

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







共有ストレージ(NFS)

editlog


編集ログ (フェンシング)





36

NFSベースの手法の欠点

•  カスタムハードウェア •  多くのお客様はデータセンタにSAN/NASを持っていない •  多くのお金、時間がかかり、高い専門性が必要 •  HDFS外から監視する別システムが必要 •  SPOFを外に出しただけで、なくしたわけじゃない

•  複雑 •  ストレージのフェンシング、NFSマウントオプション、ボン

ディング、etc. •  NFS自身の問題

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

37

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

•  特別なハードウェアを必要としないこと(PDU、NAS) •  カスタムのフェンシング設定を必要としないこと

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

•  SPOFがないこと •  ストレージにSPOFを丸投げするのはよくない •  完全な分散システムが必要

38

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

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

•  スケーラビリティを持つこと •  書き込みは並列に行われる •  書き込みが遅いノードを待たない

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

39

QuorumJournalManager

•  QuorumJournalManager(クライアント) •  クォーラムジャーナルマネージャ •  JournalManager インタフェースの実装

•  FileJournalManager 実装の置き換え

•  JournalNode(サーバ) •  ジャーナルノード •  奇数ノードで稼働するスタンドアロンデーモン •  editsの書き込み先ストレージとして機能 •  将来的には他のデーモン内部で稼働できるようにする予

定

CDH4.1

40

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







ローカルストレージ

ジャーナルノード

ブロックレポートブロックレポート




CDH4.1

41

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

NameNode

Quorum JournalManager

JournalNode

ローカルディスク

JournalNode


JournalNode


CDH4.1

42

コミットプロトコル

•  NNはローカルのeditsに書き込む •  FSEditLog.logSync()により全てのJNにHadoop RPC を

通じてeditsを送信する •  CDH4からeditsは細かく分割されているためデータは小さ

い

•  過半数のノードから成功のACKが返るのを待つ •  これにより遅いJNや障害の発生したJNがNNのレイテンシ

に与える影響を最小限にとどめることが可能 •  NNのレイテンシ ≒ JNのレイテンシの中間値

CDH4.1

43

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

•  QJMインスタンスにはユニークなエポック番号が割り当てられる •  クライアントNN間での強い順序付けを提供 •  それぞれの IPC はクライアントのエポックを持つ •  JNは今まで見たことのある最も高いエポックをディスク上

に保持する •  その値よりも小さいエポックからのリクエストは全て拒否

する。その値よりも大きいエポックはディスクに記録される •  Paxos 等でも使われている手法

CDH4.1

44

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

•  暗黙的にフェンシングを行う •  NNがアクティブになると、それより前のアクティブNN

はフェンスアウトされる •  新しいアクティブNNはより高いエポック数を持つ •  よって一旦新しいアクティブNNからのリクエストを受け入

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

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

CDH4.1

45

セグメントリカバリ

•  通常、過半数に満たないJNは同期されない •  障害発生後、全てのJNは異なる数のトランザクションを

持ちうる •  例: JN1 がダウンし、JN2はトランザクションID150が書き込まれ

る前にクラッシュした •  JN1: edits なし •  JN2: edits 101-‐149 を持つ •  JN3: edits 101-‐150 を持つ

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

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

CDH4.1

46

MapReduce v2

47

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のアーキテクチャ

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

MapReduce Job Submission

  A client submits a job to the JobTracker –  JobTracker assigns a job ID –  Client calculates the input splits for the job –  Client adds job code and configuration to HDFS

JobTracker

TaskTracker TaskTracker

Client

TaskTracker

TaskTracker

•  MRv1 には JobTrackerとTaskTracker の2つのサービスがある •  JobTracker(マスタ): 1クラスタに1つ •  TaskTracker(スレーブ): 1クラスタに多数

49

MRv2のアーキテクチャ

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

MRv2 System Architecture (cont’d)

  Slave nodes run individual tasks similar to MRv1

  For each job, one slave node is Application Master –  Manages application lifecycle –  Negotiates resource “containers” from Resource Manager –  Monitors tasks running on the other slave nodes

Node Manager

Node Manager

Node Manager

Node Manager

Resource Manager

SchedulerApplication Manager

App Master - Job #1

App Master - Job #2

•  ResourceManagerとNodeManager •  ResourceManager(マスタ): 1クラスタに1つ •  NodeManager(スレーブ): 1クラスタに多数

•  ジョブ毎に、スレーブノードはApplicaMonMaster を動作させる •  このApploicaMonMaster が1回のMRジョブを管理する

50

Flume NG

51

Flume オーバービュー

•  Flume は生成される大量のデータを効率よく移動させるための分散サービス •  ログデータを直接HDFSに投入するのに理想的

•  従来は Flume OG がメインだった •  CDH3 から追加 •  CDH4 ではアドオンとして利用可能だが、フェードアウトする予

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

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

•  よりわかりやすくシンプルなアーキテクチャ •  メモリ消費量が少なくなった

52

Flume の構成例エージェント

エージェント

エージェント

Hadoop クラスタ

Webサーバ

Unix syslog

メールサーバ

エージェント

エージェント

圧縮

暗号化

53

Flume NG アーキテクチャ概要

•  プロデューサ・コンシューマモデル •  多くのコンポーネントがプラガブル

コンポーネント機能

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

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

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

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

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

54

まとめ

55

まとめ

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

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

Hadoop を使うならまずCDH4を選びましょう

ダウンロードはこちら

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

56

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

CDH ユーザメーリングリスト(日本語) cdh-‐user-‐[email protected] CDH の質問についてはこちら Cloudera ニュースレター hHp://www.cloudera.co.jp/newsleHer Cloudera に関するニュースをお届けします CDHの最新情報・使い方なども紹介します

57

58

Technology

CDH4.1オーバービュー