변환
고친 사람 github-actions[bot]
변환은 데이터를 받는 쪽이 쓸 수 있는 모양으로 바꿔 줍니다. 금액 글자 12,000 을 숫자 12000 으로
바꾸는 식입니다. 데이터를 옮기는 일에서는 읽어 온
데이터를 싣기 전에 손보는 가운데 단계를 이 이름으로 부릅니다. 같은 낱말을 값의 타입을 바꾸는
일이나 화면의 좌표를 옮기는 일에도 씁니다. 이 편은 데이터를 옮기는 일의 변환을 다룹니다.
쉽고 빠른 이해
변환은 읽어 온 데이터를 받는 쪽에 맞게 고쳐 주는 단계입니다. 주문 기록의 금액 글자
12,000 을 숫자로 바꾸는 일이 변환입니다. 주문을 하루 단위로 모아 매출 합계를 내는 일도
변환입니다.
데이터를 내주는 쪽과 받는 쪽은 담는 모양이 다릅니다. 손보지 않고 옮기면 데이터를 쓰는 사람마다 같은 손질을 되풀이합니다. 손질이 사람마다 다르면 같은 질문에 다른 숫자가 나옵니다.
- 원래 데이터를 읽어 옵니다
- 정해 둔 규칙대로 고치고 거르고 모읍니다
- 결과를 받는 쪽에 씁니다
대가가 있습니다. 모으고 거르는 동안 원래 데이터의 세부가 버려집니다. 원래 데이터의 모양이 바뀌면 규칙이 깨집니다.
상세
장을 봐 온 채소에는 흙이 묻어 있고 크기도 제각각입니다. 부엌에서는 채소를 씻고 시든 잎을 떼어 버린 뒤 썰어서 접시에 담습니다. 접시에 오른 것은 시장에서 사 온 그 채소입니다. 식탁에 올릴 수 있는 모양이 되었을 뿐입니다.
변환은 입력 데이터를 받아 정해 둔 규칙대로 고친 출력 데이터를 내놓는 단계입니다. 쇼핑몰의 주문
테이블을 매출 분석용 테이블로 옮긴다고 해 봅시다. 금액 글자 12,000 을 숫자 12000 으로 바꾸는
일이 변환입니다. 주문을 하루 단위로 모아 그날의 매출 합계를 내는 일도 변환입니다.
이 절은 먼저 변환이 데이터를 옮기는 흐름의 어디에 서는지 봅니다. 이어서 변환이 하는 일을 종류별로 나눕니다. 그다음 한 행씩 하는 변환과 여러 행을 모으는 변환을 가릅니다. 끝으로 변환을 언제 하는지, 다시 돌려도 같은 결과를 내게 만드는 법, 변환이 깨지는 곳을 봅니다.
읽기와 쓰기 사이의 단계
파이프라인은 데이터를 한쪽에서 읽어 다른 쪽에 쓰는 작업을 단계 여럿으로 나눠 둔 것입니다. 단계를 나눠 두면 숫자가 틀렸을 때 어느 단계에서 틀렸는지 찾기 쉽습니다.
원천은 데이터를 내주는 쪽입니다. 대상은 데이터를 받는 쪽입니다. 앞의 예에서는 쇼핑몰의 주문 테이블이 원천이고 매출 분석용 테이블이 대상입니다.
추출은 원천에서 데이터를 읽어 오는 단계입니다. 적재는 대상에 데이터를 써 넣는 단계입니다. 변환은 이 둘 사이에 섭니다.
flowchart TD
A["원천 · 주문 테이블"] --> B["추출 · 읽어 온다"]
B --> C["변환 · 고치고 모은다"]
C --> D["적재 · 써 넣는다"]
D --> E["대상 · 매출 분석용 테이블"]
추출과 적재는 데이터를 나르기만 합니다. 데이터의 모양이 바뀌는 단계는 가운데 변환 하나입니다. 그래서 파이프라인이 틀린 숫자를 내면 대개 변환 규칙부터 살펴봅니다.
변환이 필요한 까닭
원천과 대상은 쓰임이 달라서 담는 모양도 다릅니다. 주문을 받는 데이터베이스는 한 건씩 빠르게 쓰고 고치기 쉽도록 표를 잘게 나눠 둡니다. 같은 정보를 한 곳에만 적도록 표를 나누는 설계가 정규화입니다.
분석용 저장소는 반대로 담습니다. 수백만 건을 한꺼번에 훑어 합계를 내야 하므로 자주 함께 보는 정보를 한 표에 모아 둡니다. 나뉜 표를 미리 붙여 한 표로 만드는 일은 비정규화입니다.
모양이 다른 채로 옮기면 분석하는 사람이 질의를 짤 때마다 같은 손질을 되풀이합니다. 금액 글자를 숫자로 바꿉니다. 나뉜 표를 다시 붙입니다. 빈 값을 거릅니다. 사람마다 손질이 조금씩 다르면 같은 질문에 다른 숫자가 나옵니다. 변환은 이 손질을 규칙으로 한 번 정해 둡니다. 그리고 파이프라인 안에서 한 번만 합니다.
원천이 여럿일 때도 변환이 필요합니다. 주문은 주문 데이터베이스에, 회원은 회원 서비스에, 결제는 결제사가 보내 주는 파일에 있습니다. 셋은 같은 고객을 서로 다른 키와 형식으로 적습니다. 변환이 키와 형식을 하나로 맞춰야 셋을 한 표에서 볼 수 있습니다.
반대로 원천이 하나이고 원천과 대상이 담는 모양이 같으면 변환이 필요 없습니다. 데이터를 손대지 않고 그대로 옮기면 됩니다.
변환이 하는 일
변환 규칙은 몇 가지 종류로 나뉩니다. 파이프라인 하나의 변환은 대개 아래 종류 여럿을 차례로 이어 붙인 것입니다. 주문 데이터를 예로 들면 이렇습니다.
| 종류 | 하는 일 | 주문 데이터에서 |
|---|---|---|
| 형식 맞추기 | [[데이터 타입 | 타입]]·단위·표기를 하나로 맞춘다 |
| 정제 | 틀린 값·빈 값을 고치거나 버린다 | 빈 배송지 값을 「미입력」으로 채운다 |
| 거르기 | 필요 없는 행을 뺀다 | 테스트 [[사용자 계정 |
| 파생 열 | 있는 열로 새 열을 계산한다 | 단가와 수량을 곱해 금액 열을 만든다 |
| 합치기 | 다른 표의 행을 키로 이어 붙인다 | 주문에 회원 등급을 붙인다 |
| 모으기 | 여러 행을 묶어 값 하나로 줄인다 | 하루 단위 매출 합계 |
표의 위 넷은 행을 하나씩 보고 끝납니다. 아래 둘은 다른 행을 함께 봐야 결과가 나옵니다. 두 번 들어온 같은 주문을 하나로 줄이는 일도 다른 행과 견줘 봐야 하므로 아래 둘 쪽에 듭니다. 이 차이가 변환을 돌리는 방식을 가릅니다.
한 행씩 하는 변환
한 행씩 하는 변환은 들어온 행 하나만 보고 결과를 냅니다. 앞에 어떤 행이 왔는지 기억할 필요가 없습니다. 아래 코드는 주문 한 건의 금액 글자를 숫자로 바꿉니다. 오른쪽 주석이 그 줄이 내는 값입니다.
price = "12,000"
won = int(price.replace(",", "")) # 12000
이 두 줄은 다른 주문을 전혀 보지 않습니다. 그래서 주문 백만 건을 열 기계에 나눠 맡겨도 됩니다. 기계마다 같은 규칙으로 제 몫만 바꾸면 결과를 합쳤을 때 한 기계에서 돌린 것과 같습니다.
여러 행을 모으는 변환
하루 매출 합계를 내려면 그날의 주문이 전부 한곳에 모여야 합니다. 여러 행을 묶어 합계·개수·평균 같은 값 하나로 줄이는 일이 집계입니다.
주문에 회원 등급을 붙일 때도 다른 행이 필요합니다. 같은 회원 번호를 가진 회원 행을 찾아와야 합니다. 조인은 두 표의 행을 같은 키로 이어 붙이는 일입니다.
데이터를 여러 기계에 나눠 두었다면 같은 키를 가진 행을 한 기계로 다시 모아야 합니다. 이렇게 키를 기준으로 행을 기계 사이에 다시 나누는 일을 셔플이라고 부릅니다. 셔플은 네트워크로 데이터를 많이 옮기므로 모으는 변환은 한 행씩 하는 변환보다 무겁습니다.
데이터가 멈추지 않고 계속 들어오면 「그날의 주문 전부」가 끝나지 않습니다. 이렇게 끝없이 들어오는 데이터를 들어오는 대로 처리하는 방식을 스트림 처리라고 부릅니다.
스트림 처리에서 집계를 하려면 모을 범위를 따로 정해야 합니다. 5분이나 하루처럼 시간으로 범위를 끊습니다. 끊은 범위가 닫힐 때마다 그 범위의 결과를 냅니다. 이 방식을 윈도 집계라고 부릅니다.
싣기 전에 바꾸는 방식과 싣고 나서 바꾸는 방식
변환을 적재 앞에 두는 방식을 ETL(Extract-Transform-Load, 추출-변환-적재)이라고 부릅니다. 변환을 마친 데이터만 대상에 들어갑니다. 변환은 파이프라인 안의 처리 서버가 맡습니다.
변환을 적재 뒤에 두는 방식은 ELT(Extract-Load-Transform, 추출-적재-변환)라고 부릅니다. 원천 데이터를 손대지 않고 대상에 먼저 싣습니다. 변환은 대상 저장소 안에서 SQL(Structured Query Language, 구조화 질의 언어) 질의로 돌립니다.
두 방식은 변환하는 때와 곳이 다릅니다. 그 차이가 규칙을 고칠 때 드러납니다.
| ETL | ELT | |
|---|---|---|
| 변환하는 때 | 적재 전 | 적재 후 |
| 변환하는 곳 | 파이프라인의 처리 서버 | 대상 저장소 안 |
| 대상에 들어가는 데이터 | 변환을 마친 결과만 | 원천 데이터와 변환 결과 둘 다 |
| 규칙을 고친 뒤 다시 만들 때 | 원천에서 다시 읽어 온다 | 대상에 남은 원천 데이터로 다시 돌린다 |
대상 저장소가 큰 데이터를 스스로 빠르게 계산할 수 있으면 ELT 를 고를 수 있습니다. 분석용으로 데이터를 모아 두는 데이터 웨어하우스가 그런 저장소입니다. 대가는 원천 데이터를 담아 둘 공간이 더 든다는 것입니다. 또 하나의 대가는 개인정보처럼 대상에 두면 안 되는 값도 일단 대상에 들어간다는 것입니다.
다시 돌려도 같은 결과
파이프라인은 한 번 돌고 끝나지 않습니다. 실패하면 다시 돌립니다. 규칙에서 틀린 곳을 찾으면 지난 기간을 다시 돌립니다. 지난 데이터를 다시 흘려 결과를 새로 만드는 일을 재처리라고 부릅니다.
재처리가 안전하려면 변환이 같은 입력에 언제나 같은 출력을 내야 합니다. 변환 안에서 현재 시각이나 난수를 읽으면 돌릴 때마다 결과가 달라집니다. 그래서 날짜 기준은 돌리는 시각에서 가져오지 않습니다. 데이터에 적힌 시각이나 처리할 기간을 입력으로 받습니다.
대상에 쓰는 쪽도 맞춰 둡니다. 같은 기간을 두 번 돌렸는데 결과가 두 벌 쌓이면 합계가 두 배가 됩니다. 그래서 그 기간의 결과를 지우고 새로 쓰거나, 키가 같은 행은 덮어씁니다. 여러 번 해도 한 번 한 것과 결과가 같은 성질을 멱등성이라고 부릅니다.
원천 데이터를 손대지 않은 채 따로 보관해 두는 것도 같은 까닭입니다. 모으고 거른 결과만 남기면 버린 세부는 되살릴 수 없습니다. 원본이 남아 있으면 규칙을 고친 뒤 처음부터 다시 만들 수 있습니다.
변환이 깨지는 곳
변환 규칙은 원천 데이터가 어떤 모양인지를 전제로 짭니다. 스키마는 테이블이 어떤 열을 어떤 타입으로 갖는지 정해 둔 것입니다. 원천의 스키마가 바뀌면 그 위에 짠 규칙이 깨집니다.
깨지는 모습은 둘입니다. 열 이름이 바뀌면 규칙이 그 열을 못 찾아 멈춥니다. 멈추면 곧바로 드러납니다. 금액 단위가 원에서 천 원으로 바뀌면 규칙은 멈추지 않습니다. 합계가 천분의 일로 줄어도 파이프라인은 성공으로 끝납니다.
조용히 틀리는 쪽을 잡으려고 변환 뒤에 결과를 검사하는 단계를 둡니다. 행 수가 갑자기 줄지 않았나, 빈 값이 늘지 않았나, 합계가 평소 범위 안인가를 봅니다. 데이터가 쓸 만한 상태인지 재는 이런 검사를 데이터 품질 검사라고 부릅니다.
파이프라인 밖의 변환
변환이라는 낱말은 다른 분야에서도 흔히 씁니다. 입력을 받아 규칙대로 바꾼 출력을 낸다는 뼈대는 같습니다. 바꾸는 것이 무엇인지가 분야마다 다릅니다. 분야마다 따로 부르는 이름도 있습니다.
| 분야 | 무엇을 바꾸나 | 따로 부르는 이름 |
|---|---|---|
| 프로그래밍 언어 | 값의 타입. 정수를 실수로 바꾸는 일 | 형 변환 |
| 그래픽스 | 점의 좌표. 옮기기·돌리기·키우기 | 변환 행렬 |
| 문자 처리 | 글자를 바이트로 적는 규칙 | 문자 인코딩 변환 |
| 네트워크 | 패킷에 적힌 주소 | NAT(Network Address Translation, 네트워크 주소 변환) |
관련 항목
변환이 끼어 있는 파이프라인 단계
파이프라인 · 원천 · 추출 · 적재 · 대상 · ETL · ELT
변환이 하는 일의 종류
데이터 정제 · 중복 제거 · 필터링 · 파생 열 · 조인 · 집계 · 비정규화
변환을 돌리는 처리 방식
배치 처리 · 스트림 처리 · 윈도 집계 · 셔플 · 맵리듀스 · 데이터플로우 그래프
변환이 지켜야 하는 성질
멱등성 · 결정성 · 재처리 · 백필 · 데이터 품질 · 데이터 계보
변환이 전제로 삼는 데이터 모양
스키마 · 스키마 변경 · 스키마 진화 · 정규화 · 데이터 모델링
변환 결과를 담는 저장소
데이터 웨어하우스 · 데이터 레이크 · 데이터 마트 · 구체화 뷰
변환을 짜고 돌리는 도구
SQL · dbt · Apache Spark · Apache Beam · Apache Flink
변환을 한 단계로 품는 데이터 작업
데이터 엔지니어링 · 데이터 통합 · 변경 데이터 캡처 · 데이터 마이그레이션
이름이 겹치는 다른 분야의 변환 용어
다른 이름: transformation · transform · 데이터 변환 · data transformation