2019-05-01用户注册，入库，合并模式
购买机票，分为查询机票和购买
查询机票，读取特定机票，过滤模式
购买机票，将所有渠道的票和合并起来，合并模式
24小时提醒，过滤出这班航班的机票，过滤模式
发送短信和电子邮箱，复制模式之后，进行分类模式发送展开作者回复: 总结得很好！
53
2019-05-05这几个模式就是sql的几个operator吗？
复制 → subquery
过滤 → where
分离 → group by
合并 → join作者回复: 谢谢你的留言！感觉我又学习到了，计算机的很多底层思想确实都是相通的。
19
2019-05-011. 注册：合并模式（因为注册渠道可能会有手机号注册、邮箱注册、微信注册等等不同的渠道，所以需要合并）
2. 购买机票：过滤+合并（首先过滤出用户查找的航班机票信息、之后查找出符合条件的机票由于可能来自不同的渠道，所有需要合并后返回给用户）
3. 提醒：复制+过滤+分离
过滤：根据时间、地点等因素过滤出需要给予提醒的用户 and 机票
复制：有可能需要对同一份数据（勾选多种提醒方式的用户）进行不同的处理（邮件通知 or 电话通知 or 短信通知）
分离：将前面过滤出的用户进行分成3组，分别对应（邮件通知 + 电话通知 +短信通知）
请大佬指教，理解有误没展开作者回复: 谢谢大佬的答案！理解基本无误的！
16
2019-05-01用户注册需要用到合并模式（不同客户端），购票过程需要用到过滤模式（对时间地点进行筛选过滤选票），提醒需要用到分离模式（进行不同渠道的分发提醒通知，如短信，电话等）。作者回复: 谢谢你的答案！
8
2019-09-28秦始皇统一六国过程中都使用什么模式！ 1- 2019-06-05感觉合并模式可能会有问题，如果两个流有差速怎么办？
作者回复: 谢谢你的提问，这个问题问得很好！对于有边界数据来说，也就是批处理，如果是读取两个流有速度上的误差是没有关系。如果你问的是无边界数据，那种有无止境数据的流处理的话，这里需要要求你在数据完整性和结果的延时上作出取舍了。具体的内容我会在介绍Beam的时候讲到。
1 - 2019-06-02请问老师，看到很多回答里面都提到，提醒功能需要用到复制模式，但我理解只需要过滤和分离模式，过滤出需要提醒的用户后，如果一个用户勾选了多种通知方式，在分离的过程是不是已经隐含了复制数据，不然前面例子中 1
2019-05-09workflow是否只适用于批处理？作者回复: 谢谢你的提问！Workflow作为一种数据处理设计思想是既适用于批处理也适用于流处理的。
1
2019-05-04题目用mq可以搞定，没啥模式信手拈来作者回复: 谢谢你的答案！就问问你mq消息发丢了怎么办？
1 1
2020-01-06思考题：我的理解是，还是一个本质，数据集的来源，和数据集的去向去判断设计模式，用户注册的行为可以涉及到的数据集是一个实时首页的航班信息展示，那么是filter mode，从全量的航班信息数据集中找到当前时间段的满足需求的数据集， 购买机票可能涉及到就是某一个条件的数据集合展示，那么可以是filter mode，或者是正对一个相对全量的数据集合，进行多维度的分离，比如按照时间段的处理到一个数据集合，又或者按照价格处理到一个数据集，那么就是splitter mode， 出行前的24小时提醒，数据集来源是所有购买了票的用户，通过时间段的处理filter 到满足某一个时间前24小时这个条件的用户集合，然后进行提醒，这是filter mode，除此之外，对于join mode 的划分还是取决于是否有多个数据源集合的条件，比如一个航空系统的航班信息的设置，是需要收集各种维度的数据决定的，比如其他航空公司的路线数据，天气等数据，这些数据的某一些相同的维度可以join 进行设置该系统的航班信息。展开- 2019-07-27就spark应用而言，过滤模式可以通过filter实现，
合并模式可以通过join实现。
至于复制模式，一般来讲一个rdd在后续处理中被多次使用到，应该就算是复制模式了吧，为了提高效率，可以使用persist持久化。
分离模式就是groupByKey吧。
这四种模式在spark中还有没有其他的实现方式呢？展开 
2019-06-26老师这么一分析，我们这个机票预定流程。就包含了四种模式。真是仔细一想，还就是这个模式。不学习，永远不知道有这样的模式，我们一直在走着这样的模式。真是生在模式中不知模式。- 2019-06-26看来同学们得分析，确实学到了！ 购买机票 过程是登录->验证有效性->查询 -> 选择->验证选择-验证用户有效性->购买 结束 。 登录和验证 就是一个过滤 查询 就是一个先复制 因为一份查询到多个平台拿数据。其次过滤 在合并 返回给用户 。用户选择如果不同平台数据必将涉及一个 多平台得预定 所以有一个 数据分离到不同平台预定 然后返回合并返回给用户。机票预定我想也就这么多流程了，至少现在我们现在是这样的，哈哈
- 2019-06-02极客星球评论功能不好用啊（汗）
请问老师，看到很多回答里面都提到，提醒功能需要用到复制模式，但我理解只需要过滤和分离，过滤出需要提醒的用户后，如果一个用户需要多种方式通知，在分离的过程中是不是已经隐含了复制数据，不然上面的例子中，一个数据无法通过分离模式输入到两个处理模块作者回复: 谢谢你的留言！其实还是需要用到复制模式的，分离的过程只是将用户划分在不同的类别中。如果同一个用户需要两种或以上的方式通知，那我们就需要把同一个用户采用复制模式复制到不同的模块中去处理了。
2019-05-07可能原始数据源的物理存储位置不同需要用合并模式，但如果针对这个注册的场景，不同渠道我们一般不用模式吧，直接一个canal同步数据库binlog日志到MQ就可以了吧。作者回复: 谢谢你的留言！如果只针对注册的场景确实可以有不同的处理方式，如果用MQ的话你可能还需要log一些失败的case再重新处理。
2019-05-06用户注册完之后，并不一定所有用户都马上买票，所有这里需要一个过滤模式过滤掉没有买票的用户；之后需要一个分离模式，根据用户出行时间分组，发送通知作者回复: 谢谢你的答案，你的理解我也赞同！
2019-05-05用户注册是会将用户信息用于多个不同的工作流属于复制模式；
购买机票：用户会根据自己要求查询特定时间和地点的机票这是过滤模式，买票完毕后会发生合并模式，即通过合并模式让可卖的总机票数减一；
出行前24小时提醒，用户可选择多种提醒方式的一种或多种属于分离模式。作者回复: 谢谢你的答案！
2019-05-031、用户注册：使用到了合并模式，系统需要整合网页端注册的用户以及手机端app注册的用户。
2、购买机票：使用到了分离模式，系统根据不同的用户等级，分离出来各个群体，针对不同群体提供不同的折扣力度。同样使用到了过滤模式，例如享有招行信用卡支付优惠2%。
3、出行前24小时提醒：使用到了分离模式，提供短信提醒、邮件提醒、电话提醒等服务。作者回复: 谢谢你的答案！分析得很到位啊！
2019-05-03注册：合并模式，把用户合并起来储存
购票：分离模式，把用户按照机票分类，之后合并模式进行储存
24小时提醒：过滤模式过滤出需要提醒的用户，之后分离模式，按照所需的提醒方式分类提醒作者回复: 谢谢你的答案，分析得不错！
2019-05-01注册～复制模式
购票～过滤模式
提醒～合并/过滤模式作者回复: 谢谢你的答案！