当使用 netcat 处理 spark 流中的日志时，它会丢失最后几行？答案

【问题标题】：When using netcat to process logs in spark streaming, it is dropping last few lines?当使用 netcat 处理 spark 流中的日志时，它会丢失最后几行？
【发布时间】：2016-02-09 18:10:45
【问题描述】：

我有一个 spark-streaming 服务，我正在根据一些离线生成的模型处理和检测异常。我从一个日志文件中将数据输入该服务，该文件使用以下命令进行流式传输

tail -f <logfile>| nc -lk 9999

这里的 spark 流服务正在从端口 9999 获取数据。但是，我观察到最后几行被删除了，即 spark 流没有接收到这些日志行或者它们没有被处理。

但是，我也观察到，如果我只是将日志文件作为标准输入而不是拖尾，则不会删除任何行：

nc -q 10 -lk 9999 < logfile

谁能解释为什么会发生这种行为？还有什么可以更好地解决流式传输日志数据以触发流式传输实例的问题？

【问题讨论】：

我用过同样的，但没有遇到任何问题。虽然正确的架构将使用一些可实现的机制来捕获日志，例如 Flume 或 Apache Nifi 将是捕获流数据然后将其提交给 Spark Streaming 作业的更好选择。 Fume 与 Spark Streaming 很好地集成在一起。见here
感谢您的建议，但我也想弄清楚这里的行为。您是否在设置中使用了 tail -f |nc -lk 9999 选项，它似乎适用于流式传输，但是当我进行归档日志重播时.. 它通常无法处理最后一个日志或最后一对日志？
我使用tail -f <logfile> 来获取 Web 应用程序生成的新日志。没有尝试重播归档日志，但从逻辑上看我没有看到任何区别。

标签： apache-spark spark-streaming netcat

【解决方案1】：

在Spark Streaming 中，数据通过网络进入，并在每个块间隔上构成一个块。这个块在其他机器上被复制（根据你的storage level，一旦形成。一旦一个批处理间隔过去了，自最后一个批处理间隔滴答起形成的每个块形成一个新的RDD的一部分。一旦你形成了这个RDD，你就可以安排一个作业，所以在批处理间隔n 期间收集的数据然后在批处理间隔@987654327 期间处理 @。

因此，“最终丢失一些数据”的罪魁祸首可能是：

您在监控 Spark 输入的同时观察您的输入文件。如果您考虑在即时t 进行监控，在n 批处理间隔过去后一点，您的日志文件已经生成了n 批处理的数据，然后是一些（“多一点”）。除了，下一批（n+1）的开始是在数据收集阶段的这个阶段，在你的接收器上以块的形式。没有数据丢失，批处理n+1 还没有开始。
或者您的应用程序假设它在每个 RDD 中接收到相似数量的元素，并且没有正确处理可能（非常）小的 last 批次的 RDD。
或者您在最后一个批处理间隔结束之前停止应用程序或数据（您需要等待n+1 批处理间隔才能看到对n 批处理数据的处理）。
或者您的执行程序的系统时钟发生了一些奇怪的事情。你有没有想过将它们与ntp 同步？

【讨论】：