面对每一种酷毙的新技术，人们很容易过于迷恋其中，开始把它用在不当的地方。比如说：从头到尾浏览数百亿条记录，从中找出几百万条标以一组标准的记录，这是MapReduce或你最喜欢实施的有向无环图(DAG，想一想Spark)相当愚蠢的一种用法。
对于诸如此类的任务，别忘了那项最初的大数据技术：搜索。借助像Solr、Lucidworks和Elasticsearch这些出色的开源工具，你就有了一种有效的方法来优化输入/输出，并实现用户体验个性化。这么做的效果比使用花哨的新工具不当好得多。
Spark不擅长的
不久前，有个客户问我如何使用Spark对他们流式传输到NoSQL数据库的数据进行搜索。问题在于，该客户的使用模式是简单的字符串搜索和向下钻取(drill-down)。这超出了数据库高效处理的能力：他们将不得不从存储系统获取所有数据，然后在内存中加以分析。就算拥有DAG，在AWS上也有点慢(更不用说成本高昂了)。
如果你可以把一个定义的数据集放入内存，Spark是很出色。Spark并不擅长获取全世界的数据，一方面在于在内存中，数据分析的效果完全取决于你将所有数据传输到内存以及购买这种内存的能力。我们仍需要考虑存储，考虑如何组织管理存储，以便能够迅速、利落地获得我们所需的数据。
对于这个特定的客户而言，答案就是为进入的数据编制索引，然后拉回数据子集，用于更高级的机器学习，但是将搜索任务交给搜索索引。
搜索vs机器学习
搜索、机器学习和某些相关技术之间并不存在清晰的界线。很显然，文本或语言信息往往强烈地表明这是搜索问题。数字、二进制或其性质根本不是文本或语言的信息表明这是机器学习(或其他)问题。是存在重叠。甚至在一些情况下，任何一种方法都可以使用，比如异常检测。
一个关键问题是，你从存储系统检索数据时能不能选择合适的数据，以此作为你的一个标准，而不是非得处理大量数据。对于文本或定义的数字数据而言，这可能很简单。同样，人们用于异常检测的那种类型的规则可能同样很适合搜索。
当然，这种方法有其局限性。如果你不知道自己在找什么数据，又无法轻而易举地定义规则，那么很显然搜索并不是合适的工具。
搜索+大数据
在许多情况下，结合使用搜索和Spark或你最喜欢的机器库可能是秘诀。我之前谈论过将搜索添加到Hadoop的方法，不过也有将Spark、Hadoop或机器学习添加到搜索的方法。
Spark方面明朗化之后，使用它的人认识到，它并不是什么灵丹妙药，内存中处理起来确实存在大问题。至于你可以索引的数据，能够迅速拉回工作集来分析，远比使用又大又粗的输入/输出、拉入到内存中找到你要找的数据好得多。
搜索和上下文
但是，搜索不仅仅是你如何解决“找到我的工作集”、内存或输入/输出问题。大多数大数据项目的软肋之一在于缺乏上下文。我之前从安全方面谈论过这个话题，但是用户体验方面又如何?虽然你流式传输你能找到的关于用户的每一个数据，但是如何处理这些数据，以便实现用户体验个性化?
使用你对用户了解的信息(即信号)，就能改善放到用户面前的信息。这可能意味着，你在向用户展示结果或个性化网页时，在用户交互的前端使用流式分析，而在后端使用分面搜索(faceted search)。
搜索解决方案
作为一名数据架构师、工程师、开发者或科学家，你需要的不仅仅是工具库中的一两种工具。我对于这种方法很恼火：“让我们存储一个很大的blog，希望得到***的结果，同时每当我们使用它，就要花钱搜寻。”一些厂商实际上似乎支持这种方法。
使用索引和搜索技术，你就能构成一个更好的工作集。你还可以避免实施基于你的数据流，为提供给用户的数据实现个性化。搜索很好，请使用它。
