분산파일·객체저장·데이터레이크

1. 파일이 전부 보이는데 왜 집계가 틀릴까

공장의 온도 기록을 하루 단위로 모으는 분석 담당자가 저장소에서 파일 두 개를 찾았다. 하나는 오늘 다시 만든 파일이고 다른 하나는 어제의 수정 전 파일이었다. 각각은 온전하지만 두 파일을 함께 읽은 합계는 어느 하루의 확정 결과도 아니었다. 파일을 여러 장비에 안전하게 저장하는 문제와 서로 맞는 파일 묶음을 읽는 문제는 같지 않다.

이 절에서는 바이트를 어디에 둘지, 이름으로 어떻게 찾을지, 어느 파일 묶음을 공개할지를 구별한다. 분산파일시스템과 객체저장을 비교한 뒤, 그 위에서 데이터레이크를 운영할 때 필요한 표 단위의 공개 경계를 살핀다. 제품 소개보다 요청 경로와 실패 지점을 따라가는 데 초점을 둔다.

공장, 파일 이름, 용량, 공개 상태와 계산은 저자가 만든 예다. 특정 제품을 설치하거나 실제 성능·장애 복구를 측정한 결과가 아니다.

파일의 이름과 실제 입출력 단위를 되짚는다

파일·블록·영속 저장에서 파일은 이름으로 다루는 논리 단위이고 블록은 장치의 입출력 단위라고 배웠다. 이번에는 한 파일의 저장 부분이 여러 장비에 나뉠 때 이름과 위치를 연결하는 책임을 살핀다.

노드가 응답하지 않아도 다른 노드는 움직인다

시간초과·재시도·멱등성과 부분실패의 분산 노드는 독립적으로 실행되고 고장 날 수 있었다. 응답 중단만으로 장비 고장과 통신 단절을 곧바로 구별할 수 없으므로, 복제본 선택과 쓰기 권한도 별도로 판단한다.

파일을 쌓아도 뜻과 형식은 자동으로 생기지 않는다

데이터·정보·메타데이터·모델에서 메타데이터는 데이터의 뜻·구조·단위·출처 등을 설명하는 데이터였고, 데이터 형식·스키마·호환성에서는 생산자와 소비자가 형식 변경을 해석할 수 있어야 했다. 저장 위치 목록만으로 온도의 단위나 필드 변경의 의미까지 검증되지는 않는다.

쉽게 말하면, 창고를 늘리는 것과 목록을 맞추는 것을 나눈다

큰 기록 파일을 여러 창고에 나눠 두었다고 생각해 보자. 같은 조각을 다른 창고에도 두면 한 창고가 멈춰도 읽을 가능성이 남는다. 그러나 어느 조각이 어느 파일에 속하는지 적은 목록을 잃으면 조각이 남아 있어도 정상적인 파일 읽기가 어려워진다.

창고 비유의 한계도 있다. 컴퓨터는 파일 이름·권한·변경 순서까지 처리해야 하고, 복구 중에도 요청이 계속 들어올 수 있다. 저장 장비 수만 세지 말고 데이터와 그것을 찾는 정보의 경로를 함께 그려야 한다.

분산 저장의 담당 범위

분산파일·객체저장은 파일 또는 객체의 바이트를 여러 노드에 배치하고, 이름·위치·버전 등의 메타데이터를 통해 읽기와 쓰기를 조정하는 저장 구조다. 모든 제품이 같은 인터페이스나 같은 일관성 보장을 제공한다는 뜻은 아니다. 예를 들어 파일 경로를 따라 읽는 방식과 객체의 키를 지정해 가져오는 방식은 이름을 다루는 계약부터 다를 수 있다. [DS1][DS4]

이 절은 분산파일처리의 저장·탐색·복구·파일 집합 공개를 담당한다. SQL 실행계획, 행 단위 잠금, 모든 DBMS의 트랜잭션 구현은 앞뒤의 해당 담당 절에서 다룬다.

세 층에서 서로 다른 질문을 한다

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

위에서 아래로 읽을 판본이 파일·객체 이름을 참조하고, 이름의 위치 정보로 바이트 사본·복구 조각을 찾는다. 바이트 보호만으로 같은 파일 묶음 판본이 보장되지 않으며 메타데이터가 맞아도 필요한 파일이 삭제되면 읽을 수 없다.

아래층의 복구 성공이 위층의 올바른 판본 선택을 대신하지는 않는다. 반대로 표의 판본 목록이 정확해도 그것이 가리키는 파일을 미리 지우면 읽을 수 없다. 각 화살표에는 참조가 유효해야 한다는 조건이 붙는다.

2. HDFS에서 이름 담당과 바이트 담당을 나눈다

NameNode는 HDFS의 파일 이름 공간과 파일을 구성하는 블록 위치 등의 메타데이터를 관리하는 역할이다. DataNode는 HDFS 데이터 블록을 저장하고 클라이언트의 블록 읽기·쓰기 요청을 처리하는 역할이다. 여기서 HDFS 블록은 분산파일시스템이 파일을 나누는 단위이지 장치의 물리 섹터와 같은 크기라는 뜻은 아니다. [DS1]

가령 /sensor/day-01의 일부가 저장 노드 D1과 D2에 복제되어 있다면, 이름 담당은 그 파일의 블록을 어디서 찾을지 알려 준다. 실제 온도 기록 바이트를 읽는 경로는 클라이언트와 해당 저장 노드 사이에 형성된다. NameNode를 모든 사용자 바이트의 중계 장치로 그리면 역할을 잘못 이해한 것이다.

읽기와 쓰기에서 목록 경로와 데이터 경로를 따라간다

읽을 때 클라이언트는 먼저 파일에 해당하는 블록 위치를 확인하고, 사용 가능한 복제본을 가진 DataNode에서 바이트를 받는다. 읽은 블록의 무결성 검사에 문제가 있으면 다른 복제본을 이용할 수 있다. 복제본이 있다는 사실과 읽은 바이트가 정상이라는 확인을 나누는 이유다. [DS1]

복제 쓰기에서는 선택된 DataNode들이 파이프라인으로 데이터를 전달할 수 있다. 클라이언트에서 첫 저장 노드로, 이어 다음 저장 노드들로 전달되는 경로와 NameNode의 파일 메타데이터 갱신 경로는 구별한다. 실제 성공 응답의 조건은 사용한 연산과 설정에 따르므로 “전송을 시작했으니 영구 보존 완료”라고 쓰지 않는다.

이 설명은 Hadoop 3.4.2 문서의 역할 분담을 따른다. 분산파일이라고 해서 임의 위치의 동시 덮어쓰기나 모든 POSIX 파일 동작이 그대로 보장된다고 확대하지 않는다.

데이터 복제만으로 이름 담당의 장애가 해결되지는 않는다

DataNode 여러 곳에 블록이 있어도 파일 이름과 블록 관계를 관리하는 계층이 멈추면 정상적인 접근이 어려워질 수 있다. 따라서 데이터의 복제 수와 메타데이터 계층의 고가용성은 별도 항목으로 점검한다. 네트워크 단절을 장비 삭제로 오판해 복제본을 무작정 제거하는 일도 피해야 한다. [DS1][DS2]

QJM(Quorum Journal Manager)은 Active와 Standby NameNode가 JournalNode들에 보관된 편집 로그를 공유하도록 하는 HDFS 고가용성 기능이다. 이 구성에서는 Active NameNode가 변경 기록을 JournalNode 과반수에 지속 기록하고, Standby가 그 기록을 읽어 자신의 이름 공간에 반영하며 전환을 준비한다. 세 JournalNode의 과반수는 두 개지만, 이 산술만으로 실제 구성의 장애 내성을 보증할 수는 없다. 쓰기 권한의 배타성, 저장 위치, 통신 경로와 전환 설정도 맞아야 한다. [DS2]

Standby가 있다고 쓰기 권한을 가진 두 Active가 동시에 마음대로 기록해도 되는 것은 아니다. 체크포인트를 만드는 Secondary NameNode를 자동 장애 전환용 Standby와 동일시해서도 안 된다. 이름에 붙은 “두 번째”보다 맡은 역할과 전환 조건을 확인한다.

삭제되지 않은 조각으로 복구할 수 있게 저장한다

삭제코딩은 데이터를 여러 조각과 복구용 부호 조각으로 나누어, 정해진 수의 조각 손실 안에서 원래 데이터를 재구성하는 저장 방법이다. 여기서 삭제는 사용자의 삭제 명령이 아니라 조각을 잃은 상황을 뜻한다. 같은 바이트를 여러 벌 두는 복제와 복구 재료의 형태가 다르다. [DS3]

데이터 조각 여섯 개와 복구용 조각 세 개를 쓰는 구성을 생각해 보자. 적절한 부호의 조건 아래 아홉 조각 중 세 조각까지 잃어도 복구할 수 있지만, 세 장비나 세 랙의 모든 고장을 무조건 견딘다는 뜻은 아니다. 한 장애 영역에 여러 조각이 몰려 있으면 한 번의 장애로 한계를 넘을 수 있다.

600 MiB를 보존하는 데 필요한 이상적 바이트 수

전체 데이터가 600 MiB이고, 완전히 채운 데이터 조각 여섯 개가 각각 100 MiB라고 가정한다. 압축, 메타데이터, 미완성 묶음의 여분 공간과 복구 중 임시 공간은 제외한다. MiB는 여기서 같은 단위를 유지하기 위한 표기이며 다른 단위의 저장 요금과 바로 비교하지 않는다.

3중 복제는 600 × 3 = 1800 MiB이고, 6+3 삭제코딩은 100 × (6 + 3) = 900 MiB다. 이 가정에서 감소량은 900 MiB, 복제 대비 감소율은 50%다. 데이터 대비 부가 공간은 각각 200%와 50%이므로 “50% 절감”과 “50% 부가 공간”의 분모가 다른 점에 주의한다.

삭제코딩의 공간 이득을 읽기 지연이나 복구 속도의 이득으로 옮겨 적으면 안 된다. 잃은 조각을 복구할 때는 여러 조각을 읽고 계산한 뒤 다시 기록할 수 있어 CPU·네트워크·디스크의 부담을 함께 본다. 자주 바뀌는 작은 데이터와 장기간 보존하는 큰 데이터의 선택이 달라지는 이유다.

파일시스템과 객체저장을 같은 기능 목록으로 가정하지 않는다

이 표는 어느 제품이 모든 기능을 가진다는 보증표가 아니다. 같은 “이름 변경”도 해당 인터페이스에서 원자적 연산인지 여러 요청의 조합인지 확인해야 한다. 분석 프로그램이 요구하는 연산을 먼저 적고 그 계약을 충족하는 저장 방식을 고른다.

3. 객체는 키로 찾아오는 바이트 단위다

객체는 객체저장 인터페이스가 하나의 키로 식별하여 저장·조회하는 데이터와 관련 메타데이터의 단위다. 버킷은 Amazon S3에서 객체를 담는 이름 있는 저장 영역이다. 객체 키는 한 버킷 안에서 객체를 식별하는 이름이다. 이 절의 S3 설명은 일반 목적 버킷의 객체 연산을 대상으로 한다. 다른 종류의 버킷이나 별도 표 서비스의 계약을 대신하지 않는다. [DS4]

예를 들어 sensor/day-01/part-a는 이 사례의 객체 키다. 이름에 /가 보여도 객체 자체가 운영체제의 디렉터리 안 파일과 동일한 연산 계약을 갖는다는 뜻은 아니다. 이름의 모양보다 GET과 PUT이 어느 단위를 처리하는지 먼저 확인한다.

함께 성공해야 하는 작업의 경계를 기억한다

트랜잭션의 네 성질(ACID)에서 트랜잭션은 함께 성공하거나 실패해야 하는 논리적 작업단위였다. 객체 한 개의 갱신이 원자적이라는 말만으로 여러 객체와 외부 업무까지 그 단위에 들어가지는 않는다.

강한 일관성이 있어도 두 키의 중간 상태는 생길 수 있다

S3 문서가 설명하는 객체 PUT·DELETE의 강한 읽기 일관성과 키 하나의 원자적 갱신은 서로 관련 있지만 여러 키의 원자적 묶음 갱신은 아니다. 성공 완료 뒤에 시작한 읽기는 그 완료된 변경을 반영하지만, 다른 쓰기가 뒤따르면 당연히 읽는 시점의 상태가 달라질 수 있다. LIST가 정확해도 두 번의 PUT 사이에 읽기를 시작할 수 있다. [DS4]

자체 예제에서 처음에는 part-a=100, part-b=200이고 확정 합계는 300이다. 새 묶음은 part-a=110, part-b=220으로 합계 330이어야 한다. 다른 쓰기는 없고 첫 PUT은 성공했지만 둘째 PUT은 아직 시작하지 않았다고 하자.

중간 합계 310은 객체가 깨져서가 아니라 묶음의 공개 경계가 없어서 생겼다. 이 예제는 강한 일관성을 위반하지 않는다. 따라서 더 많이 복제하거나 LIST를 한 번 더 호출하는 것만으로 표 전체의 확정 판본이 정해지지는 않는다.

레이크에는 저장뿐 아니라 찾기와 해석의 관리가 필요하다

데이터레이크는 여러 형식의 데이터를 축적하고 목적에 맞게 발견·해석·처리하도록 저장과 메타데이터·접근 관리를 결합한 데이터 활용 구조다. 데이터 카탈로그는 데이터 집합의 위치·구조·설명·관리 정보 등을 찾아볼 수 있도록 조직한 메타데이터 목록이다. 카탈로그가 있다고 모든 데이터의 의미와 품질이 검증되었다는 뜻은 아니다. [DS5]

센서 파일의 위치만 등록한 목록과 “섭씨, 1분 간격, 누락은 별도 표시, 담당자는 생산분석팀”까지 설명한 목록은 활용성이 다르다. 원시 파일 보존과 품질 검사 후 공개할 데이터의 경계를 구별한다. 조회 엔진을 통한 권한과 저장소 직접 접근의 권한도 실제 경로별로 점검해야 한다.

늦게 해석한다는 말을 형식 무관리로 바꾸지 않는다

파일을 받는 즉시 모든 분석 목적의 표로 변환해야 하는 것은 아니다. 원본을 보존하고 읽는 목적에 따라 해석할 수도 있다. 하지만 센서가 단위를 바꾸거나 필드 이름을 바꾸면, 어느 판본의 자료를 어떤 규칙으로 읽는지 알아야 같은 수치를 비교할 수 있다.

자체 운영 규칙으로 입수 구역, 검증 구역, 공개 구역을 나눌 수 있다. 구역의 수나 이름 자체가 데이터레이크의 필수 표준은 아니다. 중요한 것은 공개 전에 필수 필드·단위·중복·누락 처리 규칙을 검사하고, 미통과 자료를 정상 집계의 분모에 몰래 섞지 않는 것이다.

DBMS와의 접점에서는 저장 파일 목록뿐 아니라 표의 스키마와 판본, 조회 시점의 파일 집합을 확인한다. 객체저장을 선택했다는 사실만으로 SQL 처리·행 제약·여러 표의 트랜잭션까지 구현되지는 않는다. 이 절의 DBMS 기여는 그 저장 경계를 설명하는 데 한정한다.

4. 스냅숏은 독자가 읽을 파일 집합을 고정한다

표 스냅숏은 표의 한 확정 상태에서 읽어야 하는 파일 집합과 관련 정보를 식별한 판본이다. 매니페스트는 표 스냅숏을 구성하는 데이터 파일 등에 관한 항목과 메타데이터를 기록한 목록 파일이다. 여기의 스냅숏은 디스크 장치의 백업 이미지와 같은 뜻이 아니다. [DS6]

Iceberg의 설명에서는 표 메타데이터가 스냅숏을 가리키고, 스냅숏은 매니페스트 목록과 매니페스트를 통해 파일들을 식별한다. 실제 메타데이터 단계가 여러 개여도 학습의 핵심은 디렉터리의 모든 파일을 임의로 합치는 대신 어느 확정 판본에 속하는 파일인지 따라간다는 점이다. 이 절은 명시된 공통 원리만 다루며 모든 형식 버전의 세부 필드를 설명하지 않는다.

파일을 먼저 준비하고 판본 참조를 마지막에 공개한다

자체 예제의 판본 S0는 a0=100, b0=200을 가리킨다. 작성자는 이름이 다른 새 파일 a1=110, b1=220을 완성하고 두 파일을 가리키는 새 메타데이터 S1을 준비한다. 이후 현재 표 메타데이터 참조를 S0 기준에서 S1으로 바꾸는 커밋을 수행한다. 이미 S0를 선택한 독자는 읽기를 마칠 때까지 S0의 파일 집합을 유지한다.

파일을 완성한 뒤 새 판본 참조를 공개한다 · 상태 따라가기

R이 S0의 a0=100·b0=200을 읽으면 합계 300이다. 모든 단계에서 기존 읽기 R·공개 참조·새 읽기의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

실선은 판본이 가리키는 파일 집합 또는 공개 순서다. 커밋 전에 R은 S0의 a0·b0를 유지하고, 성공 뒤 새로 S1을 선택한 N은 a1·b1을 읽는다. 옛 파일 보존과 카탈로그 원자성·충돌 검사는 별도 조건이며 단순히 PUT 두 번을 뜻하지 않는다.

이 예의 조건

• 실선은 판본이 가리키는 파일 집합 또는 공개 순서다. 커밋 전에 R은 S0의 a0·b0를 유지하고, 성공 뒤 새로 S1을 선택한 N은 a1·b1을 읽는다. 옛 파일 보존과 카탈로그 원자성·충돌 검사는 별도 조건이며 단순히 PUT 두 번을 뜻하지 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상기존 판본 S0	원 설명a0=100, b0=200
대상기존 독자 R	원 설명선택한 S0를 유지
대상새 파일 완성	원 설명a1=110, b1=220
대상새 메타데이터 S1	원 설명두 새 파일 참조
대상기준 참조 S0 검증·커밋	원 설명원자적 참조 교체
대상새 독자 N	원 설명선택한 S1을 유지

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결기존 판본 S0 → 기존 독자 R	원 라벨·방향선택 / 정방향 / 실선
연결새 파일 완성 → 새 메타데이터 S1	원 라벨·방향참조 / 정방향 / 실선
연결새 메타데이터 S1 → 기준 참조 S0 검증·커밋	원 라벨·방향공개 준비 / 정방향 / 실선
연결기존 판본 S0 → 기준 참조 S0 검증·커밋	원 라벨·방향기준 비교 / 정방향 / 점선
연결기준 참조 S0 검증·커밋 → 새 독자 N	원 라벨·방향성공 뒤 선택 / 정방향 / 실선

원그림의 경계

경계	포함 대상
경계S0 · 300	포함 대상기존 판본 S0, 기존 독자 R
경계S1 · 330	포함 대상새 독자 N

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
S0 읽기 R이 S0의 a0=100·b0=200을 읽으면 합계 300이다.	값·보충 정보 기존 읽기 R: R→S0=300 공개 참조·새 읽기: 공개 S0	변화·이유 같은 판본의 두 값을 사용하며 R은 선택한 S0를 유지한다.
새 파일·S1 준비 a1=110·b1=220의 새 파일을 완성하고 두 참조를 가진 S1을 준비한다.	값·보충 정보 기존 읽기 R: R=300 유지 공개 참조·새 읽기: S1=330 공개 전	변화·이유 새 파일 하나만 공개하거나 두 번 PUT만으로 원자 공개를 주장하지 않는다.
기준 검증 뒤 원자 공개 정한 카탈로그 계약에서 기준 참조 S0를 검증한 뒤 공개 참조를 S1으로 원자적으로 교체한다.	값·보충 정보 기존 읽기 R: R→S0 유지 공개 참조·새 읽기: 기준 S0 검증·공개 S1	변화·이유 충돌 검사·카탈로그 원자성·옛 파일 보존은 이 전환의 조건이며 일반 CAS 가능을 추가하지 않는다.
새 읽기는 330 성공 뒤 S1을 새로 선택한 N은 330, 기존 R은 S0의 300을 읽는다.	값·보충 정보 기존 읽기 R: 기존 R=300 공개 참조·새 읽기: N→S1=330	변화·이유 공개 참조 교체가 이미 선택한 S0를 바꾸지 않으며 두 판본의 값을 섞지 않는다.

파일을 완성한 뒤 새 판본 참조를 공개한다 · 상태 따라가기

R이 S0의 a0=100·b0=200을 읽으면 합계 300이다. 모든 단계에서 기존 읽기 R·공개 참조·새 읽기의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

실선은 판본이 가리키는 파일 집합 또는 공개 순서다. 커밋 전에 R은 S0의 a0·b0를 유지하고, 성공 뒤 새로 S1을 선택한 N은 a1·b1을 읽는다. 옛 파일 보존과 카탈로그 원자성·충돌 검사는 별도 조건이며 단순히 PUT 두 번을 뜻하지 않는다.

이 예의 조건

• 실선은 판본이 가리키는 파일 집합 또는 공개 순서다. 커밋 전에 R은 S0의 a0·b0를 유지하고, 성공 뒤 새로 S1을 선택한 N은 a1·b1을 읽는다. 옛 파일 보존과 카탈로그 원자성·충돌 검사는 별도 조건이며 단순히 PUT 두 번을 뜻하지 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상기존 판본 S0	원 설명a0=100, b0=200
대상기존 독자 R	원 설명선택한 S0를 유지
대상새 파일 완성	원 설명a1=110, b1=220
대상새 메타데이터 S1	원 설명두 새 파일 참조
대상기준 참조 S0 검증·커밋	원 설명원자적 참조 교체
대상새 독자 N	원 설명선택한 S1을 유지

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결기존 판본 S0 → 기존 독자 R	원 라벨·방향선택 / 정방향 / 실선
연결새 파일 완성 → 새 메타데이터 S1	원 라벨·방향참조 / 정방향 / 실선
연결새 메타데이터 S1 → 기준 참조 S0 검증·커밋	원 라벨·방향공개 준비 / 정방향 / 실선
연결기존 판본 S0 → 기준 참조 S0 검증·커밋	원 라벨·방향기준 비교 / 정방향 / 점선
연결기준 참조 S0 검증·커밋 → 새 독자 N	원 라벨·방향성공 뒤 선택 / 정방향 / 실선

원그림의 경계

경계	포함 대상
경계S0 · 300	포함 대상기존 판본 S0, 기존 독자 R
경계S1 · 330	포함 대상새 독자 N

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
S0 읽기 R이 S0의 a0=100·b0=200을 읽으면 합계 300이다.	값·보충 정보 기존 읽기 R: R→S0=300 공개 참조·새 읽기: 공개 S0	변화·이유 같은 판본의 두 값을 사용하며 R은 선택한 S0를 유지한다.
새 파일·S1 준비 a1=110·b1=220의 새 파일을 완성하고 두 참조를 가진 S1을 준비한다.	값·보충 정보 기존 읽기 R: R=300 유지 공개 참조·새 읽기: S1=330 공개 전	변화·이유 새 파일 하나만 공개하거나 두 번 PUT만으로 원자 공개를 주장하지 않는다.
기준 검증 뒤 원자 공개 정한 카탈로그 계약에서 기준 참조 S0를 검증한 뒤 공개 참조를 S1으로 원자적으로 교체한다.	값·보충 정보 기존 읽기 R: R→S0 유지 공개 참조·새 읽기: 기준 S0 검증·공개 S1	변화·이유 충돌 검사·카탈로그 원자성·옛 파일 보존은 이 전환의 조건이며 일반 CAS 가능을 추가하지 않는다.
새 읽기는 330 성공 뒤 S1을 새로 선택한 N은 330, 기존 R은 S0의 300을 읽는다.	값·보충 정보 기존 읽기 R: 기존 R=300 공개 참조·새 읽기: N→S1=330	변화·이유 공개 참조 교체가 이미 선택한 S0를 바꾸지 않으며 두 판본의 값을 섞지 않는다.

표 참조를 원자적으로 교체하는 구체적 프로토콜은 카탈로그 구현에 의존한다. 일반 객체 두 개를 차례로 PUT한 일을 그대로 그 커밋으로 부르지 않는다. 이미 사용 중인 기준 참조가 바뀌었는지 검사하고 충돌을 알릴 수 있는 실제 카탈로그 계약이 필요하다. [DS6][DS7]

공개 전에 작성자가 멈추면 S0를 선택하는 독자는 이전 합계 300을 읽는다. 커밋이 성공하고 그 이후 S1을 선택한 독자는 새 합계 330을 읽는다. 참조를 바꾼 뒤 파일을 늦게 만들거나, 읽는 도중 서로 다른 스냅숏의 파일을 섞으면 이 조건이 깨진다.

읽기 중간에 커밋되는 변형. 독자 R은 S0를 선택하고 a0의 100을 읽은 뒤 잠시 멈췄다. 그사이 S1 커밋이 성공했다. R이 이어 읽을 파일과 합계는 무엇인가? R이 끝난 뒤 새로 S1을 선택한 독자 N의 합계와도 비교해 본다.

먼저 풀어 본 뒤 해설과 교정 보기

해설과 교정. R은 처음 선택한 S0의 파일 집합을 유지하므로 b0의 200을 읽어 300을 얻는다. N은 a1의 110과 b1의 220을 읽어 330을 얻는다. R이 현재 참조만 다시 보고 b1을 붙이면 100+220=320으로 어느 판본에도 없는 합계가 된다. 최신 파일을 하나씩 읽으면 정확하다는 오답은 객체별 최신성과 표 판본의 일치를 혼동한 것이다. 위 S0/S1 참조 그림으로 돌아가 먼저 판본 하나를 정한 뒤 그 판본의 두 파일 이름을 같이 적으면 고칠 수 있다. R이 읽는 동안 a0·b0가 남아 있어야 한다는 조건은 뒤의 옛 파일을 언제 지울 수 있는가에서 설명한다.

동시 작성자의 충돌을 마지막 파일 이름으로 숨기지 않는다

두 작성자가 모두 S0를 기준으로 서로 다른 새 판본을 준비할 수 있다. 첫 커밋이 성공한 뒤 둘째 작성자가 S0가 아직 현재 판본이라고 가정해 덮어쓰면 앞 작업의 결과를 잃을 위험이 있다. 기준 참조를 비교하는 커밋에서는 이런 충돌을 검출하고, 둘째 작성자가 새 현재 판본을 읽어 다시 판단한다. [DS7]

재시도는 오래된 결정을 무조건 다시 실행한다는 뜻이 아니다. 예를 들어 파일 병합 정리의 대상 파일이 여전히 유효한지, 다른 작성자가 이미 교체했는지를 확인해야 한다. 전제가 깨졌으면 다시 계획하거나 실패로 반환한다. 저장소에 파일이 존재한다는 사실만으로 그 파일이 현재 표에 속한다고 판단하지 않는다.

작은 파일을 합쳐도 판본 관리 책임은 남는다

파일 컴팩션은 여러 작은 데이터 파일을 더 적은 파일로 다시 작성하고 표의 파일 참조를 그 결과로 갱신하는 정리 작업이다. 이 작업의 목적은 이 문맥에서 파일 수에 따른 열기·목록·계획 부담을 줄이는 것이며, 손실 압축이나 무조건적인 저장 바이트 감소를 뜻하지 않는다. [DS8]

가령 각각 1 MiB인 파일 600개를 각각 100 MiB인 파일 6개로 합치면, 이 단순 가정의 데이터량은 여전히 600 MiB다. 파일 개수는 594개 줄지만 쿼리가 반드시 100배 빨라지는 것은 아니다. 읽는 범위, 파일 형식과 실행 엔진을 고정한 별도 측정이 필요하다.

옛 파일을 언제 지울 수 있는가

새 판본을 공개한 직후 옛 파일을 지우면 이전 스냅숏으로 읽던 독자의 조회를 실패하게 만들 수 있다. 스냅숏 보존 기간과 장시간 질의의 수명을 먼저 정하고, 더 이상 보존할 스냅숏이 참조하지 않는 파일을 정리해야 한다. 과거 스냅숏을 만료하면 그 판본을 이용한 과거 조회도 더 이상 가능하지 않을 수 있다. [DS8]

표에 아직 연결되지 않은 파일도 곧바로 쓰레기라고 단정할 수 없다. 진행 중인 작성자가 커밋 전에 만든 파일일 수 있기 때문이다. 고아 파일 정리의 경과시간 조건은 실제 최대 작성 시간과 실패·재시도 정책 등을 고려해 정하며, 목록에 잠시 안 연결되어 있다는 이유만으로 지우지 않는다.

따라서 유지관리 순서는 현재와 보존 스냅숏의 참조 확인, 진행 중 작업 보호, 정리 대상 확정, 삭제 결과 확인으로 설명한다. 이 순서는 자체 운영 판단 틀이며 제품별 삭제 명령과 보존 기본값을 대체하지 않는다.

5. 분산파일처리의 선택과 점검을 한 번에 연결한다

분산파일처리는 바이트의 분산 배치만이 아니라 이름 해석, 파일 집합 공개, 복구와 유지관리를 함께 설명해야 한다. 다만 각 보장은 실제 인터페이스·판본·설정의 경계 안에서만 인정한다. 자체 예제의 계산 성공이나 문서의 구조 그림을 실제 클러스터 시험 결과로 바꾸지 않는다.

자가 점검: 같은 성공이라는 말도 대상을 붙인다

다음 네 문장을 읽고 무엇까지 확인했는지 분리해 보자. “객체 한 개의 PUT 성공”은 여러 객체의 판본 공개와 다르다. “표 커밋 성공”도 원본 센서의 단위 정확성을 검사했다는 뜻은 아니다. “컴팩션 성공”은 이전 판본에 필요한 파일을 모두 삭제해도 된다는 허가가 아니다. “용량 계산 일치”는 복구 시간이나 비용 측정이 아니다.

자체 센서 배치에서 바이트 보호에는 복제 또는 삭제코딩을, 이름 담당 보호에는 메타데이터 고가용성을, 묶음 공개에는 스냅숏 커밋을 적용한다. 각 수단은 서로 다른 실패를 다루므로 하나의 제품 이름으로 네 문제를 모두 해결했다고 답하지 않는다.

10점 자체 문제

분산파일시스템과 객체저장의 책임을 구별하고, 강한 객체 읽기 일관성만으로 여러 파일의 원자적 공개가 보장되지 않는 이유를 설명하시오.

이 문항은 자체 제작이며 실제 기출이나 출제 빈도를 뜻하지 않는다. 본문의 가정 안에서 원리·경계·판정 근거를 연결한다. 답안은 학습용 작성 예이며 제한시간 필기 재현성의 사람 검증은 남아 있다.

객체 한 개와 묶음 공개의 풀이 보기

10점 답안 목차

1. 이름·메타데이터 경로와 바이트 경로
2. 인터페이스별 보장 확인
3. 서로 다른 키 사이의 중간 상태
4. 스냅숏 기반 공개와 조건

10점 답안 도식

이름은 NameNode에 묻고 바이트는 DataNode에서 읽는다 · 상태 따라가기

클라이언트는 NameNode에 자료 위치를 묻는다. 모든 단계에서 HDFS 클라이언트·이름·자료 역할의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

HDFS 클라이언트가 이름과 블록 위치를 NameNode에 확인한 뒤 사용 가능한 DataNode에서 블록 바이트를 읽는 경로다. 한 DataNode 표지는 해당 읽기에 사용할 사본을 대표하며 모든 사본을 뜻하지 않는다. 파일 묶음 판본의 공개는 앞의 스냅숏 그림에서 별도로 확인한다.

이 예의 조건

• HDFS 클라이언트가 이름과 블록 위치를 NameNode에 확인한 뒤 사용 가능한 DataNode에서 블록 바이트를 읽는 경로다. 한 DataNode 표지는 해당 읽기에 사용할 사본을 대표하며 모든 사본을 뜻하지 않는다. 파일 묶음 판본의 공개는 앞의 스냅숏 그림에서 별도로 확인한다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상읽는 클라이언트	원 설명이름 확인 뒤 바이트 읽기
대상NameNode	원 설명이름·블록 위치 전체 바이트의 중계자가 아님
대상DataNode	원 설명사용 가능한 블록 사본 실제 바이트 응답

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결읽는 클라이언트 → NameNode	원 라벨·방향이름 / 정방향 / 점선
연결NameNode → 읽는 클라이언트	원 라벨·방향위치 / 정방향 / 점선
연결읽는 클라이언트 → DataNode	원 라벨·방향읽기 / 정방향 / 실선
연결DataNode → 읽는 클라이언트	원 라벨·방향바이트 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
위치 요청 클라이언트는 NameNode에 자료 위치를 묻는다.	값·보충 정보 HDFS 클라이언트: 위치 질의 이름·자료 역할: NameNode 메타데이터	변화·이유 NameNode에서 자료 바이트를 읽는 경로가 아니다.
위치 응답 NameNode가 DataNode의 위치 정보를 돌려준다.	값·보충 정보 HDFS 클라이언트: 위치 정보 확보 이름·자료 역할: DataNode 대상 확인	변화·이유 메타데이터 응답과 바이트 수신을 구별한다.
바이트 읽기 클라이언트가 DataNode에서 실제 자료를 읽는다.	값·보충 정보 HDFS 클라이언트: DataNode 바이트 수신 이름·자료 역할: 자료 저장 역할	변화·이유 그림의 단순화 범위 밖 제품 세부를 추가하지 않는다.

이름은 NameNode에 묻고 바이트는 DataNode에서 읽는다 · 상태 따라가기

클라이언트는 NameNode에 자료 위치를 묻는다. 모든 단계에서 HDFS 클라이언트·이름·자료 역할의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

HDFS 클라이언트가 이름과 블록 위치를 NameNode에 확인한 뒤 사용 가능한 DataNode에서 블록 바이트를 읽는 경로다. 한 DataNode 표지는 해당 읽기에 사용할 사본을 대표하며 모든 사본을 뜻하지 않는다. 파일 묶음 판본의 공개는 앞의 스냅숏 그림에서 별도로 확인한다.

이 예의 조건

• HDFS 클라이언트가 이름과 블록 위치를 NameNode에 확인한 뒤 사용 가능한 DataNode에서 블록 바이트를 읽는 경로다. 한 DataNode 표지는 해당 읽기에 사용할 사본을 대표하며 모든 사본을 뜻하지 않는다. 파일 묶음 판본의 공개는 앞의 스냅숏 그림에서 별도로 확인한다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상읽는 클라이언트	원 설명이름 확인 뒤 바이트 읽기
대상NameNode	원 설명이름·블록 위치 전체 바이트의 중계자가 아님
대상DataNode	원 설명사용 가능한 블록 사본 실제 바이트 응답

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결읽는 클라이언트 → NameNode	원 라벨·방향이름 / 정방향 / 점선
연결NameNode → 읽는 클라이언트	원 라벨·방향위치 / 정방향 / 점선
연결읽는 클라이언트 → DataNode	원 라벨·방향읽기 / 정방향 / 실선
연결DataNode → 읽는 클라이언트	원 라벨·방향바이트 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
위치 요청 클라이언트는 NameNode에 자료 위치를 묻는다.	값·보충 정보 HDFS 클라이언트: 위치 질의 이름·자료 역할: NameNode 메타데이터	변화·이유 NameNode에서 자료 바이트를 읽는 경로가 아니다.
위치 응답 NameNode가 DataNode의 위치 정보를 돌려준다.	값·보충 정보 HDFS 클라이언트: 위치 정보 확보 이름·자료 역할: DataNode 대상 확인	변화·이유 메타데이터 응답과 바이트 수신을 구별한다.
바이트 읽기 클라이언트가 DataNode에서 실제 자료를 읽는다.	값·보충 정보 HDFS 클라이언트: DataNode 바이트 수신 이름·자료 역할: 자료 저장 역할	변화·이유 그림의 단순화 범위 밖 제품 세부를 추가하지 않는다.

점선은 이름·위치 메타데이터 요청/응답, 실선은 블록 바이트 읽기 경로다. 키 하나의 원자성 ≠ 파일 묶음의 원자성이다. 앞의 파일을 완성한 뒤 새 판본 참조를 공개한다 그림에서 새 파일 완성→새 판본 준비→원자적 공개→판본 유지 읽기를 함께 확인한다.

10점 답안 예시

분산 저장은 바이트의 배치와 이름·위치 관리를 함께 다룬다. HDFS의 NameNode는 메타데이터를 관리하고 실제 블록은 DataNode에서 읽고 쓰므로 두 경로를 구별한다.

파일 경로와 객체 키는 비슷해 보여도 지원 연산이 다를 수 있다. 필요한 생성·변경·조회 연산과 원자성 범위를 명시하고 해당 제품의 계약을 확인한다.

part-a를 100에서 110으로 바꾼 뒤 part-b가 아직 200이면 합계는 310이다. 이는 개별 객체의 강한 일관성과 양립하며, 두 키를 한 묶음으로 공개하는 경계가 없음을 보인다.

새 파일과 메타데이터를 먼저 완성하고 카탈로그의 원자적 커밋으로 새 판본을 공개한다. 독자는 선택한 스냅숏의 참조를 유지해야 하며, 단순한 두 PUT을 표 커밋으로 간주하지 않는다.

25점 자체 문제

600 MiB 센서 배치를 분산 저장하는 자체 사례에서 3중 복제와 6+3 삭제코딩의 이상적 공간을 계산하고, 메타데이터 장애·혼합 판본 읽기·작은 파일 정리의 대응 및 DBMS와의 경계를 제시하시오.

이 문항은 자체 제작이며 실제 기출이나 출제 빈도를 뜻하지 않는다. 본문의 가정 안에서 원리·경계·판정 근거를 연결한다. 답안은 학습용 작성 예이며 제한시간 필기 재현성의 사람 검증은 남아 있다.

센서 배치 설계의 계산·풀이 보기

25점 답안 목차

1. 공간 가정과 계산
2. 장애 영역과 복구 부담
3. 메타데이터 고가용성
4. 혼합 판본 방지
5. 동시 작성과 정리 전제
6. DBMS 기능의 경계

25점 답안 도식

앞의 층별 책임, HDFS 읽기 경로, 스냅숏 공개 그림을 연결해 답안을 작성한다. 각 확인은 다음 범위를 가진다.

확인 대상	계산·조건과 판정 범위
바이트 보호	600 MiB → 3중 복제 1800 MiB / 6+3 부호 900 MiB. 배치와 복구 비용을 별도로 확인한다.
메타데이터 고가용성	바이트 보호와 별도로 단독 쓰기·저널·복구·fencing 조건을 확인한다.
파일 묶음 읽기	새 파일→스냅숏 커밋→판본 고정 읽기. 개별 객체 쓰기 완료와 묶음 공개를 구별한다.
안전한 정리	보존 참조·진행 작업을 확인한 뒤 정리한다. 현재 판본의 미참조만으로 삭제하지 않는다.
분석·업무 사용	DBMS 기능·단위·품질·권한은 별도로 확인한다.

25점 답안 예시

완전한 100 MiB 데이터 조각 여섯 개이며 메타데이터와 임시 공간은 제외한다. 3중 복제는 1800 MiB, 6+3 삭제코딩은 900 MiB이므로 복제 대비 50% 감소하지만 이 값은 성능이나 복구 속도의 우열이 아니다.

삭제코딩의 허용 손실은 조각 수의 조건이다. 조각이 한 장애 영역에 몰리지 않게 배치를 확인하고, 복구 중 여러 조각 읽기와 계산에 필요한 자원을 별도로 검토한다.

데이터 복제와 이름 담당의 고가용성을 구별한다. QJM 기반 예에서는 변경 기록을 과반수에 지속 기록하고 Standby를 동기화하며, 동시에 쓰는 권한을 배타적으로 통제한다.

서로 다른 두 PUT 사이의 310을 새 배치 결과로 공개하지 않는다. 새 파일을 완성한 후 표 메타데이터 참조를 원자적으로 커밋하고, 독자는 S0의 300 또는 S1의 330에 해당하는 파일 집합을 유지한다.

커밋 충돌 뒤에는 현재 판본과 연산 전제를 다시 확인한다. 컴팩션으로 파일 수를 줄이더라도 보존 스냅숏과 진행 중 작업이 필요한 파일은 지우지 않는다.

저장 파일 집합의 판본과 스키마는 DBMS와 연결되는 지점이지만 객체저장 자체가 SQL 처리·행 제약·여러 표의 트랜잭션을 모두 구현하지는 않는다. 품질·단위·권한 검사도 별도 경로로 확인한다.

출처와 확인 범위

관찰 기준일은 2026-09-06이다. 아래는 명시된 HTML 본문 위치만 사용했으며 외부 도표를 복제하지 않았다. 버전 있는 문서는 그 판본으로 한정하고, 동적 문서는 보존 시점 바이트와 재검토일로 관리한다. 수치·식별자·상태 예는 저자가 만든 것이며 실제 제품 실행·성능·법적 이용권한 승인이 아니다.

[DS1] Apache Software Foundation. HDFS Architecture. Apache Hadoop 3.4.2. 위치: NameNode and DataNodes; Data Replication; Data Integrity; Replication Pipelining 원문: https://hadoop.apache.org/docs/r3.4.2/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html

[DS2] Apache Software Foundation. HDFS High Availability Using the Quorum Journal Manager. Apache Hadoop 3.4.2. 위치: Architecture; Hardware resources; Fencing configuration 원문: https://hadoop.apache.org/docs/r3.4.2/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html

[DS3] Apache Software Foundation. HDFS Erasure Coding. Apache Hadoop 3.4.2. 위치: Background; Architecture; Cluster and hardware configuration; Limitations 원문: https://hadoop.apache.org/docs/r3.4.2/hadoop-project-dist/hadoop-hdfs/HDFSErasureCoding.html

[DS4] Amazon Web Services. What is Amazon S3?. Named HTML passages observed 2026-09-06; not a claim about the latest release. 위치: Objects; Keys; Amazon S3 data consistency model: single-key atomicity and cross-key limitation 원문: https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html

[DS5] Amazon Web Services. What is AWS Lake Formation?. Named HTML passages observed 2026-09-06; not a claim about the latest release. 위치: Opening definition; data catalog and permissions roles 원문: https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html

[DS6] Apache Software Foundation. Apache Iceberg Table Specification. Named HTML passages observed 2026-09-06; not a claim about the latest release. 위치: Snapshots; Manifests; Table Metadata opening paragraphs; Table Metadata Fields: snapshots; v1/v2 common mechanism only 원문: https://iceberg.apache.org/spec/

[DS7] Apache Software Foundation. Reliability. HTML documentation labelled 1.11.0, observed 2026-09-06. 위치: Concurrent write operations; Retry validation; snapshot reads. The opening historical claim that S3 is eventually consistent is NOT used as current evidence. 원문: https://iceberg.apache.org/docs/latest/reliability/

[DS8] Apache Software Foundation. Maintenance. HTML documentation labelled 1.11.0, observed 2026-09-06. 위치: Expire Snapshots; Delete orphan files; Compact data files 원문: https://iceberg.apache.org/docs/latest/maintenance/

30초 정리

분산 저장에서는 바이트 보호, 이름·위치 관리, 확정 파일 집합 공개를 구별한다. HDFS의 역할 분담과 객체 키의 연산 계약을 확인하고, 강한 객체 일관성을 여러 파일의 원자성으로 확대하지 않는다. 레이크의 카탈로그·품질·권한과 스냅숏 유지관리까지 연결하되 각 보장은 명시한 제품·판본·가정 안에서만 인정한다.