페이퍼요약 - 데이터 클리닝 문제와 현 접근방법 by Rahm

제목: 데이터 클리닝 문제와 현 접근방법(Data Cleaning: Problems and Current Approaches)

저자: Erhard Rahm 외 1인, 독일

문서유형: 학계 페이퍼(총 11페이지), 2000년

 

데이터 클리닝에서 다루어야 할 데이터 품질 문제를 분류하고 데이터 클리닝 방법을 기술한 자료

---

데이터 클리닝(Data cleaning)

• 데이터의 품질을 향상하기 위해 데이터로부터 에러나 비일관성을 발견하고 제거하는 작업으로 데이터 클린징(data cleansing) 또는 스크러빙(scrubbing)으로도 불림
• 데이터 클리닝은 이질적인 데이터 소스(heterogeneous data sources)를 통합할 때 특히 요구되며 스키마 관련 데이터 변환(schema-related data transformations)과 함께 다루어져야 함
• 데이터 입력 시 오타, 정보 누락, 기타 유효하지 않은 데이터로 인해 단일 데이터 모음(예, 파일, 데이터베이스)에서도 데이터 품질 문제가 존재함
• 여러 다른 데이터 소스가 통합되는 경우(예, 데이터 웨어하우스, 통합 데이터베이스 시스템, 글로벌 웹 기반 정보 시스템) 소스가 종종 표현 방식이 다른 중복 데이터를 포함할 수 있기 때문에 데이터 클리닝의 필요성이 급격히 증가함. 특히, 데이터 웨어하우스에서 데이터 클리닝은 ETL 프로세스의 주요 부분이다.

데이터 웨어하우스에서 데이터 클리닝

• 데이터 웨어하우스는 다양한 소스로부터 대량의 데이터를 로드하고 지속적으로 리프레시(refresh)하므로 소스가 “더티 데이터(dirty data)”를 포함할 확률이 높음(즉, 데이터 클리닝이 요구됨)
• 가능한 데이터 불일치가 광범위하고 데이터 양도 대규모이기 때문에 데이터 클리닝은 데이터 웨어하우싱에서 가장 큰 문제 중 하나로 여겨짐
• 아래 그림은 데이터 웨어하우스의 ETL(extraction, transformation, loading) 프로세스를 나타냄. 대개 모든 데이터 클리닝이 변환된 데이터(transformed data)를 웨어하우스에 로딩하기 전에 별도의 ‘데이터 스테이징 영역(Data staging area)’에서 수행됨
• 아래 작업들을 지원하기 위한 다양한 기능을 가진 많은 도구가 가용하지만, 클리닝과 변환 작업의 주요 부분이 종종 수작업에 의해서 또는 작성/유지보수가 어려운 저레벨 프로그램(low-level programs)에 의해서 수행되어야만 함

[데이터 웨어하우스를 구축하는 단계: ETL 프로세스]

데이터 클리닝 문제(Data cleaning problems)

• 데이터 클리닝(data cleaning)과 데이터 변환(data transformation)에 의해 해결되어야 할 주요 데이터 품질 문제를 아래 그림처럼 분류함
• 데이터 변환은 데이터의 구조/표현/콘텐츠 상의 어떤 변경을 지원하기 위해 필요. 이런 변환은 많은 상황(예, 스키마 진화, 레가시 시스템을 신규 정보 시스템으로 마이그레이션, 다수의 데이터 소스를 통합)에서 필수적이다. 

[데이터 품질 문제 분류]

1. 단일 소스 문제(Single-source problems)

• 단일 소스의 데이터 품질은 허용되는 데이터 값을 통제하는 스키마와 무결성 제약(integrity constraints)에 크게 의존함. 스키마가 없는 소스(예, 파일)는 입력 및 저장되는 데이터에 제약이 거의 없어서 에러와 불일치의 가능성이 높아짐. 반면 데이터베이스 시스템은 애플리케이션 고유의(application-specific) 무결성 제약뿐만 아니라 특정 데이터 모델의 제약(예, 관계 모델의 단순 애트리뷰트 값, 참조 무결성)이 허용 가능한 데이터를 제한함
• 스키마 레벨 데이터 품질 문제는 모델 고유의 무결성 제약이나 애플리케이션 고유의 무결성 제약이 결여되어서 발생함. 인스턴스 레벨 데이터 품질 문제는 스키마 레벨에서 예방될 수 없는 에러나 불일치와 관련됨(예, 오자)

범위/문제		더티 데이터	이유
애트리뷰트	허용되지 않는 값	bdate=30.13.70	도메인 범위 밖의 값
레코드	애트리뷰트 종속성 위반	age=22, bdate=12.02.70	age = (current date – birth date)에 부합하지 않음
레코드 타입	유일성 위반	emp1=(name=”John Smith”, SSN=”123456”) emp2=(name=”Peter Miller”, SSN=”123456”)	사회보장번호(SSN)의 고유성 위반. 즉, 동일한 SSN을 가진 한 명 이상이 존재
소스	참조 무결성 위반	emp=(name=”John Smith”, deptno=127)	참조된 부서(127)가 정의되지 않음

[스키마 레벨에서 단일 소스 문제 예: 무결성 제약 위반]

범위/문제		더티 데이터	이유
애트리뷰트	값 누락	phone=9999-999999	데이터 입력으로 가용하지 않은 값(더미 또는 널 값)
	오자	city=”Liipzig”	대개 오타, 발음 에러
	암호 값, 약어	experience=”B”; occupation=”DB Prog.”	공통적으로 알기(이해하기) 어려운 값
	내포된 값	name=”J. Smith 12.02.70 New York”	하나의 애트리뷰트에 여러 값이 입력됨(예, 자유입력형식 필드에서)
	필드 위치가 틀린 값	city=”Germany”	국가 필드로 들어가야 할 데이터가 도시에 위치
레코드	애트리뷰트 종속성 위반	city=”Redmond”, zip=77777	도시와 우편번호가 상응해야 함
레코드 타입	단어 전위	name1= “J. Smith”, name2=”Miller P.”	대개 자유입력형식 필드에서
	중복 레코드	emp1=(name=”John Smith”,...); emp2=(name=”J. Smith”,...)	데이터 입력 에러로 동일 직원이 두 번 표현됨
	상충 레코드	emp1=(name=”John Smith”, bdate=12.02.70); emp2=(name=”John Smith”, bdate=12.12.70)	동일한 실 세계 엔터티가 각기 다른 값에 의해 기술됨
소스	잘못된 참조	emp=(name=”John Smith”, deptno=17)	참조된 부서(17)가 정의되었지만 부정확함

[인스턴스 레벨에서 단일 소스 문제 예]

2. 다수 소스 문제(Multi-source problems)

• 단일 소스에 존재하는 문제들이 다수의 소스가 통합될 필요가 있을 때 더 악화됨. 각 소스가 더티 데이터를 포함할 수도 있으며, 특정 니즈(needs)를 위하여 독립적으로 개발된 각 소스의 데이터가 다르게 표현되거나, 중복되거나, 상충할 수도 있음
• 다수 소스로부터의 데이터를 클리닝하는데 있어 주된 문제는 중복 데이터(특히, 동일한 실 세계 엔터티를 가리키는 레코드들)를 식별하는 것임. 흔히 정보가 부분적으로만 중복인 경우가 있어서(즉, 동일한 하나의 엔터티에 대한 추가적인 정보를 제공하면서 소스들이 서로를 보완하는 상황) 중복 정보는 제거하고 보완 정보는 통합할 필요가 생김
• 아래 두 개 소스는 모두 관계형(relational)이지만 스키마 충돌과 데이터 충돌이 나타남
  - 스키마 레벨에서 이름 충돌(Customer/Client, Cid/Cno, Sex/Gender)과 구조적 충돌(name과 address의 표현 방식이 각기 다름)이 존재
  - 인스턴스 레벨에서 다른 방식의 성별 표현(“0”/”1” vs. “F”/”M”)과 중복 레코드(Kristen Smith)가 존재
  - Cid/Cno는 둘 다 소스 고유의 식별자지만 그 콘텐츠는 소스 간에 비교 가능하지 않음. 각각 다른 번호(11/493)가 동일인을 지칭하고 동일 번호(24)는 각각 다른 사람을 나타냄
• 이런 충돌 문제를 해결하려면 스키마 통합과 데이터 클리닝 둘 다가 필요함(아래 세 번째 테이블은 가능한 솔루션 예). 데이터 클리닝을 허용하기 위해서는 스키마 충돌(특히, 하나의 통일된 표현 방식에 기반한 name과 address의 중복 레코드 발견, Gender/Sex 값의 매칭)이 먼저 해결되어야 한다.

[스키마 레벨과 인스턴스 레벨에서의 다수 소스 문제 예]

데이터 클리닝 방법(Data cleaning approaches)

통상적으로 데이터 클리닝은 아래의 여러 단계를 포함한다.

• 데이터 분석(Data analysis): 어떤 종류의 에러와 불일치가 제거되어야 하는지 발견하기 위해 상세한 데이터 분석이 요구됨. 데이터(또는 데이터 샘플)의 수작업 검사에 더불어 데이터 속성(data properties)에 대한 메타데이터를 얻고 데이터 품질 문제를 발견하기 위한 분석 프로그램이 사용되어야 함
• 변환 작업흐름과 매핑 규칙 정의(Definition of transformation workflow and mapping rules): 데이터 소스의 수, 소스 간의 이질성 정도, 데이터의 불순도(dirtiness)에 따라 많은 단계의 데이터 변환/클리닝이 실행될 필요가 있을 수 있음
• 검증(Verification): 변환 작업흐름과 변환 정의의 정확성과 효과성이 샘플(또는 소스 데이터 복사본)에서 테스트되고 평가되어야 함. 일부 에러는 특정 변환을 적용한 후에야 비로소 명백해지므로 분석/설계/검증 단계가 여러 번 반복될 필요가 있을 수 있다.
• 변환(Transformation): 변환 단계(transformation steps)들을 실행함
• 정제된 데이터의 역흐름(Backflow of cleaned data): 에러가 제거된 후 정제된 데이터(cleaned data)가 원래 소스의 더티 데이터를 대체해야 함(레가시 애플리케이션이 개선된 데이터를 가지도록 하기 위해 그리고 향후 데이터 추출 시 클리닝 작업을 다시 반복하는 것을 피하기 위한 목적). 데이터 웨어하우싱의 경우 정제된 데이터가 데이터 스테이징 영역에서 가용함

1) 데이터 분석(충돌 발견)

• 스키마에 반영된 메타데이터는 대개 소스의 데이터 품질을 평가하기에 불충분하므로 데이터 특징이나 일반적이지 않은 값 패턴에 대한 메타데이터를 얻기 위해 실제 인스턴스를 분석하는 것이 중요함. 이 메타데이터는 데이터 품질 문제를 찾는데 도움이 되며, 특히 소스 스키마들 간의 애트리뷰트 상응성(스키마 매칭)을 식별하는데 효과적이어서 이에 기반하여 자동 데이터 변환이 도출될 수 있음
• 데이터 분석을 위한 관련 방법으로 데이터 프로파일링(data profiling)과 데이터 마이닝(data mining)의 두 가지가 존재
  - 데이터 프로파일링은 개별 애트리뷰트의 인스턴스 분석에 집중하며, 데이터 타입, 길이, 값 범위, 이산 값과 그 빈도, 분산, 유일성, 널 값 발생, 전형적인 스트링 패턴 같은 정보를 도출하여 애트리뷰트의 여러 품질 측면에 대한 정확한 뷰를 제공함(아래 표는 이런 메타데이터가 어떻게 데이터 품질 문제 발견에 도움이 되는지를 보여주는 예)
  - 데이터 마이닝은 대규모 데이터 셋에서 특정 데이터 패턴의 발견을 돕는다(예, 여러 애트리뷰트들 간에 존재하는 관계). 클러스터링, 총괄(summarization), 연관성 발견(association discovery), 순차성 발견(sequence discovery) 등의 마이닝 모델이 활용됨. 예를 들어, 높은 신뢰수준(confidence)을 가진 특정 관련성 규칙(an association rule)이 해당 규칙을 위반하는 인스턴스의 데이터 품질 문제를 암시할 수 있음. 즉, 99% 신뢰수준의 규칙 “total=quantity*unit price”는 레코드의 1%가 규칙에 부합하지 않으며 자세한 조사가 필요함을 나타냄

문제	메타데이터	예/휴리스틱
허용되지 않는 값	카디널리티(cardinality)	예, 카디널리티(성별) > 2는 문제를 암시
	최소값, 최대값	최대값, 최소값이 허용가능 범위 밖이면 안됨
	분산(variance), 편차(deviation)	통계 값의 분산 및 편차가 한계치(threshold)보다 높으면 안됨
오자	애트리뷰트 값	값들을 정렬하면(sorting) 종종 오자 값이 정확한 값 옆에 나타나 눈에 뜀
누락 값	널 값(null values)	널 값의 퍼센티지와 수
	애트리뷰트 값+디폴트 값	디폴트 값의 존재가 실제 값이 누락됨을 암시할 수 있음
값의 표현 방식이 제각각	애트리뷰트 값	한 테이블의 컬럼의 애트리뷰트 값 집합을 다른 테이블의 컬럼의 애트리뷰트 값 집합과 비교
중복	카디널리티+유일성	애트리뷰트 카디널리티 = # rows가 참(true) 이여야 함
	애트리뷰트 값	값을 발생 횟수에 의해 정렬, 한 번 이상 나오면 중복 레코드를 나타냄

[데이터 품질 문제를 찾기 위해 리엔지니어된 메타데이터 사용 예]

2) 데이터 변환 정의하기(Defining data transformations)

• 데이터 변환 프로세스는 대개 여러 단계로 구성된다(각 단계에서 스키마 관련 또는 인스턴스 관련 변환/매핑이 수행됨).
• 변환 코드를 생성하기 위해서는(즉, 직접 프로그래밍하는 양을 줄임) 요구되는 변환을 적절한 언어로 명세하는 것이 필수적. 다양한 ETL 도구가 나름의 룰 기반 언어(proprietary rule languages)를 지원하여 이런 기능을 제공하지만 더 일반적인 방법은 표준쿼리언어(SQL)와 SQL:99에서 지원되는 사용자정의기능(UDF)을 사용하는 것임
• 아래는 SQL:99로 명세된 변환 단계의 예로 앞에 나온 다수 소스 문제 예의 첫 번째 소스(Customer)에 적용되는 필수 데이터 변환의 일부를 나타냄
  - 이 변환은 추가적인 매핑이 수행될 수 있는 뷰(view)를 정의함. 즉, 소스의 name과 address 애트리뷰트를 쪼개어 얻은 뷰에서 추가 애트리뷰트를 가지고 스키마 재구조화를 하며, 이 때 요구되는 데이터 추출은 굵은 글씨로 표현된 UDF를 통해 수행함
  - 이 UDF 구현에 클리닝 로직(예, 도시명에서 오자를 제거, 누락된 우편번호 채워 넣기)이 포함될 수 있음 

[변환 단계 정의 예]

3) 충돌 해결(Conflict resolution)

• 단일 소스의 데이터 품질 문제를 해결하고 타 소스와 통합을 준비하기 위해 개별 데이터 소스 상에 여러 타입의 변환이 수행됨. 이 사전 준비 단계들은 스키마 변환에 더불어 대개 아래를 포함한다.
  - 자유 형식 애트리뷰트로부터 값 추출(Extracting values from free-form attributes): 자유 형식 애트리뷰트가 종종 다수의 개별 값을 한꺼번에 캡쳐함. 이런 데이터들은 더 구체적으로 표현되고 정제 단계를 거치기 위해 추출되어야 함
  - 확인과 수정(Validation and correction): 이 단계는 데이터 입력 에러가 있는지 각 소스 인스턴스를 검토하고 가능한 자동으로 수정하려 노력함. 예, 사전 검색을 기반으로 한 철자 체킹, 지역명과 우편번호에 대한 사전을 활용하여 주소 데이터 수정, 애트리뷰트 의존성(예, 생일–나이, 총가격–단위가격ⅹ수량, 도시–전화지역번호)을 활용하여 틀린 값을 수정하고 누락 값을 채워 넣기
  - 표준화(Standardization): 인스턴스 매칭과 통합을 용이하게 하기 위해 애트리뷰트 값이 일관적이고 통일된 형식으로 전환되어야 함(예, 날짜와 시간을 특정 형식으로 통일, 이름과 기타 스트링 데이터를 대문자 또는 소문자로 전환). 텍스트 데이터는 잘라내기(stemming), 접두사/접미사/불용어 제거 등을 통해 압축되고 통일됨. 약어와 인코딩 체계는 특수한 동의어 사전을 의존하여 또는 사전 정의된 전환 규칙을 적용하여 일관적으로 해결되어야 함
• 다수 소스 문제를 해결하려면 스키마 통합을 위한 스키마 재구조화가 요구됨. 즉, 애트리뷰트와 테이블의 쪼개기(splitting)/병합(merging)/접기(folding)/펴기(unfolding) 등이 일어남
  - 스키마 레벨에서 이름 충돌(name conflicts)은 대개 재명명(renaming)에 의해 해결되고, 구조적 충돌(structural conflicts)은 부분적 재구조화(partial restructuring)와 입력 스키마의 병합(merging)을 요구함
  - 인스턴스 레벨에서는 충돌 표현(conflicting representations)과 중복 데이터(overlapping data)가 해결될 필요가 있음. 중복 제거 작업은 대개 대부분의 변환과 클리닝 단계가 수행된 후에(특히, 단일 소스 에러와 충돌 표현을 정제한 후에) 이루어짐