Databricks における画像の取り扱い

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

©2024 Databricks Inc. — All rights reserved 画像処理パイプラインのアーキテクチャ • 画像処理にはトレーニングおよび推論パイプラインが含まれます。 • モデルのトレーニング頻度は推論実行頻度よりも少ないかもしれません。 • 推論はバッチモード、あるいはリアルタイムストリーミングモードで実行されます。 • トレーニングしたモデルは推論のためにエッジデバイスにデプロイされることがあります。 • ディープラーニングフレームワークは、それらの精度と画像から特徴量を推定できる能力から頻繁に活用されます。 • 一般的なフレームワークには、TensorFlow、Keras、PyTorchがあります。 • 多くの場合、ユーザーは事前学習済みモデルを再利用するか、ユースケースに応じて最終レイヤーを再トレーニングし、スクラッチでニューラルネットを構築することなしに、画像処理パイプラインの構築を容易にします。

Slide 4

Slide 4 text

©2024 Databricks Inc. — All rights reserved ディープラーニングを用いた画像処理の課題 • モデルをトレーニングするオンプレミスGPU可用性の制限 • GPUのアーキテクチャ設計は困難であり、セキュアかつ容易に管理することも大変です。 • blobストレージに存在する大量の画像ファイル • 特徴量を持つ非構造化画像データを用いて構造化のテーブルを作ることが困難です。

Slide 5

Slide 5 text

Delta Lakeによる画像管理

Slide 6

Slide 6 text

Slide 7

Slide 7 text

©2024 Databricks Inc. — All rights reserved 探索 vs. 格納 • Delta lakeでは画像の2つのフォーマットをサポートしています。 • イメージフォーマット - 探索 • 画像をデコードし、サムネイルを作成します。 • データのサブセットを可視化し、サンプルデータの高さや幅、チャンネル数をチェックする際に有用です。 • バイナリーファイルフォーマット - 格納 • それぞれのファイルは、バイナリーのコンテンツとメタデータを持つ単一行として格納されます。 • 画像のデコードは行いません。

Slide 8

Slide 8 text

©2024 Databricks Inc. — All rights reserved 画像の格納形態 - 生の画像ファイルパスその他のメタデータ s3a://mys3bucket/images/01.png s3a://mys3bucket/images/02.png s3a://mys3bucket/images/03.png • メリット • 管理が簡単 • デメリット • パフォーマンスが出ない • バージョン管理ができない(タイムトラベル) • データを拡張できないクラウドストレージ

Slide 9

Slide 9 text

©2024 Databricks Inc. — All rights reserved ID 座標メタデータ … 画像 (バイナリー) 01 02 03 画像の格納形態 - Deltaテーブルに格納 • メリット • バージョン管理(タイムトラベル) • 大規模処理でも高いパフォーマンス(OPTIMIZE、Z-Orderなど) • Single source of truth(データが散在しない) • 管理が簡単 • デメリット • DeltaのAPIを使う必要あり Deltaテーブル

Slide 10

Slide 10 text

Slide 11

Slide 11 text

©2024 Databricks Inc. — All rights reserved 更なる画像処理で .applyInPandas(...) を活用 • 画像処理APIにアクセスするための簡潔なUDF構文 • 画像に対してより自然なpandas APIを活用 • Arrowに引き渡すデータのスキーマとデータ量を考慮 proc_df = df.select() … rtn_schema = df.select().withColumn(“x”,...)... • 自分の pandas 関数を活用 rtn_df = proc_df.groupBy().applyInPandas(rtn_schema) • 特徴量を用いてバイナリー画像データを効率的に再構成するためにSparkを活用 full_df = rtn_df.join(df,,”leftouter”)

Slide 12

Slide 12 text

©2024 Databricks Inc. — All rights reserved 格納時の圧縮の無効化格納しようとしているデータの大部分が画像特徴量ではなく画像データの場合には、圧縮を無効化します。これによって、画像が最初から圧縮フォーマットである場合には、読み書きを劇的に高速化します。 (ここでは.pngを使いました) # Save spark.conf.set("spark.sql.parquet.compression.codec", "uncompressed") ( full_df.write .format('delta') .mode('append') .option('mergeSchema',True) .save('/mnt/datalake/interesting_images') ) # Set compression back to what it was spark.conf.set("spark.sql.parquet.compression.codec", compression)

Slide 13

Slide 13 text

画像管理をサポートするUnity Catalog

Slide 14

Slide 14 text

©2024 Databricks Inc. — All rights reserved Unity Catalogガバナンスによる非テーブルデータへのアクセス、格納、整理、処理データサイエンス、機械学習を含む任意のファイルの新たな処理機能の解放すべてのファイルフォーマット。構造化、半構造化、非構造化データ UI、Spark API、FUSE、dbutils、REST、SQL、 Databricks CLI、Terraform経由でアクセス可能なファイルボリューム 14 Unity Catalogにおけるファイルのカタログコレクション

Slide 15

Slide 15 text

©2024 Databricks Inc. — All rights reserved Unity Catalogにおけるボリューム非テーブルデータのアクセス、格納、制御、整理、処理 * 15 - ボリュームタイプ: マネージド、外部 - Unity Catalogで集中管理される3レベルの名前空間で整理されるファイル .. - Hadoop分散ファイルシステムの実装、FUSEサポート - パス Hadoop [dbfs:]/Volumes///// FUSE /Volumes///// - ANSI SQLのGRANTやREVOKEコマンドをベースとしたガバナンスモデル - ボリュームレベル - カタログエクスプローラやノートブックのファイル参照、管理のためのユーザインタフェース - API(Spark、dbutils、REST、SQL、ローカルファイルシステム)やDatabricks CLI経由でアクセスできるコンテンツ * テーブルではなくファイルとして直接アクセスできるデータ

Slide 16

Slide 16 text

©2024 Databricks Inc. — All rights reserved Unity Catalogにおけるボリューム 16 Unity Catalogガバナンスによるファイルのアクセス、格納、整理、処理 - ボリュームは以下のような非テーブルデータに対するガバナンスを追加します - MLで活用される画像、音声、動画、 PDFファイルのような非構造化データ - MLモデルトレーニングで活用される半構造のトレーニング、検証、テストデータセット - ad-hocや初期段階のデータ探索で使用される生のデータ、保存されるアウトプット - ワークスペース横断で利用されるライブラリ、設定ファイル - ロギングやチェックポイントの出力ファイルのようなオペレーションデータ - … - 一方でテーブルはテーブルデータセットに対するガバナンスを提供します * テーブルではなくファイルとして直接アクセスできるデータ

Slide 17

Slide 17 text

©2024 Databricks Inc. — All rights reserved 17 すべてのワークロードに対する自動リネージ ● Databricksクラスター、SQLウェアハウスにおける実行時データリネージ自動キャプチャ ● テーブル、カラムレベルのリネージ ● Unity Catalogの共通権限モデルの活用 ● テーブル、ダッシュボード、ワークフロー、ノートブック、特徴量テーブル、ファイル、 DLTのリネージ組織におけるデータフロー、データ活用に対するエンドツーエンドの可視性

Slide 18

Slide 18 text

Thank you