问题标签 [google-cloud-bigtable]

I have a large csv dataset (>5TB) in multiple files (stored in a storage bucket) that I need to import into Google Bigtable. The files are in the format:

rowkey,s1,s2,s3,s4
text,int,int,int,int
...

There is an importtsv function with hbase that would be perfect but this does not seem to be available when using Google hbase shell in windows. Is it possible to use this tool? If not, what is the fastest way of achieving this? I have little experience with hbase and Google Cloud so a simple example would be great. I have seen some similar examples using DataFlow but would prefer not to learn how to do this unless necessary.

Thanks

我正在尝试让 google bigtable java 客户端在 GAE 中工作，这是一个 hbase 客户端。我找到了一个示例， https://github.com/GoogleCloudPlatform/cloud-bigtable-examples/tree/master/java/managed-vm-gae 但它仅适用于 GAE 中的托管虚拟机。

当我尝试将测试代码部署到沙盒 GAE 时，我收到了以下错误消息：

有关详细信息，请参阅 Google App Engine 开发人员指南。

在此处查看完整的堆栈跟踪：http: //pastebin.com/ke5QMDGY

我很好奇是否有人对沙盒 GAE 的客户端有经验可以提供一些指示。谢谢！

当我尝试连接到 Google Cloud BigTable 时，有谁知道如何解决 Jetty ALPN 未正确配置错误？

Blockquote 2015-12-11 19:53:15,056 INFO [main] grpc.BigtableSession：在数据主机 bigtable.googleapis.com 上打开 projectId crawl-corpus-app、zoneId us-central1-c、clusterId crawl-corpus 的连接，表管理员主机 bigtabletableadmin.googleapis.com。java.io.IOException：org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:240) 处的 java.lang.reflect.InvocationTargetException ...... ..................................................... ..................................................... ............................. 原因：java.lang.IllegalStateException：Jetty ALPN 未正确配置。在 com.google.cloud.bigtable.grpc.BigtableSession.(BigtableSession.java:243) 在 com.google.cloud.bigtable.grpc.BigtableSession.(BigtableSession.java:232) 在 org.apache.hadoop。

简而言之，我们有时会看到少量 Cloud Bigtable 查询重复失败（连续 10 次甚至 100 次）并出现错误rpc error: code = 13 desc = "server closed the stream without sending trailers"，直到（通常）查询最终起作用。

具体来说，我们的设置如下：

我们正在 Google Compute Engine 上运行一组（<10 个）Go 服务。每个服务从一对 PULL 任务队列中租用任务。每个任务都包含一个 bigtable 行的 ID。任务处理程序执行以下查询：

如果查询失败，则任务处理程序简单地返回。由于我们租用了租用时间在 10 到 15 分钟之间的任务，稍后该任务的租用将到期，它将再次被租用，我们将重试。这些任务的最大重试次数为 1000 次，因此可以在很长一段时间内多次重试。在少数情况下，特定任务会因上述 grpc 错误而失败。该任务通常会在每次连续运行数小时或数天时失败并出现相同的错误，然后（看似出乎意料）最终成功（或任务用完重试并死亡）。

由于这通常需要很长时间，因此似乎与服务器负载无关。例如，现在在一个星期天早上，这些服务器的负载非常轻，但是当我跟踪日志时，我看到了很多这样的错误。从这个答案中，我最初认为这可能是由于试图查询大量数据，可能接近云大表支持的最大限制。但是我现在发现情况并非如此。我可以找到许多示例，其中多次失败的任务最终成功并报告仅检索到少量数据（例如<1 MB）。

我还应该在这里看什么？

编辑：通过进一步的测试，我现在知道这完全独立于机器（客户端）。ReadRow如果我在其中一台任务租赁机器上跟踪日志，等待“服务器关闭流而不发送预告片”错误，然后尝试从另一台不相关、完全未使用的机器对同一 rowId进行一次性查询，我得到重复同样的错误。

我正在尝试像在 GoDoc 中一样插入一个简单的记录。但这又回来了，

当我搜索 grpc 代码时，它说..

我在控制台中启用了大表并创建了一个集群和一个服务帐户并收到了 json。我在这里做错了什么？

我按照本教程 在 Google Managed VMs 中启动并运行 Bigtable 客户端。但是有没有办法在本地运行它？原因是在开发中远程部署代码很痛苦。

通常我可以用来dev_appserver.sh在本地运行 GAE 应用程序。但是当我运行它时，我收到了这个错误：

原因：java.lang.IllegalStateException：Jetty ALPN 未正确配置。

这意味着我们需要包含 ALPN 库？由于我们的代码库是 Java 7，我使用了这个 ALPN 版本：7.1.3.v20150130.

然后我再次尝试了这个：

仍然收到此错误：

原因：com.google.apphosting.api.ApiProxy$CallNotFoundException：未找到 API 包“urlfetch”或调用“Fetch()”。

你如何让它在本地工作？

我在 bigtable 中有一个包含 10 个实例的小表（大小为 100Mb）。当我尝试每 1 分钟扫描/获取一行时，调用的延迟超过 300 毫秒。如果我打的是更频繁的呼叫，例如每秒一次，则延迟为 50-60 毫秒。我不确定如何通过低频调用提高性能。这是预期的行为。还是我做错了什么。

这是我的测试代码。我为两个与大表的 hbase 客户端连接创建了一个执行程序。但是低频连接响应比拨打更频繁呼叫的连接要慢得多。

有什么建议么？

背景

我们希望将不可变事件存储在（最好）托管服务中。一个事件的平均大小小于 1 Kb，我们每秒有 1-5 个事件。存储这些事件的主要原因是，一旦我们创建了可能对这些事件感兴趣的未来服务，就能够重播它们（可能使用表扫描）。由于我们在 Google Cloud 中，我们显然将 Google 的服务视为首选。

我怀疑Bigtable很适合这个，但根据价格计算器，我们每月要花费超过 1400 美元（这对我们来说是一笔大买卖）：

查看BigQuery之类的东西每月的价格为 3 美元（如果我没有错过一些重要的东西）：

即使无模式数据库更适合我们，我们也可以将事件本质上存储为带有一些元数据的 blob。

问题

我们可以为此使用 BigQuery 而不是 Bigtable 来降低成本吗？例如，BigQuery 有一种叫做流式插入的东西，在我看来，这似乎是我们可以使用的东西。如果沿着这条路线走下去，有什么我可能不知道的短期或长期会咬我们的东西吗？

我一直在玩数据流/大查询，但我仍然无法理解一些基本的东西，即何时使用某种类型的方法来查询表。

单行查询选项BigQueryIO.Read是：
+ 短而简单，
+ 适用于大型结果，在 PCollection 中返回，
- 但不为结果返回新的表模式，
因此更难将两者都导出到 (1) 。 csv 文件 - 表头、字段！！和 (2) bigquery 表 - 没有模式！每次要将查询结果保存到 bigquery 表或 .csv 文件时，我们都需要手动定义表模式或字段-csv 标头。
---> 有没有一种自动的方式可以优雅地完成？

查询的另一个选项是使用Jobs: Query。
这也有优点和缺点：
+ 返回查询结果的表模式
- 需要身份验证，最后对于精确的简单查询有更多的编码
-> 异步和同步模式；
- 不适合大型结果，
除非在带有选项的异步模式下allowLargeResults，这会导致后台执行多个查询，需要组合这些查询以获得检索到的行的完整列表 (??)
- 结果可以保存到表中，但只有异步查询可以将结果保存在永久表中（而不仅仅是临时表）。

问题仍然存在：

（1）哪种方法更好，什么时候更好？

（2）如果我们查询的表中数据量非常大，得到的结果非常大，那么首选哪种查询方式？

(3) 在处理非常大的结果（表格或 .csv 文件）时，首选哪种导出方式？

我们已经设置了 5 个节点的 Bigtable 集群，GCP 控制台声明它应该支持 50K QPS @ 6ms 的读写。

我们正在尝试加载一个包含约 50 个字段的大型数据集（约 8 亿条记录），其中主要包含数字数据和一些短字符串。键是 11 位数字字符串。

当通过 HBase API 从 GCE 中的单个客户端 VM 加载此数据集时，我们观察到在将每个字段放入单独的列时高达 4K QPS。我们使用单个 HBase 连接和多个线程 (5-30) 执行 10K 记录的批量放置。

将所有字段组合成单个列（Avro 编码，每条记录约 250 字节）时，使用批量 put 的写入性能提高到 10K QPS。并发线程数似乎不会影响 QPS。当每个线程使用单独的 HBase 连接时，写入性能提高到 5 个线程的 20K QPS。

客户端 VM 与 Bigtable 集群位于同一可用区，并且在负载期间几乎处于空闲状态，因此看起来瓶颈不在客户端。

问题：

1. 从我们的测试来看，写入 QPS 似乎随着插入的列数而降低。这是预期的吗？如何量化这种关系？（顺便说一句，如果Bigtable 性能文档中提到了这一点，那就太好了）。
2. 为了实现声明的写入 QPS，我们可能缺少什么？我的理解是每个集群节点都应该支持 10K 写入 QPS，但是似乎我们要针对具有单个 HBase 连接的单个节点，并且仅针对具有多个 HBase 连接的 2 个节点。