Storage und Compute trennen, ohne Cloud: was dafür nötig ist

Klassische Warehouses banden Speicher und Rechenleistung an denselben Knoten. Mehr Rechenleistung hieß mehr Server, und mehr Server hießen mehr Platten – auch wenn man den Platz nicht brauchte. Die Trennung löst das: Daten liegen auf einem Objektspeicher, Rechenknoten sind zustandslos und können kommen und gehen.

Dass das im eigenen Rechenzentrum funktioniert, ist keine Frage der Technik, sondern eine Frage von drei Bausteinen.

Baustein eins: S3-kompatibler Speicher

Die S3-Schnittstelle ist zum faktischen Standard geworden, und mehrere Systeme sprechen sie im eigenen Rechenzentrum: Ceph mit RADOS Gateway, MinIO, NetApp StorageGRID, Dell ECS. Für ein Lakehouse zählen dabei drei Eigenschaften mehr als der Durchsatz in Benchmarks:

• Atomare Umsetzung eines Schlüssels. Ohne sie ist ein Snapshot-Wechsel nicht sicher – dann übernimmt der Catalog diese Aufgabe.
• Lesekonsistenz nach dem Schreiben. Wer eine Datei schreibt und sofort liest, muss sie sehen. Alle genannten Systeme erfüllen das heute.
• Verhalten bei vielen kleinen Objekten. Die Metadatenlast eines Lakehouse besteht aus tausenden kleinen Dateien, nicht aus wenigen großen.

Der letzte Punkt wird in Auswahlverfahren fast immer übersehen. Ein Speicher, der bei sequenziellen Großdateien glänzt, kann bei Metadatenzugriffen deutlich abfallen – und genau die dominieren im Betrieb.

Baustein zwei: ein Orchestrator, der Knoten wegnimmt

Rechenknoten hinzuzufügen ist einfach. Die Kunst ist, sie wieder loszuwerden. Auf Kubernetes heißt das: die Warehouses laufen als eigene Ressourcen, ein Operator skaliert sie nach Warteschlangenlänge, und ein Knoten wird abgeräumt, wenn er eine Zeit lang nichts zu tun hatte.

apiVersion: lavalake.io/v1
kind: Warehouse
metadata:
  name: bi-xl
spec:
  size: xl
  minReplicas: 0          # 0, nicht 1 – sonst gibt es kein Auto-Suspend
  maxReplicas: 8
  autoSuspendAfter: 10m
  scaleOn:
    queueDepth: 4
  isolation: dedicated    # BI-Last nicht mit ETL mischen

Wer minReplicas auf 1 setzt, hat kein Auto-Suspend, sondern eine dauerhaft laufende Mindestgröße. Das ist der häufigste Grund, warum der erwartete Spareffekt ausbleibt.

Baustein drei: Caching, weil das Netz nicht verschwindet

Getrennter Speicher heißt: jede Abfrage liest über das Netz. Ein lokaler Cache auf NVMe am Rechenknoten macht den Unterschied zwischen brauchbar und quälend. Wichtig ist, dass der Cache am Snapshot hängt und nicht am Dateinamen – sonst liefert er nach einem Schreibvorgang alte Daten.

Wo die Elastizität endet

Und hier der Teil, der in Produktvergleichen fehlt: im eigenen Rechenzentrum ist Elastizität nach oben begrenzt. Wer acht Knoten hat, kann auf acht skalieren. In der Cloud kann man auf achtzig skalieren, und dafür zahlt man dann auch.

Daraus folgt eine ehrliche Abgrenzung: Wer stark schwankende, seltene Spitzen hat und dazwischen fast nichts, fährt in der Cloud besser. Wer eine hohe, gleichmäßige Grundlast hat – und das ist bei Berichtswesen und Controlling der Normalfall –, zahlt in der Cloud für Elastizität, die er nicht nutzt.

Die interessante Zahl ist deshalb nicht die Spitzenlast, sondern das Verhältnis von Spitze zu Median. Liegt es unter etwa drei, ist vorgehaltene Kapazität in der Regel günstiger. Liegt es über zehn, wird es andersherum. Diese Rechnung lässt sich aus der Query-Historie eines bestehenden Warehouses direkt beantworten – und sie wird selten gestellt.