Inhaltsverzeichnis
Die Batch-Verarbeitung kann langsam sein und bis zu mehreren Stunden dauern; diese Schicht ist jedoch äußerst zuverlässig, wenn es darum geht, große Datensätze zu verarbeiten und detaillierte Einblicke zu erhalten. Sobald ein Stapel verarbeitet ist, werden Stapelansichten erstellt und zur Speicherung und Abfrage an die Service-Schicht weitergeleitet. Die Serving-Schicht indiziert die vorberechneten Ansichten und stellt sie für Ad-hoc-Abfragen mit geringer Latenz zur Verfügung.
Zu diesem Zeitpunkt sind die Kapitel über die Serverschicht noch nicht veröffentlicht worden. Ich entwickle derzeit die Serving-Schicht für die Streaming-Daten meines Unternehmens. Ich arbeite daran, die Verschmelzung von Geschwindigkeits- und Batch-Ansichten in die Verantwortung der Serving-Schicht zu legen. So wie es in diesem Artikel beschrieben wird, bleibt viel Arbeit bei der Abfrage, um Datenquellen zusammenzuführen, und die Serving-Schicht ist nur eine Erweiterung der Batch-Schicht. Das Schöne an der Lambda-Architektur ist, dass die entsprechenden Ergebnisse in den Echtzeitansichten angezeigt werden, sobald die Daten durch die Batch-Schicht in die Serving-Schicht gelangt sind.
Das bedeutet, dass die einzigen Daten, die nicht in den Batch-Ansichten dargestellt werden, die Daten sind, die während der Vorberechnung eingegangen sind. Beliebige Funktionen, die auf beliebigen Daten in Echtzeit berechnet werden – müssen nur noch diese letzten paar Stunden an Daten kompensiert werden. In der Lambda-Architektur werden alle Daten in der Batch-Schicht gespeichert, und sie basiert auf verteilten Systemen, die eine Fehlertoleranz unterstützen.
Aufbau Einer Skalierbaren Verteilten Datenplattform Mit Lambda-architektur
Hadoop ist bekannt für seinen MapReduce-Mechanismus, seine Zuverlässigkeit und seine Batch-Verarbeitung. Spark hingegen ist bekannt für seine Fehlertoleranz, seine schnelle und echtzeitnahe Verarbeitung, aber es kann Szenarien geben, in denen sowohl Stapel- als auch Echtzeitdatenverarbeitung erforderlich sind. Stellen Sie sich vor, Sie bauen eine Datenpipeline auf, die Daten aus verschiedenen Quellen einliest. Hier hilft die Lambda-Architektur bei der Lösung von Problemen, die in solchen Szenarien auftreten. Fahren wir fort und erfahren wir, was die Lambda-Architektur ist, wie sie implementiert wird und welche Vorteile sie bietet. Das Netflix-Suro-Projekt verfügt über getrennte Verarbeitungspfade für Daten, folgt aber nicht strikt der Lambda-Architektur, da die Pfade unterschiedlichen Zwecken dienen können und nicht unbedingt dieselbe Art von Ansichten bereitstellen sollen.
- Und wenn sich die Anforderungen oder der Code ändern, können wir denselben Code und unveränderlichen Datensatz, der in Apache Kafka gespeichert ist, für die erneute Verarbeitung der Daten verwenden.
- Der heiße Pfad bezieht sich auf Streaming-Daten-Workloads und der kalte Pfad gilt für stapelverarbeitete Daten.
- Die letzte Schicht ist für die Zusammenführung der Ausgabe von Batch-Ansichten mit den Echtzeit-Ansichten der Geschwindigkeitsschicht zuständig, um Benutzeranfragen zu beantworten.
- Die Serving-Schicht fasst die Ergebnisse der Batch- und Echtzeitansichten in einem einzigen Datensatz zusammen.
Sobald Sie eine Datenverarbeitungspipeline mit dem Apache Beam SDK erstellt haben, können Sie eine Reihe von unterstützten Runnern für die Pipeline verwenden – Apache Spark, Apache Flink, Public Cloud-Implementierungen wie Google Data Flow. Die Lambda-Architektur legt die zu verwendenden Technologien nicht fest, sondern baut auf verteilten, skalierbaren Technologien auf, die einfach durch Hinzufügen weiterer Knoten erweitert werden können. Dies kann auf der Datenquelle, der Batch-Ebene, der Serving-Ebene oder der Geschwindigkeits-Ebene geschehen. Sowohl Hadoop als auch Spark sind die derzeit bevorzugten Technologien in der Big-Data-Branche.
Apache Kafka Zertifizierungsschulung
Open-Source-Echtzeit-Hadoop-Abfrageimplementierungen wie Cloudera Impala, Hortonworks Stinger, Dremel und Spark Shark können die Ansichten sofort abfragen. Hadoop kann große Datenmengen speichern und verarbeiten, und diese Tools können Daten schnell abfragen. Derzeit übertrifft Spark Shark die In-Memory-Funktionen und bietet eine größere Flexibilität für Funktionen des maschinellen Lernens.
Dies ist ein vereinfachter Ansatz, da er nur eine Codebasis erfordert, aber in Unternehmen mit historischen Daten in herkömmlichen Batch-Systemen müssen sie entscheiden, ob der Übergang zu einer reinen Streaming-Umgebung den Aufwand für den anfänglichen Plattformwechsel wert ist. Außerdem sind Nachrichtenbusse für extrem große Zeitfenster von Daten nicht so effizient wie Datenplattformen, die für größere Datensätze kosteneffizient sind. Das bedeutet, dass Sie nicht immer Ihre gesamte Datenhistorie in einer Kappa-Architektur speichern können. Durch technologische Innovationen wird diese Einschränkung jedoch aufgehoben, so dass viel größere Datenmengen in Nachrichtenbussen als On-Demand-Streams gespeichert werden können, so dass die Kappa-Architektur universeller eingesetzt werden kann.
