lambda架构 - CSDN
精华内容
参与话题
  • 传统系统的问题“我们正在从IT时代走向DT时代(数据时代)。IT和DT之间,不仅仅是技术的变革,更是思想意识的变革,IT主要是为自我服务,用来更好地自我控制和...传统应用的数据系统架构设计时,应用直接访问数据库...

    传统系统的问题

    “我们正在从IT时代走向DT时代(数据时代)。IT和DT之间,不仅仅是技术的变革,更是思想意识的变革,IT主要是为自我服务,用来更好地自我控制和管理,DT则是激活生产力,让别人活得比你好”——阿里巴巴董事局主席马云。


    数据量从M的级别到G的级别到现在T的级、P的级别。数据量的变化数据管理系统(DBMS)和数仓系统(DW)也在悄然的变化着。

    传统应用的数据系统架构设计时,应用直接访问数据库系统。当用户访问量增加时,数据库无法支撑日益增长的用户请求的负载时,从而导致数据库服务器无法及时响应用户请求,出现超时的错误。出现这种情况以后,在系统架构上就采用图(A)的架构,在数据库和应用中间过一层缓冲隔离,缓解数据库的读写压力。然而,当用户访问量持续增加时,就需要考虑读写分离技术(Master-Slave)架构如图(B),分库分表技术。现在,架构变得越来越复杂了,增加队列、分区、复制等处理逻辑。应用程序需要了解数据库的schema,才能访问到正确的数据。


    图(A)


    图(B)

    Lambda架构的背景

    大数据处理技术需要解决这种可伸缩性与复杂性。首先要认识到这种分布式的本质,要很好地处理分区与复制,不会导致错误分区引起查询失败,而是要将这些逻辑内化到数据库中。当需要扩展系统时,可以非常方便地增加节点,系统也能够针对新节点进行rebalance。其次是要让数据成为不可变的。原始数据永远都不能被修改,这样即使犯了错误,写了错误数据,原来好的数据并不会受到破坏。

    Storm的作者NathanMarz提出的一个实时大数据处理框架(Lambda架构)就满足以上两点。Marz在Twitter工作期间开发了著名的实时大数据处理框架Storm,Lambda架构是其根据多年进行分布式大数据系统的经验总结提炼而成。

    Lambda架构的目标是设计出一个能满足实时大数据系统关键特性的架构,包括有:高容错、低延时和可扩展等。Lambda架构整合离线计算和实时计算,融合不可变性(Immunability),读写分离和复杂性隔离等一系列架构原则,可集成Hadoop,Kafka,Storm,Spark,Hbase等各类大数据组件。

    大数据系统的关键特性

    Marz介绍BigData System许具备的属性:

    a、Robustandfault-tolerant(容错性和鲁棒性):对大规模分布式系统来说,机器是不可靠的,可能会当机,但是系统需要是健壮、行为正确的,即使是遇到机器错误。除了机器错误,人更可能会犯错误。在软件开发中难免会有一些Bug,系统必须对有Bug的程序写入的错误数据有足够的适应能力,所以比机器容错性更加重要的容错性是人为操作容错性。对于大规模的分布式系统来说,人和机器的错误每天都可能会发生,如何应对人和机器的错误,让系统能够从错误中快速恢复尤其重要。

    b、Lowlatency reads and updates(低延时):很多应用对于读和写操作的延时要求非常高,要求对更新和查询的响应是低延时的。

    c、Scalable(横向扩容):当数据量/负载增大时,可扩展性的系统通过增加更多的机器资源来维持性能。也就是常说的系统需要线性可扩展,通常采用scale out(通过增加机器的个数)而不是scale up(通过增强机器的性能)。

    dGeneral(通用性):系统需要能够适应广泛的应用,包括金融领域、社交网络、电子商务数据分析等。

    e、Extensible(可扩展):需要增加新功能、新特性时,可扩展的系统能以最小的开发代价来增加新功能。

    f、Allows ad hoc queries(方便查询):数据中蕴含有价值,需要能够方便、快速的查询出所需要的数据。

    d、Minimal maintenance(易于维护):系统要想做到易于维护,其关键是控制其复杂性,越是复杂的系统越容易出错、越难维护。

    h、Debuggable(易调试):当出问题时,系统需要有足够的信息来调试错误,找到问题的根源。其关键是能够追根溯源到每个数据生成点。

    数据系统的本质

    Marz认为:数据系统通过查询过去的(部分、全部)数据去回答问题。如:他是一个什么样的人?他有多少朋友?这个账号是否收支平衡?。因此,DataSystem的通用定义为QueryFunction(alldata)。对通用的表达式进行分解得到:数据系统数据查询,从而可以从数据和查询两个方面认识大数据系统的本质。

    数据本本质:When&What

    数据是一个不可分割的单元,数据有两个关键的特性:WhenWhat

    When是只数据是与时间相关的,也就是数据是在某个时间产生的。这个非常重要,在具有事务特性的数据库中,操作的先后顺序对结果至关重要。例如数据库的Binlog日志。因此,数据的时间性质决定了数据的全局发生先后,也就决定了数据的结果。

    What是只数据的本身。由于数据跟某个时间点相关,所以数据的本身是不可变的(immutable),过往的数据已经成为事实(Fact),你不可能回到过去的某个时间点去改变数据事实。这也就意味着对数据的操作其实只有两种:读取已存在的数据和添加更多的新数据。采用数据库的记法,CRUD就变成了CR,Update和Delete本质上其实是新产生的数据信息,用C来记录。

    数据的存储:StoreEverything Rawly and Immutably

    根据上述对数据特性的分析,lambda架构中对数据的存储采用的方式是:数据不可变,存储所有数据。

    采用这两种方式存储的好处:

    a、简单。采用不可变的数据模型,存储数据时只需要简单的往主数据集后追加数据即可。相比于采用可变的数据模型,为了Update操作,数据通常需要被索引,从而能快速找到要更新的数据去做更新操作。

    b、应对人为和机器的错误。人和机器每天都可能会出错,如何应对人和机器的错误,让数据系统快速恢复极其重要。不可变和可重复计算是应对认为和机器错误的常用方法。采用可变数据模型,引发错误的数据有可能被覆盖而丢失。相比于采用不可变的数据模型,因为所有的数据都在,引发错误的数据也在。修复的方法就可以简单的是遍历数据集上存储的所有的数据,丢弃错误的数据,重新计算得到Views。重新计算的关键点在于利用数据的时间特性决定的全局次序,依次顺序重新执行,必然能得到正确的结果。

    当前业界有很多采用不可变数据模型来存储所有数据的例子。比如分布式数据库Datomic,基于不可变数据模型来存储数据,从而简化了设计。分布式消息中间件Kafka,基于Log日志,以追加append-only的方式来存储消息。

    Lambda架构

    Lambda架构的主要思想是将大数据系统架构为多层个层次,分别为批处理层(batchlayer)、实时处理层(speedlayer)、服务层(servinglayer)如图(C)。

    理想状态下,任何数据访问都可以从表达式Query= function(alldata)开始,但是,若数据达到相当大的一个级别(例如PB),且还需要支持实时查询时,就需要耗费非常庞大的资源。一个解决方式是预运算查询函数(precomputedquery funciton)。书中将这种预运算查询函数称之为Batch View(A),这样当需要执行查询时,可以从BatchView中读取结果。这样一个预先运算好的View是可以建立索引的,因而可以支持随机读取(B)。于是系统就变成:

    (A)batchview = function(all data);

    (B)query =function(batch view)。

    图(C)


    BatchLayer

    Lambda架构中,实现(A)batch view =function(all data)的部分称之为BatchLayer。他承担两个职责:

    a、存储MasterDataset,这是一个不变的持续增长的数据集

    b、针对这个MasterDataset进行预运算

    在全体数据集上在线运行查询函数得到结果的代价太大,同时处理查询时间过长,导致用户体验不好。如果我们预先在数据集上计算并保存预计算的结果,查询的时候直接返回预计算的结果,而无需重新进行复制耗时的计算。显然,batchview是一个批处理过程,如采用Hadoop或spark支持的map-reduce方式。采用这种方式计算得到的每个view都支持再次计算,且每次计算的结果都相同。


    图(D)

    对View的理解: 

    View是一个和业务关联性比较大的概念,View的创建需要从业务自身的需求出发。一个通用的数据库查询系统,查询对应的函数千变万化,不可能穷举。但是如果从业务自身的需求出发,可以发现业务所需要的查询常常是有限的。BatchLayer需要做的一件重要的工作就是根据业务的需求,考察可能需要的各种查询,根据查询定义其在数据集上对应的Views。

    Batch Layer的Immutabledata模型和Views

    如图(E)坐席(agentid=50023)的人,在10:00:06分的时候,状态是calling,在10:00:10的时候状态为waiting。在传统的数据库设计中,直接后面的纪录覆盖前面的纪录,而在Immutable数据模型中,不会对原有数据进行更改,而是采用插入修改纪录的形式更改历史纪录。

    图(E)

    上文所提及的View是图(E)中预先计算得到的相关视图,例如:2016-06-21当天所有上线的agent数,每条热线、公司下上线的Agent数。根据业务需要,预先计算出结果。此过程相当于传统数仓建模的应用层,应用层也是根据业务场景,预先加工出的view。

    SpeedLayer

    BatchLayer能够很好的处理离线数据,但是在很多场景数据不断产生,并且业务场景需要实时查询。SpeedLayer就是设计用来处理增量实时数据。

    SpeedLayer和BatchLayer比较类似,对数据进行计算并生成RealtimeView,其主要的区别在于:

    a、SpeedLayer处理的数据是最近的增量数据流,BatchLayer处理的是全体数据集

    b、SpeedLayer为了效率,接收到新数据及时更新RealtimeView,而BatchLayer根据全体离线数据直接得到BatchView。SpeedLayer是一种增量计算,而非重新计算(recomputation)。

    c、SpeedLayer因为采用增量计算,所以延迟小,而BatchLayer是全数据集的计算,耗时比较长。

    综上所诉,SpeedLayer是BatchLayer在实时性上的一个补充。如图(F)


    图(F)


    SpeedLayer可总结为以(C)RealtimeViewfunction(RealtimeViewnewdata);

    LambdaArchitecture将数据处理分解为BatchLayer和SpeedLayer有如下优点:

    a、容错性:SpeedLayer中处理的数据不断写入BatchLayer,当BatchLayer中重新计算数据集包含SpeedLayer处理的数据集后,当前的RealtimeView就可以丢弃,这就意味着SpeedLayer处理中引入的错误,在BatchLayer重新计算时都可以得到修证。这点也可以看成时CAP理论中的最终一致性(EventualConsistency)的体现。

    b、复杂性隔离。BatchLayer处理的是离线数据,可以很好的掌控。Speed Layer采用增量算法处理实时数据,复杂性比Batch Layer要高很多。通过分开BatchLayer和Speed Layer,把复杂性隔离到Speed Layer,可以很好的提高整个系统的鲁棒性和可靠性。

    ServingLayer

    BatchLayer通过对MasterDataset执行查询获得BatchViewSpeed Layer通过增量计算提供RealtimeView。Lambda架构的ServingLayer用于响应用户的查询请求,合并BatchView和Realtime View中的结果数据集到最终的数据集,如图(G)。因此,ServingLayer的职责包含:

    a、对batchView和RealTimeView的随机访问

    b、更新BatchVeiw和RealTimeView,并负责结合两者的数据,对用户提供统一的接口

    图(G)

    综上所诉,ServingLayer采用如下等式(D)表示:Queryfunction(BatchViewsRealtimeView)。

    Lambda架构组件选型

    下图给出了Lambda架构中各组件在大数据生态系统中和阿里集团的常用组件。数据流存储选用不可变日志的分布式系统Kafa、TT、Metaq;BatchLayer数据集的存储选用Hadoop的HDFS或者阿里云的ODPS;BatchView的加工采用MapReduce;BatchView数据的存储采用Mysql(查询少量的最近结果数据)、Hbase(查询大量的历史结果数据)。SpeedLayer采用增量数据处理Storm、Flink;RealtimeView增量结果数据集采用内存数据库Redis。

    图(H)

    Lambda是一个通用框架,各模块选型不要局限于上面给出的组件,特别是view的选型。因为View是和各业务关联非常大的概念,View选择组件时要根据业务的需求,选择最合适的组件。

    Lambda架构的评估

    优点:

    a、数据的不可变性。里面给出的数据传输模型是在初始化阶段对数据进行实例化,这样的做法是能获益良多的。能够使得大量的MapReduce工作变得有迹可循,从而便于在不同阶段进行独立调试。

     b、强调了数据的重新计算问题。在流处理中重新计算是个主要挑战,但是经常被忽视。比方说,某工作流的数据输出是由输入决定的,那么一旦代码发生改动,我们将不得不重新计算来检视变更的效度。什么情况下代码会改动呢?例如需求发生变更,计算字段需要调整或者程序发出错误,需要进行调试。

    缺点:

    aJay Kreps认为Lambda包含固有的开发和运维的复杂性。Lambda需要将所有的算法实现两次,一次是为批处理系统,另一次是为实时系统,还要求查询得到的是两个系统结果的合并。

     

    由于存在以上缺点,Linkedin的Jaykreps提出了Kappa架构如图(I):

    图(I)

    1、使用Kafka或其它系统来对需要重新计算的数据进行日志记录,以及提供给多个订阅者使用。例如需要重新计算30天内的数据,我们可以在Kafka中设置30天的数据保留值。

    2、当需要进行重新计算时,启动流处理作业的第二个实例对之前获得的数据进行处理,之后直接把结果数据放入新的数据输出表中。

    3、当作业完成时,让应用程序直接读取新的数据记录表。

    4、停止历史作业,删除旧的数据输出表。

     

    Kappa架构暂时未做深入了解,在此不做评价。我个人觉得,不同的数据架构有各自的优缺点,我们使用的时候只能根据应用场景,选择更合适的架构,才能扬长避短。

     

    参考资料:

    Big Data:Principles and best practices of scalable real-time data systems——Nathan Marz

    http://blog.csdn.net/brucesea/article/details/45937875

    https://zhuanlan.zhihu.com/p/20510974

    http://www.infoq.com/cn/news/2014/09/lambda-architecture-questions


    转自:https://blog.csdn.net/lvsaixia/article/details/51778487

    展开全文
  • Lambda架构

    万次阅读 多人点赞 2018-07-11 21:15:04
    转载:...Marz在Twitter工作期间开发了著名的实时大数据处理框架Storm,Lambda架构是其根据多年进行分布式大数据系统的经验总结提炼而成。Lambda架构的目标是设...

    转载:https://blog.csdn.net/brucesea/article/details/45937875


    1.Lambda架构背景介绍

    Lambda架构是由Storm的作者Nathan Marz提出的一个实时大数据处理框架。Marz在Twitter工作期间开发了著名的实时大数据处理框架Storm,Lambda架构是其根据多年进行分布式大数据系统的经验总结提炼而成。

    Lambda架构的目标是设计出一个能满足实时大数据系统关键特性的架构,包括有:高容错、低延时和可扩展等。Lambda架构整合离线计算和实时计算,融合不可变性(Immunability),读写分离和复杂性隔离等一系列架构原则,可集成Hadoop,Kafka,Storm,Spark,Hbase等各类大数据组件。

    2.大数据系统的关键特性

    Marz认为大数据系统应具有以下的关键特性:

    • Robust and fault-tolerant(容错性和鲁棒性):对大规模分布式系统来说,机器是不可靠的,可能会当机,但是系统需要是健壮、行为正确的,即使是遇到机器错误。除了机器错误,人更可能会犯错误。在软件开发中难免会有一些Bug,系统必须对有Bug的程序写入的错误数据有足够的适应能力,所以比机器容错性更加重要的容错性是人为操作容错性。对于大规模的分布式系统来说,人和机器的错误每天都可能会发生,如何应对人和机器的错误,让系统能够从错误中快速恢复尤其重要。

    • Low latency reads and updates(低延时):很多应用对于读和写操作的延时要求非常高,要求对更新和查询的响应是低延时的。

    • Scalable(横向扩容):当数据量/负载增大时,可扩展性的系统通过增加更多的机器资源来维持性能。也就是常说的系统需要线性可扩展,通常采用scale out(通过增加机器的个数)而不是scale up(通过增强机器的性能)。

    • General(通用性):系统需要能够适应广泛的应用,包括金融领域、社交网络、电子商务数据分析等。

    • Extensible(可扩展):需要增加新功能、新特性时,可扩展的系统能以最小的开发代价来增加新功能。

    • Allows ad hoc queries(方便查询):数据中蕴含有价值,需要能够方便、快速的查询出所需要的数据。

    • Minimal maintenance(易于维护):系统要想做到易于维护,其关键是控制其复杂性,越是复杂的系统越容易出错、越难维护。

    • Debuggable(易调试):当出问题时,系统需要有足够的信息来调试错误,找到问题的根源。其关键是能够追根溯源到每个数据生成点。

    3.数据系统的本质

    为了设计出能满足前述的大数据关键特性的系统,我们需要对数据系统有本质性的理解。我们可将数据系统简化为:

    数据系统 = 数据 + 查询

    从而从数据和查询两方面来认识大数据系统的本质。

    3.1.数据的本质

    3.1.1.数据的特性:When & What

    我们先从“数据”的特性谈起。数据是一个不可分割的单位,数据有两个关键的性质:When和What。

    • When是指数据是与时间相关的,数据一定是在某个时间点产生的。比如Log日志就隐含着按照时间先后顺序产生的数据,Log前面的日志数据一定先于Log后面的日志数据产生;消息系统中消息的接受者一定是在消息的发送者发送消息后接收到的消息。相比于数据库,数据库中表的记录就丢失了时间先后顺序的信息,中间某条记录可能是在最后一条记录产生后发生更新的。对于分布式系统,数据的时间特性尤其重要。分布式系统中数据可能产生于不同的系统中,时间决定了数据发生的全局先后顺序。比如对一个值做算术运算,先+2,后*3,与先*3,后+2,得到的结果完全不同。数据的时间性质决定了数据的全局发生先后,也就决定了数据的结果。

    • What是指数据的本身。由于数据跟某个时间点相关,所以数据的本身是不可变的(immutable),过往的数据已经成为事实(Fact),你不可能回到过去的某个时间点去改变数据事实。这也就意味着对数据的操作其实只有两种:读取已存在的数据和添加更多的新数据。采用数据库的记法,CRUD就变成了CR,Update和Delete本质上其实是新产生的数据信息,用C来记录。

    3.1.2.数据的存储:Store Everything Rawly and Immutably

    根据上述对数据本质特性的分析,Lamba架构中对数据的存储采用的方式是:数据不可变,存储所有数据。

    通过采用不可变方式存储所有的数据,可以有如下好处:

    • 简单。采用不可变的数据模型,存储数据时只需要简单的往主数据集后追加数据即可。相比于采用可变的数据模型,为了Update操作,数据通常需要被索引,从而能快速找到要更新的数据去做更新操作。

    • 应对人为和机器的错误。前述中提到人和机器每天都可能会出错,如何应对人和机器的错误,让系统能够从错误中快速恢复极其重要。不可变性(Immutability)和重新计算(Recomputation)则是应对人为和机器错误的常用方法。采用可变数据模型,引发错误的数据有可能被覆盖而丢失。相比于采用不可变的数据模型,因为所有的数据都在,引发错误的数据也在。修复的方法就可以简单的是遍历数据集上存储的所有的数据,丢弃错误的数据,重新计算得到Views(View的概念参考4.1.2)。重新计算的关键点在于利用数据的时间特性决定的全局次序,依次顺序重新执行,必然能得到正确的结果。

    当前业界有很多采用不可变数据模型来存储所有数据的例子。比如分布式数据库Datomic,基于不可变数据模型来存储数据,从而简化了设计。分布式消息中间件Kafka,基于Log日志,以追加append-only的方式来存储消息。

    3.2.查询

    查询是个什么概念?Marz给查询如下一个简单的定义:

    Query = Function(All Data)

    该等式的含义是:查询是应用于数据集上的函数。该定义看似简单,却几乎囊括了数据库和数据系统的所有领域:RDBMS、索引、OLAP、OLTP、MapReduce、EFL、分布式文件系统、NoSQL等都可以用这个等式来表示。

    让我们进一步深入看一下函数的特性,从而挖掘函数自身的特点来执行查询。

    有一类称为Monoid特性的函数应用非常广泛。Monoid的概念来源于范畴学(Category Theory),其一个重要特性是满足结合律。如整数的加法就满足Monoid特性:

    (a+b)+c=a+(b+c)

    不满足Monoid特性的函数很多时候可以转化成多个满足Monoid特性的函数的运算。如多个数的平均值Avg函数,多个平均值没法直接通过结合来得到最终的平均值,但是可以拆成分母除以分子,分母和分子都是整数的加法,从而满足Monoid特性。

    Monoid的结合律特性在分布式计算中极其重要,满足Monoid特性意味着我们可以将计算分解到多台机器并行运算,然后再结合各自的部分运算结果得到最终结果。同时也意味着部分运算结果可以储存下来被别的运算共享利用(如果该运算也包含相同的部分子运算),从而减少重复运算的工作量。 
    Monoid

    4.Lambda架构

    有了上面对数据系统本质的探讨,下面我们来讨论大数据系统的关键问题:如何实时地在任意大数据集上进行查询?大数据再加上实时计算,问题的难度比较大。

    最简单的方法是,根据前述的查询等式Query = Function(All Data),在全体数据集上在线运行查询函数得到结果。但如果数据量比较大,该方法的计算代价太大了,所以不现实。

    Lambda架构通过分解的三层架构来解决该问题:Batch Layer,Speed Layer和Serving Layer。 
    Lamba架构

    4.1.Batch Layer

    Batch Layer的功能主要有两点:

    • 存储数据集
    • 在数据集上预先计算查询函数,构建查询所对应的View

    4.1.1.储存数据集

    根据前述对数据When&What特性的讨论,Batch Layer采用不可变模型存储所有的数据。因为数据量比较大,可以采用HDFS之类的大数据储存方案。如果需要按照数据产生的时间先后顺序存放数据,可以考虑如InfluxDB之类的时间序列数据库(TSDB)存储方案。

    4.1.2.构建查询View

    上面说到根据等式Query = Function(All Data),在全体数据集上在线运行查询函数得到结果的代价太大。但如果我们预先在数据集上计算并保存查询函数的结果,查询的时候就可以直接返回结果(或通过简单的加工运算就可得到结果)而无需重新进行完整费时的计算了。这儿可以把Batch Layer看成是一个数据预处理的过程。我们把针对查询预先计算并保存的结果称为View,View是Lamba架构的一个核心概念,它是针对查询的优化,通过View即可以快速得到查询结果。 
    Batch Layer 
    如果采用HDFS来储存数据,我们就可以使用MapReduce来在数据集上构建查询的View。Batch Layer的工作可以简单的用如下伪码表示: 
    Batch Layer Code 
    该工作看似简单,实质非常强大。任何人为或机器发生的错误,都可以通过修正错误后重新计算来恢复得到正确结果。

    对View的理解: 
    View是一个和业务关联性比较大的概念,View的创建需要从业务自身的需求出发。一个通用的数据库查询系统,查询对应的函数千变万化,不可能穷举。但是如果从业务自身的需求出发,可以发现业务所需要的查询常常是有限的。Batch Layer需要做的一件重要的工作就是根据业务的需求,考察可能需要的各种查询,根据查询定义其在数据集上对应的Views。

    4.2.Speed Layer

    Batch Layer可以很好的处理离线数据,但有很多场景数据不断实时生成,并且需要实时查询处理。Speed Layer正是用来处理增量的实时数据。

    Speed Layer和Batch Layer比较类似,对数据进行计算并生成Realtime View,其主要区别在于:

    • Speed Layer处理的数据是最近的增量数据流,Batch Layer处理的全体数据集

    • Speed Layer为了效率,接收到新数据时不断更新Realtime View,而Batch Layer根据全体离线数据集直接得到Batch View。

    Lambda架构将数据处理分解为Batch Layer和Speed Layer有如下优点:

    • 容错性。Speed Layer中处理的数据也不断写入Batch Layer,当Batch Layer中重新计算的数据集包含Speed Layer处理的数据集后,当前的Realtime View就可以丢弃,这也就意味着Speed Layer处理中引入的错误,在Batch Layer重新计算时都可以得到修正。这点也可以看成是CAP理论中的最终一致性(Eventual Consistency)的体现。 
      Speed Layer

    • 复杂性隔离。Batch Layer处理的是离线数据,可以很好的掌控。Speed Layer采用增量算法处理实时数据,复杂性比Batch Layer要高很多。通过分开Batch Layer和Speed Layer,把复杂性隔离到Speed Layer,可以很好的提高整个系统的鲁棒性和可靠性。

    4.3.Serving Layer

    Lambda架构的Serving Layer用于响应用户的查询请求,合并Batch View和Realtime View中的结果数据集到最终的数据集。

    这儿涉及到数据如何合并的问题。前面我们讨论了查询函数的Monoid性质,如果查询函数满足Monoid性质,即满足结合率,只需要简单的合并Batch View和Realtime View中的结果数据集即可。否则的话,可以把查询函数转换成多个满足Monoid性质的查询函数的运算,单独对每个满足Monoid性质的查询函数进行Batch View和Realtime View中的结果数据集合并,然后再计算得到最终的结果数据集。另外也可以根据业务自身的特性,运用业务自身的规则来对Batch View和Realtime View中的结果数据集合并。 
    Serving Layer

    5.Big Picture

    上面分别讨论了Lambda架构的三层:Batch Layer,Speed Layer和Serving Layer。下图给出了Lambda架构的一个完整视图和流程。 
    Big Picture

    数据流进入系统后,同时发往Batch Layer和Speed Layer处理。Batch Layer以不可变模型离线存储所有数据集,通过在全体数据集上不断重新计算构建查询所对应的Batch Views。Speed Layer处理增量的实时数据流,不断更新查询所对应的Realtime Views。Serving Layer响应用户的查询请求,合并Batch View和Realtime View中的结果数据集到最终的数据集。

    5.1.Lambda架构组件选型

    下图给出了Lambda架构中各个层常用的组件。数据流存储可选用基于不可变日志的分布式消息系统Kafka;Batch Layer数据集的存储可选用Hadoop的HDFS,或者是阿里云的ODPS;Batch View的预计算可以选用MapReduce或Spark;Batch View自身结果数据的存储可使用MySQL(查询少量的最近结果数据),或HBase(查询大量的历史结果数据)。Speed Layer增量数据的处理可选用Storm或Spark Streaming;Realtime View增量结果数据集为了满足实时更新的效率,可选用Redis等内存NoSQL。 
    Component

    5.2.Lambda架构组件选型原则

    Lambda架构是个通用框架,各个层选型时不要局限时上面给出的组件,特别是对于View的选型。从我对Lambda架构的实践来看,因为View是个和业务关联性非常大的概念,View选择组件时关键是要根据业务的需求,来选择最适合查询的组件。不同的View组件的选择要深入挖掘数据和计算自身的特点,从而选择出最适合数据和计算自身特点的组件,同时不同的View可以选择不同的组件。

    6.Lambda架构 vs. Event Sourcing vs. CQRS

    在Lambda架构身上可以看到很多现有设计思想和架构的影子,如Event Sourcing和CQRS,这儿我们把它们和Lambda架构做一结合对比,从而去更深入的理解Lambda架构。

    6.1.事件溯源(Event Sourcing)vs. Lambda架构

    事件溯源(Event Sourcing)是由大名鼎鼎的Martin Flower大叔提出来的架构模式。Event Sourcing本质上是一种数据持久化的方式,它将引发变化的事件(Event)本身存储下来。相比于传统数据是持久化方式,存储的是事件引发的结果,而非事件本身,这样我们在保存结果的同时,实际上失去了追溯导致结果原因的机会。

    这儿可以看到Lambda架构中数据集的存储和Event Sourcing中的思想是完全一致的,本质都是采用不可变的数据模型存储引发变化的事件而非变化产生的结果。从而在发生错误的时候,能够追本溯源,找到发生错误的根源,通过重新计算丢弃错误的信息来恢复系统,达到系统的容错性。

    6.2.CQRS vs. Lambda架构

    CQRS (Command Query Responsibility Segregation)将对数据的修改操作和查询操作分离,其本质和Lambda架构一样,也是一种形式的读写分离。在Lambda架构中,数据以不可变的方式存储下来(写操作),转换成查询所对应的Views,查询从View中直接得到结果数据(读操作)。

    读写分离将读和写两个视角进行分离,带来的好处是复杂性的隔离,从而简化系统的设计。相比于传统做法中的将读和写操作放在一起的处理方式,对于读写操作业务非常复杂的系统,只会使系统变得异常复杂,难以维护。 
    CQRS

    7.总结

    本文介绍了Lambda架构的基本概念。Lambda架构通过对数据和查询的本质认识,融合了不可变性(Immunability),读写分离和复杂性隔离等一系列架构原则,将大数据处理系统划分为Batch Layer, Speed Layer和Serving Layer三层,从而设计出一个能满足实时大数据系统关键特性(如高容错、低延时和可扩展等)的架构。Lambda架构作为一个通用的大数据处理框架,可以很方便的集成Hadoop,Kafka,Storm,Spark,Hbase等各类大数据组件。

    展开全文
  • Lambda 架构 简介

    千次阅读 2019-01-03 14:30:42
    上图就是lambda结构的一个示意, 来自图书Big Data Principles and best practices of scalable realtime data system, 该书的作者就是lambda架构的创造者Nathan Marz。 大数据的技术手段百花齐放, 各种...

     

    lambda 架构图

    上图就是lambda结构的一个示意, 来自图书Big Data Principles and best practices of scalable realtime data system, 该书的作者就是lambda架构的创造者Nathan Marz。

    大数据的技术手段百花齐放, 各种NoSQL数据库或者分布式计算框架层出不穷, 但是很少有理论来讲一讲应该怎么把这些组件有机地组合起来, lambda框架应运而生, 是一种理论指导大数据项目的顶层设计, 帮助企业以数据来驱动。

    从业务的角度来思考对于数据的应用有不同的时效性要求, 有的数据比如 E-commerce ,时效性要求非常高, 有的数据比如客户画像分析 对时效性要求比较低. 道理很简单, 电商的促销推荐瞬息万变, 而客户的行为画像变得很慢(并不是每天都有人从工薪阶层变成百万富翁,从单身汉突然变成已婚人士)。

    lambda架构从这点出发, 有两套解决办法, 正如图上的两条分支, 一条叫Speed Layer 顾名思义 快速的处理实时数据以供查询, 而另一条分支, 又分作两层(Batch Layer & Serving Layer) 处理那些对时效性要求不高的数据。

    Speed Layer处理实时数据 代价是对计算资源要求很高, 而且逻辑复杂度也会很高, 通常采用的技术比如 Redis,Storm,Kafka,Spark Streaming等。而另外两层使用的典型技术比如MR或Spark,Hive。这条路线处理延迟比较大, 结果逻辑相对简单,往往把它的处理叫做“离线处理”, 与Speed Layer的“实时处理”相对应。这种设计被称作:Complexity Isolation(复杂度分离)。

    两者其实是相辅相成的, Batch Layer会持续地吸收增量数据加以处理(比如渐变维度,增加索引,划分分区,预计算聚合值等操作), 当新增数据被Batch Layer处理完成后, 它们的分析就不再由Speed Layer处理了(交由Serving Layer处理),所以保证了Speed Layer处理的历史数据量永远不会太大,毕竟对于Speed Layer来说 “快” 是关键。

    在另一些场景下, 比如在用户浏览购物网站时的推荐系统, 会结合实时分析结果和离线处理结果: 以电商为例, 用户给购物车加了一件商品,根据这个操作"实时处理"会向用户做出推荐(用户把一条裙子加入购物车,立刻推荐这条裙子的搭配商品比如一双鞋子),但同时也要结合用户历史的行为来做推荐(用户喜欢红色,脚的尺码M), 这依赖于离线处理的结果。两者结合(该鞋子红色款且尺码M)就是最终用户在网页上看到的推荐商品列表。

    以上就是Lambda框架的简介。

    展开全文
  • Lambda架构&Kappa架构

    千次阅读 2020-03-29 10:47:30
    Lambda架构 Lambda 是用Nathan Marz(实时处理框架storm的作者) 提出的用于同时处理离线和实时的数据的,可容错的,可扩展的分布式系统。它具备强鲁棒性,提供低延迟和持续更新。它通过批量MapReduce作业提供了虽...

     

    Lambda架构

         Lambda 是用Nathan Marz(实时处理框架storm的作者) 提出的用于同时处理离线和实时的数据的,可容错的,可扩展的分布式系统。它具备强鲁棒性,提供低延迟和持续更新。它通过批量MapReduce作业提供了虽有些延迟但是结果准确的计算,同时通过Strom等实时计算引擎将最新数据的计算结果初步展示出来

    缺点:

            1、实时与批量计算结果不一致引起的数据口径问题;基于MapReduce和HDFS的Lambda系统有一个长达数小时的市价窗口,在这个窗口内,由于是是是任务事变二产生的不准确的结果一直存在

            2、Lamdba架构需要在两个不同的API中对同样的业务逻辑进行两次编程,一次为批量计算的系统,一次为流失计算的系统,针对同一的业务问题产生了两个代码库,各有不同的漏洞,系统维护成本大大提高。

            3、批量计算在计算窗口内无法完成:在IOT时代,数据量级越来越大,经常发现夜间只有4、5个小时的时间窗口,已经无法完成白天20多个小时累计的数据,保证早上上班前准时出数据已成为每个大数据团队头疼的问题。

           4、数据源变化都要重新开发,开发周期长:每次数据源的格式变化,业务的逻辑变化都需要针对ETL和Streaming做开发修改,整体开发周期很长,业务反应不够迅速。

           5、服务器存储大:数据仓库的典型设计,会产生大量的中间结果表,造成数据急速膨胀,加大服务器存储压力。

     

     

    Kappa架构

           Kappa架构的核心思想是通过改进流计算系统来解决数据全量处理的问题,使得实时计算和批处理过程使用了同一套代码。Kappa架构认为只有在有必要的时候才会对历史数据进行重复计算

    Kappa架构的核心思想包括以下三点(我看大家基本上都这么写,我就直接复制过来了,捂脸)

    1. 用Kafka或者类似的分布式队列系统保存数据,你需要几天的数据量就保存几天。
    2. 当需要全量重新计算时,重新起一个流计算实例,从头开始读取数据进行处理,并输出到一个新的结果存储中。
    3. 当新的实例做完后,停止老的流计算实例,并把老的一些结果删除。


    • 缺点:

      1、流式处理对于历史数据的高吞吐量力不从心:所有的数据都通过流式计算,即便通过加大并发实例数亦很难适应IOT时代对数据查询响应的即时性要求。

      2、 开发周期长:此外Kappa架构下由于采集的数据格式的不统一,每次都需要开发不同的Streaming程序,导致开发周期长。

      3、 服务器成本浪费:Kappa架构的核心原理依赖于外部高性能存储redis,hbase服务。但是这2种系统组件,又并非设计来满足全量数据存储设计,对服务器成本严重浪费。

       

    Lambda和Kappa优缺点:

         

    选择

            1、业务需求

                 所需的历史数据规模比较大,并且达到TB以上,那么选择Lamdba架构可能较为合适;如果历史数据相对较较小,比如电商网站仅30天的数据,可选择Kappa;

                如果项目中需频繁的对算法模型进行调优,比如在实际应用中,需要机器学习,需要有批量处理生成预测模型,在交由实时计算进行是是是分析,这种情况下,批处理和实时处理系统不能合并,因此应选择Lambda架构

           2、开发和运维成本

               Kappa批量和实时计算共用同一套代码,开发和运维成本较低。

    展开全文
  • 大数据篇:Lambda架构和Kappa架构(下) Lambda 架构的不足 虽然Lambda架构使用起来已经十分灵活,并且可以适用于很多的应用场景,但在实际应用的时候,Lambda架构也存在着一些不足,主要表现在它的维护很复杂。 ...
  • 文章目录1.2 推荐系统设计学习目标1 推荐系统要素2 推荐系统架构 1.2 推荐系统设计 学习目标 了解推荐系统要素 记忆推荐系统架构 ...Lambda架构是由实时大数据处理框架Storm的作者Nathan Marz提出的一个实时...
  • 大数据平台Lambda架构详解

    千次阅读 2017-05-06 17:31:11
    Lambda架构由Storm的作者Nathan Marz提出。 旨在设计出一个能满足实时大数据系统关键特性的架构,具有高容错、低延时和可扩展等特性 。 Lambda架构整合离线计算和实时计算,融合不可变(Immutability),读写分离和...
  • 大数据Lambda架构

    万次阅读 2016-10-24 14:12:00
    1 Lambda架构介绍 Lambda架构划分为三层,分别是批处理层,服务层,和加速层。最终实现的效果,可以使用下面的表达式来说明。 query = function(alldata) 1.1 批处理层 批处理层主用由Hadoop来实现,负责数据的存储...
  • 一、Lambda 架构 Lambda 架构由Storm的作者Nathan Marz提出,其设计目的在于提供一个能满足大数据系统关键特性的架构,包括高容错、低延迟、可扩展等。其整合离线计算与实时计算,融合不可变性、读写分离和复杂性...
  • 1. lambda架构 1.1. 优点 Lambda 架构使开发人员能够构建大规模分布式数据处理系统。它具有很好的灵活性和可扩展性,也对硬件故障和人为失误有很好的容错性。 Lambda 架构总共由三层系统组成:批处理层(Batch ...
  • 大数据篇:Lambda架构和Kappa架构(上) 大家好,我是辰,好久没有更新文章了,今天我们来讲讲Lambda架构和Kappa架构。 Lambda架构: 在讲解之前我们先来看看这个实际的项目。情况是这样的,一个正运行着的广告精准...
  • 在大数据架构中,有两个十分常见的架构,那就是lambda架构和unifield架构,这两个架构在大数据中占据着十分重要的地位,在这篇文章中我们就给大家介绍一下lambda架构和unifield架构,帮助大家更深一步的去了解大数据...
  • Lambda架构和Kappa架构

    千次阅读 2019-02-12 18:40:20
    数据系统架构——Lambda architecture(Lambda架构) 传统系统的问题 “我们正在从IT时代走向DT时代(数据时代)。IT和DT之间,不仅仅是技术的变革,更是思想意识的变革,IT主要是为自我服务,用来更好地自我控制和...
  • Lambda架构 vs Kappa架构

    千次阅读 2017-05-11 09:22:47
    Lambda 架构 Lambda 架构由Storm的作者Nathan Marz提出,其设计目的在于提供一个能满足大数据系统关键特性的架构,包括高容错、低延迟、可扩展等。其整合离线计算与实时计算,融合不可变性、读写分离和复杂性隔离...
  • 用于实时大数据处理的Lambda架构

    万次阅读 多人点赞 2015-05-24 10:40:59
    本文介绍了Lambda架构的基本概念。Lambda架构通过对数据和查询的本质认识,融合了不可变性(Immunability),读写分离和复杂性隔离等一系列架构原则,将大数据处理系统划分为Batch Layer, Speed Layer和Serving ...
  • 大数据推荐系统算法(2) lambda架构

    千次阅读 2019-12-06 13:18:30
    Lambda架构 1.Lambda系统架构提供了一个结合实时数据和Hadoop预先计算的数据环境的混合平台,以提供一个实时的数据视图。 2.分层架构:批处理层、实时处理层、服务层 批处理:批处理主要操作大容量静态数据集,并在...
  • Lambda架构在过去Lambda数据架构成为每一个公司大数据平台必备的架构,它解决了一个公司大数据批量离线处理和实时数据处理的需求。一个典型的Lambda架构如下:数据从底层的数据源开始,经过各种各样的格式进入...
  • 大数据的Lambda架构

    2020-06-04 20:25:34
    Lambda架构 Lambda架构提供了一个结合实时数据和Hadoop预先计算(离线计算批处理层)的数据环境的混合平台, 以提供一个实时的数据试图。 分层架构: 批处理层(离线处理数据),实时处理层(与批处理层数据采集点击...
  • 采用Lambda架构的目的是保证实时和离线数据的一致性。 通俗简单理解就是:kafka中的实时数据分两个条线 (1)实时条线,通过Storm、SparkStreaming、Flink等大数据实时处理框架,将kafka中的数据进行实时处理,...
  • 请首先阅读:https://blog.csdn.net/alidisi/article/details/79908258Lambda架构的一些缺点,随着数据量的增加已是显而易见了● 实时与批量计算结果不一致引起的数据口径问题:因为批量和实时计算走的是两个计算...
1 2 3 4 5 ... 20
收藏数 23,362
精华内容 9,344
热门标签
关键字:

lambda架构