수집

수집은 여러 곳에 흩어진 데이터를 한곳으로 들여옵니다. 데이터를 엮어 보거나 가공하려면 먼저 데이터가 한곳에 모여 있어야 합니다. 이 항목은 데이터를 옮기는 파이프라인의 첫 단계인 수집을 다룹니다. 서버 지표를 모으거나 웹 페이지를 긁어 오는 일도 같은 이름으로 부릅니다.

쉽고 빠른 이해

수집은 데이터가 생긴 곳에서 데이터를 가져와 한곳에 모아 두는 일입니다. 쇼핑몰의 주문 기록과 앱의 클릭 기록을 분석용 저장소 하나로 모으는 것이 수집입니다.

데이터가 흩어져 있으면 둘을 엮어 보는 질문에 답할 수 없습니다. 「광고를 누른 사람이 주문까지 했나」는 클릭 기록과 주문 기록이 한곳에 있어야 답이 나옵니다.

1. 데이터가 생긴 곳마다 가져오는 방법을 정합니다
2. 정해 둔 때에 한꺼번에 가져오거나, 생길 때마다 받아 옵니다
3. 가져온 것은 고치지 않고 먼저 저장합니다
4. 어디까지 가져왔는지 적어 둡니다

대가가 있습니다. 같은 데이터가 두 벌이 되어 저장 공간이 더 듭니다. 모아 둔 쪽은 원래 쪽보다 늘 조금 늦습니다.

데이터가 생긴 곳이 하나뿐이고 그곳을 바로 읽어도 손님 요청이 밀리지 않으면 수집 없이 그곳을 읽습니다.

상세

집배원은 동네 우체통을 돌며 편지를 걷어 우체국으로 가져옵니다. 편지를 나누고 배달하는 일은 우체국에 모인 뒤에 시작합니다. 걷으러 다니는 동안 집배원은 편지를 뜯어보지 않습니다.

수집은 데이터가 처음 생긴 곳에서 데이터를 가져와, 다루기로 정한 저장소에 들여놓는 일입니다. 쇼핑몰이라면 주문 데이터베이스의 주문, 앱이 보내는 클릭 기록, 결제 대행사가 매일 올리는 정산 파일이 가져올 데이터입니다. 이 셋을 분석용 저장소 하나에 모으는 일이 수집입니다.

수집이 필요한 까닭은 흩어진 데이터로는 엮어 보는 질문에 답할 수 없어서입니다. 「광고를 누른 사람이 주문까지 했나」는 클릭 기록과 주문 기록을 맞대어 봐야 답이 나옵니다. 두 기록은 담긴 곳도 모양도 다릅니다. 수집은 두 기록을 한곳에 모아 맞대어 볼 수 있게 합니다.

데이터를 내주는 곳을 원천이라고 부릅니다. 모아 두는 곳은 대상이라고 부릅니다. 원천은 대개 서비스를 돌리는 운영 시스템입니다. 대상은 분석을 위해 따로 둔 저장소입니다.

대상으로 흔히 쓰는 저장소는 둘입니다. 표 모양으로 정리해 두고 조회하는 데이터 웨어하우스가 하나입니다. 모양을 가리지 않고 파일로 쌓아 두는 데이터 레이크가 다른 하나입니다.

이 절은 쇼핑몰의 세 원천을 예로 들어 수집을 봅니다. 먼저 수집이 파이프라인에서 맡는 단계를 보고, 가져오는 방식이 갈리는 세 축을 봅니다. 이어서 수집에서 흔히 생기는 문제와 수집의 대가, 수집이 필요 없는 경우를 봅니다. 끝으로 같은 이름을 쓰는 다른 분야의 수집을 가릅니다.

파이프라인의 첫 단계

파이프라인은 원천에서 대상까지 데이터를 여러 단계에 걸쳐 옮기는 작업의 묶음입니다. 수집은 그 맨 앞 단계입니다. 다른 팀의 시스템에 있던 데이터가 대상으로 처음 넘어오는 단계가 수집입니다.

flowchart TD
    subgraph 원천
        A[주문 데이터베이스]
        B[클릭 기록]
        C[정산 파일]
    end
    A --> D[수집]
    B --> D
    C --> D
    subgraph 대상
        E[원본 영역] --> F[변환]
        F --> G[분석용 테이블]
    end
    D --> E

그림에서 세 원천은 모양도 가져오는 방법도 서로 다릅니다. 수집은 이 차이를 받아 냅니다. 그리고 모든 데이터를 대상 안의 원본 영역 한곳에 내려놓습니다. 원본 영역은 고치지 않은 원본을 받아 두는 구역입니다.

모양을 고치는 변환은 그다음 단계입니다. 변환을 거친 데이터는 같은 대상 안의 분석용 테이블에 담깁니다. 그림은 이처럼 먼저 싣고 나중에 고치는 순서를 그렸습니다. 이 순서에는 이름이 따로 있습니다.

싣는 것과 고치는 것의 순서

데이터를 옮기는 절차는 흔히 세 단계로 나눕니다. 원천에서 읽어 내는 추출, 모양을 고치는 변환, 대상에 써 넣는 적재입니다. 변환을 적재 앞에 두느냐 뒤에 두느냐에 따라 이름이 둘로 갈립니다. 수집이 맡는 몫도 달라집니다.

변환을 적재 앞에 두는 순서는 ETL(Extract-Transform-Load, 추출-변환-적재)입니다. 원천에서 읽은 데이터를 고친 다음에 대상에 씁니다. 이 순서에서 수집이 맡는 것은 추출입니다.

앞의 그림은 변환을 적재 뒤에 둔 순서입니다. 이 순서의 이름은 ELT(Extract-Load-Transform, 추출-적재-변환)입니다. ETL 과 글자 순서만 다릅니다. 이 순서에서는 수집이 추출과 적재를 함께 맡습니다.

그래서 수집이라는 말이 가리키는 범위는 순서에 따라 다릅니다. 같은 순서를 쓰더라도 범위를 어디까지로 잡는지는 팀과 도구마다 조금씩 다릅니다.

원본 영역

원본 영역은 대상 저장소 안에서 수집한 원본만 받아 두는 구역입니다. 실무에서는 랜딩 존이라고도 부릅니다. 수집한 데이터는 대개 이곳에 모양을 고치지 않은 채 먼저 저장합니다.

원본을 남겨 두는 까닭은 변환 규칙이 나중에 바뀌기 쉬워서입니다. 규칙이 틀렸다는 것을 한 달 뒤에 알아도 원본이 있으면 고친 규칙으로 다시 돌리면 됩니다. 원본이 없으면 원천에 다시 가야 합니다. 원천에서는 그 사이 데이터가 바뀌었거나 지워졌을 수 있습니다.

배치 수집과 스트리밍 수집

수집 방식은 먼저 언제 가져오느냐로 갈립니다. 정해 둔 때에 쌓인 몫을 한꺼번에 가져오는 방식을 배치 수집이라고 부릅니다. 매일 새벽 두 시에 전날 주문을 모아 오는 작업이 배치 수집입니다. 모아서 한 번에 처리하는 이 방식을 넓게 배치 처리라고 합니다.

데이터가 생길 때마다 곧바로 받아 오는 방식은 스트리밍 수집입니다. 앱의 클릭 기록처럼 끊임없이 생기는 데이터가 그 대상입니다. 생기는 대로 한 줄씩 흘러오는 기록의 흐름을 이벤트 스트림이라고 부릅니다. 스트리밍 수집은 이 흐름을 받아 옵니다.

두 방식은 얻는 것과 내주는 것이 반대입니다. 네 가지 기준으로 나란히 놓으면 이렇습니다.

표에서 갈리는 것은 대상이 얼마나 최신이어야 하느냐입니다. 하루 한 번 보는 매출 보고서라면 배치 수집으로 모자람이 없습니다. 수상한 결제를 바로 막아야 한다면 스트리밍 수집이 필요합니다.

풀 방식과 푸시 방식

두 번째 축은 누가 먼저 움직이느냐입니다. 수집하는 쪽이 원천에 찾아가 새 데이터를 달라고 묻는 방식을 풀(pull) 방식이라고 부릅니다. 정해 둔 간격마다 원천에 되풀이해 묻는 일을 폴링이라고 합니다.

원천이 데이터가 생길 때마다 수집하는 쪽으로 보내오는 방식은 푸시(push) 방식입니다. 결제 대행사가 결제가 끝날 때마다 쇼핑몰이 정해 둔 주소로 알려 오는 것이 그 예입니다. 이렇게 일이 생기면 미리 받아 둔 주소로 요청을 보내 알리는 방식을 웹훅이라고 부릅니다.

풀 방식에서는 수집하는 쪽이 속도를 정합니다. 받을 수 있을 만큼만 가져오므로 넘칠 일이 적습니다. 대신 묻는 간격만큼 늦습니다. 새것이 없어도 계속 물어야 합니다.

푸시 방식에서는 원천이 속도를 정합니다. 새것이 생기자마자 옵니다. 대신 한꺼번에 몰려오면 받는 쪽이 다 처리하지 못합니다.

그래서 받는 쪽 앞에 메시지 큐를 둡니다. 몰려온 것을 큐에 쌓아 두었다가 차례로 꺼내 처리합니다.

전체 수집과 증분 수집

세 번째 축은 한 번에 얼마나 가져오느냐입니다. 매번 원천의 데이터를 전부 다시 읽어 오는 방식을 전체 수집이라고 부릅니다. 상품 분류표처럼 작고 드물게 바뀌는 표라면 매일 전부 읽어 와도 부담이 적습니다.

주문 표처럼 계속 커지는 원천은 매번 전부 읽을 수 없습니다. 읽는 시간이 날마다 늡니다. 읽는 동안 원천에도 부하가 걸립니다. 그래서 지난번 이후 새로 생기거나 바뀐 몫만 가져오는 증분 수집을 씁니다.

증분 수집은 어디까지 가져왔는지를 기억해야 합니다. 흔한 방법은 마지막으로 가져온 행의 수정 시각을 적어 두는 것입니다. 다음 차례에는 그 시각 뒤에 바뀐 행만 읽습니다. 이렇게 진행 위치를 적어 둔 표시가 체크포인트입니다.

스트리밍 수집도 진행 위치를 적어 둡니다. 흐름에서 몇 번째 기록까지 읽었는지를 오프셋이라는 번호로 남깁니다. 수집이 멈췄다가 다시 뜨면 이 번호 다음부터 이어 받습니다.

수정 시각으로 찾는 방법은 지워진 행을 놓칩니다. 지워진 행은 표에서 사라져서 조회에 걸리지 않기 때문입니다. 원천 데이터베이스가 스스로 남기는 변경 기록을 읽어 들이면 추가와 수정과 삭제를 모두 받아 올 수 있습니다. 이 방법을 변경 데이터 캡처라고 부릅니다.

같은 데이터가 두 번 들어오는 문제

수집은 다른 팀의 시스템과 맞닿아 있어서 수집하는 쪽이 통제할 수 없는 일이 자주 생깁니다. 이 소절부터 흔한 문제 셋을 차례로 봅니다. 첫째는 같은 데이터가 두 번 들어오는 문제입니다.

수집 작업은 도중에 실패하면 다시 돕니다. 이것을 재시도라고 합니다. 실패한 차례에 절반쯤 이미 써 두었다면, 다시 돌 때 그 절반이 한 번 더 들어갑니다. 같은 주문이 두 번 들어가면 매출이 부풀어 보입니다.

그래서 같은 데이터를 여러 번 넣어도 한 번 넣은 것과 결과가 같게 만듭니다. 이 성질이 멱등성입니다. 넣을 때는 주문 번호처럼 행마다 하나뿐인 값을 기준으로 삼습니다. 그 값의 행이 이미 있으면 덮어쓰고, 없으면 새로 넣습니다.

원천의 모양이 바뀌는 문제

데이터가 어떤 열과 어떤 형식으로 이루어지는지 적은 정의를 스키마라고 부릅니다. 원천은 대개 다른 팀의 시스템이라 스키마가 예고 없이 바뀝니다. 열 이름이 바뀌면 수집 작업이 멈추거나 값을 엉뚱한 열에 씁니다.

막는 방법은 두 가지입니다. 하나는 수집할 때마다 들어온 데이터의 스키마를 확인해서, 바뀌었으면 멈추고 알리는 방법입니다. 다른 하나는 새 열이 생기는 정도의 변화를 받아들이도록 대상 쪽 스키마를 함께 넓히는 방법입니다. 이렇게 스키마가 바뀌어도 데이터를 계속 받는 일을 스키마 진화라고 부릅니다.

늦게 도착하는 데이터

스트리밍 수집에서는 데이터가 생긴 순서대로 도착하지 않습니다. 휴대폰이 지하철에서 연결이 끊겼다가 나중에 다시 붙으면, 한 시간 전의 클릭 기록이 한꺼번에 도착합니다. 도착한 시각으로 묶어 세면 그 클릭들이 엉뚱한 시간대에 들어갑니다.

그래서 기록에는 도착한 시각과 별개로 일이 일어난 시각을 함께 담아 둡니다. 일이 일어난 시각을 이벤트 시간이라고 부릅니다. 수집하는 쪽이 받은 시각은 처리 시간이라고 부릅니다.

집계는 이벤트 시간을 기준으로 합니다. 얼마나 늦게 온 기록까지 받아 줄지는 따로 정합니다.

두 벌이 되는 데이터

수집하면 같은 데이터가 원천과 대상에 두 벌 생깁니다. 저장 공간이 그만큼 더 듭니다. 두 벌이 서로 맞는지 살피는 일도 생깁니다.

대상은 원천보다 늘 조금 늦습니다. 대상이 원천을 얼마나 따라잡았는지 나타내는 말이 데이터 신선도입니다.

고객 정보도 함께 옮겨집니다. 원천에서 지운 고객 정보가 대상에는 남아 있을 수 있습니다. 그러면 고객이 지워 달라고 한 정보를 회사가 계속 가지고 있게 됩니다. 그래서 무엇을 가져올지, 무엇을 가리거나 뺄지를 수집 단계에서 정해 둡니다.

수집이 필요 없는 경우

수집을 두지 않아도 되는 경우도 있습니다. 필요한 데이터가 원천 하나에 다 있고, 원천에 조회를 걸어도 손님 요청이 밀리지 않는다면 원천을 직접 읽으면 됩니다. 원천이 여럿으로 늘거나 조회가 손님 요청을 밀어내기 시작하면 그때 수집을 둡니다.

같은 이름을 쓰는 다른 분야의 수집

「수집」은 데이터 파이프라인 밖에서도 흔히 쓰입니다. 무엇을 모으고 어디로 모으는지가 분야마다 다르므로 표로 가릅니다.

모니터링의 수집은 이 항목의 수집과 가장 가깝습니다. 서버마다 도는 수집기가 지표를 모아 감시용 저장소로 보냅니다. 웹 크롤링은 크롤러라는 프로그램이 링크를 따라가며 페이지를 받아 오는 일입니다.

메모리 관리에서 말하는 수집은 가비지 컬렉션을 가리킵니다. 데이터를 모으는 일이 아니라 쓰지 않는 메모리를 되찾는 일이라 이름만 같습니다.

관련 항목

수집의 양 끝에 서는 역할

원천 · 대상 · 생산자 · 소비자 · 커넥터

수집과 함께 파이프라인을 이루는 처리 단계

추출 · 변환 · 적재 · 파이프라인 · ETL · ELT · 데이터 엔지니어링

수집한 데이터가 모이는 저장소

데이터 웨어하우스 · 데이터 레이크 · 랜딩 존 · 레이크하우스 · 객체 스토리지

수집이 데이터를 받아 오는 방식

배치 처리 · 스트림 처리 · 이벤트 스트림 · 폴링 · 푸시 · 웹훅 · 전체 추출 · 증분 추출 · 변경 데이터 캡처 · 메시지 큐 · Apache Kafka

수집의 진행 위치를 기억하는 수단

체크포인트 · 오프셋 · 하이 워터마크

수집에서 생기는 문제와 막는 수단

재시도 · 멱등성 · 중복 적재 · 스키마 · 스키마 진화 · 이벤트 시간 · 처리 시간 · 늦게 도착한 데이터 · 백프레셔 · 데이터 신선도

수집과 이름이 겹치는 헷갈리는 이웃

수집기 · 모니터링 · 메트릭 · 로그 · 로그 수집 · 크롤러 · 가비지 컬렉션