![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(99.2, 15%, 19%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EFW%3C/text%3E%3C/svg%3E)
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(185.6, 36%, 27%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ETL%3C/text%3E%3C/svg%3E)
Hallo Fur Wanger,
Die Fehlermeldung deutet darauf hin, dass der aktuelle Schreibvorgang ein BigQuery-Kontingent für Tabellenänderungen erreicht hat. Wenn Ihre Anwendung sehr häufig kleine Batches oder einzelne Datensätze schreibt, ist die BigQuery Storage Write API in der Regel die empfohlene Alternative für Workloads mit hohem Durchsatz.
Für die Umstellung würde ich zunächst einen parallelen Testpfad aufbauen und die Daten zusätzlich über die Storage Write API in eine separate Tabelle schreiben. So können Sie Durchsatz, Latenz und Datenkonsistenz prüfen, ohne den bestehenden Produktionsprozess zu beeinflussen. Anschließend können Sie den bisherigen Ingestion-Pfad schrittweise ablösen, sobald die Ergebnisse stabil sind.
Könnten Sie noch mitteilen, wie die Daten aktuell nach BigQuery geschrieben werden (Load Jobs, Streaming Inserts oder ein anderes Verfahren)? Davon hängt ab, wie die Migration am sinnvollsten umgesetzt werden kann. Da BigQuery ein Google-Cloud-Dienst ist, sind die offizielle Google-Dokumentation und der Google-Support die maßgeblichen Referenzen für die konkrete Implementierung. Wenn die Antwort hilfreich war, können Sie sie gerne als Lösung akzeptieren.
Tracy Le.