使用 Apache Spark 提供实时 Web 服务查询

Question

我们有一个用例，我们从数百个数据源下载大量（每天 100 GB）数据，对这些数据进行按摩和处理，然后通过 RESTful API 将这些数据公开给我们的客户。今天，基本数据大小约为。 20TB，预计未来会大幅增长。

对于按摩/处理部分，我们相信 spark 对我们来说是一个非常好的选择。现在，为了通过 API 公开处理/按摩的数据，一种选择是将处理后的数据存储到像 ElephantDB 这样的只读数据库中，并使 Web 服务与 ElephantDB 对话（至少这是 Nathan 在他的大数据书中提出的方式）。我只是想知道我们让 Web 服务实现使用 SparkSQL 来访问来自 Spark 的已处理数据会有什么影响。在这种情况下，架构/设计的危险是什么？

每个人都在谈论 Spark 速度快，以及使用 SparkSQL 进行交互式查询。但是，它是否已经处于通过 SparkSQL 服务大量 Web 服务查询的阶段，我们有非常严格的延迟 SLA 以每秒服务成百上千的 Web 服务请求？如果 Apache Spark 可以处理这个问题，我们就可以避免维护另一个系统，例如 ElephantDB 或 Cassandra 之类的。

想听听这个板上专家的意见。

Answer 1

如果结果存储在文件中，则没有索引，SparkSQL 也不会创建索引。唯一可以稍微快一点的是从 Parquet 文件和缓存表中读取列。

但总的来说，使用 SparkSQL 来处理 Web 请求并不是一个好的用例，因为 Spark 不是为此而生的。

Answer 2

所以您正在批量处理原始数据，是吗？ 理想的方法是将结果存储为键值格式，正如您在 ElephandDB 中提到的那样，而且 Voldemort 项目已被证明非常适合作为只读存储。

我建议您阅读 Nathan Marz 的这篇文章（结合批处理和实时层）：How to beat the CAP theorem

然而，Jay Kreps 在他的文章Questioning the Lambda Architecture 中对此提出了质疑。主要问题（与 lambda 架构有关）是在不同的分布式系统中维护“相同”的系统逻辑以产生相同的结果是有问题的。

但由于您使用的是 Spark，因此您可以使用与 Spark Streaming 相同的逻辑。当 Nathan Marz 和 Jay Kreps 撰写他们的文章时，这并不“在市场上”。

您仍然可以使用 SparkSQL 以交互方式查询原始数据，但由于 Spark 最初是作为计划的批处理作业实现的，因此这不是一个完美的用例。但您可能已经注意到，提交 Spark 作业需要一些时间，这是一种“扼杀”快速查询理念的开销。

请查看 github.com/spark-jobserver/spark-jobserver，作业服务器通过长时间运行的作业上下文支持亚秒级低延迟作业。并且可以在不同作业之间共享 Spark RDD，可以证明对于同一数据集上的不同交互逻辑非常优化。通过 HTTP 请求结合机器学习结果和临时 (SparkSQL) 查询。阅读更多关于 spark 作业服务器的信息，在不同的 Spark 峰会上有一些关于它的在线讨论。