2026-11-05 · 출처：KDNuggets
평범한 데이터 로딩 단계가 상주 메모리를 거의 19배로 불렸다. ijson 같은 스트리밍 파서는 레코드를 한 번에 하나씩 처리해 파일 크기와 무관하게 메모리 사용량을 평평하게 유지한다.
808 MB. 디스크에서 겨우 43 MB짜리 JSON 파일 하나를 섭취한 파이썬 프로세스가 도달한 메모리 풋프린트다. 거의 19배 확장이며, 최근 KDNuggets의 엔지니어링 워크스루가 다룬 문제의 핵심이다.
이 점프는 버그가 아니다. 파일 통째로 파싱하는 기본 동작이다. 파이썬이 관습적인 방식으로 JSON 문서를 로드하면, 분석이 시작되기 한참 전에 온 계층 구조를 한꺼번에 구체화한다. 모든 객체, 배열, 문자열이 파이썬 고유 구조로 실체화되는 것이다. 파이썬 객체는 항목당 상당한 오버헤드를 지니기 때문에 텍스트로는 컴팩트한 문서가 살아 있는 메모리에서는 한 자릿수 더 크게 자리 잡을 수 있다. 파일 크기가 RAM 요구량의 믿을 만한 대리 지표라고 가정했던 팀에게, 43 MB와 808 MB 사이의 거리는 유쾌하지 않은 교정이다.
워크스루의 해답은 스트리밍 파서 ijson이다. 문서 전체를 메모리에 올리는 대신, ijson은 문서를 점진적으로 순회하며 한 번에 하나의 레코드를 내어준다. 그래서 코드는 다음 항목이 도착하기 전에 각 항목을 처리하고 버릴 수 있다. 메모리 사용량은 그러면 파일 크기가 아니라 단일 레코드의 크기를 따라간다. 저자가 스트리밍이 '모든 것을 바꿨다'고 말하는 바로 그 의미다.
교훈은 하나의 파일 형식을 넘어 확장된다. RAM 천장에 부딪히는 파이프라인은 대개 데이터가 진짜로 너무 커서 실패하는 게 아니라, 로딩 전략이 모든 것을 동시에 실체화하기를 고집하기 때문에 실패한다.
AI 인프라 기획자에게 이 사건은 조용하지만 실용적인 데이터 포인트다. 학습과 전처리 노드의 메모리 여유분은 비싸고, 43 MB 입력을 808 MB 상주 메모리로 부풀리는 단계는 근본 워크로드가 실제로 요구하는 것보다 더 큰 인스턴스를 강요한다. 스트리밍 수집이 가장 저렴한 최적화 중 하나로 꼽히는 이유는 정확히 그것 때문이다. 새 하드웨어가 필요 없고, 다른 파싱 경로만 있으면 된다.
태그: ijson · Python · JSON Streaming · Memory Management · Data Engineering
萬安算交所 AIXX · AIXX · 검증된 컴퓨트 거래소 · 현물 홀 입장