문서요약 - 데이터 품질과 데이터 정제 개요 by Johnson

제목: 데이터 품질과 데이터 정제 개요(Data Quality and Data Cleaning: An Overview)

저자: Theodore Johnson, 미국

문서유형: 강의 프리젠테이션 슬라이드(총 132 페이지), 2004년

 

데이터 품질 문제를 식별하고 체계화하여 그 연구 분야/방향을 제시한 튜토리얼 자료

---

데이터 글리치(Data Glitches)

정식 프로세스의 밖에서 데이터에 가해진 변경

• 데이터 레이아웃/데이터 타입의 변경. 예) 정수가 스트링이 됨, 필드의 위치가 바뀜
• 스케일/형식의 변경. 예) 달라 vs. 유로
• 일시적으로 디폴트로 되돌아감. 예) 프로세싱 스텝의 실패
• 분실된 값과 디폴트 값. 예) 애플리케이션 프로그램이 NULL 값을 제대로 다루지 못함
• 시계열(time series)에서의 갭. 예) 특히 레코드가 점진적 변경을 나타날 때

데이터 품질의 전통적 정의

• 정확성(Accuracy): 데이터가 정확하게 기록됨
• 완전성(Completeness): 모든 관련된 데이터가 기록됨
• 유일성(Uniqueness): 엔터티가 한번만 기록됨
• 적시성(Timeliness): 데이터가 계속 최신임. 예) 연합 데이터(federated data)에 특수한 문제로 시간 일관성(time consistency)이 있음
• 일관성(Consistency): 데이터가 일치됨

데이터 품질의 연속성(Data Quality Continuum)

데이터와 정보는 정적인 것이 아니며 데이터 수집 프로세스로부터 사용 프로세스로 흘러간다.

• 데이터 수집(Data gathering): 데이터가 어떻게 시스템으로 들어가는가? 문제 유발 원인으로 수동 기입, 내용 및 형식을 위한 단일 표준 부재, 병행 데이터 기입(중복), 근사화(Approximations), 대용(surrogates), SW/HW 제약, 측정 에러 등이 있음
• 데이터 전달(Data delivery): 부적절한 사전 처리(예, 부적절한 aggregation, null이 디폴트 값으로 전환됨)로 정보가 왜곡/훼손됨. 데이터 손실(예, 버퍼 오버플로우, 전송 문제)
• 데이터 저장(Data storage): 물리적 저장의 문제, 논리적 저장의 문제(예, 나쁜 메타데이터, 부적절한 데이터 모델, 애드혹 변경, SW/HW 제약)
• 데이터 통합(Data integration): 여러 데이터 셋을 결합시킴. 흔한 문제 원인으로 이종 데이터(Heterogeneous data), 제 각각인 정의, 시간 동기화(Time synchronization), 레가시 데이터, 사회학적 요인(예, 파워 손실을 우려해 정보 공유를 주저함) 등이 있다.
• 데이터 검색(Data retrieval): 도출된 데이터 셋이 실제 데이터의 하나의 뷰. 소스 데이터를 제대로 이해 못하거나, 도출 데이터의 필요성을 제대로 이해 못하거나, 또는 단순 실수(예, inner join vs. outer join, NULL 값의 이해) 등을 이유로 문제가 발생함
• 데이터 마이닝/분석(Data mining/analysis): 데이터로 무엇을 하는가?

데이터 품질의 의미

• 그 용도와 전형적인 품질 문제가 각기 다른 여러 타입의 데이터가 존재함. 예) 연합 데이터(Federated data), 고차원 데이터(High dimensional data), 서술 데이터(Descriptive data), 장기 데이터(Longitudinal data), 스트리밍 데이터, 웹 스크랩 데이터(Web scraped data), 수치 vs. 범주 vs. 텍스트 데이터
• 데이터의 용도가 다양. 예) 오퍼레이션, Aggregate 분석, 고객 관계(Customer relations)
• 데이터 해석(Data Interpretation): 데이터의 뒤에 깔린 모든 규칙을 알고 있지 않는 한 해당 데이터가 쓸모 없음
• 데이터 적합성(Data Suitability): 가용 데이터로부터 원하는 답을 얻을 수 있는가(대리 데이터 사용, 관련 데이터의 분실)

데이터 품질 제약(Data Quality Constraints)

• 많은 데이터 품질 문제가 스키마에 기반한 정적 제약(static constraints)에 의해 캡쳐 될 수 있음. 예, null 허용 안됨, 필드 도메인, 외래키 제약 등
• 또 다른 많은 데이터 품질 문제가 작업 흐름(workflow) 상의 문제 때문이며 동적 제약에 의해 캡쳐 될 수 있다. 예, $200를 넘는 주문은 Biller 2에 의해 처리됨
• 제약이 ‘80-20 규칙’을 따른다. 즉, 몇몇 제약이 대부분의 경우를 캡쳐하며, 남은 몇몇 경우를 캡쳐하기 위해 수천 개의 제약이 요구됨

기술적 접근 방법(Technical Approaches)

데이터 품질 문제에서 한 가지 방법으로 모든 문제를 해결할 수는 없으며 다각적인 접근 방법이 필요하다.

• 프로세스 관리(Process management): 적절한 절차를 보증
• 통계(Statistics): 분석에 집중. 데이터에 있는 이상(anomalies)을 찾아서 수정함
• 데이터베이스(Database): 관계(relationships)에 집중. 일관성을 보증
• 메타데이터/도메인 전문 지식: 무엇을 의미하는가? 해석(Interpretation)

프로세스 관리(Process Management)

데이터 품질을 장려하는 비즈니스 프로세스로 아래와 같은 것들이 있다.

• 품질 문제를 돈으로 환산
• 내용과 형식의 표준화
• 데이터를 한번만 정확하게 입력
• 자동화
• 책임 할당: 데이터 스튜어드(data stewards)
• 엔드-투-엔드 데이터 감사 및 리뷰
• 데이터 모니터링
• 데이터 퍼블리싱(Data Publishing): DB 내용을 쉽게 접근/이해 가능한 형태로 가용하게 함
• 피드백 루프(Feedback loops): 데이터 프로세싱 시스템이 종종 오픈 루프 시스템으로 여겨짐. 의도와 실제의 차이를 찾기 위해 시스템을 모니터하고, 피드백 루프에서 이전 컴포넌트의 동작을 바로잡는다.

통계적 접근 방법(Statistical Approaches)

데이터 품질을 위한 방법이 따로 존재하는 것은 아니며, 신중하게 설계된 실험으로부터 수집된 전통적인 통계 데이터가 종종 분석에 사용된다. 데이터의 이상을 찾고 수정하는데 적용될 수 있는 기존 방법이 아래 4개 범주로 나뉨

• 분실된, 불완전한, 모호한, 훼손된 데이터. 예) truncated 또는 censored 데이터
• 의심스러운 또는 비정상 데이터. 예) outliers
• 모델로부터의 일탈에 대한 테스팅
• 적합도(Goodness-of-fit)

분실 데이터(Missing Data)

• 값, 애트리뷰트, 전체 레코드, 전체 섹션이 분실됨. 이로 인해 왜곡된 결과나 bias가 생기는 문제가 있음
• 공공연한 분실 데이터의 발견 방법:
  - 데이터 명세를 데이터와 매치시킴(모든 애트리뷰트가 존재하는가?)
  - 개별 레코드를 스캔(갭이 있는가?)
  - 개략적 체크(파일 수, 파일 크기, 레코드 수, 중복의 수)
  - 추정치(평균, 빈도, 중앙값)를 예상 값 및 경계와 비교, 집계(aggregates)가 잘못될 수도 있으므로 다양한 수준의 입도(granularity)를 체크
• 데이터의 숨은 훼손 발견 방법:
  - 값이 truncated 또는 censored 된 경우 분포도와 히스토그램에서 치솟은 부분(spikes)과 움푹 꺼진 부분(dips) 체크
  - 값의 분실과 디폴트의 분실을 구별할 수 없는 경우 너무 많은 분실 데이터가 있는지 확인, 메타데이터 또는 도메인 전문 지식이 도움이 될 수 있음
  - 생략 에러(예, 특정 지역으로부터의 모든 통화가 분실됨)의 경우 데이터가 무작위로 분실되었는지 아니면 어떤 식으로 국한되어 있는지 체크

Censoring과 Truncation

• Censored: 예, 통화 길이가 >20이면 20초로 기록됨
• Truncated: 예, 매 달 2분 이하 통화 고객은 탈락시킴
• 만일 censoring/truncation 메카니즘이 알려지지 않았다면 분석이 부정확하거나 편향(biased)될 수 있음. 반면 메커니즘을 알고 있다면 분석에서 bias를 완화시킬 수 있음
• 메타데이터가 censoring/truncation의 존재뿐만 아니라 그 성격도 기록해야 한다.

의심스런 데이터(Suspicious Data)

• 데이터 포인트 3, 4, 7, 4, 8, 3, 9, 5, 7, 6, 92에서 “92”가 의심스러운 특이값(an outlier)
• 이런 특이값이 정당할 때도 있지만 종종 데이터 글리치 또는 모델 글리치이다.
• Outlier를 “예상으로부터의 일탈(departure from the expected)”로 정의
• 여러 방법이 존재함
  - 에러 경계, 허용 한계: 콘트롤 차트
  - 모델 기반: 회귀 깊이(regression depth), 잔여 분석(analysis of residuals)
  - 기하학적 특이값(Geometric Outliers)
  - 분포상의 특이값(Distributional Outliers)
  - 시계열 특이값(Time Series Outliers)

데이터베이스 도구(Database Tools)

대부분의 데이터베이스 관리 시스템(DBMS)이 많은 데이터 일관성 도구를 제공한다.

• 트랜잭션
• 데이터 타입
• 도메인: 필드 값의 제한된 셋
• 컬럼 제약(Not Null, 유일 값), 테이블 제약(일차키와 외래키 제약)
• 강력한 쿼리 언어
• 트리거(Triggers)
• 타임스탬프(Timestamps), temporal DBMS

 

그럼에도 DB가 깨끗하지 않은 이유로 아래와 같은 것들이 있다.
- 일관성 제약이 종종 사용되지 않음(비용, 유연성, 제약에 대한 이해 부족 등이 이유)
- 쓰레기 데이터가 입력됨(병합/연합/웹 스크랩 DB에서)
- 발견 불가능한 문제(부정확한 값, 분실된 데이터)
- 메타데이터가 유지 안됨
- DB가 이해하기에 너무 어려움

왜 도메인 전문 지식(Domain Expertise)이 중요한가?

• 데이터와 문제를 이해하고 결과를 해석하는데 중요. 예) “통화 수가 N을 넘으면 카운터가 0으로 리셋된다.” “분실된 값이 0으로 표현되지만 디폴트 청구 금액 또한 0이다.”
• 불충분한 도메인 지식은 낮은 데이터 품질의 주 원인(데이터를 사용할 수 없음)
• 도메인 전문 지식이 메타데이터로써 문서화되어야 함

도메인 전문 지식은 어디에 있는가?

• 대개 사람들 머리 속에(문서화되는 경우가 드물다)
• 여러 조직에 걸쳐 조각 조각 퍼져 있음(종종 전문가들의 의견이 일치하지 않으며 강제적인 합의가 요구됨)
• 인력이나 프로젝트의 교체/변천에 따라 소실됨
• 문서화되지 않으면 시간 경과에 따라 저하되고 흐릿해짐

메타데이터(Metadata)

• 데이터에 대한 데이터(Data about the data)
• 데이터 타입, 도메인, 제약이 도움이 되지만 종종 충분하지 않음
• 값의 해석(스케일, 측정 단위, 레이블의 의미), 테이블의 해석(리프레시 빈도, associations, 뷰 정의), 그리고 데이터 셋 해석을 위한 프로그램을 포함할 수 있음
• 대부분의 메타데이터가 정적 속성(데이터베이스 스키마, 필드 해석)에 관련되지만, 데이터 사용과 해석이 동적 속성(비즈니스 프로세스가 무엇인가, 80-20 규칙) 또한 요구함