보호되어 있는 글입니다.

1. 문제 상황: 노후 리포트가 만든 운영 리스크기존 리포트는 HTML 기반으로 운영되면서 시간이 지날수록 유지보수와 운영 한계가 뚜렷해졌다. 리포트가 단순 조회 화면에 가까운 형태로 관리되어, 데이터 생성 기준과 필터링 조건, 권한 체계를 추적하기 어려웠다. 이 때문에 리포트를 수정할 때마다 기존 로직을 다시 확인해야 했고, 작은 조건 변경에도 운영 부담이 컸다.보안과 권한 관리에서도 문제가 있었다. 접근 권한이 데이터 기준으로 체계화되어 있지 않고 기존 화면과 운영 방식에 의존하고 있어, 사용자별 접근 범위를 명확히 통제하기 어려웠다. 운영 리포트에서 데이터 접근 권한은 보안 리스크와 직접 연결되는 요소이므로 개선이 필요하다고 판단했다.과거 데이터 조회와 이력 분석에도 제약이 있었다. 특정 시점의 데..

1. 시맨틱 레이어 (Semantic Layer)란 무엇인가시맨틱 레이어, Semantic Layer는 데이터 웨어하우스·레이크하우스 위에 위치하여 물리적 테이블, 컬럼, SQL 조인, 집계 로직을 비즈니스 의미 단위로 추상화하는 계층이다.“매출, 고객, 주문, 활성 사용자, 전환율 같은 비즈니스 개념을 누가 조회하든 동일한 정의와 동일한 계산 방식으로 사용할 수 있게 하려면데이터 플랫폼 어디에 그 의미를 정의해야 하는가?” 탄생 배경예를 들어 주문 데이터가 있다고 하자. 문제는 조직이 커질수록 동일한 개념이 여러 방식으로 계산된다는 점이다.예를 들어 “매출”이라는 지표 하나만 보더라도 팀마다 정의가 달라질 수 있다.영업팀 매출: SUM(order_amount)재무팀 매출: SUM(order_amou..

출처 : https://www.kimballgroup.com/wp-content/uploads/2007/10/An-Architecture-for-Data-Quality1.pdf 아래는 원문 중에서 감사 테이블 에 대한 내용과 그 번역본이다. Ralph Kimball은 이 문제를 단순히 "ETL에서 validation 체크 좀 넣자"는 수준으로 접근하지 않는다.그는 데이터 품질 자체를 측정 가능하고, 추적 가능하며, 리포팅 가능한 시스템으로 설계해야 한다고 주장한다.그 핵심에 있는 두 가지 구조물이 바로 Error Event Schema와 Audit Dimension이다. 1. Error Event Schema: 오류를 로그로 남기지 말고, 차원 모델(dimensional model)로 설계하라. (팩트 ..

# 필요성 왜 정합성 검증이 필요한가ETL/ELT 과정에서 데이터가 깨지는 흔한 시나리오소스 DB 스키마 변경이 파이프라인에 반영 안 됨적재 도중 네트워크 끊김 → 일부만 들어간 경우타임존 차이로 날짜 데이터 밀림데이터 신뢰성 감소 # 정합성 검증의 종류① 완전성 검증 (Completeness)- 소스 건수 vs 타겟 건수 비교- 특정 컬럼 NULL 비율 체크- 날짜 범위별 누락 여부 확인 ② 정확성 검증 (Accuracy)- 합계/평균 등 집계값 소스와 비교- 주요 금액 컬럼 SUM 값 일치 여부- 소수점, 반올림 처리 기준 통일 확인 ③ 일관성 검증 (Consistency)- Fact ↔ Dimension 테이블 간 FK 정합성- 같은 데이터가 여러 테이블에 있을 때 값 일치 여부- 코드값 표준화 (..

# 탄생 배경전통적인 운영 시스템(OLTP)은 데이터의 최신 상태를 유지하는 데 집중한다.그러나 의사결정 지원 시스템이나 데이터 웨어하우스 환경에서는 '과거의 특정 시점에 데이터가 어떠했는가'라는 시계열적 관점이 필수적이다.예를 들어, 고객의 거주지가 서울에서 부산으로 변경되었을 때, OLTP 시스템은 단순히 주소를 업데이트하면 그만이지만,데이터 마트에서는 부산으로 이주하기 전 서울에서 발생시킨 매출 이력을 여전히 서울 지역 실적으로 집계할 수 있어야 한다.이러한 이력 보존의 필요성과 데이터 중복 최소화 사이의 균형을 맞추기 위해 랄프 킴벌(Ralph Kimball)에 의해 SCD 개념이 정립되었다.# 동작 원리SCD의 핵심은 차원 테이블의 속성 변화를 감지하고, 정의된 정책에 따라 테이블 구조를 갱신하..

# 히스토리 원래는 오픈 소스 분산 컴퓨팅 프레임워크인 하둡과 그 구성 요소인 HDFS 파일 시스템을 사용하여 저렴한 컴퓨터 클러스터에 걸쳐 대량의 정형 및 비정형 데이터 세트를 저장하고 처리했다.하지만 단순히 이 모든 데이터를 저장하는 것만으로는 충분하지 않았다. 하둡 생태계에는 MapReduce라는 분석 프레임워크가 포함되어 있었는데, 이를 통해 자바로 분석 작업을 작성하고 하둡 클러스터에서 실행할 수 있었다.MapReduce 작업을 작성하는 것은 장황하고 복잡했으며, 많은 분석가들은 Java보다 SQL을 작성하는 데 더 익숙했기 때문에 SQL 문을 MapReduce 작업으로 변환하기 위해 Hive가 만들어졌다.SQL을 작성하려면 저장소에 있는 파일 중 특정 데이터 세트 또는 테이블에 속하는 파일을..

# 개요전통적인 행 기반(row-oriented) 저장 방식(CSV, JSON, RDBMS heap file)은 OLTP(트랜잭션 처리)에 최적화되어 있지만, 분석 쿼리(OLAP)에서는 치명적인 비효율이 발생합니다. 예를 들어 1억 개의 row에서 단 2개의 컬럼만 집계할 때도, 행 기반 포맷은 전체 row를 읽어야 합니다. Parquet은 이 문제를 열 지향(columnar) 저장 방식으로 해결합니다. Parquet은 복잡한 중첩 데이터 구조를 염두에 두고 처음부터 설계되었으며, Dremel 논문에 설명된 record shredding and assembly algorithm 을 사용합니다. 저희는 이러한 접근 방식이 중첩된 네임스페이스를 단순히 평면화하는 것보다 우수하다고 생각합니다. [기본 철학 ]..

# 탄생 배경 과거의 데이터 파이프라인은 주로 리눅스의 크론(Cron)과 쉘 스크립트에 의존하여 구축되었다.그러나 처리해야 할 데이터의 소스와 파이프라인의 규모가 기하급수적으로 커짐에 따라 심각한 한계에 직면했다. 작업 간의 선후 관계, 즉 의존성을 설정하고 관리하기가 매우 까다로웠으며 특정 작업이 실패했을 때 하위 작업을 일시 중단하거나 실패 지점부터 재시도하는 로직을 일일이 구현해야 하는 이른바 크론 지옥(Crontab Hell)이 발생했다. 또한, 전체 파이프라인의 분산된 실행 상태를 한눈에 파악할 수 있는 중앙 관제 모니터링 시스템의 부재로 인해 장애 추적 및 복구에 막대한 엔지니어링 리소스가 소모되었다.에어플로우는 이러한 레거시 환경의 의존성 관리 부재, 실패 처리의 복잡성, 그리고 모니터링의 ..

Oozie는 Apache Hadoop 작업을 관리하기 위한 워크플로 스케줄링 시스템입니다.Oozie Workflow 작업은 지향성 비순환 그래프(DAG)의 작업입니다.Oozie Coordinator jobs는 시간(빈도)과 데이터 사용 가능성에 의해 트리거되는 반복적인 Oozie Workflow jobs입니다. # 탄생 배경초기 하둡 환경에서 데이터 엔지니어들은 각기 다른 맵리듀스(MapReduce) 작업이나 Hive 쿼리, Pig 스크립트를 수동으로 실행하거나 쉘 스크립트를 통해 연쇄적으로 실행했습니다. 그러나 이러한 방식은 다음과 같은 치명적인 한계를 가졌습니다. - 의존성 관리의 부재: 앞선 작업이 실패했을 때 후속 작업을 중단시키거나 재시도하는 로직을 구현하기 복잡함.- 데이터 가용성 확인의 어려..