這是可行的MapReduce用例，甚至可以執行？

Question

我是Hadoop，MapReduce，大數據的新手，並且正在嘗試評估特定用例的可行性，這對於我正在研究的項目非常有趣。 但是，我不確定我想完成的是A）可能是B）還是建議使用MapReduce模型。

本質上，我們有大量的小部件（已知的數據結構）和定價模型（已編入JAR文件），而我們想要做的就是執行小部件和定價模型的每種組合，以確定各個定價的結果模型的排列。 定價模型本身將檢查每個小部件，並根據模型中的決策樹確定定價。

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

因此，問題就變成了可能。 以這種方式實施是否有意義？ 如果不是，還有哪些其他選項/模式更適合這種情況？

編輯數量和種類將隨着時間增長。 為了便於討論，我們假設目前有1TB的小部件和10多種定價模型。 然后，我們期望增長到數TB和100多個定價模型，並且隨着小部件的更改和/或添加以及引入新類別的定價模型，排列的執行將經常發生。

Answer 1

您當然需要可擴展的，可並行化的解決方案，而hadoop可能就是這樣。 您只需要稍微按摩一下自己的解決方案，便可以適應Hadoop的世界。

首先，您需要使模型和窗口小部件實現公共接口（在這里非常抽象地講），以便您可以將任意模型應用於任意窗口小部件，而無需了解實際的實現或表示形式。

其次，您必須能夠通過id引用模型和小部件。 這樣一來，您就可以構建包含模型ID和小部件ID的對象（可寫文件），從而在小部件和模型的叉積中表示一個“單元”。 您可以在多個服務器上分布這些實例，並在多個服務器上將模型的應用程序分布到小部件。 這些對象（稱為ModelApply類）將保存特定的“模型到電子產品”應用程序的結果，並且可以使用hadoop以常規方式進行處理以在最佳應用程序上重新發布。

第三，這是棘手的部分，您需要計算模型與小部件的實際叉積。 您說模型的數量（因此是模型ID）最多為數百個。 這意味着您可以將該ID列表加載到映射器的內存中，並將該列表映射到小部件ID。 每次對映射器的map（）方法的調用都將傳遞一個小部件ID，並將為每個模型寫出一個ModelApply實例。

我現在就保留它。