尽管Hadoop、Spark和NoSQL数据库现在正发展的如火如荼，但请不要忘记搜索是最原始，最有用的大数据技术之一。随着很多非常棒的开源工具比如Solr，Lucidworks以及Elasticsearch的出现，你可以使用非常强大的方法优化I/O以及个性化用户体验，它会比以错误结束的纷繁复杂的新工具要好得多。

 

Spark缺陷

 

不久前，一个客户问我，如何使用spark查遍所有涌入NoSQL数据库的大批量数据。问题在于，他们的搜索模式是单一的字符串搜索和向下查询，这已经超出了数据库的有效能力范围。他们从存储中拉取数据并在内存中解析。即便AWS上有DAG，但还是很慢，更不用提昂贵的价格了。

 

当你在内存中处理意义明确的数据集时，Spark还是很有帮助的，不仅在于其强大的吸收能力，更是因为其在内存中的分析能力和转移到内存中的能力一样强大。我们仍然需要考虑存储并且要知道如何做才能达到我们想要的快速简洁的效果。对于某些客户来说，数据进来之后可能会拉取出某个集合用于机器学习，把搜索工作留给搜索引擎完成。

 

搜索与机器学习

 

其实，在搜索，机器学习和其他相关技术之间，不存在明显的界限。显然，文本或语言信息往往可以很强烈的反映出搜索问题，不管是数值型还是二进制，非文本或语言都可以很自然的表明问题所在。在这方面，这些技术是重叠的。在某些方面，这些技术的处理方式甚至很类似，比如异常检测，任何一个技术都可以有效地解决该问题。

 

关键的问题在于当你把部分内存作为标准进行检索时，能否挑选出正确的数据，而不必浏览所有数据。对文本或定义明确的数值型数据来说是比较简单的。其次，异常检测机制可能也会自己进行搜索，当然这种方法也有其局限性，如果你不知道你需要什么，或不能明确定义规则，搜索显然就不是合适的工具了。

 

搜索加大数据

 

在许多情况中，使用Spark加搜索或者机器学习的方法都不错，之前也有讲过在Hadoop中添加搜索的方法，但其实这也同样适用于Spark或机器学习。

 

当Spark趋于稳定之后，用户忽然意识到Spark并没有那么神奇，实际在内存中运行时也存在很多问题，数据可以进行搜索，拉取工作集分析的速度远比使用笨重的I/O去内存中寻找想要的数据要快得多。