使用 Apache Lucene 和 Solr 进行位置感知搜索

使用 Apache Lucene 和 Solr 进行位置感知搜索 不管是通过支持 GPS 的智能手机查找最近的咖啡馆，还是通过社交站点查找附近 的朋友，或是查看特定城市中运输某种商品的所有货车，越来越多的人和企业都使 用位置感知的搜索服务。创建位置感知搜索服务通常属于昂贵的专用解决的一 部分，并且一般由地理空间专家完成。不过，很流行的开源搜索库 Apache Lucene 和强大的 Lucene 搜索服务器 Apache Solr 最近添加了空间位置功能。 地理位置在空间搜索中至关重要！地理位置不仅在地产中至尊为王，将其用在搜索 中还能帮助位于特定位置的用户快速找到有用的信息。例如，如果您是企业名录提 供商（比如一个 “黄页” 站点），当用户需要找一位水管维修员时，该站点必须返 回在用户住所附近的维修员。如果您运营的是一个旅游站点，那么您必须让旅游者 能够搜索到他们所在的位置附近的名胜，从而帮助他们丰富旅游行程。如果您要构 建一个社交网络站点，那么最好使用位置信息来帮助用户与朋友联系。位置感知设 备（比如汽车导航系统和支持 GPS 的摄像机）和大量免费地图数据的普及为构建能够为终端用户搜索高级结果的 Geographical Information Systems (GIS) 提供了各种机会。 空间信息还可以被利用到搜索领域之外，但在本文中我将主要关注如何通过 Apache Lucene 和 Apache Solr 利用空间信息来改进搜索应用程序。为什么要使用 搜索引擎？并不是因为它是许多很好（甚至免费）的 GIS 工具中的必要组成部分 。不过，将应用程序构建在搜索引擎的基础上能够提供几个强大的功能，这是其他 传统途径无法实现的。搜索系统在合并结构化和非结构化方面非常强劲，这允许用 户输入自由形式的查询，比如在搜索免费文本的描述和标题的同时根据地理位置数 据限制或修改结果。例如，旅游站点可以实现这样一个特性，它让用户能够在一秒 之内找到马萨诸塞州波士顿市的所有 24 小时提供服务并且配有舒适床具的四星级宾馆。有些搜索系统（比如 Apache Solr ）还提供对结果集进行分类、突出显示和拼写检查的功能，从而让应用程序能够帮 助用户高效地查找所需的结果。 我首先简单介绍 Lucene 的一些关键概念，深入的细节留给读者自己探索。接下来 ，我将介绍一些基础的地理空间搜索概念。GIS 是一个广泛的领域，本文难以对其 进行详尽的描述，因此我仅关注一些查找服务、人和其他日常事项所需的基础概念 。本文的末尾是关于使用 Lucene 和 Solr 索引和搜索空间信息的的讨论。我将 通过一个真实但很简单的例子来阐述这些概念，并且使用来自 OpenStreetMap (OSM) 项目的数据。 回顾关键的 Lucene 概念 P 1 / 9 使用 Apache Lucene 和 Solr 进行位置感知搜索 Apache Lucene 是一个基于 Java™ 的高性能搜索库。Apache Solr 是一个使用 Lucene 通过 HTTP 来提供搜索、分类等功能的搜索服务器。它们都使用价格适中的 Apache Software License。 从本质上看，Solr 和 Lucene 都将内容表示为文档。文档由一个或多个字段 和一个表明文档的重要性的可选增强（boost）值 组成。字段由需要索引和储存的实际内容、告诉 Lucene 如何处理该内容的元数据 和表明该字段的重要性的增强值组成。由您决定以何种方式将内容表示为文档和字 段，这取决于您希望怎样搜索或访问文档中的信息。在每个内容单元中，您可以使 用一对一的关系，也可以使用一对多的关系。例如，我可以选择用一个包含几个字 段（比如 title、keywords 和 body）的文档来表示一个 Web 页面。如果是一本书 ，我则选择将它的每一页表示为一个独立的文档。稍后您将看到，这一区分在为搜 索编码空间数据时非常重要。可以为字段中的内容建立索引，或者原样储存供应用 程序使用。如果为内容建立了索引，应用程序就可以使用它。还可以分析建立了索 引的内容来生成词汇（通常称为令牌）。词汇是在搜索过程中查找和使用的基础。 词汇通常是一个词，但这不是必要的。 在查询方面，Lucene 和 Solr 为表达用户查询（从基础的关键字查询到短语和通配 符查询）提供丰富的功能。Lucene 和 Solr 还通过应用一个或多个对空间搜索非常 重要的过滤器来提供限制空间的能力。范围查询 和范围过滤器 是限制空间的关键 机制。在范围查询（或过滤器）中，用户声明需要将所有搜索到的文档限制在使用 自然排序的两个值之间。例如，通常使用范围查询来查找发生在过去一年或上一个 月的所有文档。在处理过程中，Lucene 必须枚举文档中的词汇以识别在范围之内 的所有文档。如我在稍后展示的一样，正确地设置范围查询是提升空间搜索应用程 序的查询性能的关键因素之一。 Lucene 和 Solr 还提供函数查询 的概念，它允许您使用字段的值（比如经度和纬度 ）作为记录机制的一部分，而不是仅仅使用组成主要的记录机制的内部数据集合。 该功能在后文我演示使用 Solr 的一些基于距离的函数时用到。 地理空间搜索概念 在构建空间搜索应用程序时，最重要的是识别需要添加到应用程序中的空间数据。 这些数据通常以某些地理编码的形式出现，比如纬度、经度和海拔，或以邮政编码 或街道地址的形式出现。编码系统的格式越，它在您的系统中的使用就越容易 。例如，民歌 “Over the River and Through the Woods”（其中有这样的歌词：“to Grandmother's house we go”）就将很多空间信息编码到了歌词中。但这些信息在 GIS 系统中就没有多大用 P 2 / 9 使用 Apache Lucene 和 Solr 进行位置感知搜索 处，因为我们不知道小河和森林的位置。该信息与到外婆家的详细方向（包含出发 地址和到达地址的）相比，您将了解到为什么正确编码地址如此重要。（有趣的是 ，能够提取和编码更常用的方向和地理实体 —— 比如渡过小河 或在棕色房子附近 —— 并根据它们进行推断的系统也是非常有用的，但这不属于本文的讨论范围）。 除了用于识别地理位置的原始地理编码数据之外，许多 GIS 系统还可以添加与实 际位置相关的信息。例如，导航系统可以使用在地图上按顺序列出的一系列位置来 创建一条从 A 点到 B 点的路线。或者气象学家可以将降雨或恶劣的天气数据添加 到特定区域的地图上，从而允许用户搜索到特定区域的降雨量。居住地点相邻的人 通常将小的区域合并起来，从而形成 ZIP 编码、地区编码，甚至是城镇、市或州。例如在 OSM 中，用户可以编辑和覆盖地 图顶层的信息，比如旅游景点或街道。通过合并各层的信息建立它们之间的关系并 进行跟踪，可以生成更加动态和强大的应用程序。 表示空间数据 不管与一个或多个位置相关的信息是什么，搜索应用程序都需要通过一种高效的方 式来表示这些数据。尽管可以通过几种方式来表示位置信息，但我仅关注与 Lucene 相关的方式。首先需要注意的是，许多类型的地理空间数据都可以用它们的 “原始” 格式表示，并且能够在搜索应用程序中很好地发挥作用。例如，Syracuse 表示城市 Syracuse 的完美方式，用户只要在搜索栏中输入 Syracuse 就可以找到包含 Syracuse 的所有文档，输入其他搜索关键词也将取得类似的结果 。实际上，原始格式是用于表示带名称的位置，比如城市、州和 ZIP 编码的最常用 方法。不过要注意，尽管我使用了术语原始表示，您仍然可以先对数据进行转换或 格式化。例如，将 New York 转换成 NY 通常是一种合理的做法。 在我介绍 Lucene 能够使用的表示方式之前，您一定要理解所有表示方式都必须考 虑到生成它们的空间引用。在美国，最常见的是 World Geodetic System，它通常缩写为 WGS 84。尽管在某些系统之间允许进行转换，但最好用一 个系统来表示您的所有数据。本文假设使用同一个系统表示数据。 使用 Lucene 和 Solr 进行搜索时，纬度和经度（缩写为 lat/lon）等数字空间信息 的表示方式是最有趣的。纬度和经度通常使用与本初子午线（位于英国的格林威治 ）相距的度、分和秒来表示，并且通常需要使用 double（或更高的精度）来表示。例如，对于我的例子中使用的数据 —— 美国纽约州的 Syracuse 市 —— 它的经度为东经 76.150026（如果没有指定东方，则为 -76.150026）和北纬 43.049648。 P 3 / 9 使用 Apache Lucene 和 Solr 进行位置感知搜索 编码每个纬度和经度可能导致索引大量唯一的词汇，这取决于应用程序。这会显著 减慢搜索速度，并且您将在本文的后面看到，这通常是不必要的。事实上，许多地 图应用程序将搜索与特定领域关联起来，因此储存关于特定区域的适当信息会生成 更少的词汇，并且不对搜索结果产生很大的负面影响。这种在精确度上采取折衷的 方法通常将纬度和经度封装到层中。您可以将每个层看作是地图的特定部分的缩放 级别，比如位于美国中央上方的第 2 层几乎包含了整个北美，而第 19 层可能只是某户人家的后院。尤其是，每个层都将地图分成 2层 # 的箱子或网格。 然后给每个箱子分配一个号码并添加到文档索引中。我将在下一小节解释如何利用 该信息加快搜索速度。 Lucene 词汇中的纬度和经度通常表示为两个不同的字段，但是这在一些应用程序 中可能会影响性能。如果希望使用一个字段，那么可以使用 Geohash 编码方式将纬度/经度编码到一个 String 中。Geohash 的好处是能够通过切去散列 码末尾的字符来实现任意的精度。在许多情况下，相邻的位置通常有相同的前缀。 例如，在 geohash.org 中输入 Syracuse, NY 将生成散列码 dr9ughxjkrt4b，而输入 Syracuse 的郊区 Cicero, NY 生成散列码 dr9veggs4ptd3，它们的前缀都是 dr9。 到目前为止，我只是谈到几个单独的点，但是许多地理空间应用程序在图像、路线 和数据中的其他关系方面都很有趣。 在搜索中将空间数据与文本合并 一旦在索引中添加了数据之后，搜索应用程序在与数据交互时至少有 5 种基本要求： 距离计算：根据给定点计算它到其他点的距离。 限定框过滤器：查找某些特定区域内所有匹配项（文档）。 排序：根据到固定点的距离对搜索结果进行排序。 相关度改进：使用距离作为记录中的增强因素，同时允许其他因素发挥作用。 查询解析：在给出位置的地址或其他一些用户规定时，创建可用于根据索引数据进 行搜索的编码表示。 这 5 个因素都可以在基于位置的应用程序中扮演重要的角色，但是我在这里主要 关注距离计算、限定框过滤和查询解析。排序和相关度改进仅使用距离计算，我将 在本文的后面介绍它们的实际应用。 P 4 / 9 使用 Apache Lucene 和 Solr 进行位置感知搜索 距离计算 当计算用于 GIS 应用程序的距离时，一定要知道有许多不同的实现方法，并且每 种方法都有其优缺点。距离计算可以划分成 3 个组，这取决于应用程序选择以什 么方式对地球进行建模。在一些情况下，完全可以采用平面地球模型，通过牺牲一 些精确性来获取速度。在平面地球模型中，大部分距离计算都是勾股定理的变体。 在其他情况下使用球面模型，所使用的主要距离计算为大圆弧长。大圆弧长计算球 面两点之间的最短距离。当两点之间的距离相隔很远和要求更高的准确度时，需要 使用球面模型。最后，可以使用椭圆的地球模型和 Vincenty 公式来获取高度精确的距离（精确到 0.5 毫米），但是在许多应用程序中用不上这种复杂的模型。 差之毫厘，失之千里 在许多本地搜索应用程序中，精度的需求由应用程序本身决定。在某些情况下，偏 离一公里问题并不大，而在另一些情况下，偏离几毫米就会导致严重的问题。例如 ，欧几里得距离计算对于跨度很长的距离（比如跨州）通常不够精确，即使是半正 矢（大圆）方法也不足以为某些场合提供所需的精度，因为将地球建模成椭圆体比 建模成球体更精确。对于这些情况，使用 Vincenty 公式将得到更加满意的结果。 在其他应用程序中，唯一需要注意的事情是对结果的排序，因此可以使用 Squared Euclidean Distance（实际不是距离），从而避免平方根计算。 当然，其他距离计算也是有用的，比如曼哈顿距离，它反映在由街区组成的城市中 行走的距离（例如在一辆出租车中穿越纽约城的曼哈顿）。但是为了实现本文的目 的，我将使用平面地球模型和大圆弧长距离来演示距离，其他方法留给读者探索。 此外，本文不将海拔作为影响因素，但是一些应用程序可能需要考虑海拔。 限定框过滤器 在许多基于位置的应用程序中，可以搜索到数百万条地址信息。遍历所有这些数据 来查找既包含关键字又在用户指定的距离之内的文档集将需要花费大量时间。一种 合理的做法是先缩小文档集的范围然后再计算相关的子集。如果仅储存了纬度和经 度信息，那么缩小文档集的首选方法是传入包含指定位置的周边区域的范围。这可 以通过 图 1 来表示，其中不完全透明的方框表示包含南卡罗来纳州的查尔斯顿（C harleston）市及其周边地区的限定框： 图 1. 位于 Charleston 中央上方的限定框 P 5 / 9 使用 Apache Lucene 和 Solr 进行位置感知搜索 如果应用程序还使用层信息或 Geohash 信息，那么可以使用这些值来更好地缩小需要搜索的文档的范围。我将在讨论使用 Lucene 和 Solr 建立索引和搜索的细节时演示这点。 查询解析 查询解析的目的是确定查询的哪个部分包含所搜索的关键字，哪个部分包含位置信 息。这个过程的后半部分称为地理编码（geocoding）。尽管我在这里在查询解析 的上下文中讨论地理编码，它在索引期间也非常有用。请考虑下面的用户查询例子 ： 1600 Pennsylvania Ave. Washington, DC 1 Washington Av. Philadelphia Pennsylvania Mall of America, 60 East Broadway Bloomington, MN 55425 Restaurants near Mall of America Restaurants in the Mall of America 查看前两个查询可以发现一些有趣的东西： 词汇的顺序通常很重要，但是在纯文本搜索中，顺序可能不重要。 P 6 / 9 使用 Apache Lucene 和 Solr 进行位置感知搜索 地名表和其他空间资源，比如 GeoNames可能在将地址转换成位置时非常有用。 这些资源通常包含旅游景点的列表 —— 例如，白宫等标志性建筑。 规范化缩写，比如 Ave. 和 DC，或使用同义词来包含用户输入地址信息的各种变体非常重要。 剩余的查询将展示几个微妙的地方。例如，在第三个查询中，用户指定了完整的地 址；如果您要搜索每个字段以获得名称、地址、城市和 ZIP，那么就必须正确地解析这些属性。在最后两个查询中，用户选择 near 还是 in 是非常重要的。与 Mall 的距离在一定范围内的所有饭店都符合第四个查询的用 户，而最后一个查询的用户仅对在 Mall 内部的饭店感兴趣。查询解析可能相差甚 远，因为描述与位置的关系很复杂，更何况还存在拼写错误、语言歧义和不良数据 等。 虽然地理编码很复杂，但是可以使用服务来将地址转换成位置。两种常用的服务为 Google Maps 公共 API 和 GeoNames。不幸的是，使用这些 Web 服务必须遵循使 用条款（通常带有某些限制）和网络流量。对于现实的生产系统，您最好自己实现 这些功能。尽管实现这些功能超出了本文的范围，但一定要记住 GeoNames 数据 和其他许多空间资源是可以完全免费下载的。有了好的资源之后，最好从基础开始 积累（地址、城市和州），然后再添加旅游景点和健壮的异常处理。随着时间的推 移，您的查询记录将能够创建健壮的查询解析器，足以应付用户的各种输入。不管 是什么搜索应用程序，良好的猜测和请求用户证实猜测结果都是好实践，如 图 2 的 Google Maps 截屏所示： 图 2. 在 Google Maps 上的良好猜测和请求用户证实猜测结果 P 7 / 9 使用 Apache Lucene 和 Solr 进行位置感知搜索 对于本文，我将展示使用 GeoNames 服务并具有一些其他特性的基础查询解析器 ，但生成版本的解析器将留给用户实现。至此，您应该具备了足够的背景知识，可 以进入主题了。本文后面的内容将关注如何使用 Lucene 和 Solr 为空间信息建立索引并搜索它们。 安装样例代码 要运行样例代码，您需要安装以下软件： JDK 1.5 或更高版本 Ant 1.7 或更高版本 最新的 Web 浏览器，比如 Firefox 您还需要本文提供的样例代码，它包含 Apache Solr 及其所依赖的软件。遵循以下步骤安装样例代码： P 8 / 9 使用 Apache Lucene 和 Solr 进行位置感知搜索 unzip sample.zip cd geospatial-examples ant install 启动 Solr： ant start-solr（以后要停止 Solr，运行 ant stop-solr） 在浏览器中访问 http://localhost:8983/solr/admin 并确认 Solr 正常运行。您应该看到一个带有查询框的基础管理员界面。 安装好 Solr 并正常运行之后，就可以在 Lucene 中开始处理空间数据了。运行安装步骤将下载一些来自 OSM 项目的样例代码，我在 http://people.apache.org/~gsingers/spatial/ 上介绍了该项目。对于本文，我包含了来自美国的 4 个位置的样例 OSM 数据（在文件中列出了到 OSM 的永久链接）： Syracuse, N.Y. Downtown Minneapolis, Minn. Around the Mall of America in Bloomington, Minn. Downtown Charleston, S.C. 为了演示本文介绍的许多概念，我编写代码来在 Solr 中为 OSM 建立索引，并将一些简单的事实与特定的位置相关联（例如，查看数据目录中的 syracuse.facts 文件）。这样做的目的是展示如何合并非结构化文本和空间数据， 以创建高效的搜索应用程序。此外还要注意，我使用 Solr 1.5-dev 版本（Solr 的当前开发主干），而不是最近发布的 Solr 1.4。 Powered by TCPDF (www.tcpdf.org) P 9 / 9