DAIS2024参加報告 ~Spark中心にしらべてみた~ (JEDAI DAIS Recap 講演資料)

© 2024 NTT DATA Group Corporation 1
Data＋AI Summit 2024 参加報告
～ Sparkを中心にしらべてみた～
株式会社NTTデータグループ技術革新統括本部 Innovation技術部内藤佑太/北波紘子

01
自己紹介

LT登壇者紹介
北波紘子
Hiroko Kitaba
株式会社NTTデータグループ Innovation技術部
高度OSSサポート担当主任
＜略歴＞
金融/製薬/エネルギーなど様々な業界で
OSS使用プロジェクト開発/性能検証支援/
アジャイル開発のコンサルティングに従事
2023年
Databricks Solutions Architect Champion 取得
現在の業務は主にSpark、Hadoop
Databricks使用プロジェクトの支援
今はまっているもの
ポケモンGO(パッチール集め)
内藤佑太
Yuta Naito
株式会社NTTデータグループ Innovation技術部
高度OSSサポート担当主任
＜略歴＞
Smart CityやMaaSなど
のPoC案件におけるアジャイル型の
開発支援やスクラムの導入支援/
データプラットフォームや
Mobileアプリの開発に従事
現在は、OSSのサポート業務及び
Spark等のOSSを用いた基盤更改などの
案件への技術支援

普段の業務 [高度OSSサポート] とは
⚫ Hadoop/Spark/Kafkaなどの
高難易度なプロダクトのサポートを提供
⚫ OSS活動やプロジェクト支援を実施するとともに、中長期的なサポートを提供している
⚫ Hadoop/Spark/Bigtop などのコミッタも在籍
高度OSSサポート
• ミドルウェア等をソースコードレベルで理解/調査
できる実力があるからこそ課題が解決できる
• 技術の方向性にも影響を持つ
• 世の中では提供仕切れていない「長期サポート」「高度サ
ポート」を提供しているケースもある
• 10年間安心して使える、なども支えている
高い技術力
安心・安全の実績

02
会場の雰囲気

Data + AI Summit 2024 とは？
• Data ＋ AI Summitは、Databricks社が毎年開催する最大規模のカンファレンス (旧 Spark ＋ AI Summit)
2024年は6月10日から6月13日までの4日間にわたってサンフランシスコで開催された
• 今年のテーマは「DATA INTELLIGENCE FOR ALL」
過去最高の60,000人以上が視聴/16,000人以上が現地参加、600以上のセッション/130以上のスポンサーブース展示
• 弊社メンバはApache Sparkや周辺サービスの最新動向などをキャッチアップしに行った
会場
Moscone Center(North, South, West)
/インターコンチネンタルホテル

スケジュール
可能な限り聴講セッションを詰め込み(↓)、現地ではさらに聞きに行った
講演たくさん！
詰め込みすぎ！

聴講セッションの紹介 KeyNote
KeyNoteについては弊社メンバのQiita記事まとめがあります。ぜひご確認ください
1日目
• #1 https://qiita.com/nttd-yuan/items/00710ead4910c2e1e742
• #2 https://qiita.com/nttd-tamurasua/items/3db302751bfb184f66b0
2日目
• #1 https://qiita.com/nttdg-naitouyut/items/9be0616c39ea0dff8423
• #2 https://qiita.com/nttd-kitabah/items/af307e54af795ec2ea9e
1日目 2日目
#1 #2
#1 #2

ダジャレTシャツ by Google Cloud
会場の雰囲気

Data After Hours
• SFMoMAを貸し切ったド派手なパーティーが開催
• 現地の有名なラッパーがゲスト出演したという情報が(地元のバーで噂になっていた)
• 会場で配られていたラーメンが美味
カラフルなチーズパン
光るわたあめ
ラーメン

03
気になってしらべてみた①

Sparkの機能紹介
発表を聞いて気になった点を調べてみた
・Spark Connect
・Variant 型
以前から聞いたことはあるが、
普通にSparkを実行するのとで何が
違うのだろうか？
半構造化データの処理性能が
大幅に上がるらしいが、
どんな仕組みなのだろうか？

Spark Connect について
Spark Connect の背景は？
• 密結合されたドライバーアーキテクチャにより、リモート接続やバージョンアップが困難
• 現行では、クライアントアプリケーションとドライバーが密結合しており、クラスターの安定性や開発効率に課題
Spark Connect とは？
• クラスタへのリモート接続と操作を可能とするクライアントサーバーアーキテクチャの仕組み
• DataFrame APIを基に、クライアントとサーバーを分離したリモート接続の仕組みを提供
• 開発者がリモートでクラスターに接続し、DataFrame操作の実行を可能とする
• クライアントとサーバーを分離することで、シームレスなアップグレード、安定性の向上、セキュリティ強化を目指す
https://spark.apache.org/docs/latest/spark-connect-overview.html

使用によるメリット
・SQL以外の言語でリモート接続するためには、
外部ツール（Apache Livyなど）が必要
・Spark Connectによりネイティブなリモート接続
が可能
・インタラクティブなデータ探索や最新の
開発ツールとの統合がサポートされていなかった
・Spark Connectにより、IDEなどのローカルツール
との統合が強化
・1つのクライアントによるOOMなどの例外が
全ユーザーに影響する可能性
・分離されたアーキテクチャにより、安定性を向上
・クライアントとサーバーのAPI密結合のためアップグレード時
の依存関係問題が生じる
・バージョン間の互換性を確保
リモート接続開発者体験
安定性バージョンアップ

Spark Connect の仕組みについて
1. DataFrame API 上に構築され、クライアント・サーバ間で言語に依存しないプロトコルを使用
2. クライアントにおいてDataFrame 操作をプロトコルバッファーを用いてエンコードされる未解決論理プランに変換し、gRPCでサーバーへ送信
3. サーバーではSpark Connect エンドポイントを通じてそれらを受信し、解析してテーブルやカラムなどの参照を解決した実行プランを、
Spark の標準実行プロセスで開始する
4. 実行結果はApache Arrow でエンコードされた行バッチとして gRPC 経由でクライアントに送信される
SQL Query
DataFrame
Unresolved
Logical Paln
Logical Paln
Optimized
Logical Plan
Physical
Plan
Cost
Model
Selected
Physical
Plan
RDDs
Query
Execution
Planner
Optimizer
Analyzer
Planner
サーバー側の処理
クライアント側の処理
①
②
③ ④
https://spark.apache.org/docs/latest/spark-connect-overview.html

Variant 型について
Variant 型の背景は？
• 従来のJSONなどの文字列と比較して処理性性能と柔軟性が向上した新たな半構造化データ
• データ分析など多くのユースケースで半構造化データの取り扱いが増加
• 半構造化データは、柔軟性がある一方でクエリ性能やデータ格納の効率に課題がある
Variant 型とは ?
• 一つのデータ型で様々な形式のデータを扱える柔軟な型を提供
• 基本的なデータ型（プリミティブ型、配列、オブジェクト）を統合して扱う
• ネスト構造が深いデータでも効率的にクエリを実行できるように設計

使用によるメリット
・ネスト構造でも高速なデータの解析と
取得が可能
・半構造化データの深いネストやフィールド数
が多いデータの効率的なクエリが可能
・データに応じたバイナリエンコーディング
により無駄なメモリ使用を削減
パフォーマンスの最適化データ格納の効率化
効率的なクエリ処理

Variant 型の仕組み
• メタデータと値のエンコーディング：Variant 型は2つのバイナリ値（メタデータと値）でエンコードされて効率的に格納できる
• プリミティブ型、配列、オブジェクトのサポート：それぞれ異なるエンコーディング方式を用いて、異なるデータ型を統合的に扱う
• 辞書ベースのフィールドID管理：オブジェクト内のフィールドは辞書により効率的に管理され、クエリや検索時に高速化を実現
JSON String [ {"key1": 1, "key2": 2 }, {"key1": 3, "key2": 4} ]
Value [ {0: 1, 1: 2 }, {0: 3, 1: 4} ]
Metadata [ "key1", "key2" ]
header
dictionary
size (N)
key
offset 1
・・・
key
offset N
key 1 key n
・・・
Metadata
header
num
fields (k)
field
id 1
field
offset 1
・・
field
id k
・・
field
offset k
・・
field
value 1
field
value k
Value
キーの数
インデックスでアクセス可能な文字列のリストのようなもの
バージョン情報など
キーを参照するフィールドID
・重複するキーのフィールド名を複数回保存する必要がなく、個別のキーをメタデータに1回保存するだけで済む
・特定の位置のキーのフィールドに二分探索でアクセスが可能
Variant 型への変換
・バイナリエンコードによりキーは数字に変換され、メタデータのインデックスと紐づく
格納の仕方変換例

04
気になって調べてみた②

Spark4.0の発表
参考講演：
「KeyNote2日目」
「What’s Next for the Upcoming Apache Spark 4.0 Release?」
「pandas on Spark: Simplicity of pandas with efficiency of Spark」

Spark4.0の発表
１ Python UDTFの機能拡充
２構造化ログフレームワーク
参考講演：
「KeyNote2日目」
「What’s Next for the Upcoming Apache Spark 4.0 Release?」
「pandas on Spark: Simplicity of pandas with efficiency of Spark」
Sparkでログを解析するとき
苦労するので朗報だと思った！
KeyNoteでPySparkが
大々的に取り上げられていた！
新しい機能が増えた！

Python UDTF について
Python UDTF(Python User Defined Table Functions)自体はSpark3.5から使えるようになった機能
Spark4.0でさらに機能が追加された
Python UDTFとは
• 1行以上の入力に対し複数の出力行(テーブル)を返却するユーザ定義関数
• 提供されている関数等では実現できないような柔軟なデータ加工が可能
• Pythonだけでテーブル操作ができるため、保守性・可読性の向上につながる
今までの実装方法との違い
vs Python UDF
(ユーザ定義関数、ユーザ独自の関数を定義できるPythonの機能の一つ)
各呼び出しからスカラー値を渡す設計であるが、
Python UDTFでは出力としてテーブル全体を返せる
vs SQL UDTF
SQL文のFROM節で呼び出され、表の形式で値を返す関数であるが、
Python UDTFではその操作がPython内で処理完結できる

Executor
JVM
Python UDTF 実現方法
Driver
Executor
②論理プラン作成
③最終的な実行プラン作成
Task
Pythonプロセス
①UDTFの登録
Action処理が実行されたタイミング
⑤Python UDTFと
その引数をシリアライズ
⑧処理の結果を
デシリアライズする
Executor
• 最初に@udtfのデコレータによってUDTFの登録がされ、論理プランに組み込まれる
• Executor上ではPython UDFと同じくPythonプロセス上にUDTFとその引数が連携され処理される
⑦処理終了後
シリアライズした結果をJVMへ返却
⑥デシリアライズ後に
Python UDTF処理
④各ExecutorへTaskとして配布
※Driver側のシリアライズ機構は省略
※注：従来のPython UDFと同じ

Python UDTF 実装方法
• 実装はドキュメントを参考
• 今回のDATA＋AI Summitの中でも、Sparkのドキュメントの拡充が発表されている
https://spark.apache.org/docs/latest/api/python/user_guide/sql/python_udtf.html
※4.0バージョンはないため、リンクはlatestバージョン
関数をSQLの一部として呼び出すことも
PySpark DataFrame APIで呼び出すことも可能

Python UDTF について
新しく追加された機能 4選
Polymorphic Analysis：戻り値の型を動的に定義できる
デコレータ(静的/既存)、analyzeメソッド(動的)での定義の2種類に関連：SPARK-44380
どちらか一方の指定ではないとエラーが出力されるバリデーション機構あり
Input Table Partitioning：Partition、OrderByが入力テーブルで使える
関連：SPARK-44503(クエリプランニング) や SPARK-44748 (クエリ実行)、 SPARK-45362(evalメソッド)、SPARK-46040(Analyzeメソッドへの変更) など
Variable Keyword Arguments：evalメソッド(もちろんanalyzeメソッドも)の引数を可変にも定義できる
関連：SPARK-44749
Custom Initialization：analyzeメソッドからevalメソッドへ状態を引き継げる
AnalyzeResultのサブクラスを作成することで、後続の関数呼び出しの初期化も行える関連：SPARK-45402
効率的に処理したい場合にはArrow最適化を使用する
デフォルトでは無効化※されているため、有効化する際にはデコレータのuseArrowをTrueにする
Python UDFはSpark4.0からデフォルトになったため今後有効化されるかも
※動作が不安定であるため？ SPARK-44479 (3.5.0で解決済み) など
１
2
3
4

なぜ Apache Arrow を使用すると処理が速くなるか
Arrowのデータ形式
• メモリ内に保存された列指向のデータ形式になる
• 同じ列のデータが連続したメモリ領域にグループ化される (RecordBatchごと)
※注：従来のPython UDFと同じ
データは行単位でメモリ上に配置される
列単位のアクセスはメモリ上に散らばったデータ
を取得するため時間がかかる
全ての行がUDTFへ連携される
大量データを連携する際には時間がかかる
データは列単位で同じメモリ領域に配置される
Pandasによるデータ分析処理では列単位のアクセスが多いため、検索が高速化
分析に必要な列のみ処理できる
データを列単位で連携することが可能であるため、UDTFへのデータ連携が高速化
シリアライズも必要なデータのみに絞れる
Arrow最適化前 Arrow最適化後
行指向データ
id
num
timestamp
id
num
timestamp
id
num
timestamp
Schema
Columns
0
1
2
3
列指向データ
RecordBatch
id
num
timestamp
データはRecordBatch単位で
Arrow形式へ変換される
UDFの例になるが、1.5~2倍の性能差があると発表されていた

戻り値の型指定
Python UDTF 触ってみた (抜粋)
デコレータで戻り値の型指定 analyzeメソッドで戻り値の型指定
class定義
メソッド定義
戻り値の型定義
analyzeで戻り値の型定義
Python UDTF を触ってみての注意点・気を付けるべきこと
Python UDTFを使う際の注意点は
基本的にPython UDFと同じ
どのくらいメモリを使用する処理なのか・出力があるか
Python UDF以上に気を付けて設計すべき
※おまけ：Sparkにこんな機能を追加したい
① UDFやUDTF内で出たエラーを正確にDriverがキャッチできる機構
Executor側のログを見ないと正確なエラーがわからないのがきつい
Executorを大量に起動している場合には確認が大変
② Pythonプロセス内でデータサイズ増加の予測や見積りできる機能
知らず知らずのうちにデータ量が多くなる処理している

構造化ログフレームワーク
構造化ログフレームワークはSpark4.0から追加され、「Usability」の一つとして紹介された機能
構造化ログフレームワークとは
• ログが構造的になった (デフォルトログ形式がJSONに！) 関連：SPARK-47574
• Sparkログは非構造であり分析が困難であったが、専用のシステムログディレクトリが導入されログが構造化された
• フィルタリング機能でほしい情報を効率的に取得できる
• 例：executor_idでフィルタして特定のExecutor情報を取得できる
なぜ必要？
• 欲しいログがすぐに検索できる
• ログデータが分析しやすくなることにより、問題特定スピードが上がる
• ログ解析システムへの連携が容易になる

構造化ログフレームワーク触ってみた
Spark4.0.0
Spark3.5.1
{"ts":"2024-08-06T07:16:30.681Z","level":"INFO","msg":"Starting executor ID driver on host
ip-172-24-192-237.ap-northeast-1.compute.internal","logger":"Executor"}
構造化された見た目
24/08/06 16:24:46 INFO Executor: Starting executor ID driver on host 172.28.220.134
いつもの見た目
このくらいだったら大差ないが、複雑で長いログになると欲しいログを取得するのが面倒

構造化ログフレームワーク触ってみた
欲しいログをすぐに取得するには？
WARNレベルの実行結果のメッセージを取得する例 (※)
※stderrファイルの1行目に
WARNING: Using incubator modules: jdk.incubator.vector と入っていたため、そのままjqコマンドで実行できなかった
ログの中身を確認する際にとても便利な機能
jsonをインプットできるシステムとの連携が容易に
SparkSQLやPandasで分析することも可能

05
まとめ

まとめ
• DATA＋AI Summit2024で、DatabricksやSpark周りの開発やビジネスの盛り上がりを身をもって体感できた
• Spark4.0の新機能が発表され、注目領域となっていた
• Spark ConnectやVariant型など、データ利活用のシステムにおける実課題を見据えた対応も多い
• PySparkで機能の幅が増え、また構造化ログ等によるユーザの使いやすさが向上
• 世界中の技術者と会話できる。講演後も時間を設けてくれる方が多くフレンドリー
また来年も情報のキャッチアップのために参加したい
• OSSのコミュニティ活動やデータ基盤の動向などの調査でも、技術/ビジネスそれぞれで多くの発見を得られる！
初めての海外イベント参加でDatabricks社の社員の方々はじめ、様々な企業の方にお世話になりました！
この場をお借りして御礼を申し上げます。今後ともよろしくお願いいたします

来年参加する方向けおすすめしたいこと
講演スケジュールを詰めすぎてはいけない！
• 体力が持たない！精神的にもきつい！講演後に講演者と話したくても時間がない！
埋まっている講演も当日飛び入り参加が可能
• 事前の予約ができなくても安心して大丈夫
Teamsの録音機能がかなり優秀
• 聞き取れなかったところを録音して確認した
• 色々な英語に対応しており、文字起こし精度が良い
LinkedInを登録する
• 名刺も必要だが、LinkedIn交換が主流
ドルをそこまで現金化しなくてよい
• カード社会
• ホテルの部屋のチップくらいしか使わなかった
(10ドルくらい)
事前に知り合い・現地に詳しい人と仲良くなっておく
• 困ったときに連絡できるように
• 現地での良いお店などの情報収集もできる
生活面
イベント参加面

06
会場の雰囲気 ~続~
余裕あったら

ハッカソン
• ハッカソンにも参加。LLMがお題
• 即興でチーム編成し、協力して構想、使うデータの選定、データの処理方式手法まで練れたが、
時間内に実装が終わらず志半ばで終了…
• お題にご興味ある方は
→https://docs.google.com/document/d/e/2PACX-1vQ3RDr5eRItkO-48Zgftk72LXJydQwxYqWc6ftFHCzJEGFLTy1y-
Ft2m7smwwHg5VrpLAEMf7p2qgMJ/pub#id.jx5gfjnth1z1
• 時代はLLMを知っていること前提
会場の様子
上記リンクのQRコード

サンフランシスコの様子
• 街は噂に聞いていたより綺麗で治安も(気を付けていれば)よく、なにより気候がとても良い
• 円安が加速しており(1ドル＝160円)、外食すると最低でも$25~(約4000円)の印象
• 食べものはどれも美味
朝ごはん
(オムレツ)
内藤が食べた
チーズケーキ
北波が食べた
チーズケーキ
夜ごはん
(ステーキ)

現地でしかできないこと
• Waymo
• Lv4の自動運転
• サンフランシスコ市内限定で走行
• 運転が静かで乗り心地は最高

DAIS2024参加報告 ~Spark中心にしらべてみた~ (JEDAI DAIS Recap 講演資料)

DAIS2024参加報告 ~Spark中心にしらべてみた~ (JEDAI DAIS Recap 講演資料)

More Related Content

DAIS2024参加報告 ~Spark中心にしらべてみた~ (JEDAI DAIS Recap 講演資料)