レポート

イレージャコーディングはすべてのノウハウを変える ―小沢PMCが「Hadoop Summit 2016 Tokyo」で語った"Hadoop 3.0のカンどころ"

この記事を読むのに必要な時間:およそ 3 分

2016年10月26,27日の2日間に渡って開催されたHadoop Summti 2016 Tokyo(主催: Hortonworks)」では50近い数のブレイクアウトセッションが用意され,Hadoopおよびそのエコシステムの最新情報や国内/海外のユーザ企業による事例の紹介が行われていました。本稿ではその中でも人気の高かった,2017年前半にリリース予定のHadoop 3.0の概要を紹介するセッション「Hadoop 3.0 in a Nutshell」から,日本人PMCとして活躍中のHadoopコミッタ 小沢健史氏(NTTイノベーションセンター)のプレゼン概要を紹介します。

小沢健史氏

小沢健史氏

Hadoop 3.0のハイライト

まずは小沢PMCが紹介したHadoop 3.0の主なアップデートについて,その内容を紹介します。

コンパイル可能なソースコードはJDK 8(Java 8)以上に

Hadoop 2.7がリリースされて以来,Hadoopのソースコードは徐々にJava 7からJava 8ベースへと移行してきましたが,2015年4月にOracle JDK 7がサポート切れ(EoL)を迎えたことをきっかけに,それ以降追加されたHadoopの新機能はJava 8で書かれるようになっています。Hadoop 3.0ではこの方針がさらに強化され,Java7やJava 6で書かれたコードはコンパイルできなくなり,Java 8より上のバージョンのみが対象となります。

ライブラリマネジメントの改善

小沢PMCの説明によれば「依存関係のアップグレード」「クライアントサイドのクラスパス分離」の2点がライブラリ関連の大きなアップデートとなります。具体的には

  • Jersey: 1.9 → 1.19
  • grizzly-http-servlet: 2.1.2 → 2.2.21
  • Guice: 3.0 → 4.0
  • cglib: 2.2 → 3.2.0
  • asm: 3.2 → 5.0.4

といったライブラリのアップグレードが行われるとのこと。また,ユーザサイド(サードパーティ)のアプリケーションコードとHadoopのベースコードの間でクラスパス名が衝突してしまう問題を回避するため,HadoopのクライアントサイドとサーバサイドのJARを分離し,クライアントサイドのみを共有させることで改善を図っています。

クライアントサイドとサーバサイドのJARを分離

クライアントサイドとサーバサイドのJARを分離

「Azure Data Lake Store」のサポート

ストレージ関連のアップデートで注目されるのは,Micrsoft Azureの大容量データリポジトリサービス「Azure Data Lake Store」の正式サポートでしょう。Azure Data Lake StoreはもともとHDFS互換ストレージとして設計されていますが,HadoopがAzure Data Lake Storeをオフィシャルにサポートすることにより,Hadoopとの連携がより行いやすくなるのは間違いありません。小沢PMCは「Hadoopはこれまで,本当にさまざまなタイプのストレージAPIをサポートしてきた」と語っており,HDFSはもちろんのこと,Amazon S3やAzure Blob Storage,OpenStaxk SwiftといったオブジェクトストレージがすでにHadoopでサポートされています。Azure Data Lake Storeが加わることで,オブジェクトストレージのサポートラインナップが強化され,Hadoop自体のクラウドシフトも進んでいきそうです。

シェルスクリプトのリライト

Hadoop 3.0ではシェルスクリプトのリライトが行われており,CLI(コマンドラインインタフェース)がリニューアルされるとのこと。小沢PMCは変更点の一例として,デーモンを起動するコマンドの変更や,環境変数やクラスパスの表示に関するコマンドの追加を挙げています。

デーモンログをKafkaに出力するプラグインの追加

ストリーミングデータをリアルタイムに処理するバックエンドとしてデファクトになりつつあるApache Kafkaとの連携をさらに強化するために,HadoopのデーモンログをKafkaにダイレクトに送り込むプラグイン(metrics2 sink plugin)が提供されます。Hadoopのデーモンやイベントのログを収集するコレクタであるMetrics System 2を経由することでKafkaのトピックにこれらのデータをシームレスに書き出すことができるようになります。

ネームノードのマルチスタンバイ構成

Hadoopでは2.0からマスターノードであるネームノード(NameNode)にアクティブ/スタンバイ構成(NameNode-HA)が取り入れられており,それ以前の課題であったネームノードによるSPOF(単一障害点)を回避することができています。しかし,1つのアクティブノードに対し1つのスタンバイノードしか用意できないため,アクティブノードに障害が発生した場合は早急にリカバーする必要がありました。この課題を解消するためにHadoop 3.0ではマルチスタンバイ方式を採用,1つのアクティブノードに対して複数のスタンバイノードを対応させ,障害時に起動するノードを選択できるようになっています。

1つのアクティブノードに対して複数のスタンバイノードを対応させる

1つのアクティブノードに対して複数のスタンバイノードを対応させる

著者プロフィール

五味明子(ごみあきこ)

IT系の出版社で編集者としてキャリアを積んだ後,2011年からフリーランスライターに。フィールドワークはオープンソースやクラウドコンピューティング,データアナリティクスなどエンタープライズITが中心。海外カンファレンス取材多め。Twitter(@g3akk)やFacebookで日々IT情報を発信中。

北海道札幌市出身/東京都立大学経済学部卒。

コメント

コメントの記入