我刚接触Hadoop、MapReduce和大数据,我正在尝试评估它在一个特定用例中的可行性,这个用例对我正在工作的项目非常有趣。然而,我不确定我想要完成的是A)可能的还是B)推荐的MapReduce模型。
我们基本上有大量的小部件(已知的数据结构)和定价模型(编码在JAR文件中),我们想要做的是执行小部件和定价模型的每一个组合,以确定模型排列的定价结果。定价模型本身将检查每个小部件,并根据模型中的决策树确定定价。
在我看来,从商品基础设施的并行处理角度来看,这是有意义的,但从技术角度来看,我不知道是否可以在MR作业中执行外部模型,从实际角度看,我是否正在尝试将用例强加到技术中。
因此,问题变成了:是否有可能;以这种方式实现是否有意义;如果没有,还有什么其他选项/模式更适合此场景?
编辑的数量和种类将随着时间的推移而增长。为了便于讨论,假设我们目前有1 the的小部件和10个定价模型。然后,我们预计将进入数to和100个定价模型,并且随着小部件的更改和/或添加以及新类别定价模型的引入,排列的执行将频繁发生。
发布于 2012-10-03 01:23:59
您当然需要一个可伸缩、可并行的解决方案,hadoop就是这样。您只需稍微调整一下您的解决方案,使其适合hadoop世界。
首先,您需要让模型和小部件实现公共接口(这里非常抽象地说),这样您就可以将任意模型应用于任意小部件,而不必了解任何关于实际实现或表示的信息。
其次,您必须能够通过id引用模型和小部件。这将允许您构建包含模型的id和小部件的id的对象(可写对象),从而在小部件和模型的叉积中表示一个“单元”。您将这些实例分布在多个服务器上,并在这样做的过程中将模型的应用程序分布到多个服务器上的小部件。这些对象(称为类ModelApply)将保存特定模型到小部件应用程序的结果,并且可以使用hadoop以通常的方式进行处理,以便在最佳应用程序上重新发布。
第三,这是棘手的部分,您需要计算模型到小部件的实际叉积。您说模型的数量(以及模型id)最多只能有数百个。这意味着您可以将该id列表加载到映射器的内存中,并将该列表映射到widget id。每次调用映射器的map()方法都会传入一个widget id,并为每个模型写出一个ModelApply实例。
我现在就把它放在这里。
https://stackoverflow.com/questions/12694119
复制相似问题