Phase 6 teknik karar rehberi
Kafka CDC ve Gerçek Zamanlı Veri Aktarımı Nasıl Ele Alınır?
Kısa cevap
Kafka CDC (change data capture, yani değişiklik verisi yakalama); veritabanındaki ekleme, güncelleme ve silme değişikliklerinin olay olarak Kafka topic'lerine aktarılmasıdır. Uygulamada yöntem seçimi, ilk yükleme, şema değişikliği, olay sırası ve tekrar işleme birlikte tasarlanır. Debezium gibi Kafka Connect üzerinde çalışan bağlayıcılar log tabanlı CDC için sık anılan seçeneklerdir; uygunluğu ortamınızda doğrulanmalıdır.
Kafka CDC uygulamasında log tabanlı yöntem, ilk yükleme, şema değişikliği, sıralama ve tekrar işleme kararları nasıl ele alınır? Mimari kontrol listesi. Bu içerik; gereksinimleri açıklaştırmak, doğru soruları görünür kılmak ve karar sürecini teknik bağlama yerleştirmek için hazırlanmıştır.
Yayın ve güncelleme: 1 Eylül 2026. Üçüncü taraf teknoloji adları yalnızca açıklama veya değerlendirme kriteri olarak kullanılır.
Kafka CDC nedir?
CDC, kaynak veritabanındaki değişikliklerin toplu okumayı beklemeden olay olarak yakalanıp aktarılmasıdır. Bu yazı tanımdan çok uygulama kararlarına odaklanır; kavramın temel anlatımı için ilgili rehbere bakılabilir.
Kafka tarafında bu olaylar topic'lerde tutulur ve tüketiciler kendi hızlarında okur. Hangi yöntemin, hangi tablo kapsamının ve hangi tüketicinin seçileceği aşağıdaki bölümlerde sırayla ele alınır.
Log tabanlı CDC ve diğer yöntemler
Log tabanlı yöntem, veritabanının kendi değişiklik kayıtlarını okur; sorgu tabanlı yöntem ise zaman damgası veya artan bir sütun üzerinden düzenli aralıklarla sorgu çalıştırır. Sorgu tabanlı yaklaşımda aradaki bazı değişiklikler ve silmeler yakalanmayabilir.
Tetikleyici tabanlı yöntemde kaynak veritabanındaki tetikleyiciler değişiklikleri ayrı bir tabloya yazar; bu kaynak sisteme ek iş yükü getirebilir. Log tabanlı yöntem için kaynağın log erişimi ve yapılandırması ortamınızda doğrulanmalıdır. Bu alanda Debezium sık anılan bir seçenektir.
İlk yükleme ve değişiklik akışı
Değişiklik akışı başlamadan önce hedefin çoğunlukla mevcut veriyle doldurulması gerekir; buna ilk yükleme veya snapshot denir. Ardından kaynaktaki log konumundan itibaren değişiklikler olay olarak akmaya başlar.
İki aşama arasındaki geçiş noktası dikkatle planlanmalıdır: ilk yükleme sürerken değişen kayıtların hedefte nasıl birleştirileceği, hata sonrası yeniden başlatmanın nasıl yapılacağı önceden belirlenmelidir.
Gerçek zamanlı veri aktarımı ne zaman gerekir?
Her veri ihtiyacı sürekli aktarım gerektirmez. Karar, bir bilginin ne kadar güncel olması gerektiğine ve gecikmenin iş sonucunu gerçekten etkileyip etkilemediğine bağlıdır.
Düzenli toplu yükleme ihtiyacı karşılıyorsa daha sade bir tasarım yeterli olabilir. Sürekli akış seçilecekse kabul edilebilir gecikme, iş birimiyle birlikte yazılı olarak tanımlanmalı ve kendi ortamınızda ölçülerek doğrulanmalıdır.
Olay şeması ve tüketici sorumluluğu
Kaynak tabloya sütun eklenmesi veya bir sütunun tipinin değişmesi, olayın yapısını da değiştirir. Bu nedenle olay şemasının kim tarafından sahiplendiği ve değişikliklerin tüketicilere nasıl duyurulduğu baştan belirlenmelidir.
Şema kaydı (schema registry) gibi bir bileşen uyumluluk kurallarının uygulanmasına yardımcı olabilir; kullanılıp kullanılmayacağı ve hangi uyumluluk düzeyinin seçileceği ekibin ihtiyacına göre değerlendirilir.
Sıralama, tekrar işleme ve hata yönetimi
Kafka'da sıralama partition düzeyinde korunur. Aynı kaydın değişiklikleri sırayla işlenecekse bu olayların aynı anahtarla yazılması gerekir; partition sayısı sonradan değişirse anahtar-partition eşleşmesi de değişebileceği için sayı baştan bu gereksinimle birlikte düşünülmelidir.
Hata veya yeniden başlatma sonrasında aynı olayın birden fazla işlenmesi mümkündür. Tüketicinin bunu tolere edecek biçimde, yani tekrar işlemeye dayanıklı (idempotent) tasarlanması ve hatalı olayların ayrı bir yerde izlenmesi değerlendirilir.
Kafka veri entegrasyonu ile ETL farkı
ETL, veriyi genellikle planlı çalışmalarla toplu olarak alıp dönüştürür ve hedefe yükler. Değişiklik akışı ise kaynaktaki tek tek değişiklikleri olay olarak taşımaya odaklanır.
İki yaklaşım birbirinin yerine geçmek zorunda değildir; örneğin ilk yükleme toplu bir işle yapılıp devamı olay akışıyla sürdürülebilir. Seçim, hedefin güncellik beklentisine ve işletim kapasitesine göre yapılır.
Danışmanlık ne zaman değerlendirilir?
Ekip içinde Kafka, kaynak veritabanı ve tüketen sistemler için ortak bir sorumlu yoksa ya da ilk kurulumdan önce mimari kararlar netleşmemişse dış bir görüş değerlendirilebilir.
Bu görüş bir ürün veya sonuç vaadi değildir; kapsam, riskler ve kabul ölçütlerinin yazılı hale getirilmesine yardımcı olur. Süreçte tüm kararlar kurumun kendi ortamında doğrulanır.
Kontrol ve izleme soruları
Yayına almadan önce şu sorular yanıtlanabilir: kaynağın değişiklik kayıtları ne kadar süre saklanıyor, tüketici geride kalırsa kim haberdar oluyor ve şema değişikliği hangi sırayla duyuruluyor?
İzleme tarafında tüketicinin geride kalma durumu (consumer lag), bağlayıcı hataları ve hatalı olayların yönetimi düzenli izlenmelidir. Uyarı eşikleri, ortamınızdaki ölçümlerle belirlenmelidir.
Kimler için uygundur?
Veri kaynakları çoğalan, raporlama veya operasyonel kararlarını daha tutarlı veriye dayandırmak isteyen; mevcut iş akışında gecikme, görünürlük, veri kalitesi ya da sorumluluk belirsizliği yaşayan ekipler bu konuyu değerlendirebilir. Öncelik, kurumun gerçek kullanım senaryosudur.
Hangi çıktılar alınır?
Kapsam sınırları, öncelikli sorular, riskler, doğrulama ölçütleri ve sorumluluklar görünür hale gelir. Çıktıların türü, kararın niteliğine ve çalışmanın kapsamına göre belirlenir; otomatik başarı veya uygulama sonucu vaat edilmez.
Süreç nasıl ilerler?
- İş hedefi, kaynaklar ve kabul ölçütleri netleştirilir.
- Mevcut durum, bağımlılıklar ve riskler değerlendirilir.
- Öncelikli adımlar ve sorumluluklar kararlaştırılır.
- Uygulanacak değişiklikler gerçek ortamda doğrulama planıyla ele alınır.
Resmi teknik kaynaklar
Teknik kavramlar için aşağıdaki birincil kaynaklar referans alınabilir. Bu bağlantılar BIAnalytics'in resmi partnerliği veya üçüncü taraf ürün desteği anlamına gelmez.
Sık sorulan sorular
Kafka CDC ve gerçek zamanlı veri aktarımı nedir?
Kafka CDC (change data capture, yani değişiklik verisi yakalama); veritabanındaki ekleme, güncelleme ve silme değişikliklerinin olay olarak Kafka topic'lerine aktarılmasıdır. Uygulamada yöntem seçimi, ilk yükleme, şema değişikliği, olay sırası ve tekrar işleme birlikte tasarlanır.
Kafka CDC ve gerçek zamanlı veri aktarımı ne zaman değerlendirilir?
CDC değişikliklerinin event streaming bağlamında hangi kontrollerle ele alınacağını açıklamak. Değerlendirme, kurumun veri kaynakları, kullanıcıları, risk toleransı ve işletim kapasitesiyle doğrulanmalıdır.
Kafka CDC ve gerçek zamanlı veri aktarımı seçerken nelere dikkat edilmelidir?
İş sorusu, kaynak-hedef kapsamı, veri anlamı, kullanıcı rolü, kalite, güvenlik, güncellik, hata yönetimi ve bakım sorumluluğu açıkça belirlenmelidir.
İlk adım nedir?
Kapsam, mevcut durum, öncelikli riskler ve kabul ölçütleri yazılı hale getirilir; sonra teknik alternatifler gerçek kullanım senaryosuyla değerlendirilir.
Hangi sınırlılıklar vardır?
Bu içerik belirli bir CDC bağlayıcısı, Kafka entegrasyonu, gecikme değeri veya veri kaybı olmama garantisi vermez.
Log tabanlı CDC ile sorgu tabanlı CDC farkı nedir?
Log tabanlı yöntem veritabanının değişiklik kayıtlarını okur; sorgu tabanlı yöntem ise belirli aralıklarla sorgu çalıştırır. Sorgu tabanlı yaklaşımda ara değişiklikler ve silmeler yakalanmayabilir. Seçim, kaynağın yapılandırma imkânlarına ve ortamınızdaki doğrulamaya göre yapılır.
Snapshot ve akış nasıl birlikte çalışır?
Önce mevcut veri hedefe ilk yükleme (snapshot) ile aktarılır, ardından kaynaktaki değişiklikler olay akışı olarak sürdürülür. Geçiş noktasının ve hata sonrası yeniden başlatmanın nasıl yönetileceği önceden planlanmalı ve ortamınızda test edilmelidir.