선임 플랫폼 엔지니어를 위한 최고의 데이터 품질 프레임워크

그렇기 때문에 내부 소비자든 외부 소비자든 비즈니스 기능에 데이터를 중요하게 생각하는 모든 조직은 데이터 품질 관리를 실천하고 데이터 품질 프레임워크를 구현해야 합니다. 말 그대로의 의미를 살펴보면, 시스템에 입력된 데이터가 다운스트림으로 전달될 때, 해당 데이터가 사용자와 소비자가 기대하는 내용인지 확인하기 위해 반복 가능하고 이상적으로는 자동화된 프로세스와 패턴을 개발하는 것입니다.

시니어 데이터 엔지니어로서 잘 아시다시피, 이러한 기대치를 이해하는 것만으로도 절반의 성공입니다. 나머지 절반의 성공은 이러한 기대치를 복잡한 수집 프로세스에서 문제를 찾고 해결하는 데 도움이 되는 추적 및 알림으로 변환하는 데 있습니다.

이 가이드에서는 데이터 품질 관리가 기존의 하드코딩된 프로세스 위에 단순히 레이어로 쌓이는 것이 아니라 모든 DAG에 내장되도록 하는 전략을 공유합니다. 이를 잘 관리하려면 품질이 낮은 데이터가 변환 계층에 들어가기 훨씬 전에 이상 징후를 감지해야 합니다.

정의부터 시작하겠습니다. 데이터 품질 프레임워크는 조직이 관련 데이터 품질 특성을 정의하고 데이터 품질이 소비자의 기대(SLA)를 충족하는지 지속적으로 보장하는 데이터 품질 관리 프로세스에 대한 지침을 제공하는 데 사용할 수 있는 툴입니다.

너무 내용이 복잡하니 풀어서 설명해 보겠습니다.

1. 프로세스 필요: 엔지니어의 시간이 무제한이 아닌 한, 프로세스에는 데이터 파이프라인의 모든 단계(특히 문제를 사전에 감지하려는 경우 수집 단계)에서 반복 가능하고 이상적으로는 자동화된 단위 테스트와 데이터 문제를 처리하기 위한 워크플로가 포함되어야 합니다.
2. 지속적으로 확인하기: 데이터 품질은 데이터 속도에 비례하여 저하되며, 이를 데이터 드리프트라고도 합니다. 오늘날 많은 사람들이 다루고 있는 고속 데이터는 자주 확인해야 합니다.
3. 자신의 기대치가 아닌 소비자의 기대치 충족하기: 데이터 품질은 근본적으로 비즈니스 프로세스입니다. 데이터 SLA 또는 "서비스 계약"은 소비자와 체결되며, 데이터 과학자가 모델을 실행할 수 없거나, 고객이 부정확한 배송 견적을 받거나, 지역 부사장이 대시보드가 로드되지 않아 빈손으로 이사회에 참석해야 하는 경우 엔지니어링 측면에서는 아무런 의미가 없습니다.

위의 약속을 이행하기 위해서는 많은 요소가 필요하며, 이러한 각 요소에는 종속성이 가득합니다. 예를 들어, 이러한 시스템을 설계하는 방법을 스스로에게 묻는다면 다음과 같은 질문을 하게 될 것입니다.

1. 데이터 품질에 대한 소비자의 기대치를 어떻게 이해할 수 있을까요?
2. 이러한 기대치를 데이터 품질에 대한 정량화 가능한 측정값으로 어떻게 변환할 수 있을까요?
3. 각 파이프라인에 대한 자동 품질 측정을 어떻게 구현할 것인가요?
4. 데이터 품질의 각 차원에 대한 임계값을 어떻게 결정할 것인가요?
5. 데이터가 이러한 임계값을 위반하면 팀에 어떻게 알릴 수 있을까요?
6. 팀에서 알림을 받으면 어떻게 해야 하나요?
7. 알림의 유효성과 긴급성을 어떻게 판단하나요?
8. 문제가 있는 경우 주요 원인을 어떻게 식별하나요?
9. 근본 원인을 어떻게 파악할 수 있나요?
10. 소비자에게 무엇을 기대할 수 있는지 어떻게 알릴 수 있을까요?
11. 근본 원인을 어떻게 해결할 수 있을까요?
12. 근본 원인을 해결했는지 어떻게 확인할 수 있나요?
13. 지식을 쌓는 과정을 어떻게 문서화하나요?

길고 불운한 번호가 매겨진 목록처럼 보이시나요? 걱정하지 마세요. 이러한 일들은 위임할 수 있습니다.

질문 1은 팀의 비즈니스 분석가에게 가장 적합합니다. 사업부와 대화하여 사용자 스토리, 명시된 선호도, 암시된 선호도, 요청 및 이벤트 사후 분석을 데이터에 대한 "요구" 목록으로 분해하는 것은 그들의 몫입니다. 이는 소비자가 데이터에 대해 갖는 정성적인 기대치이며, 소비자가 원하는 것을 정확히 설명할 수 있는 단어가 없을 수도 있기 때문에 양방향 대화가 필요합니다. (데이터 소비자가 데이터 과학자인 경우가 아니라면 이 작업의 속도를 크게 높일 수 있습니다.)

질문 2는 여러분과 데이터 과학자가 함께 답해야 할 질문입니다(특히 데이터 과학자가 소비자이기도 한 경우). 각 파이프라인에 대한 데이터의 특성을 고려할 때, 정성적 기대치 목록을 정량적 측정 목록으로 더 세분화하기 위해 실제로 어떤 속성을 측정할 수 있을까요?

어떤 데이터 품질 모델을 따르느냐에 따라 4가지 또는 5가지 차원의 품질을 살펴볼 수 있습니다. IBM Databand는 다음과 같은 네 가지 특성을 가진 모델을 선호합니다.

• 적합성
  • 정확성—데이터가 현실을 반영
  • 무결성—품질/시간
• 리니지
  • 소스 - 제공업체가 기대에 부응하고 있나요?
  • 출처 - 어디에서 왔나요?
• 거버넌스
  • 데이터 제어
  • 데이터 개인정보 보호
  • 규제
  • 보안
• 안정성
  • 일관성
  • 신뢰성
  • 적시성
  • 편향

이러한 메트릭을 확보한 데이터 엔지니어는 질문 3~13을 해결하고 데이터 품질 관리 전략을 수립할 수 있습니다. 그리고 정확히 어떻게 하는지 알아보기 전에 왜 이 모든 노력을 기울여야 하는지 생각해볼 가치가 있습니다.

몇 년 전, 주요 소매업체의 Microsoft Dynamics CRM에서 무의미한 구성 변경으로 인해 온라인에 표시되는 각 품목의 재고 수가 현실을 반영하지 못하는 일이 발생했습니다. 카운터가 업데이트를 중지한 것입니다.

사람들은 계속 구매했지만 판매량은 일정하게 유지되었습니다. 데이터 엔지니어링 팀이 경고를 받았을 때는 이미 상황이 심각해진 후였습니다.

대부분의 품목은 온라인으로 구매할 수 있었지만 매장 픽업도 가능했습니다. 많은 사람들이 매장 픽업을 선택했습니다. 주문이 처리되었고, 존재하지 않는 상품이 판매되었습니다. 소비자들은 매장을 방문했고, 소매점 직원들은 대체품을 찾거나 할인을 약속하거나 어떻게든 고객을 달래기 위해 분주히 움직였습니다. 대기줄이 생겼습니다. 매장 방문객들은 구매를 위해 기다려야 했고, 많은 사람들이 신경질적으로 휴대폰을 사용하며 매장 분위기를 불편하게 만들었습니다. 문제를 발견하고 파이프라인을 수정하는 데 며칠이 걸렸기 때문에 문제가 해결되기까지는 며칠이 더 걸렸습니다.

브랜드 평판 손실을 고려하면 수천만 달러의 손실이 발생한 이 실수는 일어나지 않았어야 할 일이었습니다.

즉, 데이터 문제는 더욱 커진다는 뜻입니다. 눈에 잘 띄지 않아 발견하고 해결하기 어려울 수 있으며, 눈에 보이지 않게 커질 수 있습니다. 데이터 부채가 점점 늘어나는 와중에도 인사이트가 어느 정도 도출되고 있다는 이유만으로 모든 것이 제대로 작동하고 있다고 생각하기 쉽습니다.

또한 데이터 품질 문제의 가장 확실한 징후는 지연 지표이기도 합니다. 예를 들어, 소비자는 다음과 같이 말합니다. 또는 앞의 소매업 CRM 사례에서처럼 수천 명의 소매업 관리자와 지역 부사장이 말합니다. 좋지 않네요. 이는 데이터가 한동안 시스템에 있었으며 수정 결과가 나오기까지 며칠이 걸릴 수 있다는 의미입니다. 소비자의 기대에 미치지 못한 것입니다.

이것이 바로 배송 스타트업 Shipper가 처한 상황이며, 이러한 상황이 다시 발생하는 것을 방지하기 위해 이들이 막대한 투자를 한 이유입니다. 데이터 엔지니어링 팀은 이커머스 공급업체가 재고를 배송 항구로 배송하는 데 도움이 되는 애플리케이션에 최대한 실시간에 가까운 데이터를 제공합니다. 이들이 걱정해야 할 것은 단지 소비자의 기대뿐만이 아닙니다. 소비자의 소비자에 대해서도 걱정해야 합니다. 그리고 시스템이 때때로 이틀이나 늦어졌을 때는 기대에 미치지 못하는 파장이 연쇄적으로 발생하기도 했습니다. 따라서 이들은 데이터 품질 관리와 자동 점검을 통해 조기 경고 알림을 제공할 수 있는 툴에 많은 투자를 했습니다.

데이터 품질 관리는 데이터 품질 검사를 자동화하고 광범위하게 적용하는 방법입니다. 즉 여러분은 데이터 세트 및 파이프라인의 엔트로피 힘에 대해 그와 동등하고 반대되는 힘으로 맞서 싸우는 셈입니다.

앞의 예시와 질문 목록으로 돌아가 보겠습니다. 분석가는 비즈니스와 논의하여 요구 사항을 수집하고, 여러분은 데이터 과학자로부터 정량적 소비자 기대치 목록을 받습니다. 그렇다면 어떻게 진행하여 시스템을 구축할 수 있을까요?

데이터 품질 프레임워크를 만듭니다. 프레임워크는 무엇보다도 시스템이 하나의 사이클이며 항상 진화하는 소비자의 기대와 관련하여 알게 된 모든 것이 시스템에 영향을 미친다는 것을 인정해야 합니다.

각 단계를 살펴보겠습니다.

1. 자격: 비즈니스 분석가는 소비자의 요구 사항을 요구 사항 목록으로 분해합니다
2. 정량화: 데이터 과학자는 요구 사항을 정량화할 수 있는 데이터 품질 측정값으로 분해하지만, 이는 아직 이론적인 수준에 불과합니다.
3. 계획: 데이터 엔지니어는 데이터 품질에 대한 정량적 측정을 데이터 파이프라인 관측 가능성 플랫폼에서 실행할 수 있는 검사로 변환합니다. 이러한 플랫폼은 매우 중요합니다. Airflow와 Spark와 같은 워크플로 및 파이프라인 스케줄링 시스템은 파이프라인 자체의 문제를 감지할 수 있지만 대부분의 문제가 발생하는 데이터 내에서는 감지할 수 없습니다. 엔지니어는 시스템에서 추적할 수 있는 것과 추적할 수 없는 것을 이해해야 합니다.
4. 구현: 데이터 엔지니어는 추적을 구현하고 테스트합니다. 아주 간단한 예로, 데이터가 모두 존재해야 하고 필드나 열이 누락되지 않아야 하는 경우 데이터 완전성 매개변수에 대한 경고를 설정할 수 있습니다. Databand 같은 관측 가능성 플랫폼을 사용하면 이를 가능하게 하고, 모든 값을 수동으로 설정할 필요가 없도록 이상 징후 탐지를 설정할 수 있습니다.
5. 관리: 데이터 엔지니어는 이러한 알림을 과거 파이프라인 데이터에 대해 백 테스트하여 실제로 의도한 대로 작동했는지 확인합니다. 사실이라면 알림이 발생했을 때 누가 책임이 있는지, 알림을 받았을 때 무엇을 할 것인지에 대한 인시던트 관리 계획과 함께 이를 프로덕션에 배치합니다.
6. 확인: 데이터 엔지니어와 데이터 과학자는 데이터 관리 프레임워크를 통해 원하는 메트릭에 따라 성능이 눈에 띄게 개선되었음을 확인합니다. 비즈니스 분석가들은 소비자에게 이것이 실제로 사실임을 확인합니다.

프레임워크를 어떻게 활용하시나요? 실전에 적용해 보세요.

여러 사례에서 살펴본 것처럼, 데이터 품질 문제를 나타내는 가장 나쁜 지표는 소비자가 무언가 고장났다고 말하는 지연 지표입니다. 데이터 엔지니어링에서 우리가 하는 일의 대부분은 파이프라인을 통해 신뢰를 구축하는 것입니다.

팀이 문제를 자동으로 식별하는 데 도움이 되는 데이터 품질 관리 프레임워크에 투자하면 신뢰할 수 있는 데이터를 만들 수 있습니다. 그러면 업무가 훨씬 쉬워집니다.

IBM Databand가 예상치 못한 열 변경 및 null 레코드를 감지하여 더 나은 데이터 품질 모니터링을 제공하고 데이터 SLA를 충족하는 데 어떻게 도움이 되는지 알아보세요. 더 자세히 살펴볼 준비가 되셨다면 지금 바로 데모를 예약하세요.