data6 MIN READ

[데이터 엔지니어링 디자인 패턴] 09. 데이터 품질

[데이터 엔지니어링 디자인 패턴] 09. 데이터 품질

#dataengineering

데이터 엔지니어링 디자인 패턴 시리즈의 글입니다.

신뢰는 데이터셋의 중요한 가치.
데이터의 신뢰를 지키기 위해, 데이터 품질 문제를 완화해줄 디자인 패턴을 알아보자.

9.1 품질 확보

  • 목표 : 신뢰할 수 있는 데이터를 공유하는것

감사-쓰기-감사-배포 (AWAP)

Audit-Write-Audit-Publish pattern assertion과 유사 데이터셋이 기대에 부합하지 않으면 전체 실행 중단 WAP pattern의 진화형

  • 문제
    • job에 새 기능을 추가하다가 고유방문자집계가 올바르게 계산되지 않음을 발견
    • 유사 문제가 발생하지 않게 해야함
  • 해결책
    • AWAP 는 비즈니스 및 기술적 요구사항(ex. 완전성, 정확성) 조건을 보장하도록 제어 (=감사audit)
    • 첫번째 감사 = 데이터 원천의 유효성을 확인
    • 두번째 감사 = 변환된 데이터의 유효성을 확인
    • 감사의 결과
      • data dispatching : 일부만 유효하지않은경우 유효하지 않은 데이터는 별개 스토리지에 보관
      • non-blocking audit : 약간의 결함은 주석으로 표기하고 최종 스토리지로 승격
    • 스트리밍 작업에서의 AWAP
      • window based : 스트리밍잡에서 직접 winodow를 생성하고, 윈도가 닫히면 감사단계 실행
      • staging based : 데이터셋을 최종 출력 위치로 승격하기 전 스테이징에 레코드를 쓰고 감사 한 후 출력
  • 결과
    • 비용 추가 : 컴퓨팅 비용이 추가됨
    • 규칙 적용 범위 : 검증을 위한 새로운 비즈니스 규칙 세트를 적용해야함. 그러나 데이터셋은 변하므로, 이 규칙은 차후에 미래의 데이터셋을 포괄하지 못하게 될 가능성이 높아서 100% 신뢰할 수 없음
    • 스트림이 지연 : 스트리밍 컨텍스트에서 약간의 추가지연을 발생시킴. (윈도 누적기간만큼)
    • 문제는 문제가 아닐수도 있음 : audit단계에서 잘못된게 올바른것으로/올바른것을 잘못된것으로 판단하기도 함.

제약 조건 적용자

Constraints Enforcer Pattern 데이터 유효성 확인을 데이터베이스/스토리지에게 위임

  • 문제
    • 필수 필드와 같은 데이터 품질 오류가 있으면 로딩프로세스를 실패하게 할 대안을 찾고있음
  • 해결책
    • 제약규칙이 할당되어야할 속성을 먼저 정하고, 제약조건을 할당함.
    • 유형제약
      • 주어진 속성의 모든 값이 항상 동일한 유형임을 보장
      • 컨슈머가 처리 프로세스를 크게 단순화할 수 있음
      • 유형제약 = 스키마의 일부.
    • NULL 허용 제약
      • 속성은 절대 누락되지 않는것 or 누락될 수 있는것으로 정의
    • 값 제약
      • 허용되는 단일 값 or 값들의 집합 or 표현식 or 비교연산장에 의존
    • 무결성 제약
      • 정규화 패턴을 사용하여 모델링한 트랜잭션 db의 일부
      • 테이블에 있는 값이 다른 테이블에 있는 실제 값을 참조하도록 보장
    • 파일형식에도 구현 가능 (ex. avro, protobuf)
  • 결과
    • 우수한 데이터 품질을 보장하는 확실한 방법 but 몇가지 단점
    • all-or-nothing semantic
    • 데이터 프로듀서 교대
      • 프로듀서 지향적인 방법임
      • 컨슈머들은 데이터 기대치가 서로 다름
      • 컨슈머는 이미 제한된 데이터셋에 대해 유효성확인 or 필터링 로직을 따로 구현해야함
    • 제약 조건 지원
      • 모든 유효성 규칙을 항상 다룰 수 있는것은 아님
      • 따라서 job에 제약조건을 정의해 db제약조건을 완성해야함

9.2 스키마 일관성

  • 스키마 제약 조건은 데이터 일관성 문제를 해결함

스키마 호환성 적용자

Schema Compatibility Enforcer Pattern 데이터셋은 시간이 지남에 따라 값이 변화함 (동적) 변화된 엔트리는 유효성이 확인되어야함 스키마가 이러한 유효성을 가진다면?

  • 문제
    • 특정 필드가 필요없어져서 삭제함
    • 그 결과 잡이 여러번 실패하게됨
    • 스키마를 손상시키는 변경을 피할 방책 구축이 필요
  • 해결책
    • 데이터 프로듀서에 중단을 일으키는 변경이 발생하지않도록 스키마 호환성 적용자 패턴 사용
    • 3가지 스키마 호환성 적용 모드 중 하나를 사용
      • 외부 서비스나 라이브러리를 통해 (ex. kafka schema registry)
      • 삽입시 암시적으로 (ex. db constraint)
      • DDL에 대한 event-driven (ex. event trigger)
    • 스키마 호환성 모드 (다운스트림 컨슈머에게 준비해야할 진화를 알려줌)
      • 하위 호환성 : new schema 사용 컨슈머는 old schema로 생성된 데이터를 여전히 조회 가능
      • 상위 호환성 : old schema 사용 컨슈머가 new schema 데이터를 조회할 수 있다
      • 완전 호환성 : 하위호환성 + 상위호환성
    • 호환성은 전이적 transitivie 일 수 있다
      • A가 B와 호환되고, B가 C와 호환된다면,
      • A도 C와 호환된다고 볼 수 있다는 성질
  • 결과
    • 이점이 위험보다 큼. (그래도 위험은 잇음)
    • 상호 작용 오버헤드 : 스키마관리때문에 데이터 생서에 추가 오버헤드 발생
    • 스키마 진화가 더 어려워짐.

스키마 마이그레이터

Schema Migrator Pattern 필드 유형 진화와 이름 변경 같은 호환성을 깨뜨리는 스키마 변경을 수행하면서도, 컨슈머를 안전하게 보장하려면?

  • 문제
    • 도메인 관련 필드가 너무 복잡해져서 동일 엔티티로 그룹화하고자함
    • 기존 스키마를 근본적으로 고쳐야하는데, 그러면 호환성이 깨짐
    • 컨슈머에게 새 형식으로 migration할 시간을 주 어 속성을 개선하려고함
  • 해결책
    • 스키마 마이그레이터 디자인 패턴
    • 진화 식별 → 컨슈머 전환 시간 합의 → 컨슈머 전환 수행 → 스키마 새 버전 생성
    • 유형
      • 이름변경
      • 유형변경
      • 제거
  • 결과
    • 데이터 크기에 영향을 미침. 많아지면 저장공간, 네트워크전송, I/O 비용 발생
    • 불가능한 제거 : 제거하려는 필드를 사용중인 컨슈머가 있다면 필드제거 불가능

9.3 품질 관찰

데이터셋은 동적. 데이터셋은 변함. 규칙은 시간에 따라 invalid해짐 데이터셋에 무슨 일이 일어나고있는지 관찰하고 기존 규칙을 수정하거나 제약조건을 추가할 준비를 하는것이 중요

오프라인 옵서버

Offline Observer Pattern

  • 문제
    • 데이터셋 속성을 모니터링하려함
    • 현재는 모든것이 원활한 상태라, 모니터링 계층이 메인 파이프라인을 차단하지 않아야함.
  • 해결책
    • 모니터링이 처리 워크플로를 차단하지 않아야 한다면 offline observer 패턴이 가장 좋음
    • 관찰 가능성 잡 (처리된 레코드 분석 + 기존 모니터링 계층 강화 + 추가 인사이트) 생성
    • 시간의 경과에 따른 데이터 품질 문제를 발견할 수 있음
    • 데이터 관찰 가능성 잡은 생성프로세스에 영향 X
    • 독립적으로 실행
    • 혹은 다른 스케쥴로 실행 (ex. 밤 스케쥴링)
  • 결과
    • 시간 정확도가 낮음
      • 적시에 실행 X
      • 이미 다운스트림 컨슈머가 데이터 처리한 이후에 인사이트가 도출될 가능성이 높음
    • 컴퓨팅 자원이 늘어남
      • 별도 잡 실행
      • 데이터셋을 샘플링하여 낮출수있으나 이런 경우 인사이트를 놓칠수있음

온라인 옵서버

Online Observer Pattern

  • 문제
    • 우편번호 필드에 예상치 못한 형식이 있는 문제를 발견함
    • 단, 오프라인 옵저버가 주 1회 실행되고있어서 일주일 후에 발견함
    • 데이터 정합성 문제를 더 빨리 발견하고 해결하고싶음
  • 해결책
    • 오프라인 옵저버의 반대패턴인 온라인 옵저버 패턴을 사용
    • 모든 관찰 지표를 생성하기 위해 데이터 관찰 잡에 의존
    • 다만, 실행되는 시간이 데이터 생성 직후.
    • 다운스트림 컨슈머와의 통신 기술 문제를 피하는데 유리함.
    • 보통 변환단계 이후 관찰 잡이 위치.
      • 병렬 분할 패턴
      • 로컬 시퀀서 패턴
      • 스트리밍 파이프라인의 경우, 관찰로직은 데이터 생성 잡에 통합
    • 만약 관찰 잡이 전체 파이프라인에 영향을 미칠 수 있다면, 데이터를 샘플링하여 관찰 수행
      • 인사이트 놓칠수 잇는 부분은 받아들여야함
  • 결과
    • 시간정확도 문제는 해결되지만, 몇가지 주의할점이 생김
    • 추가지연 발생 : 로컬시퀀서 방식이면 파이프라인 끝에 추가 단계가 생기는것이므로 완료가 지연됨

    • 병렬 분할 : 병렬성을 더하는경우 부분적으로만 유효한 데이터셋을 관찰하는 위험을 야기.