除了@karthik manchala提供的答案之外，数据处理可以通过三种方式进行：批处理、交互式处理和实时/流式处理。
我相信，您对实时的引用更多的是交互式响应，而不是流式处理，因为并非所有用例都与流式处理相关。
交互式响应是指可以在任何地方预期响应，从亚秒到几秒到几分钟，这取决于用例。这里的关键是要理解处理是在静态数据上完成的，即已经存储在存储介质上的数据。用户在处理过程中与系统交互，因此等待响应。Hive对tez、 Impala 、spark core等的所有努力都是为了解决这个问题，并尽快做出回应。
另一方面，流式传输是数据流实时进入系统的地方，例如twitter feeds、click streams等，一旦数据生成，就需要进行处理。像storm、spark流媒体这样的框架解决了这个问题。
批处理的例子是为了解决这样的场景：在一个巨大的数据集上，需要先完成一些繁重的工作，这样用户就会相信他看到的响应是实时的。例如，将大量文档集合索引到apachesolr中是一个批处理作业，根据数据集的不同，索引将运行数分钟甚至数小时。但是，查询solr索引的用户将在亚秒的延迟内得到响应。如您所见，索引无法实时实现，因为可能存在大量的数据。google搜索也是如此，索引将以批处理模式进行，结果以交互模式显示。
所有这三种数据处理模式都可能涉及到任何一个应对数据挑战的组织。lambda体系结构有效地解决了这一难题，即为多个数据处理需求使用相同的数据源

您可以查看kappa架构，其中没有单独的批处理层。一切都在流层进行分析。您可以在正确的配置中使用kafka作为主数据集存储，并将计算出的数据保存在数据库中作为您的视图。
如果要重新计算，可以启动一个新的流处理作业，将kafka中的视图重新计算到数据库中，并替换旧视图。可以只使用实时视图作为临时查询的主存储，但正如其他答案中已经提到的那样，如果有大量数据要单独进行批处理和流处理，而不是将批处理作业作为流作业来进行，则速度会更快。这取决于数据的大小。另外，用hdfs这样的存储代替用于批处理计算的数据库也更便宜。
最后一点，在很多情况下，批处理和流处理有不同的算法，所以需要分开进行。但基本上，也可以只使用“实时视图”作为批处理和流层，而不使用kafka作为主集。这取决于你的用例。

为什么选择批处理层
省时省钱！
它基本上有两个功能，
管理主数据集（假定不可变）
预计算批处理视图以进行即席查询
任何东西都可以存储在实时视图中，并从中生成结果-这不是真的
以上当然是可能的，但不可行，因为数据可能是100.1000 PB，生成结果可能需要时间。。很多时间！
这里的关键是在大数据集上实现低延迟查询。批处理层用于创建批处理视图（提供低延迟的查询），实时层用于最近/更新的数据，这些数据通常很小。现在，任何特别的查询都可以通过合并来自批处理视图和实时视图的结果来回答，而不是对所有主数据集进行计算。
另外，考虑一个查询（同一个查询？）在巨大的数据集上反复运行。。浪费时间和金钱！