Handling Large CSV Files: Performance Tips and Tools - CSV-X.com

3년 전, 저는 주니어 데이터 분석가의 노트북 팬이 그가 Excel에서 4GB 고객 거래 파일을 열려고 할 때 제트 엔진처럼 비명을 지르는 모습을 보았습니다. 애플리케이션은 멈췄고, 그의 얼굴은 창백해졌습니다. 20분 후, Excel은 충돌했고, 저장되지 않은 두 시간의 작업을 함께 잃었습니다. 그 순간은 대다수 사람들이 대형 CSV 파일에 접근하는 방식의 모든 잘못된 점을 응축시켰고, 그래서 저는 지난 10년 동안 데이터 인프라 엔지니어로서 기업들이 땀도 흘리지 않고 수십억 행을 처리할 수 있도록 도와왔습니다.

저는 마커스 첸이며, 2014년 이후로 포춘 500 기업을 위해 데이터 파이프라인을 구축해왔습니다. 저는 팀들이 CSV 파일로 싸우느라 수천 시간의 엔지니어링 시간을 낭비하는 것을 보았습니다. 진실은 대부분의 개발자와 분석가들이 작은 데이터셋을 위해 설계된 도구를 여러 배 큰 파일에서 사용하고 있다는 것입니다. 마치 픽업 트럭으로 집을 옮기려는 것과 같죠—기술적으로 가능하지만 고통스럽게 비효율적입니다.

이 가이드에서는 50MB 마케팅 목록에서 200GB 유전체 데이터셋까지 처리하면서 얻은 값진 교훈을 공유하겠습니다. 현재 도구가 언제 실패할지, 어떤 대안이 있는지, 그리고 특정 상황에 맞는 올바른 접근 방식을 어떻게 선택할 수 있는지에 대해 배울 것입니다. 이론적인 뻔한 말이 아니라, 제가 매일 사용하는 전투에서 검증된 기법들입니다.

파괴 지점 이해하기: 도구가 실패하기 시작할 때

솔루션에 들어가기 전에, 전통적인 도구가 어디에서 깨지는지를 정확히 이해해야 합니다. 저는 수백 가지 시나리오에서 수십 개의 애플리케이션에 대한 벤치마크를 수행했으며, 패턴은 놀라울 만큼 일관됩니다.

Excel은 수백만 전문가들의 기본 도구로, 1,048,576행에서 단단한 벽에 부딪힙니다. 그러나 실제로는 그 이전에 성능이 상당히 저하됩니다. 8GB RAM을 가진 일반 비즈니스 노트북에서는 100,000행 주변에서 Excel이 느려지고 500,000행을 넘기면 거의 사용할 수 없게 됩니다. 저는 200MB 범위의 파일을 불러오는 데 3-5분 걸리는 로드 시간을 측정했습니다. 이는 실제 분석을 시도하기 전의 시간입니다.

Google Sheets는 더 제한적입니다. 공식 한도는 총 1,000만 셀로, 이는 고객 분석에서 일반적인 50열 20만 행 환경을 생각할 때 관대하게 들리지만, 느린 연결에서는 50MB를 초과하는 파일 업로드 시간이 15-20분으로 늘어날 수 있으며, 협업 편집이 고통스럽게 느려질 수 있습니다.

Notepad++나 Sublime Text와 같은 텍스트 편집기는 더 큰 파일을 더 잘 다루지만, 데이터 조작을 위해 설계되지 않았습니다. 저는 Sublime Text에서 2GB 파일을 성공적으로 열었지만, 검색이나 편집이 점점 느려집니다. Notepad++는 500MB 정도에서 어려움을 겪기 시작하며, CSV 구조를 시각적으로 분석하기 위해 사용할 수 있는 구문 강조 기능이 성능을 크게 떨어뜨릴 수 있습니다.

진짜 문제는 단순히 파일 크기만이 아닙니다. 크기, 열 개수, 그리고 데이터로 무엇을 해야 하는지의 조합이 문제입니다. 10열의 1GB 파일은 200열의 1GB 파일과 본질적으로 다릅니다. 전자는 간단한 데이터의 5천만 행을 가질 수 있고, 후자는 복잡하고 중첩된 정보의 200만 행을 가질 수 있습니다. 접근 방식은 두 차원을 모두 고려해야 합니다.

제가 정기적으로 수행하는 실용적인 벤치마크가 있습니다: 표준화된 500MB CSV 파일을 테스트하여 5백만 행의 전자상거래 거래 데이터와 25개 열이 포함되어 있습니다. Excel은 열기에 4분이 걸리고 3.2GB의 RAM을 사용합니다. pandas가 포함된 Python은 로드하는 데 8초가 걸리고 1.8GB의 RAM을 사용합니다. Python의 csv 모듈을 사용하는 스트리밍 접근방식은 파일 전체를 12초 만에 처리하면서 단지 50MB의 RAM만 사용합니다. 올바른 도구는 메모리 사용에서 48배 차이를 만듭니다.

메모리 문제: 왜 CSV 파일이 크기가 폭발하는가

CSV 파일 작업에서 가장 오해되는 측면 중 하나는 메모리 소비입니다. 저는 개발자들과 수많은 대화를 나누었고, 그들 중 많은 이들은 500MB CSV 파일을 처리하는 데 4GB의 RAM이 필요하다는 것에 충격을 받습니다. 왜 이렇게 되는지를 이해하는 것이 올바른 접근 방식을 선택하는 데 중요합니다.

"대부분의 개발자들은 CSV 파일을 모두 같은 크기로 취급합니다. 이는 조종사가 Cessna와 747을 착륙시키기 위해 같은 기술을 사용하는 것과 같습니다—재앙의 조합입니다."

CSV 파일을 메모리로 로드할 때, 원시 텍스트를 저장하는 것만이 아닙니다. 대부분의 도구는 이를 훨씬 더 많은 메모리를 사용하는 데이터 구조로 구문 분석합니다. 예를 들어 pandas에서는 CSV 파일이 DataFrame에 로드될 때 일반적으로 디스크에 저장된 크기의 3-5배로 확장됩니다. 500MB 파일은 메모리에서 2GB가 됩니다. 이는 pandas가 각 값을 최적화된 형식, 메타데이터, 인덱스 및 유형 정보로 저장하기 때문입니다.

문자열 열은 특히 문제가 됩니다. "California"라는 단어가 백만 번 반복된 열은 디스크에서 10MB만 차지할 수 있지만(압축과 함께) 메모리에서 각 인스턴스는 구현에 따라 50-100바이트를 소비할 수 있습니다. 이는 하나의 열에 대해 50-100MB입니다. 여러 열에 걸쳐 이를 곱하면 메모리가 폭발하는 이유를 알 수 있습니다.

저는 2017년에 소매 클라이언트를 위한 고객 피드백 데이터를 처리할 때 이 교훈을 어렵게 배웠습니다. 우리는 자유 텍스트 댓글이 포함된 1.2GB CSV 파일을 가지고 있었습니다. 저의 초기 pandas 스크립트는 16GB 서버에서 반복적으로 충돌했습니다. 문제는? 댓글 열이 각 행당 평균 200자를 포함하고 있었고, pandas는 각 항목을 Python 객체로 저장하여 각 댓글당 약 500바이트를 소비했습니다. 800만 행이 있으면, 단일 열이 다른 30개의 열을 처리하기도 전에 4GB의 RAM을 필요로 했습니다.

해답은 세 가지 전략을 포함했습니다: 먼저, 우리는 pandas의 dtype 매개변수를 사용하여 열 유형을 명시적으로 설정하여 메모리 사용량을 40% 줄였습니다. 둘째, 우리는 모든 것을 한 번에 로드하는 대신 100,000행의 청크로 파일을 처리했습니다. 셋째, 우리는 적절한 경우 문자열 열을 범주형 유형으로 변환했습니다—반복 값이 있는 열에 대해 메모리 사용량을 추가적으로 60% 줄이는 기법입니다.

다음은 dtype 사양의 차이를 보여주는 구체적인 예입니다. 0에서 100까지의 정수 열을 고려해 보십시오. 기본적으로 pandas는 int64를 사용할 수 있으며, 값당 8바이트를 소비합니다. 그러나 int8을 지정하면 값당 1바이트만 사용됩니다—8배 감소입니다. 1000만 행에서는 단일 열에 대해 80MB와 10MB 사이의 차이가 있습니다. 20개의 숫자 열 전반에 걸쳐서는 1.4GB의 RAM을 절약한 것입니다.

스트리밍 vs. 로딩: 처리 전략 선택하기

대형 CSV 파일을 처리하는 기본 결정은 전체 데이터 세트를 메모리로 로드할 것인지 아니면 스트림으로 처리할 것인지입니다. 이 선택은 도구 선택부터 코드 아키텍처에 이르기까지 모든 것에 영향을 주며, 잘못된 선택은 몇 분 만에 실행되는 스크립트와 결코 완료되지 않는 스크립트의 차이를 의미할 수 있습니다.

전체 파일을 메모리에 로드하는 것은 제가 "한 번에 모두" 접근 방식이라고 부르며, 데이터에 대한 무작위 접근이 필요할 때 적합합니다. 데이터 세트의 서로 다른 부분 간의 복잡한 조인이나 데이터를 여러 번 통과해야 할 때 필요합니다. pandas, R의 data.table, 심지어 Excel과 같은 도구들이 이 접근 방식을 사용합니다. 장점은 속도와 유연성입니다: 로드한 후에는 모든 것이 RAM에 있기 때문에 작업이 빠릅니다. 단점은 분명합니다: 전체 데이터 세트를 보유할 만큼의 메모리와 오버헤드 작업이 필요합니다.

반면 스트리밍은 파일을 행별 또는 작은 청크로 처리합니다. 일부를 읽고, 처리하고, 결과를 작성한 후 다음 부분으로 이동합니다. 메모리 사용량은 파일 크기와 상관없이 일정하게 유지됩니다. ETL 파이프라인, 데이터 검증, 필터링 작업, 전체 데이터 세트를 한 번에 볼 필요 없이 한 형식에서 다른 형식으로 데이터를 변환하는 모든 시나리오에서 저는 스트리밍을 사용합니다.

다음은 제가 지난해 완료한 프로젝트의 실제 비교입니다. 우리는 온도가 100°F를 초과하는 기록만 유지하면서 15GB의 CSV 파일에서 센서 판독값을 필터링할 필요가 있었습니다. pandas의 한 번에 모두 접근 방식은 60GB 이상의 RAM이 필요한 서버를 요구했습니다. 대신, 저는 Python의 csv 모듈을 사용하여 한 번에 100,000행을 처리하는 스트리밍 스크립트를 작성했습니다. 총 메모리 사용량: 200MB. 처리 시간: 표준 노트북에서 8분. 스트리밍 접근 방식이 실제로 더 빨랐습니다. 왜냐하면 전체 데이터 세트를 로드하고 인덱싱하는 오버헤드를 피했기 때문입니다.

하이브리드 접근 방식인 청크 처리 역시 중간 지점을 제공합니다. 관리 가능한 청크를 메모리에 로드하고 각 청크에서 복잡한 작업을 수행한 다음 결과를 결합합니다. 이것은 제 g