데이터 품질의 비밀 (3)

데이터 수집 · 정제 · 변환 · 테스트

---

(1) 데이터 수집

수집에만 초점을 두면 데이터 파이프라인의 시작 부분인 업스트림에 있는 진입점이 가장 중요하다고 소개한다. Docker를 예시로 들면 entrypoint라고 할 수 있다. 진입점의 데이터는 모델링을 하는 외부 세계의 전형적인 노이즈와 불규칙성을 모두 내포하고 있어 가장 원시적이다. 대게 데이터 엔지니어가 데이터 수집 소스를 보유하지는 않는다. 대부분 분석 서비스 또는 API와 같은 일부 비즈니스 목표, 업스트림 도구에 의존한다. 데이터 소스는 크게 세가지로 분류 된다.

1. 애플리케이션 로그 데이터

• 소프트웨어 애플리케이션 내의 작업으로 생성된 데이터를 나타내며 클라이언트용 또는 내부용일 수 있다. 작업은 사용자 시작 또는 프로그래밍 방식일 수 있다. 소프트웨어 logger의 INFO나 DEBUGGER가 이 종류 중 하나이다.
• 운영 체제가 부팅될 때 시스템 로그와 달리 애플리케이션 로그에 포함되거나 제외하는 것 개발자에게 달렸다.
• 수집 예시 : 한 블로그 독자가 웹페이지에서 10분을 머물렀으며 텍스트에서 나가는 링크를 3개 클릭.
• 어플리 케이션 로그는 단순 직렬화 텍스트 데이터이므로 ASCII 또는 이진 형식으로 사용할 가능성이 높다. 구조는 개발자에게 달려있어 다양하며 아래는 기본적인 고려 요소이다.
  • 타임스탬프 : 로그 텍스트는 대부분 줄바꿈으로 구분되어 있는 개별 이벤트이다. 프로그래머가 작업을 올바르게 수행하는 경우 이벤트에 타임스탬프가 표시된다. 타임스탬프는 이벤트 설명과 달리 ISO 표준 형식이나 이와 유사한 형식으로 표준화되어야한다.
  • 로그레벨 : 좋은 애플리케이션 로그는 'LEVEL'을 사용하여 대략적으로 각 이벤트의 로그 유형을 체계화한다. INFO, WARN, ERROR
  • 목적 : 모든 데이터는 수집하는 데 비용이 들기 때문에 쓸모 없는 로그라도 어딘가에 쓸모가 있어야한다.
    • 요청이 얼마나 자주 시간을 초과하는지?
    • 페이지 로드가 느려지고 있는지?
    • 더 이상 활용되지 않는 라이브러리 기능을 사용하고 있는지?

2. API 응답

• 하나의 애플리케이션으로 모든 것을 할 수 없기 때문에 특정 기능을 다른 애플리케이션에 맡긴다. API는 두 프로그램 사이의 매개체로, 특정 형식의 '요청'과 이에 대한 '응답'이 필요하다. 반구조화 데이터를 사용한다. API에서 가져온 앤드포인트에서 데이터를 저장할 수 있다. API 데이터를 사용할 때 다음 사항에 주의 해야한다.
  • 구조 : API 응답 개체는 로그처럼 직렬화할 수 있지만 구조화 또는 반구조화 형식으로 압축이 풀린다. JSON은 매우 유연하지만 중요한 방식으로 구조에 제약을 받는다.(key-value) 로그 데이터와 많이 다르다. 이처럼 HTTP/1.1과 같은 HTTP 응답 사양은 HTTP 요청 또는 응답 본문에도 JSON 또는 XML을 포함할 수 있다.
  • 응답 코드 : API 요청은 성공하거나 실패할 수 있으므로 대부분의 API 사양에는 다양한 응답 유형에 대한 코드가 있다.
    • HTTP 상태 코드 : 200 OK, 404 Not Found, 500 Internal Server Error
    • 기타 전송 프로토콜 : SOAP API
  • 목적 : API 사용 사례의 세계는 방대하므로 발생할 수 있는 모든 내용을 예측할 수 없다. 또 서버 오류율을 줄이고 싶다면 코드를 볼것이다. 이처럼 특정 상황에서 전송된 일부 정보는 유용하지 않을 수 있다.

3. 센서 데이터

• 수집할 수 있는 세 번째 형태의 데이터는 사물 인터넷 장치 또는 연구 장비와 같은 '센서'에서 얻을 수 있다. 센서는 내부 논리가 매우 단순하기 때문에 반드시 애플리케이션으로 활용하진 않는다. GPU 점유율, GPU 온도, CPU 사용량 등이 이에 해당한다. 주요 고려 사항은
  • 노이즈 : 실제 센서 데이터에는 수 많은 노이즈가 존재한다. 일부 데이터는 Garbage일 수 있다. 하지만 이 데이터를 가지고 평활화, 변환 등을 통해 오류를 제거 할 수 있다.

(2) 배치 vs 실시간 처리

2010년까지 데이터를 배치로 처리하는 것이 일반적이지만 이후 실시간 처리에 대한 수요가 늘며 두가지 모두 사용하고 있다.

• 배치 처리 : 일정 기간 동안 데이터를 수집하여 대량의 데이터를 별개의 패킷으로 '배치'
  • ex) 신용 카드 거래 처리
• 실시간 처리 : 프로세스는 길지만 데이터를 거의 즉시 처리
  • ex) 사기 신고 방지

배치 프로그램

• 오픈 소스
  • 대용량 분산 처리 오픈 프로그램 하둡
• 사설
  • Google bigQuery, SnowFlake, Microsoft Azure, Amazon Redshift

실시간 처리 프로그램

• 오픈소스
  • Spark, Kafka, Flink, Storm, Flume, Apache Solution
  배치프로그램은 가능한 많은 양의 데이터를 처리하는 것과 반면 실시간 데이터는 가능한 빠르게 데이터를 제공하는 것에 초점이 되어 있다. 각 데이터의 품질은 배치프로그램이 더 높은 경향이 있다. 실시간 데이터(스트림)는 오류에 더 취약하기 때문이다.

실시간 데이터의 오류에 대한 예시를 들면 실시간으로 고객에게 맞는 광고를 게시할 때 오류로 인해 잘못된 광고를 보낸다면 쓸데없는 광고 비용으로 인한 지출이 계속 발생할 것이다. 잠재적인 수익을 놓치거나 사용자 경험을 저하시키는 관련 없는 광고를 게시 할 수도 있다.

이런 문제를 해결하기 위해 데이터 품질은 테스트를 통해 관리 된다. 테스트 이후 문제가 없는 식으로 배치 형태로 처리를 했다. 실시간 데이터에서는 어떻게 이러한 문제를 해결할까?

• 데이터 품질에 관한 새로운 오류는 항상 발생하며 엔지니어들은 문제가 다운스트림 테이블과 사용자에게 영향을 미치기 전에 원인을 분석한다. 하지만 이러한 처리도 20% 밖에 해결하지 못했다. 적은 수의 해결이라도 '알려진 미지'(예측가능한것)가 존재한 것이다. 데이터 생태계에서는 복잡성이 증가함에 따라 기존의 처리 및 테스트 방법이 구식으로 보이기 시작했다.