Pianifica la tua pipeline Dataflow

Questa pagina spiega importanti considerazioni per pianificare la pipeline di dati prima di iniziare lo sviluppo del codice. Data pipelines spostano i dati da un sistema e sono spesso fondamentali componenti dei sistemi di informazione aziendale. Le prestazioni e l'affidabilità la tua pipeline di dati può influire su questi sistemi più ampi e in modo efficace le tue esigenze aziendali.

Se pianifichi le pipeline di dati prima di svilupparle, puoi migliorarne le prestazioni e l'affidabilità. In questa pagina vengono spiegate considerazioni sulla pianificazione per le pipeline Dataflow, tra cui:

• Aspettative relative alle prestazioni per le pipeline, inclusi gli standard per misurabilità
• Integrazione delle pipeline con origini dati, sink e altro sistemi connessi
• Regionalizzazione di pipeline, origini e sink
• Sicurezza, come la crittografia dei dati e il networking privato

Definire e misurare gli SLO

Una misura importante del rendimento è il livello di efficacia della pipeline in termini di requisiti aziendali. Obiettivi del livello di servizio (SLO) Fornire definizioni tangibili di rendimento con cui fare un confronto soglie accettabili. Ad esempio, puoi definire i seguenti SLO: per il tuo sistema:

• Aggiornamento dei dati: genera il 90% dei consigli sui prodotti. dall'attività sul sito web dell'utente che si è verificata non oltre 3 minuti fa.

• Correttezza dei dati: nell'arco di un mese di calendario, meno dello 0,5% del le fatture dei clienti contengono errori.

• Isolamento dei dati/bilanciamento del carico: elabora tutti i dati entro un giorno lavorativo pagamenti con priorità elevata entro 10 minuti dall'invio, e completare i pagamenti con priorità standard entro il giorno lavorativo successivo.

Puoi utilizzare gli indicatori del livello del servizio (SLI) per misurare la conformità degli SLO. Gli SLI sono metriche quantificabili che indicano in che misura il tuo sistema soddisfa un determinato SLO. Ad esempio, puoi misurare lo SLO di aggiornamento dei dati di esempio utilizzando l'età dell'attività utente elaborata più di recente come SLI. Se le tue genera suggerimenti in base a eventi di attività utente e se il tuo SLI segnala un ritardo di 4 minuti tra l'ora dell'evento e quella in cui viene elaborato; i consigli non considerano l'attività sul sito web di un utente per più di 4 minuti. Se una pipeline che elabora i flussi di dati supera un sistema di 4 minuti, sai che lo SLO non è soddisfatto.

Poiché i componenti del sistema oltre la pipeline influiscono sullo SLO, è importante acquisire una serie di SLI che descrivono le prestazioni complessive del sistema al di là delle prestazioni della pipeline stessa, comprese le metriche che descrivono l'integrità end-to-end del tuo sistema. Ad esempio, La pipeline Dataflow potrebbe calcolare i risultati con un ritardo accettabile, ma potrebbe verificarsi un problema di prestazioni con un sistema downstream che influisce a SLO più ampi.

Per ulteriori informazioni sugli SLO importanti da considerare, consulta Site Reliability Engineering libro.

Aggiornamento dei dati

L'aggiornamento dei dati si riferisce all'usabilità dei dati in relazione alla loro età. La i seguenti SLO di aggiornamento dei dati sono menzionati nel Site Reliability Engineering libro come SLO di aggiornamento dei dati della pipeline più comune formati:

• X% dei dati elaborati in Y [secondi, giorni, minuti]. Questo SLO fa riferimento e rappresenta la percentuale di dati elaborati in un determinato periodo di tempo. it è comunemente utilizzato per le pipeline batch che elaborano origini dati limitate. La per questo tipo di SLO sono le dimensioni dei dati di input e di output i passaggi di elaborazione relativi al runtime della pipeline trascorso. Puoi scegliere un passaggio che legge un set di dati di input e un altro passaggio che elabora ogni elemento dell'input. Un esempio di SLO è "Per il gioco Shave the Yak, il 99% di le attività degli utenti che incidono i punteggi vengono presi in considerazione 30 minuti dopo il completamento della partita."

• I dati meno recenti non risalgono a più di X [secondi, giorni, minuti]. Questo Lo SLO fa riferimento all'età dei dati prodotti dalla pipeline. Di solito utilizzata per pipeline di flusso che elaborano dati da origini illimitate. Per questo tipo di SLO, usa metriche che indicano per quanto tempo per elaborare i dati. Due possibili metriche sono l'età l'elemento non elaborato più vecchio, ovvero per quanto tempo un elemento non elaborato è rimasto o l'età dell'articolo elaborato più di recente. Un esempio di SLO è I suggerimenti sui prodotti vengono generati dall'attività utente che è non più di 5 minuti".

• Il job della pipeline viene completato correttamente entro X [seconds, days, minutes]. Questo SLO stabilisce una scadenza per il completamento corretto comunemente utilizzata per le pipeline batch che elaborano i dati provenienti da dati limitati fonti. Questo SLO richiede il tempo totale trascorso dalla pipeline stato di completamento del lavoro, oltre ad altri indicatori che indicano dell'esito positivo del job, ad esempio la percentuale di elementi elaborati causare errori. Un esempio di SLO è "Ordini dei clienti giorno lavorativo in corso vengono elaborati entro le 09:00 del giorno successivo."

Per informazioni sull'utilizzo di Cloud Monitoring per misurare l'aggiornamento dei dati, Metriche dei job di Dataflow.

Correttezza dei dati

Per correttezza dei dati si intende che i dati sono privi di errori. Puoi determinare i dati la correttezza con più mezzi, tra cui:

• Test delle unità e test di integrazione, che puoi automatizzare utilizzando integrazione continua.

• Test end-to-end della pipeline, che puoi eseguire ambiente di preproduzione dopo che la pipeline ha superato i test delle unità e di integrazione. Puoi automatizzare i test end-to-end delle pipeline utilizzando distribuzione continua.

• Pipeline in esecuzione in produzione, quando utilizzi monitoring per osservare e le metriche relative alla correttezza dei dati.

Per le pipeline in esecuzione, la definizione di un target di correttezza dei dati di solito comporta a misurare la correttezza in un determinato periodo di tempo. Ad esempio:

• In base al singolo job, meno del X% degli elementi di input contiene dati errori. Puoi utilizzare questo SLO per misurare la correttezza dei dati per il batch pipeline di dati. Un esempio di SLO è "Per ogni job batch giornaliero da elaborare letture del contatore elettrico, meno del 3% delle letture contiene errori di inserimento dei dati."
• In una finestra di spostamento di X minuti, meno dell'Y% degli elementi di input contiene errori nei dati. Puoi utilizzare questo SLO per misurare la correttezza dei dati per pipeline di flusso. Un esempio di SLO è "Meno del 2% dell'elettricità le letture dello strumento di misurazione dell'ultima ora contengono valori negativi."

Per misurare questi SLO, usa le metriche su un periodo di tempo adeguato per il numero di errori per tipo. Esempi di tipi di errore sono i dati non sono corretti a causa di uno schema non corretto o i dati non rientrano in un intervallo valido.

Per informazioni sull'utilizzo di Cloud Monitoring per misurare la correttezza dei dati, vedi Metriche dei job di Dataflow.

Isolamento dei dati e bilanciamento del carico

L'isolamento dei dati prevede la segmentazione dei dati per attributo, che può rendere il carico bilanciare più facilmente la situazione. Ad esempio, in una piattaforma di elaborazione dei pagamenti online può segmentare i dati in modo che i singoli pagamenti abbiano priorità standard o priorità elevata. La pipeline può quindi utilizzare il bilanciamento del carico per garantire i pagamenti con priorità elevata vengono elaborati prima dei pagamenti con priorità standard.

Immagina di definire i seguenti SLO per l'elaborazione dei pagamenti:

• I pagamenti con priorità elevata vengono elaborati entro 10 minuti.
• I pagamenti con priorità standard vengono elaborati entro le 09:00 del giorno lavorativo successivo.

Se la piattaforma di pagamento è conforme a questi SLO, i clienti possono vedere pagamenti finalizzati ad alta priorità su una dashboard di reporting non appena vengono completati. Al contrario, i pagamenti standard potrebbero non essere visualizzati nella dashboard fino al giorno.

In questo scenario di esempio, sono disponibili le seguenti opzioni:

• Esegui un'unica pipeline per elaborare sia la priorità standard che per i pagamenti ad alta priorità.
• Isola e bilancia il carico dei dati in base alle priorità pipeline di dati.

Nelle sezioni seguenti viene descritta dettagliatamente ciascuna opzione.

Usa un'unica pipeline per la distribuzione rispetto a SLO misti

Il seguente diagramma illustra una singola pipeline utilizzata per elaborare i pagamenti con priorità elevata e standard. La pipeline riceve una notifica di nuovi pagamenti da un'origine dati in modalità flusso, come un argomento Pub/Sub o un Apache Kafka per ogni argomento. Quindi, elabora immediatamente i pagamenti e scrive gli eventi BigQuery con inserimenti di flussi di dati.

Il vantaggio di un'unica pipeline è che semplifica le operazioni perché devi gestire solo un'unica origine dati e una singola pipeline. Dataflow utilizza ottimizzazione automatica per aiutarti a eseguire il job nel modo più rapido ed efficiente possibile.

Uno svantaggio di una pipeline singola è che la pipeline condivisa non può assegnare la priorità pagamenti ad alta priorità rispetto ai pagamenti con priorità standard e risorse della pipeline sono condivisi tra i due tipi di pagamento. Nello scenario aziendale descritto in precedenza, la pipeline deve mantenere il più rigoroso dei due SLO. Vale a dire che deve utilizzare lo SLO per i pagamenti ad alta priorità, indipendentemente dal priorità dei pagamenti elaborati. Un altro svantaggio è che, nel caso di da un backlog di lavoro, la pipeline in modalità flusso non è in grado di assegnare la priorità al backlog e l'elaborazione in base all'urgenza del lavoro.

Usa più pipeline su misura per SLO specifici

Puoi usare due pipeline per isolare le risorse e distribuire a fronte di SLO specifici. Il seguente diagramma illustra questo approccio.

I pagamenti con priorità elevata sono isolati per l'elaborazione prioritaria. I pagamenti con priorità standard vengono elaborati una pipeline batch eseguita ogni giorno e che utilizza BigQuery load job per scrivere i risultati elaborati.

Isolare i dati in pipeline diverse presenta alcuni vantaggi. A inviare pagamenti ad alta priorità a fronte di SLO più restrittivi, velocizzare l'elaborazione volte ad alta priorità assegnando più risorse alla pipeline dedicata pagamenti. Le configurazioni delle risorse includono l'aggiunta Worker Dataflow, che utilizzano macchine di dimensioni maggiori e che con scalabilità automatica. Isolare gli elementi ad alta priorità in una coda di elaborazione separata mitigare i ritardi nell'elaborazione nel caso di un afflusso improvviso di priorità standard pagamenti.

Quando usi più pipeline per isolare e bilanciare il carico dei dati dai batch e flussi di sorgenti, il modello di programmazione Apache Beam consente le pipeline a priorità elevata (flusso) e a priorità standard (batch) per condividere lo stesso codice. L'unica eccezione è la trasformazione di lettura iniziale, che legge da un origine limitata per la pipeline batch. Per ulteriori informazioni, vedi Crea librerie di trasformazioni riutilizzabili.

Pianifica origini dati e sink

Per elaborare i dati, una pipeline di dati deve essere integrata con altri sistemi. Questi sistemi sono chiamati sorgenti e sink. Data pipelines leggono i dati dalle origini e scrivere dati nei sink. Oltre a origini e sink, i dati le pipeline possono interagire con sistemi esterni per l'arricchimento dei dati, l'applicazione di filtri, o chiamando la logica di business esterna in una fase di elaborazione.

Per la scalabilità, Dataflow esegue le fasi della pipeline in parallelo tra più worker. Fattori al di fuori del codice della pipeline e il servizio Dataflow influiscono anche sulla scalabilità della tua pipeline. tra cui:

• Scalabilità di sistemi esterni: i sistemi esterni che il tuo l'interazione della pipeline può limitare le prestazioni e formare limite superiore di scalabilità. Ad esempio, un Apache Kafka configurato con un numero di partizioni insufficiente per la lettura la velocità effettiva necessaria può influire sulle prestazioni della pipeline. A per garantire che la pipeline e i suoi componenti soddisfino le tue prestazioni target, consulta la documentazione sulle best practice per i sistemi esterni che stai utilizzando. Puoi anche semplificare la pianificazione della capacità dell'infrastruttura utilizzando i servizi Google Cloud che offrono scalabilità integrata. Per ulteriori informazioni le informazioni, vedi Utilizzo di origini e sink gestiti da Google Cloud in questa pagina.

• Scelta di formati dei dati: alcuni formati di dati potrebbero essere più veloci da più letti di altri. Ad esempio, usando formati di dati che supportano Letture parallelizzabili, come Avro, di solito sono più veloci rispetto all'uso di file CSV che includono a capo nei campi ed è più veloce rispetto all'utilizzo di .

• Località dei dati e topologia di rete: prossimità geografica e caratteristiche di networking di origini dati e sink in relazione e la pipeline di dati può influire sulle prestazioni. Per ulteriori informazioni, vedi Considerazioni per area geografica in questa pagina.

Chiamate ai servizi esterni

La chiamata a servizi esterni dalla pipeline comporta un overhead per chiamata che può per ridurre le prestazioni e l'efficienza della pipeline. Se la tua pipeline di dati chiama servizi esterni, per ridurre i costi generali, raggruppa più elementi di dati in un unico ove possibile. Molte applicazioni I/O native di Apache Beam le trasformazioni eseguono automaticamente questa attività, BigQueryIO e le operazioni di inserimento di flussi di dati. Oltre ai limiti di capacità, alcune applicazione di quote che limitano il numero totale di chiamate rispetto a un di un periodo di tempo, ad esempio una quota giornaliera, o limitare la frequenza delle chiamate, come il numero di richieste al secondo.

Poiché Dataflow parallelizza anche il lavoro su più worker una quantità eccessiva di traffico può sovraccaricare un servizio esterno o quote disponibili. Quando si utilizza la scalabilità automatica, Dataflow tentare di compensare aggiungendo worker per eseguire un passaggio lento come chiamata. L'aggiunta di worker può aumentare ulteriormente la pressione sui sistemi esterni. Assicurati che i sistemi esterni possono supportare i requisiti di carico previsti oppure limitare il traffico dalla pipeline a livelli sostenibili. Per ulteriori informazioni le informazioni, vedi Limita le dimensioni dei batch e le chiamate simultanee a servizi esterni.

Utilizza origini e sink gestiti di Google Cloud

Utilizzo dei servizi gestiti di Google Cloud con Dataflow elimina la complessità della gestione della capacità, fornendo servizi scalabilità, prestazioni coerenti, quote e limiti che soddisfano i tuoi requisiti. Devi comunque conoscere quote e limiti diversi per le operazioni della pipeline. Dataflow impone quote e limiti. Puoi aumentarne alcuni contattando Assistenza Google Cloud.

Dataflow utilizza le istanze VM di Compute Engine per eseguire di job, quindi è necessario disporre Quota di Compute Engine. Una quota di Compute Engine insufficiente può ostacolare la scalabilità automatica della pipeline che impediscono l'avvio dei job.

Le parti rimanenti di questa sezione esplorano i diversi modi in cui Google Cloud quote e limiti possono influenzare il modo in cui progetti, sviluppi e monitori una pipeline o un blocco note personalizzato. Pub/Sub e BigQuery sono utilizzati come esempi di origini e sink della pipeline.

Esempio 1: Pub/Sub

Quando usi Pub/Sub con Dataflow, Pub/Sub fornisce un servizio di importazione eventi scalabile e durevole per la distribuzione di messaggi da e verso le pipeline di dati in modalità flusso. Puoi usa la console Google Cloud per visualizzare Consumo della quota Pub/Sub e aumento dei limiti di quota. I nostri suggerimenti di richiedere un aumento della quota se hai una singola pipeline che supera le quote e i limiti per progetto.

Le quote e i limiti di Pub/Sub sono progettati a livello di progetto. In particolare, editori e abbonati in progetti diversi vengono assegnate quote di velocità effettiva dei dati indipendenti. Se più di pipeline di pubblicazione o sottoscrizione a un singolo argomento, puoi ottenere per quell'argomento eseguendo il deployment di ciascuna pipeline in un proprio progetto. Nel questa configurazione, ogni pipeline utilizza un diverso account di servizio basato su progetto utilizzare e pubblicare messaggi.

Nel diagramma seguente, Pipeline 1 e Pipeline 2 condividono lo stesso la quota di velocità effettiva di sottoscrittore e publisher disponibile per il progetto A. Nel Al contrario, Pipeline 3 può utilizzare l'intera velocità effettiva di sottoscrittore e publisher quota collegata al progetto B.

Più pipeline possono leggere da un singolo argomento Pub/Sub utilizzando sottoscrizioni separate all'argomento, il che consente a Dataflow per eseguire il pull e l'accettazione dei messaggi indipendentemente dagli altri sottoscrittori, come altre pipeline. Questa funzionalità semplifica la clonazione delle pipeline creando sottoscrizioni Pub/Sub aggiuntive. Creazione di altri è utile per creare pipeline di replica alta disponibilità (in genere per casi d'uso di flussi di dati), per eseguire pipeline di test degli stessi dati e per abilitare gli aggiornamenti della pipeline.

Esempio 2: BigQuery

Lettura e scrittura Dati BigQuery è supportata dall'SDK Apache Beam per vari linguaggi, tra cui Java, Python e Go. Quando utilizzi Java, lo strumento BigQueryIO offre questa funzionalità. BigQueryIO supporta metodi per la lettura dei dati: EXPORT (esportazione della tabella) e DIRECT_READ. I diversi metodi di lettura utilizzano quote di BigQuery diverse.

L'esportazione della tabella è il metodo di lettura predefinito. Funziona come illustrato di seguito. diagramma:

Il diagramma mostra il seguente flusso:

1. BigQueryIO richiama un Richiesta di esportazione BigQuery per esportare i dati della tabella. I dati della tabella esportati vengono scritti in un file Percorso di Cloud Storage.
2. BigQueryIO legge i dati della tabella dall'istanza temporanea Percorso di Cloud Storage.

Le richieste di BigQuery Export sono limitate da quote di esportazione. Anche la richiesta di esportazione deve essere completata prima che la pipeline possa iniziare l'elaborazione il che aggiunge ulteriore tempo di esecuzione per il job.

Al contrario, l'approccio alla lettura diretta utilizza API BigQuery Storage per leggere i dati delle tabelle direttamente da BigQuery. L'API BigQuery Storage offre prestazioni di lettura ad alta velocità effettiva per i dati delle righe di una tabella utilizzando gRPC. L'utilizzo dell'API BigQuery Storage rende non necessaria la fase di esportazione, evitando esporta i limiti di quota e potenzialmente riduce il tempo di esecuzione del job.

Il seguente diagramma mostra il flusso se utilizzi l'API BigQuery Storage. Nel a differenza del flusso che usa una richiesta di esportazione BigQuery. questo flusso è più semplice, perché ha un solo passaggio di lettura diretta per ottenere dai dati dalla tabella alla pipeline.

Anche la scrittura di dati nelle tabelle BigQuery ha una propria quota implicazioni. Pipeline batch che utilizzano il caricamento BigQuery dei job consumano diversi Quote dei job di caricamento BigQuery applicabili a livello di tabella e progetto. Analogamente, le pipeline in modalità flusso utilizza gli inserimenti di flussi di dati BigQuery consumano Quote di inserimento di flussi di dati BigQuery.

Per determinare i metodi più appropriati per leggere e scrivere dati, considera le caso d'uso. Ad esempio, evita di utilizzare il caricamento di BigQuery per aggiungere dati migliaia di volte al giorno in una tabella. Utilizza un flusso di dati per scrivere dati quasi in tempo reale in BigQuery. Il tuo streaming dovrebbe utilizzare gli inserimenti di flussi di dati o l'API Storage Scrivi a questo scopo.

Considerazioni a livello di regione

Dataflow è offerto come servizio gestito in più regioni Google Cloud Quando scegli una regione da utilizzare per eseguire i tuoi job, considera quanto segue fattori:

• La posizione di origini dati e sink
• Preferenze o limitazioni relative alle località di trattamento dei dati
• Funzionalità di Dataflow offerte solo in regioni specifiche
• La regione utilizzata per gestire l'esecuzione di un determinato job
• La zona utilizzata per i worker del job

Per un determinato job, l'impostazione della regione per il lavoro e per i worker possono variare. Per ulteriori informazioni, incluso quando specificare regioni e zone, consulta Documentazione sulle regioni Dataflow.

Specificando le regioni in cui eseguire i job Dataflow, puoi pianificare su considerazioni regionali per l'alta disponibilità e il ripristino di emergenza. Per ulteriori informazioni, vedi Alta disponibilità e ridondanza geografica.

Regioni

Le regioni Dataflow archiviano e gestiscono i metadati relativi al tuo job, ad esempio informazioni sul grafo Apache Beam stesso, come i nomi delle trasformazioni. Inoltre, e controllare i comportamenti dei worker, ad esempio la scalabilità automatica. Specificare una regione consente di soddisfare le esigenze di sicurezza e conformità, la località dei dati e il il posizionamento regionale di un'offerta di lavoro. Per evitare un impatto sulle prestazioni tra regioni, ti consigliamo di utilizzare la stessa regione e per i worker, se possibile.

Worker Dataflow

I job Dataflow utilizzano istanze VM di Compute Engine, dette Worker Dataflow per eseguire la pipeline. Dataflow i job possono utilizzare qualsiasi zona di Compute Engine per i worker, incluse le regioni in cui non esistono Località di Dataflow. Di specificando una regione worker per il job, puoi controllare il posizionamento dei tuoi lavoratori. Per specificare una regione o una zona dei worker:

• Se utilizzi gcloud CLI per creare un job da un modello Dataflow, utilizza --worker-region per eseguire l'override della regione worker oppure utilizza il flag --worker-zone per eseguire l'override della zona worker.
• Se utilizzi l'SDK Java Apache Beam per creare il job, imposta le regioni e zone per i worker opzioni della pipeline. Utilizza workerRegion per eseguire l'override della regione del worker o workerZone per eseguire l'override della zona worker.

Per migliorare la latenza e la velocità effettiva di rete, ti consigliamo di creare worker in una regione geograficamente vicina alle origini dati e ai sink. Se non specificare una regione o una zona per i worker quando crei un job Dataflow automaticamente il valore predefinito è una zona che si trova nella stessa regione del job.

Se non utilizzi il servizio Dataflow Shuffle o Streaming Engine, i dati elaborati dal job (ovvero i dati archiviati in PCollection) risiede sui worker del job, supponendo che nessun codice utente trasmette i dati all'esterno dei worker. Se la Dataflow Il servizio Shuffle o Streaming Engine è abilitato, il set di dati distribuito rappresentati da un oggetto PCollection, possono essere trasmessi tra i worker questi servizi.

Considerazioni sulla crittografia dei dati

Essendo un servizio completamente gestito, Dataflow cripta automaticamente i dati che si sposta attraverso la pipeline di dati utilizzando chiavi di proprietà di Google e gestite da Google e quelli at-rest. Anziché utilizzare le chiavi di proprietà di Google, puoi potrebbero preferire gestire personalmente la crittografia chiave. In questo caso, Dataflow supporta le chiavi di crittografia gestite dal cliente (CMEK) utilizzando Cloud Key Management Service (KMS). Puoi anche utilizzare Cloud HSM, un modulo di sicurezza hardware (HSM) ospitato nel cloud che consente di ospitare le chiavi di crittografia ed eseguire delle operazioni in un cluster FIPS 140-2 di livello 3 HSM certificati.

Quando utilizzi CMEK, Dataflow utilizza la chiave Cloud KMS per crittografare i dati, ad eccezione delle operazioni basate sulle chiavi di dati come windowing, raggruppamento e unione. Se le chiavi dei dati contengono dati sensibili, ad esempio informazioni che consentono l'identificazione personale (PII), devi eseguire l'hashing o la trasformazione delle chiavi prima che entrino nel Dataflow.

Considerazioni sul networking privato

I tuoi requisiti di rete e sicurezza potrebbero richiedere che i carichi di lavoro basati su VM come i job Dataflow usano solo indirizzi IP privati. Dataflow consente di specificare che i worker utilizzano l'IP privato indirizzi IP per tutte le comunicazioni di rete. Se gli IP pubblici sono disabilitati, deve attivare Accesso privato Google nella subnet, in modo che i worker Dataflow possano raggiungere le API di Google e servizi.

Ti consigliamo di disabilitare gli IP pubblici per i worker Dataflow, a meno che i job Dataflow non richiedano IP pubblici per accedere alla rete al di fuori di Google Cloud. La disabilitazione degli IP pubblici impedisce ai worker Dataflow di accedere a risorse al di fuori del subnet o di accedere a reti VPC peer. Analogamente, l'accesso di rete ai worker VM dall'esterno della subnet o del VPC peer viene impedita con le reti.

Per saperne di più sull'utilizzo dell'opzione pipeline --usePublicIps per se i worker devono avere solo IP privati, consulta Opzioni pipeline:

Passaggi successivi

• Sviluppa e testa la pipeline.
• Scopri di più sulla progettazione di flussi di lavoro completi della pipeline.
• Scopri di più su Google Pratiche di Site Reliability Engineering (SRE) per pipeline di elaborazione dati.