線上系統有些業務是每天幾百篇增量數據個性化，或者是運營每天選定幾百、幾千個商品sku
池子個性化，這種是比較好進行存儲管理以及實現的。全站數據進行個性化，每個人相關數據一般
就只有幾個幾十個多個上百個，這個量級數據還可以緩存存儲，可以存下來的。
幾億sku全部存儲，幾十億上百億評論數據，這麼大數據量怎樣存儲怎樣使用是個難題。redis緩
存全部評論信息並且存儲幾十個字段詳情信息，整個存儲將高達幾十個T成本太高。
這個問題可以從用戶需求以及使用場景來尋找突破，我們一般看評論會看前幾頁不斷下翻，但每
頁10個評論的話，一般看10頁很多了。想的挺好的存在個問題就是這是以己推人，可能會出很大問題，
經分析歷史數據發現95%以上用戶只看前30頁，也就是300條數據。
這時我們就可以redis緩存30頁數據，300條之外其他數據存儲在mangodb中和ElasticSearch中。
大部分用戶請求通過快的緩存滿足用戶需求，小部分用戶翻看到30頁之外時通過加載mangodb數據來
加載評論。這時redis緩存數據量可以減少10倍成本降低很多，只有部分用戶體驗降了一些。
評論數據個性化有兩種實現方式一是基於用戶個性化，這種就是每個用戶看到評論數據都是不同的。
另一種是基於評論本身個性化，每個人看到評論是相同的。因爲每個用戶關注評論點不同，有些人更關注
質量、有些人關注品質、有些人關注售後、有些人關注物流，基於用戶個性化是很有意義的。基於評論個
性化是將好的評論通過AI、NLP技術找到，通過情感AI技術識別差的，重複評論來降低低質量評論，節省
用戶時間，提高用戶決策效率。
如果是基於用戶個性化那實現方式是在服務端拉取評論數據，拉取用戶、評論數據、場景當前位置
處於移動還是Wifi、android 還是ios系統、用戶對於評論便好特徵，通過GBDT模型進行CTR點擊量預估。詳
細實現可以看個性化推薦系統（二）---構建推薦引擎以及個性化推薦系統（四）--- 推薦系統服務端。
如果是基於評論個性化，一般在大數據側進行實現。通過hadoop、spark實現根據分析師構建公式進行
離線計算排出每個spu（同種類不同型號不同顏色商品集合例如iPhone有多個內存尺寸、多種顏色，但都屬於一
個spu）下300的池子存儲到redis中，通過strom接收消費消息隊列JMQ、JDQ實時評論信息方式實現新評論插入
到已有排序集合合適位置。實現個性化排序，這時服務端只要根據上游請求spu信息分頁返回評論信息就可以了。
整體上大概介紹了超大數據量線上數據個性化實現方式，整個主體是這樣實現，實際上比如評論情感識別、
無意義評論識別、線上服務出現問題後容災措施、評論根據TD-IDF標籤詞抽取、基於LDA主體抽取，每一件事情
都是需要花時間花人力去解決的好問題。
微信搜索：debugme123
掃碼關注：