AI 기초
데이터 웨어하우스란? 아키텍처, ETL 및 사용 사례
Unite.AI를 Google의 선호 소스에 추가
데이터 웨어하우스는 운영 소스에서 정보를 통합하고 이를 보고, 비즈니스 인텔리전스 및 반복 가능한 분석을 위해 정리하는 분석 데이터 시스템입니다. 트랜잭션을 기록하는 애플리케이션과는 별도로 많은 분석 워크로드를 분리합니다.
현대의 웨어하우스는 컬럼형, 분산형, 서버리스형이거나 객체 스토리지에 연결될 수 있습니다. 핵심 작업은 일관됩니다: 관리된 인제스트, 모델링된 의미, 히스토리, 쿼리 성능, 보안, 품질 및 사용자에게 신뢰할 수 있는 전달.
핵심 요약
- 운영 시스템은 현재 트랜잭션을 최적화하고, 웨어하우스는 소스 전반에 걸친 과거 분석을 최적화합니다.
- ETL은 로드하기 전에 변환하고, ELT는 먼저 로드한 뒤 분석 플랫폼 내에서 변환합니다.
- 차원 모델, 정규화 모델, 와이드 테이블 모델은 각각 다른 워크로드와 거버넌스 요구를 충족합니다.
- 신뢰는 데이터 라인리지, 테스트, 최신성, 접근 제어, 의미 정의 및 비용 모니터링에 달려 있습니다.
소스, 인제스트 및 저장
데이터는 배치, 변경 데이터 캡처, 스트림, 파일 및 API를 통해 도착할 수 있습니다. 착수 레이어는 소스 컨텍스트를 보존하고, 변환은 유형을 표준화하며, 레코드를 중복 제거하고, 늦게 발생한 이벤트를 처리하고, 재사용 가능한 분석 엔터티를 생성합니다.
이는 ETL 워크플로를 확장합니다. ELT는 웨어하우스 컴퓨팅을 활용해 변환을 수행하고, ETL은 로드하기 전에 데이터를 축소하거나 검증할 수 있습니다. 올바른 선택은 지연 시간, 프라이버시, 규모 및 도구 체인에 따라 달라집니다.
질문을 위한 데이터 모델링
차원 모델은 고객, 제품, 시간과 같은 서술적 차원을 중심으로 측정 가능한 사실을 조직합니다. 정규화된 핵심 모델은 기업 관계를 보존할 수 있으며, 비정규화된 마트는 일반적인 쿼리를 단순화합니다.
시맨틱 레이어는 메트릭에 일관된 정의를 제공합니다. 이를 없애면 팀은 동일한 행에서 여러 개의 타당해 보이는 매출 또는 유지율 수치를 만들 수 있습니다. Structured data도 여전히 합의된 의미가 필요합니다.
웨어하우스, 레이크, 그리고 레이크하우스
데이터 레이크는 일반적으로 파일과 다양한 원시 또는 처리된 데이터를 객체 스토리지에 저장합니다. 웨어하우스는 관리되는 분석 테이블과 쿼리 서비스를 제공합니다. 레이크하우스 설계는 레이크 스토리지에 테이블 메타데이터, 트랜잭션 및 거버넌스를 추가합니다.
이들은 보증이 아닌 아키텍처 패턴입니다. 조직은 종종 data fabric이나 공유 거버넌스 레이어를 통해 이를 결합합니다. 워크로드, 기술 역량, 상호 운용성 및 라이프사이클 비용이 라벨보다 더 중요합니다.
품질, 보안 및 운영
소유자, 계약, 최신성 목표, 라인리지, 테스트, 보존 및 행 또는 열 접근 권한을 정의합니다. 개인 식별 데이터를 분리하고 최소 권한 원칙을 적용하며 민감한 쿼리를 감사합니다. 백필 및 스키마 변경은 통제되고 관찰 가능한 절차가 필요합니다.
성공적인 새로 고침, 데이터 지연, 테스트 실패, 쿼리 성능, 채택률, 사고 영향 및 워크로드당 비용을 측정합니다. 사용자가 메트릭을 관리된 데이터와 연결하고 결과를 재현할 수 있을 때 웨어하우스는 유용합니다.
차원 모델링 및 시맨틱
사실 테이블은 선언된 그레인(예: 주문 라인 하나 또는 시간당 디바이스 하나)에서 이벤트 또는 주기적인 측정을 기록합니다. 차원은 서술적 컨텍스트를 제공합니다. 컬럼을 선택하기 전에 그레인을 선언하면 이중 계산을 일으키는 레벨 혼합을 방지합니다. 가산 측정값은 모든 차원에서 합산할 수 있지만, 반가산 측정값은 시간에 따라 주의가 필요합니다.
대리 키는 웨어하우스 히스토리를 변화하는 소스 식별자와 분리합니다. 천천히 변하는 차원은 속성 변경을 어떻게 처리할지 정의합니다: 덮어쓰기, 새로운 히스토리 행 보존, 또는 제한된 이전 값 유지. 올바른 방법은 분석 질문과 보존 의무에 따릅니다.
시맨틱 메트릭은 공식, 필터, 시간 동작, 통화, 제외 항목, 소유자 및 테스트를 정의해야 합니다. 중앙 정의는 일관성 부족을 줄이지만, 거버넌스는 제안된 변경 및 버전 관리를 허용해야 합니다. 사용자가 책임 있게 검토하거나 확장할 수 없을 경우 단일 시맨틱 레이어는 병목이 됩니다.
현대 스토리지 및 쿼리 아키텍처
컬럼형 스토리지는 같은 컬럼의 값을 함께 저장해 압축 효율을 높이고 필요한 필드만 스캔합니다. 파티셔닝은 날짜나 다른 키를 기준으로 큰 구역을 정리하고, 클러스터링은 관련 값을 함께 배치합니다. 물리화된 뷰와 캐시는 결과를 재사용합니다. 부적절한 파티션 선택은 작은 파일, 스키와, 혹은 비용이 많이 드는 전체 스캔을 초래합니다.
대규모 병렬 쿼리 엔진은 스캔, 조인 및 집계를 워커에 분산합니다. 조인 중 데이터 이동은 실행 시간을 좌우할 수 있어 배포, 통계 및 조인 순서가 중요합니다. 자동 확장 및 서버리스 서비스는 용량 관리를 단순화하지만 비용 제어, 워크로드 우선순위 및 과도한 쿼리 제한이 필요합니다.
레이크하우스 테이블 포맷은 객체 파일 위에 메타데이터, 스냅샷, 스키마 진화 및 트랜잭션 의미를 추가합니다. 이는 상호 운용성을 향상시키지만 카탈로그와 유지 관리 책임을 부여합니다. 오픈 포맷은 실제로 컴퓨팅 엔진, 거버넌스 및 운영 절차가 활용할 때만 락인 방지에 도움이 됩니다.
신뢰할 수 있는 파이프라인 및 데이터 제품
파이프라인은 멱등성을 유지하거나 중복을 조정할 수 있어야 합니다. 워터마크와 이벤트 타임은 늦게 도착한 데이터를 처리하고, 백필은 과거 변환을 재현합니다; 스키마 계약은 호환 가능한 변경을 정의합니다. 데이터 테스트는 유일성, 완전성, 허용값, 관계 및 비즈니스 불변성을 검증하며, 작업 실행 여부만을 확인하지 않습니다.
중요한 데이터셋을 소유자, 문서, 서비스 기대치, 검색 가능성, 지원 및 사용자와 함께 제품으로 취급합니다. 라인리지는 소스 필드를 변환을 거쳐 보고서와 연결해 변경 영향 및 사고 조사 속도를 높입니다. 데이터 복제 시 접근 정책은 전파되거나 재평가되어야 합니다.
웨어하우스 프로그램은 저장 용량이 늘어나는 것이 아니라 의사결정이 더 신뢰성 있고 빠르게 이루어질 때 성공합니다. 사용되지 않는 테이블을 폐기하고, 쿼리 및 스토리지 비용을 공개하며, 민감한 접근을 검토하고, 팀이 관리된 메트릭을 신뢰하고 재사용하는지를 측정해야 합니다. 개인 스프레드시트를 유지하는 대신에.
실제 예시: 판매 분석 웨어하우스 설계
사실 그레인을 하나의 완료된 주문 라인으로 정의하고, 대리 키를 통해 제품, 고객, 채널, 프로모션, 지리 및 날짜 차원을 연결합니다. 주문 상태 이벤트는 스냅샷과 트랜잭션을 혼합하지 않고 별도의 사실 테이블에 보관합니다. 매출, 수량, 할인, 세금 및 비용은 명시적인 통화, 반환, 취소 및 인식 규칙이 필요합니다. 메트릭 정의는 대시보드, 노트북 및 재무 조정에서 동일한 답을 도출해야 합니다.
인제스트는 소스 변경을 포착하고, 불변의 원시 데이터를 적재하며, 스키마를 검증하고, 이를 테스트된 스테이징 및 차원 모델로 변환합니다. 늦게 도착한 업데이트는 사실을 중복하지 않으면서 적절한 히스토리 기간을 수정해야 합니다. 행 수와 금액 합계를 소스 시스템과 비교하고, 유일성 및 관계를 테스트하며, 보고서 필드에서 소스로의 라인리지를 기록합니다. 백필은 신뢰받는 테이블을 교체하기 전에 버전 관리된 코드와 격리된 검증을 사용합니다.
접근 권한은 고객 식별자를 광범위하게 사용 가능한 집계와 분리하고 역할 및 목적에 따라 최소 권한 원칙을 적용합니다. 워크로드 관리는 임원 대시보드의 응답성을 유지하면서 분석가는 탐색적 쿼리를 실행할 수 있게 합니다. 최신성, 실패한 테스트, 쿼리 비용, 사용되지 않은 테이블 및 시맨틱 변화를 모니터링합니다. 웨어하우스는 관리된 메트릭이 반복 가능한 의사결정을 지원할 때 성공하며, 소유권, 품질 및 정의가 해결되지 않으면 데이터를 중앙화하는 것만으로 혼란을 중앙화할 수 있습니다.
재해 복구는 백업 범위, 지역 간 복제, 카탈로그 및 권한 복원, 허용 가능한 데이터 손실 및 복구 시간을 명시해야 합니다. 격리된 환경에서 복원을 테스트하고 파일뿐 아니라 메트릭을 검증합니다. 암호화 키, 신원 구성, 오케스트레이션 코드 및 시맨틱 정의는 복구 가능한 시스템의 일부입니다. 페타바이트를 복원할 수 있지만 접근 정책이나 신뢰된 계산을 재현하지 못하는 웨어하우스는 분석 서비스를 복구하지 못한 것입니다.
실용적인 구현 체크리스트
개념을 제한되고 테스트 가능한 워크플로우로 전환합니다: source → ingest → transform → model → serve → govern. 책임자를 지정하고, 데이터와 종속성을 문서화하며, 간단한 기준선을 설정하고, 수용 및 중단 기준을 정하고, 대표적인 실패를 테스트하며, 범위를 확대하기 전에 모니터링, 롤백 및 검토를 정의합니다. 버전과 가정을 기록해 다른 팀이 결과를 재현하고 변경 사항을 이해할 수 있게 합니다.
출시 전에는 시스템을 구축, 운영, 보안 및 영향을 받는 사람들과 함께 문서화된 준비 검토를 수행합니다. 정상 사례, 경계 조건, 종속성 실패 및 오용을 테스트하고 증거와 미해결 위험을 보존합니다. 릴리스를 승인하거나 임계값을 변경하거나 출력을 무시하거나 운영을 중단할 수 있는 사람을 정의합니다. 실제 데이터가 도착한 후 결정을 재검토해야 합니다. 기술적으로 성공적인 파일럿이더라도 더 큰 규모에서 신뢰할 수 있는 성능을 보장하지 않기 때문입니다.
- 파이프라인: batch, streaming, ETL, and ELT.
- 모델: facts, dimensions, and semantic metrics.
- 신뢰: quality, lineage, security, and freshness.
자주 묻는 질문
데이터 웨어하우스는 단순히 대형 데이터베이스인가요?
이는 통합된 과거 분석을 중심으로 설계된 데이터베이스 또는 분석 플랫폼입니다. 그 모델링, 인제스트, 거버넌스 및 워크로드 패턴은 트랜잭션 애플리케이션 데이터베이스와 다릅니다.
기업은 ETL과 ELT 중 어느 것을 사용해야 할까요?
많은 기업이 두 방식을 모두 사용합니다. 프라이버시, 검증 또는 대역폭이 필요할 때는 초기에 변환하고, 웨어하우스 컴퓨팅과 빠른 반복이 유리할 때는 로드 후에 변환합니다.
주요 참고 자료
