Amazon (AWS) Redshift ist ein leistungsfähiges Data-Warehousing-Tool. Seine große Skalierbarkeit und Benutzerfreundlichkeit machen es zur idealen Plattform gerade auch für kleine Teams, die große Datenmengen effizient verwalten möchten. Wenn jedoch spezifischere Anforderungen entstehen, kann es sinnvoll sein, die Funktionen von Redshift durch zusätzliche AWS-Services zu erweitern. Dabei können Services wie Lambda, Fargate und SQS mehr Rechenleistung und Flexibilität bieten, ohne die Systemkomplexität zu erhöhen.

Dieser Beitrag zeigt Dir, wie Du mit AWS Compute Services wie Lambda, Fargate und SQS flexibel auf unterschiedliche Arbeitslasten reagieren kannst – und das alles ganz einfach mit der SQL-Steuerung direkt aus Redshift.

Architekturansätze zur Erweiterung von AWS Redshift

Für eine flexible Erweiterung von Redshift haben wir drei potenzielle Architekturansätze identifiziert. Um sie gut vergleichen zu können, haben wir folgende Schlüsselkriterien herausgefiltert: 

1. Integration mit AWS Redshift
2. Flexibilität bei Rechenleistung und Programmierunterstützung
3. Infrastrukturkomplexität
4. Kosten

Was ist der Ansatz?

AWS Fargate bietet skalierbare Rechenleistung über Container. Hier fungiert eine Lambda-Funktion als Vermittler zwischen Redshift und Fargate. Dieser Ansatz ist ideal, wenn Du mehr Rechenressourcen benötigst, als Lambda bietet.

Vorteile

• Maximale Flexibilität: Volle Anpassbarkeit durch Docker-Images.
• Skalierbarkeit: Ressourcen lassen sich einfach erhöhen, falls mehr Leistung benötigt wird.
• Transparente Integration: Für die Benutzer bleibt die Integration nahtlos.

Nachteile

• Höhere Komplexität: Die Einrichtung und Verwaltung von Containern erfordert mehr Aufwand.
• Laufzeitbeschränkung: Da Fargate-Aufgaben durch Lambda orchestriert werden, gilt weiterhin das 15-Minuten-Limit.
• Zusätzliche Kosten: Die Nutzung von Fargate ist potenziell teurer als Lambda.

Solution 2

Die Kombination aus zusätzlicher Komplexität bei der Implementierung von AWS Fargate und den Lambda-Laufzeitbeschränkungen für synchrone Funktionen macht diese Option für die meisten Fälle weniger interessant. Es ist jedoch sinnvoll, sie im Hinterkopf zu behalten, um sie mit Option 1 und 3 zu vergleichen.

Die beste Wahl hängt von den individuellen Anforderungen Deines Teams ab. Diese drei Kriterien können Dir helfen, eine gute Entscheidung zu treffen: 

1. Bedarf an Flexibilität: Lambda-UDFs sind optimal, wenn Du eine einfache, flexible Lösung suchst, die verschiedene Programmierumgebungen integriert.
2. Ausführungsgeschwindigkeit: Für parallele Prozesse bietet sich SQS an, um eine hohe horizontale Skalierbarkeit zu ermöglichen.
3. Rechenleistung: Wenn Du umfangreiche Berechnungen durchführen musst, ist Fargate die bessere Wahl, auch wenn dies eine höhere Komplexität bedeutet.
    

Wenn die vorgeschlagenen Lösungen nicht ausreichen

Falls die beschriebenen Optionen nicht alle Anforderungen erfüllen, bietet die AWS-Plattform weitere Alternativen, um die Möglichkeiten von Redshift noch gezielter auszubauen. So lässt sich beispielsweise das 15-Minuten-Limit von Lambda-Funktionen umgehen, indem Du auf asynchrone Funktionsaufrufe statt auf synchrone Lambda-UDFs setzt. Das kann jedoch mit zusätzlicher Komplexität verbunden sein.

Spezifische Anforderungen 

Letztlich hängt die beste Wahl der Architektur von Deinen spezifischen Datenverarbeitungsanforderungen ab. Bevor Du eine Entscheidung triffst, solltest Du Deine aktuelle Arbeitslast und zukünftige Anforderungen sorgfältig abwägen. So kannst Du die optimale Lösung finden, die die Leistungsfähigkeit Deiner AWS-Redshift-Umgebung ideal ergänzt.

Wenn Du Dir unsicher bist, starte am besten mit Docker-Images – selbst für einfache Lambda-Funktionen. Das schafft Flexibilität und macht einen Wechsel von Lambda zu AWS Fargate bei Bedarf einfacher.

Du stehst vor genau dieser Herausforderung und brauchst einen guten Sparringspartner? Oder Unterstützung bei der Umsetzung? Dann melde Dich jederzeit gern bei uns. Unsere Datenprofis freuen sich auf Dein Projekt!