Mantıksal replikasyon vs toplu ETL: bir senkronizasyon tarzı seçmek

“Veriyi senkronize etmek” ile hangi problemi çözüyoruz?\n\nEkipler veriyi sistemler arasında kopyalar çünkü işler nadiren tek bir yerde yürür. Satışlar bir CRM’de, ödemeler bir faturalama aracında ve operasyonlar şirket içi bir panoda olabilir. Destek tüm resmi tek bir yerde görmek ister; liderler de gerçekte olanla eşleşen raporlar ister.\n\n“Güvenilir bir senkronizasyon” tanımlaması kolay, sürdürülmesi zordur: doğru kayıtlar gelmeli, önemli hiçbir şey eksik olmamalı ve güncellemeler kullanışlı olacak kadar hızlı görünmeli. “Yeterince hızlı” işin niteliğine bağlıdır. Dolandırıcılık kontrolü dakikalar gerektirebilir. Aylık finans raporları saatlere tahammül edebilir.\n\nBir senkronizasyon bozulduğunda genelde eksik kayıtlar, çoğaltmalar, eski alanlar veya kısmi güncellemeler görünür (örneğin, bir sipariş başlığı görünür ama satır öğeleri gelmez).\n\nKullanışlı bir zihinsel model olaylar vs snapshot’lar arasındadır.\n\nOlaylar bireysel değişikliklerdir: “Sipariş #1842 oluşturuldu”, “durum gönderildi olarak değişti”, “iade yapıldı”. Değişiklik-veri yaklaşımları genellikle olayları taşır ve gerçek zamana yakın davranışı destekleyebilir.\n\nSnapshot’lar ise planlı kopyalardır: “her gece dünün siparişlerini kopyala”. Toplu ETL genelde bu şekilde çalışır. Daha basit olabilir, ama veri daha az taze olur.\n\nMantıksal replikasyon vs toplu ETL hakkındaki çoğu tartışma aslında bu seçimle ilgilidir: devam eden olay akışına mı ihtiyacınız var, yoksa periyodik snapshot’lar insanların gördüklerinden emin olmaları için yeterli mi?\n\n## Mantıksal replikasyon ve toplu ETL, basitçe açıklama\n\nMantıksal replikasyon, kaynak veritabanının değişiklikleri oldukları anda bir akış olarak göndermesidir. Tabloları bütünüyle kopyalamak yerine “satır eklendi”, “satır güncellendi” veya “satır silindi” gibi olayları yayınlar. Hedef bu değişiklikleri sırayla uygular, böylece kaynakla yakından hizalı kalır.\n\nToplu ETL ise verileri bir takvime göre alır. Bir iş veriyi çıkarır (çoğunlukla “son çalıştırmadan bu yana olan her şey”), gerekiyorsa dönüştürür ve hedefe yükler. Replikasyon canlı güncellemeler gibi hissediliyorsa, toplu ETL her saat (veya her gece) kontrol edip aradaki farkı kapatmaya benzer.\n\nGenelde farklı yerlerde çalışırlar. Replikasyon, veritabanı değişiklik günlüğüne yakın durur ve sürekli çalışır. Toplu ETL tipik olarak çalıştır, durdur, tekrar çalıştır şeklinde zamanlanan bir iştir.\n\nHer iki durumda da aynı güven sorularını yanıtlamanız gerekir:\n\n- Silmeler nasıl temsil ediliyor ki hedef “hayalet” satırlar tutmasın?\n- Aynı değişiklik iki kez gelirse ne olur (idempotency)?\n- Birçok satır hızla değiştiğinde sıralamayı nasıl doğru tutarsınız?\n- Yeniden başlatmalar veya yeniden dağıtımlar sırasında değişikliklerin kaçmasını nasıl önlersiniz?\n\nÖrnek: bir sipariş oluşturulur, sonra durumu “beklemede”den “ödenmiş”e değişir, sonra iade edilir. Replikasyon üç değişiklik olayı gönderir. Günlük snapshot yalnızca nihai durumu yakalayabilir, unless you design the batch process to preserve intermediate states.\n\n## Tazelik ve gecikme: gerçekte ne kadar gerçek zamana yakın olmanız gerekiyor?\n\nReplikasyon ve toplu ETL’yi karşılaştırmadan önce iş terimleriyle “yeterince taze”yi tanımlayın. Bir sayı ile başlayın: “destek verisi 5 dakika kadar eski olabilir” veya “finans dünün toplamlarıyla çalışabilir.”\n\nTazelik, birisi veriyi kullandığında verinin yaşıdır. Gecikme ise kaynağın değişmesi ile hedefte aynı değişikliğin görünmesi arasındaki gecikmedir. Senkronizasyon sık sık duraklıyorsa, ortalama gecikme düşük olsa bile veri “eski” olabilir.\n\n### Gecikme aslında nereden gelir\n\nBasit bir senkronizasyon bile birden çok gecikme yığar: yakalama (değişiklikleri ne zaman fark ediyorsunuz), transit (veriyi taşıma), işleme (dönüştürme ve tekrarı önleme) ve uygulama (hedefte yazma ve indeksleme).\n\nSürekli bir damla akışı (replikasyon veya sık mikro partiler) daha düzgün tazelik üretir, ama tüm gün boyunca senkronizasyonu işletirsiniz. Zamanlanmış partiler ise düşünülebilir ama zirveler yaratır: örneğin saat 02:00’de yoğun yük, ardından bir sonraki koşuya kadar eski veri.\n\nGerçeğe yakın gerçek zamanlılık, insanların hızlı karar verdiği veya müşterilerin sonuçları gördüğü durumlarda yardımcı olur. Bir destek panosu yeni siparişleri hızlıca göstermeli ki temsilci stok dışı bir şey vaat etmesin. Öte yandan ana kullanım haftalık rapor veya aylık faturalama ise her küçük güncellemeyi anında iletmek karmaşıklığı artırır ama sonucu iyileştirmez.\n\nPratik bir karar verme yolu:\n\n- Senkronize veriyi kimler kullanıyor ve hangi kararları alıyorlar?\n- Veri 15 dakika eski olursa ne bozulur?\n- Sürekli çalıştırmanın maliyeti nedir (altyapı ve on-call zamanı)?\n- Hedef ne zaman en az meşgul?\n\n## Hata kurtarma: bir şey bozulduktan sonra doğru duruma geri dönmek\n\nSenkronizasyonlar nadiren dramatik şekilde başarısız olur. Küçük, sıkıcı şekillerde başarısız olurlar: bir sunucu yeniden başlar, ağ kısa süre bağlantı kesintisi yaşar veya bir iş yükleme sırasında çöker. Hedef “hiç başarısız olmamak” değil; “doğru son duruma geri dönebilmek”tir.\n\nYaygın hata modları arasında kaynak kesintisi, hedef kesintisi, işin işlem sırasında çökmesi veya kısıtları bozan kötü veri bulunur.\n\nMantıksal replikasyonda kurtarma genelde saklı bir pozisyondan (çoğunlukla bir log offset’i) değişiklikleri yeniden oynatma anlamına gelir. Hedef kapalıysa değişiklikler birikir ve geri geldiğinde sırayla uygulanır. Uzun kesintiler sırasında replication slot’un veya eşdeğerinin sonsuza dek büyümesini yönetmek gerekir.\n\nToplu ETL’de kurtarma genelde bir zaman penceresini yeniden çalıştırmak demektir (örneğin “dünü yeniden yükle” veya “son 2 saati yeniden yükle”). Operasyonel olarak bu genelde basittir, ama yük mantığınız iki kez çalıştırılmaya karşı güvenli olmalı.\n\nEn büyük güven kırıcı kısmi yazmalardır. Bir yükleme sırasında çöküş, kopyalama veya eksik satırlara neden olabilir. Her iki stilde de işe yarayan desenler:\n\n- Aynı girdi iki kez uygulansa bile aynı durumda kalmasını sağlayacak şekilde yükleri idempotent yapın.\n- Kararlı bir birincil anahtara göre upsert tercih edin.\n- “Son işlenen” işaretinizi yalnızca başarılı bir commit sonrası ilerletin.\n- Reddedilen satırları incelemek ve yeniden oynatmak için saklayın.\n\nBackfill (geçmişi yeniden işleme) acının görüldüğü yerdir. Toplu ETL genelde bir ay verisini yeniden işlemek gerektiğinde avantajlıdır çünkü yeniden çalıştırmalar tasarımın bir parçasıdır. Replikasyon da backfill yapabilir ama genelde ayrı bir yol izler (önce snapshot, sonra değişiklikleri uygula), bu yüzden ihtiyaç duyulmadan önce test edilmelidir.\n\nÖrnek: senkronizasyon, satır öğelerini yazdıktan sonra başlık yazılmadan çökse, sipariş başına (veya parti başına) tek bir işlemle upsert tabanlı yükleme yarım senkronize siparişin kalmasını önler.\n\n## Şema evrimi: veri modeli değiştiğinde ne olur?\n\nŞema değişiklikleri, birçok senkronizasyonun güvenini sessizce kaybettiği yerdir. Bir pipeline çalışmaya devam ederken verinin anlamı altında değişebilir. Replikasyon veritabanı seviyesinde kırılabilirken, ETL genelde dönüşümlerde ve raporlarda daha sonra bozulur.\n\nEkleme (additive) değişiklikler en kolay olanlardır: yeni sütunlar, yeni tablolar, yeni opsiyonel alanlar. Tüketiciler bunları “ekstra” olarak ele alıyorsa ve varsayılanlar mantıklıysa genelde sorun çıkarmaz. Tuzak, her aşağı sistem tüketicisinin yeni alanı fark edeceğini veya nasıl backfill yapacağını varsaymaktır.\n\nKırıcı değişiklikler risklidir: yeniden adlandırma, tip değişikliği, sütun silme veya bir değerin anlamının değişmesi. Bunlar ya hızlıca hata verir (iş hatası) ya da yavaşça yanlış veri düşürür (veri hedefe gelir ama yanlıştır).\n\n### Güvenli evrim yapmak için\n\nDeğişiklikleri taşınma süresi boyunca uyumlu tutun:\n\n- Şemaları veya payload’ları versiyonlayın (v1, v2) ki eskisi ve yenisi birlikte var olabilsin.\n- Hem eski hem yeni alanların olduğu bir uyumluluk dönemi uygulayın.\n- Yeni şekle bağlı mantığı devreye almadan önce backfill yapın.\n- Hiçbir şey okumadığını doğrulamadan alanları kaldırmayın.\n\n### Eşlemelerin nerede kırıldığı\n\nGerçek kırılmalar genelde sistemler arasındaki yapıştırıcıda olur. Örnek: ETL orders tablosunu customers ile customer_id üzerinden birleştiriyorsa ve bu alan client_id olarak yeniden adlandırılırsa, birleştirme tümüyle null eşleşmelerine dönüşebilir ve yine de satırlar üretebilir.\n\nKırılgan noktaları izleyin: tip dönüşümleri, anahtarların değişmeyeceğini varsayan join’ler ve “durum bu değerlerden biri olmalı” gibi aşağı akış kuralları.\n\n## Güvenlik ve sahiplik: kim neyi senkronize etmeye izinli?\n\nGüvenlik soruları her iki yaklaşımda da benzer görünür, ama riskler farklı yerlerde ortaya çıkar. Replikasyon genelde geniş okuma erişimiyle sürekli çalışır. Toplu ETL zamanlanmıştır ama bir kerede daha büyük veri dilimleri çekebilir. Her iki durumda da senkronizasyonun yapması gereken işe izin veren en küçük izinleri hedefleyin.\n\nBir kişinin hesabı yerine adanmış bir servis hesabı kullanın. Servise yalnızca gereken tabloları, sütunları veya görünümleri okuma izni verin ve nereden bağlanabileceğini sınırlayın. Mümkünse, hedefin asla görmemesi gereken verileri önceden filtreleyen bir “sync view” sunun.\n\nHassas alanlar ekipleri şaşırtan konulardır. Hedef kayıt gerekse bile tüm alanlara ihtiyaç olmayabilir. Erken karar verin: kişisel iletişim bilgileri, ödeme bilgileri veya dahili notlar atılsın mı, maskelensin mi yoksa tokenize edilsin mi. Veriyi aktarırken şifreleyin ve gizli anahtarları pipeline konfigürasyonlarında değil, uygun bir gizli anahtar deposunda tutun.\n\nSahiplik sonsuz tartışmaları önler:\n\n- Her alan için (sadece her tablo için değil) bir doğruluk kaynağı seçin.\n- Hedefin geri yazma yapmasına izin verilip verilmeyeceğini tanımlayın.\n- Çakışmalar nasıl ele alınacak karar verin (son yazma kazanır mı, hedef düzenlemeleri yoksayılır mı, elle inceleme mi yapılır).\n- Hedefte kopyalanan verinin saklama kurallarını belirleyin.\n\nDenetim güvenin son parçasıdır. Kim veriye erişti, ne değişti ve ne zaman hedefe ulaştı sorularına cevap verebilmelisiniz. Basit bir uygulama, izlenebilir bir senkronizasyon çalıştırma id’si ve zaman damgaları taşımaktır, böylece bir güncellemenin uçtan uca takibi yapılabilir.\n\n## Senkronizasyonun güvenilir kalması için neyi izlemeli?\n\nRastgele bir salı günü senkronizasyona güvenebilmeniz için izleme gereklidir. Yaklaşım ne olursa olsun, izleme size ne kadar geride olduğunuzu, ne sıklıkla başarısız olduğunuzu ve sayıların hâlâ mantıklı olup olmadığını söylemeli.\n\nGünlük üç sağlık sinyali:\n\n- Gecikme/tazelik: hedefin kaynakla ne kadar geride olduğu\n- Hata oranı: başarısızlıklar, yeniden denemeler ve başarısız satırlar\n- İşlem hacmi: dakika başına işlenen satır veya olay sayısı ve ani sıfıra düşüşler\n\nBuna ek olarak, sessiz problemleri yakalayan küçük bir veri kalite kontrol seti ekleyin. Önemli birkaç tablo seçin (orders, invoices, tickets) ve tekrarlanabilir doğrulamalar yapın. Eğer dün kaynakta 1.240 sipariş varsa, hedefte 1.180 olmamalı — nedenini biliyorsanız başka.\n\nÇoğu şeyi kapsayan kontroller:\n\n- Günlük (kritik akışlar için saatlik) satır sayıları\n- Eşleşmesi gereken toplamlar (tutarların toplamı, ödenen sipariş sayısı)\n- Zorunlu alanlarda null oranı (email, status, timestamps)\n- Anahtarlar için benzersizlik (çift order_id yok)\n- “Silme gerçeği”: iptal edilen veya silinen kayıtlar downstream’da da kaybolmalı ya da işaretlenmeli\n\nTutarlılık sorunları genelde boşluklarda saklanır: geç gelen güncellemeler, eksik silmeler veya olayların sırasının karışması. En eski işlenmemiş zaman damgasını izleyin ve periyodik örnekleme yaparak en son sürümün var olduğunu doğrulayın.\n\nUyarı için basit ve yapılabilir tutun. Eşikler belirleyin (örneğin: gecikme 15 dakikadan fazla, hata oranı %1’in üzerinde, işlem hacmi 10 dakika boyunca baseline’ın altında) ve bir çalışma kitabı (runbook) hazırlayın: önce ne kontrol edilir, nasıl güvenli şekilde yeniden oynatılır ve doğru duruma döndüğünüz nasıl onaylanır.\n\n## Adım adım: doğru senkronizasyon yaklaşımını nasıl seçersiniz\n\nVeriyi kimlerin kullanacağını netleştirin. Finansal rapor, destek panosu ve otomatik fiyat kuralı aynı tabloları farklı şekillerde tüketir. Kararlar zaman duyarlıysa gecikmiş veri sadece sinir bozucu değil — yanlış olabilir.\n\nBasit bir karar süreci:\n\n1. Name the consumers and their decisions. List the screens, reports, and processes that depend on the sync and what they affect.\n2. Hedefleri duygu yerine sayılarla koyun. Tazelik (saniye, dakika, saat), doğruluk (hangi hatalar kabul edilebilir) ve maliyet (altyapı, mühendislik zamanı, operasyonel yük) üzerinde anlaşın.\n3. Hedefleri karşılayan en basit deseni seçin. Gerçeğe yakın gerçek zaman ve öngörülebilir değişiklik yakalama gerektiğinde replikasyonu kullanın. “Birkaç dakikada bir” yeterliyse mikro-batch’leri, raporlama ve tarihsel snapshot’lar için geceleyin toplu ETL’yi seçin. Hibrit yaygındır.\n4. Kurtarmayı planlayın. Ne kadar geriye oynatabileceğinize, backfill’i nasıl çalıştıracağınıza ve yüklerin idempotent kalmasını nasıl sağlayacağınıza karar verin.\n5. Güven kontrollerini ve sahipliği tanımlayın. Sağlığı kanıtlayan doğrulamaları (sayım, toplam, son güncellenme zamanı, spot kontroller) seçin ve kimlerin çağrılacağını, kimlerin veriyi düzelteceğini belirleyin.\n\nSomut örnek: destek müşteriyle konuşurken sipariş durumuna ihtiyaç duyuyorsa dakikalar önemlidir; bu durumda replikasyon veya mikro-batch uygundur. Finans günlük gelir rakamlarına ihtiyaç duyuyorsa geceleyin toplu ETL genelde yeterlidir.\n\n## Senkronize veriyi güvensiz yapan yaygın hatalar\n\nEn büyük tuzak, “taze” verinin otomatik olarak “doğru” veri olduğu varsayımıdır. Bir pipeline saniyeler geride olabilir ama yine de yanlış olabilir çünkü bir join değişti, bir filtre eklendi veya bir satır çoğaltıldı. Doğrulama yoksa gösterge panosu garip görünene veya müşteri şikayet edene kadar fark etmeyebilirsiniz.\n\nSilmeler başka bir sık kaçırılan konudur. Hem replikasyon hem ETL için “kaldırıldı”nın ne anlama geldiğine dair açık bir plan olmalı. Sistem A bir kaydı hard-delete yapıyorsa ama Sistem B sadece insert ve update yapıyorsa raporlar zamanla sapar. Soft-delete’ler de sorun olur eğer senkronizasyon silme bayrağını ve zaman damgasını taşımıyorsa.\n\nTekrarlanan hatalar:\n\n- Tazeliği ana hedef yapıp temel sayımlar, toplamlar ve spot kontrolleri atlamak\n- Insert ve update’leri senkronize edip silmeleri, merge’leri veya devre dışı bırakılma durumlarını kopyalamamak\n- Bir sütun yeniden adlandırıldığında, bölündüğünde veya tipi değiştiğinde gizlice kırılan sabitlenmiş alan eşlemeleri\n- Tarihsel verinin düzeltilmesi gerektiğinde backfill planı olmaması\n- Yalnızca iş hatalarına göre uyarı oluşturup gecikme, eksik veri veya yavaş sürüklenme üzerine uyarı kurmamak\n\nÖrnek: CRM’iniz bir müşteriyi “inactive” olarak işaretleyip silmiyorsa ve ETL sadece status = active olan müşterileri kopyalıyorsa, bir ay sonra gelir raporları iyi görünebilir ama tutundurma metrikleri şişmiş olur çünkü inactive müşteriler hiç aktarılmamıştır (veya silinmemiştir). Her şey taze görünüyordu ama doğruluk çoktan bozulmuştu.\n\n## Senkronizasyonu “tamam” ilan etmeden önce hızlı kontrol listesi\n\n“Tamam”ı düz sayılar, net sahiplik ve kanıtlanmış kurtarma ile üzerinde anlaşılmış şekilde yazın. İlk günde iyi görünen bir senkronizasyon gerçek değişiklikler ve arızalar başlayınca sürüklenebilir.\n\n- Tazelik taahhüdü yazılı. Hedef gecikmeyi, nerede ölçüleceğini ve kaçırılırsa ne olacağını tanımlayın.\n- Doğruluk kaynağı açık. Ana alanlar (status, price, customer email) için hangi sistemin kazandığını ve güncellemelerin tek yönlü mü çift yönlü mü olduğunu belgeleyin.\n- Kurtarma uçtan uca test edildi. Bir arızayı simüle edin ve yeniden oynatma veya yeniden çalıştırma ile çoğaltma veya eksik satır olmadan geri dönebildiğinizi doğrulayın.\n- Şema değişikliği kuralları var. Kim onaylar, nasıl yayılır, yeniden adlandırmalar, tip değişiklikleri ve düşürülen sütunlar nasıl ele alınır karar verin.\n- İzleme işlem yapılabilir. Gecikmeyi, hata oranını ve çekirdek veri kontrollerini izleyin; uyarılar bir görevliye sırada ne yapılacağını söylemeli.\n\nGerçek kontrol: delivery_instructions siparişlere eklendiğinde, süreciniz bunun otomatik senkronize edilip edilmediğini, yüksek sesle hata verip vermediğini veya güvenle yok sayılıp sayılmayacağını netleştirmeli.\n\n## Gerçekçi bir örnek: iki sistem arasında siparişleri senkronize etmek\n\nBir şirketin siparişleri PostgreSQL’de sakladığını düşünün. İki ekip bu veriye ihtiyaç duyuyor: Destek “sipariş nerede?” sorusuna cevap verecek canlı bir pano istiyor, Finans ise kapanış ve raporlama için kararlı günlük rakamlar istiyor.\n\nHer şeyi tek bir araca zorlamak yerine hibrit bir yaklaşım kullanıyorlar.\n\nDestek için mantıksal replikasyon kullanıyorlar; yeni siparişler ve durum güncellemeleri destek panosunu besleyen okuma-optimize veritabanında hızla görünsün diye. Finans için iş saatleri sonrası günlük toplu ETL çalıştırıyorlar. Bu, nihai siparişleri raporlama ambarına yüklüyor, iş kurallarını (vergi, indirim, iadeler) uyguluyor ve ay boyunca değişmeyen günlük bir snapshot üretiyor.\n\nSonra bir şema değişikliği oluyor: ürün ekibi refund_reason ekliyor. Destek bunu hemen görmek istiyor. Replikasyon yeni sütunu hızla iletebilir; toplu iş başlangıçta bunu opsiyonel olarak (varsayılan “unknown”) ele alır, raporlama mantığı hazır olana kadar.\n\nBir gün Destek hedefi 3 saat boyunca kapalı kalıyor. Geri geldiğinde replikasyon kaydedilmiş pozisyondan yakalar ve devam eder. Ana adım sadece “yeniden başladı” demek değil, “doğru” olduğundan emin olmaktır: kesinti penceresi için sipariş sayıları doğrulanır ve birkaç yeni sipariş uçtan uca spot kontrol edilir.\n\nHer sabah rakamlara güvenmeden önce kısa bir sinyal seti kontrol ederler: replikasyon gecikmesi, son 24 saatin kaynak vs hedef sipariş sayıları, finans tablolarında çoğaltmalar, partinin başarı durumu ve her çalıştırmada yüklenen satır sayısı ile yüksek değerli siparişlerin her iki sistemde de örnek doğrulaması.\n\n## Sonraki adımlar: senkronizasyonu görünür ve işletmesi kolay hale getirin\n\nBir yaklaşım (veya hibrit) seçtikten sonra gerçek iş, senkronizasyonu insanların her gün güvenebileceği bir şeye dönüştürmektir. Bir ölçülebilir hedef seçin ve ona ürün metriği gibi davranın. Çoğu ekip için ilk hedef ya tazelik (verinin ne kadar yeni olduğu) ya da doğruluk (ne sıklıkla yanlış olduğu) olur.\n\nKüçük başlayın: bir tablo, bir olay akışı veya bir iş akışı (örneğin orders veya tickets) ile başlayın. O yolu kararlı hale getirin, sonra modeli kopyalayın. Hızla genişlemek ama sorunları hızlıca tespit edip düzeltememek işi daha büyük ve hızlı bir karışıklığa dönüştürür.\n\nTeknik olmayan ekipler için pratik bir “senkronizasyon durumu” görünümü genelde şunları içerir: hedefe kıyasla mevcut gecikme, son başarılı senkronizasyon zamanı, son başarısız deneme, bugün işlenen hacim vs beklenen aralık ve durum kırmızı olduğunda ne yapılacağına dair kısa bir not.\n\nBöyle yönetim ekranlarını hızlıca oluşturmak isterseniz, AppMaster (appmaster.io) gibi no-code platformları, şema veya iş akışı evrildiğinde her şeyi yeniden yazmadan izleme görünümü yayınlamanıza yardımcı olabilir.