원천

원천은 데이터를 옮기는 작업에 데이터를 내줍니다. 주문을 받는 서비스의 데이터베이스처럼 데이터가 처음 생기는 곳이 대개 원천이 됩니다. 옮기는 작업은 원천에서 읽고 다른 곳에 씁니다. 받는 곳은 대상이라고 부릅니다.

상세

원천은 데이터를 옮기는 작업이 데이터를 읽어 오는 곳입니다. 작업 하나를 정하면 그 작업이 읽는 곳이 원천이 됩니다. 주문 테이블을 매출 분석용 테이블로 옮기는 작업에서는 주문 테이블이 원천입니다. 이 절은 이 주문 테이블 작업을 예로 들어 원천의 짝과 종류, 읽는 방법, 다룰 때 생기는 문제를 봅니다.

원천과 대상

원천은 혼자 서는 이름이 아닙니다. 언제나 데이터를 받는 쪽과 짝을 이룹니다. 그 받는 쪽을 대상이라고 부릅니다. 원천과 대상이 정해지면 옮기는 작업의 양 끝이 정해집니다.

데이터는 원천에서 대상까지 몇 단계를 거쳐 갑니다. 그 단계들을 차례로 이어 놓은 것이 파이프라인입니다. 파이프라인은 흔히 아래 그림처럼 세 단계로 나뉩니다.

flowchart TD
    A["원천 · 주문 테이블"] --> B["추출 · 읽어 온다"]
    B --> C["변환 · 모양을 고친다"]
    C --> D["적재 · 써 넣는다"]
    D --> E["대상 · 매출 분석용 테이블"]

• 원천에서 데이터를 읽어 오는 단계가 추출입니다
• 읽어 온 데이터의 모양을 대상에 맞게 고치는 단계가 변환입니다
• 대상에 써 넣는 단계가 적재입니다

원천은 이 흐름의 시작입니다. 그래서 원천에 없는 데이터는 뒤의 어느 단계에서도 생기지 않습니다.

이어지는 작업에서 바뀌는 원천

원천은 역할 이름입니다. 한 작업의 대상이 다음 작업의 원천이 될 수 있습니다.

수도꼭지에서 받은 물을 주전자에 붓습니다. 주전자의 물은 컵에 따릅니다. 컵을 채우는 사람에게 물은 주전자에서 옵니다. 주전자를 채우는 사람에게 물은 수도꼭지에서 옵니다.

원천도 이렇게 지금 어느 작업을 보느냐가 정합니다. 주문 테이블을 데이터 웨어하우스로 옮기는 작업이 있다고 해 봅시다. 웨어하우스는 이 작업의 대상입니다. 그 웨어하우스에서 일별 매출을 모아 대시보드용 요약 표를 만드는 작업이 이어지면, 웨어하우스는 이번에는 원천입니다.

flowchart TD
    A["주문 테이블"] -->|"작업 1"| B["데이터 웨어하우스"]
    B -->|"작업 2"| C["일별 매출 요약 표"]

작업 1에서 웨어하우스는 대상입니다. 작업 2에서는 원천입니다. 그래서 「원천」이라고만 말하면 어느 작업을 두고 하는 말인지가 빠집니다. 사슬의 맨 처음, 데이터가 처음 생긴 시스템을 콕 집어 말할 때는 원천 시스템이라고 부릅니다.

사슬을 거슬러 올라가며 어떤 숫자가 어느 원천에서 왔는지를 추적하는 일도 있습니다. 대시보드 숫자가 이상할 때 원천까지 거슬러 가 봐야 어디서 틀렸는지 찾을 수 있습니다. 이렇게 거쳐 온 길을 기록해 둔 것이 데이터 계보입니다.

원천이 되는 것들

원천은 데이터를 담고 있고 읽을 수 있는 것이면 무엇이든 될 수 있습니다. 자주 만나는 것을 모으면 아래와 같습니다. 셋째 열은 읽기를 언제 끝낼 수 있는지를 적었습니다.

원천은 모양이 제각각입니다. 옮기는 작업은 원천마다 읽는 방법을 따로 갖춥니다. 원천 하나를 읽는 방법을 묶어 둔 부품을 커넥터라고 부릅니다.

작업 설정에는 원천마다 주소와 접속 정보를 적어 둡니다. 새 원천이 생기면 설정 한 줄과 커넥터 하나를 더합니다.

끝이 있는 원천과 끝이 없는 원천

표의 셋째 열이 원천을 둘로 가릅니다. 파일처럼 고정된 원천은 끝이 있습니다. 끝까지 읽으면 그 원천이 가진 데이터를 전부 읽은 것입니다.

이벤트 스트림처럼 계속 새 데이터가 들어오는 원천은 끝이 없습니다. 지금까지 온 것을 다 읽어도 잠시 뒤에 또 옵니다. 이런 원천에서는 「다 읽었다」가 성립하지 않습니다.

이 차이가 옮기는 방식을 가릅니다. 끝이 있는 데이터를 정해진 때에 한 덩이씩 처리하는 방식을 배치 처리라고 부릅니다. 끝이 없는 데이터를 오는 대로 이어서 처리하는 방식이 스트림 처리입니다.

운영 데이터베이스는 그 사이에 섭니다. 테이블은 계속 바뀌지만, 한 시점에 떠 온 내용은 끝이 있습니다. 그래서 밤마다 떠 와서 배치로 옮기기도 합니다. 바뀌는 것을 이어 받아 스트림으로 옮기기도 합니다.

원천에서 읽어 오는 방법

읽는 방법은 크게 넷입니다. 읽을 때마다 원천에 주는 부담과 놓치는 것이 다릅니다.

증분 추출은 어디까지 읽었는지를 값 하나로 기억합니다. 대개 마지막으로 읽은 행의 수정 시각입니다. 다음 차례에는 그 값보다 뒤에 바뀐 행만 고릅니다.

SELECT * FROM orders
WHERE updated_at > '09-23 23:00'  -- 지난번 끝

조건의 시각이 지난번에 읽은 마지막 값입니다. 이 값을 하이 워터마크라고 부릅니다. 읽기가 끝나면 이번에 읽은 행 가운데 가장 늦은 수정 시각으로 값을 갱신해 둡니다.

증분 추출이 지워진 행을 놓치는 까닭은 이 방식이 원천에 남아 있는 행만 보기 때문입니다. 지워진 행은 원천에 없으니 조건에 걸리지 않습니다. 변경 데이터 캡처는 원천 데이터베이스가 스스로 남기는 변경 기록을 읽어서 이 틈을 메웁니다. 그 기록에는 지운 일도 한 줄로 남습니다.

원천에 주는 부담

원천은 대개 옮기는 작업을 위해 만든 시스템이 아닙니다. 운영 데이터베이스는 손님의 주문을 받으려고 있습니다. 옮기는 작업이 그 데이터베이스에 큰 조회를 걸면 손님 주문을 처리할 몫이 줄어듭니다.

그래서 원천을 읽을 때는 부담을 줄이는 방법을 함께 씁니다. 원천 데이터베이스의 내용을 계속 따라 받아 두는 데이터베이스를 하나 더 두고 거기서 읽습니다. 그렇게 따라 받는 데이터베이스가 레플리카입니다. 손님이 적은 새벽에 읽거나, 전체 추출 대신 증분 추출로 읽는 양을 줄이기도 합니다.

같은 까닭으로 옮기는 작업은 원천에 쓰지 않습니다. 원천에서는 읽기만 합니다. 고치는 일은 전부 원천 밖에서 합니다. 원천의 데이터를 고쳐 버리면 원천을 쓰는 서비스가 엉뚱한 값을 보게 됩니다.

원천의 모양이 바뀔 때

원천은 다른 팀이 굴리는 시스템인 경우가 많습니다. 그 팀은 자기 서비스에 맞춰 테이블에 열을 더하거나 열 이름을 바꿉니다. 옮기는 작업은 그 소식을 늦게 듣습니다.

원천이 담는 데이터의 모양, 곧 어떤 열이 있고 각 열에 어떤 종류의 값이 들어가는지를 스키마라고 부릅니다. 원천의 스키마가 바뀌면 옮기는 작업이 기대한 열이 없어서 멈추거나, 멈추지 않고 빈 값을 채워 넣습니다. 멈추지 않는 쪽이 더 늦게 발견됩니다.

이 문제를 줄이려고 원천을 굴리는 팀과 옮기는 팀이 스키마를 미리 약속해 둡니다. 그 약속이 데이터 계약입니다. 약속을 깨는 변경은 미리 알립니다. 옮기는 작업은 약속과 다른 데이터가 들어오면 바로 멈춥니다.

받은 그대로 한 벌 남기기

원천에서 읽어 온 데이터를 곧바로 변환하면 원래 모습이 사라집니다. 나중에 변환 코드에서 잘못을 찾으면 원천을 다시 읽어야 합니다. 그 사이 원천의 데이터가 바뀌었거나 지워졌으면 되살릴 수 없습니다.

그래서 읽어 온 데이터를 고치지 않은 채로 먼저 한 벌 저장해 둡니다. 원천에서 받은 모습 그대로 남긴 이 데이터를 원시 데이터라고 부릅니다.

원시 데이터를 모아 두는 영역이 스테이징 영역입니다. 추출한 데이터는 먼저 여기에 쌓입니다. 변환은 여기서 데이터를 읽어 갑니다.

변환이 틀렸으면 원시 데이터에서 다시 변환하면 됩니다. 원천을 다시 건드리지 않습니다. 이렇게 다시 돌리는 일이 재처리입니다.

진실의 원천

같은 데이터가 여러 시스템에 나뉘어 있으면 시스템끼리 값이 어긋날 때가 옵니다. 고객 주소가 주문 시스템과 분석 저장소와 메일 발송 시스템에 따로 있으면 셋 중 어느 것이 맞는지 정해 둬야 합니다.

그렇게 정해 둔 기준 원천을 진실의 원천이라고 부릅니다. 값이 어긋나면 진실의 원천의 값을 따릅니다. 나머지는 거기에 맞춥니다.

한 데이터에 진실의 원천을 하나만 두는 원칙이 단일 진실 공급원입니다. 공급원은 여기서 원천과 같은 말(영어 source)입니다.

진실의 원천은 데이터가 처음 생기는 원천 시스템인 경우가 많습니다. 주소를 바꾸는 화면이 주문 시스템에만 있으면 주문 시스템의 값이 기준이 됩니다. 다른 시스템의 값은 거기서 옮겨 온 것이라 늦게 바뀌기 때문입니다.

관련 항목

원천과 맞세워지는 반대편 역할

대상 · 싱크 · 생산자 · 소비자 · 클라이언트 · 서버

원천에서 대상까지 데이터가 거치는 처리 단계

추출 · 변환 · 적재 · 파이프라인 · ETL · ELT · 수집 · 커넥터

원천이 되는 데이터 저장소와 흐름

데이터베이스 · API · 이벤트 스트림 · 로그 · 메시지 큐 · 파일 · 운영 데이터베이스

원천에서 데이터를 읽어 오는 방법

전체 추출 · 증분 추출 · 변경 데이터 캡처 · 하이 워터마크 · 폴링 · 웹훅 · 오프셋 · 체크포인트

원천의 데이터를 옮겨 담는 저장소

데이터 웨어하우스 · 데이터 레이크 · 스테이징 영역 · 레플리카 · 복제

원천을 다룰 때 생기는 문제와 대응

스키마 · 스키마 진화 · 데이터 계약 · 원시 데이터 · 재처리 · 멱등성 · 복제 지연 · 데이터 계보 · 단일 진실 공급원

원천에서 온 데이터를 처리하는 방식

배치 처리 · 스트림 처리 · 데이터 엔지니어링 · 스트림