Оглавление

Медицинские и биотехнологические организации сталкиваются с уникальным вызовом: обработкой специализированных форматов данных — от DICOM-изображений до геномных файлов — часто запакованных в ZIP-архивы. Традиционные подходы требуют сложных ETL-пайплайнов с распаковкой и поэтапной обработкой, что создаёт узкие места производительности.

Проблема: медленная обработка медицинских изображений

Стандартный процесс работы с DICOM-файлами в ZIP-архивах включает:

  1. Распаковку архивов во временное хранилище
  2. Обработку каждого файла через библиотеки вроде pydicom
  3. Загрузку результатов в Delta Lake

Хотя dbx.pixels упрощает интеграцию, производительность страдает из-за операций I/O и работы с временными файлами. Для примера: архив MIDI-B Test Data (DOI: 10.7937/cf2p-aw56) содержит 1,412 ZIP-файлов с 107,000 DICOM-изображений — при распаковке объём увеличивается с 71 ГБ до 4 ТБ.

Решение: Python Data Source API в Spark

Новый Python Data Source API позволяет интегрировать медицинские библиотеки напрямую в Spark. Вместо многоступенчатого ETL обработка сжатых файлов происходит за один шаг. Реализация "zipdcm" даёт:

  • 7x ускорение обработки (2.43 ядро-секунд на файл)
  • 57x экономию хранилища (4 TB vs 70 GB)
  • Обработку 107,000 файлов за 3.5 минуты на кластере с 16 vCPU
Python Data Source API

Техническая реализация

Ключевой фрагмент кода из репозитория zipdcm:

with ZipFile(path, "r") as zipFile:
  for name_in_zip in zipFile.namelist():
    if name_in_zip.endswith(".dcm"):
      with zipFile.open(name_in_zip, "r") as zip_fp:
        yield [rowid, f"{path}::{name_in_zip}", _handle_dcm_fp(zip_fp)]

Особенности подхода:

  • Обработка в памяти без сохранения временных файлов
  • Извлечение только метаданных (отбрасывание пиксельных данных)
  • Параллельная обработка через модификацию partitions()

Откуда взялось ускорение 7x?

  • Отказ от временных файлов: обработка полностью в памяти
  • Сокращение операций I/O: 210,000+ меньше файловых операций
  • Частичное чтение: игнорирование тегов с пиксельными данными (60003000,7FE00010 и др.)
  • Параллелизм на уровне архивов: распределённая обработка без распаковки

Этот подход — не просто оптимизация, а смена парадигмы в обработке медицинских данных. Интеграция Python Data Source API со Spark устраняет главный барьер — зависимость от дисковых операций — перенося нагрузку на CPU. Для медицинской аналитики, где скорость обработки снимков напрямую влияет на диагностику, 7x ускорение при 57x экономии хранилища революционно. Однако внедрение требует пересмотра ETL-архитектуры: вместо привычных пайплайнов разработчикам придётся создавать специализированные data source. Окупаемость для крупных медицинских центров очевидна, но для небольших клиник барьером останется необходимость в Spark-инфраструктуре.