我們正在制定策略，分析用戶對我們網站上1M +項目的「興趣」（點擊次數，喜歡等）以生成「類似項目」列表。使用Hadoop及相關項目分析不斷變化的使用模式
爲了處理大量的原始數據，我們正在學習Hadoop，Hive和相關項目。
我的問題是關於這個問題：Hadoop/Hive等似乎更適合數據轉儲，接下來是處理週期。據推測，處理週期的結束是相關項之間鏈接的索引圖的擴展。
如果我到目前爲止的軌道上，通常在這些情況下如何處理數據：即，
我在尋找更好的理解這種大數據處理的常用方法。
我認爲這是Hadoop系列工具的一個很好的用例。 它看起來像我HDFS和Flume可能是明顯的選擇，我會考慮到HBase或Hive取決於你對什麼樣的分析感興趣，你是如何靈活的組織數據和查詢它 。
原始用戶數據是否按間隔重新分析以重建鏈接的索引圖？
答：Hadoop對此非常好。我會爲此使用HBase，但還有其他選擇。
我們是否在流入數據時進行流式處理，分析數據並更新數據存儲？
答：Flume對此很好。
由於分析的結果數據發生了變化，我們通常是逐個更新它，還是批量重新處理？
答案：您可以選擇兩種選項。 Bulk可能是HDFS上的MapReduce作業，可以通過HBase列族值或Hive行來管理逐片。如果你提供更多的細節，我可以更精確。
Cassandra比Hive/HDFS更好地解決了這個用例嗎？
回答：Cassandra和HBase都是Google的BigTable的實現。我認爲這個選擇取決於 你如何組織，訪問，分析和更新數據。如有需要，我可以提供更多指導。 HBase通常更適合半結構化，高R/W處理。
DHFS通常是您稱之爲靈活，可擴展的數據轉儲存儲的理想選擇。 Flume適用於移動流數據。
如果你正在思考圖表，我也會考慮看看Titan和HBase。
如果您對面向表格的數據感興趣並使用類似SQL的查詢，則Hive將適用。