Apache Atlas와 Great Expectations로 구축하는 데이터 거버넌스 운영 체계
Apache Atlas의 메타데이터·라인리지 관리와 Great Expectations 품질 검증을 파이프라인, 정책, 감사 체계에 통합하는 방법
2026-08-14 · 최초 발행 2024-04-29
데이터가 적재된 뒤에야 드러나는 문제를 줄이려면
데이터 거버넌스 고도화는 카탈로그를 구축하거나 품질 테스트를 추가하는 일로 끝나지 않는다. 데이터 라인리지, 분류, 정책, 품질 규칙을 코드와 파이프라인에 연결해야 한다. 이 연결이 있어야 신뢰도, 준법, 생산성을 함께 다룰 수 있다.
Apache Atlas는 데이터 자산의 메타데이터, 스키마, 라인리지, 분류 체계를 중앙에서 관리하는 기반이 된다. 엔터티 모델과 분류, 용어집, 라인리지 그래프를 제공한다. Great Expectations는 데이터 적합성 검증을 규칙 기반으로 자동화한다. Expectation as Code, Data Docs, 파이프라인 게이팅을 통해 품질 규칙을 실행 가능한 운영 단위로 만든다.
통합 구조에서는 파이프라인 실행 뒤 품질을 검증하고, 검증을 통과한 데이터를 커밋한 다음 메타데이터를 동기화한다. 이어서 분류와 정책을 집행한다. 이 흐름은 변경 영향도 분석과 규정 준수 증적을 자동으로 축적하는 기반이 된다.
메타데이터와 품질 검증이 만나는 지점
Atlas에서는 테이블, 컬럼, 프로세스 같은 엔터티 타입을 정의하고 인제스트를 자동화한다. Hive, Spark, DBT, HBase 등의 후크와 커넥터를 활용할 수 있다. 라인리지 그래프는 스키마 변화가 발생했을 때 종속성을 파악하고, 영향도 분석과 감사 추적에 사용된다.
Great Expectations에서는 스키마, 범위, 유니크니스, 외래키 등의 규칙을 코드로 선언한다. 테스트 스위트는 재사용과 버전관리가 가능하다. 체크포인트와 액션을 이용하면 검증 결과에 따라 게이팅, 알림, 문서 생성, 스토리지 업로드를 자동화할 수 있다.
분류와 접근 제어도 이 흐름에 포함된다. Atlas의 PII, PHI 같은 분류를 용어집과 연결하면 민감도별 등급과 정책 라우팅의 근거가 생긴다. Apache Ranger 또는 통합 IAM과 연결하면 태그 기반 접근 제어(TBAC)를 집행하고, 정책 추론과 계정 권한 최소화를 지원할 수 있다.
Airflow, Argo, Databricks Jobs 같은 오케스트레이터에서는 품질 검증을 후속 작업의 게이트로 둔다. 검증에 통과하면 다음 태스크를 진행하고, 실패하면 롤백 또는 격리한다. Prometheus, Grafana, Slack, Webhook으로 메트릭과 알림을 표준화하면 데이터 SLA와 SLO를 함께 모니터링할 수 있다.
데이터 커밋과 카탈로그 갱신의 순서
데이터 커밋을 먼저 완료한 뒤 메타데이터 인제스트를 실행해야 한다. 커밋에 실패한 데이터의 메타데이터가 카탈로그에 반영되지 않도록 막기 위해서다. 인제스트는 idempotency를 보장하고, 재시도 시에는 중복 엔터티를 병합하는 전략이 필요하다.
| 관점 | Apache Atlas | Great Expectations |
|---|---|---|
| 성능 | 메타데이터 그래프 질의 최적화와 캐시 활용이 필요하다. | 데이터 샘플 또는 배치 검증은 병렬화로 처리량을 확보한다. |
| 확장성 | HA(Active-Active)+Kafka 백플레인 확장이 가능하다. | Spark, SQL, 파일 기반의 다중 실행 백엔드로 확장할 수 있다. |
| 일관성 | 커밋 이후 인제스트와 엄격한 타입 스키마 검증을 적용한다. | 고정 버전의 Expectation Suite로 재현성을 보장한다. |
| 안정성 | 메타스토어 백업·복구와 트랜잭션 로그 관리가 필요하다. | 실패 격리, 재시도, 퀘런틴 패턴으로 데이터를 보호한다. |
| 운영 편의 | UI, REST, CLI와 용어집 워크플로우를 제공한다. | Data Docs, 체크포인트, CI 통합으로 운영을 단순화한다. |
파이프라인에 통합할 때 정할 기준
먼저 소스, 변환, 소비 레이어의 메타데이터 경계를 정한다. 엔터티 타입과 명명 규칙을 수립하고, 분류 체계와 용어집, 태그 기반 접근 제어의 정책 모델을 설계한다.
Atlas는 2.x HA 구성, 외부 RDBMS 메타저장소, Kafka/ZooKeeper 클러스터를 기준으로 구성할 수 있다. Kerberos, Sentry, Ranger를 연계하고 Hive, Spark, Presto, DBT 후크 또는 커넥터를 설치한다. 초기 벌크 스캔과 주기적 동기화 작업도 함께 설정한다.
Great Expectations에는 Expectation Suite의 표준 템플릿을 두고 스키마, 범위, 유니크니스, 참조무결성을 최소 기준으로 정한다. 체크포인트와 액션은 실패 시 롤백 또는 격리하고, 성공 시 Data Docs 게시와 메트릭 전송을 수행하도록 구성한다.
오케스트레이터에서는 검증 태스크가 적재 커밋 태스크보다 앞서야 한다. 재시도, 타임아웃, 서킷브레이커 정책을 적용하고 SLA 위반 시의 에스컬레이션 경로를 정의한다. 메타데이터 변동 알림과 품질 메트릭은 통합 대시보드에 모으고, 감사 로그 보존, 용어집 변경 승인, 데이터 스튜어드의 책임 구분을 운영 절차에 포함한다.
Great Expectations 검증과 체크포인트
전제조건은 다음과 같다.
- Python 3.10+, great_expectations 0.18+ 또는 GX 1.0+ (최신 정보 확인 필요)
- Apache Spark 또는 Pandas 환경 가정, S3/DBFS/GCS 등 파일 스토리지 접근 가능
- Apache Atlas 2.x, 인증(기본/Kerberos) 설정 완료, Atlas REST 접근 가능
# python -m pip install great_expectations pandas pyarrow
import pandas as pd
import great_expectations as ge
from great_expectations.checkpoint import SimpleCheckpoint
from great_expectations.data_context import FileDataContext
# 샘플 데이터프레임
df = pd.DataFrame({
"id": [1, 2, 3, 3],
"amount": [10.5, 20.0, 0.0, -5.0],
"country": ["KR", "US", "DE", None],
})
# Data Context 초기화(로컬 디렉터리)
context = FileDataContext.create(project_root_dir="./gx_ctx")
# Expectation Suite 생성
suite_name = "orders_basic_rules"
suite = context.add_or_update_expectation_suite(expectation_suite_name=suite_name)
gdf = ge.from_pandas(df)
gdf.expect_column_values_to_not_be_null("id")
gdf.expect_column_values_to_be_unique("id")
gdf.expect_column_values_to_be_between("amount", min_value=0)
gdf.expect_column_values_to_not_be_null("country")
# 검증 결과 저장
batch_kwargs = {"datasource": "pandas", "dataframe": df}
validator = context.get_validator(
batch=ge.dataset.PandasDataset(df),
expectation_suite=suite,
)
results = validator.validate(result_format="SUMMARY")
# 체크포인트 실행(실패 시 예외)
checkpoint = SimpleCheckpoint(
name="orders_checkpoint",
data_context=context,
validations=[{"batch_request": batch_kwargs, "expectation_suite_name": suite_name}],
)
checkpoint_result = checkpoint.run()
# Data Docs 생성
context.build_data_docs()
print("Validation success:", checkpoint_result.success)
검증에 실패하면 파이썬 예외가 발생한다. 오케스트레이터는 이를 태스크 실패로 감지해 격리 또는 롤백 처리에 연결할 수 있다.
Atlas 분류를 테이블 엔터티에 연결하기
# 분류(PII) 생성
curl -u admin:admin -H "Content-Type: application/json" -X POST \
http://atlas-host:21000/api/atlas/v2/types/typedefs \
-d '{
"classificationDefs": [{
"category": "CLASSIFICATION",
"name": "PII",
"attributeDefs": []
}]
}'
# 특정 테이블 엔터티에 PII 태깅
# 참고: typeName=hive_table, qualifiedName 규칙은 환경별 상이(예: db.table@cluster)
curl -u admin:admin -H "Content-Type: application/json" -X POST \
http://atlas-host:21000/api/atlas/v2/entity/bulk/classification \
-d '{
"classification": {"typeName": "PII"},
"entityGuids": ["<table-entity-guid>"]
}'
운영에서는 글로서리 용어인 “Customer_ID”와 PII 분류를 연결하고, 정책 엔진인 Ranger와의 태그 동기화를 활성화할 수 있다.
데이터 제품별로 달라지는 운영 방식
금융권 개인정보 보호에서는 Atlas 분류로 PII 컬럼을 태깅하고 Ranger 태그 정책으로 마스킹과 열 수준 차단을 적용한다. Great Expectations는 입력 데이터의 누락과 이상을 검증하며, 문제가 발견되면 적재를 차단하고 격리한다.
제조 IoT 데이터 파이프라인에서는 스트리밍과 배치가 결합된 환경에서 Great Expectations의 기본 통계 기반 이상치 탐지를 사용한다. 임계치를 초과하면 경보를 발생시키고, Atlas 라인리지로 센서부터 집계, 대시보드까지의 영향을 추적한다.
데이터 마트의 스키마 변경은 Atlas 영향도 분석으로 다운스트림 리포트 영향을 먼저 확인한다. Great Expectations의 스키마 테스트로 nullable과 타입 변경을 검증하고, 실패하면 자동 롤백한다.
셀프서비스 분석 환경에서는 카탈로그 검색과 Data Docs 링크를 함께 제공하고 신뢰도 점수를 기반으로 데이터셋을 추천할 수 있다. 스튜어드 승인 워크플로우는 용어집의 일관성을 유지하는 역할을 한다.
운영 지표와 관리상의 선택
이 체계를 적용하면 데이터 탐색·발견 시간을 3060% 단축하고 중복 데이터셋을 2040% 줄일 수 있다. 품질 이슈 사전 검출률은 5080% 향상되고 배포 실패율은 2035% 감소한다. 준법 감사 대응 시간은 50~70% 단축되며, 라인리지 기반 영향 분석 시간은 60% 이상 단축된다.
정성적으로는 데이터 신뢰도와 투명성이 높아지고 거버넌스 증적이 자동으로 축적된다. 스튜어드, 엔지니어, 애널리스트의 역할 구분이 명확해지며, 변경과 위험을 관리하는 방식도 체계화된다.
보안 측면에서는 Kerberos, TLS, Ranger 연동과 서비스 간 토큰 만료·재발급 자동화가 필요하다. 데이터 위치 기반 정책보다 태그 우선 정책을 설계하면 유지보수성을 높일 수 있다.
아키텍처에서는 Atlas 메타스토어의 외부 RDBMS 이중화와 Kafka HA 구성을 고려하고, 라인리지 이벤트 적체를 모니터링해야 한다. Great Expectations는 검증 비용과 커버리지 사이의 트레이드오프가 있으므로 샘플링, 임계치 조정, 증분 검증을 도입한다.
Expectation as Code에는 PR 리뷰 프로세스를 두어 비가역적 규칙 변경을 막는다. 카탈로그 품질 KPI인 적시성, 완전성, 정확성과 데이터 품질 KPI도 연계해 관리한다. 파일럿은 핵심 도메인과 주요 파이프라인 2~3개로 범위를 명확히 잡고, KPI를 정의한 뒤 단계적으로 확장한다. 제품과 오픈소스의 버전·기능 변경 주기가 빠르므로 릴리스 노트 기반의 “최신 정보 확인 필요” 절차를 운영에 포함한다.