个性化推荐系统（六）--- 超大数量业务个性化实战

        线上系统有些业务是每天几百篇增量数据个性化，或者是运营每天选定几百、几千个商品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 

        扫码关注：