Kafka und Message Streaming mit Kai Wähner - Field CTO bei Confluent

Shownotes

Im Podcast zu Gast war Kai Wähner https://www.linkedin.com/in/kaiwaehner/ , ein Field CTO bei Confluent.

Wir reden sowohl kurz über seine Rolle als Field CTO, als auch über Kafka sowie um ein Tooling um Kafka herum.
Dabei klären wir auch Fragen, ob Kafka vielleicht sogar als Datenbank genutzt werden kann, oder auch wie Kafka im Bereich Data Science eingesetzt werden kann.

Aufmerksam auf ihn geworden bin ich über seinen herausragenden Blog www.kai-waehner.de

Transkript anzeigen

00:00:00: Hallo und herzlich willkommen zu diesem wunderbaren podcast.de regionaut.

00:00:07: Heute ist eine ganz ganz ganz besondere Folge und ich freue mich tierisch drauf denn zum einen haben wir unseren ersten Film fremden Gast nämlich.

00:00:17: Kai Werner einfiel CTO von Konferenz und zum anderen reden wir über ein echtes herzensthema von mir ganz persönlich und zwar Kafka.

00:00:27: Ich wünsche dir ganz ganz viel Spaß bei dieser Folge ja hi Kai erzähl mal ein bisschen was über dich wer bist du.

00:00:36: Ja ich bin mittlerweile 41 Jahre alt und seit ungefähr 13 Jahren in der Softwareindustrie tätig aber der seit 6 Jahren bei Confluent,

00:00:45: und hier jetzt eben runter bis Thema data Streaming mit dem Patrick Kafka habe aber davor auch schon immer viele medikations Umfeld gearbeitet mit etl-tools esbs message KJUS.

00:00:54: Und kennen daher das ganze Ökosystem und in meiner Rolle arbeite ich wirklich mit Kunden auf der ganzen Welt zusammen und sie durchleben unheimlich viele use cases und mächtig Touren,

00:01:03: und an der Stelle ich dann immer auf der einen Seite wieder mit anderen Kunden oder auch mit unserem Engineering und Projektmanagement arbeiten auch z.b. den Podcast oder Blogs und deswegen sind wir heute denke ich hier,

00:01:12: genau deswegen sind wir hier ein.

00:01:15: Ganz kurzes Wort zu deiner ich nennt mal Jobbeschreibung 4 ct auch das verschreibt ziemlich genau das hast du gerade gemacht was du gerade geschrieben hast oder,

00:01:24: Vergleich zum klassischen City oder eben die Strategie des Produkte entwickelt internen der Softwarefirma,

00:01:29: ist das jetzt hier wirklich viel getrieben als das heißt ich spreche eben mit vielen Kunden und ihm auch ganz bewusst am überall weil ihm die Challenge es auf der Welt überall verschieden sind die Anforderungen sind verschieden,

00:01:39: und dadurch sehe ich ihm zum einen viele Szenarien und kann das immer auch intern wiedergeben damit wir unser Produkt dementsprechend anpassen aber natürlich daneben auch wir uns auf dem Vorgespräch schon gesprochen dass du dich auch irgendwie eine Art sales weil ich immer auf technischer Ebene,

00:01:51: kann das gut erklären kann wo ihm der Mehrwert von unserer Lösung und generell der Technologie des Taylor Streamings ist,

00:01:56: und somit ist es ein breites Spektrum also ich arbeite auch mit Marketing ich arbeite auch z.b. mit Analysten wie Garten und Forester also ich bin wirklich ein ganz breit gestreut und das ist das auch was ich dann diese Rolle Liebe und da werde ich nämlich auch unheimlich viele verschiedene déprimés auf der ganzen Welt.

00:02:10: Klingt super spannend und was auch echt spannendes ist dieses Wort data Streaming magst du dazu mal ein bisschen was erzählen was das eigentlich.

00:02:17: Absolut also das ist mir zu der Kernbegriff früher hat immer das immer Event Streaming genannt 1 bis das Marketing überall erkannt da die Leute sagen data Streaming dazu.

00:02:26: Aber meine Begriffe wie Streaming Analytics Stream processing also gibt's ganz viele Begriffe,

00:02:32: der Kern oder ist kein Prinzip ist einfach an dass ich mit Datastream in das jetzt ich als Begriff verwenden werde heute

00:02:38: ant man Daten kontinuierlich verarbeiten kann also im Gegensatz zu letzten 20-30 Jahren an wo wir immer Daten auf eine Disk geschrieben haben oder dann in der Datenbank heute vielleicht in den data lake.

00:02:50: Das ist so genanntes data-at-rest also ich speichere Daten irgendwo ab und später kann jemand auf die Daten zugreifen mit einer SQL query oder mit einem Webservice oder mit einem Python Script oder ähnliches aber die Daten werden erst mal gespeichert.

00:03:02: Das ist gut für den Report oder für Batch processing aber für viele use cases die man im heute so baut oder bauen muss,

00:03:09: Ist es deutlicher Mehrwert wenn ich die Daten kontinuierlich in Echtzeit verarbeiten kann und das nennt sich dann eben nicht mehr data at rest sondern ich verarbeite die data in Motion also kontinuierlich während die Information in Bewegung ist,

00:03:22: kann ich sie mit anderen Daten korrelieren und eben direkt darauf Aktionen starten wie betrugserkennung notifications Alarme oder ähnliches und das ist doch ganz grob auf heile beschrieben wo der Unterschied ist zwischen data Streaming und diesem neuen Konzept.

00:03:35: Gegenüber eben den klassischen Programmierparadigmen in der Datenbank mit einem Webservice und mit einer SQL.

00:03:42: Und wie spielt Apache Kafka da rein.

00:03:46: Apache Kafka hat sich jetzt erzähle ich als de facto Standard am Markt entwickelt mit mittlerweile von über 100.000 Organisationen eingesetzt.

00:03:53: Es wurde eben relativ früh am Stand heute vor ich glaube 12 13 Jahren Bedlington entwickelt weil eben es damals noch keine solche Technologie am Markt gab.

00:04:02: Die Daten sowohl in Echtzeit an versenden und korrigieren konnte und das ganze dann aber gleichzeitig auch hochskalierbar also auf viele viele Millionen Datensätze pro Sekunde.

00:04:12: Und so hat sich Apache Kafka damals erst im Silicon Valley etabliert aber mittlerweile ist es tatsächlich auf der ganzen Welt über alle Industrien im Einsatz.

00:04:20: Und an der Text jetzt wirklich wie sich hier in der neue Software Kategorie Bilder Leben und rundum data Streaming und die meisten der Hersteller verwenden hier jetzt eben auch Apache Kafka.

00:04:29: Oder manchmal auch nur das Kafka protocol das ist immer auch wieder des schönen Open Source.

00:04:34: Viele Hersteller haben sich nerve neben Apache Kafka ist Open-Source-Projekt und baumprodukt oder ein Cloud-Service außenrum,

00:04:40: manche sagen aber nee wir können es noch besser wir brauchen was Eigenes und verwenden eben nur das Kafka protocol dazu.

00:04:45: Also gibt es viele verschiedene Szenarien aber man sieht das ziemlich am Markt eben genau wie z.b. Amazon S3 der Standard für objectstore ist und das obwohl proprietär ist hat sie von Amazon das wirklich weltweit durchgesetzt bei erstellen.

00:04:58: Und genauso ist es jetzt hier in data Streaming Umfeld mit dem Open-Source-Projekt Apache Kafka und wie viel bessere Lösungen als Kafka hast du schon gesehen.

00:05:08: Besser noch gar keine man muss hier noch ergänzen auch es gibt nämlich immer spezifische Probleme für die spezifische Produkte gibt ne wenn wir z.b. über wir sprechen auf der B realtime über Daten kontinuierlich verarbeiten,

00:05:23: und da muss man sich z.b. von Beginn an Bewusstsein im realtime im Sinne von kafka und auch ähnliche Nighty Lösungen heißt immer end-to-end 10 Millisekunden oder langsamer.

00:05:32: Das reicht aus für die meisten User ist das aber es gibt am Szenarien wo ich noch schneller Daten verarbeiten muss z.b. für die nächste Trading Plattform auf der nestec da brauche ich Mikrosekunden,

00:05:43: oder wenn ich bei OT Unfälle der Fabrik bin dann brauche ich für Robotics ein ähnliches sogar deterministische Systeme mit einem Haken wir time und das ist daneben was wirklich nicht besser dass man einfach andere Lösungen für andere Probleme,

00:05:56: aber im md.de streaming Umfeld jetzt wo wir drüber sprechen kann man wirklich sagen dass ich einfach Kafka etabliert hat,

00:06:01: und da gibt's eben an sowohl Oppen source wenn man selber betreuen will oder eben dann viele verschiedene Lösungen die auf Kafka oder dem Protokoll aufbauen mit gewissen vor Nachteilen daneben.

00:06:10: Mal ganz kurz ein Gehalt du hast jetzt gerade gesagt im 1 und ihr Umfeld da braucht man bestenfalls wirklich Echtzeit.

00:06:20: Doch da gibt es mehrere Kontext in dem man auch dort Kafka verwenden kann oder Echtzeit,

00:06:26: sag jetzt mal Controller brauche oder wenn es safety-critical ist also wenn ich zB Flight Control Flugzeug mach oder wenn ich in die Robotersteuerung macht ein bisschen Thematik und die werden im mit C oder warst implementiert weil ich hier werde ich ein deterministisches System.

00:06:41: Mit Kafka oder auch allen ähnlichen Technologien wir jetzt Puls HF links Park oder ähnliches selbst im schnellsten Fall habe ich hier MMS Bikes also ich habe hier manchmal Situationen wo Ebene Nachricht auch an mal 100 Sekunden oder 200 Millisekunden dauern.

00:06:55: Und das neben dem Artikel die kann ich mit einer klassischen ID Lösung wie Kafka oder anderen nicht ab.

00:07:00: Nichtsdestotrotz und das sieht man doch zum Beispiel meinen Blog über die ganzen case-study ist vom Automotiv oder meine Factoring Umfeld,

00:07:06: all diese Industrien verwenden Kafka in vielen verschiedenen Szenarien auch für IOT use cases aber eben nicht für den safety-critical Teil sondern eben um daten z.b. auch von dem Roboter über seine Soldaten zu konsumieren,

00:07:18: und dann mit dem SAP-System z.b. korrelieren also dafür ja nur für diese quasi wirklich safety-critical Themen da ist es eben nicht geeignet.

00:07:26: Max Meyer Stern wie Kafka so grob funktioniert ich meine da gibt es ja Begriffe wie Topic Offset,

00:07:33: Lachs append-only ist das eine einfache kyu ist das ein einfacher Message Broker.

00:07:40: Was kannst du da so erzählen absolut also das hat gleich auch ganz wichtig zur Erläuterung noch mal es gibt immer diesen diesen Apple to orange comparison also viele viele Leute vergleichen Kafka mit einem message tuneIn message,

00:07:52: also da gibt's ja Technologien wie rabbit and you open source oder ipayment Jura tippco was viel eingesetzt wird.

00:07:59: Und dann muss man einfach verstehen dass Kafka deswegen nennt sich eben auch eine Streaming-Plattform deutlich mehr ist der Kern von kafka ist auch letztendlich Messaging also pubsub publish subscribe dass ich Daten von A nach B senden kann

00:08:12: und wie wird schon diskutiert haben in Echtzeit und hochskalierbar also auch Millionen von nachrichten pro Sekunde

00:08:18: Kafka ist aber deutlich mehr als nur die Messaging Komponente und das ist wirklich wo vieles nicht mehr wissen was Kafka alles kann und das dann auch nicht verwenden oder nur indirekt verwenden als zweite wichtige Komponente hat Kraft eben auf den storage,

00:08:32: das heißt.

00:08:33: Diese Events die in Kafka gespeichert werden die werden eben in so einem sogenannten Comic Blog also einem up and only locam angehängt wenn sie produziert werden und dann werden die dort auch gespeichert und persistiert.

00:08:45: Und am besten riesen Unterschied zu traditionellen messaging system and weil ich hier out-of-the-box am auch keine richtigen bekomme ein wie z.b. back-pressure Handling also es ist kein Push passierte System in der message Kuh sondern der Consumer konsumiert die Daten von dem Bruch.

00:09:00: Dadurch sind die mir viel besser entkoppelt voneinander und dadurch skaliert ist eben auch viel besser.

00:09:05: Arm und zusätzlich unterstützt daneben auch z.b. slow consumer also nicht jeder consumer kann Daten in Echtzeit konsumieren und oftmals ist es auch nicht nötig wie z.b. in data warehouse finden report,

00:09:15: und ich kann durch diesen storage auch Daten historische Daten abspielen also Events die vor 1 Tag oder von der Woche passiert sind,

00:09:22: also sind gerade die richtigen die eben Kafka unterscheiden von dem Message Broker weil eben es nicht nur am Messaging geht sondern auch um in storage und die Entkopplung.

00:09:31: Und das ist jetzt der Kern von kafka und es gibt aber noch zwei weitere Komponenten es gibt noch kafka-connect kafka-connect ist für Datenintegration

00:09:41: genau das gleiche wie ihr von eurem favorisierten ETL oder ESB Tool kennt also hier kann ich am Konnektoren verwenden um zu Datenbanken um zu Data-Warehouse ist um zu anderen Schnittstellen zu integrieren

00:09:54: und Daten zu transformieren,

00:09:55: und es gibt eben noch last but not least Stream processing oder Streaming Analytics das ist daneben in Kafka mit kafka-streams supportet und damit kann ich dann eben diese Daten aus den verschiedenen Systemen und Anwendungen auch korrelieren.

00:10:09: Der Charme hier drin ist dass all diese Komponenten Teil von der Kafka Infras.

00:10:13: Wir werden später denkt auch noch drüber diskutieren es gibt natürlich auch noch andere Lösungen sowohl für Integration als auch für Stream processing,

00:10:19: der Charme davon ist alles mit Kafka dann zumachen ist das essento and eine Infrastruktur ist und das ist dann ganz wichtig insbesondere für kritische Systeme,

00:10:28: wenn ich lolette latency requirements habe,

00:10:31: oder wenn ich z.b. einfach die Infrastrukturkosten und das Risiko minimieren möchte dann habe ich immer eine Infrastruktur anstatt viele andere die zusammen Kette

00:10:41: und das ist so der generelle Mehrwert von kafka mit diesen ganzen Komponenten ich muss nicht alles verwenden und es gibt auch gute Gründe manchmal andere Technologien mit Kafka zu kombinieren aber das ist so dieses Bewusstsein ist jeder haben sollte was Kafka alles kann

00:10:54: und deswegen zusammenfassend noch mal Kafkas deutlich mehr als nur eine Message TUS ist auch der storage für die einkopf.

00:11:01: Und es ist Datenintegration und Datenverarbeitung und das ist alles Open Source Kafka wenn ich mir das binary oder das ZIP-File am vom Apache-Webserver runterlade.

00:11:11: Ja das ist schon mal ein sehr sehr guter,

00:11:14: Einblick vielen Dank dafür und damit können wir auch direkt ins Eingemachte gehen ich meine wir haben ja schon mehr oder weniger gehört innerhalb von kafka kann man Daten persistieren.

00:11:25: Kann man Kraft auch als Datenbanken nutzen das ist super wieder auf kurze Antwort ist ja,

00:11:33: es gibt aber die wichtigere deutlich längere Antwort am lst von Kafkas jetzt nicht andere Datenbanken Wiener Oracle eine MongoDB oder ähnliches zu ersetzen aber man muss ich Bewusstsein Kafka

00:11:45: je nachdem wie möglich Datenbank definiert hat die gleichen Traktoristen also Kafka lass einfach mal kurz und Datenbank definieren vorab

00:11:53: genau also das war echt ein guter Punkt und andere reinziehen auch davon schon ab ne also eine Datenbank hat ja verschiedene Charakteristika sie speichert Informationen persistent ab.

00:12:02: Da gibt's verschiedene verfügbarkeits Thematiken also auch wenn ein Data Center down ist es trotzdem noch die Daten verfügbar,

00:12:08: und dann noch das Thema wie kann ich die Daten später wieder abgreifen überall über abfragen bei queries.

00:12:13: Und ein bisschen zu die Charakteristik und dazu daneben auch noch Themen wie transaktionale Konzepte kann ich hier nur Analytics machen oder wirklich auch die nächste payment platform und anhand von diesem Charakteristiken,

00:12:23: und dann aber eben auch wie das Ganze skaliert kann ich dann eben entscheiden welche Art von Datenbank ich benötige und für viele Use-Cases ist tatsächlich am Kavka eingesetzt als Datenbank nach dieser Definition.

00:12:37: Jetzt fängt das ein bisschen spannend du hast jetzt gerade gesagt Transaktionen und können in einer Datenbank abgebildet werden das heißt irgendwie mutations von Daten jetzt hast du gesagt Kafka ist

00:12:47: ein append-only Prinzip na das heißt da kommen irgendwie nachrichten Logs rein die sind immer fortlaufend und man verändert alte Nachricht.

00:12:55: Wirklich wie kommt das mit diesem transection Konzepte Datenbanken zusammen wie kann Kafka das realisieren.

00:13:01: Also da ist es tatsächlich ganz wichtig zu verstehen und es ist auch wirklich wieder nicht nur Verkauf Kasse sondern auch z.b. für flink oder andere Technologien.

00:13:09: Kafka supported Transaktionen seit mittlerweile über fünf Jahren aber es funktioniert einfach komplett anders als man es vielleicht auf der Datenbank oder Mainframe Welt.

00:13:18: Also ich habe ja in in Minecraft mit einer DB2 und dann mit einem Ei Pimkie oder einer Oracle Datenbank habe ich Excel Transaktionen also also wirklich eine komplexe Implementierung die auch nicht gut skaliert wegen der Transaktion umsetzen kann.

00:13:33: Das ist ein Widerspruch zur kafka bei den Crafter kann ich ja eben auch Millionen von nachrichten pro Sekunde verarbeiten und jetzt ist die Frage wie das ganze funktioniert und unten drunter ist eben Kraft ein verteiltes System.

00:13:44: Und an david ist komplett anders implementiert also das heißt der produsa z.b. hat eben dann item content producing Apps das heißt.

00:13:54: Auch was in den verteiltes System ist kann es passieren dass wenn z.b. Netzwerk nicht stimmt am dass ich immer nachricht zweimal sende aber Kafka ist eben dann so schlau zu erkennen ob die Nachrichten der doppelte Nachricht ist.

00:14:04: Oder eben nicht und er hat genau das gleiche für die Replikation und für die Konsumieren der Nachrichten.

00:14:11: Das Wichtige und deswegen starte ich gerne so Exkursion auch im aus der Business Sicht ist dass ich ihm das Problem des businesses lösen möchte und wenn wir jetzt wieder das Beispiel der payment platform nehmen.

00:14:21: Naja die Kanban Systeme der Vergangenheit die laufen alle auf eine Mainframe und da habe ich eben dann xa Transaktionen zwischen der DB2 und dem IBM MQ System das aber dafür eben nicht so gut skaliert.

00:14:32: Auf der anderen Seite mit Kafka setze ich das mit dem gleichen IP Eis um also auch in Kafka habe ich Apps wie z.b. commit und Rollback.

00:14:40: Unten drunter ist es aber komplett anders implementiert in den verteilten System und ich kann ganz ehrlich auch gar nicht tief erklären wie das funktioniert das kann man nachlesen am Caspers OpenSource und,

00:14:49: wir haben viele engineers von unserer von Controllern die das in Kafka Summit talks erklärt haben aber grundsätzlich ist es wirklich der Meere dass ich auch end-to-end garantieren kann auch für große Datenmengen,

00:14:58: dass die nachricht die einmal beim produsat produziert wurde.

00:15:01: Einmal bei allen consumer jeweils angelangt und dort konsumiert wird genau einmal und das ist noch mal dieses ganz wichtige Prinzip es gibt eben nicht mehr nur dieses at least once Prinzip des normalerweise für verteilte Systeme genutzt wird.

00:15:13: Sondern seit über fünf Jahren gibt es in Kafka auch das Prinzip von exactly once semantics,

00:15:18: und an das kann ich dann wirklich für die ganzen Pipelines auch verwenden nicht nur von A nach B sondern insbesondere auch wenn ich daneben Anwendungen baue mit kafka-streams mit Casey Quell oder ähnlichen,

00:15:28: damit ich dann eben auch hier transaktionale Anwendungen mit Kafka Baum.

00:15:32: Okay du hast von noch ein richtig spannendes Konzept gesagt von wegen Kafka erkennt wenn eine Nachricht zweimal gesendet wurde.

00:15:42: Anwidern also kannst du dazu vielleicht ein paar Sachen sagen für das.

00:15:51: Ausnutzer oder Entwickler sich damit der nur eine Konfiguration als ich schalte das sächlich in der,

00:15:56: in der config file einfach am exactly one semantic Sun mit einem mit einem yes no button quasi oder Konfekt und unten drunter die edlp iOS framework,

00:16:07: MZ daneben das Nachrichten senden anders um,

00:16:10: das ist ja ganz generell egal ob ich jetzt exakt Yvonne sm antik verwende oder nicht im Kaufpreis ist ganz wichtig zu verstehen dass ich sowohl auf Client als auch auf Server Seite fast jede,

00:16:21: ist Thematik konfigurieren kann und da gibt es viele viele verschiedene Setups das extremste Beispiel auf der einen Seite ist fire and forget,

00:16:29: David einfach drum wo ich möchte Nachrichten schicken ohne jegliche Garantie ob es ankommt ist in vielen ernsten aber gut genug dafür aber viel performante.

00:16:37: Und das andere Extrem ist im exakt Yvonne zimmermann.

00:16:39: Aber es gibt noch viel mehr Fragen zum BWM bevor ich das Ganze beim consumer dann bekomme so muss das ganze auf der Serverseite auch repliziert werden über verschiedene Knoten so dass es wirklich auch persistent ist selbst im Ausfall von knot.

00:16:53: Und das kann ich an jeder Stelle konfigurieren wie es eben von meiner SLS notwendig ist und am das ist wirklich so der Mehrwert,

00:16:59: dass ich das eben auch für meine Anforderungen anpassen kann damit ich eben dann an diese Transaktionen oder ähnliche Themen umsetzen kann,

00:17:07: weil das man ja auch dazu sagen muss an wenn man hier wieder aus businesses startet am Anfang hört man sehr auf die Anfrage ja wir brauchen am Zero Dädalus und Zero Downtime wenn man da natürlich dem Kunde erklärt an mach das dann kein Aufwand ist,

00:17:19: dann erkennt man sehr schnell her wenn hier Downtown von 60 Sekunden besteht im desasterfall wenn kompletter data center ausfällt ist es auch noch.

00:17:28: Und deswegen muss mich immer ganz vorsichtig sein aber es gibt diese transnationalen Kapazitäten dann musst du eben richtig einsetzen und richtig konfigurieren.

00:17:36: Jetzt nehmen wir mal an man würde Kafka nicht unbedingt als Datenbank nutzen wollen sondern wirklich einfacher irgendwie für Stream processing.

00:17:45: Und jetzt werden die Latte haben ja trotzdem persistiert es heißt ich habe ja irgendwo in meinem Unternehmen an mehreren Stellen diese Daten persistiert.

00:17:54: Bietet Kafka irgendwie Möglichkeiten ich sag jetzt mal alte Daten weg zu schmeißen oder hat.

00:17:59: Gibt es da irgendwelche policies die dafür sorgen dass wir nicht unendlich viel storage volllaufen lassen,

00:18:04: das ist ja genau einer der der Prinzipien von kafka am muss ich es auch von vielen anderen Systemen unterscheidet also wir haben sie gesagt das ist ein up and only Log also die neuen Informationen werden immer 1 log angehängt.

00:18:16: Und am auf diesem Grund gibt jetzt auch eben die sogenannte detention time und die kann ich eben wirklich probusiness Objekt also mkpreis dessen Kafka Topic genauso wie bei einer message TuneECU.

00:18:27: Und brocas Kartoffel kann ich eben eine retention time definieren das kann ich entweder anhand der Zeit machen also ich kann sagen halt die mir Daten nur die letzten 7 Tage oder 30 Tage.

00:18:37: Oder ich kann das ganze auch anhand der Größe machen z.b. am halt die mir immer das letzte Gigabyte oder Terabyte oder ähnliches pro.

00:18:44: Und basiert auf dem kann ich eben Kafka so konfigurieren dass es immer nur die letzten Datenströme in dem Kafka topic.

00:18:51: Und es spannend ist eben dass es hier wirklich wieder pro Use-Case unterschiedlich.

00:18:55: Für die klassischen News Käse sind jetzt viele denken wie im Log Analytics z.b. oder Sensordaten von den IOT devices.

00:19:02: Das ist oftmals gut genug wenn ich die Daten nur drei Tage halte weil ich möchte die kontinuierlich,

00:19:07: korrelieren verarbeiten aggregieren oder vielleicht auch nur eine Data-Warehouse schreiben oder in der aggregierten Versionen Data-Warehouse schreiben.

00:19:15: Und an das ist okay wenn die automatisch nach drei Tagen gelöscht werden jetzt haben wir bei andere Szenarien mit z.b. wieder im Banking und wenn ich regulatory reporting machen muss.

00:19:24: Muss ich auch auf historische Daten zugreifen und dann speichere ich für solche Datensätze die Daten in Kafka eben auch länger.

00:19:30: Und am es gibt jetzt die Möglichkeit hier Daten auch im Jahr zu speichern oder einfach mit herrschend 1 -1 heißt ich speichere Daten unendlich,

00:19:38: das macht man natürlich nicht für Terabyte zwei einlogdaten aber z.b. für transnationale Informationen wie z.b. Kunden Transaktionen kann man das durchaus machen weil das eben eher kleinere Datenmengen sind und das hat dann den Mehrwert,

00:19:52: dass die Daten eben immer wieder von verschiedenen Systemen von kafka abgegriffen werden können der Charme hier dran ist dadurch dass das eben append-only Log ist,

00:20:02: sind die Daten auf Kafka immer mit garantiert orderings in der richtigen Reihenfolge mit timestamps.

00:20:08: Wenn ich jetzt z.b. einen inzident in der Bank habe kann ich jetzt einfach mit einem Python klein hergehen und sagen gib mir mal die letzten Transaktionen der letzten 90 Tage ich möchte die mit meinem Job wieder Notebook analysieren oder in den Dashboard schieben.

00:20:21: Diese Konstanten läuft komplett unabhängig von dem Mischen für den Workflow der vielleicht in scharfer unabhängig davon die daten consume.

00:20:29: Das ist wirklich eine dieser stärken Design Kopplung mit diesem Blog ich kann völlig entkoppelt Anwendungen bauen also die Grundidee von diesen Themen die microservices das eben,

00:20:38: die Anwendungen nicht eng gekoppelt sind wir über eine klassische HTTP Integration das ist der Riesen Mehrwert warum ich für solche Szenarien dann Kafka Einsätze.

00:20:48: Ja das ist wirklich ein großer Schamhaar also gerade diese ganze.

00:20:53: Dieses ganze asynchroner kommunizieren zwischen Anwendungen wie es eben bei microservices auf der Fall ist und entsprechend sich gegenseitig vor Fehler ausfallen zu schützen sehen auch ein sehr interessanter usecase von kafka aber,

00:21:08: was mich noch ein bisschen mehr interessiert ist.

00:21:11: Arm du hast jetzt gerade gesagt man kann die Loks oder die Nachrichten der letzten 90 Tage abgreifen wenn man sich so ein bisschen mit Kafka beschäftigt dann liest man sehr schnell was über Offset und Offset early ist Aufsatz latest kann man auch.

00:21:26: Aber bestimmte timestamps abfragen bei Kafka also kann man ganz klasse Spiel gegen eine SQL-Datenbank oder

00:21:33: eine zeitreihendatenbank sagen gib mir eine Nachricht zu einem bestimmten Zeitstempel bzw gib mir die Nachrichten ab einem bestimmten Zeitstempel anstelle des Offsets genau die ganze Frage was kann man es einfach mit Kafka machen und

00:21:47: warum kann ich jetzt eben nicht die nächsten Datenbanken ersetzt nur darum ist es nicht das Ziel,

00:21:52: also diese Daten werden in diesem Blog gespeichert mit ihm diesen Offsets also auf seid heißt quasi die erste Nachricht ist 10 die 2 1 1 3 1 2 und so weiter,

00:22:00: und dann kann ich eben von dem kleinen die Daten wieder konsumieren ich kann diese Daten auch wieder den timestamps abgreifen also das geht und genau dieses Beispiel wieder mit dem inzident ich kann Daten innerhalb von einer bestimmten timeframe am abgreifen in diesem garantiert ordering.

00:22:15: Was ich aber nicht machen kann das ist jetzt der riesen Unterschied warum Kafka nicht alle Daten mal Probleme löst ich kann keine komplexen

00:22:23: Anfragen an dieses Lock stellen ich kann wirklich nur Daten anhand diesen Offsets oder times es abspielen und daneben in meiner kleinen an wenn du wieder analysieren ich kann jetzt aber nicht wie einer Oracle Datenbank oder MongoDB,

00:22:35: eine komplexe SQL-Query schreiben und gegen des Kafka lukschy.

00:22:40: Also das geht nicht ich kann Teile davon in der Kafka Client Anwendungsschreiben ist wenn wir gleich denke ich auch noch besprechen,

00:22:46: aber grundsätzlich erstmal wirklich der riesen Unterschied ist eben warum Kafka nicht der Ersatz meine Datenbank ist,

00:22:52: die Grundregel Nummer eins ist im Einrich kann keine kompletten keine komplexen Analysen fahren gegen das Kafka Log dafür ist es nie gebaut und war nie gedacht.

00:23:00: Und das ist der Unterschied warum dann eben oftmals eben auch die meisten Kunden Kraft hat zusammen mit anderen Daten mit Datenbanken verwenden und hiermit kafka-connect eben dann die Pipelines aufbauen,

00:23:11: so dass manche Anwendungen die Daten direkt in Kafka in Echtzeit verwenden andere aber natürlich die Daten einfach in ihrer Datenbank oder data Lake schieben um dort eben z.b. Komplex Analysen zu.

00:23:23: Jetzt hast du gerade schon gesagt überall kleines reden wir gleich ein bisschen lass uns das doch gerne jetzt machen aber wie sieht denn so ein klassischer Kafka Client aus.

00:23:31: Das ist jetzt auch wieder das ganz spannende an Kafka das muss mal auch noch vielleicht vor noch erläutern in Kafka die Serverseite ist dumm also hier geht's jetzt wirklich um dieses Prinzip auch was der Martin Fowler mal schön,

00:23:42: der diskutiert hat mit diesen Smart endpoints und dumb pipes,

00:23:46: also Kafka skaliert so gut weil es eben an die Logik in den kleinen schiebt das ist auch eine riesen Unterschied zu message pro kann ich kann auf Serverseite nicht filtern oder Daten verarbeiten,

00:23:56: also das passiert alles in dem kleinen

00:23:58: und der kleinen kann jetzt alles sein das ist jetzt der riesenschaben da dran jede Domäne wenn ich jetzt microservices baue oder Domain Domain driven Design,

00:24:07: jeder Domäne oder jede Anwendung kann ihre eigenen Technologien einsetzen und wenn du jetzt fragst wie schaut so ein klein aus an spielt keine Rolle es muss eben irgendwie die Daten von kafka vom Block abgreifen können.

00:24:17: Und an da gibt's jetzt ein einfachste Variante EP 1 in allen verschiedenen Programmiersprachen also wir von Kontrollen am z.b. neben scharfer welches eben bei Kafka dabei ist,

00:24:27: auf Clients verteilen oder C plus plus oder dot net,

00:24:31: oder wir haben z.b. auch Rest HTTP LPA ist so dass man direkt mit http auf das Kraftklub zugreifen kann für produzieren oder konsumieren von Nachricht.

00:24:40: Aber am genauso spannend viele,

00:24:43: Kräutersauna naja ich will euch nicht lole recording machen ich will eben mein Favorite Analytics tool nehmen oder eine andere Mittel werfe Integration

00:24:51: naja und dann nehme ich eben dort den Kafka Connector dafür und an das ist der riesenschaben da dran am dadurch dass ich eben wirklich im data Streaming Umfeld Kafka als De-facto-Standard am Markt etabliert hat gibt heute kaum eine andere Plattform die Nichten Kafka Interface hart

00:25:05: Und wenn es tatsächlich eine gibt die noch keines hat dann kann sie immer noch über HTTP integrieren und deswegen wie schaut der kleinen aus,

00:25:12: völlig beliebig und das ist ja riesen charmant wird mit Kafka eben nicht aufgezwungen dass man den beliebige dass man bestimmte Technologie auf Kleinseite anwenden muss weil,

00:25:20: wir wissen alle dass der das Heinz ist der verwendeten der verwendet eben kein Schaf auf diversen Gründen auf der anderen Seite eben wenn ich jetzt irgendwie eine Instant payment Abbau dann baue ich die man nicht mit Python sondern eben mit scharfer oder go und so heute jede Business Unit die eigenen Optionen.

00:25:34: Und trotzdem läuft es ganz über die gleiche Plattform es ist also alles entkoppelt voneinander als ich möchte das wirklich noch mal daraus greifen wir springen alle über Realteilung Skalierbarkeit.

00:25:43: Mit den meisten Kunden bräuchten die ich sehe leider Problem haben die meisten noch nicht ne also gerade in Deutschland hier geht's wirklich der richtige mehr will es auch diese Entkopplung der Systeme und die Flexibilität,

00:25:54: vom andocken von verschiedenen Technologien und im nicht nur cutting-edge in der Cloud sondern dann z.b. auch Legacy mit dem Mainframe unendlich.

00:26:02: Wir waren jetzt gerade bei Kafka eine ganze Weile jetzt gibt es aber auch sowas die kafka-streams dass dass das gleiche oder wo ist der Unterschied ist eben ganz ganz spannender. Also wie gesagt in Kafka muss man sich sowohl die Serverseite als auch die kleinen Seite anschauen die Serverseite ist es Cluster,

00:26:16: dass ich entweder selber betreibe im Data Center oder im als Cloud-Service konsumiere und als Clients gibt's dann eben die Anwendungen jetzt habe ich vorhin schon gesagt es gibt viele Programmiersprachen.

00:26:26: Und da kann ich dann produzieren und konsumieren richtig spannendes aber eigentlich erst wenn ich die Daten nicht nur produzieren dann reinschreiben oder konsumieren dann in der Datenbank schicke,

00:26:36: nichts anderes ist ja auch was kafka-connect macht mit einem Rapper außenrum sondern wenn ich diese Daten Informationen die rein fließen dann auch in Echtzeit verwende und korreliere oftmals auch aus verschiedenen Datenquellen.

00:26:47: Das ist daneben das sogenannte Stream processing ich sage auf mein Zimmer bei Kunden auch das ist die secret Songs weil das ist der so ich dann den wirklichen Mehrwert generieren kann wenn ich die Daten auch in Echtzeit korrelieren anwende.

00:26:58: Und da kann ich jetzt entweder wieder und mit einem ganz normalen kleinen die daten konsumieren und diese ganze businesslogic selber schreiben für das Verarbeiten der Daten.

00:27:06: Oder ich verwende eben einen Stream processing framework dafür.

00:27:10: Unter Stream processing framework wie z.b. im Kafka Streams welches als Server library bei Kafka mit dabei ist hier kann ich daneben Daten wenn ich nicht nur am konsumieren sondern diese Daten dann verarbeiten also z.b. Filtern oder auch aggregieren,

00:27:24: und dann die das Endresultat dieser Verarbeitung wieder zurück in den anderes Kraft card.

00:27:29: Also im Prinzip ist kafka-streams Rapper rund um den Server producer und consumer und ich habe da eben dann viele viele Möglichkeiten out-of-the-box die ich mir sonst selber bauen möchte.

00:27:40: Und am besten die Grundidee dass ich das nicht selber machen muss deswegen gibt es eben Stream processing Frameworks und eins davon ist im kafka-streams welches eben Kafka nativ ist.

00:27:50: Geht so ein bisschen in die Richtung Stateful and stateless na also a man das Kafka Streams wenn du sagst Daten eingegeben den stage hält

00:27:59: Dessau Nachrichten Streams kann man das so sehen genau also es gibt immer im Stream zwei Arten die einfache ist stateless hier geht's wirklich drum dass ich jedes eingehende Event einzeln verarbeite

00:28:10: da kann auch ganz komplexe businesslogic sein fließen nicht nur ein füttern oder transformieren ich kann ja auch ein analytisches Modell anwenden dass ich woanders trainiert habe und dann im Bett.

00:28:18: Am Apotheke zum einzelne Events ich erkläre mal besten von den Beispielen versteht man es besser wenn ich Sensordaten abgreifen und danach Kafka schiebe,

00:28:26: Mit dem stateless Event bei z.b. condition-monitoring also ich schaue mir jedes einzelne Event an und z.b. die Temperatur.

00:28:32: Und nur z.b. wenn die Temperatur über 100 Grad ist dann finde ich das Event und verarbeite es weiter z.b. nächsten Anwendungen alarm schick.

00:28:41: Aber viel spannender was daneben noch wenn ich mir Stateful Anwendungen baue hier schaue ich nicht nur auf ein Event sondern auf mehrere Events in diesem Sensor Beispiel z.b. entweder auf mehrere Center Events von einer Maschine.

00:28:54: Oder eben sogar von mehreren Maschinen.

00:28:56: Und hier schaue ich mir dann immer auf den Zustand über ein bestimmtes window über dem Fenster z.b. wo ich daneben sage innerhalb der letzten 60 sekunden.

00:29:05: Wenn mehr als 20 dieser Events über 100 Grad sind dann schicke ich den alarm raus aber das ist deutlich mächtiger aber damit auch wird deutlich schwieriger zu implementieren weil ich natürlich dann sehr schnell auch am,

00:29:17: z.b. Thematiken wie memory consumption beachten muss aber deswegen genau die 2. artigen Weg Stream processing bauen kann.

00:29:24: Haben die Grundrechte ist trotzdem immer wie bei Software Development Kit mitessen place possible.

00:29:29: Und am so insbesondere bei Stateful Stream processing am kommt man manchmal einfach eingrenzen wo dann immer auch wieder eine andere Datenbank besser geeignet ist

00:29:38: in diesem Sinne aber mit den Sensoren ich kann es sehr gut mit kafka-streams Daten aggregieren und filtern und korrelieren und auch Modelle anwenden z.b. dich embedded habe

00:29:47: aber für wirklich komplex Analytics

00:29:50: sollte diesem Thema dann schiebe ich die Daten lieber in der timeseries Datenbank und macht dort das Analytics weil genau da dafür wurde diese Datenbank eben gebaut und die hat man dann immer diese trade-offs,

00:29:59: aber generell Stream processing mit Kafka Streams oder okaysi Quellen als Kafka native Lösung.

00:30:05: Oder auf externe Lösungen wie Apache flink hier geht's drum Stateful oder stateless

00:30:09: Daten korrelieren während sie in Bewegung sind das ist eben das spannende im Vergleich zu einer Datenbank oder einem data Lake absolut vielleicht noch eine ergänzende frage jetzt wo wir schon bei state sind und Datenbank Features.

00:30:21: Wie läuft es denn bei Giants ab das ist doch unfassbar Komplex eigentlich in Aussicht eines verteilten Systems wie schafft es Kafka dort.

00:30:30: Aber ich sag mal die Styles zu kombinieren

00:30:35: 80% die gleichen Features egal jetzt kafka-streams Casey quel flink Spark Streaming die Grundidee ist einfach sobald ich

00:30:43: Zustand erreichen möchte und es dann eben über diese joints z.b. weil dann aggregiere ich ja verschiedene Datenströme und das heißt ich bau mir dann quasi in der Anwendung Zustand auf,

00:30:53: das ist aber ganz ganz wichtig zu verstehen das ist nicht im Kafka

00:30:56: Server in Broker das ist in der Anwendung wo der Zug schon aufgebaut wird und in kafka-streams oder auch im Käfig weil es ist dann so dass hier entweder nur im memory im Speicher der schon aufgebaut wird

00:31:09: und dann natürlich wenn die wenn der Container down ist dann ist den die Daten verloren oder ich kann die Daten auch wieder der Clientanwendung persistieren.

00:31:16: Out-of-the-box Meteo rocksdb verwendet welches etablierter key-value store ist der im auch für diese Anforderungen sehr gut taugt und dann kann ich eben sogar so eine Art nennen operacional tailorstore in der Kafka Anwendung bauen wirklich auch für kritische transnationale Systeme.

00:31:31: Und am bist jetzt in eine Möglichkeit wie ich sowas machen kann und da muss ich immer gut abwägen mach das jetzt hin wenn ich sowas Ende Kafka Anwendung noch mit kafka-streams oder Casey.

00:31:41: Oder sind vielleicht doch besser aus welchen Gründen auch immer wenn ich nur in Anführungszeichen der Aggregation oder Verarbeitung war,

00:31:47: und dann bis ganz aber trotzdem über kafka-connect in den MongoDB schreibe für welche Gründe auch immer auf dessen aber genau diese verschiedenen Möglichkeiten die ich habe und immer die Frage stellen wie ich mir immer stellen sollte weil dann muss ich immer die die verschiedenen Vorteile und Nachteile abwägen.

00:32:01: Aus meiner Sicht ist immer die erste Frage am brauche ich weitere Tools meine andere Datenbank oder kann ich es nur mit Kafka lösen weil dann brauche ich keine andere Infrastruktur das hat höhere Kosten ihren Betrieb und so weiter end-to-end leiten Sie ein größeres Problem.

00:32:14: Aber auf der anderen Seite mich auch gerade gesagt aber muss immer verstehen was in die trade-offs ich kann kein complex Analytics in Kafka machen und auch manchmal ist es für die long-term persistence nicht die richtige Technologie man sollte sich all diese Möglichkeiten Bewusstsein und kannst dann je nach Beute einfach entscheiden wie das Ganze zusammen passt.

00:32:30: Du hast ein paar mal noch was von wegen flink und spar gezählt magst du da noch kurz ein paar Worte zu anreißen was was ist das genau wann verwendet man das vielleicht gegenüber von Kay Streams oder Kafka.

00:32:43: Genau also der ersten Thematik ist erstmal wirklich so ein Unterschied zwischen dem Kern von data Streaming mit Kafka wo ich Daten das Messaging und in storage verwende um verschiedene Systeme zu integrieren

00:32:55: und Daten hin und her zu schieben das machen fast alle mit Kafka und egal ob ich dann für Screenshots das hängt.

00:33:01: Kafka native Tools wie kafka-streams oder que Sequel verwende oder eben was ist er Party engines wie z.b. flink oder Spark streaming.

00:33:09: Am alle vor Nachteile 80% der Features will ich sagen überlappen also man kann vieles mit allen dieser Thematik mehr lösen hat alles der gewisse Anreize.

00:33:19: An der Kern Unterschied ist einfach dass ich mit anderen Tools wie flink oder Sport eine andere Engine habe und insbesondere wieder für kritische Systeme.

00:33:26: Ihr Mehrkomponenten nicht kombinieren muss wenn and un pipe.

00:33:30: Umso schwieriger wird es die end-to-end latency abzusichern und die uptime SLS und Datenverlust aber ansonsten ist es ruhig kann es beliebig kombinieren deswegen sind am Puls wie flink wendig komplementär zum Kern von kafka,

00:33:43: und am nicht wirklich uncompetitive und am so hängt das ganze dann quasi zusammen und deswegen am Markt sind wir all diese deployment bei dem Kunden also manche verwenden für manche Use-Cases Kafka streams.

00:33:53: Für andere ist es dann eher flink weil flink z.b. stärker ist auch nicht nur für realtime sondern auch für Patchwork.

00:34:00: Na ja und wenn ich eh schon der petrispark für Batch im Einsatz habe macht weit es auch sinnvoll manche Stream processing Workloads aber da muss man wirklich mehr in die Details schauen,

00:34:08: aber grundsätzlich sind Kafka der Kern für das Messaging und den Tschechen und dann kann ich mir überlegen für Stream processing nehme ich eine Kafka native oder Netzwerkparty Ente.

00:34:18: Der vielleicht noch abschließen Einsatz zur adicional Tools in der nächste jetzt mal ne also es ist wird ja oft gesagt und hast du ja jetzt nicht auch,

00:34:28: KV Gottschalk und flink sind Stuhl sie muss man extra nehmen des Kafka Cluster stellen und muss man eben auch pflegen und bringe auch eigene Risiken mit sich.

00:34:40: Anke Streams ist einer Java an oder Java Bibliothek die irgendwie Kafka nativ läuft aber so wie ich das verstehe ist Kay Streams eben auch.

00:34:50: Innerhalb eines Java Programms angewendet also irgendwie auch eine eigene Architektur oder verstehe ich da was falsch.

00:34:57: Genau also der riesen Unterschied aus aus implementierungs Sicht ist das

00:35:01: Desigual Apache flink Spark Streaming dessen alles in und Infrastrukturen Diako betrieben werden kafka-streams entgegengesetzt Shara Library also es wäre ich ein Schaffell und das kann ich da ja in der andere chawer Anwendung m Betten oder muss ich sogar,

00:35:15: also bei kafka-streams muss ich mir immer überlegen was ist eine Anwendung außenrum und wie betreibe ich das ganze als z.b. dann ich bau ne eigene chabe Anwendung und die Bräute dann in den Docker Container zum.

00:35:25: Und das hat jetzt eben vor Nachteile wieder also die vor der Vorteil ist unheimlich flexibel und ich kann es immerhin existierende chabe Anwendungen einbetten.

00:35:33: Ich muss aber eben als Nachteil da mich auch selber drum kümmern wie ich das ganze betreibe.

00:35:36: Das sieht man jetzt auch dann wieder einfach die unterschiedlichen Einsatz cinarin und deswegen hat die meisten unserer Kunden für manche Szenarien kafka-streams im Einsatz und für andere Szenarien daneben sowas wie Apache flink.

00:35:46: Wie weit auch mal generell der kann Unterschiede heute ganz wenig drüber gesprochen aber was man sie da ganz klar den den den den Tränen die Cloud und hier ist in der Vorteil dass ich im für solche Technologien daneben ein fully Managed Service verwende.

00:35:59: Den gibt es sowohl für am Kafka jetzt mit Confluent Cloud z.b.

00:36:03: Der gibt es auch verpflegt mit manchen offerings und den gibt es aber jetzt nicht von Kafka Streams Kafka Streams eben nur eine Library ist da da geht es einfach technisch nicht und das sind ebenso die Unterschiede je nachdem was ich machen möchte und wo ich das am aufräumen muss oder möchte.

00:36:18: Jetzt bist du natürlich irgendwie in einem data science Podcast gelandet und Anna und wir data scientist and wir machen natürlich sehr sehr viel mit ich sag mal batch processing.

00:36:28: Am hast du so ein paar typische Kafka Anwendungsfälle vielleicht noch für data science die man sich mal angucken kann.

00:36:35: Also absolut also erstmal ist es trotzdem so selbst im data science Umfeld wenn ich eben meinen klassisches data Lake verwende für Model Training oder ähnliches am.

00:36:43: Data injection passiert sehr sehr oft mit Kafka weil auch für der das 1 Teams ist es oftmals besser wenn ich die Daten akkurate zur Verfügung habe und dem nicht dass am Ende des Tages über den Patchwork-Look sondern eben wenn die daten passieren,

00:36:56: das muss auch dann nicht im Millisekundenbereich passieren sondern vielleicht in 5 minuten ein Batch mit Kafka,

00:37:01: und dafür auch nicht vergessen selbst mit Kafka die produsat consumer Arbeiten oftmals im Bett da wird nicht jeder Neven Einzel verarbeitet weil es für Gigabyte von Daten oftmals nicht sinnvoll ist.

00:37:10: Und somit ist schon der erste Mehrwert mit kafka-connect kann ich die Daten zeitnah in this data Lake oder Data Warehouse schieben sodass ich dann eben mein Titans Grip dagegen fahren kann.

00:37:20: In dein Zukunft aber noch und das ist vielleicht jetzt spannender hier.

00:37:24: Wir sind einen unheimlich großen sogenannten impedance mismatch zwischen dem Model Training der eben in der Regel heute noch mit Patchwork world passiert.

00:37:33: Und dann aber die Model deployment,

00:37:34: weil Model deployment hat oft Anforderungen eben Wilo latency 24 x 7 Betrieb Zero data loss insbesondere für Themen wie z.b. protection

00:37:44: oder der recommendation engine und deswegen sehen wir sehr sehr viele Kunden die ich natürlich die Daten im Data lake.

00:37:50: Ferien Modelle trainieren im Patchwork laut vielleicht jeden Tag jede Woche aber dann diese Modelle auch irgendwie planen müssen und dann für solche Szenarien ist es fast immer.

00:37:59: Wenn du wieder zurück zum Bezness gehen die Frage ist das besser die daten jetzt zu verarbeiten oder später in diesem Fall ist es besser wird ein predictions sofort zu machen oder erst später in data lake.

00:38:10: Und da ich jetzt die ganze Zeit schon mit Banking gesprochen hat und wenn man sich vorstellen man baut ne protection Anwendung na ja ich kann das auch in data Lake laufen lassen mit meinen Modellen wenn ich aber erst nachher Stunde erkennen dass ein Frog passiert ist dann kriege ich immer noch ein alarm aber der Front ist schon passiert.

00:38:25: Und deswegen ist eins der Kerze darin dass wir immer mehr sehen dass das data-scientist ihre Modelle auch in Kafka Anwendungen oder im Kafka eco-system betreiben.

00:38:34: Und hinzu kommt dann auch noch das gleiche für das ganze Ökosystem monitoring ich möchte ja auch die Infrastruktur Monitoren und meine Modelle Monitoren

00:38:41: IP testing z.b. das sind alles Themen Hameau des Kafka eco-system im helfen kann mit einer Infrastruktur um Daten in Echtzeit in Bewegung zu verarbeiten und deswegen sehen wir das sehr sehr oft auch mittlerweile jeder seins Umfeld.

00:38:55: Und es gibt ja auch mittlerweile immer mehr machine learning frameworks die direkt Kafka interfaces anbieten z.b. wenn man sich tensorflow anschaut tensorflow hat man früher immer die Daten erst in hdfs oder ähnliches geschrieben und dann Model trainiert

00:39:09: mittlerweile kann ich Daten auch direkt von Kafka Log mitnehmen tensorflow Kafka Connector konsumieren das Model training ist oftmals immer noch Patch

00:39:17: aber dadurch dass Kafka emissa Pantone iLok ist ist das genau der Schaden dran einem monitoring Anwendung komplett entkoppelt vom data science Team konsumierte Daten in Echtzeit.

00:39:26: Das Data science Team sagt ich habe mein Zug oder Notebook und ich möchte Daten einmal am Tag konsumieren vom gleichen Block.

00:39:32: Verwende dadurch tensorflow muss aber nicht noch ein extra data lecken oder für auf Spinnen und dessen dann genau diese Mehrwerte wo wir eben immer mehr

00:39:39: das Thema sehen wo auch der das scientist immer mehr Kafka einsetzen da geht ihm ganz klar der Trend hin da komme ich wahrscheinlich in der Teilung eingehen heute mehr aber wir haben früher alle mit dieser lambda-architektur eingebaut Batch und wird Ei mit zwei separaten Infrastrukturen.

00:39:53: Heute verwenden selbst die der das 1 Teams immer mehr diese Kappe Architektur oder Kernkraft kann und wildheim ist auch wenn ich aus als Konsument mit Batch darauf zugreifen muss oder möchte.

00:40:05: Super das ist insgesamt ein sehr sehr spannender Einbeck als flight allerletzte Frage protection implementiert du das mit flink Spark oder Case stream.

00:40:16: Wasser dein favorita.

00:40:18: Update hängt tatsächlich wieder ein bisschen Hauptszenario ab bei Frau detection system täglich so dass hier einer der spannendsten Use-Cases ist der wirklich mit low latency laufen muss und 24 x 7 ohne Datenverlust.

00:40:30: Und genau für diese Use-Cases ist einfach einfacher wenn ich das mit nur einer Infostruktur Umsätze end-to-end,

00:40:36: und deswegen ist das tatsächlich ein Beispiel wo sehr sehr viele Kunden an am kafka-streams einsetzen,

00:40:41: also gibt's diverse praktische Beispiele auch am z.b. Körperzone Security Engine gebaut also Gravis der der ride-hailing Service in in Asien sowie über und Lift.

00:40:49: Im Urlaub z.b. PayPal macht unheimlich viel am rundum Kafka mit protection abend also es gibt da viele Beispiele aber es gibt auch hier wieder immer die trade-offs also mal ganz vorsichtig sein ich würde es wegen eher sagen,

00:40:59: man sollte es mit Stream processing machen ob man dann mit flink oder Crafter Stream oder ähnlichem macht ist eine andere Frage man sollte es aber definitiv nicht im data Lake umsetzen.

00:41:10: Sehr schön,

00:41:11: von meiner Seite aus ich bin total zufrieden und bedanke mich sehr sehr herzlich bei Dir aber hast du noch ein paar abschließende Worte oder möchtest Du noch was verlieren was jetzt vielleicht nicht zur Geltung kam

00:41:20: ja gleich zum Abschluss einfach wen diese Themen interessieren am auf meinem Blog schreibe ich zu diesen Themen sehr sehr viele Beispiele am mir ist immer ganz wichtig auch am Release auf der realen Welt zu zeigen

00:41:30: auf meinem Blog findet ihr daher viele Beispiele sowohl zur technischen Themen wie Kafka und machine learning oder data mal schauen jetzt heute gar nicht drüber gesprochen hast cutting-edge Thema.

00:41:38: Aber dann immer auf Industrie spezifische Beispiele für Banking insurance retail Telco und so weiter.

00:41:44: Also wer da Interesse hat kann gerne auf meinen Blog schauen oder auch gerne mit mir auf LinkedIn und Twitter vernetzen um in ein Beziehung zu stehen.

00:41:53: Ja den Block den kann ich auch sehr empfehlen über dir bin ich auf dich aufmerksam geworden in sehr ich nenne es mal anspruchsvollen Zeiten hatte mir sehr geholfen.

00:42:01: In dem Sinne bedanke ich mich direkt in zweifacher Hinsicht einmal für den Podcast und einmal für den Block und ja wird nicht mal verabschieden.

00:42:13: Tja das war es leider auch schon ich bedanke mich ganz ganz herzlich bei Kai und auch bei dir fürs Zuhören das freut mich immer Hörer und Hörerinnen.

00:42:22: Zu haben.

00:42:24: Lass gerne ein bisschen Feedback da gibt gerne mal ein paar Themenwünsche ab falls ich irgendwas ganz besonders interessiert in bezug auf data science data engineering.

00:42:34: Consulting was auch immer und wenn du dich mit Kafka beschäftigst oder mit.

00:42:39: Message Streaming schau super gerne beim block von Kai vorbei das war nicht nur so daher gesagt ich finde ihn.

00:42:47: Sehr ich würde fast sagen inspirierend man lernt sehr viel über das Ökosystem von kafka über Kafka selbst also.

00:42:56: Eine ernst gemeint war Verfehlung von mir und jetzt wünsche ich dir noch viel Spaß bei was auch immer du als nächstes machst und.

00:43:04: Bis zum nächsten mal tschüssi.

00:43:06: Music.

Neuer Kommentar

Dein Name oder Pseudonym (wird öffentlich angezeigt)
Mindestens 10 Zeichen
Durch das Abschicken des Formulars stimmst du zu, dass der Wert unter "Name oder Pseudonym" gespeichert wird und öffentlich angezeigt werden kann. Wir speichern keine IP-Adressen oder andere personenbezogene Daten. Die Nutzung deines echten Namens ist freiwillig.