大规模数据处理实战
蔡元楠
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讲)
结束语 | 世间所有的相遇,都是久别重逢
大规模数据处理实战
登录|注册

11 | Kappa架构:利用Kafka锻造的屠龙刀

蔡元楠 2019-05-10
你好,我是蔡元楠。
今天我要分享的主题是 Kappa 架构。
同样身为大规模数据处理架构,Kappa 架构这把利用 Kafka 锻造的“屠龙刀”,它与 Lambda 架构的不同之处在哪里呢?
上一讲中,我讲述了在处理大规模数据时所用到经典架构,Lambda 架构。我先来带你简要回顾一下。
Lambda 架构结合了批处理和流处理的架构思想,将进入系统的大规模数据同时送入这两套架构层中,分别是批处理层(Batch Layer)和速度层(Speed Layer),同时产生两套数据结果并存入服务层。
批处理层有着很好的容错性,同时也因为保存着所有的历史记录,使产生的数据集具有很好的准确性。速度层可以及时地处理流入的数据,因此具有低延迟性。最终服务层将这两套数据结合,并生成一个完整的数据视图提供给用户。
Lambda 架构也具有很好的灵活性,你可以将现有开源生态圈中不同的平台套入这个架构,具体请参照上一讲内容。

Lambda 架构的不足

虽然 Lambda 架构使用起来十分灵活,并且可以适用于很多的应用场景,但在实际应用的时候,Lambda 架构也存在着一些不足,主要表现在它的维护很复杂。
使用 Lambda 架构时,架构师需要维护两个复杂的分布式系统,并且保证他们逻辑上产生相同的结果输出到服务层中。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《大规模数据处理实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(37)

  • :)
    1.kappa架构使用更少的技术栈,实时和历史部分都是同一套技术栈。lambda架构为了解决历史部分和实时部分可能会使用不同的技术栈。

    2.kappa架构使用了统一的处理逻辑。而lambda架构分别为历史和实时部分使用了两套逻辑。一旦需求变更,两套逻辑都要同时变更。

    3.kappa架构具有流式处理的特点和优点。比如可以具有多个订阅者,比如具有更高的吞吐量。

    作者回复: 谢谢你的留言!不错的总结!

    2019-05-10
    12
  • 朱同学
    我感觉这是用队列代替了hdfs

    作者回复: 谢谢你的留言!哈哈,可以这么理解,而且这个队列还必须具有重新处理所有历史数据的能力。

    2019-05-11
    10
  • 程序设计的艺术
    有几个地方没太明白:
    1.批处理数据具有很高的准确性,实时运算处理就没有?
    2.关于数据错误,两者应该都有吧?数据错误后两者的处理不一样吗?比如10个任务中的3个有错误,批处理和实时处理都应该可以找到3个任务重新计算吧?
    为什么实时运算需要完全从头计算所有任务?
    谢谢

    作者回复: 谢谢你的提问!
    1. 批处理和实时运算中的处理肯定都具有准确性的,只是这里所说的高准确性是批处理结果相对于流处理结果而言的,因为毕竟批处理所处理的数据是历史数据。举个例子,假设我们拥有一个人近几年的上班目的地的历史数据,大部分时间这个人上班都在A地,只有少部分时间在B地。那批处理层所处理完这些历史数据之后可能会判断出这个人的常规上班地点是A,出差地点是B。如果是实时处理的话,可能刚好拿到的数据就是出差的那几天地点B,那实时处理的判断可能会判断出这个人的常规上班地点是B了。所以相对而言,批处理具有高准确性。
    2. 无论是数据出错或者还是逻辑出错,批处理和实时处理肯定都会发生的。流处理的处理方式并不是按照任务为单位来计算的,通常都是把每一份数据当作是一个消息,流入的消息处理过了就不会再回头了。批处理的处理方式就是不断的有定时任务去重新处理所有历史数据。在Kappa架构下,除非你的logging做得非常好,能够知道在从哪一个数据时间点上出错了,那就把offset调回那个点重新从那个点开始重新计算。如果是逻辑有所改变了,那肯定是要全部数据从头完全重新计算了。

    2019-05-10
    1
    8
  • Rainbow
    spark算kappa架构吗?批处理 流处理一套

    作者回复: 谢谢你的提问!Spark不算Kappa架构,Spark是有能力可以处理批处理和流处理,我们可以利用Spark搭建Kappa架构出来,但是它本身不具备这种架构的思想在里面。这就好比我们可以借助编程语言实现一些算法,但是我们不会说这种编程语言就属于这种算法一样。

    2019-05-10
    6
  • 罗钛龙
    有个问题不明白,实时数据量很大的化,每次都从头计算,是否削弱了速度层实时性的特点,这样不和初心违背了么?

    作者回复: 谢谢你的提问!Kappa架构是具有从头计算的能力,但是这个架构并不太适用于需要经常重新计算历史数据的应用场景。当我们发现有重大逻辑错误出现或者修改的时候才会从头计算所有的数据。

    2019-05-17
    5
  • 夷,这也可以
    蔡老师好!看了之后有几点疑问:Lamabda基本上很好理解,Kappa还是不理解。目前的理解是这样的
    1、Lamabda是离线每天计算T+1数据 联合 当天实时处理的数据;T+1的数据会更新覆盖掉昨天实时数据。
    2、Kappa架构是从设定的时间数据开始,对每一条数据进行处理并和以前实时计算的结果数据聚会出结果,不断实时更新数据,直至实时处理的数据是目前最新的。
    a、Kappa从开发来说只有实时逻辑,不涉及T+1的批量逻辑了。
    b、数据的实时性来说,Kappa和Lambda都能拿到当前最新的全量"结果"数据。
    c、如果有需求变更了,2种架构其实都要开发。
    d、如果数据发声错误时,Lambda排查的时候相对Kappa会容易些,但是Kappa也可以通过业务处理逻辑对一个周期(比如天、周、月)的结果进行保存来使得查错和Lambada一样。对于纠错更正来说,如果业务逻辑比较简单只需在最后的迭代中修正即OK,那么2者也没有什么区别。但是如果业务逻辑比较复杂,不能简单的修改最后迭代结果,而需要从新迭代的情况,那么Lambda相对Kappa要容易,毕竟批处理的迭代次数相对较少。实际情况不能简单的修改最后迭代结果的情况应该毕竟少,而且一般发生错误都是就近的也就是当前时间不长,矫正比较容易。而且发现久远错误更正的情况也应该毕竟小。
    这样来看Kappa相对Lambda还有些优势的,不过从稳定性来看Lambda要强点。
    见识较少。不知道对不对
    2019-06-19
    3
  • 涛哥迷妹
    处理这种大数据量有窗口期的比如近30天的任务聚合计算可以用这种模式吗?是需要用kafka stream?每天都需要计算一次近30天的任务计算全量数据很大都是离线日志产生的数据

    作者回复: 谢谢你的提问!按照你的说法你的应用需求是需要定时处理离线数据的,Kappa还是不太适合这种应用场景。这种应用场景可以用crontab加batch job完成。

    2019-05-16
    3
  • 我只是想改个名字
    在我看来,Kappa架构和lambda架构没有绝对的谁好,就拿我们现在的业务场景,MySQL同步至tidb平台,原数据进kafka就有可能有问题,而我们又是金融公司,就只能选择lambda架构随时对数据进行校验,对最终数据进行纠正。
    2019-05-20
    2
  • jasine
    老师您好,麻烦请教下 如果实时与历史批量流程合在一起 那么重跑的时候kafka offset置成0 到latest这段时间是不是实时就无法提供服务了 怎么解决这个问题呢 感谢

    作者回复: 谢谢你的提问!这个问题可以这么看,因为重跑Kafka数据的是一个新的实例,它不影响现在正在运行的Kafka实例,所以说这段时间还是可以继续提供服务的。而不同的Kafka实例所产生的数据视图是不同版本的,只有当新的实例数据视图赶上旧的实例时,我们才会进行数据视图的切换。

    2019-05-11
    2
  • CoderLean
    不可能啊,如果要保存长久的数据,那么kafka的集群容量得有多大,按每天就一个t来说,加上默认副本3,那一年要存的数据量就得很多了。 这还可能只是其中一个业务。国内有小公司敢这样做吗

    作者回复: 谢谢你的留言!你说得也没有错,现在硅谷这边实践得比较多的可能就Linkedin或者Confluent了。

    2019-05-10
    2
  • 孙稚昊
    这样批和流的压力就全压到kafka 上了,对kafka并发的要求也非常高,应该只有kafka 能做到这件事了吧

    作者回复: 谢谢你的留言!是的呢,现在只有用Kafka来实现Kappa架构。

    2019-05-10
    2
  • AF
    如果批处理比较多的话,每次都从kafka的earlist offset消费的话,第一会耗费很长很长时间,而且消费者如果资源不够多,会导致任务堆积的吧。所以kappa不适合批处理多的架构。

    Kappa架构因为整合了批处理层和速度层,优势就是:
    1. 实时性比较高,适合对实时性要求高的场景
    2. 业务逻辑可以使用统一的API来编写,那么对于之后的业务需求变更和代码维护都比较友好

    作者回复: 谢谢你的留言总结!是的,现在Kappa架构用得比较多的是Confluent的数据平台,不过他们也没有放出Benchmark,具体和Lambda相比性能差距多少还不确定。不过我赞同你说kappa不适合批处理多的架构,毕竟如果常常要重做批处理的话,性能肯定会受影响的。

    2019-05-10
    2
  • Zoe
    老师,请问一下,纽约时报这个例子,是不是每次只处理delta部分而不是把log offset设成0更好一些?
    我粗浅的理解是可以把batch layer想成一个cache,感觉这种基于time series的每次只需要处理new data的部分再把结果和之前的cache聚合在一起就可以了?
    还是说业界普遍的做法都是从头开始处理,因为相较于找delta考虑overlap的困难就不那么意额外的处理时间和机器运行的成本?

    作者回复: 谢谢你的提问!你的理解没有错,一般来说是只处理delta部分就可以了。需要从头开始处理的场景一般都是在发现之前的逻辑有重大的错误或者说新加了一些字段需要backfill以前的数据。

    2019-05-29
    1
  • YYY
    https://www.cnblogs.com/xiaodf/p/11642555.html 我在这个博文里面看到了老师讲课一样的内容 是19年10月份发布的 还有微信公众号
    2019-11-24
  • 飞天大白菜
    请问一下,用kappa architecture来做时间窗口统计是它的一个合理应用吗?

    比如说我想每隔一段时间统计过去一小时的topK(暂时忽略处理时间过长问题),那么我是否可以每次将kafka consumer group的位移回调一个小时,然后直接运行一次topK算法?
    2019-10-01
  • tonyzhang
    老师,我想问一下,像lambda架构分成批处理和实时处理的两层,最终都是输出到对应的结果表供应用层分析;那为什么不能先进行实时计算,再把实时计算的结果写入到批处理的表中,这样批处理的数据就会不断累加,也能达到分析历史整体数据的目的,同时计算任务只需要实时计算的任务,批处理的数据是通过同步的形式进行,维护成本也能降低,不知道我的理解对不对?

    作者回复: 这就是kappa的理念

    2019-08-16
  • 滩涂曳尾
    一句话心得:
    kappa架构主要就是利用kafka做流批一体化,得益于kafka可以方便地把[任意历史时刻, 当前时刻]的数据“框进去”——
    1. kafka保留时间: 滑动窗口size
    2. kafka LogOffset: 滑动窗口offset
    2019-06-30
  • 西北偏北
    基于kafka可以永久缓存数据的特性,将kafka当作一个存储引擎

    基于kafka可以通过offset回溯回溯的特点来基于推送的获取和处理历史数据
    2019-06-27
  • 李恒达
    我是新手,没有接触过这个东西,想问一下老师,这个架构的过程是不是可以这样理解:
    旧的数据视图运行的同时,在另一个通道中,重新计算新的数据视图,训练好了以后就把旧的替换掉,使用新的数据视图,如此循环往复。
    2019-06-15
  • 天下行走
    老师是否可以讲下实时计算里得视图,因为两种架构都用到了,而且感觉是非常关键的一部分
    2019-06-10
收起评论
37
返回
顶部