데이터 파이프라인을 만들다 보면 "멱등성" 이라는 단어를 한 번쯤 듣게 된다. 멱등성(Idempotency)은 같은 작업을 한 번 실행하든 세 번 실행하든 결과가 동일한 성질이다.데이터 파이프라인에서 이게 의미하는 건 단순하다. > 배치를 한 번 돌리든 세 번 돌리든, 테이블에 들어가는 데이터는 똑같아야 한다. 팀에 합류하고 얼마 안 돼서 기존 파이프라인 몇 개를 넘겨받았다. 전임자가 만들어둔 거라 구조만 훑어보고 넘어갔다. 잘 돌아가고 있었으니까. 어느 날 새벽에 그 배치가 죽었다. 네트워크 타임아웃. 재실행했다. 다음 날 아침에 분석팀에서 "데이터가 이상한 것 같다"라고 연락이 왔다. 코드를 다시 열어봤다. 간소화하면 대충 이런 형태였다.INSERT INTO analytics.daily_payment..

이커머스 데이터에는 다른 도메인이랑 다른 점이 하나 있다.한 번 집계한 숫자가 며칠 뒤에 보면 달라져 있다는 거다. 코드가 바뀐 것도 아니고, 데이터가 사라진 것도 아닌데, 어제 매출이라고 찍어둔 숫자가 오늘 보면 줄어 있을 수 있다. 이건 파이프라인 버그가 아니라 이커머스 데이터의 본질적인 특성이다.그래서 이커머스 파이프라인은 처음 설계할 때부터 이 특성을 전제로 깔고 가야한다. 이 문제를 이해하려면 먼저 이커머스 데이터가 어떻게 만들어지는지 봐야한다.로그나 클릭 같은 데이터는 한 번 발생하면 그걸로 끝이다.어제 찍힌 페이뷰작 오늘 갑자기 사라지지 않는다.그래서 어제 데이터를 한 번 집계하면 그 숫자는 영원히 그 값이다. 이커머스의 주문은 다르다.주문 한 건이 끝까지 가는 데 며칠에서 몇 주가 걸리고..

데이터 엔지니어링을 공부하다 보면 어느 순간부터 dbt라는 단어가 자꾸 눈에 들어온다.찾아보면 "SQL 변환 도구"라는 설명이 반복되는데, 솔직히 그걸로는 감이 안왔따.그래서 이게 대체 왜 필요한 건지, 파이프라인 안에서 어떤 역할을 하는 건지 직접 정리해봤다. 데이터 파이프라인, 큰 그림부터 보자SaaS 서비스를 운영하는 회사에서 일한다고 해보자. Salesforce에서는 고객 정보가 들어오고, Stripe에서는 결재 내역에 쌓이고,자체 서비스 DB에는 유저 활동 로그가 남는다.이 데이터들은 분석팀이 쓸 수 있게 만들려면 보통 세 단계를 거친다.추출 (Extract) - 여기저기 흩어진 데이터를 끌고온다적재 (Load) - 한 곳에 모아서 저장한다변환 (Transform) - 분석할 수 있는 형태로 가..

UUID는 128비트 길이의 고유 식별자로, 중앙 관리 시스템 없이도 전 세계적으로 유일한 ID를 생성할 수 있도록 설계되었습니다.RFC 4122 표준으로 정의되어 있으며, 일반적으로 다음과 같은 형태로 표현됩니다`550e8400-e29b-41d4-a716-446655440000`8-4-4-4-12 형식의 16진수로 구성되며, 하이픈으로 구분된 5개의 그룹으로 이루어집니다. UUID의 구조UUID는 총 128비트(16바이트)로 구성되며, 다음과 같이 분해할 수 있습니다.`xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx`time_low (32비트): 타임스탬프의 하위 32비트time_mid (16비트): 타임스탬프의 중간 16비트time_hi_and_version (16비트): 타임스탬프..

오늘 오후 중에 윈도우 서버 컴퓨터가 강제 종료가 되버리는 증상이 발생하였습니다.기존의 돌리던 프로그램들은 거의 다 Linux 환경으로 옮겨놨고, 남아있던게 MySQL이랑 Apache였는데 작업 도중 서버가 다운이 되버렸습니다. 다시 부팅을 하고 XAMPP로 기존의 프로그램을 실행했는데 Apache는 잘 돌아가는 반면 MySQL의 경우에는 기존의 사용하던 3306 Port로 열리지 않고 3307로 자동으로 Port가 변경되어 열리는 현상이 발생하였습니다. [mysql] Error: MySQL shutdown unexpectedly.This may be due to a blocked port, missing dependencies, improper privileges, a crash, or a shutdo..

현대의 분산 시스템 환경에서 데이터는 여러 시스템과 데이터베이스에 분산되어 저장됩니다.이때 데이터의 일관성을 유지하고 실시간으로 동기화하는 것은 매우 중요한 과제입니다.CDC(Change Data Capture)파이프라인은 이러한 문제를 해결하기 위한 핵심 기술로, 데이터베이스의 변경사항을 실시간으로 감지하고 다른 시스템으로 전파하는 역할을 합니다.CDC란 무엇인가?CDC(Change Data Capture)는 데이터베이스에서 발생하는 모든 변경사항(INSERT, UPDATE, DELETE)을 실시간으로 감지하고 캡처하는 기술입니다.전통적인 배치 처리 방식과 달리, CDC는 데이터 변경이 발생하는 즉시 이를 감지하여 스트리밍 방식으로 처리합니다. CDC의 핵심 개념트랜잭션 로그 기반 감지대부분의 CDC ..

"매일 오전 9시에 데이터를 추출해서 변환하고, 문제가 있으면 알림을 보내고, 성공하면 리포트를 생성해서" 이런 반복적인 작업을 수동으로 처리하고 계신가요? 개발자라면 누구나 한 번쯤은 복잡한 배치 작업들을 자동화하고 싶어했을 것입니다. Apache Airflow가 바로 이런 고민을 해결해주는 강력한 솔루션입니다. Apache Airflow란?Apache Airflow는 워크플로우를 프로그래밍 방식으로 작성, 스케줄링, 모니터링할 수 있게 해주는 오픈소스 플랫폼입니다. 2014년 Airbnb에서 복잡한 데이터 파이프라인을 관리하게 위해 개발되었고, 2016년 Apache Software Foundation에 기부되어 현재는 데이터 엔지니어링 분야의 사실상 표준으로 자리잡았습니다. 왜 Airflow가 필요..

"우리는 Data Drvien 회사입니다." 이제는 이말을 하지 않는 회사가 없을 정도다.10년 전만 해도 Data Driven은 구글이나 넷플릭스 같은 빅테크 기업들만의 전유물이었다.하지만 이제는 스타트업부터 전통 기업까지, 모든 곳에서 Data Driven을 말한다. 문제는 이제 Data Drvien이 너무 당연한 말이 되버렸다는 것이다.마치 "고객을 생각합니다." 처럼 누구나 하는 말이되었다.데이터가 중요한 이유현대 사회에서 데이터의 중요성은 더 이상 설명이 필요 없을 정도다.특히 디지털 환경에서는 모든 행동이 데이터로 기록된다. 사용자가 언제 들어왔는지, 어떤 페이지를 봤는지, 얼마나 머물렀는지, 어디서 이탈했는지까지 모든 것이 숫자로 남는다. 이런 데이터들은 고객의 진짜 모습을 보여준다. 설문조..

데이터 엔지니어링 팀에서 Terraform을 도입할 때 가장 첫 번째로 마주하는 근본적인 질문이 있습니다."우리의 인프라 코드를 어떻게 구조화할 것인가?" 하나의 거대한 Terraform 프로젝트로 모든 것을 관리할 것인가, 아니면 작은 모듈들로 나누어 관리할 것인가?이는 단순한 코드 구조 문제를 넘어서 팀의 협업 방식, 배포 전략, 그리고 장기적인 유지보수성까지 결정하는 중요한 아키텍처 결정입니다. Monolithic 접근법: 하나로 통합하는 철학Monlithic 접근법은 전체 데이터 인프라를 하나의 큰 Terraform 프로젝트로 관리하는 방식입니다.모든 리소스가 단일 상태 파일에서 관리되며, 하나의 `terraform apply`명령으로 전체 인프라가 배포됩니다.# monolithic-data-in..

현대 데이터 플랫폼에서는 데이터만큼이나 메타데이터(metadata)의 관리가 중요해졌습니다.데이터가 무엇인지, 어디서 왔는지, 어떻게 사용되는지를 설명하는 메타데이터는 모든 데이터 흐름의 핵심이자 품질 보장의 기반이 되기 때문입니다. 그런데, 이 메타데이터를 어디에 어떻게 저장하고 관리할 것이지에 따라 플랫폼의 구조는 크게 두 가지 방식으로 나뉩니다. 바로 SSOT(Single Source of Truth)와 Federated Metadata 방식입니다. 메타데이터(Metadata)란?간단히 말하면, 데이터에 대한 데이터입니다.즉, 어떤 테이블이 어떤 컬럼으로 이루어져 있고, 누가 만들었으며, 어떻게 사용되는지 등의 정보입니다. 예시:컬럼 이름설명데이터 타입customer_id고객 고유 IDVARCHA..