칼의 치치

Trino 쿼리를 통한 Iceberg 내부 살펴보기

칼쵸쵸 — Thu, 31 Jul 2025 22:43:20 +0900

1. Iceberg 파일 구조 개요

Iceberg 테이블은 HDFS, S3, HDFS-compatible storage 등에 저장되며 크게 두 가지 계층으로 나뉩니다:

table_name/
 ├── data/                  # 실제 데이터 파일 (Parquet/ORC/Avro)
 │    ├── ...partition.../
 │    │    └── 00000-aaaa.parquet
 │    └── ...
 └── metadata/              # 테이블 스냅샷과 스키마/파티션 정의
      ├── version-hash.json
      ├── v0001.metadata.json
      ├── v0002.metadata.json
      └── snapshots/

구성 요소

데이터 파일 (data/)
- 실질적인 레코드가 저장되는 Parquet/ORC 파일
- 파티션 규칙에 따라 디렉터리 구조로 나뉨
매니페스트 파일 (manifest)
- 데이터 파일 리스트 + min/max statistics 보관
- 파일 단위 pruning에 활용
매니페스트 리스트 (manifest list)
- 하나의 스냅샷을 구성하는 매니페스트들의 목록
스냅샷 (snapshot)
- 테이블의 특정 시점 상태 (매니페스트 리스트를 가리킴)
메타데이터 JSON (v000N.metadata.json)
- 테이블 전체 이력과 모든 스냅샷/스키마 정의를 관리

2. Iceberg 스냅샷의 연결 관계

아키텍처 플로우 (간단 버전):

metadata.json
   │
   └─ snapshot → manifest list → manifest → data files

metadata.json: 스냅샷 목록 + 현재 활성 snapshot ID
snapshot: manifest list 파일 경로 + 요약 정보
manifest list: 여러 manifest 파일 경로 모음
manifest: 개별 데이터 파일 경로와 통계
data file: 실제 row 데이터 저장

3. $snapshots에서 Manifest List 확인하기

Trino에서 $snapshots를 조회하면 manifest list 경로를 볼 수 있습니다.

SELECT snapshot_id,
       committed_at,
       manifest_list
FROM table_name$snapshots
ORDER BY committed_at DESC
LIMIT 3;

예시 결과

snapshot_id	committed_at	manifest_list
4151342690114749344	2025-07-27 00:00	hdfs://warehouse/table_name/metadata/snap-4151342690114749344-1-ml.avro
4151342690114749221	2025-07-26 00:00	hdfs://warehouse/table_name/metadata/snap-4151342690114749221-1-ml.avro

manifest_list: manifest list 파일 경로
Iceberg는 이 파일을 통해 어떤 manifest들이 이 스냅샷에 속하는지 알 수 있음

4. Manifest List 내부 구조

manifest list 파일 자체는 Avro 포맷으로 저장되어 있으며, 각 행은 하나의 manifest 파일을 나타냅니다.

manifest_path	manifest 파일 경로
manifest_length	manifest 파일 크기
partition_spec_id	어떤 partition spec에 해당하는지
added_snapshot_id	어떤 스냅샷에서 추가됐는지
existing	기존 데이터 파일 개수
added_files_count	새로 추가된 데이터 파일 개수
deleted_files_count	삭제된 데이터 파일 개수

5. Manifest 파일 구조 (참고)

각 manifest 파일에는 실제 데이터 파일 정보가 들어 있습니다:

data_file_path: parquet/orc 파일 경로
partition_data: 파티션 값
record_count: 파일의 레코드 수
lower_bounds / upper_bounds: 각 컬럼의 최소/최대 값 (→ pruning 가능)
file_size_in_bytes

이 덕분에 Iceberg는 **파일 단위 프루닝(file pruning)**을 할 수 있음.

6. Trino에서 $snapshots 메타테이블

Trino는 Iceberg 테이블 메타데이터를 SQL로 조회할 수 있게 $snapshots를 제공합니다.

SELECT snapshot_id,
       committed_at,
       parent_id,
       operation,
       summary
FROM table_name$snapshots
ORDER BY committed_at DESC;

출력 예시

snapshot_id	committed_at	parent_id	operation	summary
4151342690114749344	2025-07-27 00:00	4151342690114749221	append	{"added-records":"12000"}
4151342690114749221	2025-07-26 00:00	NULL	overwrite	{"deleted-records":"500"}

snapshot_id: 스냅샷 고유 ID
parent_id: 이전 스냅샷 (branch 구조 추적)
operation: append / overwrite / delete 등
summary: record count, 파일 수, 파티션 통계 등

$snapshots는 Iceberg 테이블의 전체 히스토리와 파일 구조 추적의 시작점

7. Trino에서 $refs (Branch / Tag)

$refs는 현재 살아있는 참조 (branch, tag) 목록을 보여줍니다.
즉, 어떤 snapshot_id를 보호하고 있는지 확인 가능.

SELECT name,
       type,
       snapshot_id,
       min_snapshots_to_keep,
       max_snapshot_age_ms,
       max_ref_age_ms
FROM table_name$refs;

name	type	snapshot_id	min_snapshots_to_keep	max_snapshot_age_ms	max_ref_age_ms
main	BRANCH	4151342690114749344	1	NULL	NULL
month_end_202507	TAG	4151342690114749221	NULL	NULL	31536000000

name: 참조 이름 (main, branch명, tag명)
type: BRANCH / TAG
snapshot_id: 해당 참조가 가리키는 snapshot
보존 정책 필드: 만료 정책 (ms 단위)

$refs를 보면 어떤 snapshot이 expire 대상에서 제외되는지 한눈에 알 수 있음

8. $snapshots + $refs로 Iceberg 구조 이해하기

예시:

SELECT r.name, r.type, r.snapshot_id, s.committed_at, s.operation
FROM table_name$refs r
JOIN table_name$snapshots s
  ON r.snapshot_id = s.snapshot_id
ORDER BY s.committed_at DESC;

결과:

name	type	snapshot_id	committed_at	operation
main	BRANCH	4151342690114749344	2025-07-27 00:00	append
month_end_202507	TAG	4151342690114749221	2025-07-26 00:00	overwrite

main branch → 최신 snapshot
month_end_202507 tag → 이전 snapshot 고정 보존

이 구조를 통해:

데이터 파일 계층이 어떻게 스냅샷으로 묶여있는지 확인 가능
어떤 snapshot이 보존되고 어떤 건 expire 대상인지 식별 가능

✅ 정리

data/ → 실제 파티션별 데이터 파일
metadata/ → snapshot/manifest 정의
$snapshots → 모든 snapshot 이력 (commit, operation, parent 관계)
$refs → branch/tag → snapshot 매핑, 보존 정책 확인
Trino에서는 FOR VERSION AS OF 'tag_name' 문법으로 태그 기반 조회 가능

9. Manifest List ↔ Snapshot ↔ Ref 관계 쿼리 예시

Trino에서 manifest list를 확인하고 어떤 태그/브랜치가 참조 중인지 조회:

SELECT r.name AS ref_name,
       r.type,
       s.snapshot_id,
       s.committed_at,
       s.manifest_list
FROM table_name$refs r
JOIN table_name$snapshots s
  ON r.snapshot_id = s.snapshot_id
ORDER BY s.committed_at DESC;

그림으로 요약 (텍스트 다이어그램)

[table_name$refs]
   │   (태그: month_end_202507 → snapshot_id=4151342690114749344)
   │
   ▼
[table_name$snapshots]
   snapshot_id=4151342690114749344
   manifest_list = snap-4151342690114749344-1-ml.avro
   │
   ▼
[manifest list]
   ├─ manifest-001.avro
   └─ manifest-002.avro
       │
       ├─ data-0001.parquet
       ├─ data-0002.parquet
       └─ ...

✅ 정리

$snapshots.manifest_list → 특정 snapshot이 참조하는 manifest list 파일 경로
manifest list 파일 → 여러 manifest 파일을 가리키는 Avro
manifest 파일 → 실제 데이터 파일(Parquet 등) + 통계 정보
$refs와 조합해 "어떤 태그/브랜치가 어떤 manifest list를 보호 중인지" 파악 가능

Iceberg에서 Tagging을 활용한 데이터 Snapshot 관리

칼쵸쵸 — Thu, 31 Jul 2025 22:28:57 +0900

1. Iceberg에서 Tagging의 개념

Iceberg의 Tag는 특정 시점의 스냅샷을 이름 기반으로 고정 보존할 수 있는 기능입니다.

스냅샷: 테이블의 특정 시점 상태 (데이터 파일 목록 + 메타데이터)
태그(Tag): 스냅샷에 붙이는 사용자 정의 라벨
목적: 보존(retention) 정책에서 제외하거나, 특정 분석/재처리를 위해 고정 시점 참조

ALTER TABLE db.table 
CREATE TAG `month_end_202507` 
AS OF VERSION 4151342690114749344 
RETAIN 365 DAYS;

AS OF VERSION : 특정 스냅샷 버전 지정
RETAIN : 이 태그를 최소 며칠 동안 보존할지 설정 (만료 보호 기간)

2. Expire Snapshots와 Tagging의 상호작용

보통 Iceberg 테이블은 expire_snapshots 명령어를 주기적으로 실행하여
오래된 스냅샷과 관련 파일(데이터, 매니페스트)을 정리합니다.

ALTER TABLE db.table 
EXECUTE expire_snapshots(retention_threshold => '7d');

동작 원리

retention_threshold보다 오래된 스냅샷을 삭제
단, Tag나 Branch가 참조 중인 스냅샷은 삭제 제외

즉, 태그가 달린 스냅샷은 expire 대상에서 제외됩니다.

3. 태그 기반 Expire 제외 전략

대표 시점 보존

월말/분기말/연말 등 대표 시점 스냅샷에 태그를 걸어 보존
일반 스냅샷은 7일~30일 단위로 expire
태그가 붙은 스냅샷만 장기 보존 (예: 1년)

-- 매일 만료 실행 (최근 7일 유지)
ALTER TABLE db.table EXECUTE expire_snapshots(retention_threshold => '7d');

-- 월말 스냅샷 보존
ALTER TABLE db.table 
CREATE TAG `month_end_202507` 
AS OF VERSION <snapshot_id> 
RETAIN 365 DAYS;

4. Trino에서 태그 기반 조회

Trino는 Iceberg tag name을 직접 지정할 수 있습니다.

SELECT *
FROM table_name
FOR VERSION AS OF 'month_end_202507';

'month_end_202507' → snapshot_id가 아니라 태그명 (문자열 일시)
Trino 엔진이 Iceberg 메타스토어에서 해당 태그가 가리키는 snapshot_id를 찾아서 실행

JVM (Java Virtual Machine) 구조 상세 설명

칼쵸쵸 — Thu, 31 Jul 2025 22:12:45 +0900

JVM은 **자바 바이트코드(.class 파일)**를 실행하기 위한 가상 머신이에요.
구조적으로는 크게 클래스 로더, 런타임 데이터 영역, 실행 엔진, 네이티브 인터페이스로 나뉘어요.

1️⃣ 클래스 로더 (Class Loader Subsystem)

역할: .class 파일(바이트코드)을 메모리로 적재해서 런타임 영역에 올림
동적 로딩(Dynamic Loading): 실행 중 필요한 클래스만 메모리에 로드
주요 단계
1. Loading
  - 클래스 파일을 읽어 Method Area에 로드
2. Linking
  - Verification: 바이트코드가 JVM 규격에 맞는지 검사
  - Preparation: static 변수에 메모리 할당 & 기본값 초기화
  - Resolution: 심볼릭 참조(클래스명, 메소드명 등)를 실제 메모리 주소로 변경
3. Initialization
  - static 변수와 static 블록 실행

2️⃣ 런타임 데이터 영역 (Runtime Data Area)

JVM 프로세스 안에서 데이터를 저장하고 관리하는 메모리 영역이에요.

[공유 영역 - 모든 스레드가 공유]

Method Area (또는 MetaSpace, JDK 8 이후)
- 클래스 구조, 메소드, 상수 풀, static 변수 저장
- JDK 8 이전에는 PermGen 영역이었으나, 이후 MetaSpace로 교체 (네이티브 메모리 사용)
Heap Area
- 모든 객체 인스턴스와 배열이 저장되는 영역
- GC의 주요 대상
- 세분화 구조
  - Young Generation
    - Eden Space: 새로 생성된 객체
    - Survivor Space (S0/S1): GC에서 살아남은 객체 이동
  - Old Generation (Tenured): 여러 번 GC를 거쳐 살아남은 장수 객체
- Heap은 JVM 성능 튜닝의 핵심 (-Xmx, -Xms)

[스레드별 영역 - 각 스레드마다 생성]

PC Register (Program Counter Register)
- 현재 실행 중인 JVM 명령어의 주소 보관
JVM Stack
- 메서드 호출 시 생성되는 Frame 저장
- Frame 구조
  - Local Variables Array: 매개변수 & 지역변수
  - Operand Stack: 연산 중간 결과
  - Frame Data: 메서드/클래스 정보, Exception 처리기 등
- 스레드 종료 시 스택도 함께 제거
Native Method Stack
- JNI (Java Native Interface)로 호출되는 C/C++ 같은 네이티브 코드용 스택

3️⃣ 실행 엔진 (Execution Engine)

클래스 로더가 적재한 바이트코드를 실제로 실행하는 부분

인터프리터
- 바이트코드를 한 줄씩 해석 후 실행
- 빠른 시작 가능하지만 실행 속도는 느림
JIT 컴파일러 (Just-In-Time Compiler)
- 자주 실행되는 바이트코드를 기계어로 변환 후 캐시
- 이후에는 인터프리팅 없이 네이티브 코드 실행
- HotSpot JVM의 핵심 성능 최적화
Garbage Collector (GC)
- Heap 영역의 불필요한 객체 자동 해제
- 대표 알고리즘
  - Serial GC (단일 스레드)
  - Parallel GC (여러 스레드 병렬 수집)
  - CMS (Concurrent Mark-Sweep) → JDK 9부터 deprecated
  - G1 GC (Garbage-First) → 대용량 Heap에 유리
  - ZGC, Shenandoah → 초저지연 목적

4️⃣ 네이티브 인터페이스 (JNI)

Java에서 네이티브 라이브러리(C/C++)를 호출할 수 있게 하는 인터페이스
OS API나 고성능 라이브러리 호출 시 사용
Native Method Libraries와 연동

⚙️ 실행 흐름 예시

[.java 파일] → javac → [.class 파일]
         ↓
    Class Loader
         ↓
   Runtime Data Area
         ↓
   Execution Engine
     ↳ Interpreter & JIT
     ↳ GC 관리
         ↓
   Native Interface
         ↓
       OS / 하드웨어

성능/튜닝 포인트

Heap 크기 조정
- -Xmx / -Xms
GC 알고리즘 선택
- 대규모 데이터 처리 시 G1GC, 저지연 필요 시 ZGC
Thread Stack 크기
- -Xss 옵션
Metaspace 크기
- -XX:MaxMetaspaceSize
JIT Warm-up 시간 고려
- 서버 앱은 장시간 실행 시 JIT 최적화 효과 큼

✅ 요약
JVM은

클래스 로더로 바이트코드를 메모리에 올리고
런타임 데이터 영역에서 객체와 스레드별 메모리를 관리하며
실행 엔진이 인터프리터 & JIT & GC를 통해 코드를 실행하고
필요 시 JNI로 네이티브 코드와 통신

파이썬의 동작 과정

칼쵸쵸 — Tue, 29 Jul 2025 22:56:37 +0900

파이썬 ↔ C 관계 & 가상환경

1. 파이썬과 C의 관계

파이썬(특히 CPython)은 사실상 C로 구현된 인터프리터예요.

CPython: 가장 널리 쓰이는 파이썬 구현체 (Python 공식 배포판)
핵심 원리:
- 파이썬 소스 코드 → **바이트코드(.pyc)**로 컴파일
- 이 바이트코드를 **C로 작성된 인터프리터(CPython VM)**가 실행
파이썬 객체(PyObject)는 C 구조체로 관리됨

즉:

파이썬은 "문법과 문화를 가진 언어"
CPython은 "C로 만들어진 실행기"

a = 10

a는 스택에 참조 저장
10은 힙에 PyLongObject라는 C 구조체로 생성

파이썬에서 int, list 같은 객체들은 실제로 C 언어 구조체에 불과함.

2. 왜 C 기반으로 동작할까?

성능: C는 저수준 언어라서 메모리와 CPU 제어에 강함
확장성: 파이썬 라이브러리 중 NumPy, Pandas, TensorFlow 등이 내부적으로 C/C++로 구현됨
호환성: 운영체제 API와 쉽게 연동 가능

따라서, 파이썬은 편리한 문법 + C의 성능을 동시에 가져가는 구조임.

3. 가상환경(virtual environment)의 개념

가상환경은 파이썬 프로젝트별 독립적인 실행 환경이에요.

일반적으로 파이썬은 전역(Global) 환경에 설치되는데,
프로젝트마다 필요한 패키지 버전이 다르기 때문에 충돌 문제 발생
이를 해결하기 위해 가상환경을 사용

장점:

프로젝트별 패키지/라이브러리 버전 격리
시스템 파이썬에 영향 주지 않음
배포 시 환경 복제 용이

4. 가상환경 동작 원리

가상환경을 만들면 특정 디렉토리에
- bin (또는 Scripts): 파이썬 실행 파일
- lib: 설치된 패키지 저장
- pyvenv.cfg: 가상환경 설정
  이 생성됨
활성화 시, PATH 환경변수가 바뀌어 해당 디렉토리 안의 파이썬을 사용하게 됨.

# 가상환경 생성
python -m venv myenv

# 활성화
source myenv/bin/activate   # macOS/Linux
myenv\Scripts\activate      # Windows

3. 종료 시에는 PATH가 원래대로 돌아옴.

deactivate

5. 가상환경과 C의 관계

가상환경은 파이썬 실행 파일과 **해당 실행기에 필요한 라이브러리(C 기반 모듈 포함)**를 격리된 디렉토리에 모아둔 것.
예를 들어, NumPy 같은 패키지는 내부적으로 C 코드로 되어 있는데, 가상환경 안에 설치되면 그 환경 안에서만 접근 가능.

[시스템 파이썬] ----+
                   |
                   +--> [가상환경 myenv]
                   |        ├─ bin/python (별도 실행기)
                   |        ├─ lib/site-packages (패키지들)
                   |        └─ C 기반 모듈 (numpy, pandas 등)
                   |
                   +--> [가상환경 projectX]
                            ├─ bin/python
                            ├─ lib/site-packages
                            └─ 다른 버전의 패키지들

✅ 정리

파이썬은 C로 만들어진 CPython 위에서 동작하며, 실제 객체는 C 구조체임
가상환경은 프로젝트별로 파이썬 인터프리터와 라이브러리를 격리시켜주는 시스템임

파이썬 실행 과정 (C, 인터프리터, 컴파일러, 메모리 관점)

1. 파이썬 코드 → 실행까지 흐름

.py 파일 작성
   ↓
[컴파일러] Python Compiler
   ↓ 바이트코드(.pyc) 생성
[인터프리터] CPython Virtual Machine
   ↓ 바이트코드 해석
[메모리] 스택/힙에 객체 배치
   ↓
CPU에서 실행

2. 단계별 설명

(1) 소스코드 작성

우리가 작성한 .py 파일은 순수 텍스트

x = 10
y = 20
print(x + y)

(2) 파이썬 컴파일러

파이썬도 컴파일러를 갖고 있음 (단, 기계어가 아니라 바이트코드로 변환)
결과물: 바이트코드(.pyc)
보통 __pycache__ 폴더에 저장됨

python -m py_compile script.py

바이트코드 예시 (추상화):

LOAD_CONST 10
STORE_NAME x
LOAD_CONST 20
STORE_NAME y
LOAD_NAME print
CALL_FUNCTION 1

(3) CPython 인터프리터

바이트코드를 한 줄씩 읽어 실행
이때 내부적으로는 **C로 구현된 가상머신 (CPython VM)**이 동작
eval_frame 같은 C 함수가 바이트코드를 처리

즉:

컴파일러: .py → .pyc
인터프리터: .pyc → 실제 실행

(4) 메모리 구조 활용

실행 시 메모리 구성:

스택 (Stack)
- 함수 호출 시 로컬 변수 이름과 객체 참조(포인터) 저장
- x, y 같은 변수명 존재
힙 (Heap)
- 실제 객체 데이터 저장 (10, 20, 리스트 등)
- 모든 파이썬 객체는 힙에 있음
- 객체는 C 구조체(PyObject) 형태
GC (Garbage Collector)
- 참조 카운트 + 세대별 수집으로 메모리 해제 관리

3. C와의 관계

CPython은 C로 작성됨 → 바이트코드를 C 함수들이 해석
파이썬 객체는 모두 C 구조체
수학 연산이나 리스트 조작 등은 결국 C 코드 함수 호출

a = [1,2,3]

a (스택에 저장된 이름)
[1,2,3] (힙에 저장된 PyListObject → 내부적으로 C 배열)

4. 그림으로 이해하기

[파이썬 코드] .py
   ↓ 컴파일러
[바이트코드] .pyc
   ↓ 인터프리터(CPython VM)
 ┌─────────────────────┐
 │   C로 구현된 가상머신 │
 │   (eval_frame 등)   │
 └─────────┬───────────┘
           │
      ┌────┴─────┐
      │ 메모리 구조│
      │           │
      │ [스택]    │ → 변수 참조 저장
      │ [힙]      │ → 객체(PyObject) 저장
      │ [GC]      │ → 참조 카운트 & 순환 수집
      └───────────┘

5. 정리

컴파일러: .py를 **바이트코드(.pyc)**로 변환
인터프리터: 바이트코드를 C로 작성된 가상머신에서 실행
메모리 구조:
- 스택 → 변수 참조 저장
- 힙 → 실제 객체 저장
- GC → 메모리 자동 해제
C의 역할: CPython 구현, 객체 구조 정의, 핵심 함수 실행

파이썬 메모리 구조 개요

칼쵸쵸 — Tue, 29 Jul 2025 22:48:53 +0900

파이썬 메모리 구조 & GC 정리

1. 메모리 구조 개요

파이썬 인터프리터(CPython 기준) 메모리 구성:

스택(Stack)
- 함수 호출 시 로컬 변수, 참조 저장
- 함수 종료 시 자동 해제
- 실제 데이터가 아닌 객체 참조(포인터) 저장
힙(Heap)
- 모든 파이썬 객체(list, dict, 사용자 정의 객체 등) 저장
- GC와 메모리 풀(Pymalloc) 관리
- 크기 동적 할당
코드/전역 영역
- 전역 변수, 상수, 함수 정의 저장
- 프로그램 종료 전까지 유지

2. 힙 메모리와 객체 구조

모든 객체는 PyObject 구조체로 관리됨.

typedef struct {
    Py_ssize_t ob_refcnt;        // 참조 카운트
    struct _typeobject *ob_type; // 객체 타입
} PyObject;

ob_refcnt: 참조 횟수 (GC 관리 기준)
ob_type: 객체 타입 정보

변수는 객체를 직접 담는 게 아니라 힙에 있는 객체 주소를 참조.

3. 메모리 관리 전략

① 참조 카운팅 (Reference Counting)

각 객체가 참조될 때마다 카운트 증가
참조가 0이 되면 즉시 해제

a = [1,2,3]
b = a
del a
del b  # refcount=0 → 해제

장점: 즉시 해제
단점: 순환 참조 해결 불가

② 가비지 컬렉터 (GC)

세대별 수집(Generational GC) 사용
세대 구분:
- 0세대: 새 객체
- 1세대: 한 번 생존
- 2세대: 오래된 객체

순환 참조 해결 가능.

import gc
gc.collect()  # 강제 GC 실행

③ 메모리 풀 (Pymalloc)

작은 객체(512바이트 이하)는 메모리 풀에서 관리
큰 객체는 OS malloc/free 직접 호출

4. 가비지 컬렉션 동작 과정

참조 카운트 0인 객체 즉시 해제
주기적으로 순환 참조 탐색
gc.collect()로 강제 실행 가능
GC 주기 튜닝 가능

import gc
gc.set_threshold(700, 10, 10)

5. 메모리 구조 시각화

[스택]              →  함수 호출 시 참조 저장
   └─ a ───────┐
   └─ b ───┐   │
            │   │
[힙]        │   │
   [List]───┘   │
      ├── 1     │
      ├── 2     │
      └── 3     │
                 │
[GC] ← refcount 관리 및 순환 참조 탐색

6. 메모리 최적화 팁

__slots__ 사용: 객체 메모리 절감
제너레이터 활용: 대규모 데이터 처리 시 효율적
불필요한 참조 해제: del 명시적 사용
Numpy/Pandas: 메모리 효율적(C 기반)
GC 주기 조절: Spark/Airflow 등 대규모 파이프라인에서 유용

Apache Iceberg 기본 동작 확인 및 실습 정리

칼쵸쵸 — Sun, 6 Jul 2025 21:18:42 +0900

demo.analytics_users 테이블 상태 변화 요약

Snapshot 단계 작업 내용 테이블 상태 (id, name)

초기 생성	INSERT (Alice, Bob)	(1, 'Alice'), (2, 'Bob')
Snapshot 2	DELETE id = 2	(1, 'Alice')
Snapshot 3	UPDATE id = 1	(1, 'Charlie')
Snapshot 4	MERGE INTO (id = 3)	(1, 'Charlie'), (3, 'David')
Snapshot 5	ROLLBACK to Snap 1	(1, 'Alice'), (2, 'Bob')
Snapshot 6	INSERT (Eve)	(1, 'Alice'), (2, 'Bob'), (4, 'Eve')

✅ 1. Iceberg 테이블 생성 및 데이터 삽입

Spark SQL

CREATE TABLE demo.analytics_users (
  id INT,
  name STRING
)
USING ICEBERG
TBLPROPERTIES ('format-version' = '2');

INSERT INTO demo.analytics_users VALUES
  (1, 'Alice'),
  (2, 'Bob');

Trino

CREATE TABLE iceberg.demo.analytics_users (
  id INT,
  name VARCHAR
)
WITH (
  format_version = 2
);

INSERT INTO iceberg.demo.analytics_users VALUES
  (1, 'Alice'),
  (2, 'Bob');

예상 결과: 테이블이 정상 생성되고, snapshot 1개가 생성됨 (예: [(1, 'Alice'), (2, 'Bob')])

✅ 2. 스냅샷 존재 확인 및 목록 조회

Spark SQL

SELECT * FROM growth.demo.analytics_users.snapshots;

Trino

SELECT * FROM iceberg.demo."analytics_users$snapshots";

예상 결과: 최소 1개 이상의 snapshot ID, timestamp, operation(insert 등)이 조회됨

✅ 3. 타임트래블 (Time Travel)

Spark (PySpark)

spark.read \
  .format("iceberg") \
  .option("snapshot-id", "1234567890123") \
  .load("demo.analytics_users")

Trino

SELECT * FROM iceberg.demo.analytics_users
FOR VERSION AS OF 1234567890123;

예상 결과: 해당 snapshot 시점의 데이터만 조회됨 (예: [(1, 'Alice'), (2, 'Bob')])

✅ 4. Snapshot 간 데이터 차이 확인

Spark (PySpark)

old_df = spark.read.option("snapshot-id", "old_id").format("iceberg").load("demo.analytics_users")
new_df = spark.read.format("iceberg").load("demo.analytics_users")

added = new_df.subtract(old_df)
removed = old_df.subtract(new_df)

예상 결과:

added: 새로 추가된 행만 출력됨 (예: [(3, 'Charlie')])
removed: 삭제된 행만 출력됨 (예: [(2, 'Bob')])

✅ 5. 시스템 테이블 $changes 조회 (Trino 전용)

SELECT * FROM iceberg.demo."analytics_users$changes";

❗ DELETE, MERGE, UPDATE 등의 작업이 수행되지 않으면 $changes 테이블은 존재하지 않습니다.

예상 결과: 변경 기록(snapshot_id, change_type 등)이 담긴 row가 조회됨 (예: INSERT → id=3, name='Charlie')

✅ 6. Row-level 작업 (UPDATE / DELETE / MERGE)

Trino

-- DELETE
DELETE FROM iceberg.demo.analytics_users WHERE id = 2;

-- UPDATE
UPDATE iceberg.demo.analytics_users
SET name = 'Charlie' WHERE id = 1;

-- MERGE
MERGE INTO iceberg.demo.analytics_users t
USING (SELECT 3 AS id, 'David' AS name) s
ON t.id = s.id
WHEN MATCHED THEN UPDATE SET name = s.name
WHEN NOT MATCHED THEN INSERT (id, name);

예상 결과:

DELETE: (2, 'Bob') 제거됨
UPDATE: (1, 'Alice') → (1, 'Charlie')로 변경
MERGE: 새로운 행 (3, 'David') 추가됨

✅ 7. 롤백 (Rollback)

Spark SQL

CALL growth.system.rollback_to_snapshot(
  'demo.analytics_users',
  1234567890123
);

예상 결과: 테이블의 현재 상태가 지정한 snapshot 시점으로 되돌아감 (예: UPDATE 및 DELETE 이전 상태)

Trino와 HyperLogLog 알고리즘

칼쵸쵸 — Wed, 21 May 2025 13:40:57 +0900

HyperLogLog

핵심 아이디어

"해시값에서 가장 긴 앞자리 0의 개수를 보면, 얼마나 많은 고유 값이 있었는지 추정할 수 있다."

원소들을 해시 함수로 변환하고,
해시값의 **이진 표현에서 가장 앞의 연속된 0의 길이(max leading zeros)**를 기록,
이를 여러 버킷(bucket)에 나눠서 평균/보정하면 전체 고유 수를 추정할 수 있음.

왜 효과적인가?

해시값은 고유하게 퍼지기 때문에, 많은 고유 값이 들어오면 더 긴 연속된 0이 나타날 확률이 높아짐.
이걸 통계적으로 계산하면 거의 선형적 정확도를 얻을 수 있음.

장점

메모리 효율	수십억 개 데이터를 추정하는 데 수 KB만 사용
속도	입력값 처리 시 해시 → 배열 업데이트만 하면 됨
병렬 처리 용이	HLL 스케치는 쉽게 merge 가능 → 분산 시스템에 적합
추정 정확도 조절 가능	파라미터로 ±1% ~ ±5% 조절 가능

단점

추정치	정확하지는 않음 (신뢰 구간 존재)
고유 수가 작을 때	정확도가 낮아질 수 있음 (bias 보정 기법 존재)
해시 충돌	극단적인 충돌 가능성 존재하지만 희박

⚙️ 작동 예시 (단순화 버전)

각 입력값에 대해 hash(x)를 계산 → 이진수로 표현
해시값을 m개의 버킷으로 나눔 (보통 2^k 개)
각 버킷에 대해 leading zeros 개수를 기록
전체 평균을 통해 추정치 계산:

여기서:

R[i]: i번 버킷에 기록된 max leading zeros
α_m: 보정 상수 (m값에 따라 다름)

예를 들어 Trino에서

SELECT approx_distinct(user_id) FROM logs;

→ 내부적으로는 각 user_id를 해시하고, 그 해시값으로 HLL 스케치를 만들어서 최종 카디널리티를 추정합니다.

✅ 사용되는 곳

Trino (approx_distinct)
BigQuery (APPROX_COUNT_DISTINCT)
Redis (HLL 자료구조)
Elasticsearch (카디널리티 집계)
Flink, Druid, ClickHouse 등 모든 대용량 분석 플랫폼

위 시뮬레이션은 HyperLogLog(HLL) 알고리즘이 어떻게 동작하는지 보여줍니다.

실제로는 user_0부터 user_9999까지 10,000개의 고유 값을 넣었습니다.
해시값을 바탕으로 64개의 버킷으로 나누고, 각 버킷마다 해시값의 앞쪽 연속된 0의 개수를 기록했습니다.
최종적으로 HLL이 추정한 고유 개수는 약 14,025개로, 약간 과대 추정된 것을 볼 수 있습니다.

이는 HyperLogLog의 특성상 약 ±2~5%의 오차가 있으며, 데이터 수가 많을수록 정확도가 향상됩니다.

그래프는 각 버킷이 저장한 "가장 긴 leading zeros" 값을 나타낸 것으로, 분산된 해시값들이 어떻게 카디널리티 추정에 기여하는지를 시각적으로 보여줍니다.

✅ Trino의 대표적인 Approximate 함수 목록

함수설명예시

approx_distinct(x [, e])	고유 개수 추정 (COUNT(DISTINCT x))	approx_distinct(user_id)
approx_percentile(x, percentage [, accuracy])	퍼센타일 추정 (e.g. 95%)	approx_percentile(duration, 0.95)
approx_percentile(x, percentages ARRAY)	여러 퍼센타일 한 번에	approx_percentile(duration, ARRAY[0.5, 0.9, 0.99])
approx_set(x)	HLL 구조 리턴 (post-aggregation 처리 가능)	approx_set(user_id)
cardinality(approx_set)	approx_set() 결과의 고유 개수 추정	cardinality(approx_set(user_id))
merge(approx_set)	여러 노드에서 나온 approx_set을 병합	cardinality(merge(sets))

함수별 상세 설명

1. approx_distinct(x [, e])

HyperLogLog 기반
e: 상대 오차율 (default: 0.023)
예: approx_distinct(user_id, 0.01) → 약 1% 오차

2. approx_percentile(x, p [, accuracy])

큰 데이터셋에서 퍼센타일 추정치 구할 때 사용
예: 평균보다 상위 95% 사용시간

SELECT approx_percentile(duration, 0.95) FROM sessions;

여러 퍼센타일 계산도 가능:

SELECT approx_percentile(duration, ARRAY[0.5, 0.9, 0.99]) FROM sessions;

3. approx_set(x)

user_id들을 HLL 형식으로 집계 (나중에 merge 가능)

SELECT approx_set(user_id) FROM logs;

cardinality()와 함께 쓰면 추정 고유 수 구할 수 있음

4. merge(approx_set)

분산 환경에서 approx_set들을 합칠 때 사용

SELECT cardinality(merge(sets)) FROM ( SELECT approx_set(user_id) AS sets FROM logs GROUP BY region );

요약 표

고유 개수	COUNT(DISTINCT x)	approx_distinct(x)
퍼센타일	percentile(x, p)	approx_percentile(x, p)
유니크 값 집합	없음	approx_set(x)
집합 합치기	없음	merge(approx_set) + cardinality()

PyTorch, Hugging Face Trainer를 활용한 분산 환경 학습

칼쵸쵸 — Wed, 12 Mar 2025 15:05:16 +0900

LLM 모델 분산 학습의 구성요소

1. PyTorch

개요:
PyTorch는 Facebook AI Research(FAIR)에서 개발한 오픈 소스 딥러닝 프레임워크로, 연구와 산업계에서 널리 사용됩니다.
특징:
- 동적 계산 그래프: 모델을 개발하고 디버깅할 때 유연성이 뛰어납니다.
- GPU 가속: 손쉽게 GPU를 활용하여 연산을 가속할 수 있습니다.
- 커뮤니티와 생태계: 다양한 라이브러리와 도구들이 활발히 개발되고 있으며, 풍부한 문서와 튜토리얼이 제공됩니다.

2. Hugging Face Trainer

개요:
Hugging Face의 Transformers 라이브러리에서 제공하는 고수준 학습 인터페이스로, 복잡한 학습 루프를 단순화시켜 줍니다.
특징:
- 자동화: 학습 루프, 평가, 로깅, 체크포인트 저장 등 반복되는 작업들을 자동으로 처리합니다.
- 사용 편의성: 복잡한 딥러닝 모델도 몇 줄의 코드로 학습시킬 수 있어, 연구자나 개발자가 모델 실험에 집중할 수 있습니다.
- 분산 학습 지원: PyTorch의 분산 학습 기능과 연동되어 대규모 모델 학습도 지원합니다.

3. rdzv (Rendezvous)

개요:
rdzv는 “rendezvous”의 약자로, 분산 학습 환경에서 여러 프로세스나 노드가 서로를 인식하고 동기화하는 초기 단계에서 사용되는 메커니즘입니다.
역할:
- 프로세스 동기화: 분산 학습을 시작할 때, 각 학습 프로세스가 서로 연결되어 통신할 수 있도록 초기 설정을 합니다.
- 노드 연결: rdzv를 통해 모든 참여 프로세스가 공통의 “만남의 장소”(endpoint)를 사용하여 서로를 찾고, 이후에 작업을 분배받게 됩니다.
Hugging Face Trainer와의 관계:
- Trainer는 내부적으로 PyTorch의 분산 학습 기능을 사용하며, 이때 rdzv 설정(예: rdzv_endpoint, rdzv_backend 등)을 활용하여 다수의 프로세스가 원활히 협력할 수 있도록 합니다.
- 이를 통해 대규모 모델을 여러 GPU나 노드에 분산하여 효율적으로 학습할 수 있습니다.

요약

PyTorch: 강력하고 유연한 딥러닝 프레임워크로, 동적 계산 그래프와 GPU 가속을 지원합니다.
Hugging Face Trainer: PyTorch 기반의 모델 학습을 단순화하는 고수준 API로, 자동화된 학습 루프와 분산 학습 기능을 제공합니다.
rdzv (Rendezvous): 분산 학습 환경에서 여러 프로세스가 초기 동기화 및 연결을 할 수 있도록 하는 메커니즘으로, 대규모 모델 학습 시 필수적인 역할을 합니다.

코드 예시

train.py

import os
import torch
from transformers import Trainer, TrainingArguments, BertForSequenceClassification, BertTokenizerFast
from datasets import load_dataset

def main():
    # 데이터셋 불러오기 (예시로 GLUE의 MRPC 사용)
    dataset = load_dataset("glue", "mrpc")
    tokenizer = BertTokenizerFast.from_pretrained("bert-base-uncased")
    
    def tokenize_function(examples):
        return tokenizer(examples["sentence1"], examples["sentence2"], truncation=True)
    
    tokenized_datasets = dataset.map(tokenize_function, batched=True)
    # 불필요한 컬럼 제거 및 텐서 포맷 지정
    tokenized_datasets = tokenized_datasets.remove_columns(["sentence1", "sentence2", "idx"])
    tokenized_datasets.set_format("torch")

    # 모델 초기화
    model = BertForSequenceClassification.from_pretrained("bert-base-uncased", num_labels=2)

    # TrainingArguments: torchrun 환경변수(예: LOCAL_RANK, RANK, WORLD_SIZE)를 활용해 분산 학습이 자동 인식됩니다.
    training_args = TrainingArguments(
        output_dir="./results",
        num_train_epochs=3,
        per_device_train_batch_size=8,
        per_device_eval_batch_size=8,
        evaluation_strategy="epoch",
        save_strategy="epoch",
        logging_dir="./logs",
        logging_steps=10,
    )

    trainer = Trainer(
        model=model,
        args=training_args,
        train_dataset=tokenized_datasets["train"],
        eval_dataset=tokenized_datasets["validation"],
    )

    trainer.train()

if __name__ == "__main__":
    # torchrun으로 실행하면 환경변수에 따라 분산 학습 설정이 전달됩니다.
    # 이미 초기화되지 않은 경우, 아래와 같이 명시적으로 프로세스 그룹을 초기화할 수 있습니다.
    if "RANK" in os.environ and "WORLD_SIZE" in os.environ:
        backend = "nccl" if torch.cuda.is_available() else "gloo"
        torch.distributed.init_process_group(backend=backend)
    main()

실행 방법 (3개 노드 분산 학습)

각 노드에서는 아래와 같이 torchrun 명령어를 사용하여 실행합니다. 예를 들어, 마스터 노드의 IP가 192.168.1.1이고 포트 29500을 사용한다고 가정합니다.

노드 0 (node_rank=0):

torchrun --nproc_per_node=1 --nnodes=3 --node_rank=0 --rdzv_backend=c10d --rdzv_endpoint=192.168.1.1:29500 train.py

노드 1 (node_rank=1):

torchrun --nproc_per_node=1 --nnodes=3 --node_rank=1 --rdzv_backend=c10d --rdzv_endpoint=192.168.1.1:29500 train.py

노드 2 (node_rank=2):

torchrun --nproc_per_node=1 --nnodes=3 --node_rank=2 --rdzv_backend=c10d --rdzv_endpoint=192.168.1.1:29500 train.py

각 노드에서 --nproc_per_node 옵션은 해당 노드에서 사용할 GPU(혹은 프로세스) 수를 지정합니다. 이 예제에서는 각 노드당 1개의 프로세스를 사용합니다.

내부 통신 및 리소스 할당 과정

Rendezvous 단계 (rdzv):
- 초기 등록:
  각 노드는 torchrun 명령어를 통해 실행되며, --rdzv_endpoint로 지정된 마스터(또는 공용) IP와 포트에 접속하여 자신의 존재를 알립니다.
- 환경 변수 설정:
  torchrun은 각 노드에 RANK, WORLD_SIZE, LOCAL_RANK 등의 환경 변수를 설정하여 전체 분산 환경 정보를 전달합니다.
- 프로세스 그룹 초기화:
  코드 내에서 torch.distributed.init_process_group를 호출하여, 각 노드가 rdzv를 통해 서로를 확인하고 동일한 프로세스 그룹에 가입합니다.
통신 방식:
- 백엔드 선택:
  GPU가 사용 가능하면 nccl, 그렇지 않으면 gloo 백엔드를 사용해 통신합니다. 이 백엔드는 TCP/IP를 기반으로 각 프로세스 간의 데이터(예: gradient) 교환 및 동기화를 담당합니다.
- All-Reduce 연산:
  학습 과정에서 각 프로세스가 계산한 gradient는 All-Reduce 방식으로 집계되어, 모든 프로세스가 동일한 모델 파라미터 업데이트를 받게 됩니다.
리소스 할당:
- 노드별 할당:
  각 노드는 실행 시 LOCAL_RANK에 따라 특정 GPU에 할당됩니다. Hugging Face Trainer 및 PyTorch는 이를 자동으로 인식하여, 각 프로세스가 자신에게 할당된 GPU에서 연산을 수행하도록 합니다.
- 동기화 및 학습:
  모든 노드가 초기 rdzv 과정을 마치면, 각 노드는 동기화된 상태에서 학습 루프를 시작합니다. 모델의 파라미터 업데이트와 gradient 계산은 분산 환경에서 통신 및 동기화를 통해 이루어집니다.

요약

rdzv (Rendezvous):
각 노드가 중앙의 rendezvous 엔드포인트를 통해 서로를 인식하고, 환경 변수(RANK, WORLD_SIZE 등)를 기반으로 분산 프로세스 그룹을 형성합니다.
통신:
선택된 백엔드(nccl/gloo)를 통해 각 노드 간에 gradient와 모델 업데이트 정보를 All-Reduce 등의 집계 연산으로 동기화합니다.
리소스 할당 및 학습 진행:
각 노드는 자신에게 할당된 GPU에서 학습을 진행하며, 모든 노드가 동기화되어 동일한 모델 파라미터를 업데이트하면서 분산 학습이 효율적으로 수행됩니다.

이와 같이 Hugging Face Trainer는 torchrun과 rdzv 메커니즘을 활용해 여러 노드에서 분산 학습을 원활하게 수행할 수 있도록 도와줍니다.

Docker 이미지, 캐시, 데몬, 빌드 프로세스

칼쵸쵸 — Mon, 10 Mar 2025 23:19:55 +0900

(1) Docker 이미지란?

Docker 이미지는 컨테이너를 실행하는 데 필요한 모든 것을 포함한 불변(immutable)한 패키지입니다.
이는 레이어(layer) 기반 파일 시스템으로 구성되어 있으며, 각 레이어는 아래와 같은 명령어에 의해 생성됩니다.

FROM → 베이스 이미지 정의 (예: ubuntu:20.04)
RUN → 명령어 실행 후 파일 시스템 변경 (예: apt-get install -y curl)
COPY / ADD → 파일 복사
CMD / ENTRYPOINT → 실행 명령어 지정

각 명령어(RUN, COPY 등)는 새로운 레이어를 생성하며, 이러한 레이어는 Docker가 저장하고 관리합니다.

(2) Docker 데몬(Docker Daemon)

Docker 데몬(dockerd)은 컨테이너를 관리하는 백그라운드 프로세스로, 다음과 같은 역할을 합니다.

Docker 이미지 저장 및 관리 (docker image ls)
컨테이너 실행 (docker run)
네트워크 및 볼륨 관리
Docker API를 통해 CLI 명령어 처리

Docker CLI (docker)는 명령을 실행하면 Docker 데몬에게 요청을 보내고, 데몬이 이를 처리하여 컨테이너를 실행하거나 이미지를 빌드합니다.

(3) Docker 빌드 캐시란?

Docker는 레이어(layer) 캐싱을 활용하여 빌드를 최적화합니다.
즉, 이전 빌드에서 변경되지 않은 레이어는 **재사용(캐싱)**하여 빌드 속도를 향상시킵니다.

Docker 캐시는 다음과 같은 규칙을 따릅니다.

FROM 명령어가 같은 경우 캐시를 재사용
RUN, COPY, ADD 명령어가 동일하고, 입력 파일이 변경되지 않았다면 캐시 재사용
변경된 명령어 이후의 모든 레이어는 다시 실행됨

✅ 예제

# 베이스 이미지
FROM ubuntu:20.04 

# 패키지 업데이트 및 설치 (RUN 명령어 실행)
RUN apt-get update && apt-get install -y curl

# 실행 파일 복사
COPY app /usr/local/bin/app

➡ 빌드 과정

FROM ubuntu:20.04 → 캐시 사용 가능
RUN apt-get update && apt-get install -y curl → 변경 없음 → 캐시 사용 가능
COPY app /usr/local/bin/app → app 파일이 변경되면 캐시 무효화 ❌
(이후 모든 레이어 다시 빌드)

➡ 해결책
자주 변경되는 COPY 명령어를 나중에 배치하여 캐시를 최대한 활용하면 좋습니다.

FROM ubuntu:20.04
RUN apt-get update && apt-get install -y curl
COPY app /usr/local/bin/app

이렇게 하면 app만 변경되었을 때, 패키지 설치(RUN) 단계는 캐시를 유지하여 빌드 속도가 빨라집니다.

(4) 고정된 태그와 Digest란?

(1) 고정된 태그 (Fixed Tag)

FROM ubuntu:latest 같은 **태그(Tag)**는 변할 수 있습니다.
즉, ubuntu:latest는 오늘은 20.04지만 내일은 22.04일 수도 있음.

그래서 버전을 명확히 지정하는 것이 좋음

FROM ubuntu:20.04 # 고정된 태그 사용

이렇게 하면 빌드 시 항상 같은 20.04 버전이 사용됩니다.

(2) Digest란?

Digest는 이미지의 변경을 방지하는 고유한 SHA256 해시값입니다.

✅ 예제

FROM ubuntu@sha256:e5c01b00c3e3e87db...

이렇게 하면 어떤 태그든 변경이 발생해도, 정확한 동일한 이미지가 사용됨.

docker pull ubuntu:20.04
docker inspect ubuntu:20.04 | grep -i sha256

➡ 고유한 SHA256 해시값이 표시됨.

(5) 멀티스테이지 빌드(Multi-stage Build)란?

Docker에서 빌드 과정에서 필요하지만, 최종 컨테이너에는 불필요한 파일이나 도구를 포함하지 않도록 여러 개의 FROM을 사용하는 기법입니다.

(1) 스테이지(Stage)란?

FROM이 실행될 때마다 **새로운 스테이지(Stage)**가 생성됨.
이전 스테이지의 결과물을 최종 이미지에 필요한 부분만 복사할 수 있음.

✅ 예제: Go 애플리케이션 빌드

# 빌드 스테이지 (컴파일러 포함)
FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp

# 실행 스테이지 (최소한의 런타임 환경)
FROM ubuntu:20.04
COPY --from=builder /app/myapp /usr/local/bin/myapp
CMD ["myapp"]

(2) 멀티스테이지 빌드의 장점

최종 이미지가 작아짐 → 빌드 도구 포함되지 않음
보안 강화 → 불필요한 파일 제거
캐시 최적화 → 불필요한 중간 레이어 제거

(6) 도커 캐시, 고정 태그, 멀티스테이지 빌드 정리

개념설명

Docker 이미지	컨테이너 실행을 위한 패키지 (레이어 기반)
Docker 데몬	컨테이너 및 이미지 관리를 담당하는 백그라운드 프로세스
Docker 캐시	이전 빌드된 레이어를 재사용하여 속도를 최적화
고정된 태그	ubuntu:20.04처럼 특정 버전을 사용하여 예측 가능성 증가
Digest	sha256:e5c01b00...과 같이 해시를 사용하여 정확한 이미지 보장
멀티스테이지 빌드	FROM을 여러 번 사용하여 빌드와 실행을 분리하여 최적화

마무리

Docker 이미지는 여러 개의 불변 레이어로 구성됨.
Docker 캐시는 빌드 속도를 높이지만, 특정 단계가 변경되면 이후 모든 단계가 재빌드됨.
고정된 태그(Fixed Tag)나 Digest를 사용하여 빌드 안정성을 보장.
멀티스테이지 빌드는 빌드와 실행 환경을 분리하여 보안, 성능, 크기 최적화를 가능하게 함.

NVIDIA의 GPU, CUDA, PyTorch, TensorRT

칼쵸쵸 — Mon, 10 Mar 2025 22:27:27 +0900

NVIDIA GPU와 CUDA의 관계

CUDA(Compute Unified Device Architecture)는 NVIDIA에서 개발한 병렬 컴퓨팅 플랫폼으로, GPU의 강력한 병렬 처리 능력을 활용하여 일반적인 계산 작업을 가속화합니다. 이는 그래픽 처리뿐만 아니라 과학 계산, 머신 러닝 등 다양한 분야에서 활용됩니다.

GPU 아키텍처별 지원하는 CUDA 버전:GPU 모델아키텍처지원 가능한 CUDA 최소 버전

GPU 모델 아키텍처 지원 가능한 CUDA 최소 버전

P40 Pascal CUDA 8.0 이상

T4 Turing CUDA 10.0 이상

A100 Ampere CUDA 11.0 이상

H100 Hopper CUDA 12.0 이상

주의: 최신 CUDA 버전은 이전 GPU 아키텍처와의 호환성을 유지하지만, 최신 GPU의 기능을 완전히 활용하려면 해당 GPU가 요구하는 최소 CUDA 버전을 사용하는 것이 중요합니다.

NVIDIA는 다양한 용도와 성능 요구 사항을 충족시키기 위해 여러 세대의 GPU를 출시해 왔습니다. 아래는 P40, T4, A100, H100을 포함한 주요 NVIDIA GPU의 성능과 특징을 정리한 표입니다.

GPU 모델	아키텍처	출시일	CUDA 코어 수	메모리	대역폭	주요 특징
P40	Pascal	2016년	3,840	24GB GDDR5	346 GB/s	고성능 컴퓨팅 및 딥러닝 추론에 최적화
T4	Turing	2018년	2,560	16GB GDDR6	320 GB/s	에너지 효율성이 높으며, AI 추론 및 그래픽 작업에 적합
A100	Ampere	2020년	6,912	40GB 또는 80GB HBM2e	1,555 GB/s	고성능 컴퓨팅, AI 학습 및 추론에 최적화
H100	Hopper	2022년	8,192	80GB HBM3	2,000 GB/s	차세대 고성능 컴퓨팅 및 AI 워크로드에 최적화
RTX 5090	Blackwell	2025년	21,760	32GB GDDR7	1,792 GB/s	최고 수준의 게임 및 그래픽 성능 제공

참고 사항:

P40: Pascal 아키텍처 기반으로, 딥러닝 추론 및 고성능 컴퓨팅 작업에 사용되었습니다.
T4: Turing 아키텍처를 채택하여 에너지 효율성이 높고, AI 추론 및 그래픽 작업에 널리 활용되었습니다.
A100: Ampere 아키텍처 기반으로, 대규모 AI 학습 및 추론, 고성능 컴퓨팅에 최적화되었습니다.
H100: Hopper 아키텍처를 적용하여 이전 세대보다 향상된 성능과 메모리 대역폭을 제공합니다.

CPU 코어와 CUDA 코어

CPU 코어와 CUDA 코어는 모두 연산 작업을 수행하는 프로세서의 기본 단위이지만, 그 설계 목적과 구조에는 차이가 있습니다.

CPU 코어:

설계 목적: 순차적 작업 처리와 낮은 지연 시간에 최적화되어 있습니다.
구조: 상대적으로 적은 수의 코어(일반적으로 4~16개)를 가지고 있으며, 각 코어는 복잡한 제어 로직과 큰 캐시 메모리를 포함하여 다양한 작업을 빠르게 처리할 수 있습니다.
특징: 높은 클럭 속도와 복잡한 연산 처리를 통해 단일 또는 소수의 스레드를 효율적으로 처리합니다.

CUDA 코어:

설계 목적: 대규모 병렬 처리를 통해 높은 처리량을 제공하도록 최적화되어 있습니다.
구조: 수백에서 수천 개의 간단한 코어로 구성되어 있으며, 각 코어는 단순한 연산을 수행하도록 설계되어 대량의 데이터를 동시에 처리할 수 있습니다.
특징: 낮은 클럭 속도와 단순한 제어 로직을 통해 에너지 효율성을 높이고, 대규모 병렬 연산을 효율적으로 수행합니다.

비교 요약:

코어 수: CPU는 적은 수의 복잡한 코어를, GPU는 많은 수의 단순한 코어를 가집니다.
처리 방식: CPU는 순차적 처리에, GPU는 병렬 처리에 최적화되어 있습니다.
용도: CPU는 일반적인 컴퓨팅 작업에, GPU는 그래픽 처리 및 병렬 연산이 필요한 작업에 주로 사용됩니다.

이러한 차이로 인해 CPU와 GPU는 각기 다른 작업 부하에 대해 최적의 성능을 발휘하며, 현대 컴퓨팅 환경에서는 두 프로세서의 협업을 통해 다양한 작업을 효율적으로 처리합니다.

PyTorch와 CUDA의 관계

PyTorch는 Python 기반의 오픈 소스 머신 러닝 라이브러리로, 자연어 처리와 컴퓨터 비전과 같은 분야에서 널리 사용됩니다. PyTorch는 CUDA를 지원하여 NVIDIA GPU를 활용한 고속 연산을 가능하게 합니다.

PyTorch 버전별 지원하는 CUDA 버전:PyTorch 버전지원하는 CUDA 버전

PyTorch 버전 지원하는 CUDA 버전

1.8 10.2, 11.1

1.9 10.2, 11.1

1.10 10.2, 11.3

1.11 10.2, 11.3

1.12 10.2, 11.6

1.13 11.6

2.0 11.7, 11.8

2.1 11.8, 12.1

참고: PyTorch는 CUDA와의 호환성을 위해 다양한 버전의 빌드를 제공합니다. 따라서, 사용 중인 GPU와 CUDA 버전에 맞는 PyTorch 버전을 선택하여 설치하는 것이 중요합니다.

TensorRT와의 통합

TensorRT는 NVIDIA의 딥러닝 추론 최적화 라이브러리로, 모델의 추론 속도를 크게 향상시킵니다. PyTorch와 TensorRT의 통합은 Torch-TensorRT를 통해 이루어지며, 이는 PyTorch에서 학습한 모델을 TensorRT로 변환하여 추론 성능을 최대 6배까지 향상시킬 수 있습니다.

Torch-TensorRT 사용 예시:

import torch
import torch_tensorrt

model = MyModel().eval().cuda()  # 모델 정의
inputs = [torch.randn((1, 3, 224, 224)).cuda()]  # 입력 데이터 정의

# Torch-TensorRT를 사용하여 모델 최적화
optimized_model = torch_tensorrt.compile(model, inputs=inputs, enabled_precisions={torch.float})

nvidia/pytorch 컨테이너 버전별 주요 변경 사항

# NVIDIA PyTorch 최신 컨테이너 사용
FROM nvcr.io/nvidia/pytorch:25.02-py3

NVIDIA는 딥러닝 프레임워크와 라이브러리의 호환성을 유지하기 위해 정기적으로 컨테이너를 업데이트합니다. 아래는 주요 변경 사항이 있었던 컨테이너 버전의 목록입니다:

https://docs.nvidia.com/deeplearning/frameworks/pytorch-release-notes/rel-25-02.html

PyTorch Release 25.02 - NVIDIA Docs

NVIDIA Optimized Frameworks

docs.nvidia.com

컨테이너 버전	Ubuntu 버전	Python 버전	CUDA 버전	PyTorch 버전	TensorRT 버전	주요 변경 사항
25.02	24.04	3.12	12.8.0.38	2.7.0a0	10.8.0.43	Ubuntu 24.04 및 Python 3.12로 업그레이드
23.06	22.04	3.10	12.0	2.1.0a0	8.6.1	CUDA 12.0 지원 시작
22.08	22.04	3.10	11.7	1.13.0a0	8.5.2	Ubuntu 22.04 및 Python 3.10으로 업그레이드
21.03	20.04	3.8	11.2	1.8.0a0	7.2.2	Ubuntu 20.04 및 Python 3.8로 업그레이드
20.06	18.04	3.6	11.0	1.6.0a0	7.0.0	CUDA 11.0 지원 시작
20.01	18.04	3.6	10.1	1.4.0a0	6.0.1	초기 릴리스

참고: 각 컨테이너 버전은 해당 시점의 최신 소프트웨어 스택을 포함하고 있으며, 새로운 기능과 성능 향상을 제공합니다. 따라서, 프로젝트의 요구 사항과 사용 중인 하드웨어에 맞게 적절한 버전을 선택하는 것이 중요합니다.

GPU 모델	아키텍처	지원 가능한 CUDA 최소 버전
P40	Pascal	CUDA 8.0 이상
T4	Turing	CUDA 10.0 이상
A100	Ampere	CUDA 11.0 이상
H100	Hopper	CUDA 12.0 이상

PyTorch 버전	지원하는 CUDA 버전
1.8	10.2, 11.1
1.9	10.2, 11.1
1.10	10.2, 11.3
1.11	10.2, 11.3
1.12	10.2, 11.6
1.13	11.6
2.0	11.7, 11.8
2.1	11.8, 12.1