Örnek sorular
St Kafka Connect Schema RegistryZorluk 2
Apache Kafka Connect'te standalone mod ile distributed mod arasındaki temel mimari fark nedir?
- aDistributed mod konfigürasyon, offset ve durumu Kafka'da paylaşır; standalone tek süreç ve yerel source-offset dosyası kullanır.✓
- bStandalone mod yalnızca sink connector çalıştırabilir, distributed mod ise yalnızca source connector çalıştırabilir.
- cStandalone mod başlamak için bir Schema Registry gerektirir, distributed mod ise yalnızca şemasız converter'larla çalışır.
- dStandalone mod topic partition sayısı kadar task atar, distributed mod ise tam olarak bir task atar.
Açıklama:Standalone mod, offset'lerini yerel bir dosyaya yazan, yerleşik hata toleransı ya da ölçekleme olmayan tek-süreçli bir dağıtımdır. Distributed mod ise birden fazla worker sürecinin Kafka topic'leri üzerinden koordine olmasını sağlar; bu da hata toleransı ve yatay ölçekleme kazandırır. b, c ve d şıkları her iki modda da var olmayan kısıtlar uyduruyor.
St Kafka Connect Schema RegistryZorluk 2
Kafka Connect terminolojisinde connector ile task'ları arasındaki ilişki nedir?
- aConnector ve task aynı çalışma zamanı nesnesinin iki farklı adıdır; terimler birbirinin yerine kullanılır.
- bConnector, Connect REST API'sini barındıran bir JVM sürecidir, task ise her source veya sink için ayrı bir JVM sürecidir.
- cConnector işin bölünmesini belirleyip task konfigürasyonları üretir; veriyi task'lar taşır.✓
- dConnector yalnızca standalone modda çalışır, task'lar ise yalnızca distributed modda var olur.
Açıklama:Connector örneği, dış sistemi izlemekten ve bir dizi task konfigürasyonu üretmekten sorumludur; kaydı kendisi tüketmez ya da üretmez. Task'lar ise worker'lara zamanlanan, veriyi fiilen taşıyan birimlerdir. b şıkkı task'ı bir worker süreciyle karıştırıyor, d şıkkı ise var olmayan bir mod kısıtı uyduruyor.
St Kafka Connect Schema RegistryZorluk 2
tasks.max connector ayarı gerçekte neyi kontrol eder?
- aDış kaynak veya hedef nasıl bölünebilirse bölünsün, connector'ın oluşturacağı task sayısını kesin olarak belirler.
- bBir üst sınırdır; kaynak o kadar ince bölünemiyorsa connector daha az task oluşturabilir.✓
- cConnector çalışmadan önce başlatılması gereken Connect worker süreci sayısını belirler.
- dDahili offset saklama topic'inin kaç partition'a sahip olacağını kontrol eder.
Açıklama:tasks.max bir garanti değil, bir tavan değeridir. Connector'ın Connector.taskConfigs(int maxTasks) metodu, kaç task konfigürasyonu üretileceğine karar verir; bu değer tasks.max ile sınırlıdır ama kaynağın veya hedefin doğal olarak ne kadar ince bölünebildiğiyle de (örneğin mevcut tablo veya dosya sayısı) sınırlıdır. a şıkkı bunu sabit bir sayı gibi abartıyor, c ve d ise worker sayısı veya dahili topic partition'lamasıyla karıştırıyor.
St Kafka Connect Schema RegistryZorluk 1
Distributed modda, dahili config.storage.topic'inde ne saklanır?
- aCluster'da çalışan her source connector'ın ürettiği ham kayıtlar.
- bHer connector ve task'ın o anki çalışıyor/duraklatıldı/başarısız durumu.
- cHer source connector için son commit edilmiş offset'ler.
- dREST API üzerinden gönderilen connector ve task konfigürasyonları; böylece herhangi bir worker bunları alabilir.✓
Açıklama:config.storage.topic, REST API üzerinden gönderilen konfigürasyonların kalıcı tutulduğu yerdir; bu sayede cluster'daki herhangi bir worker bir connector'ın konfigürasyonunu yükleyip task'larını devralabilir. Connector ve task durumu status.storage.topic'te, source offset'leri ise offset.storage.topic'te tutulur — b ve c şıkları aslında bu diğer iki topic'i tarif ediyor.
St Kafka Connect Schema RegistryZorluk 1
Distributed bir Kafka Connect cluster'ında dahili offset.storage.topic'in amacı nedir?
- aSink connector'ların Kafka'ya geri commit ettiği consumer group offset'lerini saklar.
- bHer source connector'ın okuduğu sistemde ulaştığı konum; böylece Connect yeniden başladığında kaldığı yerden devam edebilir.✓
- cBir sink connector'ın dış sistemine yazdığı her mesajın bir kopyasını saklar.
- dYeni connector konfigürasyonu göndermek için kullanılan REST API kimlik bilgilerini saklar.
Açıklama:Source connector'lar Kafka'nın kendisi olmayan sistemlerden (bir veritabanı, dosya, API) okur, bu yüzden Connect'in her birinin ne kadar ilerlediğini bir yerde hatırlaması gerekir. offset.storage.topic tam olarak bu ilerleme işaretini her source partition için tutar. Sink connector'lar kendi ilerlemeleri için bu topic'i kullanmaz — bunun yerine sıradan Kafka consumer group mekanizmasına dayanırlar; a şıkkı bunu karıştırıyor.
St Kafka Connect Schema RegistryZorluk 1
Distributed bir Connect cluster'ındaki dahili status.storage.topic neyi tutar?
- aHer connector ve task'ın o anki çalışıyor/duraklatıldı/başarısız durumu; REST API durum sorguları için kullanılır.✓
- bREST API üzerinden gönderilen connector konfigürasyonlarını tutar.
- cSource connector'ların okudukları sistemlerde ulaştıkları offset'leri tutar.
- dSingle message transform'ların uyguladığı her dönüşümün kaydını tutar.
Açıklama:status.storage.topic, Connect REST API'sinin /connectors/{name}/status endpoint'inin okuduğu yerdir — her connector ve task'ın hangi worker'da çalıştığını, duraklatıldığını ya da başarısız olduğunu izler. Konfigürasyon config.storage.topic'te, source ilerlemesi ise offset.storage.topic'te tutulur; bu yüzden b ve c yanlış topic'i tarif ediyor.