flink流或批处理
我的任务是重新设计一个现有的目录处理器，需求如下:我有5到10个供应商(每个供应商可以有多个商店)，他们会为我提供每个商店的'XML‘文件。基本上，每个商店1个产品的xml文件，和每个供应商的多个商店文件。最大文件大小可以是500 MB，最小文件大小可以是100 MB，每个文件的平均产品大小可以是100,000。
示例xml格式可能如下所示... ... ...
每个商店下载文件的时间不超过30分钟，这些文件每天或每3到6小时更新一次。
现在的优先要求是，产品细节是高度混乱的，这些文件必须组织、处理(10+过程)并转换为另一个公共对象(Json)，然后将文件存储在Cassandra中。
我的技术主管建议我在HDFS上使用Apache Flink和Kafka进行设计，在HDFS上，flink直接从供应商的服务器流式传输文件，并在流式传输的同时开始处理它们。
我的观点是，无论哪种情况，文件的大小都是有限的，没有太多需要流式传输它们。因此，我想到了一个独立的调度程序来下载文件并将其加载到HDFS。一旦文件加载到HDFS，我就可以触发Flink处理并将其存储在Cassandra中。
我这里的问题是，知道文件是有限的大小和有限的计数，而不考虑供应商的数量，流处理是过度杀伤力，还是批处理会成为以后的延迟负担？
回答 1
Stack Overflow用户
发布于 2016-09-24 05:19:05
这个问题在很大程度上取决于你将要使用的工具。如果你选择Flink，我相信使用流是很好的，而且从长远来看不会产生问题。如果您正确地编写了函数和作业，那么如果需要的话，从DataStream应用程序接口迁移到DataSet应用程序接口将会很容易。Batch在这里引入了一个无用的延迟，而且没有进一步的信息似乎不是合适的方法。我相信它无论如何都会工作得很好，但目前还不清楚延迟是否是一个严格的要求。
也就是说，我认为Flink本身就是一种矫饰。在这个特定的用例中，像Spark这样的更传统的库在可用性方面会是一个更好的选择，但如果你想在Flink上投资，这是完全可以的，考虑到用例，我认为你不需要任何特定的库，这些库存在/集成了spark，但在Flink上却没有。
https://stackoverflow.com/questions/39667578
复制相似问题
腾讯云开发者
