大数据经典论文解读
徐文浩
bothub 创始人
13844 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 59 讲
大数据经典论文解读
15
15
1.0x
00:00/00:00
登录|注册

25 | 从S4到Storm(一):当分布式遇上实时计算

你好,我是徐文浩。
到 Spanner 为止,我们已经把大数据里,关于数据存储和在线服务的重要论文解读完了。从这一讲开始,我们就要开始讲解另一个重要的主题,也就是大数据的流式处理。今天我们解读的第一篇论文,来自一个曾经辉煌但是今天已经逐渐销声匿迹的公司 Yahoo。这篇论文就是《S4:Distributed Stream Computing Platform》,伴随着这篇论文的,同样是一个开源系统 Apache S4。和同样孵化自 Yahoo 的 Hadoop 不同,S4 虽然是最早发布的开源分布式流式数据处理系统,但是在市场上最终却没有占有一席之地。
不过,学习 S4 的论文本身还是很有价值的。一方面,你可以看到大数据流式处理的基础结构是怎么样的,你会发现它和批处理的 MapReduce 是非常相似的;另一方面,它又会面临比批处理的 MapReduce 多得多的挑战和困难。
那在学完这一讲之后,你能有这样几点收获:
首先是对于大数据的流式计算问题的基本抽象,也就是它在逻辑上应该是一个什么样的模型,它想要解决的具体问题是什么。
其次是 S4 这个系统的设计是怎么样的,它是如何进行分布式计算的。
最后是 S4 系统的缺陷有哪些,以及有哪些问题 S4 干脆是回避了。这一点对于我们后面去认识 Storm、Kafka 这些系统的核心价值点非常关键。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

大数据领域的流式处理成为研究热点,S4系统通过抽象流式计算为处理元素(PE)对象,构建了一个有向无环图(DAG)的设计,实现了无中心的、完全对称的架构。S4系统的设计思想和挑战为读者提供了对大数据流式处理系统的基本抽象和设计原则的理解,为后续学习Storm、Kafka等系统奠定了基础。S4的架构与MapReduce的设计理念一脉相承,但更加激进,选择了无中心的、完全对称的架构。S4系统的设计为开发人员提供了更高的抽象层面,使其只需关注业务逻辑层面,而不需要关心计算在哪一台服务器上发生,各个节点之间是如何通信的。S4系统的设计思想和架构为大数据流式处理系统的发展提供了重要的参考和启发。 然而,S4的设计也存在一些问题。例如,海量对象的管理、缺乏时间窗口概念、简单的容错处理以及不支持真正的动态扩容等方面存在挑战。这些问题成为后续流式数据处理系统改进的出发点,如Storm、Kafka、Flink等系统。尽管S4在2014年已经从Apache孵化项目中“退役”,但其设计上的各种缺陷成为后来系统的改进点。 总的来说,S4系统是流式计算的起点,其设计上的缺陷为后续系统的改进提供了重要参考。阅读S4的论文原文有助于认识流式计算最原始和粗糙的想法,以及了解流式计算的起源和发展。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《大数据经典论文解读》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(4)

  • 最新
  • 精选
  • 在路上
    徐老师好,第一、MapReduce的每个Reduce任务都会对数据排序,哪怕需要的顺序和输入的顺序一致,在运算大数据集时排序可以让相关的数据靠在一起,减少内存的使用,但是对流式计算来说,把一分钟的数据全部放入内存是可行的,排序应该只在需要的时候进行。 第二、MapReduce的输入是有界数据,所以它总是等上一个任务完成,再开始下一个任务,这样系统不能有效利用所有的分布式资源,并且被掉队者(straggler)拖慢进度。而流式计算,会在上一个任务产生输出之后,马上开始第二个任务,这也决定了流式计算的数据一般不需要排序,因为排序需要等待收到全部数据。
    2021-11-29
    10
  • 沉淀的梦想
    这种 Actor 模型扩容不是应该非常容易吗?为什么 S4 不支持动态扩容呢?是因为底层设计无法支撑,还是单纯没做?
    2023-03-04归属地:浙江
    1
  • CRT
    Mr做实时处理会遇到两个问题,第一个就是每个任务都要启动master,过于消耗时间,我们可以让master常驻来解决,也就是把流任务抽象为一个超级大的批任务,输入源无限大,让mr任务每次处理一小部分;第二个问题是mr任务中间结果会落地磁盘,这个比较好解决,既然每次只处理一部分,这部分在内存处理完直接释放即可。
    2022-01-04
    1
  • 陈迪
    communication layer 类似于node的sidecar😄
    2021-12-01
收起评论
显示
设置
留言
4
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部