web-dev-qa-db-ja.com

BigQueryへの直接ストリーミングとGooglePub / Sub + Dataflowを介したストリーミングの長所/短所

Google KubernetesEngineでホストされているNodeJSAPIがあり、BigQueryへのイベントのログ記録を開始したいと思います。

私はそれを行う3つの異なる方法を見ることができます：

  1. APIのNode BigQuery SDKを使用して各イベントをBigQueryに直接挿入します（ここで「ストリーミング挿入の例」で説明されています：- https://cloud.google.com/bigquery/streaming-data-into-bigquery またはここ： https://github.com/googleapis/nodejs-bigquery/blob/7d7ead644e1b9fe8428462958dbc9625fe6c99c8/ samples/Tables.js＃L367 ）
  2. 各イベントをCloud Pub/Subトピックに公開し、Cloud Dataflowパイプラインを記述してBigQueryにストリーミングします（JavaまたはPython見た目だけ）、ここのように https://blog.doit-intl.com/replacing-mixpanel-with-bigquery-dataflow-and-kubernetes-b5f844710674 またはここ https://github.com/bomboradata/pubsub-to-bigquery
  3. 各イベントをAPIからPub/Subトピックにパブリッシュしますが、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に直接送信する）は、実行する変換がない場合に最も簡単に思えます。 Pub/Subトピックへのパブリッシュと同じくらい高速で信頼性がありますか？私は主にレイテンシーとエラー/重複処理について懸念しています（ https://cloud.google.com/bigquery/troubleshooting-errors#streaming ）。たぶん、これは別のプロセスで行う方が良いですか？
  • オプション2の場合、必要なのがPub/Subから読み取り、変換なしでBQに確実に送信するだけの場合にカスタムコードを記述する必要のないDataflow「プリセット」はありますか（おそらく重複排除/エラー処理）
  • Pub/Subから読み取り、BQにストリーミングし、すべてのエラー処理/再試行などを行う単純なカスタムワーカー（オプション3）を使用することに欠点はありますか？
google-bigquerygoogle-cloud-dataflowgoogle-cloud-pubsub
16
renaudg

オプション2の場合、はい。コードを記述せずにPubSubからBigQueryへのデータの移動を容易にするGoogle提供のテンプレートと呼ばれるプリセットがあります。

このGoogle提供のテンプレートやその他の使用方法について詳しくは、 Cloud Dataflowのドキュメント をご覧ください。

4
Andrew Mo

別のオプションは、ログシンクを使用してログをエクスポートすることです。 Stackdriver Logging UIから直接、ログにBigQuery（または他の宛先）を指定できます。 Node APIはKubernetesで実行されているため、メッセージをstdoutに記録するだけで、自動的にStackdriverに書き込まれます。

参照： https://cloud.google.com/logging/docs/export/configure_export_v2

3
Andrew Nguonly

これを見てみると、少し答えが足りない気がします。各アプローチの長所と短所について、次のように説明します。

  1. （Node BQ APIまたはカスタムワーカープロセスを介して）カスタムプログラムを作成する場合、いくつかの1回限りの保証に関しては落とし穴があります。具体的には、自分のワーカーの場合、進行状況をチェックするために追加の作業を実行し、ランタイムエラーやワーカープロセスが停止した場合に要素が削除または複製されないようにする必要があります。

  2. 要件が変更された場合（たとえば、BQストリーミング挿入の実行が高額になりすぎる場合）、DataflowのJava SDKは、ストリーミング挿入、または複数のロードジョブを実行するより安価なオプションのいずれかをシームレスにサポートします。ストリーミング挿入の代わりにBQ;また、複数のデータソースも処理します。

  3. Dataflowは、データ量が増加した場合に自動スケーリングを提供します。

それを念頭に置いて、私は言うでしょう：

  • ユースケースが比較的単純で、ワーカーの再起動時に非常にまれなデータポイントがドロップされても問題がない場合は、カスタム作成されたNode/Python applicationあなたのためにトリックをする必要があります。

  • ユースケースにPubSubのBQへのストリーミングのみが含まれているが、データがドロップされていないことを確認する必要がある場合は、 Andrewが提供するテンプレート を確認してください。これはまさにこれを行います。

  • ユースケースがそれよりも複雑になる可能性がある場合は、独自のパイプラインを作成することを検討してください（そして、 インスピレーションとしてテンプレートコード ！を使用してください）。

0
Pablo