From Bulk Load to Data Lake

TL;DR

• 파일은 원래 벌크 로더의 입력이었고 Hadoop과 Hive를 거치며 임시물에서 최종 저장소로 승격
• Hive가 테이블을 “이 디렉터리 아래 파일 전부”로 정의하면서 dt=2010-03-01 경로 규약이 굳어짐
• 객체 스토리지에 UPDATE와 인덱스가 없어 파티션 경로를 인덱스 대용·재작성 단위·멱등 키로 사용

AI-assisted

---

1. 파일은 원래 중간 산물이었다

RDB 시대의 배치 적재는 벌크 로더가 맡았다. 행 단위 INSERT는 건마다 인덱스 갱신, WAL 기록, 제약 검사, 락이 붙어서 100만 건이면 몇 시간이 걸린다.

그래서 DW마다 벌크 로더가 따로 있었고 전부 파일을 입력으로 받았다.

제품	벌크 로더
Oracle	SQL*Loader (sqlldr)
Teradata	FastLoad, MultiLoad
SQL Server	BULK INSERT, bcp
PostgreSQL	COPY
MySQL	LOAD DATA INFILE

적재 순서는 이렇다.

1. 추출: 소스 DB에서 데이터를 꺼내 /tmp/orders_20050301.dat 같은 flat file로 저장한다.
2. 벌크 로드: 로더가 파일을 읽어 DW 테이블에 적재한다.
3. 파일 삭제: 적재가 끝나면 중간 파일을 삭제하고 이후 조회는 DW 테이블에서 수행한다.

파일은 처음부터 있었지만 로더가 읽은 뒤 삭제하는 임시 파일이었다. 조회하는 쪽이 보는 것은 언제나 DW 테이블이었다.

로더가 빠른 이유: 우회하는 것이 많다

• 인덱스를 건별로 갱신하지 않고 적재가 끝난 뒤 한 번에 다시 만든다
• 로그 기록을 최소화하거나 끈다. 실패하면 처음부터 다시 돌리는 쪽을 택한다
• 제약 검사를 나중으로 미루거나 위반 행을 별도 파일로 뺀다
• Oracle의 direct path load는 행 단위 SQL 처리 대신 데이터 블록을 직접 만들어 저장한다

---

2. 파일이 목적지가 되다

2000년대 중반에는 늘어나는 데이터를 모두 DB에 적재하기 어려워졌다.

• 웹 로그와 클릭스트림이 하루 수 TB씩 쌓이기 시작했다
• 이 데이터는 대부분 한 번 훑고 마는 성격이라 인덱스와 트랜잭션이 필요 없었다
• DW에 넣으려면 라이선스와 장비 비용이 데이터 가치를 넘어섰다

Google의 GFS와 MapReduce 논문을 거쳐 Hadoop이 2006년에 나오면서 다른 선택지가 생겼다. 파일을 여러 서버에 흩어 두고 계산을 그쪽으로 보내는 방식이다.

구분	DB에 적재하는 방식	분산 파일 시스템에 저장하는 방식
데이터 저장	파일을 DB 테이블에 적재	파일을 분산 파일 시스템에 저장
조회 대상	DB 테이블	저장된 파일을 엔진이 직접 읽음
파일의 역할	적재 후 삭제하는 중간 파일	보관하며 조회하는 원본 데이터

바뀐 것은 파일의 지위다. 적재 후 삭제하던 파일을 보관하며 조회에 사용하게 됐다.

이 시기 나온 Sqoop은 RDB 테이블의 데이터를 읽어 HDFS에 파일로 저장하는 도구다.

이때는 아직 "레이크"가 아니다

• HDFS는 저장과 계산이 같은 장비에 묶여 있었다. 용량만 늘리고 싶어도 서버를 통째로 사야 했다
• 파일은 쌓였지만 그걸 조회할 방법이 MapReduce 자바 코드뿐이었다
• 조회 문제는 Hive가 풀고 결합 문제는 S3가 푼다

---

3. Hive가 디렉터리를 테이블이라고 불렀다

파일이 쌓이자 다음 문제는 조회였다. 집계 하나 뽑으려고 매번 MapReduce job을 자바로 짜는 것은 감당이 안 됐다.

Facebook이 2008년에 만든 Hive가 SQL을 MapReduce로 번역해 이 문제를 풀었다. SQL을 붙이려면 테이블이 뭔지부터 정의해야 했는데 Hive는 이렇게 정했다.

• 테이블: 이 디렉터리 아래 있는 파일 전부
• 파티션: 그 아래 하위 디렉터리
• 스키마: 메타스토어(별도 RDB)에 저장

경로는 key=value 형태로 굳었다.

/user/hive/warehouse/orders/
  dt=2010-03-01/000000_0
  dt=2010-03-02/000000_0
  dt=2010-03-03/000000_0

Hive-style partitioning이라고 부른다. 지금 S3에 쌓는 dt=2026-08-17도 이 규약을 따른다.

적재 문법도 함께 바뀌었다.

-- 행을 추가하는 것이 아니라 파티션 하나를 갈아엎는다
INSERT OVERWRITE TABLE orders PARTITION (dt='2010-03-01')
SELECT * FROM staging WHERE order_date = '2010-03-01';

INSERT INTO로 행을 추가하던 방식과 달리 INSERT OVERWRITE는 지정한 파티션의 데이터를 쿼리 결과로 교체한다. 이때 교체 범위는 파티션 디렉터리 아래의 데이터 파일 전체다.

메타스토어와 파일이 어긋날 수 있다

• Hive는 스키마와 파티션 목록을 메타스토어에 두고 데이터는 HDFS에 뒀다. 두 곳이 따로 논다
• 다른 job이 파일을 경로에 직접 저장하면 메타스토어에 등록되지 않아 쿼리에서 조회되지 않는다
• 그래서 MSCK REPAIR TABLE로 파일 시스템을 훑어 파티션을 다시 등록하는 명령이 따로 있다
• 이 어긋남이 나중에 테이블 포맷이 파일 목록을 메타데이터에 직접 적게 된 이유다

---

4. 파티션 경로의 세 가지 용도

파일 시스템에 없는 기능을 보완하려고 파티션 경로에 키를 넣고 조회와 재처리에 사용했다.

RDB의 기능	레이크에서 파티션 경로를 사용하는 방식
인덱스	dt=2026-08-17 경로로 후보를 좁힌다
UPDATE/DELETE	그 디렉터리만 새로 쓴다
트랜잭션 재실행	같은 경로를 덮어쓰면 결과가 같다

세 가지를 나눠 보면 이렇다.

• 인덱스 대용: 객체 스토리지에는 B-tree가 없다. 경로에 조건을 넣어두면 조회할 디렉터리를 좁힐 수 있다. WHERE dt='2026-08-17'이 디렉터리 하나를 고르는 연산이 된다
• 재작성 단위: S3 객체는 부분 수정이 안 되고 통째로 덮어쓰는 것만 된다. 다시 쓸 수 있는 최소 덩어리를 미리 정해둬야 하고 그것을 표현할 수단이 경로다
• 멱등 키: 배치가 실패해서 다시 돌릴 때 INSERT는 중복이 쌓인다. dt=2026-08-17 디렉터리를 지우고 새로 쓰면 몇 번을 돌려도 결과가 같다

파티션 단위로 덮어쓰면 같은 입력으로 배치를 다시 실행해도 데이터가 중복으로 쌓이지 않는다.

주의: 파티션 키를 잘못 잡으면 되돌리기 어렵다

• 파티션 키는 곧 디렉터리 구조다. 바꾸려면 전체를 다시 써야 한다
• 카디널리티가 높은 컬럼으로 나누면 디렉터리가 수만 개로 불어나 작은 파일 문제가 생긴다
• 그래서 날짜처럼 값 범위가 예측되는 컬럼을 쓴다
• Iceberg는 파티션 스펙을 메타데이터에 기록해 파티션을 나누는 규칙을 경로와 분리한다

---

5. S3에 저장하고 계산 자원을 따로 쓰다

Hive까지 와도 저장과 계산은 여전히 한 덩어리였다. 디스크가 모자라면 CPU까지 같이 사야 했다.

2006년에 나온 S3에 데이터를 저장하면 계산용 서버와 별도로 저장 용량을 늘릴 수 있었다. 저장은 S3에 두고 계산할 때만 클러스터를 띄우는 구성이 가능해졌다. 실제 이동은 관리형 Hadoop인 EMR이 나온 2009년 이후에 본격화됐다.

• 비용: GB당 단가가 자체 운영 HDFS보다 낮고 쓰는 만큼만 낸다
• 탄력성: 야간 배치에만 노드 100대를 띄우고 끝나면 반납한다
• 운영: NameNode 이중화와 디스크 교체가 사라진다

기존 경로 규약을 S3에서도 사용할 수 있었다. s3://bucket/orders/dt=2026-08-17/은 HDFS 경로와 생김새가 같다.

이 무렵 James Dixon이 데이터 레이크라는 말을 만들었다.

주의: S3는 파일 시스템이 아니다

• 디렉터리가 실재하지 않는다. dt=2026-08-17/part-0은 슬래시가 든 키 하나일 뿐이다
• rename이 원자적이지 않다. 복사 후 삭제라 파일 수만큼 비용이 붙는다. 파티션 덮어쓰기가 중간에 실패하면 부분 반영 상태가 남는다
• 2020년 12월 전까지 읽기 일관성이 최종 일관성이었다. 방금 쓴 파일이 목록에 안 잡히는 일이 있었다
• 이 셋이 테이블 포맷이 커밋 원자성을 따로 설계하게 된 배경이다

---

6. 얻은 것과 잃은 것

스키마를 다루는 시점도 함께 옮겨갔다.

	schema-on-write	schema-on-read
검증 시점	넣을 때	읽을 때
스키마 위치	카탈로그	파일 안 또는 없음
소스가 필드를 추가하면	적재 실패	일단 쌓이고 나중에 해석
대표	RDBMS, DW	Parquet, Avro, JSON

얻은 것.

• 원본 보존: 변환 로직이 틀려도 원본 파일이 남아 있어 고쳐서 다시 돌린다. INSERT한 데이터는 원본이 사라져 복구가 안 된다
• 적재 지연 감소: 파싱과 검증을 뒤로 미루면 파일을 저장하는 것으로 수집이 끝난다
• 비정형 수용: 로그, 중첩 JSON, 이벤트처럼 관계형 테이블에 안 맞는 데이터를 그대로 받는다

잃은 것.

• 원자성: 쓰는 도중에 읽으면 절반만 반영된 상태가 보여 원자성을 보장하지 못한다
• 일관성 강제: 오타로 생긴 컬럼도 그대로 쌓인다. 검증할 주체가 없다
• 롤백: 잘못 쓴 배치를 되돌릴 방법이 없다
• 스키마 관리: 파일마다 스키마가 달라 컬럼 이름을 바꾸면 과거 데이터가 오류 없이 null로 읽힌다

데이터 늪(data swamp)이라는 말이 이 시기에 나왔다. 여러 데이터를 쌓다가 무엇이 들어 있는지 파악하기 어려워진 상태를 가리킨다.

---

7. 다시 테이블로

2017년 이후 Iceberg·Delta·Hudi로 여러 데이터 파일을 하나의 테이블로 관리하게 됐다. 파일 목록을 메타데이터에 직접 기록해서 메타스토어 불일치와 앞에서 잃은 것을 되돌리는 방식이다.

시기	저장 방식	트랜잭션	유연성	비용
1990s	DB 테이블	O	X	비쌈
2010s	파일 더미	X	O	쌈
2020s	파일 + 테이블 포맷	O	O	쌈

문법도 되돌아왔다.

-- 2010년: 파티션을 통째로 갈아엎는다
INSERT OVERWRITE TABLE orders PARTITION (dt='2010-03-01') SELECT ...;
 
-- 지금: 행 단위로 병합한다
MERGE INTO orders t USING updates s ON t.order_id = s.order_id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

MERGE INTO는 20년 전 DW에 있던 문법이다. 같은 문법을 사용해도 데이터를 저장하고 계산하는 구성은 달라졌다. 저장은 객체 스토리지에 남았고 계산은 분리된 채다.

테이블 포맷에서는 경로에 의존하던 세 기능을 메타데이터와 트랜잭션으로 처리한다.

경로로 처리하던 기능	테이블 포맷의 처리 수단
인덱스	manifest의 컬럼 통계와 파일 단위 min/max
재작성 단위	스냅샷과 커밋
멱등 키	트랜잭션과 롤백

파티션 디렉터리가 사라진 것은 아니며 다만 조회 성능을 경로에만 기대지 않게 됐다. 통계는 파일 포맷의 footer와 테이블 포맷의 manifest 두 곳에 나뉘어 있다.