데이터 품질 프로세스를 구현하는 방법

데이터 웨어하우스 시스템의 데이터 품질(DQ)은 점점 더 중요해지고 있습니다. 규제 요구 사항이 증가할 뿐만 아니라 데이터 웨어하우스 솔루션의 복잡성이 증가함에 따라 기업은 데이터 품질 이니셔티브를 강화(또는 시작)해야 합니다.

이 기사의 주요 초점은 "전통적인" 데이터 웨어하우징에 있지만 데이터 레이크와 같은 보다 "현대적인" 개념에서는 데이터 품질도 문제입니다. 데이터 품질 전략을 구현할 때 고려해야 할 몇 가지 주요 사항과 피해야 할 몇 가지 일반적인 함정을 보여줍니다. DQ 프레임워크를 구축하는 데 적합한 기술/도구를 선택하는 부분은 다루지 않습니다.

DQ 프로젝트의 가장 방해가 되는 문제 중 하나는 첫눈에 추가 기능을 제공하지 않고 비즈니스 단위에 많은 작업을 생성한다는 사실입니다. 데이터 품질 이니셔티브에는 일반적으로 다음과 같은 경우에만 강력한 지지자가 있습니다.

• 비즈니스에 심각한 영향을 미치는 데이터 품질 문제가 있습니다.
• 규제 기관은 데이터 품질 표준을 시행합니다(예: 금융 산업의 BCBS 239).

DQ의 처리는 소프트웨어 개발의 테스트와 유사합니다. 프로젝트에 시간 및/또는 예산이 부족하면 이 부분이 먼저 축소되는 경향이 있습니다.

물론 이것이 진실의 전부는 아닙니다. 우수한 데이터 품질 시스템은 오류를 조기에 감지하여 사용자에게 "충분히 좋은" 품질의 데이터를 제공하는 프로세스를 가속화합니다.

용어 정의

주제를 논의하기 전에 사용된 용어에 대한 일반적인 이해가 중요합니다.

데이터 웨어하우스(DWH)

데이터 웨어하우스(DWH)는 주로 의사 결정 지원에 사용되는 비운영 시스템입니다. 운영 체제의 데이터(모두 또는 더 작은 하위 집합)를 통합하고 DWH 시스템 사용자에게 쿼리 최적화 데이터를 제공합니다. 데이터 웨어하우스는 기업 내에서 "단일 버전의 진실"을 제공해야 합니다. 데이터 웨어하우스는 일반적으로 다음과 같은 단계/계층으로 구성됩니다.

운영 데이터는 대부분 변경되지 않고 스테이징 계층 에 저장됩니다. 코어 레이어 에는 통합 및 통합 데이터가 포함됩니다. 다음 선택적 단계는 파생 데이터(예: 판매에 대한 고객 점수) 및 집계를 제공하는 파생 영역 입니다. 데이터 마트 계층 에는 주어진 사용자 그룹에 최적화된 데이터가 포함됩니다. 데이터 마트에는 종종 집계와 많은 파생 메트릭이 포함됩니다. 데이터 웨어하우스 사용자는 종종 데이터 마트 계층에서만 작업합니다.

각 단계 사이에서 일종의 데이터 변환이 발생합니다. 일반적으로 데이터 웨어하우스는 운영 데이터의 델타 추출과 함께 주기적으로 로드되며 기록 데이터를 유지하는 알고리즘을 포함합니다.

데이터 품질

데이터 품질은 일반적으로 제품이 사용자 요구 사항을 얼마나 잘 충족하는지에 대한 메트릭으로 정의됩니다. 사용자마다 제품에 대한 요구 사항이 다를 수 있으므로 구현은 사용자의 관점에 따라 다르며 이러한 요구 사항을 식별하는 것이 중요합니다.

데이터 품질은 데이터가 완전히 또는 거의 오류가 없어야 함을 의미하는 것이 아니라 사용자의 요구 사항에 따라 다릅니다. "충분히 좋은" 접근 방식은 시작하기에 좋은 선택입니다. 요즘 대기업들은 '데이터(또는 정보) 정부 정책'을 갖고 있으며 데이터 품질도 그 일부다. 데이터 정부 정책 은 회사에서 데이터를 처리하는 방법과 데이터의 품질이 올바른지, 데이터 개인 정보 보호 규칙 이 위반되지 않도록 하는 방법을 설명해야 합니다.

데이터 품질은 지속적인 주제입니다. DQ 회로 루프를 구현해야 합니다(다음 장 참조). 규제 요구 사항 및 준수 규칙은 개인 정보 보호 문제에 대한 유럽의 TCPA(미국 전화 소비자 보호법) 또는 GDPR과 같이 필요한 데이터 품질에 영향을 미칠 뿐만 아니라 EU의 보험에 대한 Solvency II, BCBS 239와 같은 산업별 규칙에도 영향을 미칩니다. 기타 은행업 등.

데이터 품질 회로 루프

모든 품질 주제와 마찬가지로 DQ는 만족스러운 품질을 유지하기 위해 설계된 지속적인 활동입니다. DQ 프로젝트의 결과로 아래와 유사한 회로 루프 를 구현해야 합니다.

이 루프 내의 단계는 다음 장에서 설명합니다.

데이터 품질 역할

성공적인 DQ 이니셔티브를 구현하려면 다음 역할이 필요합니다.

• 데이터 소유자. 데이터 소유자는 데이터 품질뿐만 아니라 데이터 개인 정보 보호에 대한 책임도 있습니다. 데이터 소유자는 데이터 도메인을 "소유"하고 액세스를 제어하며 데이터 품질을 보장하고 발견 사항을 수정하기 위한 조치를 취할 책임이 있습니다. 대규모 조직에서는 여러 데이터 소유자를 찾는 것이 일반적입니다. 데이터 도메인은 예를 들어 마케팅 데이터, 제어 데이터 등이 될 수 있습니다. 회사에 둘 이상의 데이터 소유자가 있는 경우 전체 데이터 품질 프로세스를 책임지는 한 사람(데이터 소유자 또는 다른 사람)이 있어야 합니다. 데이터 소유자는 데이터 품질을 시행하고 DQ 프로세스를 지원할 강력한 권한이 있어야 합니다. 따라서 데이터 소유자는 종종 고위 이해 관계자입니다. 좋은 의사 소통 기술과 함께 비즈니스 영역에 대한 좋은 이해가 중요합니다.
• 데이터 스튜어드. 데이터 관리자는 데이터/데이터 모델, 데이터 품질 문제 등을 해석하는 방법에 대한 질문에 대해 데이터 사용자를 지원하여 기업 내 데이터 품질 구현을 돕습니다. 데이터 관리자는 종종 데이터 소유자의 직원이거나 데이터 품질 역량 센터에서 구성될 수 있습니다. 또는 DQ 팀. 데이터 관리자는 IT 또는 비즈니스 배경을 가질 수 있지만 양쪽 모두를 알고 있어야 합니다. 분석 기술은 지원하는 비즈니스 영역에 대한 충분한 이해와 강력한 의사 소통 기술이 결합되어 성공적인 데이터 관리자를 위한 주요 전제 조건입니다.
• 데이터 사용자. 이들은 데이터로 작업하는 데이터 웨어하우스 사용자입니다. 데이터 사용자는 일반적으로 데이터 마트 계층으로 작업하며 데이터 작업 결과에 대한 책임이 있습니다. 데이터 사용자는 필요한 품질 수준에 대해 적절한 데이터 품질 검사가 있는지 확인합니다. 데이터 사용자는 데이터, 비즈니스 도메인 및 데이터 해석에 필요한 분석 기술에 대한 강력한 이해가 필요합니다. 모든 사업부의 데이터 사용자 중에서 데이터 품질 문제를 담당할 소수의 사람을 찾는 것이 합리적입니다.

성공을 보장하려면 DQ 프로젝트의 초기 단계에서 이러한 역할을 명확하게 정의하고 조직 내에서 널리 받아들이 는 것이 중요합니다. 프로젝트를 지원하는 이러한 역할에 대해 유능한 데이터 전문가를 찾는 것도 마찬가지로 중요합니다.

규칙 정의

유용한 DQ 검사/규칙을 찾아 구현합니다. DQ 규칙을 정의하려면 데이터 웨어하우스와 그 용도를 잘 이해해야 합니다.

DQ 규칙을 찾는 방법?

앞서 논의한 바와 같이 데이터 사용자 (및 데이터 소유자)는 데이터 사용에 대한 책임이 있으므로 필요한 수준의 데이터 품질에 대해서도 책임이 있습니다. 데이터 사용자는 유용한 데이터 품질 규칙에 대한 최상의 입력을 제공할 수 있도록 데이터를 잘 이해해야 합니다.

그들은 데이터 품질 규칙의 결과를 분석하는 사람이기도 하므로 항상 자신의 규칙을 정의하도록 하는 것이 좋습니다. 이렇게 하면 데이터 사용자 단위에 할당된 DQ 규칙의 결과를 확인하고 평가하기 위한 승인이 더욱 향상됩니다("분석" 장 참조).

이 접근 방식의 단점은 데이터 사용자가 일반적으로 데이터 웨어하우스의 이전 계층이 아닌 데이터 마트 계층만 알고 있다는 것입니다. "하위" 단계에서 데이터가 손상된 경우 데이터 웨어하우스의 "상위" 계층만 확인하면 감지되지 않습니다.

오류 해결

데이터 웨어하우스에서 어떤 종류의 알려진 오류가 발생할 수 있습니까?

• 데이터 웨어하우스의 잘못된 변환 논리
  • IT 환경이 복잡할수록 변환 논리가 더 복잡해지는 경향이 있습니다. 이것은 가장 일반적인 DQ 문제이며 이러한 오류의 영향은 "손실" 데이터, 중복, 잘못된 값 등이 될 수 있습니다.
• 불안정한 로드 프로세스 또는 잘못된 로드 처리
  • 데이터 웨어하우스의 로드는 작업 오케스트레이션 정의에 오류를 포함할 수 있는 복잡한 프로세스일 수 있습니다(너무 일찍 시작하거나 너무 늦게 시작하는 작업, 실행되지 않은 작업 등). 수동 개입으로 인한 오류(예: 일부 작업을 건너뛰거나 일부 작업이 잘못된 기한으로 시작되거나 어제의 데이터 파일로 시작됨)는 로드 프로세스가 일부 중단으로 인해 대역 외에서 실행될 때 자주 발생합니다.
• 데이터 소스의 잘못된 데이터 전송
  • 데이터 전송은 종종 소스 시스템의 작업으로 구현됩니다. 작업 흐름의 이상 또는 중단으로 인해 비어 있거나 불완전한 데이터가 배달될 수 있습니다.
• 잘못된 운영 데이터
  • 운영 체제의 데이터에는 지금까지 인식되지 않은 오류가 있습니다. 이상하게 들릴 수 있지만 데이터 웨어하우스 프로젝트에서 데이터가 DWH에 포함될 때까지 운영 데이터의 품질이 종종 확인되지 않는다는 것은 진부한 일입니다.
• 데이터의 잘못된 해석
  • 데이터는 정확하지만 사용자는 올바르게 해석하는 방법을 모릅니다. 이것은 엄밀히 말하면 데이터 품질 문제가 아니라 데이터 거버넌스와 관련이 있고 데이터 관리자의 작업인 매우 일반적인 "오류"입니다.

이러한 문제는 종종 데이터 웨어하우스 솔루션을 정의, 구현, 실행 및 작업하는 데 적절한 노하우와 기술이 부족한 사람들로 인해 발생합니다.

데이터 품질 차원

DQ 차원 은 DQ 검사를 식별하고 클러스터링하는 일반적인 방법입니다. 많은 정의가 있으며 차원의 수는 상당히 다양합니다. 16개 또는 그 이상의 차원을 찾을 수 있습니다. 실용적인 관점에서 몇 가지 차원으로 시작하여 사용자 사이에서 이에 대한 일반적인 이해를 찾는 것이 덜 혼란스럽습니다.

• 완전성: 필요한 모든 데이터를 사용할 수 있고 액세스할 수 있습니까? 필요한 모든 소스를 사용할 수 있고 로드합니까? 단계 사이에 데이터가 손실되었습니까?
• 일관성: 오류/충돌/일관되지 않는 데이터가 있습니까? 예를 들어 "종료됨" 상태의 계약 종료 날짜에는 계약 시작 날짜보다 높거나 같은 유효한 날짜가 포함되어야 합니다.
• 고유성: 중복이 있습니까?
• 무결성: 모든 데이터가 올바르게 연결되어 있습니까? 예를 들어, 존재하지 않는 고객 ID에 연결되는 주문이 있습니까(고전적인 참조 무결성 문제)?
• 적시성: 데이터가 최신 상태입니까? 예를 들어, 매일 업데이트되는 데이터 웨어하우스에서 어제의 데이터를 오늘 사용할 수 있을 것으로 예상합니다.

데이터 웨어하우스 로드 프로세스 에서 생성된 데이터도 도움이 될 수 있습니다.

• 삭제된 데이터가 있는 테이블입니다. 데이터 웨어하우스에는 기술적인 문제(예: 형식 변환, 누락된 필수 값 등)로 인해 로드할 수 없는 데이터를 건너뛰거나 지연시키는 프로세스가 있을 수 있습니다.
• 로깅 정보. 눈에 띄는 문제는 로깅 테이블이나 로그 파일에 기록될 수 있습니다.
• 납품서. 일부 시스템은 운영 체제에서 제공하는 데이터에 대해 "배송 청구서"를 사용합니다(예: 레코드 수, 고유 키 수, 값 합계). 데이터 웨어하우스와 운영 체제 간의 조정 확인(아래 참조)에 사용할 수 있습니다.

각 데이터 품질 검사는 오류가 발견된 경우 최소 한 명의 데이터 사용자("분석" 장 참조)가 분석해야 하며, 구현된 모든 검사를 돌볼 수 있는 책임 있고 사용할 수 있는 사람이 필요합니다.

복잡한 데이터 웨어하우스 내에서 많은(때로는 수천) DQ 규칙이 생길 수 있습니다. 데이터 품질 규칙을 실행하는 프로세스는 이를 처리할 수 있을 만큼 충분히 빠르고 강력해야 합니다.

기술 구현에 의해 보장되는 사실을 확인하지 마십시오. 예를 들어 데이터가 관계형 DBMS에 저장되어 있는 경우 다음 사항을 확인할 필요가 없습니다.

• 필수로 정의된 열에는 NULL 값이 있습니다.
• 기본 키 필드 값은 테이블에서 고유합니다.
• 관계형 무결성 검사가 활성화된 테이블에 기존 외래 키가 없습니다.

즉, 데이터 웨어하우스는 지속적으로 변경되고 필드 및 테이블의 데이터 정의는 시간이 지남에 따라 변경될 수 있다는 점을 항상 염두에 두십시오.

하우스키핑은 매우 중요합니다. 다른 데이터 사용자 단위에 의해 정의된 규칙은 겹칠 수 있으므로 통합해야 합니다. 조직이 복잡할수록 더 많은 하우스키핑이 필요합니다. 데이터 소유자는 일종의 "데이터 품질 규칙에 대한 데이터 품질"로 규칙 통합 프로세스를 구현해야 합니다. 또한 데이터가 더 이상 사용되지 않거나 정의가 변경된 경우 데이터 품질 검사가 무용지물이 될 수 있습니다.

데이터 품질 규칙의 클래스

데이터 품질 규칙은 테스트 유형에 따라 분류할 수 있습니다.

• 데이터 품질 검사. "정상적인" 경우, 하나의 테이블 또는 테이블 세트 내에서 하나의 데이터 웨어하우스 계층(그림 1 참조) 내에서 데이터를 확인합니다.
• 화해. 데이터 웨어하우스 계층 간에 데이터가 올바르게 전송되었는지 확인하는 규칙(그림 1 참조). 이러한 규칙은 "완전함"의 DQ 차원을 확인하는 데 주로 사용됩니다. 조정은 단일 행 또는 요약된 접근 방식을 사용할 수 있습니다. 단일 행을 확인하는 것이 훨씬 더 세분화되지만 비교된 레이어 간에 변환 단계(데이터 필터링, 필드 값 변경, 비정규화, 조인 등)를 재현해야 합니다. 건너뛴 레이어가 많을수록 더 복잡한 변환 논리를 구현해야 합니다. 따라서 스테이징을 데이터 마트 계층과 비교하는 대신 각 계층과 이전 계층 간에 조정을 수행하는 것이 좋습니다. 조정 규칙에서 변환을 구현해야 하는 경우 데이터 웨어하우스 코드가 아닌 사양을 사용하십시오! 요약된 조정의 경우 의미 있는 필드(예: 요약, 고유 값 개수 등)를 찾습니다.
• 모니터링. 데이터 웨어하우스는 일반적으로 과거 데이터를 포함하고 운영 데이터의 델타 추출과 함께 로드됩니다. 데이터 웨어하우스와 운영 데이터 간의 격차가 서서히 증가할 위험이 있습니다. 요약된 시계열 데이터를 작성하면 이와 같은 문제를 식별하는 데 도움이 됩니다(예: 지난 달 데이터를 이번 달 데이터와 비교). 데이터에 대해 잘 알고 있는 데이터 사용자는 모니터링 규칙에 대한 유용한 측정 및 임계값을 제공할 수 있습니다.

데이터 품질 문제를 수량화하는 방법

확인할 항목을 정의했으면 식별된 문제를 수량화하는 방법을 지정해야 합니다. "5개의 데이터 행이 ID 15의 DQ 규칙을 위반함"과 같은 정보는 데이터 품질에 거의 의미가 없습니다.

다음 부품이 누락되었습니다.

• 감지된 오류를 수량화/카운트하는 방법. "행 수"를 계산할 수 있지만 금전적 척도(예: 노출)를 사용할 수도 있습니다. 금전적 가치는 다른 부호를 가질 수 있으므로 의미 있게 요약하는 방법을 조사해야 합니다. 데이터 품질 규칙에 두 수량화 단위(행 수 및 요약)를 모두 사용할 수 있습니다.
• 인구. 데이터 품질 규칙에 의해 확인되는 단위의 수는 얼마입니까? "5개 중 5개 데이터 행"은 "5백만 개 중 5개"와 품질이 다릅니다. 모집단은 오류와 동일한 수량화를 사용하여 측정해야 합니다. 데이터 품질 규칙의 결과를 백분율로 표시하는 것이 일반적입니다. 채우기는 테이블의 행 수와 동일하지 않아야 합니다. DQ 규칙이 데이터의 하위 집합만 확인하는 경우(예: 계약 테이블에서 종료된 계약만) 모집단을 측정하기 위해 동일한 필터를 적용해야 합니다.
• 결과의 정의. 데이터 품질 검사에서 문제가 발견되더라도 항상 오류가 발생하는 것은 아닙니다. 데이터 품질의 경우 임계값을 사용하여 결과를 평가하는 신호등 시스템(빨간색, 노란색, 녹색)이 매우 유용합니다. 예를 들어 녹색: 0-2%, 노란색: 2-5%, 빨간색: 5% 이상입니다. 데이터 사용자 단위가 동일한 규칙을 공유하는 경우 지정된 규칙에 대해 임계값이 매우 다를 수 있습니다. 마케팅 사업부에서는 몇 건의 주문 손실을 신경 쓰지 않을 수 있지만 회계 부서는 몇 센트라도 신경 쓸 수 있습니다. 백분율 또는 절대 수치에 대한 임계값을 정의할 수 있어야 합니다.
• 샘플 오류 행을 수집합니다. 데이터 품질 규칙이 감지된 오류의 샘플을 제공하면 도움이 됩니다. 일반적으로 (비즈니스!) 키와 확인된 데이터 값은 오류를 검사하는 데 도움이 됩니다. 데이터 품질 규칙에 대해 작성된 오류 행 수를 제한하는 것이 좋습니다.
• 경우에 따라 수정되지는 않지만 유용한 데이터 품질 검사를 통해 찾은 데이터에서 "알려진 오류"를 찾을 수 있습니다. 이러한 경우 화이트리스트 (데이터 품질 검사에서 건너뛰어야 하는 레코드 키)를 사용하는 것이 좋습니다.

기타 메타데이터

메타데이터는 "분석" 경로를 지정하고 데이터 품질 관리 루프의 단계를 모니터링하는 데 중요합니다.

• 체크 항목입니다. 확인된 테이블과 필드를 데이터 품질 규칙에 할당하는 데 도움이 됩니다. 향상된 메타데이터 시스템이 있는 경우 이 규칙에 데이터 사용자와 데이터 소유자를 자동으로 할당하는 데 도움이 될 수 있습니다. 규제상의 이유로(예: BCBS 239) DQ에서 데이터를 확인하는 방법도 증명해야 합니다. 그러나 데이터 계보(*)를 통해 데이터 사용자/데이터 소유자에게 자동으로 규칙을 할당하는 것은 양날의 검일 수 있습니다(아래 참조).
• 데이터 사용자. 모든 DQ 규칙에는 "분석" 단계에서 결과를 확인하고 결과가 데이터 작업에 영향을 미치는지 여부와 방법을 결정하기 위해 할당된 데이터 사용자/데이터 사용자 단위가 하나 이상 있어야 합니다.
• 데이터 소유자. 모든 DQ 규칙에는 데이터 소유자가 할당되어 있어야 합니다.

(*) 데이터 계보는 두 지점 간의 데이터 흐름을 나타냅니다. 데이터 계보를 사용하면 웨어하우스 내에서 지정된 대상 필드에 영향을 미치는 모든 데이터 요소를 찾을 수 있습니다.

데이터 연계를 사용하여 사용자를 규칙에 할당하는 것은 문제가 될 수 있습니다. 앞서 언급했듯이 비즈니스 사용자는 일반적으로 데이터 마트 계층(및 운영 체제)만 알고 데이터 웨어하우스의 하위 수준은 알지 못합니다. 데이터 계보를 통해 매핑하면 데이터 사용자에게 익숙하지 않은 규칙이 할당됩니다. 낮은 수준의 경우 데이터 품질 결과를 평가하기 위해 IT 직원이 필요할 수 있습니다. 많은 경우 수동 매핑 또는 혼합 접근 방식(데이터 마트 내에서만 데이터 계보를 통한 매핑)이 도움이 될 수 있습니다.

데이터 품질 측정

데이터 품질을 측정한다는 것은 데이터 웨어하우스의 로드 프로세스에 의해 트리거되는 자동으로 수행되어야 하는 사용 가능한 데이터 품질 규칙을 실행하는 것을 의미합니다. 이전에 보았듯이 데이터 품질 규칙이 상당히 많을 수 있으므로 확인하는 데 시간이 많이 걸립니다.

완벽한 세상에서 데이터 웨어하우스는 모든 데이터에 오류가 없는 경우에만 로드됩니다. 현실 세계에서는 이런 경우가 거의 없습니다(현실적으로는 거의 그렇지 않습니다). 데이터 웨어하우스의 전체 로드 전략에 따라 데이터 품질 프로세스가 로드 프로세스를 지배하거나 지배하지 않아야 합니다(후자가 훨씬 더 가능성 있음). 데이터 품질 프로세스(작업 네트워크)를 병렬로 갖고 "일반" 데이터 웨어하우스 로드 프로세스에 연결하는 것은 좋은 설계입니다.

정의된 서비스 수준 계약이 있는 경우 데이터 품질 검사로 데이터 웨어하우스 로드를 방해하지 않도록 하십시오. 데이터 품질 프로세스의 오류/이상으로 인해 일반 로드 프로세스가 중지되어서는 안 됩니다. 데이터 품질 프로세스 내의 예기치 않은 오류는 보고되고 "분석" 단계에 표시되어야 합니다(다음 장 참조).

데이터 품질 규칙은 예기치 않은 오류(규칙 자체가 잘못 구현되었거나 시간이 지남에 따라 기본 데이터 구조가 변경되었을 수 있음)로 인해 충돌할 수 있습니다. 데이터 품질 시스템이 그러한 규칙을 비활성화 하는 메커니즘을 제공했다면, 특히 회사에서 연간 릴리스가 거의 없는 경우에 도움이 될 것입니다.

DQ 프로세스는 가능한 한 빨리 실행하고 보고 해야 합니다. 이상적으로는 확인된 데이터가 로드된 직후입니다. 이렇게 하면 데이터 웨어하우스를 로드하는 동안 가능한 한 빨리 오류를 감지하는 데 도움이 됩니다(일부 복잡한 웨어하우스 시스템 로드에는 며칠이 소요됨).

분석하다

이러한 맥락에서 "분석"은 데이터 품질 결과에 반응하는 것을 의미합니다. 할당된 데이터 사용자와 데이터 소유자를 위한 작업입니다.

대응 방법은 데이터 품질 프로젝트에서 명확하게 정의해야 합니다. 데이터 사용자는 결과가 포함된 규칙(적어도 빨간색 표시등이 있는 규칙)에 대해 설명하고 해당 결과를 처리하기 위해 어떤 조치를 취하고 있는지 설명해야 합니다. 데이터 소유자는 정보를 제공받아야 하며 데이터 사용자와 함께 결정해야 합니다.

다음 작업이 가능합니다.

• 심각한 문제: 문제를 수정하고 데이터 로드를 반복해야 합니다.
• 문제는 허용 됩니다. 향후 데이터 로드를 위해 문제를 수정하고 데이터 웨어하우스 또는 보고 내에서 문제를 처리합니다.
• 결함 있는 DQ 규칙: 문제가 있는 DQ 규칙을 수정합니다.

완벽한 세상에서는 모든 데이터 품질 문제가 해결됩니다. 그러나 리소스 및/또는 시간이 부족하면 종종 해결 방법이 나타납니다.

적시에 대응할 수 있으려면 DQ 시스템이 데이터 사용자에게 결과와 함께 "그들의" 규칙에 대해 알려야 합니다. 데이터 품질 대시보드를 사용하는 것은 좋은 생각입니다. 사용자에게 결과에 대해 일찍 알릴수록 좋습니다.

데이터 품질 대시보드 에는 다음이 포함되어야 합니다.

• 주어진 역할에 할당된 모든 규칙
• 결과 및 데이터 도메인별로 규칙을 필터링하는 기능이 있는 규칙의 결과(신호등, 측정값 및 예제 행)
• 데이터 사용자가 결과에 대해 입력해야 하는 필수 설명
• 결과를 선택적으로 "재정의"하는 기능(예: 잘못된 구현으로 인해 데이터 품질 규칙이 오류를 보고하는 경우). 둘 이상의 사업부에 동일한 데이터 품질 규칙이 할당된 경우 "무효"는 데이터 사용자의 사업부(회사 전체가 아님)에만 유효합니다.
• 실행되지 않았거나 이상된 규칙 표시

대시보드는 또한 최근 데이터 웨어하우스 로드 프로세스의 현재 상태를 표시하여 사용자에게 데이터 웨어하우스 로드 프로세스의 360도 보기를 제공해야 합니다.

데이터 소유자는 모든 결과에 주석이 달렸고 데이터 품질(원본 또는 무효) 상태가 모든 데이터 사용자에 대해 최소한 노란색인지 확인할 책임이 있습니다.

빠른 개요를 위해 데이터 사용자/데이터 소유자를 위한 일종의 간단한 KPI(핵심 성과 지표)를 구축하는 데 도움이 될 것입니다. 연결된 모든 규칙의 결과에 대한 전체 신호등을 갖는 것은 각 규칙에 동일한 가중치가 부여되는 경우 매우 쉽습니다.

개인적으로, 주어진 데이터 도메인에 대한 데이터 품질의 전체 가치를 계산하는 것은 다소 복잡하고 cabalistic 경향이 있다고 생각하지만, 적어도 데이터 도메인에 대한 결과별로 그룹화된 전체 규칙 수를 표시할 수 있습니다(예: "100 DQ 규칙 90% 녹색, 5% 노란색, 5% 빨간색 결과").

결과를 수정하고 데이터 품질을 개선하는 것은 데이터 소유자의 임무입니다.

프로세스 개선

데이터 웨어하우스 프로세스가 자주 변경됨에 따라 데이터 품질 메커니즘도 유지 관리가 필요합니다.

데이터 소유자는 항상 다음 사항에 주의해야 합니다.

• 최신 상태로 유지하십시오. 데이터 웨어하우스의 변경 사항은 데이터 품질 시스템에서 포착해야 합니다.
• 향상시키다. 데이터 품질 규칙에 아직 포함되지 않은 오류에 대한 새 규칙을 구현합니다.
• 유선. 더 이상 필요하지 않은 데이터 품질 규칙을 비활성화합니다. 겹치는 규칙을 통합합니다.

데이터 품질 프로세스 모니터링

전체 데이터 품질 프로세스를 모니터링하면 시간이 지남에 따라 개선하는 데 도움이 됩니다.

볼 가치가 있는 항목은 다음과 같습니다.

• 데이터 품질 규칙으로 데이터 적용
• 시간 경과에 따른 활성 규칙 내 데이터 품질 결과의 백분율
• 활성 데이터 품질 규칙의 수(계속 주시하십시오. 데이터 사용자가 점점 더 많은 데이터 품질 규칙을 비활성화하여 결과를 해결하는 것을 보았습니다.)
• 데이터 로드 내에서 모든 결과를 평가하고 수정하는 데 필요한 시간

결론

다음 사항 중 많은 부분이 모든 종류의 프로젝트에서 중요합니다.

저항을 예상하십시오. 지금까지 살펴본 바와 같이 긴급한 품질 문제가 없다면 데이터 품질은 새로운 기능을 제공하지 않고 추가 부담으로 간주되는 경우가 많습니다. 데이터 사용자에게 추가 작업 부하를 생성할 수 있다는 점에 유의하십시오. 많은 경우 규정 준수 및 규정 요구 사항은 사용자가 이를 피할 수 없는 요구 사항으로 보도록 설득하는 데 도움이 될 수 있습니다.

후원자를 찾습니다. 위에서 언급했듯이 DQ는 빠르게 판매되는 품목이 아니므로 강력한 후원자/이해관계자가 필요합니다. 경영진이 높을수록 좋습니다.

동맹을 찾으십시오. 후원자와 마찬가지로 강력한 데이터 품질에 대한 아이디어를 공유하는 사람이라면 누구라도 가장 도움이 될 것입니다. DQ 회로 루프는 진행 중인 프로세스이며 회로 루프를 활성 상태로 유지하기 위해 사람들이 필요합니다.

작게 시작하세요. 지금까지 DQ 전략이 없었다면 더 나은 데이터 품질이 필요한 사업부를 찾으십시오. 프로토타입을 만들어 더 나은 데이터의 이점을 보여줍니다. 귀하의 작업이 주어진 데이터 품질 전략을 개선하거나 교체하는 것이라면 조직에서 잘 작동하거나 수용하고 있는 사항을 살펴보고 유지하십시오.

전체 그림을 놓치지 마십시오. 작게 시작하지만 일부 포인트, 특히 역할은 성공적인 DQ 전략의 전제 조건임을 명심하십시오.

일단 구현하면 놓지 마십시오. 데이터 품질 프로세스는 데이터 웨어하우스 사용의 일부여야 합니다. 시간이 지남에 따라 데이터 품질에 중점을 두는 것이 다소 손실되는 경향이 있으며 이를 유지 관리하는 것은 사용자에게 달려 있습니다.