大规模数据处理实战
蔡元楠
Google Brain资深工程师
立即订阅
8411 人已学习
课程目录
已完结 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讲)
结束语 | 世间所有的相遇,都是久别重逢
大规模数据处理实战
登录|注册

05 | 分布式系统(下):架构师不得不知的三大指标

蔡元楠 2019-04-26
你好,我是蔡元楠。
上一讲中,我们学习了如何用服务等级协议(SLA)来评估我们设计的分布式系统,并了解了几个常见的 SLA 指标。
今天我们继续来探索分布式系统的另外几个重要基础概念。

可扩展性

还是从我们为什么需要分布式系统讲起。原因是我们要面对的数据量越来越大,从 GB 到 TB 再到现在的 PB 级,单机无法胜任这样的工作。
工作中也常有这样的场景,随着业务变得越来越复杂,之前设计的系统无法处理日渐增长的负载。这时,我们就需要增加系统的容量。
分布式系统的核心就是可扩展性(Scalability)。
最基本而且最流行的增加系统容量的模型有两种: 水平扩展(Horizontal Scaling)和垂直扩展(Vertical Scaling)。
所谓水平扩展,就是指在现有的系统中增加新的机器节点。
垂直扩展就是在不改变系统中机器数量的情况下,“升级”现有机器的性能,比如增加机器的内存。
举个例子,假设你现在负责一批木材采伐的操作。你有 3 辆卡车,每辆车一次可以运 25 根木材。那么 1 小时最多可以运 3 辆卡车 * 25 根木材 * 1 小时 =75 根木材/小时。
如果要使这个系统的负荷量增加一倍,用水平扩展的办法,我们可以将卡车的数量增加到 6 辆;用垂直扩展的办法,我们可以使每辆卡车的运输量增加一倍,或者使每辆卡车的速度增加一倍。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《大规模数据处理实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(31)

  • JohnT3e
    微信朋友圈评论主要由评论和后续回复组成:
    首先,对于评论,评论内容对评论者而言应该要保证读写一致性(read-your-writes consistency),即评论一旦发出,那么对于该评论者无论在手机、网页还是其它城市应该都能看到其之前写的评论。而对于朋友圈可见的其它人来说,只要保证最终一致性(eventual consistency)就可以了(可能有时间要求),不同人的评论读取顺序无需和真实发生的顺序保持一致;
    其次,对于评论的后续回复。回复内容对于回复者而言应该要保证读写一致性(read-your-writes consistency),而其它朋友圈可见的人一样,评论和回复内容应该按顺序被读取到,即需要保证一致前缀读(Consisten Prefix Reads)
    2019-04-26
    27
  • 3SKarl
    老师,我不太明白弱一致性和最终一致性的区别在哪里,文章对弱一致性提到
    “经过不一致时间窗口这段时间后,后续对该数据的读取都是更新后的值”
    这句描述的不就是最终一致性么

    是不是说弱一致性允许数据始终不一致,而要求最终结果一致的弱一执性叫做最终一致性

    作者回复: 你好,这是个很棒的问题。简而言之,弱一致性是个很宽泛的概念,它是区别于强一致性而定义的。广义上讲,任何不是强一致的,而又有某种同步性的分布式系统,我们都可以说它是弱一致的。而最终一致性是弱一致性的一个特例,而且是最常被各种分布式系统用到的一个特例。其他的比如因果一致性、FIFO一致性等都可以看作是弱一致性的特例,不同弱一致性只是对数据不同步的容忍程度不同,但是经过一段时间,所有节点的数据都要求要一致。

    学习时也没必要抠字眼,重要的是理解它们的区别。这部分知识是为了后边讲CAP理论服务的,实际的工作中不会像考试考概念题一样让你背写这些一致性的定义。

    如果你还有疑问,欢迎继续留言。

    2019-04-26
    23
  • leeon
    朋友圈保证最终一致性即可,消息发布后,先保证“端”是可见的,等待网络请求后会确认最终有无发布成功,成功后最终其他人的timeline会收到

    作者回复: 你的想法很好,但是有的场景下最终一致性还不够。试想这个场景,A发布了一张图片,B问他这是哪里,然后C回答B这里是北京。这个例子中,C的评论一定要在B之后,因为他俩有逻辑上的因果关系。所以微信朋友圈的评论要满足这样的因果一致性。因果一致性也是弱一致性的一个特例,感兴趣的话可以去多搜索点资料来学习~

    2019-04-26
    8
  • hallo128
    恩~其实我好像没有听懂~介绍了几个概念的定义,但还是不理解它们之间的联系和差别。
    2019-04-26
    4
  • hua168
    老师我想问一下,所谓的强一致性,它允许的误差是多少范围?
    比如金融股票大厅显示屏数据,应该是强一致性的吧,全球显示误差不会超过0.2s吧?
    这样强一致性怎达到?网络传输,路由处理都不止了,更何况还有网络延迟

    作者回复: 谢谢你的提问!强一致性并没有误差可言的,强一致性简单地说指的就是如果更新一条数据,那所有用户读取数据的时候必须都看到这条更新了的数据。

    在这里我也分享一个自己的面试经历。其实这个问题恰好我当年在面试Bloomberg的时候面到过,是一道系统设计题。问的大概是在设计他们家股票信息系统的时候,数据的更新写入量太大,用户也需要读取最新的股票资讯,该如何设计这套系统。最后和它家的tech lead讨论发现,原来他们的股票系统显示的延迟范围是1分钟左右,因为应用场景上普通股民并不会需要实时关心每秒钟股票价格的动态,更多的是关心大盘走势。而金融巨头在操作股票的时候更多只关心特定的几只股票,所以这些股票的价格通常对于他们来说会更新快一点。

    所以说金融股票大厅上的数据应该不会是强一致性的,延时误差也应该没有你想象的那么少。

    2019-04-30
    1
    3
  • 明翼
    笔记总结:扩展性包括水平和垂直,水平扩展是增加水平类似的机器打群架方式,垂直扩展是现有的每个人提升实力,提升整体实力;一致性,集群上的数据为了保证高可用性显然要存在不同机器上存多份,这就存在不同机器数量同步问题,要求同步造成才可以进行读写的就是最终一致性,中间准许有个不一致时间窗的就是弱一致性,时间窗更长但是最终会统一的就是最终一致性,比如发微博场景,还讲了数据持久性,消息的持久性,一般类似kafka之类消息总线系统可以配置各种持久性要求,比如要求所有主和副本都同步,要求只要发给主即可,有的发送不需要确认。

    关于问题:朋友圈属于最终一致性,信息推送晚一会不是特别重要,所以最终一致性满足要求

    作者回复: 很棒的总结。

    对于思考题的答案,建议你再读读别的读者得留言,有的留言思考很深入~

    2019-04-26
    3
  • 陈建斌红了..
    ap模型,先保证评论的人自己能看见,再保证被评论的人和别人能看见。
    2019-04-26
    3
  • Flash
    老师,消息队列的持久性第二点不是太能理解,意思是说消息发送者发完消息后,接收者下线了,然后接收者上线仍能收到吗?

    作者回复: 谢谢你的提问!没错,这里的持久性指的就是消息队列在接收到发送者发送的消息后,只要没有收到接收者的回应,就会一直尝试发送消息给接收者,直到收到回应为止。所以接收者下线了再上线仍是能收到消息队列发送的消息。当然中间如果超过了消息保留期限或者一定的重发次数也会消息队列也会停止发送。

    2019-05-06
    2
  • 利利
    朋友圈采用最终一致性+因果一致性就好,只要保证评论及其派生评论是有序的,以保证其逻辑、语义上面不会出现混乱,场景对延时性要求不高;另外,有注意到手机端的微信和PC端的微信,会出现数据不一致的情况(特别是微信公众号订阅的文章,PC端少些文章)
    2019-04-28
    2
  • 对于微信朋友圈的评论功能我想最终一致性,保护因果一致性的特征就够了。从需求角度,微信朋友圈是一种社交工具,不具有critical的特性,数据一致的实效性要求不高。每个独立评论的先后顺序也不那么重要。重要的是对于某一条评论的评论必须显示在派生这条评论的原始评论之后,否则用户读起来会很混乱。从最低成本满足需求的角度,因此最终一致性加上因果一致性特征即可。
    2019-04-27
    2
  • 炖排骨
    弱一致性,场景可以容忍一定时间的延迟。
    2019-04-26
    2
  • Darrykinger.com
    这一节课,怎么让我想起了阿里李云华<从零到架构师>中提到的CAP理论,这大规模数据和架构师之间的知识看来是想通的着呀

    作者回复: 谢谢你的留言!有同感,其实当你学识更广之后会发现计算机中很多方向都是相辅相成的,并不会说某一块知识是相对独立起来的。

    2019-05-02
    1
  • 欢喜
    因果一致性。比如说A评论了,然后B评论了A的评论,只要保证A的评论在B对于A的评论之前就行了。
    2019-04-26
    1
  • Codelife
    以前曾经考虑过微信朋友圈这个一致性问题,最初认为是顺序一致性,仔细一想,如果是顺序一致性,成本太高,也没必要,对于微信朋友圈的评论来说,只有互为好友的人才能看到,评论也是互为好友的人,如果A发了朋友圈,所有人对A的评论,只有A才能完全看到,同时,B对A如果进行了评论,C对B的评论进行了评论,那么,对于A,B,C来说,C的评论肯定在B之后,只要保证互相能看到的评论一致即可,所以应该是因果一致性,至于如何的,暂时还没考虑
    2019-04-26
    1
  • 孙稚昊
    我觉得微信朋友圈只要最终一致就够了,没有对更新延迟那么高的要求
    2019-04-26
    1
  • 有铭
    我想请教老师,有些业务,不用关系数据库的话,如果处理分析需求(OLAP)?就我所知连google这样的公司某些时候还是必须用join来完成一些数据分析。比如下面这类需求,分布式系统里,用户表和订单表在不同的库里。请查出所有20-30岁用户的订单,并按照一定的规则进行数据统计。而20-30岁的用户数量可能非常庞大,十几万之多,这类的需求。非关系型的数据库,或者分布式系统如何做统计?统计现在才是大部分公司实施分布式数据处理的困难点,相反事务倒不是那么重要了,互联网企业的需求对强一致性要求没那么高
    2019-04-26
    1
  • 倪必荣
    思考题的评论系统,最终一致性比较合适,强一致的高延迟会非常影响用户评论的兴致
    2019-06-13
  • 西北偏北
    为了提高系统的吞吐量,我们需要水平扩展。
    水平扩展后,消息,数据在集群中的传输,需要可靠的一致性保证。由于是分布式,无法保证像单机一样的强一致,只能保证最终一致性

    分布式集群中,可能涉及通过通信沟通,去保证最终一致性,但通信可能会丢失。要么通过算法去保证,即便通信丢失,集群也能协商出一个一致的结果,比如paxos和raft算法。要么通过可靠的消息中间件来保证消息的可靠传达和消费。
    2019-06-13
  • roaming
    看老师评论里说需要最终一致性和因果一致性,感觉这个因果一致性和Java内存模型里的happens-before好像

    作者回复: 谢谢你的留言!是的呢,在第九讲里面所讲到的线性一致性(Linearizability)其实也和Java Memory Model有关。如果在Java中修改的变量是volatile的话就会有这种线性一致性。

    2019-05-09
  • 果果几号
    对于想深入学习分布式系统,有什么学习资料推荐的吗?
    2019-05-02
收起评论
31
返回
顶部