web-dev-qa-db-fra.com

Avantages/inconvénients de la diffusion dans BigQuery directement ou via Google Pub/Sub + Dataflow

Nous avons une API NodeJS hébergée sur Google Kubernetes Engine et nous aimerions commencer à enregistrer les événements dans BigQuery.

Je peux voir 3 façons différentes de le faire:

  1. Insérez chaque événement directement dans BigQuery à l'aide du kit de développement logiciel (SDK) Node BigQuery dans l'API (comme décrit ici sous "Exemples d'insertion en streaming": https://cloud.google.com/bigquery/streaming-data-into -bigquery ou ici: https://github.com/googleapis/nodejs-bigquery/blob/7d7ead644e1b9fe8428462958dbc9625fe6c99c8/samples/tables.js#L367 )
  2. Publiez chaque événement dans un sujet Cloud Pub/Sub, puis écrivez un pipeline Cloud Dataflow pour le diffuser dans BigQuery (uniquement en Java ou en Python), comme ici https: //blog.doit- intl.com/replacement-mixpanel-with-bigquery-dataflow-and-kubernetes-b5f844710674 ou ici https://github.com/bomboradata/pubsub-to-bigquery
  3. Publiez chaque événement de l'API dans une rubrique Pub/Sub. Toutefois, au lieu de Dataflow, utilisez un processus de travail personnalisé qui s'abonne à la rubrique Pub/Sous d'un côté et est transféré au BQ de l'autre . Comme ici: https://github.com/GoogleCloudPlatform/kubernetes-bigquery-python/blob/master/pubsub/pubsub-pipe-image/pubsub-to-bigquery.py ou ici: https://github.com/mchon89/Google_PubSub_BigQuery/blob/master/pubsub_to_bigquery.py

Pour ce cas d'utilisation particulier, nous n'avons pas besoin de transformer, nous allons simplement envoyer les événements directement dans le bon format. Mais nous aurons peut-être plus tard d'autres cas d'utilisation pour lesquels nous aurons besoin de synchroniser les tables de notre magasin de données principal (MySQL) vers BQ pour l'analyse, alors peut-être que commencer immédiatement avec Dataflow en vaut la peine?

Quelques questions :

  • L'option 1 (envoyer un seul événement directement à BQ) semble plus simple si vous n'avez aucune transformation à faire. Est-il aussi rapide et fiable que Publier sur un sujet Pub/Sub? Je suis principalement préoccupé par la latence Et le traitement des erreurs/duplications ( https://cloud.google.com/bigquery/troubleshooting-errors#streaming ). Peut-être que cela serait mieux fait dans un processus séparé?
  • Pour l'option 2, existe-t-il des "préréglages" de Dataflow qui ne nécessitent pas l'écriture de code personnalisé alors que vous avez simplement besoin de lire à partir de Pub/Sub + et de l'envoyer de manière fiable dans BQ sans transformation (peut-être juste la gestion de la déduplication/des erreurs)
  • Y a-t-il des inconvénients à avoir un simple ouvrier personnalisé (option 3) qui lit à partir de Pub/Sub puis est transféré dans BQ et effectue toutes les erreurs de traitement/nouvelle tentative, etc.?
google-bigquerygoogle-cloud-dataflowgoogle-cloud-pubsub
12
renaudg

Oui, il existe un paramètre prédéfini appelé Modèle fourni par Google qui facilite le déplacement des données de PubSub vers BigQuery sans avoir à écrire de code.

Pour en savoir plus sur l’utilisation de ce modèle fourni par Google et d’autres, consultez la documentation Cloud Dataflow .

3
Andrew Mo

Une autre option consiste à exporter les journaux à l'aide d'un collecteur de journaux. Dès l'interface utilisateur de journalisation Stackdriver, vous pouvez spécifier BigQuery (ou d'autres destinations) pour vos journaux. Puisque votre API de nœud est en cours d’exécution dans Kubernetes, il vous suffit de consigner vos messages dans stdout. Ils seront automatiquement écrits dans Stackdriver.

Référence: https://cloud.google.com/logging/docs/export/configure_export_v2

2
Andrew Nguonly

J'ai jeté un coup d'œil à cela, et j'ai l'impression que les réponses manquent quelque peu. Voici ce que je peux vous dire sur les avantages et les inconvénients de chaque approche:

  1. L'écriture d'un programme personnalisé (via l'API Node BQ ou un processus de travail personnalisé) présente quelques pièges lorsqu'il s'agit de garantir une seule fois les garanties . Plus précisément, si vous écrivez vous-même votre ouvrier, vous devrez effectuer un travail supplémentaire pour vérifier la progression du point de contrôle et vous assurer qu'aucun élément n'est oublié ou dupliqué en cas d'erreur d'exécution ou de mort de votre processus de travail.

  2. Si vos besoins changent (par exemple, effectuer des insertions de streaming BQ devient trop coûteux), le SDK Java de Dataflow prend en charge de manière transparente l'une des options suivantes: les insertions en streaming ou le moins coûteux d'effectuer plusieurs tâches de chargement dans BQ au lieu d'insertions en streaming; et il gère également plusieurs sources de données.

  3. Dataflow fournit une mise à l'échelle automatique automatique en cas d'augmentation du volume de vos données.

Dans cet esprit, je dirais:

  • Si votre cas d'utilisation est relativement simple et que des points de données très rares sont supprimés lors des redémarrages d'ouvriers, vous pouvez utiliser une application Node/Python personnalisée, qui devrait faire l'affaire pour vous.

  • Si votre cas d'utilisation implique uniquement la diffusion de PubSub vers BQ, mais que vous devez vous assurer qu'aucune donnée n'est supprimée, consultez le modèle fourni par Andrew qui fait exactement cela.

  • Si votre cas d'utilisation est susceptible d'être plus complexe que cela, vous pouvez envisager d'écrire votre propre pipeline (et utiliser le code Template comme source d'inspiration !).

0
Pablo