Lambda 架构 - 为什么选择批处理层

Question

我正在浏览 lambda 架构并了解如何使用它来构建容错大数据系统。

我想知道当所有内容都可以存储在实时视图中并从中生成结果时，批处理层有什么用处？是不是因为实时存储不能用于存储所有数据，所以它不会是实时的，因为检索数据所花费的时间取决于数据存储所占用的空间。

Answer 1

为什么是批处理层

为了节省时间和金钱！

它基本上有两个功能，

• 管理主数据集（假设是不可变的）
• 预先计算用于临时查询的批处理视图

所有内容都可以存储在实时视图中并从中生成结果 - 不正确

以上当然是可能的，但不可行，因为数据可能是 100 到 1000 PB 并且生成结果可能需要时间……很多时间！

这里的关键是实现对大型数据集的低延迟查询。批处理层用于创建批处理视图（以低延迟服务的查询），实时层用于通常很小的最近/更新数据。现在，可以通过合并来自批处理视图和实时视图的结果来回答任何临时查询，而不是计算所有主数据集。

另外，想想一个查询（相同的查询？）在庞大的数据集上一次又一次地运行......浪费时间和金钱！

Answer 2

在@karthik manchala 提供的答案的基础上，可以通过三种方式处理数据处理 - 批处理、交互式和实时/流式处理。

我相信，您对实时的提及更多的是交互式响应，而不是流式传输，因为并非所有用例都与流式传输相关。

交互式响应是指响应可以在亚秒到几秒到几分钟之间的任何地方进行，具体取决于用例。这里的关键是要了解处理是在静态数据上完成的，即已经存储在存储介质上的数据。用户在处理时与系统交互，因此等待响应。 Hive 在 Tez、Impala、Spark core 等上所做的所有努力都是为了解决这个问题并尽快做出响应。

另一方面，流式传输是数据实时流入系统的地方 - 例如 Twitter 提要、点击流等，并且需要在生成数据后立即进行处理。 Storm、Spark Streaming 等框架解决了这一问题。

批处理的情况是解决需要事先在庞大的数据集上完成一些繁重的工作的场景，以便让用户相信他看到的响应是实时的。例如，将大量文档索引到 Apache Solr 是一个批处理作业，其中索引将运行几分钟或可能几小时，具体取决于数据集。但是，查询 Solr 索引的用户将在亚秒级延迟内获得响应。如您所见，索引无法实时实现，因为可能存在大量数据。谷歌搜索也是如此，索引将以批处理模式完成，结果以交互模式呈现。

所有这三种数据处理模式都可能涉及任何应对数据挑战的组织。 Lambda 架构有效地解决了这一挑战，将相同的数据源用于多种数据处理要求

Answer 3

您可以查看没有单独批处理层的 Kappa 架构。 一切都在流层中进行分析。您可以在正确的配置中将 Kafka 用作主数据集存储，并将计算数据保存在数据库中作为您的视图。

如果你想重新计算，你可以开始一个新的流处理作业，将你的视图从 Kafka 重新计算到你的数据库中，并替换你的旧视图。 可以仅使用实时视图作为临时查询的主要存储，但正如其他答案中已经提到的那样，如果您有大量数据要单独进行批处理和流处理而不是批处理作业，则速度会更快作为流作业。这取决于您的数据大小。 此外，使用 hdfs 之类的存储而不是用于批量计算的数据库更便宜。

最后一点，在许多情况下，批处理和流处理的算法不同，因此需要分开处理。但基本上也可以只使用“实时视图”作为批处理和流层，而不使用 Kafka 作为主集。这取决于您的用例。