데이터 레이크

데이터 레이크는 주문 기록·서버 로그처럼 회사 곳곳에서 생기는 데이터를 손대지 않은 채 한곳에 쌓는 저장소입니다. 어떤 모양으로 읽을지는 꺼내 쓸 때 정하기로 한 설계 결정이기도 합니다. 그래서 아직 떠오르지 않은 질문에도 원본으로 돌아가 답할 수 있습니다. 대신 정리 없이 쌓인 데이터는 무엇이 어디 있는지 아무도 모르게 됩니다.

쉽고 빠른 이해

데이터 레이크는 주문 기록, 서버 로그, 앱 클릭 기록처럼 성격이 다른 데이터를 받은 모양 그대로 한 저장소에 쌓습니다. 로그 파일은 로그 파일로, 이미지는 이미지로 둡니다.

분석용 표를 먼저 설계하고 거기 맞춰 넣으면 표에 안 맞는 값은 버려집니다. 나중에 새 질문이 생겨도 버린 값은 되살릴 수 없습니다. 원본을 남겨 두면 질문이 바뀔 때마다 다시 읽으면 됩니다.

여러 곳의 데이터를 바꾸지 않고 값싼 저장소로 옮깁니다
쓰는 사람이 필요한 부분만 골라 읽으며 뜻을 정합니다
자주 쓰는 결과는 다듬어서 따로 둡니다

대가는 정리를 뒤로 미룬다는 점입니다. 목록과 설명을 챙기지 않으면 아무도 못 찾는 파일 더미가 됩니다. 읽을 때마다 해석을 새로 해야 해서 사람마다 다르게 읽기도 쉽습니다.

앞으로 어떤 질문이 나올지 모를 때 맞는 방식입니다. 정해진 보고서 몇 개만 뽑으면 되는 곳이라면 미리 표로 정리해 넣는 분석용 데이터베이스로 충분합니다.

상세

분석할 데이터를 따로 모으는 까닭

쇼핑몰 백엔드를 떠올려 봅시다. 주문은 주문 데이터베이스에, 회원은 회원 데이터베이스에 있습니다. 서버마다 로그 파일이 쌓입니다. 앱은 사용자가 누른 버튼을 이벤트로 보냅니다.

「장바구니에 담고도 결제하지 않은 사람은 어느 화면에서 나갔나」 같은 질문은 이 넷을 다 엮어야 답이 나옵니다. 그런데 서비스가 쓰는 데이터베이스에 몇 달 치를 훑는 조회를 던지면 주문 처리까지 밀립니다. 그래서 분석할 데이터를 따로 복사해 모으는 저장소를 둡니다.

미리 표로 정리해 넣는 방식

오래 써 온 답은 데이터 웨어하우스입니다. 분석하기 쉽게 설계한 표에 데이터를 정리해 넣는 분석 전용 데이터베이스입니다. 매주 같은 매출 보고서를 뽑는 일처럼 질문이 정해져 있을 때 잘 맞습니다.

표에 넣으려면 먼저 모양을 맞춰야 합니다. 원천에서 꺼내고, 표 모양으로 바꾸고, 표에 넣습니다. 이 세 단계를 ETL(Extract, Transform, Load, 추출·변환·적재)이라고 부릅니다.

이 방식은 데이터를 넣기 전에 스키마를 정합니다. 스키마는 표에 어떤 열이 있고 열마다 무슨 값이 들어가는지 정한 약속입니다. 무엇을 담을지를 넣는 쪽이 미리 결정한다는 뜻입니다.

미리 정한 표가 걸림돌이 될 때

표를 먼저 정하면 표에 없는 값은 들어오지 못합니다. 클릭 이벤트에 붙어 온 기기 정보를 쓸 데가 없다며 빼 버렸다고 해 봅시다. 원천에서 그 값이 지워지고 나면 반년 뒤 「기기별 이탈률」이 궁금해져도 되돌릴 방법이 없습니다.

표에 담기 어려운 데이터도 많습니다. 고객 문의 글이나 상품 이미지는 행과 열로 자를 수가 없습니다. 이렇게 행과 열로 딱 떨어지지 않는 데이터가 비정형 데이터입니다.

질문이 바뀔 때도 품이 듭니다. 표에 열을 더하고, 변환 코드를 고치고, 지난 데이터를 다시 넣어야 합니다. 질문이 자주 바뀔수록 이 일이 쌓입니다.

원본을 먼저 쌓는 순서

정수해서 병에 담아 파는 생수는 바로 마시기 좋게 손질돼 있습니다. 호수에는 여러 물줄기에서 흘러든 물이 담겨 있습니다. 마실 사람은 떠서 거릅니다. 조사하러 온 사람은 자기 방식대로 표본을 뜹니다.

이름이 이 비유에서 왔습니다. 쓰기 좋게 손질해 담아 둔 분석용 저장소가 병에 담긴 물이라면, 흘러든 모양 그대로 담는 저장소가 호수입니다.

데이터 레이크는 순서를 뒤집습니다. 원천에서 꺼낸 것을 바꾸지 않고 먼저 넣습니다. 이벤트는 이벤트 파일로, 이미지는 이미지 파일로 둡니다. 꺼내서 넣은 뒤에 바꾸는 이 순서를 ELT(Extract, Load, Transform, 추출·적재·변환)라고 부릅니다.

버린 것이 없으니 새 질문이 생겨도 원본으로 돌아갈 수 있습니다. 반년 뒤의 기기별 이탈률도 그때 원본 이벤트를 다시 읽으면 답이 나옵니다.

읽는 순간 구조를 정하는 방식

넣기 전에 스키마를 정하는 방식을 스키마 온 라이트(schema-on-write)라고 부릅니다. 데이터 레이크는 반대로 읽는 순간 스키마를 정합니다. 이것을 스키마 온 리드(schema-on-read)라고 합니다.

아래는 레이크에 쌓인 클릭 이벤트 한 줄입니다. JSON(JavaScript Object Notation)은 이름과 값을 짝지어 적는 글자 형식입니다. 저장소는 이 줄을 글자로만 압니다. 어떤 필드가 들었는지는 모릅니다.

JSON

{"user": 7, "page": "/cart", "ms": 420, "os": "iOS"}

같은 줄을 두 팀이 읽어도 꺼내는 필드가 다릅니다. 화면 속도를 보는 팀은 ms 를, 기기별 이탈을 보는 팀은 os 를 꺼냅니다.

Python

e = json.loads(line)
e["ms"]   # 420
e["os"]   # 'iOS'

필드의 뜻을 정하는 일이 저장하는 쪽에서 읽는 쪽 코드로 옮겨 갔습니다. 이벤트에 새 필드가 붙어도 저장하는 쪽은 고칠 것이 없습니다. 대신 읽는 코드마다 같은 해석을 되풀이해야 합니다. 필드가 빠진 줄을 만나면 읽는 쪽이 알아서 처리해야 합니다.

저장과 계산을 나누는 구성

데이터 레이크는 흔히 객체 스토리지 위에 짓습니다. 객체 스토리지는 파일을 키 하나로 넣고 꺼내는 저장소입니다. 용량을 쉽게 늘릴 수 있고 저장 단가가 낮습니다. 원본을 버리지 않고 오래 쌓기에 맞는 저장소입니다.

파일을 읽고 계산하는 일은 따로 띄운 엔진이 맡습니다. 여러 서버가 파일을 나눠 읽고 결과를 합쳐 주는 프로그램이 분산 쿼리 엔진입니다. 이 엔진은 조회할 때만 띄웁니다. 파일은 저장소에 늘 남아 있습니다.

둘을 나누면 저장량과 계산량을 따로 늘릴 수 있습니다. 몇 년 치를 쌓아도 계산 서버는 분석하는 시간에만 빌려 쓰면 됩니다.

구역을 나눠 단계별로 다듬는 방식

원본만 쌓으면 쓸 때마다 해석부터 해야 합니다. 그래서 레이크 안을 구역으로 나누고 단계를 밟아 데이터를 다듬습니다. 앞 구역의 결과가 다음 구역의 입력이 됩니다.

다듬은 데이터는 매주 보는 보고서와 머신러닝 학습이 가져갑니다. 머신러닝은 데이터를 많이 읽혀 규칙을 스스로 찾게 하는 방법입니다. 아래 그림은 데이터가 구역을 거쳐 이 둘에 닿는 순서입니다.

flowchart TD
    S["서비스 데이터베이스 · 로그 · 이벤트"] --> R["원본 구역 · 받은 파일을 고치지 않고 둔다"]
    R --> C["정제 구역 · 형식을 맞추고 깨진 줄을 걸러낸다"]
    C --> G["분석용 구역 · 질문에 맞춰 모으고 합친다"]
    C --> M["머신러닝 학습"]
    G --> B["보고서 · 대시보드"]

원본 구역은 한 번 넣은 파일을 고치지 않습니다. 정제 단계에서 실수가 나도 원본에서 다시 만들면 되기 때문입니다.

정제 구역은 형식을 맞추고 중복이나 깨진 줄을 걸러낸 데이터를 담습니다. 머신러닝 학습은 흔히 여기서 데이터를 가져갑니다.

분석용 구역은 질문에 맞게 미리 모으고 합친 결과를 담습니다. 매주 보는 보고서와 대시보드가 이것을 읽습니다.

구역에서 구역으로 데이터를 옮기고 바꾸는 작업은 순서대로 이어집니다. 이렇게 이어진 작업의 사슬이 데이터 파이프라인입니다. 한 번 짜 놓으면 새 데이터가 들어올 때마다 같은 순서로 다시 돌릴 수 있습니다.

정제하면서 파일 형식도 바꾸곤 합니다. 한 줄에 한 건씩 적는 대신 같은 열의 값끼리 모아 적는 형식을 열 지향 포맷이라고 합니다. 「응답 시간」 열 하나만 필요한 조회는 그 열이 적힌 부분만 읽으면 됩니다.

어느 구역이든 쌓이는 파일은 날짜별 폴더로 나눠 담습니다. 「9월 18일 이벤트」를 찾을 때 그 날짜 폴더만 열면 됩니다. 이렇게 기준에 따라 데이터를 나눠 담는 일을 파티셔닝이라고 합니다.

목록 없이 쌓인 레이크

무엇이든 받아 주니 버릴 이유가 없어 보입니다. 파일이 수십만 개 쌓이면 비슷한 이름의 폴더가 여럿 생깁니다. 어느 것이 최신인지, 누가 넣었는지, 이 열의 단위가 초인지 밀리초인지 아무도 모르게 됩니다.

이렇게 쌓기만 하고 못 쓰게 된 레이크를 데이터 늪(data swamp)이라고 부릅니다. 데이터는 다 있습니다. 그런데 믿고 쓸 수 있는 것이 없습니다.

늪을 막는 것은 데이터에 대한 설명입니다. 파일마다 어디서 왔는지, 어떤 필드가 있는지, 누가 책임지는지를 적은 정보가 메타데이터입니다.

메타데이터를 한데 모아 검색할 수 있게 만든 목록이 데이터 카탈로그입니다. 분석가는 파일을 뒤지는 대신 카탈로그에서 「주문 이벤트」를 찾아 위치와 필드 설명을 얻습니다. 그래서 레이크를 세울 때 저장 방식과 함께 이 목록을 챙깁니다.

쌓인 원본의 보존과 삭제

원본을 남기기로 했다면 언제까지 남길지도 정해야 합니다. 데이터를 얼마나 오래 둘지 정한 기간이 보존 기간입니다. 기간이 지난 파일은 보관용 저장소로 옮기거나 지웁니다. 보관용 저장소는 자주 꺼내 쓰기 불편한 대신 저장 단가가 더 낮습니다.

개인정보는 더 까다롭습니다. 회원이 탈퇴하며 자기 기록을 지워 달라고 하면, 레이크 곳곳에 흩어진 파일에서도 그 사람의 줄을 찾아 지워야 합니다. 객체 스토리지의 파일은 일부만 고칠 수 없습니다. 한 사람의 줄을 빼려면 그 줄이 든 파일을 새로 써서 바꿔 넣어야 합니다.

원본에는 민감한 값이 섞여 있습니다. 그래서 누가 어느 구역과 어느 열을 읽을 수 있는지 접근 제어로 나눕니다. 원본 구역은 좁게 열고, 가려서 다듬은 분석용 구역을 넓게 여는 식입니다.

데이터 웨어하우스와 나눠 맡는 일

두 방식은 무엇을 먼저 하느냐가 다릅니다. 아래 표로 둘을 맞세웁니다.

	데이터 웨어하우스	데이터 레이크
넣기 전에	표 모양으로 바꾼다	바꾸지 않는다
스키마를 정하는 때	넣을 때	읽을 때
담는 데이터	표로 정리된 값	표 · 로그 · 글 · 이미지
맞는 질문	매번 같은 보고서	아직 정해지지 않은 분석 · 머신러닝
무너지는 모양	새 질문마다 표와 변환을 고친다	목록 없이 쌓여 늪이 된다

둘 중 하나만 고르지 않는 경우가 많습니다. 레이크에 원본을 쌓습니다. 자주 쓰는 결과만 다듬어 웨어하우스에 올립니다. 레이크의 파일을 웨어하우스의 표처럼 다루려는 구성은 레이크하우스라고 부릅니다.

고를 만한 상황과 미룰 상황

이 결정이 이득이 되는 것은 데이터의 종류가 많고 어떤 질문이 나올지 미리 모를 때입니다. 가공 전 원본을 많이 읽혀야 하는 머신러닝에도 맞습니다.

데이터가 데이터베이스 한두 개에 다 있고 질문이 정해진 보고서 몇 개뿐이면 웨어하우스 하나로 충분합니다. 레이크를 세우면 파이프라인과 카탈로그와 권한을 굴리는 일이 먼저 생깁니다. 이 일을 맡을 사람이 없으면 레이크는 곧 늪이 됩니다.