Regioni Dataflow

La regione Dataflow archivia e gestisce i metadati relativi al tuo job Dataflow ed esegue il deployment e il controllo dei tuoi worker Dataflow.

I nomi delle regioni seguono una convenzione standard basata su Nomi delle regioni di Compute Engine. Ad esempio, il nome della regione degli Stati Uniti centrali è us-central1.

Questa funzionalità è disponibile in tutte le regioni in cui è supportato Dataflow. Per visualizzare le località disponibili, consulta Località di Dataflow.

Linee guida per la scelta di una regione

Attieniti alle linee guida riportate di seguito per scegliere un'area geografica appropriata per il job.

Sicurezza e conformità

Potresti dover limitare l'elaborazione del job Dataflow a un geografica a supporto delle esigenze di sicurezza e conformità del tuo progetto.

Località di dati

Puoi ridurre al minimo la latenza di rete e i costi di trasporto della rete eseguendo una Job Dataflow dalla stessa regione delle origini, dei sink, delle posizioni dei file temporanei e le posizioni dei file temporanei. Se utilizzi origini, sink, posizioni dei file temporanei di posizioni dei file temporanei o che si trovano al di fuori della regione del job, potrebbero essere inviati tra regioni diverse.

Durante l'esecuzione di una pipeline, i dati utente vengono gestiti solo dal pool di worker di Dataflow e il trasferimento dei dati è limitato ai percorsi di rete che collegano i worker di Dataflow nel pool.

Sebbene i dati utente vengano gestiti rigorosamente dai worker Dataflow regione assegnata, i messaggi di log della pipeline sono archiviati Cloud Logging, che ha una singola presenza globale in in Google Cloud.

Se hai bisogno di un maggiore controllo sulla posizione dei messaggi di log della pipeline, puoi fare quanto segue:

1. Crea un filtro di esclusione per il sink del router dei log _Default per impedire l'esportazione dei log di Dataflow nel bucket dei log _Default.
2. Crea un bucket di log nella regione che preferisci.
3. Configura un nuovo sink del router dei log che esporterà i log di Dataflow nel nuovo bucket di log.

Per saperne di più sulla configurazione del logging, consulta Panoramica su routing e archiviazione e Panoramica del routing dei log.

Note sulle origini dei job Dataflow comuni:

• Quando utilizzi un bucket Cloud Storage come origine, ti consigliamo di eseguire operazioni di lettura nella stessa regione del bucket.
• Gli argomenti Pub/Sub, quando vengono pubblicati nell'endpoint Pub/Sub globale, vengono archiviati nella regione Google Cloud più vicina. Tuttavia, puoi modificare il criterio di archiviazione dell'argomento in un criterio una regione o un insieme di regioni. Analogamente, gli argomenti Pub/Sub Lite supportano solo lo spazio di archiviazione a livello di zona.

Resilienza e separazione geografica

Potresti voler isolare le normali operazioni Dataflow e che potrebbero verificarsi in altre regioni geografiche. In alternativa, potresti dover pianificare siti alternativi per la continuità aziendale in caso di calamità in tutta la regione.

Nei tuoi piani di ripristino di emergenza e continuità aziendale, ti consigliamo di includere i dettagli relativi alle fonti e ai sink utilizzati con il tuo di job Dataflow. Il team di vendita di Google Cloud può aiutarti a soddisfare i tuoi requisiti.

Posizionamento regionale

Per impostazione predefinita, la regione selezionata configura il Dataflow pool di worker per utilizzare tutte le zone disponibili all'interno della regione. La selezione della zona è viene calcolata per ogni worker al momento della creazione, ottimizzando per la risorsa l'acquisizione e l'utilizzo di dati prenotazioni.

Il posizionamento regionale offre vantaggi quali:

• Maggiore disponibilità delle risorse: i job Dataflow sono più resilienti agli errori di disponibilità delle risorse a livello di zona, perché i worker possono continuare a essere creati in altre zone con disponibilità rimanente.
• Affidabilità migliorata: in caso di errore a livello di zona, i job Dataflow possono continuare a essere eseguiti perché i worker vengono ricreati in altre zone.

Si applicano le seguenti limitazioni:

• Il posizionamento a livello di regione è supportato solo per i job che utilizzano Streaming Engine o Dataflow Shuffle. Job che hanno disattivato Streaming Engine oppure Dataflow Shuffle non può usare il posizionamento a livello di regione.
• Il posizionamento a livello di regione si applica solo alle VM e non alle risorse di backend.
• Le VM non vengono replicate in più zone. Ad esempio, se una VM non è più disponibile, i relativi elementi di lavoro vengono considerati persi e vengono sottoposti a nuovo trattamento da un'altra VM.
• Se si verifica un'interruzione dell'inventario a livello di regione, il servizio Dataflow non può creare altre VM.

Visualizzare le zone di risorse dei job

I job Dataflow dipendono dalle risorse interne. Alcune di queste risorse dei job di backend sono zonali. Se si verifica un errore in una singola zona e occorre una risorsa di zona del job Dataflow si trova in quella zona, il job potrebbe avere esito negativo.

Per capire se un job non è riuscito a causa di un'interruzione a livello di zona, Rivedi le zone di servizio utilizzate dalle risorse di backend del tuo job. Questa funzionalità è disponibile solo per i job di Streaming Engine.

• Per visualizzare le zone di servizio nel nella console Google Cloud, utilizza il campo Zone di servizio Riquadro Informazioni job.

• Per utilizzare l'API al fine di rivedere le zone di servizio, utilizza ServiceResources .

I valori in questo campo vengono aggiornati per tutta la durata del job, poiché le risorse utilizzate dal job cambiano durante l'esecuzione.

Posizionamento automatico della zona

Per i job non supportati per il posizionamento a livello di regione, la zona migliore della regione viene selezionata automaticamente, in base alle di capacità della zona al momento della richiesta di creazione del job. Selezione automatica della zona contribuisce a garantire che i worker del job vengano eseguiti nella zona migliore per il tuo job.

Poiché il job è configurato per essere eseguito in una singola zona, l'operazione potrebbe non riuscire con un disponibilità delle risorse a livello di zona se non sono disponibili risorse Compute Engine sufficienti.

Inoltre, quando una zona non è disponibile, il backend di flussi di dati può diventare non è disponibile, il che potrebbe causare una perdita di dati.

Specifica una regione

Per specificare una regione per il job, imposta l'opzione --region su una delle regioni supportate. L'opzione --region sostituisce la regione predefinita impostata nel server dei metadati, nel client locale o nelle variabili di ambiente.

L'interfaccia a riga di comando di Dataflow supporta anche l'opzione --region per specificare le regioni.

Sostituire la regione o la zona dell'operatore

Per impostazione predefinita, quando invii un job con l'opzione --region, i worker vengono assegnati automaticamente in zone della regione o zona migliore all'interno della regione, a seconda del tipo di prestazione.

Se vuoi assicurarti che i worker per il tuo job Dataflow vengano eseguiti esclusivamente in una zona specifica, puoi specificare la zona utilizzando la seguente opzione della pipeline. Questo pattern di utilizzo è insolito per i job Dataflow.

Questa opzione controlla solo la zona utilizzata per i worker Dataflow. Non si applica alle risorse di backend. Le risorse di backend possono essere create in qualsiasi zona all'interno della regione del job.

--workerZone

--worker_zone

--worker_zone

In tutti gli altri casi, non è consigliabile eseguire l'override della posizione del worker. La La tabella degli scenari comuni contiene suggerimenti sull'utilizzo per queste situazioni.

Poiché il job è configurato per essere eseguito in una singola zona, l'operazione potrebbe non riuscire con un errore di disponibilità delle risorse di zona se non sono disponibili risorse Compute Engine sufficienti.

Puoi eseguire il comando gcloud compute regions list per visualizzare un elenco di regioni e zone disponibili per il deployment dei worker.

Scenari comuni

La tabella seguente contiene consigli per l'utilizzo per scenari comuni.