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

30 | Dataflow(二):MillWheel,一个早期实现

你好,我是徐文浩。
上一讲里,我们通过一个简单的统计广告点击率和广告计费的 Storm Topology,看到了第一代流式数据处理系统面临的三个核心挑战,分别是:
数据的正确性,也就是需要能够保障“正好一次”的数据处理。
系统的容错能力,也就是我们不能因为某一台服务器的硬件故障,就丢失掉一部分数据。
对于时间窗口的正确处理,也就是能够准确地根据事件时间生成报表,而不是简单地使用进行处理的服务器的本地时间。并且,还需要能够考虑到分布式集群中,数据的传输可能会有延时的情况出现。
这三个能力,在我们之前介绍的 Kafka+Storm 的组合下,其实是不具备的。当然,我们也看到了,这些问题并不是解决不了,我们也可以在应用层撰写大量的代码,来进行数据去重、状态持久化。但是,一个合理的解决方案,应该是在流式计算框架层面就解决这些问题,而不是把这些问题留给应用开发人员。
围绕着这三个核心挑战,在 2013 年,Google 的一篇论文《MillWheel: Fault-Tolerant Stream Processing at Internet Scale》给我们带来了一套解决方案。这个解决方案,在我看来可以算是第二代流式数据处理系统。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

MillWheel是Google在2013年提出的第二代流式数据处理系统,旨在解决流式数据处理中的三大核心挑战:数据的正确性、系统的容错能力和时间窗口的正确处理。该系统引入了Computation和Key的概念,通过有向无环图来表示流式数据处理,实现了更高效的数据处理和容错能力。MillWheel的设计极大地提高了流式数据处理的效率和容错能力,为解决大规模流式数据处理问题提供了重要的思路和方法。 MillWheel还解决了流式数据处理中的容错问题,通过强大的基础设施(如Bigtable和Spanner)实现了数据持久化和容错能力。系统采用Strong Production策略,确保数据的严格一致性,同时采用租约机制来避免僵尸进程和数据不一致性问题。MillWheel还支持Weak Production,允许关闭去重机制和Strong Production机制,以提高计算资源的利用效率。 总之,MillWheel是一款高效、可靠的流式数据处理系统,通过引入新的概念和机制,解决了流式数据处理中的关键挑战,为大规模数据处理提供了可靠的解决方案。虽然MillWheel还有一些不足之处,但它已经迈出了解决容错问题和一致性问题的重要一步。

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

全部留言(5)

  • 最新
  • 精选
  • 在路上
    徐老师好,在MillWheel中为了保证消息处理至少一次的语义,Computation的每条消息在发送之后都需要应答,收不到应答就会不断重试。String Production的做法是,下游Computation收到消息后存起来,然后立即应答上游的Computation。Weak Production的做法是,不保存消息,不保存消息就必须等整个链路处理完再逐层应答,链路越长,遇到故障的可能性越大,故障会导致消息从头消费,整个系统的延迟就变大了。解决方法就是Computation在发出消息一段时间后收不到应答,就把消息存起来,并应答上游的Computation。这样如果下游链路出问题,只需要从当前的Computation开始重试,而不用从头开始。
    2021-12-31
    1
    12
  • zart
    徐老师好,每一个 Computation + Key 的组合,在接收到一条消息的处理过程的第一步,消息去重,使用分段的 BloomFilter 来解决,不是会有小概率的误判,导致非重复的消息也会判断为重复,这样就会导致丢数据。请问会有这种情况么?MillWheel如果允许这种情况就做不到ExactlyOnce了吧
    2022-01-06
    1
    2
  • Geek_64affe
    因为没有Checkpoint,所以只能通过不断重试来确保消息不丢失,并且重试的粒度是整个计算过程,如果计算过程比较深,每一个Computation都需要重新计算,很可能会慢于Checkpoint机制
    2022-10-09归属地:浙江
    1
  • InfoQ_cdca53d71446
    "网络传输是乱序的,我们其实并不知道是 X 会先到下游,还是 Y 会先到下游." 这里有点歧义. tcp传输已经解决了包乱序的问题. 这里的乱序, 应该是两个并发tcp连接,发送的包谁先到服务端不确定的意思.
    2022-06-05
    1
    1
  • CRT
    不是很明白保存状态和checkpoint的区别是什么,就像文章说的,如果一个computation已经通过timer发送了消息x,按道理如果故障重启后不会有相同时间窗口的消息才对。
    2022-01-09
    1
收起评论
显示
设置
留言
5
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部