🔍 DuckDB가 분산 컴퓨팅을 지원한다고?
DuckDB는 뛰어난 성능과 간편한 사용성으로 많은 데이터 엔지니어들에게 사랑받는 분석용 데이터베이스입니다. 하지만 본질적으로 싱글 노드(In-process) 실행이 기본이라 대량 데이터 처리에는 한계가 있었습니다.
그런데 최근 AI 기업 DeepSeek이 DuckDB를 분산 환경에서 활용할 수 있도록 하는 smallpond를 공개했습니다.
이 기술이 의미하는 바는 무엇일까요? 기존 빅데이터 프레임워크(Spark, Ray 등)와 비교했을 때 어떤 차이가 있을까요? smallpond의 핵심 아키텍처와 실제 적용 가능성을 함께 살펴보겠습니다.
🐥 DuckDB는 왜 AI 기업에서 주목받는가?
✅ DuckDB란?
DuckDB는 SQLite처럼 가벼운 데이터베이스지만, 빅데이터 분석에 최적화된 엔진입니다.
- 별도 서버가 필요 없고, 애플리케이션 내부에서 실행 가능
- Parquet, Iceberg 등 주요 데이터 포맷을 지원
- 고성능 쿼리 실행 (컬럼 기반 처리, 멀티코어 활용)
특히 AI 분야에서는 HuggingFace 같은 기업이 DuckDB를 활용해 빠르게 대용량 데이터셋을 탐색하고 분석하는 데 사용하고 있습니다.
하지만 단일 노드 기반이라는 점이 한계였습니다. 대규모 데이터를 처리하려면 분산 시스템이 필요합니다.
🌊 DeepSeek의 smallpond란?
🔥 DeepSeek의 새로운 도전
DeepSeek은 AI 모델과 데이터 인프라 혁신을 주도하는 기업입니다.
최근 공개한 smallpond는 DuckDB의 싱글 노드 한계를 뛰어넘기 위한 분산 컴퓨팅 프레임워크입니다.
💡 벤치마크 결과:
smallpond는 110.5TiB(테라바이트)의 데이터를 30분 14초 만에 정렬하며 평균 처리 속도 3.66TiB/min을 기록했습니다.
이제 smallpond의 핵심 아키텍처를 살펴보겠습니다.
⚙️ smallpond의 핵심 아키텍처 분석
📌 1️⃣ DAG 기반 실행 모델
smallpond는 DAG(Directed Acyclic Graph) 기반의 실행 모델을 채택했습니다.
즉, 데이터를 바로 처리하지 않고 논리적 실행 계획을 먼저 구성한 후 필요할 때만 실행하는 방식입니다.
import duckdb
conn = duckdb.connect()
conn.sql("SELECT * FROM 'data.parquet'").count()
이처럼 count() 같은 액션을 호출해야 쿼리가 실행됩니다.
🛠 주요 연산 방식:
- map(), filter(), partial_sql() 등의 연산은 실행되지 않고 DAG를 생성
- write_parquet(), compute(), count() 등의 액션이 호출될 때 실행됨
- 최적의 실행 경로를 자동 설정하여 불필요한 연산을 최소화
📌 2️⃣ Ray Core를 활용한 분산 처리
DuckDB는 기본적으로 단일 프로세스에서 실행됩니다.
smallpond는 Python의 Ray Core 프레임워크를 이용해 여러 노드에서 병렬 처리를 수행합니다.
✔️ 분산 처리 방식:
- 데이터를 여러 파티션(Partition) 으로 나눔
- 각 파티션을 별도의 DuckDB 인스턴스에서 독립적으로 처리
- 처리된 데이터를 다시 병합하여 최종 결과 생성
✔️ 지원하는 파티셔닝 방식:
- 해시 파티셔닝 (특정 컬럼 기준)
- 균등 파티셔닝 (파일 또는 행 단위)
- 랜덤 셔플 파티셔닝
🔄 기존 분산 프레임워크(Spark, Ray 등)와 비교
smallpond (DuckDB + Ray) Apache Spark Ray (Daft 등)
| 분산 방식 | 파일/파티션 단위 분산 | 태스크 & 오퍼레이터 단위 분산 | 데이터프레임 연산 단위 분산 |
| 실행 모델 | Lazy Evaluation (DAG 기반) | Lazy Evaluation (DAG 기반) | Lazy Execution |
| 주요 사용 사례 | 대용량 데이터 정렬, ETL | 대규모 데이터 분석, ML 파이프라인 | 병렬 연산, AI 모델 배포 |
| 복잡한 쿼리 최적화 | 낮음 | 높음 | 보통 |
| 설치 및 사용 편의성 | 쉬움 (Python 코드만 필요) | 중간 (Spark 클러스터 필요) | 중간 (Ray 클러스터 필요) |
🧐 핵심 차이점
- Spark: SQL 연산을 세밀하게 분산할 수 있지만, 설정이 복잡하고 클러스터 관리 비용이 높음
- Ray (Daft): 데이터프레임 단위로 분산 처리 가능하지만, AI/ML 특화 환경
- smallpond: 전체 파티션을 별도 DuckDB 인스턴스에서 실행하기 때문에 구조가 단순함
즉, smallpond는 데이터 정렬, 전처리, ETL 작업에 적합하지만, 복잡한 쿼리 분산 실행에는 최적화되지 않음.
🚀 smallpond의 실제 활용 가능성과 한계
✅ 적용 가능한 워크로드
- TB(테라바이트) 단위 데이터 정렬 및 필터링
- 빠른 데이터 전처리 및 변환(ETL)
- AI 모델 학습 데이터 준비
❌ 한계점 및 고려 사항
- Ray 클러스터 필요: 분산 실행을 위해 Ray 환경을 설정해야 함
- SQL 단위 병렬 처리 부족: Spark처럼 쿼리 내부 연산을 나눠서 실행하지 못함
- 3FS 전용 스토리지: DeepSeek이 자체 개발한 분산 파일 시스템(3FS)이 필요하여 일반적인 클라우드 스토리지(S3 등)와 직접 비교 어려움
DeepSeek의 smallpond는 DuckDB의 한계를 넘어서려는 첫 번째 시도입니다.
이제 데이터 엔지니어들은 DuckDB의 간결함을 유지하면서도 대규모 데이터 처리까지 가능해졌습니다.
✅ smallpond의 의미
- DuckDB를 빅데이터 환경에서도 활용할 수 있도록 확장
- ETL 및 데이터 전처리에 적합한 경량 분산 프레임워크 제공
- Spark, Ray와는 다른 방식의 분산 접근법을 제시
❗ 하지만...
- SQL 쿼리 단위의 최적화가 부족해 복잡한 연산에는 Spark가 여전히 유리
- DeepSeek의 3FS 스토리지 의존도가 높아, 실무 적용에 고려할 점이 많음
결국, "어떤 워크로드에 적합한가?" 가 핵심 질문입니다.
smallpond는 "DuckDB를 활용해 빠르게 데이터를 전처리하고 싶다!" 라는 유스케이스에 딱 맞는 도구입니다.
앞으로 smallpond가 AWS S3 같은 범용 스토리지를 지원할지, 혹은 더 발전된 분산 처리 모델로 확장될지 기대해봅니다. 🚀
DuckDB goes distributed? DeepSeek’s smallpond takes on Big Data
DeepSeek is pushing DuckDB beyond its single-node roots with smallpond, a new, simple approach to distributed compute. But does it solve the scalability challenge—or introduce new trade-offs?
mehdio.substack.com
'인공지능' 카테고리의 다른 글
| AI가 만들어낸 가짜 코드, 정말 큰 문제일까? (0) | 2025.03.04 |
|---|---|
| Git 리포지토리를 LLM에 최적화된 텍스트 데이터로 변환하는 방법 – gitingest 활용하기 (0) | 2025.03.04 |
| LLM 활용의 모든 것: Andre Karpathy의 'How I use LLMs' 분석 (0) | 2025.03.04 |
| 100개 이상의 LLM을 간편하게 활용하는 방법 – LiteLLM 소개 및 활용 가이드 (0) | 2025.03.03 |
| 알리바바 클라우드, AI 영상 생성 모델 ‘Wan2.1’ 오픈소스 공개! 개발자와 기업이 얻을 수 있는 이점은? (0) | 2025.03.02 |
