Pianifica la tua pipeline Dataflow

Questa pagina illustra alcune considerazioni importanti per la pianificazione della 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à. Questa pagina illustra vari aspetti di pianificazione per le pipeline Dataflow, tra cui:

• Aspettative di rendimento per le pipeline, inclusi gli standard per la misurabilità
• Integrazione delle pipeline con origini dati, sink e altro sistemi connessi
• Regionalizzazione di pipeline, origini e sink
• Sicurezza, ad esempio crittografia dei dati e reti private

Definire e misurare gli SLO

Un'importante misura del rendimento è il grado di soddisfazione della pipeline rispetto ai requisiti della tua attività. Obiettivi del livello di servizio (SLO) Fornire definizioni tangibili di rendimento con cui fare un confronto soglie accettabili. Ad esempio, potresti definire i seguenti SLO di esempio 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: in un mese di calendario, meno dello 0,5% delle fatture dei clienti contiene errori.

• Isolamento dei dati/load balancing: entro un giorno lavorativo, elabora tutti i pagamenti con priorità elevata entro 10 minuti dalla loro impostazione e completa i pagamenti con priorità standard entro il giorno lavorativo successivo.

Puoi utilizzare gli indicatori del livello del servizio (SLI) per misurare la conformità agli 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 dagli 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 dati in streaming supera una latenza del sistema di 4 minuti, significa che lo SLO non è soddisfatto.

Poiché i componenti di sistema oltre la pipeline influiscono sullo SLO, è importante acquisire una serie di SLI che descrivano il rendimento complessivo del sistema oltre a quello della pipeline stessa, incluse le metriche che descrivono lo stato end-to-end del 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 prendere in considerazione, consulta il libro Site Reliability Engineering.

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. Viene spesso utilizzato per le pipeline batch che elaborano origini dati limitate. Le metriche per questo tipo di SLO sono le dimensioni dei dati di input e di output nelle fasi di elaborazione chiave rispetto al tempo di esecuzione della pipeline trascorso. Puoi scegliere un 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% delle attività utente che influiscono sui punteggi dei giocatori viene preso in considerazione entro 30 minuti dal completamento della partita".

• I dati più vecchi 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 in modalità flusso che elaborano dati da origini illimitate. Per questo tipo di SLO, utilizza le metriche che indicano il tempo necessario alla pipeline 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 imposta una scadenza per il completamento e viene comunemente utilizzato per le pipeline batch che elaborano i dati da origini di dati limitate. Questo SLO richiede il tempo di esecuzione totale della pipeline e lo stato di completamento del job, oltre ad altri indicatori che indicano il successo del job, ad esempio la percentuale di elementi elaborati che generano 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 l'esattezza dei dati tramite diversi mezzi, tra cui:

• Test di unità e test di integrazione, che puoi automatizzare utilizzando l'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 il monitoraggio per osservare 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:

• Su base job, meno del X% degli elementi di input contiene errori nei dati. 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 un intervallo mobile di X minuti, meno del Y% degli elementi di input contiene errori nei dati. Puoi utilizzare questo SLO per misurare l'accuratezza dei dati per le pipeline di streaming. 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. Alcuni esempi di tipi di errori sono i dati incorrect 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 una singola pipeline per elaborare i pagamenti con priorità standard e prioritaria.
• Isola e bilancia il carico dei dati in base alle priorità pipeline di dati.

Le sezioni seguenti descrivono in dettaglio ogni opzione.

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

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

Il vantaggio di una singola pipeline è che semplifica i requisiti operativi, in quanto devi gestire solo un'origine dati e una pipeline. Dataflow utilizza funzionalità di ottimizzazione automatica per aiutarti a eseguire il job nel modo più rapido ed efficiente possibile.

Uno svantaggio di una singola pipeline è che non può dare la priorità ai pagamenti con priorità elevata rispetto a quelli con priorità standard e le risorse della pipeline sono condivise tra entrambi i 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, in caso di un backlog di lavoro, la pipeline di inserimento flussi non è in grado di dare la priorità all'elaborazione del backlog in base all'urgenza del lavoro.

Usa più pipeline su misura per SLO specifici

Puoi utilizzare due pipeline per isolare le risorse e pubblicare contenuti in base a SLO specifici. Il seguente diagramma illustra questo approccio.

I pagamenti ad alta priorità vengono isolati in una pipeline di streaming per l'elaborazione con priorità. I pagamenti con priorità standard vengono elaborati da una pipeline batch che viene eseguita quotidianamente e che utilizza i job di caricamento di BigQuery per scrivere i risultati elaborati.

L'isolamento dei dati in pipeline diverse presenta dei vantaggi. Per eseguire pagamenti con priorità elevata in base a SLO più stringenti, puoi ridurre i tempi di elaborazione assegnando più risorse alla pipeline dedicata ai pagamenti con priorità elevata. Le configurazioni delle risorse includono l'aggiunta di worker Dataflow, l'utilizzo di macchine più grandi e l'attivazione dell'autoscaling. L'isolamento degli elementi ad alta priorità in una coda di elaborazione separata può anche attenuare i ritardi di elaborazione in caso di un improvviso afflusso di pagamenti con priorità standard.

Quando utilizzi più pipeline per isolare e bilanciare il carico dei dati provenienti da origini in batch e in streaming, il modello di programmazione Apache Beam consente alle pipeline ad alta priorità (streaming) e a priorità standard (batch) di condividere lo stesso codice. L'unica eccezione è la trasformazione di lettura iniziale, che legge da un'origine delimitata 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 denominati origini e sink. Le pipeline di dati leggono i dati dalle origini e li scrivono negli sink. Oltre alle origini e ai destinazioni, le pipeline di dati possono interagire con sistemi esterni per l'arricchimento dei dati, il filtraggio o la chiamata di logica di business esterna all'interno di un passaggio di elaborazione.

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

• Scalabilità dei sistemi esterni: i sistemi esterni con cui interagisce la pipeline possono limitare il rendimento e costituire il limite superiore della scalabilità. Ad esempio, un argomento Apache Kafka configurato con un numero insufficiente di partizioni per il throughput di lettura necessario può influire sul rendimento 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, consulta Utilizzare origini e destinazioni gestite da Google Cloud in questa pagina.

• Scelta dei formati dei dati: alcuni formati dei dati possono essere più rapidi da leggere rispetto ad altri. Ad esempio, l'utilizzo di formati di dati che supportano letture parallelizzabili, come Avro, è in genere più veloce rispetto all'utilizzo di file CSV con interruzioni di riga incorporate nei campi e rispetto all'utilizzo di file compressi.

• Posizione dei dati e topologia di rete: la vicinanza geografica e le caratteristiche di rete delle origini dati e degli sink in relazione alla pipeline di dati potrebbero 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 pipeline di dati chiama servizi esterni, per ridurre i costi generali, raggruppa più elementi di dati in singole richieste, se possibile. Molte trasformazioni I/O native di Apache Beam eseguono automaticamente questa attività, tra cui BigQueryIO e le operazioni di inserimento in streaming. Oltre ai limiti di capacità, alcuni servizi esterni applicano anche quote che limitano il numero totale di chiamate in un determinato periodo di tempo, ad esempio una quota giornaliera, o limitano la frequenza di chiamata, ad esempio 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, consulta Limitare le dimensioni dei batch e le chiamate simultanee ai servizi esterni.

Utilizza origini e sink gestiti di Google Cloud

L'utilizzo dei servizi gestiti di Google Cloud con la pipeline Dataflow rimuove la complessità della gestione della capacità fornendo scalabilità integrata, prestazioni coerenti e quote e limiti che soddisfano la maggior parte dei requisiti. Devi comunque conoscere quote e limiti diversi per le operazioni della pipeline. Dataflow stesso impone quote e limiti. Puoi aumentarne alcuni contattando Assistenza Google Cloud.

Dataflow utilizza istanze VM di Compute Engine per eseguire i job, quindi devi disporre di una quota Compute Engine sufficiente. 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. Ti consigliamo di richiedere un aumento della quota se una singola pipeline 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. In questa configurazione, ogni pipeline utilizza un account di servizio basato su progetto diverso per consumare e pubblicare i 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. Nella 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 alle pipeline Dataflow di estrarre e confermare i messaggi indipendentemente da 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

La lettura e la scrittura di dati BigQuery è supportata dall'SDK Apache Beam per più linguaggi, tra cui Java, Python e Go. Quando utilizzi Java, la classe BigQueryIO fornisce questa funzionalità. BigQueryIO supporta due metodi per leggere i dati: EXPORT (esportazione di tabelle) e DIRECT_READ. I diversi metodi di lettura utilizzano quote di BigQuery diverse.

L'esportazione della tabella è il metodo di lettura predefinito. Funziona come mostrato nel seguente 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 una posizione Cloud Storage temporanea.
2. BigQueryIO legge i dati della tabella dall'istanza temporanea Percorso di Cloud Storage.

Le richieste di esportazione di BigQuery sono limitate dalle 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à per i dati delle righe della tabella utilizzando gRPC. L'utilizzo dell'API BigQuery Storage rende superfluo il passaggio di esportazione, il che evita le limitazioni delle quote di esportazione e potenzialmente riduce il tempo di esecuzione del job.

Il seguente diagramma mostra il flusso se utilizzi l'API BigQuery Storage. Nella 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. Le pipeline batch che utilizzano i job di caricamento BigQuery consumano diverse quote per i job di caricamento BigQuery che si applicano 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 i dati, prendi in considerazione il tuo caso d'uso. Ad esempio, evita di utilizzare il caricamento BigQuery per aggiungere dati migliaia di volte al giorno a una tabella. Utilizza una pipeline di streaming per scrivere dati quasi in tempo reale in BigQuery. A questo scopo, la pipeline di streaming deve utilizzare gli inserimenti in streaming o l'API Storage Write.

Considerazioni a livello di regione

Dataflow è offerto come servizio gestito in più regioni Google Cloud Quando scegli una regione da utilizzare per eseguire i 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 che utilizzi per il job e per i worker può essere diversa. 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 le 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. La specifica di una regione ti aiuta a soddisfare le tue esigenze in termini di sicurezza e conformità, località dei dati e collocamento regionale di un job. 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 le istanze VM di Compute Engine, chiamate 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. Specificando una regione di worker per il job, puoi controllare il posizionamento regionale degli worker. 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 Apache Beam Java per creare il job, imposta le regioni e le zone per i worker utilizzando le opzioni della pipeline. Utilizza workerRegion per eseguire l'override della regione del worker o workerZone per eseguire l'override della zona del 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 specifichi una regione o una zona per i worker quando crei un job, Dataflow imposta automaticamente 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 qualsiasi PCollection oggetto) risiedono nei worker del job, supponendo che nessun codice utente trasmetta dati all'esterno dei worker. Se il servizio Dataflow Shuffle o Streaming Engine è attivato, il set di dati distribuito rappresentato da un oggetto PCollection può essere trasmesso tra i worker e 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 servizio per moduli di sicurezza hardware (HSM) ospitato nel cloud che consente di ospitare chiavi di crittografia ed eseguire operazioni crittografiche in un cluster di HSM certificati FIPS 140-2 di livello 3.

Quando utilizzi CMEK, Dataflow utilizza la tua chiave Cloud KMS per criptare i dati, tranne che per le operazioni basate su chiavi di dati come finestre, raggruppamenti e unioni. Se le chiavi di dati contengono dati sensibili, ad esempio informazioni che consentono l'identificazione personale (PII), devi sottoporle ad hashing o trasformarle in altro modo prima che entrino nella pipeline Dataflow.

Considerazioni sul networking privato

I requisiti di rete e sicurezza potrebbero prevedere che i carichi di lavoro basati su VM, come i job Dataflow, utilizzino 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 abilitare Accesso privato Google nella subnet, in modo che i worker Dataflow possano raggiungere le API di Google e servizi.

Ti consigliamo di disattivare gli IP pubblici per i worker di Dataflow, a meno che i tuoi job di Dataflow non richiedano indirizzi IP pubblici per accedere alle risorse di 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, viene impedito l'accesso alla rete dei worker VM dall'esterno della sottorete o delle reti VPC peer.

Per ulteriori informazioni sull'utilizzo dell'opzione della pipeline --usePublicIps per specificare se i worker devono avere solo IP privati, consulta Opzioni della pipeline.

Passaggi successivi

• Sviluppa e testa la tua 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.