03 | 大规模数据处理初体验：怎样实现大型电商热销榜？

精选留言(43)

• 

  青石

  好多年前还未接触大数据时，写过日志采集统计各接口请求报表及puv的脚本，经历了几个阶段。
  1. 最初是汇总所有日志到一台服务器，在处理日志，测试环境没问题，上生产跑起来就几个小时。
  2. 后来分到Web服务器各自处理数据，时间缩短了，但是汇总数据偶尔会有问题。
  3. 将数据写入到数据库，解决汇总数据问题。但是单表数据量过大，统计又很慢。
  4. 按天分表解决数据量问题，最后就这么一直运行下去了。
  
  这段经历其实很普通，但也确实让我更轻松的学习和理解大数据。当我学到mapreduce内容的时候，回忆起这段经历，让我很容易就接受了mapreduce的分治思想。
  
  就像看到hbase的时候，我的理解它就是在实现数据的寻址、不断的拆分/合并表，但是原来的人工操作变成现在自动化操作。

  2019-04-22

  

   21
• 

  Liu C.

  有一次处理一个非常高维的feature矩阵，要给它降维，但手头的电脑cpu和内存都不够好。于是我用了非常hack的手段：先使用random projection算法降低一定维度，这是一个纯矩阵乘法，可以分块放入内存计算。之后剩余的维度还是有些大，于是我把feature拆成几组，对每组分别做pca，之后再选出每组最大的主成分拼起来，就完成了降维。
  

  作者回复: 谢谢你的经验分享！

  2019-04-22

  

   21
• 

  bwv825

  Top 1 的情况，只统计每台机器的top 1是不是可能会不准确呢？比如数据按时间段分片，某个商品销量很大很稳定，累计总数第一但很少是top 1, 因为各个时间段都有不同的爆款...

  2019-04-27

   4

   9
• 

  Mr Zhuo

  老师好，我目前是做NLP落地的，本来是作为补充知识学的这个专栏，但是学了这几节后发现这个方向很有潜力，也很感兴趣。另外由于你们google的BERT横空出世，感觉NLP方向的个人发展有些迷茫，所以想请问老师，对于专栏内容和NLP的结合，在未来发展有没有好的建议呢？

  2019-04-22

  

   9
• 

  孙稚昊

  数据量一大，最常见的问题除了各种exception，就是key 值分布不均衡。电商一般都是长尾的，少量的item 占据大多数购买量，很容易发送数据倾斜，需要设计更新的hash-sharding 方法

  2019-04-23

  

   8
• 

  Kev1n

  个人经验，拆分，复制，异步，并行，是大规模数据处理和应用架构的常见手段，一致性根据业务场景适当妥协

  2019-04-22

  

   7
• 

  孙稚昊

  我们在做商品订单统计的时候，会按itemid + order year + order month 对订单做hash来做group 的 key，分割成更小块，防止popular item 堆积造成的瓶颈

  2019-04-23

  

   6
• 

  乘坐Tornado的线程魔法师

  作者好！找出前K个集群小节里面的第一个计算集群的第二个节点（机器），是否应该像第一个节点一样计算product_id=1的所有记录。文中图示貌似只有第一个节点计算了。请作者查证。

  作者回复: 这个图里面是按照product_id分组了，所以所有product id =1的都归第一个机器

  2019-04-22

  

   6
• 

  Codelife

  最初，GPS数据以文件形式存储在盘阵中，数据增长达到TB级别后，考虑到性能和成本以及可扩展性，系统迁移到HDFS中，离线任务用MR，在线查询采用HBSE，现在，数据PB级别后，发现热点数据hbase成本太高，系统迁移到时序数据库，专供线上实时查询，同时，实时分析采用storm，批处理用spark。其实，很多情况下，采用什么技术，成本具有决定性因素

  2019-04-23

  

   5
• 

  zhihai.tu

  有一个项目，试点的时候由于用户访问量小，传统负载均衡F5下连6台应用服务器访问为啥问题。后续推广后，由于访问量出现了50倍以上的增加，前台响应慢，服务器也出现内存溢出等问题。后续采用了docker容器技术，从应用服务器上抽取出并发访问较高的服务模块，单独部署服务层，支持横向扩展以及在线扩容，较好的解决了问题。

  2019-04-22

  

   5
• 

  hua168

  分解法…像剁鱼那样，一条一口吃不下就切成块，块一口吃还大，有风险，再就再用筷子分小…
  关键问题是怎么切，切多大？怎么不全切碎，让它完整的，让人知道是条鱼😄

  作者回复: 你这比喻很屌

  2019-04-22

  

   4
• 

  leeon

  大规模的topk在计算过程中很容易引发数据倾斜的问题，在实际业务里，计算的优化是一方面，有时候从数据层面去优化也会有更好的效果，以榜单为例，可以在时间维度和地域为度去拆解数据，先小聚再大聚

  2019-04-24

  

   3
• 

  涵

  做传统数仓时，使用oracle数据库，随着数据量增大会需要使用到分区。分区需要思考使用哪个属性来分，分成多大的区间合适。另外，当视图很大时，有时查询很慢，会使用物化视图的方法。

  作者回复: 谢谢你的经验分享！

  2019-04-22

  

   3
• 

  JohnT3e

  数据倾斜，导致任务运行时间超出预期，这个时候就需要对数据做一些分析和采样，优化shuffle。任务出错后，调试周期变长，这个目前没有很好的解决。不过，之前看flumejava论文，其采用了缓存不变结果来加快调试周期。另外，就是集群规模增大，后期运维的问题了

  作者回复: 谢谢你的经验分享！

  2019-04-22

  

   3
• 

  哈哈

  将大规模数据拆解到多台机器处理，还应该用一定的规则哈希到每台机器吧

  2019-05-10

  

   2
• 

  Daryl

  作者其实关于top k没描述清楚，虽然我明白他的意思，因为我了解这边，但是对于没有了解的同学会有点晕乎

  2019-04-29

  

   2
• 

  朱同学

  实际上传统服务也是这样，业务初期我们一台物理机，后面又是三台物理机，做的反向代理小集群，到现在几个机柜做了虚拟化，数据库也做了读写分离，说到底就是集群化处理

  作者回复: 谢谢你的经验分享！

  2019-04-26

  

   2
• 

  hufox

  以前做订单系统的时候，由于数据量没有那么大，没有考虑到大规模数据处理问题，但是一旦数据量上来了，统计查询都很慢，今天阅读了老师这一讲，原来可以这样设计处理大规模数据问题，涨姿势了！继续学习！

  作者回复: 谢谢支持！

  2019-04-24

  

   2
• 

  乘坐Tornado的线程魔法师

  顺便复习了王争老师的《数据结构与算法》，看到Top算法的时间复杂度准确来讲应该是是O(nLogK)

  作者回复: 这里K远小于n，写成O(n)没有问题

  2019-04-23

  

   2
• 

  Charles.Gast

  数据不数据什么的无所谓，我就想听听那个力学公式的讲解㊣

  作者回复: 哈哈

  2019-04-22

  

   2