3月14日（木）にHadoop / Spark Conference 2019が開催されました。このイベントの参加メモになります。
目次
- プログラム
- 1. Hadoopの現在と未来：鯵坂 明さん、Arpit Agarwalさん
- 2. The upcoming Spark 3.0: What’s Next：猿田 浩輔さん、Xiao Liさん
- 3. Cloud-Nativeなデータ分析基盤におけるPrestoの活用：廣瀬 智史（SmartNews, Inc.）
- 4. DataFrameとDatasetの内部をのぞいてみる：石崎 一明（日本アイ・ビー・エム）
- 5. スキーマレスカラムナフォーマット「Yosegi」で実現するスキーマの柔軟性と処理性能を両立したログ収集システム：井島 洸二さん
- 5. Apache Kafkaって本当に大丈夫？～実際にいじめてみたのでお伝えします～：土橋 昌さん
同イベントは毎年開催されているわけではなく、近年は開催されていなかったらしい。そんなわけで「Hadoopはオワコンなんだね」と巷では認識されることもあるが、ちゃんと進化してますぜ！ということをこのイベントではアピールしたいらしい。（※旧MapReduceは確かに下火ですが、HDFSはバリバリ活躍中ですよね。）
※Hadoop/SParkの初心者の方は以下の勉強会資料をご参考ください。 speakerdeck.com
プログラム
黄色線が引かれた講演を、私自身は聴いてきました。いくつか本ブログでも共有したいと思います。
1. Hadoopの現在と未来：鯵坂 明さん、Arpit Agarwalさん
「Hadoopの利用状況」に関する事前アンケート結果
※あくまで参加者のアンケート回答であり、正しい現状を示しているとは限らないので注意してください。
- Hadoop利用者の1/4くらいはHadoop 3系を既に利用。2系から3系へと検証／導入が進んでいる。
- オンプレミス環境での利用者が60%くらい。オンプレ優勢もクラウドでの利用ユーザが拡大している。
- クラスタ数は～10台と小規模なクラスタ構成が45%程度と多い。
Hadoop 3系がリリースされたのは、確か2017年の12月くらいだったと思うので、この1年ちょっとで徐々に浸透し始めているということだと思います。
並列分散処理の取り巻く動向
現在の並列分散処理の取り巻く動向としては、下記4つが挙げられており、この動向を受けて、Hadoopエコシステムも進化を続けている模様。
個人的には、TensorflowやPytorch等のカバーを目指している点に注目。
オブジェクトストレージ機能『OZONE』の紹介
- Ozoneは、HDFS上にオブジェクトストアを実装し、（Amazon S3やAzure Storageのような）オブジェクトストレージとして利用可能にする技術。HDFSの良い部分はそのままに、HDFSと併用可能かつ移行可能な技術。
- 「多数のオブジェクトを格納したい」、というHDFSが苦手とする領域をカバーする目的で開発が進んでいる。
- 現在はまだアルファ版。今後ベータ版も出す予定。Hadoop／Sparkのエコシステムはそのまま利用可能。
what is ozone #hcp2019 Hadoopにオブジェクトストレージの機能を追加する機能。 pic.twitter.com/jk8lPHq46L
— いしお (@Ishitonton) 2019年3月14日
www.slideshare.net
2. The upcoming Spark 3.0: What’s Next：猿田 浩輔さん、Xiao Liさん
Sparkに関するこれまでの振り返りと今後の展望について共有がなされました。
振り返り
2018年の12月末にはSpark2.4がリリースされている。Sparkは、Unified Data Processing Engineとして着実に進化。バッチ処理、ETLでの活用が依然として多いが、新たに「IoTやアナリティクス領域」でのデータ活用を取り込めている。Spark2.0以降では、これらのデータ活用に即した機能追加も行われた（ex：Structured Streaming／Pythonからの利用における利便性向上／PandasUDFなどの拡充）。詳しくは下記資料にまとめられています。
一方で、現在の課題としては「AI領域の需要取り込み」が挙げられます。昨今は機械学習やDeep Learningがトレンドとなっているが、この領域の活用を取り込めていない現状があるとのこと。
Spark3.0の展望について
CIOへの調査報告によると、AI分野への投資が増加しているが、成功例は少ない。Unified Analyticsが成功のカギと言っている。79%のCIOがUnified analytics Platformとして、データサイエンスとデータエンジニアリングの統合を評価しており、AI領域においても、AIとデータの統合的なアプローチが期待されている。これを受けた下記のような展望。
Project Tungsten
- メモリの利用効率改善やモダンなCPU機能の活用によりCPUネックの解消を行うプロジェクト。
- 分散実行されるDeep LearningのジョブをSparkのStageとして埋め込むために、ギャングスケジューリング機能を追加する。これにより分散学習のワークフローが簡素化される。
MLflowの導入
- Data Source API 2.0
- クエリ実行時の再最適化
- クエリが完了した後の統計情報をもとに、実行計画を再最適化させる
3. Cloud-Nativeなデータ分析基盤におけるPrestoの活用：廣瀬 智史（SmartNews, Inc.）
既に資料は公開されています。
2014年当時は、Amazon S3上のデータをMapReduce処理してMongoDBに蓄積していた。課題としては、データを気軽に分析できる環境ではなかったこと。新しい集計処理が必要になる度にMapReduce処理を追加する必要があったし、新たな可視化ニーズの度にアプリケーションの修正が必要になっていたとのこと。
そこで、「Amazon S3 + Presto + Hive」の構成に変更。ETL／バッチ処理はHive（Hive metastoreのデータを参照）、リアルタイムデータ集計はPrestoを利用。これにより、ストレージとコンピューティングリソースを分離することができ、またSQLを書けば、誰でもデータ分析できるようになった。
また、利用用途ごとに要求が異なるため、クラスタを使い分けて利用している（例えば、広告配信はシビアな要求が求められるが、ニュース配信はそこまでではない）。これにより依存性を局所化しているが、その結果データが分散する状況にもなる。そこで複数のデータソースに対するリクエストを可能とする「Presto」をインタフェースとして利用し、この問題を解決している。 また、EMRではなくEC2上にPrestoクラスタを構築することで、デフォルトのPrestoには存在しないコネクターや、独自のファンクションの追加を行っている。Prestoは開発が盛んなので、最新版を試せる環境にしておきたいとのこと。
4. DataFrameとDatasetの内部をのぞいてみる：石崎 一明（日本アイ・ビー・エム）
資料公開されています。個人的にとても面白かったです！！
www.slideshare.net
Sparkで実装する上で、RDDやDataFrameやDatasetなどの選択に迫られる。DataFrameはSQL由来なのでループ処理の記述が難しいが、一方DatasetはScala由来なので簡単に記述できる。ただし、同じ処理でもDatasetはDataFarmeと比較して処理が非常に遅い、という二者択一状態。機械学習のアルゴリズムを記述する場合、ループ処理が書けないと結構大変なので、Datasetの処理性能改善を加えていっている、という話。Spark2.2以降でだいぶ改善されている模様。 Sparkの仕組みとして、DataFrameやDatasetは様々な最適化（Catalyst）の末、最終的にJavaのコードを生成する。PythonとかScalaのまま実行されるわけではない。それぞれ最適化の仕方が異なるので、処理性能に違いが生じる。 DatasetとRDDでは、現状は性能差があるため、SparkのMLアルゴリズムではほとんどRDDへの変換後に実行されているのが実情（？）。本来はRDDへの変換にオーバーヘッドコストがかかるため本当はやりたくない！でも現状はまだまだRDDがメインストリームということなのだろうか。
5. スキーマレスカラムナフォーマット「Yosegi」で実現するスキーマの柔軟性と処理性能を両立したログ収集システム：井島 洸二さん
資料公開されています。
ヤフーで日々発生する多種多様なサービスのログは、リアルタイムに収集しHDFSに格納している。データを利用するデータサイエンス部門が試行錯誤を繰り返すために、ログの仕様変更（つまりスキーマの変更）が日々行われる（らしい）。
スキーマ定義には2つの方法がある。
- Schema on Read：利用時にスキーマを定義する
- 収集時に制約が少ない／保存時の効率化が難しい
- Schema on write：保存時にスキーマを定義する
- 収集時に制約が多い／保存時の効率化が容易
ヤフーでは、Schema on Readを採用。理由は多種多様なサービスからログが生成されるため、スキーマ定義のコストが大きいため。一般的には、JSONファイルなどが利用される。
一方で、カラムナフォーマットについても検討する必要がある。カラムナフォーマットは、データベースの分析用途に利用されるファイルフォーマットの1つ。大量データを扱う際に効率的に圧縮してストレージコストを下げたり、計算時に必要なデータだけを取り出して計算コストを小さくできる設計がされている。代表的なフォーマットにはORCやParquetがある。カラムナフォーマットへの変換には、事前のスキーマ定義が必要になる。
このように、多様なスキーマにはJSON、膨大なログ量にはカラムナフォーマットが選択肢としてあるが、スキーマの柔軟性と処理性能はトレードオフの関係にある。そこで、スキーマレスカラムナフォーマット「Yosegi」を開発したという話。スキーマの柔軟性と高い処理性能を両立しつつ、スキーマ管理が不要なログ収集システムを実現しているようである。YosegiはGithubでも公開されている。
5. Apache Kafkaって本当に大丈夫？～実際にいじめてみたのでお伝えします～：土橋 昌さん
正直、知見があふれまくってたので。資料公開をお待ちしています。この発表では、Kafkaの障害における様々な検証をしてくれています。
Kafkaは、データハブとして、ストリーム処理のパイプラインとして、そしてスケーラブルなメッセージングキューとして利用されるメッセージングシステムです。Consumer、Broker、Producerで構成され、さらにZookeeperを利用してHA構成を取りますが、それぞれのコンポーネントが故障した時に、Kafkaの挙動はどうなるのかを実際に各コンポーネントに障害を起こして検証しています。バージョンの違いでKafkaの構成は異なってくるため、一概にこの検証がそのまま役に立つわけではないと思いますが、検証結果や検証項目の考え方は非常に勉強になるものでした。
故障検証のサマリーとしては、公式ドキュメントに記載されたアーキテクチャから想像される挙動とおおむね合致するが、実際の挙動のうちZookeeperのアンサンブル故障と、データファイル（ログファイル）の異常については特に注意したほうが良いよ！という内容でした。
