問題タブ [google-cloud-bigtable]

Google Cloud Bigtable で Quickstart を使用してテーブルを作成しようとした後、"List" を実行すると、以下のエラー メッセージが表示され、HBase シェルが終了しました。アドバイスしてください...ありがとう。

テーブルへの連続挿入に基づいて処理がトリガーされるように、無制限の方法でビッグテーブルからデータフローにデータを取得しようとしています。ドキュメント ( https://cloud.google.com/bigtable/docs/dataflow-hbase ) では、スキャンを使用した境界読み取りについてのみ説明しています。コネクタまたは大きなテーブルはこのモデルをサポートしていますか?

Google Cloud Bigtable に対して呼び出しを行う gRPC C++ クライアントに問題があります。これらの通話はときどきハングしますが、通話の締め切りが設定されている場合にのみ、通話が返されます。gRPC チーム ( https://github.com/grpc/grpc/issues/6278)に提出された問題があり、スタック トレースと gRPC トレース ログが提供されています。

最も頻繁にハングする呼び出しは、ReadRowsストリーム読み取り呼び出しです。通話がハングするのも数回見MutateRowたことがありますが、それはかなりまれです。

gRPC トレースは、サーバーから何らかの応答が返されていることを示していますが、その応答は gRPC クライアントが続行するには不十分なようです。

コードのデバッグにかなりの時間を費やしましたが、これまでクライアント側で明らかな問題は見つかりませんでした。メモリの破損も見られませんでした。これはシングル スレッド アプリケーションであり、一度に 1 つの呼び出しを行います。クライアント側の同時実行性は疑わしいものではありません。クライアントは Google コンピューティング エンジン ボックスで実行されるため、ネットワークも問題にならない可能性があります。gRPC クライアントは、github リポジトリのメイン ラインで最新の状態に保たれます。

任意の提案をいただければ幸いです。デバッグのアイデアがあれば、それも素晴らしいでしょう。valgrind、gdb を使用して、アプリケーションを再現可能な結果のサブセットに縮小しても、これまでのところ役に立ちませんでした。問題の原因を突き止めることができませんでした。問題はランダムで、時折発生します。

2016 年 5 月 17 日の追記 再試行が問題の解決に役立つ可能性があるという提案がありました。残念ながら、再試行はアプリケーション ロジックに引き継がなければならないため、うまく機能しません。簡単に更新を再試行できます。MutateRowこれらはストリーミング コールではなく、簡単に再試行できます。ただし、DB クエリ結果の反復がアプリケーションによって開始された後、失敗した場合、再試行は、アプリケーションがクエリを再発行し、結果の反復を再度開始する必要があることを意味します。これは問題です。アプリケーションが結果セット全体を一度に読み取ってから、アプリケーション レベルで反復処理をメモリ内で実行できるようにする変更をいつでも検討できます。その後、再試行を処理できます。しかし、これは、メモリ フットプリントやアプリケーションのレイテンシなど、あらゆる種類の理由で問題になります。DB クエリの結果がすべてメモリにあるときではなく、到着したらすぐに処理したいのです。また、通話がハングしたときに、通話の待ち時間にタイムアウトが追加されます。そう、

(HBase API 経由で) Bigtable に書き込む Google Cloud Dataflow ジョブがあります。残念ながら、次の理由で失敗します。

java.io.IOException: The Application Default Credentials are not available. They are available if running in Google Compute Engine. Otherwise, the environment variable GOOGLE_APPLICATION_CREDENTIALS must be defined pointing to a file defining the credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information. at com.google.bigtable.repackaged.com.google.auth.oauth2.DefaultCredentialsProvider.getDefaultCredentials(DefaultCredentialsProvider.java:74) at com.google.bigtable.repackaged.com.google.auth.oauth2.GoogleCredentials.getApplicationDefault(GoogleCredentials.java:54) at com.google.bigtable.repackaged.com.google.cloud.config.CredentialFactory.getApplicationDefaultCredential(CredentialFactory.java:181) at com.google.bigtable.repackaged.com.google.cloud.config.CredentialFactory.getCredentials(CredentialFactory.java:100) at com.google.bigtable.repackaged.com.google.cloud.grpc.io.CredentialInterceptorCache.getCredentialsInterceptor(CredentialInterceptorCache.java:85) at com.google.bigtable.repackaged.com.google.cloud.grpc.BigtableSession.<init>(BigtableSession.java:257) at org.apache.hadoop.hbase.client.AbstractBigtableConnection.<init>(AbstractBigtableConnection.java:123) at org.apache.hadoop.hbase.client.AbstractBigtableConnection.<init>(AbstractBigtableConnection.java:91) at com.google.cloud.bigtable.hbase1_0.BigtableConnection.<init>(BigtableConnection.java:33) at com.google.cloud.bigtable.dataflow.CloudBigtableConnectionPool$1.<init>(CloudBigtableConnectionPool.java:72) at com.google.cloud.bigtable.dataflow.CloudBigtableConnectionPool.createConnection(CloudBigtableConnectionPool.java:72) at com.google.cloud.bigtable.dataflow.CloudBigtableConnectionPool.getConnection(CloudBigtableConnectionPool.java:64) at com.google.cloud.bigtable.dataflow.CloudBigtableConnectionPool.getConnection(CloudBigtableConnectionPool.java:57) at com.google.cloud.bigtable.dataflow.AbstractCloudBigtableTableDoFn.getConnection(AbstractCloudBigtableTableDoFn.java:96) at com.google.cloud.bigtable.dataflow.CloudBigtableIO$CloudBigtableSingleTableBufferedWriteFn.getBufferedMutator(CloudBigtableIO.java:836) at com.google.cloud.bigtable.dataflow.CloudBigtableIO$CloudBigtableSingleTableBufferedWriteFn.processElement(CloudBigtableIO.java:861)

ジョブはすでに Cloud Dataflow サービス / VM で実行されているため、これはほとんど意味がありません。

Cloud Dataflow ジョブ ID:2016-05-13_11_11_57-8485496303848899541

bigtable-hbase-dataflowバージョンを使用して0.3.0おり、HBase API を使用したいと考えています。

複数のサブフィルターを含む複雑なフィルター (FilterList) を作成しました。次の理由により、そのフィルタを使用したクエリを実行できませんでした

Cloud Bigtable の割り当てとサービス制限を確認しました。

• https://cloud.google.com/bigtable/docs/schema-design#size-limits
• https://cloud.google.com/bigtable/quota

言及された制限を定義するドキュメントはありません。もチェックBigtableOptionsFactoryしましたが、その制限を変更するオプションはありませんでした。どうすればその制限を回避できますか?

スタックトレース：

単調に増加するキー (従来のタイムスタンプなど) を使用する危険性は、 docs に明確に説明されています。

この記事の執筆時点では、キーで単調減少パターンを使用した場合の影響の可能性が高くなります。これは、「最新のレコードを最初に」定期的に取得するときに提案されるアプローチです。

増加するキーと比較して減少するキーを使用した場合の影響について、誰かが権威をもって話すことができますか? おそらく、「同等のホットスポット」、「ホットスポットの減少」、または「ホットスポットはありませんが、他の望ましくない/壊滅的な動作を引き起こします」?

PS確かに、適切なデータストアの選択として Bigtable を提案するのに十分な「大きな」データがないかもしれません (決してないかもしれません)。 " 可能性のある読者 (つまり、キーに対してレンジ スキャンを使用する -- おそらくタイムスタンプによってクラスター化されている) は、可能性のあるライター (つまり、キーが "de-プロモートされたフィールド、塩の破片、またはランダムエントロピーによって「クラスター化」されていますが、何かが欠けている可能性があります... それとも、これは単なる「最先端」ですか?

複数のテーブルを含む Google クラウドのビッグテーブルをデプロイしています。テーブル レベルの権限でサービス アカウントを作成する方法はありますか?

たとえば、2 つのジョブ A と B があるとします。1. ジョブ A は、テーブル T1 への読み取りおよび書き込みアクセスのみを取得します (サービス アカウント Sa 経由)。2. ジョブ B は、テーブル T2 への読み取りおよび書き込みアクセスを取得しますが、テーブル T1 への読み取りアクセスのみを取得します (サービス アカウント Sb を介して)。

ありがとう。

バックエンドのデータベースに保存して、Android アプリでユーザー イベントを追跡しようとしています。モバイル バックエンドに Google App Engine を使用しています。Google App Engine のデータストアがこれに適しているかどうかを把握しようとしています。また、NoSQL 用の Bigtable (有料機能) に出会いました。

Google App Engine で Cloud Datastore と Bigtable を使用することの長所と短所は何ですか?

また、Datastore 内の古いデータ (つまり、特定の日より古いデータなど) を自動的に消去する方法が見つかりませんでした (cron ジョブを使用するためのいくつかの提案を見つけました)。