³⁄₁₄ に開催された Hadoop / Spark Conference 2019 Japan に行ってきました。参加したセッションの内容と感想を書いてみました。

Hadoop / Spark Conference Japan 2019 ご挨拶・開催にあたって

「Hadoop もう終わりつつあるのでは？」と思われがちだけど、HDFS とか YARN といった技術は分散並列処理の基盤として主流だよ、という話。実際「Hadoop」という文字を Web の記事等で目にすることはかなり少なくなりましたが、分析基盤の構築の事例はまだ結構見るので、それらを支える技術として進化しているようです。

Apache Hadoopの現在と未来

参加申請の時に取ったアンケート結果の発表から。オンプレでの運用が多いのと、Kudu を使っているところがあったのが面白いな、と。あとは新機能の Hadoop Submarine, Hadoop Ozone が面白そう。この発表の時の話だったか忘れましたが、HDFS の Erasure Coding の導入によって、データの Locality を気にしなくなってきている、という話をもうちょっと聴きたかった。実運用ではもうあまり気にしなくても変わらないものなんですかね？

The upcoming Spark 3.0: What’s Next

Spark 3.0 の話。「GPU Aware Scheduling」とあったので、Spark はすでに計算処理に GPU を使うようになっているんだろうな。どういう条件で使うようになっているか気になるところ。「Data Source API V2 transactional write, columnar scan」ももうちょっと調べてみたい。Transactional Write といえば Iceberg で実装を進めていますが、それとは別に Spark 独自で実装する、ということなのかな。Columnar Scan も現在どのような実装が使われていて、どのあたりが課題なのかは気になるところです。以前、Uber が Presto で Parquet File を Scan する際に、元々の実装だと Columnar Scan の効率が悪いので別の実装を作ったという話がありましたが、同じようなことなのかな。

Cloud-Nativeなデータ分析基盤におけるPrestoの活用

SmartNews の分析基盤の話。Presto の利点は、クエリのレイテンシと複数のデータソースから集約できるところですかね。独自の Connector や Function を実装しているとのこと。

OASIS : LINE’s Data Analysis Tool Using Apache Spark

Line で社内で分析する為に Notebook Application を独自で作った、という話。Data Permission や Workload Control を考えると、既存のツールをそのまま使うのが難しい、というのは凄く良く分かります…。このカンファレンスでこういった話が聴けると思ってなかったので、思わぬ収穫でした。とても面白かった。

1日100個以上のHadoopクラスターを使い捨てる方法

「Hadoopクラスターを使い捨てる」とあったので、AWS EMR の話かな、と思ったらそのとおりでした。最近は AWS を全然触らなくなったので、このセッションで「c5.18xlarge」が出ていることや「AWS Glue Data Catalog」という新しい機能を知りました。EMR クラスタの落とし忘れとかよく分かります…。

Ozone: An Object Store for Apache Hadoop

Hadoop の新しいオブジェクトストア、Ozone のセッション。Small Files を扱うことができ、Scalable で、HDFS のインターフェースと互換性があり、また S3 のツールでも操作できる、ということでした。また、HDFS と Ozone (Hadoop Distributed Data Storage)を併用することもできそうです。Name Node の役割を担う Ozone Manager と BlockServer の役割を担う Storage Container Manager がそれぞれ scale できるようになっている、という話でした。

「Yosegi」で実現する スキーマの柔軟性と処理性能を両立したログ収集システム

Schema-on-read のスキーマ柔軟な性質と、Schema-on-write の処理性能の良さの両方を備えた Yosegi の話。両方の性質を持ったファイルフォーマットが欲しいと思うことはあっても、それを実装して運用しているところまで到達しているのは凄い。しかも TPC-H の bench は Parquet よりも優れています。ログ収集の仕組みの中に Kafka の Schema Registry があったので、スキーマの変更が入るとこれがキツいんだろうな…。今までどうしてたのか気になります(Schema Registry で苦労しているので…)。

Arrow_Fdw – PostgreSQLで大量のログデータを処理するためのハードウェア最適化アプローチ

PostgreSQL の Foreign Data Wrapper(FDW)の仕組みを使い、Apache Arrowのデータに対してクエリを実行できるようにした話。また、PostgreSQL のレコードを Arrow の形式に変換する Pg2arrow というツールも実装した、とのこと。Arrow データはパーティショニングして配置できるようになっており、不要なパーティションは Scan しないようになっていました。このセッションの最後に、カラムナフォーマットの中から Arrow を選んだ理由について質問させてもらいましたが、Arrow は圧縮が無いので、ということでした。その後の質問で出ていたクエリ処理の話は、Gandiva のことかな？

Conclusion

久々にカンファレンスに参加しましたが、色々と面白い話が聴けて良かったです。