Mimari, uygulama kodunu değiştirmeden veri hatlarını enstrümante eden Hibrit Meta Veri Toplama Katmanı etrafında şekillenmektedir. Değişiklik Veri Yakalama (CDC) ajanları, Apache Kafka konu şemalarını, Apache Spark yürütme planlarını ve eski Oracle veritabanlarından JDBC sorgu günlüklerini keserek, bölgesel bir Apache Pulsar otobüsüne yapılandırılmış köken olayları yayar.
Akış İşleme katmanı, bu olayları ayrıştırmak için Apache Flink kullanarak JanusGraph içinde dinamik bir özellik grafiği oluşturur; burada köşeler veri kümelerini (tablolar, konular, dosyalar) temsil eder ve kenarlar dönüşüm mantığını sütun inceliği ile yakalar. GDPR otomasyonu için sistem, PII imzalarını (örneğin, e-posta hash'leri, tokenize edilmiş SSN'ler) grafik kenarlarına eşleyen ters bir dizin tutmaktadır, bunu Apache Lucene aracılığıyla gerçekleştirir.
Silme talebi geldiğinde, bir Saga Orkestratörü etkilenen veri kümelerini belirlemek için grafiği tarar, Delta Lake vakum komutları ve Kafka mezar olayları üretir ve bunları Apache Airflow iş akışları aracılığıyla kesin bir biçimde yürütür. Şema Etki Tahmini, tarihsel köken desenleri üzerinde eğitilmiş Graf Sinir Ağları (GNN) kullanarak, önerilen Avro şema değişikliklerinin patlama alanını simüle eder, grafiği Gremlin ile sorgular ve alt saniye gecikmesi için agresif Redis önbelleği kullanır.
AB, APAC ve ABD bölgelerinde faaliyet gösteren çok uluslu bir finansal kuruluş, Veri Ağı göçü sırasında GDPR Madde 17 uyumunda zorluk çekmiştir. Müşteri PII'si 500+ mikro hizmet, eski büyük sistem çıkarımları ve Snowflake analitik veri ambarları aracılığıyla yayılmıştır.
Bir müşteri veri silme talebinde bulunduğunda, manuel denetimler alanlar boyunca üç hafta süren SQL izini gerektirmiş ve genellikle S3 veri göllerinde türetilen veri setlerini kaçırmıştır. Aynı zamanda, Ödemeler alanındaki şema değişiklikleri, Analitik alanındaki Dolandırıcılık Tespiti panolarını sıkça bozmuş ve bir çeyrekte altı üretim olayı yaşanmıştır.
Seçenek A, tüm tablo şemalarının gecelik Spark toplama taramaları ile merkezi bir Apache Hive Metastore önermiştir. Bu basitlik ve güçlü tutarlılık sağlamış ancak 24 saat güncellik, GDPR'nın "gereksiz gecikme olmadan" gereğini ihlal etmiş ve Apache Flink işlerindeki akış dönüşümlerini yakalamakta başarısız olmuştur.
Seçenek B, tüm Kubernetes düğümlerinde eBPF çekirdek probaları dağıtmayı önererek, derin paket inceleme için ham TCP yüklerini yakalamıştır. Bu gerçek zamanlı doğruluk sağlasa da, hassas PII'yi köken deposunda potansiyel olarak kaydetme riski taşıdığı için ciddi gizlilik riskleri yaratmış, %40 CPU ek yük oluşturmuş ve veri azaltma ilkesini ihlal etmiştir.
Sonuçta seçilen Seçenek C, veritabanları için Debezium bağlayıcılarına ve akış hatları için Kafka Interceptor'lara bağlanan Log-CDC ajanları uygulamıştır. Bu, yalnızca şema meta verilerini ve dönüşüm mantığını yakalayarak satır değerlerini incelemeden alt dakikalık köken yayılımı sağlamış ve sıfır uygulama kodu değişikliği ile gerçekleştirilmiştir. Dağıtım sonrası, GDPR silme gecikmesi 5 dakikanın altına düşmüş, şema değişikliği etki analizi proaktif hale gelmiş ve %85 tahmin doğruluğuna ulaşılmıştır; banka sıfır bulgu ile SOC 2 denetimini geçmiştir.
Kullanıcı Tanımlı Fonksiyonlar (UDF'ler) gibi deterministik olmayan dönüşümler için köken takibini nasıl ele alıyorsunuz ya da dinamik olarak dış API çağrılarına dayalı sütun şemalarını değiştiren Python dönüşümleri?**
Çoğu aday, tüm dönüşümlerin statik ve açıklayıcı olduğunu varsayar. Gerçekte, UDF'ler kara kutulardır. Çözüm, dağıtım öncesinde sütun başvurularını çıkarmak için CI/CD hattında Python bayt kodunun veya Scala soyut sözdizim ağaçlarının (AST) Statik Analizi gerektirir.
Gerçekten dinamik şemalar (örneğin, değişen anahtarlarla JSON pikini) için sistem, köken toplayıcının olası çıktı alanlarını girdi alanlarına olasılıksal olarak eşleştirmek üzere bir kayıt altı örneğini örneklediği Şema Çıkarma Örnekleme uygulamalıdır; bu kenarları grafikte güven puanları ile etiketleyerek yapar.
Ayrıca, gerçek çıktı şemalarını çıkarılan kökene karşı doğrulamak için Confluent Schema Registry kullanan Çalışma Zamanı Şema Kaydı kontrolleri, beklenmedik davranış değişikliklerinde drift'i işaretleyebilir.
Olay zamanı su damlaları ile geç gelen veriler işlendiğinde köken doğruluğunu nasıl uzlaştırıyorsunuz; bu da pencere toplamalarına geri dönük güncellemeler yapıyor?
Adaylar genelde kökeni sabit DAG'ler olarak modellemektedir; ancak Apache Flink ve Kafka Streams, pencere yeniden hesaplamalarına izin verir. Mimari, grafikteki her köken ilişkisinin olay zamanı su damlası ve işleme zamanı versiyonu ile damgalanmasını sağlayan Zamansal Sürümleme uygulamalıdır.
Geç gelen veri bir yeniden hesaplama tetiklediğinde, sistem yeni bir zamansal kenar oluştururken tarihi birini korur ve Geçerli-Den/Geçerli-İçin zaman damgaları kullanır. Gremlin sorguları, en son zamansal dilimi varsayılan olarak almakla birlikte, tarihsel denetimleri desteklemelidir.
Ayrıca, GDPR silme senaryosu, geç gelen bu verileri hesaba katacak Geriye Dönük Pencereler kullanmalıdır; böylece silme işlemleri, ilk pencere kapandıktan saatler sonra gerçekleşse bile, yeniden işlenen toplam değerlere ulaşır.