Veri kalitesi kontrolü

1) Amaç ve prensipler

Neden: güvenilir raporlar (GGR/vergiler), dolandırıcılıkla mücadele ve RG modelleri, uyumluluk yüklemeleri, ürünler ve kişiselleştirme.

• Schema-first & Contracts: Sözleşme verilerini yayınlamak için tüm kaynaklar gereklidir.
• DQ-as-code: depodaki kurallar, sürümler, testler ve incelemeler.
• Observation-by-default: metrics/logging/lineage.
• Tasarıma göre gizlilik: PII minimum, maskeleme ve RLS/CLS.
• Maliyet bilincine sahip: kritik kuralların önceliklendirilmesi, akıllı örnekler.

2) Kalite ölçümlerinin taksonomisi

Tamlık - Gerekli alanların/satırların yüzdesi.
Geçerlilik-Maç türleri/aralıkları/referans kitapları.
Benzersizlik: yinelenen anahtarlar/olaylar yok.

Tutarlılık: referans bütünlüğü, iş değişmezleri

Doğruluk - "Gerçek" kaynağa yaklaşır (özet uzlaştırmalar).
Zaman Çizelgesi/Tazelik - Malzeme gecikmesi.
Lineage Integrity: Dönüşümlerin kökenini/sürümlerini korumak.

Kalite ve kritiklik KPI'ları (kritik/büyük/küçük) her etki alanı için tanımlanır.

3) Sözleşmeler ve planlar (gerçeğin kaynağı)

Veri sözleşmeleri: JSON Schema/Avro/OpenAPI/AsyncAPI, Registry tarafından barındırılmaktadır.
Kararlılık: geriye uyumlu değişiklikler - nullable ekleyerek; kırılma - yeni sürüm + çift giriş.
İzlenebilirlik: olaylarda - 'event _ id', 'trace _ id', 'schema _ version', 'source'.

4) DQ-as-code: artefakt yapısı

/dq/
rules/
silver. payments. yaml gold. ggr_daily. yaml checks/
sql/
python/
policies/
severities. yaml notifications/
routes. yaml

Kurallar: bildirimsel YAML/SQL;

Önem derecesi: eşleme - uyarı kanalları/tırmanma seviyeleri;

CI: devre bağlantıları, uyumluluk testleri, kuru çalıştırma/simülatör.

5) Örnek Kurallar (YAML)

yaml table: silver. payments owner: data-payments slo:
freshness_minutes: 15 completeness_percent: 99. 5 rules:
- name: amount_positive severity: critical type: range column: amount min: 0. 01
- name: currency_in_whitelist severity: major type: in_set column: currency set: [EUR, USD, GBP, TRY, BRL]
- name: unique_tx severity: critical type: unique columns: [transaction_id]
- name: fk_user_exists severity: critical type: foreign_key column: user_pseudo_id ref_table: dim. users ref_column: user_pseudo_id
- name: ts_monotonicity severity: minor type: temporal expression: "ts between date_sub(now(), interval 90 day) and now()"

6) SQL testleri (örnekler)

Anahtarların benzersizliği

sql
SELECT transaction_id, COUNT() AS c
FROM silver. payments
GROUP BY transaction_id
HAVING COUNT() > 1;

Gerekli Alan Bütünlüğü

sql
SELECT COUNT() AS nulls
FROM silver. payments
WHERE amount IS NULL OR currency IS NULL OR ts IS NULL;

Referanslar/Tutarlılık

sql
SELECT p. currency
FROM silver. payments p
LEFT JOIN ref. currencies r ON p. currency = r. code
WHERE r. code IS NULL;

7) DQ Akışı (gerçek zamanlı)

Ingest-validation: şema doğrulama, boyut sınırları, türler ve enum'lar.
Yayın içi kontroller: dedup '(event_id, kaynak)', izin verilen gecikme, para birimi/tutar geçerliliği.
Sınırlar: kritik hatalar - DLQ + uyarısı; Kritik değil - etiket, ancak atla ('dq _ flag' bayrağı ile).
Metrikler: taraflara göre tamlık/gecikme/dup oranı.

8) Hataları ve istisnaları işleme

DLQ/Karantina: Hasta kayıtları tutulur, düzeltme için kullanılabilir.
İstisna kayıtları: hariç tutma kartı (sahibi, tarihi, nedeni, alanı).
Otomatik geri dönüş: Ekran kasasının son doğru anlık görüntüsünü kullanın.
SLA'nın kapatılması: kritik - 24-48 saat ≤; Major - ≤ 5 çalışan günü.

9) Gizlilik ve uyum ile koordinasyon

PII minimizasyonu: analitik katmanlarda "ham" PII'yi kontrol etmeyin; Takma ad kullan.
RLS/CLS-Kontrolleri alan maskelemeye dayalı olarak gerçekleştirilir.
Bölgeselleştirme: Kurallar "yargı yetkisini" (EEA/UK/BR) dikkate alır.
Yasal Bekletme: Arşivlerin bekletmenin bir parçası olarak yeniden yazılmaması.

10) Gözlemlenebilirlik, SLI/SLO ve uyarılar

• Tazelik p95 (Gümüş): ≤ 15 dk
• Bütünlük (kritik tipler): ≥ 99. 5%.
• Geçerlilik (şema): ≥ 99. 9%.
• Yinelenen oran: ≤ 0. 1%.
• DQ olayı MTTR: ≤ 24-48 ч.

Uyarılar: kritik, kenar yumuşatma, bakım pencereleri için çağrı cihazı.

11) Gösterge Panoları (minimum set)

Tazelik/Tamlık Alana ve pazara göre ısı haritası.
Olay oranına ve düzeltme maliyetine göre üst N tabloları.
DQ hunisi: yutmak - gümüş - altın (kayıp/düzeltme).
Kritik raporlar için Linedge haritası (regülatör/GGR/RG/AML).
"Eski" şemaların ve istemcilerin haritası (SDK/şema sürümleri).

12) Süreçler ve RACI

R (Sorumlu): Veri Mühendisliği (tablolardaki kurallar), Alan Sahipleri (anlambilim).
A (Sorumlu): Veri/CDO Başkanı.
C (Consulted): Uyumluluk/Yasal/DPO, Mimari, SRE.
I (Informed): BI/Продукт/Маркетинг/Финансы/Операции.

Rule lifecycle: offers> review> "dark run"> inclusion> monitoring> retrospective.

13) Uzlaşma ve Doğruluk

Checksums/işlemler: OLTP/sağlayıcıları (PSP/KYC) ile kasa.
İki döngülü karşılaştırmalar: seçici doğrulama için bağımsız boru hattı.
Toleranslar metriklere göre yüzde eşikleridir (örn. GGR varyansı ≤ 0. 2%).
Günlük eylemler: denetim uzlaşma raporları.

14) Maliyet ve önceliklendirme

Kritik kuralları daha sık çalıştırın (akış/saatlik), küçük - günlük.
Ağır tablolar için getirmeler ve maddeleştirilmiş kontroller kullanın.
Maliyet/sorgu ve maliyet/GB izleyin, kümeleme/endeksleme uygulayın.
Takımlar bağlamında DQ için bir bütçe ayırın (ters ibraz).

15) Altın vitrinler için şablonlar (GGR Günlük örnek)

yaml table: gold. ggr_daily owner: fin-analytics slo:
ready_by_local_time: "06:00"
rules:
- name: ggr_not_negative severity: critical type: range column: ggr min: 0. 0
- name: market_known severity: major type: in_set column: market set_ref: ref. markets
- name: fx_source_present severity: major type: not_null column: fx_source
- name: completeness_by_market severity: critical type: completeness partition_keys: [event_date, market]
expected_rows_expression: "ref. expected_activity(event_date, market)"

16) Kalite Olayları: Yönetim ve İletişim

Biletleme: Ekli seçimler ve metriklerle görevlerin otomatik olarak oluşturulması.
İletişim şablonları: etkilendiğinde ürün sahiplerini/düzenleyicileri bilgilendirmek.
Ölüm sonrası: kök neden (şema sürüklenmesi, yukarı akış hatası, yük), CAPA eylemleri, "regresyon dönüşü" kontrolü.

17) Uygulama Yol Haritası

1. Kritik tabloların kataloğu (Ödemeler, Oyun, GGR, Uyumluluk).

2. 10-15 anahtar kontrolleri + CI doğrulaması için YAML kuralları.

3. Tazelik/Bütünlük panosu ve kritik için uyarılar.

4. DLQ/Quarantine + runbook düzeltmeleri.

• Kural uzantısı (FK/doğruluk), kuru çalışma simülatörü, A/B kapanımları.
• Soy entegrasyonu, istisna düzenlemeleri ve SLA'lar.
• "Gürültülü" kaynaklar için yutmak üzerine DQ akışı.

• Dokümantasyonun kurallara göre otomatik olarak oluşturulması, maliyet ölçütleri.
• "Kontrol konturları" (bağımsız mutabakat), haftalık retrospektif.
• Rule-as-Code platform SDKs, standart etki alanı kontrollerinin bir kaydı.

18) Satış öncesi kontrol listesi

• Kayıt Defterindeki sözleşmeler ve şemalar, uyumluluk testleri geçer.
• YAML kuralları dondurulmuş, önem/tırmanma atanmış.
• Gösterge panoları ve uyarılar aktiftir; SLO'lar tanımlanmış ve kabul edilmiştir.
• DLQ/Karantina mevcuttur, çalışma kitapları belgelenmiştir.
• Yasal/Uygunluk ile kararlaştırılan istisna/uzlaşma prosedürleri.
• Denetimlerin maliyetinin ve ağır taleplerin sınırlarının ölçülmesi.

19) Sık yapılan hatalar ve bunlardan nasıl kaçınılacağı

Sözleşmesiz ham veriler: şema-ilk ve tüketici testlerini girin.
"Manüel" kontroller: DQ-as-code ve CI'ye çevrilir.
Önceliklendirme yok: kritik/büyük/küçük ve uyarı kanallarını ayırın.
DLQ yoktur: hatalarla çalışacak hiçbir şey yoktur - karantina ekleyin.
Maliyeti göz ardı edin: Profil sorguları, materyalizasyon kullanın.
Ölüm sonrası yok: hatalar tekrarlanır - CAPA ve regresyon kontrolüne girin.

20) Alt satır

Veri kalite kontrol sistemi bir dizi dağınık kontrol değil, yönetilen bir programdır: sözleşmeler ve şemalar, kod olarak DQ, gözlemlenebilirlik ve SLO, olay ve uzlaşma disiplini. Bu makaleyi takip ederek, düzenleyici raporlama, ürün çözümleri ve gerçek zamanlı risk dedektörleri için yeterli tekrarlanabilir, doğrulanabilir ve uygun maliyetli veriler alacaksınız.