#eventstreamprocessing

Apache Kafka коренным образом изменила подход к проектированию распределенных систем. Она объединяет в себе надежность дискового хранилища и скорость обмена сообщениями. Понимание принципов работы партиций и групп потребителей открывает двери к созданию высоконагруженных приложений. Начните внедрение с простых задач по сбору метрик, и вы быстро оцените мощь этой платформы.   Референсные ссылки: Official Apache Kafka Documentation (2025) Confluent Blog: Kafka Architecture Fundamentals (2025) Apache Kafka KRaft Mode Guide (2025)

Das »Warum« der Datenverarbeitung liegt auf der Hand, wenn man die große Anzahl von Sensoren, vernetzten Geräten, Websites oder mobilen Anwendungen betrachtet; oder einfach alle Daten, die sowohl von Menschen als auch von Maschinen erzeugt werden. Die immensen, rasch ansteigenden Datenberge erfordern kontinuierlich leistungsfähigere Ansätze zur Datenverarbeitung. Open Source spielt dabei nach Meinung der data Artisans GmbH aus Berlin eine wichtige Rolle.   Die »Vorgeschichte« von Big Data Mit der Erfindung des Computers entstand ein deutlicher Bedarf an Informationen und Datenverarbeitung. In diesen sehr frühen Tagen mussten Informatiker benutzerdefinierte Programme zur Datenverarbeitung schreiben und diese Programme höchstwahrscheinlich in eine Lochkarte stecken. Die nächsten Entwicklungsschritte brachten die Assemblersprache und zielführendere Programmiersprachen wie Fortran, dann C und Java hervor. Aus der »prähistorischen« Big-Data-Perspektive betrachtet, würden Softwareingenieure diese Frameworks nutzen, um speziell entwickelte Programme für bestimmte Datenverarbeitungsaufgaben zu schreiben. Dieses Paradigma der Datenverarbeitung war jedoch nur für wenige Auserwählte, die einen Programmier-Background hatten, zugänglich. Dies verhinderte eine breitere Akzeptanz seitens Datenanalytikern oder der Geschäftswelt, die Informationen verarbeiten und darauf basierend spezifische Entscheidungen treffen wollten. Als nächster Schritt setzte sich um die 1970er Jahre der Einsatz von Datenbanken durch. Traditionelle relationale Datenbanksysteme wie IBMs Datenbanken ermöglichten die Nutzung von SQL (für »Structured Query Language«, auf Deutsch »Strukturierte Abfrage-Sprache«) und erhöhten die Akzeptanz der Datenverarbeitung bei einem breiteren Publikum. SQL ist eine standardisierte und ausdrucksstarke Abfragesprache, die sich ähnlich wie Englisch liest und mehr Menschen Zugang zur Datenverarbeitung bot. Die Anwender waren nicht mehr auf einen Programmierer angewiesen, um spezielle Einzelprogramme zu schreiben und Daten zu analysieren. SQL erweiterte auch die Anzahl und Art der Datenverarbeitungsaufgaben wie Geschäftsanwendungen, Berechnung der Abwanderungsquote oder Warenkorbgröße, Jahresvergleich von Wachstumszahlen etc.   Die Anfänge von Big Data Die Ära von Big Data begann mit dem von Google herausgegebenen MapReduce-Paper, das ein einfaches Modell erklärt, das auf den beiden Primitiven Map und Reduce (die Funktionen zweiter Ordnung sind) basiert, die parallele Berechnungen über eine große Anzahl paralleler Maschinen ermöglichen. Offensichtlich waren parallele Berechnungen schon vor der MapReduce-Ära durch mehrere Computer, Supercomputer und MPI-Systeme möglich. MapReduce stellte es jedoch einem breiteren Publikum zur Verfügung. Dann kam Apache Hadoop als Open-Source-Implementierung des Frameworks (ursprünglich bei Yahoo! implementiert). Hadoop war bald im Open-Source-Bereich weit verbreitet und stand somit einem breiteren Publikum zur Verfügung. Hadoop setzte sich bei verschiedenen Unternehmen durch und viele Big-Data-Akteure stammen aus dem Hadoop-Framework (Cloudera oder Hortonworks). Hadoop hat ein neues Paradigma in der Datenverarbeitung eingeführt: eines, in dem sich Daten in einem verteilten Dateisystem oder Speicher (etwa HDFS for Hadoop) speichern lassen, um zu einem späteren Zeitpunkt Fragen zu diesen Daten stellen zu können (Abfrage von Daten). Der Hadoop-Raum sah einen ähnlichen Weg vor wie bei den relationalen Datenbanken (die Geschichte wiederholt sich immer wieder), wo der erste Schritt die benutzerdefinierte Programmierung durch einen bestimmten »Cast« von Personen beinhaltete, die in der Lage waren, Programme zu schreiben, um dann SQL-Abfragen auf Daten in einem verteilten Dateisystem wie Hive oder anderen Storage-Frameworks zu implementieren.   Die nächste Stufe der Batch-Verarbeitung Der nächste Schritt für Big Data war die Einführung von Apache Spark. Spark ermöglichte eine zusätzliche Parallelisierung und brachte die Batch-Verarbeitung auf die nächste Stufe. Die Batch-Verarbeitung oder Stapelverarbeitung sieht das Einfügen von Daten in ein Speichersystem vor, auf dem dann Berechnungen geplant werden. Das Hauptkonzept besteht darin, dass die Daten irgendwo sitzen, während regelmäßig (täglich, wöchentlich, stündlich) Berechnungen durchgeführt werden, um Ergebnisse basierend auf früheren Informationen sichtbar zu machen. Diese Berechnungen laufen nicht kontinuierlich, sondern haben einen Anfang und ein Ende. Daher müssen sie fortlaufend neu ausgeführt werden, um aktuelle Ergebnisse zu erhalten.   Die Entwicklung von Big Data zu Fast Data: Stream-Verarbeitung In einem weiteren Schritt der Big-Data-Evolution folgte die Einführung der Stream-Verarbeitung mit Apache Storm als erstem weit verbreiteten Framework (es gab andere Forschungssysteme und Frameworks zur gleichen Zeit, aber Storm hatte eine zunehmende Akzeptanz). Was dieses Framework ermöglicht, ist das Schreiben von Programmen, die kontinuierlich (24/7) laufen. Im Gegensatz zum Batch-Verarbeitungsansatz, bei dem die Programme und Anwendungen einen Anfang und ein Ende haben, wird das Programm bei der Stream-Verarbeitung kontinuierlich auf dem Datenstrom ausgeführt und produziert Ergebnisse in Echtzeit, während die Daten generiert werden. Die Stream-Verarbeitung wurde mit der Einführung von Apache Kafka (ursprünglich bei Linkedin) als Speichermechanismus für einen Nachrichtenstrom weiterentwickelt. Kafka fungierte als Puffer zwischen den Datenquellen und dem Verarbeitungssystem (wie Apache Storm). Ein kleiner Umweg in der Entwicklung von Big Data war die sogenannte »Lambda-Architektur«. Diese Architektur entstand, weil die ersten Anwender der Stream-Verarbeitung nicht glaubten, dass Stream-Verarbeitungssysteme wie Apache Storm zuverlässig genug waren, so dass sie beide Systeme (Batch- und Stream-Verarbeitung) gleichzeitig betrieben. Die Lambda-Architektur kombiniert also die beide Systeme, wobei ein Stream-Verarbeitungssystem wie Apache Storm für Echtzeiteinblicke genutzt wird, aber die Architektur dennoch periodisch auf ein Batch-Verarbeitungssystem zurückgreift, das die »Grundwahrheit des Geschehens« aufrechterhält. Zum jetzigen Zeitpunkt wird die Stream-Verarbeitung nur für Sofortmaßnahmen oder Analysen verwendet, nicht aber für die »Ground Source of Truth«.   Die Stream-Verarbeitung wird zugänglich gemacht: Apache Flink Die Landschaft änderte sich etwa um 2015 herum, als Apache Flink begann, sich zu einem führenden Stream-Processing-Framework zu entwickeln, das von namhaften Entwicklern, datenorientierten Unternehmen und Analytikern übernommen wurde. Von Anfang an zeichnete sich Flink durch sehr starke Garantien, eine genau abgestimmte Semantik und eine fehlertolerante Processing-Engine aus. Die Anwender sahen sich darin überzeugt, dass die Lambda-Architektur keine Notwendigkeit mehr sei und Stream Processing für komplexe Ereignisverarbeitung und kontinuierlich laufende, unternehmenskritische Anwendungen geeignet sei. Der gesamte Aufwand, der mit dem Bau und der Wartung von zwei Systemen (ein Batch- und ein Stream-Verarbeitungssystem) verbunden war, konnten nun entfallen, da Flink ein zuverlässiges und zugängliches Datenverarbeitungs-Framework einführte. Die Stream-Verarbeitung führte ein neues Paradigma und einen Wandel in der Denkweise ein: von einem Anfrage-Antwort-Ansatz, bei dem Daten gespeichert werden, bevor Fragen zu einem Ereignis gestellt werden können, zu einem Ansatz, bei dem die Fragen zuerst gestellt werden, um in Echtzeit Informationen zu erhalten, während die Daten laufend generiert werden. Mithilfe der Stream-Verarbeitung lässt sich beispielsweise ein Betrugserkennungsprogramm entwickeln, das rund um die Uhr läuft. Es erfasst Ereignisse in Echtzeit und liefert wertvolle Einblicke, wenn es Anzeichen auf Kreditkartenbetrug erkennt. Dadurch kann verhindert werden, dass der Betrug tatsächlich stattfinden kann. Dies ist eine der größeren Veränderungen in der Datenverarbeitung, weil sie Echtzeiteinblicke in das Geschehen in der Welt und proaktives Handeln ermöglicht.   Fazit und Ausblick »Bei der Entwicklung der Open-Source-Datenverarbeitung wird ein gemeinsames Muster deutlich: Ein neues Framework wird auf dem Markt eingeführt, das zunächst einem bestimmten Publikum zur Verfügung steht, das kundenspezifische Programme zur Datenverarbeitung schreiben kann«, fasst Dr. Stephan Ewen von data Artisans abschließend zusammen. »Dann kommt die Einführung von SQL im Framework, das es für breitere Zielgruppen, die nicht unbedingt Programme für anspruchsvolle Datenverarbeitung schreiben können müssen, zugänglich macht. Mit der Einführung von SQL in der Stream-Verarbeitung dürfte für die Zukunft eine breite Akzeptanz für das Framework in Unternehmen und ein Markt, der exponentiell wächst, zu erwarten sein.«     https://ap-verlag.de/konzepte-fuer-schnellere-datenverarbeitung-im-neuen-jahr/49708/ https://ap-verlag.de/49449-2/49449/ https://ap-verlag.de/the-next-big-thing-tipps-zum-wechsel-von-datenbasierten-zu-ereignisfokussierten-datenstrategien/48418/ https://ap-verlag.de/datenuebertragung-2019-stoerungsfrei-schnell-und-sicher/50053/ https://ap-verlag.de/trends-2019-datenvirtualisierung-ki-und-cloud/49541/   Read the full article

https://pixabay.com/de/ Im zehnten Visual Networking Index (VNI) prognostiziert Cisco eine Verdreifachung des globalen Datenverkehrs in den kommenden vier Jahren. Für das Jahr 2019 erwartet das Unternehmen, dass weltweit die 2-Zetabyte Schallmauer durchbrochen wird. Als Teil dieser Entwicklung wächst auch die Menge an Daten, die unter dem Überbegriff »Big Data« erzeugt, verarbeitet und gespeichert werden. Experten sind sich weitgehend einig, dass diese Entwicklung neue Konzepte der Datenverarbeitung erfordert damit Unternehmen Daten effektiv auswerten und nutzen können. Eine in diesem Zusammenhang zunehmend häufig genannte Technologie ist das Event Stream Processing – die Verarbeitung von Daten in nahezu Echtzeit, die ohne die klassische Stapelverarbeitung auskommt. Für Till Rohrmann, Software Engineer und Co-Founder bei data Artisans, dem ursprünglichen Entwickler der Open-Source-Stream-Processing-Technologie »Apache Flink« spielen die folgenden Punkte im kommenden Jahr eine zentrale Rolle.   Echtzeitverarbeitung von Daten Die Verarbeitung von Daten mit möglichst geringer Latenz ist seit langem eine große Herausforderung. Alle bisherigen Lösungen verfehlten jedoch das, was Unternehmen und Geschäftsanwender wirklich brauchten: eine schnelle Verarbeitung von Daten als Stream mit der Möglichkeit, komplexe Berechnungen und Analysen zu integrieren. Unternehmen und Nutzer hatten bislang mit hohen Latenzen zu kämpfen und versuchten, dies auf alle möglichen kostspieligen Arten zu bewältigen. Event Stream Processing löst dieses Problem.   Das Wachstum geht weiter Eine aktuelle Qubole-Umfrage ergab, dass Apache Flink 2018 mit einer Steigerung der Akzeptanzrate um 125 Prozent im Vergleich zu 2017 das am schnellsten wachsende Open-Source-Projekt im Big-Data-/Hadoop-Ökosystem ist. Die Event-Stream-Processing-Technologie von Apache Flink wird mittlerweile in Unternehmen wie Netflix, Alibaba, Uber und Lyft eingesetzt.   Daten auf vielfältige Weise verarbeiten Apache Flink ermöglicht dem Nutzer seine Daten auf verschiedenste Weise zu verarbeiten. Nicht nur bietet das Projekt eine Vielzahl an Integrationen mit anderen Systemen, um Daten einzulesen, es bietet auch eine Vielzahl an Bibliotheken und Programmierschnittstellen, um Daten schnell und einfach der Anwendungsdomäne angepasst zu verarbeiten. Besonderes Augenmerk sei hier auf die Unterstützung von SQL gelegt, die eine einfache und nahtlose Integration in bestehende IT-Infrastruktur ermöglicht.   Apache Flink überwindet alle Hürden Es gibt viele große Produktionsanwendungen von Apache Flink für das Event Stream Processing. Im Internet sind viele ausführliche Diskussionen von Alibaba, Netflix, Lyft, Uber, DriveTribe und anderen über die Einführung von Flink zu finden. Dabei zeigt sich, dass Event Stream Processing oftmals dort Einsatz findet, wo andere Lösungen scheitern.   In Anlehnung an das Micro-Batching-Paradigma eines anderen Projekts schreibt Alibaba: »Der erste Ansatz besteht darin, Batch als Ausgangspunkt zu verwenden und dann zu versuchen, Streaming zusätzlich zum Batch aufzubauen. Dies wird jedoch wahrscheinlich nicht den strengen Latenzanforderungen entsprechen, da Micro-Batching zur Simulation von Echtzeitverarbeitung einen festen Overhead erfordert. Der Anteil des Overheads steigt aber, wenn Sie versuchen, die Latenz zu reduzieren.« Ebenso schreibt Uber in der Diskussion über seine Flink-basierte Plattform AthenaX, wie das Unternehmen Apache Storm und Apache Samza eingesetzt hatte, bevor Flink eingeführt wurde: »Diese Lösungen waren jedoch noch nicht ideal. Benutzer waren entweder gezwungen, ihre eigenen Streaming-Analyse-Anwendungen zu implementieren, zu verwalten und zu überwachen, oder sie waren darauf beschränkt, Antworten auf einen vordefinierten Fragensatz zu erhalten.« Es scheint, dass auf den ersten Blick Architekturen wie Micro-Batching, Lambda-Architekturen, behelfsmäßige Stream-Processing-Technologien und alternative Stream-Processing-Projekte adäquat erscheinen. Dies gilt so lange, bis die Unternehmen feststellen, dass Anforderungen rund um die Niedriglatenz-Verarbeitung und komplexe Analyse nicht kostengünstig, skalierbar und fehlertolerant erfüllt werden können. »Ich kann Unternehmen, die im kommenden Jahr große Projekte in Sachen Real Time Big Data anvisieren, nur raten eine Event-Stream-Processing-Technologie wie Apache Flink fest einzuplanen«, fasst Till Rohrmann abschließend zusammen. »Die Open-Source-Community und Anbieter wie data Artisans werden auch in Zukunft alles daran setzen, diese Technologie noch weiter voranzubringen und Unternehmen dabei zu helfen von den immer weiter wachsenden Datenströmen bestmöglich zu profitieren.«     https://ap-verlag.de/edge-computing-hohe-it-security-fuer-echtzeit-datenverarbeitung/46836/ https://ap-verlag.de/industrie-4-0-mit-luft-nach-oben-manuelle-datenerfassung-statt-echtzeit-monitoring/43618/ https://ap-verlag.de/95-der-unternehmen-sind-nicht-in-der-lage-ihre-kundendaten-sinnvoll-zu-interpretieren-und-daraus-echtzeiteinblicke-zu-gewinnen/34006/ https://ap-verlag.de/digitale-transformation-datenanalyse-in-echtzeit-auch-im-mittelstand/11813/ https://ap-verlag.de/trends-2019-datenvirtualisierung-ki-und-cloud/49541/ https://ap-verlag.de/big-data-nutzlos-oder-ungenutzt-verschiebung-von-kalten-zu-heissen-daten/49183/ Read the full article

Illustration: Absmeier, PdP Das rasante Datenwachstum der vergangenen Jahre hat vielerorts bereits zu einem Umdenken in den IT-Abteilugen geführt. Lag der Fokus in der Vergangenheit oft auf der Infrastruktur und den Anwendungen, so haben viele Unternehmen angesichts der sich auftürmenden Datenberge mehr und mehr den Schritt hin zu datenzentrischen IT-Umgebungen gewagt. Dass die Reise hier aber nicht endet, stellen vor allem die Unternehmen fest, welche Daten nahe an der Echtzeit verarbeiten müssen und mit Aufgaben wie Real-Time-Big-Data-Analytics konfrontiert sind. War bis dato die überwiegenden Masse an Daten »kalt«, so steigt mittlerweile der Anteil der »heißen« Daten, also Daten in Bewegung, stetig.   In vielen Organisationen findet bereits ein Umstieg von datenbasierten, zu ereignisfokussierten (Event-driven) Datenstrategien statt. Ein aktuelles Beispiel ist der chinesische E-Commerce-Gigant Alibaba, der unter anderem auf Data Streaming auf Basis von Apache Flink setzt.   »Datenstrategien auf Basis von Ereignisströmen beziehungsweise Events unterscheiden sich von monolithischen Datenspeicherstrategien deutlich«, erklärt Fabian Hueske, Mitgründer und Software Engineer bei data Artisans aus Berlin. »Auch wenn der Umstieg sicher nicht von heute auf morgen geschehen wird, so sehen wir dennoch langfristig ganz klar einen starken Trend in Richtung ereigniszentrischer Datenstrategien«. Welche Überlegungen müssen Data Engineers und Softwareentwickler anstellen, wenn sie ihre Datenarchitektur von einem datenzentrischen Ansatz hin zu Stream Processing, also moderner Datenstromverarbeitung verlagern?   »Wenn ein Unternehmen die Stream-Verarbeitung einsetzt, sind mehrere Aspekte zu berücksichtigen. Diese reichen von der technologischen Sichtweise bis hin zur Möglichkeit, die Leistungsfähigkeit der Stream-Verarbeitung zu nutzen, um neue Fähigkeiten und Denkweisen zu entwickeln. So gibt es vier wichtige Unterschiede zwischen den beiden Datenstrategien«, ergänzt Fabian Hueske.   Diese vier Punkte müssen Unternehmen, die einen solchen Übergang planen, beachten:   Die Art und Weise, wie sie mit Daten in Ihrem Unternehmen umgehen, wird sich verändern: In monolithischen Systemen ruhen die Daten, während sie bei der Verarbeitung von Ereignisströmen laufend in Bewegung sind um nutzbare Ergebnisse zu gewinnen. Die Prioritäten zwischen Daten und Aktionen ändern sich: Ihre Dateninfrastruktur wechselt von einer Fokussierung auf die Aufbewahrung von Daten hin zu einer Reaktion auf Ereignisströme. Die Stream-Verarbeitung ermöglicht es digitalen Unternehmen, sofort auf Ereignisse zu reagieren und Kunden, Partnern oder anderen Interessengruppen Reaktion, Erfahrung und Services in Echtzeit zu bieten. Der Fokus richtet sich dabei auf den kontinuierlichen Fluss der Stream-Verarbeitung und die Priorisierung des Handelns aufgrund von Ereignissen. Die Datenquelle wird angepasst: Ihre Datenstrategie wird sich letztendlich auf die Datenautorität in Ihrem Unternehmen auswirken. Von ihrem Datenspeicher in einer monolithischen Dateninfrastruktur verschiebt sich die Datenautorität hin zum Ereignisprotokoll als neuer ultimativer Punkt der Wahrheit. Dies kommt etwa zum Tragen, wenn Unternehmen versuchen, die Ursache für einen Systemausfall oder andere Probleme zu finden, die sich auf den Betrieb ihrer Infrastruktur auswirken könnten. Die Rolle der Dateninfrastruktur im Unternehmen ändert sich: Mit der Umstellung auf Stream Processing verändert sich die Wahrnehmung der IT- und Datensysteme innerhalb des Unternehmens wesentlich. Die Dateninfrastruktur wird zum zentralen Nervensystem, das es einem Unternehmen ermöglicht, auf Ereignisse in Echtzeit zu reagieren und Entscheidungen von unschätzbarem Wert zu treffen, genau zu dem Zeitpunkt, wenn die Daten generiert werden und somit, wenn sie am wertvollsten sind. Bisher wurden Daten, die in einer Datenbank oder monolithischen Infrastruktur ruhten, lediglich als Datenarchiv für das Unternehmen angesehen.   Event Stream Processing in die Unternehmenskultur zu integrieren wird nach Meinung von data Artisans für die Transformationsphase zu einem modernen, softwaregesteuerten, digitalen Unternehmen künftig unerlässlich sein. Die Transformation ist grundlegend und geht weit über technologische und technische Veränderungen hinaus.   »Die Veränderung erfolgt auf kultureller genauso wie auf technischer Ebene. IT- und Datenmanager, die eine digitale Transformation in ihrem Unternehmen vorantreiben, sollten Event Stream Processing als technische, organisatorische und kulturelle Grundlage ihrer Strategie anerkennen«, fasst Fabian Hueske von data Artisans abschließend zusammen.     https://ap-verlag.de/nur-wer-alle-daten-und-dokumente-im-griff-hat-kann-als-unternehmen-im-digitalen-wandel-bestehen/47683/ https://ap-verlag.de/eine-neue-aera-fuer-kundendaten-wird-it-sicherheit-das-neue-gruen/47762/ https://ap-verlag.de/datensilos-in-datenspringbrunnen-verwandeln/45780/ https://ap-verlag.de/cyberangreifer-nutzen-versteckte-tunnel-um-finanzdienstleister-auszuspionieren-und-daten-zu-stehlen/45003/ https://ap-verlag.de/dsgvo-konform-mit-datenzentrierter-strategie-dreigeteilter-ansatz-zur-erfuellung-der-dsgvo/44148/     Read the full article