Je moet een nieuwe streaming Dataflow-pijplijnversie (leest Pub/Sub, schrijft BigQuery) implementeren zonder gegevensverlies, inconsistenties te vermijden en de toegevoegde latentie onder de 10 minuten te houden. Welke implementatievolgorde volg je?

Het leegmaken (drainen) van de oude pijplijn zorgt ervoor dat alle gegevens die nog in verwerking zijn, volledig worden verwerkt en naar BigQuery worden geschreven voordat de pijplijn stopt. Dit voorkomt gegevensverlies en inconsistenties. Zodra de oude pijplijn is geleegd, kan de nieuwe pijplijn worden gestart, die de verwerking van nieuwe Pub/Sub-berichten overneemt. Deze methode minimaliseert downtime en houdt de toegevoegde latentie laag, omdat er geen handmatige herverwerking van gegevens nodig is. Het bijwerken van de oude pijplijn is niet mogelijk voor streaming Dataflow-jobs; er moet een nieuwe job worden gestart. Een snapshot maken en de pijplijn opnieuw starten vanuit de snapshot is bedoeld voor het herstellen van een pijplijn naar een eerder punt in de tijd, niet voor het implementeren van een nieuwe versie. Het annuleren van de oude pijplijn zou leiden tot gegevensverlies, omdat onverwerkte gegevens verloren gaan.