我不知道如何为以下用例构建架构：
我有一个Web应用程序，用户可以上传要处理的文件(pdf和pptx)和目录。上传完成后，web应用程序将这些文件和目录放在HDFS中，然后在kafka上发送一条消息，其中包含这些文件的路径。
Spark应用程序从kafka流中读取消息，在master(驱动程序)上收集消息，然后进行处理。我首先收集消息，因为我需要将代码移动到数据，而不是将数据移动到接收消息的地方。我知道spark将工作分配给本地已经有文件的执行器。
我对卡夫卡有意见，因为出于上述原因，我被迫先收集它们，以及当想要创建检查点应用程序崩溃时，"因为你试图从广播变量引用SparkContext"，即使代码在添加检查点之前运行(我在那里使用SparkContext，因为我需要将数据保存到ElasticSearch和PostgreSQL。我不知道在这种情况下我到底该如何进行代码升级。
我读过关于hadoop小文件问题的文章，我了解这种情况下的问题是什么。我读到HBase是保存小文件的更好的解决方案，而不仅仅是保存在hdfs中。hadoop小文件问题中的另一个问题是为计算创建了大量的映射器和还原器，但我不明白这个问题是否存在于spark中。
这个用例的最佳体系结构是什么？如何进行作业调度？这是卡夫卡好吗？或者我需要使用其他服务，比如rabbitMQ或其他什么？是否存在通过某些REST API将作业添加到正在运行的Spark应用程序的方法？保存文件的最佳方式是什么？因为我有小文件(<100MB)，所以使用Hbase更好吗？或者我需要使用SequenceFile？我认为SequenceFile不适合我的用例，因为我需要随机重新处理一些文件。
您认为这个用例的最佳架构是什么？
谢谢！
构建体系结构没有单一的"最佳"方法。你需要做出决定并坚持下去。使体系结构灵活且解耦，以便在需要时轻松更换组件。
在您的体系结构中考虑以下阶段/层：
- 源数据(文件)的检索/获取/传输
- 数据处理/转换
- 数据存档
作为检索组件，我会使用Flume。它是灵活的，支持许多源、通道(包括Kafka)和汇。在您的情况下，您可以配置监视目录并提取新接收的文件的源。
对于数据处理/转换，这取决于您正在解决的任务。你可能决定使用Spark Streaming。Spark流可以与Flume水槽集成(http://spark.apache.org/docs/latest/streaming-flume-integration.html)还有其他可用选项，例如Apache Storm。Flume与Storm结合得很好。Flume中也可以应用一些转换。
对于数据归档，不要直接在Hadoop中存储/归档文件，除非它们大于几百兆字节。一种解决方案是将它们放入HBase中。
使您的体系结构更加灵活。我会把处理过的文件放在一个临时的HDFS位置，并有一些工作定期将它们归档到zip、HBase、Hadoop归档(有这样一种动物)或任何其他解决方案中。
考虑使用ApacheNiFi(又名HDF-Hortonworks数据流)。它使用内部队列，提供大量处理器。它可以让你的生活更轻松，并在几分钟内开发出工作流程。试试看。有一个很好的Hortonworks教程，结合在虚拟机/Docker上运行的HDP Sandbox，可以在很短的时间内(1-2小时？)让你跟上进度。