데이터 엔지니어링

여기저기서 생겨나는 데이터를 한데 모아 두고 쓸 수 있는 상태로 만드는 자리입니다. 여기서 만드는 것은 화면도 기능도 아닙니다. 데이터가 지나갈 길 자체입니다. 무엇을 하는 일이냐고 물으면 답이 한 문장이 아니라 목록으로 열립니다.

상세

데이터 엔지니어링은 무엇을 만드느냐보다 어느 자리인가를 가리키는 말입니다. 그 자리에서 만드는 물건에는 이름이 있습니다. Apache Beam 프로그래밍 가이드는 그것을 파이프라인이라 부릅니다. 파이프라인은 데이터 처리 작업 전체를 처음부터 끝까지 담습니다. 입력 데이터를 읽는 일, 그 데이터를 변환하는 일, 출력 데이터를 쓰는 일이 그 안에 함께 들어갑니다.

flowchart TD
    입력["입력 데이터"] --> 읽기["읽기"]
    읽기 --> 변환["변환"]
    변환 --> 쓰기["쓰기"]
    쓰기 --> 출력["출력 데이터"]

길은 한 줄로만 놓이지 않습니다. 같은 문서는 파이프라인을 방향 있는 비순환 그래프(directed acyclic graph)로 생각하는 것이 가장 낫다고 적습니다. 변환 노드가 데이터 집합 노드를 입력으로 받아 데이터 집합 노드를 출력으로 내보내는 모양입니다. 그래서 이 자리의 작업물은 코드 한 덩이가 아니라 노드와 화살표로 이어진 그래프입니다.

다루는 데이터가 언제 끝나는지도 갈립니다. Beam 의 데이터 집합은 경계가 있을 수도 있고 없을 수도 있습니다. 파일처럼 고정된 원천에서 오면 경계가 있습니다. 구독처럼 계속 갱신되는 원천에서 오면 경계가 없습니다. 배치와 스트리밍이라는 두 낱말이 이 구분 위에 놓입니다.

옮겨 온 데이터를 담아 두는 자리에도 이름이 붙습니다. Bill Inmon 은 업계가 받아들인 데이터 웨어하우스의 정의를 이렇게 적습니다. 경영 의사결정을 위한, 주제 지향적이고 통합되어 있으며 비휘발성이고 시간에 따라 변하는 데이터 모음입니다. 본인의 저서 Building the Data Warehouse 에 처음 실린 문장이라고 덧붙입니다.

여기서 한 문장 정의가 안 서는 까닭이 드러납니다. 이 구역의 물음은 무엇을 계산하느냐가 아닙니다. 어디서 가져와 어디에 담고 무엇으로 바꿔서 언제 돌릴 것이냐입니다. 가져오는 일, 담아 두는 일, 옮기고 바꾸는 일, 언제 돌릴지 정하는 일, 믿을 수 있게 지키는 일이 나란히 놓입니다. 그래서 답이 목록으로 열립니다. 사람이 그 안에서 일하는 구역 이름이면서 직무 이름이기도 합니다.

경계

서비스가 쓰는 운영 데이터베이스

서비스가 요청마다 읽고 쓰는 데이터베이스를 짓는 일도 이 구역인가. 아닙니다. AWS 는 온라인 분석 처리(OLAP, Online Analytical Processing)와 온라인 트랜잭션 처리(OLTP, Online Transaction Processing)를 업무 데이터를 저장하고 분석하도록 돕는 두 데이터 처리 시스템으로 나란히 적습니다. 분석 처리 쪽은 데이터를 결합하고 묶어서 여러 관점에서 볼 수 있게 하는 쪽이라고 적습니다.

Microsoft 는 데이터 엔지니어를 이렇게 적습니다. 여러 정형·비정형·스트리밍 데이터 시스템의 데이터를 통합하고 변환하고 하나로 모아, 분석 솔루션을 만들기에 알맞은 스키마로 만드는 전문성을 가진 사람입니다. 그 문장에서 여러 데이터 시스템은 재료 쪽에 놓입니다. 결과물은 분석 쪽 스키마 입니다. 서비스가 요청마다 읽고 쓰는 데이터베이스는 그 재료 쪽에 있습니다.

분석용 집계 테이블

분석용 집계 테이블을 SQL(Structured Query Language, 구조화 질의어)로 만드는 일은 데이터 분석인가. 아닙니다. dbt Labs 의 Claire Carroll 은 이 자리에 애널리틱스 엔지니어라는 별도 이름을 제안하면서 두 쪽을 갈라 적습니다. 데이터 분석가는 데이터를 분석하는 데 시간을 쓰고, 애널리틱스 엔지니어는 데이터를 변환하고 테스트하고 배포하고 문서화하는 데 시간을 씁니다. 최종 사용자가 스스로 질문에 답할 수 있도록 깨끗한 데이터 집합을 만들어 주는 쪽입니다. 같은 글은 애널리틱스 엔지니어가 버전 관리나 지속적 통합 같은 소프트웨어 엔지니어링 관행을 분석 코드베이스에 적용한다고 적습니다. 데이터를 다듬어 내놓는 쪽과 그것으로 답을 찾는 쪽 사이에 선이 그어져 있습니다.

학습용 특성

모델 학습에 쓸 특성을 만들어 두는 일은 이 구역인가 머신러닝인가. 담아 두고 읽고 쓰게 만드는 쪽까지가 이 구역입니다. Feast 는 문서를 읽는 사람의 역할별로 자기 소개를 나눠 적습니다. 데이터 엔지니어 쪽 문단에서는 특성 정의를 담는 중앙 카탈로그를 제공한다고 적습니다. 특성 데이터의 단일 진실 원천을 유지하게 해 주고, 여러 종류의 오프라인·온라인 데이터 저장소를 읽고 쓰는 추상을 제공한다고 적습니다.

모델을 훈련시키는 쪽은 이 구역 밖입니다. Microsoft 는 데이터 과학자의 책임으로 데이터 과학 작업에 알맞은 작업 환경을 설계하고 만드는 일, 데이터를 탐색하는 일, 머신러닝 모델을 훈련시키는 일, 파이프라인을 구현하는 일을 듭니다. 파이프라인이라는 낱말이 양쪽에 다 나오지만 훈련은 한쪽에만 나옵니다.

이견

이 구역을 어떤 축으로 나누느냐가 사람마다 다릅니다.

Inmon 과 Kimball

분석용 데이터를 어떤 모양으로 세울 것인가에서 두 이름이 갈립니다.

Bill Inmon 은 자기 아키텍처를 corporate information factory 라고 부른다고 적습니다. 그냥 Inmon 아키텍처라고 불리기도 한다고 덧붙입니다. 그 안의 데이터 웨어하우스에 담기는 데이터는 원칙적으로 정규화된 관계형 형식으로 저장된다고 본인이 적습니다. 두 진영이 갈리는 핵심으로는 단일 진실 버전을 듭니다. Kimball 의 단순 차원 아키텍처 1단계 어디에도 그 개념이 없다는 것이 문제라고 적습니다. Kimball 은 기껏해야 애플리케이션 데이터를 애플리케이션 환경에서 복사해 오라고 말한다고 적습니다. Inmon 자신은 단일 진실 버전을 만들려면 레거시 데이터의 근본적이고 엄격한 변환이 필요하다고 봅니다.

Ralph Kimball 은 차원 모델링을 데이터 웨어하우스에 자주 쓰이는 논리 설계 기법이라고 적습니다. 엔티티-관계 모델링과 다르며 그것과 대비된다고 못 박습니다. 데이터를 표준적이고 직관적인 틀로 보여 고성능 접근을 가능하게 하려는 기법이라고 정의합니다. Kimball Group 의 엔터프라이즈 데이터 웨어하우스 버스 아키텍처 문서는 이 접근을 점진적이라고 적습니다. 계획 과정을 다룰 만한 조각으로 쪼개 비즈니스 프로세스에 초점을 맞춥니다. 프로세스들 사이에서 재사용되는 표준화된 컨폼드 디멘션으로 통합을 이룬다고 적습니다.

ETL 과 ELT

데이터를 옮기기 전에 바꿀 것인가 담고 나서 바꿀 것인가에서 갈립니다.

Informatica 는 ETL(Extract, Transform, Load — 추출·변환·적재)을 세 단계짜리 데이터 통합 과정으로 적습니다. 여러 데이터 원천의 원시 데이터를 데이터 웨어하우스나 데이터 레이크나 데이터 스토어나 관계형 데이터베이스나 그 밖의 애플리케이션으로 결합하고 합치는 데 쓰인다고 적습니다. ETL 에서는 데이터를 추출한 뒤에 정의하고 변환해 데이터 품질과 무결성을 개선하고, 그다음에 저장소로 적재한다고 적습니다.

dbt Labs 는 둘의 핵심 차이가 변환이 언제 어디서 일어나느냐에 있다고 적습니다. ETL 은 적재 전에 변환하고 ELT(Extract, Load, Transform — 추출·적재·변환)는 데이터 웨어하우스에 적재한 뒤에 변환합니다. 같은 문서는 ELT 가 클라우드 네이티브 환경에서 인기를 얻었다고 적습니다. 데이터를 먼저 웨어하우스로 추출·적재해 두면 웨어하우스의 연산 능력으로 변환할 수 있다고 적습니다.

소프트웨어 엔지니어링과의 거리

이 일이 소프트웨어 엔지니어링의 한 갈래인가 별도 직무인가에서 갈립니다.

Maxime Beauchemin 은 데이터 엔지니어가 도구와 인프라와 프레임워크와 서비스를 만든다고 적습니다. 데이터 과학자와 달리, 더 성숙한 부모 격인 소프트웨어 엔지니어링에서 영감을 받은 쪽이라고 적습니다. 데이터 엔지니어링이 데이터 사이언스보다 소프트웨어 엔지니어링에 훨씬 가깝다고 말할 만하다는 것이 본인의 표현입니다. 기존 역할과 견주면 비즈니스 인텔리전스와 데이터 웨어하우징의 상위 집합에 소프트웨어 엔지니어링의 요소가 더 들어온 것으로 볼 수 있다고 적습니다.

Niels Cautaerts 는 반대쪽에 섭니다. 데이터 엔지니어링과 소프트웨어 엔지니어링이 도구와 관행을 많이 공유하지만 여러 핵심 영역에서 상당히 다르다고 적습니다. 그 차이를 무시하고 데이터 엔지니어링 팀을 소프트웨어 제품 팀처럼 관리하는 것은 실수라고 적습니다. 데이터 엔지니어링을 토마토처럼 생각하라고 덧붙입니다. 토마토는 과일이지만 그렇다고 과일 샐러드에 넣을 것은 아니라는 비유입니다.

관련 항목

데이터를 들여오는 경로와 방식

원천 · 대상 · 수집 · 변경 데이터 캡처 · 이벤트 스트림 · 복제

처리 시점을 가르는 대립 개념

배치 처리 · 스트리밍 처리 · 유계 데이터 · 무계 데이터

분석용 데이터가 놓이는 저장소

데이터 웨어하우스 · 데이터 레이크 · 데이터 마트 · 객체 저장소

저장 데이터를 다루는 기법

컬럼 지향 저장 · 파티셔닝 · 스키마 진화

분석용 데이터를 세우는 설계 기법

정규화 · 차원 모델링 · 컨폼드 디멘션 · 엔티티-관계 모델링 · Corporate Information Factory · 엔터프라이즈 데이터 웨어하우스 버스 아키텍처

파이프라인을 이루는 구성 요소

파이프라인 · 데이터플로우 그래프 · 변환 · 데이터 통합

데이터를 옮기는 전략

ETL · ELT · 증분 처리

스트리밍 처리를 다루는 기법

윈도우 · 워터마크 · 컴팩션

실행을 조율하는 구성 요소

오케스트레이션 · 스케줄링 · 워크플로 · DAG(Directed Acyclic Graph, 방향 있는 비순환 그래프) · 태스크

다시 실행해도 안전하게 만드는 성질

백필 · 재시도 · 멱등성

데이터 신뢰를 지키는 요소

데이터 품질 · 데이터 계보 · 거버넌스 · 메타데이터 · 데이터 카탈로그 · 단일 진실 원천

이것에서 자주 나는 오류·장애

지연 도착 데이터 · 중복 적재 · 작은 파일 문제 · 태스크 실패 · 스키마 변경

경계를 가르는 이웃 영역

온라인 트랜잭션 처리 · 온라인 분석 처리 · 데이터 분석 · 애널리틱스 엔지니어 · 비즈니스 인텔리전스 · 피처 스토어 · 머신러닝 · 데이터 모델링 · 인프라

이것을 실제로 구현·채택한 도구

Apache Beam · Apache Airflow · Apache Kafka · Apache Parquet · Apache Iceberg · Apache Atlas · Debezium · Airbyte · dbt · Great Expectations · OpenLineage · Feast · Amazon S3 · SQL