# Great Expectations

## 1. 개요
**Great Expectations(GE)**는 데이터 파이프라인의 신뢰성을 보장하기 위해 설계된 오픈소스 파이썬 라이브러리로, 데이터의 품질을 정의하고 검증하며 문서화하는 프레임워크이다.

현대적인 데이터 엔지니어링 환경에서 데이터 품질 관리(Data Quality Control)는 매우 중요하다. Great Expectations는 소프트웨어 공학의 **유닛 테스트(Unit Test)** 개념을 데이터에 도입하여, 데이터가 기대하는 형태와 값의 범위를 유지하고 있는지 자동으로 검증하는 '데이터 유닛 테스트' 환경을 제공한다. 이를 통해 데이터 파이프라인 상에서 발생하는 데이터 드리프트(Data Drift, 시간이 지남에 따라 데이터의 통계적 특성이 변하는 현상)나 스키마 변경으로 인한 오류를 조기에 발견할 수 있다.

## 2. 설치 및 초기 설정
Great Expectations는 파이썬 환경에서 패키지 관리자를 통해 쉽게 설치할 수 있다.

### 2.1 설치 방법
```bash
pip install great_expectations
```

### 2.2 초기 설정 가이드
과거에는 CLI 기반의 `great_expectations init` 명령어를 통해 설정 파일(`great_expectations.yml`)과 폴더 구조를 생성하는 방식을 사용했으나, **최신 버전에서는 코드 기반 설정(Fluent API) 방식이 권장됩니다.**

기존 CLI 방식의 구조는 다음과 같습니다:
- `gx/`: 설정 파일, Expectation Suite, Validation 결과 및 Data Docs가 저장되는 메인 디렉토리.
- `great_expectations.yml`: 데이터 소스 연결 정보 및 전역 설정이 포함된 YAML 파일.

## 3. 핵심 동작 원리
Great Expectations의 핵심은 "데이터가 어떠해야 한다"라는 **기대치(Expectation)**를 정의하고, 이를 실제 데이터에 적용하여 성공/실패 여부를 판별하는 것이다.

### 3.1 검증 파이프라인 흐름
1. **Expectation Suite 정의**: 검증하고자 하는 규칙들의 집합을 생성한다.
2. **Checkpoint 실행**: 특정 데이터 소스와 Expectation Suite를 연결하여 검증 프로세스를 트리거한다.
3. **Validation Operator 작동**: 정의된 규칙을 데이터에 적용하여 각 항목의 통과 여부를 계산한다.
4. **Validation Result 생성**: 검증 결과(성공 횟수, 실패 횟수, 기대값 vs 실제값)를 기록한다.

### 3.2 주요 구성 요소 비교
| 구성 요소 | 역할 | 설명 |
| :--- | :--- | :--- |
| **Expectation** | 검증 규칙 | `expect_column_values_to_not_be_null`과 같이 개별 데이터 품질 규칙을 정의함 |
| **Expectation Suite** | 규칙 집합 | 특정 테이블이나 데이터셋에 적용할 여러 Expectation들의 묶음 |
| **Checkpoint** | 실행 제어기 | 어떤 데이터 소스를 어떤 Suite로 검증할지 정의하고 실행하는 워크플로우 단위 |
| **Validation Result** | 검증 결과 | 실행 후 생성되는 상세 리포트로, 어떤 규칙이 실패했는지에 대한 메타데이터 포함 |

## 4. 주요 기능 및 Expectation 종류
GE는 수백 가지의 내장 Expectation을 제공하며, 사용자는 필요에 따라 커스텀 Expectation을 생성할 수 있다.

### 4.1 Expectation 라이브러리 유형
- **값의 범위 및 분포**: 컬럼의 값이 특정 범위 내에 있는지, 혹은 특정 분포를 따르는지 검증한다.
- **데이터 타입 및 형식**: 정수, 문자열, 날짜 형식 등 스키마 일치 여부를 확인한다.
- **Null 값 및 유일성**: 필수 값의 누락 여부(Null)나 기본키(PK)의 중복 여부를 검증한다.
- **집합 및 포함 관계**: 값이 미리 정의된 허용 리스트(Set) 내에 존재하는지 확인한다.

### 4.2 대표적인 API 사용 예시
```python
# 본 예제는 Fluent API(V3+) 기준입니다.
import great_expectations as gx

# 컨텍스트 생성 및 데이터 소스 연결
context = gx.get_context()
datasource = context.sources.add_pandas()
asset = datasource.add_csv_asset(filepath_or_buffer="data.csv")

# Validator 생성
validator = context.get_validator(batch_request=asset.build_batch_request(), expectation_suite_name="my_suite")

# 1. 컬럼 값이 특정 범위 내에 있는지 검증
validator.expect_column_values_to_be_between("age", min_value=0, max_value=120)

# 2. 컬럼에 Null 값이 없는지 검증
validator.expect_column_values_to_not_be_null("user_id")

# 3. 컬럼 값이 특정 리스트에 포함되는지 검증
validator.expect_column_values_to_be_in_set("status", ["active", "inactive", "pending"])

# 결과 저장
validator.save_expectation_suite(expectation_suite_name="my_suite")
```

## 5. 워크플로우 및 설정 방법
전체적인 데이터 검증 프로세스는 다음과 같은 단계로 진행된다.

### 5.1 데이터 소스 연결 및 계층 구조
GE는 데이터를 효율적으로 관리하기 위해 다음과 같은 계층 구조를 가진다:
**Datasource $\rightarrow$ Data Asset $\rightarrow$ Batch**
- **Datasource**: 데이터가 저장된 물리적 위치(DB, S3, Local 등)에 대한 연결 정보.
- **Data Asset**: Datasource 내의 특정 테이블, 뷰, 혹은 파일.
- **Batch**: Asset 내에서 실제로 검증 대상이 되는 데이터의 특정 부분 집합(예: 특정 날짜의 파티션).

**다양한 데이터 소스 연결 예시:**
```python
# 1. Pandas 연결
datasource_pandas = context.sources.add_pandas()

# 2. SQL Database 연결 (PostgreSQL, Snowflake, BigQuery 등)
datasource_sql = context.sources.add_sql_datasource(
    name="my_sql_datasource", 
    connection_string="postgresql+psycopg2://user:password@localhost:5432/mydb"
)
asset_sql = datasource_sql.add_table_asset(name="users_table", table_name="users")
```

### 5.2 전체 프로세스 단계
1. **Datasources 연결**: 위에서 설명한 계층 구조에 따라 데이터 소스를 연결한다.
2. **Expectation Suite 생성**: 검증할 컬럼과 규칙을 정의한다. (GE의 'Interactive Profiler'를 사용하면 기존 데이터를 분석해 자동으로 추천 규칙을 생성할 수 있다.)
3. **Checkpoint 설정**: 검증 주기, 알림 설정, 결과 저장 경로 등을 설정한 Checkpoint를 생성한다.
4. **검증 실행**: 파이프라인 내에서 Checkpoint를 호출하여 데이터를 검증한다.
5. **결과 확인 및 조치**: 생성된 Validation Result를 바탕으로 데이터 파이프라인을 중단시키거나 담당자에게 알림을 보낸다.

## 6. 데이터 문서화 및 리포팅 (Data Docs)
**Data Docs**는 검증 결과와 정의를 HTML 기반의 시각적 리포트로 자동 생성하는 기능이다.

- **특징**: 기술적인 코드 형태가 아닌 시각적인 리포트를 제공하므로, 데이터 엔지니어뿐만 아니라 데이터 분석가, 이해관계자가 데이터 품질 상태를 쉽게 파악할 수 있다.
- **커뮤니케이션 개선**: "데이터가 잘못되었다"라는 모호한 보고 대신, "특정 컬럼의 Null 비율이 5%를 초과하여 검증에 실패했다"라는 객관적인 근거를 제시함으로써 팀 간의 소통 비용을 줄인다.

**생성 및 확인 방법:**
```python
# Data Docs 빌드 및 실행
context.build_data_docs()
context.open_data_docs() # 로컬 환경에서 브라우저로 리포트 열기
```
빌드된 HTML 파일은 설정된 저장소(로컬 디렉토리, S3, GCS 등)에 저장되어 정적 웹사이트 형태로 호스팅할 수 있다.

## 7. 에코시스템 통합 및 활용
GE는 독립적인 도구가 아니라 기존 데이터 스택에 통합되어 자동화된 품질 게이트(Quality Gate) 역할을 수행한다.

### 7.1 통합 도구
- **오케스트레이션**: Airflow, Prefect, Dagster와 결합하여 ETL 프로세스 중간에 검증 단계를 삽입한다.
- **컴퓨팅 엔진**: Pandas(소규모), PySpark(대규모 분산 처리)를 모두 지원한다.

### 7.2 Airflow 통합 예시
```python
from airflow import DAG
from great_expectations_provider.operators.great_expectations import GreatExpectationsOperator
from datetime import datetime

with DAG(dag_id="data_quality_check", start_date=datetime(2023, 1, 1), schedule_interval="@daily") as dag:
    
    # GE Checkpoint를 실행하는 Operator
    validate_data = GreatExpectationsOperator(
        task_id="validate_user_data",
        checkpoint_name="user_data_checkpoint",
        fail_task_on_validation_failure=True # 검증 실패 시 DAG 태스크 실패 처리
    )
```

## 8. 타 데이터 검증 도구와의 비교 분석
| 비교 항목 | Great Expectations | dbt Tests | Deequ (AWS) |
| :--- | :--- | :--- | :--- |
| **주요 목적** | 범용 데이터 품질 프레임워크 | SQL 변환 모델 검증 | Spark 기반 대규모 데이터 검증 |
| **검증 방식** | Python API 기반 (선언적) | YAML 설정 기반 (SQL 중심) | Scala/Java API 기반 |
| **문서화** | 자동 HTML 리포트 (Data Docs) | 기본 로그 및 dbt docs | 별도 리포팅 도구 필요 |
| **적용 시점** | 파이프라인 전 과정 (Ingestion → Load) | 변환 단계 (Transformation) | 대규모 데이터 처리 단계 |
| **학습 곡선** | 중간 (Python 숙련도 필요) | 낮음 (SQL 숙련도 필요) | 높음 (Spark/Scala 필요) |

## 9. 실제 적용 사례 (Use Case)
### 사례 1: 이커머스 주문 데이터 파이프라인
- **문제**: 외부 API를 통해 수집되는 주문 데이터의 가격(price) 컬럼에 간혹 음수 값이 들어와 매출 집계 오류 발생.
- **해결**: `expect_column_values_to_be_between("price", min_value=0)` 규칙을 적용한 Checkpoint를 수집 단계 직후에 배치.
- **결과**: 음수 값이 발견될 경우 즉시 슬랙(Slack) 알림을 보내고, 해당 배치를 격리(Quarantine)하여 집계 오류를 원천 차단.

### 사례 2: 머신러닝 모델 피처 스토어(Feature Store)
- **문제**: 모델 학습에 사용되는 피처의 분포가 갑자기 변하여 모델 성능이 저하되는 데이터 드리프트 발생.
- **해결**: `expect_column_kl_divergence_to_be_less_than` (KL 발산도 검증) 등을 통해 학습 데이터와 서빙 데이터의 통계적 분포 차이를 상시 모니터링.
- **결과**: 분포 변화 감지 시 모델 재학습(Retraining) 파이프라인을 자동으로 트리거하는 체계 구축.

## 10. 고려사항 및 한계
Great Expectations는 매우 강력한 도구이지만, 도입 시 다음과 같은 사항을 고려해야 한다.

- **설정 오버헤드**: 초기 Datasource 설정 및 Expectation Suite 정의에 상당한 시간이 소요될 수 있다. 모든 컬럼에 대해 규칙을 만들기보다 핵심 지표(KPI)와 관련된 중요 컬럼 위주로 우선 적용하는 것이 효율적이다.
- **성능 저하**: 대량의 데이터셋에 대해 복잡한 Expectation을 전수 조사 방식으로 실행할 경우, 검증 단계에서 심각한 성능 저하가 발생할 수 있다.
- **최적화 팁**: 
    - 데이터 규모가 매우 클 경우 전수 조사 대신 **샘플링 검증**을 권장한다.
    - 컴퓨팅 부하를 줄이기 위해 Pandas보다는 **PySpark**나 **SQL 엔진(Push-down)**을 활용하여 데이터베이스 단에서 검증이 수행되도록 설정하는 것이 좋다.