1.数据聚合
聚合（aggregations）可以让我们极其方便的实现对数据的统计、分析、运算。例如：
什么品牌的手机最受欢迎？
这些手机的平均价格、最高价格、最低价格？
这些手机每月的销售情况如何？
实现这些统计功能的比数据库的sql要方便的多，而且查询速度非常快，可以实现近实时搜索效果。
1.1.聚合的种类
聚合常见的有三类：
桶（Bucket）聚合：用来对文档做分组
TermAggregation：按照文档字段值分组，例如按照品牌值分组、按照国家分组
Date Histogram：按照日期阶梯分组，例如一周为一组，或者一月为一组
度量（Metric）聚合：用以计算一些值，比如：最大值、最小值、平均值等
Avg：求平均值
Max：求最大值
Min：求最小值
Stats：同时求max、min、avg、sum等
管道（pipeline）聚合：其它聚合的结果为基础做聚合
注意：参加聚合的字段必须是keyword、日期、数值、布尔类型
1.2.DSL实现聚合
现在，我们要统计所有数据中的酒店品牌有几种，其实就是按照品牌对数据分组。此时可以根据酒店品牌的名称做聚合，也就是Bucket聚合。
1.2.1.Bucket聚合语法
语法如下：
结果如图：
图片加载失败
1.2.2.聚合结果排序
默认情况下，Bucket聚合会统计Bucket内的文档数量，记为count，并且按照count降序排序。我们可以指定order属性，自定义聚合的排序方式：
1.2.3.限定聚合范围
默认情况下，Bucket聚合是对索引库的所有文档做聚合，但真实场景下，用户会输入搜索条件，因此聚合必须是对搜索结果聚合。那么聚合必须添加限定条件。我们可以限定要聚合的文档范围，只要添加query条件即可：
这次，聚合得到的品牌明显变少了：
1.2.4.Metric聚合语法
上节我们对酒店按照品牌分组，形成了一个个桶。现在我们需要对桶内的酒店做运算，获取每个品牌的用户评分的min、max、avg等值。这就要用到Metric聚合了，例如stat聚合：就可以获取min、max、avg等结果。
注意：嵌套的aggs应该在brandAgg内部，与terms保持平级
语法如下：
这次的score_stats聚合是在brandAgg的聚合内部嵌套的子聚合。因为我们需要在每个桶分别计算。另外，我们还可以给聚合结果做个排序，例如按照每个桶的酒店平均分做排序：
1.2.5.小结
aggs代表聚合，与query同级，此时query的作用是？
限定聚合的的文档范围
聚合必须的三要素：
聚合名称
聚合类型
聚合字段
聚合可配置属性有：
size：指定聚合结果数量
order：指定聚合结果排序方式
field：指定聚合字段
1.3.RestAPI实现聚合
1.3.1.API语法
聚合条件与query条件同级别，因此需要使用request.source()来指定聚合条件。
聚合条件的语法：
聚合的结果也与查询结果不同，API也比较特殊。不过同样是JSON逐层解析：
完整代码如下：
完整映射关系如下：
1.3.2.业务需求
需求：搜索页面的品牌、城市等信息不应该是在页面写死，而是通过聚合索引库中的酒店数据得来的：
图片加载失败
分析：目前，页面的城市列表、星级列表、品牌列表都是写死的，并不会随着搜索结果的变化而变化。但是用户搜索条件改变时，搜索结果会跟着变化。例如：用户搜索“东方明珠”，那搜索的酒店肯定是在上海东方明珠附近，因此，城市只能是上海，此时城市列表中就不应该显示北京、深圳、杭州这些信息了。
也就是说，搜索结果中包含哪些城市，页面就应该列出哪些城市；搜索结果中包含哪些品牌，页面就应该列出哪些品牌。如何得知搜索结果中包含哪些品牌？如何得知搜索结果中包含哪些城市？
使用聚合功能，利用Bucket聚合，对搜索结果中的文档基于品牌分组、基于城市分组，就能得知包含哪些品牌、哪些城市了。因为是对搜索结果聚合，因此聚合是限定范围的聚合，也就是说聚合的限定条件跟搜索文档的条件一致。
查看浏览器可以发现，前端其实已经发出了这样的一个请求：
请求参数与搜索文档的参数完全一致。返回值类型就是页面要展示的最终结果：
结果是一个Map结构：
key是字符串，城市、星级、品牌、价格
value是集合，例如多个城市的名称
1.3.3.业务实现
在cn.itcast.hotel.web包的HotelController中添加一个方法，遵循下面的要求：
请求方式：POST
请求路径：/hotel/filters
请求参数：RequestParams，与搜索文档的参数一致
返回值类型：Map>
代码：
这里调用了IHotelService中的getFilters方法，尚未实现（因此需要定义这个新的接口）。在cn.itcast.hotel.service.IHotelService中定义新接口方法：
在cn.itcast.hotel.service.impl.HotelService中实现该方法：
2.自动补全
当用户在搜索框输入字符时，我们应该提示出与该字符有关的搜索项，如图：
图片加载失败
这种根据用户输入的字母，提示完整词条的功能，就是自动补全了。因为需要根据拼音字母来推断，因此要用到拼音分词功能。
2.1.拼音分词器
要实现根据字母做补全，就必须对文档按照拼音分词。在GitHub上恰好有elasticsearch的拼音分词插件。地址：https://github.com/medcl/elasticsearch-analysis-pinyin。
安装方式与IK分词器一样，分三步：
①解压（课程资料已做，无需在做）
②上传到虚拟机中，elasticsearch的plugin目录
执行下述指令，会发现存储路径： "Mountpoint": "/var/lib/docker/volumes/es-plugins/_data"
将py文件夹整个拖拽进去
③重启elasticsearch：docker restart es
④测试
详细安装步骤可以参考IK分词器的安装过程。测试用法如下：
结果：
2.2.自定义分词器
默认的拼音分词器会将每个汉字单独分为拼音，而我们希望的是每个词条形成一组拼音，需要对拼音分词器做个性化定制，形成自定义分词器。elasticsearch中分词器（analyzer）的组成包含三部分：
character filters：在tokenizer之前对文本进行处理。例如删除字符、替换字符
tokenizer：将文本按照一定的规则切割成词条（term）。例如keyword，就是不分词；还有ik_smart
tokenizer filter：将tokenizer输出的词条做进一步处理。例如大小写转换、同义词处理、拼音处理等
文档分词时会依次由这三部分来处理文档：
声明自定义分词器的语法如下：
测试（测试时候需要加上上述的索引库名称）：
图片加载失败
总结：
如何使用拼音分词器？
①下载pinyin分词器
②解压并放到elasticsearch的plugin目录
③重启即可
如何自定义分词器？
①创建索引库时，在settings中配置，可以包含三部分
②character filter
③tokenizer
④filter
拼音分词器注意事项？
为了避免搜索到同音字，搜索时不要使用拼音分词器
2.3.自动补全查询
elasticsearch提供了Completion Suggester查询来实现自动补全功能。这个查询会匹配以用户输入内容开头的词条并返回。为了提高补全查询的效率，对于文档中字段的类型有一些约束：
参与补全查询的字段必须是completion类型。
字段的内容一般是用来补全的多个词条形成的数组。
比如，一个这样的索引库：
然后插入下面的数据：
查询的DSL语句如下：
2.4.实现酒店搜索框自动补全
现在，我们的hotel索引库还没有设置拼音分词器，需要修改索引库中的配置。但是我们知道索引库是无法修改的，只能删除然后重新创建。另外我们需要添加一个字段，用来做自动补全，将brand、address、city等都放进去，作为自动补全的提示。
因此，总结一下，我们需要做的事情包括：
修改hotel索引库结构，设置自定义拼音分词器
修改索引库的name、all字段，使用自定义分词器
索引库添加一个新字段suggestion，类型为completion类型，使用自定义的分词器
给HotelDoc类添加suggestion字段，内容包含brand、business
重新导入数据到hotel库
2.4.1.修改酒店映射结构
先删除原有的索引库：DELETE /hotel
再创建新的索引库信息，代码如下：
2.4.2.修改HotelDoc实体
HotelDoc中要添加一个字段，用来做自动补全，内容可以是酒店品牌、城市、商圈等信息。按照自动补全字段的要求，最好是这些字段的数组。因此我们在HotelDoc中添加一个suggestion字段，类型为List，然后将brand、city、business等信息放到里面。
代码如下：
2.4.3.重新导入
重新执行之前编写的导入数据功能，可以看到新的酒店数据中包含了suggestion：
图片加载失败
2.4.4.自动补全查询的JavaAPI
之前我们学习了自动补全查询的DSL，而没有学习对应的JavaAPI，这里给出一个示例：
而自动补全的结果也比较特殊，解析的代码如下：
2.4.5.实现搜索框自动补全
查看前端页面，可以发现当我们在输入框键入时，前端会发起ajax请求：
图片加载失败
返回值是补全词条的集合，类型为List
1）在cn.itcast.hotel.web包下的HotelController中添加新接口，接收新的请求：
2）在cn.itcast.hotel.service包下的IhotelService中添加方法：
3）在cn.itcast.hotel.service.impl.HotelService中实现该方法：
3.数据同步
elasticsearch中的酒店数据来自于mysql数据库，因此mysql数据发生改变时，elasticsearch也必须跟着改变，这个就是elasticsearch与mysql之间的数据同步。
3.1.思路分析
常见的数据同步方案有三种：
同步调用
异步通知
监听binlog
3.1.1.同步调用
方案一：同步调用
图片加载失败
基本步骤如下：
hotel-demo对外提供接口，用来修改elasticsearch中的数据
酒店管理服务在完成数据库操作后，直接调用hotel-demo提供的接口，
3.1.2.异步通知
方案二：异步通知
图片加载失败
流程如下：
hotel-admin对mysql数据库数据完成增、删、改后，发送MQ消息
hotel-demo监听MQ，接收到消息后完成elasticsearch数据修改
3.1.3.监听binlog
方案三：监听binlog
流程如下：
给mysql开启binlog功能
mysql完成增、删、改操作都会记录在binlog中
hotel-demo基于canal监听binlog变化，实时更新elasticsearch中的内容
3.1.4.选择
方式一：同步调用
优点：实现简单，粗暴
缺点：业务耦合度高
方式二：异步通知
优点：低耦合，实现难度一般
缺点：依赖mq的可靠性
方式三：监听binlog
优点：完全解除服务间耦合
缺点：开启binlog增加数据库负担、实现复杂度高
3.2.实现数据同步
3.2.1.思路
利用课前资料提供的hotel-admin项目作为酒店管理的微服务。当酒店数据发生增、删、改时，要求对elasticsearch中数据也要完成相同操作。
步骤：
导入课前资料提供的hotel-admin项目，启动并测试酒店数据的CRUD
声明exchange、queue、RoutingKey
在hotel-admin中的增、删、改业务中完成消息发送
在hotel-demo中完成消息监听，并更新elasticsearch中数据
启动并测试数据同步功能
3.2.2.导入demo
导入提供的hotel-admin项目：
hotel-admin.zip
(98 KB)
，运行后，访问 http://localhost:8099
其中包含了酒店的CRUD功能：
如果新增失败，控制台提示的是：
请修改表结构让其主键自增
3.2.3.声明交换机、队列
MQ结构如图：
1）引入依赖
在hotel-admin、hotel-demo中引入rabbitmq的依赖：
引入配置项（注意修改自己的ip等信息）
2）声明队列交换机名称
在hotel-admin和hotel-demo中的cn.itcast.hotel.constatnts包下新建一个类MqConstants：
3）声明队列交换机
在hotel-demo中，定义配置类，声明队列、交换机：
3.2.4.发送MQ消息
发送之前务必确认MQ是否启动（先启动MQ再启动工程，才可以完成队列的注册）
在hotel-admin中的增、删、改业务中分别发送MQ消息：
注意原有的save改成insert，获取里面返回的ID值，用作后续的消息发送
Hotel类的ID生成策略：@TableId(type = IdType.AUTO)
数据库ID需要改成自增
以上三个都完成，才可以实现insert方法有id返回（并非唯一的方法）
启动工程，去浏览器验证一下是否有对应的交换机、队列、及绑定关系
3.2.5.接收MQ消息
hotel-demo接收到MQ消息要做的事情包括：
新增消息：根据传递的hotel的id查询hotel信息，然后新增一条数据到索引库
删除消息：根据传递的hotel的id删除索引库中的一条数据
1）首先在hotel-demo的cn.itcast.hotel.service包下的IHotelService中新增新增、删除业务
2）给hotel-demo中的cn.itcast.hotel.service.impl包下的HotelService中实现业务：
3）编写监听器
在hotel-demo中的cn.itcast.hotel.mq包新增一个类：
3.2.6.结果验证
修改后去kibana控制台可以查看到修改信息
Java
运行代码
复制代码
1
2
3
4
5
6
7
8
9
10
GET /hotel182/_search
{
"query": {
"term": {
"id": {
"value": "2062643521"
}
}
}
}
删除后去kibana查看数据没了（执行上述命令会发现hits中是0）
