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を分離し、クライアントサイドのみを共有させることで改善を図っています。

「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つのアクティブノードに対して複数のスタンバイノードを対応させ、障害時に起動するノードを選択できるようになっています。

ディスクスペースを大幅削減! HDFSにおけるイレージャコーディングのサポート

小沢PMCはプレゼンの最後、「⁠Hadoop 3.0における最大のアップデート」として、HDFSにおけるイレージャコーディング（erasure coding）のサポートについて詳しく説明しています。

HDFSは通常、3ヵ所にデータ（ブロック）をコピーしますが、その際、チェーンレプリケーション（Chain Replication）方式を採用しているので、3ヵ所すべてのコピー（書き込み）が終了するまで読み出しが行われることもなく、データはつねに一貫性を保つことができます。しかし一方で、コピーが完了するまでのレイテンシやオーバーヘッドは大きく、また、3ヵ所のコピーに必要なディスクスペース（オリジナルが1テラバイトなら3テラバイト必要）も大きな負荷となります。

ここで登場するのがイレージャコーディングです。小沢PMCは「イレージャコーディングはいままでのHDFSの概念をすべて変える」と強調しますが、決して大げさな表現ではなく、ストレージのディスクスペースを大幅に削減しながら、フォルトトレランスを担保することが可能になります。イレージャコーディングは「リード・ソロモン符号（Reed-Solomon coding⁠）⁠」というQRコードなどでも使われている高度なデータ保護演算方式をベースにしており、これにより消失したデータの復元や破損したデータの検出が可能になっています。

もうすこし具体的に説明すると、イレージャコーディングでは従来のように3ヵ所にデータのコピーを作るのではなく、データを複数に分割し、その分割したデータとセットでパリティを付与します。障害が発生した際は、データとパリティの逆行列を掛け合わせることでオリジナルのデータをリカバリできます。つまり、データそのものののコピーをもつのではなく、復元に必要な値（パリティ）をデータセットと組み合わせてもつことで、ディスクスペースを効率的に使うことを可能にしているのです。

なお、データは従来のHDFSのように64MBではなく、1MBのブロックサイズに分割され、ディスクへの書き込みはチェーンレプリケーション方式ではなく、パラレルに行われます。つまり、Hadoopがあまり得意ではなかった小さなサイズのファイルの扱いがイレージャコーディングにより強化されることになります。

小沢PMCはイレージャコーディングの利点として、チューニングの柔軟性が高いこと、そしてディスク効率が高いことを挙げています。たとえばデータが6ビット、パリティが3ビットというチューニング（RS(6,3)と表現する）の場合、これまでの3コピーを必要とするのに比べ、ディスクの容量は半分で済みます。

イレージャコーディングでストレージをどう配置していくかについては、現在2つのアプローチが検討されているとのこと。ひとつは「Striping（ストライピング⁠）⁠」で、HDFSで通常に実装されている64MBではなく、より細いブロックにデータを分けて複数のノードに配置していくというもの。もうひとつは「Contiguous（連続したブロック配置⁠）⁠」で、現在のHDFSと同様に、ファイルを連続したブロック配置にするものです。どちらも長所と短所があり、Stripingでは、小さなファイルにとって効率が良く、スループットもディスク効率も向上しますが、データが細かく分散されるため、読み込みの際にローカリティが損なわれてしまいます。一方、Contiguousの場合はローカリティは単純なので読み出しは容易ですが、小さなファイルの扱いは困難になります。

良いことずくめのように見えるイレージャコーディングですが、やはり課題も存在します。小沢PMCが強調していたのは「ネットワークトラフィックの負荷」で、クライアント/サーバ間で要求される帯域が非常に大きいことを指摘しています。頻繁にアクセスのあるホットデータにはあまり適しているとはいえませんが、逆に「アクセス頻度の少ないコールドデータがほとんどで、しかもファイルサイズが小さい場合、イレージャコーディングは非常にすぐれたオプション」と小沢PMCは指摘しています。「⁠これまでのノウハウがイレージャコーディングにより、すべて変わる」（⁠小沢PMC）というほど大きなインパクトをもつ新機能はHadoopの活躍範囲をさらに拡げてくれそうです。

なお、Hadoop 3.0のリリーススケジュールについては、小沢PMCとともに登壇したHortonworksのJunping Du氏（PMC）が、現時点での予定を以下のように説明しています。

• 2016年9月3日 … alpha1
• 2016年Q4（12月中⁠）⁠ … alpha2
• 2017年Q1早期 … beta1
• 2017年Q1またはQ2 … 正式リリース

この予定を見る限り、2017年6月あたりがいちおうの目安のようです。

Du氏のプレゼンは、Hadoop 3.0におけるYARNの機能強化についての説明が中心で、その中でも注目されている履歴管理のTimeline Server v2（ATS v2）については「⁠（⁠シングルインスタンスのWriter/Reader、LevelDBベースのストレージなど）v1の制限項目を取り払い、スケーラビリティやパフォーマンス、信頼性の面で劇的に向上する」と語っています。

またプロセスと並行してDockerコンテナを起動できるようにするなど、コンテナ関連のサポートも強化され、よりクラウドフレンドリなHadoopへと進化するとのこと。イレージャコーディングをはじめ、多くの機能強化がはかられたビッグマイルストーンとなるHadoop 3.0 ―約半年後の正式リリースに向けて、PMCやコミッターたちの忙しい日々は当分続きそうです。