189 8069 5689
尽管Hadoop、Spark和NoSQL数据库现在正发展的如火如荼，但请不要忘记搜索是最原始，最有用的大数据技术之一。随着很多非常棒的开源工具比如Solr，Lucidworks以及Elasticsearch的出现，你可以使用非常强大的方法优化I/O以及个性化用户体验，它会比以错误结束的纷繁复杂的新工具要好得多。
Spark缺陷
不久前，一个客户问我，如何使用spark查遍所有涌入NoSQL数据库的大批量数据。问题在于，他们的搜索模式是单一的字符串搜索和向下查询，这已经超出了数据库的有效能力范围。他们从存储中拉取数据并在内存中解析。即便AWS上有DAG，但还是很慢，更不用提昂贵的价格了。
当你在内存中处理意义明确的数据集时，Spark还是很有帮助的，不仅在于其强大的吸收能力，更是因为其在内存中的分析能力和转移到内存中的能力一样强大。我们仍然需要考虑存储并且要知道如何做才能达到我们想要的快速简洁的效果。对于某些客户来说，数据进来之后可能会拉取出某个集合用于机器学习，把搜索工作留给搜索引擎完成。
搜索与机器学习
其实，在搜索，机器学习和其他相关技术之间，不存在明显的界限。显然，文本或语言信息往往可以很强烈的反映出搜索问题，不管是数值型还是二进制，非文本或语言都可以很自然的表明问题所在。在这方面，这些技术是重叠的。在某些方面，这些技术的处理方式甚至很类似，比如异常检测，任何一个技术都可以有效地解决该问题。
关键的问题在于当你把部分内存作为标准进行检索时，能否挑选出正确的数据，而不必浏览所有数据。对文本或定义明确的数值型数据来说是比较简单的。其次，异常检测机制可能也会自己进行搜索，当然这种方法也有其局限性，如果你不知道你需要什么，或不能明确定义规则，搜索显然就不是合适的工具了。
搜索加大数据
在许多情况中，使用Spark加搜索或者机器学习的方法都不错，之前也有讲过在Hadoop中添加搜索的方法，但其实这也同样适用于Spark或机器学习。
当Spark趋于稳定之后，用户忽然意识到Spark并没有那么神奇，实际在内存中运行时也存在很多问题，数据可以进行搜索，拉取工作集分析的速度远比使用笨重的I/O去内存中寻找想要的数据要快得多。
搜索和上下文
搜索并不仅仅是解决工作集，内存或I/O问题，大多数大数据项目的弱点之一是缺少上下文环境，关于安全问题已经讲过了，那用户体验如何呢?尽管你可以发现很多用户数据，但你如何个性化用户体验呢?使用你所知道的一切用户信息，可以提高呈现在用户面前的数据质量，这可能意味着当你向用户呈现个性化页面时，前端的用户交互和后端的搜索需要使用流分析搞定。搜索解决方案作为数据架构师，工程师，开发者或者是科学家，在搜索方案上，你至少需要一到两个选择。我最不喜欢的方法就是，内存搞得特别大，然后希望每次分类都可以使用它，一些供应商似乎非常喜欢这种方式。
使用索引和搜索技术可以构建更好的工作空间，还可以避免机器学习或分析以及简单的从存储中通过某种标准选择数据——甚至通过某些标志，基于数据流对用户数据进行个性化。从中可以看出，搜索是非常不错的选择，值得一用!