Zeit bedeutet eine Abwägung von Skalierbarkeit und Konsistenz

Transkript

1 1

2 2

3 Dies ist ein Vortrag über Zeit in verteilten Anwendungen Wir betrachten die diskrete "Anwendungszeit" in der nebenläufige Aktivitäten auftreten Aktivitäten in einer hochgradig skalierbaren (verteilten) Anwendung sind aufwändig zeitlich zu synchronisieren Der Vortrag beschreibt die Effekte des Auftreten von unsynchronisierten Zeitpunkten und ihren Einfluss auf die Anwendungsarchitektur eines BigData Stacks Was bedeutet dies für OLTP Unternehmensanwendungen, wenn sie auf einen BigData Stack ausweichen müssen? Zeit bedeutet eine Abwägung von Skalierbarkeit und Konsistenz 3

4 Wir betrachten eine OLTP Unternehmensmiddleware mit typischer Architektur Daten werden aus heterogenen Quellen importiert, verarbeitet und persistiert Services stellen den Zugriff auf die integrierten (homogenisierten, verknüpften) Daten als Graph bereit Der Grund für meinen Einsatz? Die Einsatzszenarien überforderten die Leistungsfähigkeit der Architektur, der Algorithmen und der Datenbank um mehr als eine Größenordnung -> 3-4 stellige TB Daten sind geplant 4

5 Verlockend Logisch: das fachliche Modell ist ein Graph. Ist es nicht einfacher, dieses Modell in einer Graphdatenbank zu speichern? Titan ist eine Graphdatenbank, die mit echten Massendaten eingesetzt wird (Yahoo, Apple etc.) Cassandra als NoSQL Storage-Backend verspricht unlimitierte horizontale Skalierbarkeit Happy? Der Faktor Zeit (genauer die interne Zeit der Anwendung) wird zu einem wichtigen Faktor Dominiert die neue Architektur und beeinflusst fachliche und nicht-fachliche Eigenschaften der Anwendung 5

6 Viele Unternehmensanwendungen bieten Services, die mit den Berechnungen anderer Services synchronisiert werden müssen Zeitliche Aspekte der Nebenläufigkeit werden durchaus diskutiert, aber die Strategie ist ihre Vermeidung Fachliche und technische Locks werden nötig, wenn einerseits ACID aufrechterhalten werden soll und andererseits Services um globale Datenressourcen buhlen Zeitliche Granularität: Transaktion Auch in Java EE Anwendungen ist dies eine Quelle von harten Skalierungsproblemen Verteilte Anwendungen wie Big Data erfordern zwingend für eine lineare horizontale Skalierung eine echt parallele Verarbeitung mit möglichst wenig Synchronisation 6

7 Big Data Anwendungen sind in der Regel verteilte Anwendungen, die dem CAP Theorem unterliegen Zeit tritt dabei in mehreren Granularitäten auf Eventual Consistency der verwendeten verteilten Datenbank und Index über ihr Replikationsverhalten Die Zeitüberlappungen echt paralleler Verarbeitungen ohne Synchronisierung Eventual Consistency entsteht durch die Replikation von Daten über die verteilten Cassandra / EL Knoten Jeder Service Knoten ist mit nur einem DB Knoten verbunden. Die Replikation erzeugt ein Zeitfenster der Inkonsistenz aus Sicht von Import und Abfrage Das Zeitfenster der Inkonsistenz durch Eventual Consistent kann noch vermieden werden, in dem man die Replikation abwartet Das wirkt sich ausgesprochen negativ auf Antwortzeit UND Durchsatz aus 7

8 In einer echt parallelen Abarbeitung von Services sind diese nicht mehr atomar zu betrachten Die Abarbeitungssequenz definiert Abhängigkeiten zwischen parallel ausgeführten Services durch parallel stattfindende Datenänderungen Damit die Zeitfenster der Unsichtbarkeit parallel erzielter Ergebnisse klein sind, zerteilen wir die ehemals atomaren Services in Schritte Ohne Synchronisation ergeben sich bei unveränderten Algorithmen dauerhafte Inkonsistenzen die korrigiert werden müssen Die Algorithmen und die zugrundeliegenden nicht-fachlichen Anforderungen müssen kritisch hinterfragt werden Sie haben sicherlich den Faktor Zeit nicht berücksichtigt 8

9 Wir wenden SEDA mit Events großer Granularität ein (ganze Dokumente) Die Kritik des Erfinders ( an den hohen Kosten des Queuing und der Kontextwechsel greift hier nicht Jede Stage definiert einen Transaktionskontext Frühe Stages erlauben die schnelle Propagation von Ergebnissen durch die Replikation Hervorragende Steuerungsmöglichkeiten für Ressourcenzuordnung, Priorisierungen und allgemein Optimierung des Durchsatzes 9

10 Die Strategie ist: Daten so schnell wie möglich sichtbar machen, Integration der Daten unter verzeihlichen Fehlern nachfolgen lassen und Finalisierung des Import in regelmäßigen globalen Batch (Hadoop) Läufen Konsistenz von Analytikergebnissen wie Scoring für einen Datensatz ist meist bei Big Data irrelevant (Nachkommafehler) Erwarte umfangreiche Diskussionen mit der Fachabteilung 10

11 Hier sieht man gut die zeitliche Zerlegung von ursprünglich atomaren Import Services in verschiedene Stages und Batches Zusammengehalten wird dies durch ein Netzwerke von Queue-Brokern und Datenbank-Shards 11

12 12

13 13