Great Expectations

Great Expectations 는 데이터가 기대한 모양대로 들어왔는지 검사해 주는 파이썬 라이브러리입니다. 「이 열에는 빈 값이 없어야 한다」 같은 약속을 코드로 적어 두면 데이터가 들어올 때마다 그 약속을 지키는지 확인합니다. 검사 결과는 사람이 읽을 수 있는 보고서로 남깁니다.

쉽고 빠른 이해

데이터에 거는 테스트를 적고 돌리는 도구입니다. 「주문 금액은 0 이상이어야 한다」를 적어 두면 금액이 음수인 행을 찾아 몇 개인지 알려 줍니다.

왜 이렇게 하나. 코드는 테스트로 지키지만 데이터는 코드 밖에서 들어옵니다. 데이터를 보내는 쪽 시스템이 형식을 바꾸거나 값을 빠뜨려도 파이프라인은 멈추지 않고 돕니다. 틀린 숫자는 보고서에 가서야 드러납니다.

어떻게 도나.

데이터에 거는 약속을 하나씩 적어 한 묶음으로 모읍니다.
파이프라인 중간에서 그 묶음으로 새로 들어온 데이터를 검사합니다.
결과를 보고 다음 단계를 멈추거나 알림을 보냅니다. 결과는 웹 페이지 보고서로도 남습니다.

대가. 설정할 부품이 여럿이라 처음 붙일 때 손이 갑니다. 데이터가 쌓인 뒤에 검사하므로 틀린 값을 들어오는 순간 막지는 못합니다. 약속의 기준값도 데이터가 바뀌면 사람이 고쳐야 합니다.

상세

이 절은 Great Expectations 가 풀려는 문제부터 봅니다. 이어서 데이터에 거는 약속 하나를 코드로 적어 돌려 봅니다. 그다음 그 약속을 묶어 자동으로 돌리는 부품들과 이 도구가 맡지 않는 일을 차례로 봅니다.

Great Expectations 는 데이터 품질을 검사하는 오픈 소스 파이썬 라이브러리입니다. 데이터 품질은 데이터가 쓰려는 목적에 맞게 올바른지를 말합니다. 주문 번호가 비어 있거나, 금액이 음수이거나, 어제 들어와야 할 행이 절반만 들어온 데이터는 품질이 낮습니다. 흔히 줄여서 GX 라고 부릅니다.

데이터에 거는 테스트

백엔드 개발자는 코드를 단위 테스트로 지킵니다. 함수에 값을 넣고 나온 값이 기대와 같은지 확인합니다. 코드를 고칠 때마다 테스트를 돌리므로 망가진 곳이 바로 드러납니다.

데이터는 이 그물에 걸리지 않습니다. 데이터는 다른 팀의 시스템이나 외부 업체에서 들어옵니다. 그래서 내 코드를 안 고쳐도 모양이 바뀝니다.

들어온 데이터는 파이프라인을 타고 흐릅니다. 파이프라인은 데이터를 꺼내고 바꾸고 싣는 단계를 차례로 이은 작업 흐름입니다. 데이터를 보내는 쪽 시스템이 금액 단위를 원에서 천 원으로 바꿔도 파이프라인은 오류 없이 돕니다.

이때 코드 테스트는 전부 통과합니다. 보고서 숫자만 틀립니다. 틀린 줄도 모른 채 며칠이 지나기도 합니다.

GX 는 테스트의 대상을 코드에서 데이터로 옮깁니다. 데이터가 지켜야 할 조건을 적어 둡니다. 데이터가 새로 들어올 때마다 그 조건으로 검사합니다. 조건이 깨지면 어느 열의 어떤 값이 몇 개 깨졌는지 알려 줍니다.

기대 — 데이터에 거는 약속 하나

GX 에서 데이터에 거는 조건 하나를 기대(Expectation)라고 부릅니다. 도구 이름이 여기서 왔습니다. 기대는 「무엇을 검사하라」만 적고 「어떻게 검사하라」는 적지 않습니다. 검사하는 방법은 GX 가 맡습니다.

기대는 이름만 읽어도 뜻이 드러나게 지어져 있습니다. 자주 쓰는 것을 몇 개 보면 이렇습니다.

기대	검사하는 것
`ExpectColumnValuesToNotBeNull`	이 열에 빈 값이 없다
`ExpectColumnValuesToBeUnique`	이 열의 값이 서로 겹치지 않는다
`ExpectColumnValuesToBeBetween`	이 열의 값이 정한 범위 안에 있다
`ExpectColumnValuesToBeInSet`	이 열의 값이 정한 목록 가운데 하나다
`ExpectColumnValuesToMatchRegex`	이 열의 값이 정한 정규 표현식에 맞는다
`ExpectTableRowCountToBeBetween`	표의 행 수가 정한 범위 안에 있다

표의 앞쪽 다섯은 열의 값 하나하나를 봅니다. 마지막 하나는 표 전체를 봅니다. 「어제 주문이 평소처럼 수만 건 들어왔나」 같은 검사가 이런 표 단위 기대로 적힙니다.

기대를 코드로 적고 돌리기

기대 하나를 적어 돌려 봅니다. 아래 데이터는 주문 네 건이고 그중 하나의 금액이 음수입니다.

데이터는 pandas 의 데이터프레임에 담았습니다. pandas 는 표 모양 데이터를 다루는 파이썬 라이브러리입니다. 데이터프레임은 그 라이브러리가 다루는 표 하나입니다.

Python

df = pd.DataFrame({
    "order_id": [101, 102, 103, 104],
    "amount": [5000, -300, 1200, 800],
})

이 데이터를 GX 에 넘기려면 몇 줄의 준비가 필요합니다. 지금은 준비를 마친 결과를 batch 라고 두겠습니다. 배치는 한 번에 검사할 데이터 한 덩어리입니다.

Python

exp = gx.expectations.ExpectColumnValuesToBeBetween(
    column="amount", min_value=0,
)
res = batch.validate(exp)
res.success                      # False
r = res.result
r["unexpected_count"]            # 1
r["unexpected_percent"]          # 25.0
r["partial_unexpected_list"]     # [-300]

첫 줄은 「amount 열의 값은 0 이상이어야 한다」는 기대를 만듭니다. max_value 를 안 적었으므로 위쪽 한계는 없습니다. batch.validate 가 이 기대로 배치를 검사하고 결과를 돌려줍니다.

결과의 success 는 기대를 지켰는지를 참과 거짓으로 알려 줍니다. result 에는 어긋난 값의 개수와 비율, 그리고 어긋난 값의 일부가 들어 있습니다. 네 행 가운데 -300 한 행이 어긋났으므로 개수는 1, 비율은 25 퍼센트입니다.

어긋남을 봐주는 비율 mostly

현실의 데이터에는 이상한 값이 몇 행씩 섞이기 쉽습니다. 한 행만 어긋나도 실패로 치면 검사가 매일 실패합니다. 그러면 사람들이 실패 알림을 무시하게 됩니다.

그래서 기대에는 mostly 를 붙일 수 있습니다. 전체 행 가운데 이 비율 이상이 조건을 지키면 통과로 칩니다. 앞의 데이터에 mostly=0.7 을 붙이면 네 행 중 세 행, 곧 75 퍼센트가 지키므로 통과합니다.

Python

exp = gx.expectations.ExpectColumnValuesToBeBetween(
    column="amount", min_value=0, mostly=0.7,
)
batch.validate(exp).success      # True

기준을 너무 느슨하게 잡으면 진짜 사고를 놓칩니다. 너무 빡빡하게 잡으면 알림이 소음이 됩니다. 이 비율은 데이터를 지켜보며 사람이 맞춰 가는 값입니다.

기대 모음과 검증 결과

데이터 하나에 기대 하나만 거는 일은 드뭅니다. 주문 표라면 주문 번호는 비지 않아야 하며 서로 겹치지 않아야 합니다. 금액은 0 이상이어야 합니다. 행 수는 평소 범위 안에 들어야 합니다.

이렇게 한 데이터에 거는 기대들을 모은 것을 기대 모음(Expectation Suite)이라고 부릅니다. 기대를 하나씩 따로 돌리지 않고 모음 하나로 데이터를 검사합니다.

기대 모음으로 배치를 검사하면 기대마다 결과가 하나씩 나옵니다. 모음 전체의 결과도 하나 더 나옵니다. 모음 전체는 기대가 하나라도 실패하면 실패입니다. 이 결과를 검증 결과(Validation Result)라고 부릅니다.

기대 모음은 JSON(JavaScript Object Notation) 파일로 저장할 수 있습니다. JSON 은 키와 값을 글자로 적는 형식입니다. 파일로 남으므로 코드처럼 저장소에 넣고 리뷰를 거쳐 고칩니다.

데이터를 가리키는 부품

GX 는 검사할 데이터를 세 단계로 가리킵니다. 어디에 있나, 그 안의 무엇인가, 그중 이번에 볼 것은 어디까지인가입니다. 단계마다 부품이 하나씩 있습니다.

데이터 소스(Data Source)는 데이터가 사는 곳입니다. pandas 데이터프레임, Apache Spark(여러 컴퓨터에 나눠 도는 처리 엔진), SQL(Structured Query Language) 데이터베이스가 대표적입니다.

데이터 에셋(Data Asset)은 그 소스 안의 검사 대상 하나입니다. 데이터베이스라면 표 하나, 파일 저장소라면 같은 모양의 파일 묶음 하나가 에셋입니다.

배치 정의(Batch Definition)는 그 에셋을 어떻게 잘라 배치로 만들지 정합니다. 에셋 전부를 한 배치로 볼 수도 있습니다. 날짜별로 잘라 어제 들어온 몫만 볼 수도 있습니다.

SQL 데이터베이스를 검사할 때 GX 는 기대를 SQL 질의로 바꿔 데이터베이스 안에서 돌립니다. 행을 전부 파이썬으로 꺼내 오지 않습니다. 개수와 비율만 받아 와서 판정합니다. 그래서 데이터 웨어하우스(분석에 쓸 데이터를 한곳에 모아 두는 큰 데이터베이스)에 쌓인 큰 표도 검사할 수 있습니다.

체크포인트와 액션

검사는 파이프라인 안에서 자동으로 돌아야 쓸모가 있습니다. GX 에서 그 일을 맡는 부품이 체크포인트(Checkpoint)입니다. 체크포인트는 「이 배치를 이 기대 모음으로 검사하라」를 여럿 묶어 한 번에 돌립니다.

체크포인트에는 액션(Action)을 붙입니다. 액션은 검사가 끝난 뒤 할 일입니다.

흔히 붙는 액션은 셋입니다. 결과를 저장합니다. 보고서를 새로 만듭니다. 실패하면 슬랙(Slack) 같은 메신저로 알림을 보냅니다.

체크포인트는 대개 Apache Airflow 같은 작업 순서 도구의 한 단계로 들어갑니다. 들어온 데이터를 싣는 단계와 그 데이터로 계산하는 단계 사이에 끼웁니다. 검사가 실패하면 뒤 단계를 돌리지 않아 틀린 데이터가 보고서까지 흘러가지 않습니다.

flowchart TD
    A["들어온 데이터를 싣는다"] --> B["체크포인트가 기대 모음으로 검사한다"]
    B -->|언제나| E["검증 결과를 저장하고 보고서를 새로 만든다"]
    B -->|통과| C["데이터로 계산해 보고서 표를 만든다"]
    B -->|실패| D["뒤 단계를 멈추고 알림을 보낸다"]

체크포인트는 통과든 실패든 결과를 남깁니다. 실패일 때만 뒤 단계가 멈춥니다.

데이터 문서

GX 는 기대 모음과 검증 결과로 HTML(HyperText Markup Language) 페이지를 만듭니다. 이 페이지 묶음을 데이터 문서(Data Docs)라고 부릅니다. HTML 은 웹 브라우저가 읽는 문서 형식입니다.

데이터 문서에는 이 데이터에 어떤 기대가 걸려 있는지가 사람 말에 가깝게 적힙니다. 날마다 어느 기대가 통과했고 어느 기대가 몇 행에서 어긋났는지도 남습니다. 코드를 안 읽는 분석가나 기획자도 이 페이지로 데이터의 상태를 봅니다.

그래서 기대 모음은 검사 규칙이자 데이터 설명서 노릇도 합니다. 「이 표의 금액은 0 이상이다」라는 기대는 그 표를 처음 보는 사람에게 금액 열의 뜻을 알려 줍니다.

데이터 컨텍스트

지금까지의 부품을 한데 담는 것이 데이터 컨텍스트(Data Context)입니다. 데이터 소스, 기대 모음, 체크포인트, 검증 결과를 어디에 두고 어떻게 불러올지를 컨텍스트가 압니다. GX 코드는 대개 gx.get_context() 로 컨텍스트를 얻는 데서 시작합니다.

flowchart TD
    subgraph 컨텍스트["데이터 컨텍스트"]
        S["데이터 소스"] --> AS["데이터 에셋"]
        AS --> BD["배치 정의"]
        SU["기대 모음"]
        CP["체크포인트"]
        VR["검증 결과"]
    end
    BD --> CP
    SU --> CP
    CP --> VR

데이터 소스·데이터 에셋·배치 정의가 「무엇을 검사하나」를 가리킵니다. 기대 모음은 「무엇을 지켜야 하나」를 적습니다. 체크포인트가 둘을 받아 검사하고 검증 결과를 남깁니다.