데이터 품질 향상: Lyft를 통한 데이터 계약 탐색

데이터 품질에 관한 시리즈의 2부인 것 같습니다!

이전 게시물 에서 인센티브를 통해 데이터 품질을 향상시키는 에어비앤비의 전략을 살펴봤습니다. 단일 점수와 명확한 채점 기준을 구현하여 데이터 생산자와 소비자 간의 공통된 이해를 구축하고 진정한 주인의식을 조성했습니다.

이제 Lyft는 동일한 것을 다르게 시도하는 것이 아니라 데이터 품질의 다양한 측면에 초점을 맞추는 독특한 접근 방식을 취하고 있습니다. 그리고 Lyft의 전략은 Airbnb의 노력을 보완합니다. 나는 Airbnb의 DQ 점수(또는 유사한 점수)를 데이터 품질을 향상하려는 다양한 시도를 통합하는 효과적인 수단으로 간주하지만 Lyft는 다른 각도에서 이 문제를 다루고 있습니다.

Airbnb의 DQ 점수는 데이터 품질을 구체적으로 시각화하는 데 유용한 도구 역할을 합니다. 본질적으로 데이터 품질을 향상하려는 모든 계획은 이 점수에 눈에 띄는 영향을 미쳐야 합니다. 반면에 Lyft는 특정 품질 기준에 따라 데이터를 테스트하고 검증함으로써 사전에 품질을 향상시킬 수 있는 한 가지 가능한 이니셔티브를 제시합니다.

근본적으로 이는 데이터 품질 수명주기의 다른 지점입니다. 품질을 개선하기 위한 메커니즘을 도입하려면 초기에 품질을 측정할 수 있는 능력이 필요합니다.

따라서 Airbnb 의 초점은 데이터 품질을 측정 하고 관찰하는 데 있으며, 데이터 품질을 향상하고 '보기 좋게' 보이려는 생산자의 관심에 의존하는 반면, Lyft는 다른 접근 방식을 취합니다. Lyft는 데이터 품질을 적극적으로 테스트 하고 검증하여 생산자와 소비자 모두에게 품질을 효과적으로 개선하고 제어할 수 있는 수단을 제공하는 데 중점을 둡니다.

종합적으로 이러한 접근 방식은 수명주기 전반에 걸쳐 데이터 품질을 해결하고 향상하기 위한 포괄적인 전략을 제공합니다.

이러한 이유로 저는 특히 Lyft의 접근 방식을 자세히 살펴보고 싶었습니다.

제가 흥미를 느낀 또 다른 요소는 테스트, 특히 마이크로서비스 아키텍처의 출현과 함께 기본 소프트웨어 엔지니어링에서 수년 동안 사용되어 온 계약 테스트입니다. 그러나 데이터 계약은 데이터 엔지니어링 영역에서 보다 최근에 나온 것으로, 고품질 데이터 파이프라인을 구축하기 위한 경로에서 실행하기 위한 정점 또는 궁극적인 단계 중 하나로 간주됩니다. 이것이 바로 제가 Lyft의 접근 방식을 더 자세히 조사하고 몇 가지 잠재적인 유사점을 탐구하고 싶었던 이유입니다.

앞서 언급했듯이 Airbnb와 Lyft가 취한 접근 방식은 상호 보완적이며 데이터 품질 개선이라는 동일한 목표를 달성하는 것을 목표로 합니다.

Airbnb는 데이터 품질의 4가지 측면을 측정하고 향상하는 데 초점을 맞춘 DQ 점수를 개발했습니다.

DQ Score에는 전체 적용 범위, 자동화, 실행 가능성, 다차원성 및 진화 가능성을 포함한 기본 원칙이 있습니다. 정확성, 신뢰성, 관리 및 유용성과 같은 차원이 있습니다.

Lyft의 Verity는 5가지 차원에 걸쳐 데이터 품질을 향상하도록 설계된 플랫폼입니다.

데이터 품질을 의미적 정확성, 일관성, 완전성, 고유성, 올바른 형식, 적시성과 같은 측면을 다루면서 데이터가 의도한 대로 얼마나 잘 사용될 수 있는지에 대한 척도로 정의합니다.

Lyft의 Verity로 개선된 5가지 데이터 품질 측면과 Airbnb의 DQ 점수로 측정된 4가지 데이터 품질 측면 사이의 유사점을 쉽게 찾아볼 수 있습니다. 예를 들어 적시성과 같은 측면은 확실히 DQ 점수의 신뢰성에 기여하는 반면 정확성은 의미론적 정확성, 완전성 및 데이터 고유성에 따라 달라집니다. 반면에 유용성 점수는 다른 요소들 사이에서 데이터의 일관성에 의해 영향을 받습니다.

Lyft의 Verity 는 의미적 정확성, 일관성, 완전성, 고유성, 올바른 형식 및 적시성과 관련된 검사를 정의하는 데 중점을 둡니다. Airbnb의 통합 DQ 점수는 테스트 우선 및 검증 접근 방식을 따르는 반면, Airbnb의 통합 DQ 점수는 다양한 차원을 통한 데이터 품질 평가를 강조합니다.

DQ 점수를 이 마지막 스키마에 통합하려면 경고/디버그 단계 측면에 있어야 합니다.

Airbnb의 DQ 점수는 다양한 신호를 사용하여 정확성, 신뢰성, 관리 및 유용성 측면 에서 데이터 품질을 평가합니다.

또한 품질을 보다 직접적으로 측정하는 일련의 입력 신호(Midas 인증, 데이터 검증, 버그, SLA, 자동화된 DQ 확인 등)가 있는 반면 다른 것들은 품질에 대한 프록시(예: 유효한 소유권, 올바른 거버넌스 위생, 포장된 경로 도구 사용).

앞서 논의한 것처럼 Airbnb의 DQ 점수와 Verity 사이에는 중복이 있을 가능성이 높습니다. Airbnb는 측정 및 채점을 강조하면서 데이터 품질을 오른쪽으로 이동하는 데 중점을 두는 반면, Lyft의 Verity는 확인 정의 구성, 테스트 및 검증 프로세스를 왼쪽으로 이동하여 데이터 품질의 사전 예방적 개선을 강조하는 사전 예방적 접근 방식을 취합니다.

이제 나의 주된 관심은 왼쪽, 즉 검사 정의 구성, 테스트 및 검증 측면에 있습니다.

Lyft는 데이터 품질 테스트를 프로세스에 어떻게 통합합니까?

먼저 실행 경로를 살펴보겠습니다.

현재 Lyft의 Verity는 주로 Hive 데이터 웨어하우스에 저장된 데이터의 품질을 보장하는 데 중점을 두고 있습니다. 그러나 향후 다른 데이터 소스를 지원하기 위해 기능을 확장할 계획이 있습니다.

그들은 Hive를 데이터 작업장이라고 부르지만 실제로는 이를 하이브리드 데이터 스토리지 솔루션으로 활용하여 구조화되고 처리되고 정리된 데이터(실버 레이어)를 위한 데이터 웨어하우스로 작동하는 동시에 원시 이벤트를 위한 데이터 레이크 역할도 합니다. 데이터(브론즈 레이어).

Hive의 열악한 데이터 품질로 인해 실험 지표가 오염되고 기계 학습 기능이 부정확해졌으며 경영진 대시보드에 결함이 생겼습니다.

Verity의 검사는 Airflow DAG에 통합되어 고품질 원시 데이터만 Hive에서 파생 데이터로 처리되고 저장되도록 할 수 있습니다.

데이터 생산자와 소비자는 데이터 품질 검사를 정의하고 데이터가 생성될 때 또는 내부에서 소비되기 전에 데이터를 확인할 수 있습니다. 기류 또는 플라이트 .

…

VerityAirflowOperator를 차단 방식으로 사용하면 검사 실패 시 DAG를 중지하여 잘못된 데이터가 프로덕션에 도달하는 것을 방지할 수 있습니다. 이는 “ 단계-점검-교환 ” 패턴: 단계적 스키마에서 데이터를 생성하고 차단 연산자로 데이터를 확인한 다음 품질 검사를 통과하면 프로덕션으로 승격합니다.

원시 데이터와 파생 데이터를 모두 확인하기 위해 검사를 수동으로 수행하거나 자동으로 예약할 수도 있습니다.

Verity Scheduled Checks는 모든 데이터 조정 엔진에서 격리되므로 Airflow 또는 Flyte가 완전히 다운된 경우에도 계속 실행됩니다. 이는 Airflow Task가 실행되지 않았기 때문에 검사가 경고하지 않는 일반적인 문제를 해결합니다.

따라서 검사를 실행하는 기본 방법에는 Airflow DAG의 일부로 수동으로 실행하거나 Verity 플랫폼/UI를 통해 예약하는 3가지 기본 방법이 있습니다.

나는 현재 검사를 실시간 스트리밍 파이프라인(예: Flink + Kafka)에 통합하여 Hive(또는 그 이전)에 들어갈 때 예제 데이터의 유효성을 검사할 수 있다고 믿지 않습니다.

이러한 유형의 실시간 확인을 구현하면 불일치를 신속하게 감지할 수 있어 저장 및 처리 비용이 절감되고 전반적인 데이터 품질이 향상됩니다.

철저하게 말하자면, Verity 검사는 API 서버를 통해 관리되며, 이는 일부 API를 통해 프로그래밍 방식으로 검사를 실행하는 데 사용될 수 있습니다.

Verity API 서버 — 이 서비스는 검사 실행은 물론 결과 유지 및 검색과 관련된 모든 외부 API를 처리합니다. API 서버는 검사를 실행하지 않고 대신 검사 대기열에 메시지를 씁니다. SimpleQueueService (SQS).

따라서 잠재적으로 Hive 변경 데이터 캡처(CDC)와 통합하여 스트리밍 작업이나 장기적으로 이러한 작업을 보다 실시간 방식으로 트리거할 수 있습니다.

그러나 Airflow 외부에서 실행되는 경우 이러한 작업은 데이터 처리 작업을 차단할 수 없습니다. 대신 점검 대기열에 푸시된 비동기 경고를 생성합니다. 일부 소비자는 검사가 실패할 때 데이터 처리가 지연되는 것을 선호하는 반면, 다른 소비자는 계속 진행하여 경고를 받기를 원합니다.

이제 이러한 데이터 품질 테스트를 살펴보겠습니다.

다음은 rider_events.session_id null이 아닌지 확인하는 예입니다. 이는 쿼리와 조건 구성 요소의 조합을 통해 수행됩니다.

 core rider events session_id is not null: # check name metadata: id: 90bde4fa-148b-4f06-bd5f-f15b3d2ad759 ownership_slack: #dispatch-service-dev tags: [rides, core-data, high-priority] query: type: dsl data_source_id: hive.core.rider_events filters: - session_id = null condition: type: fixed_threshold max: 0 notifier_group: pagerduty_policy: dispatch-service email: [email protected]

Verity는 완전한 데이터 스키마를 정의하기보다는 데이터 품질 검사를 정의하고 시행하는 데 주로 중점을 두고 있습니다.

스키마 유효성 검사는 새로운 개념이 아닙니다. JSON 스키마, 프로토콜 버퍼, Avro 또는 Parquet와 같은 스토리지 형식과 같은 이벤트 기반 시스템에서 이벤트 데이터 스키마를 정의하기 위한 여러 가지 방법이 있습니다. 최적의 선택은 기술 스택, 사용량 및 특정 요구 사항에 따라 다릅니다.

데이터 스키마는 데이터 개체 또는 테이블 행의 전체 구조를 정의하는 데 유용하지만 데이터 배포, 비즈니스 규칙, SLA 및 임계값과 같은 소비자와 관련된 보다 정교한 유효성 검사를 캡처하는 데는 부족합니다.

데이터 계약은 구문 오류 식별에 초점을 맞춘 스키마 유효성 검사 그 이상입니다. 저는 개인적으로 JSON 스키마가 이러한 구조적, 구문적 검증 기능을 직렬화 또는 저장 문제와 효과적으로 분리하여 더 적합하고 읽기 쉬운 옵션을 제공한다고 생각합니다.

그러나 의미 오류를 해결하고 데이터 정확성을 높이기 위해 데이터 검사를 정의하는 효과적인 수단을 사용하면 데이터 계약의 다른 측면을 정의할 수 있습니다.

Verity DSL이 활용되는 곳이 바로 여기입니다.

의미론적 검증 외에도 데이터 계약은 주목할 만한 또 다른 중요한 측면을 제공합니다.

구문론적 관점에서 유효성 검사는 관련된 소비자나 생산자에 관계없이 일관되게 유지됩니다. 유효성 검사 규칙 집합은 특정 소비자나 생산자에 묶여 있지 않으며 단일 스키마로 한 번에 정의할 수 있습니다.

그러나 Verity 데이터 계약 DSL은 작은 독립 규칙을 정의하는 보다 세부적인 세부사항을 제공하며 이는 특히 이러한 맥락에 매우 적합합니다. 즉, 데이터의 의미론적 의미와 사용법은 특정 소비자에 따라 다릅니다. 또한 모든 소비자가 객체의 모든 속성을 활용할 필요는 없습니다. 그들의 기대는 다릅니다. 이것은 그들이 모순적이라는 것을 의미하는 것이 아니라(확실히 문제가 될 것입니다) 오히려 보완적이고 구별되는 것임을 의미합니다.

따라서 모든 소비자가 협력하여 결합할 때 데이터 품질의 의미론적 중요성에 대한 포괄적인 이해를 제공할 수 있는 고유한 규칙을 설정할 수 있도록 하는 것이 매우 중요합니다.

그리고 특히 저에게 공감을 불러일으키는 것은 바로 이러한 협력적 측면입니다. 참아주십시오. 이것은 무리한 것처럼 보일 수 있지만 제 관점에서는 언급할 가치가 있습니다. :)

데이터 교환을 통해 다양한 팀(생산자와 소비자)이 효과적으로 협업할 수 있습니다. 기존 소프트웨어 개발의 API와 마찬가지로 이러한 데이터 교환에 대한 공유된 이해를 구축하는 것이 가장 중요합니다. 마이크로서비스 아키텍처에서는 소비자 중심 계약(CDC)으로 알려진 협업 테스트 접근 방식이 등장했습니다. 여기서 소비자는 생산자가 제공하는 API의 예상 동작을 정의합니다. 제작자는 새 버전을 출시하기 전에 이러한 계약을 확인할 책임이 있습니다.

데이터 계약도 비슷한 협력 정신을 공유한다고 생각합니다. 데이터 검증은 릴리스 시점이 아닌 실제 데이터에 대해 수행되고 릴리스를 차단하지 않지만 협력을 기반으로 하며 데이터 생산자와 소비자 간의 팀워크를 장려합니다. 저는 이러한 협업적 접근 방식이 데이터 품질을 향상시키는 핵심이며 프로세스에 더욱 통합되어야 한다고 굳게 믿습니다.

글쎄요, 저는 평행선 그리기를 좋아해요…

실제로 이러한 협력적 측면은 Lyft의 진실성 헌장의 일부로도 언급된 것입니다.

VerityUI는 Verity 홈페이지를 통해 효율적인 데이터 검색 경험을 제공합니다. 검사 정의 메타데이터에 대한 전체 텍스트 검색을 통해 사용자는 현재 시행 중인 모든 검사와 해당 검사 결과를 볼 수 있습니다. 여기에는 팀 소유, 테이블 이름 및 태그와 같은 유용한 집계가 있습니다.

Verity 플랫폼 UI를 통해 소비자와 생산자 간에 데이터 계약 문제가 어떻게 공유되는지 완전히 명확하지는 않지만 대시보드를 통한 협업의 중요성은 확실히 인식하고 있습니다.

• 데이터 제품 인터페이스의 제작자는 예상하지 못한 다운스트림 손상을 부주의하게 유발하지 않는다는 것을 확신할 수 있습니다.

• 인터페이스 소비자는 인터페이스에 대한 의존도가 손상되지 않으며 앞으로도 손상되지 않을 것이라는 확신을 가질 수 있습니다.

Verity는 데이터 품질 검사를 정의하는 뛰어난 도구이지만 안타깝게도 오픈 소스는 아닙니다.

다행히도 유사한 기능을 제공하는 Soda Core라는 또 다른 오픈 소스 데이터 품질 프레임워크가 있습니다.

Soda Core는 데이터 엔지니어가 데이터 품질을 테스트할 수 있는 무료 오픈 소스 명령줄 도구이자 Python 라이브러리입니다. 사용자 정의 입력을 활용하여 데이터 소스의 데이터세트에 대한 검사를 실행하여 유효하지 않거나 누락되었거나 예상치 못한 데이터를 찾는 SQL 쿼리를 생성합니다. 검사가 실패하면 검사에서 "불량"으로 정의한 데이터가 표시됩니다.

데이터 세트를 스캔하는 동안 Soda Core는 사전 정의된 검사를 평가하여 유효하지 않거나 누락되었거나 예상치 못한 데이터를 식별합니다.

다음은 이전에 정의된 Verity DSL 테스트에 Soda.core 구문을 사용한 동등한 검사입니다.

 name: rider_events_session_id_check source: hive query: SELECT * FROM rider_events WHERE session_id IS NULL; raise_alert: true threshold: 10 action: slack message: "There are more than 10 rows that are null for the 'session_id' property in the 'rider_events' table. Please investigate this issue."

 soda run --check checks/rider_events_session_id_check.yaml

Soda Core는 데이터 품질을 보장하는 강력한 도구입니다. 데이터 문제가 비즈니스에 문제를 일으키기 전에 조기에 식별하고 해결하는 데 도움이 될 수 있습니다.

Soda Core는 Spark DataFrames와 원활하게 통합되어 스트리밍 데이터에 대한 데이터 품질 검사를 용이하게 할 수도 있다는 점은 주목할 가치가 있습니다.

Hive에 대한 Verity의 데이터 품질 검사는 정적 데이터 세트에 적용되지만 스트리밍 데이터에 대한 검사는 더 가볍고 효율적이어야 합니다.

데이터는 일반적으로 대기 시간이 매우 짧은 소규모 이벤트 배치로 처리되므로 실시간 확인 및 이상 탐지와 같은 특정 사용 사례에 적합합니다.

마지막으로 DeeQu, Great Expectations 등과 같은 다른 데이터 검증 도구도 사용할 수 있다는 점을 언급하겠습니다.

마무리하면서 데이터 품질 여정을 향상하기 위해 취할 수 있는 단계를 더 명확하게 이해하시기 바랍니다.

우리는 데이터 품질 개선을 위한 두 가지 서로 다른 접근 방식을 살펴보았으며, 각 접근 방식에는 고유한 장점과 방법론이 있습니다. 하나는 가시성과 관찰 가능성을 높이는 데 중점을 두고 데이터 생산자가 품질 기준을 높이도록 동기를 부여합니다. 다른 하나는 테스트 및 검증 우선 접근 방식을 통해 품질 표준을 높이는 데 우선순위를 둡니다. 둘 다 보완적입니다.

Verity는 단순히 데이터 검사를 정의하기 위한 DSL(도메인별 언어)이 아닙니다. 이는 데이터 실무자가 효과적으로 협업할 수 있도록 지원하는 중앙 집중식 플랫폼입니다. 이 플랫폼은 생산자와 소비자가 형식, 구조, 정확성을 포함한 데이터 품질 기대치를 조정하는 데 도움이 됩니다.

Verity의 데이터 계약 관리 기능은 보다 정교한 데이터 품질 요구 사항을 해결하기 위해 메타데이터 관리 및 검색과 같은 광범위한 기능 세트와 통합함으로써 더욱 향상될 수 있습니다.

Airbnb의 DQ 점수와 유사하게 Lyft의 Verity는 데이터 생산자와 소비자 간의 협업 피드백 루프를 조성합니다. Verity는 각 팀이 데이터 품질에 대한 주인의식을 갖도록 장려하고 권한을 부여함으로써 데이터 품질이 지속적으로 향상되는 지원 환경을 조성합니다.

이 기사가 유용하다고 생각하시나요? 나를 따라와 링크드인 , 해커눈 , 그리고 중간 ! 이 글을 공유하려면 👏해주세요!