크롤링 데이터 저장 형식

크롤링 데이터 저장 형식

HTML·JSON·Parquet·KV 저장소는 크롤링 데이터에 각각 언제 적합한가.

Scope

핵심 질문

웹 크롤링 결과를 파일, JSON, Parquet, 관계형 DB, KV 저장소 중 어떤 형태로 저장해야 하는가?

Research

핵심 근거

• 원문 보존과 분석용 데이터는 접근패턴이 달라 별도 계층으로 분리하는 것이 유리하다.
• 작은 파일 수백만 개는 filesystem metadata와 backup/listing 비용을 키울 수 있다.
• Parquet는 대량 columnar analytics에, KV/DB는 key lookup과 incremental update에 유리하다.

참고 자료

• Apache Parquet: https://parquet.apache.org/

Draft

크롤링 데이터 저장 형식은 '무엇을 저장하는가'보다 이후 어떻게 읽을 것인가에 따라 결정해야 한다.

원문과 구조화 데이터 분리

HTML 원문은 재파싱과 증거보존을 위해 그대로 남길 가치가 있다. 반면 제목, 날짜, 본문, 링크처럼 분석에 필요한 필드는 구조화해서 따로 저장하는 편이 효율적이다.

한 페이지 한 파일

가장 단순하고 복구가 쉽다. 하지만 수백만 개의 작은 파일이 생기면 directory traversal, inode, backup과 sync 비용이 커질 수 있다.

JSON

사람이 읽기 쉽고 schema 변화에 유연하다. 그러나 대량 분석에서는 parsing 비용과 저장효율이 좋지 않다.

Parquet

컬럼 단위 압축과 predicate pushdown이 가능해 대량 데이터 분석에 적합하다. 날짜나 domain 단위로 partition하면 DuckDB, Spark 같은 엔진에서 효율적으로 조회할 수 있다.

대신 개별 페이지 하나를 빈번하게 업데이트하는 용도에는 불편하다.

DB와 KV Store

URL이나 content hash로 개별 문서를 빠르게 찾고 상태를 업데이트하려면 관계형 DB나 KV store가 유리하다. crawl queue와 metadata 저장에도 적합하다.

실용적 구성

원문은 object/file storage, crawl 상태와 metadata는 DB, 분석용 snapshot은 Parquet로 두는 혼합구조가 자주 합리적이다.

핵심

저장 형식 하나로 모든 목적을 해결하려 하지 않는 것이 좋다. 원문 보존, point lookup, incremental state, 대량 분석이라는 서로 다른 접근패턴에 맞춰 계층을 나누는 것이 핵심이다.