견고한 데이터 엔지니어링 Chapter 5.1 - 원천 시스템에서의 데이터 생성

이 글은 스터디 활동에서 진행하는 견고한 데이터 엔지니어링 정리입니다.

Fundamentals of Data Engineering

---

5.1장. 원천 시스템의 데이터 생성

 데이터 엔지니어링 라이프사이클의 첫 단계는 원천 시스템에서 데이터가 생성되는 과정이다. 데이터 엔지니어는 원천 시스템에서 데이터를 추출해 다운스트림의 다양한 사용 사례에 맞게 가공하지만, 이를 위해서는 원천 데이터가 어디에 있으며 어떻게 생성되는지를 이해해야 한다. 데이터의 특성과 그 고유성을 파악하는 작업이 필수적이다.

 

 

데이터가 폭증하면서 데이터 공유의 필요성도 증가하고 있어, 데이터 엔지니어의 역할은 점점 데이터 원천과 목적지 간의 상호작용을 이해하는 데 집중될 것으로 보인다. 데이터 전달 경로의 단순화가 이루어지더라도, 원천 시스템에서 생성되는 데이터의 특성을 깊이 이해하는 것은 여전히 핵심이다.

 

5.1 데이터 원천 : 데이터는 어떻게 생성될까?

 데이터 엔지니어링에서 원천 시스템이 데이터를 생성하는 방식에 대한 이해는 필수적이다. 데이터는 단순한 사실이나 숫자의 모음일 수 있지만, 이를 통해 유용한 정보를 얻으려면 생성 방식을 이해해야 한다. 데이터는 아날로그와 디지털 두 가지 주요 방식으로 생성된다.

• 아날로그 데이터 생성
  • 음성, 수화, 종이에 글을 쓰거나 악기 연주와 같은 방식으로 현실 세계에서 발생하는 데이터.
  • 일시적인 특성이 있어, 대화나 동작이 끝나면 사라지는 경우가 많음.
• 디지털 데이터 생성
  • 아날로그에서 디지털로 변환하는 예로는 아날로그 음성을 디지털 텍스트로 전환하는 문자 메시지 앱.
  • 디지텅 데이터의 예로는 전자상거래 플랫폼의 신용카드 거래가 있으며 , 고객 주문과 결제 정보가 데이터베이스에 저장됨.

 오늘날 우리는 웹사이트 상호작용, 모바일 애플리케이션, IoT 기기, 신용카드 단말기 등에서 다량의 디지털 데이터를 수집하며, 이는 데이터 엔지니어링의 핵심 원천 역할을 한다. 

 

5.2 원천 시스템: 주요 아이디어

 원천 시스템은 다양한 방식으로 데이터를 생성하며, 데이터 엔지니어가 주로 다루는 데이터 생성 방식과 파일 형식에는 몇 가지 주요 아이디어가 있다.

5.2.1 파일과 비정형 데이터

  먼저, 파일은 일반적으로 디스크에 저장된 바이트 시퀀스 형태로 존재하며, 애플리케이션은 이를 이용해 로컬 매개변수, 이벤트, 로그, 이미지 및 오디오 등의 데이터를 저장한다. 파일은 데이터 교환의 보편적인 매체로, 특히 공공 기관이나 기업에서는 Excel, CSV 형식의 파일을 다운로드하거나 이메일로 전달하는 방식을 통해 데이터를 주고받는다.

 

 주요 원천 시스템 파일 형식에는 Excel, CSV, TXT, JSON, XML 등이 있으며, 각 형식은 고유한 특성을 지닌다. Excel과 CSV와 같은 형식은 주로 구조화된 데이터를 저장하는 데 사용되며, JSON과 XML은 반구조화된 데이터 형식으로 활용된다. TXT 형식은 비정형 데이터의 예에 해당한다.

 

5.2.2 API

 애플리케이션 프로그래밍 인터페이스(API)는 시스템 간 데이터 교환의 표준화된 방식으로, 이론적으로는 데이터 엔지니어의 데이터 수집 작업을 간소화하는 역할을 한다. 그러나 실제로는 많은 API가 여전히 복잡한 구조와 상호작용 방식으로 인해 엔지니어에게 적지 않은 관리 부담을 준다. API 기반 데이터 수집을 자동화하는 여러 서비스와 프레임워크가 제공되지만, 데이터 엔지니어는 주로 특정 요구 사항에 맞춘 API 연결을 설정하고 유지보수하는 데 상당한 노력을 들여야 한다.

 

5.2.3 애플리케이션 데이터베이스

 애플리케이션 데이터베이스, 흔히 온라인 거래 처리 시스템(OLTP)이라고도 불리는 이 데이터베이스는 애플리케이션의 상태를 저장하는 데 사용된다. 예를 들어, 은행 애플리케이션에서는 고객의 거래 내역이나 지불 정보를 업데이트하여 계좌 잔액을 실시간으로 반영한다. 이러한 OLTP 시스템은 빠른 속도로 데이터를 읽고 쓰기 때문에 트랜잭션 데이터베이스로도 불리며, 낮은 대기 시간과 높은 동시성을 지원한다. 

 

 관계형 데이터베이스 관리 시스템(RDBMS) 같은 OLTP 시스템은 밀리초 단위로 데이터를 읽거나 업데이트할 수 있어 초당 수천 건의 트랜잭션을 처리할 수 있으며, 이는 수많은 사용자가 동시에 상호작용할 때도 문제없이 작동할 수 있도록 한다. 특히 RDBMS는 데이터의 일관성을 위해 잠재적 불일치를 희생하지 않는 한편, 문서 데이터베이스는 더 높은 속도의 커밋을 관리하며 일부 그래프 데이터베이스 역시 트랜잭션 중심의 사용 사례를 지원할 수 있다. 그러나 OLTP 데이터베이스는 실시간으로 많은 양의 데이터를 처리해야 하는 대규모 분석용 시스템에는 적합하지 않다.

 

ACID

 데이터베이스 시스템에서 원자적 트랜잭션을 지원하기 위해서는 ACID라는 특성이 중요하다. ACID는 원자성(Atomicity), 일관성(Consistency), 독립성(Isolation), 내구성(Durability)을 의미한다. 원자성은 트랜잭션의 모든 작업이 완전히 수행되거나 아예 수행되지 않아야 한다는 것을 의미하며, 일관성은 트랜잭션 이후 데이터베이스가 항상 일관된 상태를 유지하도록 보장한다. 독립성은 동시에 여러 트랜잭션이 진행될 경우 각 트랜잭션이 서로 독립적으로 처리되도록 보장하며, 내구성은 시스템 오류에도 불구하고 트랜잭션이 완료된 후 데이터가 보존되는 것을 의미한다.

 

 ACID 특성을 갖추면 데이터베이스의 일관성 있는 상태 유지가 가능해지고 개발자에게도 상당한 편의를 제공한다. 반면에 ACID 제약을 완화하면 성능과 확장성을 높일 수 있는 장점이 있어, 일부 분산 데이터베이스는 '최종 일관성'을 선택하기도 한다.

원자적 트랜잭션

 원자적 트랜잭션은 한 단위로 수행되어야 하는 여러 변경 작업을 포함하는데, 예를 들어 뱅킹 애플리케이션에서 계좌 간 송금을 할 때, 계좌 A에서 돈을 빼고 계좌 B에 추가하는 작업은 하나의 트랜잭션으로 묶여야 한다. 송금 작업이 중단되면 어느 계좌에도 변경이 일어나지 않아야 하며, 완료되면 두 계좌 모두 정확하게 반영되어야 한다.

 

OLTP와 분석

  OLTP 시스템에서 분석 작업을 수행할 수 있지만, 장기적으로는 트랜잭션 워크로드와 자원 충돌로 인해 성능에 한계가 발생할 수 있다. 데이터 엔지니어는 OLTP 시스템과 분석 시스템을 분리하고 적절한 통합 전략을 통해 프로덕션 성능 저하를 피할 수 있도록 해야 한다. SaaS 애플리케이션이 분석 기능을 결합하는 하이브리드 애플리케이션의 필요성이 증가하면서, 데이터 엔지니어는 이러한 트랜잭션과 분석 워크로드가 혼합된 데이터 애플리케이션을 효과적으로 관리하는 것이 중요한 과제가 되고 있다.

 

5.2.4 온라인 분석 처리 시스템

 OLAP(온라인 분석 처리) 시스템은 OLTP 시스템과 대비되는 기능을 지닌다. OLAP는 대규모 분석 쿼리를 효율적으로 처리하기 위해 구축된 시스템으로, 개별 레코드 조회에는 비효율적이다. 예를 들어, 최신 열 형식 데이터베이스는 대용량 데이터를 스캔하도록 최적화되어 있으며, 최소 100MB 이상의 데이터 블록을 스캔하여 높은 확장성과 스캔 성능을 제공한다. 따라서 OLAP 시스템에서 개별 항목 조회가 빈번하게 이루어진다면, 캐싱 계층을 추가하여 속도를 보완하지 않는 한 시스템 성능 저하가 발생할 수 있다.

 

 OLAP는 대규모 대화형 분석 쿼리를 지원하는 모든 데이터베이스 시스템을 포괄하는 용어로, 특정 시스템 유형에만 국한되지 않는다. 이 시스템의 온라인 부분은 끊임없이 들어오는 쿼리를 처리할 수 있어 대화형 분석에 적합하다. 또한, OLAP 시스템은 ML 모델 학습을 위한 데이터 제공과 같이 다양한 활용을 위해 데이터 웨어하우스로부터 데이터를 읽어 오기도 하며, 역방향 ETL 워크플로를 통해 분석 결과를 CRM, SaaS 플랫폼 등의 원천 시스템에 다시 전달하는 역할도 수행할 수 있다.

5.2.5 변경 데이터 캡처

 변경 데이터 캡처(CDC- Change Data Capture)는 데이터베이스에서 발생하는 변경 사항(삽입, 업데이트, 삭제)을 추출하여 거의 실시간으로 처리하는 방법이다. 이를 통해 데이터베이스 간 복제를 가능하게 하거나 다운스트림 처리에 필요한 이벤트 스트림을 제공하는 데 자주 활용된다.

 

 CDC 방식은 데이터베이스 유형에 따라 상이하게 구현되며, 예를 들어 관계형 데이터베이스에서는 데이터베이스 서버가 직접 이벤트 로그를 생성해 이를 스트림으로 활용한다. 반면, 클라우드 기반 NoSQL 데이터베이스는 로그나 이벤트 스트림을 대상 스토리지에 바로 전송하여 데이터를 실시간으로 동기화하거나 분석할 수 있도록 지원한다.

5.2.6 로그

 로그는 시스템에서 발생하는 다양한 이벤트 정보를 캡처하는 역할을 하며, 예를 들어 웹 서버의 트래픽과 사용 패턴이나 운영 체제의 부팅, 애플리케이션 시작 및 충돌 시 이벤트를 기록하는 것이 일반적이다. 이러한 로그는 다운스트림 데이터 분석, 머신러닝, 자동화에 매우 유용한 데이터를 제공할 수 있다.

 

 주요 로그 소스에는 운영 체제, 애플리케이션, 서버, 컨테이너, 네트워크, IoT 기기 등이 포함되며, 각 로그는 이벤트와 관련된 메타데이터를 추적한다. 특히 로그는 최소한 누가, 무엇이, 언제에 해당하는 정보를 담고 있어야 한다.

• 누가: 이벤트와 관련된 사용자, 시스템, 또는 서비스 계정 정보 (예: 브라우저 사용자 에이전트, 사용자 ID)
• 무슨 일이 있었는가: 발생한 이벤트 자체와 관련된 구체적인 메타데이터
• 언제 발생했는가: 이벤트가 발생한 타임스탬프

 로그 인코딩

 로그는 몇가지 방식으로 인코딩 된다.

1. 이진 인코딩된 로그
   공간 효율성과 빠른 입출력을 위해 사용자 지정 압축 형식으로 데이터를 저장하며, 대표적으로 데이터베이스 로그가 여기에 해당된다.
2. 반정형 로그
   주로 JSON과 같은 객체 직렬화 형식의 텍스트로 저장되어 기계가 읽기에 용이하나, 이진 인코딩보다 효율성이 떨어진다. 이 로그 형식은 활용하려면 추가적인 사용자 정의 코드가 필요하여 분석 과정에서 복잡성이 발생할 수 있다.
3. 비구조화된 일반 텍스트 로그
   소프트웨어의 콘솔 출력을 저장하는 형식으로, 특정 표준 없이 원시 텍스트 형태로 저장된다. ML 엔지니어나 데이터 과학자가 활용할 때 유용할 수 있으나, 필요한 정보를 추출하는 데 복잡할 수 있다.

로그 해상도

 로그 해상도는 로그가 캡처하는 이벤트 데이터의 양을 나타내며, 데이터베이스 로그는 데이터베이스 이벤트 정보를 통해 데이터베이스 상태를 재구성하는 데 충분한 정보를 포함한다. 그러나 모든 데이터 변경 사항을 캡처하는 것은 빅데이터 환경에서 실용적이지 않아 특정 커밋 이벤트만을 기록하는 경우도 많다. 또한, 로그는 설정된 조건에 따라 다양한 수준으로 기록되며, 시스템은 모든 이벤트 또는 오류만을 기록하도록 설정할 수 있다.

 

 로그는 일괄 처리와 실시간 방식으로 저장되며, 일괄 로그는 파일에 지속적으로 기록된다. 실시간 애플리케이션의 경우 개별 로그 항목이 Kafka나 Pulsar와 같은 메시징 시스템에 기록된다.

 

5.2.7 데이터베이스 로그

 데이터베이스 로그는 데이터 무결성과 복구 가능성을 유지하는 데 필수적인 역할을 한다. 로그 선행 기록(WAL, Write-Ahead Logging) 방식을 통해 데이터베이스 서버는 각 쓰기 또는 업데이트 작업을 승인하기 전에 로그 파일에 해당 작업을 기록하며, 이 로그는 특정 데이터베이스의 고유한 바이너리 형식으로 저장된다. 서버가 중단되거나 오류가 발생하더라도 로그에 기록된 정보를 기반으로 작업을 완료하거나 이전 상태로 복구할 수 있다.

 

 이러한 데이터베이스 로그는 CDC(변경 데이터 캡처)에서 활용될 수 있는데, 이를 통해 데이터베이스에서 발생하는 변경 이벤트를 실시간 스트림으로 생성하여 다운스트림 시스템에 전달한다. 이는 데이터 엔지니어가 데이터베이스 변경 사항을 추적하고, 데이터를 다른 시스템으로 복제하는 작업에 유용하다.

 

데이터베이스 로그는 테이블에 대한 작업을 기록

5.2.8 CRUD

 CRUD는 생성(Create), 읽기(Read), 업데이트(Update), 삭제(Delete)를 뜻하는 네 가지 기본 트랜잭션 작업을 말하며, 프로그래밍에서 데이터의 기본 조작 방식이다. 이 패턴은 데이터베이스에 애플리케이션 상태를 저장하는 데 널리 쓰이며, 데이터를 사용하기 위해서는 먼저 데이터를 생성하고, 이후 데이터를 읽거나 업데이트하며, 필요에 따라 데이터를 삭제할 수 있도록 보장하는 원칙을 따른다. 이를 통해 데이터가 저장소 유형에 관계없이 CRUD 작업을 안정적으로 수행할 수 있다.

소프트웨어 애플리케이션에서 CRUD는 특히 API와 데이터베이스의 동작 패턴으로 자주 활용되며, 웹 애플리케이션에서도 RESTful HTTP 요청과 데이터베이스의 CRUD 연산을 통해 데이터 저장과 검색이 이루어진다.

 

 또한, 스냅샷 기반 추출 방식은 데이터베이스에서 CRUD 작업을 통해 데이터 상태를 가져오며, 반면 CDC를 활용하면 데이터 변경 사항의 전체 기록을 캡처하여 실시간 분석이 가능해진다. 이는 데이터베이스의 트랜잭션 기록을 지속적으로 추적하고, 데이터 동기화와 분석에 중요한 역할을 한다.

 

5.2.9 입력 전용

 입력 전용 패턴은 데이터를 포함한 테이블에 직접 기록을 보관하는 방식이다. 레코드를 업데이트하는 대신 새 레코드를 생성된 시간을 나타내는 타임스탬프와 함께 추가한다. 예를 들어, 고객 주소 테이블이 있는 경우, 일반 CRUD 패턴에서는 고객이 주소를 변경할 때 기존 레코드를 업데이트하지만, 입력 전용 패턴에서는 동일한 고객 ID로 새로운 주소 레코드를 추가한다. 이후 고객 ID를 통해 최신 주소 정보를 조회하려면 해당 ID의 최신 레코드를 찾는다.  

 

레코드 ID	값	타임스탬프
1	40	2021-09-19T00:10:23+00:00
1	51	2021-09-30T00:12:00+00:00

 

 이 패턴은 테이블 자체에 데이터베이스 로그를 유지하는 효과가 있어, 애플리케이션이 기록에 접근할 필요가 있는 경우 특히 유용하다. 예를 들어, 은행 애플리케이션에서 고객 주소 기록을 표시하는 데 적합하다. 별도의 분석 테이블에서도 입력 전용 패턴이 종종 사용되며, 입력 전용 ETL 패턴에서는 CRUD 테이블에서 업데이트가 발생할 때마다 대상 분석 테이블에 새로운 레코드를 입력한다. 

 

 이 패턴에는 몇 가지 단점이 존재한다. 첫째, 데이터가 자주 변경될 경우 각 변경 사항이 입력되기 때문에 테이블이 상당히 커질 수 있다. 테이블 크기를 적절히 유지하기 위해 레코드 만료 날짜나 최대 버전 수를 기준으로 오래된 레코드를 삭제하는 경우가 있다. 둘째, 현재 상태를 조회하려면 최신 타임스탬프를 기준으로 검색해야 하므로, 대량의 레코드를 가진 ID에서 조회하는 경우 추가적인 오버헤드가 발생한다.

 

5.2.10 메시지와 스트림

 메시지와 스트림은 이벤트 기반 아키텍처에서 자주 사용하는 두 가지 개념으로, 데이터 전송과 관련된 핵심 기능을 제공하지만 중요한 차이가 존재한다.

 

 메시지는 두 시스템 간 통신되는 단위 데이터이다. 예를 들어, 시스템 1에서 시스템 2로 메시지가 전송될 때, 주로 메시지 큐를 통해 전달되어 소비자가 메시지를 받아 처리한 후 큐에서 제거된다. 이는 주로 특정 이벤트에 대한 개별적 신호를 보내는 데 사용되며, 예를 들어 IoT 기기가 온도 판독값을 메시지 큐로 전송하고, 이 값을 기반으로 적절한 조치를 취하는 시스템이 이를 수신하여 처리할 수 있다.

 

두 시스템 간에 전달되는 메시지

 

 스트림은 메시지와 달리, 이벤트 레코드를 순서대로 쌓아 추가 전용 로그 형태로 저장하는 방식이다. 스트리밍 플랫폼은 정렬된 순서로 데이터 이벤트를 저장하고, 특정 시점으로 되돌아가거나 집계 작업 등을 가능하게 해준다. 이러한 추가 전용 특성 덕분에 스트림은 장기간 유지되며, 복잡한 이벤트 분석이나 과거 데이터 조회에 유리하다. 예를 들어, IoT 온도 판독값을 지속적으로 스트림에 저장함으로써 향후 온도 패턴과 통계를 분석하는 데 사용할 수 있다.

 

레코드의 정렬된 추가 전용 로그인 스트림

 

 메시지는 개별 사건의 실시간 처리에 적합하고, 스트림은 데이터의 지속적 축적과 과거 데이터 조회 및 분석에 유리하여 두 방식은 서로 보완적인 관계를 이룬다.

 

5.2.11 시간 유형

 시간은 모든 데이터 수집에서 중요하지만, 특히 스트리밍 환경에서는 더욱 세밀한 주의가 필요하다. 스트리밍에서 데이터를 연속적으로 처리하는 특성상, 데이터가 생성된 직후 실시간으로 사용될 것이라 기대된다. 이를 위해 데이터가 흐르는 과정에서 발생하는 주요 시간 유형을 관리하는 것이 중요하다.

• 이벤트 시간은 소스 시스템에서 데이터 이벤트가 실제로 발생한 시간을 의미하며, 해당 이벤트의 타임스탬프를 포함한다. 이벤트가 생성된 후 다운스트림 시스템으로 전달되기까지 지연이 발생할 수 있으며, 이는 이벤트의 원래 발생 시점을 명확히 기록해 전체 데이터 이동의 추적을 가능하게 한다.
• 수집 시간은 데이터가 원천 시스템에서 메시지 큐, 메모리, 데이터베이스 등으로 전송되는 순간을 나타낸다. 수집된 데이터는 이후 즉시 처리될 수도, 일정 시간이 지나 처리될 수도 있으며, 일부는 장기 저장소에 보관될 수 있다.
• 처리 시간은 데이터 수집 후 변환 작업을 거쳐 데이터가 처리되는 시점이다. 이 시간은 데이터의 변환이 완료되는 데 걸리는 시간으로, 초 단위부터 시간 단위까지 다양하게 측정된다.

 이러한 시간 유형들을 추적함으로써 데이터의 흐름을 파악하고 지연 시간을 관리할 수 있다. 자동화된 방식으로 이러한 시간들을 기록하고 모니터링을 설정하면, 데이터가 이동하는 경로를 명확히 파악할 수 있어 데이터 워크플로의 최적화를 지원한다.