A Field Journal on Ray Data and Daft for Multimodal Data Lake

Author: Mehul Batra | Source: Medium | Published: 2026-05-25

한 줄 요약

KubeRay 위에서 Ray Data 2.55.1과 Daft 0.7.13을 동일 하드웨어·데이터·모델로 8개 멀티모달 배치 추론 use case에 돌려 비교한 실전 기록 — 안정성이 결정적이어서 Ray Data를 56:47로 채택.

두 엔진의 아키텍처 명제 차이: Ray Data는 disaggregated execution(독립 CPU/GPU 풀 + in-memory object store, streaming batch 모델 = Spark 파티션 내결함성 + Flink 스트리밍 파이프라이닝). Daft는 멀티모달 행이 처음부터 MB~GB라는 전제로 Swordfish 스트리밍 러너 + 최적화 가능한 expression tree(AST) → 네이티브 멀티모달 연산자(read_video_frames, embed_image, join_asof)
Daft 강점: 네이티브 멀티모달 타입(Image/Tensor/Audio가 Arrow 백업 실타입), one-liner 표현식(UC-5 영상에서 native primitive 4개 사용 vs Ray Data 0개), expression tree로 async I/O와 sync compute 분리
Ray Data 강점: 안정성(UC-6 50k 비동기 LLM 추론에서 Daft는 2회 모두 완료 실패), 명시적 primitive(ActorPoolStrategy, asyncio.Semaphore는 강제 캡 — Daft의 max_concurrency는 advisory 힌트에 그침), Ray Core 플랫폼(Train/Serve/Tune), Apache 2.0 거버넌스
공통 교훈: ① concurrency knob은 스케일 전 100행 스모크로 advisory/enforced 검증 ② 처음 몇 UC는 엔진이 아니라 모델·배치 크기를 측정 ③ 배치 인프라에서 안정성은 최고 가중치이자 이진적 ④ native primitive는 capability가 아닌 ergonomic 축

UC-1 텍스트 임베딩: Daft one-liner ~110 LOC vs Ray Data ~190 LOC (단, FP16 원하면 둘 다 커스텀 actor 필요)
UC-6: Ray Data ~72% 설정 동시성 달성, Daft ~8% → 50k 규모에서 복리
스택: KubeRay v1.6.1, Lance(멀티모달 저장 spine) + DuckDB lance extension, Apache Gravitino 통합 카탈로그(Iceberg + Lance)
“Daft의 분산 러너는 Ray executor로 제공 → 같은 KubeRay 클러스터에서 둘 다 실행 가능, either-or 아님”