我想弄清楚谷歌趨勢背後的系統設計（或任何其他如Twitter這樣的大規模趨勢功能）。Google趨勢的系統設計？
挑戰：
需要處理大量的數據來計算趨勢。
過濾的支持 - 按時間，區域，類別等
需要一種方法來存儲存檔/離線處理。篩選支持可能需要多維存儲。
這是我的假設是什麼（我的MapReduce/NoSQL的技術零practial經驗）
從用戶的每次搜索項目將保持設置將被保存並最終處理的屬性。
除了按時間戳，搜索的區域，類別等，保持搜索的列表
例子：
搜索Kurt Cobain項：
Kurt-> (Time stamp, Region of search origin, category ,etc.)
Cobain-> (Time stamp, Region of search origin, category ,etc.)
問題：
他們如何有效地計算搜索詞的頻率？
換句話說，給定一個大的數據集，他們如何找到分佈式規模化方式的前10個頻繁項目？
嗯...發現頂尖的K術語並不是一個真正的大問題。在這個領域中的一個關鍵想法是「流處理」的想法，即在數據的一次傳遞中執行操作並犧牲一些準確性以獲得概率答案。因此，假設你得到的數據流如下所示：
A B K A C A B B C d F G A B F H I B的全稱I U X A C
你想要的是前K項。天真地，每個項目都會有一個計數器，最後按每個項目的計數進行排序。這需要O(U)空間和O(max(U*log(U), N))時間，其中U是唯一項目的數量，N是列表中的項目數量。
如果U很小，這並不是什麼大問題。但是，一旦進入數十億或數萬萬次獨特搜索的搜索日誌領域，空間消耗開始成爲問題。
所以，人們提出了「數字草圖」的想法（您可以在這裏閱讀更多：count min sketch page on wikipedia）。在這裏，你保持長度n的哈希表，併爲每個項目兩個散列：
h1(x) = 0 ... n-1均勻概率
h2(x) = 0/1每個概率0.5
那你就A[h1[x]] += h2[x]。關鍵的觀察結果是，由於每個值隨機散列爲+/- 1,E[ A[h1[x]] * h2[x] ] = count(x)，其中E是表達式的預期值，count是流出現在x中的次數。
當然，這種方法的問題是每個估計值仍然有很大的差異，但是可以通過維護大量散列計數器並從每個集合取平均值或最小值來處理。
使用此草圖數據結構，您可以獲得每個項目的大概頻率。現在，您只需維護一個列表中包含10個頻率估計值最高的項目，並在最後列出您的清單。
還需要考慮時間衰減因子 –
我認爲使用以加速查找趨勢的方式構建的特殊數據結構，數據的排列方式可以爲數百萬在線用戶在線預處理所有打開的功能 –
顯然我不能投票結束別人提供的賞金問題，但對我來說，這個問題似乎偏離主題/太廣泛：有許多技術和與此主題相關的研究領域，並且沒有辦法一個答案可以封裝他們，而不是通過鏈接到一些更合適的資源，如教科書或專用網站。爲了解釋幫助中心的指導原則之一：「如果您可以想象基於找到答案的整個職業生涯或商業計劃，那麼問題可能過於寬泛」。 – IMSoP