본문 바로가기
WIKI 기술 지식 베이스

용어집

원문 보기 위키 갱신

용어집 (Glossary)

이 문서는 lakeFS의 기술 내부 동작과 아키텍처와 관련된 모든 용어의 정의와 설명을 담고 있어요.

출처: 용어집 (Glossary)

본문

Auditing (감사)

데이터 감사는 특정 용도에 맞는 데이터의 정확성, 보안, 효율성을 확인하는 데이터 평가예요. 데이터 라이프사이클 전반에 걸쳐 데이터 품질을 평가하고, 낮은 품질의 데이터가 조직의 성과와 매출에 미치는 영향을 이해하는 것도 포함돼요. 데이터의 재현성, 감사 가능성, 거버넌스를 보장하는 것은 요즘 데이터 엔지니어들의 핵심 관심사예요. lakeFS 커밋 히스토리는 데이터 팀이 데이터의 모든 변경 사항을 추적하도록 도와 데이터 감사를 지원해요.

Branch (브랜치)

lakeFS의 브랜치는 사용자가 저장소의 자신만의 "격리된" 뷰를 만들 수 있게 해줘요. Read more.

Collection (컬렉션)

컬렉션은 대략 말하자면 데이터의 집합이에요. 컬렉션은 구조화될 수도, 구조화되지 않을 수도 있어요. 구조화된 컬렉션은 흔히 테이블이라고 불려요.

Commit (커밋)

커밋을 사용하면 저장소의 히스토리에서 특정 시점을 볼 수 있고, 그 시점에 커밋됐던 그대로의 데이터를 보고 있다는 보장을 받아요. Read More.

Cross-Collection Consistency (컬렉션 간 일관성)

아쉽게도 'consistency'라는 단어는 여러 의미를 가지고 있어요. Martin Kleppmann에 따르면 적어도 네 가지가 있죠. lakeFS와 데이터 버저닝의 맥락에서의 일관성은 트랜잭션 내 연산이 정확하고, 올바르게, 그리고 무엇보다 원자적으로 수행된다는 보장이에요.

lakeFS의 저장소(그리고 브랜치)는 여러 테이블이나 컬렉션에 걸칠 수 있어요. 브랜치, 커밋, 머지, 리버트 연산을 브랜치 위에서 원자적으로 제공함으로써, lakeFS는 서로 다른 논리적 컬렉션에 걸친 일관성 보장을 달성해요. 즉, 저장소 내 여러 컬렉션에 걸쳐 데이터 버저닝이 일관되게 유지돼요.

때로는 multi-table transactions라고도 불려요. 즉, lakeFS는 여러 테이블에 걸친 트랜잭션 보장을 제공해요.

Data Lake Governance (데이터 레이크 거버넌스)

데이터 레이크 거버넌스의 목표는 데이터에 정책, 표준, 프로세스를 적용하는 거예요. 이를 통해 고품질 데이터를 만들고 조직 전반에서 데이터가 적절히 사용되도록 보장할 수 있어요. 데이터 레이크 거버넌스는 데이터 품질을 개선하고 비즈니스 의사결정을 위한 데이터 활용을 늘려서, 운영 개선, 더 나은 정보에 기반한 비즈니스 전략, 더 강한 재무 성과로 이어져요. lakeFS Cloud는 Role-Based Access Control, Branch Aware Managed Garbage Collection, Data Lineage, Audit log 같은 고급 데이터 레이크 관리 기능을 제공해요.

Data Lifecycle Management (데이터 라이프사이클 관리)

데이터 집약적 애플리케이션에서 데이터는 팀이 코드를 관리하는 방식처럼 전체 라이프사이클 동안 관리되어야 해요. 그렇게 하면 애플리케이션 라이프사이클 관리(CI/CD 연산 등)의 모범 사례와 도구를 데이터에 적용할 수 있어요. lakeFS는 공유 버킷 대신 격리된 데이터 개발 환경으로 데이터 라이프사이클 관리를 제공해요.

Data Pipeline Reproducibility (데이터 파이프라인 재현성)

데이터 파이프라인의 재현성은 프로세스를 반복할 수 있는 능력이에요. 한 예로 프로덕션 파이프라인에서 발생한 이슈를 재현하는 경우가 있어요. 재현성 덕분에 에러를 통제된 방식으로 만들어 나중에 디버깅하고 문제를 해결할 수 있어요. 데이터 파이프라인 이슈를 재현하는 일은 대부분의 데이터 엔지니어가 매일 마주하는 과제예요. lakeFS가 데이터 파이프라인 재현성을 어떻게 지원하는지 자세히 알아보세요. 다른 활용 사례로는 애드혹 쿼리 실행(데이터 사이언스에 유용), 리뷰, 백필(backfill)이 있어요.

Data Quality Testing (데이터 품질 테스트)

이 용어는 데이터의 정확성, 완전성, 일관성, 시의성, 유효성, 무결성을 검사하는 방법을 설명해요. lakeFS hooks를 사용하면 스테이징 데이터를 프로덕션으로 승격하기 전에 데이터 품질 테스트를 구현하고 실행할 수 있어요.

Dataset (데이터셋)

데이터셋은 lakeFS에서 저장소 데이터 위의 큐레이션된 뷰에 이름을 붙인 일급(first-class) 버전 관리 엔티티예요. 데이터셋은 포인터(데이터 항목)들의 집합과 설명 메타데이터로 이루어져 있고, 데이터는 복사되지 않아요. 데이터셋은 설치 환경의 최상위 수준에서 저장소와 나란히 존재해요. 각 데이터셋은 선형 버전 히스토리를 가지며, 모든 변경은 다음 불변 버전(v1, v2, ...)을 만들어요. Read more.

Data Item (데이터 항목)

데이터 항목은 데이터셋 안의 단일 (target, source) 쌍이에요. target은 소비자가 데이터셋을 통해 데이터를 읽을 때 사용하는 주소이고, source는 lakeFS 저장소 안의 경로, 프리픽스, 테이블, 네임스페이스로 특정 커밋에 고정(pin)돼 있어요.

Dataset Version (데이터셋 버전)

데이터셋 정의의 불변적이고 단조 증가하는 번호가 매겨진 스냅샷이에요. 생성이나 업데이트가 있을 때마다 다음 버전(v1, v2, v3, ...)이 만들어져요. latest는 항상 가장 최근에 발행된 버전을 가리켜요. 버전 식별자는 시스템이 생성하며 재사용되지 않아요.

Data Versioning (데이터 버저닝)

데이터를 버저닝한다는 것은 나중에 접근할 수 있는 고유한 시점 참조를 데이터에 만드는 거예요. 이 참조는 쿼리, ID, 또는 흔히 DateTime 식별자 형태를 가질 수 있어요. 데이터 버저닝에는 버전을 만들 때마다 데이터 전체 복사본을 새 이름이나 새 파일 경로 아래 저장하는 방식도 포함될 수 있어요. lakeFS 같은 더 진보된 버저닝 솔루션은 zero-copy 데이터 연산으로 버저닝을 수행해요. lakeFS는 버전 사이의 스토리지 사용량도 최적화하고, 버전을 관리하는 특별한 연산도 제공해요.

Git-like Operations (Git 같은 연산)

lakeFS는 팀이 데이터 레이크를 Git 저장소처럼 다룰 수 있게 해줘요. Git이 코드 버저닝에 쓰인다면 lakeFS는 데이터 버저닝에 쓰여요. lakeFS는 branch, commit, merge, revert 같은 Git 스타일 연산을 제공해요.

Graveler

Graveler는 lakeFS의 핵심 버저닝 엔진이에요. lakeFS 주소를 실제 저장된 객체로 변환하는 방식으로 버저닝을 처리해요. lakeFS가 메타데이터를 어떻게 저장하는지는 versioning internals 섹션을 참고하세요.

Hooks (훅)

lakeFS hooks를 사용하면 중요한 라이프사이클 이벤트 이전에 특정 검사와 검증이 반드시 수행되도록 자동화할 수 있어요. 개념적으로는 Git Hooks와 비슷하지만, 대조적으로 서버에서 원격으로 실행돼요. 현재 lakeFS는 두 종류의 이벤트에서 훅 실행을 허용해요: 커밋이 승인되기 전에 실행되는 pre-commit 이벤트와, 머지 연산 직전에 트리거되는 pre-merge 이벤트예요.

Isolated Data Snapshot (격리된 데이터 스냅샷)

lakeFS에서 브랜치를 만들면 저장소의 스냅샷을 담은 격리된 환경이 생겨요. 브랜치에서 격리된 상태로 작업하는 동안 다른 모든 데이터 사용자는 저장소의 main 브랜치를 보고 있어요. 그래서 그들은 당신의 변경 사항을 볼 수 없고, 당신도 main 브랜치에 적용된 변경 사항을 볼 수 없어요. 이 모든 일은 데이터 복제 없이 메타데이터 관리만으로 일어나요.

Main Branch (메인 브랜치)

모든 Git 저장소에는 main 브랜치가 있고(명시적으로 제거하지 않는 한), 소프트웨어 개발 과정에서 핵심 역할을 해요. 대부분의 프로젝트에서 main 브랜치는 source of truth, 즉 동작이 검증되고 프로덕션에 푸시할 준비가 된 모든 코드를 나타내요. 마찬가지로 lakeFS의 main 브랜치도 단일 source of truth로 사용할 수 있어요. 예를 들어 실제 프로덕션 데이터를 main 브랜치에 둘 수 있어요.

Metadata Management (메타데이터 관리)

데이터가 있는 곳에는 메타데이터도 있기 마련이에요. lakeFS는 메타데이터로 스키마, 데이터 타입, 데이터 버전, 다른 데이터셋과의 관계 등을 정의해요. 이는 탐색 가능성(discoverability)과 관리 용이성을 높여줘요. lakeFS는 메타데이터 연산을 통해 데이터 버저닝을 수행해요.

Merge (머지)

lakeFS의 merge 명령은 Git의 머지 기능처럼 데이터 브랜치를 머지할 수 있게 해줘요. 데이터를 커밋한 뒤 검토하고, 커밋된 데이터를 대상 브랜치로 머지할 수 있어요. 머지는 대상 브랜치에 모든 변경 사항을 담은 커밋을 생성해요. lakeFS는 데이터 복사가 필요 없기 때문에 빠른 원자적 머지를 보장해요. Read More.

Object Metadata (객체 메타데이터)

lakeFS에서 각 객체는 두 종류의 메타데이터를 가질 수 있어요:

  • 시스템 메타데이터: 객체 경로, 크기, 마지막 수정 시간, 변경을 만든 커미터 같은 자동으로 수집되는 속성이에요.

  • 사용자 정의 메타데이터: 데이터 수집, 처리, 큐레이션 과정에서 맥락을 풍부하게 하기 위해 추가하는 커스텀 키-값 쌍(예: 레이블, 어노테이션, 태그)이에요.

데이터 자체처럼 객체 메타데이터도 lakeFS에서 버저닝돼요. 즉, 메타데이터가 데이터와 함께 진화하고 쉽게 관리, 쿼리, 재현될 수 있어요.

S3 호환성: S3 게이트웨이를 사용할 때 lakeFS는 사용자 정의 메타데이터 키를 X-Amz-Meta- 프리픽스와 함께 저장하고 키 자체는 소문자로 만들어요. 이는 "Amazon S3 stores user-defined metadata keys in lowercase"라고 명시한 S3 specification을 따르는 거예요. 예를 들어 메타데이터 키 MyKey를 가진 객체를 S3 게이트웨이로 업로드하면 저장된 키는 X-Amz-Meta-mykey가 돼요. S3 클라이언트가 게이트웨이를 통해 객체를 다시 읽으면 키를 mykey로 봐요(SDK가 프리픽스를 떼어냄), 반면 lakeFS API는 저장된 전체 키를 반환해요.

Repository (저장소)

lakeFS에서 저장소는 관련된 객체(또는 객체 컬렉션)의 집합이에요. Read More.

Rollback (롤백)

롤백은 이전 커밋의 효과를 되돌리는 원자적 연산이에요. 개발자가 새 코드 버전을 프로덕션에 배포했다가 치명적인 버그를 발견하면, 이전 버전으로 간단히 롤백할 수 있어요. lakeFS에서 롤백은 원자적 액션으로, 이슈가 해결될 때까지 데이터 소비자가 저품질 데이터를 받지 않도록 막아줘요. lakeFS가 롤백 연산을 지원하는 방식을 자세히 알아보세요.

Storage Namespace (스토리지 네임스페이스)

스토리지 네임스페이스는 특정 저장소 전용으로 할당된 기반 스토리지의 위치예요. lakeFS는 이곳에 저장소의 객체와 일부 메타데이터를 저장해요.

Underlying Storage (기반 스토리지)

기반 스토리지는 lakeFS가 객체와 일부 메타데이터를 보관하는 오브젝트 스토어의 위치예요.

Tag (태그)

태그는 특정 커밋에 의미 있는 이름을 붙이는 방법이에요. Read More.

Fluffy

lakeFS Enterprise의 싱글 사인온(SSO) 서비스예요. lakeFS의 인증 요청을 위임받아 처리하고, 인증 응답을 lakeFS에 다시 돌려줘요.

더 알아보기 (Learn more)

공식 문서의 원문은 https://docs.lakefs.io/resources/glossary/ 에서 확인할 수 있어요.