Lambda 架构
(Partial Recomputation algorithms),也即选取必要的历史数据进行重新计算,以生日推断算法为例,假设新数据中只包含用户 A 的数据,那么,我们可以从主数据集中选取用户 A 的历史数据与新数据合并,再进行计算,这样计算的数据量将会大大减少。比如,假设用户的报表需要按月、按天、按小时、按分钟等维度的视图,最简单的方法是只保存一份分钟级视图,若用户需要查询小时级粒度的数据,
Lambda的命名由来
我们通常认为这个希腊字母与这一模式相关联是因为数据来自两个地方。
批量数据和快速的流式数据代表Lambda符号的弯曲部分,然后通过服务层(线段与曲线部分合并)合并,如图所示。
显示中的例子
Lambda 架构的解决思路
我们可将数据分成两类,历史数据和实时数据(最近几个小时),用户对两类数据在查询时延、精度等方面的要求各不相同。所以,我们完全可以采取不同的技术方案对它们分别处理。这就是 Lambda 架构的核心思想之一,分层。
Lambda 架构分 3 个层次,每个层次职责分明、使用不同的技术方案,以此来满足大数据系统的各项诉求。
- 批处理层(Batch Layer):负责离线处理历史数据,包含主数据集(Master Dataset)。所有的数据都会往主数据集写入。批处理层不会立即处理新数据,而是会在非业务繁忙时段,对全量数据进行批量处理,生成批视图(Batch View)。
- 服务层(Serving Layer):负责存储批处理层生成的批视图,并对外提供批视图的查询接口。通常都会带有索引,以便用户能够快速查询数据。
- 速度层(Speed Layer):负责实时处理新数据,生成实时视图(Realtime View),提供实时视图的查询接口,。
批处理层(Batch Layer)
不可变的数据
传统数据系统中,数据是可变的,比如前文所提到的网页访问例子中,pageviews
字段会随着网页访问行为而递增。当出现问题,特别是人为错误时,通常因难以溯源而无法纠错,导致容错性较低。
为此,Lambda 架构中批处理层采取的策略是不可变的数据,通过存储原始的数据实现:
上述例子中,采用可变数据的存储方式后,用户的每一次访问行为都对应一行数据,并通过时间戳来区分。pageviews
不再作为字段存储在数据库里,而是在数据处理时进行计算。
这种不可变的数据存储能够带来以下一些好处:
- 更灵活的查询,可以对任何一个时间段的数据进行计算。
- 更高的容错性。即使在人为错误发生后,我们仍能够基于原始数据进行重新计算,得到正确的结果。
- 更简单的存储。存储只涉及追加新的数据,不涉及数据更改、索引更新等复杂操作。
不可变数据存储的缺点也很明显,相比可变存储,数据是持续追加的,因此需要占用更大的存储空间。当然,我们也可以制定一些数据过期删除策略,定时清理冗余、低价值的数据,降低存储成本。
数据存储
主数据集包含了所有数据,存储它的数据库应具备以下的能力:
- 能够支持追加写数据。
- 能够保证数据是不可变的。
- 数据存储量要足够大。
- 能够支持大批量地处理历史数据。
由此,我们很容易想到用分布式文件(Distributed File Systems,DFS)来存储主数据集:
- DFS 实现追加写非常简单,只须将文件添加到主数据集所包含的文件夹中即可。
- DFS 通过权限控制可以轻松确保数据不可变。
- DFS 通常有很好的可扩展性,可以轻松增加机器来应对不断增长的数据量。
- DFS 的优点之一是具备很高的读写吞吐量,比如 HDFS,结合 MapReduce 计算引擎,能够实现大批量的离线数据处理。
全量计算 VS 增量计算
批处理的数据计算方式可以分成全量计算(Recomputation algorithms)和增量计算(Incremental algorithms)。全量计算每次都会对全量数据进行重新计算,得到新的批视图;而增量计算只会对新的数据进行计算,并将计算出来的视图与已有视图进行合并,形成新的批视图。
相比全量计算,增量计算每次计算量更小、有更好的性能,但其代价是更低的容错性,因此,更推荐使用全量计算。
另外,当算法依赖历史数据时,增量计算显然难以得到正确答案。考虑一个生日推断算法的例子,系统根据不同时刻抓取的用户信息 [userid, age, timestamp]
来推断用户的生日,比如在 2023/2/21 抓取某用户的年龄为 28,在 2024/3/4 再次抓取他的年龄为 29,那么该用户的生日就在 2023/2/21 和 2024/3/4 之间。显然,每次用于计算的信息越多,生日推断的结果就越准。
另外,我们也可以选择一个折中方案,部分重计算(Partial Recomputation algorithms),也即选取必要的历史数据进行重新计算,以生日推断算法为例,假设新数据中只包含用户 A 的数据,那么,我们可以从主数据集中选取用户 A 的历史数据与新数据合并,再进行计算,这样计算的数据量将会大大减少。
服务层(Serving Layer)
服务层属于批处理层的延伸,负责存储批视图,并对外提供查询接口。通常,服务层所使用的数据库须要具备如下属性:
- 支持批量写。当新的批视图计算完成后,服务层需要支持批量写来完全替换掉旧视图。
- 可扩展性好。随着主数据集的增长,批视图的存储空间可能也会随之增大,因此也要具备良好的可扩展性。
- 支持随机读。服务层必须支持随机读,以及索引查询能力,这样才能做到快速的查询响应。
- 容错性好。服务层通常也是分布式数据库,因此容错性是基础能力,Speed Layer中处理的数据也不断写入Batch Layer,当Batch Layer中重新计算的数据集包含Speed Layer处理的数据集后,当前的Realtime View就可以丢弃,这也就意味着Speed Layer处理中引入的错误,在Batch Layer重新计算时都可以得到修正。这点也可以看成是CAP理论中的最终一致性(Eventual Consistency)的体现。
比如,假设用户的报表需要按月、按天、按小时、按分钟等维度的视图,最简单的方法是只保存一份分钟级视图,若用户需要查询小时级粒度的数据,临时汇聚。但因为这需要额外的聚合运算,无法满足低时延的诉求。更好的方法是,在服务层保存多种粒度的视图。
速度层(Speed Layer)
批处理层可以很好地处理离线历史数据,但很多场景下,数据是实时产生的,比如 IoT。此时,单靠批处理层显然无法无法满足实时数据的低时延处理。因此,可以把速度层看成是对批处理层在实时性上的补充,它负责实时处理源源不断的新数据,并生成实时视图(Realtime View)供用户查询。
与批处理层相比,速度层具备如下的特点:
- 能够处理实时数据。与批处理层处理全量数据不同,速度层只处理实时数据。在技术上选型上,通常使用流式计算引擎,能够不断处理数据,并实时更新实时视图。
- 采用增量计算。速度层的首要目的是为用户提供实时数据的低时延查询能力,作为代价,计算结果可能存在精度不足、甚至错误的问题,不过这些错误最终都会被批处理层纠正。
速度层除了要进行实时数据的增量处理外,还需保存实时视图,提供类似服务层的能力,也即对外提供实时视图的查询接口。
更好的 Lambda 架构实现
上面所介绍的 Lambda 架构中,服务层只是作为批处理层的延伸,存储批视图。但在介绍速度层时我们提到,速度层也要对外提供实时视图的查询接口。因此,更好的实现方式是,把批视图和实时视图都存储在服务层,让服务层成为唯一对外提供接口的地方:
、
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。
广告推送的例子
我们举个这样的例子:假如用户A的电脑暂时借给用户B使用了一下,而用户B浏览了一些新的网站类型(与用户A不同)。这种情况下,我们无法判断用户A实际上是否对这类型的广告感兴趣,所以不能根据这些新的浏览记录给用户A推送广告。那么我们如何做到既能实时分析用户新的网站浏览行为又能兼顾到用户的网站浏览行为历史呢?这就可以利用Lambda架构。
所有的新用户行为数据都可以同时流入批处理层和速度层。批处理层会永久保存数据并且对数据进行预处理,得到我们想要的用户行为模型并写入服务层。而速度层也同时对新用户行为数据进行处理,得到实时的用户行为模型。
而当“应该对用户投放什么样的广告”作为一个查询(Query)来到时,我们从服务层既查询服务层中保存好的批处理输出模型,也对速度层中处理的实时行为进行查询,这样我们就可以得到一个完整的用户行为历史了。
电商行为分析为例子
数据流角度分析
技术架构角度分析
五、课后练习
1.以下关于大数据的说法中,错误的是()。
A.大数据拥有体量大、构造单调、时效性强等特点
B.处理大数据需要采用新式计算架构和智能算法等新技术
C.大数据的应用着重相关剖析,而不是因果剖析
D.大数据的目的在于发现新的知识,洞悉并进行科学决策
2.Lambda 架构分为三层:(1)的核心功能是存储主数据集。(2)的核心功能是处理增量实时数据,生成实时视图,快速执行即席查询。(3)的核心功能是响应用户请求,合并批视图和实时视图中的结果数据集得到最终数据集。
(1)A.批处理层 B.流处理层 C.加速层 D.存储层
(2)A.批处理层 B.服务层 C.加速层 D.视图层
(3)A.视图层 B.流处理层 C.服务层 D.存储层
3.某互联网公司近期为其旗下产品升级架构,架构图如图22.10所示,请指出该架构图采用的是什么架构,并结合架构图说明该架构的层次结构。
答案解析:
1、解析:大数据具有体量大、时效性强的特征,并非构造单调,而是类型多样;处理大数据时,传统数据处理系统因数据过载,来源复杂,类型多样等诸多原因性能低下,需要采用以新式计算架构和智能算法为代表的新技术;大数据的应用重在发掘数据间的相关性,而非传统逻辑上的因果关系;因此,大数据的目的和价值就在于发现新的知识,洞悉并进行科学决策。
答案:A
2、解析:Lambda架构分为3层:(1)批处理层。该层的核心功能是存储主数据集,主数据集数据具有原始、不可变、真实的特征。批处理层周期性地将增量数据转储至主数据集,并在主数据集上执行批处理,生成批视图。架构实现方面可以使用Hadoop HDFS或HBase存储主数据集,再利用Spark或Map/Reduce 执行周期批处理,之后使用Map/Reduce创建批视图。
(2)加速层。该层的核心功能是处理增量实时数据,生成实时视图,快速执行即席查询。架构实现方面可以使用Hadoop HDFS或HBase存储实时数据,利用Spark或Storm实现实时数据处理和实时视图。
(3)服务层。该层的核心功能是响应用户请求,合并批视图和实时视图中的结果数据集得到最终数据集。具体来说就是接收用户请求,通过索引加速访问批视图,直接访问实时视图,然后合并两个视图的结果数据集生成最终数据集,响应用户请求。架构实现方面可以使用 HBase 或Cassandra作为服务层,通过Hive创建可查询的视图。
答案:ACC
3、解析:根据题目给出的架构图可发现,该产品通过Collector收集结构化数据推送给主Kafka.主Kafka 再将数据写入HDFS分布式文件系统,而异构数据通过DataX/Sqoop 写入HDFS.HDFS中的数据会通过Offline采用Hive、MapReduce或Spark进行离线处理,还会通过OLAP采用Kylin
或Naix进行联机分析处理后存储至由非各类关系型数据库组成的处理结果存储。主Kafka会通过分发机制将数据分发给Kafka,从而将数据转交给 Flink/Storm 订阅者。Flink/Storm 会对数据进行流式实时处理,再将处理结果存储至处理结果存储。OneDataAPI通过非关系型数据库中的处理结果对数据平面DataFace和业务系统提供数据服务。通过分析架构图可知,该架构图采用的是Lambda
架构。
答案:该架构图采用的是Lambda架构,该架构由如下层次组成:
(1)数据采集层:Collector、DataX/Sqoop.
(2)数据源:HDFS.
(3)批处理层:Offline(Hive/MR/Spark),OLAP(Kylin/Naix).
(4)加速层:Flink/Storm.
(5)服务层:结果视图存储(MongoDB、ElasticSearch、HBase、Redis...),OneDataAPI.
开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!
更多推荐
所有评论(0)