BIGQUERY → STACKIT · ARCHITEKTUR
BigQuery zu STACKIT: die Datenplattform entwerfen
BigQuery wird nicht umgezogen, sondern durch ein Design ersetzt. StackToIT stuft ein BigQuery-Dataset als REDESIGN mit Konfidenz LOW ein und schreibt dafür kein Terraform, weil ein serverloses Warehouse samt SQL-Dialekt und Abrechnungsmodell keine einzelne STACKIT-Ressource als Ziel hat. Diese Seite zeigt die Optionen, was die Engine mit den Teilen rund ums Warehouse tut und wie Sie wählen.
Ein Dataset mit Tabellen, als eine Einheit bewertet
Eine kleine Analytics-Umgebung, für diese Seite geschrieben und am 4. November 2026 von StackToIT bewertet: ein Dataset, eine partitionierte Tabelle, eine View, eine Dataset-Berechtigung, ein Bucket und ein Topic. Links Dataset und Orders-Tabelle, wie die Eingabe sie deklariert. Rechts ein Auszug der Einheit aus assessment.json mit den Werten genau so, wie der Lauf sie geschrieben hat; der Beschreibungstext des Zieldienstes ist weggelassen.
resource "google_bigquery_dataset" "sales" {
dataset_id = "sales"
location = "EU"
default_table_expiration_ms = 31536000000
}
resource "google_bigquery_table" "orders" {
dataset_id = google_bigquery_dataset.sales.dataset_id
table_id = "orders"
deletion_protection = true
time_partitioning {
type = "DAY"
field = "order_date"
}
clustering = ["customer_id"]
schema = jsonencode([
{ name = "order_id", type = "STRING", mode = "REQUIRED" },
{ name = "customer_id", type = "STRING", mode = "REQUIRED" },
{ name = "order_date", type = "DATE", mode = "REQUIRED" },
{ name = "total", type = "NUMERIC", mode = "NULLABLE" }
])
}{
"id": "google_bigquery_dataset.sales",
"kind": "data_warehouse",
"facets": [
"google_bigquery_dataset_iam_member.analysts",
"google_bigquery_table.daily_revenue",
"google_bigquery_table.orders"
],
"result": {
"class": "REDESIGN",
"confidence": "LOW",
"target": {
"resources": [
"stackit_dremio_instance"
]
},
"reason": "BigQuery is a serverless warehouse with its own SQL dialect, storage and billing model. On STACKIT, data lands as files (e.g. Iceberg) in Object Storage queried with Dremio, or in a self-managed warehouse; queries, scheduled queries and BI connections are rewritten."
}
}Tabellen, View und Berechtigung gehen im Dataset auf
Die beiden Tabellen und die Dataset-Berechtigung stehen als Facetten der Dataset-Einheit; aus sechs Ressourcen werden so drei Einheiten. Die Einheit steht für den ganzen Warehouse-Ausschnitt, nicht für ein einzelnes Objekt.
Für das Warehouse wird nichts entworfen
Die Klasse ist REDESIGN, die Konfidenz LOW. Als Zielressource ist eine Dremio-Instanz genannt, die der Provider als Teil eines zuschaltbaren Features führt, das sich erheblich ändern kann; der Lauf führt sie als Kandidaten und schreibt keinen Block. Die Dremio-Seite von STACKIT ergänzt, Stand November 2026, dass in der aktuellen Phase eine weiche Grenze für aktive Instanzen je Projekt gilt und die Engine-Größen gedeckelt sind; mehr Kapazität gibt es über den STACKIT-Support.
Zwölf kritische Einstellungen bleiben bei Ihnen
Der Architektenbericht listet sie nach Art: Identität und Zugriff (die Dataset-Berechtigung), Ablauf der Daten, Löschschutz an beiden Tabellen, der Standort, drei Namen, das Tabellenschema und das Partitionslayout. Jede ist eine Entscheidung über den Ersatz, kein Wert zum Kopieren.
Die Teile rund ums Warehouse werden entworfen
Aus demselben Lauf. Ein Landing-Bucket und ein Event-Topic sind gewöhnliche Migrationen. Links die Eingabe. Danach die Blöcke, die die Engine geschrieben hat, ein Ausschnitt je Datei, ohne die Prüfkommentare darüber.
resource "google_storage_bucket" "landing" {
name = "shop-analytics-landing"
location = "EUROPE-WEST3"
uniform_bucket_level_access = true
}
resource "google_pubsub_topic" "events" {
name = "order-events"
}resource "stackit_objectstorage_bucket" "landing" {
project_id = var.project_id
name = "shop-analytics-landing"
}resource "stackit_rabbitmq_instance" "messaging" {
project_id = var.project_id
name = "messaging"
plan_name = var.rabbitmq_plan_name
version = var.rabbitmq_version
parameters = {
sgw_acl = join(",", var.rabbitmq_allowed_cidrs)
}
}Der Bucket ist das Fundament
Ein Cloud-Storage-Bucket wird zu einem STACKIT-Object-Storage-Bucket (RECONFIGURE). Für welches Warehouse-Design Sie sich auch entscheiden: Die Dateien landen hier, also bauen Sie ihn zuerst.
Pub/Sub-Topic zu RabbitMQ
Ein Topic wird zu einem Exchange auf einer gemeinsamen RabbitMQ-Instanz (REPLATFORM). Der Entwurf legt nur die Instanz an; Exchanges, Queues und der Wechsel vom Pub/Sub-Client zu AMQP sind Ihre Aufgabe.
Der Datenumzug ist eine offene Entscheidung
migration/data-movement.md führt Dataset und Bucket als zustandsbehaftete Einheiten mit noch unbekanntem Verfahren und vermerkt, dass Datenmenge und Änderungsrate nicht in der Quelle stehen.
Die Optionen und ihre Abwägungen
| Option | Passt, wenn | Abwägung |
|---|---|---|
| Lakehouse: Dateien im Object Storage, abgefragt mit STACKIT Dremio | Viele SQL-Nutzer und BI-Werkzeuge; Daten dürfen als Dateien in offenen Formaten liegen | Abfragen und Views werden auf Dremio-SQL umgeschrieben; der Dienst ist im Provider zuschaltbar und dort für eu01 verfügbar |
| Selbst betriebenes Warehouse auf Servern oder SKE | Sie brauchen eine bestimmte Engine oder volle Kontrolle über ihr Tuning | Sie betreiben, patchen, skalieren und sichern es |
| PostgreSQL Flex für kleine relationale Marts | Die Daten sind überschaubar und die Abfragen relational | Eine einzelne verwaltete Instanz; sie skaliert nicht horizontal wie ein serverloses Warehouse |
| Diese Workload vorerst bei BigQuery lassen | Die Daten dürfen zeitweise außerhalb von STACKIT bleiben | Zwei Plattformen im Betrieb, und der Export bleibt eine spätere Aufgabe |
Die ersten beiden Zeilen sind die Ziele, die die Engine für BigQuery nennt. Die letzten beiden sind Optionen, die ein Architekt abwägen kann; der Lauf schlägt sie nicht vor.
So entscheiden Sie
Beantworten Sie die Fragen der Reihe nach; meist ergibt sich daraus die passende Zeile.
Wer fragt ab, und womit
Listen Sie Analysten, Berichte und geplante Jobs auf. Der SQL-Dialekt von BigQuery, verschachtelte und wiederholte Felder und BigQuery-ML-Modelle müssen Sie umschreiben oder ersetzen (allgemeine Praxis, keine Ausgabe des Laufs); zählen Sie sie, denn sie sind der eigentliche Aufwand.
Wie groß, und wie schnell ändert es sich
Der Lauf sagt klar, dass beides nicht in der Quelle steht. Ohne diese Angaben lässt sich der Datenumzug nicht planen und keine Instanz dimensionieren.
Was verfallen oder bleiben muss
Ihr Dataset setzt einen Standardablauf für Tabellen von einem Jahr, den der Lauf markiert. Bei einem dateibasierten Design wird der Ablauf zu einem Job oder einer Lifecycle-Regel, die Sie bewusst schreiben.
Wer was lesen darf
Dremio dokumentiert Zugriffskontrolle auf Zeilen- und Spaltenebene und Anmeldung über einen OIDC-Identitätsanbieter. Übersetzen Sie jede BigQuery-Dataset-Berechtigung in eine solche Regel, statt Rollen zu kopieren.
Daten umziehen, sobald die Wahl getroffen ist
Allgemeine Praxis, keine Engine-Ausgabe. Der Lauf vermerkt nur, dass ein Verfahren gewählt werden muss.
Aus BigQuery exportieren
Ein Tabellenexport schreibt ausschließlich nach Cloud Storage, als CSV, zeilenweises JSON, Avro oder Parquet. Dataset und Bucket müssen am selben Standort liegen, und eine einzelne Datei fasst bis zu 1 GB Tabellendaten; nutzen Sie daher einen Platzhalter im Dateinamen.
Nach Object Storage kopieren
Kopieren Sie die exportierten Dateien mit einem S3-kompatiblen Werkzeug wie rclone in den STACKIT-Bucket. Der Bucket spricht die S3-API über HTTPS.
Tabellen registrieren
Dremio hat native Konnektoren für S3-kompatiblen Speicher und unterstützt Iceberg- und Delta-Lake-Tabellen. Legen Sie das Partitionslayout bewusst fest; der Lauf führt die Partitionsspalte als offen.
Views und Zeitpläne neu schreiben
Die View für den Tagesumsatz ist in BigQuery-SQL geschrieben und wird von Hand umgeschrieben. STACKIT Workflows, aufgebaut auf Apache Airflow, kann wiederkehrende Jobs als Python-DAGs ausführen; der webbasierte DAG-Editor ist noch nicht verfügbar.
Streaming-Eingänge
Wo Ereignisse bisher in BigQuery flossen, nimmt STACKIT Intake sie über das Kafka-Protokoll in Iceberg-Tabellen eines Dremio-Katalogs auf. Prüfen Sie, ob es zu Ihren Produzenten passt, bevor Sie sich darauf verlassen.
Fragen, die Datenteams stellen
Warum schreibt StackToIT kein Terraform für BigQuery?
Weil das richtige Ziel von einer Designentscheidung abhängt: Dateien mit Dremio abfragen oder ein Warehouse, das Sie selbst betreiben. Der Lauf nennt die Kandidaten, listet die offenen Einstellungen und überlässt Ihnen die Wahl.
Gibt es bei STACKIT einen zu BigQuery gleichwertigen Dienst?
Nicht als einzelnen Dienst. Der nächste verwaltete Weg in STACKITs Dokumentation ist ein Lakehouse: Dateien in offenen Formaten im Object Storage, abgefragt mit Dremio. Das ist ein anderes Modell, daher ändern sich Abfragen und Werkzeuge.
Gehen BigQuery-Partitionen und Clustering über?
Keine Einstellung geht von selbst über. Der Lauf führt Partitionsspalte, Partitionstyp und Tabellenschema als offene Punkte. Das Clustering auf customer_id liest er zwar ein, meldet dazu aber keinen Punkt; nehmen Sie es also selbst in Ihre Liste auf. Das Layout der Dateien oder Tabellen am Ziel legen Sie fest.
Können wir erst die Daten umziehen und später entwerfen?
Ja. Der Export nach Parquet und das Kopieren in einen Object-Storage-Bucket legt Sie nicht auf eine Engine fest. Es ist ein sicherer erster Schritt, denn jede der STACKIT-Optionen oben liest Dateien oder kann sie laden.
Quellen
Ihr nächster Schritt: STACKIT.
Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.