White scenery @showyou, hatena

If you have any comments, you may also send twitter @shsub or @showyou.

Hadoop / Spark Conference 2019 感想とログ #hcj2019

イベント情報:

https://www.eventbrite.com/e/hadoop-spark-conference-japan-2019-tickets-56807065462

所感

Hadoop, YARNに関しては新しい情報はあまり無かった気がします。Hadoopは周辺のテクニックとかの話が多かったと思います。

HDFSに関してはOzoneというS3のような新ストレージが紹介されていました。

一方でSparkSQLのチューニングに関しては3連続でセッションが続いてました。内容とはしては

  • EXPLAINしてボトルネック見つけろ
  • とにかくMerge Joinはshuffle挟むんで遅いから、EXPLAIN ANALYZEしてBroadcast hash joinに持ち込め(HiveにおけるMap side joinみたいなもの?)

といった感じでした。

あと自分は観ていないですがKafkaのセッションが大人気だったようです。Spring XD・・ それとk8s(Kubernates)の勢いは驚異に感じてるようでしたね。Sparkも新しいバージョンでk8sサポートしてるようです。

PrestoとSparkSQLのどちらが早いかに関しては、懇親会で「メモリに乗り切るならPrestoの方が早い」とお聞きしました(あくまで伝聞なので注意)。

ただ現状Hadoopクラスタ用意出来るのって(AWSのEMRとかもあるものの)大抵オンプレミスでマシンを用意できるところに限られていて、小規模なとこはBigQueryに集約しちゃうんじゃ?って感じもします。流石にタブーなのか、会の中で一言もBigQueryって単語は出てこなかったですが。DPCTでリクルートテクノロジーズの方はHadoopからBigQueryに移ったようなことおっしゃってましたし。あと個人的にはBigQueryは完全ベンダーロックインなのも気がかりです。

さらに、Tensorflow/Pytorch on k8sとon Spark(+ on k8sもあるかもしれませんが)の棲み分けどうすんだって気もしました。

ログ(メモ)

基調講演

hamakenさん

Hadoopは終わりつつあるのでは?

Apache Hadoopの現在と未来

Ajs_kaさん@Yahoo Japan

事前アンケートの結果

Hadoopの現在と未来

  • 様々なデータストアに対応
  • クラスタを束ねることでマスタの負荷を軽減
  • オブジェクトストレージ機能の開発(Ozone)
  • HDFS Erasure Codingによるディスクの節約
  • Submarine: YARNの最新機能をつかって、TensorFlow, PyTorch等をHadoop上で分散実行させる

  • 現在の課題

  • 今後の野望

    • Java 11への対応
    • リリースサイクルの加速化

The Ozone Object Store

Arpitさん@cloudera

  • HDFSの限界

    • 小さいファイルが非効率
    • 3億ファイルが限界
  • New opportunities

    • Streaming
    • Cloud-like
    • S3 to ingest data
  • 以下を満たすデータストアが必要  - 既存のアプリケーションがそのまま動く  - 既存のHDFSからそのまま移行できる

What is Ozone

  • A spiritual successor to HDFS
  • Roadmap: support k8s
  • 最初は100億オブジェクトをサポート
  • ネイティブメモリを使ってJava GCを回避

Ozoneユースケース

  • オンプレのS3

What makes Apache Spark

猿田さん

  • バージョン2の途中でSparkの性能が10倍に上がった?
  • Spark 3.0 AI関連 Project Hydrogenがリリース
  • Structured Streaming
  • Pythonからの活用、Pandas UDF
  • AI/Deep Learning関連
  • Sparkの使われ方
    • バッチ、ETL、データ分析は多い AIはこれから
    • k8s: Spark 2.3からサポート
  • 現時点ではYARNの利用が圧倒的
  • Spark 3.0での予定:GPU, FPGAの活用等

What's Next for Apache Spark 3.0

Xiao Liさん@Databrics

Spark 2.4のMajor Features

  • Spark on K8s, Avro Support, Image source
  • Unified AnanyticsがAI成功の鍵
  • Unifying data science & engineering

Project Hydrogen:

  • gang scheduling DLのジョブをSparkのstageとして埋め込む
  • GPU Aware scheduling
  • Mlflow
  • Graphライブラリの課題:GraphXがあまり活発に開発されてない
  • Cypher: グラフライブラリの新版?

Data Source API v2

  • Streaming support, columnar scan, statics and data partitioning, Transactional CTAS, RTAS
  • クエリ実行時の再最適化
  • Navive Spark Apps on k8s Spark3.0のfeature:Hadoop 3.0 support

Cloud-Nativeなデータ分析基盤でのPrestoの活用

廣瀬 智史さん@SmartNews https://speakerdeck.com/satoshihirose/cloud-native-data-infrastructure-with-presto

  • 2014年当時:S3 -> MR(pythonのMR job) + MongoDB
  • Presto導入後:S3+ Presto + Hive
  • 今:Hive/Spark + EMR + S3, 広告配信と?でHive Metastoreが分かれている
  • Prestoでデータ統合をしている
  • PrestoはEMR使わずにEC2上にクラスタを構築している
  • 課題:バージョンアップ追従仕組み 監視強化 RCFile->ORCへの移行 Streaming Processingの拡充
  • Presto Software Foundation: Facebookじゃない団体で設立 PrestodbからPrestosqlへ分岐

OASIS: SPARK

Yoshida Keijiさん@LINE https://speakerdeck.com/line_developers/oasis-lines-data-analysis-tool-using-apache-spark

  • BI Dashboard
  • Security: Rangerでファイルへのアクセスを管理
  • マルチテナントのクエリ安定性を求めるためにSpark採用
  • ZEPPELINE使っていたが
    • スケジューラで実行するときに、別ユーザで実行できてしまう
    • yarn-clusterモードが使えず、1台に1Sparkアプリケーションを入れる必要がある OASIS
  • 1 notebook sessionに付き1 spark appricationとしてyarnに割り当てられる
  • HDFSへはノートブックのユーザでアクセスされる
  • サービスごとにSPACEを作り、SPACE内でnotebookは共有される
  • スケジューリング
  • DAU 200人ほど
  • Hadoop Cluster: 500 Datanode, 30PB, 150 hive database 1,500 hive tables
  • Data Engineering Meetup https://dem.connpass.com/event/120994/

C会場 LT

Flink SQL Client

Kimura Sotaroさん@dot Data https://www.slideshare.net/SotaroKimura/flinksqlclient-136105751 YAML, コードでデータの投入管理

(昼食とってた為メモなし)

Sonnet の Impala

菅沼 嘉一さん@So-net Media Networks https://www.slideshare.net/suganoo1/2impalahadoop

  • Total 2PB, 8TB/day
  • CDH 5.15
  • Data Node 20台: 8TB
  • メタデータ: AWS RDB
  • Impala: hiveから1時間毎にImpalaクエリ実行
  • データ容量が90%近くなると性能落ちる
  • DBパーティション数は20万/ Clouderaの推奨は3~5万
  • バージョンアップはどこかでミスがあるとインストールできなくなる(戻るは押さない)
  • Active-Stanbyを取っている。データコピーはdistcp

Sparkを使うためのApache Livy

@Yahoo Japan

  • Apache Livy: SparkをRestfulに使うAPIサーバ
  • Spark jobがLivy経由でされるようになった
  • Jupyter ZeppelinからSparkを利用できるようになった
  • HA対応まだしてない

Introduction to Apache Hivemall v0.5.2 and v0.6

myuiさん@Treasure Data

HivemallはHive, Spark(Dataframe, SQL, steram), Pig上で動く

  • 0.5.2: Birckhouse UDF, Field-aware Factorization Machines, Okapi BM
  • 0.6: Adam HD, Gradient Boostring, XGBoost, Sparse Vector, Support Spark 2.4
  • 0.7: Word2Vec, Multi-cass LogiReg, Grid search, Yarn SQL on hadoopは何がいいか? -> Tez+Yarnがいい。Sparkはリソース食いつぶす

1日100個以上のHadoopクラスターを使い捨てる方法 & Spark Streamingで全世界の混雑状況を20分ごとに集計

ソフトバンク株式会社 中里 浩之さん 濱田 佑さん https://speakerdeck.com/nakazax/how-to-throw-away-100-hadoop-clusters-a-day

  • 2016: ETL EC2 + Jenkins on EC2 -> Redshift スケールできない
  • Spark on EMR、1時間分のETLを1クラスターが担当
  • 1日48個(多い日は200個くらい)くらいEMRインスタンスが立っている
  • EMR:ステップ機能が使える
  • Lambda(Python)でRunJobFlowをコール、パラメータが非常に多い。HOCONを利用 時刻をプレースホルダにしてjenkinsから起動
  • Glue Data Catalog フルマネージドHiveメタストア SPOF回避、同時接続数制限なし

Deep Dive into Spark SQL with Advanced Performance Tuning

上新 卓也さん(Databricks)

https://www.slideshare.net/ueshin/deep-dive-into-spark-sql-with-advanced-performance-tuning

  • Databrick Platform: AzureとAWSで使用可能
  • Sparkアプリケーション、ライブラリもSparkSQLをベースにしている
    • MLlib, GraphFrameなど
  • Spark SQL : queries から RDDsへのコンパイラ
  • Run EXPLAIN Plan
  • Interpret Plan
  • Tune Plan

Delarative APIs:

 何をしたいのか を定義   SQL/ Hive QL, Dataset(コンパイル時に型情報が必要なのでJava, Scalaのみ)/DataFrame APIs   DataFrame APIはuntypedなフレーム処理、Datasetはtypeなフレーム処理

Metadata Catalog:

  • Hive metastore
  • temporary view manager
  • global temporary view manager
  • funtion registry(セッション毎に登録しなおす必要がある)
    - PySpark Python UDF / Pandas UDF
    - JavaによるNative UDAF インタフェース
    - Hive UDF/UDAF
    - Higher UDF
    

Partition metadata取得のコスト - Hive metastoreのアップグレード - Cardinalityの高いパーティションカラムを避ける - Partition pruning predicates

Cache Manager - プランが一致したときにキャッシュデータと置き換える - Cross session

Cache 多すぎるとディスクに書き出されることがあり、遅くなることがある。不必要にキャッシュしないことが大事

Optimizer

Planner

  • Logical PlanをPhysical Planへ コストに基づいて最適なPhysical Planを選択
  • Broadcast Joinが使えればMarge sort joinではなくこちらを使う(片方のテーブルがメモリに乗れば)
    • autoBroadcastJoinThreshold
    • 統計情報がたまにおかしくなるので、EXPLAIN ANALYZEを実行してを最新に保つ
  • Broadcast joinヒントを使って強制的にさせる
  • Equal joinを使う
    • =をjoin keyに含めたjoin
    • =があるとO(n),ないとO(n2)

Query Exection

  • Memory Manager
    • Spark.executor.memoryとspark.memory.fractionを、監視外メモリのため、余裕をもって設定する。Netty buffer とparquetwriter bufferはSparkが監視できない
    • Off-heapを有効化
  • Code Generator

Data Sources

  • computationとstorageの分離
  • Scan Vetorization(Parquet, ORC)を使う
    • JVMSIMDを利用しやすくなって高速化, Parquet 10倍早くなった事例も
  • Partitioning and Bucketing使う

An Insider’s Guide to Maximizing Spark SQL Performance

Xiao Liさん(Databricks)

https://www.slideshare.net/ueshin/an-insiders-guide-to-maximizing-spark-sql-performance

(注:資料公開されないと運営から言われていましたが、公開されました。感謝!)

Engineering manager

Focus: Catalyst Optimization & Tungsten Execution

  • Read Plan
  • Interpret Plan
  • Tune Plan
  • []? (わからず)

  • これまでのSparkはSQLのPlanが表示できなかった?? Spark 3.0で改善

  • なんで!=0(0.0でなし) で0.35のデータが弾かれるんだろう・・ -> Explainするとintにcastしてることが分かる
  • hiveでテーブルを作った場合、Hive serde readerはSpark native readerより遅いので、spark.sql.hige.convertMetastoreOrc = Trueを使う (注:hive-serde tableとnative tableの違いわからず) (注:Pushed downってなんだ?)
  • ORC(Spark navite table)使うと、自動でcastされることがある nestedPluneSchema, trueを使え
  • 1回別のセッションでクエリをキャッシュすると、別のセッションでも同じクエリならキャッシュが使われる
  • Job Tab in Spark UI
    • Jobs
    • Stages ○ ステージごとのタスク所要時間が分かる
    • Tasks
  • Executors Tab
    • メモリ使用量やデータ転送量が分かる
    • Thread dumpで詳細が分かる
  • Storage Tab
  • (Linkedinがqueueシステムを作ってる?) f:id:showyou:20190315094640j:plain f:id:showyou:20190315094709j:plain f:id:showyou:20190315094730j:plain f:id:showyou:20190315094749j:plain f:id:showyou:20190315094806j:plain f:id:showyou:20190315094829j:plain f:id:showyou:20190315094851j:plain

Spark SQL の性能改善の取り組み

Yoshida Keijiさん@LINE https://speakerdeck.com/line_developers/improving-spark-sql-performance

  • Cbo.enable = False ルールベース使う
  • ユーザのクエリを変えずに性能を向上させる

    1. 統計情報を使う
      • 例:sort merge join -> broadcast hash join
      • autoBroadcastHashJoinThrethord = 10MB 設定
      • OASISで作るとき、自動的に統計情報を取る?
    2. 独自最適化ルールを加える
      • hiveで作られたデータ、sqoopからロードされたデータはLOAD DATAが呼ばれ、統計情報が取られない
      • extraOptimization使って自前の最適化ルールを作る。今回の場合はデータ量見てbroadcast hintを加える
    3. CBOを使う
      • Spark 2.2.0~使用可能、ただしdefaultではcost baseはoff(DatabricsはCBO on)
      • join順番を最適化できる
      • CBO on で速度10倍
      • Cost=weight * numOfRows + (1.0 -weight) * dataSize weightはデフォルトで0.7。いかにカラムの統計情報を、最小限、自動的に取るかは課題
  • Q: 独自ルールを加えた時、テストをどう行っている?難しいと思うんだけど

  • A: テストは行っていない

マルチテナント Hadoop クラスタのためのモニタリング Best Practice

平野 智巌さん(楽天株式会社)

  • 楽天市場で使っているHadoop
  • サービスの例:CustomerDNA, Rakuten Airis(注:AIというかレコメンド?)
  • 420 Slaves, 30PB, 70000-80000jobs, 80teams, MR, Hive Tez, Spark, Spark ML, Sqoop, Hbase, Slider 4 clusters(Japan, oversea)
  • 600+ account, 70000+jobs
  • 細かなチェックできない、申請したら使ってもらう
  • Small Hadoop Admin Team: 2.5人+マネージャで回している

  • グラフの作り方 Graphite + Grafana

  • 最重要ダッシュボード
  • マルチテナント特有のダッシュボード

  • 中間ファイル格納用にSSDを追加することで、処理速度を改善

  • 7億ファイルあって限界が来ている
  • Q: Hiveでテーブル作るとHDFSがHiveユーザで作られる気がするが? A: 弊環境ではHiveテーブル作ると各ユーザで作られる
  • (注:しきい値設けてアラートをメールかチャットに飛ばせばいいのでは?と思いました)

おまけ

観てないので紹介だけ。

DataFrameとDatasetの内部をのぞいてみる

石崎 一明さん@日本IBM 東京基礎研

https://www.slideshare.net/ishizaki/hscj2019ishizakipublic

Hive/Spark/HBase on S3 & NFS -- HDFSを運用しない気軽Hadoop/Spark

Yifeng Jiang‏さん

https://www.slideshare.net/uprush/hive-sparks3acommitterhbasenfs

Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ

関山 宣孝さん@AWS

https://www.slideshare.net/ssuserca76a5/hcj2019-hadoop-sparks3/ssuserca76a5/hcj2019-hadoop-sparks3

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

井島 洸二さん@Yahoo Japan

https://www.slideshare.net/techblogyahoo/hadoop-spark-conference-japan-2019-yosegi-135810726

(2019/03/15 10:00追記)

HDFSにおけるサポータビリティ(保守性)の改善について

Kobayashi Daisukeさん@Cloudera

https://www.slideshare.net/Cloudera_jp/hdfs-supportaiblity-improvements

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

KaiGai Koheiさん@HeteroDB

https://www.slideshare.net/kaigai/20190314-pgstrom-arrowfdw