我很想知道设计spark流应用程序的最佳实践方法是什么。
我们有大量的数据源，我们想摄取，清理和转换Kafka使用Spark流。
处理过程分为3个步骤，产生一个新的主题，每个主题都有新的结构，例如原始的、标准化的和逻辑的。
这个问题与Spark蒸汽应用的设计有关。我看到三种选择
每个步骤1个流应用程序，意味着每个源3个运行spark作业
每个源1个流应用程序意味着1个正在运行的spark作业为同一个源读写多个主题
1个适用于所有源和主题的流媒体应用程序。
我的直觉告诉我，选项2是最好的折衷方案，因为选项1会导致太多正在运行的spark作业，而且单个作业的复杂性太高。
然而，这实际上是一个好主意，有一个单一的Spark工作做一个以上的管道一步呢？如果作业停止或失败，是否会降低可靠性或导致某种类型的数据丢失？
1条答案
按热度按时间vptzau2j1#
如评论部分所确认的，流程如下所示：
sources -> step1(raw) -> topic1 -> step2(standardized) -> topic2 -> step3(logical) -> target我会将整个流媒体管道保存在一个应用程序中（即您提到的第三个选项）。这种方法的好处如下：不需要将中间结果（步骤1和步骤2）写入磁盘（Kafka主题或文件）。当整个计算都可以在内存中完成时，为什么还要涉及磁盘io呢。这就是全部
单个应用程序将易于维护。i、 所有的转换逻辑都可以在一个应用程序中。另外，在同一个应用程序中添加一个新的转换（step）与为一个新的转换（step）生成一个新的应用程序相比也很容易。
关于您对数据丢失的担忧：
不太清楚基于数据流的流，但对于结构化流，如果流应用程序由于任何原因失败，spark将重新处理最近一批（作业失败）的数据，直到源代码可重放为止。所以不会有数据丢失，但可能有重复的数据。检查此链接：https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html#fault-容忍语义学
对于基于数据流的流媒体，我也相信有一个零数据丢失的保证。检查此链接：https://databricks.com/blog/2015/01/15/improved-driver-fault-tolerance-and-zero-data-loss-in-spark-streaming.html
然而，我在基于数据流的模型方面没有太多实际操作经验。所以我不会对此发表太多评论。
注意：我假设第1步和第2步的中间结果不会被第2步和第3步以外的任何其他应用程序或作业使用。如果必须存储中间结果，那么我们需要重新考虑方法。