用于NRT数据应用的Google

Question

我正在评估Kafka/Spark/HDFS，用于开发NRT (子秒级) java应用程序，该应用程序接收来自外部网关的数据，并将其发布到桌面/移动客户端(使用者)，用于各种主题。同时，数据将通过用于分析和ML的流和批处理(持久)管道提供。

例如，流量将是..。

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

必须对Kafka集群进行管理、配置和监视，以获得最佳性能和可伸缩性。这可能需要额外的人力、资源和工具来管理操作。

Kafka、Spark和HDFS可以通过亚马逊EC2 (或Google使用连接器)进行可选部署。

我读到了谷歌云DataFlow，云存储，BigQuery和Pub。数据流提供了实时监测数据管道的自动缩放和工具，这是非常有用的。但是设置有一些限制，例如pub-sub要求客户端使用https端点，而应用部署需要使用web服务器，例如app、webapp或GCE上的web服务器。

这可能不像部署双向tcp/ip应用程序那样高效(我担心使用http时的延迟)，该应用程序可以利用pub-sub和数据流管道进行流数据传输。

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

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

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

Answer 1

谈到Cloud /Sub方面，有几件事要记住：

• 如果您不希望在订阅服务器中运行web服务器，可以考虑使用基于推送的用户代替基于推送的订阅者。为了减少延迟，您希望在任何时候至少有几个未完成的拉请求。
• 让您的桌面消费应用程序直接充当Pub/Sub的订阅者，只有当您的客户端不超过10,000个时才能工作；有一个10 000订阅的限额。如果您需要扩展到更高的范围，您应该考虑Google消息传递或Firebase。

Answer 2

从Dataflow的角度来看，这听起来很合适，特别是当您将流和批处理风格的分析混合在一起时。如果您还没有，请查看我们的移动游戏演练。

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