前言
在大数据架构中，有两个十分常见的架构，那就是lambda架构和unifield架构，这两个架构在大数据中占据着十分重要的地位，在这篇文章中我们就给大家介绍一下lambda架构和unifield架构，帮助大家更深一步的去了解大数据，为今后我们的大数据学习有帮助。
1.lambda架构
在大数据系统中，Lambda架构算是一个重要的架构，大多数架构基本都是Lambda架构或者基于其变种的架构。通常来说，Lambda的数据通道分为两条分支：实时流和离线。实时流依照流式架构，保障了其实时性，而离线则以批处理方式为主，保障了最终一致性。这就是流式通道处理为保障实效性更多的以增量计算为主辅助参考，而批处理层则对数据进行全量运算，保障其最终的一致性，因此Lambda最外层有一个实时层和离线层合并的动作，此动作是Lambda里非常重要的一个动作。这也是很多人最容易忽略的地方。而lambda架构的优点十分明显，那就是既有实时又有离线，对于数据分析场景涵盖的非常到位。当然，这个架构的缺点也需要我们去了解，那就是离线层和实时流虽然面临的场景不相同，但是其内部处理的逻辑却是相同，因此有大量荣誉和重复的模块存在。正因为如此，这个架构的适用场景同时存在实时和离线需求的情况。
大数据的技术手段百花齐放, 各种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）就是最终用户在网页上看到的推荐商品列表。
2.unifield架构
Unifield架构表现更激进，将机器学习和数据处理揉为一体，从核心上来说，Unifield依旧以Lambda为主，不过对其进行了改造，在流处理层新增了机器学习层。新增了模型训练部分，并且将其在流式层进行使用。同时流式层不单使用模型，也包含着对模型的持续训练。Unifield架构的优点就是提供了一套数据分析和机器学习结合的架构方案，完美的解决了机器学习如何与数据平台进行结合的问题。缺点则是这个架构实施复杂度更高，对于机器学习架构来说，从软件包到硬件部署都和数据分析平台有着非常大的差别，因此在实施过程中的难度系数更高。所以这个架构学习起来是比较困难的。
我们在这篇文章中为大家介绍了两种常见的大数据架构的相关知识，具体就是unifield架构以及lambda架构。在大数据中，这两种架构都是十分常见的架构，所以大家要对这两个架构有所了解，希望这篇文章能够更好的帮助大家。
3.传统大数据架构
数据分析的业务没有发生任何变化，但是因为数据量、性能等问题导致系统无法正常使用，需要进行升级改造，那么此类架构便是为了解决这个问题。依然保留了ETL的动作，将数据经过ETL动作进入数据存储。数据分析需求依旧以BI场景为主，但是因为数据量、性能等问题无法满足日常使用。
4.流式架构
在传统大数据架构的基础上，流式架构数据全程以流的形式处理，在数据接入端将ETL替换为数据通道。经过流处理加工后的数据，以消息的形式直接推送给了消费者。存储部分在外围系统以窗口的形式进行存储。适用于预警、监控、对数据有有效期要求的情况。
5.Kappa架构
Kappa架构在Lambda的基础上进行了优化，将实时和流部分进行了合并，将数据通道以消息队列进行替代。因此对于Kappa架构来说，依旧以流处理为主，但是数据却在数据湖层面进行了存储，当需要进行离线分析或者再次计算的时候，则将数据湖的数据再次经过消息队列重播一次则可。
