用于 NRT 数据应用的 Google Cloud DataFlow

Question

我正在评估 Kafka/Spark/HDFS 以开发 NRT（亚秒）Java 应用程序，该应用程序从外部网关接收数据并将其发布到各种主题的桌面/移动客户端（消费者）。同时，数据将通过流式处理和批处理（持久）管道提供给分析和机器学习。

例如，流程将是......

1. 独立的 TCP 客户端从外部 TCP 服务器读取流数据
2. 客户端根据数据包 (Kafka) 发布不同主题的数据，并将其传递到流式管道进行分析 (Spark)
3. 桌面/移动消费者应用订阅各种主题并接收 NRT 数据事件 (Kafka)
4. 消费者还从流/批处理管道 (Spark) 接收分析

必须对 Kafka 集群进行管理、配置和监控，以实现最佳性能和可扩展性。这可能需要额外的人力资源和工具来管理操作。

Kafka、Spark 和 HDFS 可以选择部署在 Amazon EC2（或使用连接器的 Google Cloud）上。

我正在阅读有关 Google Cloud DataFlow、Cloud Storage、BigQuery 和 Pub-Sub 的信息。数据流提供了自动缩放和工具来实时监控数据管道，这非常有用。但是设置有一些限制，例如pub-sub push 要求客户端使用 https 端点，并且应用程序部署需要使用 Web 服务器，例如GCE 上的应用引擎 webapp 或 Web 服务器。

这可能不如部署可以利用 pub-sub 和数据流管道传输数据的双向 tcp/ip 应用程序高效（我担心使用 http 时的延迟）。

理想情况下，Google 云上的首选设置是运行 TCP 客户端连接到部署在 GCE 上的外部网关，该网关使用 pub-sub 将数据推送到桌面消费者应用程序。此外，它将利用 DataFlow 管道进行分析和云存储，使用用于 ML 的 spark（预测 API 有点限制），使用 cloudera spark 连接器进行数据流。

可以在 Google 云上部署 Kafka/Spark/HDFS 等，但这有点违背了利用 Google 云技术的目的。

感谢您对上述设置是否可以使用 Google 云或继续使用 EC2/Kafka/Spark 等的任何想法。

Answer 1

谈到 Cloud Pub/Sub 方面，有几点需要牢记：

• 如果您不想在订阅者中运行 Web 服务器，您可以考虑使用pull-based subscriber instead of the push-based one。为了最大限度地减少延迟，您希望随时至少有几个未完成的拉取请求。
• 仅当您的客户端不超过 10,000 个时，您的桌面消费者应用程序才能直接充当 Pub/Sub 的订阅者；有一个limit of 10,000 subscriptions。如果您需要扩展，您应该考虑Google Cloud Messaging 或Firebase。

Answer 2

从数据流方面来看，这听起来很合适，尤其是当您将混合流式分析和批处理式分析时。如果您还没有，请查看我们的Mobile Gaming walkthrough。

我不太清楚您对使用 Cloudera 的 Dataflow/Spark 运行器进行 ML 是什么意思。该运行程序在 Spark 上运行 Dataflow 代码，但反之则不然。