vorheriger Artikel
Als AWS Advanced Partner wollen wir in diesem Blog unsere Erkenntnisse im Kontext Data- und Analytics-Lösungen regelmäßig dokumentieren und mit AWS-Interessierten teilen. AWS stellt als Cloud-Provider mit seinem Ökosystem und seinen Services Lösungen für uns und unsere Kunden bereit, die für eine moderne Datenarchitektur sehr gut genutzt werden können. Ziel ist hierbei nicht die Wiederholung von allgemein zugänglichen AWS-Dokumentationen. Es wird hierbei vielmehr darum gehen, unsere technischen und fachlichen Erfahrungen verdichtet zu „Papier“ zu bringen.
Diese Blogreihe startet mit der Fragestellung: „Sizing einer Redshift-Datenbank für ein Cloud-DWH“.
Motivation
Data-Warehouse-Lösungen sind seit über 35 Jahren aus Unternehmen nicht mehr wegzudenken, sie sind ein zentraler Bestandteil von „datengetriebenen“ Unternehmen, sei es als klassische Business Intelligence zur strategischen und taktischen Steuerung oder auch als Basis für Datenprodukte zur operativen Steuerung.
Sehr lange war hierbei das Thema „Big Data“ für On-Premises-Datenbanken ein echtes Hindernis, sei es als Kostentreiber oder als Bremse, wenn es darum geht, mal eben Daten aufbereiten zu können. Dies hat sich in den letzten Jahren mit der Einführung von Cloud-DWH-Lösungen dramatisch geändert, da nun Storage & Compute innerhalb von Minuten oder Sekunden bereitstehen. Beliebig große Workloads können verarbeitet werden.
Auf der anderen Seite birgt aber gerade diese Flexibilität Risiken im Kontext von Infrastrukturkosten und Nachhaltigkeit, die im Rahmen dieses Artikels diskutiert werden sollen. Das heißt, wie regelt man eigentlich sinnvollerweise die Größe einer Redshift aus, ohne dass man von einer Kostenexplosion überrascht wird?
Vorüberlegungen oder Software schlägt Hardware
Die Performance einer Redshift und eines Cloud-DWH im Allgemeinen wird von der Geschwindigkeit der Datenkommunikation dominiert:
- Wie schnell bekommen die Redshift-Knoten Daten von dem Managed-S3-Speicher der Redshift?
- Wie schnell werden Daten einzelner Tabellen zwischen den Knoten des Clusters ausgetauscht?
Das heißt, unabhängig davon, ob man mit einem Cluster oder mit Redshift Serverless arbeitet, geht es in jedem Fall immer darum, I/O-Last zu reduzieren! I/O-Anforderungen haben einen Hauptanteil an dem Sizing der Datenbank.
Die Größe des DWH hängt somit von folgenden Faktoren ab:
- Komprimiertes (zu verarbeitendes) Datenvolumen und hierbei in der Regel die Größe und das Abfrageverhalten auf den größten Faktentabellen, d. h., wenn in der Regel nur 5 % dieser Fakten abgefragt werden, dann hilft z. B. eine Sortierung auf dem Zeitattribut dabei, I/O massiv zu reduzieren.
- Anforderungen an die Laufzeit der Tagesverarbeitung oder auch der stündlichen Verarbeitungen. Hier machen folgende Standardanforderungen Sinn:
- Täglicher Prozess sollte max. 2–4 h dauern, um die Chance zu haben, morgens ggf. Prozesse, die abgebrochen sind, nach Fehlerbehebung neu zu starten und eben keinen kompletten Tag zu verlieren.
- Stündliche Prozesse sollten wenige Minuten laufen, damit hier die Stundenverarbeitung überhaupt sinnvoll ist. Die Anforderung basiert hierbei darauf, möglichst frische Daten verarbeiten zu können und ein zeitlich aktuelles Reporting zu haben.
- Prozesse im Minuten-/Sekundenbereich, also Streaming-Prozesse, sollten auch entsprechend schnell laufen können, sodass sich kein Daten-Backlog aufbaut.
Dies bedeutet, dass man ein Verständnis für Data Use Cases (Requirements), Abfragepattern und eine Veränderung des Datenvolumens über die Zeit entwickeln muss, um bei Bedarf auch entsprechend pro-aktiv nachsteuern zu können.
- Query-Performance für End-User/BI-Tools – Einflussfaktoren:
- Komplexität SQLs und User-Erwartung – im Bereich Reporting und auch Ad-hoc-Analysen sollten >95 % aller Abfragen im Sekundenbereich liegen, während die restlichen 5 % (falls sie nicht ständig laufen) auch Minuten dauern dürfen.
- Zahl der Abfragen und Concurrent-User
- Langlaufende Abfragen (z. B. Monatsabschluss), die sehr selten laufen und das Sizing nicht beeinflussen sollten
Letztlich ist das Sizing eines DWH genau dann abgeschlossen, wenn diese Anforderungen erfüllt sind. Die Speicherung der Daten insgesamt ist untergeordnet, da durch die Trennung (zumindest Serverless und neue RA3-Knoten) Speicher mehr oder weniger „unlimitiert“ ist und auch zu den Gesamtkosten einer Redshift wenig beiträgt. 20 h eines ra3.xlplus oder auch 8 h 8 RPU einer Redshift Serverless kosten in etwa so viel wie 1 TB pro Monat. Usage-Kosten für Server sind in der Regel Kostentreiber und nicht das Datenvolumen.
Die Möglichkeit einer Skalierung der Datenbank scheint die Anforderungen einfach zu lösen. Wir raten aber davon ab, ausschließlich diesen Faktor als Lösung zu verwenden, da hier die Erfahrung zeigt, dass folgende Entwicklungsmuster in der Regel deutlich mehr Einfluss auf die Performance der Abfragen haben und deutlich kostengünstiger zu realisieren sind:
Diese Entwicklungsmuster sind recht einfach zu berücksichtigen und sollten bei allen Data Engineers präsent sein. Delta-Prozesse und Sort-Keys sind in der Regel die größten „Hebel“, da man so einfach Performance-Gewinne von 100–1.000 realisieren kann, es werden einfach deutlich weniger Daten verarbeitet. Statt 10 Jahren Historie wird ggf. nur die Historie des letzten Monats oder der letzten Tage verarbeitet.
Die anderen Best Practices haben einen geringeren Einfluss:
- Import/Export von/nach S3 durch Verwendung von komprimierten oder auch spaltenbasierten Datenformaten (z. B. Parquet)
- Reduktion der Datenkommunikation zwischen Cluster-Knoten durch die richtige Wahl von Distribution-Keys
- Reduktion der Daten durch eine kluge Wahl des Datenmodells (z. B. Aggregatstabellen) oder Materialized Views
- Auslagern in den Lake und Verwendung von Redshift Spectrum und Nutzung von Caching in BI-Tools oder proprietäre Datenhaltung in den BI-Tools zur Reduktion des Query-Aufkommens
- Verarbeitung von Massendaten außerhalb der Redshift durch z. B. Nutzung von AWS Glue, um entsprechend die Peak-Nutzung zu reduzieren
- Materialisierung von Zwischenergebnissen in temporären Tabellen für eine genaue Performance-Analyse oder auch um dem Redshift Query Optimizer entsprechend „zu helfen“
Der Einfluss von Data Vault vs. Dimensional vs. 3NF-Modellierungsansätzen spielt aus unserer Erfahrung eine untergeordnete Rolle, bzw. die obigen Maßnahmen können davon unabhängig angewendet werden.
Sizing einer Redshift-Datenbank
Das Sizing der Redshift wird in folgenden vier Schritten durchgeführt:
Hierbei wird (1) „Help me choose“ einmalig durchgeführt, während die Schritte 2–4 bei Bedarf oder auch monatlich wiederholt werden, um so regelmäßig einen Blick auf dem Thema Performance zu halten.
Das Problem bei Schritt (1) ist, dass sich die Schätzung stark auf einzelne Abfragemuster konzentriert (zeitbasiert) oder die Größe der Redshift überschätzt wird. Daher ist unsere Empfehlung, doch kleiner zu starten (50 %) und erst bei Bedarf zu skalieren.
Eine Analyse von Langläufern (3) (SQL von Data Engineers, BI-Tools oder ad hoc von Power-Usern) sollte aus unserer Sicht im monatlichen Rhythmus durchgeführt werden. Die Entscheidung, ob entweder Softwareänderungen oder eine Hardwareskalierung durchgeführt wird, sollte ausschließlich dem/der DWH-Architekt:in vorbehalten sein.
Zusätzlich sind natürlich Mechanismen wie Concurrency Scaling, Limits in Redshift Serverless oder auch Redshift Advisor (für Sort-Keys, Distribution-Keys, Compression oder Workload Management) einsetzbar, allerdings ist zu beachten, dass diese zwar die Performance verbessern können, letztlich aber „schlechten“ SQL-Code oder ein Datenmodell nicht optimieren.
Fazit
Bei der Nutzung von Cloud-Services ist es verführerisch, die potenziell unbeschränkten Ressourcen „einfach mal hochzudrehen“, allerdings zeigt die Erfahrung, dass dies zu immer weiteren Kostensteigerungen führt und auch das Thema Nachhaltigkeit (im Sinne von Schonung von Ressourcen und Qualität von ETL-Prozessen) zu kurz kommt.
Wir empfehlen daher, in jedem Fall immer zuerst den Aufbau von SQL-Abfragen/-Prozessen zu hinterfragen und zu optimieren. Es ist hierbei vollkommen klar, dass der Trade-off zwischen Entwicklungsaufwänden und Infrastrukturkosten ausgeregelt werden muss. Bestimmte Entwicklungsmuster können hierbei helfen, den Entwicklungsaufwand gering zu halten und einem schleichenden „Immer-größer-Werden“ entgegenzusteuern. Denk daran, dass das Sizing einer Redshift-Datenbank für ein Cloud-DWH kein einmaliger Prozess ist. Wenn sich Daten, Abfragepattern oder auch Workloads ändern, ist es erforderlich, das Sizing zu überprüfen und Anpassungen vorzunehmen.
Als b.telligent unterstützen wir Dich gerne bei der Einführung von Redshift für Deine Data Warehouse Use
Cases und helfen auch gerne bei der Feinjustierung Deines Redshift-Clusters und der zugehörigen Daten-
prozesse!
