大规模数据处理实战
蔡元楠
Google Brain资深工程师
立即订阅
8402 人已学习
课程目录
已完结 46 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 从这里开始,带你走上硅谷一线系统架构师之路
免费
模块一 | 直通硅谷大规模数据处理技术 (3讲)
01 | 为什么MapReduce会被硅谷一线公司淘汰?
02 | MapReduce后谁主沉浮:怎样设计下一代数据处理技术?
03 | 大规模数据处理初体验:怎样实现大型电商热销榜?
模块二 | 实战学习大规模数据处理基本功 (8讲)
04 | 分布式系统(上):学会用服务等级协议SLA来评估你的系统
05 | 分布式系统(下):架构师不得不知的三大指标
06 | 如何区分批处理还是流处理?
07 | Workflow设计模式:让你在大规模数据世界中君临天下
08 | 发布/订阅模式:流处理架构中的瑞士军刀
09 | CAP定理:三选二,架构师必须学会的取舍
10 | Lambda架构:Twitter亿级实时数据分析架构背后的倚天剑
11 | Kappa架构:利用Kafka锻造的屠龙刀
模块三 | 抽丝剥茧剖析Apache Spark设计精髓 (10讲)
12 | 我们为什么需要Spark?
13 | 弹性分布式数据集:Spark大厦的地基(上)
14 | 弹性分布式数据集:Spark大厦的地基(下)
15 | Spark SQL:Spark数据查询的利器
16 | Spark Streaming:Spark的实时流计算API
17 | Structured Streaming:如何用DataFrame API进行实时数据分析?
18 | Word Count:从零开始运行你的第一个Spark应用
19 | 综合案例实战:处理加州房屋信息,构建线性回归模型
20 | 流处理案例实战:分析纽约市出租车载客信息
21 | 深入对比Spark与Flink:帮你系统设计两开花
模块四 | Apache Beam为何能一统江湖 (8讲)
22 | Apache Beam的前世今生
23 | 站在Google的肩膀上学习Beam编程模型
24 | PCollection:为什么Beam要如此抽象封装数据?
25 | Transform:Beam数据转换操作的抽象方法
26 | Pipeline:Beam如何抽象多步骤的数据流水线?
27 | Pipeline I/O: Beam数据中转的设计模式
28 | 如何设计创建好一个Beam Pipeline?
29 | 如何测试Beam Pipeline?
模块五 | 决战 Apache Beam 真实硅谷案例 (7讲)
30 | Apache Beam实战冲刺:Beam如何run everywhere?
31 | WordCount Beam Pipeline实战
32 | Beam Window:打通流处理的任督二脉
33 | 横看成岭侧成峰:再战Streaming WordCount
34 | Amazon热销榜Beam Pipeline实战
35 | Facebook游戏实时流处理Beam Pipeline实战(上)
36 | Facebook游戏实时流处理Beam Pipeline实战(下)
模块六 | 大规模数据处理的挑战与未来 (4讲)
37 | 5G时代,如何处理超大规模物联网数据
38 | 大规模数据处理在深度学习中如何应用?
39 | 从SQL到Streaming SQL:突破静态数据查询的次元
40 | 大规模数据处理未来之路
专栏加餐 | 特别福利 (4讲)
FAQ第一期 | 学习大规模数据处理需要什么基础?
加油站 | Practice makes perfect!
FAQ第二期 | Spark案例实战答疑
FAQ第三期 | Apache Beam基础答疑
结束语 (1讲)
结束语 | 世间所有的相遇,都是久别重逢
大规模数据处理实战
登录|注册

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

蔡元楠 2019-04-22
你好,我是蔡元楠。
今天我要与你分享的主题是“怎样实现大型电商热销榜”。
我在 Google 面试过很多优秀的候选人,应对普通的编程问题 coding 能力很强,算法数据结构也应用得不错。
可是当我追问数据规模变大时该怎么设计系统,他们却说不出所以然来。这说明他们缺乏必备的规模增长的技术思维(mindset of scaling)。这会限制这些候选人的职业成长。
因为产品从 1 万用户到 1 亿用户,技术团队从 10 个人到 1000 个人,你的技术规模和数据规模都会完全不一样。
今天我们就以大型电商热销榜为例,来谈一谈从 1 万用户到 1 亿用户,从 GB 数据到 PB 数据系统,技术思维需要怎样的转型升级?
同样的问题举一反三,可以应用在淘宝热卖,App 排行榜,抖音热门,甚至是胡润百富榜,因为实际上他们背后都应用了相似的大规模数据处理技术。
真正的排序系统非常复杂,仅仅是用来排序的特征(features)就需要多年的迭代设计。
为了便于这一讲的讨论,我们来构想一个简化的玩具问题,来帮助你理解。
假设你的电商网站销售 10 亿件商品,已经跟踪了网站的销售记录:商品 id 和购买时间 {product_id, timestamp},整个交易记录是 1000 亿行数据,TB 级。作为技术负责人,你会怎样设计一个系统,根据销售记录统计去年销量前 10 的商品呢?
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《大规模数据处理实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(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
  • Mr Zhuo
    老师好,我目前是做NLP落地的,本来是作为补充知识学的这个专栏,但是学了这几节后发现这个方向很有潜力,也很感兴趣。另外由于你们google的BERT横空出世,感觉NLP方向的个人发展有些迷茫,所以想请问老师,对于专栏内容和NLP的结合,在未来发展有没有好的建议呢?
    2019-04-22
    9
  • bwv825
    Top 1 的情况,只统计每台机器的top 1是不是可能会不准确呢?比如数据按时间段分片,某个商品销量很大很稳定,累计总数第一但很少是top 1, 因为各个时间段都有不同的爆款...
    2019-04-27
    4
    8
  • 孙稚昊
    数据量一大,最常见的问题除了各种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
  • 做传统数仓时,使用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
  • leeon
    大规模的topk在计算过程中很容易引发数据倾斜的问题,在实际业务里,计算的优化是一方面,有时候从数据层面去优化也会有更好的效果,以榜单为例,可以在时间维度和地域为度去拆解数据,先小聚再大聚
    2019-04-24
    2
  • 乘坐Tornado的线程魔法师
    顺便复习了王争老师的《数据结构与算法》,看到Top算法的时间复杂度准确来讲应该是是O(nLogK)

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

    2019-04-23
    2
  • Charles.Gast
    数据不数据什么的无所谓,我就想听听那个力学公式的讲解㊣

    作者回复: 哈哈

    2019-04-22
    2
收起评论
43
返回
顶部