您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 
     
   
 订阅
  捐助
深度漫谈数据系统架构——Lambda architecture
 
作者:永不言弃01
165 次浏览     评价:  
 2020-2-26
 
编辑推荐:
本文讲述传统系统的问题,Lambda架构的背景,大数据系统的关键特性,数据系统的本质等 希望对您有所帮助
本文来自于微信号阿里云云栖号,由火龙果软件Delores编辑、推荐。

传统系统的问题

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

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

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

Lambda架构的背景

大数据处理技术需要解决这种可伸缩性与复杂性。

首先要认识到这种分布式的本质,要很好地处理分区与复制,不会导致错误分区引起查询失败,而是要将这些逻辑内化到数据库中。当需要扩展系统时,可以非常方便地增加节点,系统也能够针对新节点进行rebalance。

其次是要让数据成为不可变的。原始数据永远都不能被修改,这样即使犯了错误,写了错误数据,原来好的数据并不会受到破坏。

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

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

大数据系统的关键特性

Marz介绍Big Data System许具备的属性:

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

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

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

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

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

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

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

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

数据系统的本质

Marz认为:数据系统通过查询过去的(部分、全部)数据去回答问题。如:他是一个什么样的人?他有多少朋友?这个账号是否收支平衡?。因此,Data System的通用定义为:

Query = Function(all data)。

对通用的表达式进行分解得到:

数据系统 = 数据 + 查询

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

数据本本质:When和What

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

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

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

数据的存储

Store Everything Rawly and Immutably

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

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

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

b、应对人为和机器的错误。人和机器每天都可能会出错,如何应对人和机器的错误,让数据系统快速恢复极其重要。不可变和可重复计算是应对认为和机器错误的常用方法。采用可变数据模型,引发错误的数据有可能被覆盖而丢失。

相比于采用不可变的数据模型,因为所有的数据都在,引发错误的数据也在。

修复的方法就可以简单的是遍历数据集上存储的所有的数据,丢弃错误的数据,重新计算得到Views。重新计算的关键点在于利用数据的时间特性决定的全局次序,依次顺序重新执行,必然能得到正确的结果。

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

Lambda架构

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

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

(A)batch view = function(all data);

(B)query = function(batch view)。

Batch Layer

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

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

b、针对这个Master Dataset进行预运算

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

对View的理解:

View是一个和业务关联性比较大的概念,View的创建需要从业务自身的需求出发。一个通用的数据库查询系统,查询对应的函数千变万化,不可能穷举。但是如果从业务自身的需求出发,可以发现业务所需要的查询常常是有限的。

Batch Layer需要做的一件重要的工作就是根据业务的需求,考察可能需要的各种查询,根据查询定义其在数据集上对应的Views。

Batch Layer的Immutable data模型和Views

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

图(E)

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

Speed Layer

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

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

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

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

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

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

图(F)

Speed Layer可总结为以(C)

Realtime View = function(Realtime View, new data);

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

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

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

Serving Layer

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

a、对batch View和RealTime View的随机访问

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

图(G)

综上所诉,Serving Layer采用如下等式(D)表示:

Query = function(Batch Views, Realtime View)。

Lambda 架构组件选型

下图给出了Lambda架构中各组件在大数据生态系统中和阿里集团的常用组件。

数据流存储选用不可变日志的分布式系统Kafa、TT、Metaq;Batch Layer数据集的存储选用Hadoop的HDFS或者阿里云的ODPS;Batch View的加工采用MapReduce;Batch View数据的存储采用Mysql(查询少量的最近结果数据)、Hbase(查询大量的历史结果数据)。Speed Layer采用增量数据处理Storm、Flink;Realtime View增量结果数据集采用内存数据库Redis。

图(H)

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

Lambda架构的评估

优点:

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

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

缺点:

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

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

图(I)

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

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

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

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

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

 
   
165 次浏览  评价: 差  订阅 捐助
相关文章

我们该如何设计数据库
数据库设计经验谈
数据库设计过程
数据库编程总结
 
相关文档

数据库性能调优技巧
数据库性能调整
数据库性能优化讲座
数据库系统性能调优系列
相关课程

高性能数据库设计与优化
高级数据库架构师
数据仓库和数据挖掘技术
Hadoop原理、部署与性能调优