1 Ein­lei­tung

In vie­len Unter­neh­men ist die klas­si­sche, häu­fig batch-basierte Bereit­stel­lung von Daten nicht mehr aus­reichend und es wird nach Mög­lich­kei­ten gesucht, eine real-time-nahe und event-basierte Datenversor­gung bereit­zu­stel­len. Ein Mit­tel hier­für kann ein sog. Change Data Cap­ture (CDC) Tool in Kom­bi­na­tion mit einer Strea­ming Platt­form wie Apa­che Kafka dar­stel­len. Ein CDC-Tool ist im Gegen­satz zu einem ETL-Tool deut­lich res­sour­cen-scho­nen­der. Beide Tools bil­den jedoch nur die tech­ni­schen Events ab. Busi­ness Events als auch Domain Dri­ven Design gehen hier­bei noch einen Schritt weiter.

Wäh­rend CDC-Tools aus der klas­si­schen Anwen­dung ent­stan­den sind, Daten kos­ten­ef­fi­zi­ent und per­for­mant von einer Daten­bank­ta­belle zu einer ande­ren zu repli­zie­ren, sind die Mög­lich­kei­ten für die Ziel­seite über klas­si­sche Daten­ban­ken hin­aus­ge­wach­sen. So sind Ziel­sys­teme wie Apa­che Hadoop, Apa­che Kafka, IBM MQ, etc. im Bereich der Strea­ming- und Queu­ing-Lösun­gen hin­zu­ge­kom­men. Cloud-basierte Strea­ming-Sys­teme wie Azure Event Hub als auch Datenbank­systeme wie Ama­zon RDS, Snow­flake (AWS, GCP, Azure), Micro­soft Azure Data­base, Google Cloud SQL, etc. sind eben­falls hin­zu­ge­kom­men. Damit eröff­nen sich für Unter­neh­men diverse Mög­lich­kei­ten, Daten aus exis­tie­ren­den on-pre­mise Sys­temen mit der Cloud zu ver­bin­den sowie real-time-nahe Events der­sel­bi­gen in die Cloud zu repli­zie­ren. Immer mehr CDC-Too­l­an­bie­ter haben diese Möglich­keiten erkannt und bie­ten einen Sup­port für diese Ziel­sys­teme an. Neben kom­mer­zi­el­len CDC-Tools von bekann­ten Her­stel­lern wie IBM InfoS­phere Data Repli­ca­tion, Ora­cle Gol­den Gate, Qlik Repli­cate, Infor­ma­tica Power­Ex­ch­ange, Tal­end, etc. gibt es eben­falls frei ver­füg­bare CDC-Tools wie bspw. Debe­zium, Stream­Sets, etc., wobei bei die­sen eine Lizenz vom Daten­bank­pro­vi­der erforder­lich sein kann.

Apa­che Kafka hat in den ver­gan­ge­nen Jah­ren immer wei­ter an Popu­la­ri­tät zuge­nom­men und wird aktiv von der Con­flu­ent Inc. wei­ter­ent­wi­ckelt. Neben der Kafka Strea­ming Platt­form selbst wer­den vor allem Kafka Kon­nek­to­ren weiter­entwickelt, die sich eben­falls zu diver­sen Quell- und Ziel­sys­te­men ver­bin­den kön­nen. So gibt es für einige Daten­ban­ken bei­spiels­weise bereits Debe­zium Quell­kon­nek­to­ren, die (zu Tei­len) die Auf­gabe eines CDC-Tools erle­di­gen kön­nen. Wei­ter­hin ent­wi­ckelt und ver­treibt Con­flu­ent eine eigene kom­mer­zi­elle Kafka-Ver­sion mit zusätz­li­chen Fea­tures, die sog. «Con­flu­ent Plat­form», die ent­we­der on-pre­mise, auf einer der bekann­ten Cloud-Platt­for­men (AWS, GCP, etc.) oder auf der «Con­flu­ent Cloud» instal­liert und genutzt wer­den kann. Neben Kafka Con­nect gibt es zudem noch Kafka Streams und ksqlDB für die Ent­wick­lung von Strea­ming Appli­ka­tio­nen. In der nach­fol­gen­den Abbil­dung 1 ist die Kom­bi­na­tion eines CDC-Tools mit dem Kafka Öko­sys­tem dargestellt.

2 Change Data Cap­ture (CDC)

2.1 Defi­ni­tion

Der Aus­druck Change Data Cap­ture (CDC) wird vor allem im Daten­bank­um­feld ver­wen­det und bezeich­net die tech­ni­schen Mög­lich­kei­ten um Ände­run­gen, häu­fig auch «Del­tas» genannt, aus der Quelldaten­bank zu iden­ti­fi­zie­ren und diese zu ver­wen­den bzw. weiterzuverarbeiten.

2.2 Arten von CDC

Bei CDC kann unter­schie­den wer­den zwi­schen Pro­ce­du­res, Trig­gers, Query-based und Log-based CDC. Alles sind tech­ni­sche Metho­den und Ansätze um eine Quel­län­de­rung als Event zu erken­nen und weiterzugeben.

2.3 His­to­ri­scher Rück­blick: Pro­ze­du­ren und Trigger

In der Ver­gan­gen­heit war die Ver­wen­dung von Daten­bank Pro­ze­du­ren oder Trig­gern ein gän­gi­ges Mit­tel, um Quel­län­de­run­gen zu erken­nen und abzu­grei­fen. Pro­ze­du­ren, sog. Stored Pro­ce­du­res, im CDC-Kon­text wer­den von der jewei­li­gen Quell­ap­pli­ka­tion auf­ge­ru­fen, um DML-Ope­ra­tio­nen auf der Ziel­ta­belle durch­zu­füh­ren. Trig­ger grei­fen im Ver­gleich zu Pro­ze­du­ren die Ände­rung erst von der jewei­li­gen Quell­ta­belle ab, d.h. wenn die DML-Ope­ra­tio­nen bereits gegen die Daten­bank und Quell­ta­belle abge­setzt wur­den. Trig­ger sind somit aktive „Lis­te­ner“ auf einer Tabelle. Zusätz­lich kön­nen neben den DML-Ope­ra­tio­nen pro­gram­ma­tisch wei­tere Aktio­nen auf der Daten­bank aus­ge­führt wer­den, bei­spiels­weise eine eigene Pro­to­koll­ta­belle über die Ände­rung zu füh­ren (sog. Log Trig­ger), bei einer Ände­rung wei­tere Tabel­len zu befül­len oder direkt eine nach­ge­la­gerte kom­ple­xere Ver­ar­bei­tung gege­be­nen­falls mit einer Busi­ness­lo­gik abhän­gig von der jewei­li­gen Ände­rung durch­zu­füh­ren. Auf Daten­bank­än­de­run­gen kön­nen Trig­ger ana­log zu Pro­ze­du­ren pro­gram­ma­tisch reagie­ren oder sogar eine Pro­ze­dur aus einem Trig­ger her­aus aufrufen.

Im Fol­gen­den sind einige Gründe dafür auf­ge­lis­tet, dass Pro­ze­du­ren und Trig­ger heute für CDC sel­ten im Ein­satz sind:

• Je nach Daten­bank sind sie in einer daten­bank­na­hen Pro­gram­mier­spra­che wie PL/SQL, SQL PL, Tran­sact SQL, etc. geschrie­ben, wodurch sie stark mit der jewei­li­gen Daten­bank ver­knüpft sind und es ent­spre­chende Ent­wick­ler benötigt

• Trig­ger sind res­sour­cen­in­ten­siv, da sie einen akti­ven Pro­zess pro Tabelle darstellen

• Pro­ze­du­ren kön­nen res­sour­cen­in­ten­siv sein, je nach imple­men­tier­ter Logik and Anzahl

• Je nach Design kann die Ska­lier­bar­keit pro­ble­ma­tisch sein, abhän­gig davon wie viele Sys­teme die Ände­run­gen wie erhalten

• Bei daten­bank­na­hen Pro­gram­mier­spra­chen ist es häu­fig nicht mög­lich Events an eine Strea­ming Platt­form wie Kafka zu sen­den (Aus­nah­men sind bspw. Java-basierte APIs)

2.4 Query-based CDC

Der Query-based CDC-Ansatz beschreibt das Aus­füh­ren von SQL-Queries gegen die Quell­da­ten­bank, um Ände­run­gen an den rele­van­ten Tabel­len zu ermit­teln. Hier­für ist es erfor­der­lich, dass die ent­spre­chen­den Tabel­len ein Attri­but zur Delta-Ermitt­lung ent­hal­ten. Dies kann bei­spiel­weise ein Attri­but mit einem Timestamp, einer Ver­si­ons­num­mer oder einem Sta­tus­feld sein. Hier­bei kann die Wahl des CDC-Attri­bu­tes auf Quell­seite impli­zit dazu füh­ren eine ent­spre­chende Logik bei der Imple­men­tie­rung von DML-Ope­ra­tio­nen anzuwenden.

based CDC-Ansatz beschreibt das Aus­füh­ren von SQL-Queries gegen die Quell­da­ten­bank, um Ände­run­gen an den rele­van­ten Tabel­len zu ermit­teln. Hier­für ist es erfor­der­lich, dass die entspre­chenden Tabel­len ein Attri­but zur Delta-Ermitt­lung ent­hal­ten. Dies kann bei­spiel­weise ein Attri­but mit einem Timestamp, einer Ver­si­ons­num­mer oder einem Sta­tus­feld sein. Hier­bei kann die Wahl des CDC-Attri­bu­tes auf Quell­seite impli­zit dazu füh­ren eine ent­spre­chende Logik bei der Imple­men­tie­rung von DML-Ope­ra­tio­nen anzuwenden.

Der Query-based CDC-Ansatz kann dar­über hin­aus keine Löschun­gen in der Quell­tabelle erken­nen, da diese Events nur durch einen Voll­be­stands­ab­gleich iden­ti­fiziert wer­den können.

2.5 Log-based CDC

Der Log-based CDC-Ansatz ist der bekann­teste und am häu­figs­ten refe­ren­zierte Ansatz, wenn von Change Data Cap­ture bzw. CDC die Rede ist. Vor allem wird die­ser Ansatz dann refe­ren­ziert, wenn es um CDC-Tools geht.

Die­ser Ansatz beschreibt das Erken­nen von Daten­bank­än­de­run­gen durch das Aus­le­sen der Daten­bank­log­files. Dabei kön­nen neben DML-Ände­run­gen auch DDL-Ände­run­gen erkannt wer­den. Für die­sen Ansatz ist es i.d.R. not­wen­dig, dass die Daten­bank mehr loggt als stan­dard­mä­ßig ein­ge­stellt ist und dass für ein­zelne Tabel­len, die anzu­bin­den sind, eben­falls wei­tere Kon­fi­gu­ra­tio­nen durch­ge­führt wer­den müs­sen. Das inten­si­vere Log­ging führt ent­spre­chend zu einer höhe­ren Res­sour­cen­be­an­spru­chung auf Daten­bank­seite, wobei hier vor allem der für die Logs not­wen­dige Spei­cher­platz gemeint ist.

Im Fol­gen­den fin­det sich eine Über­sicht der Vor- und Nach­teile die­ses Ansatzes:

Ein wesent­li­cher Aspekt bei dem Log-based CDC-Ansatz ist, dass ein CDC-Tool benö­tigt wird, um die übli­cher­weise pro­prie­tä­ren Daten­bank­logs aus­zu­le­sen und zu ver­ar­bei­ten. Je nach Quell­da­ten­bank und Aus­wahl des CDC-Tools sind hier­für (in der Regel) ent­we­der zusätz­li­che Lizen­zen beim Datenbankan­bieter oder beim CDC-Too­l­an­bie­ter zu erwer­ben. Neben den kom­mer­zi­el­len CDC-Tools wie Qlik Repli­cate, IBM InfoS­phere Data Repli­ca­tion, Infor­ma­tica Power­Ex­ch­ange, etc. gibt es einige kos­ten­freie, teil­weise open-source basierte Anbie­ter wie Debe­zium, Stream­Sets, etc. Hier soll­ten die unter­stütz­ten Quell­da­ten­ban­ken und Ziel­sys­teme beach­tet werden.

Ein wesent­li­ches Qua­li­täts­merk­mal eines CDC-Tools ist die Durch­füh­rung eines Initial Loads mit anschlie­ßen­der lücken­lo­ser Delta-Ver­ar­bei­tung. Da es aus dem Daten­bank­log i.d.R. nicht mög­lich ist einen Initial Load durch­zu­füh­ren, brin­gen hier die CDC-Tools meist eine Initial Load Funk­tio­na­li­tät (per SQL Full Table Scan) mit und sor­gen für die Kon­sis­tenz zwi­schen Initial Load und Delta (CDC) Daten.

Wei­ter­hin wer­den diverse Ziel­sys­teme, unter ande­rem Cloud-basierte und vor allem Strea­ming / Event Platt­for­men wie bspw. Apa­che Kafka, eben­falls unterstützt.

In der fol­gen­den Abbil­dung 2 wird der CDC-Infor­ma­ti­ons­fluss veranschaulicht.

3 Apa­che Kafka

3.1   Archi­tek­tur

Apa­che Kafka, wel­ches pri­mär von der Con­flu­ent Inc. wei­ter­ent­wi­ckelt wird, stellt eine log­ba­sierte Strea­ming Lösung dar.

Die Kafka Archi­tek­tur ist in Abbil­dung 3 dar­ge­stellt. Diese umfasst die fol­gen­den Elemente:

·         Pro­du­cer: Sen­der von Nachrichten/Records nach Kafka unter Benut­zung der Producer-API.

·         Con­su­mer: Empfänger/Konsument von Nach­rich­ten aus Kafka Topics mit Hilfe der Consumer-API.

·         Zoo­kee­per: Ent­hält Kafka Clus­ter Infor­ma­tio­nen über Bro­ker, Topics, Par­ti­tio­nen, etc.

·         Bro­ker: Kafka Nodes, wel­che den Logstream und damit die Nach­rich­ten enthalten.

Wesent­li­che Vor­teile von Kafka sind hierbei:

·         Near-Real­time Verarbeitung

·         Hoher Daten­durch­satz durch ver­teilte Verarbeitung

·         Ent­kopp­lung von Quell- und Ziel­sys­te­men (Asyn­chro­ni­tät)

·         Ein Pro­du­cer – viele Consumer

Inner­halb eines Bro­kers wer­den Nach­rich­ten (Records) in Topics gespei­chert, die aus sog. Par­ti­tio­nen, wel­che wie­derum aus sog. Seg­men­ten bestehen. Dabei wer­den ver­schie­dene Par­ti­tio­nen auf verschie­denen Bro­kern gespei­chert bzw. red­un­dant repli­ziert. In Abbil­dung 4 ist die Bezie­hung zwi­schen Topics, Par­ti­tio­nen und Seg­men­ten abgebildet.

Für die Ver­tei­lung auf Par­ti­tio­nen wird ein sog. Par­ti­tio­ner ver­wen­det. Neben dem Default-Par­ti­tio­ner ist es mög­lich andere use-case bezo­gene Par­ti­tio­ner selbst zu imple­men­tie­ren und zu verwenden.

3.2 Kafka Con­nect als Query-based CDC

Neben der Mög­lich­keit mit einem eige­nen Kafka Pro­du­cer oder Con­su­mer eigene Daten direkt nach Kafka zu schrei­ben, stellt Kafka Con­nect mit sog. Con­nect Nodes wei­tere stan­dar­di­sierte Mög­lich­kei­ten der Daten­an­bin­dung bereit. Mit Kafka Con­nect ist es mög­lich die Daten­an­bin­dung diver­ser Quell- und Ziel­sys­teme  durch die Kon­fi­gu­ra­tion des ent­spre­chen­den Con­nec­tors leicht anzubinden.

4 CDC-Tools in Kom­bi­na­tion mit Apa­che Kafka

4.1 Ver­schlüs­se­lung 

Häu­fig wird Kafka auf einer der Cloud Platt­for­men (Azure, GCP, AWS) betrie­ben. Dabei wer­den teil­weise Daten aus on-pre­mise Bestands­sys­te­men in die Cloud nach Kafka über­tra­gen. Hier­für ist es empfehlens¬wert diese Ver­bin­dung zu ver­schlüs­seln. Wei­ter­hin ist rat­sam die Ver­bin­dung zwi­schen Appli­ka­tio­nen, die bereits in der Cloud lau­fen, und Kafka zu ver­schlüs­seln. Hier­für gibt es diverse Verschlüsselungspro¬tokolle wie SSL/TLS, mTLS, SASL_SSL . Dies gilt im Übri­gen eben­falls für die ggf. vor­han­dene Schema Registry.

4.2 Nach­rich­ten­for­mat: AVRO, Pro­to­buf oder JSON

Bei der Ein­rich­tung von Kafka ist es mög­lich ein Nach­rich­ten­for­mat (im Fol­gen­den Schema genannt) wie AVRO, Pro­to­buf oder JSON zu den Input­nach­rich­ten mitzu¬geben. Ein expli­zi­tes Schema erfor­dert ein zusätz­li­ches Auf­set­zen einer Schema Regis­try. Es ermög­licht wei­ter­hin eine Vali­die­rung von Schema-Ände­run­gen („Schema Com­pa­ti­bi­lity“). Ob ein Schema ver­wen­det wird, kann von Topic zu Topic vari­ie­ren. Häu­fig ist es bei CDC-Tools jedoch so, dass diese etwas weni­ger fle­xi­bel sind und nur eine Ein­stel­lung des Sche­mas pro Ver­bin­dung / End­point mög­lich ist. Gleich­wohl kön­nen meh­rere Ver­bin­dun­gen / End­points ein­ge­rich­tet wer­den, sodass alle (vom CDC-Tool) unterstütz¬ten Sche­mata mit einem CDC-Tool abge­deckt wer­den können.

4.3 Par­ti­tio­nie­rung

Die Par­ti­tio­nie­rung sorgt zum einen für die Ver­tei­lung der Daten auf dem Kafka Clus­ter und damit auch für die Mög­lich­keit der Par­al­le­li­sie­rung. Zum ande­ren führt die Ver­wen­dung von mehr als einer Par­ti­tion in der Regel dazu, dass die Ände­rungs­rei­hen­folge nicht ein­ge­hal­ten wer­den kann. Die Rei­hen­folge spielt bei CRUD-Ope­ra­tio­nen, vor allem Insert, Update und Delete, eine wesent­li­che Rolle. Abhän­gig vom CDC-Tool kann die Rei­hen­folge im Post-Pro­ces­sing jedoch auf Basis von CDC-Meta­da­ten ermit­telt und wie­der­her­ge­stellt werden.

4.4 Kom­pri­mie­rung

Abhän­gig davon wie viele Daten für wel­chen Zeit­raum und mit wel­chem Repli­zie­rungs­fak­tor nach Kafka geschrie­ben wer­den, kann es sinn­voll sein, diese Daten zu kom­pri­mie­ren. Kom­pri­mie­rung kann ent­we­der im Pro­du­cer oder auf Kafka Clus­ter Seite durch­ge­führt wer­den. Dabei ist es mög­lich bis zu 80%  des Daten­vo­lu­mens ein­zu­spa­ren. Kom­pri­mie­rungs­me­tho­den sind u.a. Gzip, Snappy, Lz4, Zstd . Je nach CDC-Tool wer­den nicht alle Kom­pri­mie­rungs­me­tho­den unter­stützt. Die Kom­pri­mie­rungs­me­thode ist zudem ein Trade-Off zwi­schen Kom­pri­mie­rungs­fak­tor und ‑geschwin­dig­keit. Um vor allem Netz­werk-Traf­fic ein­zu­spa­ren, emp­fiehlt es sich die Kom­pri­mie­rung auf Pro­du­cer­seite vor dem Sen­den durch­zu­füh­ren. Zudem sollte beach­tet wer­den, dass dann die Daten in den ent­spre­chen­den Kafka Topics nur kom­pri­miert vor­han­den sind und jeder Con­su­mer diese erst dekom­pri­mie­ren muss, bevor sie ver­ar­bei­tet wer­den kön­nen, was wie­derum CPU-Zeit (Com­pute Time) erfor­dert. Eine mög­li­che Alter­na­tive oder Ergän­zung zur Kom­pri­mie­rung wäre die Ver­wen­dung von sog. Tie­red Storage .

4.5 Audi­ting

Typi­scher­weise sind CDC-Tools in der Lage sog. Before und After Images in einem Ände­rungs­event mit­zu­lie­fern. Diese Abbil­dun­gen ent­hal­ten die Werte vor einer Ände­rung und nach einer Ände­rung. Dadurch ist es mög­lich eine Audit­fä­hig­keit ein­zu­füh­ren. Diese Funk­tio­na­li­tät ist abhän­gig vom CDC-Tool. Wenn audit­fä­hige Nach­rich­ten erzeugt wer­den, so wer­den die ent­hal­te­nen Attri­bute dop­pelt vor­kom­men, häu­fig mit Prä­fi­xen unter­schie­den. Audit­fä­hige Nach­rich­ten ver­hin­dern jedoch das Pro­du­zie­ren und Erhal­ten von Kafka Delete Events, sog. Tomb­stone Events. Dies kann zu Pro­ble­men mit der DSGVO / GDPR Kon­for­mi­tät führen.

4.6 Bei­spiele

4.6.1 Bei­spiel 1: Qlik Replicate

Qlik Repli­cate unter­stützt bis­lang kein Protobuf.

4.6.2 Bei­spiel 2: IBM InfoS­phere Data Replication

5 Vor- und Nachteile 

Bei der Abwä­gung, inwie­weit ein CDC-Tool in Kom­bi­na­tion mit Kafka sinn­voll ist, gibt es diverse Vor- und Nach­teile. Im Fol­gen­den wer­den die wesent­li­chen aufgelistet.

Vor­teile:

• Ein­fa­che und schnelle Art und Weise tech­ni­sche Events aus den Quell­sys­te­men zu beziehen

• Trans­ak­ti­ons­si­cher (ver­lust­frei)

• Lücken­lo­ser Über­gang von Initial Load zu Delta Replikation

• Unter­stüt­zung der gän­gigs­ten Daten­ban­ken als Quelle

• Unter­stüt­zung der gän­gigs­ten Kafka Funktionalitäten

• Zusätz­li­che Funk­tio­na­li­tä­ten (Fil­te­rung, Trans­for­ma­tio­nen, Enco­ding, etc.)

• Tools sind leicht zu bedie­nen (und bie­ten i.d.R. eine GUI)

• Tools ska­lie­ren i.d.R. sehr gut

• DDL-Ände­run­gen las­sen sich erkennen

• Ein­satz von CDC-Tech­no­lo­gie ent­las­tet die Quelldatenbank

• Ermög­licht reale Audit­fä­hig­keit (tech­ni­sche und orga­ni­sa­to­ri­sche Rah­men­be­din­gun­gen vorausgesetzt)

Nach­teile:

• Keine Abbil­dung von Busi­ness Events

• I.d.R. wie­der­keh­rende Lizenz­kos­ten (sofern CDC-Tool kommerziell)

• Lizenz­kos­ten abhän­gig von den ange­bun­de­nen Quell- und Zielsystemtypen

• Ein­ma­li­ger Auf­wand für Pro­dukt­ein­füh­rung (Umge­bungs­auf­bau, Instal­la­tion, Kon­fi­gu­ra­tion, etc.)

• Per­ma­nente War­tungs- und Wei­ter­ent­wick­lungs­kos­ten durch Ein­füh­rung eines neuen Produktes

• Ggf. Ven­dor Lock-In

• I.d.R. nicht Highly Available (HA) Architektur

• Ent­ste­hung sub­op­ti­ma­ler Archi­tek­tur durch CDC-Tool-Funk­tio­na­li­tä­ten mög­lich (z.B. Lookups)

• Erfasst keine Bat­ch­ope­ra­tio­nen (z.B. LOAD/UNLOAD, Truncate)

• Ska­lie­rung i.d.R. nur ver­ti­kal möglich

Bei der Eva­lua­tion eines Open-Source CDC-Tools wie Debe­zium oder ande­ren müs­sen die Auf­wände (wie bei jedem kos­ten­lo­sen Open Source Tool) für den feh­len­den oder ein­ge­schränk­ten Sup­port und den auf­wen­di­ge­ren Betrieb sowie die Wei­ter­ent­wick­lung mit­be­trach­tet werden.

Nicht alle Vor- und Nach­teile tref­fen bei jedem CDC-Tool zu, daher sind die o.g. Vor- und Nach­teile poten­zi­ell mög­lich, aber nicht bei jedem CDC-Tool zutreffend.

6 Fazit

CDC-Tools bie­ten in Kom­bi­na­tion mit Kafka eine sehr leis­tungs­fä­hige Mög­lich­keit tech­ni­sche Events der Quell­sys­teme abzu­grei­fen, jedoch erset­zen sie keine Busi­ness Events. CDC-Tools wer­den nach wie vor von zahl­rei­chen Unter­neh­men ein­ge­setzt und ver­lie­ren nicht an Beliebt­heit. Sie bie­ten einen guten Ein­stieg in die Near-Real­time Ver­ar­bei­tung. Um bei einer E2E-Betrach­tung nicht in der Mitte „ste­cken­zu­blei­ben“ und auf eine Batch-Ver­ar­bei­tung zurück­zu­fal­len, bie­tet Kafka eine ideale Mög­lich­keit für die Wei­ter­ar­bei­tung in Near-Real­time als auch wie­der im Batch Modus (durch das Zurück­schrei­ben in eine Daten­bank). Zudem wird Kafka von allen gän­gi­gen CDC-Tools unter­stützt, sowie auch Vari­an­ten von Kafka wie bspw. Azure Event Hub wer­den häu­fig eben­falls unter­stützt. Bei der Ein­füh­rung eines CDC-Tools darf der mone­täre und (wenn auch geringe) betrieb­li­che Auf­wand nicht unter­schätzt wer­den, da es sich um ein eigen­stän­di­ges Soft­ware Pro­dukt han­delt. Dies gilt eben­falls für die Ein­füh­rung von Kafka, wobei hier­bei der Auf­wand für Ein­füh­rung und Betrieb i.d.R. deut­lich höher aus­fällt und ein Platt­form-Team zu emp­feh­len ist. Beim CDC-Tool ist das in der Regel nicht der Fall. Alles in allem funk­tio­nie­ren CDC-Tools in Kom­bi­na­tion mit Apa­che Kafka heut­zu­tage sehr gut und ermög­li­chen Unter­neh­men den Ein­stieg in die real­time-nahe und event­ba­sierte Datenverarbeitung.

Erfah­ren Sie hier mehr über Lösun­gen im Bereich Data Manage­ment oder besu­chen Sie eines unse­rer kos­ten­lo­sen Web­i­nare.