데이터 품질 문제(Data Quality Matters) - 분석기법

[기술적 해법(Technical Insights) | Data Quality Matters]

원문 출처: https://www.arbutussoftware.com/en/technical-insights/data-quality-management-0

모든 사람들이 "Garbage in, Garbage out"(GIGO)이라는 개념에 대해 들어보았지만, 우리 대부분에게 이것은 받아들여지기는 하지만 추상적인 개념입니다.

오늘 우리는 데이터 품질(Data Quality - DQ)을 더 자세히 살펴보고 GIGO 를 최소화하는 방법을 보여줄 것입니다.

** Garbage in, Garbage out"(GIGO): ‘쓸데없는 것이 입력되면, 출력되는 것도 쓸데없는 것뿐’이라는 뜻으로, 컴퓨터에 불완전한 데이터를 입력하면 불완전한 결과 값이 나올 수밖에 없다는 말.

데이터 품질 문제(Data Quality Matters)

문제점(The Problem)

이상적인 세상에서는, 모든 시스템에 가장 높은 수준(level)의 내장 DQ(Data Quality) 검사가 있지만, 슬프게도 이것은 거의 그렇지 않습니다. 여기에는 여러 가지 이유가 있을 수 있겠지만 다음과 같은 몇 가지 이유가 있습니다.

데이터가 폭발적으로 증가하면서 DQ(Data Quality)의 중요성에 대한 인식이 높아지고 있습니다. 이것은 종종 시스템이 오래될수록 데이터 검사의 품질이 떨어진다는 것을 의미합니다.

기존 시스템과 환경은 특히 취약합니다. 그 이유는 역사적으로 DQ에 대한 중요성이 낮았을 뿐만 아니라 적절하게 포괄적인 테스트를 구현하는데 필요한 리소스/컴퓨팅 능력도 제한되었을 수 있기 때문입니다.

현대 시스템을 취급하는 곳에서도 모든 것을 생각하기는 어렵습니다.

Date(날짜)와 같은 간단한 필드(field)를 생각해보십시오.

매우 오래된 날짜(1919년에 실제로 고객(customer)이 될 수 있었을까요?), 미래의 날짜 또는 단순히 유효하지 않은 날짜-invalid date("Unknown/알 수 없는" 또는 흔히 볼 수 있는 " / / ")와 같은 문제를 쉽게 생각해 볼 수 있습니다.

생각하기에 어렵지 않지만 간과할 수 있는 다양한 다른 상황들이 존재합니다.

주문(Order) 전에 배송된(shipped) 것처럼, 순서(sequencing)는 어떤가요?

Date format-날짜 형식(D/M/Y vs M/D/Y vs, Y/M/D) 또는 다른 입력 방법(slash vs. dot vs. dash)은 어떻습니까?

날짜 선택기(Date picker)는 이 이슈(issue)들에 대한 최신 접근 방식이지만, 레거시 환경에서는 사용하지 못할 수 있습니다.

더 어려운 이슈(issue)는 주말, 법정 공휴일 등과 같이. 업무를 하지 않는 경우일 수 있습니다.

시사점(The Implications)

여기에서 GIGO(Garbage in, Garbage out- 불완전한 데이터를 입력하면 불완전한 결과 값이 나올 수밖에 없다)가 고개를 듭니다.

잘못된 데이터(Bad data)는 사용자가 찾은 결과(result) 또는 해당 데이터를 기반으로 한 의사결정의 품질에 쉽게 영향을 미칠 수 있습니다.

앞서 언급한 바와 같이, 어떤 오류(error)가 향후 분석 및 의사결정에 영향을 미칠지 정확히 사전에 예측하는 것은 매우 어려운 일입니다. 이는 오늘날 우리가 살고 있는 빅 데이터(big data)의 역동적인 시대에 특히 그렇습니다.

아마도 내일의 작업은 해당 요일(the day of the week) 또는 시간(the time of day)을 기준으로 합니다.

이 데이터는 새로운 분석(analysis)이기 때문에 과거에 테스트되지 않았을 수 있습니다.

분석가(Analyst)가 작업을 시작할 때 직접 테스트(적절한 툴이 있는 경우)해 볼 수도 있지만, 데이터를 신뢰하고 그 데이터가 잘못된 경우 결과(result)가 손상될 수 있습니다.

데이터 품질(Data Quality)과 그 중요성

Date(날짜)는 하나의 예에 불과하지만, DQ를 조사할 수 있는 수준(level)를 보여줍니다.

시스템의 많은 데이터 요소는 동일한 깊이의 DQ 이슈(issue)를 가질 수 있으며, 실제로 거의 모든 데이터 요소는 DQ 개선을 위한 약간의 기회를 제공합니다. 또한 데이터의 용도는 시간이 지남에 따라 변한다는 점을 기억하는 것이 중요합니다.

시스템이 구현(implementing)되었을 당시에는 상대적으로 중요하지 않았던 것이 현재 분석에 매우 중요해질 수 있습니다. 시스템이 구현되었을 시점에는 영업일이 아닌 날에 거래(transaction)가 예약되었다는 것은 중요하지 않았을 수 있지만, 이제는 해당 부정(fraud)을 식별하는 것이 매우 중요합니다.

이러한 현상을 인지하는 것은 DQ 의 중요성에 대한 인식을 향한 첫 걸음입니다.

마지막으로, DQ 는 비용이 많이 들 수 있습니다.

DQ 에 대한 생각(및 구현-implementing)과 관련된 비용이 있을 뿐만 아니라 DQ 를 시행하는데 필요한 리소스에도 상당한 비용이 수반될 수 있습니다.

DQ 테스트 결과로 인해, 생산 프로세스(production process)가 두 배 느리게 실행되면 비즈니스에 상당한 영향을 미칠 수 있습니다.

어떠한 기업도 돈을 낭비하고 싶어하지 않으며, 심지어 DQ 조차도 비용/편익(cost/benefit) 분석의 대상이 됩니다.

이와 관련된 문제는 향후 데이터 사용과 관련된 후속 비용 및 편익(cost & benefit)이 구현 결정이 내려지는 시점에는 알 수 없다는 것입니다.

한가지 접근 방식 - 사후 테스트(Testing After the fact)

전사적인 데이터(Enterprise data)가 서로 다른 환경에서, 서로 다른 시간에, 서로 다른 직원에 의해 생성되는 다양한 시스템을 포함하고 있다는 점을 고려해 볼 때, 모든 시스템을 대상으로 적절한 수준(level)의 기본 DQ가 있을 것이라고 기대하는 것은 다소 순진(naïve)할 수 있습니다.

대신에, 강력한 접근 방식으로 사후 데이터(the data after the fact)를 테스트할 수 있습니다.

사후 테스트(Testing after the fact) 하는 것은 전후 사정을 다 파악할 수 있는 이점을 얻을 수 있습니다.

시스템이 구현(implement)될 때 모든 데이터 조각에 대한 모든 잠재적인 사용을 예상하는 대신, 지금 새로운 DQ 테스트를 설계 및 실행하고 현재 분석에 영향을 미치는 데이터 품질 이슈(data quality issue)를 식별할 수 있습니다.

또한 분석 요구 사항이 변경되면(DQ 기대치로 인해) 원본 소프트웨어를 업데이트하는 비용이 많이 드는 단계를 수행하지 않고도 이러한 새로운 요구 사항을 확인할 수 있습니다.

발견된 이슈(issue)에 대한 대응은 심각도에 따라 달라집니다.

문제(Problem)를 무시하거나, 데이터를 보정하거나, 원본 시스템을 업데이트하여 오류(error)를 허용하지 않도록 할 수 있습니다. 각 오류 타입은 분석에 고유한 영향을 미치지만, 문제(issue)가 있음을 인식하는 것이 첫 번째 단계입니다.

데이터 품질 구현(DQ Implementation)

적절하게 구현된 DQ 프로그램은 다음과 같습니다.

관리 정보(Management information) 목적의 중요한 데이터가 항상 깨끗한지(clean) 확인하기 위해, 모든 전사적 애플리케이션(enterprise applications)에 대한 데이터를 사전에 모니터링하고 데이터 품질 문제-data quality issues(적절한 빈도로)를 리포트
조직의 변화하는 요구 사항을 충족하도록 쉽게 업데이트
개선된 데이터 품질 탐지(data quality detection) 및 리포트를 통해 더 나은 정보 시스템(information systems)을 달성
신뢰할 수 있고 정확한 전사적인 데이터(enterprise data)를 사용하여 더 나은 비즈니스 의사 결정 및 결과(decisions & outcomes)를 달성

데이터 품질(Data quality)을 모니터링 하는 것이 여러분의 일이 아닐 수도 있지만, DQ 의 상태에 대해 리포트 하는 것은 여러분의 일이 될 수 있습니다.

올바른 도구(tools)를 사용하면 거의 모든 데이터 필드(data field)를 테스트하고, 데이터 품질 문제(data quality issues)를 적시에 식별하고 해결할 수 있습니다.

데이터가 깨끗(clean)하고, 깨끗하게 유지되도록 함으로써 GIGO 를 최소화하고 모든 사람이 데이터와 정확성을 신뢰할 수 있도록 돕습니다.

오류(Error)는 어디서?

DQ 를 테스트할 때 데이터 웨어하우스(DW) 또는 데이터 마트(data mart)와 같은 데이터 저장소(data repository) 또는 소스 데이터(source data) 자체라는 두 가지 주요 소스가 있는 경우가 대부분입니다.

둘 다 다 다르며, 둘 다 확인하는 것이 중요합니다.

DW 는 분명 'clean(깨끗)'해야 하지만, 깨끗하다고 해서 그것이 옳다는 것은 아닙니다.

저장소-Repository(ETL) 로드 시 오류(error)가 발생하면 소스 데이터 오류 또는 문제를 쉽게 가려(mask) 잘못된 DW 내용을 초래할 수 있습니다.

소스 데이터를 봐야만 데이터 품질(data quality)을 알 수 있습니다.

간단한 설명 예제가 도움이 될 수 있습니다.

DW 테이블에는 외부 시스템에서 생성된 고객(customer)과 관련된 성별(sex) 필드가 포함될 수 있습니다.

DW 필드를 로드하는 논리는 소스:sex="M"이면 DW:gender="M"이고 그렇지 않으면 DW:gender="F"인 것처럼 간단할 수 있습니다. (** Sex: 생물학적 기준의 성 구분. Gender: 사회성에 따른 성 역할 구분.)

이것은 DW 에서 분명히 깨끗한 데이터(clean data)를 보장하지만, 모든 오류(error)를 female(여성)으로 잘못 표시하여 DW 사용에 심각한 영향을 미칠 수 있습니다.

입력 당시에 알려지지 않았거나 단순히 오타가 있었는지 여부는 살펴보지 않는 한 소스 시스템에 무엇이 있는지 알 수 없습니다.

소스 데이터를 살펴보면, "M" 또는 "F"를 포함할 것으로 예상되는 단일 문자 필드(single character field)일 것입니다.

그러나 소스 시스템은 이 필드의 유효성(validate)을 검사하지 않으므로 "m", "?", "U" 또는 "L"과 같은 타입이 포함될 수 있습니다.

소스 시스템의 품질을 식별하는 것은 모든 DQ 실행의 기본입니다.

데이터 읽기(Reading the Data)

소스 데이터(Source data)는 전통적으로 액세스하기 어렵기 때문에 웨어하우스(warehouse)가 진화한 이유 중 하나입니다. 이것이 바로 Arbutus 의 독보적인 역량이 중요한 이유입니다.

Arbutus 는 시스템의 사용 기간이나 데이터의 복잡성에 상관없이 모든 소스 데이터에 액세스할 수 있는 제품군을 제공합니다.

Arbutus 기술은 모든 관계형 데이터베이스(relational database)와 호환될 뿐만 아니라 더 중요하게는 기본 메인프레임 애플리케이션(native mainframe application)을 통해 귀사의 메인프레임의 모든 레거시 데이터(legacy data)에도 액세스할 수 있습니다.

여기에는 VSAM, IMS, DB2, ADABAS 및 가변 레코드 길이(variable record length)와 여러 레코드 타입을 가진 VSAM 및 flat file 이 포함됩니다!

데이터 품질 정의(Data Quality Definition)

간단히 말해, 데이터 품질(DQ) 오류는 해당 항목이 명시적 또는 암시적(explicit or implicit) 메타데이터 정의(metadata definition)와 일치하지 않음을 의미합니다.

명시적 정의(Explicit definition)의 예는 데이터가 숫자(numeric)인 반면,

암시적 정의(implicit definition)의 예는 직원 연령 필드(employee age field)가 16세보다 작거나 70세보다 커서는 안 된다는 것입니다

두 가지 타입의 문제는 중요한 의미를 가질 수 있습니다.

데이터 품질 범주(Data Quality Categories)

DQ 오류에 대해 일반적으로 허용되는 IT 프레임워크는 다음과 같습니다.

IT Framework - DQ Implementation-2.jpg

정확하기는 하지만, 이러한 범주는 다소 추상적이라고 생각할 수 있습니다. 대신 다음과 같은 데이터 범주(data category)를 고려할 수 있습니다.

유효하지 않은(Invalid)
부적절한(Improper)
불완전한(Incomplete)
불일치한(Inconsistent)

데이터 품질(Data Quality) 예제

유효하지 않은 데이터(invalid data)는 정의된 필드(defined field) 타입과 일치(match)하지 않습니다.

데이터가 숫자(numeric)여야 하지만, 실제로 "UNKNOWN"이 포함된 경우 데이터는 유효하지 않은 데이터(invalid data)입니다.

아래의 경우 DateField(날짜 필드)에 잘못된 데이터가 있습니다. 공백 및 말도 안 되는 날짜가 감지되었습니다.

부적절한 데이터(Improper data)는 기술적으로 유효하지만, 예상되는 비즈니스 규칙과 일치(match )하지 않습니다.

필드(Field)가 비어(blank) 있거나, format 이 잘못되었거나(예: 전화번호), 고유하지 않거나(non-unique), 잘못 정렬(sort)되었거나, 기술적으로 유효하지만 필드에 적합하지 않은 문자-character(예: 주소의 경우 12345) 또는 너무 작거나 클 수(예: 나이/age) 있습니다.

불완전한 데이터(Incomplete data)는 모두 기술적으로 유효하지만 일부 상위 수준(higher-level)의 비즈니스 규칙을 위반합니다.

불완전한 데이터의 한 가지 예는 순차적 송장(sequential invoice) 또는 수표 번호(cheque number)입니다.

회사의 송장 번호(invoice number)는 공백(gap) 없이 연속적인 세트(continuous set)를 형성할 것이라고 예상해 볼 수 있습니다.

불완전한 데이터(Incomplete data)의 또 다른 일반적인 예는 key value(키 값)를 다른 테이블과 일치(matching)시키는 것과 관련됩니다.

예를 들어, 모든 고객 거래(customer transaction)에는 고객 마스터 파일(customer master file)에도 표시되는 고객 번호(customer number)가 있어야 합니다.

이러한 타입의 오류(error)를 식별하면 누락된 고객 마스터 레코드뿐만 아니라 거래(transaction) 또는 마스터 파일 키(master file key) 자체의 DQ 문제도 포착할 수 있습니다.

불일치 데이터(Inconsistent data)는 내부적으로 일치하지 않는 데이터가 포함됩니다.

이것은 값이 수량 곱하기 가격과 같지 않은(value <> quantity x price) 수량, 가격 및 값 필드(value field)를 포함하는 테이블(table)만큼 간단할 수 있습니다.

대부분의 다른 불일치(inconsistence) 예에는 테이블 간의 일치 데이터-matching data(key 서로 다른)가 포함됩니다.

동일한 값(value)이 두 개 이상의 테이블에 표시될 수 있으며, 한 테이블에서는 다를 수 있습니다. 또는 고객 거래(customer transaction)의 총계(total)는 고객 마스터-customer master YTD 총계(Year to Date Total)를 합산해야 하지만 그렇지 않습니다.

** YTD 총계(Year to Date Total): 특정 시점을 기준으로 해당 연도부터 그 시점까지 총계를 의미.

데이터 품질 검색(Data Quality Discovery)

자! 해봅시다(JUST DO IT)

어떤 범주(category)를 선호하든, Arbutus 를 사용하면 이러한 모든 특성을 완벽하게 테스트하고, 진행 중인 테스트를 자동으로 예약(automatically schedule)할 수 있습니다.

적절한 프로세스를 통해 시간이 지남에 따라 더 신뢰할 수 있고 정확한 데이터(trusted & accurate data)를 일관되게 확보할 수 있을 뿐만 아니라, 지속적이고 시기 적절한 발견(finding)을 통해 전반적인 정보 시스템(information systems)을 개선할 수 밖에 없습니다.

DQ 탐색(DQ DISCOVERY)

마지막으로 언급할 가치가 있는 영역은 일부 조직이 모든 데이터 요소에 대한 메타데이터(metadata)를 공식화(formalized)했지만 대부분 조직에서는 그렇지 않다는 것입니다.

공식화된 규칙(Formalized rule)이 있는 경우, 테스트는 거의 점검 목록(check-list)이 될 수 있습니다.

공식화된 메타데이터를 완전하게 보유하지 않은 대부분의 조직에서는, DQ는 규칙을 "discover(탐색)"하기 위해 대화형 프로세스를 사용할 수 있습니다.

공식화된 규칙을 가지고 있더라도, 메타데이터의 인스턴스(instances of metadata) 중 완전하고 최신인 것은 거의 없기 때문에 탐색 프로세스(discovery process)가 매우 유용할 수 있습니다.

규칙을 탐색할 때, 데이터만 보고 문제(issue)를 알 수도 있지만, 결과(result)를 빠르게 산출하는 체계적인 접근 방식이 종종 있습니다. 여기에는 다음이 포함됩니다.

Outliers(이상치):

Classify(분류)와 같은 command(명령)를 사용하면 테이블에서 공통 값(common value)을 빠르게 식별할 수 있습니다. 그보다 더 중요한 것은 흔하지 않은 값(the least common values)을 식별할 수 있다는 것입니다. 오류가 숨어 있는 곳이 될 수 있습니다.

Sorting(정렬):

Arbutus 에서는 마우스 오른쪽 버튼을 클릭하기만 하면 sorting(정렬)이 매우 쉽습니다. 작업이 완료되면, 각 열(column)에 대한 최고값과 최저값(the highest and lowest values)을 살펴볼 수 있습니다. 다시 말하지만, 극단적인 데이터는 부정확할 가능성이 더 높습니다.

Formatting(포맷):

데이터가 알려진 format(예: 북미 전화번호 "(999) 999-9999")을 가질 것으로 예상되는 경우, Format function(포맷 함수)을 사용하여 데이터를 쉽게 테스트할 수 있습니다.

"Format(fieldname)"인 테이블에 열(column)을 추가하기만 하면 됩니다.

그런 다음 이 필드(field)에서 Classify(분류)를 수행하여 각 데이터 요소의 format 을 기반으로 outliers(이상치)를 찾을 수 있습니다.

다른 기술들과 마찬가지로, 아주 흔하지 않은 포맷(the least common formatting)은 정의(definition)가 잘못되었거나 오류(error)가 발생할 가능성이 더 높습니다.

모든 탐색 프로세스(discovery process)에서 중요한 부분은 메타데이터(metadata)에 대한 피드백 루프(feedback loop)입니다. 문제를 찾으면 정의(definition) 상 일부 비즈니스 규칙을 위반하는 것입니다.

나중에 이를 포착하기 위해 자동화 테스트(automated testing)에 이것을 추가하고 싶을 것입니다.

이러한 모든 규칙이 공식적으로 명시되어 있어야 DQ 인프라를 개선할 때 데이터에 대해서도 학습할 수 있습니다.

** Feedback Loop: 출력된 데이터가 다음 출력되는 데이터에 영향을 끼치는 구조를 의미합니다.