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

07 | Workflow设计模式:让你在大规模数据世界中君临天下

蔡元楠 2019-05-01
你好,我是蔡元楠。
今天我要与你分享的主题是“Workflow 设计模式”。
在上一讲中,我们一起学习了大规模数据处理的两种处理模式——批处理和流处理。
利用好这两种处理模式,作为架构师的你就可以运筹帷幄,根据实际需求搭建出一套符合自己应用的数据处理系统。
然而,光是掌握了这两种数据处理模式就足够自如应对大规模数据世界中的需求挑战吗?从我的实战经验中看来,其实未必。
我们每个人在最开始学习大规模数据处理的时候,可能都是以 WordCount 作为教学例子来进行学习的。
WordCount 这个例子,只需要一个单词集合作为输入,数据处理的结果是统计单词出现的次数,中间只需要经过一次数据处理的转换,就如同下图所示。
但在现实的应用场景种中,各式各样的应用需求决定了大规模数据处理中的应用场景会比 WordCount 复杂很多倍。
我还是以我在第一讲中所提到过的例子来说明吧。
在根据活跃在街头的美团外卖电动车的数量来预测美团的股价这个例子中,我们的输入数据集有可能不止一个。
例如,会有自己团队在街道上拍摄到的美团外卖电动车图片,会有第三方公司提供的美团外卖电动车数据集等等。
整个数据处理流程又会需要至少 10 个处理模块,每一个处理模块的输出结果都将会成为下一个处理模块的输入数据,就如同下图所示。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《大规模数据处理实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(23)

  • third
    用户注册,入库,合并模式

    购买机票,分为查询机票和购买

    查询机票,读取特定机票,过滤模式

    购买机票,将所有渠道的票和合并起来,合并模式

    24小时提醒,过滤出这班航班的机票,过滤模式
    发送短信和电子邮箱,复制模式之后,进行分类模式发送

    作者回复: 总结得很好!

    2019-05-01
    52
  • monkeyking
    这几个模式就是sql的几个operator吗?
    复制 → subquery
    过滤 → where
    分离 → group by
    合并 → join

    作者回复: 谢谢你的留言!感觉我又学习到了,计算机的很多底层思想确实都是相通的。

    2019-05-05
    16
  • 利利
    1. 注册:合并模式(因为注册渠道可能会有手机号注册、邮箱注册、微信注册等等不同的渠道,所以需要合并)
    2. 购买机票:过滤+合并(首先过滤出用户查找的航班机票信息、之后查找出符合条件的机票由于可能来自不同的渠道,所有需要合并后返回给用户)
    3. 提醒:复制+过滤+分离
              过滤:根据时间、地点等因素过滤出需要给予提醒的用户 and 机票
              复制:有可能需要对同一份数据(勾选多种提醒方式的用户)进行不同的处理(邮件通知 or 电话通知 or 短信通知)
              分离:将前面过滤出的用户进行分成3组,分别对应(邮件通知 + 电话通知 +短信通知)
    请大佬指教,理解有误没

    作者回复: 谢谢大佬的答案!理解基本无误的!

    2019-05-01
    16
  • 缪斯
    用户注册需要用到合并模式(不同客户端),购票过程需要用到过滤模式(对时间地点进行筛选过滤选票),提醒需要用到分离模式(进行不同渠道的分发提醒通知,如短信,电话等)。

    作者回复: 谢谢你的答案!

    2019-05-01
    8
  • vigo
    秦始皇统一六国过程中都使用什么模式!
    2019-09-28
    1
  • nuclear
    感觉合并模式可能会有问题,如果两个流有差速怎么办?

    作者回复: 谢谢你的提问,这个问题问得很好!对于有边界数据来说,也就是批处理,如果是读取两个流有速度上的误差是没有关系。如果你问的是无边界数据,那种有无止境数据的流处理的话,这里需要要求你在数据完整性和结果的延时上作出取舍了。具体的内容我会在介绍Beam的时候讲到。

    2019-06-05
    1
  • linkzhang
    请问老师,看到很多回答里面都提到,提醒功能需要用到复制模式,但我理解只需要过滤和分离模式,过滤出需要提醒的用户后,如果一个用户勾选了多种通知方式,在分离的过程是不是已经隐含了复制数据,不然前面例子中
    2019-06-02
    1
  • 珅剑
    workflow是否只适用于批处理?

    作者回复: 谢谢你的提问!Workflow作为一种数据处理设计思想是既适用于批处理也适用于流处理的。

    2019-05-09
    1
  • james
    题目用mq可以搞定,没啥模式信手拈来

    作者回复: 谢谢你的答案!就问问你mq消息发丢了怎么办?

    2019-05-04
    1
    1
  • 潘腾
    就spark应用而言,过滤模式可以通过filter实现,

    合并模式可以通过join实现。

    至于复制模式,一般来讲一个rdd在后续处理中被多次使用到,应该就算是复制模式了吧,为了提高效率,可以使用persist持久化。

    分离模式就是groupByKey吧。

    这四种模式在spark中还有没有其他的实现方式呢?
    2019-07-27
  • 风中花
    老师这么一分析,我们这个机票预定流程。就包含了四种模式。真是仔细一想,还就是这个模式。不学习,永远不知道有这样的模式,我们一直在走着这样的模式。真是生在模式中不知模式。
    2019-06-26
  • 风中花
    看来同学们得分析,确实学到了! 购买机票 过程是登录->验证有效性->查询 -> 选择->验证选择-验证用户有效性->购买 结束 。 登录和验证 就是一个过滤 查询 就是一个先复制 因为一份查询到多个平台拿数据。其次过滤 在合并 返回给用户 。用户选择如果不同平台数据必将涉及一个 多平台得预定 所以有一个 数据分离到不同平台预定 然后返回合并返回给用户。机票预定我想也就这么多流程了,至少现在我们现在是这样的,哈哈
    2019-06-26
  • linkzhang
    极客星球评论功能不好用啊(汗)
    请问老师,看到很多回答里面都提到,提醒功能需要用到复制模式,但我理解只需要过滤和分离,过滤出需要提醒的用户后,如果一个用户需要多种方式通知,在分离的过程中是不是已经隐含了复制数据,不然上面的例子中,一个数据无法通过分离模式输入到两个处理模块

    作者回复: 谢谢你的留言!其实还是需要用到复制模式的,分离的过程只是将用户划分在不同的类别中。如果同一个用户需要两种或以上的方式通知,那我们就需要把同一个用户采用复制模式复制到不同的模块中去处理了。

    2019-06-02
  • 长大的肚腩
    可能原始数据源的物理存储位置不同需要用合并模式,但如果针对这个注册的场景,不同渠道我们一般不用模式吧,直接一个canal同步数据库binlog日志到MQ就可以了吧。

    作者回复: 谢谢你的留言!如果只针对注册的场景确实可以有不同的处理方式,如果用MQ的话你可能还需要log一些失败的case再重新处理。

    2019-05-07
  • 来碗绿豆汤
    用户注册完之后,并不一定所有用户都马上买票,所有这里需要一个过滤模式过滤掉没有买票的用户;之后需要一个分离模式,根据用户出行时间分组,发送通知

    作者回复: 谢谢你的答案,你的理解我也赞同!

    2019-05-06
  • 不贰者
    用户注册是会将用户信息用于多个不同的工作流属于复制模式;
    购买机票:用户会根据自己要求查询特定时间和地点的机票这是过滤模式,买票完毕后会发生合并模式,即通过合并模式让可卖的总机票数减一;
    出行前24小时提醒,用户可选择多种提醒方式的一种或多种属于分离模式。

    作者回复: 谢谢你的答案!

    2019-05-05
  • zhihai.tu
    1、用户注册:使用到了合并模式,系统需要整合网页端注册的用户以及手机端app注册的用户。
    2、购买机票:使用到了分离模式,系统根据不同的用户等级,分离出来各个群体,针对不同群体提供不同的折扣力度。同样使用到了过滤模式,例如享有招行信用卡支付优惠2%。
    3、出行前24小时提醒:使用到了分离模式,提供短信提醒、邮件提醒、电话提醒等服务。

    作者回复: 谢谢你的答案!分析得很到位啊!

    2019-05-03
  • Liu C.
    注册:合并模式,把用户合并起来储存
    购票:分离模式,把用户按照机票分类,之后合并模式进行储存
    24小时提醒:过滤模式过滤出需要提醒的用户,之后分离模式,按照所需的提醒方式分类提醒

    作者回复: 谢谢你的答案,分析得不错!

    2019-05-03
  • 罗钛龙
    注册~复制模式
    购票~过滤模式
    提醒~合并/过滤模式

    作者回复: 谢谢你的答案!

    2019-05-01
  • 段斌
    用户注册(复制注册服务)->注册成功(过滤成功注册用户)->购买机票(合并购买动作)->购买机票成功(过滤成功购买用户)->出行前24小时提醒(分离提醒消息系统)

    请元楠给个反馈,评估当前的认知是否正确

    作者回复: 分析得不错,另外我觉得用户注册和注册成功这两步可以合并为一步。

    2019-05-01
收起评论
23
返回
顶部