浅析Lambda架构

　　大家好，今天我们来介绍一个Lambda架构，用于亿级实时数据分析架构。

　　Lambda架构(Lambda Architecture)南森·马茨，Twitter工程师(Nathan Marz)提出的大数据处理架构。基于马茨在Backtype和Twitter上的分布式数据处理系统的经验，提出了该架构。

　　Lambda架构使开发人员能够构建大规模的分布式数据处理系统。它具有良好的灵活性和可扩展性，对硬件故障和人为错误也具有良好的容错性。

　　Lambda架构由三层系统组成： 批处理层(Batch Layer)， 速度处理层(Speed Layer)，以及用于响应查询的 服务层(Serving Layer)。

　　在Lambda架构中，每层都有自己的任务。

　　批处理层存储管理主数据集(不变数据集)和预批处理计算的视图。

　　批处理层使用分布式处理系统提前计算结果，可以处理大量数据。它通过处理所有现有的历史数据来实现数据的准确性。这意味着它基于一个完整的数据集进行重新计算，可以修复任何错误，然后更新现有的数据视图。输出通常存储在只读数据库中，更新完全取代了现有的预计视图。

　　速度处理层将实时处理新的大数据。

　　速度层通过提供最新数据的实时视图来减少延迟。速度层生成的数据视图可能不如批处理层生成的最终视图准确或完整，但在收到数据后几乎可以立即使用。当批处理层处理相同的数据时，速度层的数据可以被替换。

　　本质上，速度层弥补了批处理层造成的数据视图滞后。例如，批处理层的每项任务需要一个小时才能完成，而在这一个小时内，我们无法获得批处理层中最新任务给出的数据视图。速度层弥补了这一小时的滞后，因为它可以实时处理数据给出的结果。

　　批处理层和速度层处理的所有结果都输出并存储在服务层中。服务层通过返回预计算的数据视图或从速度层处理构建数据视图来响应查询。

　　让我们举一个例子：如果用户A的计算机暂时借给用户B，用户B浏览了一些新的网站类型(不同于用户A)。在这种情况下，我们无法判断用户A实际上是否对这类广告感兴趣，因此我们无法根据这些新的浏览记录向用户A推送广告。那么，我们如何既能实时分析用户的新网站浏览行为，又能兼顾用户网站浏览行为的历史呢?Lambda架构可用于此。

　　所有新用户行为数据都可以同时流入批处理层和速度层。批处理层将永久保存数据并对数据进行预处理，以获得我们想要的用户行为模型并将其写入服务层。同时，速度层还处理新用户行为数据，以获得实时用户行为模型。

　　而且当“应该向用户投放什么样的广告”作为查询时(Query)当我们到达时，我们不仅查询服务层中保存的批处理输出模型，还查询速度层中处理的实时行为，从而获得完整的用户行为历史。

　　如下图所示，一个查询不仅可以通过批处理层考虑数据的完整性，还可以通过速度层弥补批处理层的高延迟，使整个查询实时。

　　Lambda架构已广泛应用于硅谷一线大公司。让我带你去看看一些实际的应用场景。Twitter的数据分析案例

　　Twitter在欧美非常受欢迎，而Twitter中人们发布的Tweeet中的Hashtag往往会引爆一些热门搜索词，即Moster Popular Hashtags。让我告诉你如何利用Lambda架构实时分析这些Hashtags。

　　在这个实际案例中，我们首先使用twitter4J的流处理API捕获实时twitter推文，同时使用Apache。 保存Kafka捕获的数据，并将其实时推送到批处理层和速度层。

　　由于Apache Spark平台既有批处理架构，又兼容流处理架构，所以我们选择在批处理层和速度层使用Apachee Spark读取来自Apache Kafka的数据。

　　分析处理数据后，批处理层和速度层将数据视图输出并存储在服务层中。我们将使用Apache Cassandra平台存储他们的数据视图。Apache 通过将批处理层的视图数据与速度层的实时视图数据相结合，Cassandra可以获得一系列有趣的数据。

　　例如，我们根据每个Tweet中元数据(Metadata)location中的location field，你可以知道发送推文的人的位置。服务层中的逻辑可以根据地址信息进行分组，然后统计不同地区人们关心的标签。

　　数据持续几周或几个月，我们可以结合批处理层和速度层的数据视图，我们可以根据速度层的数据视图了解快几个小时的数据。怎么样?这个架构很灵活吗?

　　看到这里，你可能会问，我上面提到的所有例子都来自一些科技巨头。如果我在开发中面临的数据场景没有那么大，或者我的公司还处于创业初期，我能使用Lambda架构吗?

　　答案是肯定的!我们来看看硅谷旧金山创业公司app的后台架构。Smart Parking案例分析

　　在硅谷工作生活，找停车位是个大问题。这里车少，每次旅行，尤其是周末，找停车位要几分钟才能找到。

　　智能停车应用就是在这样的背景下诞生的。该应用程序可以根据大规模数据构建的视图向用户推荐最新的停车位。

　　看到这里，我想让你考虑一下Lambda架构是如何应用于这个应用程序的，然后结合之前提到的广告准确案例听我说。

　　好了，我们来梳理一下各种可以使用的大数据。

　　首先，您可以获得各种停车场的数据。虽然这些数据的实时性不一定很高，但数据的准确性很高。我们只能通过这些大数据推荐停车位吗?

　　我举个极端的例子。假设一个地区有三个停车场，现在停车场A只剩下一个停车位了。

　　停车场B和C还有很多空间。此时，10名车主正在使用该应用程序寻求推荐的停车位。如果只通过车主与停车场的距离和停车场的剩余停车位来判断，该应用程序很可能会同时向10名用户推荐只剩下一个停车位的停车场A。

　　结果可想而知，只有一个幸运的人能找到停车位，剩下的九个车主需要重新找到停车位。

　　如果附近只有一个停车位呢?同样，该应用程序也将向剩下的9名用户推荐该停车场。只有一个幸运的人能找到停车位。

　　这样的重复循环，用户体验会很差，甚至会导致用户放弃这个应用。

　　有没有办法提高推荐的准确性?

　　您可能会认为，我们可以利用这些停车场的历史数据建立人工智能预测模型。在推荐停车位时，我们不仅可以考虑附近停车场的剩余停车位与用户与停车场的相邻距离，还可以将预测模型应用到推荐中，看看停车场在未来是否可能停车。

　　此时，我们的停车位推荐系统已成为一个基于分数的系统(Score)推荐停车位系统。

　　那么，此时的系统架构是否达到了最佳水平呢?您有没有想过Lambda架构的应用?

　　是的，我们可以把这些停车场的历史数据或每半小时获得的停车位数据作为批处理层的数据。

　　速度层的数据呢?我们可以收集所有用户的GPS数据，这些需要每秒收集的GPS数据只是速度层擅长的实时流处理数据。从这些用户的实时GPS数据中，我们可以建立另一个预测模型来预测附近停车场的拥挤程度。

　　服务层将从批处理层和速度层得到的分数结合起来，向用户推荐最高分数的停车场。这样，历史数据(停车场数据)和实时数据(用户GPS数据)的使用可以大大提高推荐的准确性。总结

　　在了解了Lambda架构之后，我们知道Lambda架构具有良好的灵活性和可扩展性。如下图所示，我们可以很容易地将现有的开源平台应用到该架构中。

　　当开发者需要迁移平台时，整体架构不需要改变，只需要将逻辑迁移到新平台。

　　例如，Apache可以使用 替换为Apache的Spark Storm。而且由于我们有一个批处理层的概念，并且具有良好的容错性。

　　如果有一天开发人员发现逻辑错误，他们只需要调整算法，将永久保存的数据重新处理并写入服务层。经过多次迭代，可以纠正整体逻辑。现在有许多开发项目可能有相对成熟的架构或算法。

　　然而，如果我们能更多地思考现有架构的瓶颈，或者思考现有架构是否能得到更好的改进，有了这样的思考，在学习了这些经典和优秀的架构之后，我们可能真的能使现有的架构更好。