All
8.1 스키마 관리가 필요한 이유
•
데이터 웨어하우스는 정형화된 스키마 정의가 필수
•
소스의 스키마가 변경되면 수집이나 적재가 중단되고 웨어하우스 구조 수정이 필요 → 웨어하우스는 스키마 변경하느라 몇시간씩 걸리기도함
◦
대기업에서는 스키마 업데이트 작업 계획해 스키마 변경 요청 프로세스에 따라 진행
◦
스타트업 등 소규모 조직에서는 내버려두다가 문제 생길때 조치 취하는 형식
◦
→ 보통 사용자들이 문제를 인지하고 보고하기 때문에 사용자 불만이 큼
•
어떤 스키마 변경 처리 작업도 상당한 수작업을 동반
8.1.1 기존 데이터 웨어하우스 아키텍처의 스키마 변경
•
단일 파일 기반 데이터 소스를 사용하는 데이터 웨어하우스의 경우:
◦
소스 파일 → 랜딩 테이블에 데이터 적재
◦
스키마 불일치 시 적재 실패하고 랜딩 테이블 수정 필수
◦
수집 중단 → 수정 → 프로세스 재개를 반복하게 됨
8.1.2 스키마 온 리드 방식(Schema-on-read)
•
하둡의 등장과 함께 도입된 개념
•
파일 시스템은 파일 내부 구조에 신경쓰지 않기 때문에 수집 프로세스가 업스트림 스키마 변경에 회복력을 가지고 있음
•
파일 시스템에서는 데이터를 적재할때가 아닌 처리하기 시작할때 스키마가 필요하기 때문
•
이 방식은 스키마 관리 문제를 수집 단계에서 변환단계로 한단계 내려보내지만, 결국 데이터 처리를 위해서는 최신 스키마가 필요
8.2 스키마 관리 방식
•
앞선 7장에서 알아봤듯이 메타데이터 계층은 스키마 변경관리를 도와주는 역할로 메타데이터 계층 중 하나가 스키마 레지스트리
•
스키마 레지스트리는 스키마 저장소로 데이터 소스별 전체 스키마의 모든 버전 포함
•
스키마 변경문제를 사전에 대비하는 두가지 방안
◦
스키마를 계약으로 다루거나
◦
플랫폼에서 스키마 관리를 수행
8.2.1 스키마를 계약(Contract)으로 다루기
•
애플리케이션 개발자가 애플리케이션에서 생성하는 데이터의 스키마 관리를 책임지도록 함
•
스키마는 데이터 생성자와 소비자 간 계약으로 간주
•
중앙 저장소에 모든 스키마를 저장하고 데이터 소비자는 최신 스키마 버전을 가져와 사용
•
자동화된 호환성 검사와 보호 로직 필요
전제조건
•
높은 수준의 개발 프로세스 성숙도
◦
스키마 변경 사항마다 상호호환성 확인을 개발자가 수행
•
서드파티 데이터 소스의 데이터 소유자가 누구인지 명확해야함
◦
SaaS 서비스는 관리 통제권이 사용자에게 있지 않기때문에 스키마 변경에 대한 책임을 개발자가 담당하는 것이 어려움
8.2.2 데이터 플랫폼의 스키마 관리
•
데이터 플랫폼은 내부 데이터 소스와 서드파티 데이터 소스의 통합지점이므로 스키마를 중앙에서 관리하기 용이함
•
스키마 변경시 호환성 문제 있을경우 데이터 변환 파이프라인이 가장 먼저 감지
장점
•
회복력있는 ETL 구현
•
최신화된 스키마 카탈로그 유지
•
스키마 변경 이력으로 파이프라인 디버깅과 트러블슈팅 용이
스키마 관리 모듈
•
공통 데이터 변환 파이프라인에 스키마 관리 모듈 추가해 스키마 관리
•
스키마가 레지스트리에 없는 경우
1.
수신 데이터에서 스키마 추론 → 스키마 버전 1로 등록
•
스키마가 레지스트리에 있는 경우
1.
레지스트리로부터 현재 버전 스키마 가져옴
2.
수신 데이터로부터 추론한 스키마와 비교
3.
호환성 판단 후 신규 스키마 버전 레지스트리에 게시
8.2.3 스키마 변경 모니터링
•
자동화가 되어있어도 논리 오류까지 감지할 순 없음
•
예시
◦
컬럼명이 바뀌었을때 자동으로 디폴트 0 값 넣는 파이프라인 (today_amount → today_total 로 변경)
◦
today_amount 으로 총 판매액을 계산하고 있다면 판매액이 0으로 표기됨
◦
이와 같은 사항은 수작업으로 처리해야함
◦
스키마 변경 이벤트에 대한 모니터링과 알람 시스템이 필요한 이유
8.3 스키마 레지스트리 구현
다양한 데이터 소스로부터 온 데이터를 처리하려면 스키마에 속성명, 데이터 타입, 디폴트 값 정의 필요
8.3.1 아파치 아브로 스키마
•
자체 스키마로 데이터 표현
•
기본 데이터 타입(strings, integers, floats, null 등)부터 복잡한 데이터 타입(records, arrays, enums 등) 지원
•
관계형 DB부터 복잡한 JSON까지 모든 데이터 표현 가능
•
사람이 쉽게 읽을 수 있어 수작업으로 정의 가능
•
스키마 진화를 지원하여 변경 이력 추적 가능
•
JSON 형식으로 저장되어 JSON 지원 데이터베이스라면 어디든 저장 가능
8.3.2 스키마 레지스트리 솔루션
데이터 카탈로그(AWS Glue, GCP, Azure)
•
스키마 저장은 가능하지만 버전관리, 검색, 게시 기능이 제한적
•
각 클라우드의 고유 스키마 표현 방식으로 변환 필요
컨플루언트 스키마 레지스트리
•
대부분의 기능 제공 (버전관리, Avro 지원, API 지원)
•
스키마 진화 규칙 지원으로 기존 파이프라인 보호
•
컨플루언트 커뮤니티 라이선스로 배포(일반적인 오픈소스 라이선스와 다름)
8.3.3 메타데이터 계층의 스키마 레지스트리
API 레이어를 통해 데이터 플랫폼 내 파이프라인, 외부 팀과 툴에서 사용 가능
다양한 툴들과 스키마 레지스트리 간 상호작용하는 방식
스키마 레지스트리 주요 기능
•
데이터 소스의 현재 스키마 버전 확인
•
신규 스키마 생성 및 기존 데이터 소스에 새 버전 추가
스키마 레지스트리에 저장할 속성
•
ID - 스키마의 식별자 (동일 스키마 여러 버전이 있을 수 있으므로 고유값 아님)
•
버전 - 스키마 버전, ID와 함께 사용해 고유 키 형성
•
스키마 - 아브로 스키마 정의를 저장하는 텍스트 속성
•
created_at, updated_at
8.4 스키마 진화 시나리오
스키마 변경의 일반적인 예
•
신규 컬럼 추가
•
기존 컬럼 삭제
•
컬럼명 변경
•
컬럼 타입 변경
스키마 변경의 두가지 유형
•
이전 버전 호환성 유지형: 최신 버전으로 이전 데이터 읽기 가능
•
이후 버전 호환성 유지형: 이전 버전으로 이후 데이터 처리 가능
8.4.1 스키마 호환성 규칙
컬럼 추가 & 삭제
•
신규 컬럼 추가 시 Avro는 디폴트 값을 자동 적용
•
이후 버전 호환성시 신규 컬럼 무시 가능
◦
파이프라인이 바로 v2로 전환하지 않고 v1 스키마로 처리하면 신규 컬럼을 무시하고 없는 것처럼 데이터를 계속 읽음
→ 아브로의 호환성 기능은 이런식으로 스키마 변경에 유연하게 대응이 가능
컬럼명 변경
•
신규 컬럼 추가 및 기존 컬럼 삭제 방식으로 처리
•
호환성은 컬럼 추가 & 삭제와 동일
•
디폴트 값 있으면 이전/후 버전 모두 호환가능, 디폴트값 없으면 모두 호환 불가
컬럼 타입변경
•
아브로는 특정 데이터 타입을 호환 가능한 다른 데이터 타입으로 “승격”하도록 지원
•
손실되지 않는 방향으로 승격 가능
◦
long > int 64비트에서 32비트이므로 불가
◦
int > long 가능
8.4.2 스키마 진화와 데이터 변환 파이프라인
공통 데이터 변환 파이프라인
•
특정 컬럼이나 특정 타입을 필요로 하지 않아 스키마 변경에 강한 회복력유지
비즈니스 로직 변환 파이프라인
•
특정 컬럼에 종속되어 있어 컬럼 삭제 또는 변경 시 오류 발생 가능
•
디폴트 값으로 일부 회피 가능하지만 완벽하지 않음
•
예시 - col1 고유값 기준으로 col2의 합계를 계산하는 파이프라인이 있을 때:
◦
스키마가 v2로 변경되면서 col3가 새로 추가되고 col2가 삭제된 경우, 새로운 데이터는 더 이상 col2 값을 포함하지 않으므로 기존 파이프라인이 오류 발생.
◦
만약 col2에 디폴트 값이 있다면, 누락된 컬럼 대신 디폴트 값을 이용하여 파이프라인이 계속 동작.
◦
그러나 디폴트 값이 없으면, 파이프라인은 스키마 v1을 기준으로 동작하기 때문에, 새 데이터에서 col2 컬럼을 찾지 못해 장애가 발생.
스키마 변경 유형별 호환성 정리
스키마 변경 | 이전 버전 호환성 유지 | 이후 버전 호환성 유지 | 변환에 대한 안전성 여부 |
디폴트 값이 있는 컬럼 추가 | 예 | 예 | 예 |
디폴트 값이 없는 컬럼 추가 | 아니요 | 예 | 예 |
디폴트 값이 있는 컬럼 삭제 | 예 | 예 | 예. 이전 버전 사용시 |
디폴트 값이 없는 컬럼 삭제 | 예 | 아니요 | 아니요 |
디폴트 값이 있는 컬럼면 변경 | 예 | 예 | 예. 이전 버전 사용시 |
디폴트 값이 없는 컬럼명 변경 | 아니요 | 아니요 | 아니요 |
컬럼 타입 변경 | 때때로 | 때때로 | 때때로 |
이처럼 스키마 변경에 회복력있는 파이프라인을 유지할 순 있지만, 비즈니스 로직 계산에 논리적 오류까지 없애주진 못하므로 알람 설정이 중요.
신속하게 파이프라인 검토해 변경 작업 진행해야함
8.5 스키마 진화와 데이터 웨어하우스
•
테이블은 스키마를 반드시 사전 정의해야하고 여러 버전의 스키마가 있을 수 없음
•
스키마 변경시 테이블 스키마 수정이 필수
•
테이블 스키마는 변경사항 모두 누적해야하며 되돌릴 수 없는 변경사항은 적용하면 안됨
◦
컬럼 삭제나 컬럼 명 변경시 똑같이 삭제 처리하면 안됨
•
외부 스키마 레지스트리와 통합 불가
테이블 스키마 최신으로 유지 자동화
•
스키마 레지스트리에 버전별 스키마 이용해 데이터 웨어하우스 테이블 정의를 업데이트할 SQL문 자동 생성
•
아브로 데이터 타입을 데이터 웨어하우스에 매핑하는 사용자 정의 개발 필요
테이블이 작은 경우 변경보다 기존 테이블 삭제하고 신규 스키마로 신규 테이블 생성해 마이그레이션하는게 더 빠를 수 있음
8.5.1 클라우드 데이터 웨어하우스의 스키마 관리 기능
AWS 레드시프트 - postgreSQL RDBMS 기반
•
테이블 스키마 미리 정의 필요
•
ALTER TABLE 명령으로 테이블 수정기능 제공
◦
테이블 락 때문에 읽기/쓰기 쿼리 불가능
◦
데이터 소비자는 스키마 변경이 끝날때까지 기다려야 함
•
컬럼 기반 데이터베이스로 컬럼 추가 삭제는 빠른편
•
컬럼 타입 변경하면 데이터 변환 필요
GCP 빅쿼리
•
특정 포맷(Avro, Parquet, JSON) 자동 스키마 추론
•
신규 컬럼 추가만 지원 - 기존 파일의 스키마 기반으로 자동으로 수행
•
ALTER TABLE SQL 지원하지 않아 컬럼명 변경, 삭제, 컬럼 타입 변경 불가능
•
신규 테이블을 신규 스키마로 만들어서 마이그레이션 하는 방법이 있지만 큰 테이블의 경우 읽기 비용 많이 나옴