大家好，明天咱们来介绍一个用于亿级实时数据分析架构 Lambda 架构。
Lambda 架构
Lambda 架构（Lambda Architecture）是由 Twitter 工程师南森·马茨（Nathan Marz）提出的大数据处理架构。这一架构的提出基于马茨在 BackType 和 Twitter 上的分布式数据处理系统的教训。
Lambda 架构使开发人员可能构建大规模分布式数据处理系统。它具备很好的灵活性和可扩展性，也对硬件故障和人为失误有很好的容错性。
Lambda 架构总共由三层零碎组成：批处理层 （Batch Layer）， 速度解决层 （Speed Layer），以及用于响应查问的 服务层（Serving Layer）。
在 Lambda 架构中，每层都有本人所肩负的工作。
批处理层存储管理主数据集（不可变的数据集）和事后批处理计算好的视图。
批处理层应用可解决大量数据的分布式解决零碎事后计算结果。它通过解决所有的已有历史数据来实现数据的准确性。这意味着它是基于残缺的数据集来从新计算的，可能修复任何谬误，而后更新现有的数据视图。输入通常存储在只读数据库中，更新则齐全取代现有的事后计算好的视图。
速度解决层会实时处理新来的大数据。
速度层通过提供最新数据的实时视图来最小化提早。速度层所生成的数据视图可能不如批处理层最终生成的视图那样精确或残缺，但它们简直在收到数据后立刻可用。而当同样的数据在批处理层解决实现后，在速度层的数据就能够被代替掉了。
实质上，速度层补救了批处理层所导致的数据视图滞后。比如说，批处理层的每个工作都须要 1 个小时能力实现，而在这 1 个小时里，咱们是无奈获取批处理层中最新工作给出的数据视图的。而速度层因为可能实时处理数据给出后果，就补救了这 1 个小时的滞后。
所有在批处理层和速度层解决完的后果都输入存储在服务层中，服务层通过返回事后计算的数据视图或从速度层解决构建好数据视图来响应查问。
咱们举个这样的例子：如果用户 A 的电脑临时借给用户 B 应用了一下，而用户 B 浏览了一些新的网站类型（与用户 A 不同）。这种状况下，咱们无奈判断用户 A 实际上是否对这类型的广告感兴趣，所以不能依据这些新的浏览记录给用户 A 推送广告。那么咱们如何做到既能实时剖析用户新的网站浏览行为又能兼顾到用户的网站浏览行为历史呢？这就能够利用 Lambda 架构。
所有的新用户行为数据都能够同时流入批处理层和速度层。批处理层会永恒保留数据并且对数据进行预处理，失去咱们想要的用户行为模型并写入服务层。而速度层也同时对新用户行为数据进行解决，失去实时的用户行为模型。
而当“应该对用户投放什么样的广告”作为一个查问（Query）来到时，咱们从服务层既查问服务层中保留好的批处理输入模型，也对速度层中解决的实时行为进行查问，这样咱们就能够失去一个残缺的用户行为历史了。
一个查问就如下图所示，既通过批处理层兼顾了数据的完整性，也能够通过速度层补救批处理层的高延时性，让整个查问具备实时性。
Lambda 架构在硅谷一线大公司的利用曾经非常宽泛，我来带你一起看看一些理论的利用场景。
Twitter 的数据分析案例
Twitter 在欧美非常受欢迎，而 Twitter 中人们所发 Tweet 外面的 Hashtag 也经常能引爆一些热搜词汇，也就是 Most Popular Hashtags。上面我来给你讲述一下如何利用 Lambda 架构来实时剖析这些 Hashtags。
在这个理论案例里，咱们先用 twitter4J 的流解决 API 抓取实时的 Twitter 推文，同时利用 Apache Kafka 将抓取到的数据保留并实时推送给批处理层和速度层。
因为 Apache Spark 平台中既有批处理架构也兼容了流解决架构，所以咱们抉择在批处理层和速度层都采纳 Apache Spark 来读取来自 Apache Kafka 的数据。
批处理层和速度层在剖析解决好数据后会将数据视图输入存储在服务层中，咱们将应用 Apache Cassandra 平台来存储他们的数据视图。Apache Cassandra 将批处理层的视图数据和速度层的实时视图数据联合起来，就能够失去一系列乏味的数据。
例如，咱们依据每一条 Tweet 中元数据（Metadata）里的 location field，能够得悉发推文的人的所在地。而服务层中的逻辑能够依据这个地址信息进行分组，而后统计在不同地区的人所关怀的 Hashtag 是什么。
工夫长达几周或者的几个月的数据，咱们能够联合批处理层和速度层的数据视图来得出，而快至几个小时的数据咱们又能够依据速度层的数据视图来获知，怎么样？这个架构是不是非常灵便？
看到这里，你可能会问，我在下面所讲的例子都是来自些科技巨头公司，如果我在开发中面对的数据场景没有这么微小，又或者说我的公司还在守业起步阶段，我是否能够用到 Lambda 架构呢？
答案是必定的！咱们一起来看一个在硅谷旧金山守业公司的 App 后盾架构。
Smart Parking 案例剖析
在硅谷地区下班生存，找停车位是一大难题。这里地少车多，每次出行，特地是周末，找停车位都要绕个好几十分钟能力找失去。
智能停车 App 就是在这样的背景下诞生的。这个 App 能够依据大规模数据所构建的视图举荐最近的车位给用户。
看到这里，我想先请你联合之前所讲到的广告精准投放案例，思考一下 Lambda 架构是如何利用在这个 App 里的，而后再听我娓娓道来。
好，咱们来梳理一下各种能够利用到的大数据。
首先是能够拿到各类停车场的数据。这类数据的实时性尽管不肯定高，然而数据的准确性高。那咱们能不能只通过这类大数据来举荐停车位呢？
我举个极其的例子。假如在一个区域有三个停车场，停车场 A 当初只剩下 1 个停车位了。
停车场 B 和 C 还有十分多的空位。而在这时候间隔停车场比 A 较近的地位有 10 位车主在应用这个 App 寻求举荐停车位。如果只通过车主和停车场的间隔和停车场残余停车位来判断的话，App 很有可能会将这个只剩下一个停车位的停车场 A 同时举荐给这 10 位用户。
后果可想而知，只有一位幸运儿能找到停车位，剩下的 9 位车主须要从新寻找停车位。
如果左近又呈现了只有一个停车位的停车场呢？同理，这个 App 又会举荐这个停车场给剩下的 9 位用户。这时又只能有一位幸运儿找到停车位。
如此重复循环，用户体验会十分差，甚至会导致用户放弃这个 App。
那咱们有没有方法能够改良举荐的准确度呢？
你可能会想到咱们能够利用这些停车场的历史数据，建设一个人工智能的预测模型，在举荐停车位的时候，不单单思考到左近停车场的残余停车位和用户与停车场的相邻间隔，还能将预测模型利用在举荐里，看看将来的一段时间内这个停车场是否有可能会被停满了。
这时候咱们的停车位举荐零碎就变成了一个基于分数（Score）来举荐停车位的零碎了。
好了，这个时候的零碎架构是否曾经达到最优了呢？你有想到利用 Lambda 架构吗？
没错，这些停车场的历史数据或者每隔半小时拿到的停车位数据，咱们能够把它作为批处理层的数据。
那速度层的数据呢？咱们能够将所有用户的 GPS 数据汇集起来，这些须要每秒收集的 GPS 数据刚好又是速度层所善于的实时流解决数据。从这些用户的实时 GPS 数据中，咱们能够再建设一套预测模型来预测左近停车场地位的拥挤水平。
服务层将从批处理层和速度层失去的分数联合后将失去最高分数的停车场举荐给用户。这样利用了历史数据（停车场数据）和实时数据（用户 GPS 数据）能大大晋升举荐的准确率。
总结
在理解 Lambda 架构后，咱们晓得 Lambda 架构具备很好的灵活性和可扩展性。咱们能够很不便地将现有的开源平台套用入这个架构中，如下图所示。
当开发者须要迁徙平台时，整体的架构不须要扭转，只须要将逻辑迁徙到新平台中。
例如，能够将 Apache Spark 替换成 Apache Storm。而因为咱们有批处理层这一概念，又有了很好的容错性。
如果某天开发者发现逻辑呈现了谬误，只须要调整算法对永恒保留好的数据从新进行解决写入服务层，通过屡次迭代后整体的逻辑便能够被纠正过去。当初有很多的开发我的项目可能曾经有了比拟成熟的架构或者算法了。
然而如果咱们平时能多思考一下现有架构的瓶颈，又或者想一想当初的架构能不能改善得更好，有了这样的思考，在学习到这些经典优良架构之后，说不定真的能让现有的架构变得更好。
本文由 mdnice 多平台公布