Integrace dat bez datového hřbitova: CDC, streamování událostí a ETL v porovnání pro ERP/CRM/sklad

Kdo propojuje ERP, CRM a správu skladu, obvykle chce současně dvě věci: procesy mají běžet kontinuálně (např. objednávka → kompletace → expedice → faktura) a data musí být dostupná pro vyhodnocení (např. schopnost dodat, příspěvek k marži, míra vrácení). V praxi to rychle vede ke sporu mezi „Potřebujeme to dnes v reportech“ a „Produktivní ERP nesmíme destabilizovat“. Právě tady se rozhoduje, zda se povede integrace dat bez hřbitova dat nebo zda se v průběhu let nashromáždí nepřehledná směs CSV exportů, nočních jobů, stínových tabulek a nevyjasněných kopií dat.

Tento článek porovnává tři klíčové přístupy: ETL (Extract, Transform, Load), CDC (Change Data Capture, tedy rozpoznání a přenos změn dat) a Event Streaming (události jako nepřetržitý datový proud přes broker). Záměr není diskutovat programovací detaily, ale architektonické důsledky, provozní realitu, kvalitu dat, bezpečnostní a rollout otázky – tak, jak se skutečně objevují v integračních projektech mezi podnikový­mi systémy.

Proč se integrace často mění v hřbitov dat

Hřbitov dat zřídka vzniká ze zlého úmyslu. Typické příčiny jsou:

• Nejasné hranice systémů: ERP je jednou „vedoucí“, pak zas CRM a ve skladu je vlastní logika stavů. Bez stanoveného vlastnictví dat (System of Record) jsou konflikty předprogramovány.
• Ad‑hoc požadavky: „Potřebujeme rychle dashboard“ vede k přímým přístupům do ERP, později přibývají další dotazy, materializované pohledy nebo kopie. Každé rychlé řešení posouvá provozní zátěž a odpovědnosti.
• Chybějící smlouvy: smlouvy o rozhraních (která pole, jaká sémantika, jaké verzování) chybí. Výsledek: schema drift – pole mění význam nebo strukturu, aniž by to downstream systémy včas zaznamenaly.
• Žádný provozní koncept: úlohy běží „někde“, přihlašovací údaje leží ve skriptech, neexistuje upozornění při mezerách v datech a nikdo nedokáže odpovědět, zda je report „úplný“.

ETL, CDC a Event Streaming řeší různé části tohoto problému. Rozhodující je, abyste zvolili přístup odpovídající kritičnosti procesu, požadavku na latenci a provozní zralosti – a abyste integrační cestu provozovali jako produkt, nikoli jako jednorázový projektový artefakt.

Pojmy přesně zařadit: ETL, CDC a Event Streaming

ETL znamená „Extract, Transform, Load“: data se odebírají z výchozích systémů, transformují (např. čištěna, agregována, namapována) a načítají do cílového systému, často do datového skladu. Klasicky se to děje dávkově, např. v noci nebo každou hodinu.

CDC (Change Data Capture) popisuje mechanismy, které rozpoznávají změny v datech a přenášejí je jako delta: nové/aktualizované/smazané záznamy. CDC lze realizovat pomocí časových razítek, triggerů nebo – provozně často nejčistěji – přes transakční logy databáze. Cílem je obvykle „near realtime“, aniž by bylo nutné neustále provádět plné extrakty.

Event Streaming znamená publikování událostí (např. „Objednávka uvolněna“, „Příjem zboží zaúčtován“) jako nepřetržitý proud přes Message Broker (např. systémy podobné Kafce nebo koncepty service‑busu). Odběratelé si události přihlašují a zpracovávají je vlastním tempem. Důležité: událost není automaticky „celá pravda“ o datech, často jde o změnu stavu doplněnou kontextem.

Porovnání podle otázek, které v provozu skutečně počítají

Latence: Jak rychlá data skutečně musí být?

Pro mnoho ERP reportů stačí data z „minulé noci“. Pro operativní řízení ve skladu může být „5 minut staré“ už pozdě (např. při nízkých zásobách). Platí:

• ETL poskytuje plánovatelná okna aktualizace, je však svým návrhem neokamžité.
• CDC je vhodné, pokud chcete změny dat rychle zrcadlit do reportingových nebo vyhledávacích systémů, aniž byste museli znovu modelovat aplikační logiku.
• streamování událostí se hodí, pokud mají procesy reagovat včas (např. generování štítků pro odeslání, aktualizace stavu zákazníka, odesílání notifikací).

Častá chyba je požadovat „reálný čas“ všude. Reálný čas zvyšuje složitost monitoringu, zpracování chyb a konzistence dat. Smysluplné je klasifikovat: Která data jsou operativní (kritická pro proces), která analytická (kritická pro reporting), která archivní (audit/compliance)?

Konzistence: Co se stane při částečných chybách?

V distribuovaných integracích jsou částečné chyby normální: přerušení sítě, time-outy, zámky, okna údržby. Rozhodující je, zda váš přístup tyto situace robustně zvládá.

• ETL obvykle běží v dávkách. Pokud dávka selže, je stav dat v cíli často konzistentní „do času X“, poté zastaralý. To je pro reporting často přijatelné, pokud je to transparentní.
• CDC přenáší delty. Pokud proces zadrhne, vzniká hromadění. To je zvládnutelné, ale musíte měřit lag (zpoždění) a alarmovat při překročení mezí.
• streamování událostí přenáší chyby na konzumenty. Potřebujete proto idempotenci (vícenásobné zpracování bez vedlejších účinků), strategie opětovného pokusu a Dead-Letter-Queue (úložiště pro nezpracovatelné zprávy), jinak chyby „tichnou“ a objeví se až v provozní doméně.

Konzistence je také doménová otázka: Musí „objednávka + položky + rezervace“ dorazit jako balík, nebo stačí eventual consistency (pozdější sladění)? Čím vyšší je závislost balíku, tím spíše potřebujete transakční hranice a jasná pravidla pořadí.

Zátěž a riziko pro ERP: Co se jak zatěžuje?

Mnoho integračních problémů jsou ve skutečnosti výkonové a zamykací problémy ve zdrojovém systému. ERP je OLTP systém (Online Transaction Processing): mnoho malých transakcí, vysoká zátěž zápisu, citlivé indexy.

• ETL často tahá velké objemy dat. Bez čistých časových oken, read-replicy nebo cílených extraktových tabulek může ETL ERP zpomalit.
• CDC přes logy je obvykle šetrnější, protože využívá „již existující“ proud změn. Trigger-based CDC může naopak prodlužovat cestu zápisu a představuje riziko u intenzivně zatížených tabulek.
• streamování událostí se vyhne přímé čtecí zátěži, pokud eventy přicházejí přímo z aplikace. Pokud jsou však eventy „generované z databáze“, jste opět blízko CDC – s podobnými kompromisy.

Pravidlo z praxe: Pokud je ERP dnes už těsně dimenzované, neměla by integrace začínat dalšími plnými odběry. Často se vyplatí nejprve odpojení, např. přes CDC do samostatného reportingového nebo integračního schématu, a teprve potom transformace.

ETL v každodenním provozu: dobré pro reporting, nebezpečné jako lepidlo procesů

ETL je v mnoha firmách vstupní bod, protože je koncepčně uchopitelné: „Vytáhneme data, připravíme je, nahrajeme do DWH.“ Pro klasické BI požadavky má to stále smysl.

Silné stránky ETL

• Plánovatelnost: Noční běhy nebo hodinové běhy jsou dobře říditelné a hodí se do úseků pro údržbu.
• Centrální transformační logika: Čištění, mapování, historizace (např. Slowly Changing Dimensions) jsou v kontextu DWH zavedené.
• Auditovatelnost: Pomocí ID běhů, počtu řádků a kontrolních součtů můžete dohledat, co kdy bylo nahráno.

Typická rizika a „datového hřbitova“-vzory

• Nekontrolovaný přímý přístup: Čím více analýz přímo vychází z extrahovaných tabulek, tím více „neoficiálních datových produktů“ vzniká.
• Schema drift bez včasného varování: Pokud se v ERP pole změní, často si toho všimnete až při dalším běhu – nebo hůře: vůbec, protože nulové hodnoty „proklouznou“.
• Batch okna se zužují: Objem dat roste, doba běhu roste, až ETL začne kolidovat se zálohami, reorganizacemi nebo nočními řetězci ERP úloh.

Konkrétní příklad: Sklad potřebuje denně sestavu „artikely bez zásob ale s otevřenými objednávkami“. Jako ETL report je to v pořádku. Pokud je tato sestava však používána jako podklad pro operativní dispozici, je 24hodinové zpoždění najednou provozně kritické. Pak se ETL stává procesním lepidlem – a to málokdy bývá stabilní.

CDC: Pragmatická cesta k deltám a téměř v reálném čase

CDC je často optimální přístup, když chcete data z ERP/CRM/skladu dostat s minimální prodlevou do vyhledávacích systémů, Data Warehouse nebo integračních databází, aniž byste každou obchodní logiku museli znovu modelovat jako události.

Varianty CDC a jejich provozní dopady

• CDC na základě časových razítek/High-Watermark: Čtete „vše od posledního časového razítka“. To je jednoduché, ale náchylné na následné opravy, posuny času a chybějící události mazání.
• Na triggerech založené CDC: Změny se navíc zapisují do tabulek změn. To je funkčně jasné, ale zvyšuje zátěž zápisů a vyžaduje čistá oprávnění a údržbu při změnách schématu.
• Z logu založené CDC: Změny jsou odvozeny z transakčního logu. Často je to výkonnější a bližší realitě, ale vyžaduje pečlivou konfiguraci, protože retence logu, zálohy a údržbové úlohy najednou získávají význam pro integraci.

Důležité pro administrátory: CDC není „nastavit a zapomenout“. Musíte sledovat zpoždění (lag), definovat resync postupy (např. obnovení jednotlivých tabulek) a stanovit, jak dlouho bude historie změn v cíli uchovávána.

Co CDC zvlášť dobře umí

• Ulevění od plných extrakcí: Po počátečním snapshotu běží už jen delty.
• Čisté oddělení OLTP vs. analytika: Reportování může běžet na samostatné databázi nebo v Data Warehouse, aniž by zatěžovalo ERP.
• Technicky neutrální poskytování dat: Downstream týmy mohou nezávisle iterovat transformační kroky.

Příklad z praxe: CRM musí mít denně aktuální informaci, zda má zákazník otevřené dodávky, aniž by se v ERP musely stále spouštět složité dotazy. CDC replikuje relevantní tabulky nebo Views do integrační databáze; CRM čte odtud. Výsledek: méně špiček zátěže v ERP a dotazy je možné cíleně indexovat.

Event Streaming: Když musí procesy reagovat – a vy přijmete odpovědnost

Event Streaming se vyplatí zejména, pokud nechcete jen kopírovat data, ale orchestrujete reakce procesů: změny stavů, notifikace, následné úkoly, integrace s partnery. Event je „věc, která se stala“ – včetně časové značky, identifikátorů a minimálně nutného kontextu.

Silné stránky Event Streamingu

• Oddělení: Producent a konzument nemusí být dostupní současně. To snižuje náchylnost k výpadkům během údržbových oken.
• Škálování přes konzumenty: Více systémů může využívat totéž event (např. CRM, expedice, BI), aniž by ERP muselo doručovat pro každý cíl zvlášť.
• Transparentnost toku: S dobrým monitoringem uvidíte průtok, hromadění a míry chyb pro každého konzumenta.

Rizika a typické mylné představy

• „Pošleme eventy, a pak bude kvalita dat v pořádku“: Eventy také přenášejí chybné stavy, pokud chybí upstream validace. Kvalita dat zůstává odbornou odpovědností.
• Idempotence se zapomíná: Duplikované eventy se dějí (retry, síť, rebalancing). Konzumenti musí tolerovat duplicitní zpracování, např. pomocí jedinečných ID eventu a kontrol typu „již zpracováno“.
• Správa schémat a verzí: Eventové zprávy jsou kontrakty rozhraní. Bez verzování a plánu na vyřazení vznikne chaos, jen rychleji.
• Pořadí není zadarmo: Mnoho brokerů poskytuje pořadí pouze v rámci definovaných particí/klíčů. Z obchodního hlediska musí být jasné, který klíč (např. Auftrag-ID) zaručuje pořádek.

Konkrétní scénář: Na skladě se zaeviduje výdej zboží. ERP má fakturovat, CRM aktualizovat status zákazníka a tracking-portal má poskytnout informaci o expedici. Event Streaming to může čistě oddělit. Pokud je ale fakturace bezpodmínečně před změnou statusu, potřebujete buď koordinaci procesu (např. Saga/Choreografie) nebo jasná pravidla, kdo je orchestrátor. Jinak budou stavy kolísat.

Pomoc při rozhodování: Který přístup se hodí k jakému cíli?

V integračních projektech je špatné základní rozhodnutí drahé. Praktické zařazení:

Pokud je vaším primárním cílem reporting a analytika

Wenn Ihr Ziel operative, zeitnahe Synchronisation ist

• Startpunkt: CDC für Tabellen-/Objektspiegelung, dazu schlanke Services für Validierung und Konfliktlösung.
• Wenn echte Reaktionsketten nötig sind: Event Streaming, aber nur mit definiertem Ownership und Betriebsverantwortung pro Konsument.

Wenn Ihr Ziel Prozesskopplung zwischen ERP/CRM/Lager ist

• Startpunkt: Event Streaming oder Message-basierte Integration, ergänzt um Rückkanäle (Acknowledgements) und Fehlerpfade.
• ETL hier nur für Nebenströme (z. B. tägliche Abgleiche, Archiv, BI), nicht als Trigger für operative Aktionen.

Wichtig: In der Realität ist es selten „entweder-oder“. Viele stabile Architekturen kombinieren: Events für Prozesse, CDC für Datenbereitstellung und ETL/ELT für Reportingmodelle.

Architekturfolgen, die Sie früh klären sollten

Datenhoheit und Golden-Record-Fragen

Wer darf was ändern? Ein „Golden Record“ ist der fachlich gültige Datensatz für ein Objekt (Kunde, Artikel, Auftrag). Wenn mehrere Systeme schreiben, brauchen Sie Konfliktregeln: Prioritäten, manuelle Klärung oder MDM-Ansätze (Master Data Management). Ohne diese Regeln wird Integration zum ständigen „Warum sind die Daten unterschiedlich?“-Ticket.

Fehlerbehandlung als Design, nicht als Nacharbeit

Ob ETL, CDC oder Event Streaming: Sie brauchen definierte Fehlerklassen. Bewährt ist eine Dreiteilung:

• Technische Fehler (Timeout, Netzwerk, temporäre Sperren): automatischer Retry mit Backoff.
• Semantische Fehler (Pflichtfeld fehlt, unbekannter Status): ab in Quarantäne/Dead-Letter, mit Ticketfähigkeit.
• Prozesskonflikte (Reihenfolge verletzt, Doppelbuchung): fachlicher Klärprozess, oft mit manueller Entscheidung.

Ohne Quarantäne-Mechanismus landen Sie bei „Integration läuft grün, aber einzelne Fälle fehlen“. Das ist der schnellste Weg in den Datenfriedhof, weil niemand mehr weiß, welcher Datenstand „wahr“ ist.

Monitoring, Alerting und Nachvollziehbarkeit

Für IT-Leitung und Betrieb zählen konkrete Fragen: Wie viele Datensätze/Events pro Stunde? Wie groß ist der Rückstau? Welche Schnittstelle verursacht die meisten Retries? ETL braucht Laufmonitoring (Start/Ende, Row-Counts), CDC braucht Lag-Metriken, Event Streaming braucht Consumer-Lag und Dead-Letter-Quoten. Dazu gehören Logs mit Korrelation (z. B. Auftrag-ID), damit Supportfälle nicht in Screenshots enden.

Sicherheit und Compliance: Datenkopien sind Verantwortung

Integration erzeugt Kopien. Kopien bedeuten neue Angriffsflächen und neue Aufbewahrungsfragen. Typische Punkte, die in Projekten zu spät kommen:

• Least Privilege: ETL- und CDC-Accounts sollten nur lesen, was nötig ist. Für Event-Produzenten/Konsumenten sind Service Accounts mit minimalen Rechten Pflicht.
• Secrets-Handling: Passwörter in Skripten oder Task Scheduler sind ein Klassiker. Besser: zentrales Secrets-Management oder zumindest saubere Rotation und Audit.
• DSGVO und Löschung: Wenn im ERP gelöscht/gesperrt wird, muss klar sein, was im DWH/Data Lake/Stream passiert. CDC muss Löschereignisse abbilden, ETL braucht Lösch- oder Anonymisierungslogik.
• Auditní stopy: U kritických procesů může být relevantní, kdo kdy změnil který stav. Tato informace nesmí být při transformacích „odstraněna“.

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

Právě u historicky vzniklých procesů je postupný přechod stabilnější. Prakticky proveditelný postup:

1. Inventarizace: Jaké datové toky existují (včetně Excelu, SFTP, přímých DB přístupů)? Které jsou kritické pro proces?
2. Stabilní cílový stav pro doménu: např. „stav skladu pochází z WMS, stav objednávky z ERP, komunikace se zákazníky z CRM“.
3. Paralelní provoz s porovnáním: CDC/ETL nejprve běží v shadow režimu, výsledky se porovnávají se stávajícím stavem (delta reporty, výběrové kontroly).
4. Přepnutí s možností návratu: Pro provozní integrace: přepnutí na Event/CDC zdroj, ale s jasnou úrovní návratu (např. pouze pro čtení dotazy nebo dočasný batch).
5. Úklid: Vypnout staré joby, odebrat přístupy, upevnit dokumentaci a odpovědnost. Bez tohoto kroku zůstane datový hřbitov, jen s novou výzdobou.

Důležité je řízení očekávání: Integrace nikdy není „hotová“. Nová pole, nové procesy, nová místa – to vše působí na datové toky. Úspěšné týmy proto definují režim údržby: verzování, testy, schvalování, úpravy monitoringu.

Fazit: Datenintegration ohne Datenfriedhof braucht Technik – und Betriebsklarheit

ETL zůstává spolehlivým nástrojem pro reporting, dokud máte pod kontrolou běhové plány, datové smlouvy a růst okna batchů. CDC je často pragmatická cesta k aktuálním datům, odlehčuje zdrojové systémy a vytváří čisté oddělení mezi OLTP a vyhodnocováním. Event Streaming je silný, když musí procesy reagovat a více systémů využívá události – vyžaduje ale důsledné řízení chyb, verzování a vlastnictví u každého konzumenta.

V praxi není rozhodující otázka „která technologie je moderní“, ale: Jakou latenci a spolehlivost naše procesy potřebují – a jakou provozní schopnost jsme schopni dlouhodobě nést? Pokud to vyjasníte brzy, lze integrace postavit tak, aby rostly, aniž by zchátraly.

Pokud chcete strukturovaně modernizovat své integrace mezi ERP, CRM a skladem – včetně provozního konceptu, datových smluv a migrační cesty – kontaktujte nás:

Pro toto téma jsou důležité také Change Data Capture (Cdc) a ERP integrace. Příspěvek tyto aspekty srozumitelně zařazuje a ukazuje, na co jde v praxi.

Projednat projekt nebo modernizační záměr s Net-Base.