Kafka Connect ile Veri Entegrasyonu: Source, Sink ve Hata Yönetimi

Kafka Connect neyi çözer?

Veri entegrasyonu işlerinin çoğu tekrarlayan bir desendir: bir veritabanındaki değişiklikleri Kafka'ya yazmak, bir topic'teki veriyi nesne depolamaya ya da arama motoruna aktarmak. Bunun için her seferinde özel bir producer ve consumer uygulaması yazmak, ofset takibi, hata yönetimi, yeniden deneme ve ölçeklemeyi her seferinde yeniden çözmek demektir.

Kafka Connect bu işi ortak bir çatıya taşır. Çatı; paralellik, hata toleransı, ofset yönetimi ve izleme gibi ortak ihtiyaçları sağlar. Siz yalnızca connector'ı seçer, yapılandırırsınız. Hazır connector'lar çoğu yaygın sisteme bağlanmak için vardır; gerekirse özel bir connector da yazılabilir.

Temel ayrım yöndedir. Source connector dış sistemden okuyup Kafka'ya yazar; sink connector Kafka'dan okuyup dış sisteme yazar. Bir veri hattında genellikle ikisi birlikte bulunur: kaynaktan topic'e, topic'ten hedefe. Böylece Kafka, sistemler arasında ayrık bir orta katman olur ve kaynak ile hedef birbirinden bağımsız ölçeklenir.

Connect, akış işlemenin yerine geçmez. Bir kaydı ağır biçimde dönüştürmek, birleştirmek ya da pencerelemek gerekiyorsa Kafka Streams ya da ayrı bir akış motoru tercih edilir. Connect taşımaya, hafif dönüşümler de yalnızca bu taşımanın parçasıdır.

Mimari: worker, connector ve görev

Üç kavram bilinmeden yapılandırma anlaşılmaz. Connector eklentisi, ilgili sınıfları içeren pakettir. Connector örneği, bu eklentiyi kullanan ve verinin kopyalanmasını yöneten çalışan iştir. Görevler, asıl kopyalamayı yapan birimlerdir. Connector, işi birden çok göreve böler; görev sayısı bir üst sınırla ayarlanır ve bu sınır paralelliği belirler.

Görevler durum tutmaz. Durum Kafka'daki yapılandırma ve durum topic'lerinde saklanır; bu yüzden görevler istenildiği zaman durdurulup başlatılabilir. Bir connector gönderildiğinde ya da yeniden yapılandırıldığında, ya da bir worker düştüğünde, iş görevler arasında yeniden dağıtılır. Bir görev kendisi hata verip durursa yeniden dağıtım tetiklenmez; görevi REST arayüzü üzerinden yeniden başlatmak gerekir.

Worker'lar iki modda çalışır. Tek süreçli mod geliştirme ve tek makinelik işler için basittir ama hata toleransı yoktur; connector yapılandırma dosyaları komut satırı parametresi olarak verilir. Dağıtık modda birden çok worker aynı grup kimliğini paylaşarak bir küme kurar. İşi dengeler, bir worker düştüğünde yeniden dağıtır. Bu modda connector'lar bir REST API aracılığıyla dağıtılır ve yönetilir. Üretim için dağıtık mod tercih edilir.

Source ve sink connector kurmak

Dağıtık modda bir connector, REST API ile bir yapılandırma gönderilerek oluşturulur. Yapılandırma bir ad ve bir ayar kümesinden oluşur. Ayarların ortak çekirdeği şunlardır:

• connector.class: Kullanılacak connector sınıfı.
• tasks.max: Oluşturulabilecek en fazla görev sayısı.
• topics: Sink connector'ın okuyacağı topic'ler (source connector'larda hedef topic ayarı connector'a özgüdür).
• Bağlantı ayarları: Dış sistemin adresi, kimlik doğrulama bilgisi, okunacak tablo ya da hedef dizin gibi connector'a özgü alanlar.

Converter ayarı çoğunlukla worker düzeyinde yapılır; key.converter ve value.converter ile anahtar ve değerin hangi biçimle yazılıp okunacağı belirlenir. Düz JSON, metin, bayt dizisi ve şema kayıt defteriyle çalışan Avro, Protobuf ve JSON Schema converter'ları yaygın seçeneklerdir. Şemalı biçimler, kaynak ve hedef arasında veri sözleşmesini korur ve alan değişikliklerini yönetmeyi kolaylaştırır.

Kurulumdan sonra connector ve görevlerin durumu sorgulanır. Çalışmayan bir görevin hata mesajı durum bilgisinde görünür. Önce küçük bir veriyle denemek, ardından gerçek hacimle ölçeklemek güvenli yoldur.

Kimlik bilgileri yapılandırma dosyasına düz metin olarak yazılmaz; ortamın sır deposu ya da gizli bilgi yönetimi çözümü kullanılır.

Dönüşümler ve converter

Converter ile dönüşüm sıklıkla karıştırılır. Converter, Kafka'daki bayt biçimi ile Connect'in iç veri biçimi arasında çeviri yapar; yani kaydın nasıl serileştirildiğini belirler. Dönüşüm (transform) ise tek bir kaydı, taşınırken hafifçe değiştirir: bir alanı silmek, adını değiştirmek, bir değer eklemek ya da kaydı başka bir topic'e yönlendirmek gibi. Dönüşümler zincir halinde bir connector yapılandırmasına eklenebilir.

Bu araç hafif işler için iyidir. Alan maskeleme, zaman damgası ekleme, topic adı düzenleme gibi küçük ihtiyaçlar tek yerde çözülür. Ancak birden çok kayda bakan hesaplar, tablolar arası birleştirme ya da durum gerektiren iş burada yapılmaz. Bunlar için Kafka Streams ya da akış motoru uygun yerdir.

Zincirdeki dönüşümlerin sırası önemlidir ve her biri performans maliyeti getirir. Sade tutmak, hata ayıklamayı kolaylaştırır. Dönüşümlerin sonucunu hedef sistemde değil, önce bir topic'te görmek hatayı erken yakalatır.

Şema değişiklikleri ayrı bir konudur. Kaynakta yeni bir alan eklendiğinde hedefin bunu kabul edip etmeyeceği, converter ve hedef connector ayarlarına bağlıdır. Değişiklikleri üretimden önce test ortamında denemek gerekir.

Hata yönetimi ve dead letter queue

Bir hat bozuk veriyle karşılaştığında ne olacağını önceden belirlemek gerekir. Connect'in varsayılan davranışı hata toleransının kapalı olmasıdır: errors.tolerance değeri none iken bozuk kayıt görevi başarısız kılar ve hat durur. Bu güvenlidir, çünkü veri sessizce kaybolmaz; ancak tek bozuk kayıt tüm akışı bloke edebilir.

Değer all yapıldığında bozuk kayıtlar atlanır ve hat devam eder. Bu durumda atlanan kayıtların kaybolmaması için dead letter queue tanımlanır; errors.deadletterqueue.topic.name ayarı ile başarısız kayıtlar ayrı bir topic'e yazılır. errors.deadletterqueue.context.headers.enable açıldığında her kayda hatanın nedenini açıklayan başlıklar eklenir. Bu özellik sink connector'lar için geçerlidir.

Dead letter queue bir çöp kutusu değildir; düzenli izlenmezse sorun görünmez kalır. Topic'e düşen kayıt sayısı için uyarı kurulur, kayıtlar incelenir, kaynağı düzeltilir ya da yeniden işlenir. Hata günlüğü ayarı da ek bilgi sağlar.

Sık hatalar ve işletme

Connect işlerinde görülen hatalar kolay önlenebilir. Bazıları şunlardır: üretimde tek süreçli modun kullanılması, görev sayısı üst sınırının kaynak sistemin yükünü hesaba katmadan yüksek ayarlanması, converter'ların kaynak ve hedefte farklı seçilmesi, hatalı kayıtlar için tolerans açıp kuyruğu izlememek, şifreleri düz metin yazmak ve şema değişikliklerini test etmemek.

İşletme tarafında üç şey izlenir: connector ve görev durumları, gecikme (kaynak ile hedef arasındaki fark) ve hata sayısı. Çalışmayan görev uyarısı en azından kurulmalıdır, çünkü görev hatası kendiliğinden yeniden dağıtım başlatmaz.

Başlangıç için önerilen yol şöyledir. Önce tek makinede bir dosya ya da test veritabanıyla source ve sink connector denenir. Sonra dağıtık moda geçilir, converter ve şema yönetimi kurulur. Ardından hata davranışı ve dead letter queue eklenir. Son olarak izleme, uyarı ve sürüm geçişi prosedürü hazırlanır.

Değişen veri yakalama gibi veritabanı kaynaklı hatlarda da aynı çatı kullanılır; kaynak tarafı connector'a, taşıma Kafka'ya, hedef tarafı sink connector'a bırakılır.

Bu beceriyi Mindset programında nerede çalışırsınız?

Apache Kafka ile Akış Mimarisi programı; Kafka mimarisi ve temel kavramlar, topic yönetimi ve veri modelleme, producer ve consumer API, Kafka Streams, kümeleme ve üretim yönetimi ile Kafka Connect ile entegrasyon başlıklarını işler. Connect konusu, programın kapsamındaki bir modüldür; mimariyi bilen veri mühendisleri ve geliştiriciler bu modülle veri entegrasyonu uygulamasına geçer.