Veri mezarlığı olmadan veri entegrasyonu: ERP/CRM/Depo için CDC, Olay Akışı ve ETL karşılaştırması

ERP, CRM ve depo yönetimini birbirine bağlayanlar genellikle iki şeyi aynı anda ister: süreçlerin kesintisiz çalışması (ör. Auftrag → Sipariş hazırlama → Versand → Rechnung), ve verilerin analizler için erişilebilir olması (ör. tedarik edilebilirlik, Deckungsbeiträge, iade oranları). Pratikte bunun sonucu hızla “Bugün raporlarda olması lazım” ile “Üretim ERP’sini destabilize edemeyiz” arasındaki bir gerilim olur. Tam da burada, veri mezarlığı olmadan veri entegrasyonu mümkün olup olmadığı ya da yıllar içinde CSV-aktarımları, gece işleri, gölge-tablolar ve açıklığa kavuşturulmamış veri kopyalarının düzensiz bir karışımı birikip birikmeyeceği karar verilir.

Bu yazı üç ana yaklaşımı karşılaştırır: ETL (Extract, Transform, Load), CDC (Change Data Capture, yani veri değişikliklerini tespit edip iletme) ve Event Streaming (olayların bir broker üzerinden sürekli bir veri akışı olarak yayınlanması). Odak noktasında programlama detayları değil; mimari sonuçlar, işletme gerçekliği, veri kalitesi, güvenlik ve rollout-sorunları vardır — kurumsal sistemler arasındaki entegrasyon projelerinde gerçekte nasıl ortaya çıktıkları açısından ele alınmıştır.

Warum Integrationen oft zum Datenfriedhof werden

Bir veri mezarlığı nadiren kötü niyetle oluşur. Tipik nedenler şunlardır:

• Belirsiz sistem sınırları: ERP bir süre “yetkili” olur, sonra CRM öne geçer ve depoda kendi durum mantığı vardır. Bir veri otoritesi (System of Record) belirlenmeden çatışmalar kaçınılmazdır.
• Acil/Ad‑hoc talepler: “Hızlıca bir dashboard lazım” ERP’ye doğrudan erişimler ile sonuçlanır; sonrasında ek sorgular, materialized view’lar veya kopyalar eklenir. Her kısa vadeli kazanım işletme yükünü ve sorumlulukları kaydırır.
• Eksik arayüz sözleşmeleri: Schnittstellenverträge (hangi alanlar, hangi semantik, hangi sürümlendirme) yoktur. Sonuç: şema kayması (Schema-Drift) — alanlar anlamını veya yapısını değiştirir ve downstream sistemler bunu zamanında fark etmez.
• İşletme konsepti yok: işler “bir yerde” çalışıyor, kimlik bilgileri betiklerde duruyor, veri boşlukları için alarm yok ve kimse bir raporun “tam” olup olmadığını yanıtlayamıyor.

ETL, CDC ve Event Streaming bu problemin farklı parçalarını çözer. Önemli olan yaklaşımı süreç kritikliği, gecikme gereksinimi ve işletme olgunluğuna uygun seçmektir — ve entegrasyon yolunu tek seferlik bir proje çıktısı değil, ürün olarak işletmektir.

Begriffe sauber einordnen: ETL, CDC und Event Streaming

ETL steht für „Extract, Transform, Load“: Veriler kaynak sistemlerden çekilir, dönüştürülür (ör. temizleme, agregasyon, eşleme) ve genellikle bir hedef sisteme yüklenir, sıklıkla bir Data Warehouse. Geleneksel olarak bu batch‑odaklı gerçekleşir; ör. gece veya saatlik olarak.

CDC (Change Data Capture) değişiklikleri tespit eden ve bunları delta olarak ileten mekanizmaları tanımlar: yeni/güncellenmiş/silinen kayıtlar. CDC zaman damgaları, tetikleyiciler veya işletme açısından genellikle en temiz yöntem olan veritabanı işlem günlükleri üzerinden uygulanabilir. Amaç çoğunlukla neredeyse gerçek zamanlıdır (near realtime), sürekli tam çekimler yapmak zorunda kalmadan.

Event Streaming olayların (ör. „Auftrag freigegeben“, „Wareneingang gebucht“) bir Message Broker üzerinden sürekli bir akış halinde yayınlanmasını ifade eder (ör. Kafka‑benzeri sistemler veya Service‑Bus kavramları). Tüketiciler event’leri abonelikle alır ve kendi hızlarında işler. Önemli: Bir event otomatik olarak verinin „tam gerçeği“ değildir; genellikle bağlam içeren bir durum değişikliğidir.

İşletmede gerçekten önemli olan sorulara göre karşılaştırma

Gecikme: Verilerin gerçekten ne kadar hızlı olması gerekiyor?

Birçok ERP raporu için „dün gece“ verileri yeterlidir. Depoda operasyonel kontrol için „5 dakika eski“ olmak bile fazla geç olabilir (ör. stok kısıtlarında). Burada geçerlidir:

• ETL planlanabilir güncelleme pencereleri sağlar, ancak tasarım gereği „anında“ değildir.
• CDC, veri değişikliklerini iş mantığını yeniden modellemeden raporlama veya arama sistemlerine hızlıca yansıtmak istiyorsanız uygundur.
• Event Streaming, süreçlerin zamanında tepki vermesi gerekiyorsa uygundur (ör. gönderi etiketi oluşturma, müşteri durumunu güncelleme, bildirim tetikleme).

Yaygın bir hata her yerde „gerçek zamanlı“ talep etmektir. Gerçek zamanlılık izleme, hata yönetimi ve veri tutarlılığında karmaşıklığı artırır. Mantıklı olan bir sınıflandırma yapmaktır: Hangi veriler operasyonel (süreç açısından kritik), hangileri analitik (raporlama için kritik), hangileri arşivsel (Audit/Compliance)?

Tutarlılık: Kısmi hatalarda ne olur?

Dağıtık entegrasyonlarda kısmi hatalar normaldir: ağ kopmaları, zaman aşımı, kilitlenmeler, bakım pencereleri. Önemli olan yaklaşımınızın bunları sağlam şekilde hafifletip hafifletmediğidir.

• ETL genellikle parti çalışır. Bir parti başarısız olursa hedefteki veri durumu çoğunlukla „X zamanına kadar“ tutarlıdır, sonrasında güncel değildir. Bu, şeffaf olduğu sürece raporlama için sıkça kabul edilebilir.
• CDC deltaları aktarır. Süreç aksarsa birikme oluşur. Bu kontrol edilebilir, ancak gecikmeyi (Lag) ölçmeli ve eşiklere göre alarm vermelisiniz.
• Event Streaming hataları tüketicilere kaydırır. Bunun için idempotenz (çoklu işleme durumunda yan etki olmaması), yeniden deneme stratejileri ve bir Dead-Letter-Queue (işlenemeyen mesajların depolandığı yer) gerekir; aksi takdirde hatalar „sessizce“ kalır ve ancak iş biriminde ortaya çıkar.

Tutarlılık aynı zamanda iş konusudur: „Auftrag + Positionen + Reservierungen“ paket halinde mi gelmeli, yoksa eventual consistency (sonradan uyum sağlama) yeterli mi? Paket bağımlılığı ne kadar yüksekse, o kadar çok işlem sınırlarına ve net sıraya ilişkin kurallara ihtiyaç duyarsınız.

ERP için Yük ve Risk: Ne nasıl yükleniyor?

Birçok entegrasyon sorunu gerçekte kaynak sistemdeki performans ve kilitlenme sorunlarıdır. Das ERP ist ein OLTP-System (Online Transaction Processing): çok sayıda küçük işlem, yüksek yazma yükü, hassas indeksler.

• ETL genellikle büyük veri hacimleri çeker. Temiz zaman pencereleri, Read-Replica veya hedefe yönelik ekstrakt tabloları olmadan ETL, ERP’yi yavaşlatabilir.
• CDC üzerinden Logs çalışmak genellikle daha naziktir, çünkü „zaten var olan“ değişiklik akışını kullanır. Trigger tabanlı CDC ise yazma yollarını uzatabilir ve yüksek yük altındaki tablolar için bir risk oluşturur.
• Event Streaming, eventler uygulamanın kendisinden geliyorsa doğrudan okuma yükünü önler. Ancak eventler „veritabanından üretiliyorsa“, tekrar CDC’ye yakınsınız – benzer değerlendirmeler geçerli olur.

Pratik kural: Eğer ERP bugün zaten dar kaynaklıysa, entegrasyon ek tam veri çekimleriyle başlamamalıdır. Çoğu durumda önce bir ayırma faydalıdır, ör. CDC ile ayrı bir raporlama veya entegrasyon şemasına, ve ancak ondan sonra dönüşümler yapılmalıdır.

Günlük hayatta ETL: Raporlama için uygun, süreç bağlayıcısı olarak riskli

ETL birçok şirkette başlangıç noktasıdır çünkü kavramsal olarak somuttur: „Wir holen Daten, bereiten sie auf, laden sie ins DWH.“ Klasik BI gereksinimleri için bu hâlen geçerlidir.

ETL’in Güçlü Yönleri

• Planlanabilirlik: Gece çalıştırmaları veya saatlik çalıştırmalar iyi yönetilebilir ve bakım pencerelerine uyacak şekilde ayarlanabilir.
• Dönüşüm mantığının merkezileştirilmesi: Temizleme, eşleme, tarihçeleştirme (z. B. Slowly Changing Dimensions) DWH bağlamında yerleşiktir.
• Denetlenebilirlik: Çalışma-ID’leri, satır sayıları ve checksumlar ile neyin ne zaman yüklendiğini izleyebilirsiniz.

Tipik riskler ve „Datenfriedhof“-örüntüleri

• Doğrudan erişimin kontrolsüz çoğalması: Çıkarılmış tablolara doğrudan dayanan analizler arttıkça daha fazla „resmi olmayan veri ürünü“ ortaya çıkar.
• Şema sapması ön uyarı olmadan: ERP’de alanlar değiştiğinde bu genellikle bir sonraki çalıştırmada fark edilir — ya da daha kötüsü: hiç fark edilmez, çünkü NULL değerler „süzülüp“ geçer.
• Toplu iş pencereleri daralır: Veri hacmi büyür, çalıştırma süresi uzar; bir noktada ETL, yedeklemeler, Reorgs veya geceleyin çalışan ERP iş zincirleriyle çakışır.

Somut örnek: Bir depo günlük olarak „stoğu olmayan ancak açık siparişleri olan maddeler“ raporuna ihtiyaç duyar. ETL raporu olarak kabul edilebilir. Ancak bu rapor operasyonel sevk planlaması için temel alındığında 24 saatlik gecikme bir anda sektörel olarak kritikleşir. Bu durumda ETL süreçlerin „yapıştırıcısı“ haline gelir — ve bu nadiren stabildir.

CDC: Deltalara ve Yakın Gerçek Zamanlılığa Pragmatik Yol

CDC genellikle en uygun çözümdür; ERP/CRM/depo verilerini arama sistemlerine, Data Warehouse’a veya entegrasyon veritabanlarına zamanında aktarmak istediğinizde ve her iş mantığını bir olay modeline dönüştürmeden bunu yapmak istediğinizde sıkça tercih edilir.

CDC varyantları ve bunların işletme etkileri

• CDC über Zeitstempel/High-Watermark: Son zaman damgasından itibaren „her şeyi“ okursunuz. Bu basittir, ancak sonradan yapılan düzeltmelere, zaman sapmasına ve eksik silme olaylarına karşı hassastır.
• Tetikleyici tabanlı CDC: Değişiklikler ek olarak Change tablolarına yazılır. Fonksiyonel olarak açıktır, ancak yazma yükünü artırır ve şema değişikliklerinde temiz yetkilendirme ile bakım gerektirir.
• Log-basierte CDC: Değişiklikler işlem günlüğünden türetilir. Bu genellikle daha yüksek performans sağlar ve gerçeğe daha yakın olur, fakat Log-Retention, yedeklemeler ve bakım işleri bir anda entegrasyon açısından kritik hale geldiği için dikkatli konfigürasyon gerektirir.

Yöneticiler için önemli: CDC „bir kez açıp bırakılacak“ bir özellik değildir. Gecikmeyi izlemeniz, yeniden senkronizasyon prosedürleri tanımlamanız (z. B. belirli tabloların yeniden oluşturulması) ve hedefte değişiklik geçmişinin ne kadar süre saklanacağını belirlemeniz gerekir.

CDC’nin özellikle iyi yaptığı şeyler

• Tam alımların yükünü azaltma: Başlangıç snapshot’ından sonra yalnızca deltalara göre güncellemeler çalışır.
• OLTP ile Analytics’in net ayrımı: Raporlama, ERP’yi etkilemeden ayrı bir veritabanı veya bir warehouse üzerinde çalıştırılabilir.
• Teknik olarak tarafsız veri sunumu: Downstream ekipleri dönüşüm adımlarını bağımsız olarak yineleyebilir.

Uygulama örneği: Bir CRM, bir müşterinin açık teslimatları olup olmadığını günlük olarak bilmelidir; ERP’de sürekli karmaşık sorgular çalıştırılmasına gerek kalmadan. CDC, ilgili tabloları veya görünümleri bir entegrasyon veritabanına yansıtır; CRM oradan okur. Sonuç: ERP’de daha az yük zirvesi ve sorgular hedeflenmiş şekilde indekslenebilir.

Event Streaming: Süreçlerin tepki vermesi gerektiğinde – ve siz sorumluluğu kabul ettiğinizde

Event Streaming özellikle yalnızca veri kopyalamakla kalmayıp süreç reaksiyonlarını orkestre etmek istiyorsanız faydalıdır: durum değişiklikleri, bildirimler, takip görevleri, iş ortaklarıyla entegrasyonlar. Bir Event, „gerçekleşmiş bir şey“dir — zaman damgası, tanımlayıcılar ve gerekli asgari bağlam dahil.

Event Streaming’in Güçlü Yönleri

• Ayrıştırma: Üretici ve tüketici aynı anda erişilebilir olmak zorunda değildir. Bu, bakım pencerelerindeki arızaya yatkınlığı azaltır.
• Tüketiciler aracılığıyla ölçeklenme: Birden fazla sistem aynı Event’i kullanabilir (örn. CRM, sevkiyat, BI), ERP her hedef için ayrı ayrı teslimat yapmak zorunda kalmaz.
• Akışta şeffaflık: İyi bir izleme ile tüketici başına işlem hacmini, birikmeyi ve hata oranlarını görebilirsiniz.

Riskler und typische Fehlannahmen

• „Event göndeririz, o zaman veri kalitesi sağlanmış olur“: Event’ler, üst akışta doğrulamalar eksikse yanlış durumları da taşır. Veri kalitesi bir iş disiplini olarak kalır.
• İdempotenz unutuluyor: Çift Event’ler meydana gelir (retry, ağ, rebalancing). Tüketiciler, benzersiz Event-ID’leri ve „zaten işlenmiş“ kontrolleri gibi yöntemlerle çift işleme toleransı göstermelidir.
• Şema ve sürüm yönetimi: Event mesajları arayüz sözleşmeleridir. Versiyonlama ve kullanımdan kaldırma planı olmadan kaos oluşur — sadece daha hızlı.
• Sıralama bedava değildir: Birçok broker sıralamayı yalnızca tanımlı bölümler/anahtarlar içinde sağlar. Hangi anahtarın (örn. Sipariş-ID) düzeni garanti ettiği iş açısından açık olmalıdır.

Somut senaryo: Depoda bir mal çıkışı kaydedilir. ERP faturalama yapmalı, CRM müşteri durumunu güncellemelidir ve takip portalı bir gönderi bilgisi sağlamalıdır. Event Streaming bunu düzgün şekilde ayrıştırabilir. Ancak faturalamanın kesinlikle durum değişikliğinden önce gerçekleşmesi gerekiyorsa, ya süreç koordinasyonu gerekir (örn. Saga/Choreografie) ya da kimin orkestratör olduğuna ilişkin net kurallar. Aksi halde durumlarda tutarsızlık oluşur.

Karar desteği: Hangi yaklaşım hangi hedefe uygundur?

Entegrasyon projelerinde yanlış temel karar maliyetlidir. Uygulamalı bir sınıflandırma:

Hedefiniz öncelikle raporlama ve analitik ise

• Başlangıç noktası: ETL veya ELT (Önce yükleme, hedef sistemde daha sonra dönüşüm) – net çalıştırma planlarıyla.
• Güncellik arttığında: CDC, Warehouse’a veri beslemesi olarak; ETL/ELT dönüşüm ve modelleme için.

Eğer hedefiniz operasyonel, zamanlı senkronizasyon ise

• Başlangıç noktası: CDC tablo/nesne yansıtımı için; buna ek olarak doğrulama ve çakışma çözümü için hafif servisler.
• Gerçek tepki zincirleri gerekiyorsa: Event Streaming, ancak her tüketici için tanımlı sahiplik ve işletme sorumluluğu ile.

Eğer hedefiniz ERP/CRM/Depo arasında süreç entegrasyonu ise

• Başlangıç noktası: Event Streaming veya mesaj tabanlı entegrasyon; geri kanallar (onay bildirimleri) ve hata yolları ile tamamlanmış.
• ETL burada yalnızca yan akışlar için (örn. günlük mutabakatlar, arşiv, BI), operasyonel eylemler için tetikleyici olarak değil.

Önemli: Gerçekte nadiren “ya-bu-ya-da” durumu söz konusudur. Birçok sağlam mimari şu kombinasyonu kullanır: Süreçler için Event’ler, veri sağlama için CDC ve raporlama modelleri için ETL/ELT.

Mimari sonuçlar — erken netleştirmeniz gerekenler

Veri egemenliği ve Golden-Record soruları

Kim neyi değiştirebilir? Bir „Golden Record“ bir nesne için (müşteri, madde, sipariş) alanında geçerli veri kaydıdır. Birden fazla sistem yazıyorsa çakışma kurallarına ihtiyacınız vardır: öncelikler, manuel çözüm veya MDM yaklaşımları (Master Data Management). Bu kurallar olmadan entegrasyon sürekli “Neden veriler farklı?” bileti haline gelir.

Hata yönetimi: Tasarım, sonradan düzeltme değil

ETL, CDC veya Event Streaming fark etmeksizin: Tanımlı hata sınıflarına ihtiyacınız var. Yaygın olarak üçe ayrılması önerilir:

• Teknik hatalar (Timeout, ağ, geçici kilitlenmeler): Backoff ile otomatik yeniden deneme.
• Semantik hatalar (zorunlu alan eksik, bilinmeyen durum): karantina/Dead-Letter’e alınmalı, ticket oluşturulabilir şekilde.
• Süreç çatışmaları (sıra ihlali, çift kayıt): konuya ilişkin çözüm süreci, genellikle manuel karar ile.

Karantina mekanizması olmadan “Entegrasyon yeşil, ama bazı vakalar eksik” durumuna düşersiniz. Bu, hangi veri durumunun “gerçek” olduğunu kimsenin bilmemesi nedeniyle verilerin mezarlığına giden en hızlı yoldur.

İzleme, uyarı ve izlenebilirlik

IT yönetimi ve işletme için somut sorular önemlidir: Saatte kaç veri kaydı/event var? Geriikme (backlog) ne kadar büyük? Hangi arayüz en çok yeniden denemeye neden oluyor? ETL çalıştırma izlemesine ihtiyaç duyar (başlangıç/bitiş, satır sayıları), CDC gecikme metriklerine ihtiyaç duyar, Event Streaming ise consumer-lag ve Dead-Letter oranlarına ihtiyaç duyar. Buna ek olarak korelasyonlu loglar (örn. sipariş-ID) olmalıdır, böylece destek vakaları ekran görüntüleriyle bitmez.

Güvenlik ve Uyumluluk: Veri kopyaları bir sorumluluktur

Entegrasyon kopyalar üretir. Kopyalar yeni saldırı yüzeyleri ve yeni saklama soruları demektir. Projelerde genellikle geç kalan tipik noktalar:

• Least Privilege: ETL ve CDC hesapları yalnızca gerekli olanı okumalıdır. Event üreticileri/tüketicileri için en az yetkiye sahip servis hesapları zorunludur.
• Secrets-Handling: Betiklerde veya Görev Zamanlayıcıda parolalar klasik bir hatadır. Daha doğru olan merkezi bir secrets yönetimi veya en azından düzenli rotasyon ve denetimdir.
• DSGVO und Löschung: ERP’de silme/engelleme yapıldığında DWH/Data Lake/Stream içinde ne olacağı net olmalıdır. CDC silme olaylarını yansıtmalı, ETL silme veya anonimleştirme mantığına ihtiyaç duyar.

Rollout und Migration: So vermeiden Sie Big-Bang-Integrationen

Özellikle zaman içinde büyümüş süreçlerde kademeli geçiş daha stabildir. Pratik bir yol:

1. Envanter çıkarmak: Hangi veri akışları mevcut (Excel, SFTP, doğrudan DB erişimleri dahil)? Hangileri süreç açısından kritik?
2. Her alan için stabil Zielzustand: örn. ‚Stok durumu WMS’den, sipariş durumu ERP’den, müşteri iletişimi CRM’den gelir‘.
3. Paralel işletim ve mutabakat: CDC/ETL önce ’shadow‘ olarak çalışır, sonuçlar mevcut durumla karşılaştırılır (delta raporları, örneklem kontrolleri).
4. Cutover ve geri dönüş: Operasyonel entegrasyonlar için: Event/CDC kaynağına geçiş, ancak net bir geri dönüş düzeyi ile (örn. salt-okuma sorguları veya geçici batch).
5. Temizleme: Eski işleri kapatmak, erişimleri kaldırmak, dokümantasyon ve sahipliği netleştirmek. Bu adım olmadan veri mezarlığı varlığını korur, sadece yeni bir süslemeyle.

Önemli olan beklentilerin yönetilmesidir: Bir entegrasyon asla ‚tamam‘ olmaz. Yeni alanlar, yeni süreçler, yeni lokasyonlar — bunların hepsi veri akışlarını etkiler. Başarılı ekipler bu nedenle bir bakım modu tanımlar: sürümleme, testler, onaylar, izleme ayarlarının uyarlanması.

Fazit: Datenintegration ohne Datenfriedhof braucht Technik – und Betriebsklarheit

ETL raporlama için sağlam bir araç olmaya devam eder; koşul olarak çalışma planları, veri sözleşmeleri ve batch pencerelerinin büyümesini kontrol altında tutmanız gerekir. CDC genellikle güncel veri durumlarına ulaşmak için pragmatik bir yoldur, kaynak sistemleri rahatlatır ve OLTP ile analiz arasında temiz bir ayırma sağlar. Event Streaming süreçlerin tepki vermesi ve birden çok sistemin olayları kullanması gerektiğinde güçlüdür — ancak tutarlı hata yönetimi, sürümleme ve her tüketici için sahiplik gerektirir.

Pratikte belirleyici soru ‚hangi teknoloji modern‘ değil, şudur: Süreçlerimizin hangi gecikme ve güvenilirliğe ihtiyacı var – ve sürekli olarak hangi işletme kapasitesini sürdürebiliriz? Bunu erken netleştirirseniz, entegrasyonlar çürümeye başlamadan büyüyecek şekilde inşa edilebilir.

Eğer ERP, CRM ve depo arasındaki entegrasyonlarınızı yapılandırılmış şekilde modernize etmek istiyorsanız – işletme konsepti, veri sözleşmeleri ve geçiş yolu dahil – bizimle konuşun:

Bu konu için Change Data Capture (Cdc) ve ERP Integration da önemlidir. Bu yazı bu hususları anlaşılır şekilde sınıflandırır ve günlük hayatta nelere dikkat edilmesi gerektiğini gösterir.

Proje veya modernizasyon girişiminizi Net-Base ile görüşün.