[견고한 데이터 엔지니어링] 8장. 쿼리 모델링 및 데이터 변환 | LIM

이번 장에서 살펴볼 수 있는 것

• 쿼리와 그 기반이 되는 중요한 패턴
• 데이터에 비즈니스 로직을 도입하는데 사용할 수 있는 주요 데이터 모델링 패턴
• 데이터 모델의 로직과 쿼리 결과를 채택해 더 간단한 다운스트림 사용에 유용하게 만드는 변환

 

쿼리

쿼리 수명은 다음과 같다. 

• SQL 쿼리 명령어 수행
• 파싱 및 바이트코드로 전환
• 쿼리 플래닝과 최적화
• 쿼리 실행
• 결과 반환

쿼리 옵티마이저의 역할은 쿼리를 효율적인 순서로 적절한 단계로 분할해 쿼리의 성능을 최적화하고 비용을 최소화한다. 

 

🤔 쿼리 성능을 향상 시키는 방법에는 어떤 것들이 있을까?

1. 데이터를 선조인(prejoin)하는 것

-> 분석 쿼리가 동일한 데이터를 반복해 조인하는 경우, 계산 부하가 높은 작업을 반복하지 않도록 사전에 데이터를 조인하고 선조인된 데이터 버전에서 쿼리를 읽는 것이 좋다. 

2. 중첩된 서브쿼리 또는 임시 테이블 대신 공통 테이블 표현식(CTE)을 사용

 

EXPLAIN 명령어를 사용해 쿼리가 실행되는 방식을 파악하고, 쿼리 성능을 모니터링해 데이터베이스 자원 사용량에 대한 측정 지표를 확인해야 한다. 모니터링이 필요한 영역은 다음과 같다.

• 디스크, 메모리, 네트워크 등의 주요 리소스 사용량
• 데이터 로딩 시간과 처리 시간 비교
• 쿼리 실행시간, 레코드 수, 스캔한 데이터의 크기, 데이터 셔플링에 사용된 데이터양
• 데이터베이스에서 리소스 경합을 일으킬 수 있는 경쟁 쿼리
• 사용 가능한 연결 수 대비 사용된 동시 연결 수

 

데이터베이스가 커밋을 처리하는 방법 파악

데이터베이스에서 커밋은 레코드, 테이블 또는 기타 데이터베이스 객체의 생성, 갱신 또는 삭제와 같은 데이터베이스 내의 변경 작업을 의미하고, 많은 데이터베이스가 일관된 상태를 유지하는 방식으로 여러 작업을 동시에 커밋하는 개념인 트랜잭션을 지원한다.

 

📌 현재 내가 사용하고 있는 빅쿼리의 경우

빅쿼리는 특정 시점의 풀 테이블 커밋 모델 사용

• 읽기 쿼리가 실행되면 빅쿼리는 테이블의 최신 커밋된 스냅숏에서 읽는다. 즉, 쿼리가 1초 동안 실행되는 2시간 동안 실행되는 상관없이 해당 스냅숏에서 읽기만 하고 이후 변경 사항은 표시되지 않는다.
• 빅쿼리에서 읽기를 수행하는 동안 테이블 락은 발생하지 않는다. 대신, 후속 쓰기 작업을 수행하면 쿼리가 시작된 스냅숏에서 쿼리가 계속 실행되는 동안 새로운 커밋과 스냅숏이 생성된다.
• 따라서, 빅쿼리는 일관되지 않는 상태를 방지하기 위해 한 번에 하나의 쓰기 작업만 허용한다. (즉, 빅쿼리는 쓰기 동시성을 전혀 제공하지 않는다.)

 

*몽고디비의 경우

• 가변적 일관성 데이터베이스라고 부른다.
• 몽고 DB는 뛰어난 확장성과 쓰기 동시성으로 유명하지만, 엔지니어가 이를 남용할 때 발생하는 문제로 악명이 높다.
• 매우 높은 쓰기 성능을 지원하지만, 이 때 과부하가 일어나면 무의식적으로 쓰기를 폐기한다.
  • 단순히 많은 측정값을 원하지만 모든 측정값을 캡처하는데 신경쓰지 않는 IoT 애플리케이션에 매우 적합
  • 정확한 데이터와 통계를 캡쳐해야 하는 애플리케이션에는 적합하지 않다.

 

스트리밍 데이터에 대한 쿼리

스트리밍 데이터에 대해서는 카파 아키텍처를 빼놓을 수 없는데 카파 아키텍처의 큰 아이디어는 스트리밍 스토리지를 실시간 전송 계층이자 과거 데이터를 검색하고 쿼리하는 데이터베이스로 취급하는 것이다.

 

윈도는 스트리밍 쿼리 및 처리에서 필수적인 기능이다. 윈도는 동적 트리거를 기반으로 처리되는 작은 배치다.

 

[세션 윈도]

근접하게 발생한 이벤트를 그룹화하고, 이벤트가 발생하지 않을 때 비활성 기간을 필터링한다. 예를 들어 5분간 활동이 없는 상태에서 공백이 발생하면 시스템은 윈도를 닫고 계산을 전송한 다음 데이터를 플러시한다. 새로운 이벤트가 도착하면 시스템은 세션 윈도를 기동한다. 

 

 

[고정 시간 윈도(tumbling)]

고정된 일정에 따라 실행되는 고정 기간이 특징으로, 이전 창이 닫힌 이후의 모든 데이터를 처리한다. 예를 들어 20초마다 윈도를 닫고 이전 윈도에서 도착하는 모든 데이터를 처리해 평균값 및 중앙값 통계를 제공할 수 있다. 이는 데이터 갱신 작업을 매일 또는 매시간 실행하는 기존 배치 ETL 처리와 유사하다. 

 

[슬라이딩 윈도]

별도의 윈도가 겹칠 수 있는 고정된 시간 길이의 윈도에 버킷화된다. 예를 들어 30초마다 새로운 60초 윈도를 생성할 수 있다. 

 

 

[워터마크]

워터마크는 윈도의 데이터가 설정된 시간 간격 내에 있는지, 또는 지연으로 간주되는지를 판단하기 위해 윈도에서 사용하는 임계값이다. 윈도에 새로 도착했지만 워터마크 타임스탬프보다 오래된 데이터는 늦게 도착한 데이터로 간주된다.

 

 

데이터 모델링

데이터 모델링은 데이터의 일관성 있는 구조를 의도적으로 선택하는 작업이며, 데이터를 비즈니스에 유용하게 만드는 중요한 단계다.

하지만, 데이터 모델링은 2010년대 초중반에 다소 유행에 뒤떨어지게 됐다. 데이터 레이크와 NoSQL, 빅데이터 시스템의 등장으로 엔지니어는 기존의 데이터 모델링을 우회할 수 있게 되었으며, 때로는 정당한 성능 향상을 도모할 수도 있었다. 

 

엄격한 데이터 모델링의 부재로, 중복되거나, 일치하지 않거나, 단순히 잘못된 데이터가 많아지면서 데이터 늪이 만들어지기도 했다. 

오늘날에는 다시 데이터 모델링 쪽으로 무게추가 기우는 분위기이다. 데이터 관리(데이터 거버넌스 및 데이터 품질)의 인기가 높아짐에 따라 일관성 있는 비즈니스 로직의 필요성이 커지고 있다. 

 

🤔 데이터 모델이란

데이터 모델은 조직의 프로세스, 정의, 워크플로 및 논리를 가장 잘 반영하기 위해 데이터가 어떻게 구조화되고 표준화되어야 하는지를 반영한다. 하지만 모델링은 치실 사용이나 숙면 등 모범적인 위생 관행과 마찬가지로, 좋은 일로 인식되지만 실제로 무시되는 경우가 많다. 

 

데이터를 모델링할 때는 모델을 비즈니스 성과로 변환하는데 초점을 맞추는 것이 중요하다. 

 

 

배치 분석 데이터 모델링 기술

데이터 레이크 또는 데이터 웨어하우스의 데이터 모델링을 설명할 떄, 원시 데이터는 다양한 형태지만 출력은 행과 열의 정형화된 데이터 모델이라고 가정해야 한다.

 

[인먼]

데이터 웨어하우스의 아버지인 빌 인먼은 1989년에 데이터 모델링에 대한 접근 방식 고안.

이전에는 원천 시스템 자체에서 분석이 이뤄지곤 했기 때문에 장기간 실행되는 쿼리로 인해 운영 트랜잭션 데이터베이스가 정체되는 것은 당연한 일이었다. 즉, 데이터 웨어하우스 목적은 원천 시스템과 분석 시스템의 분리이다.

 

데이터 웨어하우스는 전체 비즈니스 정보 요구 사항을 지원하는 '신뢰할 수 있는 단일 정보 출처'를 나타낸다.

 

[킴벌]

정규화에 초점을 맞추지 않으며 때에 따라서는 비정규화를 수용한다. 인먼 모델은 기업 전체의 데이터를 데이터 웨어하우스에 통합하고 데이터 마트를 통해 부서별 분석을 제공하는 반면, 킴벌 모델은 상향식으로 데이터 웨어하우스 자체에서 부서 또는 비즈니스 분석을 모델링하고 제공하도록 권장한다. 이 접근법은 효과적으로 데이터 마트를 데이터 웨어하우스 자체로 만들기 때문에 인먼보다 더 빠른 반복 및 모델링이 가능해지지만, 데이터 통합이 느슨해지고 중복 및 복제가 발생할 수 있다. 

 

 

[데이터 볼트]

킴벌과 인먼은 데이터 웨어하우스의 비즈니스 로직 구조에 초점을 맞추지만, 데이터 볼트는 데이터 모델링에 대한 다른 접근 방식을 제공한다. 

데이터 볼트 모델은 허브, 링크, 위성이라는 세 가지 주요 유형의 테이블로 구성된다. 

데이터 볼트는 애자일 방법론과 기술에 기반하므로 급변하는 비즈니스 요구 사항에 맞게 조정할 수 있다. 

https://www.databricks.com/kr/glossary/data-vault

허브

데이터 볼트에 로드된 모든 고유한 비즈니스 키의 레코드를 보관하는 데이터 볼트의 중심 엔티티.

입력 전용이며 허브에서 데이터는 변경되지 않는다.

 

링크

허브 간 비즈니스 키의 관계를 추적한다. 링크 테이블은 다양한 허브의 데이터를 연결하므로 다대다 관계다. 데이터 볼트 모델의 관계는 간단하며 링크 변경을 통해 처리된다. 

 

위성

허브와 링크 간의 관계에 의미와 맥락을 부여하는 기술 속성. 

 

▼ 데이터 볼트가 유연하게 파이프라인을 설계할 수 있는 주요 이유

데이터 볼트(Data Vault) 아키텍처는 현대의 엔터프라이즈 데이터 웨어하우스 설계에 주로 사용되는 방법론 중 하나입니다. Data Vault는 데이터의 통합과 확장성에 중점을 둔 모델링 기법으로, 변화하는 비즈니스 요구사항과 소스 시스템에 대응할 수 있는 유연성을 제공합니다.

데이터 볼트가 유연하게 파이프라인을 설계할 수 있는 주요 이유는 다음과 같습니다:

1. 모듈화된 구조: 데이터 볼트는 Hub, Satellite, Link의 세 가지 주요 컴포넌트로 구성됩니다. 이러한 모듈화된 구조는 소스 시스템의 변경이나 추가 데이터 소스의 통합이 필요할 때 파이프라인에 대한 큰 수정 없이 쉽게 대응할 수 있습니다.

2. 변화에 강함: 전통적인 데이터 웨어하우스 설계 방식에 비해, Data Vault는 소스 시스템의 변경에 대응하기 쉽습니다. 예를 들면, 소스 시스템에서 필드가 추가되거나 제거되는 경우, Satellite 테이블만 수정하면 됩니다.

3. 시간 변동성: 데이터 볼트는 데이터의 시간적 변동성을 관리하기 위한 설계를 갖추고 있습니다. 이로 인해 시간에 따른 데이터의 변화를 쉽게 추적하고 저장할 수 있습니다.

4. 병렬 처리: 볼트의 모듈화된 구조는 병렬로 데이터를 로드하는 것을 용이하게 합니다. 이는 ETL(Extract, Transform, Load) 또는 ELT(Extract, Load, Transform) 프로세스를 통한 데이터 로딩 속도를 향상시킬 수 있습니다.

5. 확장성: 새로운 데이터 소스나 비즈니스 요구사항이 생겨나더라도, 기존의 아키텍처와 파이프라인을 크게 변경할 필요 없이 통합이 가능합니다.

이러한 특징들 덕분에 데이터 볼트 아키텍처는 다양한 데이터 웨어하우스 환경에서 유연하게 파이프라인을 설계하고 관리하는 데 매우 효과적입니다.

 

변환

데이터 변환의 최종 결과는 데이터를 통합하고 집약하는 능력이다.
일단 데이터가 변환되면 해당 데이터를 단일 엔티티로 볼 수 있다.
그러나 데이터를 변환하지 않으면 조직 전체의 데이터를 통합적인 시각으로 볼 수 없다.

 

 

구체화된 뷰(Materialized View)

구체화되지 않은 뷰의 잠재적인 단점은 사전 연산을 수행하지 않는다는 것이다. 5개의 테이블을 조인하는 뷰의 예에서는 마케팅 분석가가 이 뷰에 대한 쿼리를 실행할 떄마다 조인을 실행해야 하므로 조인 비용이 매우 많이 들 수 있다.

하지만, 구체화된 뷰는 뷰이 일부 또는 전부를 미리 연산한다. 

 

즉, Materialized View는 일반적인 뷰와는 다르게 데이터 베이스에 물리적으로 저장된다. 즉, 결과 데이터셋이 계산되어 디스크에 저장되는 것이다. 따라서 MV는 미리 계산된 결과를 저장하고 있기 때문에 데이터를 빠르게 조회할 수 있다. 

 

▼ 장단점 및 적용 시나리오

Materialized View란?
Materialized View (MV)는 일반적인 뷰와는 다르게 데이터베이스에 물리적으로 저장되는 뷰입니다. 즉, 결과 데이터셋이 계산되어 디스크에 저장됩니다. 일반 뷰는 쿼리가 호출될 때마다 데이터를 실시간으로 계산하지만, MV는 미리 계산된 결과를 저장하고 있기 때문에 데이터를 빠르게 조회할 수 있습니다.

Materialized View의 장점:
1. 성능 향상: 주요 데이터에 대한 집계, 변환, 필터링 등의 연산이 미리 수행되기 때문에 쿼리 응답 시간이 빠릅니다.
2. 계산 최적화: 복잡한 쿼리나 큰 데이터셋에 대한 계산을 미리 수행하여 저장해두기 때문에 일반 뷰에 비해 계산 부하를 줄일 수 있습니다.
3. 데이터 일관성: MV를 주기적으로 갱신하는 경우, 특정 시점의 데이터 상태를 보존하면서 일관성 있는 결과를 제공할 수 있습니다.

Materialized View의 단점 및 사용 시 주의사항:
1. 저장 공간: MV는 물리적으로 데이터를 저장하기 때문에 추가적인 디스크 공간이 필요합니다.
2. 유지 관리: MV의 데이터는 정기적으로 갱신되어야 합니다. 이 갱신 작업은 부하를 발생시킬 수 있으므로 적절한 갱신 전략이 필요합니다.
3. 갱신 지연: 실시간 데이터에 대한 최신 상태가 반영되지 않을 수 있습니다. 따라서, MV가 가장 최근의 데이터를 포함하도록 관리해야 합니다.

Materialized View를 사용하는 시나리오:
1. 복잡한 계산: 여러 테이블에 걸쳐 조인, 집계, 변환 등 복잡한 계산이 필요한 쿼리가 자주 실행될 경우.
2. 빈번한 읽기 연산: 동일한 쿼리가 빈번하게 호출되며, 데이터 변경보다 읽기 연산이 훨씬 더 빈번한 경우.
3. 분석 및 보고: 주기적인 보고나 대시보드를 위한 데이터를 제공해야 하는 경우.

Materialized View의 효율성이 떨어지는 시나리오:
1. 빈번한 데이터 갱신: MV의 기반 데이터가 지속적으로 변동되는 경우, MV도 빈번하게 갱신되어야 하므로 관리 부하가 증가합니다.
2. 실시간성 요구: 데이터의 실시간 상태를 반영해야 하는 애플리케이션에서는 MV가 항상 최신 상태를 반영하지 않을 수 있으므로 적합하지 않을 수 있습니다.

결론:
Materialized View는 쿼리 성능을 향상시키기 위해 사용됩니다. 그러나 사용 시 MV의 데이터 갱신 및 관리에 대한 고려사항이 필요합니다. 따라서, MV를 사용하기 전에 사용 사례와 데이터의 특성을 잘 분석하여 MV가 적절한지 판단해야 합니다.

 

 

결론

엔지니어들은 최신 기술 장난감을 가지고 놀기 위해 고용되는 게 아니라 고객에게 서비스를 제공하기 위해 고용된다. 변환은 데이터가 비즈니스에 가치와 ROI 를 더하게 한다.