개요

Data Observability 모니터는 계절성, 추세 및 사용자 피드백을 학습하는 이상 탐지를 사용하여 지연된 데이터, 불완전한 로드 및 예기치 않은 값의 변경이 다운스트림 대시보드, AI 애플리케이션 또는 비즈니스 결정에 영향을 미치기 전에 이를 감지합니다. 이러한 모니터는 엔드투엔드 데이터 및 코드 계보와 결합되어 있으며, 팀이 문제를 조기에 탐지하고, 다운스트림 영향을 평가하며, 적절한 담당자에게 전달하도록 돕습니다.

Data Observability 모니터는 다음 메트릭 유형을 지원합니다.

테이블 수준 메트릭 유형:

열 수준 메트릭 유형:

Datadog은 가능할 경우 웨어하우스 시스템 메타데이터(예: INFORMATION_SCHEMA)에서 행 개수 및 신선도와 같은 메트릭을 수집합니다. 웨어하우스에 쿼리를 실행하지 않아도 되므로 컴퓨팅 비용이 절감됩니다. 모든 웨어하우스가 시스템 메타데이터를 노출하는 것은 아닙니다. 시스템 메타데이터에서 수집할 수 없는 메트릭의 경우, 모니터가 웨어하우스에 직접 쿼리를 실행하여 값을 계산합니다.

Data Observability 모니터를 사용하려면 최소 하나 이상의 지원되는 데이터 웨어하우스(예: Snowflake, Databricks 또는 BigQuery)에 Quality Monitoring이 설정되어 있어야 합니다.

Data Observability는 모니터 생성 흐름의 첫 번째 단계에서 선택하는 네 가지 모니터 유형을 제공합니다.

별도로 명시되지 않는 한, 아래 섹션에서는 데이터 품질 모니터 유형에 대해 설명합니다.

모니터 생성

Datadog에서 Data Observability 모니터를 생성하려면 Data Observability > Monitors > New Monitor 또는 Monitors > New Monitor > Data Observability로 이동합니다. 기존의 모든 Data Observability 모니터를 확인하려면 Data Observability 모니터 페이지를 참조하세요.

모니터링 데이터 선택

먼저 Table 수준 또는 Column 수준 중 무엇을 모니터링할지 선택합니다.

그런 다음 Edit 탭에서 검색 필드에 key:value 필터를 입력하여 테이블, 뷰 또는 열을 검색합니다.

이름 또는 위치로 필터링:

태그로 필터링:

태그 키를 필터 키로 사용하여 데이터 자산에 적용된 모든 태그를 필터링합니다. 예를 들어, 데이터 자산에 owner, platform 또는 environment 태그가 적용된 경우 해당 태그를 직접 검색합니다.

태그 필터는 이름 필터와 동일한 * 와일드카드 및 따옴표를 지원합니다(예: owner:data-* 또는 platform:"Snowflake Prod").

계산된 속성으로 필터링:

사용자 지정 태그 외에도 Datadog은 필터링할 수 있는 데이터 자산의 속성을 계산합니다. 사용 가능한 계산된 속성은 다음과 같습니다.

lineage_score는 연속적인 값을 취하는 대신 위에 나열된 개별 계층으로 버킷화되므로 해당 값 중 하나를 정확히 지정하여 필터링합니다. 단일 계층을 선택하거나 OR를 사용하여 여러 계층을 결합합니다. 예를 들어, lineage_score:1.00은 가장 많이 의존되는 자산을 반환하고, lineage_score:(0.90 OR 1.00)은 상위 두 계층을 반환합니다.

이러한 필터를 AND 또는 OR와 결합하고, 괄호를 사용하여 조건을 그룹화하며, -를 앞에 붙여 제외합니다.

예시:

계보 관계로 필터링:

계보 그래프에서 다른 자산과 연결된 자산으로 선택 범위를 좁히려면 Add Relation Filter를 클릭합니다. Upstream of 또는 Downstream of를 선택한 다음, 특정 자산을 선택하거나 동일한 key:value 필터를 사용하여 자산 집합을 찾습니다. 예를 들어, 중요한 대시보드의 상위에 있는 모든 테이블을 모니터링하거나, 특정 소스 테이블의 하위에 있는 모든 열을 모니터링합니다.

계층 관계로 필터링:

계보 그래프에서 다른 자산의 상위 또는 하위 자산으로 선택 범위를 좁히려면 Add Relation Filter를 클릭합니다. Parent of 또는 Child of를 선택한 다음, 특정 자산을 선택하거나 동일한 key:value 필터를 사용하여 자산 집합을 찾습니다. 예를 들어, revenue 열이 있는 모든 테이블이나 중요한 스키마 내에 있는 모든 테이블을 모니터링합니다.

단일 모니터는 최대 5,000개의 테이블, 뷰 또는 열을 추적할 수 있습니다. 이 제한은 늘릴 수 없습니다. 쿼리가 더 많은 항목과 일치하는 경우, 여러 모니터로 나누세요.

메트릭 유형 선택

추적하려는 데이터 품질 신호에 따라 메트릭 유형을 선택합니다. 각 모니터는 하나의 메트릭 유형을 추적합니다.

Freshness 메트릭 유형은 예상 시간 내에 데이터가 업데이트되지 않은 경우를 감지합니다. 다운스트림 보고서나 모델에 영향을 미치기 전에 오래된 데이터를 포착하는 데 사용하세요.

• 테이블 신선도는 테이블이 마지막으로 업데이트된 이후 경과된 시간을 추적합니다. 테이블 신선도는 뷰 또는 시스템 메타데이터에서 테이블의 업데이트된 타임스탬프를 제공하지 않는 데이터 웨어하우스에는 사용할 수 없습니다. 대신 열 수준 신선도를 사용하세요.
• 열 신선도는 날짜/시간 열에 기록된 가장 최근 날짜를 추적합니다.

Row Count 메트릭 유형은 테이블의 행 개수 변화를 추적합니다. 파이프라인 장애나 업스트림 문제를 나타낼 수 있는 예상치 못한 데이터 감소 또는 급증을 감지하는 데 사용하세요.

Column 메트릭 유형은 열 수준 메트릭을 추적하여 데이터 드리프트나 품질 저하를 감지합니다. 다음 중에서 선택하세요.

메트릭	설명
Uniqueness	열에서 고유한 값의 비율입니다.
Nullness	열에서 null인 값의 비율입니다.
Cardinality	열에 있는 고유한 값의 개수입니다.
Percent Zero	열에서 0인 값의 비율입니다.
Percent Negative	열에서 음수인 값의 비율입니다.
Min	열에 있는 모든 값의 최소값입니다.
Max	열에 있는 모든 값의 최대값입니다.
Mean	열에 있는 모든 값의 평균값입니다.
Standard Deviation	열에 있는 값의 변동을 측정한 값입니다.
Sum	열에 있는 모든 값의 합계입니다.

일부 열 메트릭은 특정 열 유형에서만 사용할 수 있습니다. 숫자 메트릭(0 비율, 음수 비율, 최소, 최대, 평균, 표준 편차, 합계)은 숫자형 열이 필요합니다.

Custom SQL 메트릭 유형은 사용자가 정의한 SQL 쿼리에서 반환되는 사용자 지정 메트릭 값을 추적합니다. 비즈니스에 특화된 데이터 품질 규칙 모니터링과 같이 기본 제공 메트릭 유형으로 지원할 수 없는 경우 사용하세요.

1. 쿼리에서 반환된 값을 설명하는 모델 유형을 선택하세요.
   • Default: 쿼리가 스칼라값을 반환합니다. 대부분의 경우에 사용하세요.
   • Freshness: 쿼리가 현재 시간과 이벤트가 마지막으로 발생한 시간의 차이(초)를 반환합니다.
   • Percentage: 쿼리가 0에서 100 사이의 백분율 값을 반환합니다.
2. dd_value로 별칭이 지정된 단일 값을 반환하는 SQL 쿼리를 작성하세요. 예: SELECT COUNT(*) as dd_value FROM ANALYTICS_DB.PROD.ORDERS WHERE STATUS = 'FAILED'
3. 쿼리 구문을 확인하려면 Validate를 클릭하세요.

SQL 쿼리에 GROUP BY 절이 포함된 경우, Group by 필드에 그룹화된 열을 쉼표로 구분하여 나열하세요(예: column_a, column_b). 각 그룹은 독립적으로 평가됩니다.

참고: 각 사용자 지정 SQL 모니터는 청구 시 개별 모니터링 대상 테이블로 계산됩니다.

모니터 설정

감지 방법

감지 방법을 선택하세요.

• Anomalies: 메트릭이 예상 패턴에서 벗어나면 경보를 보냅니다. 임계값은 필요하지 않습니다. 이상 탐지 모델은 기본 데이터의 업데이트 빈도에 따라 학습하는 데 3~7일(주말 포함)이 소요됩니다. 학습 기간 동안 모니터는 경보를 보내지 않으며 파란색으로 표시됩니다. 학습이 완료되면 모니터는 정상 상태일 때 녹색으로, 이상치 상태일 때 빨간색으로 표시됩니다.
• Thresholds: 메트릭이 고정된 값을 넘으면 경보를 보냅니다. 비교 연산자(above, above or equal to, below, below or equal to, equal to 또는 not equal to)를 설정하고 Critical 임계값을 정의하세요(필수). 필요에 따라 Warning 임계값을 지정합니다. 자세한 내용은 모니터 설정을 참조하세요.

WHERE 절

모니터가 평가하는 데이터를 필터링하려면 WHERE 절을 추가하세요. 이는 특정 데이터 세그먼트나 최근 레코드만 모니터링할 때 유용합니다. 예를 들면 다음과 같습니다.

• created_at >= DATEADD(day, -7, CURRENT_TIMESTAMP()) — 지난주 데이터의 행만 모니터링합니다.
• region = 'US' — 특정 지역의 데이터만 모니터링합니다.

Group by

Group by 절을 추가하여 단일 모니터를 여러 그룹으로 분할하고 각 그룹을 독립적으로 평가할 수 있습니다. 예를 들어, 행 개수 모니터를 REGION 열로 그룹화하면 각 지역별로 별도의 경보가 생성됩니다.

기본 제한은 모니터당 500개 그룹입니다. 이 제한을 늘리려면 지원팀에 문의하세요.

누락된 데이터

If data is missing to evaluate 드롭다운 메뉴에서 평가할 데이터가 없는 경우 모니터가 보고할 내용을 선택하세요.

모델 설정

Anomalies 감지 방법을 사용하는 모니터의 경우 Model configuration을 확장하여 모델의 동작 방식을 세부적으로 조정할 수 있습니다.

모니터 일정

모니터가 데이터를 평가하는 빈도를 설정하세요.

• Scheduled: 모니터는 일정한 주기로 실행됩니다. Run this monitor에서 Hourly, Every 3 hours, Every 6 hours, Every 12 hours, Daily 또는 Custom schedule을 선택합니다.
• Manual (미리 보기): 모니터는 프로그래밍 방식으로 트리거된 경우에만 실행됩니다. 모델링에 유용하도록 충분한 과거 데이터를 축적하려면 Data Observability API를 사용하여 일정에 따라 이러한 모니터를 실행하세요. UI에서는 행 개수 및 신선도와 같은 기본 메트릭을 지원하지 않으므로 이 워크플로는 사용자 지정 메트릭 또는 열 수준 메트릭에 적용됩니다.

사용자 지정 주기를 정의하려면 Custom schedule를 선택하고 cron 표현식을 입력하세요. 사용자 지정 주기는 15분 간격으로 설정할 수 있습니다. Preview times는 다음 몇 차례의 실행 일정을 현지 시간대로 표시하므로, 저장하기 전에 표현식을 확인할 수 있습니다.

경보 조건 설정

집계 유형을 선택하세요.

• Simple Alert: 모니터링 대상 테이블이나 열이 조건을 충족하면 하나의 알림을 보냅니다.
• Multi Alert: 조건을 충족하는 각 그룹에 대해 알림을 보냅니다. 경보를 세분화하려면 그룹화할 차원(table, schema, database 등)을 사용자 지정합니다. 예를 들어 schema로 그룹화하면 스키마당 하나의 경보만 전송되므로, 영향을 받는 모든 테이블을 하나로 묶어 노이즈를 줄일 수 있습니다.

알림 예시

{{#is_alert}}
Data quality issue detected on {{database.name}}.{{schema.name}}.{{table.name}}:
current value {{value}} has breached the threshold of {{threshold}}.
{{/is_alert}}

{{#is_recovery}}
Data quality issue on {{database.name}}.{{schema.name}}.{{table.name}} has recovered.
Current value {{value}} is within the threshold of {{threshold}}.
{{/is_recovery}}

{{#is_alert}}
Anomaly detected on {{database.name}}.{{schema.name}}.{{table.name}}:
observed value {{observed}} is outside the expected range of {{lower_bound}} to {{upper_bound}}
(predicted: {{predicted}}).
{{/is_alert}}

{{#is_recovery}}
{{database.name}}.{{schema.name}}.{{table.name}} has recovered.
Observed value {{observed}} is within the expected range.
{{/is_recovery}}

소스-대상 모니터

소스-대상 모니터는 두 데이터 자산에서 동일한 메트릭을 비교하고, 두 값이 서로 달라지면 경보를 보냅니다. 다른 Data Observability 모니터는 단일 자산의 신선도나 완전성을 추적합니다. 소스-대상 모니터는 소스에서 전송된 데이터와 대상에 도착한 복사본이 일치하는지 추적합니다.

파이프라인이 시스템 간에 데이터를 이동할 때 부분적인 실패는 실패처럼 보이지 않는 경우가 많습니다. 소스 테이블에서 100,000개의 행이 전송되고 대상 테이블에 99,850개의 행이 도착하면, 대상 테이블의 행 개수 모니터만으로는 정상적으로 보일 수 있습니다. 두 자산을 비교하면 차이가 드러납니다.

소스-대상 모니터를 사용하여 다음을 수행하세요.

• Postgres에서 Databricks로의 복제를 검증합니다.
• 동일한 Snowflake 계정 내의 두 데이터베이스(예: 품질 데이터베이스와 프로덕션 데이터베이스)를 조정합니다.
• 전환 전에 Redshift에서 BigQuery로의 마이그레이션을 검증하려면 두 시스템을 동시에 실행하면서 서로 일치하는지 확인합니다.
• 변환 과정에서 입력과 출력 사이에 행이 누락되지 않는지 확인합니다.

소스-대상 모니터는 GovCloud를 제외한 모든 리전에서 사용할 수 있습니다.

소스-대상 모니터 만들기

1. Monitors > New Monitor로 이동하여 Source to Target을 선택합니다.
2. Choose source에서 소스 데이터가 저장된 웨어하우스를 선택한 다음, 비교할 데이터를 선택합니다.
3. Choose target에서 대상에 대해서도 동일한 작업을 수행합니다. 소스와 대상은 서로 다른 데이터 웨어하우스에 저장되어 있거나 동일한 웨어하우스에 저장되어 있을 수 있습니다.
4. Select your metric type에서 비교할 메트릭을 선택합니다. 소스-대상 모니터는 행 개수, 신선도, null 여부, 고유성, 카디널리티 및 Custom SQL을 포함하여 다른 Data Observability 모니터와 동일한 메트릭 유형을 지원합니다.
5. 비교 결과를 표시하는 방식을 제어하려면 Format을 설정합니다.
   • Difference: 대상 값에서 소스 값을 뺀 값입니다. 음수 값은 대상 값이 소스 값보다 작음을 의미합니다.
   • % Difference: 소스 값 대비 차이를 백분율로 나타낸 값입니다.
6. 모니터 설정에 설명된 대로 감지 방법, 일정 및 알림을 설정합니다.

Preview Monitor Evaluation 패널에는 식별된 소스와 대상 및 선택한 메트릭의 미리 보기가 표시됩니다.

모니터링 대상 자산이 대상이므로, 모니터는 대상의 상태 페이지에 표시됩니다.

사용자 지정 메트릭 비교

메트릭 유형이 Custom SQL인 경우 소스에 대한 쿼리 하나와 대상에 대한 쿼리 하나를 입력합니다. 이 메트릭 유형에서는 WHERE 절을 사용할 수 없습니다. 각 쿼리에 필터링을 포함하세요.

평가

소스와 대상 간의 차이는 별도의 메트릭으로 기록되므로 소스-대상 모니터는 이상 탐지를 포함하여 다른 Data Observability 모니터와 동일한 감지 방법으로 평가됩니다. 소스와 대상은 동기화된 일정에 따라 측정되므로, 각 웨어하우스의 기본 수집 주기를 따르는 대신 두 값을 동시에 수집합니다.

스키마 변경 모니터

스키마 변경 모니터는 데이터의 내용이 변경되는 경우가 아니라 데이터의 구조가 변경되면 경보를 보냅니다. 열이 삭제되거나, 이름 또는 데이터 유형이 변경되는 경우와 같이 다운스트림 파이프라인이나 대시보드가 중단되기 전에 업스트림 변경 사항을 포착하는 데 사용하세요.

스키마 변경 모니터는 데이터베이스, 스키마, 테이블 및 열 전반에서 발생하는 네 가지 유형의 변경 사항을 감지합니다.

Snowflake, BigQuery, Databricks 및 Redshift에서 스키마 변경 사항을 감지합니다.

스키마 변경 모니터 만들기

1. Monitors > New Monitor > Schema Change로 이동합니다.
2. Choose data to monitor에서 모니터링할 웨어하우스를 선택합니다.
3. 모니터 설정에 설명된 대로 알림을 설정합니다.

스키마 변경 모니터는 측정된 값이 임계값을 초과하는 경우가 아니라 구조가 변경되면 경보를 보내므로 메트릭 유형이나 감지 방법이 필요하지 않습니다.

감지된 스키마 변경 사항 찾아보기

모니터를 생성하지 않고 Datadog에서 감지한 변경 사항을 확인하려면 Data Observability > Schema Changes로 이동합니다. 플랫폼, 계정, 데이터베이스, 스키마 또는 변경 유형으로 필터링하고, 항목을 확장하여 영향을 받는 열과 해당 데이터 유형을 확인합니다.

Datadog은 웨어하우스의 스키마 메타데이터를 수집할 때 현재 구조를 이전에 수집한 구조와 비교하여 변경 사항을 감지합니다.

모니터 예시

경계 주석 달기

이상 탐지 방법을 사용하는 모니터의 경우, 경계 범위에 주석을 달아 피드백을 제공하고 시간이 지남에 따라 모델을 개선할 수 있습니다. 인프라 메트릭과 달리 데이터 품질 메트릭은 비즈니스별로 다른 경우가 많으므로, 주석을 사용하여 해당 데이터에서 어떤 동작이 정상인지 모델에 학습시킬 수 있습니다.

모니터의 상태 페이지에서 Annotate Bounds를 클릭하고, 차트에서 시간 범위를 선택한 다음, 다음 주석 중 하나를 선택합니다.

추가 자료

추가적인 유용한 설명서, 링크 및 기사:

Data Observability 개요설명서 Quality Monitoring설명서 모니터 알림 설정설명서 모니터 음소거를 위한 가동 중지 예약설명서 모니터 상태 확인설명서