Integracija podataka bez groblja podataka: CDC, Event Streaming i ETL u usporedbi za ERP/CRM/skladišta

Tko povezuje ERP, CRM i upravljanje skladištem obično želi dvije stvari istovremeno: procesi trebaju teći bez prekida (npr. Auftrag → Kommissionierung → Versand → Rechnung), i podaci trebaju biti dostupni za analize (npr. sposobnost isporuke, doprinosi pokriću, stopa povrata). U praksi se brzo pojavljuje jaz između „Treba nam to danas u izvještajima“ i „Ne smijemo destabilizirati produktivni ERP“. Upravo tu se odlučuje hoće li Datenintegration ohne Datenfriedhof uspjeti ili će se tijekom godina nakupiti nerazmrsivi miks CSV‑eksporta, noćnih zadataka, sjenovitih tablica i nejasnih kopija podataka.

Ovaj članak uspoređuje tri središnja pristupa: ETL (Extract, Transform, Load), CDC (Change Data Capture, tj. otkrivanje i prijenos promjena podataka) i Event Streaming (događaji kao stalan tok podataka preko brokera). Fokus nije na detaljima programiranja, nego na arhitektonskim posljedicama, operativnoj stvarnosti, kvaliteti podataka, pitanjima sigurnosti i rollout‑a – onako kako se stvarno javljaju u integracijskim projektima između poslovnih sustava.

Warum Integrationen oft zum Datenfriedhof werden

Groblje podataka rijetko nastaje iz zle namjere. Tipični uzroci su:

• Neprecizne granice sustava: ERP je ponekad „vodeći“, ponekad CRM, a skladište ima vlastitu logiku statusa. Bez definirane nadležnosti podataka (System of Record) sukobi su unaprijed predodređeni.
• Ad‑hoc zahtjevi: „Trebamo brzo dashboard“ vodi direktnim pristupima ERP‑u, kasnije dolaze dodatni upiti, materializirani pogledi ili kopije. Svaki brzi uspjeh premješta operativno opterećenje i odgovornosti.
• Nedostatak ugovora: ugovori o sučeljima (koja polja, kakva semantika, kako će se verzionirati) nedostaju. Rezultat: Schema‑Drift – polja mijenjaju značenje ili strukturu bez da downstream sustavi to pravodobno uoče.
• Nema koncepta za rad: zadaci rade „negdje“, vjerodajnice leže u skriptama, nema sustava upozorenja kod nedostataka podataka, i nitko ne može odgovoriti je li izvještaj „potpun“.

ETL, CDC i Event Streaming rješavaju različite dijelove ovog problema. Ključno je da odaberete pristup prema kritičnosti procesa, zahtjevu za latencijom i razini operativne zrelosti – i da put integracije upravljate kao proizvod, a ne kao jednokratni artefakt projekta.

Begriffe sauber einordnen: ETL, CDC und Event Streaming

ETL znači „Extract, Transform, Load“: podaci se uzimaju iz izvorišnih sustava, preoblikuju (npr. čiste, agregiraju, mapiraju) i učitavaju u ciljni sustav, često Data Warehouse. Klasično se to odvija batch‑orijentirano, npr. noću ili satno.

CDC (Change Data Capture) opisuje mehanizme koji detektiraju promjene u podacima i prenose ih kao deltu: novi/ažurirani/izbrisani zapisi. CDC se može provesti preko vremenskih oznaka, triggera ili – iz operativne perspektive često najčistije – preko transakcijskih logova baze podataka. Cilj je obično „blizu stvarnog vremena“, bez stalnog izvođenja potpunih izvoza podataka.

Event Streaming odnosi se na objavljivanje događaja (npr. „Auftrag freigegeben“, „Wareneingang gebucht“) kao stalan tok preko Message Brokera (npr. sustavi slični Kafki ili koncepti service‑busa). Potrošači se pretplaćuju na događaje i obrađuju ih vlastitim tempom. Važno: događaj nije automatski „cijela istina“ o podacima, već često promjena stanja s kontekstom.

Usporedba prema pitanjima koja u radu zaista znače

Latencija: Koliko brzo podaci doista moraju biti?

Za mnoge ERP-izvještaje dovoljni su podaci od „prošle noći“. Za operativno upravljanje u skladištu „stari 5 minuta“ može već biti prekasno (npr. kod ograničenih zaliha). Ovdje vrijedi:

• ETL daje planabilne prozore ažuriranja, ali po dizajnu nije „stvarno vrijeme“.
• CDC je dobar kad želite brzo preslikati izmjene podataka u reporting- ili sustave za pretraživanje, bez ponovnog modeliranja poslovne logike.
• Event Streaming odgovara kad procesi trebaju reagirati u bliskom vremenu (npr. generiranje otpremnih naljepnica, ažuriranje statusa kupca, pokretanje obavijesti).

Česta pogreška je tražiti „stvarno vrijeme“ svugdje. Stvarno vrijeme povećava složenost u monitoringu, rukovanju greškama i konzistenciji podataka. Korisna je klasifikacija: Koji su podaci operativni (kritični za proces), koji analitički (kritični za izvještavanje), koji arhivski (revizija/usklađenost)?

Konzistencija: Što se događa kod djelomičnih pogrešaka?

U distribuiranim integracijama djelomične pogreške su normalne: prekidi mreže, time-outi, zaključavanja, periodi održavanja. Presudno je hoće li vaš pristup to robusno ublažiti.

• ETL obično radi u batch-ovima. Ako batch zakaže, stanje podataka u odredištu je često konzistentno „do točke X“, nakon čega je zastarjelo. To je za reporting često prihvatljivo sve dok je transparentno.
• CDC prenosi delte. Ako proces zapne, nastaje nakupljanje. To je upravljivo, ali morate mjeriti zaostatak i alarmirati pri prekoračenju pragova.
• Event Streaming pomiče greške na konzumente. Zato trebate idempotenciju (višeprocesno obrađivanje bez nuspojava), strategije ponovnog pokušaja i Dead-Letter-Queue (spremište za neobradive poruke), inače greške postaju „tih“ i pojavljuju se tek u poslovnom području.

Konzistencija je također stručna odluka: Mora li „Auftrag + Positionen + Reservierungen“ stići kao paket, ili je dovoljna eventualna konzistencija (kasnije usklađivanje)? Što je veća ovisnost elemenata paketa, to je vjerojatnije da će vam trebati granice transakcije i jasna pravila redoslijeda.

Opterećenje i rizik za ERP: što se kako opterećuje?

Mnogi problemi integracije u pravilu su problemi performansi i zaključavanja u izvornom sustavu. ERP je OLTP-sustav (Online Transaction Processing): mnogo malih transakcija, visoko opterećenje pisanja, osjetljivi indeksi.

• ETL često povlači velike količine podataka. Bez čistih vremenskih prozora, Read-Replica ili ciljnih ekstrakt-tablica, ETL može usporiti ERP.
• CDC preko logova je obično nježniji jer koristi „već postojeći“ tok izmjena. Trigger-bazirana CDC može pak produžiti putove pisanja i predstavlja rizik na snažno opterećenim tablicama.
• Event Streaming izbjegava direktno čitanje na teret, ako eventi dolaze iz same aplikacije. Ako se eventi međutim generiraju „iz baze podataka“, opet ste blizu CDC-a — sa sličnim kompromisima.

Pravilo iz prakse: Ako je ERP već danas tijesno dimenzioniran, integracija ne bi trebala započeti s dodatnim punim odvojenjima. Često se isprva isplati odvojiti sustave, npr. preko CDC u zasebnu reporting- ili integracijsku shemu, a tek potom raditi transformacije.

ETL u svakodnevici: dobar za izvještavanje, rizičan kao ljepilo procesa

ETL je u mnogim tvrtkama ulazna točka jer je konceptualno opipljiv: „Mi dohvatimo podatke, očistimo ih, učitamo u DWH.“ Za klasične BI-zahtjeve to i dalje ima smisla.

Snažne strane ETL-a

• Planabilnost: noćna ili satna izvođenja su lako upravljiva i uklapaju se u prozore održavanja.
• Središnja transformacijska logika: čišćenje podataka, mapiranje, historizacija (npr. Slowly Changing Dimensions) su u kontekstu DWH-a utemeljeni.
• Mogućnost audita: pomoću ID-ova pokretanja, broja redaka i kontrolnih suma možete rekonstruirati što je i kada učitano.

Tipični rizici i uzorci „groblja podataka“

• Nekontrolirani rast direktnih pristupa: što više izvještaja izravno ovisi o izvezenim tablicama, to nastaje više „neoficijalnih data-proizvoda“.
• Promjena sheme bez ranog upozorenja: ako se u ERP-u polja promijene, to se često primijeti tek pri sljedećem pokretanju — ili, još gore, uopće ne, jer se nulte vrijednosti „provuču“.
• Batch-prozori postaju uski: volumen podataka raste, vrijeme izvođenja raste i prije ili kasnije ETL počne kolidirati s backupima, reorgovima ili noćnim lancima poslova u ERP-u.

Konkretan primjer: skladište treba dnevno izvješće „artikli bez zaliha ali s otvorenim narudžbama“. Kao ETL-izvještaj je to prihvatljivo. Ako se taj izvještaj međutim koristi kao osnova za operativno raspoređivanje, zakašnjenje od 24 sata iznenada postaje funkcionalno kritično. Tada ETL postaje ljepilo procesa — i to rijetko ostaje stabilno.

CDC: pragmatičan put do delti i skoro u stvarnom vremenu

CDC je često „sweet spot“ kad želite podatke iz ERP/CRM/skladišta pravovremeno dovesti u sustave za pretraživanje, Data Warehouse ili integracijske baze podataka, bez potrebe da svu poslovnu logiku ponovno modelirate kao event-model.

Varijante CDC-a i njihove operativne posljedice

• CDC preko vremenskih oznaka / high-watermark: čitate „sve od zadnje vremenske oznake“. To je jednostavno, ali podložno naknadnim ispravkama, driftu vremena i nedostatku događaja brisanja.
• Trigger-temeljeno CDC: promjene se dodatno zapisuju u tablice promjena. Funkcionalno je jasno, ali povećava se opterećenje pri pisanju i potrebno je uredno upravljanje pravima te održavanje pri promjenama sheme.
• Log-bazirano CDC: promjene se izvode iz transakcijskog loga. Često je performativnije i bliže istini, ali zahtijeva pažljivu konfiguraciju jer zadržavanje loga, backupi i poslovi održavanja postaju relevantni za integraciju.

Važno za administratore: CDC nije „uključi i zaboravi“. Morate nadzirati lag, definirati resync-procedure (npr. ponovno izgraditi pojedine tablice) i odrediti koliko dugo će se povijest promjena čuvati u odredišnoj bazi.

U čemu je CDC posebno dobar

• Smanjenje opterećenja punih izvlačenja: nakon inicijalnog snapshot-a pokreću se samo delte.
• Čista razdvojenost OLTP vs. Analytics: izvještavanje može raditi na zasebnoj bazi ili skladištu bez opterećivanja ERP-a.
• Tehnički neutralno pružanje podataka: Downstream timovi mogu neovisno iterirati korake transformacije.

Primjer iz prakse: CRM treba imati dnevno ažurno stanje ima li klijent otvorene isporuke, bez stalnog izvođenja složenih upita u ERP-u. CDC preslikava relevantne tablice ili poglede u integracijsku bazu podataka; CRM čita od tamo. Rezultat: manje vrhova opterećenja u ERP-u i upiti se mogu ciljano indeksirati.

Event Streaming: Kad procesi moraju reagirati – i vi prihvaćate odgovornost

Event Streaming se posebno isplati kada ne želite samo kopirati podatke, nego orkestrirati reakcije procesa: promjene statusa, obavijesti, sljedeći zadaci, integracije s partnerima. Događaj je „stvar koja se dogodila“ – uključujući vremensku oznaku, identifikatore i minimalno potreban kontekst.

Prednosti Event Streaminga

• Odvajanje: Proizvođač i konzument ne moraju biti istovremeno dostupni. To smanjuje ranjivost tijekom održavanja.
• Skaliranje preko konzumenata: Više sustava može koristiti isti događaj (npr. CRM, dostava, BI), bez da ERP mora posebno isporučivati za svako odredište.
• Transparentnost toka: Dobrom nadzorom vidite propusnost, zaostatke i stope pogrešaka po konzumentu.

Rizici i tipične pogrešne pretpostavke

• „Šaljemo događaje, pa će podaci biti ispravni“: Događaji prenose i netočna stanja ako nedostaju uzvodne validacije. Kvaliteta podataka ostaje stručna disciplina.
• Idempotencija se zaboravlja: Dupli događaji se događaju (ponovni pokušaji, mreža, rebalansiranje). Konzumenti moraju tolerirati dvostruku obradu, npr. preko jedinstvenih Event-ID‑eva i provjera „već obrađeno“.
• Upravljanje shemama i verzijama: Event-poruke su ugovori sučelja. Bez verzioniranja i plana za zastarijevanje nastaje kaos, samo brže.
• Redoslijed nije besplatan: Mnogi brokeri nude redoslijed samo unutar definiranih particija/ključeva. Stručno mora biti jasno koji ključ (npr. ID narudžbe) jamči poredak.

Konkretni scenarij: U skladištu se evidentira izlazak robe. ERP treba fakturirati, CRM treba ažurirati status kupca, a portal za praćenje treba pružiti informaciju o isporuci. Event Streaming to može jasno odvojiti. Ako međutim fakturiranje mora nužno prethoditi promjeni statusa, trebate ili koordinaciju procesa (npr. Saga/Choreografija) ili jasna pravila tko je orkestrator. Inače se stanja „trepere“.

Pomoć pri odluci: Koji pristup odgovara kojem cilju?

U integracijskim projektima pogrešan osnovni odabir je skup. Praktična kategorizacija:

Ako je vaš cilj prvenstveno izvještavanje i analitika

Ako je vaš cilj operativna, pravovremena sinkronizacija

• Početna točka: CDC za zrcaljenje tablica/objekata, uz lagane servise za validaciju i rješavanje konflikata.
• Ako su potrebni stvarni lanci reakcije: Event Streaming, ali samo s jasno definiranim vlasništvom i operativnom odgovornošću za svakog konzumenta.

Ako je vaš cilj povezivanje procesa između ERP/CRM/skladišta

• Početna točka: Event Streaming ili integracija temeljena na porukama, dopunjena povratnim kanalima (Acknowledgements) i putovima za greške.
• ETL ovdje samo za sporedne tokove (npr. dnevna usklađenja, arhiva, BI), ne kao okidač za operativne akcije.

Važno: U praksi rijetko je riječ o „ili-ili“. Mnoge stabilne arhitekture kombiniraju: Events za procese, CDC za pružanje podataka i ETL/ELT za modele izvještavanja.

Posljedice arhitekture koje biste trebali rano razjasniti

Vlast nad podacima i pitanja Golden Record-a

Tko smije što izmijeniti? Jedan „Golden Record“ je stručno važeći zapis podataka za objekt (kupac, artikl, narudžba). Ako više sustava piše, trebate pravila za konflikte: prioritete, ručno razjašnjenje ili MDM-pristupe (Master Data Management). Bez tih pravila integracija postaje stalni tiket „Zašto su podaci različiti?“.

Rukovanje pogreškama kao dizajn, ne kao naknadni rad

Bilo da se radi o ETL, CDC ili Event Streaming: trebate definirane klase pogrešaka. Provjeren pristup je trodjelna podjela:

• Tehničke pogreške (timeout, mreža, privremene blokade): automatski ponovni pokušaj s backoffom.
• Semantičke pogreške (obavezno polje nedostaje, nepoznat status): u karantenu/Dead-Letter, s mogućnošću otvaranja ticketa.
• Procesni konflikti (povrijeđen redoslijed, dvostruko knjiženje): stručni proces razjašnjenja, često s ručnom odlukom.

Bez mehanizma karantene završite s „Integracija radi green, ali pojedinačni slučajevi nedostaju“. To je najbrži put u groblje podataka, jer nitko više ne zna koji je podatkovni status „istinit“.

Monitoring, Alerting i sljedivost

Za IT-upravu i operacije važna su konkretna pitanja: Koliko zapisa/eventa po satu? Koliki je zaostatak? Koje sučelje uzrokuje najviše ponovnih pokušaja? ETL treba monitoring izvođenja (start/kraj, broj redova), CDC treba metrike za lag, Event Streaming treba consumer-lag i udjele Dead-Lettera. Uz to idu logovi s korelacijom (npr. ID narudžbe), kako slučajevi podrške ne bi završavali na screenshotima.

Sigurnost i usklađenost: kopije podataka su odgovornost

Integracija stvara kopije. Kopije znače nove površine napada i nova pitanja čuvanja. Tipične točke koje u projektima dolaze prekasno:

• Least Privilege: ETL- i CDC-nalozi trebali bi samo čitati ono što je potrebno. Za Event-producente/konzumente obvezni su servisni nalozi s minimalnim pravima.
• Rukovanje tajnama (Secrets-Handling): Lozinke u skriptama ili planerima zadataka su klasik. Bolje: centralizirano upravljanje tajnama ili barem uredna rotacija i audit.
• GDPR i brisanje: Ako se u ERP-u izbriše/označi kao blokirano, mora biti jasno što se događa u DWH/Data Lake/Streamu. CDC mora odražavati događaje brisanja, ETL treba logiku brisanja ili anonimizacije.

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

Pogotovo kod procesa koji su se razvijali tijekom vremena, postupan prijelaz je stabilniji. Praktičan pristup:

1. Inventarisieren: Koji tokovi podataka postoje (uključujući Excel, SFTP, izravne pristupe bazi podataka)? Koji su procesno kritični?
2. Stabilno ciljano stanje po domeni: npr. „stanje skladišta dolazi iz WMS, status narudžbe iz ERP‑a, komunikacija s kupcem iz CRM‑a“.
3. Paralelni rad s usporedbom: CDC/ETL u početku rade u „shadow“ načinu, rezultati se uspoređuju s dosadašnjim stanjem (delta‑izvještaji, uzorci).
4. Cutover s povratnom opcijom: Za operativne integracije: prebacivanje na Event/CDC‑izvor, ali s jasnom opcijom povrata (npr. upiti samo za čitanje ili privremeni batch).
5. Čišćenje: Isključiti stare jobove, oduzeti pristupe, utvrditi dokumentaciju i ownership. Bez ovog koraka ostaje groblje podataka, samo s novom dekoracijom.

Važno je upravljanje očekivanjima: integracija nikad nije „gotova“. Nova polja, novi procesi, nove lokacije – sve to utječe na tokove podataka. Uspješni timovi zato definiraju način održavanja: verzioniranje, testovi, odobrenja, prilagodbe monitoringa.

Fazit: Datenintegration ohne Datenfriedhof braucht Technik – und Betriebsklarheit

ETL ostaje solidan alat za reporting, pod uvjetom da imate kontrolu nad rasporedima, podatkovnim ugovorima i rastom batch‑prozora. CDC je često pragmatičan put do aktualnih stanja podataka, rasterećuje izvorne sustave i stvara jasnu separaciju između OLTP‑a i analiznih slojeva. Event Streaming je snažan kad procesi moraju reagirati i kad više sustava koristi događaje – ali zahtijeva dosljedno upravljanje greškama, verzioniranje i jasno ownership po konzumentu.

U praksi ključna pitanja nisu „koja je tehnologija moderna“, nego: Koju latenciju i pouzdanost trebaju naši procesi – i koju operativnu sposobnost možemo trajno podnijeti? Ako to razjasnite rano, integracije se mogu graditi tako da rastu bez propadanja.

Ako želite strukturirano modernizirati integracije između ERP‑a, CRM‑a i skladišta – uključujući koncept rada, podatkovne ugovore i migracijski put – razgovarajte s nama:

Za ovu temu su također važni Change Data Capture (CDC) i ERP‑integracija. Članak razumljivo razvrstava te aspekte i pokazuje na što treba paziti u svakodnevnoj praksi.

Razgovarati o projektu ili modernizacijskom pothvatu s Net-Base.