Veri Kalitesini Geliştirme: Lyft ile Veri Sözleşmelerini Keşfetmek

Veri Kalitesi serimin 2. bölümü gibi görünüyor!

Önceki bir gönderide Airbnb'nin teşvikler yoluyla veri kalitesini artırma stratejisini incelemiştim. Veri üreticileri ve tüketicileri arasında ortak bir anlayış oluşturmak ve gerçek bir sahiplenme duygusunu teşvik etmek için tek bir puan ve net puanlama kriterleri uyguladılar.

Lyft artık farklı bir yaklaşım benimsiyor; aynı şeyi farklı şekilde denemek yerine veri kalitesinin farklı yönlerine odaklanıyor. Ve Lyft'in stratejisi Airbnb'nin çabalarını tamamlıyor. Airbnb'nin DQ puanını (veya benzer herhangi bir puanı) veri kalitesini yükseltmeye yönelik çeşitli girişimleri birleştirmenin etkili bir yolu olarak görsem de Lyft bu zorlukla farklı bir açıdan mücadele ediyor.

Airbnb'nin DQ puanı, veri kalitesinin somut bir görselleştirilmesini sağlamak için değerli bir araç görevi görür. Temel olarak, veri kalitesini artırmaya yönelik herhangi bir girişimin bu puan üzerinde fark edilebilir bir etki göstermesi gerekir. Öte yandan Lyft, verileri belirli kalite kriterlerine göre test edip doğrulayarak kaliteyi proaktif olarak artırmak için olası bir girişim sunuyor.

Temel olarak veri kalitesi yaşam döngüsünde farklı bir noktadır. Kaliteyi artıracak bir mekanizmanın devreye sokulması, başlangıçta kalitenin ölçülebilmesini gerektirir.

Airbnb'nin odak noktası veri kalitesini ölçmek ve gözlemlemek , üreticinin bu kaliteyi artırma ve "iyi görünme" konusundaki ilgisine güvenmek olsa da Lyft farklı bir yaklaşım benimsiyor. Lyft, veri kalitesini aktif olarak test etmeye ve doğrulamaya önem vererek hem üreticilere hem de tüketicilere kaliteyi etkili bir şekilde iyileştirme ve kontrol etme araçlarını sağlar.

Toplu olarak bu yaklaşımlar, yaşam döngüsü boyunca veri kalitesini ele almak ve geliştirmek için kapsamlı bir strateji sağlar.

Bu nedenle Lyft'in yaklaşımına daha yakından bakmak özellikle ilgimi çekti.

İlgimi çeken bir diğer faktör de mikro hizmet mimarisinin ortaya çıkmasıyla birlikte temel yazılım mühendisliğinde uzun yıllardan beri kullanılan test etme, daha spesifik olarak sözleşme testidir. Ancak veri sözleşmeleri, veri mühendisliği alanında daha yeni bir şeydir ve yüksek kaliteli veri hatları oluşturma yolunda atılacak zirve veya nihai adımlardan biri olarak görülür. Bu nedenle Lyft'in yaklaşımını daha detaylı incelemek ve bazı olası paralellikleri araştırmak istedim.

Belirtildiği gibi Airbnb ve Lyft'in yaklaşımları birbirini tamamlayıcı niteliktedir ve aynı hedefe ulaşmayı amaçlamaktadır: veri kalitesinin iyileştirilmesi.

Airbnb , veri kalitesinin 4 farklı yönünü ölçmeye ve geliştirmeye odaklanan DQ puanını geliştirmiştir:

DQ Puanı, tam kapsam, otomasyon, eyleme geçirilebilirlik, çok boyutluluk ve geliştirilebilirlik gibi yol gösterici ilkelere sahiptir. Doğruluk, Güvenilirlik, Yönetim ve Kullanılabilirlik gibi boyutları vardır.

Lyft Verity, 5 boyutta veri kalitesini artırmak için tasarlanmış bir platformdur

Veri kalitesini , anlamsal doğruluk, tutarlılık, tamlık, benzersizlik, iyi biçimlendirilmişlik ve zamanlılık gibi yönleri kapsayan, verilerin amaçlandığı şekilde ne kadar iyi kullanılabileceğinin ölçüsü olarak tanımlar.

Lyft Verity tarafından geliştirilen 5 veri kalitesi özelliği ile Airbnb'nin DQ puanıyla ölçülen 4 veri kalitesi boyutu arasında paralellikler kurmak kolaydır. Örneğin, Zamanlılık gibi yönler kesinlikle DQ puanının Güvenilirliğine katkıda bulunurken Doğruluk, verilerin semantik doğruluğuna, eksiksizliğine ve benzersizliğine bağlı olacaktır. Kullanılabilirlik puanı ise diğer faktörlerin yanı sıra verilerin tutarlılığından etkilenir.

Lyft's Verity anlamsal doğruluk, tutarlılık, tamlık, benzersizlik, iyi biçimlendirilmişlik ve güncellik ile ilgili kontrollerin tanımlanmasına odaklanır. Önce test ve doğrulama yaklaşımını takip ederken Airbnb'nin birleşik DQ puanı, veri kalitesinin çeşitli boyutlar aracılığıyla değerlendirilmesini vurgular.

DQ puanını bu son şemaya dahil etmek isteseydik, Uyarı/Hata Ayıklama adımlarının yanında olurdu.

Airbnb'nin DQ puanı , Doğruluk, Güvenilirlik, Yönetim ve Kullanılabilirlik açılarından veri kalitesini değerlendirmek için farklı sinyaller kullanır.

Ayrıca kaliteyi daha doğrudan ölçen (Midas sertifikasyonu, veri doğrulama, hatalar, SLA'lar, otomatik DQ kontrolleri vb.) bir dizi girdi sinyalimiz vardı, oysa diğerleri daha çok kalitenin vekilleri gibiydi (örneğin, geçerli sahiplik, iyi yönetişim hijyeni, döşeli yol araçlarının kullanımı).

Daha önce tartışıldığı gibi Airbnb'nin DQ puanı ile Verity arasında muhtemelen örtüşmeler vardır. Airbnb ölçüm ve puanlamayı vurgulayarak veri kalitesini sağa doğru itmeye odaklanırken Lyft Verity, kontrol tanımı yapılandırmalarını, test ve doğrulama süreçlerini sola kaydırarak proaktif bir yaklaşım benimsiyor ve veri kalitesinin proaktif olarak iyileştirilmesini vurguluyor.

Şimdi asıl ilgi alanım sol tarafta, kontrol tanımı yapılandırmaları, test etme ve doğrulama yönleridir.

Lyft veri kalitesi testini süreçlerine nasıl entegre ediyor?

Öncelikle yürütme yollarını inceleyelim.

Şu anda Lyft Verity öncelikle Hive veri ambarında depolanan verilerin kalitesini sağlamaya odaklanmıştır. Ancak gelecekte diğer veri kaynaklarını destekleyecek şekilde yeteneklerini genişletme planları var.

Hive'ı bir veri çalışma evi olarak adlandırsalar da aslında onu hibrit bir veri depolama çözümü olarak kullandıklarını, yapılandırılmış, işlenmiş ve temizlenmiş veriler (gümüş katman) için bir veri ambarı olarak çalıştıklarını ve aynı zamanda ham olay için bir veri gölü görevi gördüklerini unutmayın. veriler (bronz katman).

Hive'daki düşük veri kalitesi, hatalı deney ölçümlerine, hatalı makine öğrenimi özelliklerine ve kusurlu yönetici kontrol panellerine neden oldu.

Verity'nin kontrolleri, yalnızca yüksek kaliteli ham verilerin Hive'da türetilmiş veriler olarak işlenmesini ve saklanmasını sağlamak için Airflow DAG'ye entegre edilebilir.

Veri üreticileri ve tüketicileri, veri kalitesi kontrollerini tanımlayabilir ve verileri üretildiğinde veya tüketilmeden önce doğrulayabilirler. Hava akışı veya Flyte .

…

VerityAirflowOperator, bir kontrol hatası durumunda DAG'yi durdurmak için engelleyici bir şekilde kullanılabilir ve böylece hatalı verilerin üretime ulaşması önlenir. Bu, “ Aşama-Kontrol-Değişim ” modeli: Aşamalı bir şemada veri oluştururuz, verileri bir engelleme operatörüyle doğrularız, ardından kalite kontrollerini geçerse üretime yükseltiriz.

Hem ham hem de türetilmiş verileri doğrulamak için kontroller manuel olarak gerçekleştirilebilir veya otomatik olarak programlanabilir.

Verity Planlanmış Kontroller herhangi bir veri düzenleme motorundan izole edilmiştir, bu nedenle Airflow veya Flyte tamamen kapalı olsa bile çalışmaya devam ederler. Bu, Hava Akışı Görevi hiç yürütülmediğinden kontrollerin uyarı vermemesiyle ilgili yaygın bir sorunu çözer.

Dolayısıyla, bir denetimi tetiklemenin esas olarak 3 temel yolu vardır: Airflow DAG'nin bir parçası olarak, manuel olarak veya Verity platformu/kullanıcı arayüzü aracılığıyla programlanmış olarak.

Mevcut kontrollerin, örneğin Hive'a girerken (veya hatta daha önce) verileri doğrulamak için gerçek zamanlı akış hatlarına (Flink + Kafka gibi) entegre edilebileceğine inanmıyorum.

Bu tür gerçek zamanlı kontrolün uygulanması, tutarsızlıkların anında tespit edilmesini sağlayarak depolama ve işleme maliyetlerinin azalmasına ve genel veri kalitesinin artmasına yol açacaktır.

Kapsamlı olmak gerekirse, Verity kontrolleri, bazı API'ler aracılığıyla kontrolleri programlı olarak tetiklemek için kullanılabilen bir API sunucusu aracılığıyla yönetilir.

Verity API Sunucusu — Bu hizmet, kontrollerin yürütülmesi, sonuçların sürdürülmesi ve alınmasıyla ilgili tüm harici API'leri yönetir. API Sunucusu herhangi bir kontrol yürütmez, bunun yerine Kontrol Kuyruğumuza bir mesaj yazar. SimpleQueueService (SQS).

Dolayısıyla, belki de bu işleri daha gerçek zamanlı bir şekilde, örneğin bir akış işinden veya hatta uzun bir süre boyunca Hive değişiklik veri yakalama (CDC) ile entegre ederek tetikleyebilirsiniz.

Ancak bu işler Airflow dışında yürütüldüğünde veri işleme işini engelleyemez; bunun yerine Kontrol Kuyruğuna gönderilen eşzamansız uyarılar oluşturacaklar. Bazı tüketiciler, bir kontrol başarısız olduğunda veri işlemenin ertelenmesini tercih ederken, diğerleri devam etmeyi ve bir uyarı almayı tercih eder.

Şimdi bu veri kalitesi testlerine bakalım.

rider_events.session_id hiçbir zaman boş olup olmadığını kontrol eden bir örneği burada bulabilirsiniz. Bu, sorgu ve koşul bileşenlerinin bir kombinasyonu aracılığıyla gerçekleştirilir.

 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, eksiksiz veri şemalarını tanımlamak yerine öncelikle veri kalitesi kontrollerini tanımlamaya ve uygulamaya odaklanır.

Şema doğrulama yeni bir kavram değildir. Olay tabanlı sistemlerde olay veri şemalarını tanımlamak için JSON Şeması, Protokol Tamponları, Avro veya Parquet gibi depolama formatları gibi çeşitli yöntemler mevcuttur. En uygun seçim teknoloji yığınınıza, kullanımınıza ve özel gereksinimlerinize bağlıdır.

Veri şemaları, veri nesnelerinin veya tablo satırlarının genel yapısını tanımlamak için değerli olsa da, veri dağıtımı, iş kuralları, SLA'lar ve eşikler gibi tüketicilere özel daha karmaşık doğrulama kontrollerini yakalamada yetersiz kalır.

Veri sözleşmeleri, sözdizimsel hataların belirlenmesine odaklanan şema doğrulamanın ötesine geçer. Kişisel olarak JSON Schema'nın burada daha uygun ve okunabilir bir seçenek sunduğunu ve bu yapısal ve sözdizimsel doğrulama yeteneklerini serileştirme veya depolama sorunlarından etkili bir şekilde ayırdığını düşünüyorum.

Ancak anlamsal hataları ele almak ve veri doğruluğunu artırmak için, veri kontrollerini tanımlamaya yönelik etkili bir araca sahip olmak, veri sözleşmelerinin diğer yönlerinin tanımlanmasına olanak tanır.

Verity DSL'in devreye girdiği yer burasıdır.

Anlamsal doğrulamanın ötesinde, veri sözleşmeleri dikkat edilmesi gereken başka bir önemli husus daha sunmaktadır.

Sözdizimsel açıdan bakıldığında, doğrulama kontrolleri ilgili tüketici veya üreticiden bağımsız olarak tutarlı kalır. Doğrulama kuralları kümesi herhangi bir belirli tüketiciye veya üreticiye bağlı değildir ve tek bir şema olarak tek seferde tanımlanabilir.

Bununla birlikte, Verity veri sözleşmesi DSL, küçük bağımsız kuralları tanımlayan daha ince bir ayrıntı düzeyi sunar ve bu, özellikle bu bağlama çok uygundur: Verilerin anlamsal anlamı ve kullanımı, belirli tüketiciye bağlı olarak değişir. Ayrıca her tüketicinin bir nesnenin tüm özelliklerinden faydalanmasına gerek yoktur. Beklentileri farklı. Bu onların çelişkili olduğu anlamına gelmez (ki bu kesinlikle bir sorun olacaktır), daha ziyade tamamlayıcı ve farklı oldukları anlamına gelir.

Bu nedenle, tüm tüketicilerin işbirliği içinde birleştirildiğinde veri kalitesinin anlamsal öneminin kapsamlı bir şekilde anlaşılmasını sağlayabilecek benzersiz kurallar oluşturmasına izin vermek oldukça önemlidir.

Ve bende özellikle yankı uyandıran da bu işbirlikçi yön. Sabırlı olun, bu biraz abartı gibi görünebilir ama benim bakış açıma göre bahsetmeye değer. :)

Veri alışverişi, farklı ekiplerin (üreticiler ve tüketiciler) etkili bir şekilde işbirliği yapmasına olanak tanır. Bu veri alışverişlerine ilişkin ortak bir anlayış oluşturmak, tıpkı geleneksel yazılım geliştirmedeki API'ler gibi çok önemlidir. Mikro hizmet mimarilerinde, tüketicilerin üreticiler tarafından sağlanan API'lerin beklenen davranışını tanımladığı, tüketici odaklı sözleşmeler (CDC) olarak bilinen işbirlikçi bir test yaklaşımı ortaya çıktı. Üreticiler, yeni versiyonları yayınlamadan önce bu sözleşmeleri doğrulamaktan sorumludur.

Veri sözleşmelerinin de benzer bir işbirlikçi ruhu paylaştığını düşünüyorum. Veri doğrulama, yayınlanma zamanı yerine gerçek veriler üzerinde gerçekleştirilse ve yayınları engellemese de işbirliğine dayalıdır ve veri üreticileri ile tüketiciler arasındaki ekip çalışmasını teşvik eder. Bu işbirlikçi yaklaşımın veri kalitesini iyileştirmenin anahtarı olduğuna ve sürece daha fazla entegre edilmesi gerektiğine kuvvetle inanıyorum.

Ben paralellikler kurmanın büyük bir hayranıyım…

Aslında bu işbirlikçi yönün Lyft'in doğruluk sözleşmesinin bir parçası olarak da bahsedilen bir şey olduğuna dikkat edin.

VerityUI, Verity Ana Sayfası aracılığıyla kolaylaştırılmış bir veri keşif deneyimi sağlar. Çek Tanımı Meta Verilerindeki tam metin aramamız, kullanıcıların halihazırda uygulanmakta olan tüm kontrolleri ve bunların Kontrol Sonuçlarını görmesine olanak tanır. Bu, ekibe sahip olma, tablo adı ve etiketler gibi yararlı toplamalara sahiptir.

Verity platformu kullanıcı arayüzü aracılığıyla veri sözleşmesi sorunlarının tüketiciler ve üreticiler arasında nasıl paylaşıldığı konusunda tam olarak net değilim, ancak kontrol panelleri aracılığıyla işbirliğinin öneminin kesinlikle farkındayım:

• Bir veri ürünü arayüzünün üreticisi, yanlışlıkla, beklemedikleri aşağı yönlü kırılmalara neden olmadıklarından emin olabilir.

• Arayüzün tüketicisi, arayüze olan güvenlerinin tehlikeye atılmadığından ve taviz verilmeyeceğinden emin olabilir.

Verity, veri kalitesi kontrollerini tanımlamak için dikkate değer bir araç olsa da ne yazık ki açık kaynak değil.

Neyse ki Soda Core adında benzer işlevsellik sağlayan başka bir açık kaynaklı veri kalitesi çerçevesi var.

Soda Core, veri mühendislerinin veri kalitesini test etmesine olanak tanıyan ücretsiz ve açık kaynaklı bir komut satırı aracı ve Python kitaplığıdır. Geçersiz, eksik veya beklenmeyen verileri bulmak amacıyla bir veri kaynağındaki veri kümeleri üzerinde kontroller çalıştıran SQL sorguları oluşturmak için kullanıcı tanımlı girişi kullanır. Kontroller başarısız olduğunda, çekte “kötü” olarak tanımladığınız verileri ortaya çıkarırlar.

Bir veri kümesinin taranması sırasında Soda Core, geçersiz, eksik veya beklenmeyen verileri belirlemek için önceden tanımlanmış kontrolleri değerlendirir.

Daha önce tanımlanan Verity DSL testi için Soda.core sözdizimini kullanan eşdeğer kontrolü burada bulabilirsiniz.

 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, verilerinizin kalitesini sağlamak için güçlü bir araçtır. İşletmenizde sorunlara yol açmadan önce veri sorunlarını erken tespit edip düzeltmenize yardımcı olabilir.

Soda Core'un Spark DataFrames ile sorunsuz bir şekilde entegre olarak veri akışına yönelik veri kalitesi kontrollerini de kolaylaştırabileceğini belirtmekte fayda var.

Verity'nin Hive'a yönelik veri kalitesi kontrolleri statik veri kümelerine uygulanırken, akış verilerine yönelik kontrollerin daha hafif ve verimli olması gerekir.

Veriler genellikle çok düşük gecikme süresiyle küçük olay grupları halinde işlenir; bu da onları gerçek zamanlı kontroller ve anormallik tespiti gibi özel kullanım durumları için uygun hale getirir.

Son olarak DeeQu, Great Expectations gibi başka veri doğrulama araçlarının da bulunduğunu belirtelim…

Bitirirken, veri kalitesi yolculuğunuzu geliştirmek için atabileceğiniz adımları daha iyi anladığınıza inanıyorum.

Veri kalitesinin iyileştirilmesine yönelik, her birinin kendine özgü güçlü yönleri ve metodolojileri olan iki farklı yaklaşım gördük. Bunlardan biri görünürlüğü ve gözlemlenebilirliği artırmaya odaklanarak veri üreticilerini kalite çıtasını yükseltmeye motive ediyor. Diğeri ise önce test etme ve doğrulama yaklaşımı yoluyla kalite standardını yükseltmeye öncelik verir. Her ikisi de tamamlayıcıdır.

Verity yalnızca veri kontrollerini tanımlamak için kullanılan alana özgü bir dil (DSL) değildir; veri uygulayıcılarının etkili bir şekilde işbirliği yapmasına olanak tanıyan merkezi bir platformdur. Bu platform, üreticilerin ve tüketicilerin format, yapı ve doğruluk dahil olmak üzere veri kalitesi beklentileri konusunda uyum sağlamasına yardımcı olur.

Verity'nin veri sözleşmesi yönetimi yetenekleri, daha karmaşık veri kalitesi ihtiyaçlarını karşılamak için meta veri yönetimi ve keşfi gibi daha geniş bir özellikler kümesiyle entegre edilerek daha da geliştirilebilir (geliştirilir mi?).

Airbnb'nin DQ puanına benzer şekilde Lyft'in Verity'si, veri üreticileri ve tüketicileri arasında işbirliğine dayalı bir geri bildirim döngüsünü teşvik eder. Verity, her ekibi veri kalitesini sahiplenmeye teşvik ederek ve güçlendirerek, veri kalitesinin sürekli olarak iyileştirildiği destekleyici bir ortam geliştirir.

Bu makaleyi faydalı buldunuz mu? Beni takip et LinkedIn , Hackernoon , Ve Orta ! Lütfen bu makaleyi paylaşmak için 👏!