근본 원인은 문제 해결의 종착점입니다. 인과 관계에서 최초로 일어난 사건, 즉 첫 번째 도미노와 같아야 하며, 대부분의 문제를 설명할 수 있어야 합니다. 데이터 문제의 근본 원인이 발생하지 않았다면, 근접 원인도 발생하지 않아야 합니다. 근본 원인은 이 모든 근접 원인과 직접적으로 연결되어 있습니다.
물론 근본 원인은 항상 명확하지 않고, 상관관계도 항상 정확하지 않습니다. 자신의 답변에 확신이 서지 않는다면, 이 사고 실험을 통해 나의 실제 확신 점수를 확률적으로 확인해 볼 수 있습니다. 상사가 "팀이 네가 세운 가설에 전적으로 올인할 것이고, 운영 단계에 들어가기 전에는 아무도 확인하지 않을 것"이라고 말하고, 나는 그 결과에 대한 모든 책임을 지게 된다고 상상해 보세요. 만약 가설이 틀리면 모든 책임은 전적으로 나에게 있습니다. 이때, 가설에 대해 0~100점 중 몇 점의 신뢰도를 부여하시겠어요? 70점 미만이라면 계속 조사하세요.
일반적인 근본 원인 데이터 문제는 다음과 같습니다.
1. 사용자 오류: 사용자 오류는 흔히 발생하기 때문에 먼저 다루겠습니다. 누군가 잘못된 스키마나 값을 입력하여 파이프라인이 데이터를 읽지 못했거나, 잘못된 값으로 올바른 작업을 수행하다가 작업 실패가 발생했을 수 있습니다.
2. 레이블이 잘못 지정된 데이터: 테이블에서 행이 이동하면서 올바른 레이블이 잘못된 열에 적용되는 경우가 있습니다.
3. 데이터 파트너가 제때 보내지 않은 경우: 이 문제 역시 매우 일반적입니다. 완벽한 시스템을 구축할 수는 있지만 보이지 않는 것을 통제할 수는 없으며, 소스 데이터에 데이터 문제가 있는 경우, 완벽하게 좋은 파이프라인도 제대로 작동하지 않게 됩니다.
4. 코드에 버그가 있는 경우: 파이프라인의 새 버전에서 흔히 발생하는 문제입니다. Git 또는 GitLab과 같은 버전 관리 소프트웨어를 사용하면 이를 매우 빠르게 파악할 수 있습니다. 프로덕션 코드를 이전 버전과 비교하고 해당 이전 버전으로 테스트를 실행합니다.
5. OCR 데이터 오류: 광학 스캐너가 데이터를 잘못 읽어 이상값 또는 결측값이 생깁니다.
6. 오래된 데이터 문제: 데이터 세트가 너무 오래되어 더 이상 유효하지 않습니다.
7. 중복 데이터 문제: 공급업체가 데이터를 제공하지 못해 파이프라인이 지난 주 데이터에 대해 실행되는 경우가 종종 있습니다.
8. 권한 문제: 시스템에 데이터를 가져오거나 변환을 수행할 수 있는 권한이 없어 파이프라인이 실패했습니다.
9. 인프라 오류: 사용 가능한 메모리 또는 API 호출 한도를 초과했거나, Apache Spark 클러스터가 실행되지 않았거나, 데이터 웨어하우스가 비정상적으로 느려서 데이터 없이 실행이 진행되었을 수 있습니다.
10. 일정 변경: 누군가 또는 무언가가 일정을 변경하여 파이프라인이 잘못 작동하거나 실행되지 않습니다.
11.편향된 데이터 세트: 분류하기가 매우 까다롭습니다. 데이터가 유사한 실제 데이터 세트와 비교하여 비정상적인지 확인하기 위해 몇 가지 테스트를 실행하거나 데이터가 어떻게 수집 또는 생성되었는지 알아내는 것 외에는 이를 파악하는 좋은 방법은 없습니다.
12. 오케스트레이터 실패: 파이프라인 스케줄러가 작업을 예약하거나 실행하지 못했습니다.
13. 고스트 인 더 머신(데이터 엑소 마키나): 알 수 없는 상황입니다. 이를 인정하기는 어렵지만, 어떤 경우에는 사실입니다. 할 수 있는 최선은 문서화하여 더 많은 데이터를 수집하고 상관관계를 도출할 수 있을 때를 대비하는 것입니다.
물론 근본 원인이 완전히 명확하지 않은 현실도 있습니다. 많은 것들이 서로 연관되어 있고 아마도 상호 의존적일 수 있지만, 딱 하나의 명확한 답은 없습니다. 그리고 변경을 한 후에 데이터 문제를 해결했지만 이유가 확실하지 않기도 합니다.
이러한 경우에는 다른 경우와 마찬가지로 로그에 가설을 기록하고, 다시 돌아올 수 있을 때 과거 데이터를 계속 테스트하면서 새로운 문제와 더 설명할 수 있는 원인을 찾아보세요.
