Ottimizzazione dell'importazione su larga scala di eventi e log di analisi

Last reviewed 2022-08-22 UTC

Questo articolo descrive un'architettura per ottimizzare l'importazione dell'analisi su larga scala su Google Cloud. Ai fini di questo articolo, il termine su larga scala indica un numero di eventi superiore a 100.000 al secondo o una dimensione payload di eventi aggregati totali di oltre 100 MB al secondo.

Puoi utilizzare i servizi gestiti elastici e scalabili di Google Cloud per raccogliere grandi quantità di eventi di analisi e log in entrata e quindi elaborarli per l'accesso a un data warehouse, ad esempio BigQuery.

Qualsiasi architettura per l'importazione di quantità significative di dati di analisi deve prendere in considerazione i dati a cui devi accedere quasi in tempo reale e quali puoi gestire dopo un breve ritardo, quindi suddividerli in modo appropriato. Un approccio segmentato presenta i seguenti vantaggi:

  • Integrità dei log. Puoi visualizzare i log completi. Nessun log andrà perso a causa dei limiti di quota per i flussi di dati o del campionamento.
  • Riduzione dei costi. L'inserimento di flussi di dati di eventi e log viene fatturato a una tariffa superiore rispetto a quelli inseriti da Cloud Storage utilizzando job batch.
  • Risorse di query riservate. Lo spostamento dei log con priorità inferiore al caricamento batch impedisce che abbiano un impatto sulle risorse delle query prenotate.

Il seguente diagramma dell'architettura mostra un sistema di questo tipo e introduce i concetti di percorsi attivi e percorsi freddi per l'importazione:

percorsi di importazione generali

Panoramica dell'architettura

In questa architettura, i dati provengono da due possibili origini:

  • I log vengono raccolti utilizzando Cloud Logging.
  • Gli eventi Analytics vengono pubblicati in un argomento Pub/Sub.

Dopo l'importazione da una delle due origini, in base ai requisiti di latenza del messaggio, i dati vengono inseriti nel percorso attivo o nel percorso a freddo. Il percorso a caldo utilizza l'input di flussi di dati, che può gestire un flusso di dati continuo, mentre il percorso a freddo è un processo batch, che carica i dati in base a una pianificazione definita da te.

Logging degli eventi

Puoi utilizzare Cloud Logging per importare gli eventi di logging generati dalle funzionalità di logging standard del sistema operativo. Per impostazione predefinita, Cloud Logging è disponibile in una serie di ambienti Compute Engine, incluse le immagini standard, e può essere installato su molti sistemi operativi utilizzando l'agente Cloud Logging. L'agente Logging è il sink di logging predefinito per App Engine e Google Kubernetes Engine.

Percorso rapido

logging dei percorsi a caldo

Nel percorso ad accesso rapido, i log critici necessari per il monitoraggio e l'analisi dei servizi vengono selezionati specificando un filtro nel sink di Cloud Logging, quindi vengono trasmessi a più tabelle BigQuery. Utilizza tabelle separate per i livelli di logging ERROR e WARN e poi suddividi ulteriormente per servizio se sono previsti volumi elevati. Questa best practice consente di mantenere il numero di inserimenti al secondo per tabella al di sotto del limite di 100.000 e di garantire un buon rendimento delle query su questi dati.

Percorso completo

logging percorso a freddo

Per il percorso a freddo, i log che non richiedono l'analisi quasi in tempo reale vengono selezionati utilizzando un sink di Cloud Logging che punta a un bucket Cloud Storage. I log vengono raggruppati e scritti nei file di log nei batch orari di Cloud Storage. Questi log possono quindi essere caricati collettivamente in BigQuery utilizzando il processo di importazione file standard di Cloud Storage, che può essere avviato utilizzando la console Google Cloud, l'interfaccia a riga di comando (CLI) o anche un semplice script. Il caricamento batch non influisce sulle prestazioni di importazione di flussi di dati o query dei flussi di dati del percorso a caldo. Nella maggior parte dei casi, probabilmente l'ideale è unire i log dei percorsi a freddo direttamente nelle stesse tabelle utilizzate dai log dei percorsi ad accesso frequente per semplificare la risoluzione dei problemi e la generazione dei report.

Eventi di Analytics

Gli eventi di analisi possono essere generati dai servizi dell'app in Google Cloud o inviati da client remoti. L'importazione di questi eventi di analisi tramite Pub/Sub e quindi l'elaborazione in Dataflow fornisce un sistema ad alta velocità effettiva con bassa latenza. Sebbene sia possibile inviare gli eventi di analisi a caldo e a freddo a due argomenti Pub/Sub distinti, devi inviare tutti gli eventi a un argomento ed elaborarli utilizzando job Dataflow a percorso caldo e freddo separati. In questo modo, puoi modificare il percorso seguito da un evento di analisi aggiornando i job Dataflow, il che è più semplice rispetto al deployment di una nuova app o versione client.

Percorso rapido

eventi hot-path

Alcuni eventi richiedono un'analisi immediata. Ad esempio, un evento potrebbe indicare comportamenti indesiderati del cliente o malintenzionati. Scegli questi eventi da Pub/Sub utilizzando un job Dataflow con scalabilità automatica e inviali direttamente a BigQuery. Questi dati possono essere partizionati dal job Dataflow per garantire che non venga raggiunto il limite di 100.000 righe al secondo per tabella. Questo consente inoltre di ottenere buone prestazioni delle query.

Percorso completo

eventi di percorso a freddo

Gli eventi che devono essere monitorati e analizzati ogni ora o ogni giorno, ma mai immediatamente, possono essere inviati da Dataflow agli oggetti in Cloud Storage. I carichi di lavoro possono essere avviati da Cloud Storage in BigQuery utilizzando la console Cloud, Google Cloud CLI o anche un semplice script. Puoi unirli nelle stesse tabelle degli eventi del percorso a caldo. Come il percorso a freddo di logging, gli eventi di analisi caricati in batch non hanno un impatto sulle risorse delle query prenotate e mantengono un carico del percorso di importazione dei flussi di dati ragionevole.

Per ulteriori informazioni sul caricamento dei dati in BigQuery, consulta Introduzione al caricamento dei dati.

Passaggi successivi