我们有一个用例，我们正在从数百个数据源下载大量(每天100 gb)的数据，对这些数据进行处理，然后通过RESTful API将这些数据公开给我们的客户。目前的基本数据大小约为20TB，预计未来将大幅增长。
对于按摩/加工部分，我们相信spark会是一个很好的选择。现在，为了通过API公开处理过的/经过处理的数据，一种选择是将处理过的数据存储到象ElephantDB这样的只读数据库中，并使web服务与ElephantDB通信(至少Nathan在他的大数据书中是这样建议的)。我只是想知道，如果我们让web服务实现使用SparkSQL来访问Spark处理过的数据，这意味着什么。在这种情况下，架构/设计的危险是什么?
每个人都在谈论Spark的速度很快，以及使用SparkSQL进行交互式查询。但是，是否已经到了通过SparkSQL提供大量web服务查询的阶段，我们对延迟有非常严格的SLA，每秒提供数百甚至数千个web服务请求?如果Apache Spark可以处理这个问题，我们就可以避免维护另一个像ElephantDB或Cassandra之类的系统。
我想听听专家们的意见。
如果结果存储在文件中，则没有索引，而且SparkSQL也不创建索引。唯一可以稍微快一点的是从Parquet文件和缓存表中读取列。
但是一般来说，使用SparkSQL来处理web请求并不是一个好的用例，因为Spark并不是为此而设计的。
那么您正在批量处理原始数据，是吗?理想的方法是将结果存储为键值格式，就像您在ElephandDB中提到的那样，而且项目Voldemort也被证明非常适合作为只读存储。
我建议您阅读Nathan Marz的文章(结合批处理层和实时层):如何击败CAP定理
然而，Jay Kreps在他的文章《质疑Lambda架构》中对此提出了质疑。(lambda架构)的主要问题是，在不同的分布式系统中维护"相同"的系统逻辑以产生相同的结果是有问题的。
但是因为你正在使用Spark，你可以使用Spark Streaming相同的逻辑。当Nathan Marz和Jay Kreps写他们的文章时，它还没有"进入市场"。
您仍然可以使用SparkSQL交互式地查询原始数据，但由于Spark最初是作为调度批处理作业实现的，因此这将不是完美的用例。但是正如你可能已经注意到的那样，提交spark作业需要一些时间，这是一个"扼杀"快速查询想法的开销。
请查看 github.com/spark-jobserver/spark-jobserver，作业服务器通过长时间运行的作业上下文支持亚秒级的低延迟作业。并且可以在不同的作业之间共享Spark rdd，对于同一数据集上不同的交互逻辑，可以被证明是非常优化的。结合机器学习结果和通过HTTP请求的特别(SparkSQL)查询。阅读更多关于spark job-server的信息，在不同的spark峰会上有一些关于它的讨论。