Apache Hudi 는 데이터 레이크에 놓인 파일 묶음을 갱신·삭제할 수 있는 테이블처럼 다루게 해 주는 테이블 포맷이자 그 위에서 도는 적재 도구다. 오브젝트 스토리지나 HDFS 에 파케이 파일을 쌓기만 하면 한 건을 고치려 해도 파티션을 통째로 다시 써야 하는데, Hudi 는 레코드 키를 기준으로 upsert 와 delete 를 처리하고 변경 이력을 남긴다. Iceberg · Delta Lake 와 같은 자리를 놓고 겨루는 제품이다.
Hudi 를 고를 때 가장 먼저 정하는 것이 테이블 유형이다. 적재 지연과 조회 성능 사이에서 어느 쪽을 택할지를 여기서 결정한다.
| 유형 | 동작 | 맞는 자리 |
|---|---|---|
| Copy On Write (COW) | 갱신이 들어오면 해당 파일을 새로 써서 교체한다. 조회는 항상 정리된 파케이를 읽는다 | 읽기가 잦고 갱신이 드문 테이블 |
| Merge On Read (MOR) | 갱신을 로그 파일에 먼저 적고, 압축(compaction) 시점에 본 파일과 합친다 | 적재가 잦고 지연을 줄여야 하는 테이블 |
MOR 은 적재가 가볍지만 조회할 때 로그를 합쳐 읽어야 하므로 압축을 제때 돌리지 않으면 조회가 점점 느려진다. 압축 주기와 실패 감시가 운영의 핵심이 된다.
| 조회 | 보이는 것 |
|---|---|
| Snapshot | 가장 최근 커밋 기준의 전체 모습. 일반적인 조회 |
| Read Optimized | 압축이 끝난 본 파일만 읽는다. MOR 에서 빠르지만 최신 변경이 빠질 수 있다 |
| Incremental | 지정한 커밋 시각 이후 바뀐 레코드만 읽는다. 다운스트림 적재를 증분으로 돌릴 때 쓴다 |
증분 조회가 Hudi 를 쓰는 큰 이유다. 원본 테이블 전체를 다시 훑지 않고 바뀐 부분만 받아 다음 계층을 갱신할 수 있다.
recordkey — 레코드를 식별하는 키. 이 값이 같으면 갱신으로 본다.precombine — 같은 키가 한 배치에 여러 번 들어왔을 때 어느 쪽을 남길지 정하는 컬럼. 보통 갱신 시각을 쓴다.partitionpath — 파티션 컬럼. 잘못 잡으면 작은 파일이 폭증한다.같은 자리의 제품이 셋이므로 실제 선택은 주변 도구가 결정한다. 이미 쓰고 있는 엔진이 무엇을 읽고 쓸 수 있는지, 카탈로그를 무엇으로 둘 것인지를 먼저 확인한다. Impala · Trino · Spark 각각의 지원 범위가 다르고, 벤더 배포판은 특정 포맷만 지원하는 경우가 있다. Cloudera 배포판에서는 Iceberg 쪽이 표준 경로로 잡혀 있으므로, Hudi 를 쓰려면 지원 범위를 먼저 확인해야 한다 (확인 필요).