By 바 모세, Monte Carlo &의 CEO 겸 공동 설립자 라이언 컨즈, Monte Carlo의 기계 학습 엔지니어

이 기사 시리즈에서는 자신만의 데이터 관찰 가능성 모니터를 처음부터 생성하고 다음으로 매핑하는 방법을 안내합니다. 데이터 상태의 XNUMX가지 핵심 기둥. 내가 찾을 수 있는 부분 여기에서 지금 확인해 보세요..

이 시리즈의 XNUMX부는 Barr Moses와 Ryan Kearns의 O'Reilly 교육을 각색한 것입니다. 데이터 다운타임 관리: 데이터 파이프라인에 관찰 가능성 적용, 데이터 관찰 가능성에 대한 업계 최초의 과정입니다. 관련 연습을 사용할 수 있습니다. 여기에서 지금 확인해 보세요., 이 문서에 표시된 수정된 코드를 사용할 수 있습니다. 여기에서 지금 확인해 보세요..

데이터에 대한 전 세계의 수요가 증가함에 따라 강력한 데이터 파이프라인이 더욱 중요해졌습니다. 스키마 변경, null 값, 중복 등으로 인해 데이터가 손상되면 데이터 엔지니어가 알아야 합니다.

가장 중요한 것은 다운스트림 시스템과 소비자에게 영향을 미치기 전에 파손의 근본 원인을 신속하게 평가해야 한다는 것입니다. 우리는 사용 "데이터 다운 타임”는 데이터가 누락, 오류 또는 기타 부정확한 기간을 나타냅니다. 데이터 전문가라면 다음 질문에 익숙할 것입니다.

• 데이터가 최신 상태입니까?
• 데이터가 완전합니까?
• 필드가 예상 범위 내에 있습니까?
• null 비율이 정상보다 높거나 낮습니까?
• 스키마가 변경되었습니까?

이러한 질문에 효과적으로 답하기 위해 소프트웨어 엔지니어의 플레이북에서 한 페이지를 가져올 수 있습니다. 모니터링 및 관찰 가능성.

XNUMX부 이후로 기억을 되살리기 위해 다음을 정의합니다. 데이터 관찰 가능성 이러한 질문에 답하고 데이터 에코시스템의 상태를 평가하는 조직의 능력입니다. 데이터 상태의 주요 변수를 반영하여 데이터 관찰 가능성의 XNUMX가지 기둥은 다음과 같습니다.

• 선도: 내 데이터가 최신 상태입니까? 내 데이터가 업데이트되지 않은 시간 간격이 있습니까?
• 콘텐츠 배급: 필드 수준에서 내 데이터가 얼마나 건강한가요? 내 데이터가 예상 범위 내에 있습니까?
• 음량: 내 데이터 수집이 예상 임계값을 충족합니까?
• 개요: 내 데이터 관리 시스템의 공식 구조가 변경되었습니까?
• 혈통: 내 데이터 중 일부가 다운된 경우 업스트림 및 다운스트림에 영향을 미치는 것은 무엇입니까? 내 데이터 소스는 서로 어떻게 의존합니까?

이 기사 시리즈에서 우리는 커튼을 뒤로 젖히고 데이터 관찰 가능성이 어떤 것인지 조사하는 데 관심이 있습니다. 코드에서.

In 제 1 부, 우리는 처음 두 기둥인 신선도와 배포를 살펴보고 약간의 SQL 코드가 이러한 개념을 운영할 수 있는 방법을 보여주었습니다. 이것들은 우리가 더 "클래식"이라고 부르는 것입니다. 이상 감지 문제 — 꾸준한 데이터 흐름이 주어졌을 때 이상하게 보이는 것이 있습니까? 우수한 이상 탐지는 확실히 데이터 관찰 가능성 퍼즐의 일부이지만 전부는 아닙니다.

똑같이 중요한 것은 문맥. 이상 현상이 발생하면 좋습니다. 하지만 어디? 어떤 업스트림 파이프라인이 원인일 수 있습니까? 어떤 다운스트림 대시보드가 ​​영향을 받습니까? 그리고 내 데이터의 공식적인 구조가 변경되었습니까? 우수한 데이터 관찰 가능성은 메타데이터를 적절하게 활용하여 이러한 질문과 기타 많은 질문에 답하는 능력에 달려 있으므로 더 큰 문제가 되기 전에 근본 원인을 식별하고 문제를 해결할 수 있습니다.

이 기사에서는 이러한 중요한 컨텍스트를 제공하도록 설계된 두 가지 데이터 관찰 가능성 기둥을 살펴보겠습니다. 개요 과 혈통. 다시 한 번 Jupyter 및 SQLite와 같은 경량 도구를 사용하므로 환경을 쉽게 가동하고 이러한 연습을 직접 해 볼 수 있습니다. 시작하자.

데이터 환경

 
이 튜토리얼은 연습 2 및 3 O'Reilly 과정의 데이터 다운타임 관리. Jupyter Notebook 및 SQL을 사용하여 이러한 연습을 직접 시도해 볼 수 있습니다. 운동을 포함하여 더 자세히 다룰 것입니다. 4, 향후 기사에서.

당신이 읽는다면 제 1 부 이 시리즈의 데이터를 잘 알고 있어야 합니다. 이전과 마찬가지로 모의 천문 데이터 거주 가능한 외계 행성에 대해. 우리는 Python으로 데이터 세트를 생성하고 프로덕션 환경에서 접한 실제 사건에서 데이터 및 이상을 모델링했습니다. 이 데이터 세트는 전적으로 무료로 사용할 수 있으며 유틸리티 폴더 관심이 있는 경우 저장소에 데이터를 생성한 코드가 포함되어 있습니다.

최소한의 설정으로 명령 프롬프트 또는 SQL 파일에서 데이터베이스에 액세스할 수 있도록 하는 SQLite 3.32.3을 사용하고 있습니다. 개념은 실제로 모든 쿼리 언어로 확장되며 이러한 구현 최소한의 변경만으로 MySQL, Snowflake 및 기타 데이터베이스 환경으로 확장할 수 있습니다.

다시 한 번 EXOPLANETS 테이블이 있습니다.

$ sqlite3 EXOPLANETS.db
sqlite> PRAGMA TABLE_INFO(EXOPLANETS);
0 | _id | TEXT | 0 | | 0
1 | distance | REAL | 0 | | 0
2 | g | REAL | 0 | | 0
3 | orbital_period | REAL | 0 | | 0
4 | avg_temp | REAL | 0 | | 0
5 | date_added | TEXT | 0 | | 0

EXOPLANETS의 데이터베이스 항목에는 다음 정보가 포함됩니다.

0. _id: 행성에 해당하는 UUID.
1. distance: 지구로부터의 거리, 광년 단위.
2. g: 중력 상수인 g의 배수로서의 표면 중력.
3. orbital_period: 단일 궤도 주기의 길이(일)입니다.
4. avg_temp: 평균 표면 온도(켈빈도).
5. date_added: 시스템이 행성을 발견하고 데이터베이스에 자동으로 추가한 날짜입니다.

다음 중 하나 이상에 유의하십시오. distance, g, orbital_period및 avg_temp 수 NULL 누락되거나 잘못된 데이터의 결과로 주어진 행성에 대해.

sqlite> SELECT * FROM EXOPLANETS LIMIT 5;

이 연습은 소급 적용됩니다. 과거 데이터를 보고 있습니다. 프로덕션 데이터 환경에서 데이터 관찰 가능성은 실시간이며 데이터 수명 주기의 각 단계에 적용되므로 여기에서 수행되는 것과 약간 다른 구현이 필요합니다.

가장 오래된 데이터의 날짜가 2020–01–01인 것 같습니다(주의: 대부분의 데이터베이스는 개별 레코드에 대한 타임스탬프를 저장하지 않으므로 DATE_ADDED 열이 우리를 위해 추적하고 있습니다). 최신 데이터…

sqlite> SELECT DATE_ADDED FROM EXOPLANETS ORDER BY DATE_ADDED DESC LIMIT 1;
2020–07–18

… 2020–07–18로 보입니다. 물론 이것은 이전 기사에서 사용한 것과 동일한 테이블입니다. 스키마와 혈통의 더 많은 컨텍스트 기반 기둥을 탐색하려면 환경을 확장해야 합니다.

이제 추가로 EXOPLANETS, 라는 테이블이 있습니다. EXOPLANETS_EXTENDED, 과거 테이블의 상위 집합입니다. 동일한 테이블로 생각하는 것이 유용합니다. 시간의 다른 순간. 사실상, EXOPLANETS_EXTENDED 2020–01–01로 거슬러 올라가는 데이터가 있습니다…

sqlite> SELECT DATE_ADDED FROM EXOPLANETS_EXTENDED ORDER BY DATE_ADDED ASC LIMIT 1;
2020–01–01

… 그러나 2020–09–06까지의 데이터도 포함합니다. EXOPLANETS:

sqlite> SELECT DATE_ADDED FROM EXOPLANETS_EXTENDED ORDER BY DATE_ADDED DESC LIMIT 1;
2020–09–06

스키마 변경 시각화

 
이 테이블 간에는 다른 점이 있습니다.

sqlite> PRAGMA TABLE_INFO(EXOPLANETS_EXTENDED);
0 | _ID | VARCHAR(16777216) | 1 | | 0
1 | DISTANCE | FLOAT | 0 | | 0
2 | G | FLOAT | 0 | | 0
3 | ORBITAL_PERIOD | FLOAT | 0 | | 0
4 | AVG_TEMP | FLOAT | 0 | | 0
5 | DATE_ADDED | TIMESTAMP_NTZ(6) | 1 | | 0
6 | ECCENTRICITY | FLOAT | 0 | | 0
7 | ATMOSPHERE | VARCHAR(16777216) | 0 | | 0

6개의 필드 외에도 EXOPLANETSWalk Through California 프로그램, EXOPLANETS_EXTENDED 테이블에는 두 개의 추가 필드가 있습니다.

6. eccentricity다음 궤도 이심률 호스트 스타에 대한 행성의.
7. atmosphere: 행성 대기의 지배적인 화학적 구성.

좋아요 참고 distance, g, orbital_period및 avg_temp모두 eccentricity 과 atmosphere 수 NULL 누락되거나 잘못된 데이터의 결과로 주어진 행성에 대해. 예를 들어, 불량 행성 정의되지 않은 궤도 이심률을 가지며 많은 행성에는 대기가 전혀 없습니다.

또한 데이터는 다시 채워지지 않습니다. 즉, 테이블 시작 부분의 데이터 항목(테이블에도 포함된 데이터)을 의미합니다. EXOPLANETS 표)에는 이심률 및 대기 정보가 없습니다.

sqlite> SELECT ...> DATE_ADDED, ...> ECCENTRICITY, ...> ATMOSPHERE ...> FROM ...> EXOPLANETS_EXTENDED ...> ORDER BY ...> DATE_ADDED ASC ...> LIMIT 10;
2020–01–01 | |
2020–01–01 | |
2020–01–01 | |
2020–01–01 | |
2020–01–01 | |
2020–01–01 | |
2020–01–01 | |
2020–01–01 | |
2020–01–01 | |
2020–01–01 | |

두 개의 필드 추가는 개요 이전 단계로 돌아가기 — 데이터의 공식 청사진이 수정되었습니다. 스키마 변경은 데이터 구조가 변경될 때 발생하며 수동으로 디버깅하기 어려울 수 있습니다. 스키마 변경은 다음을 포함하여 데이터에 대한 여러 가지 사항을 나타낼 수 있습니다.

• 새로운 API 엔드포인트 추가
• 아직 사용되지 않는 사용되지 않는 것으로 추정되는 필드… 사용되지 않음
• 열, 행 또는 전체 테이블의 추가 또는 빼기

이상적으로는 파이프라인에서 발생할 수 있는 문제에 대한 벡터를 나타내므로 이 변경 사항에 대한 기록이 필요합니다. 유감스럽게도 저희 데이터베이스는 이러한 변경 사항을 추적하도록 기본적으로 구성되어 있지 않습니다. 버전 기록이 없습니다.

이 문제는 제 1 부 개별 레코드의 나이를 쿼리할 때 DATE_ADDED 대처할 칼럼. 이 경우 전체 테이블을 추가하는 것을 제외하고는 비슷한 작업을 수행합니다.

sqlite> PRAGMA TABLE_INFO(EXOPLANETS_COLUMNS);
0 | DATE | TEXT | 0 | | 0
1 | COLUMNS | TEXT | 0 | | 0

　 EXOPLANETS_COLUMNS 테이블에 열을 기록하여 스키마 "버전" EXOPLANETS_EXTENDED 임의의 날짜에. 첫 번째 항목과 마지막 항목을 살펴보면 어느 시점에서 열이 확실히 변경되었음을 알 수 있습니다.

sqlite> SELECT * FROM EXOPLANETS_COLUMNS ORDER BY DATE ASC LIMIT 1;
2020–01–01 | [ (0, ‘_id’, ‘TEXT’, 0, None, 0), (1, ‘distance’, ‘REAL’, 0, None, 0), (2, ‘g’, ‘REAL’, 0, None, 0), (3, ‘orbital_period’, ‘REAL’, 0, None, 0), (4, ‘avg_temp’, ‘REAL’, 0, None, 0), (5, ‘date_added’, ‘TEXT’, 0, None, 0) ]sqlite> SELECT * FROM EXOPLANETS_COLUMNS ORDER BY DATE DESC LIMIT 1;
2020–09–06 | [ (0, ‘_id’, ‘TEXT’, 0, None, 0), (1, ‘distance’, ‘REAL’, 0, None, 0), (2, ‘g’, ‘REAL’, 0, None, 0), (3, ‘orbital_period’, ‘REAL’, 0, None, 0), (4, ‘avg_temp’, ‘REAL’, 0, None, 0), (5, ‘date_added’, ‘TEXT’, 0, None, 0), (6, ‘eccentricity’, ‘REAL’, 0, None, 0), (7, ‘atmosphere’, ‘TEXT’, 0, None, 0) ]

이제 원래 질문으로 돌아가서 스키마가 정확히 언제 변경되었습니까? 열 목록은 날짜별로 인덱싱되므로 빠른 SQL 스크립트를 사용하여 변경 날짜를 찾을 수 있습니다.

반환된 데이터는 다음과 같습니다. 가독성을 위해 형식을 다시 지정했습니다.

DATE: 2020–07–19
NEW_COLUMNS: [ (0, ‘_id’, ‘TEXT’, 0, None, 0), (1, ‘distance’, ‘REAL’, 0, None, 0), (2, ‘g’, ‘REAL’, 0, None, 0), (3, ‘orbital_period’, ‘REAL’, 0, None, 0), (4, ‘avg_temp’, ‘REAL’, 0, None, 0), (5, ‘date_added’, ‘TEXT’, 0, None, 0), (6, ‘eccentricity’, ‘REAL’, 0, None, 0), (7, ‘atmosphere’, ‘TEXT’, 0, None, 0) ]
PAST_COLUMNS: [ (0, ‘_id’, ‘TEXT’, 0, None, 0), (1, ‘distance’, ‘REAL’, 0, None, 0), (2, ‘g’, ‘REAL’, 0, None, 0), (3, ‘orbital_period’, ‘REAL’, 0, None, 0), (4, ‘avg_temp’, ‘REAL’, 0, None, 0), (5, ‘date_added’, ‘TEXT’, 0, None, 0) ]

이 쿼리를 통해 잘못된 날짜인 2020–07–19를 반환합니다. 신선도 및 배포 관찰 가능성과 마찬가지로 스키마 관찰 가능성을 달성하는 것은 패턴을 따릅니다. 유용한 메타데이터 파이프라인 상태를 알리고 추적하며 감지기를 구축하여 잠재적인 문제를 경고합니다. 다음과 같은 추가 테이블 제공 EXOPLANETS_COLUMNS 스키마를 추적하는 한 가지 방법이지만 다른 방법도 많이 있습니다. 자체 데이터 파이프라인에 대한 스키마 변경 감지기를 구현할 수 있는 방법에 대해 생각하는 것이 좋습니다!

계보 시각화

 
우리는 혈통을 다음과 같이 설명했습니다. 가장 전체적인 데이터 관찰 가능성의 5가지 기둥 중 하나이며 그만한 이유가 있습니다.

Lineage는 (1) 영향을 받을 수 있는 다운스트림 소스와 (2) 근본 원인이 될 수 있는 업스트림 소스를 알려줌으로써 사건을 맥락화합니다. SQL 코드로 계보를 "시각화"하는 것은 직관적이지 않지만 간단한 예를 통해 이것이 얼마나 유용한지 알 수 있습니다.

이를 위해서는 데이터 환경을 다시 한 번 확장해야 합니다.

소개: 거주지

 
데이터베이스에 다른 테이블을 추가해 보겠습니다. 지금까지 우리는 외계 행성에 대한 데이터를 기록해 왔습니다. 재미있는 질문이 하나 있습니다. 이 행성들 중 얼마나 많은 행성에 생명체가 살고 있을까요?

　 HABITABLES 테이블에서 데이터 가져오기 EXOPLANETS 그 질문에 답하는 데 도움이 되도록:

sqlite> PRAGMA TABLE_INFO(HABITABLES);
0 | _id | TEXT | 0 | | 0
1 | perihelion | REAL | 0 | | 0
2 | aphelion | REAL | 0 | | 0
3 | atmosphere | TEXT | 0 | | 0
4 | habitability | REAL | 0 | | 0
5 | min_temp | REAL | 0 | | 0
6 | max_temp | REAL | 0 | | 0
7 | date_added | TEXT | 0 | | 0

항목 HABITABLES 다음을 포함합니다.

0. _id: 행성에 해당하는 UUID.
1. perihelion다음 가장 가까운 거리 궤도 주기 동안 천체에.
2. aphelion다음 가장 먼 거리 궤도 주기 동안 천체에.
3. atmosphere: 행성 대기의 지배적인 화학적 구성.
4. habitability: 0과 1 사이의 실수로 행성에 생명이 있을 가능성을 나타냅니다.
5. min_temp: 행성 표면의 최저 온도.
6. max_temp: 행성 표면의 최고 온도.
7. date_added: 시스템이 행성을 발견하고 데이터베이스에 자동으로 추가한 날짜입니다.

의 칼럼처럼 EXOPLANETS, 값 perihelion, aphelion, atmosphere, min_temp및 max_temp 허용된다 NULL. 사실상, perihelion 과 aphelion 될거야 NULL 어떤을 위해 _id in EXOPLANETS 어디에 eccentricity is NULL, 궤도 이심률을 사용하여 이러한 메트릭을 계산하기 때문입니다. 이는 이 두 필드가 항상 NULL 이전 데이터 항목에서:

sqlite> SELECT * FROM HABITABLES LIMIT 5;

그래서 우리는 HABITABLES 의 값에 따라 다름 EXOPLANETS (또는 동등하게, EXOPLANETS_EXTENDED), 그리고 EXOPLANETS_COLUMNS 뿐만 아니라 않습니다. 데이터베이스의 종속성 그래프는 다음과 같습니다.

이미지 제공 : 몬테 카를로.

매우 간단한 계보 정보이지만 이미 유용합니다. 이상 현상을 살펴보자 HABITABLES 이 그래프의 맥락에서 우리가 무엇을 배울 수 있는지 확인하십시오.

이상 현상 조사

 
거주 가능성과 같은 주요 지표가 있을 때 HABITABLES, 여러 가지 방법으로 해당 메트릭의 상태를 평가할 수 있습니다. 우선, 평균값은 얼마입니까? habitability 특정 날짜의 새 데이터를 위해?

이 데이터를 보면 뭔가 잘못되었음을 알 수 있습니다. 에 대한 평균값 habitability 일반적으로 0.5 정도이지만 기록된 데이터에서는 나중에 0.25 정도로 반감됩니다.

분포 이상… 그러나 원인은 무엇입니까?

이것은 명백한 분배 이상이지만 정확히 무슨 일이 일어나고 있습니까? 다시 말해, 무엇입니까 근본 원인 이 변칙의?

왜 우리는 NULL 우리가 그랬던 것처럼 거주 가능성에 대한 비율 제 1 부?

다행히도 여기에서 이상하게 보이는 것은 없습니다.

그러나 이것은 우리 문제의 원인으로 유망해 보이지 않습니다. 또 다른 분포 건강 지표인 XNUMX 값의 비율?

여기에서 분명히 뭔가 더 잘못된 것 같습니다.

역사적으로, habitability 거의 40이 아니었지만 나중에는 평균적으로 거의 XNUMX%까지 치솟았습니다. 이는 필드의 평균값을 낮추는 감지된 효과가 있습니다.

분포 이상… 그러나 원인은 무엇입니까?

우리는 XNUMX부에서 구축한 분포 탐지기 중 하나를 조정하여 habitability 들:

명령줄을 통해 이 쿼리를 실행했습니다.

$ sqlite3 EXOPLANETS.db < queries/lineage/habitability-zero-rate-detector.sql
DATE_ADDED | HABITABILITY_ZERO_RATE | PREV_HABITABILITY_ZERO_RATE
2020–07–19 | 0.369047619047619 | 0.0

2020–07–19는 제로금리가 비정상적인 결과를 보이기 시작한 첫 번째 날짜였습니다. 이 날은 스키마 변경 감지와 같은 날입니다. EXOPLANETS_EXTENDED. EXOPLANETS_EXTENDED 업스트림 HABITABLES, 따라서 이 두 사건이 관련되어 있을 가능성이 매우 높습니다.

이런 식으로 혈통 정보는 우리가 다음을 식별하는 데 도움이 될 수 있습니다. 근본 원인 문제를 해결하기 위해 더 빠르게 움직입니다. 에서 이 사건에 대한 다음 두 가지 설명을 비교하십시오. HABITABLES:

1. 2020–07–19에 거주 가능성 열의 제로 비율 HABITABLES 테이블이 0%에서 37%로 뛰었습니다.
2. 2020–07–19에 두 개의 추가 필드를 추적하기 시작했습니다. eccentricity 과 atmosphere,에 EXOPLANETS 테이블. 이는 다운스트림 테이블에 악영향을 미쳤습니다. HABITABLES, 종종 필드 설정 min_temp 과 max_temp 언제라도 극단값으로 eccentricity 아니였다 NULL. 결과적으로 이로 인해 habitability 평균값의 비정상적 감소로 감지된 제로 비율의 필드 스파이크.

설명 (1)은 변칙이 발생했다는 사실만을 사용합니다. 설명 (2)는 테이블과 필드 간의 종속성 측면에서 계보를 사용하여 인시던트를 컨텍스트에 배치하고 근본 원인을 결정합니다. 그나저나 (2)의 모든 내용은 실제로 정확합니다. 무슨 일이 일어나고 있는지 스스로 이해하기 위해 환경을 어지럽히는 것이 좋습니다. 이것들은 단순한 예일 뿐이지만 (2)를 갖춘 엔지니어는 이해 과 해결 근본적인 문제이며 이것은 모두 적절한 관찰 가능성에 기인합니다.

무엇 향후 계획?

 
스키마 변경 및 계보를 추적하면 데이터의 상태 및 사용 패턴에 대한 전례 없는 가시성을 제공하여 누가, 무엇을, 어디서, 왜, 어떻게 데이터를 사용했는지에 대한 중요한 컨텍스트 정보를 제공할 수 있습니다. 실제로 스키마와 계보는 데이터 다운타임의 다운스트림(및 종종 실제 세계) 영향을 이해하는 데 있어 가장 중요한 두 가지 데이터 관찰 가능성 기둥입니다.

요약하면 :

• 우리의 데이터를 관찰 개요 데이터의 형식적 구조와 데이터가 언제 어떻게 변경되는지 이해하는 것을 의미합니다.
• 우리의 데이터를 관찰 혈통 파이프라인의 업스트림 및 다운스트림 종속성을 이해하고 격리된 사건을 더 큰 맥락에 두는 것을 의미합니다.
• 이 두 기둥은 데이터 관찰 가능성 적절한 메타데이터를 추적하고 이상 현상을 이해할 수 있는 방식으로 데이터를 변환합니다.
• 더 나은 관찰 가능성 의미 데이터 중단 이유와 방법에 대한 더 나은 이해, 탐지 시간과 해결 시간을 모두 단축합니다.

"Data Observability in Context"의 두 번째 기사가 도움이 되었기를 바랍니다.

XNUMX부까지는 데이터 중단 시간이 없기를 바랍니다!

데이터 관찰 가능성에 대한 Monte Carlo의 접근 방식에 대해 더 알고 싶으십니까? 연락하기 라이언, 바및 몬테카를로 팀.

 
바 모세 데이터 관측 회사인 Monte Carlo의 CEO이자 공동 설립자입니다. 이전에는 Gainsight에서 운영 부사장을 역임했습니다.

라이언 컨즈 Monte Carlo의 데이터 및 기계 학습 엔지니어이자 Stanford University의 신입생입니다.

실물. 허가를 받아 다시 게시했습니다.

관련 :

• 데이터 관찰 가능성 : SQL을 사용하여 데이터 품질 모니터 구축
• 데이터 카탈로그가 죽었습니다. 긴 라이브 데이터 검색
• SQL의 데이터 정리 및 랭 글링