2025年8月7日

医療画像処理を7倍高速化：Python Data Source APIの活用法

業界標準ライブラリpydicomとzipfileを活用し、DICOMデータ取り込みパイプラインを高速化

ヘルスケア・ライフサイエンス組織では、DICOM画像、実験機器データ、ゲノム出力、バイオメディカルファイルなど多様なデータ形式を扱っており、これらは多くの場合ZIP形式で保存されるため、従来のプラットフォームでは処理が困難
Python Data Source APIにより、ヘルスケア向けPythonライブラリをSparkに統合し、複雑なETLパイプラインや解凍処理、UDFを使わずに圧縮ファイルを直接処理可能
Python Data Source APIの活用により、メモリ内処理による一時ファイルの削除とI/O操作の最小化を実現し、従来比7倍の高速処理を達成（ストレージ使用量は57分の1に削減）

ヘルスケアデータの課題：標準フォーマットを超えて

ヘルスケアおよびライフサイエンス組織では、従来の構造化データをはるかに超える極めて多様なデータ形式を扱っています。DICOM医療画像規格、独自仕様の実験機器データ、ゲノムシーケンス出力、特殊なバイオメディカルファイル形式などは、従来のデータプラットフォームにとって大きな課題となっています。Apache Spark™は約10種類の標準的なデータソースタイプに対して強力なサポートを提供していますが、ヘルスケア領域では数百種類の特殊なフォーマットとプロトコルへのアクセスが必要です。

医療画像は、CT、X-Ray、PET、超音波、MRIなどのモダリティを含み、整形外科から腫瘍学、産科に至る幅広い専門分野における診断・治療プロセスに不可欠です。これらの医療画像が圧縮され、アーカイブ化され、または特殊なPythonライブラリが必要な独自の形式で保存されている場合、課題はさらに複雑になります。

DICOMファイルには、豊富なメタデータのヘッダーセクションが含まれています。標準定義されたDICOMタグは4200種類以上存在します。一部の顧客はカスタムメタデータタグを実装しています。“zipdcm”データソースは、これらのメタデータタグの抽出を高速化するために開発されました。

問題：医療画像処理の遅さ

ヘルスケア組織は、数千のDICOMファイルを含む圧縮ZIPアーカイブに医療画像を保存することがよくあります。これらのアーカイブを大規模に処理するには、通常以下の複数ステップが必要です：

ZIPファイルを一時ストレージに展開する
pydicomのようなPythonライブラリを使用して個々のDICOMファイルを処理する
結果をDelta Lakeにロードして分析する

Databricksは、ソリューションアクセラレータdbx.pixelsをリリースし、数百の画像形式を大規模に簡単に統合することができます。しかし、ディスクI/O操作や一時ファイルの処理により、プロセスは依然として遅いことがあります。

解決策：Python Data Source API

新しいPython Data Source APIは、ヘルスケア特化のPythonライブラリをSparkの分散処理フレームワークに直接統合することでこれを解決します。ファイルを事前に解凍してからユーザー定義関数（UDF）で処理する複雑なETLパイプラインを構築する代わりに、圧縮された医療画像を直接一括処理できます。

Python Data Source APIを使用してZIPファイル抽出とDICOM処理を組み合わせたカスタムデータソースを実装することで、従来のアプローチと比較して7倍の高速処理を実現できます。

”zipdcm”リーダーは、合計107,000以上のDICOMファイルを含む1,416のzipfileアーカイブを処理しました。DICOMファイルあたり2.43コア秒です。独立したテスターは、パフォーマンスが10倍速くなったと報告しました。使用したクラスタには、それぞれ8 v-coresのワーカーノードが2つありました。”zipdcm”リーダーを実行するための時間はわずか3.5分でした。

ソースデータをZIP形式のまま保持し、ZIPアーカイブを展開しないことで、クラウドストレージコストを大幅に削減できます（解凍時4TBに対してZIP形式では70GBのため、57倍のコスト削減）。

Zipped DICOMデータソースの実装

ここでは、githubで見つけたDICOM画像を含むZIPファイルを処理するカスタムデータソースの作り方を説明します。

Zipファイル内のDICOMファイルを読み込む肝心な部分（オリジナルソース）：

このループを変更して、zipアーカイブ内にネストされた他のタイプのファイルを処理します。zip_fpはzipアーカイブ内のファイルのファイルハンドルです。上記のコードスニペットを見ると、個々のzipアーカイブメンバーがどのように個別にアドレス指定されるかがわかります。

このコード設計のいくつかの重要な側面：

DICOMのメタデータはyieldを通じて返され、これはメタデータ全体をメモリに蓄積しないため、メモリ効率が良い技術です。1つのDICOMファイルのメタデータは数キロバイト程度です。
このデータソースのメモリフットプリントをさらに削減するために、ピクセルデータを破棄します。

partitions() methodにさらなる修正を加えることで、複数のSparkタスクが同じzipfileを操作することも可能になります。DICOMの場合、通常、zipアーカイブは3Dスキャンからの個々のスライスやフレームを1つのファイルにまとめて保持するために使用されます。

全体的に見ると、「zipdcm」はSpark DataFrame APIの標準的なread.format(<name_of_data_source>)において、新しいカスタムデータソースとして簡単に使用できます。以下のコードスニペットを参照してください。

データフォルダがどのように見えるか（データソースは素のdcmファイルとzipされたdcmファイルを読み込むことができます）：

なぜ7倍速いのか？

Python Data Source APIを使用したカスタムデータソースの実装により、7倍の高速化を実現する要因は以下の通りです：

一時ファイルなし： 従来のアプローチでは、解凍したDICOMファイルをディスクに書き込みます。カスタムデータソースはすべてをメモリ内で処理します。
開くファイル数の削減： The Cancer Imaging Archive (TCIA)のデータセット[DOI: 10.7937/cf2p-aw56]¹では、107,000個のDICOMファイルとライセンステキストファイルを含む1,412個のZIPファイルを使用しました。これにより、処理が必要なファイル数が100倍に増加することになります。
部分的な読み込み： DICOMメタデータzipdcmデータソースでは、大容量の画像データ関連タグ"60003000,7FE00010,00283010,00283006")を除外します。
ストレージへのIOとストレージからのIOを減らす：従来の方法では、unzipを使用して107,000ファイルを展開し、合計4TBのストレージが必要でした。TCIAからダウンロードした圧縮データは71GBだけでした。zipdcmリーダーを使用すると、210,000以上の個々のファイルIOを節約できます。
パーティション認識の並列性： イテレータがトップレベルのZIPと各アーカイブ内のメンバーの両方を公開するため、データソースは単一のZIPファイルに対して複数の論理パーティションを作成することができます。 これにより、Sparkは共有ディスク上でアーカイブを事前に展開することなく、ワークロードを複数のエグゼキュータコアに分散できます。

これらの最適化により、ボトルネックがディスク・ネットワークI/OからCPU処理に移行し、参照データセットにおけるエンドツーエンドの実行時間を7倍短縮しつつ、メモリ使用量を予測可能な制限範囲内に維持できます。

医療画像を超えて：ヘルスケアPythonエコシステム

Python Data Source APIは、ヘルスケアとライフサイエンスのPythonパッケージの豊富なエコシステムへのアクセスを開きます：

医療画像： pydicom、SimpleITK、scikit-imageを使用して各種医療画像形式を処理します
ゲノム： BioPython、pysam、genomics-pythonを使用してゲノムシーケンスデータを処理します
実験室データ： フローサイトメトリー、質量分析、臨床実験室機器用の専門パーサー
製薬： 化学情報学と薬物発見ワークフローのためのRDKit
臨床データ： ヘルスケア相互運用性規格のためのHL7処理ライブラリ

これらのドメインには、今やスケーラブルなSparkパイプラインに統合できる成熟した、実戦検証済みのPythonライブラリがあります。ヘルスケアデータサイエンスでのPythonの優位性が、ついにプロダクションスケールのデータエンジニアリングに翻訳されます。

次のステップ

このブログ記事では、Python Data Source APIとApache Sparkを組み合わせることで、医療画像の取り込みが大幅に改善する方法について説明しています。DICOMファイルのインデックス作成とハッシングの7倍の高速化、100,000以上のDICOMファイルを4分以内に処理し、ストレージを57倍に削減することを強調しています。レントゲン画像解析の市場は年間400億ドル以上と評価されており、これらのパフォーマンス向上は、コストを下げながらワークフローの自動化を加速する機会となります。著者は、彼らの研究で使用されたベンチマークデータセットの作成者に感謝しています。

Rutherford, M. W., Nolan, T., Pei, L., Wagner, U., Pan, Q., Farmer, P., Smith, K., Kopchick, B., Laura Opsahl-Ong, Sutton, G., Clunie, D. A., Farahani, K., & Prior, F. (2025). MIDI-Bチャレンジのサポートデータ (MIDI-B-Synthetic-Validation, MIDI-B-Curated-Validation, MIDI-B-Synthetic-Test, MIDI-B-Curated-Test) (バージョン1) [データセット]. The Cancer Imaging Archive. https://doi.org/10.7937/CF2P-AW56

サンプルデータが付属のデータソース（“fake”、“zipcsv”、“zipdcm”）を試してみてください。すべてここで見つけることができます：https://github.com/databricks-industry-solutions/python-data-sources

あなたのDatabricksアカウントチームに連絡して、あなたのユースケースを共有し、お気に入りのデータソースの取り込みをスケールアップする方法について戦略を練るようにしてください。