首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >flink流或批处理

flink流或批处理
EN

Stack Overflow用户
提问于 2016-09-24 02:42:45
回答 1查看 646关注 0票数 0

我的任务是重新设计一个现有的目录处理器,需求如下:我有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中。

我这里的问题是,知道文件是有限的大小和有限的计数,而不考虑供应商的数量,流处理是过度杀伤力,还是批处理会成为以后的延迟负担?

EN

回答 1

Stack Overflow用户

发布于 2016-09-24 05:19:05

这个问题在很大程度上取决于你将要使用的工具。如果你选择Flink,我相信使用流是很好的,而且从长远来看不会产生问题。如果您正确地编写了函数和作业,那么如果需要的话,从DataStream应用程序接口迁移到DataSet应用程序接口将会很容易。Batch在这里引入了一个无用的延迟,而且没有进一步的信息似乎不是合适的方法。我相信它无论如何都会工作得很好,但目前还不清楚延迟是否是一个严格的要求。

也就是说,我认为Flink本身就是一种矫饰。在这个特定的用例中,像Spark这样的更传统的库在可用性方面会是一个更好的选择,但如果你想在Flink上投资,这是完全可以的,考虑到用例,我认为你不需要任何特定的库,这些库存在/集成了spark,但在Flink上却没有。

票数 0
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/39667578

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档