GH GambleHub

Veri kaynağı

Soy

1) Soyun ne olduğu ve neden gerekli olduğu

Data Lineage, "verilerin nereden geldiği, nasıl dönüştürüldüğü, nerede ve kim tarafından kullanıldığının" resmi bir kaydıdır. Sonuç, veri sistemini anlaşılabilir ve denetlenebilir kılan niteliklere (zaman, sürümler, sahipler, dönüşümler, erişim politikaları, kalite) sahip yönlendirilmiş bir bağımlılık grafiğidir.

İş değeri:
  • Metriklerin şeffaflığı (finans, ürün, risk): "Neden X sayısı = 1.234? ».
  • Değişikliklerin hızlı etki analizi (şema/iş): "Eğer kırılırsa ne kırılacak"....
  • Uyumluluk ve denetim (GDPR/ISO/SOC): kanıtlanabilir saha yolu.
  • Onboarding hızlandırılması ve azaltılması (self servis bilgisi).
  • Kalite iyileştirme: Riskin daha yüksek olduğu hedefli denetimler.

2) Kapsama alanları ve detay seviyeleri

Akış seviyesi (boru hattı/iş): Hangi işler/orkestratörler veri kümeleri üretti.
Veri kümesi düzeyi (tablo/görünüm/konu/dosya): girdiler - çıktılar, sürümler/anlık görüntüler.
Sütun/özellik düzeyi - her alanın nasıl hesaplandığı, hangi kaynaklardan.
Tüketim katmanı: BI raporları, API'ler, ML modelleri, panolar ve uyarılar.

Kritik varlıklar için (para, düzenleme), sütun düzeyinde detaylandırma gereklidir.

3) Lineage Veri Modeli - Anahtar Varlıklar

Veri kümesi: '{urn, type, schema, owners, pii_class, retention, tags}'

İş/Görev: '{urn, code_ref, version, runtime, schedule, owners}'

Run/Execution: '{run _ id, job_urn, start/end, status, inputs [], outputs [], code_sha, infra}'

Alan: '{dataset _ urn, name, type, derivation}' (derivation - expression/AST/operator).

Politika: '{dataset _ urn/field, access_rules, maskeleme, consent_scope}'

Kalite Kontrolü: '{check _ id, kapsam, kural, önem, sonuç}'

4) Lineage kaynakları: aktif vs pasif montaj

Active (event-based): Orchestrators/engines (Spark/DBT/SQL engines/Kafka) enstrümantasyonu, "job started/finished, input/outputs, column-mapping" etkinliklerini yayınlamak için kullanılır.

Artıları: doğruluk, alaka düzeyi, ayrıştırma sonrası minimize etme.
Pasif (çıkarım): DAG parsim, SQL/DDL/log istekleri, dizin/depolama günlükleri; Bağımlılıkları geriye dönük olarak inşa edin.

Artıları: hızlı miras kapsamı; Eksileri: sütun düzeyinde daha düşük doğruluk.

Genellikle bir melez kullanılır: mümkün olduğunda aktif olaylar ve "sigorta şebekesi'olarak pasif analiz.

5) Çözüm mimarisi (referans)

Producers (orchestrators/engines)? Lineage event bus? Normalizer? Graph storage? Index/search? UI/API/alerts? Export/catalog.

Olaylar: Birleşik (job/run/dataset/column-lineage), URN'ler ve semantik sürümlerle.
Grafik depolama: sütun düzeyinde grafik (örneğin, bir grafik veritabanına veya ilişkisel + ters dizine dayalı).
UI: En kısa yolların etkileşimli görselleştirilmesi, etki/kök nedeni, kenarlarda ve düğümlerde "kaliteli sinyaller".
Entegrasyonlar: veri kataloğu, kalite sistemi (DQ), erişim kontrolü (ABAC), denetim (yalnızca ekleme günlükleri).

6) Tanımlayıcılar ve sürüm oluşturma

Her veri kümesi/iş/alan için URN/Global ID: platform/ad alanı/ad/sürüm dahil olmak üzere kararlı, insan tarafından okunabilir.
SchemaVersion ve kod sürümü (kod SHA, görüntü özeti).
Zaman yolculuğu soyu: araştırmaların tekrarlanabilirliği.

7) Sütun düzeyinde soy: nasıl güvenilir olunur

AST yapımı ve takma adların normalleştirilmesi/CTE/blizzard ile SQL ayrıştırma.
Dönüştürme kodundaki ek açıklamalar (DBT testleri, ilkel yorumlar, UDF-meta veriler).

Motorlardan gelen olaylar: belirleme "hedefi. col = f (src. a, src. b) "

Anlamsal kurallar: UDF/aggregation opses "kayıplı" (granülarite kaybıyla) veya "hassas korumalı" (PII etiketlerini aktarır) olarak işaretlenir.

8) Soyu gizlilik ve güvenliğe bağlamak

Tasarıma Göre Gizlilik: alan etiketleri 'pii _ class', 'consent _ scope', 'retention'. Sütunları tanıtırken, etiketler kurallara göre iletilir (örneğin,'e-posta - hash_email' PII kaynaklı kalıntılar).
PII tokenization: soy, tokenization/detokenization fact ve token servis düğümlerini depolar; Herhangi bir detokenizasyon bir denetim olayıdır.
Şifreleme: AEAD/FPE alanları için soy, "kripto durumunu've anahtar alanını (kiracı/kapsam) - anahtar ifşası olmadan yakalar.
Denetim ve WORM - soy olayları ve politika değişiklikleri değiştirilemeyen bir günlükte saklanır (yalnızca karma zincirlerle eklenir).

9) Veri kalitesi ve soy tabanlı SLO'lar

Kenarları denetler: tazelik, bütünlük, benzersizlik/anahtarlar, dağılımların sürüklenmesi.
SLO/SLI: "Fino-rapor metriklerini besleyen işlerin %95'i 06:00 UTC ≤ tamamlandı".
Kök neden: grafik + yürütme süreleri'ilk kırık düğüm'ün hızlı bir tanımını verir.

10) Etki analizi ve değişim yönetimi

Şema/mantıkta planlanan bir değişiklik olması durumunda: aşağı yönde (aşağı yönde) sütunla - etkilenen raporların/modellerin/API istemcilerinin bir listesi.
Değişiklik politikasının kırılması: Aşağı akış eserleri sahiplerinin zorunlu bildirimi, ödemesiz dönem, paralel sürümler ('v1'/' v2') ve gün batımı-tarih bayrağı.
Bir tüketici listesi ve bir geçiş kontrol listesi ile otomatik PR/bilet.

11) Orkestratörler ve motorlarla entegrasyon

Orkestratörler: Giriş/çıkışları olan 'RunStarted/RunCompleted' etkinlikleri işten önce/sonra yayınlanır.
SQL/ELT: Gerçek yürütme planını ve sütun eşlemesini elde etmek için motorlara (depo, lakehouse) konektörler.
Stream-processing: mesajların soyağacı (topic - topic, key/headers), Avro/Protobuf şemaları, kayıt yoluyla şemaların evrimi.
ML: soy özellikleri/veri kümeleri, model sürümleri, eğitim eserleri, özellik kaynakları.

12) Etiket yayılım kurallarının modellenmesi (veri sözleşmeleri)

Veri kümesi sözleşmesi: şema + alan semantiği (anahtarlar, PII, toplanabilirlik, lisanslar/yasal dayanaklar, saklama).

Yayılma kuralları:
  • 'SELECT a, b FROM T' - 'A, b' etiketlerini taşıyın.
  • 'hash (e-posta)' - detokenizasyon yasak olan 'PII-türevi (takma adlı)' etiketi.
  • 'SUM (miktar)' - bireysellik kaybı; Sonuç alanında join'lere izin verilmez.
  • Sözleşmeler CI'da (uygunsuzluk durumunda engelleyici) doğrulanır ve ihlaller denetimdeki olaylardır.

13) Performans ve ölçek

Soy olaylarının artımlı enjeksiyonu; '(run_id, job_urn)'ile veri tekilleştirme.
Sütun depolama: sıcak indeksin ayrılması (son 30-90 gün) ve arşiv; Anlık görüntüler.
Sık gelen istekler için yolları önbelleğe alma ("altın" metriklere giden kısa yollar).
Neimspaces/kiracılar tarafından sharding; "Canavar düğümlerine" karşı koruma (fan çıkışı sınırlaması).

14) Görselleştirme ve UX

Modlar:
  • Metriğe giden yol: "Metriğin birleştirildiği yol".
  • Kaynaktan gelen etki: "Değişiklikten kim etkilenecek".
  • Alan soyu: "Alan nasıl hesaplanır".
  • Kaplamalar: iş durumları, kalite, PII etiketleri, retentions, sahipleri.
  • Eylemler: bir sözleşme açın, geçiş için bir bilet oluşturun, uyarıları değiştirmek için abone olun.

15) Grafiğe erişim güvenliği

ABAC: Düğüm/kenar görünürlüğü kiracılar/roller ile sınırlıdır.
Redaksiyon: Eğitimsiz roller için hassas alan adlarını UI'de gizleme (veya takma adlar).
API soy olayları için mTLS/OIDC servis kimlikleri ile imzalanır.
WORM ve okuma kontrolü: Kritik grafik bölümlerini okumak da günlüğe kaydedilir.

16) Operasyon: SLO, izleme, uyarılar

Grafik SLO: olay gecikmesi <5 dk; Kapsama bütünlüğü> kritik boru hatlarının %98'i; "Altın metriklerin" %100'ü sütun düzeyinde soyağacına sahiptir.
Uyarılar: zincir kırılması, tamamlanma olayları olmadan çalıştırma, tutarsız şemalar, yetim veri kümeleri, fan büyümesi/döngüleri.
Raporlar: haftalık "soy kapsama durumu", en iyi 10 risk düğümü.

17) Gizlilik ve uyumluluk (paketler)

GDPR/PbD: Etiket olarak depolama işleme bazları ve retentions; Lineage, hızlı DSAR yol bulma ve karşılık gelen segmentlerin basamaklı kripto silme yoluyla "silme hakkı" sağlar.
Gizli yönetim: hammaddelere erişim kaynakları asla açık kredi olarak soyağacına girmez; Yalnızca rol/politika referansı saklanır.
Denetim/değiştirilmemiş günlükler - tüm soy olayları imzalanır ve yalnızca ek bilgi havuzuna sabitlenir (ilgili makaleye bakın).

18) Kontrol listeleri

Başlamadan önce:
  • Veri kümeleri/işler/alanlar için tanımlanan URN anlaşmaları.
  • Orkestratörlerden ve motorlardan soy olaylarının etkin emisyonu.
  • SQL/DDL ayrıştırıcı ve şema normalleştirici çalışması.
  • Veri sözleşmeleri ve PII/tutma yayılma kuralları onaylanmıştır.
  • Yapılandırılmış WORM olay günlüğü ve grafik yedeklemeleri.
  • BI/ML soy tüketiciler (raporlar, modeller, özellikler) olarak bağlanır.
Operasyon:
  • Kritik alanlar için çizgi kapsamı ≥ %98, "para" için sütun seviyesi = %100.
  • Molalar için uyarılar, yetim veri kümeleri, devre sürüklenmesi açık.
  • PII etiketlerinin ve sözleşmelerin üç aylık denetimleri.
  • Değişikliklerin belge akışı (kırılma) ve tüketicilere dağıtımı.

19) Mini tarifler

RunCompleted olayı (sözde JSON):
json
{
"event": "RunCompleted",
"run": {
"id": "run_2025-10-31T14:20:00Z_42",
"job": "urn:job:etl:finance:close_books_v3",
"status": "SUCCESS",
"code_sha": "b3f9…",
"started_at": "2025-10-31T14:05:00Z",
"ended_at": "2025-10-31T14:19:52Z"
},
"inputs": [
"urn:dataset:lake:bank_txn_v2",
"urn:dataset:warehouse:fx_rates_d+1"
],
"outputs": [
"urn:dataset:warehouse:pnl_daily_v3"
],
"column_lineage": [
{
"output": "pnl_daily_v3. pnl_usd",
"expr": "SUM(txn. amount_local fx. rate)",
"inputs": ["bank_txn_v2. amount_local", "fx_rates_d+1. rate"],
"lossy": true
}
]
}
PII yayılma kuralı (fikir):

if input. field. pii in {email, phone, id} and transform in {hash, tokenize}:
output. field. pii = "pseudonymized"
elif transform in {aggregate, anonymize_k}:
output. field. pii = "anonymous"
else:
output. field. pii = input. field. pii
Darbe quaris'ne kıracak ":

affected = downstream(urn:"urn:dataset:warehouse:users_v4", depth=4)
filter affected where kind in {"dashboard","model","api"} and owner not in {"team-exp"}

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

Resmi bir model olmadan "resimde" Lineage. Olaylar/şemalar/URN gereklidir, aksi takdirde grafik ölçeklenmez.
"Paranın" olduğu yerde sütun seviyesi yoktur. "Hesaplamalar bir sütun seviyesi olmadan açıklanamaz.
Tamamlanmamış olaylar (code_sha/versii şemalar olmadan). Tekrarlanabilirlik mümkün değildir.
Gizliliği görmezden gelin. PII etiketleri yaşamalı ve tarlalarla birlikte taşınmalıdır.
Sharding olmadan bir büyük grafik veritabanı. Ad alanlarına bölün, anlık görüntüleri saklayın.
Ayrıştırıcılara körü körüne inanç. Tartışmalı durumlarda - motorlardan aktif olaylar.

21) Runbook'и

Olay: Metric "atladı".

1. "Path to metric" (Metriğe giden yol) seçeneğini açın - yoldaki son 'Run' düğümlerini kontrol edin.
2. Kod/şema sürümlerini kontrol edin, kenarlardaki DQ durumunu kontrol edin.
3. Bozuk bir bağlantı bulunursa, sahibi için bir bilet oluşturun, metrik yayının geçici "bekletme'sini etkinleştirin.
4. Düzeltmeden sonra - RCA'yı işaretleyin ve grafiğin düğümleriyle ilişkilendirin.

Kaynak şeması değiştiriliyor.

1. Aşağı akış etkisi istiyorum.
2. Sahiplere bildirim gönderin, geçiş PR'leri oluşturun.
3. Paralel 'v _ next' yükseltin, her iki sürümü de günbatımı tarihine kadar saklayın.
4. Kapat 'v _ prev', güncelleştirme sözleşmeleri ve soy grafiği.

İlgili malzemeler:
  • "Tasarıma Göre Gizlilik (GDPR)"
  • "PII Veri Tokenizasyonu"
  • "Gizli yönetim"
  • "Denetim ve değişmez günlükler"
  • "Dinlenme/Transit Şifrelemede"
  • "Anahtar Yönetimi ve Rotasyon"
Contact

Bizimle iletişime geçin

Her türlü soru veya destek için bize ulaşın.Size yardımcı olmaya her zaman hazırız!

Telegram
@Gamble_GC
Entegrasyona başla

Email — zorunlu. Telegram veya WhatsApp — isteğe bağlı.

Adınız zorunlu değil
Email zorunlu değil
Konu zorunlu değil
Mesaj zorunlu değil
Telegram zorunlu değil
@
Telegram belirtirseniz, Email’e ek olarak oradan da yanıt veririz.
WhatsApp zorunlu değil
Format: +ülke kodu ve numara (örneğin, +90XXXXXXXXX).

Butona tıklayarak veri işlemenize onay vermiş olursunuz.