elasticsearch - 实时流作业的架构

Question

我正在使用Spark Streaming开发流应用程序，我想将数据索引到 flex 搜索中。

我的分析:
我可以直接将数据从Spark推送到 flex 搜索，但是在这种情况下，我觉得两个组件都将紧密结合在一起。

如果这是一个核心工作，我们可以将该输出写入HDFS，并使用logstash从HDFS中获取数据并将其推送到 flex 搜索。

根据我的解决方案:
我可以将数据从Spark Streaming推送到Kafka，从Kafka可以使用Logstash读取数据并推送到ES。

请提出建议。

Answer 1

首先，很高兴您已经通过不同的方法进行了思考。

在进行良好设计之前，您应该问几个问题:

时间轴？ Spark-> ES轻而易举，如果您从PoC开始，则建议使用。

操作带宽？引入更多的组件将增加运营问题。根据我的个人经验，确保流媒体工作稳定是一项耗时的工作。您还希望添加Kafka，因此您需要花费更多的时间来尝试进行监视，而其他操作问题也应得到解决。

规模？如果要进行更大的扩展，那么拥有持久的消息总线可能能够帮助吸收背压，并且仍然可以很好地扩展。

如果我有时间处理大量问题，Spark流-> Kafka-> ES似乎是最好的选择。这样，当ES群集不稳定时，您仍然可以选择Kafka重播。

我对Kafka-> HDFS-> ES有点困惑，因为在Source和Sink之间添加批处理层可能会对性能产生影响。老实说，我不知道HDFS的logstash效果如何，因此无法发表评论。

紧密联接是经常讨论的主题。有人以可重用性为由反对它，但也有人为它辩护，因为有时它可以创建更简单的设计并使整个系统更容易推理。还讨论过早的优化:)我们已经在中等规模的数据流入方面直接通过Spark-> ES取得了成功。因此，不要像这样剥夺简单设计的力量:)