데이터 엔지니어링 공부 #1 — Coffee 와 coffee 는 다른 값이다

데이터 엔지니어링 공부를 시작했다. 지금 SK플래닛 부산 스마트항만 · 해양물류 데이터 실무 과정(K-뉴딜 아카데미)을 듣고 있고, 버크만 검사나 MBTI 같은 적성 검사에서도 데이터 엔지니어가 잘 맞는다는 결과가 나왔다. 10월부터 협업 프로젝트가 있으니 그것도 준비할 겸 시작했다.

Open Table of contents

Day 1 — 더러운 데이터를 일부러 만들어봤다
Day 2 — raw 데이터는 절대 업데이트하지 않는다
회고 — 문법보다 먼저 보는 눈
더 공부해볼 것

Day 1 — 더러운 데이터를 일부러 만들어봤다

첫날은 CSV 에서 랜덤으로 데이터를 만드는 것부터 했다. 그냥 깨끗한 데이터를 만든 게 아니라 일부러 망가뜨려서 만들었다.

Coffee 와 coffee 처럼 대소문자만 다른 값을 섞었다
군데군데 빈 값을 넣었다

그리고 집계해봤더니, 대소문자가 다른 값이 각각 별개의 카테고리로 인식돼서 제대로 분류되지 않았다. 사람 눈에는 같은 커피지만 기계는 다른 문자열로 본다. 머리로는 아는 얘기인데 직접 만들어놓고 결과를 보니 체감이 달랐다.

빈 값 쪽도 두 가지를 확인했다.

결측값 확인 — NULL 이 들어간 부분이 얼마나 되는지 세어봤다
합계 동작 — 합계를 낼 때 NULL 이 들어간 데이터는 빼고 합산된다

두 번째가 특히 조심스러운 지점 같다. NULL 이 있어도 에러가 나지 않고 조용히 빠진 채로 숫자가 나온다. 결측이 얼마나 되는지 먼저 세어보지 않으면 그 합계가 몇 건 기준인지 모르는 채로 쓰게 된다.

Day 2 — raw 데이터는 절대 업데이트하지 않는다

둘째 날 첫 번째로 배운 원칙이 이거였다. raw 데이터는 절대 업데이트하면 안 된다.

고쳐야 한다면 둘 중 하나다.

읽을 때 처리한다 — 원본은 그대로 두고 조회 시점에 변환
정리본을 staging 한다 — 정제한 결과를 별도 단계에 쌓는다

그리고 그 정제에 쓰는 SQL 을 배웠다. WHERE, ORDER BY 같은 기본과 함께 정제용 함수들을 봤다.

UPPER — 대소문자를 통일한다. Day 1 에서 Coffee / coffee 가 갈리던 문제가 여기서 풀린다.
CASE — 조건문처럼 쓴다. 값에 따라 다른 결과를 내보낼 수 있다.
COALESCE — NULL 을 0 같은 다른 값으로 바꾼다.

SELECT
  UPPER(category)        AS category,   -- Coffee / coffee 통일
  COALESCE(amount, 0)    AS amount,     -- NULL 을 0 으로
  CASE
    WHEN amount IS NULL THEN '결측'
    ELSE '정상'
  END                    AS status
FROM raw_orders
WHERE ...
ORDER BY ...

이렇게 정제한 데이터를 보는 단계가 staging 이라고 했다. Day 1 에서 손으로 확인했던 문제들이 Day 2 에서 각각 대응되는 도구를 가진 셈이라, 순서가 잘 짜인 커리큘럼이라는 생각이 들었다.

회고 — 문법보다 먼저 보는 눈

코드를 따라 치면서 든 생각이 하나 있다.

SQL 을 어떻게 쓰는지 아는 것도 중요하지만, 데이터를 보고 어떤 작업이 필요할지 느끼는 것도 그만큼 중요할 것 같다. 아무리 잘 정제하고 필요한 값을 뽑아낼 수 있어도, raw 데이터를 보고 어디를 정제해야 할지 모른다면 그다음 단계로 갈 수가 없다.

UPPER 를 아는 것과, 데이터를 열어보고 “여기 대소문자가 섞여 있네” 를 알아채는 것은 다른 능력이다. 전자는 검색하면 나오고 후자는 안 나온다.

더 공부해볼 것

NULL 의 3값 논리 — SQL 에서 NULL = NULL 이 참이 아닌 이유. 집계 함수가 NULL 을 건너뛰는 것과 COUNT(*) / COUNT(column) 의 차이도 같이 확인해볼 것. (PostgreSQL — Comparison Functions and Operators)
COALESCE 로 NULL 을 0 으로 바꿔도 되는 경우와 안 되는 경우 — “값이 0” 과 “값이 없음” 은 다른 의미다. 평균을 낼 때 이 둘을 섞으면 결과가 달라진다. 어떤 상황에서 채우고 어떤 상황에서 남겨야 하는지.
Medallion 아키텍처 (bronze / silver / gold) — 이번에 배운 raw → staging 이 더 큰 계층 구조의 일부인지. (Databricks — Medallion architecture)
대소문자 통일을 어디서 할 것인가 — UPPER 로 조회할 때마다 변환하는 방법과, staging 에 정규화된 값을 저장해두는 방법의 트레이드오프. 인덱스가 걸린 컬럼에 함수를 씌우면 인덱스를 못 타는 문제도 있다고 들었다.
데이터 프로파일링 도구 — 결측률 · 중복 · 값 분포를 자동으로 훑어주는 도구가 있는지. 매번 손으로 세는 대신 raw 를 받자마자 돌릴 수 있는 것.