데이터 팀이 데이터 유효성 검사에 어려움을 겪는 이유(및 이를 변경하는 방법)

편집자 주: 이 기사는 원래 2020년 12월 18일 Iteratively 블로그에 게시되었습니다.

"쓰레기가 들어가면 쓰레기가 나온다"는 옛 속담을 아십니까? 아마도 데이터 위생과 관련하여 이 문구를 들어보셨을 것입니다. 하지만 데이터 관리와 품질이 나쁜 쓰레기는 어떻게 고칠까요? 음, 까다롭습니다. 특히 추적 코드 구현을 제어할 수 없는 경우(많은 데이터 팀의 경우).

그러나 데이터 리드가 데이터 설계에서 커밋까지의 파이프라인을 소유하지 않는다고 해서 모든 희망이 사라지는 것은 아닙니다. 데이터 소비자(즉, 제품 관리자, 제품 팀 및 분석가)와 데이터 생산자(엔지니어) 사이의 가교 역할을 함으로써 데이터 위생을 전반적으로 개선할 데이터 유효성 검사를 개발하고 관리하는 데 도움을 줄 수 있습니다.

잡초에 들어가기 전에 데이터 유효성 검사라고 하면 데이터 팀이 데이터 품질을 유지하는 데 도움이 되는 프로세스와 기술을 말합니다.

이제 데이터 팀이 이 검증에 어려움을 겪는 이유와 이러한 문제를 극복할 수 있는 방법을 살펴보겠습니다.

첫째, 데이터 팀이 데이터 검증에 어려움을 겪는 이유는 무엇입니까?

데이터 팀이 분석을 위한 데이터 검증에 어려움을 겪는 세 가지 주요 이유가 있습니다.

1. 이벤트 추적 코드 구현 및 문제 해결에 직접 관여하지 않는 경우가 많기 때문에 데이터 팀은 문제를 분석을 위한 데이터 유효성 검사와 관련된 표준화된 프로세스가 없는 경우가 많습니다 . 즉, 테스트가 일관성 없는 QA 확인에 좌우된다는 의미입니다.
2. 데이터 팀과 엔지니어는 사전 예방적 데이터 유효성 검사 방법이 아닌 반응성 유효성 검사 기술에 의존 하므로 핵심 데이터 위생 문제가 중단되지 않습니다.

이 세 가지 문제는 최고의 데이터 리드(및 이를 지원하는 팀)조차 좌절시키기에 충분합니다. 그 이유는 다음과 같습니다. 품질이 좋지 않은 데이터는 단순히 비용이 많이 드는 것이 아닙니다. IBM에 따르면 불량 데이터는 평균 3조 달러 의 비용이 듭니다. 또한 조직 전체에서 데이터 자체에 대한 신뢰를 약화시키고 데이터 팀과 엔지니어가 버그를 없애기 위해 몇 시간의 생산성을 잃게 만듭니다.

이야기의 교훈은? 데이터 검증이 미뤄지면 아무도 이길 수 없습니다.

고맙게도 이러한 문제는 좋은 데이터 유효성 검사 방법으로 극복할 수 있습니다. 각 문제점에 대해 자세히 살펴보겠습니다.

데이터 팀이 데이터 수집 자체를 제어하지 못하는 경우가 많습니다.

위에서 말했듯이 데이터 팀이 데이터 유효성 검사에 어려움을 겪는 주된 이유는 그들이 문제의 이벤트 추적 계측을 수행하는 팀이 아니기 때문입니다(기껏해야 문제가 있음을 알 수는 있지만 해결할 수는 없습니다) ).

이로 인해 데이터 분석가와 제품 관리자는 물론 의사 결정을 보다 데이터 중심으로 만들고자 하는 사람은 사실 이후에 데이터를 풀고 정리해야 하는 작업을 짊어지게 됩니다. 그리고 그 누구도(아무도 아닌데) 데이터 무작정을 취미로 즐기는 사람은 없습니다.

이 문제는 대부분의 데이터 팀이 극복하기 특히 어렵습니다. 엔지니어 외에 데이터 명단에 있는 사람 중 소수만이 데이터 유효성 검사를 직접 수행할 수 있는 기술을 가지고 있기 때문입니다. 데이터 생산자와 데이터 소비자 사이의 조직적 사일로는 이러한 문제점을 더욱 민감하게 만듭니다. 이를 완화하기 위해 데이터 리드는 깨끗한 데이터를 보장하기 위해 팀 간 협업을 촉진해야 합니다.

결국, 데이터는 팀 스포츠이며 플레이어가 서로 대화하거나 함께 훈련하거나 더 나은 결과를 위해 더 나은 플레이를 브레인스토밍할 수 없다면 어떤 게임에서도 이길 수 없습니다.

데이터 계측 및 유효성 검사는 다르지 않습니다. 데이터 소비자는 데이터 생산자와 협력하여 테스트를 포함하여 소스에서 데이터 관리 관행을 적용하고 시행해야 합니다. 이 관행은 누군가가 하류에서 고군분투하기 전에 데이터 관련 문제를 사전에 감지합니다.

이것은 우리를 다음 요점으로 인도합니다.

데이터 팀(및 해당 조직)은 분석을 위한 데이터 유효성 검사와 관련된 프로세스를 설정하지 않은 경우가 많습니다.

엔지니어는 테스트 코드가 중요하다는 것을 알고 있습니다. 모든 사람이 항상 그렇게 하는 것을 좋아하지는 않을 수 있지만 애플리케이션이 예상대로 실행되는지 확인하는 것은 훌륭한 제품을 제공하는 데 있어 핵심적인 부분입니다.

결과적으로 분석 코드가 의도한 대로 이벤트 데이터를 수집하고 전달하는지 확인하는 것도 훌륭한 제품을 구축하고 반복하는 데 핵심입니다.

그렇다면 연결이 끊어진 곳은 어디입니까? 분석 데이터를 테스트하는 관행은 엔지니어링 및 데이터 팀에게 아직 비교적 새로운 것입니다. 너무 자주 분석 코드는 핵심 기능이 아닌 기능의 추가 기능으로 간주됩니다. 이는 부진한 데이터 거버넌스 관행과 결합되어 전반적으로 산발적으로 구현되거나 전혀 구현되지 않음을 의미할 수 있습니다.

간단히 말해, 이는 데이터 팀 외부의 사람들이 이벤트 데이터가 일상 업무에 얼마나 중요한지 아직 이해하지 못하기 때문인 경우가 많습니다. 그들은 클린 이벤트 데이터가 뒷마당에 있는 돈나무라는 사실과 은행을 만들기 위해 정기적으로 물을 주는 것(검증)만 하면 된다는 사실을 모릅니다.

모든 사람이 이벤트 데이터인 돈 나무를 관리해야 한다는 것을 이해하게 하려면 데이터 팀은 잘 검증된 데이터를 조직 전체에서 사용할 수 있는 모든 방법을 전파해야 합니다. 데이터 팀은 조직 내에서 제한되고 사일로화될 수 있지만 데이터 품질을 개선하기 위한 올바른 프로세스와 도구가 마련되어 있는지 확인하기 위해 그들과 다른 이해 관계자 사이의 벽을 허물기 위한 작업을 수행하는 것은 궁극적으로 이러한 데이터 챔피언에게 달려 있습니다.

이러한 데이터 관리의 거친 서부를 극복하고 적절한 데이터 거버넌스를 보장하기 위해 데이터 팀은 언제, 어디서, 어떻게 데이터를 사전에 테스트해야 하는지 설명하는 프로세스를 구축해야 합니다. 어렵게 들릴 수 있지만 실제로 데이터 테스트는 기존 SDLC(소프트웨어 개발 수명 주기), 도구 및 CI/CD 파이프라인에 원활하게 적용될 수 있습니다.

데이터 전략을 설계하는 데이터 팀과 코드를 구현하고 테스트하는 엔지니어링 팀 모두를 위한 명확한 프로세스와 지침은 모든 사람이 예상되는 출력과 입력을 이해하는 데 도움이 될 것입니다.

데이터 팀과 엔지니어는 능동적인 데이터 테스트 기술이 아닌 반응적인 데이터 테스트 기술에 의존합니다.

삶의 거의 모든 부분에서 수동적이기보다 능동적이 되는 것이 좋습니다. 이는 분석을 위한 데이터 유효성 검사에서도 마찬가지입니다.

그러나 많은 데이터 팀과 엔지니어는 반응형 데이터 유효성 검사 기술에 갇혀 있다고 느낍니다. 견고한 데이터 거버넌스, 도구 및 선제적 테스트를 쉽게 만드는 프로세스가 없으면 릴리스에 포함하기 위해 이벤트 추적을 신속하게 구현하고 배송해야 합니다(또는 배송 후 소급하여 추가해야 함). 이로 인해 데이터 리드와 해당 팀은 사후에 변칙 검색 또는 데이터 변환과 같은 기술을 사용하게 됩니다.

이 접근 방식은 잘못된 데이터의 근본 문제를 해결하지 못할 뿐만 아니라 데이터 엔지니어가 버그를 제거하는 데 많은 시간을 소비합니다. 또한 분석가는 잘못된 데이터를 정리하는 데 많은 시간을 소비하고 데이터가 더 좋았을 경우 발생할 수 있는 모든 제품 개선으로 인한 비즈니스 수익 손실 비용을 지불해야 합니다.

데이터 리드는 지속적인 데이터 캐치업 상태에 있기보다는 사전 예방적 테스트를 포함하는 데이터 관리 프로세스를 형성하고 데이터 품질을 개선하고 다운스트림에서 재작업을 줄이기 위해 유형 안전과 같은 가드레일을 특징으로 하는 도구를 지원해야 합니다.

그렇다면 선제적 데이터 검증 조치란 무엇입니까? 한 번 보자.

데이터 유효성 검사 방법 및 기술

선제적 데이터 검증은 데이터 파이프라인의 각 단계에서 올바른 도구와 테스트 프로세스를 수용하는 것을 의미합니다.

• 유형 안전성, 단위 테스트 및 A/B 테스트를 활용하는 Amplitude와 같은 도구 가 있는 클라이언트 에서.
• Amplitude, Segment Protocols 및 스키마 유효성 검사를 위한 Snowplow의 오픈 소스 스키마 저장소 Iglu와 같은 도구와 통합 및 구성 요소 테스트, 신선도 테스트 및 배포 테스트를 위한 기타 도구가 포함된 파이프라인 에서.
• 웨어하우스 에서 dbt, Dataform 및 Great Expectations와 같은 도구를 사용하여 스키마화, 보안 테스트, 관계 테스트, 신선도 및 배포 테스트, 범위 및 유형 확인을 활용합니다.

데이터 팀이 사전 예방적 데이터 유효성 검사 조치를 적극적으로 유지하고 시행하면 수집된 데이터가 유용하고 명확하며 깨끗하고 모든 데이터 주주가 데이터를 유지하는 방법을 이해하는지 확인할 수 있습니다.

또한 데이터 수집, 프로세스 및 테스트 기술과 관련된 문제는 혼자서 극복하기 어려울 수 있으므로 리드가 데이터 팀과 엔지니어링 팀 간의 조직적 사일로를 무너뜨리는 것이 중요합니다.

더 나은 분석을 위해 데이터 검증을 변경하는 방법

분석을 위한 기능적 데이터 유효성 검사 사례를 향한 첫 번째 단계는 데이터가 데이터 리더인 당신이든 추적 코드 라인을 구현하는 개별 엔지니어이든 모든 수준에서 데이터 주주의 투자가 필요한 팀 스포츠 임을 인식하는 것입니다.

조직의 모든 사람은 클라이언트에서 웨어하우스에 이르기까지 우수한 데이터 수집 및 데이터 유효성 검사를 통해 이점을 얻습니다.

이를 구동하려면 세 가지가 필요합니다.

1. 비즈니스 전반에서 데이터를 유지 관리하고 사용하기 위한 프로세스를 설정하는 데이터 리드 및 회사 리더십의 하향식 방향
2. 각 팀이 데이터가 어떻게 업무를 더 잘 수행하는 데 도움이 되는지, 정기적인 테스트가 이를 어떻게 지원하는지 이해할 수 있도록 회사의 모든 계층에서 데이터 전파
3. 내부 도구, Segment Protocols, Snowplow 및 dbt와 같은 도구의 혼합, 더 나은 방법은 Amplitude와 같은 내장 분석 플랫폼 등 데이터를 잘 관리하기 위한 워크플로 및 도구 입니다. 이러한 각 단계에서 데이터 리드가 좋은 데이터를 향한 성공과 진행 상황을 조기에 자주 공유하는 것도 중요합니다. 이러한 투명성은 데이터 소비자가 데이터를 더 잘 사용할 수 있는 방법을 보는 데 도움이 될 뿐만 아니라 데이터 생산자(예: 테스트를 수행하는 엔지니어)가 노동의 결실을 보는 데 도움이 됩니다. 윈윈입니다.

데이터 검증 문제 극복

데이터 소비자가 구현을 제어할 수 없고, 데이터 생산자가 구현이 중요한 이유를 이해하지 못하며, 단편적인 유효성 검사 기술로 인해 모두가 잘못된 데이터를 방지하는 대신 반응하게 되기 때문에 데이터 팀에게 데이터 유효성 검사는 어렵습니다. 하지만 꼭 그럴 필요는 없습니다.

데이터 팀(및 이를 지원하는 엔지니어)은 함께 작업하고, 좋은 데이터의 교차 기능 이점을 수용하고, 데이터 관리 및 테스트를 더 쉽게 만들어주는 뛰어난 도구를 활용하여 데이터 품질 문제를 극복할 수 있습니다.