파일 I/O와 벤치마킹 실전
Shared on March 19, 2026
대용량 데이터 저장 및 파일 I/O 최적화
개요
- 주제: 대용량 데이터 처리 시 저장 장치, 파일 I/O, 파일 포맷, 벤치마킹에 대한 실무 지식
- 목표: 데이터 사이언스·AI 프로젝트에서 속도·용량·가용성을 균형 있게 관리하는 방법을 학습
핵심 개념
| 항목 | 핵심 내용 |
|---|---|
| 저장 매체 | HDD → SSD → NVMe (PCI‑e) |
| RAID | RAID 0(스트라이프), 1(미러), 5/6(패리티), 10(복합) – 용량·속도·신뢰성 균형 |
| 메모리 | DDR4/DDR5, ECC 지원 여부, 2 TB RAM 한계 |
| 파일 포맷 | CSV (텍스트, 느림) → Feather (바이너리, 빠름) → Parquet (컬럼형, 압축) → Arrow (인‑메모리, 언어 독립) |
| R 패키지 | data.table, readr, feather, arrow, parquet, feather, fst |
| 벤치마크 | microbenchmark, bench, benchmarks 패키지, 파일 I/O 시간 측정 |
| Lazy Loading | 필요 시에만 메모리 로드 → 메모리 절약 & 속도 향상 |
| Human‑Readable vs Binary | 가독성(텍스트) vs 성능(바이너리) 선택 시 고려 요소 |
| 비용·전력 | SSD/NVMe 가격 상승, 2000 TB 규모 시 2 TB RAM 한계, 전력 소비 |
상세 노트
1. 저장 장치와 RAID
- HDD: 7200 RPM, 10–12 GB/s (대용량·저비용)
- SSD: 500 GB/s(PCI‑e) → 5 TB/s(PCI‑e 4.0)
- NVMe: PCI‑e 4.0 → 10 TB/s, 1 TB/s 읽기/쓰기
- RAID 0: 최대 속도, 무리한 데이터 손실 위험
- RAID 10: 성능·신뢰성 균형, 2 TB RAM 한계와 병행해 4 TB 이상 저장 가능
Tip: 2000 TB 규모를 다루려면 RAID 10 + NVMe SSD 조합이 가장 실용적.
2. 메모리와 ECC
- ECC: 24/7 운영 시 블루스크린 방지, 비용 상승
- RAM 용량: 일반 PC 2 TB, 서버 4–8 TB
- 메모리 병렬성: 1 GB 데이터 → 512 GB RAM → 1 TB 이상 데이터는 Lazy Loading 필요
3. 파일 포맷과 R 패키지
| 포맷 | 특징 | R 패키지 | 사용 시나리오 |
|---|---|---|---|
| CSV | 텍스트, 가독성 | readr::read_csv, data.table::fread | 작은 데이터, 공유 |
| Feather | 바이너리, 2–3 배 빠름 | feather::read_feather, arrow::write_feather | 모델링 전 단계, 대용량 |
| Parquet | 컬럼형, 압축, 스키마 | arrow::write_parquet, parquet::read_parquet | 저장 용량 절약, 분석 |
| Arrow | 인‑메모리, 언어 독립 | arrow::read_table, arrow::write_table | R ↔ Python ↔ Scala 간 데이터 교환 |
Benchmark:
microbenchmark::microbenchmark로 각 포맷·패키지의 읽기/쓰기 시간을 측정하고, Feather가 가장 빠르고 Parquet가 가장 압축률이 높음.
4. 파일 I/O 벤치마킹 실습
- 데이터 생성: 1,000 × 2,000 랜덤 행렬
- 파일 저장:
write.table,fwrite,write_feather,write_parquet - 시간 측정:
microbenchmark - 결과
write.table: ~3 초 (CSV)fwrite: ~0.5 초 (CSV)write_feather: ~0.1 초write_parquet: ~0.2 초
Insight: CSV는 가독성에, Feather는 속도에, Parquet은 압축에 최적.
5. Lazy Loading & Memory Management
- Lazy Loading: 필요 시에만 메모리 로드 → 대용량 데이터 처리 시 메모리 부족 방지
feather:feather::read_feather(..., lazy = TRUE)사용arrow:arrow::read_table(..., use_threads = TRUE)로 멀티스레드 활용
Tip: 2 TB RAM 한계가 있는 경우 메모리 매핑(memory‑mapped) 파일 사용을 고려.
6. Human‑Readable vs Binary
| 포맷 | 가독성 | 성능 | 용도 |
|---|---|---|---|
| CSV | 높음 | 낮음 | 공유, 문서화 |
| Feather | 낮음 | 높음 | 모델링 전 단계 |
| Parquet | 중간 | 높음 | 저장, 분석 |
| Arrow | 중간 | 높음 | 언어 간 교환 |
7. 그림·보고서 파일 포맷
- PNG/JPEG: 비트맵, DPI 300 이상 권장 (인쇄용)
- SVG/PNG: 벡터, 확대 시 품질 유지
- PDF: 벡터 + 텍스트, 인쇄 및 배포에 최적
Tip: R에서
ggsave(..., dpi = 300, width = 8, height = 6)사용.
8. 실무 팁
- RAID 구성: 10 → 2 TB SSD + 2 TB HDD → 4 TB 저장, 1 TB 이상 쓰기/읽기
- 파일 I/O:
fwrite+feather조합이 가장 빠름 - 벤치마크: 정기적으로
microbenchmark실행 → 하드웨어·소프트웨어 변화 감지 - 메모리: ECC RAM 사용 시 안정성 ↑, 비용 ↑
- 데이터 전처리:
data.table로 빠른 필터링,arrow로 대용량 열 단위 연산
마무리
- 핵심: 저장 장치(SSD/NVMe, RAID), 파일 포맷(CSV, Feather, Parquet, Arrow), 벤치마크(microbenchmark), 메모리 관리(Lazy Loading, ECC) 를 종합적으로 이해하고 적용해야 대용량 데이터 처리의 성능과 안정성을 확보할 수 있다.
- 실전: 실제 데이터(≈2 TB) 를
feather로 저장 →arrow로 읽기 →microbenchmark로 성능 측정 → 결과를 보고서에 포함.
결론: 파일 I/O 최적화는 단순히 “속도 빠르게”가 아니라 가용성·비용·가독성을 동시에 고려한 전략적 선택이 필요하다.