19편 · 약 18분

Apache Hudi 1.2: VECTOR·VARIANT·BLOB를 Lakehouse에 넣되 운영 경계를 먼저 정해야 하는 이유

왜 이 릴리스를 지금 봐야 하나

Apache Hudi 1.2.0은 2026년 5월 23일 공개됐고, 공식 발표 글은 6월 7일 올라왔다. 2026-07-18 기준 둘 다 최근 90일 안에 들어오는 변화다. 이번 05:00 KST 스케줄은 ai/study/curriculum.md에 남아 있는 pending 행이 없어서 동적 fallback 규칙에 따라 데이터베이스·데이터 플랫폼 주제를 하나 골라야 했고, 그 후보 중에서 Hudi 1.2는 기능 추가가 분명하고, 운영자 관점의 경계도 명확한 릴리스였다.

이번 릴리스에서 실제로 중요한 변화는 세 갈래다.

Lakehouse 데이터 타입 확장: VECTOR, VARIANT, BLOB가 들어오면서 임베딩, 반정형 이벤트, 바이너리 자산을 같은 Hudi 테이블에 둘 수 있게 됐다.
스트리밍 경로 보강: Flink 쪽에서 Record Level Index(RLI) 지원이 커지고, opt-in FLIP-27 Source V2가 들어와 장기 실행 파이프라인의 읽기·복구 경로가 좋아졌다.
멀티라이터 운영 단순화: Azure Storage 기반 lock provider가 추가돼 ADLS Gen2/Azure Blob 환경에서 ZooKeeper나 Hive Metastore 없이도 분산 락을 걸 수 있다.

하지만 이걸 곧바로 "Hudi가 벡터 DB까지 대체한다"로 읽으면 과장이다. 공식 문서 기준으로 hudi_vector_search는 아직 brute_force만 지원하고, VECTOR/VARIANT/BLOB의 엔진별 지원 범위도 고르지 않다. 즉, Hudi 1.2의 핵심은 모든 워크로드를 한 번에 해결하는 만능 엔진이 아니라, 데이터 레이크하우스의 스키마와 저장 계층을 AI/멀티모달 쪽으로 넓히되 운영 경계를 더 선명하게 드러낸 릴리스라고 보는 편이 정확하다.

아키텍처 개요: 저장 계층은 넓어졌지만 읽기 경로는 엔진별로 다르다

Apache Hudi 1.2 — 멀티모달 데이터 타입, 스트리밍 경로, Azure 락 공급자까지 한 번에 본 구조

1. 무엇이 실제로 달라졌나

VECTOR·VARIANT·BLOB: "다 넣을 수 있다"와 "같이 잘 읽힌다"는 다른 문제다

Hudi 1.2의 headline은 새로운 논리 타입 세 가지다.

타입	해결하려는 문제	운영자가 바로 봐야 할 제한
`VECTOR(dim[, elementType])`	임베딩을 단순 `ARRAY<FLOAT>`가 아니라 차원과 타입이 고정된 컬럼으로 저장	top-level 필드만 가능, 차원/타입은 생성 후 변경 불가, Flink는 native decode 불가
`VARIANT`	스키마가 자주 흔들리는 JSON/이벤트 payload를 반정형 컬럼으로 보관	Spark 4.0+에서 native, Spark 3.x는 fallback DDL 필요, Lance-backed table에서는 지원 안 함
`BLOB`	이미지·PDF·오디오 같은 바이너리를 같은 테이블 행과 묶어 관리	`INLINE`/`OUT_OF_LINE` 두 모드가 있고, external reference 정리는 아직 cleaner가 자동 수행하지 않음

이 세 타입이 중요한 이유는 단순히 "새 데이터 타입이 생겼다"가 아니다. Hudi가 이제 분석용 테이블 포맷에서 AI/멀티모달 파이프라인의 스키마 저장소 쪽으로 한 걸음 옮겼다는 뜻이기 때문이다.

하지만 제약도 분명하다.

VECTOR는 top-level 필드만 허용된다.
VECTOR의 차원과 element type은 생성 후 schema evolution으로 바꿀 수 없다.
VARIANT는 Spark 4.0+에서만 native type으로 다뤄진다.
BLOB의 managed 플래그는 현재 cleaner가 실제로 소비하지 않는다.

즉, 저장 계층의 표현력은 늘었지만 수명주기 관리와 엔진 호환성은 여전히 운영 설계 과제로 남아 있다.

Lance 지원은 "파일 포맷 선택 기준" 자체를 바꾼다

공식 release note는 Lance file format 지원을 Hudi 1.2의 핵심 변화로 묶는다. 의미는 단순하다. 이제 운영자는 Parquet만 볼 것이 아니라, 질의 패턴에 따라 Parquet와 Lance를 나눠야 한다.

Parquet는 기존 분석 친화 경로에 익숙하고 VARIANT와도 맞는다.
Lance는 VECTOR를 native FixedSizeList로 다루며 AI/ML 접근 패턴에 최적화됐다.
대신 공식 문서상 VARIANT는 Lance-backed table에서 지원되지 않는다.

따라서 Hudi 1.2 도입은 단순 버전 업그레이드가 아니라 테이블별 file format policy를 새로 세우는 일에 가깝다.

2. Hudi 안에서 벡터 검색이 가능해졌지만, 아직 전용 벡터 DB를 대체하는 단계는 아니다

Hudi 1.2은 hudi_vector_search() TVF를 추가했다. SQL로 top-K 벡터 유사도 검색을 직접 호출할 수 있다는 뜻이다.

SELECT product_id, name, _hudi_distance
FROM hudi_vector_search(
  'products',
  'embedding',
  ARRAY(0.12, -0.03, 0.87),
  10,
  'cosine'
)
ORDER BY _hudi_distance;

여기서 중요한 것은 가능 여부보다 현재 알고리즘 경계다. 공식 sql_queries 문서는 algorithm 파라미터의 기본값이 brute_force이고, 현재 지원되는 것도 brute_force뿐이라고 적고 있다.

이 말은 곧 다음을 뜻한다.

장점: 이미 Hudi에 저장된 임베딩을 같은 거버넌스 경로 안에서 조회할 수 있다. 별도 벡터 저장소 복제 파이프라인을 만들지 않아도 된다.
한계: ANN 인덱스 기반의 저지연 온라인 서빙 경로와는 다르다. QPS가 높고 tail latency가 민감한 검색 서비스라면 전용 벡터 엔진이 여전히 더 적합하다.
현실적 용도: 오프라인/배치성 retrieval, 품질 검증용 샘플링, Spark 중심 RAG 전처리, 데이터 거버넌스가 중요한 내부 검색에는 잘 맞을 수 있다.

즉, Hudi 1.2의 벡터 검색은 "Lakehouse에서 벡터 데이터를 관리하면서 SQL로 가까운 이웃을 바로 확인하는 기능" 이지, 곧바로 "온라인 ANN serving layer"가 된 것은 아니다.

BLOB도 같은 함정을 가진다

BLOB도 비슷하다. 같은 row 안에서 바이너리 자산과 메타데이터를 묶을 수 있다는 점은 좋다. 하지만 OUT_OF_LINE 모드를 택하면 결국 외부 파일 참조와 lifecycle 관리가 남는다. managed=true를 써도 cleaner가 아직 그것을 자동 정리하지 않으므로, 파일 참조 garbage collection은 운영자가 따로 설계해야 한다.

3. 이번 릴리스에서 오히려 더 실전적인 변화는 Flink 쪽이다

Hudi 1.2을 멀티모달 스토리지 얘기만으로 이해하면 반쪽짜리다. 실제 운영자에게 더 큰 변화는 Flink 경로일 수 있다.

Record Level Index가 스트리밍 writer 쪽으로 깊게 들어왔다

release note는 Flink streaming writer에 대해 full Record Level Index 지원이 들어왔고, 고처리량 장기 실행 파이프라인을 위해 optional RocksDB-backed bootstrap을 언급한다.

이 변화가 중요한 이유는 Hudi 스트리밍 운영의 고질적인 비용이 보통 여기서 나오기 때문이다.

upsert/delete가 많을수록 기존 파일 그룹을 더 정확히 찾아야 한다.
장기 실행 job은 인덱스 bootstrap 비용과 상태 크기 때문에 재시작이 아프다.
CDC 파이프라인은 늦은 레코드와 out-of-order update 때문에 파일 탐색 비용이 곧 latency와 checkpoint 시간으로 이어진다.

RLI가 성숙해지면 "정확히 어느 file group에 가야 하는가"를 더 싸게 풀 수 있고, RocksDB bootstrap은 장시간 돌린 job의 상태 복원 비용을 낮추는 방향으로 작동한다.

FLIP-27 Source V2는 읽기 복구 경로를 더 운영 친화적으로 만든다

공식 release note가 강조하는 키워드는 세 개다.

resumable split assignment
checkpoint alignment
stronger predicate / partition / LIMIT push-down

이건 화려한 신기능처럼 보이지 않을 수 있지만, 실제로는 대규모 테이블에서 필요한 것만 읽고, 장애 후 다시 시작했을 때 얼마나 덜 고생하는가의 문제다.

특히 다음 같은 팀은 혜택을 볼 가능성이 크다.

Hudi를 Flink source로 읽어 downstream 스트림을 다시 만드는 팀
파티션 pruning과 LIMIT push-down이 실제 비용 차이로 이어지는 대용량 테이블 팀
split 재개와 checkpoint 정렬이 중요할 만큼 job runtime이 긴 팀

다만 release note가 분명히 말하듯 Source V2는 opt-in이다. 즉, 새 source가 존재한다는 사실과 운영 기본값이 바뀌었다는 말은 다르다. 이 경우 안전한 접근은 기존 source와 신규 source를 같은 테이블에서 병렬 canary 하는 것이다.

Flink 도입 체크포인트

checkpoint duration과 alignment time이 실제로 줄었는가
split backlog가 장기 실행 중 안정적으로 유지되는가
predicate/partition push-down으로 source read byte가 내려갔는가
RLI bootstrap 시간이 장애 복구 시간에 어떤 영향을 주는가
compaction/backfill이 source read 지연을 악화시키지 않는가

4. Azure 운영자에게는 storage-based lock provider가 더 직접적인 변화다

Hudi는 원래부터 OCC, NBCC 같은 동시성 모델을 강조해 왔다. 공식 concurrency 문서도 writer, table service, reader가 서로 다른 스냅샷과 락 규칙 아래 움직인다고 설명한다. 중요한 점은 락을 잡는 행위가 사라진 것이 아니라, 락을 위해 의존하던 외부 시스템이 줄어들었다는 것이다.

Hudi 1.2 release note가 강조하는 Azure Storage-Based Lock Provider는 ADLS Gen2/Azure Blob Storage에서 storage-based lock provider를 직접 쓰게 해 준다. 공식 docs 기준으로 이 방식은 .hoodie/ 경로와 스토리지 계층의 conditional write/lease 같은 기능을 활용해 분산 락을 구현한다.

운영 관점에서 이건 꽤 큰 차이다.

ZooKeeper나 Hive Metastore를 락 목적으로만 유지할 필요가 줄어든다.
Azure shop에서는 Managed Identity까지 포함한 인증 경로를 더 자연스럽게 쓸 수 있다.
lock validity timeout, renew interval 같은 파라미터는 여전히 팀이 소유한다.

문서가 제시하는 Azure 인증 precedence도 실무적이다.

connection string
SAS token
user-assigned managed identity client id
service principal
DefaultAzureCredential

즉, 기능이 생겼다고 해서 멀티라이터가 저절로 안전해지는 것은 아니다. 락 인프라 의존성은 줄었지만, 락 운영 책임은 그대로 남는다.

hoodie.write.lock.provider=org.apache.hudi.client.transaction.lock.StorageBasedLockProvider
hoodie.write.lock.storage.validity.timeout.secs=300
hoodie.write.lock.storage.renew.interval.secs=30

이 설정을 넣었다면 다음을 반드시 같이 봐야 한다.

renew 실패 시 어떤 알림을 받을 것인가
failover 중 lock lease가 얼마나 오래 남는가
table service와 writer가 같은 경로를 공유할 때 live-lock 없이 끝나는가

5. 마이그레이션은 가볍지만, 기능 활성화는 단계적으로 가야 한다

release note 기준으로 Hudi 1.2.0은 1.1.1에서 table version이 그대로 9다. 따라서 1.1.1에서 올라오는 팀은 table version upgrade 자체는 필요 없다. 이 점은 생각보다 중요하다. 파일 형식이나 timeline 자체를 뒤흔드는 릴리스가 아니라는 뜻이기 때문이다.

하지만 그걸 "리스크가 낮다"와 같은 뜻으로 읽으면 곤란하다. feature surface는 오히려 넓어졌다.

항목	1.2에서 쉬워진 점	운영자가 따로 검증해야 하는 점
코어 업그레이드	1.1.1 → 1.2.0은 table version bump 없음	pre-1.1.1이면 중간 업그레이드 가이드를 순차 확인해야 함
엔진 번들	Spark 4.1 / Flink 2.1 bundle 추가	실제 배포 런타임과 connector 조합이 맞는지 확인 필요
`VECTOR`	schema-level type 도입	차원 고정, top-level only, Flink decode 불가
`VARIANT`	Spark 4 native type 사용 가능	Spark 3.x 소비자는 fallback DDL 준비 필요
`BLOB`	row와 asset reference를 함께 관리 가능	out-of-line external file 정리는 별도 프로세스 필요
Lance	AI/ML 친화 저장 경로 확보	`VARIANT`와 함께 못 쓰므로 테이블 정책 분리 필요

실전에서는 보통 아래 순서가 안전하다.

런타임만 먼저 올린다. 테이블 버전이 그대로이므로 먼저 1.2 bundle 호환성만 본다.
신규 타입은 신규/샌드박스 테이블에서 켠다. 기존 핵심 fact table에 바로 VECTOR나 VARIANT를 넣지 않는다.
엔진별 소비 경로를 분리한다. Spark 4 write + Spark 3 read fallback + Flink read 제한을 모두 적어둔다.
feature별 rollback line을 정한다. Lance, FLIP-27 source, Azure lock provider를 각각 독립 토글처럼 다룬다.

운영자 채택 체크리스트

이런 팀이라면 Hudi 1.2가 설득력 있다

이미 Hudi를 표준 테이블 포맷으로 쓰고 있고, 임베딩/JSON/BLOB를 별도 시스템으로 복제하는 비용이 커진 팀
Spark 중심 데이터 플랫폼이라 Spark 4.x adoption이 가능한 팀
Flink 기반 ingestion/replay 파이프라인이 길고, source recovery와 selective read가 실제 비용 문제인 팀
Azure에서 멀티라이터 락을 위해 별도 조정 시스템을 유지하는 것이 번거로운 팀

이런 팀이라면 아직 기다리는 편이 낫다

저지연 ANN 검색을 독립 서비스로 서빙해야 하는 팀
Flink가 벡터 컬럼을 완전히 이해해 주길 기대하는 팀
VARIANT 내부 필드 push-down이나 shredding을 당장 기대하는 팀
external BLOB lifecycle을 자동으로 치워 주는 cleaner를 기대하는 팀

도입 전 검증 항목

검증 항목	왜 필요한가
`hudi_vector_search` 샘플 쿼리 latency 측정	현재는 brute-force이므로 데이터 크기에 따라 한계가 빨리 온다
Spark 4 write / Spark 3 read fallback 테스트	`VARIANT` 소비자가 섞여 있으면 장애 지점이 된다
Flink Source V2 canary	push-down과 split 재개 효과가 실제 workload에서 나오는지 확인해야 한다
Azure lock renew failure drill	락 provider 자체보다 renewal 실패 시나리오가 더 위험하다
BLOB orphan 파일 점검 절차	cleaner가 아직 external reference lifecycle을 자동화하지 않는다
Lance/Parquet 테이블 분리 기준 문서화	`VARIANT`와 `VECTOR`의 지원 비대칭을 숨기면 운영 혼선이 생긴다

결론

Apache Hudi 1.2는 "Lakehouse가 AI 데이터를 다룰 준비가 됐다"는 선언에 가까운 릴리스다. 그 선언을 가능하게 만든 실체는 VECTOR·VARIANT·BLOB, Lance 지원, Flink Source V2, Azure lock provider다.

하지만 운영자의 눈으로 보면 더 중요한 문장은 따로 있다.

벡터 검색은 가능하지만 아직 brute-force다.
VARIANT는 Spark 4에서 가장 자연스럽고, 다른 엔진은 fallback이 필요하다.
BLOB는 참조를 저장해 주지만 external file lifecycle까지 책임지진 않는다.
Azure lock provider는 의존성을 줄여 주지만 멀티라이터 검증을 대신해 주진 않는다.

그래서 Hudi 1.2는 만능 대체재라기보다, 기존 Hudi 플랫폼 위에 AI/멀티모달 데이터를 편입하려는 팀이 더 적은 복제와 더 많은 명시적 운영 정책으로 앞으로 나아갈 수 있게 한 릴리스라고 보는 편이 정확하다.

Open question

공식 문서 기준 hudi_vector_search는 현재 brute_force만 지원한다. ANN 인덱스 기반 검색이 언제 어떤 형태로 들어올지는 추가 추적이 필요하다.
release note는 FLIP-27 Source V2를 opt-in으로 소개하지만, 장기적으로 기본 source가 언제 전환될지는 확인되지 않았다.
BLOB의 managed 플래그를 cleaner가 실제 lifecycle 정리에 사용하는 시점은 향후 릴리스 노트 확인이 필요하다.

References

https://github.com/apache/hudi/releases/tag/release-1.2.0
https://hudi.apache.org/releases/release-1.2
https://hudi.apache.org/blog/2026/06/07/apache-hudi-release-1-2-announcement/
https://hudi.apache.org/docs/next/sql_ddl
https://hudi.apache.org/docs/next/sql_queries/
https://hudi.apache.org/docs/next/concurrency_control