MapReduce連續執行

Question

我正在使用Hadoop將現有的時間序列數據庫系統轉換爲MapReduce模型。數據庫系統具有歷史和實時處理能力。到目前爲止，我能夠將批處理功能轉換爲Hadoop。

不幸的是，當涉及到實時處理時，我發現與MapReduce模型存在一些概念上的不一致。

我可以寫我自己的實現Hadoop的InputFormat接口，這將持續飼料與映射器的新數據，從而映射器可以處理和不斷發射數據。 但是，因爲沒有reduce（）方法正在被調用，直到所有的mappers完成它們的執行，我的計算必然會停留在映射階段。

我見過一些提到mapred.reduce.slowstart.completed.maps的帖子，但據我所知，這隻能控制減速器何時開始將數據拉到本地目的地（洗牌） - 實際縮減方法只有在所有的mappers完成之後纔會調用執行。

當然，通過使用連續的獨立MR作業流在小時間間隔內處理小批量數據，可以選擇模擬連續執行，但這會引入額外的延遲，這在我的情況下是不可接受的。

我也考慮過使用Storm或S4，但在進一步移動之前，我需要確保它不在Hadoop的範圍之內。

總之，人們似乎已經能夠開發實時Hadoop應用程序（如Impala）或基於Hadoop構建的實時處理解決方案。問題是如何？

Answer 1

你是正確的減少方法永遠不會被調用，如果InputFormat /映射器連續發射數據。原因是reduce方法必須遍歷鍵的所有值，並且在映射階段完成之前，整個值集都是未知的，因爲要賦予該方法的值可能來自任何方法隨時都可以使用mapper。

reduce方法通過迭代器訪問值，所以從API的角度來看，理論上可以先調用reduce（），並使其在迭代器上永久阻塞直到值可用。 Hadoop中沒有這個特性的原因是它需要在內存中保存每個密鑰的上下文，這對批量處理大數據集沒有意義。

在Hadoop MapReduce編程模型中實現對數據流的連續分析的一種方法是提交連續的小型MR作業流，每個作業分析一大塊數據。在這種情況下處理額外延遲的方法是使用許多可用的Hadoop加速器之一（免責聲明：我爲一家公司工作，ScaleOut Software，他提供了這樣的加速器：ScaleOut hServer - 可在免費社區版中獲得） 。 ScaleOut hServer是可在毫秒內運行MR作業的內存中MapReduce引擎。它在作業之間重用了JVM，因此與Hadoop相比，作業啓動延遲非常小。這對於連續在數據塊上運行MapReduce作業非常合適，因爲它針對適合內存的數據集上的實時性能進行了優化。

以上所有情況的一個例外是，如果分析不需要縮小階段（即，縮減器的數量設置爲0）：如果算法可以表示爲僅映射，則可以連續完成使用一個Hadoop批處理作業。

Answer 2

我個人已經走下了實現MapReduce流式解決方案的道路，但它並不漂亮。無論何時您嘗試使用MapReduce開箱即可完成某些任務，它都會以某種方式失敗。

MapReduce專門用於批處理，您正在尋找的流處理功能是Flume和Storm等技術的主要原因之一。這些都被視爲hadoop生態系統中的事實標準，並與Hadoop的其他部分有良好的整合。

---

您提到您正在處理時間序列數據。你看過OpenTSDB嗎？這是一個建立在HBase和HDFS之上的時間序列數據庫。

Answer 3

Nathan Marz在他即將出版的書籍「大數據」中正在討論「Lambda Architecture」，它將Storm和Hadoop融合在一起提供實時系統。

我也推薦看看Twitter Summingbird，它允許你有：「Streaming MapReduce」模型。

Summingbird是一個庫，它可以讓你編寫看起來像本地Scala或Java集合轉換的流式MapReduce程序，並在Storm和Scalding等衆多知名分佈式MapReduce平臺上執行它們。