あけましておめでとうございます。
今年も大規模データ向けの分散処理フレームワークの展望についてご紹介します。例年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） などは、大規模データ処理におけるストレージの選択肢が増え、多様化したことを反映しているという印象です。周辺プロダクトやクラウドサービスの動向と合わせて、動向をフォローするとよいでしょう。
酒井遼平氏（左）と田中正浩氏
Spark
2018年はSpark 2.3と2.4のフィーチャーアップデートバージョンがリリースされました。これまでと比べて目玉となるアップデートが多かったように思います。
猿田浩輔氏
Kubernates対応とPython対応の強化
昨今Kubernetesの活用が活発になってきており、SparkもKubernetesへの対応が始まりました。2.3ではまだ機能不足感が否めませんでしたが、2.4ではPySparkが動作するようになったほか、クライアントモードをサポートしたことでSpark Shellからの利用が可能になるなど、少しずつプロダクションレディーに近づいています（[SPARK-18278]SPIP: Support native submission of spark jobs to a kubernetes cluster 、[SPARK-23984]PySpark Bindings for K8S、[SPARK-23146]Support client mode for Kubernetes cluster backend ） 。
クラウドでのSparkの活用も活発になってきましたが、Kubernetesがサポートされたことによってこの流れがさらに加速するかもしれません。多くのユーザに使われることによって、Kubernetes対応の完成度も劇的に向上していくのではないかと思われます。
PythonユーザにとってはPandas UDF（SPARK-21190） は嬉しい機能のひとつだと思います。
これまでSpark SQLをPythonから利用する場合、Pythonで書かれたUDFの呼び出しがパフォーマンスのボトルネックになるケースが散見されました。これはJVMとPythonインタプリタ間の通信に伴うシリアライズ/デシリアライズが非効率だったことや、Pythonインタプリタ側でのデータ処理効率が良くなかったことが原因です。Spark 2.3からPandas UDFと呼ばれる機能が導入され、Pandasと連携することで複数のレコードを同時に処理するUDFが記述できるようになりました。また、これに伴ってJVMとPythonインタプリタ間のシリアライズ/デシリアライズ効率を、Apache Arrowを利用して改善しています。
Structured Streamingの改善
2017年にアルファ版を卒業したStructured Streamingも依然として開発が活発です。とくにContinuous Processingと呼ばれる、新たな実行モードが導入されたことが大きなトピックです。従来はMicrobatch Processingと呼ばれる、マイクロバッチによるストリーム処理の実行方式のみをサポートしていました。
Microbatch Processingでは、マイクロバッチごとにExecutor（スレーブノード上で実際のデータ処理を行うプロセス）にタスクを配布します。マイクロバッチに同期してオフセットログ(データソースから次に読み出す位置が記録されたログ)が書き出される実装になっているため、どうしてもエンドツーエンド（データの受信から処理結果を対向側に受け渡すまで）で秒オーダーの時間がかかってしまいます。
Continuous ProcessingではロングランニングタスクをExecutor上に常駐させることで都度のタスクの配布を回避するほか、各タスクが読み込んだオフセットを非同期的にドライバ(分散処理全体のスケジューリングなどを行うプロセス)にレポートすることで、オフセットログの書き込み性能の向上も図っており、エンドツーエンドでミリ秒オーダーでの処理を実現可能にします。
AIを指向したProject Hydrogen、利便性向上が続くSpark SQL
また昨今なにかと「AI」というキーワードが出てくることが多いですが、SparkでもAIを指向したProject Hydrogenと呼ばれるサブプロジェクトが始まりました。Sparkでは従来からMLlibやSpark MLなど機械学習のためのコンポーネントが備わっています。これらは各種学習/最適化アルゴリズムなどをSpark上で実行するためのものだったのに対し、Hydrogenの取り組みはどちらかというと、機械学習やディープラーニングなどを支えるインフラのエンハンスメントという色合いが強いように思います。
Project Hydrogenでは大きく3つの取り組みが計画されています。
Barrier Execution Mode（SPARK-24374 ）
分散ディープラーニングなどに求められる、タスク間の通信や同期を支援する機能
Optimized Data Exchange（SPARK-24579 ）
Sparkとさまざまなディープラーニングフレームワークとの間で効率的にデータ交換を行うためのデータフォーマットの策定など
Accelerator Aware Scheduling（SPARK-24615 ）
GPUやFPGAなど、利用可能なアクセラレータの種類や数などを考慮したタスクスケジューリングを行う機能
Spark 2.4の時点ではBarrier Execution Modeの基本的な部分が実装されました。
このほかSpark SQLではハイオーダーファンクション（配列やマップなどのデータ構造を対象とした関数）をはじめとしたビルトイン関数の実装も充実してきたり（SPARK-23899 ） 、イメージデータの入出力を簡素に行えるAPIが整備されたりと（SPARK-21866 、SPARK-22666 ） 、従来からの機能も着実に利便性の良いものに進化し続けています。
2019年のSpark
2019年はSpark 3.0がリリースされる見込みです。2016年にリリースされたSpark 2.0から、実に約3年ぶりのメジャーバージョンアップとなります。3.0になにを盛り込むかは現在ディスカッションされていますが、ユーザに特に影響の大きいところでは、依存しているライブラリやミドルウェアのバージョンアップがあげられます。
主要なものは以下の通りです。
Java 11対応
Scala 2.12対応
Hadoop 3系対応
Hive 3系対応
Scala 2.12への対応は以前から要望が多く、Spark 2.4ではScala 2.12向けにビルドされたバイナリが実験的に配布されていますが、Spark 3.0からは標準でSpark 2.12に対応する見込みです。Hadoop 3系対応に関しては、実はSpark 2.4の時点でpom.xmlにHadoop 3.1向けのプロファイルが定義されています。しかしSpark 2.4まででサポートしているHiveのバージョンと、Hadoop 3系との間で一部APIの互換性がないため、Hadoop 3.1に対応させつつHiveの機能を利用可能なようにビルドすることはできません。そのため現在はHadoop 3.1向けにビルドされたSparkのバイナリは配布されていません。Spark 3.0ではサポートするHiveのバージョンアップを行うことで、Hadoop 3系にも対応していくはずです。
また現在は実験的導入の扱いとなっているKubernetesサポートについても、2019年のどこかのタイミングではプロダクションレディーが宣言されるでしょう。
このほかProject Hydrogenは引き続き進められる予定です。Spark 2.4ではBarrier Execution Modeの基本的な部分が実装されましたが、残りの2つについても取り組みが進められるはずです。現時点でまだデザインドキュメントが公開されているだけですが、徐々に実装が出てくるでしょう。
Kafka
Apache Kafkaは分散メッセージングシステムのデファクトスタンダードとしてここ数年急速に成長していますが、その傾向は2018年も続きました。
佐々木徹氏
堅実に成長したKafka
7月には昨年の1.0.0に引き続きのメジャーバージョンアップとなるKafka 2.0.0がリリース されました。このバージョンではJava 7のサポートが打ち切られたほか、ScalaベースのProducer/Consumerのソースが削除されました。それ以外にもセキュリティなどで多くの機能追加や改善が実施されています。
また、11月には2.1.0がリリース され、新たにJava 11が正式にサポートされるようになりました。
Kafkaの本体だけでなく、その周辺でもさまざまな変化がありました。
代表的なところでは、Kafkaと組み合わせてSQLライクな言語でストリーム処理を記述できるKSQLが、4月にProduction Readyになりました 。Kafkaの主要ディストリビュータのConfluent社が提供しているConfluent Platformの4.1からKSQLのパッケージが含まれるようになっています。データ処理をSQLやSQLに近い言語で行いたいという要望は従前からありますが、新たな選択肢が増えたことはKafkaユーザにとって嬉しいことだと思います。
またConfluent社が提供しているKafkaのクラウドサービスであるConfluent Cloudで、クラウドプロバイダとしてGoogle Cloud Platformが選択できるようになりました 。以前はAmazon Web Serviceがクラウドプロバイダとして選択できましたが、ここに選択肢が増えた格好です。
11月にはAmazon Web ServiceからKafkaのマネージドサービスであるMSK（Managed Streaming for Kafka） が発表されました。現在はパブリックプレビューの段階ですが、将来的にはこちらもKafkaの利用シーンを広げることが期待されます。
Kafkaコミュニティの広がりと2019年への期待
Kafkaのユーザコミュニティも引き続き、そして確実に拡大しています。
2016年から開催されている、KafkaをテーマとしたカンファレンスであるKafka Summitについては、米国外では初となるKafka Summit London 2018が4月に開催されました。また、10月に開催されたKafka Summit San Francisco 2018は、前回より広い会場に移り、開催も2日間となるなど、Kafkaの利用者拡大を受け、その規模が徐々に拡大しています。
また、Kafka Summit以外のカンファレンスでも、Kafkaをテーマとした発表が多くみられました。AIをはじめとするデータ活用が広がる中、各方面からのデータを受け止めるツールとしてのユースケースが多い印象です。9月に行われたStrata Data Conference New York 2018では、NTTデータからも発表を行いました 。
他のプラットフォームと同じようにKafkaも、コンテナ環境で利用するケースが見られるようになりました。カンファレンスで発表された利用事例も複数あり、Confluent社からもKubernetes利用に関する発表 がなされています。
書ききれなかったトピックも含めて、2018年はKafka本体、周辺環境、ユーザコミュニティの各方面で堅実な成長がみられました。Kafkaがこの分野のデファクトスタンダードとなり、広がっていることが実感できる1年だったと感じます。手軽にKafkaとストリーム処理を利用できる環境やツールが増えたことで、2019年にはさらなる飛躍が期待されます。
吉田耕陽氏
まとめにかえて
ユーザの裾野は広がる一方で、開発コミュニティとしては大規模ユーザ向けの開発が続くHadoop、Kubernates対応などのトレンドも取り込みつつ、AI対応の開発が続くSpark、メッセージシステムのデファクトとして利便性を上げる方向に着実に進化を続けるKafkaと、3者3様の状況をご理解いただけたかと思います。
世の中的にクラウドシフトがますます加速していく中においても、クラウドベンダからこれらのマネージドサービスがリリースされ続けている状況を見ると分散処理フレームワークの利用ニーズは2019年も継続していると見るべきでしょう。これらの動向からまだまだ目が話せません。
本稿がみなさまにおけるこれからの Hadoop, Spark, Kafka の利用に関する一助となれば幸いです。2019 年もよい1年となりますように！
