详细讲解大数据处理中的Lambda架构和Kappa架构用户在线业务处理组件用棕色标注。这部分属于互联网在线应用，其他蓝色部分属于大数据相关组件。使用开源大数据产品或自行开发相关大数据组件。可以看到大数据平台从上到下可以分为三个部分：数据采集、数据处理、数据输出和展示。数据采集??将应用产生的数据和日志同步到大数据系统。由于数据来源不同，这里的数据同步系统实际上是多个相关系统的组合。Sqoop通常用于数据库同步，日志同步可以选择Flume，打点采集的数据通过Kafka等消息队列进行格式化转换传输。不同数据源产生的数据质量可能会有很大差异。数据库中的数据可能会直接导入大数据系统使用，而日志和爬虫产生的数据需要经过大量的清洗和转化才能有效使用。数据处理是大数据存储和计算的核心，数据同步系统导入的数据存储在HDFS中。MapReduce、Hive、Spark等计算任务读取HDFS上的数据进行计算，然后将计算结果写入HDFS。MapReduce、Hive、Spark等进行的计算处理称为离线计算，存储在HDFS中的数据称为离线数据。在大数据系统上进行的离线计算通常针对所有数据（的某一方面），例如挖掘历史上所有订单的商品相关性。这时候数据规模非常大，需要很长的运行时间。这种计算是离线计算。除了离线计算，还有一些数据量比较大，但需要处理时间比较短的场景。比如淘宝需要统计每秒产生的订单数，用于监控和宣传。这种场景称为大数据流式计算，通常采用Storm、SparkSteaming等流式大数据引擎来完成，可以在秒级甚至毫秒级完成计算。数据输出与展示大数据计算产生的数据仍然写入HDFS，但应用程序不可能从HDFS读取数据，所以必须将HDFS中的数据导出到数据库中。同步导出数据相对容易，计算产生的数据也比较规范。稍加处理后，就可以用Sqoop等系统导出到数据库中了。这时，应用程序可以直接访问数据库中的数据并实时展示给用户，比如展示给用户关联的推荐商品。大数据除了为用户接入提供数据外，还需要为运营和决策提供各种统计报表。这些数据也被写入数据库，并被相应的后台系统访问。很多运营管理人员每天上班都会登录后台数据系统，查看前一天的数据报表，看业务是否正常。如果数据正常甚至上升，可以稍微放松一下；如果数据在下降，那么焦躁而忙碌的一天就要开始了。将以上三部分整合在一起就是任务调度管理系统。不同数据什么时候开始同步，如何合理调度各种MapReduce和Spark任务，使资源利用最合理，等待时间不至于过长。同时，临时的重要任务也能尽快执行，这一切都需要一个任务调度管理系统来完成。上面提到的大数据平台架构也称为Lambda架构，是构建大数据平台的常规架构原型方案。Lambda架构原型请见下图。Lambda架构Lambda架构（LambdaArchitecture）是由Twitter工程师NathanMarz提出的一种大数据处理架构。该架构基于Matz在BackType和Twitter的分布式数据处理系统方面的经验。Lambda架构使开发人员能够构建大规模的分布式数据处理系统。它具有很好的灵活性和可扩展性，对硬件故障和人为错误也有很好的容错能力。Lambda架构由三层系统组成：批处理层（BatchLayer）、速度处理层（SpeedLayer）和响应查询的服务层（ServingLayer）。在Lambda架构中，每一层都有自己的任务。批处理层存储和管理主数据集（不可变数据集）和预批处理计算视图。批处理层使用可以处理大量数据的分布式处理系统预先计算结果。它通过处理所有现有的历史数据来实现数据的准确性。这意味着它会根据完整数据集重新计算，修复所有错误，然后更新数据的现有视图。输出通常存储在只读数据库中，更新完全取代现有的预先计算的视图。速度处理层实时处理传入的大数据。速度层通过提供最新数据的实时视图来最大限度地减少延迟。速度层生成的数据视图可能不像批处理层最终生成的视图那样准确或完整，但它们几乎在接收到数据后立即可用。并且在batch层处理相同的数据时，可以替换speed层的数据。本质上，速度层补偿了批处理层导致的数据查看滞后。比如batch层的每个task需要1小时完成，而在这个小时内，我们无法获取到batch层最新task给出的dataview。速度层弥补了1小时的延迟，因为它可以实时处理数据并给出结果。所有批处理层和速度层处理的结果都输出并存储在服务层，服务层通过返回预先计算的数据视图或处理来自速度层的构建数据视图来响应查询。例如，广告预测等推荐系统一般采用Lambda架构。一般能做精准广告的公司都会有大量的历史数据，比如用户特征、用户历史浏览记录、网页类型分类等。业界比较流行的做法是在批处理层使用AlternatingLeastSquares(ALS)算法，即CollaborativeFiltering协同过滤算法，可以得到符合用户特征的广告类型和其他用户感兴趣的，也可以获得该用户感兴趣的广告类型。广告类型与广告类似，也可以使用k-means对客户感兴趣的广告类型进行分类，这里的结果就是batch层的结果。在速度层，根据用户实时浏览的网页类型，在之前分类的广告中找到前K个广告。最终服务层可以将速度层中排名前K的广告和批处理层中分类的点击率高的同类广告进行组合，进行选择投放给用户。Lambda架构的不足虽然Lambda架构使用起来非常灵活，可以适用于很多应用场景，但是在实际应用中，Lambda架构也存在一些不足，主要是其维护非常复杂。在使用Lambda架构时，架构师需要维护两个复杂的分布式系统，并确保它们在逻辑上向服务层产生相同的输出。我们都知道在分布式框架中编程其实是非常复杂的，尤其是我们还会针对不同的框架进行专门的优化。所以几乎每个架构师都同意Lambda架构在实践中维护起来有些复杂。那么如何解决这个问题呢？我们先想一想，维护这个架构复杂的根本原因是什么？维护Lambda架构的复杂性在于我们要同时维护两套系统架构：批处理层和速度层。我们已经说过，将批处理层包含在架构中是因为从批处理层获得的结果准确率高，而添加速度层是因为它在处理大规模数据时延迟低。我们能否改进其中一层的架构，使其具有另一层的特性？比如改进批处理层的系统让它有更低的延迟，或者改进速度层的系统，让它生成的数据视图更准确更接近历史数据如何？另一种常用于大规模数据处理的架构——Kappa架构（KappaArchitecture），就是在这样的思考下诞生的。Kappa架构Kappa架构是LinkedIn前总工程师JayKreps提出的架构思想。Kreps是多个知名开源项目（包括ApacheKafka和ApacheSamza等流处理系统）的作者之一，现任Confluent大数据公司CEO。Krepps提出了一个改进Lambda架构的观点：我们能否提高Lambda架构中速度层的系统性能，使其也能处理数据的完整性和准确性？我们可以改进Lambda架构吗？速度层使其能够进行实时数据处理，同时也具备在业务逻辑更新的情况下重新处理之前处理过的历史数据的能力？他发现，根据他多年的架构经验，我们可以实现这样的改进。ApacheKafka等流处理平台具有永久保存数据日志的功能。通过平台的这个特性，我们可以对部署在速度层架构中的历史数据进行再加工。下面以ApacheKafka为例，介绍一下整个新架构的流程。第一步是部署ApacheKafka，并设置数据日志的保留期限（RetentionPeriod）。这里的保留期是指你希望能够重新处理的历史数据的时间间隔。例如，如果您希望重新处理长达一年的历史数据，您可以将ApacheKafka中的保留期设置为365天。如果你希望能够处理所有的历史数据，你可以在ApacheKafka中将保留期设置为“永远”。第二步，如果我们需要对现有的逻辑算法进行改进，就意味着我们需要对历史数据进行重新处理。我们需要做的就是重启一个ApacheKafka作业实例（Instance）。该作业实例将从头开始，重新计算保留的历史数据，并将结果输出到新的数据视图中。我们知道ApacheKafka底层是通过LogOffset来判断现在处理了哪个数据块，所以只需要将LogOffset设置为0，新的作业实例就会从头开始处理历史数据。第三步，当这个新数据视图处理的数据赶上旧数据视图时，我们的应用程序就可以切换到从新数据视图读取。第四步，停止旧版本的作业实例，删除旧的数据视图。与Lambda架构不同，Kappa架构去掉了batch层的架构，只保留了speed层。您只需要在业务逻辑发生变化或代码发生变化时重新处理数据。说完Kappa架构，我想强调一下，Kappa架构也有自己的缺点。由于Kappa架构只保留了速度层，缺少了批处理层，在速度层上处理大规模数据可能会导致数据更新错误，这就需要我们花更多的时间来处理这些错误异常。还有一点就是Kappa架构的批处理和流处理都放在了速度层，导致这个架构使用同一套代码来处理算法逻辑。所以Kappa架构不适合批处理和流处理代码逻辑不一致的场景。总结在这篇文章中，我们简要描述了两种大规模数据处理架构，Lambda架构和Kappa架构，它们各有优缺点。我们需要根据实际情况权衡利弊，看业务需要采用哪种架构。如果你的业务逻辑是设计一个健壮的机器学习模型来预测将要发生的事情，那么你应该优先使用Lambda架构，因为它有一个批处理层和一个速度层来确保更少的错误。如果你面对的业务逻辑对实时性要求很高，客户端根据运行时发生的实时事件进行响应，那么你应该优先使用Kappa架构。
