Pianifica la pipeline Dataflow

Questa pagina illustra considerazioni importanti per la pianificazione della pipeline di dati prima di iniziare lo sviluppo del codice. Data pipelines spostano i dati da un sistema all'altro e sono spesso componenti fondamentali dei sistemi informativi aziendali. Le prestazioni e l'affidabilità della pipeline di dati possono influire su questi sistemi più ampi e sull'efficacia con cui vengono soddisfatti i requisiti aziendali.

Se pianifichi le pipeline di dati prima di svilupparle, puoi migliorarne le prestazioni e l'affidabilità. Questa pagina illustra varie considerazioni di pianificazione per le pipeline Dataflow, tra cui:

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

Definisci e misura gli SLO

Una misura importante del rendimento è il grado in cui la pipeline soddisfa i requisiti aziendali. Gli obiettivi del livello di servizio (SLO) forniscono definizioni tangibili delle prestazioni che puoi confrontare con 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 in base all'attività degli utenti sul sito web avvenuta non più di 3 minuti prima.

• Correttezza dei dati: entro un mese di calendario, meno dello 0,5% delle fatture dei clienti contiene errori.

• Isolamento/bilanciamento del carico dei dati: entro un giorno lavorativo, elabora tutti i pagamenti ad alta priorità entro 10 minuti dal deposito e completa i pagamenti a 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 il livello di efficacia del sistema rispetto a un determinato SLO. Ad esempio, puoi misurare l'SLO di aggiornamento dei dati di esempio utilizzando l'età dell'attività utente elaborata più di recente come SLI. Se la tua pipeline genera consigli a partire dagli eventi di attività utente e se il tuo SLI segnala un ritardo di 4 minuti tra l'ora dell'evento e l'ora in cui l'evento viene elaborato, i consigli non tengono conto dell'attività dell'utente sul sito web precedente a 4 minuti. Se una pipeline che elabora dati di streaming supera una latenza di sistema di 4 minuti, sai che l'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 al rendimento 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 su SLO più ampi.

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

Aggiornamento dei dati

L'aggiornamento dei dati si riferisce all'usabilità dei dati in relazione alla loro età. Nel libro Site Reliability Engineering vengono menzionati i seguenti SLO di aggiornamento dei dati come formati più comuni per gli SLO di aggiornamento dei dati della pipeline:

• X% dei dati elaborati in Y [secondi, giorni, minuti]. Questo SLO si riferisce alla percentuale di dati elaborati in un determinato periodo di tempo. Viene comunemente utilizzato per le pipeline batch che elaborano origini dati delimitate. Le metriche per questo tipo di SLO sono le dimensioni dei dati di input e output nelle fasi di elaborazione chiave rispetto al tempo di esecuzione 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% delle attività degli utenti che influiscono sui punteggi dei giocatori viene conteggiato entro 30 minuti dal completamento della partita".

• I dati meno recenti non risalgono a più di X [secondi, giorni, minuti]. Questo SLO si riferisce all'età dei dati prodotti dalla pipeline. Viene comunemente utilizzato per le pipeline di streaming che elaborano i dati provenienti da origini illimitate. Per questo tipo di SLO, utilizza metriche che indicano il tempo necessario alla pipeline per elaborare i dati. Due possibili metriche sono l'età dell'elemento non elaborato più vecchio, ovvero da quanto tempo un elemento non elaborato si trova nella coda, o l'età dell'elemento elaborato più di recente. Un esempio di SLO è: "I consigli sui prodotti vengono generati dall'attività utente non più vecchia di 5 minuti".

• Il job di pipeline viene completato correttamente entro X [secondi, giorni, minuti]. Questo SLO imposta una scadenza per il completamento e viene comunemente utilizzato per le pipeline batch che elaborano i dati da origini dati limitate. Questa SLO richiede il tempo totale trascorso della pipeline e lo stato di completamento del job, oltre ad altri indicatori che indicano la riuscita del job, ad esempio la percentuale di elementi elaborati che generano errori. Un esempio di SLO è "Gli ordini dei clienti del giorno lavorativo corrente vengono elaborati entro le 9:00 del giorno successivo".

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

Correttezza dei dati

Correttezza dei dati indica che i dati sono privi di errori. Puoi determinare la correttezza dei dati in diversi modi, tra cui:

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

• Test della pipeline end-to-end, che puoi eseguire in un ambiente di preproduzione dopo che la pipeline supera correttamente i test unitari e di integrazione. Puoi automatizzare i test end-to-end della pipeline utilizzando la distribuzione continua.

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

Per l'esecuzione delle pipeline, la definizione di un target di correttezza dei dati di solito comporta la misurazione della correttezza in un periodo di tempo. Ad esempio:

• Per ogni job, meno del X% degli elementi di input contiene errori nei dati. Puoi utilizzare questo SLO per misurare la correttezza dei dati per le pipeline batch. Un esempio di SLO è "Per ogni job batch giornaliero per l'elaborazione delle letture del contatore dell'elettricità, meno del 3% delle letture contiene errori di inserimento dei dati".
• In una finestra mobile di X minuti, meno del Y% degli elementi di input contiene errori nei dati. Puoi utilizzare questo SLO per misurare la correttezza dei dati per le pipeline di streaming. Un esempio di SLO è "Meno del 2% delle letture del contatore dell'elettricità nell'ultima ora contiene valori negativi".

Per misurare questi SLO, utilizza le metriche in un periodo di tempo adeguato per accumulare il numero di errori per tipo. Alcuni esempi di tipi di errori sono i dati non corretti a causa di uno schema non valido o i dati al di fuori di un intervallo valido.

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

Isolamento dei dati e bilanciamento del carico

L'isolamento dei dati comporta la segmentazione dei dati per attributo, il che può semplificare il bilanciamento del carico. Ad esempio, in una piattaforma di elaborazione dei pagamenti online, puoi segmentare i dati in modo che i singoli pagamenti abbiano priorità standard o alta. La pipeline può quindi utilizzare il bilanciamento del carico per garantire che i pagamenti ad alta priorità vengano elaborati prima di quelli a priorità standard.

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

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

Se la piattaforma di pagamento rispetta questi SLO, i clienti possono visualizzare i pagamenti ad alta priorità finalizzati in una dashboard dei report man mano che vengono completati. Al contrario, i pagamenti standard potrebbero non essere visualizzati nella dashboard fino al giorno successivo.

In questo scenario di esempio, hai le seguenti opzioni:

• Esegui una singola pipeline per elaborare i pagamenti con priorità standard e priorità elevata.
• Isola e bilancia il carico dei dati in base alle priorità in più pipeline.

Le sezioni seguenti descrivono in dettaglio ciascuna opzione.

Utilizzare una singola pipeline per rispettare gli SLO misti

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

Il vantaggio di una singola pipeline è che semplifica i requisiti operativi, perché devi gestire una sola origine dati e una sola pipeline. Dataflow utilizza funzionalità di ottimizzazione automatica per eseguire il job nel modo più rapido ed efficiente possibile.

Uno svantaggio di una singola pipeline è che la pipeline condivisa non può dare la priorità ai pagamenti ad alta priorità rispetto a quelli a 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 lo SLO più rigoroso tra i due. ovvero la pipeline deve utilizzare l'SLO per i pagamenti ad alta priorità indipendentemente dalla priorità effettiva dei pagamenti elaborati. Un altro svantaggio è che in caso di backlog di lavoro, la pipeline di streaming non è in grado di dare la priorità all'elaborazione del backlog in base all'urgenza del lavoro.

Utilizzare più pipeline personalizzate per SLO specifiche

Puoi utilizzare due pipeline per isolare le risorse e rispettare SLA specifiche. Il seguente diagramma illustra questo approccio.

I pagamenti ad alta priorità sono isolati in una pipeline di streaming per l'elaborazione prioritaria. I pagamenti con priorità standard vengono elaborati da una pipeline batch 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 effettuare pagamenti ad alta priorità in base a SLO più rigorosi, puoi ridurre i tempi di elaborazione assegnando più risorse alla pipeline dedicata ai pagamenti ad alta priorità. Le configurazioni delle risorse includono l'aggiunta di worker Dataflow, l'utilizzo di macchine più grandi e l'attivazione dello scalabilità automatica. L'isolamento degli elementi ad alta priorità in una coda di elaborazione separata può anche mitigare i ritardi di elaborazione in caso di improvviso afflusso di pagamenti con priorità standard.

Quando utilizzi più pipeline per isolare e bilanciare il carico dei dati provenienti da origini batch e 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 saperne di più, consulta Creare librerie di trasformazioni riutilizzabili.

Pianificare 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. Data pipelines leggono i dati dalle origini e li scrivono nei sink. Oltre a origini e sink, le pipeline di dati potrebbero interagire con sistemi esterni per l'arricchimento, 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. Anche fattori esterni al codice della pipeline e al servizio Dataflow influiscono sulla scalabilità della pipeline. Questi fattori potrebbero includere quanto segue:

• Scalabilità dei sistemi esterni: i sistemi esterni con cui interagisce la tua pipeline possono limitare le prestazioni e costituire il limite superiore della scalabilità. Ad esempio, un argomento Apache Kafka configurato con un numero insufficiente di partizioni per la velocità effettiva di lettura di cui hai bisogno può influire sulle prestazioni della pipeline. Per assicurarti che la pipeline e i relativi componenti soddisfino i tuoi target di rendimento, consulta la documentazione sulle best practice per i sistemi esterni che utilizzi. Puoi anche semplificare la pianificazione della capacità dell'infrastruttura utilizzando i servizi Google Cloud che forniscono scalabilità integrata. Per saperne di più, consulta la sezione Utilizzare origini e sink gestiti in questa pagina. Google Cloud

• Scelta dei formati dei dati: alcuni formati dei dati potrebbero essere più veloci da leggere rispetto ad altri. Ad esempio, l'utilizzo di formati di dati che supportano letture parallelizzabili, come Avro, è in genere più veloce dell'utilizzo di file CSV con nuove righe incorporate nei campi ed è più veloce dell'utilizzo di file compressi.

• Posizione dei dati e topologia di rete: la vicinanza geografica e le caratteristiche di rete delle origini e delle destinazioni dei dati in relazione alla pipeline di dati potrebbero influire sulle prestazioni. Per ulteriori informazioni, consulta la sezione Considerazioni regionali in questa pagina.

Chiamate a servizi esterni

La chiamata di servizi esterni dalla pipeline comporta costi generali per chiamata che possono ridurre le prestazioni e l'efficienza della pipeline. Se la pipeline di dati chiama servizi esterni, per ridurre i sovraccarichi, raggruppa più elementi di dati in singole richieste, se possibile. Molte trasformazioni I/O Apache Beam native eseguono automaticamente questa attività, tra cui BigQueryIO e operazioni di inserimento di flussi di dati. Oltre ai limiti di capacità, alcuni servizi esterni applicano anche quote che limitano il numero totale di chiamate in un periodo di tempo, ad esempio una quota giornaliera, o limitano la frequenza delle chiamate, ad esempio il numero di richieste al secondo.

Poiché Dataflow parallelizza il lavoro su più worker, un traffico eccessivo può sovraccaricare un servizio esterno o esaurire le quote disponibili. Quando viene utilizzata la scalabilità automatica, Dataflow potrebbe tentare di compensare aggiungendo worker per eseguire un passaggio lento come una chiamata esterna. L'aggiunta di worker può esercitare ulteriore pressione sui sistemi esterni. Assicurati che i sistemi esterni possano supportare i requisiti di carico previsti oppure limita il traffico della pipeline a livelli sostenibili. Per ulteriori informazioni, vedi Limitare le dimensioni dei batch e le chiamate simultanee a servizi esterni.

Utilizzare Google Cloud origini e sink gestiti

L'utilizzo di Google Cloud servizi gestiti con la pipeline Dataflow elimina la complessità della gestione della capacità fornendo scalabilità integrata, prestazioni coerenti e quote e limiti che soddisfano la maggior parte dei requisiti. Devi comunque essere a conoscenza delle diverse quote e dei limiti per le operazioni della pipeline. Dataflow stesso impone quote e limiti. Puoi aumentare alcuni di questi limiti contattando l'Google Cloud assistenza.

Dataflow utilizza le istanze VM di Compute Engine per eseguire i tuoi job, pertanto hai bisogno di una quota di Compute Engine sufficiente. Una quota di Compute Engine insufficiente può ostacolare la scalabilità automatica della pipeline o impedire l'avvio dei job.

Le parti rimanenti di questa sezione esplorano in che modo quote e limiti diversi possono influire sulla progettazione, lo sviluppo e il monitoraggio della pipeline. Google CloudPub/Sub e BigQuery vengono utilizzati come esempi di origini e sink della pipeline.

Esempio 1: Pub/Sub

Quando utilizzi Pub/Sub con Dataflow, Pub/Sub fornisce un servizio di importazione di eventi scalabile e duraturo per la distribuzione di messaggi alle e dalle pipeline di dati di streaming. Puoi utilizzare la console Google Cloud per visualizzare il consumo di quota di Pub/Sub e aumentare i limiti di quota. Ti consigliamo 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 in base all'utilizzo a livello di progetto. Nello specifico, publisher e sottoscrittori in progetti diversi ricevono quote di velocità effettiva dei dati indipendenti. Se più pipeline pubblicano o si iscrivono a un singolo argomento, puoi ottenere la velocità effettiva massima consentita per quell'argomento eseguendo il deployment di ogni pipeline nel proprio progetto. In questa configurazione, ogni pipeline utilizza un account di servizio basato su un progetto diverso per utilizzare e pubblicare i messaggi.

Nel seguente diagramma, Pipeline 1 e Pipeline 2 condividono la stessa quota di throughput di publisher e subscriber disponibile per Project A. Al contrario, Pipeline 3 può utilizzare l'intera quota di velocità effettiva di abbonati ed editori associata 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 eseguire il pull e confermare i messaggi indipendentemente da altri sottoscrittori, come altre pipeline. Questa funzionalità semplifica la clonazione delle pipeline creando sottoscrizioni Pub/Sub aggiuntive. La creazione di abbonamenti aggiuntivi è utile per creare pipeline di replica per l'alta disponibilità (in genere per i casi d'uso di streaming), per eseguire pipeline di test aggiuntive sugli stessi dati e per abilitare gli aggiornamenti delle pipeline.

Esempio 2: BigQuery

La lettura e la scrittura dei dati BigQuery sono supportate 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 la lettura dei dati: EXPORT (esportazione della tabella) e DIRECT_READ. I diversi metodi di lettura utilizzano quote 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 una richiesta di esportazione BigQuery per esportare i dati della tabella. I dati della tabella esportati vengono scritti in una posizione temporanea di Cloud Storage.
2. BigQueryIO legge i dati della tabella dalla posizione temporanea di Cloud Storage.

Le richieste di esportazione BigQuery sono limitate dalle quote di esportazione. La richiesta di esportazione deve essere completata prima che la pipeline possa iniziare a elaborare i dati, il che aggiunge ulteriore tempo di esecuzione al job.

Al contrario, l'approccio di lettura diretta utilizza l'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 della tabella utilizzando gRPC. L'utilizzo dell'API BigQuery Storage rende superfluo il passaggio di esportazione, il che evita le limitazioni della quota di esportazione e potenzialmente riduce il tempo di esecuzione del job.

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

Anche la scrittura di dati nelle tabelle BigQuery ha le sue implicazioni in termini di quota. Le pipeline batch che utilizzano i job di caricamento BigQuery consumano quote diverse per i job di caricamento BigQuery che si applicano a livello di tabella e progetto. Allo stesso modo, le pipeline di streaming che utilizzano gli inserimenti di flussi di dati BigQuery consumano le quote di inserimento di flussi di dati BigQuery.

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

Considerazioni regionali

Dataflow è offerto come servizio gestito in più Google Cloud regioni. Quando scegli una regione da utilizzare per eseguire i job, considera i seguenti 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 saperne di più, incluso quando specificare regioni e zone, consulta la documentazione sulle regioni Dataflow.

Specificando le regioni in cui eseguire i job Dataflow, puoi pianificare in base alle considerazioni regionali per l'alta disponibilità eripristino di emergenzay. Per maggiori informazioni, consulta Alta disponibilità e ridondanza geografica.

Regioni

Le regioni Dataflow archiviano e gestiscono i metadati relativi al tuo job, ad esempio le informazioni sul grafico Apache Beam stesso, come i nomi delle trasformazioni. Controllano anche il comportamento dei worker, ad esempio la scalabilità automatica. La specifica di una regione ti aiuta a soddisfare le tue esigenze di sicurezza e conformità, localizzazione dei dati e posizionamento regionale di un job. Per evitare un impatto sulle prestazioni delle chiamate di rete tra regioni, ti consigliamo di utilizzare la stessa regione per il job e per i worker, se possibile.

Dataflow workers

I job Dataflow utilizzano le istanze VM di Compute Engine, chiamate worker Dataflow, per eseguire la pipeline. I job Dataflow possono utilizzare qualsiasi zona Compute Engine per i worker, incluse le regioni in cui non sono presenti posizioni Dataflow. Se specifichi una regione worker per il tuo job, puoi controllare il posizionamento regionale dei tuoi worker. Per specificare una regione o una zona di worker:

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

Per migliorare la latenza e la velocità effettiva della rete, ti consigliamo di creare worker in una regione geograficamente vicina alle origini e alle destinazioni dei dati. Se non specifichi una regione o una zona per i worker quando crei un job, Dataflow imposta automaticamente una zona predefinita 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 oggetto PCollection) risiedono sui worker del job, supponendo che nessun codice utente trasmetta dati all'esterno dei worker. Se è attivato il servizio Dataflow Shuffle o Streaming Engine, il set di dati distribuito rappresentato da un oggetto PCollection può essere trasmesso tra i worker e questi servizi.

Considerazioni sulla crittografia dei dati

In quanto servizio completamente gestito, Dataflow cripta automaticamente i dati che si spostano nella pipeline di dati utilizzando Google-owned and Google-managed encryption keys sia per i dati in transito sia per i dati archiviati. Anziché utilizzare Google-owned and Google-managed encryption keys, potresti preferire gestire le tue chiavi di crittografia. 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 modulo 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 chiave Cloud KMS per criptare i dati, ad eccezione delle operazioni basate su chiavi dei dati come la suddivisione in finestre, il raggruppamento e l'unione. Se le chiavi dei dati contengono dati sensibili, ad esempio informazioni che consentono l'identificazione personale (PII), devi eseguire l'hashing o trasformare in altro modo le chiavi prima che entrino nella pipeline 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, utilizzino solo indirizzi IP privati. Dataflow consente di specificare che i worker utilizzano indirizzi IP privati per tutte le comunicazioni di rete. Se gli IP pubblici sono disabilitati, devi attivare l'accesso privato Google nella subnet in modo che i worker Dataflow possano raggiungere le API e i servizi Google.

Ti consigliamo di disabilitare gli IP pubblici per i worker Dataflow, a meno che i job Dataflow non richiedano IP pubblici per accedere alle risorse di rete al di fuori di Google Cloud. La disattivazione degli IP pubblici impedisce ai worker Dataflow di accedere a risorse esterne alla subnet o alle reti VPC peer. Analogamente, l'accesso alla rete ai worker VM dall'esterno della subnet o delle reti VPC peer è impedito.

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

Passaggi successivi

• Sviluppa e testa la pipeline.
• Scopri di più sulla progettazione di workflow completi della pipeline.
• Scopri di più sulle pratiche di Site Reliability Engineering (SRE) di Google per le pipeline di elaborazione dei dati.