我的任务是重新设计现有的目录处理器和要求如下 我有5到10个供应商（每个供应商可以有多个商店），他们会为我提供每个商店的“xml”文件。基本上，每个商店有一个产品xml文件，每个供应商有多个商店文件。最大文件大小可以是500 mb，最小可以是100 mb平均每个文件的产品可以是100000。
示例xml格式可以是这样的。。。
每个商店下载文件不需要超过30分钟，而且这些文件每天更新一次或每3到6小时更新一次。
现在优先级要求 也就是说，产品细节是高度无组织的，这些文件必须经过组织、处理（10+个进程）并转换为另一个公共对象（json），然后将文件存储在cassandra中。
我的技术负责人建议我在hdfs的基础上使用apache flink和kafka进行设计，flink直接从供应商服务器流式传输文件，并在流式传输时开始处理它们。
我的观点是，无论哪种情况，文件的大小都是有限的，不需要太多的数据流。因此，我们考虑使用一个独立的调度器来下载文件并将其加载到hdfs。一旦文件加载到hdfs，我就可以触发flink处理并将其存储在cassandra中。
我在这里的问题是，知道文件的大小是有限的，数量是有限的，不考虑供应商的数量，流处理是一种过度杀伤力，还是批处理会成为以后的延迟负担？
1条答案
按热度按时间pzfprimi1#
这个问题在很大程度上取决于你将使用的工具。如果你选择flink，我相信使用流是好的，从长远来看不会造成问题。如果您正确地编写了函数和作业，那么如果需要的话，从datastreamapi迁移到datasetapi将很容易。批处理在这里引入了一个无用的延迟，没有进一步的信息似乎不是合适的方法。我相信它无论如何都可以工作，但不清楚延迟是否是一个严格的要求。
也就是说，我相信Flink本身就是一个过度杀戮。在这个特定的用例中，一个更传统的像spark这样的库在可用性方面会是一个更好的选择，但是如果你想在flink上投资的话，它是完全好的，并且考虑到这个用例，我认为你不需要任何特定的库，它是spark的现有库/集成库，但是在flink上是缺失的。