2012-10-02 36 views
0

我是Hadoop,MapReduce,Big Data的新手,我試圖評估它對於我正在開發的項目非常有趣的特定用例的可行性。但我不確定,如果我想完成的是A)可能的或者B)推薦使用MapReduce模型。這是一個可行的MapReduce用例,甚至可能執行?

我們基本上擁有大量小部件(已知的數據結構)和定價模型(編入JAR文件),我們希望能夠做的是執行小部件和定價模型的每個組合以確定結果的模型排列中的定價。定價模型本身將檢查每個小部件,並根據模型內的決策樹確定定價。

這對我在腦海中對商品基礎設施角度的並行處理很有意義,但從技術角度來看,我不知道是否有可能在MR作業內部執行外部模型,並且從實際角度來看我是否嘗試強制使用案例進入技術。

問題因此變成了可能;以這種方式實施是否合理?如果不是更適合這種情況的其他選項/模式是什麼?

編輯 數量和品種會隨着時間而增長。爲了討論的緣故,我們假設我們目前有一個terabyte小部件和10個定價模型。隨後,我們預計會涉及多TB和100多種定價模型,並且隨着小部件更改和/或添加以及引入新類別的定價模型,排列的執行將會頻繁發生。

+0

有趣的...你能更具體地瞭解你有多少數據? MapReduce,Hadoop和BigData都很棒,但老實說,除非你有超過TB數量的原始數據進行處理,否則它們是過量的。 –

回答

0

你當然需要一個可擴展的,可並行化的解決方案,而hadoop可以是這樣的。你只需要稍微按摩你的解決方案,以適應hadoop世界。首先,您需要使模型和小部件實現通用接口(在此處講得非常抽象),以便您可以將任意模型應用於任意小部件而無需知道任何有關實際實現或表示的內容。

其次,您必須能夠通過id引用模型和小部件。這可以讓你創建持有模型id和小部件id的對象(可寫),從而代表小部件和模型交叉產品中的一個「單元」。您可以將這些實例分佈到多個服務器上,並將這些模型的應用程序分佈到多個服務器上的小部件。這些對象(稱爲類ModelApply)將保存特定模型到窗口小部件應用程序的結果,並且可以用通常的方式使用hadoop處理,以重新發布最佳應用程序。

第三,這是棘手的部分,您需要計算模型與小部件的實際交叉乘積。你說模型的數量(以及模型ID)最多會有數百個。這意味着你可以在映射器中將該列表的id加載到內存中,並將該列表映射到widget ID。每次調用映射器的map()方法都會傳入一個小部件ID,併爲每個模型寫出一個ModelApply的實例。

我現在就離開它。

相關問題