对于每一项很酷的新技术，我们都很容易迷恋它并开始将其用于错误的事情。例如：从头到尾遍历数百亿条记录，找到几百万条记录由标准集标记，这是MapReduce或您最喜欢的有向无环图（DAG，认为是Spark）的实现一种相当愚蠢的用法。对于这些任务，不要忘记最初的大数据技术：搜索。借助Solr、Lucidworks和Elasticsearch等出色的开源工具，您可以有效地优化输入/输出并个性化用户体验。这比不正确地使用花哨的新工具要好得多。不久前，一位客户问我如何使用Spark对他们流入NoSQL数据库的数据执行搜索。问题在于该客户的使用模式是简单的字符串搜索和向下钻取。这超出了数据库有效处理的能力：它们将不得不从存储系统中获取所有数据并在内存中进行分析。即使使用DAG，它在AWS上也有点慢（更不用说昂贵了）。如果您可以将定义的数据集装入内存，则Spark非常棒。Spark并不擅长从全世界获取数据。一方面，在内存中，数据分析的效果完全取决于你是否有能力将所有数据都转移到内存中，并购买这块内存。我们仍然需要考虑存储，如何组织和管理存储，以便我们能够快速、干净地获取我们需要的数据。对于这个特定的客户，答案是为传入的数据编制索引，然后拉回数据的一个子集以进行更高级的机器学习，但将搜索卸载到搜索索引。搜索与机器学习搜索、机器学习和一些相关技术之间没有明确的界限。显然，文本或语言信息通常强烈表明这是一个搜索问题。数字、二进制或它们的性质根本不是文本或语言的信息表明这是一个机器学习（或其他）问题。是的，有重叠。甚至在某些情况下可以使用任何一种方法，例如异常检测。一个关键的问题是你是否可以在从存储系统中检索数据时选择正确的数据作为你的标准，而不是必须处理大量的数据。对于文本或定义的数字数据，这可能很简单。同样，人们用于异常检测的规则类型可能同样适用于搜索。当然，这种方法有其局限性。如果您不知道要查找的数据是什么，并且无法轻松定义规则，那么搜索显然不是适合您的工具。搜索+大数据在许多情况下，将搜索与Spark或您最喜欢的机器库结合使用可能是秘诀。之前讲过在Hadoop中加入搜索的方法，其实也有在Spark、Hadoop或者机器学习中加入搜索的方法。Spark搞清楚之后，用过的人才发现它不是万能的，在内存处理上确实存在很大的问题。就您可以索引的数据而言，能够快速拉回工作集进行分析远比使用大而胖的I/O并将其拉入内存以查找您要查找的数据要好得多。搜索和上下文但是搜索不仅仅是解决“查找我的工作集”、内存或I/O问题的方式。大多数大数据项目的弱点之一是缺乏上下文。我之前从安全方面谈过这个，但是用户体验方面呢？当您流式传输您可以找到的关于用户的所有数据时，您如何处理这些数据以便个性化用户体验？使用您的用户体验了解信息（即信号），可以改善摆在用户面前的信息。这可能意味着在向用户呈现结果或个性化网页时，在用户交互的前端使用流分析，在后端使用分面搜索。搜索解决方案作为数据架构师、工程师、开发人员或科学家，您的武器库中需要的不仅仅是一两个工具。我对这种做法感到恼火：“让我们存储一个大博客，希望得到最好的结果，每次我们使用它时都要花钱搜索。”一些供应商实际上似乎支持这种方法。使用索引和搜索技术，您可以形成更好的工作集。您还可以避免根据您的数据流对提供给用户的数据实施个性化。搜索很棒，使用它。
