Google bigquery 自定义数据流模板-BigQuery到CloudStorage-文档？一般解决方案建议？

我正在使用BigQuery表数据源。它是“无限的”，因为它是通过批处理更新的。它包含来自服务器日志的会话键控报告数据，其中每行捕获一个请求。我无法访问原始日志数据，必须使用BigQuery表

我想使用beam api开发一个自定义的基于Java的google数据流模板，目标是：

整理键控会话对象

导出会话级度量

基于会话度量导出可过滤窗口级别度量，例如，在上一个窗口期间出现错误的会话百分比和每个过滤属性的错误百分比，例如，每个设备类型的错误百分比

将结果作为格式化/压缩报告写入云存储

这似乎是一个相当标准的用例？到目前为止，在我的研究中，我还没有找到一个完美的例子，仍然无法确定某些基本需求的最佳实践方法。我非常感谢任何指点。关键词研究？文档、教程。我现在的想法是正确的还是需要考虑其他方法？ 问题:

beam windowing和BigQuery I/O连接器-我发现我可以通过beam api指定窗口类型和大小。我的BQ表每行有一个时间戳字段。我是应该通过配置来传递这个信息，还是应该是automagic？我是否需要通过SQL查询手动执行此操作？这我不清楚

固定时间窗口与会话窗口功能-示例是基本的，不涉及任何边缘情况。我的疗程可以持续几个小时。每个窗口可能有100K以上的会话密钥。会话窗口是否支持此功能

BigQuery与BigQueryClientStorage的区别我不清楚。我知道BQCS提供了性能优势，但我是否必须在使用它的初步步骤中存储BQ数据？或者我可以直接通过BQCS查询我的表，它会帮我解决这个问题吗

对于数字1，您可以在应用窗口之前简单地使用withTimestamps函数，这将为您的项目分配时间戳。下面是一些python示例

第二个州：

会话窗口在每个键的基础上应用，对于时间分布不规则的数据非常有用。[…]如果数据在指定的最小间隔持续时间之后到达，则启动新窗口的开始

此外，在中，您只能指定最小间隙持续时间，但不能指定最大间隙持续时间。这意味着会话窗口可以轻松支持持续一小时的会话。毕竟，它所做的唯一一件事就是在你的数据上加上一个水印并保持它的活力

对于数字3，与的区别在于，后者是自2020年1月起的一个实验特性，直接访问存储的数据，而不通过BigQuery的逻辑通道BigQuery数据不存储在BigQuery中。这意味着，对于存储API，状态为：

您不能使用它来读取数据源，例如联合表和逻辑视图

---

另外，这两种方法有不同的限制和配额，您可以在上面的文档链接中找到。

谢谢！好的，太好了。对于3，我试图从这个示例中学习—它利用了这里描述的这个较新的BigQueryClientStorage api—到目前为止，我只使用客户端库直接查询BQ表，而不使用BQ存储。在这种情况下，我相信为了创建这些表，我必须对api做一些特殊的处理？听起来我可以直接使用这个beta版BigQueryClientStorage库来代替BigQueryAPI，而无需事先做任何特殊的事情？也许是它在引擎盖下创造了这个临时桌子？这有意义吗？或者我把BQ客户端存储和“大结果”临时表混在一起了？换句话说——我不知道什么时候使用BigQueryIO和BigQueryClientStorage readSession——我编辑了我的答案，现在我明白了你的意思，希望你觉得它有用。请考虑将此标记为已接受的答案：考虑到您希望使用BigQu疑问作为无限制的流源。关于问题1和3，BigQuyIO读取和存储API将读取一次表快照而不考虑新到达的数据。使用流数据通常是发布/订阅用例，但我知道您只能访问BigQuery表。您可以在每次X刷新一次的侧输入中使用BigQuery客户端库，但这将带来其他挑战：查询获取增量数据、延迟数据、重复数据消除等。对于问题2，您需要打开会话窗口，然后将结果重新打开固定时间窗口。当然，在一个窗口中有很多键和事件

---

可能会导致OOM问题，因此我建议尽快使用组合器，即在计算会话时。当然，如果您可以事后进行分析，您只需使用前一天的数据运行每日批处理作业，并简化整个设计。谢谢Guillem。我想我明白了。BQ表源的时间划分为天。所以我想我应该考虑到这一点。另外，一旦我为给定的一天生成了一份报告并将其持久化到云存储，我就不需要再次查询BQ数据了。就目前而言，我想我可能只是每隔一段时间（比如一小时）覆盖一次报告，因为报告不需要是实时的。如果我覆盖整个报告，我就不需要再处理旁侧输入、延迟数据、重复数据消除等。不考虑任何跨天重叠的会话—我想这可能会花费更多，但我认为为了获得每小时的数据，这可能是值得的。因此，是的，日常批处理工作似乎是一个很好的简化方法。当我使用BQ客户端库时，OOM是一个真正的问题。在这种情况下，关键是通过清除事件数据和保留会话摘要数据，在不需要内存时尽快释放内存。我对beam还是个新手，但我感觉combiner也有类似的效果。