hadoop - 用于处理保存在 HDFS 中的小型二进制文件的 Spark 架构

Question

我不知道如何为以下用例构建架构:

我有一个 Web 应用程序，用户可以在其中上传文件 (pdf&pptx) 和要处理的目录。上传完成后，Web 应用程序将此文件和目录放在 HDFS 中，然后在 kafka 上发送一条包含此文件路径的消息。

Spark 应用程序从 kafka 流中读取消息，将它们收集到 master(驱动程序)上，然后进行处理。我首先收集消息，因为我需要将代码移动到数据，而不是将数据移动到接收到消息的地方。我知道 spark 将作业分配给本地已有文件的执行程序。

我对 kafka 有疑问，因为出于上述原因我被迫首先收集它们，并且当想要创建检查点应用程序崩溃时“因为你试图从广播变量中引用 SparkContext”，即使代码在添加检查点之前运行(我在那里使用 sparkContext 是因为我需要将数据保存到 ElasticSearch 和 PostgreSQL。我不知道在这种情况下我该如何进行代码升级。

我阅读了有关 hadoop 小文件问题的文章，我了解这种情况下的问题所在。我读到 HBase 是保存小文件的更好解决方案，而不仅仅是保存在 hdfs 中。 hadoop 小文件问题中的其他问题是为计算创建的大量映射器和缩减器，但我不明白这个问题是否存在于 spark 中。

此用例的最佳架构是什么？如何进行作业调度？卡夫卡对此有好处吗？或者我需要使用其他服务，如 rabbitMQ 或其他？是否存在通过某些 REST API 将作业添加到正在运行的 Spark 应用程序的方法？保存文件的最佳方式是什么？因为我有小文件(<100MB)所以最好使用 Hbase？或者我需要使用 SequenceFile？我认为 SequenceFile 不适合我的用例，因为我需要随机重新处理一些文件。

您认为这个用例的最佳架构是什么？

谢谢!

Answer 1

没有一种单一的“最佳”架构构建方式。你需要做出决定并坚持下去。使架构灵活且解耦，以便您可以根据需要轻松更换组件。

考虑架构中的以下阶段/层:

1. 源数据(文件)的检索/获取/传输
2. 数据处理/转换
3. 数据归档

作为检索组件，我会使用 Flume。它很灵活，支持很多源、 channel (包括 Kafka)和接收器。在您的情况下，您可以配置源来监视目录并提取新收到的文件。

对于数据处理/转换——这取决于您要解决的任务。您可能决定使用 Spark Streaming。 Spark streaming 可以与 Flume sink 集成(http://spark.apache.org/docs/latest/streaming-flume-integration.html)还有其他可用选项，例如 Apache Storm 。 Flume 与 Storm 结合得很好。一些转换也可以在 Flume 中应用。

对于数据归档 - 不要直接在 Hadoop 中存储/归档文件，除非它们大于百分之几兆字节。一种解决方案是将它们放入 HBase。

让您的架构更加灵活。我会把处理过的文件放在一个临时的 HDFS 位置，并有一些工作定期将它们归档到 zip、HBase、Hadoop Archive(有这样的动物)或任何其他解决方案。

考虑使用 Apache NiFi(又名 HDF - Hortonworks 数据流)。它使用内部队列，提供大量处理器。它可以让您的生活更轻松，并在几分钟内开发出工作流程。试试看。有不错Hortonworks tutorial结合在虚拟机/Docker 上运行的 HDP 沙箱，可以让您在很短的时间内(1-2 小时？)加快速度。