Hadoop / Spark Conference 2019 に行ってきた

2016年以来、実に3年ぶりとのことです。

自分は最近業務でHadoopやSparkを触るようになってきたんですが、 元々この領域は全くといっていいほど経験が無く、社内にもガッツリ触ったことのある人はほんの一握りといった状況です。 多分遅れ取りまくってるんだろうなぁと思いつつ、一度他社のレベルの高さに打ち負かされてこようと思い、参加してきました。

以下、自分が見たセッションのメモです。(自分の記憶力と理解の無さ故に間違えてる可能性が十二分にあります。ご注意ください)

入場

これが噂の象。

f:id:romiogaku:20190315170041j:plain
あいつ・・・あの目

セッション

ご挨拶、ご案内 / 濱野賢一朗さん(日本Hadoopユーザー会)

資料

メモ

  • 本カンファレンスは2016年以来の開催。間が空いたのには特に理由はありません。
  • Hadoopは終わりつつあるのではと言われている
    • たしかにMapReduceは収束
    • HDFSは健在。でも実は大きな変化点を迎えた。
    • 並列分散処理を支える基盤として主流。まだまだ進化中
  • このカンファレンスは Hadoop,Spark に限らず並列分散システムに関する総合イベントです。

Apache Hadoopの現在と未来 / 鯵坂明さん(Hadoop PMC member)、Arpit Agarwal(Hadoop PMC member)

資料

要約

Hadoop2系、3系の利用者が増えてきた。 Hadoopはこれからも進化を続け、ディープラーニングまわりのHadoop {Submarine} ProjectやオブジェクトストレージのOzoneの開発が進んでいる。

メモ

  • 事前のアンケート結果紹介
    • 2系,3系の利用者が進む
    • クラウド利用も増えているがオンプレミス優勢。
    • クラスタ台数は10台までが多数。データ量はきれいに割れた。~10G~10PB~
    • 使ってるMWはHive、Kafka,Jupyter,Fluentd,Presto...
  • スケーラビリティ
    • Federationでクラスタを束ねる機能が追加され、マスタの負荷を分散できるようになった。
    • オブジェクトストレージ機能の開発(Ozone)が進んでいる。
    • HDFS Erasure Codingによるディスクの節約!
  • プロジェクト構成の変化
    • SubmarineOzone の追加。
  • Submarine
    • ディープラーニングに関する機能。
    • YRANの最新機能を活用して、TensorFlow, PyTorchなどをHadoop上で分散実行させる
      • GUP isolation, Docker on YARN, Container-DNS support
  • Ozone
    • Arpit氏がこのあと紹介します。
  • Hadoopの未来はどうなる>k8sとできることは変わらないはずなのに、k8sが今流行っている理由は? 利用しやすさ?
    • 元々の論文は同じだった。
  • 野望: Java11対応等、リリースサイクルの加速、プロダクトのさらなる分割?

The Ozone Object Store / Arpit Agarwal(Hadoop PMC member)

資料

...

要約

HDFSは従来、小さいファイルの格納が非効率だった。 ストリームデータ処理等、新しいニーズに対する処理を効率よく行えるようOzoneというオブジェクトストレージを開発している。 HDFSの完全上位互換? f:id:romiogaku:20190315170518j:plain

メモ

  • Ozoneとはオブジェクトストレージである。HDFSがあるのになぜ?
  • HDFSは小さいファイルの格納が非効率。3億ファイルぐらいが一つの壁。
  • 新しいニーズもでてきた
    • ストリームデータ処理
    • データソースとしてのS3
  • 既存のHDFSからそのまま移行できる、数十億ファイルを格納できるデータストアが必要だ!
  • Ozoneとは
    • HDFSの精神的続編
    • HDFSのよいところはそのまま
    • HDFSと併用可能
    • HDFSのデータをそのまま以降可能
    • NameNode (マスターノード)がボトルネックにならない
    • アプリケーションの回収は不要
    • 現状
      • 2つのアルファ番がリリース済み、3番目のアルファ版が準備中。ベータ版も3つ出す予定。
    • 設計方針
      • 強い一貫性
      • シンプルなアーキテクチャ
      • 実証済みの部品を使う(Raftによる冗長化、データはRocksDBで管理)
      • Hadoop,Sparkエコシステムの各種プロダクトが使える

The upcoming Spark 3.0: What’s Next / 猿田浩輔さん(Sparkコミッタ)、Xiao Li(Spark PMC member)

資料

...

要約

Spark2.4までの機能振り返り

Spark3.0、新機能続々!主に機械学習周りがアツそう。

f:id:romiogaku:20190315170729j:plain
spark2.4

f:id:romiogaku:20190315170810j:plain
spark3.0

メモ

  • Sparkはデータ活用のトレンドとともに進化してきた。機械学習とか。
  • 2.0では
    • Structured Streaming
    • Pandas UDF、ビルトイン関数の拡充。Pythonからの活用利便性向上..etc
    • Project Hydrogenの発表
    • 分散コンピューティングのトレンド
      • 2.3からk8sサポートが始まった。
      • でも今はやはりYARNと組み合わせた利用が圧倒的に多い。(事前のアンケートによると)
      • k8sサポートはまだ始まったばかり。安定性もこれから。
      • SparkのプラットフォームとしてはまだまだYARN一強。
      • 大量の計算資源を必要とするバッチならYARN、組織内の計算資源をシェアしてアドホックにサービスがが実行されるようなケースならk8s、のような選択も。
    • ハードウェアのトレンド
      • Project Tungsten(Spark1.5) では資源を使い切る、ということにフォーカスしてた
      • 3.0 Project Hydrogen
    • 使いやすさはユーザにしかわからない。ユーザはがんがん要望を送ってくれ!
  • 3.0では
    • シャオ氏にバトンタッチ。
    • 今年リリース。新機能は?
      • AI
      • Big data vs AI tecnology
    • Project Hydrogen: Spark + AI
      • Sparkのスケジューラを刷新し、分散実行されるDeep Learningのジョブを効率的に行えるようにし、これで分散学習のワークフローを簡素化。
      • GPUを考慮したスケジューリング。
      • 機械学習の本番運用には困難が伴う。
        • なぜ?
          • 機械学習のライフサイクルは手作業で統一性がなく、連携されてない。(前処理、モデルの構築、モデルの配信。。
      • mlflow tracking
      • mlflow projects
      • mlflow models
    • 既存のグラフライブラリの課題
      • GraphX : DataFrameに対応してない、あまりメンテされてない
      • GraphFrame: グラフのパターンマッチに制限がある、意味的に弱いグラフデータモデル
    • Cyper for Spark
    • Spark Graph
      • プロパティグラフ(属性が付与されたグラフ)とCyperクエリが与えられると、SparkがDataframeを返す
    • Data Source API V2
    • クエリ実行時の再最適化
    • Spark本体でのk8sサポート

Cloud-Nativeなデータ分析基盤におけるPrestoの活用 / 廣瀬智史さん(SmartNews, Inc.)

資料

要約

スマートニュースではチーム毎にクラスタがあり、データが分散している。 それらを跨いだ集計処理のためにPrestoを活用している。

OASISApache Spark を活用した LINE 全社のデータ分析ツール / 吉田啓二さん(LINE株式会社)

資料

要約

LINEではOASISというwebベースのアナリシスプラットフォームを開発し、様々な部署で様々なスキルセットを持つ人が利用している。 Apache Zeppelinが求めているものに近かったが、セキュリティと安定面で採用を見送った経緯がある。 OASIS上でsparkアプリケーションが書け、ステップごとに異なる言語で書くことも可能。(sparkのcreateTempViewを使っている) 今年中にOSS化を目標にしている。

[LT] スキーマ付き分散ストリーム処理を実行可能なFlinkSQLClientの紹介 / 木村宗太郎さん(dotData Japan)

資料

要約

弁当に夢中であまり聞けませんでした...

[LT] データサイズ2ペタ ソネット・メディア・ネットワークスでのImpala活用とHadoop運用 / 菅沼嘉一さん (ソネット・メディア・ネットワークス)

資料

要約

CDHのバージョンアップは本当に鬼門らしい。弊社でも古いCDHをどうするか検討してるけど、軽い気持ちでやっちゃダメなんだと認識。

[LT] SparkをRESTfulに利用できるApache Livyを導入した話 / 植草智輝さん(ヤフー株式会社)

資料

要約

Apache LivyはSparkをRESTfulに利用できるAPIサーバ。(OSS)

ヤフーで導入してみたが、Livy自体がHA未対応だったりして妥協したところもあった。

sparkジョブがLivy経由でできるようになった。これにより各自のjupyter notebookやzeppelinからSparkを利用可能になり、社内のspark利用者が増えた。

[LT] Introduction to Apache Hivemall v0.5.2 and v0.6 / 油井誠さん(トレジャーデータ株式会社)

資料

要約

諸事情で途中までしか聞けず。

DataFrameとDatasetの内部をのぞいてみる / 石崎一明さん(日本アイ・ビー・エム株式会社)

資料

要約

Datasetはラムダ式を使って処理が書けるので、ループを書けたりして便利。

が、DataFrameとDatasetで単純な処理を書いたところ、DSはDFに比べて何倍も遅いことが判明した。 Spark2.2ではコードを改良し高速化を実現できた。(まだ改善の余地はある)

ぜひDatasetを使ってみてほしい。issueを投げて声を上げてほしい。

Deep Dive into Spark SQL with Advanced Performance Tuning / 上新卓也さん(Databricks)

資料

要約

SparkSQLの内部構造について紹介。

最適化のためには実行プランを見たり、節度を持ってCacheを利用したり、Equal JOINしたりしましょう (自分にとっては難しい内容でした。)

スキーマレスカラムナフォーマット「Yosegi」で実現するスキーマの柔軟性と処理性能を両立したログ収集システム / 井島洸二さん(ヤフー株式会社)

資料

要約

多様なスキーマを扱え変更に強いJSONと、処理性能の良いカラムナフォーマット(ORC,Parquet)のいいとこ取りをしたようなデータフォーマットの「Yosegi」を開発した。

ネストスキーマが課題だったが、フラットスキーマへ変換することで対応した。

OSS化してるのでぜひ使ってみてください。 https://github.com/yahoojapan/yosegi

Hive/Spark/HBase on S3 & NFS -- HDFSを運用しない気軽なHadoop/Spark / 蒋 逸峰さん

資料

要約

Hadoopコンポーネントで一番事故りたくないのはHDFSHDFSの代わりにNFSやS3を使ってみよう。

sparkならURIスキーマs3a://とすれば良い。 rename処理に関してS3は遅いという特徴がある。LIST - COPY - DELETEという操作になる。 最適化コミッターを使いましょう。

Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~ / 土橋昌さん(株式会社NTTデータ

資料

要約

Kafka検証環境で様々な故障をおこして実験してみた。

概ね想定通りだが、Zkのアンサンブル故障とデータファイルの欠損内容によってはBrokerが起動しないことがあった。

検証時のversionは1.1.0だったので、最新だとまた異なるかもしれない。

メモ

  • 故障検証のoverview
    • version 1.1.0 (検証当時の最新)、Broker4台、3台がZookeeper同居
    • 故障例
      • 物理コンポーネントの故障を検証(物理
      • Brokerを物るじゃなくてなんらかの方法で故障させたり
      • zkを故障したり
      • マシンリソース不足を再現したり
      • ログファイルとインデックスファイルを何らかの形で故障させたり
    • 結論
      • 基本的に想定通り
      • Zkのアンサンブル故障は一部注意が必要
      • データファイルの欠損内容によってはBrokerが起動しないこともあった。
    • 公式ドキュメントに記載されたアーキテクチャから想像される挙動と概ね合致する。
    • Exactry Onceのメッセージ重複に関しては話が違ってくるので横に置いとく
  • Zkアンサンブル故障
    • Zk3台中2台が故障したときの挙動
    • client(producer,consumer)使ってエラー無くメッセージ送受信できるか調べた。
    • APIを使ってるConsumerは故障後はメッセージ送受信できなくなるが、新APIは故障後もできた。(故障後数十分程度は)
    • 旧はクラスタ情報の取得やOffsetの記録毎にZKを利用してる。新は直接は依存して無くて、BrokerがZK利用してるだけで、Clientは大丈夫。でも、Topicの情報取得はできなくなる。
    • 新でZK故障した後に一部のBrokerが停止した場合、一部Brokerが停止した際からメッセージの送受信が行えなくなる。
    • 考察
      • ZKを直接利用しないAPI、機構はアンサンブル故障後の刹那に停止するわけではない。
      • その後Broker故障などクラスタに状態に変化を及ぼす事象が生じたらその限りではない。
  • データファイル(ログファイル)異常
    • インデックスファイルとログファイルそれぞれに対して...
      • 存在すべきファイルが無い
      • 規定サイズと違う、内容がおかしい
      • ファイル自体をダミーファイルにして破損してる状況にしてみる
    • 結論
      • BrokerがGracefulでない停止後の起動では可能な限りのリカバリ処理が行われ、いずれのケースでもBrokerが起動する。(すごい) 
      • Graceful shutdownの場合、一部の状況において正常にリカバリされないケースが存在する。
        • Active segmentがおかしい場合、Brokerが起動しない
        • not active segmentの場合OK
    • 極力Kafka側でリカバーしてくれる挙動をしている。
    • 起動時のサニティチェックが、検証当時と今とで結構かわってきている。spark sanityCheckメソッド。1系と2系で結構違ってくるみたい。
  • クロージング
    • 概ね想定通り、一部注意。アンサンブル故障とログファイル異常。どちらも重要なものなので注意してね。

以下、見れなかったもの

Apache HBaseの現在 - 火山と呼ばれたHBaseは今どうなっているのか / 鈴木俊裕さん(Cloudera)

資料

機械学習、グラフ分析、SQLによるサイバー攻撃対策事例(金融業界) / 小野寺誠さん(マップアール・テクノロジーズ株式会社)

資料

...

1日100個以上のHadoopクラスターを使い捨てる方法 & Spark Streamingで全世界の混雑状況を20分ごとに集計 / 中里浩之さん(ソフトバンク) 濱田佑さん(ソフトバンク

資料

HDFSのスケーラビリティの限界を突破するためのさまざまな取り組み 〜エクサバイト級の分散ストレージを目指して〜 / 浅沼孝信さん(ヤフー株式会社)

資料

Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ 関山宜孝さん(Amazon Web Services Japan)

資料

Ozone: An Object Store for Apache Hadoop / Arpit Agarwal(Cloudera)

資料

...

HDFS におけるサポータビリティ(保守性)の改善について / 小林大輔さん(Cloudera)

資料

An Insider’s Guide to Maximizing Spark SQL Performance / Xiao Li(Databricks)

資料

Automation of Hadoop cluster operations in ARM Treasure Data / Yan Wang(トレジャーデータ株式会社)

資料

...

Spark SQL の性能改善の取り組み / 吉田啓二さん(LINE株式会社)

資料

マルチテナント Hadoop クラスタのためのモニタリング Best Practice / 平野智巌さん(楽天株式会社)

資料

Arrow_Fdw - PostgreSQLで大量のログデータを処理するためのハードウェア最適化アプローチ / 海外浩平さん(HeteroDB)

資料