Accumulo高速攝取選項

Question

簡而言之，我有一位客戶想要包含在一堆ASCII文本文件（a.k.a「輸入文件」）中的數據攝入Accumulo。

這些文件是從各種數據輸入設備輸出的，並且將在非Hadoop /非Accumulo節點（a.k.a「feed節點」）上連續生成。預計所有提要的整體數據吞吐率將非常高。

爲了簡單起見，假設所有的數據將最終存放在一個正向索引表中，並且一個反向索引表在Accumulo中。

我已經使用pyaccumulo編寫了一個Accumulo客戶端模塊，它可以通過Thrift Proxy建立與Accumulo的連接，從本地文件系統（而不是HDFS）讀取和解析輸入文件，創建適當的正向和反向索引突變在代碼中，並使用BatchWriter將突變寫入正向和反向索引表。到現在爲止還挺好。但還有更多。

從各方面來看，我已經瞭解到，對於Accumulo高速攝取至少有一些標準方法可能適用於我的場景，並且我要求提供關於哪些選項最有意義的建議的資源使用情況，並且易於實施維護。這裏有一些選擇：

1. BatchWriter客戶對飼料節點：運行我Accumulo客戶進節點上。該選項具有在整個網絡上發送正向和反向索引突變的缺點。另外，Accumulo/Thrift庫需要在Feed節點上可用，以支持Accumulo客戶端。然而，這個選項的優勢在於它能夠並行化解析輸入文件和創建突變，並且與以下選項相比，似乎可以最大限度地減少Hadoop集羣上的磁盤I/O。
2. Accumulo主節點上的BatchWriter客戶端：scp/sftp從Feed節點到Accumulo主節點的輸入文件到本地文件系統的某個目錄中。然後只在Accumulo主節點上運行我的Accumulo客戶端。此選項的優勢在於，它不會通過網絡從饋送節點向Accumulo主節點發送正向和反向索引突變，並且不需要Accumulo/Thrift庫在饋送節點上可用。然而，它的缺點是它使Accumulo主節點完成解析輸入文件和創建突變的所有工作，並且它使用Accumulo主設備的本地磁盤作爲輸入文件的入口點。
3. MapReduce with AccumuloOutputFormat：scp/sftp從Feed節點到Accumulo主節點的輸入文件。然後定期將它們複製到HDFS並運行MapReduce作業，該作業從HDFS讀取和解析輸入文件，創建突變，並使用AccumuloOutputFormat編寫它們。此選項具有上述＃2的優點，並行化了解析輸入文件和創建突變的工作。然而，它有一個缺點，它會不斷地啓動和分解MapReduce作業，並調用與這些進程有關的所有開銷。它還有一個缺點，它使用兩個磁盤路徑點（本地和HDFS）以及相關的磁盤I/O。這聽起來有點痛苦，實施和保持連續攝取。
4. MapReduce with AccumuloOutput * File * Format（rfiles）：scp/sftp從Feed節點到Accumulo主節點的輸入文件。然後定期將它們複製到HDFS並運行MapReduce作業，該作業從HDFS讀取並解析輸入文件，創建突變，並使用AccumuloOutputFileFormat編寫rfiles。然後使用Accumulo shell來「攝取」rfiles。這個選項具有上述＃3的所有優點，但是我不知道它是否還有其他優點（是嗎？Accumulo手冊指出了批量攝取：「在某些情況下，以這種方式加載數據可能會更快，而不是通過通過使用BatchWriters的客戶端攝取。「什麼情況？）。它還具有上述＃3的所有缺點，除了它使用三個磁盤路點（本地，HDFSx2）以及相關的磁盤I/O。實施和維持連續攝取聽起來很痛苦。

就我個人而言，只要Accumulo主節點可以處理其自身（非並行輸入文件解析）所涉及的處理負載，我最喜歡選項＃2。我可以在每個Accumulo節點上運行我的Accumulo客戶端並將不同饋送節點的輸出發送到不同的Accumulo節點或循環法的＃2變體仍然具有在整個雲中發送正向和反向索引突變的缺點網絡連接到Accumulo主設備，但具有並行執行輸入文件分析的優點。

我需要知道的是：我錯過了任何可行的選擇嗎？我錯過了每個選項的優點/缺點嗎？無論我的問題情況如何，尤其是網絡帶寬/ CPU週期/磁盤I/O折衷，有哪些優點/缺點是微不足道的或非常重要的？與BatchWriter相比，MapReduce有沒有值得遇到的麻煩？有沒有人有「戰爭故事」？

謝謝！

Answer 1

即使在每個用例中，人們對於如何實現特定用例的解決方案都有個人偏好。實際上，我會在Feed節點上運行flume代理，並在HDFS中收集數據，並定期對使用RFile方法到達HDFS的新數據運行MapReduce。