Плюсы/минусы потоковой передачи в BigQuery напрямую через Google Pub/Sub + Dataflow

У нас есть API NodeJS, размещенный в Google Kubernetes Engine, и мы хотели бы начать запись событий в BigQuery.

Я вижу три разных способа сделать это:

Вставить каждое событие непосредственно в BigQuery с помощью Node BigQuery SDK в API (как описано здесь в разделе "Примеры потоковой вставки": https://cloud.google.com/bigquery/streaming-data-into-bigquery или здесь: https://github.com/googleapis/nodejs-bigquery/blob/7d7ead644e1b9fe8428462958dbc9625fe6c99c8/samples/tables.js#L367)
Публиковать каждое событие в облачной пабе/подтеке, а затем писать конвейер потока данных для потоковой передачи в BigQuery (в Java или Python только это кажется), например здесь https://blog.doit-intl.com/replacing-mixpanel-with-bigquery-dataflow-and-kubernetes-b5f844710674 или здесь https://github.com/bomboradata/pubsub-to-bigquery
Публиковать каждое событие в теме Pub/Sub из API, но вместо Dataflow используйте настраиваемый рабочий процесс, который подписывается на тему Pub/Sub с одной стороны и передает в BQ другой, Как здесь: https://github.com/GoogleCloudPlatform/kubernetes-bigquery-python/blob/master/pubsub/pubsub-pipe-image/pubsub-to-bigquery.py или здесь: https://github.com/mchon89/Google_PubSub_BigQuery/blob/master/pubsub_to_bigquery.py

В этом конкретном случае использования нам не нужно делать никаких преобразований и просто отправлять события прямо в нужный формат. Но позже мы можем использовать другие варианты использования, где нам нужно синхронизировать таблицы из нашего основного хранилища данных (MySQL) в BQ для аналитики, так что, возможно, начиная с Dataflow сразу стоит того?

Несколько вопросов:

Вариант 1 (отправка одного события прямо в BQ) кажется простым, если у вас нет каких-либо преобразований. Это так же быстро и надежно, как и публикация в Паб/Под тема? Я в основном обеспокоен задержкой и обработка ошибок/дублирования (https://cloud.google.com/bigquery/troubleshooting-errors#streaming). Может быть, это лучше сделать в отдельном процессе?
Для варианта 2 существуют ли какие-либо "пресеты" потока данных, которые не требуют, чтобы вы писали пользовательский код, когда все, что вам нужно, - это читать с Pub/Sub + надежно в BQ без каких-либо преобразований (возможно, только дедупликация/обработка ошибок )
Существуют ли какие-либо недостатки в отношении простого пользовательского рабочего (опция 3), который читает из Pub/Sub, а затем передает в BQ и выполняет ли все обработку/повторную обработку ошибок и т.д.?

Ответ 1

Для варианта 2 да, есть пресет, называемый шаблоном, предоставленным Google, который облегчает перемещение данных из PubSub в BigQuery без необходимости писать какой-либо код.

Вы можете узнать больше о том, как использовать этот шаблон, предоставленный Google, и другие, в Документация по облачному документу.

Ответ 2

Другой вариант - экспортировать журналы с помощью системного лога. Прямо из пользовательского интерфейса регистрации Stackdriver вы можете указать BigQuery (или другие адресаты) для своих журналов. Поскольку ваш API Node работает в Kubernetes, вам просто нужно записывать сообщения на stdout, и они автоматически будут записаны в Stackdriver.

Ссылка: https://cloud.google.com/logging/docs/export/configure_export_v2

Ответ 3

Я посмотрел на это, и мне кажется, что ответов немного не хватает. Вот что я могу рассказать вам о плюсах и минусах каждого подхода:

Написание пользовательской программы (через Node BQ API или пользовательский рабочий процесс) имеет несколько ловушек, когда речь идет о гарантиях, выполняемых ровно один раз. В частности, если вы напишите своего собственного работника, вам нужно будет выполнить дополнительную работу, чтобы проверить прогресс контрольной точки и убедиться, что никакие элементы не были отброшены или дублированы в случае ошибок времени выполнения или смерти вашего рабочего процесса.
Если ваши требования изменяются (например, выполнение потоковых вставок BQ становится слишком дорогим), Dataflow Java SDK без проблем поддерживает любой из вариантов: потоковые вставки или более дешевое выполнение нескольких заданий загрузки в BQ вместо потоковых вставок; и он также хорошо обрабатывает несколько источников данных.
Поток данных обеспечивает автоматическое автоматическое масштабирование в случае увеличения объема данных.

Имея это в виду, я бы сказал:

Если ваш сценарий использования относительно прост, и у вас все в порядке с очень редкими точками данных, отбрасываемыми при перезапуске рабочих, тогда написанное пользователем приложение Node/Python должно помочь вам.
Если ваш вариант использования предусматривает только потоковую передачу PubSub на BQ, но вы должны убедиться, что данные не удалены, проверьте шаблон, предоставленный Эндрю, который делает именно это.
Если ваш вариант использования, вероятно, будет более сложным, чем это, вы можете заняться написанием своего собственного конвейера (и использовать код шаблона в качестве вдохновения !).