Kapitel 1. Entwicklung von Rechenleistung für Datenpipelines
Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com
Wenn du Anwendungen entwickelst, die auf dedizierter Hardware laufen, sei es ein Rechenzentrum vor Ort, ein Laptop oder ein Telefon, hast du eine vorher festgelegte Menge an Ressourcen. In der Cloud hingegen kannst du die virtuelle Hardware so konfigurieren, dass sie den Anforderungen der Arbeitslast am besten gerecht wird, und musst nicht mit einer vordefinierten Ressourcenmenge arbeiten.
Bei der Entwicklung von Rechenressourcen für Datenpipelines geht es darum, zu bestimmen, welche Ressourcen du für einen leistungsfähigen und zuverlässigen Betrieb brauchst. Neben CPU, Arbeitsspeicher, Festplattenspeicher und Bandbreite gibt es beim Cloud Computing noch eine weitere Achse von Kaufoptionen, die dir die Möglichkeit geben, einen Kompromiss zwischen Kosten und Leistung zu finden.
Dies kann ein entmutigendes Thema sein, denn es gibt Millionen möglicher Kombinationen von Recheninstanztypen, Größen und Kaufplänen. In diesem Kapitel zeige ich dir, wie du dich in diesem Bereich zurechtfindest, indem du die Optionen nach den Leistungsmerkmalen der Datenpipeline auswählst und deine Auswahl mit Leistungsbenchmarks verfeinerst.
Als Erstes solltest du bedenken, dass Cloud Computing ein gemeinsam genutztes, verteiltes System ist. Daher kann es vorkommen, dass die Kapazität nicht ausreicht, um deine Ressourcenanforderungen zu erfüllen. Zu Beginn dieses Kapitels werde ich verschiedene Szenarien aufzeigen, in denen es zu Ressourcenengpässen kommen kann, denn letztendlich ist es egal, wie gut du deinen Cluster konzipiert hast, wenn die benötigten Ressourcen nicht verfügbar sind.
Als Nächstes erhältst du Ratschläge zu verschiedenen Kaufoptionen für Cloud Compute und wie du diese Optionen am besten für die Gestaltung von Datenpipelines nutzen kannst.
Ein weiterer Schritt, um die richtige Rechenkonfiguration zu finden, ist die Berücksichtigung der geschäftlichen und architektonischen Anforderungen an den Designraum. Zur Veranschaulichung dieses Prozesses gehe ich durch ein Szenario, das mit einem Geschäftsproblem beginnt und dich durch die Identifizierung relevanter Compute-Optionen auf einer hohen Ebene führt.
Nachdem du die Millionen von Rechenoptionen auf eine relevante Teilmenge reduziert hast, erfährst du im letzten Abschnitt des Kapitels, wie du die Leistung verschiedener Clusterkonfigurationen bewerten kannst. Dies ist ein spannender Teil des Kapitels, in dem du beginnst, die vielfältigen Abhängigkeiten zu verstehen, die bei der Optimierung der Rechenleistung eine Rolle spielen, einschließlich der Tatsache, dass mehr Clusterknoten nicht unbedingt eine bessere Leistung bedeuten. Am Ende des Kapitels bringe ich die Kaufoptionen wieder ins Spiel und zeige dir, wie du einen Kompromiss zwischen Leistung und Kosten finden kannst.
Auch wenn du in einer Umgebung arbeitest, in der du nicht die Infrastruktur besitzt, wirst du in diesem Kapitel wichtige Einblicke in robustes Pipeline-Design, Kompromisse zwischen Kosten und Leistung und sogar ein wenig Architektur erhalten, was, ehrlich gesagt, meiner Meinung nach für gutes Pipeline-Design unerlässlich ist.
Die Verfügbarkeit von Cloud Compute verstehen
Die Cloud bietet zwar erhebliche Kapazitäten, aber bei der Verfügbarkeit der Rechenressourcen gibt es noch mehr zu beachten. Ich versuche immer zu bedenken, dass die Cloud-Ressourcen durch physische Hardware unterstützt werden. Dabei wird leicht übersehen, dass die Serverfarmen und Netzwerke, die den virtuellen Rechner unterstützen, genauso anfällig für Kapazitäts- und Zuverlässigkeitsüberlegungen sind, wie du es bei deinem eigenen System vor Ort tun würdest. Auch bei der Art und Weise, wie Cloud-Service-Provider (CSPs) Rechenressourcen für ihre Kunden bereitstellen, gibt es einiges zu beachten.
Ausfälle
Da immer mehr Datenverarbeitung in die Cloud verlagert wird, können die Auswirkungen von CSP-Ausfällen weitreichende Folgen haben, z. B. für Behörden-Websites, Essenslieferdienste und sogar für die Zeitplanung von Staubsaugerrobotern.
CSPs bieten Service Level Agreements (SLAs) an, die einen bestimmten Prozentsatz an Betriebszeit garantieren, wie du an der Google Cloud und Amazon EC2 sehen kannst. Wenn diese SLAs nicht eingehalten werden, kannst du dir einen Teil der Ausgaben für Rechenleistung erstatten lassen, die davon betroffen waren.
Auf den ersten Blick mag das gut klingen: Wenn du wegen eines Ausfalls keine Ressourcen einsetzen kannst, musst du auch nicht für sie bezahlen. Aber bedenke die finanziellen Auswirkungen, wenn dein Dienst wegen eines Ausfalls nicht funktioniert. Aus betriebswirtschaftlicher Sicht solltest du durch Serviceunterbrechungen deutlich mehr Geld verlieren als durch die Kosten für die Bereitstellung von Cloud-Ressourcen. In einem Bericht von Lloyd's of London aus dem Jahr 2018 wird geschätzt, dass ein Vorfall, der einen der drei größten CSPs für drei bis sechs Tage außer Gefecht setzt, zu Umsatzeinbußen von bis zu 15 Milliarden US-Dollar führen würde. Da sich die Zahl der Unternehmen, die in der Cloud arbeiten, seit dieser Veröffentlichung vergrößert hat, wären die Einnahmeverluste bei einem ähnlichen Vorfall heute noch teurer.
Eine Möglichkeit, die Auswirkungen von Ausfällen einzudämmen, besteht darin, die Rechenressourcen an verschiedenen Orten einzusetzen. Wenn es zu Ausfällen kommt, können sie eine Teilmenge der Regionen und Availability Zones (AZs) im Netzwerk eines CSP betreffen, wie es bei diesem Ausfall von Amazon Web Services (AWS) im Jahr 2021 der Fall war. Die Option, Pipelines in mehreren Availability Zones zu betreiben, kann dazu beitragen, die Gefahr von Ausfällen zu verringern.
Denk daran, dass dies auch mit Kosten verbunden ist: Die Unterstützung von Multi-AZ-Einsätzen erfordert zusätzliche Infrastruktur. Außerdem können die Netzwerkkosten eine Rolle spielen und die Leistung der Datenpipeline beeinträchtigt werden, wenn sich die Arbeitslasten über mehrere AZs erstrecken.
Hinweis
Failover-Systeme bieten, wie der Name schon sagt, eine Absicherung im Falle eines Ausfalls des Primärsystems. Sie können auf unterschiedliche Weise implementiert werden, je nachdem, wie dringend du das System online halten musst. Ein Hot Failover ist ein laufendes, redundantes System, auf das schnell umgeschaltet werden kann, wobei ein redundantes System immer online und einsatzbereit sein muss.
Von hier aus gibt es verschiedene Stufen der Failover-Bereitschaft bis hin zu einem Cold-Failover-System, bei dem die Ressourcen im Falle eines Ausfalls online geschaltet werden. In diesem Fall tauschst du die Systemverfügbarkeit gegen die Kosten, da du keine Kosten für den Betrieb eines redundanten Systems hast, aber du opferst die Systemverfügbarkeit, während das kalte System online geht.
Failover-Systeme können zwar eine zusätzliche Absicherung im Falle eines Ausfalls bieten, aber diese Systeme können sehr kostspielig sein. Bei einer Failover-Strategie, bei der deine Pipeline in einer anderen Region läuft, müssen die Daten über mehrere Regionen hinweg repliziert werden, was die Kosten für die Speicherung und den Zugriff auf deine Daten erheblich erhöht.
Kapazitätsgrenzen
Was bei der Arbeit mit Cloud-Diensten oft übersehen wird, ist, dass Ressourcen gemeinsam genutzt werden. Wenn du keine spezielle Hardware kaufst, teilst du die Rechenleistung mit anderen Kunden. Das heißt, wenn du einen Cluster bereitstellst, forderst du diese Ressourcen an. Das ist keine Garantie für die Verfügbarkeit.
Wenn du eine Compute Instance oder einen Cluster startest, stellst du eine Anfrage für bestimmte Instanztypen und -größen. Ob diese Anfrage erfüllt werden kann, hängt von der verfügbaren Kapazität in der von dir ausgewählten Region und AZ ab.
Wenn alle Ressourcen aufgebraucht sind, wenn du einen Batch-Job starten oder einer Streaming-Pipeline mehr Kapazität hinzufügen musst, wird deine Ressourcenanforderung nicht erfüllt. Ich habe dieses Verhalten beobachtet, wenn ich Rechenkapazitäten zu beliebten Zeiten für die Ausführung von Workloads anforderte, z. B. in den Stunden nach Geschäftsschluss in der östlichen Zeitzone der USA. Auch wenn du dedizierte Rechenressourcen reserviert hast, kannst du dieses Problem selbst verursachen, wenn du versuchst, mehr Kapazität bereitzustellen, als du gekauft hast.
Die Segmentierung kann dir dabei helfen, Kapazitätsauswirkungen abzumildern, indem du die Pipeline-Workloads in zeitkritische und solche unterteilst, die nach Verfügbarkeit von Ressourcen ausgeführt werden können. Mehr dazu erfährst du in "Architektonische Anforderungen".
Kontolimits
Je nach Abonnementstufe kann die verfügbare Kapazität begrenzt sein. Du kannst zum Beispiel nur auf eine begrenzte Menge an CPU-Kapazität zugreifen. Anfragen, die diese Menge überschreiten, werden nicht erfüllt und können zu einer Fehlermeldung führen. Wenn du diese Kontobeschränkungen im Voraus kennst, kannst du die Situation möglicherweise entschärfen, indem du dein Abonnement aufstockst, aber bedenke, dass du möglicherweise nicht sofort Zugang zu zusätzlichen Ressourcen hast. Je nachdem, welche Art von Erhöhung du beantragst, musst du möglicherweise auf die Genehmigung deines ZDA warten.
Infrastruktur
Ob Compute verfügbar ist, hängt auch davon ab, wie du die Umgebung einrichtest, in der du Pipelines ausführst. Die Verfügbarkeit eines bestimmten Instance-Typs und einer bestimmten Größe variiert je nach Rechenregion und AZ, wobei einige Optionen in verschiedenen Regionen nicht verfügbar sind. Wenn du einen Service wie AWS Elastic MapReduce (EMR) nutzt, kann es Einschränkungen bei den unterstützten Instanztypen geben.
Hinweis
Ich habe bereits einige Strategien erwähnt, um die Auswirkungen von Verfügbarkeitsproblemen in der Cloud abzuschwächen, darunter Failover-Systeme, Multi-AZ-Betrieb und Job-Segmentierung. Grundsätzlich müssen deine Pipelines in einer Umgebung arbeiten, in der diese Situationen auftreten können. Gute Designtechniken wie Idempotenz, Strategien zur Datendeduplizierung und Wiederholungsmechanismen tragen dazu bei, die Auswirkungen unerwarteter Ressourcenengpässe auf die Betriebszeit der Pipelines und die Datenqualität zu begrenzen. Diese Themen werden in Kapitel 4 behandelt.
Nutzung verschiedener Einkaufsoptionen bei der Planung von Pipelines
Es gibt drei Optionen für den Kauf von Rechenleistung: On Demand, Interruptible/Spot und vertragliche Rabatte wie Reserved Instances und Committed Use. Tabelle 1-1 zeigt die Aufschlüsselung der verschiedenen Preise für eine fiktive Instanz INST3, basierend auf einem AWS-Preismodell.
| Auf Anfrage | Reserviert | Punktuelles Minimum | Spot Maximum |
|---|---|---|---|
| $0.4 | $0.2 | $0.1 | $0.2 |
Hinweis
In diesem Buch konzentriere ich mich auf stundenbasierte Kaufoptionen für Instanzen, bei denen die zugrunde liegenden Recheninstanzen eine feste Menge an Ressourcen bereitstellen und nach der Anzahl der genutzten Stunden abgerechnet werden.
Abrufbar
Wie du in Tabelle 1-1 sehen kannst, ist der On-Demand-Tarif die teuerste Option, weil du eine Instanz anfordern kannst, wann immer du sie brauchst, und sie für die Dauer deines Arbeitsaufkommens behältst. Es ist wichtig, sich daran zu erinnern, dass du jederzeit Rechenleistung anfordern kannst, aber es gibt keine Garantie, dass die angeforderte Leistung auch verfügbar ist, wie du weiter oben in diesem Kapitel gesehen hast.
On-Demand ist eine gute Option, wenn du versuchst, ein Gefühl für deinen Compute-Bedarf zu bekommen und keine Service-Unterbrechungen tolerieren kannst oder wenn deine Arbeitslasten kurz, selten oder unvorhersehbar sind. Von den verfügbaren Kaufoptionen ist On-Demand am einfachsten zu verwalten, weil du keine Reservierungen auswerten oder den Verlust von Spot-Instances verkraften musst.
Spot/unterbrechbar
Spot-Instanzen, auch bekannt als unterbrechbare Instanzen, sind überschüssige Rechenleistung, die ein CSP zur Verfügung hat. Diese Instanzen bieten einen erheblichen Preisnachlass gegenüber der Nachfrage, wie der "Spot Minimum"-Preis in Tabelle 1-1 zeigt, aber ihr Preis und ihre Verfügbarkeit sind sehr volatil. Wenn die Nachfrage zunimmt, steigen die Spotpreise (siehe "Spot Maximum" in Tabelle 1-1) und die Verfügbarkeit sinkt. An diesem Punkt ruft ein CSP die ausstehenden Spot-Instanzen ab und warnt die Spot-Kunden, dass die Instanz bald ausläuft. Spot-Instanzen sind eine gute Wahl für nicht zeitkritische Arbeitslasten mit niedriger Priorität und können auch zur Bereitstellung zusätzlicher Clusterkapazität verwendet werden.
Spot-Instances werden oft mit anderen Kaufoptionen kombiniert, um die Leistung zu verbessern und die Kosten je nach Systemanforderungen zu senken. Wenn du eine Hochleistungspipeline hast, bei der Unterbrechungen nicht toleriert werden können, kannst du eine Basis von On-Demand- oder vertraglicher Bereitstellung verwenden und diese mit Spot-Instances ergänzen, um die Leistung zu verbessern.
Einige Dienste können die Unterbrechung der Beendigung von Spot-Instanzen für dich verwalten. Wenn du Spot-Instances als Task-Knoten in deinem EMR-Cluster verwendest, kannst du Einstellungen konfigurieren, um zu verhindern, dass ein Auftrag ausfällt, wenn die unterbrechbaren Instances beendet werden. AWS bietet auch Instance-Flotten an, bei denen eine Mischung aus On-Demand- und Spot-Instances konfiguriert wird, um eine Zielkapazität zu erreichen. Dadurch profitierst du von kostengünstigeren unterbrechbaren Instanzen, ohne dass du sie selbst konfigurieren musst. Wenn du einen solchen Ansatz wählst, bei dem ein CSP die Auswahl der Instanzen verwaltet, solltest du unbedingt einige Testläufe durchführen, um zu überprüfen, ob die für dich getroffenen Entscheidungen deinen Anforderungen entsprechen.
Es ist möglich, dass die Unterbrechung eines Pipeline-Auftrags ein vernünftiger Kompromiss ist. Wenn die Kosten einen höheren Stellenwert haben als die Leistung und die Datenverfügbarkeit, können Spot-Instanzen eine gute Wahl für deine primäre Resourcing-Strategie sein. Wie du mit unterbrochenen Pipeline-Aufträgen umgehst, erfährst du in Kapitel 4.
Andere Möglichkeiten, Spot-Instanzen zu nutzen, sind Entwicklung, Tests und kurze Wartungsarbeiten.
Vertragliche Rabatte
Es gibt eine Reihe von Optionen, bei denen du einen Rabatt erhältst, wenn du dich verpflichtest, Rechenleistung über einen bestimmten Zeitraum zu kaufen. AWS reservierte Instanzen, Sparpläne und Google-Rabatte für die verbindliche Nutzung sind einige Angebote, die in diese Kategorie fallen. Abgesehen von diesen Optionen können Unternehmen auch private Preisvereinbarungen direkt mit CSPs aushandeln.
Vertragliche Rabatte können eine gute Option sein, wenn beides zutrifft: Du hast einen vorhersehbaren Bedarf an Rechenleistung und die Art und Weise, wie du die Rechenleistung nutzt, entspricht der Art und Weise, wie der Rabatt angewendet wird. Es ist sehr wichtig zu verstehen, wie die Rabatte angewendet werden. Im nächsten Abschnitt erzähle ich dir, wie es war, als du diesen Aspekt des Kaufs von reservierten Instanzen falsch verstanden hast, was zu unerwarteten Kosten führte. Solange du dir darüber im Klaren bist, kannst du im Vergleich zu On-Demand erheblich sparen, wie in Tabelle 1-1 gezeigt. Pipelines, die rund um die Uhr laufen und eine feste Basisauslastung haben, sind gute Kandidaten für diese Option.
In der Regel gilt: Je starrer die Reservierung ist, desto höher ist der Rabatt. Wenn du dich zum Beispiel verpflichtest, einen bestimmten Instance-Typ in einem einzigen AZ zu reservieren, kannst du einen besseren Rabatt bekommen als wenn du mehr Flexibilität brauchst, z. B. mehrere Instance-Typen.
Bei reservierten Vertragsrabatten ist zu beachten, dass die Kosten für die Instanzstunden in der Vergangenheit gesunken sind. Wenn die Preise unter den Preis fallen, den du mit deinem reservierten Instance-Kauf bezahlt hast, bekommst du die Differenz nicht erstattet. Wenn du dich an die Mindestlaufzeit hältst, kannst du in diesem Fall nicht zu viel bezahlen.
Der Bereich der Vertragsrabatte entwickelt sich ständig weiter. Damit du herausfinden kannst, ob dies eine gute Option ist, solltest du dir die folgenden Fragen stellen:
- Was genau reserviere ich?
- Abgesehen von dem Zeitraum, den du reservieren musst, um dich für den Rabatt zu qualifizieren, solltest du dir darüber im Klaren sein, wozu du dich genau verpflichtest. Reservierst du einen bestimmten Computertyp und/oder eine bestimmte Größe, eine bestimmte Anzahl von CPU-Kernen oder eine bestimmte Menge an Arbeitsspeicher? Kannst du diese Optionen im Vertrag ändern oder sind sie festgelegt?
- Ist die Verfügbarkeit garantiert?
- Reservierst du die Verfügbarkeit? Entgegen dem, was der Name vermuten lässt, bedeutet "Reservierung" bei einigen CSPs nicht, dass das, was du reservierst, auch verfügbar ist. Der Kauf einer reservierten AWS-Instanz garantiert zum Beispiel keine Verfügbarkeit, es sei denn, du hast auch eine Kapazitätsreservierung, indem du eine einzelne AZ für deinen reservierten Instanzkauf angibst.
- Was ist, wenn ich meine Reservierung nicht mehr benötige?
- Wenn sich der Bedarf an Ressourcen ändert, kann es sein, dass du ungenutzte Reservierungen hast. In manchen Fällen kannst du ungenutzte Reservierungen verkaufen, um die Kosten wieder hereinzuholen, z. B. auf dem Amazon EC2-Marktplatz. Außerdem kannst du bei einigen Verträgen auf eine andere Instanzkonfiguration umsteigen.
- Wie wird der Rabatt angewendet?
- Du denkst vielleicht, dass die Reservierung einer bestimmten Menge an Kapazität bedeutet, dass der Rabatt immer dann angewendet wird, wenn du Ressourcen nutzt, die der reservierten Menge entsprechen. Das ist aber nicht unbedingt der Fall.
Vertragsrabatte in der realen Welt: Ein abschreckendes Beispiel
Um zu verdeutlichen, wie wichtig es ist zu verstehen, wie vertragliche Rabatte angewendet werden, betrachten wir eine Pipeline mit zwei Arbeitern, ARBEITER1 und ARBEITER2, die einen Instanztyp INST3 verwenden. Im vergangenen Jahr hat die Pipeline konstant 10 Instanzstunden pro Monat verbraucht. Es wird erwartet, dass die Pipeline in den Folgejahren genauso viele oder mehr Daten verarbeiten wird, sodass eine Kostenreduzierung durch den Kauf einer reservierten Instanz attraktiv erscheint. Auf der Grundlage der bisherigen Nutzung verpflichtest du dich, 10 Instanzstunden pro Monat zu kaufen, also insgesamt 120 Instanzstunden INST3 über den Zeitraum von einem Jahr.
Der Kauf der reservierten Instanz soll im Januar beginnen. In den ersten Monaten des Jahres werden die Instanzstunden wie in Abbildung 1-1 dargestellt genutzt.
Abbildung 1-1. Genutzte INST3-Instanzstunden nach Monat
Im Januar und März verbrauchte jeder Arbeiter fünf Instanzstunden, also mehr als die 10, die du aufgrund der bisherigen Nutzung erwartet hast. Im Februar hattest du etwas mehr Daten zu verarbeiten als sonst, sodass jeder Knotenpunkt acht Instanzstunden verbraucht hat, also insgesamt 16 Instanzstunden. Du bist nicht allzu besorgt, denn du weißt, dass du für die Überschreitung der reservierten Kapazität einen On-Demand-Preis zahlen musst. Daher erwartest du, dass die vierteljährliche Cloud-Rechnung in etwa so aussehen wird wie in Tabelle 1-2.
| Stunden | Kosten pro Stunde | Gesamt | |
|---|---|---|---|
| INST3-reserviert | 30 | 0.2 | $6.00 |
| INST3-auf Anfrage | 6 | 0.4 | $2.40 |
| Vierteljährlich insgesamt: | $8.40 |
Stattdessen erhältst du die in Tabelle 1-3 dargestellte Rechnung.
| Stunden | Kosten pro Stunde | Gesamt | |
|---|---|---|---|
| INST3-reserviert | 30 | 0.2 | $6.00 |
| INST3-auf Anfrage | 18 | 0.4 | $7.20 |
| Vierteljährlich insgesamt: | $13.20 |
Was ist passiert? Du hast die reservierte Anzahl an Instanzstunden für 30 von 36 Stunden genutzt. Warum wird dir also mehr als die Hälfte der Gesamtzeit zum On-Demand-Preis berechnet? Und warum werden dir 48 Stunden in Rechnung gestellt?1
Leider handelt es sich dabei nicht um einen Abrechnungsfehler. Die Reservierung bezieht sich auf eine einzige Instanz, sodass der Rabatt jeweils nur auf eine INST3-Instanz angewendet wird. Die ausgefüllten Teile von Abbildung 1-2 zeigen die Anwendung der reservierten Instanzstunden. Nur ARBEITER1 hat den Rabatt erhalten. Außerdem bedeutet die Reservierung von Instanzkapazitäten, dass du für die reservierten Instanzstunden bezahlst, auch wenn sie ungenutzt sind, weshalb dir 30 Stunden über drei Monate berechnet wurden.
Abbildung 1-2. Reservierte Instanzkapazität, die von ARBEITER1 genutzt wird
Um den Preis zu erhalten, von dem du ausgegangen bist, hättest du zwei reservierte Instanzen kaufen müssen und dich zu 60 Stunden pro Jahr für jede verpflichten müssen.
Anforderungserhebung für Compute Design
Wenn wir als Ingenieure über Ressourcen nachdenken, neigen wir dazu, uns darauf zu konzentrieren, was wir für eine bestimmte Aufgabe brauchen, z. B. die Durchführung einer Reihe von Datentransformationen. Das ist sicherlich ein Teil der Gleichung, aber wenn wir das Gesamtbild auf Systemebene verstehen, wird deutlich, wo wir Kompromisse eingehen können, um alle Möglichkeiten der Cloud auszuschöpfen.
Geschäftsanforderungen
Wenn du die Geschäftsprobleme verstehst, die gelöst werden müssen, kannst du die Anforderungen an die Pipeline besser einschätzen. Dazu gehören die Identifizierung der Datenquellen, die Festlegung des Zeitplans für die Datenaufnahme und die Angabe der gewünschten Ergebnisdaten. Dies ist der richtige Zeitpunkt, um ein Gefühl für die Anforderungen an die Betriebszeit des Systems zu bekommen, damit du feststellen kannst, ob du ein Failover-System einplanen musst. Zu den geschäftlichen Anforderungen können auch Einschränkungen gehören, welche Regionen du nutzen kannst und welche Cloud-Dienste und Software du verwenden darfst.
Auch die Geschwindigkeit, mit der das Ingestion abgeschlossen werden muss, kann zu diesem Zeitpunkt festgelegt werden. Dazu gehört auch zu verstehen, wie die Leistung gegen die Cloud-Ausgaben abgewogen wird: Ist die Anwendung etwas, das in Echtzeit und ohne Ausfallzeiten betrieben werden muss, oder ist die Ingestion-Laufzeit nicht so wichtig, so dass du Leistung und Verfügbarkeit gegen geringere Kosten eintauschen kannst?
Wenn du die Datenquellen und Ergebnisdaten definiert hast, bekommst du ein Gefühl für die Komplexität des Pipelinebetriebs. Die drei Vs von Big Data - Vielfalt, Geschwindigkeit und Volumen - helfen dir dabei, die Pipeline-Architektur und den Bedarf an Ressourcen zu bestimmen. Wenn du z. B. mit Datenquellen arbeitest, deren Datenvolumen sich im Laufe der Zeit stark verändert, solltest du überlegen, wie du damit umgehst, indem du entweder die maximal benötigte Rechenleistung bereitstellst oder eine Skalierungsstrategie anwendest, um die Verschwendung zu reduzieren, wenn die Datenlast gering ist.
Architektonische Anforderungen
Die architektonischen Anforderungen übersetzen die geschäftlichen Anforderungen in technische Spezifikationen und vermitteln ein Bild davon, was gebaut werden muss, um die geschäftlichen Anforderungen zu erfüllen. Dazu können Leistungsspezifikationen, Anforderungen an die Betriebszeit und die Wahl der Datenverarbeitungsmaschine gehören.
Du solltest das Rechendesign und die Datenverarbeitungs-Engines zusammen betrachten, da die Konfigurationsmöglichkeiten zwischen beiden eng miteinander verbunden sind. Außerdem solltest du dir Gedanken über die Umgebung machen, in der die Pipeline laufen soll. In einer Kubernetes-Umgebung, in der ein einziger Cluster mehrere verschiedene Prozesse bedient, solltest du sicherstellen, dass du die richtigen Namensräume einrichtest, um Konkurrenzdenken zu vermeiden. Dies ist wichtig, um sicherzustellen, dass die Pipeline über ausreichend Ressourcen verfügt und andere Teile des Systems nicht beeinträchtigt werden.
Anhand der architektonischen Anforderungen kannst du Möglichkeiten erkennen, den Betrieb der Pipeline in leistungsrelevante und weniger leistungsrelevante Prozesse aufzuteilen. Dies bietet die Möglichkeit, einige kostensparende Strategien anzuwenden.
Leistungsstarke Workloads können einen erheblichen Prozentsatz an freiem Speicher und CPU beanspruchen. Diese ungenutzte Kapazität ist zwar wichtig für die Leistung, aber auch eine Verschwendung: Du zahlst für Ressourcen, die du nicht nutzt. Eine Möglichkeit, diese ungenutzten Ressourcen ohne Leistungseinbußen zu nutzen, ist der Einsatz von Prioritätsplänen. Prozesse mit niedriger Priorität können im Hintergrund laufen, um freie Zyklen zu nutzen, und können reduziert oder ausgesetzt werden, wenn die Prozesse mit höherer Priorität anlaufen. Uber hat diese Strategie genutzt, um die Auslastung seiner Big-Data-Plattform zu verbessern.
Die Workload-Segmentierung kann dir auch dabei helfen, die Laufzeit der Pipeline zu reduzieren, indem du einige Aufgaben außerhalb der Geschäftszeiten oder im Hintergrund ausführst. Wenn zum Beispiel die Kosten für die Deduplizierung von Daten während der Pipeline-Ausführung zu hoch sind, kannst du die Deduplizierung nach dem Ingestion in Betracht ziehen. Uber nutzte diesen Ansatz, um Parquet-Dateien im Hintergrund mit einem höheren Komprimierungsgrad neu zu komprimieren und so von den niedrigeren Kosten für die Speicherung zu profitieren, ohne die Pipeline-Laufzeit zu beeinträchtigen.
Offline-Prozesse sind auch eine Möglichkeit, kostengünstige unterbrechbare Instanzen zu nutzen. Wenn du eine Pipeline hast, die im Laufe des Tages viele kleine Dateien erzeugt, kannst du einen Verdichtungsjob offline laufen lassen, um die Auswirkungen zu mildern. Auf das Problem der kleinen Dateien und die Strategien zur Schadensbegrenzung gehe ich in Kapitel 3 ein.
Beispiel für das Sammeln von Anforderungen: HoD Batch Ingest
Um auf das Beispiel aus dem Vorwort zurückzukommen: Das Herons on Demand (HoD)-Team arbeitet mit einem Universitätslabor zusammen, um es bei der Sammlung und Analyse von Zugvogeldaten durch Umfragen zu unterstützen. Man hofft, dass durch die Kombination der Vogelsichtungsdaten von HoD-Nutzern mit den von den Forschern gesammelten Umfragedaten neue Zuggebiete identifiziert werden können. Die Pipeline zur Verarbeitung dieser Daten ist in Abbildung 1-3 dargestellt.
Abbildung 1-3. HoD-Batch-Architektur: Umfrage-Pipeline
Die Feldumfragen werden mit einer App gesammelt, die die Umfrageergebnisse als komprimiertes JSON in die Cloud Speicherung hochlädt. Die Pipeline fügt die Umfragedaten mit den von HoD gesammelten sozialen Medien zusammen und speichert das Ergebnis im Parquet-Format für die Analyse durch die Forscher der Universität.
Betrachten wir zunächst einige der geschäftlichen Anforderungen an die Umfragedaten-Pipeline. Die von dieser Pipeline erzeugten Daten werden von den Forschern für Förderanträge und Dissertationen verwendet. Die Forscher möchten die Daten so schnell wie möglich erhalten, vor allem kurz vor diesen wichtigen Terminen, aber sie müssen auch mit den Fördergeldern, die für Cloud Computing verwendet werden sollen, sorgsam umgehen. Das klingt nach einem möglichen Kompromiss zwischen Kosten und Leistung.
Die Forscher sind damit einverstanden, alle zwei Wochen oder zweiwöchentlich Datenpakete zu erhalten. Angesichts des seltenen Ingest-Zyklus schlägt das HoD-Team vor, etwaige Pipeline-Fehler durch Überwachung und Wiederholung am selben Tag zu beheben, an dem der Fehler auftrat, anstatt zusätzliches Geld für den Aufbau einer ausgefeilteren Lösung auszugeben, die solche Probleme in Echtzeit erkennen und entschärfen kann.
Das HoD-Team erhält von den Forschern Zugang zu einem bestehenden Datensatz mit Umfragen aus dem Vorjahr. Um ein Gefühl für die Größe des Umfragedatensatzes zu bekommen, stellt es die Datengröße in zweiwöchigen Abständen dar, wie in Abbildung 1-4 gezeigt.
Abbildung 1-4. Daten der Vogelumfrage alle zwei Wochen
Vom architektonischen Standpunkt aus betrachtet, betreibt das Team bereits einige Pipelines mit Spark auf EMR. Sie sind mit diesem System bereits vertraut, und die große Datenmenge und die Anzahl der Verbesserungen scheinen sich gut für die In-Memory-Verarbeitung zu eignen, also beschließen sie, die Umfrage-Pipeline mit denselben Tools durchzuführen.
Angesichts dieses Szenarios sollten wir uns ansehen, was wir über die Umfrage-Pipeline wissen.
Daten
Die Umfragedaten sind statisch und haben ein Volumen von einigen TB an komprimierten JSON-Daten in der Cloud Speicherung. Die Speicherung in der Cloud bietet eine Bandbreite von Hunderten von Gbit/s, die wir angesichts der erwarteten Datenmenge pro Stapel deutlich unterschreiten würden.
Die andere Datenquelle ist die HoD-Datenbank für soziale Medien, die sowohl Inhalte für die HoD-Website als auch Daten für die Pipeline bereitstellt. Da diese Ressource mehrfach beansprucht wird, sind Konflikte und Leistungseinbußen sowohl für die Website als auch für die Pipeline ein Problem. Möglicherweise müssen die Datenbankressourcen aufgestockt werden, um beide Zwecke zu erfüllen. Da die Datenpipeline zweiwöchentlich läuft, besteht eine weitere Möglichkeit darin, einen Schnappschuss der Datenbank kurz vor der Aufnahme zu erstellen, der von der Pipeline genutzt werden kann.
In jedem Fall solltest du sicherstellen, dass Wiederholungsversuche beim Zugriff auf die Daten eingebaut sind, egal ob sie von einer Cloud Speicherung oder der HoD Datenbank stammen.
Leistung
Die Anforderungen enthielten keine spezifischen Leistungsangaben, sondern nur den Wunsch, die Daten schnell und ohne große Kosten zu erhalten. Im Abschnitt "Benchmarking" werden wir darauf zurückkommen, um ein Gefühl für den Kompromiss zwischen Leistung und Kosten zu bekommen.
Als Ausgangspunkt empfiehlt die Spark-Dokumentation, maximal 75 % des verfügbaren Speichers für Spark zuzuweisen. Je nach Bedarf an Pipeline-Ressourcen und gewünschter Ingest-Geschwindigkeit musst du eventuell einen niedrigeren Prozentsatz anstreben. Das Gleiche gilt für die CPU-, Festplatten- und Netzwerkauslastung. Du wirst mit der Zeit ein besseres Gefühl dafür bekommen, wenn du die Leistung der Pipeline überwachst.
Optionen für den Einkauf
Für den Anfang ist ein On-Demand-Kaufmodell sinnvoll, da es eine feste Anzahl von Ressourcen bietet und die Pipeline zuverlässig zum Laufen bringt. Es ist noch zu früh, um vertragliche Rabatte, wie z. B. reservierte Instanzen, in Betracht zu ziehen, da du nicht weißt, wie die Auslastung langfristig aussieht.
Mit der Möglichkeit, Kosten gegen Leistung zu tauschen, können Spot-Instances in den Mix aufgenommen werden, sobald du ein solides Gefühl für den Bedarf an Ressourcen hast. Es gibt keine bestimmte Tageszeit oder einen bestimmten Wochentag, an dem die Pipeline laufen muss. Das gibt dir zusätzlichen Spielraum bei der Planung, damit du den Auftrag dann ausführen kannst, wenn Spot-Instances verfügbar sind oder die On-Demand-Preise niedriger sind.
Benchmarking
Jetzt, wo du ein Gefühl für die relevanten Rechenoptionen bekommen hast, ist es an der Zeit, sie auf die Probe zu stellen. Beim Benchmarking werden das Clusterdesign und die Compute-Optionen anhand eines Beispiel-Workloads bewertet, um die optimale Konfiguration zu ermitteln.
Was mich zu Beginn meiner Karriere wirklich frustriert hat, war, wie wenig Informationen ich über Benchmarking und Clustergröße finden konnte, sei es online, in Büchern oder in Gesprächen mit erfahreneren Dateningenieuren. Die Antwort lautete immer: "Es kommt darauf an."
Ich habe zwar einige allgemeine Formeln für die Einschätzung des Ressourcenbedarfs gesehen, wie z. B. den Packt-Ansatz für die Dimensionierung eines Hadoop-Clusters für die Datenverarbeitung, aber meine Erfahrung ist, dass dies wirklich von vielen Dingen abhängt, die miteinander verbunden sind und sich im Laufe der Zeit in Datenpipelines ändern können.
Ich kann dir zwar keine Zauberformel geben, aber ich kann dich durch den Prozess der Abschätzung und Bewertung verschiedener Berechnungskonfigurationen führen und dir zeigen, wie sich die verschiedenen Aspekte des Pipeline-Designs auf die von dir getroffenen Entscheidungen auswirken. Ich werde das Beispiel aus dem vorherigen Abschnitt fortsetzen und einige Entscheidungen über verschiedene Datenverarbeitungsmaschinen, Techniken und Clustergrößen treffen und aufzeigen, wie sie sich gegenseitig beeinflussen.
Da Datenverarbeitungsmaschinen einen erheblichen Einfluss auf den Rechenbedarf haben, eine Erörterung dieses Themas aber den Rahmen dieses Buches sprengen würde, habe ich in "Empfohlene Lektüre" Hinweise auf Ressourcen aufgenommen .
Hinweis
Während du diesen Abschnitt liest, solltest du bedenken, dass Benchmarking-Workloads dir nicht nur Einblicke in das Clusterdesign geben, sondern auch ein hilfreiches Werkzeug zur Charakterisierung und Fehlersuche sind. Das kann nützlich sein, wenn du erwägst, einen Prozess serverlos auszuführen, dir aber nicht sicher bist, welche Ressourcen dafür benötigt werden (und du daher keinen Überblick über die potenziellen serverlosen Kosten hast). Einer der Kompromisse bei der Nutzung von Serverless ist die geringere Transparenz der Ressourcennutzung, die die Auswirkungen von suboptimalen Konfigurationen der Datenverarbeitungsmaschine, leistungsschwachen Abfragen und minderwertigen Datenstrukturen verbergen kann. Wenn du dich in dieser Situation befindest, kann es sich lohnen, einen Cluster zu gründen, in dem du die Leistung überwachen und einsehen kannst.
Auch wenn du Managed Services nutzt, ist es hilfreich, diesen Prozess zu verstehen. Bei vielen beliebten verwalteten Lösungen wie Google Dataproc, AWS Glue, Databricks und Snowflake hast du die Möglichkeit, Eigenschaften der Clusterkonfiguration wie Instance-Familie, Größe und Anzahl der Arbeiter festzulegen.
Instanz Familie Identifikation
Um die richtige Instanzfamilie zu finden, musst du den relativen Bedarf an CPU, Arbeitsspeicher und Bandbreite ermitteln und die Leistung des Clusters analysieren. Wenn du diesen Prozess ein paar Mal durchlaufen hast, wirst du ein Gefühl dafür entwickeln, welche Familien für verschiedene Anwendungen gut geeignet sind.
Um auf das Beispiel der HoD-Vogelerhebungspipeline zurückzukommen: Für die Verarbeitung der Daten wird Spark verwendet, das in erster Linie mit Daten im Arbeitsspeicher arbeitet. Ein weiterer Aspekt dieser Pipeline ist der Join zwischen den Erhebungsdaten und der HoD-Datenbank. Die Verknüpfung großer Datensätze im Arbeitsspeicher deutet auf eine speicheroptimierte Familie oder möglicherweise auf eine Allzweckinstanz mit viel Speicher hin.
Tipp
Dies ist ein guter Zeitpunkt, um die Abhängigkeiten zwischen den Daten, mit denen du arbeitest, der Art und Weise, wie du sie verarbeitest, und den Rechenressourcen, die du brauchst, zu berücksichtigen. Ich habe erwähnt, dass große Datensätze im Speicher zusammengeführt werden. Du könntest diese Daten auch auf andere Weise erstellen: Du könntest die Größe der zusammenzuführenden Daten minimieren, um die Datenmenge im Speicher und den für die Zusammenführung benötigten Festplattenplatz zu verringern, oder du könntest ganz auf die Zusammenführung verzichten und stattdessen einen Lookup in einem sortierten Key-Value-Store durchführen.
Es gibt viele Stellschrauben, um die Verarbeitung von Daten zu optimieren. Die Herausforderung bei Datenpipelines besteht darin, dass es sich bei diesen Stellschrauben um das Design der Infrastruktur, die Datenformatierung und die Konfiguration der Datenverarbeitungsmaschine handelt, um nur einige zu nennen.
Da die Pipeline in EMR ausgeführt wird, ist nur eine Teilmenge der Instanztypen verfügbar. Einige zusätzliche Hinweise aus der Spark-Dokumentation empfehlen eine Konfiguration mit acht bis 16 Kernen pro Maschine2 und eine Bandbreite von 10 GB oder mehr, was die möglichen Optionen weiter einschränkt.
Die AWS-Instanzen, die diese Anforderungen erfüllen, sind in Tabelle 1-4 aufgeführt.3
| API-Name | Speicher (GB) | vCPUs | Netzwerkleistung | Linux on demand Kosten |
|---|---|---|---|---|
| m4.2xgroß | 32 | 8 | Hoch | $0.40 |
| m4.4xgroß | 64 | 16 | Hoch | $0.80 |
| m5.xlarge | 16 | 4 | Bis zu 10 Gb | $0.19 |
| m5.2xgroß | 32 | 8 | Bis zu 10 Gb | $0.38 |
| m5.4xgroß | 64 | 16 | Bis zu 10 Gb | $0.77 |
| r4.xlarge | 30.5 | 4 | Bis zu 10 Gb | $0.27 |
| r4.2xgroß | 61 | 8 | Bis zu 10 Gb | $0.53 |
| r4.4xgroß | 122 | 16 | Bis zu 10 Gb | $1.06 |
| r5.xlarge | 32 | 4 | Bis zu 10 Gb | $0.25 |
| r5.2xgroß | 64 | 8 | Bis zu 10 Gb | $0.50 |
| r5.4xgroß | 128 | 16 | Bis zu 10 Gb | $1.01 |
| r5.12xgroß | 384 | 48 | 10 Gb | $3.02 |
Hinweis
Laut Datacenters.com wird vCPU wie folgt berechnet: (Threads × Cores) × Physical CPU = Number vCPU. vCPU ist effektiv die Anzahl der verfügbaren Threads. Mehr vCPUs können mehr Parallelität ermöglichen, indem sie mehr Spark-Executors aktivieren, oder sie können eine feste Gruppe von Executors mit mehr Ressourcen versorgen.
Für den Vergleich habe ich einige Allzweck-Typen, m4 und m5, und zwei speicheroptimierte Typen, r4 und r5, ausgewählt. Beachte, dass die speicheroptimierten Instanzen bei gleicher vCPU doppelt so viel Speicher haben und die Stundenkosten entsprechend steigen.
Cluster-Größe
Eine weitere häufige Frage beim Compute Design ist, wie viele Nodes du in deinem Cluster haben solltest. Aus Gründen der Zuverlässigkeit und Leistung sollte ein Cluster mindestens zwei Worker haben. Um die gewünschte Kapazität zu erreichen, kannst du entweder einen Cluster mit vielen kleineren Instanzen konfigurieren oder weniger größere Instanzen verwenden. Was ist besser? Nun, das kommt darauf an. Dies ist ein weiterer Fall, in dem Infrastrukturdesign, Konfiguration der Datenverarbeitungsmaschine, Code und Datenstruktur zusammenkommen.
Eine weitere Überlegung ist die Art der Kaufoptionen, die du für die Clusterknoten nutzt. Unter "Benchmarking-Beispiel" findest du einige Beispiele für die Kombination von unterbrechbaren und On-Demand-Instanzen.
Betrachten wir einen Fall, in dem du einen Cluster mit einigen Knoten entwickelst, die Instanzen mit viel Speicher pro Instanz verwenden. Bei der Arbeit mit Spark kann es zu langen Zeiten für die Speicherbereinigung kommen, wenn jeder Worker-Knoten über eine große Menge an Speicher verfügt. Wenn dies zu inakzeptablen Auswirkungen auf die Leistung und Zuverlässigkeit deines Workloads führt, wäre es besser, wenn du mehr Knoten mit einer kleineren Speichermenge pro Knoten bereitstellst, um die gewünschte Speicherkapazität zu erreichen.
Wenn deine Arbeitslast jedoch stark schwankt, bedeutet eine größere Anzahl von Workern, dass du Daten zwischen mehr Instanzen verschieben musst. In diesem Fall wäre es für die Leistung besser, den Cluster so zu gestalten, dass er aus einigen Knoten mit einem größeren Speicherplatz besteht, wie in einer aktuellen Anleitung von Databricks beschrieben.
Ein Beispiel für diesen Kompromiss findest du im nächsten Abschnitt, "Benchmarking-Beispiel".
Überwachung
Um die Effizienz einer bestimmten Clusterkonfiguration zu bewerten, musst du die Leistung überwachen. Dies wird in Kapitel 11 ausführlicher behandelt, daher werde ich jetzt nur einige der spezifischen Überwachungsbereiche hervorheben, die sich auf das Benchmarking von Workloads beziehen.
Auslastung der Cluster-Ressourcen
Die Überwachung der Nutzung von Arbeitsspeicher, Festplatte, CPU und Bandbreite im Laufe eines Workloads kann dir dabei helfen, festzustellen, ob du unter- oder überversorgt bist. In EMR kannst du diese Metriken mit Ganglia überprüfen. Prometheus und Grafana sind weitere Überwachungs-Tools, mit denen du Metriken aus mehreren Einsätzen in einem einzigen Dashboard zusammenfassen kannst.
Introspektion der Datenverarbeitungsmaschine
Bei der Arbeit mit Spark liefert die Spark-Benutzeroberfläche zusätzliche Diagnoseinformationen zur Ausführungslast, zur Ausgewogenheit (oder auch nicht) deiner Berechnung über die Executors, Shuffles, Spills und Abfragepläne, die dir zeigen, wie Spark deine Abfrage ausführt. Diese Informationen können dir helfen, die Spark-Einstellungen, die Datenpartitionierung und den Datenumwandlungscode zu optimieren.
Benchmarking Beispiel
Um dir zu zeigen, wie du das Benchmarking in der Praxis durchführen kannst, gehe ich durch einige Beispielkonfigurationen für die Batch-Pipeline der Vogelumfrage in Abbildung 1-3 und beschreibe, wie du die Leistung des Clusters unter Last erkennen kannst.
Ein Blick auf die Datenverteilung in Abbildung 1-4 zeigt, dass die meisten Stapel 1 bis 2 TB an Daten enthalten. Wenn du die Schätzung mit einem Batch in diesem Bereich beginnst, erhältst du eine Konfiguration, die in der größten Anzahl von Fällen funktioniert. Sie hat auch den Vorteil, dass sie sich nicht zu sehr an sehr große oder sehr kleine Aufträge anpasst, die unterschiedliche Leistungsmerkmale haben können.
Unterdimensioniert
Ich beginne mit der Clusterkonfiguration in Tabelle 1-5. Diese Konfiguration ist unterdimensioniert und ich möchte sie veranschaulichen, damit du weißt, wie du dieses Szenario identifizieren kannst. GP1 bezeichnet die allgemeine Clusterkonfiguration und M1 die speicheroptimierte Konfiguration.
| Name | Instanztyp | Anzahl der Instanzen | Gesamt vCPU | Gesamtspeicher (GB) | Bandbreite (GB) |
|---|---|---|---|---|---|
| GP1 | m5.xlarge | 3 | 12 | 48 | Bis zu 10 |
| M1 | r5.xlarge | 3 | 12 | 96 | Bis zu 10 |
Wenn du mit großen Datenmengen arbeitest, kann es lange dauern, bis ein einzelner Lauf abgeschlossen ist. Du musst aber nicht warten, bis ein Auftrag abgeschlossen ist, um die Ergebnisse zu prüfen. Beim Benchmarking ist es sogar besser, wenn du den Zustand des Clusters von Zeit zu Zeit mit den bereits erwähnten Überwachungs-Tools überprüfen kannst.
Verteilte Systeme, einschließlich verteilter Datenverarbeitungs-Engines wie Spark, versuchen, eine Reihe von Fehlschlägen zu wiederholen, z. B. die Wiederholung einer fehlgeschlagenen Aufgabe und die Wiederholung bei einem Kommunikations-Timeout. Dies ist ein grundlegender Aspekt der Fehlertoleranz in verteilten Systemen und bedeutet für deine Datenverarbeitungsaufträge, dass ein Auftrag bei unzureichenden Ressourcen mehrmals wiederholt werden kann, bevor er offiziell als fehlgeschlagen erklärt wird.
Betrachten wir ein hypothetisches Szenario für die Ausführung der Umfragedaten-Pipeline gegen einen 2-TB-Batch unter Verwendung einer der beiden Clusterkonfigurationen in Tabelle 1-5, da in diesem Fall beide in etwa die gleiche Leistung erbringen werden.
Du startest den Cluster und die Pipeline beginnt zu tuckern und verbringt eine ganze Weile im Schritt "Enrich with social", in dem der Join stattfindet. Auf deinem Laptop hast du eine kleinere Batchgröße durch den Schritt "Enrich with social" laufen lassen und es hat nur ein paar Minuten gedauert, während er auf dem Cluster schon seit über einer Stunde läuft. Es ist an der Zeit, einen Blick auf die Leistungsüberwachung zu werfen, um herauszufinden, was los ist.
Wenn du dir die Spark-Benutzeroberfläche ansiehst, siehst du mehrere fehlgeschlagene Aufgaben und "out of memory"-Meldungen in den Executor-Logs. Du überprüfst Ganglia und siehst, dass 85% des verfügbaren Speichers verbraucht wurden und die Worker stark ausgelastet sind. Du siehst auch, dass einige Clusterknoten fehlgeschlagen sind, da sie durch EMR ersetzt wurden, um den Cluster auf dem geforderten Ressourcenniveau zu halten. Der Auftrag läuft weiter, während Spark versucht, die fehlgeschlagenen Aufgaben erneut auszuführen, aber letztendlich schlägt der Auftrag fehl.
Überdimensionale
Bei den anderen Konfigurationsoptionen GP2 und M2 in Tabelle 1-6 kommen deutlich mehr Worker hinzu, aber die xlarge-Instanzgröße wird beibehalten. In M2 werden weniger speicheroptimierte Instanzen verwendet als in GP2, da dieser Instanztyp mehr Speicherplatz bietet.
| Name | Instanztyp | Anzahl der Instanzen | Gesamt vCPU | Gesamtspeicher (GB) | Bandbreite (GB) |
|---|---|---|---|---|---|
| GP2 | m5.xlarge | 40 | 160 | 640 | Bis zu 10 |
| M2 | r5.xlarge | 30 | 120 | 960 | Bis zu 10 |
In dem hypothetischen 2 TB Batch-Beispiel siehst du, dass diese Konfigurationen deutlich besser abschneiden. Die Metriken liegen während der gesamten Auftragsausführung im Rahmen - keine Probleme mit fehlgeschlagenen Knoten oder Speicherplatzmangel. Wenn du dir die Spark-Benutzeroberfläche ansiehst, bemerkst du, dass es eine Menge Durcheinander gibt. Der Auftrag wird erfolgreich abgeschlossen, mit einer Laufzeit von 8 Stunden für GP2 und 6,5 Stunden für M2.
Die richtige Größe
Right-sizing bedeutet, dass du die optimale Anzahl an Ressourcen hast, um eine Aufgabe zu erfüllen. Das bedeutet, dass es nur begrenzt überschüssige Ressourcen (Verschwendung) gibt und dass du nicht zu wenig Ressourcen hast, was zu Problemen mit der Zuverlässigkeit und Leistung führen kann.
Warnung
Während diese Übung direkt in die richtige Dimensionierung als Teil des Benchmarking-Prozesses einsteigt, solltest du vorsichtig sein, wenn du zu früh im Designprozess Zeit damit verbringst, die optimale Compute-Konfiguration zu finden.
Die richtige Dimensionierung kommt mit der Zeit, wenn du Einblick in die Leistung der Pipeline und die Ressourcennutzung bekommst. Wenn du eine Pipeline zum Laufen bringst, kann es wünschenswert sein, mehr Ressourcen bereitzustellen als nötig. So vermeidest du das Problem der Unterversorgung und kannst dich auf die Behebung von Fehlern in anderen Bereichen konzentrieren. Sobald du das Gefühl hast, dass die Dinge zuverlässig laufen, kannst du über die richtige Größe nachdenken.
Angesichts des Shufflings, das du bei den Konfigurationen GP2 und M2 gesehen hast, könnte das Austauschen der kleinen Instanzen gegen weniger größere Instanzen die Leistung verbessern, so dass sich die Konfiguration in Tabelle 1-7 ergibt.
| Name | Instanztyp | Anzahl der Instanzen | Gesamt vCPU | Gesamtspeicher (GB) | Bandbreite (GB) |
|---|---|---|---|---|---|
| GP3 | m5.4xgroß | 10 | 160 | 640 | Bis zu 10 |
| M3 | r5.2xgroß | 8 | 64 | 512 | Bis zu 10 |
Wenn du diese Konfiguration verwendest, siehst du eine Verringerung des Shufflings im Vergleich zu GP2 und M2 und kürzere Laufzeiten. GP3 läuft in 7 Stunden und M3 läuft in 4,75 Stunden. Das ist ein interessantes Ergebnis, denn M3 hat weniger Ressourcen als M2, läuft aber schneller, weil der Aufwand für das Shuffling durch weniger Arbeiter reduziert wird.
Nachdem du nun einige funktionierende Konfigurationen gefunden hast, lass uns einen Blick auf die Kosten in Tabelle 1-8 werfen.
| Name | Anzahl der Instanzen | Stunden | Auf Anfrage | 40% Spot | 60% Spot |
|---|---|---|---|---|---|
| GP2 | 40 | 8 | $77 | $62 | $54 |
| M2 | 30 | 6.5 | $58 | $49 | $44 |
| GP3 | 10 | 7 | $67 | $56 | $51 |
| M3 | 8 | 4.75 | $24 | $20 | $19 |
Beginnend mit GP2 ist es wahrscheinlich nicht überraschend, dass dies angesichts der Anzahl der Instanzen und der Laufzeit die teuerste Option ist. Erinnere dich daran, dass sowohl GP2 als auch M2 die Pipeline erfolgreich ausgeführt haben. Hätten wir nicht die Leistung des Clusters überprüft, wäre es nicht aufgefallen, dass die Konfiguration suboptimal war.
Du kannst den Kostenvorteil der speicheroptimierten Instanzen für diese Anwendung sehen, wenn du M3 mit GP3 vergleichst. Es wurden nicht nur weniger speicheroptimierte Instanzen benötigt, sondern auch die Laufzeit des Auftrags war geringer. Infolgedessen liegen die M3 On-Demand-Kosten bei etwa 35 % der GP3-Kosten. Wenn 60 % der Instanzstunden durch Spot-Instanzen erbracht werden, können die M3-Kosten um weitere 20 % gesenkt werden.
Tipp
Wenn du Prototypen entwickelst und verschiedene Konfigurationen ausprobierst, vergisst du leicht, die Ressourcen abzuschalten, wenn du mit ihnen fertig bist. Achte beim Starten von Ressourcen auf die Optionen zum automatischen Herunterfahren. In der Regel kannst du einstellen, dass die Ressource nach einer bestimmten Zeit der Inaktivität abgeschaltet wird.
Eine weitere Möglichkeit, den Überblick über Ressourcen zu behalten, sind Tags oder Labels, die ebenfalls beim Start einer Ressource festgelegt werden. Du könntest zum Beispiel das Tag DEV-TEMP verwenden, um kurzlebige Entwicklungsressourcen zu kennzeichnen, die abgeschaltet werden können, wenn sie länger als 24 Stunden inaktiv sind.
Zusammenfassung
Die zahlreichen gebrauchsfertigen Compute-Konfigurationen, die in der Cloud verfügbar sind, geben dir die Möglichkeit, den Compute so zu gestalten, dass er ein optimales Gleichgewicht aus Leistung, Kosten und Betriebszeit für deine Datenpipelines bietet. Anstatt dich von den Millionen von Auswahlmöglichkeiten überwältigt zu fühlen, kannst du deine Rechenleistung selbstbewusst gestalten, indem du die Preisgestaltung, die Instanzkonfiguration und die Optionen für das Clusterdesign evaluierst und Benchmarking nutzt, um diese Entscheidungen zu verfeinern.
Mit diesem Verständnis bist du in der Lage, Services und Produkte zu bewerten, die das Compute Design für dich verwalten. Dazu gehören Produkte und Services von Drittanbietern, die die Kosten für Cloud Computing senken, CSP-Angebote, die das Computing für dich verwalten, wie AWS Fargate, und Serviceoptionen, die verschiedene Preispläne unter der Haube verwalten, wie AWS Instance Fleets.
Wie bei jedem Systemdesign ist es auch beim Compute-Design wichtig zu verstehen, wie etwas schiefgehen kann. Wenn du mit Cloud Compute arbeitest, hilft es dir, robuste Pipelines zu entwerfen und für Eventualitäten vorzusorgen, wenn du die Ursachen für potenzielle Ressourcenprobleme kennst. Ausfälle, Kapazitäts- und Kontolimits und das Design der Infrastruktur sind Bereiche, die du im Auge behalten solltest, besonders wenn du mit Shared Tenancy Compute arbeitest.
Je nach dem Kompromiss zwischen Kosten und Verfügbarkeit deiner Anwendung hast du verschiedene Möglichkeiten, mit Verfügbarkeitsfragen umzugehen, z. B. Failover-Systeme, Job-Segmentierung und die Ausführung von Pipelines in mehreren AZs. Behalte bei der Bewertung von Failover-Systemen oder multiregionalen Einsätzen die Kosten im Vergleich zu den Geschäftsanforderungen im Auge, insbesondere die Kosten für die Datenreplikation.
Das Wissen über die verschiedenen Preisoptionen hilft dir dabei, dort Kosten zu sparen, wo du eine gewisse Unbestimmtheit bei der Rechenkapazität mit unterbrechbaren/spot Instanzen tolerieren kannst und wo du dich bequem auf Reservierungen festlegen kannst - beides Strategien, mit denen du im Vergleich zu On-Demand-Preisen erhebliche Kosten sparen kannst. Unterbrechbare Instanzen sind eine gute Wahl für Entwicklungsaktivitäten, für das gelegentliche Hinzufügen zusätzlicher Kapazität, für Tests oder für Wartungsarbeiten mit geringer Priorität. Wenn du Reservierungen auswertest, solltest du unbedingt das Kleingedruckte lesen! Du zahlst für deine reservierte Kapazität, egal ob du sie nutzt oder nicht. Vergewissere dich also, dass du verstehst, wie die reservierte Kapazität auf deine Arbeitslast angewendet wird.
Um ein Gefühl dafür zu bekommen, welche Compute-Optionen für dich geeignet sind, solltest du deine geschäftlichen Bedürfnisse und architektonischen Anforderungen bewerten. Dies wird dir helfen, die richtige Mischung aus Kaufplänen und Cluster-Konfigurationsmöglichkeiten für deine Pipelines zu finden.
Die geschäftlichen Anforderungen helfen dir, den Bedarf an Daten, Leistung, Kosten und Zuverlässigkeit zu ermitteln, während die architektonischen Anforderungen Aufschluss über die Datenverarbeitungsmaschinen und die Infrastruktur geben. Wenn du während dieses Prozesses Beispieldaten sammelst und dir ein Bild davon machst, wo die Kosten für den Systembetrieb gehandelt werden können, erhältst du wichtige Informationen, um mit der Erkundung von Optionen für die Datenverarbeitung zu beginnen.
Wie du in diesem Kapitel gesehen hast, bereiten dich die Erkenntnisse, die du aus den geschäftlichen und architektonischen Anforderungen gewinnst, darauf vor, verschiedene Clusterkonfigurationen zu bewerten, indem du die erforderlichen Ressourcen abschätzt, Cluster für die Ausführung deiner Pipeline einsetzt und die Leistung, die Ressourcennutzung und das Verhalten der Datenverarbeitungs-Engine überwachst. Außerdem hast du in diesem Kapitel gesehen, wie das Rechendesign mit vielen anderen Aspekten des Betriebs von Datenpipelines zusammenhängt, z. B. mit der Konfiguration der Datenverarbeitungs-Engine, mit Ansätzen zur Datenumwandlung und mit Entscheidungen über die Datenstruktur. Ein weiteres Element, das sich auf die Rechenleistung auswirkt, ist die Speicherung der Daten, über die du in Kapitel 3 mehr erfahren wirst.
Wie du im Benchmarking-Beispiel gesehen hast, bringt mehr Rechenleistung nicht unbedingt eine bessere Leistung. Das Überwachen und Wiederholen von Berechnungskonfigurationen ist eine wichtige Praxis für ein kosteneffizientes Design und hilft dir dabei, herauszufinden, welche Konfigurationen für eine bestimmte Arbeitslast am effektivsten sind. Obwohl ich mich in diesem Kapitel auf das Benchmarking konzentriert habe, um Cluster-Konfigurationen zu ermitteln, ist diese Fähigkeit für die Fehlersuche unverzichtbar und hilft dir, Entscheidungen über die Infrastruktur zu treffen, unabhängig davon, ob du die Infrastruktur selbst entwickelst oder nicht.
Im nächsten Kapitel erfährst du, wie du die Elastizität der Cloud nutzen kannst, um Cloud-Ressourcen zu vergrößern oder zu verkleinern, um verschiedenen Arbeitslasten gerecht zu werden und Kompromisse zwischen Kosten und Leistung zu schließen.
Empfohlene Lektüre
Ressourcen für die Spark-Optimierung
High Performance Spark von Holden Karau und Rachel Warren (O'Reilly)
Kapitel 7 von Learning Spark, 2nd Edition, von Jules S. Damji, Brooke Wenig, Tathagata Das, und Denny Lee (O'Reilly)
Kapitel 19 von Spark: The Definitive Guide von Bill Chambers und Matei Zaharia (O'Reilly)
Ressourcen zur Dask-Optimierung
Python skalieren mit Dask von Holden Karau und Mika Kimmins (O'Reilly)
Dask: The Definitive Guide von Matthew Rocklin, Matthew Powers, und Richard Pelgrim (O'Reilly)
1 In dem Szenario, das diese Geschichte inspiriert hat, betrugen die zusätzlichen Kosten weit mehr als ein paar Dollar.
2 Das hängt auch stark davon ab, wie du Spark konfigurierst und wie hoch deine Arbeitslast ist.
3 Daten von https://instances.vantage.sh.
Get Kosteneffiziente Datenpipelines now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
