운영 담당자로부터 "Iceberg 전체 기능을 쓰려면 7.3.1 을 7.3.2 로 올려야 하고 4시간쯤 걸린다" 는 안내를 받고 검토한 내용과, 2026년 8월 기준 Cloudera Manager / Runtime 의 안정 버전과 지원 정책을 정리한 것이다. 사실관계는 Cloudera 릴리스 노트와 지원 수명 정책에 따른다.
| 구분 | 버전 | GA | 지원 |
|---|---|---|---|
| Cloudera Manager | 7.13.2 | 2026-03-31 | 7.3.2 / 7.3.1(SP 포함) / 7.1.9 SP1 관리 |
| Cloudera Runtime (구 CDH) | 7.3.2.0 | 2026-03-31 | LTS, 2032년까지 |
| Runtime 7.1.9 | SP2 (2026-06-01) + CM 7.13.1 CHF8 | — | LTS, 2028년까지 |
| Runtime 7.3.1 | SP3 CHF4 (7.3.1.900) + CM 7.13.1 CHF9 | 2024-12 | STS, 2026년 내 EOS |
Cloudera 는 LTS/STS 이원 체계다. EOS 는 통상 GA 후 3년, LTS 는 최대 4년이며 서비스팩이 약 6개월 주기로 나오고, 최신 SP 를 적용한 상태에서만 완전한 지원을 받는다. 7.3.1 은 온클라우드/온프렘 통합 코드베이스의 첫 릴리즈이자 STS 라 프로덕션 신규 도입 대상이 아니다. 7.1.7 SP3, 7.1.9 SP1, 7.3.1, 7.2.18 에서 7.3.2 로 단일 단계 in-place 업그레이드가 가능하다.
| 현재 상태 | 권장 |
|---|---|
| 7.1.7 (EOS) | 7.3.2 로 직행 |
| 7.1.9 SP1/SP2 | 2028년까지 LTS 이므로 7.3.2 CHF 가 한두 번 나온 뒤 전환 |
| 7.3.1 | 올해 EOS 이므로 7.3.2 계획 필요 |
| 신규 구축 | 7.3.2 + CM 7.13.2 |
Iceberg 는 7.1.9 부터 V2 가 GA 이므로 7.3.1 에서도 이미 쓸 수 있다. "업그레이드해야 Iceberg 를 쓸 수 있다" 가 아니라 "7.3.2 에서 운영·유지관리 기능이 완성된다" 가 정확하다.
| 구분 | 7.3.1 | 7.3.2 |
|---|---|---|
| Iceberg V2 기본 기능 (Time Travel, 파티션 진화, ACID) | 지원 | 지원 |
| 스냅샷 만료, Branching/Tagging, Copy-on-Write, 파티션 단위 DML | 7.3.1.500 CHF 이상에서 지원 | 지원 |
| Lakehouse Optimizer (Compaction·정리 자동화, Ranger 연동) | 미지원 | 지원 |
| Iceberg REST Catalog + HMS 연동 (외부 플랫폼 공유) | 미지원 | 지원 |
| Orphan file 제거, Impala 스캔 메트릭, Replication Manager Iceberg 복제 | 미지원 | 지원 |
"7.3.1 은 ACID 가 불완전하다" 는 인식은 7.3.1 GA(7.3.1.0) 에서 Impala UPDATE / MERGE / DROP PARTITION 이 없었던 데서 나온 것이다. Hive UPDATE/DELETE/MERGE 와 Impala DELETE 는 7.3.1 부터, Impala UPDATE/MERGE, Hive Copy-on-Write, Compaction/Branching/Tagging 은 7.3.1.500 부터 지원된다. 따라서 현재 빌드가 7.3.1.0 인지 7.3.1.500 이상인지가 최우선 확인 사항이다 — 7.3.1.500 미만이면 CHF 적용만으로 ACID 기능을 확보할 수 있고, 이상이면 7.3.2 의 목적은 Lakehouse Optimizer·REST Catalog·성능 개선과 LTS 지원 수명이 된다.
7.3.2 에서도 남는 제약 — Serializable isolation 은 Spark 만 지원(Hive·Impala 는 Snapshot isolation), Impala 는 Copy-on-Write·Branching/Tagging 미지원, Spark 는 Ranger 세분화 권한 제어·DROP PARTITION 미지원, Equality deletes 는 전 엔진 읽기 전용이다. 사용할 엔진 기준으로 기능 매트릭스를 확인하고 설계한다.
7.3.1 → 7.3.2 는 컴포넌트 선택 업그레이드가 아니라 Runtime Parcel 전체 업그레이드다. Cloudera Manager 7.13.2 가 선행되고 Hadoop 3.4, Spark 3.5, Ranger 2.6, Atlas 2.4, Knox 2.1, Kafka 3.9, HBase 2.6.3, ZooKeeper 3.8 로 일괄 리베이스된다. Data Services 를 쓰면 1.5.5 SP1/SP2 만 지원되며 Cloudera AI 사용 시 1.5.5 SP2 CHF1 이상이 필요하다. 7.3.1 이하에서 KRaft(테크 프리뷰) 로 돌던 Streams Messaging 클러스터는 업그레이드 자체가 지원되지 않는다.
가장 큰 위험은 호환성보다 선행 인프라 교체다. CM 7.13.2 / Runtime 7.3.2 는 JDK 17 만 지원(8·11 제거, 업그레이드 후 이전 Java 로 롤백 불가), Python 3.11 만 지원(3.8~3.10 제거), PostgreSQL 13·Oracle 19c·SLES 15 SP4·Ubuntu 20.04 지원 중단이다. 신규 인증 OS 는 RHEL 9.6, Rocky Linux 9.6, Ubuntu 24.04, SLES 15 SP6 이며 MariaDB 11.4 가 추가됐다.
| 위험 | 대응 |
|---|---|
| JDK 17 전환 | UDF·Spark·Oozie 잡의 JDK 17 호환성 사전 검증. 리플렉션 기반 라이브러리 실패 사례가 많아 가장 큰 공수. 7.3.1 단계에서 JDK 를 먼저 올려 검증(phased JDK upgrade) |
| Python 3.11 / OS / DB | 현행 OS·메타 DB 조사 후 선행 교체 계획. Oracle 19c·PG 13 이면 DB 마이그레이션이 별도 프로젝트 |
| 서비스 중단 | Runtime 업그레이드 창구 자체는 4~8시간이나 선행 작업 포함 시 수 주 단위 준비 |
| 롤백 | CM DB, HMS, Ranger Admin/KMS, Schema Registry 메타 DB 전량 백업 |
| 워크로드 영향 | DEV → STG → PROD 순 동일 버전 선검증과 배치 회귀 테스트 |
"4시간" 은 Runtime 업그레이드 실행 창구 기준이므로 전제조건 충족 여부를 먼저 확인한 뒤 전체 일정을 재산정한다.
metadata/, data/ 경로의 HDFS 정책 정합성을 재점검한다.STS 는 채택하지 않고 LTS 만 적용하며, 반기 1회 정기 점검으로 SP/CHF 를 적용하고, 메이저 업그레이드는 EOS 12개월 전에 착수한다. 버전별 EOS 관리대장을 운영하고 OS/JDK/Python/DB 요건 변경을 업그레이드 체크리스트에 상시 반영한다. Data Services 는 에어갭 배포물이 약 500GB 이고 1.5.4 SP2·1.5.5 에서 1.5.5 SP2 로 직행할 수 없어 1.5.5 SP1 을 경유해야 하므로 업그레이드 경로를 미리 확인한다.