问题标签 [google-cloud-bigtable]

我们正在寻求在 GCP 上构建用于活动/广告分析的解决方案（将 doubleclik 和其他广告服务器数据提取到 DW 中）。数据以星型模式批量摄取，但更新会持续长达一周，需要对多个客户（广告商）进行趋势分析和报告。我无法在支持更新和时间序列分析的 Google Big table 与非常适合星型模式和 ad-hoc 分析的 Big Query 之间做出决定。

有什么建议么？性能和灵活性很重要。

我正在尝试将对象转换为 org.apache.hadoop.hbase.client.Put 在 DoFn 中。我不断收到此错误：

但是，如果我使用与 org.apache.hadoop.hbase.client.Put （任何自定义类型）不同的类，则不会发生错误

这是当前的 DoFn processElementMethod：

如您所见，输出后没有对 Put 对象进行任何修改。

这是我使用的库

任何的想法 ？

更新：我在https://github.com/GoogleCloudPlatform/cloud-bigtable-examples/tree/master/java/dataflow-connector-examples获取了示例， 它也不起作用，失败的方式完全相同：

我想运行数据流作业以将数据从 google-project-1-table 迁移到 google-project-2-table。（从一个读取并写入另一个）。这样做时我遇到了许可问题。我已将“GOOGLE_APPLICATION_CREDENTIALS”设置为指向我的项目 1 的凭据文件。下面的 project-2 是 project-1 的权限/角色。1) 服务帐户（角色 - 编辑） 2) -compute@developer.gserviceaccount.com（角色 - 编辑） 3) @cloudservices.gserviceaccount.com（角色 - 编辑）。

我还需要做些什么来完成这项工作吗？

原因：com.google.bigtable.repackaged.com.google.cloud.grpc.io.IOExceptionWithStatus：com.google.bigtable.repackaged.com.google.cloud.grpc.scanner.ResultQueueEntry$ExceptionResultQueueEntry 的响应流错误。 getResponseOrThrow(ResultQueueEntry.java:66) 在 com.google.bigtable.repackaged.com.google.cloud.grpc.scanner.ResponseQueueReader.getNextMergedRow(ResponseQueueReader.java:55) 在 com.google.bigtable.repackaged.com.google。 cloud.grpc.scanner.StreamingBigtableResultScanner.next(StreamingBigtableResultScanner.java:42) 在 com.google.bigtable.repackaged.com.google.cloud.grpc.scanner.StreamingBigtableResultScanner.next(StreamingBigtableResultScanner.java:27) 在 com.google。 bigtable.repackaged.com.google.cloud.grpc.scanner.ResumingStreamingResultScanner.next(ResumingStreamingResultScanner.java:89) at com.google.bigtable.repackaged.com.google.cloud.grpc.scanner.ResumingStreamingResultScanner.next(ResumingStreamingResultScanner.java:45) at com.google.cloud.bigtable.dataflow.CloudBigtableIO$1.next(CloudBigtableIO .java:221) 在 com.google.cloud.bigtable.dataflow.CloudBigtableIO$1.next(CloudBigtableIO.java:216) 在 com.google.cloud.bigtable.dataflow.CloudBigtableIO$Reader.advance(CloudBigtableIO.java:775)在 com.google.cloud.bigtable.dataflow.CloudBigtableIO$Reader.start(CloudBigtableIO.java:799) 在 com.google.cloud.dataflow.sdk.io.Read$Bounded$1.evaluateReadHelper(Read.java:178) 。 .. 还有 18 个原因：com.google.bigtable.repackaged.io.grpc.StatusRuntimeException：PERMISSION_DENIED：用户无法访问项目：com.google.bigtable.repackaged 的​​项目 2。io.grpc.Status.asRuntimeException(Status.java:431) 在 com.google.bigtable.repackaged.com.google.cloud.grpc.scanner.StreamObserverAdapter.onClose(StreamObserverAdapter.java:48) 在 com.google.bigtable。 repackaged.io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$3.runInContext(ClientCallImpl.java:462) 在 com.google.bigtable.repackaged.io.grpc.internal.ContextRunnable.run(ContextRunnable.java:54) 在 com.google .bigtable.repackaged.io.grpc.internal.SerializingExecutor$TaskRunner.run(SerializingExecutor.java:154) 在 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 在 java.util.concurrent.ThreadPoolExecutor$Worker .run(ThreadPoolExecutor.java:617) ... 还有 1 个com.google.cloud.grpc.scanner.StreamObserverAdapter.onClose(StreamObserverAdapter.java:48) 在 com.google.bigtable.repackaged.io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$3.runInContext(ClientCallImpl.java:462) 在 com .google.bigtable.repackaged.io.grpc.internal.ContextRunnable.run(ContextRunnable.java:54) 在 com.google.bigtable.repackaged.io.grpc.internal.SerializingExecutor$TaskRunner.run(SerializingExecutor.java:154)在 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 在 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ... 还有 1 个com.google.cloud.grpc.scanner.StreamObserverAdapter.onClose(StreamObserverAdapter.java:48) 在 com.google.bigtable.repackaged.io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$3.runInContext(ClientCallImpl.java:462) 在 com .google.bigtable.repackaged.io.grpc.internal.ContextRunnable.run(ContextRunnable.java:54) 在 com.google.bigtable.repackaged.io.grpc.internal.SerializingExecutor$TaskRunner.run(SerializingExecutor.java:154)在 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 在 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ... 还有 1 个ClientCallImpl$ClientStreamListenerImpl$3.runInContext(ClientCallImpl.java:462) 在 com.google.bigtable.repackaged.io.grpc.internal.ContextRunnable.run(ContextRunnable.java:54) 在 com.google.bigtable.repackaged.io.grpc .internal.SerializingExecutor$TaskRunner.run(SerializingExecutor.java:154) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617 ) ... 还有 1 个ClientCallImpl$ClientStreamListenerImpl$3.runInContext(ClientCallImpl.java:462) 在 com.google.bigtable.repackaged.io.grpc.internal.ContextRunnable.run(ContextRunnable.java:54) 在 com.google.bigtable.repackaged.io.grpc .internal.SerializingExecutor$TaskRunner.run(SerializingExecutor.java:154) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617 ) ... 还有 1 个runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ... 还有 1 个runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ... 还有 1 个

https://cloud.google.com/bigtable/docs/go/cbt-reference

如在此参考中，我尝试了以下命令

三个不同的表。

对于其中一个，我得到了我的预期：行数，略低于 1M。

对于第二个表，我收到以下错误：

我尝试了几次，但每次都得到相同的错误。

对于最后一个，我得到了一个不同的错误（错误代码与上面相同，但其描述不同）：

我也尝试了几次，没有任何改变。

我用“rpc 错误代码 4”作为关键字在 stackoverflow 上搜索和搜索，但没有找到任何有用的东西。

我真的很好奇为什么这个命令会失败，以及我能做些什么来解决这个问题（顺便说一下，这两个表正在 24/7 生产中使用，我们有几十个大表节点工作得很好，所以我不要认为它与带宽或QPS有关）。

任何帮助将不胜感激。

我在 Google Cloud Dataproc 集群上使用 Spark，我想在 PySpark 作业中访问 Bigtable。我们是否有任何用于 Spark 的 Bigtable 连接器，例如 Google BigQuery 连接器？

我们如何从 PySpark 应用程序访问 Bigtable？

我希望在 Bigtable 中构建一个（历史）表，该表将是 30TB 并且还在增长。我预计单个每日批处理负载为 200GB，并且偶尔会在某个键范围内进行批处理查询。Bigtable 中每个节点的 TB 数有哪些指导？我已经阅读了一些 Cassandra 的倾斜帖子，建议每个节点可用 1TB，以及其他一些建议每个 HBase 节点 6-12TB 的帖子。我在 Google Bigtable 文档中找不到任何明确的指导。

Google Bigtable Python 客户端库仍处于 Alpha 阶段，这意味着未来的更改可能无法向后兼容并且没有 SLA。

有谁知道图书馆什么时候会有生产支持？

为了提供更多上下文，

1. 我正在辩论 Bigtable 与 Datastore。而且我更熟悉 C++ 和 Python。
2. 要构建的服务是 - 用户可以写帖子和添加标签。用户可以搜索或过滤特定用户或标签的帖子。Bigtable 似乎是一个很好的选择（用户 id 作为行键，标签作为列族）。但是 python 客户端库是一个问题。

感谢您提前回答。

有官方页面，回答这个问题吗？2016 年 11 月，我尝试运行一些 Java Bigtable 代码，但它在本地开发服务器和真实远程实例上都失败了。

我尝试了两个库的不同版本。Appengine 要么抱怨使用 JMX，要么抱怨正在运行线程。在这两种情况下，这些技术/API 的使用都在内部，被 Bigtable 客户端核心用于连接建立等。

SQL Alchemy 似乎可以连接到在 Google Cloud SQL 上运行的 MySQL 表。但是，我花了一些时间寻找 NoSQL 数据库 Google Cloud Bigtable 的包装器，但找不到足够成熟的东西。

只是想知道如何从 SQL Alchemy 管理 Google Cloud Bigtable。

我看到 Google Cloud 的示例代码中有 2 个 hbase 表扫描 API：

1）使用 google.cloud 模块 bigtable 对象 https://github.com/GoogleCloudPlatform/python-docs-samples/blob/master/bigtable/hello/main.py

2) 使用 google.cloud 模块 bigtable 和 happybase 对象 https://github.com/GoogleCloudPlatform/python-docs-samples/blob/master/bigtable/hello_happybase/main.py

这两种机制中的哪一种是扫描 BigTable 的推荐方法？

此外，它们是否适合从 PySpark 使用？