Data Lake

Data Lake 는 다양한 형식 (structured, semi-structured, unstructured) 의 데이터를 원시 (raw) 형태로 저장하는 중앙 저장소이다. 스키마를 저장 시점이 아닌 조회 시 정의하는 schema-on-read 방식을 사용하며, AWS S3, Azure Data Lake Storage, Hadoop HDFS 등 객체 스토리지를 기반으로 구성된다. 대규모 데이터 저장, 데이터 탐색, 데이터 과학, 실시간 분석 등 여러 데이터 활용 시나리오를 지원하며 Lakehouse 나 Data Warehouse 와 연계되어 통합 데이터 전략을 구현할 수 있다.

배경

  1. 데이터 폭증 시대의 도래

    • 2025 년까지 전 세계 데이터 생성량이 181 제타바이트에 도달 예상
    • IoT 디바이스, 소셜 미디어, 모바일 애플리케이션의 급속한 확산
    • 일일 2.5 퀸틸리온 바이트의 데이터 생성 (2017 년 기준)
  2. 기존 데이터 웨어하우스의 한계

    • 구조화된 데이터만 처리 가능
    • 스키마 온 라이트 (Schema-on-Write) 로 인한 유연성 부족
    • 높은 저장 비용과 복잡한 ETL 프로세스
    • 비정형 데이터 처리의 어려움
  3. 빅데이터 기술의 발전

    • Apache Hadoop 생태계의 성숙
    • 클라우드 컴퓨팅의 대중화
    • 머신러닝과 AI 기술의 급속한 발전

목적 및 필요성

  1. 비즈니스 목적

    • 비용 절감: 저렴한 객체 스토리지 활용으로 스토리지 비용 최대 90% 절감
    • 민첩성 향상: 새로운 데이터 소스의 빠른 통합
    • 혁신 촉진: 고급 분석 및 머신러닝 워크로드 지원
    • 규모 확장: 페타바이트 규모의 데이터 처리 능력
  2. 기술적 필요성

    • 다양한 데이터 형태 통합: 정형, 반정형, 비정형 데이터의 단일 저장소
    • 실시간 데이터 처리: 스트리밍 데이터의 즉시 수집 및 처리
    • AI/ML 지원: 원시 데이터에서 직접 머신러닝 모델 훈련
    • 셀프 서비스 분석: 비즈니스 사용자의 직접적 데이터 접근

핵심 개념

데이터 레이크는 다양한 소스로부터 수집된 구조화, 반구조화, 비구조화 데이터를 원시 형태로 저장하는 확장 가능한 중앙집중식 저장소이다. 스키마 온 리드 (Schema-on-Read) 접근 방식을 채택하여 데이터 저장 시점에는 구조를 강제하지 않고, 분석이나 처리가 필요한 시점에 스키마를 적용한다.

  1. 스키마 온 리드 (Schema-on-Read)

    • 정의: 데이터를 읽을 때 스키마를 적용하는 방식
    • 장점: 데이터 저장 시 전처리 시간 단축, 유연한 데이터 구조 변경
    • 특징: ETL 대신 ELT(Extract, Load, Transform) 방식 활용
  2. 플랫 아키텍처 (Flat Architecture)

    • 계층적 구조의 데이터 웨어하우스와 달리 수평적 저장 구조
    • 객체 스토리지 기반의 확장 가능한 저장 방식
    • 메타데이터를 통한 데이터 관리 및 검색
  3. 멀티 모달 데이터 지원

    • 구조화 데이터: 관계형 데이터베이스, CSV, JSON
    • 반구조화 데이터: XML, Parquet, Avro
    • 비구조화 데이터: 텍스트, 이미지, 비디오, 오디오

실무 구현 연관성

  1. 스토리지 기술 연관성

    • 객체 스토리지: Amazon S3, Azure Blob Storage, Google Cloud Storage
    • 분산 파일 시스템: HDFS (Hadoop Distributed File System)
    • 클라우드 네이티브 솔루션: AWS Lake Formation, Azure Data Lake Storage
  2. 데이터 처리 엔진 연관성

    • 배치 처리: Apache Spark, Apache Hadoop MapReduce
    • 스트림 처리: Apache Kafka, Apache Flink, Amazon Kinesis
    • 쿼리 엔진: Apache Presto, Trino, Amazon Athena
  3. 메타데이터 관리 연관성

    • 카탈로그 서비스: Apache Hive Metastore, AWS Glue Catalog
    • 데이터 거버넌스: Apache Atlas, Collibra, Alation
    • 스키마 레지스트리: Confluent Schema Registry, Apache Avro

주요 기능 및 역할

  1. 데이터 수집 기능

    • 배치 수집: 정기적인 대량 데이터 로딩
    • 실시간 수집: 스트리밍 데이터의 연속 처리
    • API 기반 수집: REST, GraphQL 을 통한 데이터 연동
    • 파일 기반 수집: FTP, SFTP 를 통한 파일 전송
  2. 데이터 저장 기능

    • 원시 데이터 보존: 데이터 변환 없이 원본 상태 유지
    • 버전 관리: 데이터 변경 이력 추적
    • 압축 및 파티셔닝: 저장 효율성 최적화
    • 데이터 레이크 계층화: Raw, Standardized, Curated, Sandbox 레이어
  3. 데이터 처리 기능

    • 배치 처리: 대용량 데이터의 주기적 처리
    • 스트림 처리: 실시간 데이터 변환 및 분석
    • ETL/ELT 파이프라인: 데이터 변환 및 품질 관리
    • 데이터 품질 검증: 자동화된 데이터 검증 및 정제

특징

  1. 유연성 (Flexibility)

    • 스키마 온 리드 (Schema on Read) 로 인한 구조 변경의 자유도
    • 다양한 데이터 형태와 포맷 지원
    • 새로운 분석 요구사항에 대한 빠른 대응
  2. 확장성 (Scalability)

    • 수평적 확장 가능한 분산 스토리지
    • 페타바이트 규모의 데이터 처리 능력
    • 클라우드 기반 탄력적 자원 관리
  3. 비용 효율성 (Cost-Effectiveness)

    • 저렴한 객체 스토리지 활용
    • 사용량 기반 과금 모델
    • 데이터 압축 및 중복 제거 기술
  4. 개방성 (Openness)

    • 오픈 소스 기술 스택 활용
    • 벤더 종속성 최소화
    • 다양한 도구와의 호환성

핵심 원칙

  1. 모든 데이터 수용 (Ingest All Data)

    • 데이터 형태나 품질에 관계없이 모든 데이터 수집
    • 미래의 분석 가능성을 위한 데이터 보존
    • “Ask questions later” 접근 방식
  2. 원시 데이터 보존 (Keep Raw Data)

    • 데이터 변환 전 원본 상태 유지
    • 데이터 계보 (Lineage) 추적 가능
    • 재처리 및 재분석 지원
  3. 스키마 온 리드 (Schema-on-Read)

    • 저장 시점이 아닌 사용 시점에 스키마 적용
    • 유연한 데이터 구조 변경
    • 빠른 데이터 수집 지원
  4. 메타데이터 중심 관리 (Metadata-Driven)

    • 풍부한 메타데이터를 통한 데이터 검색성 향상
    • 데이터 카탈로그를 통한 데이터 거버넌스
    • 자동화된 분류 및 태깅

주요 원리

다이어그램

flowchart TD
    A["데이터 소스(정형/비정형)"] --> B[데이터 인제스트 계층]
    B --> C[데이터 레이크 스토리지]
    C --> D[데이터 카탈로그/메타데이터]
    D --> E[분석/머신러닝/BI]

작동 원리 및 방식

전형적인 Data Lake 흐름

sequenceDiagram
  participant Source as Data Source
  participant Ingest as Ingestion Layer
  participant RawZone as Raw Storage
  participant Process as Processing Engine
  participant CuratedZone as Curated Storage
  participant Query as Query Engine
  participant Consumer as BI/ML Consumer

  Source->>Ingest: 실시간/배치 데이터 수집
  Ingest->>RawZone: 원시 데이터 저장
  RawZone->>Process: 데이터 정제, 포맷 변환
  Process->>CuratedZone: 분석용 데이터 저장
  CuratedZone->>Query: SQL/ML 쿼리 수행
  Query->>Consumer: 결과 전달

데이터 레이크 작동 원리 설명:

  1. 데이터 수집: 다양한 소스에서 배치 또는 실시간으로 데이터 수집
  2. 원시 저장: 수집된 데이터를 변환 없이 원본 형태로 저장
  3. 표준화: 필요시 데이터 형식 통일 및 구조화
  4. 정제 및 변환: 비즈니스 로직 적용 및 품질 관리
  5. 분석 및 소비: 다양한 도구를 통한 데이터 활용

구조 및 아키텍처

graph LR
  subgraph Sources
    A1[DBMS] --> I1
    A2[Web Logs] --> I1
    A3[IoT Devices] --> I1
  end

  subgraph Ingestion
    I1[Kafka/Kinesis/Batch Upload]
  end

  subgraph Storage Zones
    RZ[Raw Zone]
    PZ[Processed Zone]
    AZ[Analytics Zone]
  end

  subgraph Processing
    PR1[Spark/Glue/Databricks]
  end

  subgraph Metadata
    M1[Glue Catalog/Atlas]
  end

  subgraph Query & Consumption
    Q1[Athena/Presto]
    C1[BI Tool]
    C2[ML Tool]
  end

  I1 --> RZ
  RZ --> PR1
  PR1 --> PZ
  PZ --> AZ
  AZ --> Q1
  Q1 --> C1
  Q1 --> C2
  AZ --> M1
  PZ --> M1

주요 구성 요소

구성 요소설명
Ingestion LayerKafka, Kinesis, NiFi, Flume 등으로 실시간 또는 배치로 데이터 적재
Storage LayerAmazon S3, Azure ADLS, Hadoop HDFS 등 오브젝트 스토리지 기반 저장소
Processing LayerApache Spark, AWS Glue, Databricks 등으로 ETL/ELT 수행
Metadata & GovernanceAWS Glue Catalog, Unity Catalog, Apache Atlas 등으로 메타데이터, 데이터 계보, 보안 정책 관리
Query LayerPresto, Athena, Trino, Hive 등으로 SQL-on-Object Storage 지원
Consumer LayerBI 도구 (Tableau, QuickSight), ML 도구 (SageMaker, Vertex AI 등)

구현 기법

Data Lake 는 다양한 기술 조합으로 구현할 수 있으며, 일반적으로 Ingestion → Storage → Processing → Query → Governance 흐름으로 구성된다.

구성 요소구현 기법설명예시
데이터 수집 (Ingestion)Batch, Stream 기반 적재Kafka, Kinesis, Flume, Sqoop 등을 통해 로그, DB, IoT 데이터 수집Kafka → S3 / Flume → HDFS
저장소 구성 (Storage)오브젝트 스토리지 계층 분리Raw, Processed, Analytics 계층으로 나눠 관리S3 Bucket prefix or HDFS directory 로 구분
처리 (Processing)Spark 기반의 ETL 또는 ELT정제, 포맷 변경, 중복 제거, 데이터 정렬, 집계 등AWS Glue, Databricks, EMR
쿼리 엔진SQL-on-Lake / Serverless QueryPresto, Athena, Hive 등으로 직접 SQL 조회Athena 로 Parquet 데이터 분석
메타데이터 관리Catalog 연동 + 계보 추적AWS Glue, Apache Atlas, DataHub 등을 통한 데이터 등록·검색스키마 자동 추출, lineage 시각화
접근 제어정책기반 권한 관리IAM, Lake Formation, Unity Catalog 등을 통해 권한 제어팀별 read/write 정책 분리

장점

📌 카테고리항목설명
1. 저장 및 인프라 유연성확장성오브젝트 스토리지 기반으로 페타/엑사바이트급까지 수평 확장 가능. 클라우드와 온프레미스 모두 지원 가능
비용 효율성S3/HDFS 등 저비용 저장소 기반, 사용량 기반 과금으로 비용 절감 효과 (DWH 대비 70~90% 저렴)
벤더 독립성오픈 포맷 (Parquet, ORC) 과 오픈 소스 스택 (Flink, Presto 등) 을 활용하여 클라우드 벤더 종속성 최소화
2. 데이터 유연성 및 다양성데이터 포맷 다양성정형 (CSV), 반정형 (JSON, Avro), 비정형 (이미지, 오디오, 로그 등) 까지 단일 저장소에서 통합 관리 가능
Schema-on-Read저장 시 스키마 적용 없이, 읽는 시점에서 유연하게 분석 가능. 다양한 소비 목적에 대응 가능
데이터 수집 유연성원시 데이터를 가공 없이 바로 저장 가능. 배치/스트리밍 수집 모두 유연하게 수용
3. 분석 및 활용 확장성AI/ML 연동성원시 데이터를 그대로 활용하여 ML 모델 학습 가능. 피처 스토어와 MLOps 시스템과 연동 유리
다양한 분석 도구 지원Spark, Hive, Athena, Presto 등 다양한 분석 도구와 연동 가능. BI 및 ML 모두 지원
빠른 실험/반복 가능성새로운 데이터 유형이나 분석 요구에 빠르게 대응하고 실험 가능한 환경 제공
4. 운영 및 전략적 가치데이터 사일로 해소다양한 소스의 데이터를 중앙 집중화하여 조직 전반에서 통합 분석 기반 제공
유연한 거버넌스 통합메타데이터, 품질, 보안 정책을 중앙 통제 가능. 관리 및 감사 용이
다양한 워크로드 지원ETL, BI, ML, Streaming 등 다양한 워크로드를 단일 환경에서 지원

단점과 문제점 그리고 해결방안

단점

카테고리항목설명해결 방안 및 전략
데이터 품질 관리데이터 스웜 현상스키마 없는 저장 → 탐색/분석 불가한 " 데이터 늪 " 으로 전락 위험데이터 카탈로그 (Glue, Atlas 등) 도입, 메타데이터 자동화, 계약 기반 저장 (Contract-First)
거버넌스 부재권한/품질/계보 관리 부재권한, 계보 추적, 품질 통제 어려움RBAC/ABAC 정책 도입, Atlas+Ranger, 품질 검증 자동화
쿼리 성능 문제느린 쿼리 응답 시간원시 데이터 직접 스캔, 파티션 미설계, 압축 포맷 미사용 등Parquet/ORC/Delta 도입, 파티셔닝, Z-Ordering, Caching 전략
운영 복잡성기술/아키텍처 복잡성 증가다양한 스택 연계 필요, 운영·유지보수 인력 부담단계별 구축 (PoC → Pilot), 관리형 서비스 사용 (AWS Glue, EMR 등)
비용 관리 한계스토리지/컴퓨팅 비용 증가데이터 무분별 적재로 인한 저장 비용 및 쿼리 비용 증가S3 Lifecycle Policy, Intelligent Tiering, Access Log 기반 데이터 TTL 설계

문제점

카테고리항목원인영향탐지 및 진단예방 방안해결 기법/도구
데이터 품질 문제일관성 없음스키마 불일치, 중복 적재, 형식 오류분석 오류, 모델 성능 저하dbt test, Great ExpectationsContract 기반 저장, ELT 사전 검증데이터 프로파일링, Skew 분석, 정제 파이프라인 구축
중복 데이터 저장동일 파일 재적재, 파티션 중복무분별 적재, 배치 중복 실행저장 비용 증가, 결과 불일치S3 파일 수/버전 모니터링Incremental Load 설계SCD2, Watermark 기반 중복 방지 처리
보안 위협권한 관리 미흡, 암호화 누락중앙 저장소 보안 미흡민감 정보 유출, 컴플라이언스 미준수S3 로그, 감사 로그, 접근 통계 확인IAM + KMS 연동, ABAC 정책 설정데이터 암호화 (SSE-KMS), 데이터 마스킹
메타데이터 부족카탈로그/계보 관리 미흡스키마 진화 미추적, 탐색 불가비효율적 탐색, 분석 지연메타데이터 완성도 지표자동 수집/버전 관리Apache Atlas, Glue Crawlers, DataHub
비용 예측 실패장기 보관, 비활성 데이터 적재데이터 수명/접근 패턴 고려 부족불필요한 저장 과금Access 로그 분석, Cold Zone 트래킹TTL 정책, 저장 등급 분리S3 Lifecycle Rule, Intelligent Tiering, Cost Explorer 분석 도구

도전 과제

카테고리과제명원인 및 증상영향탐지/진단 방법예방 및 해결 방안대표 기술/전략 예시
거버넌스/보안데이터 거버넌스 미비분산된 소스, 형식 불일치, 메타데이터 관리 부재규정 준수 실패, 신뢰성 저하메타데이터 누락 비율, 규제 로그 분석통합 거버넌스 프레임워크, 자동화 규정 모니터링Apache Atlas, DataHub, Collibra
권한 제어 및 감사 실패역할 기반 권한 모델 부재, 접근 제어 로그 미활용보안 취약, 인증 실패, 데이터 유출 위험IAM 로그, 접근 실패 이력RBAC/ABAC 설계, 세분화된 접근 정책 적용AWS IAM, Lake Formation, Ranger
데이터 품질 저하스키마 불일치, 결측치, 이상치 관리 미흡분석 오류, 모델 학습 실패dbt 테스트 실패율, Null 비율스키마 고정, Quality 프레임워크 구축Great Expectations, dbt, Data Contracts
아키텍처 설계Zone 전략 부재단일 저장소 사용, Raw/Processed/Curated 구분 없음관리 복잡성 증가, 추적 어려움스토리지 분석 도구, 디렉토리 구조 시각화레이어드 스토리지 설계, 계층별 관리 도입Raw → Silver → Gold, Medallion Architecture
실시간 처리 미흡배치 위주의 처리 구조, 이벤트 기반 처리 미지원실시간 의사결정 지연지연 시간, 스트림 누락율Kafka 기반 스트리밍 도입, CDC 적용, 델타 지원Kafka, Flink, Delta Lake
AI/ML 통합의 어려움파이프라인/ML 워크플로우 분리, 피처/모델 공유 어려움AI 프로젝트 지연, 재현성 부족MLOps 실패율, 학습 데이터 드리프트MLOps 파이프라인 구축, 피처 스토어 도입MLflow, Feast, SageMaker Pipelines
운영/자동화운영 자동화 부족수동 작업, 인프라/워크플로우 자동화 미흡운영 비용 상승, 장애 대응 지연실패율 로그, 수동 작업 지표스케줄러 도입, IaC, Auto ObservabilityAirflow, Dagster, Terraform, Prometheus
데이터 스웜 현상무분별한 저장, 중복 파일 증가, 카탈로그 혼란검색/관리/보안 어려움파일 수 증가율, 카탈로그 오류 수카탈로그 자동화, 저장소 TTL 정책 도입Apache Hive, Glue Catalog, Atlas
비용/효율성스토리지 비용 폭증중복 데이터, 장기 저장, 핫 데이터 분리 실패예산 초과, 비효율적인 저장소 운영S3 분석 리포트, 비용 예측 지표스토리지 파티셔닝, S3 Tier 관리, 백업 주기 최적화S3 Lifecycle Rule, Glacier, Delta Optimize
멀티클라우드이식성 및 사일로 발생클라우드별 서비스/포맷/카탈로그 차이통합 관리 어려움, 복잡도 증가클라우드간 메타데이터 불일치, 포맷 충돌표준 기반 메타데이터/포맷 채택, 컨테이너화, 오픈소스 활용Apache Iceberg, OpenLineage, Docker

분류 기준에 따른 종류 및 유형

분류 기준유형설명대표 기술 / 적용 사례
1. 배포 환경온프레미스 (On-Premise)자체 데이터센터 및 HDFS 기반 구축, 높은 제어권Hadoop, 금융·정부 기관
클라우드 (Cloud-Native)완전 관리형 서비스 기반의 유연한 확장 구조AWS S3, Azure ADLS, GCP GCS
하이브리드온프레미스와 클라우드를 함께 사용하는 유연한 구성AWS Outposts, Azure Arc, 점진적 클라우드 이전 시 활용
2. 스토리지 유형오브젝트 스토리지 (Object)대용량 비정형 데이터에 최적화, 확장성 뛰어남Amazon S3, Azure Blob, GCS
파일 기반 (File)파일 시스템 기반, 고성능 연산에 적합HDFS, NFS
블록 기반 (Block)저지연 고속 접근이 필요한 워크로드EBS, SAN
3. 처리 방식배치 처리 중심주기적인 대량 데이터 처리, 정형 보고서 및 BI 에 적합Apache Spark, Hive
실시간 처리 중심 (Streaming)이벤트 기반 데이터 수집, 실시간 분석Kafka, Flink, Spark Structured Streaming
하이브리드 처리배치 + 스트림을 통합하여 유연한 데이터 처리 지원Lambda Architecture, Kappa Architecture
4. 아키텍처 계층단일 티어모든 데이터가 하나의 계층에 저장됨 (단순 구조)Flat HDFS 디렉토리 구조
멀티 티어Raw → Processed → Curated 형태의 계층적 저장 구조데이터 파이프라인 최적화 및 거버넌스 통합에 유리
레이크하우스 (Lakehouse)레이크와 웨어하우스의 통합 구조. ACID, 카탈로그, 성능 기능 포함Delta Lake, Apache Iceberg, Apache Hudi
5. 통합 수준스탠드얼론 데이터 레이크DWH 와 별도로 존재하는 독립형 데이터 저장소전통적인 Hadoop 기반 구축형 레이크
통합형 (DWH 통합 or Lakehouse)기존 DWH 와 연계하거나 웨어하우스 기능을 흡수한 구조Snowflake on S3, Databricks
6. 데이터 구조 유형정형 데이터 (Structured)테이블, CSV, SQL 등 명확한 스키마가 존재하는 데이터RDBMS Export, BI 연동 데이터
반정형 (Semi-structured)JSON, XML, Avro 등 필드 기반 데이터IoT, 로그 분석, 이벤트 데이터
비정형 (Unstructured)이미지, 동영상, PDF, 로그 파일 등 구조 정의 어려운 데이터데이터 레이크의 주요 대상, ML/AI 학습 데이터
7. 관리 방식비관리형 (Self-managed)자체 인프라/워크플로우/거버넌스를 직접 운영Hadoop, Airflow, Hive
관리형 (Managed)클라우드 공급자 또는 SaaS 기반의 데이터 레이크 플랫폼 제공AWS Lake Formation, Azure Synapse, GCP BigLake

실무 사용 예시

도메인사용 목적주요 데이터 유형구성 요소 예시기대 효과
금융리스크 분석, 감사 추적거래 로그, 시장 데이터, 뉴스, 트랜잭션 기록Kafka → S3/Parquet → Glue → Spark/Athena실시간 리스크 감지, 규제 준수 강화
헬스케어의료 진단, 환자 데이터 분석의료 영상, 센서 데이터, EHR(전자 건강 기록)S3 + Airflow + TensorFlow + SageMaker95% 이상 정확도의 예측 모델 구축, 의료 의사결정 지원
제조예측 정비, 품질 관리IoT 센서, 장비 로그, 유지보수 이력IoT → Kinesis/Flink → InfluxDB/S3 → Spark다운타임 40% 감소, 실시간 이상 탐지
이커머스사용자 행동 기반 추천, 마케팅 최적화클릭스트림, 구매 이력, 검색 로그Kafka → S3 → Athena/EMR + Spark MLlib개인화 추천, 전환율 30% 향상
리테일재고 최적화, 수요 예측판매 이력, 재고 상태, 고객 활동 로그S3 + Parquet + AWS Glue + Redshift Spectrum재고 비용 감소, 수요 기반 재고 관리
미디어콘텐츠 분석 및 검색 최적화동영상, 오디오, 사용자 시청 로그비정형 파일 (S3) + ML Indexing + OpenCV + Kafka시청률 예측 85%, 콘텐츠 자동 분류
IoT/스마트시티실시간 데이터 수집 및 분석센서 데이터, GPS, 교통 흐름, 기후 정보MQTT/Kafka → S3 + Time Series DB (InfluxDB, Timestream)교통 흐름 최적화, 에너지 소비 분석
AI/ML 플랫폼학습 데이터 통합 및 버전 관리정형/비정형 데이터, 이미지, 라벨링된 텍스트Data Lake + SageMaker + Feature Store + LakeFS재현 가능한 학습 파이프라인, 데이터 버전 관리 체계화
BI/리포팅대시보드 기반 리포트 생성 및 쿼리 수행트랜잭션, 고객 활동 로그, KPI 집계S3 + Athena + Quicksight/Looker비용 효율적 분석, 빠른 리포트 작성

활용 사례

사례 1: 글로벌 리테일 기업의 Data Lake 기반 분석 시스템

시스템 구성:

Workflow:

  1. 다양한 소스에서 원본 데이터를 실시간/배치로 수집
  2. Data Lake 에 원본 그대로 저장
  3. Glue 카탈로그로 메타데이터 관리
  4. Spark, Athena 등으로 분석 및 BI 리포팅
  5. 머신러닝 모델 학습 및 예측에 활용

Data Lake 의 역할:

Data Lake 유무에 따른 차이:

사례 2: 금융 데이터 감사 시스템

금융 기업에서 모든 고객의 거래 기록을 장기 보관하고, 필요한 경우 실시간으로 규제기관의 요청에 응답할 수 있도록 Data Lake 를 도입.

시스템 구성 및 흐름:

flowchart LR
  T[Transaction Logs] --> K(Kinesis)
  K --> RZ["Raw Zone (S3)"]
  RZ --> PR[Spark/Glue ETL]
  PR --> CZ["Curated Zone (Parquet)"]
  CZ --> Q[Athena Query Layer]
  Q --> GRC[감사 응답 시스템]
  CZ --> CAT[Glue Catalog]

차이점 비교

항목Data Lake 도입 전도입 후
데이터 보관 비용고비용 관계형 DB 장기 보관S3 기반 저비용 장기 저장
분석 응답 시간느림 (CSV 추출 후 분석)Athena 즉시 응답
스키마 관리문서화 미흡Glue Catalog 자동 관리
감사 응답수작업자동화 + 보안 추적 가능

사례 3: Netflix 의 콘텐츠 추천 시스템

시스템 구성

graph TB
    subgraph "Netflix 데이터 레이크 아키텍처"
        A[시청 이벤트] --> B[Amazon Kinesis]
        C[콘텐츠 메타데이터] --> D[Apache Kafka]
        E[사용자 프로필] --> F[AWS Lambda]
        
        B --> G[Amazon S3 - Raw Layer]
        D --> G
        F --> G
        
        G --> H[Apache Spark - Processing]
        H --> I[S3 - Curated Layer]
        
        I --> J[Apache Spark MLlib]
        J --> K[추천 모델]
        
        K --> L[Amazon ElastiCache]
        L --> M[실시간 추천 API]
        
        I --> N[Amazon Redshift]
        N --> O[BI 대시보드]
    end

Workflow

  1. 데이터 수집: 시청 이벤트, 평점, 검색 쿼리를 실시간 수집
  2. 원시 데이터 저장: S3 에 JSON 형태로 파티션별 저장
  3. 데이터 처리: Spark 를 통한 ETL 파이프라인 실행
  4. 모델 훈련: MLlib 기반 협업 필터링 및 딥러닝 모델
  5. 추천 서비스: ElastiCache 를 통한 실시간 추천 제공

데이터 레이크의 역할

데이터 레이크 유무에 따른 차이점

구분데이터 레이크 있음데이터 레이크 없음
데이터 처리 규모일일 20 억 건일일 1 억 건 한계
새 모델 배포 시간2-3 일2-3 주
스토리지 비용월 10 만 달러월 50 만 달러
데이터 형태 지원모든 형태 지원구조화 데이터만
A/B 테스트 속도실시간주간 단위

구현 예시

Python: 고객 데이터 처리

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
import boto3
import pandas as pd
from pyspark.sql import SparkSession
from pyspark.sql.functions import col, when, isnan, count
import logging
from datetime import datetime

class DataLakeManager:
    """
    데이터 레이크 관리를 위한 클래스
    주요 기능: 데이터 수집, 저장, 품질 검증, 카탈로그 관리
    """
    
    def __init__(self, bucket_name, region='us-east-1'):
        """
        데이터 레이크 매니저 초기화
        Args:
            bucket_name: S3 버킷 이름
            region: AWS 리전
        """
        self.bucket_name = bucket_name
        self.s3_client = boto3.client('s3', region_name=region)
        self.glue_client = boto3.client('glue', region_name=region)
        
        # Spark 세션 초기화 - 데이터 처리 엔진
        self.spark = SparkSession.builder \
            .appName("DataLakeProcessor") \
            .config("spark.sql.adaptive.enabled", "true") \
            .config("spark.sql.adaptive.coalescePartitions.enabled", "true") \
            .getOrCreate()
        
        # 로깅 설정 - 운영 모니터링을 위한 로그
        logging.basicConfig(level=logging.INFO)
        self.logger = logging.getLogger(__name__)
    
    def ingest_batch_data(self, source_path, destination_key, data_format='parquet'):
        """
        배치 데이터 수집 및 저장
        Args:
            source_path: 소스 데이터 경로
            destination_key: S3 저장 경로
            data_format: 데이터 형식 (parquet, json, csv)
        """
        try:
            # 데이터 읽기 - 다양한 형식 지원
            if data_format == 'parquet':
                df = self.spark.read.parquet(source_path)
            elif data_format == 'json':
                df = self.spark.read.json(source_path)
            else:  # CSV
                df = self.spark.read.option("header", "true").csv(source_path)
            
            # 데이터 품질 검증 - 결측치 및 중복 확인
            quality_metrics = self._validate_data_quality(df)
            self.logger.info(f"Data quality metrics: {quality_metrics}")
            
            # 메타데이터 추가 - 데이터 계보 추적을 위한 정보
            df_with_metadata = df.withColumn("ingestion_timestamp", 
                                           lit(datetime.now().isoformat()))
            
            # 파티션 기반 저장 - 성능 최적화를 위한 파티셔닝
            partition_column = self._determine_partition_column(df_with_metadata)
            
            # S3에 저장 - Raw 계층에 원시 데이터 저장
            s3_path = f"s3a://{self.bucket_name}/raw/{destination_key}"
            
            if partition_column:
                df_with_metadata.write.mode("append") \
                    .partitionBy(partition_column) \
                    .parquet(s3_path)
            else:
                df_with_metadata.write.mode("append").parquet(s3_path)
            
            # 메타데이터 카탈로그 업데이트
            self._update_glue_catalog(destination_key, df_with_metadata.schema)
            
            self.logger.info(f"Successfully ingested {df.count()} records to {s3_path}")
            
        except Exception as e:
            self.logger.error(f"Error ingesting data: {str(e)}")
            raise
    
    def _validate_data_quality(self, df):
        """
        데이터 품질 검증 함수
        Returns:
            dict: 품질 메트릭 정보
        """
        total_rows = df.count()
        
        # 컬럼별 결측치 계산
        null_counts = df.select([count(when(col(c).isNull() | isnan(col(c)), c)).alias(c) 
                               for c in df.columns]).collect()[0].asDict()
        
        # 중복 레코드 수 계산
        distinct_rows = df.distinct().count()
        duplicate_rows = total_rows - distinct_rows
        
        return {
            'total_rows': total_rows,
            'duplicate_rows': duplicate_rows,
            'null_counts': null_counts,
            'duplicate_percentage': (duplicate_rows / total_rows) * 100 if total_rows > 0 else 0
        }
    
    def _determine_partition_column(self, df):
        """
        최적의 파티션 컬럼 결정
        Returns:
            str: 파티션 컬럼명 또는 None
        """
        # 날짜/시간 컬럼 우선 선택
        date_columns = [col for col in df.columns 
                       if 'date' in col.lower() or 'time' in col.lower()]
        
        if date_columns:
            return date_columns[0]
        
        # 카디널리티가 적절한 범위의 컬럼 선택 (100-10000)
        for col_name in df.columns:
            if df.select(col_name).distinct().count() in range(100, 10000):
                return col_name
        
        return None
    
    def _update_glue_catalog(self, table_name, schema):
        """
        AWS Glue 카탈로그 업데이트 - 메타데이터 관리
        Args:
            table_name: 테이블명
            schema: 스키마 정보
        """
        try:
            # Spark 스키마를 Glue 스키마로 변환
            glue_columns = []
            for field in schema.fields:
                glue_columns.append({
                    'Name': field.name,
                    'Type': self._spark_to_glue_type(field.dataType)
                })
            
            # Glue 테이블 정의
            table_input = {
                'Name': table_name.replace('/', '_'),
                'StorageDescriptor': {
                    'Columns': glue_columns,
                    'Location': f"s3://{self.bucket_name}/raw/{table_name}/",
                    'InputFormat': 'org.apache.hadoop.mapred.TextInputFormat',
                    'OutputFormat': 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat',
                    'SerdeInfo': {
                        'SerializationLibrary': 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe'
                    }
                }
            }
            
            # 테이블 생성 또는 업데이트
            try:
                self.glue_client.create_table(
                    DatabaseName='data_lake_catalog',
                    TableInput=table_input
                )
            except self.glue_client.exceptions.AlreadyExistsException:
                self.glue_client.update_table(
                    DatabaseName='data_lake_catalog',
                    TableInput=table_input
                )
            
            self.logger.info(f"Updated Glue catalog for table: {table_name}")
            
        except Exception as e:
            self.logger.warning(f"Failed to update Glue catalog: {str(e)}")
    
    def _spark_to_glue_type(self, spark_type):
        """
        Spark 데이터 타입을 Glue 데이터 타입으로 변환
        """
        type_mapping = {
            'StringType': 'string',
            'IntegerType': 'int',
            'LongType': 'bigint',
            'DoubleType': 'double',
            'BooleanType': 'boolean',
            'TimestampType': 'timestamp'
        }
        return type_mapping.get(type(spark_type).__name__, 'string')
    
    def transform_data(self, source_table, target_path, transformation_rules):
        """
        데이터 변환 및 정제 - Curated 계층 생성
        Args:
            source_table: 원본 테이블명
            target_path: 변환된 데이터 저장 경로
            transformation_rules: 변환 규칙 딕셔너리
        """
        try:
            # 원시 데이터 읽기
            source_path = f"s3a://{self.bucket_name}/raw/{source_table}/"
            df = self.spark.read.parquet(source_path)
            
            # 변환 규칙 적용
            transformed_df = df
            
            # 컬럼 이름 정규화
            if 'column_mapping' in transformation_rules:
                for old_name, new_name in transformation_rules['column_mapping'].items():
                    transformed_df = transformed_df.withColumnRenamed(old_name, new_name)
            
            # 데이터 타입 변환
            if 'type_casting' in transformation_rules:
                for column, data_type in transformation_rules['type_casting'].items():
                    transformed_df = transformed_df.withColumn(column, col(column).cast(data_type))
            
            # 필터링 규칙 적용
            if 'filters' in transformation_rules:
                for filter_condition in transformation_rules['filters']:
                    transformed_df = transformed_df.filter(filter_condition)
            
            # 집계 규칙 적용
            if 'aggregations' in transformation_rules:
                group_by_cols = transformation_rules['aggregations']['group_by']
                agg_expressions = transformation_rules['aggregations']['expressions']
                transformed_df = transformed_df.groupBy(*group_by_cols).agg(*agg_expressions)
            
            # Curated 계층에 저장
            curated_path = f"s3a://{self.bucket_name}/curated/{target_path}/"
            transformed_df.write.mode("overwrite").parquet(curated_path)
            
            # 메타데이터 업데이트
            self._update_glue_catalog(f"curated_{target_path}", transformed_df.schema)
            
            self.logger.info(f"Successfully transformed and stored data to {curated_path}")
            
        except Exception as e:
            self.logger.error(f"Error transforming data: {str(e)}")
            raise
    
    def create_data_pipeline(self, pipeline_config):
        """
        데이터 파이프라인 생성 - ETL 워크플로우 자동화
        Args:
            pipeline_config: 파이프라인 설정 정보
        """
        try:
            for step in pipeline_config['steps']:
                if step['type'] == 'ingestion':
                    self.ingest_batch_data(
                        step['source_path'],
                        step['destination_key'],
                        step.get('format', 'parquet')
                    )
                elif step['type'] == 'transformation':
                    self.transform_data(
                        step['source_table'],
                        step['target_path'],
                        step['transformation_rules']
                    )
            
            self.logger.info("Data pipeline executed successfully")
            
        except Exception as e:
            self.logger.error(f"Pipeline execution failed: {str(e)}")
            raise

# 사용 예시
if __name__ == "__main__":
    # 데이터 레이크 매니저 초기화
    dl_manager = DataLakeManager(bucket_name="my-data-lake-bucket")
    
    # 파이프라인 설정 - 고객 데이터 처리 예시
    pipeline_config = {
        'steps': [
            {
                'type': 'ingestion',
                'source_path': '/data/customer_data.parquet',
                'destination_key': 'customer_data',
                'format': 'parquet'
            },
            {
                'type': 'transformation',
                'source_table': 'customer_data',
                'target_path': 'customer_insights',
                'transformation_rules': {
                    'column_mapping': {
                        'cust_id': 'customer_id',
                        'cust_name': 'customer_name'
                    },
                    'type_casting': {
                        'customer_id': 'string',
                        'age': 'integer'
                    },
                    'filters': ['age > 18', 'customer_name is not null'],
                    'aggregations': {
                        'group_by': ['age_group'],
                        'expressions': ['count(*).alias("customer_count")', 
                                      'avg("purchase_amount").alias("avg_purchase")']
                    }
                }
            }
        ]
    }
    
    # 파이프라인 실행
    dl_manager.create_data_pipeline(pipeline_config)

Python + AWS SDK

목적: 금융 거래 로그를 S3 에 저장하고, Glue Catalog 에 자동 등록

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
import boto3
import json
import datetime

# 거래 로그 예시
transaction = {
    "transaction_id": "TX123456",
    "user_id": "U789",
    "amount": 320.50,
    "currency": "USD",
    "timestamp": str(datetime.datetime.now())
}

# S3 저장
s3 = boto3.client('s3')
bucket = "banking-raw-zone"
key = f"transactions/{transaction['transaction_id']}.json"

s3.put_object(Bucket=bucket, Key=key, Body=json.dumps(transaction))
print("Raw transaction saved to S3.")

# Glue Catalog 자동 등록 예시
glue = boto3.client('glue')
glue.create_table(
    DatabaseName='finance_logs',
    TableInput={
        'Name': 'transactions',
        'StorageDescriptor': {
            'Columns': [
                {'Name': 'transaction_id', 'Type': 'string'},
                {'Name': 'user_id', 'Type': 'string'},
                {'Name': 'amount', 'Type': 'double'},
                {'Name': 'currency', 'Type': 'string'},
                {'Name': 'timestamp', 'Type': 'string'}
            ],
            'Location': f"s3://{bucket}/transactions/",
            'InputFormat': 'org.apache.hadoop.mapred.TextInputFormat',
            'OutputFormat': 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat',
            'SerdeInfo': {
                'SerializationLibrary': 'org.openx.data.jsonserde.JsonSerDe',
                'Parameters': {
                    'serialization.format': '1'
                }
            }
        },
        'TableType': 'EXTERNAL_TABLE'
    }
)
print("Glue Catalog 등록 완료.")

Python, AWS S3 + Glue + Athena)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
# AWS Boto3를 활용한 S3 데이터 적재 및 Athena 쿼리 예시

import boto3

# S3에 데이터 업로드
s3 = boto3.client('s3')
with open('data.csv', 'rb') as data:
    s3.upload_fileobj(data, 'my-datalake-bucket', 'raw/data.csv')

# Glue 카탈로그 등록 및 Athena 쿼리는 AWS 콘솔 또는 SDK로 실행
# Athena에서 쿼리 예시 (SQL)
# SELECT * FROM my_datalake.raw_data WHERE event_type = 'purchase';

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

카테고리고려사항설명 및 권장사항
아키텍처 설계계층형 Zone 구조Raw → Standardized → Curated → Sandbox 단계적 구성으로 가시성 및 관리성 확보
파티셔닝 전략날짜, 지역 등 기준 분할 → 쿼리 성능 향상 및 스토리지 비용 절감
컬럼형 파일 포맷 선택Parquet, ORC, Delta 등 → 고압축, 빠른 분석 최적화
운영 관리ETL/ELT 파이프라인 표준화dbt, Spark, Glue 등 사용으로 복잡도 최소화, 코드 재사용성 확보
스토리지 라이프사이클Intelligent Tiering, 자동 아카이빙 → 비용 최적화 전략
모니터링 및 가시성 확보CloudWatch, Grafana, DataDog 기반 대시보드 구축
데이터 거버넌스메타데이터 관리Apache Atlas, AWS Glue Catalog, DataHub 등으로 메타정보 통합 관리
계보 추적 및 품질 검증데이터 계보(lineage), 품질 룰 검증 자동화 → 신뢰도 확보
보안 및 규제접근 제어 및 감사 로깅RBAC + ABAC 혼합 정책, CloudTrailKMS 연계
데이터 분류 및 민감정보 보호Data Classification, 암호화 정책 자동 적용 필수
클라우드 최적화클라우드 서비스 연동IAM, S3, Glue, KMS, Lake Formation 등 클라우드 네이티브 기능 적극 활용
조직 운영팀 역량 및 역할 정의Data Engineer, Platform Architect, Governance 담당 역할 분리/명확화
단계적 확산 전략PoC → Pilot → Rollout 방식의 점진적 전개로 리스크 최소화

최적화하기 위한 고려사항 및 주의할 점

카테고리최적화 항목설명권장 방안 및 기술 예시
스토리지 최적화데이터 압축저장 공간 절약 및 I/O 최소화를 위한 압축 적용Snappy, Zstd, GZIP 등 압축 포맷 사용
파티셔닝쿼리 범위를 줄여 I/O 및 스캔 최소화날짜/지역/사용자 기준 파티셔닝
포맷 일관성포맷 불일치로 인한 성능 저하 방지전사 표준 포맷 정의 (예: Parquet + JSON)
라이프사이클 관리장기 미사용 데이터에 대한 자동 이전 처리S3 Lifecycle, HDFS TTL 적용
쿼리 성능 최적화인덱싱 & 컬럼 프루닝필요한 컬럼만 조회하고, 인덱스 기반 필터링으로 쿼리 속도 향상Column Pruning, 컬럼 인덱스 적용
Z-Ordering자주 필터링하는 컬럼 기준으로 물리적 정렬하여 스캔 효율화Delta Lake Z-Ordering 적용
캐싱반복 쿼리나 공통 쿼리에 대해 결과를 캐싱하여 응답 시간 개선Presto/Athena 캐시, Redis 캐시
처리 성능 및 자원 관리엔진 적합성 선택워크로드 유형별 최적의 엔진 선택Spark (배치), Flink (스트림), Presto (쿼리)
증분 처리중복 처리 방지 및 비용 절감을 위한 증분 로딩Watermark 기반 Incremental Load
스케일링 자동화처리량 증가에 따라 동적으로 리소스를 확장Kubernetes Horizontal Pod Autoscaler
비용 최적화인프라 비용 절감처리/저장 리소스의 비용 최적화스팟 인스턴스, EC2 Savings Plan
저장 비용 관리빈도에 따라 스토리지 클래스 변경S3 Infrequent Access, Glacier
데이터 품질실시간 품질 모니터링데이터의 정확성/정합성을 자동으로 점검Great Expectations, Data Quality DAG
품질 자동 검증정합성 체크, Null/이상치 검사 등 자동화ETL 중간 검증, 통계 기반 이상 탐지
운영 자동화 및 안정성파이프라인 자동화ETL/ELT/스트리밍 파이프라인을 자동화하여 운영 효율성 증대Apache Airflow, Dagster
거버넌스 및 정책 적용데이터 보안/품질 정책의 자동 적용정책 기반 접근 통제, 자동 거버넌스 룰
재해 복구 및 백업장애 복구 시간 최소화 및 데이터 손실 방지다중 리전 백업, RTO/RPO 기준 설정

Z-Ordering

대용량 데이터 쿼리 성능을 획기적으로 개선하기 위한 멀티 컬럼 정렬 최적화 기법이다. 특히 데이터 레이크 기반의 분석 환경, 예를 들어 Databricks Delta Lake, Apache Iceberg에서 매우 중요한 역할을 한다.

항목설명
정의다차원 컬럼들을 기반으로 **Z-curve (Morton order)**를 적용하여 데이터를 정렬하는 멀티 컬럼 정렬 최적화 기법
목적특정 컬럼들에 대한 필터 조건이 자주 사용되는 쿼리의 I/O 비용을 줄이고, 데이터 스캔 범위를 최소화
적용 대상주로 Delta Lake, Apache Iceberg, ClickHouse 등의 분석 시스템에서 사용됨
핵심 개념여러 컬럼의 값을 이진 표현으로 interleave(교차 혼합) 하여 Z 모양의 순서로 데이터 정렬

Z-Ordering 동작 원리:

성능 이점 및 실험 사례

실험 항목내용
성능 비교10 억 건 데이터셋에서 특정 컬럼 조건 필터 시, Z-Ordering 적용 후 쿼리 시간이 최대 60~80% 감소
I/O 효율Z-Ordering 을 적용하면 필터된 데이터만 읽을 수 있어 스캔되는 파일 수와 크기 대폭 감소
실사용 사례Databricks 기준: OPTIMIZE table ZORDER BY (user_id, event_time) 수행 후, user_id 조건 쿼리가 4 배 이상 빨라짐

주의사항 및 한계점

항목설명
과도한 Z-Ordering 사용너무 많은 컬럼에 대해 Z-Ordering 시, 오히려 정렬 효과가 떨어질 수 있음 (3~5 개 컬럼 이하 권장)
비용Z-Ordering 은 전체 파일을 재정렬하고 재작성하므로 배치 실행 비용이 높음
데이터 추가 시 재정렬 필요새로운 데이터가 들어오면 기존 정렬이 깨지므로 정기적인 OPTIMIZE 가 필요
비정형 필터에는 효과 미미Full Scan 성격의 쿼리나 LIKE, REGEXP 기반 쿼리에는 효과 없음

주제와 관련하여 주목할 내용

카테고리세부 주제기술/도구주요 설명 및 특징
아키텍처 특성스키마 온 리드-저장 시 스키마 미정, 읽을 때 해석 → 유연성/비정형 데이터 수용
오브젝트 스토리지S3, ADLS, GCS저비용, 무제한 확장성, 파일 기반 구조에 최적화
데이터 처리 엔진배치 처리Apache Spark대규모 병렬 처리, ML 지원 포함
스트림 처리Apache Flink, Kafka실시간/무한 스트림 처리, 이벤트 기반 분석 가능
파일 포맷컬럼형 저장Apache Parquet압축률 우수, 쿼리 성능 향상
스키마 진화Apache Avro동적 스키마 변경, 백워드 호환 지원
메타데이터 및 거버넌스메타데이터 관리Apache Atlas, Glue Catalog데이터 계보, 검색, 품질 통제
보안 및 권한 관리Apache Ranger사용자별 접근 제어 및 감사 로깅
레이크하우스 통합ACID 지원 스토리지Delta Lake, Iceberg, Hudi트랜잭션 처리, 시간여행, Merge 지원
클라우드 서비스AWSLake FormationIAM 통합, 자동 데이터 카탈로그
AzureData Lake Storage Gen2하둡 호환 + RBAC 통합 지원
GCPBigQuery서버리스 분석 플랫폼, ELT 통합
워크로드 유형다양한 분석 지원BI, ML, 실시간 쿼리 등유연한 데이터 활용: 정형/비정형/반정형 모두 가능
기술 트렌드스트리밍 데이터레이크Kafka + Iceberg실시간 수집과 히스토리 동시 저장 (Hybrid Architecture)

반드시 학습해야할 내용

대분류중분류세부 항목설명 및 학습 포인트
1. 데이터 아키텍처개념 비교Schema-on-Read vs Schema-on-Write저장 vs 조회 시점의 스키마 적용 전략. 유연성 vs 정합성 트레이드오프 분석
아키텍처 비교Data Lake vs Warehouse vs Lakehouse구조적 차이점, 사용 목적, 성능/정합성/비용 관점 비교
2. 스토리지 기술스토리지 유형Object Storage vs Block StorageS3/HDFS vs EBS 등의 차이점, 데이터 레이크 적합성 분석
저장 최적화Partitioning & Indexing파일 분할 및 색인을 통한 스캔 범위 최소화, 성능 향상 전략
3. 데이터 처리 기술배치 처리Apache Spark Fundamentals대용량 데이터 병렬 처리의 핵심, RDD/DataFrame 차이 학습
실시간 처리Kafka 기반 Stream Processing스트리밍 아키텍처, 이벤트 기반 처리 흐름 구성 방법
4. 파일 포맷컬럼 기반 포맷Parquet, ORC, Avro압축률, 쿼리 성능 최적화 관점에서의 포맷 비교
5. 분석 엔진쿼리 및 분석 도구Presto, Trino, Athena, Spark SQLObject Storage 직접 분석 가능 도구 비교 (속도, 비용, 유연성)
6. 거버넌스 및 카탈로그메타데이터 관리Glue, Hive Metastore, Apache Atlas메타데이터 수집, 분류, 계보 추적 자동화 기술
데이터 품질 관리Data Quality FrameworkNull 검사, 범위 제한, 중복 제거 등 품질 기준 정의
데이터 계보 추적Data Lineage데이터 흐름 추적, 규제 대응, 품질 이슈 분석 도구
7. 보안 및 접근 제어접근 제어 모델RBAC, ABAC사용자 역할 및 속성 기반 접근 통제 전략
민감 정보 보호Data Masking, Encryption at Rest개인정보 보호 및 규제 준수를 위한 기술 구현
8. 클라우드 환경AWS 기반 서비스S3, EMR, Glue, AthenaAWS 기반 전체 파이프라인 구성 흐름
Azure 기반 서비스Azure Data Lake Storage, Databricks, SynapseMS 생태계 기반 레이크 구성 요소
9. 운영 및 모니터링운영 모니터링Observability, Logging, Alerting데이터 레이크 파이프라인 운영 감시 및 경고 시스템 구성
자동화 및 배포IaC (Terraform), GitOps, Airflow인프라 자동화, 배치/스케줄링 워크플로우 구성 전략
10. 기타 필수 역량표준화 및 거버넌스 프레임워크Data Governance Principles, FAIR데이터 접근성, 품질, 재사용성 보장 위한 조직적 원칙
성능 벤치마크TPC-DS, TPC-H 테스트 분석포맷, 엔진, 인프라 성능 비교 기준 이해

용어 정리

카테고리용어정의 및 설명Data Lake 내 역할 및 의의
스토리지Object Storage파일, 이미지, 로그 등 비정형 대용량 데이터를 객체 단위로 저장하는 구조 (예: AWS S3, Azure Blob)확장성과 내구성이 뛰어나며, Data Lake 의 기반 스토리지 시스템
Partitioning데이터를 날짜, 지역, 카테고리 등 기준으로 분할 저장하는 기법쿼리 성능 향상, 스캔 범위 최소화, 비용 절감
아키텍처 및 기술Schema-on-Read저장 시 스키마를 적용하지 않고, 조회 시점에 스키마를 적용하는 유연한 접근 방식다양한 구조의 데이터를 유연하게 수용 가능, 반정형/비정형 데이터 분석에 적합
Schema-on-Write저장 시 스키마를 강제 적용하여 데이터의 정합성을 보장하는 방식강한 정형성 요구되는 시스템에서 활용, 데이터 품질 보장
Multi-tenancy하나의 시스템 자원을 다수의 사용자 (조직) 가 공유하여 사용하는 클라우드 아키텍처플랫폼형 서비스에서 리소스 효율성과 격리성 보장
데이터 처리ETL / ELTETL: 추출 → 변환 → 적재 / ELT: 추출 → 적재 → 변환 방식으로 데이터 파이프라인 구성데이터 정제 및 통합, 분석 목적에 따라 적절한 처리 방식 선택 필요
CDC (Change Data Capture)DB 변경사항을 실시간 추적하여 데이터 흐름에 반영하는 기술실시간 동기화 및 스트리밍 ETL 에 필수 요소
분석 및 쿼리 엔진Presto / Athena오브젝트 스토리지 상의 데이터를 직접 SQL 쿼리로 분석할 수 있는 서버리스 엔진ETL 없이 빠른 분석, 분석 비용 절감 및 셀프서비스 BI 가능
Parquet / ORC열 기반 저장 포맷으로, 압축률과 쿼리 성능에 최적화됨대규모 데이터 분석 시 스캔 효율성 및 저장 공간 최적화
거버넌스 및 보안Data Catalog데이터셋의 메타데이터, 계보, 품질, 위치, 사용 이력 등을 관리하고 탐색할 수 있는 시스템데이터 탐색성, 거버넌스, 데이터 거버넌스 체계의 핵심 축
Data Lineage데이터의 출처와 처리 과정을 추적할 수 있는 기능신뢰도 확보, 규제 대응, 품질 이슈 분석 가능
Data Stewardship데이터의 품질, 사용 규칙, 정책 등을 지속적으로 관리하는 책임자 역할조직 내 데이터 관리 책임 명확화, 데이터 품질 확보
RBAC역할 기반 접근 제어로, 사용자 역할에 따라 데이터 접근을 통제거버넌스 강화 및 권한 분리
ABAC속성 기반 접근 제어로, 사용자와 자원의 속성을 기준으로 세밀하게 접근 통제정교한 정책 적용, 민감 데이터 보호 강화
데이터 무결성ACID트랜잭션의 원자성, 일관성, 고립성, 지속성을 보장하는 데이터 처리 특성Delta Lake, Iceberg 등 Lakehouse 시스템에서 데이터 정합성 보장 요소로 사용

참고 및 출처