Data Observability

정의 및 필요성

• 시스템, 데이터 파이프라인 등 전반적인 프로세스에서 데이터가 일정한 품질, 사용 가능성, 신뢰성을 가지는지 모니터링, 관리, 유지하는 것
• 필요성 : 조직 내 데이터의 발전에 따라 아래와 같은 문제점 발생
  • More external data sources : 내/외부 데이터 양 및 속도 증가 -> 예상하지 못한 schema 변경, 변환, 지연 발생
    
  • More complicated transformation : 외부 데이터의 증가 = 사용할 수 있도록 구조 변경 및 연산 필요
    
    • Format 변경 시, 도미노처럼 downstream에서 오류가 줄줄이 발생함
      
  • Too much focus on analytics engineering : ETL + ELT = MDS(Modern data Stack)
    
    • MDS 목적 : 데이터를 사용할 수 있도록 변환하는 시간 단축
      
    • 자동화 시스템이 많아질수록, 데이터를 원하는 형태로 변환하기가 어려워짐

 

DataOps Cycle

Detection - Validation

• DataOps의 초석, 첫 단계
• Todo
  
  • Data warehouse와 데이터 사용 시의 데이터 품질이 동일한지 확인
  • 컬럼 스키마, row level validation에 집중
  • 데이터 시스템 내의 모든 데이터에 business rule이 모두 적용되었는지 확인해야함
• 특징
  
  • Detection은 환경에 대해 반동적
    
    • data lake나 warehouse에 저장되어 있거나, 사용되고 있는 데이터가 원하는 형태가 맞는지 확인하게 해줌
  • Business rule을 숙지할 것
    
    • 이슈의 원인을 알지 못하면 엔지니어가 따를 새로운 rule을 수립하지 못함
      
      • Data lifecycle의 모든 단계에 적용되는 business rule을 알아야함 -> 지속적인 data observability 필요

Awareness - Visibility

• 중앙화, 표준화된 파이프라인 & 데이터에 대한 metadata : data team이 전체 조직에 대한 이슈를 발견할 수 있도록 해줌
• Data governance에 대한 논의 & metadata 우선 접근 방식이 시작되는 지점
• Metadata의 중앙화 : 조직이 end-to-end data health에 관심을 가지도록 함
  
  • Data issue를 해결하기 위해 선제적으로 움직일 수 있게 함
    
    • Bad data가 들어올 경우, 문제가 발생한 upstream/downstream까지 추적할 수 있음

Iteration - Process

• 모든 데이터 개발에 적용할 수 있는 반복 가능 & 지속 가능한 기준을 가지고 있음
  
  • 효과 : 동일한 데이터 신뢰성을 가질 수 있음
• 점진적인 data health 개선 : issue를 탐지하고 upstream root 원인 및 효율적인 프로세스에 대한 개선으로 이어짐

 

이점

• Higher data quality : 결측값, 중복값, 일관적이지 않은 형식을 탐지 -> 데이터 품질 개선 -> 더 나은 data 기반 의사결정
  
• Faster troubleshooting : 데이터 오류를 실시간으로 탐지하고 알림을 줌 -> 빠른 문제 해결을 통해 비용 및 중단 시간을 최소화할 수 있음
  
• Improved collaboration : 공유된 대시보드를 사용함으로써 실무자가 중요한 데이터셋의 상태를 확인할 수 있음 -> 팀 간 협업 능력 상승
  
• Increased efficiency : 엔지니어가 더 나은 리소스 사용과 빠른 처리 시간을 위해 시스템 최적화 -> 병목현상과 성능 문제를 해결
  
• Improved compliance : 헬스케어, 금융, 통신 등 규제가 많은 산업군에서 데이터가 정확성, 일관성, 보안성 기준을 충족하도록 함 -> Compliance Risk를 줄임
  
• enhanced customer experience
  
  • 고객의 요구, 선호 및 행동을 이해하도록 도움 -> 더 개인화된 고객 경험 제공
    
  • 정확한 최신의 고객 데이터 유지 -> 고객 만족도 및 충성도 향상
    
• Increased revenue : 트렌드와 잠재적인 수익 기회 발견 -> 새로운 인사이트 도출 -> 수익 상승 및 성장

 

The 5 Pillars

• Freshness : 데이터를 어떻게, 얼마나 자주 업데이트할 것인가
  
  • Data staleness : 데이터가 업데이트되지 않아서 데이터와 실제 간 차이가 발생할 경우 발생. 최신성 문제로 data pipeline에 문제가 생기는 경우가 대부분
• Distribution : field 수준의 data health 관련 지표. 허용 가능한 범위 안에 데이터가 속하는가
  
  • 예상했던 data 분포와의 차이 : 데이터 품질 문제 및 원본 데이터의 변화 탐지 지표
• Volume : 다양한 프로세스와 파이프라인으로 생성, 수집, 변경되는 데이터의 크기. 데이터 테이블의 완전성을 의미하기도 함
  
  • 수집된 데이터가 기준을 충족하는지 파악할 수 있는 핵심 지표
• Schema : 데이터의 조직
  
  • 스키마 변경은 종종 오류로 이어짐
  • Data observability는 데이터가 지속적으로 조직화되었는지, 서로 다른 시스템 간에 호환이 가능한지, 전체적인 lifecycle에 걸쳐서 통일성을 유지하는지 확인할 수 있게 함
• Lineage : 어디에서 오류가 발생했는지 파악하기 위함
  
  • 원본부터 end location까지의 data를 살펴보며, 모든 변경 사항의 내용과 변경 이유를 고려함
    가장 자주 가시화됨

 

다른 개념과의 차이점 : Data Quality, Data Governance

• vs Data Quality : 데이터를 관리하는 영역이 다른 두 분야
  
  • Data observability : 데이터셋의 품질 문제를 파악할 수 있음. 그러나 단독적으로 좋은 데이터 품질을 보장할 수 없음
    
    • 데이터 이슈를 해결하고 문제 발생을 방지해야 좋은 데이터 품질 보장 가능
    • Data observability를 적용하지 않더라도 좋은 데이터 품질을 유지할 수 있음
  • Data Quality : 데이터셋 상태가 운영 및 분석에 활용될 수 있을 정도로 적합한지 나타냄
    
    • 정확성, 완전성, 일관성, 신뢰성, 유효성, 적시성 등 다양한 품질 지표를 기준으로 검토해야함
• vs Data Governance : 상호보완적인 하나의 프로세스
  
  • Data Governance : 조직의 데이터가 사용 가능하고, 일관되고 안전한지 검증하는 것이 목표
    
    • 내부적인 규정에 준거한 Compliance를 준수
    • 데이터 품질 개선 활동과 밀접하게 연관
    • 강한 Governance 활동은 data observability에 제한을 줄 수 있는 data silo, 데이터 통합 및 데이터 품질 문제 해결에 도움을 줌
  • Data Obervability : 데이터 품질, 접근성, lineage의 변경을 모니터링하여 Data Governance에 도움을 줌

 

Hierarchy

• Operational Health & dataset Monitoring : 데이터셋과 파이프라인은 각기 다른 측면에서 모니터링되지만, 둘은 상호의존적. 둘을 각기 다른 tool이나 team으로 나누어서 관리하는 것은 고차원의 data health 측면에서 권장하지 않음
  
  • Data at rest(정지 중인 데이터) : 고정된 위치에 있는 데이터의 상태 확인
    
    • 데이터셋이 시간 안에 도달했는가 : 적시성
    • 데이터셋이 필요한 만큼 자주 업데이트되었는가 : 최신성
    • 예상했던 크기의 데이터를 활용할 수 있는가 : 완전성
  • Data in motion(움직이는 데이터) : 데이터 파이프라인의 상태 확인. 데이터가 파이프라인에 따라 변동하고 이동할 때의 상태.
    
    • 파이프라인 성능이 어떻게 데이터셋 품질에 영향을 미쳤는가
    • 어떤 조건에서 실행한 게 성공적인가
    • Datalake 혹은 datawarehouse에 도달하기 이전에 어떤 작업을 거치는가
  • Column-level Profiling : 새로운 비즈니스 규칙 수립과 컬럼 수준에 기존 규칙 적용 관련 인사이트 제공
    
    • Actionable한 방식으로 데이터 품질 프레임워크를 개선
      
      • 컬럼의 예상 범위는 어느 정도인가?
      • 컬럼의 예상 스키마는 무엇인가?
      • 컬럼의 고유값은 무엇인가?
  • Row-Level Validation : 각 행의 data value가 정확한지 검증. Row-level validation만 신경쓰면 전체적인 숲을 보기 어려워짐
    
    • 운영 및 데이터셋 모니터링과 함께 framework를 도입하면 전체적인 맥락과 문제의 근본적인 원인, 관련 영향을 고려할 수 있음
      
      • 각 행의 데이터가 예상한 형태인가
      • 각 행의 데이터가 예상한 길이인가
      • 맥락을 고려했을 때, 마지막 사용자에게 유용하고 충분한 정보가 있는가

 

Implementing

• 다양한 tool과 기술의 통합, 각기 다른 팀의 협업 필요
• Define Key metrics : 추적해야하는 핵심 metric을 정의하는 것부터 시작. 데이터 품질, 양, 최신성, 오류 비율 및 가용 리소스 등의 지표를 포함함
  
  • 핵심 니즈와 데이터 파이프라인의 특징에 따라 선택하는 Metric이 달라진다.
• Choose appropriate tools : 데이터 수집, 저장, 분석 등에 사용할 도구 선정하기
  
  • 오픈소스를 포함한 툴이 기존 인프라와 호환 가능한지, 규모를 감당할 수 있는지 고려해야함
• Standardize libraries : 동일한 언어로, 공개적으로 이슈를 언급할 수 있는 곳에 인프라를 둘 것
• Instrument your data pipeline : 데이터 수집 라이브러리/Agent를 데이터 파이프라인에 통합
  
  • 이를 통해 사전에 정의된 metric을 파이프라인의 다양한 단계에서 수집할 수 있음
  • 목표는 포괄적인 가시성을 확보하는 것이므로 모든 중요한 단계를 장비화하는 것이 중요함 : 장비 -> 측정 가능 -> 가시성 확보
• Set up a data storage solution : 데이터의 확장을 측정하기 위해 DB나 시계열 플랫폼에 수집한 metric를 저장해야함
  
  • 데이터의 속도 및 양을 처리할 수 있는 저장 솔루션을 선택해야함
• Implement data analysis tools : 저장된 metric에서 인사이트를 도출할 수 있는 도구를 선택해야함
  
  • 심층 분석을 위해선 직관적인 시각화와 복잡한 쿼리를 지원하는 도구를 고려할 것
• Configure alerts and notifications : 사전에 정의된 임계점을 넘거나 이상 탐지 시, 자동 알람을 보내기 위한 시스템 구축
  
  • 이슈에 즉각 대응하고 잠재적인 downtime을 최소화할 수 있음
• Integrate with incident management platforms : 데이터 관측성은 이슈 탐지 및 효과적인 이슈 관리 방법과 관련
  
  • 사고 관리 시스템과 파이프라인을 통합하면 이슈 대응 workflow를 간소화하는 데 도움이 될 수 있음
• Regularly review and update your observability pipeline : 비즈니스가 진화하는 것처럼 데이터와 요구사항도 진화할 것.
  
  • 인사이트와 성능을 제공하기 위해선 정기적인 리뷰 및 파이프라인 업데이트 필요

 

출처 : https://www.ibm.com/think/topics/data-observability