데이터 품질의 비밀 (2)

신뢰할 수 있는 데이터 시스템 구축을 위한 블록 조립

---

(1) 운영 데이터와 분석 데이터의 차이

조직 내 데이터를 가장 크게 구분해 달라고 한다면 간단하게 운영 데이터와 분석 데이터로 나눌 수 있다. 운영 데이터의 품질과 신뢰성 관리는 종종 (DevOps, SRE), 분석 데이터의 관리는 소프트웨어 프로덕트와 관련이 있을 것이다. 간단한 예로 OLTP와 OLAP라고 볼 수 있다. 운영상이냐 분석을 위해 이냐 차이로 보면 된다.

운영 데이터는 운영상 생성된 데이터, 조직에서 일상적인 운영을 통해 생성된 데이터이다. 특정 시점의 인벤토리 스냅샷, 고객 인상 및 거래 기록 모두 운영 데이터에 속한다.

분석 데이터는 분석적으로 사용되는 데이터, 데이터 기반 의사 결정에 활용되는 데이터를 말한다. 전환률, 클릭률, 글로벌 지역별 광고 노출 등이 분석 데이터에 속한다.

두 데이터를 운용하는 데 있어 관리를 같이하면 좋을 것 같지만 이 관계는 Trade-Off와 같다. 카페를 운영한다고 할 때 카페의 회전률은 커피의 소비량으로 모든 손님을 수용할 수 있게 매장을 넓히면 소비량이 늘어날 것으로 생각하지만 주문을 받을 수 있는 인원이 한정적이고 주문을 받고 손님이 나가는 데 까지 속도가 개선되지 않으면 병목현상으로 인해 커피 판매량은 늘지 않을 것이다.

트랜젝션 데이터베이스의 경우 페이지 로드 시 주문 세부 정보와 같은 특정 정보를 최대한 빨리 가져와야 한다. 따라서 아키텍쳐는 복잡한 일보다 최대한 빨리 처리해야하는 방향으로 최적화가 되어있다. 반면 분석 데이터 베이스는 대규모 데이터셋에서 고객의 요구에 부응하기 위해 높은 처리량에 맞게 최적화가 되어 있다.

(2) 데이터 웨어하우스 vs 데이터 레이크

많은 조직에서 데이터 파이프라인 내에 이 두 가지 유형의 시스템을 모두 필요로 하지만 둘은 서로 다른 용도로 사용된다. 일반적으로 데이터 웨어하우스는 데이터를 구조화된 형식으로 저장한다. 햐당 데이터는 고도로 변한 전처리된 데이터로 변환된다. 다 필요에 의해 이론적으로 확실한 존재의 이유가 있다.

1. 데이터 웨어하우스 : 스키마 수준의 테이블 타입

• 장점
  • 데이터 웨어하우스에는 Schema on write 액세스 권한이 필요하다. 즉 이미 구조가 정해져있는 곳에 데이터를 입력하는 형식이다. 데이터의 구조가 바뀌면 모든 단계에서 새로운 구조를 만들어야한다. 데이터 레이크보다 많은 구조와 스키마가 필요하므로 데이터 위생(data hygiene)이 개선된다.
• 데이터 웨어하우스 종류
  • 아마존 레드시프트 : 최초의 클라우드 데이터 웨어하우스
  • 구글 빅쿼리 : GCP를 활용한 열 기반 저장 구조를 활용, 서버 리스 솔류션
  • 스노우플레이크 : 미리 패키징된 분석 도구 SQL은 데이터 분석팀에 적합하다. 사용자가 컴퓨팅 및 스토리지 비용을 별도로 지불 할 수 있어 좀더 유용한 빌링이 가능(현재는 다른 서비스도 일부 가능)
• 단점
  • 제한된 유연성 : 데이터 웨어하우스 확장성이 낮지는 않지만 형식이 제한되어있다. 예를들면 JSON과 반구조화된 데이터와 그 쿼리는 대개 적합하지 못하고, 나쁜 데이터의 경우 강제변환하지 않으면 소실되기도한다.
  • SQL 전용 지원 : SQL로 데이터를 받아야하므로 분석으로 머신러닝이나 고도화된 연산을 지원하지 않는다. 따라서 데이터를 이동해야하는 일이 잦다. 이러한 데이터 이동은 종종 데이터를 망가뜨리고 데이터의 볼륨과 신선도에 부정적인 영향을 미치며 스키마 이상(anomaly) 현상의 원인이 되기도 한다.
  • 워크플로에서의 마찰(Frictional workflows) : 프로덕트의 이터레이션이 반복됨에 따라 소규모 데이터 과학자 팀은 이를 간소하고 느슨하게 바꾸기를 원하지만 지속적인 스키마 변경은 달가워하지 않는다. (ex. 스키마 변경 없이 6개 이상의 테이블을 참조하는 쿼리를 개선하기는 어렵다)

2. 데이터 레이크 : 파일 수준의 조작

• 장점
  • 현대 데이터 시스템에서 자주 사용되며 고품질 분석 데이터에 의존한다.
  • schema on read 읽기 schema에 접근이 가능하며 데이터가 준비 되었을 때 데이터의 구조를 추론한다.
  • 데이터 사이언스, 머신러닝 엔지니어, 데이터 엔지니어가 반구조 형식과 비구조 형식을 모두 포함하는 훨씬 더 큰 데이터 풀에서 데이터를 가져올 수 있다.
  • 극초기 아파치 하둡 맵리듀스(MapReduce)와 HDFS를 기반으로 구축되었으며, SQL 엔진으로 데이터를 쿼리하기 위해 아파치 하이브를 활용
  • 특징
    • 분산된 저장소 및 컴퓨팅 : 비용 절감, 실시간 스트리밍 및 쿼리 데이터를 enrich하게 만듦
    • 분산 컴퓨팅 지원 : 분산 컴퓨팅은 더 나은 세그먼트 쿼리 성능, 대규모 데이터 처리 능력
    • 사용자 지정 및 상호 운용성 : 플러그 앤 처그 (plug and chug) 특성으로 인해, 기업의 데이터 요구 사항이 발전하고 성숙해짐
    • 오픈 소스 기술 기반 구축 : 공급업체에 대한 의존도가 줄고 대규모 데이터 엔지니어링 팀을 보유한 기업에 적합
    • 비정형 또는 거의 정형화되지 않은 데이터 처리 능력 : 데이터 레이크는 원시 데이터를 지원하기 때문에 데이터를 사용할 때 유연성이 향상되어야 데이터 과학자와 엔지니어에게 이상적, 집계 및 계산을 효과적으로 제어
    • 정교한 비SQL 프로그래밍 모델 지원 : pyspark, spark, hadoop
• 단점
  • 데이터 레이크의 확장성과 유연성은 광범위하나 데이터 구성 및 거버넌스와 관련된 다른 문제가 많이 발생
  • 데이터 무결성 : 파일 레벨에서 조작되는 데이터 레이크의 리소스는 데이터 스키마에 대한 보장이 없다. 만약 레이크 속 데이터를 변환할 수 있고 스키마에 대한 가정을 했다면 Blind ETL을 수행할 가능성이 있다. 예상치 못한 업스트림 변경으로 인해 언제든지 변환이 실패 할 수 있다. (무결성이 보장 되지 않는다.)
  • 늪지화(swampification) : SQL과 같이 전통성이 없어 관리자의 부재가 곧 기술 부채를 초래할 수 있다. 데이터 아키텍처 구성 변경을 모두 숙련된 엔지니어에게 요청해야한다. 데이터를 잘 사용하려면 학습 곡선 상위에 도달해야만한다.
  • 엔드포인트 증가 : 데이터를 수집, 조작, 변환할 수 있는 방법이 다양하기 때문, 데이터 안전성 종종 데이터 레이크에서 큰 문제가 된다. 데이터 파이프라인의 단계가 많아질수록 오류 발생 가능성이 높아지기 때문이다.

** 데이터 레이크 + 데이터 웨어하우스 통합 도구 ** : AWS 글루, 파이브트랜, 마틸리온

(3) 데이터 품질 지표 수립

데이터 품질 지표란?
측정할 수 없는 것은 관리도 할 수 없다 -> 주요 성과 지표(KPI) 없이는 목표를 이를 수 없다.

• 데이터가 중단 되었을 때 프로세스 체크
  • 데이터가 최신 상태인가?
  • 데이터가 완전한가?
  • 필드가 예상 범위에 내에 있는가?
  • NULL 비율이 예상보다 높은 것은 아닌가?
  • 스키마가 변경되었는가?
  • 데이터 품질 지표 구성 요소
    • 확장성 : 많은 수의 테이블과 대규모의 데이터 셋을 추적하는 작업은 까다로울 수 있다. 요청을 한 번에 처리하고 규모에 맞게 쿼리를 최적화하며, 중복을 제거하고, 다양한 방법으로 스키마를 정규화하며 운영과 업데이트 및 유지 관리할 수 있는 전용 파이프라인 구축
    • 신선도 : table 생성 년도를 확인해 항상 업데이트 날짜를 확인하자.
    • 쿼리 로그 체크 : 실행 쿼리를 모니터링해 언제 적재되고 이동했는지 확인
      • 누가 이 데이터에 접근하는가?
      • 업스트림 또는 다운스트림은 어디서 나오는가?
      • 평균적으로 이 특정 변환은 얼마나 자주 실행되는가?
      • 몇개의 행이 영향을 받는가?
    • 데이터 분포 정보 확인 : 질의에서 Primary Key로 작용할 요소의 완전성과 유일성 비율을 확인한다.
    • UI 활용 : 가시성을 높이기 위해 항상 모니터링 요소를 사용
    • 데이터 카탈로그 설계
      • 데이터를 어디에서 찾아야하는가?
      • 이 데이터는 중요한가?
      • 이 데이터는 무엇을 나타내는가?
      • 이 데이터가 관련성이 있고 그 관련성은 중요한가?
      • 이 데이터를 어떻게 사용할 수 있는가?
        • 카탈로그 작성시 질문자의 이해를 위해 낮은 수준의 기술 언어를 사용해야하며 다운스트림에 대해 이해관계자와 협력하여 비즈니스에 가장 중요한 데이터가 무엇인지 파악하고 문서화 및 카탈로그화해야한다.
        • ex) 각자 다른 SQL문을 고려해 sqlparser, sql-parser를 사용해 충돌을 피하고 카탈로그를 채워나가야한다.

James Dixon : 소프트 회사 펜타오의 CEO로 데이터 레이크의 개념 주장
Kimball Group : 데이터 웨어하우스 정립
SLA(Service Level Agreement) : 소수 기업에서 데이터 품질에 대한 책임을 묻기 위해 시행