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

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

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

    展开

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

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

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

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

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

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

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

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

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

    
     5
  • 夷,这也可以
    2019-06-19
    蔡老师好!看了之后有几点疑问: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要强点。
    见识较少。不知道对不对
    展开
    
     3
  • 又双叒叕是一年啊
    2019-05-16
    处理这种大数据量有窗口期的比如近30天的任务聚合计算可以用这种模式吗?是需要用kafka stream?每天都需要计算一次近30天的任务计算全量数据很大都是离线日志产生的数据

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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