あけましておめでとうございます。

今年も大規模データ向けの分散処理フレームワークの展望についてご紹介します。例年Apache HadoopとApache Sparkを中心にお届けしておりましたが，今年はこれらに加えて，2018年に活用が広がりが認知された分散メッセージシステムのApache Kafkaについても 同様に取り上げたいと思います。

今年は，NTTデータに所属するエンジニアの中でも特にHadoop，Spark，Kafkaなどに深く取り組んでいる 岩崎正剛（Hadoopコミッタ⁠）⁠，猿田浩輔（Sparkコミッタ⁠）⁠，都築正宜（Sparkコントリビューター⁠）⁠，吉田耕陽，佐々木徹（Kafkaコントリビューター⁠）⁠，酒井遼平，田中正浩（Hadoopコントリビューター）というメンバーでディスカッションした内容をもとに構成しています。

Hadoop

Hadoopは2018年に入っても活発に開発が進められています。主に大規模ユーザ向けの改修が目立っており，YARN，HDFSともにより大きなクラスタを扱えるようにするためのフェデレーション機能の開発が進んでいたり，Hadoopクラスタ上でオブジェクトストレージを実装するOzoneに代表されるHDDS（Hadoop Distributed Data Storage）の開発が進められていたりします。

本稿では上述のHadoopの開発動向そのものよりも，Hadoopが成熟し，適用に広がりを見せていることを示すエピソードを2つほどご紹介したいと思います。

Hadoop 3系リリースとエコシステムとの互換性問題

2017年12月にHadoop 3.0.0がリリースされ，SparkやHiveといったエコシステムのプロダクトでもHadoop 3対応が進められました。その過程でHDFSのデフォルトのポート番号の変更（HDFS-9427）には，移行の妨げとなる部分があることがわかりました。

Hadoop 2系のHDFSでは，NameNodeやDataNodeといったサービスが50010や50070のようなポート番号を利用していました。これらはエフェメラルポートの範囲に含まれるため，同じ番号を一時的に利用している他のプロセスが存在すると，サービスの起動に失敗してしまいます。そのため，Hadoop 3.0.0ではポート番号のデフォルト値が，9800番台周辺に変更されました。

ここで問題となったのが，NameNodeの8020番が9820番に変更されたことです。HDFS上のファイルにアクセスする際，hdfs://nn01:8020/a/b のようなNameNodeのホスト名とポート番号を含むURIを指定することができます。そのため，Hadoop関連プロダクトのユニットテストや，ユーザが作成したスクリプトなど，8020がハードコーディングされている部分が，予想以上に多く存在したのです。とくに，既存のクラスタ内で利用されているHiveメタストアに8020番を含むURIが含まれているような場合，Hadoop 3への移行が難しくなります。

もともと8020番はエフェメラルポートの範囲外で本質的には変更不要であったことから，2018年3月にリリースされたHadoop 3.0.1では9820番への変更が取り消され，元の8020番に戻されました。

ポリシー上，互換性を損なう変更は，メジャーバージョンを上げる時にしか行わないことになっています。しかし，Hadoop 3への移行性に大きく影響することと，その時点でHadoop 3.0.0を商用利用しているユーザはまだいないとの判断から，例外的に互換性のない変更を含む3.0.1がリリースされ，3.0.0は非推奨バージョンとなりました。

昨年以前の本記事でも，Hadoopエコシステム内のプロダクト間の依存関係と互換性に言及しましたが，その難しさの一端を示すエピソードだと思います。

Hadoopに対する攻撃

2018年には，XbashやDemonBotと呼ばれる複数種類のマルウェアによる，Hadoopを対象とした攻撃が観測されました。インターネットからアクセス可能なHadoopクラスタを探し，ビットコインのマイニングやDDoS攻撃に利用するという内容です。

これらはセキュアでない設定のHadoopクラスタを標的にするもので，Hadoopの脆弱性を突いたというものではありません。セキュリティ機能を有効化していないHadoopクラスタでは，容易に別のユーザ権限で処理を実行可能です。このようなクラスタをインターネットからアクセス可能な状態に置くことは，当然避けるべきミスというべきですが，クラウドサービス上で気軽にHadoopを利用できるようになった昨今，攻撃対象となりうるクラスタも増えているのかもしれません。良くも悪くも，Hadoopが広く利用されていることを示す事例であると感じます。

また，セキュリティ機能を有効にし，クローズドなネットワーク内でHadoopを運用しているとしても，Zip Slipによるコードインジェクション（CVE-2018-8009）のような脆弱性が発見されることもあります。不特定多数のユーザがHadoopを利用するような環境では，セキュリティアップデートに注意を払う必要があります。

Hadoopディストリビュータの合併

今年Hadoop界隈を大きく騒がせたニュースが，Hadoopのパッケージを提供するディストリビュータの2大巨頭であるCloudera社とHortonworks社の合併です。2019年に合併されることが，2018年10月に発表されました。

2018年にはHadoop 3をベースとして，ClouderaがCDH 6を，HortonworksがHDP 3をそれぞれリリースしている状況であり，双方ともに積極的な開発が続いています。

Hadoop 開発者の目線で見たときに，Hadoopおよびエコシステムのプロダクトは，コミュニティベースで開発されるオープンソースソフトウェアなので，合併したとしてもそこが変わるわけではありせん。もともと技術者間の交流もあるため，そこは継続されるでしょう。

とはいえ，主要開発者の所属企業として，ClouderaとHortonworksが占める割合は大きく，Hadoopエコシステムに供給されるエンジニアリングリソースが，合併によってどう変化するのかは，気になるところです。

また，Hadoopの利用者目線で見たときに，類似の機能を持つプロダクトを，ClouderaとHortonworksそれぞれが主導して開発するような競争関係があるケースについても，変化が起こると予想されます。執筆時点ではどのようにマージされていくかについてはアナウンスはありませんが，この動向については注視しておく必要があるでしょう。

2019年のHadoop

Hadoop 3.0.0がリリースされた後も，開発は継続して行われています。冒頭で述べたような開発以外にも，Amazon S3上のデータにアクセスするためのS3AFileSystemの継続的な改善や，HDFS外に格納されたデータをHDFSと連携させるPROVIDEDストレージ機能（HDFS-9806）などは，大規模データ処理におけるストレージの選択肢が増え，多様化したことを反映しているという印象です。周辺プロダクトやクラウドサービスの動向と合わせて，動向をフォローするとよいでしょう。