flink 流式处理或批处理

Question

我的任务是重新设计现有的目录处理器，要求如下要求我有 5 到 10 个供应商（每个供应商可以有多个商店），他们将为每个商店提供“XML”文件。基本上，每个商店有 1 个产品 xml 文件，每个供应商有多个商店文件。最大文件大小可以是 500 MB，最小可以是 100 MB 每个文件的平均产品可以是 100,000。

示例xml格式可能是这样的………………

每个商店下载文件不超过 30 分钟，这些文件每天或每 3 到 6 小时更新一次。

现在的优先要求是，产品详细信息高度无组织，这些文件必须组织、处理（10 多个进程）并转换为另一个通用对象（json），然后文件存储在 Cassandra 中。

我的技术负责人建议我在 HDFS 之上使用 Apache Flink 和 Kafka 进行设计，其中 flink 直接从供应商服务器流式传输文件并在流式传输时开始处理它们。

我的观点是，无论哪种情况，文件的大小都是有限的，没有太多需要流式传输它们。所以想到有一个独立的调度程序来下载器来下载文件并将其加载到 HDFS。文件加载到 HDFS 后，我可以触发 Flink 处理并将其存储在 Cassandra 中。

我的问题是，无论供应商的数量如何，知道文件的大小和数量都是有限的，流处理是过度杀伤还是批处理会成为以后的延迟负担？

Answer 1

这个问题在很大程度上取决于您将使用的工具。如果你选择 Flink，我相信使用流很好，从长远来看不会造成问题。如果您正确编写函数和作业，如果需要，从 DataStream API 迁移到 DataSet API 会很容易。这里的批处理引入了无用的延迟，并且没有进一步的信息似乎不是合适的方法。我相信它无论如何都可以正常工作，但尚不清楚延迟是否是严格要求。

也就是说，我认为 Flink 本身就是一种矫枉过正。在这个特定的用例中，就可用性而言，像 Spark 这样更传统的选择会是更好的选择，但如果你想投资 Flink，那完全没问题，考虑到用例，我认为你不需要任何特定的库与 spark 存在/集成，但在 Flink 上缺失。