众所周知，Elasticsearch(ES)是日志分析ELK解决方案的重要一环，也是全文检索的好帮手。实际上，ES在LBS(Location based service)场景也同样好用，结合全文检索、结构化检索与分析，ES基本可以做到实时提供基于地理位置的多种信息。
UCloud Elasticsearch(UES)是基于Elasticsearch和Kibana打造的日志管理分析服务。为支持LBS场景，UCloud(优刻得)已于近日推出UES大内存机型，可支持配置16核64G，其性能可以满足更频繁的位置查询。
UES功能进一步升级
UES通过创建集群的方式来创建服务，集群自动初始化优良配置和丰富插件为用户提供快速创建、易于管理以及线性扩容。此外，UES还提供丰富的性能指标监控和可视化管理平台，高性能SSD磁盘有效提升海量日志数据存储、检索、分析的处理效率。通过本次功能升级，现已全力支持LBS场景。
LBS的应用场景有很多，生活中随处可见，比如社交应用中“附近的人”，或是本地服务应用中“附近的餐厅”等。还有一种不太引人注意的场景是零售行业广告营销中的位置营销(LBA)。LBA与前两种稍有不同，技术实现稍显复杂。下面以查看“附近的餐厅”场景为例，概述ES如何建立地理位置索引，以及如何用ES提供的REST API做位置查询。
(图：搜索当前点500米范围内的餐厅结果)
简单来说，ES在其中的作用分为两步。***步是建立位置索引，存储餐厅经纬度坐标，在客户端用户开始查询时，用ES提供的geo_distance查询出一定距离内所有的餐厅。
本次示例选用UES服务作为基础服务支持，选择内存优化型实例配置，当数据量较大或地理位置查询较频繁时，集群类型可以选择UES提供的“主节点分离”型。
(图：UCloud控制台创建UES集群的界面)
创建mapping
ES支持geo_point和geo_shape两种地理位置数据结构类型。如果想用经纬度坐标表示位置，可以用geo_point字段;如果想存储和查询复杂的地形，可以用geo_shape字段。本次查询“附近的餐厅”应用场景使用geo_point更合适,代码示例如下：
- PUT /index_name
- {
- "mappings": {
- "TYPE_NAME": {
- "properties": {
- "location": {
- "type": "geo_point"
- }
- }
- }
- }
- }
建立索引
location字段被声明为geo_point后，就可以索引包含了经纬度信息的文档了。经纬度信息的形式可以是字符串、数组或者对象。例如，将(经度121.457，纬度31.215)的餐厅坐标点存入索引中，代码示例如下：
- PUT index_name/index_type/1
- {
- "location": {
- "lat": 31.215,
- "lon": 121.457
- }
- }
距离查询
当一个用户在(经度121.453，纬度31.216)的位置查询附近2000米内所有的餐厅时，内部服务可以向ES服务发起geo_distance查询，查询参数包括距离2000米和用户经纬度[121.453, 31.216]。ES服务会返回符合条件的餐厅，本例中会包括上一步中经纬度[121.457, 31.215]的餐厅。
至此就完成了利用UES查询客户端用户附近一定范围内的餐厅需求。在查询期间不需要部署服务，也无需了解地理位置上两点距离的算法，只需向UES发请求即可。本文中讨论的场景也仅是ES服务在地理位置应用(LBS)场景的一个小示例，在实际应用中还有更多地形对比、结合地图SDK的位置聚合等功能，值得继续挖掘。
发现数据更多价值
经过近一年的产品迭代优化，UES在性能表现和功能上更为出色，主要升级点包括：
- 可以做故障自动恢复，无需担心服务不可用;
- 提供了节点升级功能，让用户有多种扩容选择;
- 增加Elasticsearch的6.2.1版本，并全量发布x-pack插件，用户可在控制台一键安装，使用Kibana时更安全，安装后即可在Kibana中看到Elasticsearch服务本身更多监控指标，使用方便;
- 上线海外可用区，为用户业务的出海需求提供更多支持。
目前，UES也接入了UCloud(优刻得)其它数据分析产品，例如用户可以将UES数据备份到UHadoop，保证了数据安全。未来，UES将会接入UKafka等更多UCloud(优刻得)数据分析产品，为用户提供整套数据挖掘、数据分析以及可视化方案。UES可以省去企业部署和维护的成本，从而发现数据的更多价值。
