Veri hatları sessizce bozulur. Bir pano dünün sayılarını gösterir, kaynakta bir sütunun tipi değişir ve bir iş hata vermeden satırları düşürür, ya da kimsenin hatırlamadığı bir replikasyon slotu, disk dolana kadar üretim veritabanında write-ahead log biriktirir. Bunların her biri, hiç çizilmemiş bir adım ya da sözleşmedir.
Veri hattı mimari diyagramı, verinin nereden geldiğini, nasıl hareket ettiğini, her aşamada nerede saklandığını, onu kimin ne zaman dönüştürdüğünü ve herkesin verinin taze ve doğru olduğunu nasıl bildiğini gösterir. Bu yazı yaygın bir kurulum için, PostgreSQL'den Kafka üzerinden bir göle ve bir veri ambarına değişiklik verisi yakalama için böyle bir diyagram kuruyor ve her adımda neyin etiketlenmesi gerektiğini anlatıyor.
Toplu çekim, CDC ya da olaylar
Operasyonel bir veritabanından veri almanın üç yaygın yolu vardır:
| Yaklaşım | Nasıl okur | Tipik tazelik | Dikkat edilecekler |
|---|---|---|---|
| Toplu çekim | Son çalışmadan sonra updated_at değeri değişen satırlar gibi zamanlanmış bir sorgu |
Saatler | Kaynaktaki yük; kalıcı silmeler hiç görünmez |
| Log tabanlı CDC | Veritabanının işlem log'unu okur | Saniyeler ile dakikalar | Okuyucu için tutulan log ve tablo şemalarına bağımlılık |
| Uygulama olayları | Servis, çoğu zaman bir outbox tablosu üzerinden alan olayları yayımlar | Saniyeler | Kod değişikliği gerekir; olaylar tüketiciler için tasarlanmalıdır |
Log tabanlı değişiklik verisi yakalama (CDC), uygulama değişikliği gerektirmediği, silmeleri gördüğü ve az sorgu yükü eklediği için analitikte popülerdir. Bedelleri operasyoneldir ve diyagramda yer almalıdır.
PostgreSQL ile log tabanlı CDC nasıl çalışır
PostgreSQL değişiklikleri, write-ahead log'u (WAL) bir satır değişiklikleri akışına dönüştüren mantıksal çözümleme (logical decoding) ile sunar. Bunun için wal_level = logical, bir çıktı eklentisi ve bir replikasyon slotu gerekir. Debezium PostgreSQL connector'ı, PostgreSQL 10 ve sonrasıyla gelen standart pgoutput eklentisini kullanır. İlk başlatmada tabloların tutarlı bir anlık görüntüsünü alır, ardından onaylanmış her insert, update ve delete işlemini varsayılan olarak tablo başına bir Kafka konusuna, topicPrefix.schemaName.tableName adıyla akıtır.
Can yakan kısım replikasyon slotudur. PostgreSQL belgeleri, bir slotun tüketicisinin hâlâ ihtiyaç duyduğu WAL'ın silinmesini, hiçbir şey bağlı olmasa bile engellediğini açıklar. Connector bir hafta sonu boyunca durursa, WAL birincil sunucuda büyümeye devam eder. max_slot_wal_keep_size ayarı, slotların ne kadar WAL tutabileceğini sınırlar; varsayılan değeri olan -1 sınır yok demektir. Bir sınır veritabanını korur, ama bedeli slotun geçersiz kalması, yani yeni bir anlık görüntüdür. Her iki durumda da slot gecikmesini izleyin ve slotu diyagrama çizin.
Göl katmanları ve veri ambarı
Değişiklikler Kafka'ya ulaştığında bir sink onları depolamaya yazar ve dönüşümler onları kullanılabilir hale getirir. Aşamaları adlandırmak için Databricks medallion mimarisini yaygınlaştırdı:
- Bronze, ham veriyi geldiği gibi, yükleme meta verisiyle tutar; böylece kaynağı yeniden okumadan yeniden işleyebilirsiniz.
- Silver, temizlenmiş, tekilleştirilmiş ve uyumlu hale getirilmiş kayıtları tutar: sipariş başına tek bir güncel satır, tutarlı tipler ve anahtarlar.
- Gold, panoların ve modellerin okuduğu iş düzeyindeki tabloları ve toplamları tutar.
Her katmanın nerede duracağı bir tasarım kararıdır: Apache Iceberg gibi açık bir tablo biçimiyle nesne depolamada ya da veri ambarının kendisinde. Gerçekte nerede durduğunu çizin; çünkü maliyete, erişim denetimine ve kimin sorgulayabileceğine o karar verir.
Orkestrasyon ve sözleşmeler
Bronze'dan gold'a dönüşümler bir zamanlamayla ya da yeni veri geldiğinde çalışır; bunları Airflow ya da Dagster gibi bir orkestratör yönetir ve çoğu zaman dbt'de SQL modelleri çalıştırır. İki şey, bir veri hattı ile bir yük arasındaki farkı yaratır:
- Sözleşmeler. Değişiklik olayı şemaları, uyumluluk kurallarıyla bir şema kayıt defterine kaydedilir; böylece kaynak tablodaki kırıcı bir değişiklik bir raporda sessizce değil, üreticide yüksek sesle başarısız olur.
- Kontroller. Tazelik, satır sayısı, benzersizlik ve boş değer kontrolleri her adımdan sonra çalışır ve bir başarısızlık, pano yanlış göstermeden önce sahibini çağırır.
Örnek: bir online mağaza
Mağazanın PostgreSQL veritabanı siparişleri, ödemeleri ve müşterileri tutar. Debezium, Kafka Connect içinde çalışır, WAL'ı bir replikasyon slotu üzerinden okur ve shop.public.orders, shop.public.payments ve shop.public.customers konularını yayımlar. Bir sink connector değişiklik olaylarını bronze tablolara ekler. Orkestratör her 15 dakikada bir silver ve gold'u kuran dbt modellerini, ardından veri kontrollerini çalıştırır. Panolar gold'u okur.
Diyagram içeriği
- shop DB
- Debezium
- Kafka
- Sink connector
- Schema registry
- Lake and warehouse
- Gold: marts
- Silver: cleaned
- Bronze: raw changes
- BI dashboards
- Orchestrator: dbt
- Data checks
- WAL via slot
- change events
- register schemas
- topic per table
- append raw changes
- merge, dedupe
- aggregate
- SQL
- runs models
- every 15 min
- then checks
Nasıl okunur:
- Üst sıra, yakalama. Değişiklikler PostgreSQL'den replikasyon slotu üzerinden çıkar, şemalarını kaydeden Debezium'da değişiklik olaylarına dönüşür ve tablo başına bir Kafka konusundan geçerek sink connector'a ulaşır.
- Alt sıra, depolama, sağdan sola. Sink ham değişiklikleri bronze'a ekler. Dönüşümler onları silver'da birleştirir ve silver'ı, panoların sorguladığı gold'da toplar.
- Altta, denetim. Orkestratör dönüşümleri ve kontrolleri çalıştırır; başarısız bir kontrol bir uyarı üretir.
- Markdown bloğu, slot ve şema değişiklikleri için işletim kurallarını listeler.
Neler etiketlenmeli
- İlk kenarda slot ve sınırı ile slot geciktiğinde kimin uyarılacağı.
- Bir tüketicinin neye abone olacağını bilmesi için konu adları ya da bir adlandırma kuralı.
- Dönüşüm kenarlarında "her 15 dk, en fazla 30 dk eski" gibi zamanlamalar ve tazelik hedefleri.
- Katman başına saklama süresi. Bronze çoğu zaman geçmişi en uzun tutar; yeniden oynatma tamponunuz odur.
- Her katmanın ve her kontrolün sahipleri.
- Kişisel veriler. Nerede saklandığını ve nerede maskelendiğini ya da düşürüldüğünü işaretleyin; GDPR veri haritalama diyagramına bakın.
Yaygın hatalar
- Veritabanından veri ambarına tek bir ok. Slotu, şemaları ve verinin kaybolabileceği ya da gecikebileceği her yeri gizler.
- Birincil sunucuda analitik sorgular. Üretimdeki birincil sunucuya karşı toplu çekimler müşteri trafiğiyle yarışır; CDC ya da bir replika kullanın ve hangisi olduğunu çizin.
- Yeniden oynatma yolu olmaması. Bronze saklanmazsa, bir dönüşümdeki hata kaynağı yeniden okumak anlamına gelir.
- Herkese açık arayüz olarak ham tablolar. İç tabloların değişiklik olaylarını okuyan tüketiciler, şema değiştiğinde bozulur. Diğer ekipler için olan olaylarda tasarlanmış olaylar yayımlayın; o tarafı olay güdümlü mimari diyagramı ele alır.
- Yalnızca log yazan kontroller. Kimseyi uyarmadan başarısız olan bir test, bir yorumdan ibarettir.
Aynı sistemin veritabanı tarafı için veritabanı replikasyon diyagramına ve ER diyagramı örneğine bakın.
Archboard'da oluşturun
- Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
- Veri paketinden kaynak veritabanı için bir Postgres düğümü, konular için bir Kafka düğümü ekleyin.
- Debezium, şema kayıt defteri, sink connector ve panolar için C4 Modeli paketinden Konteyner düğümleri ekleyin.
- Lake and warehouse adlı bir Temel paketi Çerçeve ekleyin; içine bronze ve silver için Veri paketinden iki Nesne deposu, gold için de bir Veri ambarı koyun.
- DevOps paketinden orkestratör için bir İş hattı, veri kontrolleri için bir Uyarı ekleyin. Denetim kenarlarını kesikli çizin.
- Slot ve şema kurallarıyla bir Temel paketi Markdown bloğu ekleyin.
Örnek 13 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor. Kaynak şemayı SQL olarak tutuyorsanız, PostgreSQL'den ER diyagramına aracı konuların arkasındaki tabloları çizer.
SSS
CDC toplu çekimlerden daha mı iyi? Tazelik, silmeler ve kaynaktaki yük açısından genellikle evet. Saatlerce gecikme kabul edilebiliyorsa ve satırlar hiç kalıcı olarak silinmiyorsa, toplu çekimi işletmek daha basittir ve yeterlidir.
CDC için Kafka'ya ihtiyacım var mı? Debezium en çok Kafka Connect üzerinde çalıştırılır ve Kafka size yeniden oynatma ile çok sayıda tüketici sağlar. Başka kurulumlar da vardır; gerçekte çalıştırdığınız taşıyıcıyı ve saklama süresini çizin.
Şema değişikliklerini nasıl yönetirim? Şemaları uyumluluk kurallarıyla kaydedin, sütunları değiştirmek yerine ekleyin ve sonraki modellerin yeni sütunlara tolerans göstermesini sağlayın. Kayıt defterini çizin; sözleşme orada yaşar.
Veri kalitesi kontrolleri nerede çalışmalı? Orkestre edilen çalışmanın parçası olarak her katmandan sonra, sahibine giden uyarılarla. Gold üzerindeki tazelik kontrolleri sessiz hataların çoğunu yakalar.
Veri hattı diyagramını nasıl güncel tutarım? Onu connector ve orkestratör yapılandırmasıyla aynı pull request'te değiştirin; eskimeyen mimari diyagramlar yazısına bakın.