是时候用 ES 拯救发际线啦

构建Elasticsearch专家Bot的详细步骤指南

构建Elasticsearch专家Bot的详细步骤指南

步骤1: 文档搜集

  • 利用专业工具搜集Elasticsearch 8.13.2版本的官方文档,确保文档的完整性和准确性。如:Elasticsearch文档

步骤2: 知识库建立

  • 在coze.cn平台上创建一个专门的知识库,命名清晰,便于管理和识别。

步骤3: 文档上传

  • 将搜集到的Elasticsearch文档上传至新创建的知识库,确保文档格式适合后续的检索和分析。

步骤4: Bot创建

  • 在coze.cn上创建一个新的Bot,命名为“Elasticsearch专家”,为其设定一个专业且引人注目的形象。

步骤5: 知识库配置

  • 将步骤2中的知识库与新创建的Bot进行关联,确保Bot能够访问和利用这些文档资源。

步骤6: 功能插件集成

  • 为Bot添加以下功能插件,以提供更全面的服务:
    • 必应搜索引擎(Bing Web Search):扩展信息检索范围。
    • 代码执行器(CodeRunner):实现代码的即时测试与验证。
    • 微信搜索(WeChat Search):增加中文信息源的覆盖。

步骤7: 人设与回复逻辑定制

  • 设定Bot的人设,明确其专业领域和能力,如:“我是Elasticsearch的专家,随时准备解答你的疑问。”
  • 利用coze平台的AI技术,优化Bot的回复逻辑,确保其回答既准确又具有针对性。

步骤8: 测试与调整

  • 在Bot设置完成后,进行全面的测试,确保其能够正确理解和回应各种查询。
  • 根据测试反馈,调整Bot的交互逻辑和回答内容,以提高用户满意度。

步骤9: 发布与分享

  • 完成所有设置和测试后,点击发布,使Bot正式上线。
  • 通过Bot页面的商店功能,将你的“Elasticsearch专家”Bot分享给你的伙伴们,让他们也能享受到这一强大的学习工具。

步骤10: 持续优化与更新

  • 定期回顾Bot的表现,根据用户反馈进行持续的优化和功能更新。
  • 随着Elasticsearch版本的迭代,及时更新知识库内容,确保Bot提供的信息始终最新。

通过遵循这些步骤,你不仅能够构建一个功能全面的Elasticsearch专家Bot,而且能够确保它随着时间的推移不断进化,满足用户日益增长的需求。这将是一个不仅能提供文档查询,还能执行代码和搜索网络的智能助手,极大地提升你的Elasticsearch学习之旅。

继续阅读 »

构建Elasticsearch专家Bot的详细步骤指南

步骤1: 文档搜集

  • 利用专业工具搜集Elasticsearch 8.13.2版本的官方文档,确保文档的完整性和准确性。如:Elasticsearch文档

步骤2: 知识库建立

  • 在coze.cn平台上创建一个专门的知识库,命名清晰,便于管理和识别。

步骤3: 文档上传

  • 将搜集到的Elasticsearch文档上传至新创建的知识库,确保文档格式适合后续的检索和分析。

步骤4: Bot创建

  • 在coze.cn上创建一个新的Bot,命名为“Elasticsearch专家”,为其设定一个专业且引人注目的形象。

步骤5: 知识库配置

  • 将步骤2中的知识库与新创建的Bot进行关联,确保Bot能够访问和利用这些文档资源。

步骤6: 功能插件集成

  • 为Bot添加以下功能插件,以提供更全面的服务:
    • 必应搜索引擎(Bing Web Search):扩展信息检索范围。
    • 代码执行器(CodeRunner):实现代码的即时测试与验证。
    • 微信搜索(WeChat Search):增加中文信息源的覆盖。

步骤7: 人设与回复逻辑定制

  • 设定Bot的人设,明确其专业领域和能力,如:“我是Elasticsearch的专家,随时准备解答你的疑问。”
  • 利用coze平台的AI技术,优化Bot的回复逻辑,确保其回答既准确又具有针对性。

步骤8: 测试与调整

  • 在Bot设置完成后,进行全面的测试,确保其能够正确理解和回应各种查询。
  • 根据测试反馈,调整Bot的交互逻辑和回答内容,以提高用户满意度。

步骤9: 发布与分享

  • 完成所有设置和测试后,点击发布,使Bot正式上线。
  • 通过Bot页面的商店功能,将你的“Elasticsearch专家”Bot分享给你的伙伴们,让他们也能享受到这一强大的学习工具。

步骤10: 持续优化与更新

  • 定期回顾Bot的表现,根据用户反馈进行持续的优化和功能更新。
  • 随着Elasticsearch版本的迭代,及时更新知识库内容,确保Bot提供的信息始终最新。

通过遵循这些步骤,你不仅能够构建一个功能全面的Elasticsearch专家Bot,而且能够确保它随着时间的推移不断进化,满足用户日益增长的需求。这将是一个不仅能提供文档查询,还能执行代码和搜索网络的智能助手,极大地提升你的Elasticsearch学习之旅。

收起阅读 »

极限网关助力好未来 Elasticsearch 容器化升级

极限网关在好未来的最佳实践案例,轻松扛住日增百 TB 数据的流量,助力 ES 从物理机到云原生架构的改造,实现了流控、请求分析、安全管理、无缝迁移等场景。一次完美的客户体验~

背景

物理机架构时代

2022 年,好未来整个日志 Elasticsearch 拥有数十套服务集群,几百台物理机。这么多台机器耗费成本非常高,而且还要花费很大精力去维护。在人力资源有限情况下,存在非常多的弊端,运行成本高,不仅是机器折旧还有机柜等费用。

流量特征

这是来自某个业务线,如下图 1,真实流量,潮汐性非常明显。好未来有很多条业务线,几乎跟这个趋势都一致的,除了个别业务有“续报”、“开课”等活动特殊情况。潮汐性带来的问题就是高峰期 CPU、内存资源是可以消耗很高;低峰期资源使用量非常低,由于是物理架构,这些资源无法给其他业务线共享。

图1

图1

降本增效-容器化改造原动力

日志服务对成本的空前的压力促使我们推进 Elasticsearch 进行架构改造;如何改造,改造成什么样子,这两个问题一直是推进改造原动力。业界能够同时对水平扩展和垂直扩展就是 K8S,我们开始对 Elasticsearch 改造成能在 K8S 上运行进行探索,从而提升 CPU、内存利用率。

物理机时代,没办法把资源动态的扩缩,动态调配,资源隔离,单靠人力操作调度成本太高,几乎无法完成;集群对内存资源需求要比 CPU 资源大很多,由于机器型号配置是固定的,无法“定制”,这也会导致成本居高不下。所以,无论从那个方面来讲,容器化优势非常明显,既能够优化成本,也能够降低运维复杂度。

ES 容器化改造

进行架构升级重点难点- API 服务

改造过程,我们遇到了很多问题,比如容器 ES 版本和物理机 ES 版本不一致,如何让 ES API 能够兼容不同的 ES 版本,由于版本的不兼容,导致无法直接使用原有的 tribenode 进行服务,怎么提供一个高可用的 Elasticsearch API 服务。我们考虑到多个方面,比如使用官方推荐的 proxy 模式、第三方服务等进行选择,经过多方面对比,选择了极限网关 进行 tribenode 替换。

原始 ES API 服务痛点

  • API 访问没有流量控制
  • 可观测性差,而且稳定性一般
  • 版本兼容性差

物理机时代 API 架构

在物理机时代 ES 集群,API 架构如图 2,可以明显看到 tribe node 对所有 ES 集群的“侵入性”是非常大的,这就带来了很多问题,比较严重的就是单个集群对 ES tribenode 的影响和版本升级带来的不兼容问题。

图2

图2

混合时代 API 架构

通过图 3,我们可以看到,极限网关对于版本兼容性很好,能够适配不同的版本。因此,最终选择极限网关作为下一代 ES API 服务方。

图3

图3

里程碑:全部 ES 集群容器化

在 2023 年 3 月份,通过 Elastic 官方 ECK 模式,完成全部日志 ES 集群容器化改造,拥有数百节点,1PB+ 数据存储,每日新增数据 100T 左右。紧接着,除了日志服务外,同时支持了好未来多条业务线。

图4

图4

极限网关实践

下面主要讲述了,为什么选择极限网关,以及极限网关在好未来落地、应用这些内容。

为什么选择极限网关?

学习成本低

我们可以从文档中看到极限网关,其架构简洁,语法简单,直观易懂。学习成本比较低,上手非常快,对新手友好。

性能强悍

经过压测,发现极限网关速度非常快,且针对 Elasticsearch 做了非常细致的优化,能成倍提升写入和查询的速度。

安全性高

支持多种认证方式,最简单的账号密码认证,可以给自定义多个账户密码,大大简化了 Elasticsearch 的安全设置,同时,还可以支持 LDAP 安全验证。

跨版本支持

我们容器化改造过程需要兼容不同版本的 Elasticsrearch,极限网关针对不同的 Elasticsearch 版本做了兼容和针对性处理,能够让业务代码无缝的进行适配,后端 Elasticsearch 集群版本升级能够做到无缝过渡,降低版本升级和数据迁移的复杂度,非常匹配我们的业务场景。

灵活可扩展

可灵活对每个请求进行干预和路由,支持路由的智能学习,内置丰富的过滤器,通过配置动态修改每个请求的处理逻辑,也支持通过插件来进行扩展,满足我们对流量的控制,尤其是限流、用户、IP 等这些功能非常实用。

启用安全策略-为 API 服务保驾护航

痛点

在升级之前使用 tribe 作为 API 服务提供后端,几乎相当于裸奔,没有任何认证策略;另外,tribe 本身的稳定性也有问题,官方在新版本逐渐废弃这种 CCS(跨集群搜索),期间出现多次服务崩溃。

极限网关解决问题

极限网关通过,“basic_auth” 插件,提供最基本的安全校验,使用起来非常方便;同时,极限网关提供 LDAP 插件,可以接入公共的 LDAP 服务,对所有的访问用户进行校验,安全策略对所有的用户生效,不用担心因为 IP 问题泄漏数据等。

强大的过滤功能

在使用 ES 集群过程中,许多场景,需要对请求进行控制、限制等操作。在这方便,感受到了极限网关强大的产品力。比如下面的两个场景

对异常流量进行限流

  • 支持对 IP 限流
  • 支持对 hostname 限流
  • 支持 header 限流

对异常用户进行封禁

当 Elasticsearch 是通过 Basic Auth 或者 LDAP 方式来进行身份认证的时候,request_user_filter 过滤器可用来按请求的用户名信息来进行过滤。操作起来也非常简单,只需要 request_user_filter 这一个过滤器。

- request_user_filter:
    include:
        - "elastic"
    exclude:
        - "Ryan"

总结来讲,主要有这些方面的功能:

图5

图5

优秀的可观测性

痛点

改造前经常为看不到直观的数据指标感到头疼,查看指标需要多个地方同时打开,去筛选,查找,非常繁琐,付出的成本非常大。为此,大家都再考虑如何优化这种情况,无奈优先级比较低,一直没有真正的投入时间去优化这块。

完美解决

使用了极限网关,通过收集请求日志,非常清晰的收集到想要的数据,具体如下:

  • 总体方面:
    • 流量曲线
    • 状态码占比
    • 缓存统计
    • 每台网关请求流量
  • 细节方面:
    • 打印每次请求语句
    • 可以查看请求到具体 ES 节点流量
    • 可以查看过滤器的列表

通过下图,我们可以从管理视角直观的看到各种信息,这对于管理员来讲,省时省力,方便快捷。

图6

图6

意外收获:无缝迁移业务 Elasticsearch 上云

由于前期日志业务上云,受到非常好的反馈,多个业务线期望能够上云上服务,达到降本增效的目的。

支持双写

数据可以通过极限网关同时写入两个 ES 集群,能够保障数据完全一致,安全可靠。

无缝切换

切换很丝滑,影响非常小,能够让外界几乎感受不到服务波动。

图7

图7

通过使用极限网关,自建 ES 集群可以无缝的迁移上云,在整个迁移的过程中,两套集群通过网关进行了解耦,在迁移的过程中还能实现版本的无缝升级,极大降低了迁移成本,提高迁移效率,多次验证服务稳定可靠。

极限网关流量概览

这是其中一套极限网关的流量统计。用这部分数据进行巡检,一目了然,做到全局的掌控,提高感知力度。

图8

图8

极限网关使用总结

极限网关提供一系列高性能和高可靠性的网关服务。使用这样的服务给我们带来以下好处:

  1. 可观测性好:极限网关可以动态的对 Elasticsearch 运行过程中请求进行拦截和分析,通过指标和日志来了解集群运行状态,这些指标可以用于提升性能和业务优化。
  2. 增强安全性:包含先进的安全机制,如 basicauth、LDAP 等支持,保护用户数据不受未授权访问和各种网络威胁的侵害。
  3. 高稳定性:通过冗余设计和故障转移机制,极限网关能够确保网络服务的高可用性,即使在某些组件发生故障时也能保持服务不中断,单版本最长服务超过 15 个月。
  4. 易于管理:通过提供 INFINI Console 简洁直观的管理界面,让用户能够轻松配置和监控网络状态,提升管理效率。
  5. 客户支持:良好的客户服务支持可以帮助用户快速解决使用过程中遇到的问题,提供专业的技术指导。

综上所述,极限网关为用户提供了一个高速、安全、稳定且易于管理的 ES 网关,适合对网络性能有较高要求的个人和企业用户。

未来规划

第一阶段,完成了日志 ES 集群,所有集群的容器化改造,合并,成功的把成本降低了 60%以上。这期间积累了丰富容器化经验,为业务 ES 集群上容器做了良好的铺垫;成本优势和运维优势吸引越来越多的业务接入到容器化 ES 集群。

提升 ES 集群效能--新技术应用&&版本升级

  • 极限科技官方推荐的 Easysearch 在压缩率,查询速度等等方面有很多的优势,通过长时间的测试稳定性,新特性,对比云原生的 ES 集群,根据测试结果,给“客户”提供多种选择,这也是工作重点之一。
  • 我们当前使用的 ES 版本是 6.8,已经远远落后于官方版本,今年我们计划在选择合适的集群升级 ES 版本,拥抱更多官方提供的特性。

混合(多)云架构支持

随着越来越多的 ES 集群在机房的 K8S 集群部署,这里资源出现了紧张局面。 我们尝试在云上部署自建 ES 集群,弥补机房资源有限,无法大规模扩容,同时能够支持多活场景,满足更多客户的不同需求。混合云主要实现以下几种能力:

1、扩缩容:满足不同业务灵活适配

混合(多)云部署,可以让负载内部私有云 ES,同时部署到公有云,提升扩展 IT 基础设施不仅局限于 CPU、内存,还有存储。比如某一个业务要做活动,预估流量“大爆发”,需要提前准备大规模资源,在机房内根本来不及采购扩容支持,然而在公有云上就能很方便扩容、缩容。在云上搭建 ES 集群,设置满足需求的数量、容量、配置,配合极限网关路由策略,精准的把控流量流向。

图9

图9

2、灾备:紧急情况快速部署,恢复 ES 集群读写

当机房级别大规模故障,部分业务实现了多活,单一的机房故障不会影响其服务能力,而此时比如日志查看等仍有需求,为了满足这部分“客户”需求,可以在云上 K8S 集群,快速搭建 ES 集群,恢复日志读写功能。

图10

图10

参考文档:

作者:张华勋,前新浪 CDN 研发,工作主要涉及 Mysql、MongoDB、Redis、Elasticsearch、流量调度等组件和系统,以及运维自动化、平台化等工作。现就职于好未来。

关于好未来

好未来(NYSE:TAL)是一家以内容能力与科技能力为基础,以科教、科创、科普为战略方向,助力人的终身成长,并持续探索创新的科技公司。 好未来的前身学而思成立于 2003 年,2010 年在美国纽交所正式挂牌交易。好未来以“爱与科技助力终身成长”为使命,致力成为持续创新的组织。更多参见:https://www.100tal.com/

关于极限科技(INFINI Labs)

INFINI Labs

极限科技,全称极限数据(北京)科技有限公司,是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室(INFINI Labs)致力于打造极致易用的数据探索与分析体验。

极限科技是一支年轻的团队,采用天然分布式的方式来进行远程协作,员工分布在全球各地,希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选,为中国技术品牌输出添砖加瓦。

官网:https://www.infinilabs.cn

联系我们

继续阅读 »

极限网关在好未来的最佳实践案例,轻松扛住日增百 TB 数据的流量,助力 ES 从物理机到云原生架构的改造,实现了流控、请求分析、安全管理、无缝迁移等场景。一次完美的客户体验~

背景

物理机架构时代

2022 年,好未来整个日志 Elasticsearch 拥有数十套服务集群,几百台物理机。这么多台机器耗费成本非常高,而且还要花费很大精力去维护。在人力资源有限情况下,存在非常多的弊端,运行成本高,不仅是机器折旧还有机柜等费用。

流量特征

这是来自某个业务线,如下图 1,真实流量,潮汐性非常明显。好未来有很多条业务线,几乎跟这个趋势都一致的,除了个别业务有“续报”、“开课”等活动特殊情况。潮汐性带来的问题就是高峰期 CPU、内存资源是可以消耗很高;低峰期资源使用量非常低,由于是物理架构,这些资源无法给其他业务线共享。

图1

图1

降本增效-容器化改造原动力

日志服务对成本的空前的压力促使我们推进 Elasticsearch 进行架构改造;如何改造,改造成什么样子,这两个问题一直是推进改造原动力。业界能够同时对水平扩展和垂直扩展就是 K8S,我们开始对 Elasticsearch 改造成能在 K8S 上运行进行探索,从而提升 CPU、内存利用率。

物理机时代,没办法把资源动态的扩缩,动态调配,资源隔离,单靠人力操作调度成本太高,几乎无法完成;集群对内存资源需求要比 CPU 资源大很多,由于机器型号配置是固定的,无法“定制”,这也会导致成本居高不下。所以,无论从那个方面来讲,容器化优势非常明显,既能够优化成本,也能够降低运维复杂度。

ES 容器化改造

进行架构升级重点难点- API 服务

改造过程,我们遇到了很多问题,比如容器 ES 版本和物理机 ES 版本不一致,如何让 ES API 能够兼容不同的 ES 版本,由于版本的不兼容,导致无法直接使用原有的 tribenode 进行服务,怎么提供一个高可用的 Elasticsearch API 服务。我们考虑到多个方面,比如使用官方推荐的 proxy 模式、第三方服务等进行选择,经过多方面对比,选择了极限网关 进行 tribenode 替换。

原始 ES API 服务痛点

  • API 访问没有流量控制
  • 可观测性差,而且稳定性一般
  • 版本兼容性差

物理机时代 API 架构

在物理机时代 ES 集群,API 架构如图 2,可以明显看到 tribe node 对所有 ES 集群的“侵入性”是非常大的,这就带来了很多问题,比较严重的就是单个集群对 ES tribenode 的影响和版本升级带来的不兼容问题。

图2

图2

混合时代 API 架构

通过图 3,我们可以看到,极限网关对于版本兼容性很好,能够适配不同的版本。因此,最终选择极限网关作为下一代 ES API 服务方。

图3

图3

里程碑:全部 ES 集群容器化

在 2023 年 3 月份,通过 Elastic 官方 ECK 模式,完成全部日志 ES 集群容器化改造,拥有数百节点,1PB+ 数据存储,每日新增数据 100T 左右。紧接着,除了日志服务外,同时支持了好未来多条业务线。

图4

图4

极限网关实践

下面主要讲述了,为什么选择极限网关,以及极限网关在好未来落地、应用这些内容。

为什么选择极限网关?

学习成本低

我们可以从文档中看到极限网关,其架构简洁,语法简单,直观易懂。学习成本比较低,上手非常快,对新手友好。

性能强悍

经过压测,发现极限网关速度非常快,且针对 Elasticsearch 做了非常细致的优化,能成倍提升写入和查询的速度。

安全性高

支持多种认证方式,最简单的账号密码认证,可以给自定义多个账户密码,大大简化了 Elasticsearch 的安全设置,同时,还可以支持 LDAP 安全验证。

跨版本支持

我们容器化改造过程需要兼容不同版本的 Elasticsrearch,极限网关针对不同的 Elasticsearch 版本做了兼容和针对性处理,能够让业务代码无缝的进行适配,后端 Elasticsearch 集群版本升级能够做到无缝过渡,降低版本升级和数据迁移的复杂度,非常匹配我们的业务场景。

灵活可扩展

可灵活对每个请求进行干预和路由,支持路由的智能学习,内置丰富的过滤器,通过配置动态修改每个请求的处理逻辑,也支持通过插件来进行扩展,满足我们对流量的控制,尤其是限流、用户、IP 等这些功能非常实用。

启用安全策略-为 API 服务保驾护航

痛点

在升级之前使用 tribe 作为 API 服务提供后端,几乎相当于裸奔,没有任何认证策略;另外,tribe 本身的稳定性也有问题,官方在新版本逐渐废弃这种 CCS(跨集群搜索),期间出现多次服务崩溃。

极限网关解决问题

极限网关通过,“basic_auth” 插件,提供最基本的安全校验,使用起来非常方便;同时,极限网关提供 LDAP 插件,可以接入公共的 LDAP 服务,对所有的访问用户进行校验,安全策略对所有的用户生效,不用担心因为 IP 问题泄漏数据等。

强大的过滤功能

在使用 ES 集群过程中,许多场景,需要对请求进行控制、限制等操作。在这方便,感受到了极限网关强大的产品力。比如下面的两个场景

对异常流量进行限流

  • 支持对 IP 限流
  • 支持对 hostname 限流
  • 支持 header 限流

对异常用户进行封禁

当 Elasticsearch 是通过 Basic Auth 或者 LDAP 方式来进行身份认证的时候,request_user_filter 过滤器可用来按请求的用户名信息来进行过滤。操作起来也非常简单,只需要 request_user_filter 这一个过滤器。

- request_user_filter:
    include:
        - "elastic"
    exclude:
        - "Ryan"

总结来讲,主要有这些方面的功能:

图5

图5

优秀的可观测性

痛点

改造前经常为看不到直观的数据指标感到头疼,查看指标需要多个地方同时打开,去筛选,查找,非常繁琐,付出的成本非常大。为此,大家都再考虑如何优化这种情况,无奈优先级比较低,一直没有真正的投入时间去优化这块。

完美解决

使用了极限网关,通过收集请求日志,非常清晰的收集到想要的数据,具体如下:

  • 总体方面:
    • 流量曲线
    • 状态码占比
    • 缓存统计
    • 每台网关请求流量
  • 细节方面:
    • 打印每次请求语句
    • 可以查看请求到具体 ES 节点流量
    • 可以查看过滤器的列表

通过下图,我们可以从管理视角直观的看到各种信息,这对于管理员来讲,省时省力,方便快捷。

图6

图6

意外收获:无缝迁移业务 Elasticsearch 上云

由于前期日志业务上云,受到非常好的反馈,多个业务线期望能够上云上服务,达到降本增效的目的。

支持双写

数据可以通过极限网关同时写入两个 ES 集群,能够保障数据完全一致,安全可靠。

无缝切换

切换很丝滑,影响非常小,能够让外界几乎感受不到服务波动。

图7

图7

通过使用极限网关,自建 ES 集群可以无缝的迁移上云,在整个迁移的过程中,两套集群通过网关进行了解耦,在迁移的过程中还能实现版本的无缝升级,极大降低了迁移成本,提高迁移效率,多次验证服务稳定可靠。

极限网关流量概览

这是其中一套极限网关的流量统计。用这部分数据进行巡检,一目了然,做到全局的掌控,提高感知力度。

图8

图8

极限网关使用总结

极限网关提供一系列高性能和高可靠性的网关服务。使用这样的服务给我们带来以下好处:

  1. 可观测性好:极限网关可以动态的对 Elasticsearch 运行过程中请求进行拦截和分析,通过指标和日志来了解集群运行状态,这些指标可以用于提升性能和业务优化。
  2. 增强安全性:包含先进的安全机制,如 basicauth、LDAP 等支持,保护用户数据不受未授权访问和各种网络威胁的侵害。
  3. 高稳定性:通过冗余设计和故障转移机制,极限网关能够确保网络服务的高可用性,即使在某些组件发生故障时也能保持服务不中断,单版本最长服务超过 15 个月。
  4. 易于管理:通过提供 INFINI Console 简洁直观的管理界面,让用户能够轻松配置和监控网络状态,提升管理效率。
  5. 客户支持:良好的客户服务支持可以帮助用户快速解决使用过程中遇到的问题,提供专业的技术指导。

综上所述,极限网关为用户提供了一个高速、安全、稳定且易于管理的 ES 网关,适合对网络性能有较高要求的个人和企业用户。

未来规划

第一阶段,完成了日志 ES 集群,所有集群的容器化改造,合并,成功的把成本降低了 60%以上。这期间积累了丰富容器化经验,为业务 ES 集群上容器做了良好的铺垫;成本优势和运维优势吸引越来越多的业务接入到容器化 ES 集群。

提升 ES 集群效能--新技术应用&&版本升级

  • 极限科技官方推荐的 Easysearch 在压缩率,查询速度等等方面有很多的优势,通过长时间的测试稳定性,新特性,对比云原生的 ES 集群,根据测试结果,给“客户”提供多种选择,这也是工作重点之一。
  • 我们当前使用的 ES 版本是 6.8,已经远远落后于官方版本,今年我们计划在选择合适的集群升级 ES 版本,拥抱更多官方提供的特性。

混合(多)云架构支持

随着越来越多的 ES 集群在机房的 K8S 集群部署,这里资源出现了紧张局面。 我们尝试在云上部署自建 ES 集群,弥补机房资源有限,无法大规模扩容,同时能够支持多活场景,满足更多客户的不同需求。混合云主要实现以下几种能力:

1、扩缩容:满足不同业务灵活适配

混合(多)云部署,可以让负载内部私有云 ES,同时部署到公有云,提升扩展 IT 基础设施不仅局限于 CPU、内存,还有存储。比如某一个业务要做活动,预估流量“大爆发”,需要提前准备大规模资源,在机房内根本来不及采购扩容支持,然而在公有云上就能很方便扩容、缩容。在云上搭建 ES 集群,设置满足需求的数量、容量、配置,配合极限网关路由策略,精准的把控流量流向。

图9

图9

2、灾备:紧急情况快速部署,恢复 ES 集群读写

当机房级别大规模故障,部分业务实现了多活,单一的机房故障不会影响其服务能力,而此时比如日志查看等仍有需求,为了满足这部分“客户”需求,可以在云上 K8S 集群,快速搭建 ES 集群,恢复日志读写功能。

图10

图10

参考文档:

作者:张华勋,前新浪 CDN 研发,工作主要涉及 Mysql、MongoDB、Redis、Elasticsearch、流量调度等组件和系统,以及运维自动化、平台化等工作。现就职于好未来。

关于好未来

好未来(NYSE:TAL)是一家以内容能力与科技能力为基础,以科教、科创、科普为战略方向,助力人的终身成长,并持续探索创新的科技公司。 好未来的前身学而思成立于 2003 年,2010 年在美国纽交所正式挂牌交易。好未来以“爱与科技助力终身成长”为使命,致力成为持续创新的组织。更多参见:https://www.100tal.com/

关于极限科技(INFINI Labs)

INFINI Labs

极限科技,全称极限数据(北京)科技有限公司,是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室(INFINI Labs)致力于打造极致易用的数据探索与分析体验。

极限科技是一支年轻的团队,采用天然分布式的方式来进行远程协作,员工分布在全球各地,希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选,为中国技术品牌输出添砖加瓦。

官网:https://www.infinilabs.cn

联系我们

收起阅读 »

记某客户的一次 Elasticsearch 无缝数据迁移

背景

客户需要将 Elasticsearch 集群无缝迁移到移动云,迁移过程要保证业务的最小停机时间。

实现方式

通过采用成熟的 INFINI 网关来进行数据的双写,在集群的切换恢复过程中来记录数据变更,待全量数据恢复之后再追平后面增量数据,追平增量之后,进行校验确保数据一致再进行流量的切换。

总体流程

总体迁移流程如下:

  1. 客户业务代码,切流量,双写。(新增的变更都会记录在网关本地,但是暂停消费到移动云)
  2. 暂停网关移动云这边的增量数据消费。
  3. 迁移 11 月的数据,快照,快照上传到 S3;
  4. 下载 S3 的文件到移动云。
  5. 恢复快照到移动云的 11 月份的索引。
  6. 开启网关移动云这边的增量消费。
  7. 等待增量追平(接近追平)。
  8. 按照时间条件(如:时间 A,当前时间往前 30 分钟),验证文档数据量,Hash 校验等等。
  9. 停业务的写入,网关,腾讯云的写入(10 分钟)。
  10. 等待剩余的增量追完。
  11. 对时间 A 之后的,增量进行校验。
  12. 切换所有流量到移动云,业务端直接访问移动云 ES。

总体的迁移时间:

  1. 11 月备份时间(30 分钟)19 号开始
  2. 备份下载到移动云的时间(2-3 天)
  3. 备份恢复到移动云集群的时间(30 分钟)
  4. 11 月份增量备份(20 分钟)(双写开始)(21 号)
  5. 11 月份增量下载到移动云(6 小时)
  6. 11 月份增量恢复时间(20 分钟)
  7. 追增量数据(8 个小时产生的数据,需要 1 个小时)
  8. 校验比对(存量 1 个小时)
  9. 流量暂停,增量的校验(10 分钟)
  10. 切换(1 分钟)

总体流程如下示意图:

ES 集群信息

  1. ES 版本 7.10.1
  2. 2个热节点 3个温节点  总数 1.9 TB
  3. 索引   1041, 分片2085
  4. 无自定义插件
  5. 有 update_bu_query 使用
  6. 有 delete_by_query 使用
  7. 吞吐量没有测试过,当前日增文档数 1 千多万,目标日增加上亿  

    迁移操作手册(参考)

    环境

  • 自建 ES 5.4.2
  • 自建 ES 5.6.8
  • 自建 ES 7.5.0
  • 极限网关服务器 1
  • 极限网关服务器 2
  • 云端负载均衡 1 (监听 9200 端口,指向极限网关服务器 1/2 的 8000 端口)
  • 云端负载均衡 2 (监听 9200 端口,指向极限网关服务器 1/2 的 8001 端口)

    场景描述

    若干个自建 Elasticsearch 集群需要平滑迁移到移动云,业务不停写、不做代码改动。

    数据架构

    通过将应用端流量走网关的方式,请求同步转发给自建 ES,网关记录所有的写入请求,并确保顺序在云端 ES 上重放请求,两侧集群的各种故障都妥善进行了处理,从而实现透明的集群双写,实现安全无缝的数据迁移。 业务端如果已经部署在云上,可以使用云上的 SLB 服务来访问网关,确保后端网关的高可用,如果业务端和极限网关还在企业内网,可以使用极限网关自带的 4 层浮动 IP 来确保网关的高可用

数据描述

以数据从自建集群 5.4.2 迁移到云上的 5.6.16 为例进行说明,执行步骤依次说明。

执行步骤

部署 INFINI Gateway

为了保证数据的无缝透明迁移,通过 INFINI Gateway 来进行双写。

  1. 系统调优

    参考此文档

  2. 下载程序
    
    [root@iZbp1gxkifg8uetb33pvcoZ ~]# mkdir /opt/gateway
    [root@iZbp1gxkifg8uetb33pvcoZ ~]# cd /opt/gateway/
    [root@iZbp1gxkifg8uetb33pvcoZ gateway]# wget http://release.infinilabs.com/gateway/snapshot/gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz
    --2022-05-19 10:16:25--  http://release.infinilabs.com/gateway/snapshot/gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz
    正在解析主机 release.infinilabs.com (release.infinilabs.com)... 120.79.205.193
    正在连接 release.infinilabs.com (release.infinilabs.com)|120.79.205.193|:80... 已连接。
    已发出 HTTP 请求,正在等待回应... 200 OK
    长度:7430568 (7.1M) [application/octet-stream]
    正在保存至: “gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz”

100%[==============================================================================================================================================>] 7,430,568 22.8MB/s 用时 0.3s

2022-05-19 10:16:25 (22.8 MB/s) - 已保存 “gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz” [7430568/7430568])

[root@iZbp1gxkifg8uetb33pvcoZ gateway]# tar vxzf gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz gateway-linux-amd64 gateway.yml sample-configs/ sample-configs/elasticsearch-with-ldap.yml sample-configs/indices-replace.yml sample-configs/record_and_play.yml sample-configs/cross-cluster-search.yml sample-configs/kibana-proxy.yml sample-configs/elasticsearch-proxy.yml sample-configs/v8-bulk-indexing-compatibility.yml sample-configs/use_old_style_search_response.yml sample-configs/context-update.yml sample-configs/elasticsearch-route-by-index.yml sample-configs/hello_world.yml sample-configs/entry-with-tls.yml sample-configs/javascript.yml sample-configs/log4j-request-filter.yml sample-configs/request-filter.yml sample-configs/condition.yml sample-configs/cross-cluster-replication.yml sample-configs/secured-elasticsearch-proxy.yml sample-configs/fast-bulk-indexing.yml sample-configs/es_migration.yml sample-configs/index-docs-diff.yml sample-configs/rate-limiter.yml sample-configs/async-bulk-indexing.yml sample-configs/elasticssearch-request-logging.yml sample-configs/router_rules.yml sample-configs/auth.yml sample-configs/index-backup.yml


3. 修改配置

将网关提供的示例配置拷贝,并根据实际集群的信息进行相应的修改,如下:

[root@iZbp1gxkifg8uetb33pvcoZ gateway]# cp sample-configs/cross-cluster-replication.yml 5.4.2TO5.6.16.yml

首先修改集群的身份信息,如下:
![](https://www.infinilabs.com/img/blog/2024/seamless-data-migration/3.png)

然后修改集群的注册信息,如下:
![](https://www.infinilabs.com/img/blog/2024/seamless-data-migration/4.png)

根据需要修改网关监听的端口,以及是否开启 TLS (如果应用客户端通过 http 协议访问 ES,请将entry.tls.enabled 值改为 false),如下:
![](https://www.infinilabs.com/img/blog/2024/seamless-data-migration/5.png)
不同的集群可以使用不同的配置,分别监听不同的端口,用于业务的分开访问。

4. 启动网关

启动网关并指定刚刚创建的配置,如下:

[root@iZbp1gxkifg8uetb33pvcoZ gateway]# ./gateway-linux-amd64 -config 5.4.2TO5.6.16.yml


/ \ /\ / \/\/ / /\ \ \/\ /_/\ / /\///\ / /\/\ \ \/ \/ //\_ / / /\/ \/ / // \ /\ / \/ \ ___/\/ \/\/ \/ \/ \/_/ _/_/

[GATEWAY] A light-weight, powerful and high-performance elasticsearch gateway. [GATEWAY] 1.6.0_SNAPSHOT, 2022-05-18 11:09:54, 2023-12-31 10:10:10, 73408e82a0f96352075f4c7d2974fd274eeafe11 [05-19 13:35:43] [INF] [app.go:174] initializing gateway. [05-19 13:35:43] [INF] [app.go:175] using config: /opt/gateway/5.4.2TO5.6.16.yml. [05-19 13:35:43] [INF] [instance.go:72] workspace: /opt/gateway/data1/gateway/nodes/ca2tc22j7ad0gneois80 [05-19 13:35:43] [INF] [app.go:283] gateway is up and running now. [05-19 13:35:50] [INF] [actions.go:358] elasticsearch [primary] is available [05-19 13:35:50] [INF] [api.go:262] api listen at: http://0.0.0.0:2900 [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [primary] hosts: [] => [192.168.0.19:9200] [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [backup] hosts: [] => [es-cn-tl32p9fkk0006m56k.elasticsearch.aliyuncs.com:9200] [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [primary] hosts: [] => [192.168.0.19:9200] [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [backup] hosts: [] => [es-cn-tl32p9fkk0006m56k.elasticsearch.aliyuncs.com:9200] [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [primary] hosts: [] => [192.168.0.19:9200] [05-19 13:35:50] [INF] [entry.go:322] entry [my_es_entry/] listen at: https://0.0.0.0:8000 [05-19 13:35:50] [INF] [module.go:116] all modules are started


5. 后台运行

[root@iZbp1gxkifg8uetb33pvcoZ gateway]# nohup ./gateway-linux-amd64 -config 5.4.2TO5.6.16.yml &


6. 应用授权

curl -XPOST http://localhost:2900/_license/apply -d' { "license": "XXXXXXXXXXXXXXXXXXXXXXXXX" }'

#### 部署 INFINI Console
为了方便在多个集群之间快速切换,使用 INFINI [Console](https://infinilabs.cn/products/console/) 来进行管理。

1. 下载安装

[root@iZbp1gxkifg8uetb33pvcpZ console]# wget http://release.infinilabs.com/console/snapshot/console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz --2022-05-19 10:57:24-- http://release.infinilabs.com/console/snapshot/console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz 正在解析主机 release.infinilabs.com (release.infinilabs.com)... 120.79.205.193 正在连接 release.infinilabs.com (release.infinilabs.com)|120.79.205.193|:80... 已连接。 已发出 HTTP 请求,正在等待回应... 200 OK 长度:13576234 (13M) [application/octet-stream] 正在保存至: “console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz”

100%[==============================================================================================================================================>] 13,576,234 33.2MB/s 用时 0.4s

2022-05-19 10:57:25 (33.2 MB/s) - 已保存 “console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz” [13576234/13576234])

[root@iZbp1gxkifg8uetb33pvcpZ console]# tar vxzf console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz console-linux-amd64 console.yml


2. 修改配置

[root@iZbp1gxkifg8uetb33pvcpZ console]# cat console.yml

for the system cluster, please use Elasticsearch v7.3+

elasticsearch:

  1. 启动服务

    [root@iZbp1gxkifg8uetb33pvcpZ console]# ./console-linux-amd64 -service install
    Success
    [root@iZbp1gxkifg8uetb33pvcpZ console]# ./console-linux-amd64 -service start
    Success
  2. 访问后台

访问该主机的 9000 端口,即可打开 Console 后台,http://x.x.x.x:9000/ 打开菜单 [System][Cluster] ,注册当前需要管理的 Elasticsearch 集群和网关地址,用来快速管理,如下:

测试 INFINI Gateway

为了验证网关是否正常工作,我们通过 INFINI Console 来快速验证一下。 首先通过走网关的接口来创建一个索引,并写入一个文档,如下: 查看 5.4.2 集群的数据情况,如下: 查看集群 5.6.16 的数据情况,如下: 说明网关配置都正常,验证结束。

调整网关的消费策略

因为我们需要在全量数据迁移之后,才能进行增量数据的追加,在全量数据迁移完成之前,我们应该暂停增量数据的消费。修改网关配置里面 Pipeline consume-queue_backup-to-backupconsume-queue_primary-failure-to-backup的参数 auto_startfalse,表示不自动启动该任务,具体配置方法如下: 修改完配置之后,需要重新启动网关。 为了方便管理,可以使用 INFINI Console 来注册和管理网关,如下: 待全量迁移完成之后,可以通过后台的 Task 管理来进行后续的任务启动、停止,如下:

切换流量

接下来,将业务正常写的流量切换到网关,也就是需要把之前指向 ES 5.4.2 的地址指向网关的地址,如果 5.4.2 集群开启了身份验证,业务端代码同样需要传递身份信息,和 5.4.2 之前的用法保持不变。 切换流量到网关之后,用户的请求还是以同步的方式正常访问自建集群,网关记录到的请求会按顺序记录到 MQ 里面,但是消费是暂停状态。 如果业务端代码使用的 ES 的 SDK 支持 Sniff,并且业务代码开启了 Sniff,那么应该关闭 Sniff,避免业务端通过 Sniff 直接链接到后端的 ES 节点,所有的流量现在应该都只通过网关来进行访问。

全量数据迁移

在流量迁移到网关之后,我们开始对自建 Elasticsearch 集群的数据进行全量迁移到云端 Elasticsearch 集群。 全量迁移已有的数据的方式有很多种:

  • 通过快照的方式进行恢复
  • 使用工具来导出导入,如: ESM

如果索引数量很多的话,可以按照索引依次进行导入,同时需要注意将 Mapping 和 Setting 提前导入。 以现在 5.4 集群的索引来为例,目前的待迁移索引为 demo_5_4_2,只有4 个文档: 我们使用网关自带的迁移功能来进行数据迁移,拷贝自带的样例文件,如下:

[root@iZbp1gxkifg8uetb33pvcpZ gateway]# cp sample-configs/es_migration.yml  5.4TO5.6.yml

修改其中代表集群和索引的相关配置,可以根据需要配置是否需要重命名索引和统一 Type( 用于跨版本统一 Type),如下图红框位置: 创建好模板和索引,如果目标集群不允许动态创建文档,需要提前创建好索引,如下图: 然后就可以开始数据的迁移了,执行网关程序并指定刚刚定义的配置,如下: 执行完成后,可以确认下数据的情况,如下图: 全量数据至此导入完成。

增量数据迁移

在全量导入的过程中,可能存在数据的增量修改,不过这部分请求都已经完整记录下来了,我们只需要开启网关的消费任务即可将挤压的请求应用到云端的 Elasticsearch 集群。 示例操作如下: 如果从 5.6 的集群来看的话,这部分的修改还没同步过来,如下: 这部分增量的数据变更,在网关层面都进行了完整记录,我们只需要开启网关的增量消费任务,如下: 通过观察队列是否消费完成来判断增量数据是否做完,如下: 现在我们再看一下 5.6 集群的数据情况,如下: 数据的增量更新就过来了。

执行数据比对

由于集群内部的数据可能比较多,我们需要进行一个完整的比对才能确保数据的完整性,可以通过网关自带的数据比对工具来进行,将样例自带的文件拷贝一份,如下:

[root@iZbp1gxkifg8uetb33pvcpZ gateway]# cp sample-configs/index-docs-diff.yml  5.4DIFF5.6.yml

修改需要比对的集群和索引信息,可以加上过滤条件,如时间范围窗口来进行增量 Diff,如下图:

执行网关程序,并指定该配置文件,如下图: 如图,两个集群完全一致。

切换集群

如果验证完之后,两个集群的数据已经完全一致了,可以将程序切换到新集群,或者将网关的配置里面的主备进行互换,同步写 5.6 集群。 双集群在线运行一段时间,待业务完全验证之后,再安全下线旧集群,如遇到问题,也可以随时回切到老集群。

小结

通过使用极限网关,自建 ES 集群可以安全无缝的迁移到移动云 ES,在迁移的过程中,两套集群通过网关进行了解耦,两套集群的版本也可以不一样,在迁移的过程中还能实现版本的无缝升级。 如有任何问题,请随时联系我,期待与您交流!

继续阅读 »

背景

客户需要将 Elasticsearch 集群无缝迁移到移动云,迁移过程要保证业务的最小停机时间。

实现方式

通过采用成熟的 INFINI 网关来进行数据的双写,在集群的切换恢复过程中来记录数据变更,待全量数据恢复之后再追平后面增量数据,追平增量之后,进行校验确保数据一致再进行流量的切换。

总体流程

总体迁移流程如下:

  1. 客户业务代码,切流量,双写。(新增的变更都会记录在网关本地,但是暂停消费到移动云)
  2. 暂停网关移动云这边的增量数据消费。
  3. 迁移 11 月的数据,快照,快照上传到 S3;
  4. 下载 S3 的文件到移动云。
  5. 恢复快照到移动云的 11 月份的索引。
  6. 开启网关移动云这边的增量消费。
  7. 等待增量追平(接近追平)。
  8. 按照时间条件(如:时间 A,当前时间往前 30 分钟),验证文档数据量,Hash 校验等等。
  9. 停业务的写入,网关,腾讯云的写入(10 分钟)。
  10. 等待剩余的增量追完。
  11. 对时间 A 之后的,增量进行校验。
  12. 切换所有流量到移动云,业务端直接访问移动云 ES。

总体的迁移时间:

  1. 11 月备份时间(30 分钟)19 号开始
  2. 备份下载到移动云的时间(2-3 天)
  3. 备份恢复到移动云集群的时间(30 分钟)
  4. 11 月份增量备份(20 分钟)(双写开始)(21 号)
  5. 11 月份增量下载到移动云(6 小时)
  6. 11 月份增量恢复时间(20 分钟)
  7. 追增量数据(8 个小时产生的数据,需要 1 个小时)
  8. 校验比对(存量 1 个小时)
  9. 流量暂停,增量的校验(10 分钟)
  10. 切换(1 分钟)

总体流程如下示意图:

ES 集群信息

  1. ES 版本 7.10.1
  2. 2个热节点 3个温节点  总数 1.9 TB
  3. 索引   1041, 分片2085
  4. 无自定义插件
  5. 有 update_bu_query 使用
  6. 有 delete_by_query 使用
  7. 吞吐量没有测试过,当前日增文档数 1 千多万,目标日增加上亿  

    迁移操作手册(参考)

    环境

  • 自建 ES 5.4.2
  • 自建 ES 5.6.8
  • 自建 ES 7.5.0
  • 极限网关服务器 1
  • 极限网关服务器 2
  • 云端负载均衡 1 (监听 9200 端口,指向极限网关服务器 1/2 的 8000 端口)
  • 云端负载均衡 2 (监听 9200 端口,指向极限网关服务器 1/2 的 8001 端口)

    场景描述

    若干个自建 Elasticsearch 集群需要平滑迁移到移动云,业务不停写、不做代码改动。

    数据架构

    通过将应用端流量走网关的方式,请求同步转发给自建 ES,网关记录所有的写入请求,并确保顺序在云端 ES 上重放请求,两侧集群的各种故障都妥善进行了处理,从而实现透明的集群双写,实现安全无缝的数据迁移。 业务端如果已经部署在云上,可以使用云上的 SLB 服务来访问网关,确保后端网关的高可用,如果业务端和极限网关还在企业内网,可以使用极限网关自带的 4 层浮动 IP 来确保网关的高可用

数据描述

以数据从自建集群 5.4.2 迁移到云上的 5.6.16 为例进行说明,执行步骤依次说明。

执行步骤

部署 INFINI Gateway

为了保证数据的无缝透明迁移,通过 INFINI Gateway 来进行双写。

  1. 系统调优

    参考此文档

  2. 下载程序
    
    [root@iZbp1gxkifg8uetb33pvcoZ ~]# mkdir /opt/gateway
    [root@iZbp1gxkifg8uetb33pvcoZ ~]# cd /opt/gateway/
    [root@iZbp1gxkifg8uetb33pvcoZ gateway]# wget http://release.infinilabs.com/gateway/snapshot/gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz
    --2022-05-19 10:16:25--  http://release.infinilabs.com/gateway/snapshot/gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz
    正在解析主机 release.infinilabs.com (release.infinilabs.com)... 120.79.205.193
    正在连接 release.infinilabs.com (release.infinilabs.com)|120.79.205.193|:80... 已连接。
    已发出 HTTP 请求,正在等待回应... 200 OK
    长度:7430568 (7.1M) [application/octet-stream]
    正在保存至: “gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz”

100%[==============================================================================================================================================>] 7,430,568 22.8MB/s 用时 0.3s

2022-05-19 10:16:25 (22.8 MB/s) - 已保存 “gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz” [7430568/7430568])

[root@iZbp1gxkifg8uetb33pvcoZ gateway]# tar vxzf gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz gateway-linux-amd64 gateway.yml sample-configs/ sample-configs/elasticsearch-with-ldap.yml sample-configs/indices-replace.yml sample-configs/record_and_play.yml sample-configs/cross-cluster-search.yml sample-configs/kibana-proxy.yml sample-configs/elasticsearch-proxy.yml sample-configs/v8-bulk-indexing-compatibility.yml sample-configs/use_old_style_search_response.yml sample-configs/context-update.yml sample-configs/elasticsearch-route-by-index.yml sample-configs/hello_world.yml sample-configs/entry-with-tls.yml sample-configs/javascript.yml sample-configs/log4j-request-filter.yml sample-configs/request-filter.yml sample-configs/condition.yml sample-configs/cross-cluster-replication.yml sample-configs/secured-elasticsearch-proxy.yml sample-configs/fast-bulk-indexing.yml sample-configs/es_migration.yml sample-configs/index-docs-diff.yml sample-configs/rate-limiter.yml sample-configs/async-bulk-indexing.yml sample-configs/elasticssearch-request-logging.yml sample-configs/router_rules.yml sample-configs/auth.yml sample-configs/index-backup.yml


3. 修改配置

将网关提供的示例配置拷贝,并根据实际集群的信息进行相应的修改,如下:

[root@iZbp1gxkifg8uetb33pvcoZ gateway]# cp sample-configs/cross-cluster-replication.yml 5.4.2TO5.6.16.yml

首先修改集群的身份信息,如下:
![](https://www.infinilabs.com/img/blog/2024/seamless-data-migration/3.png)

然后修改集群的注册信息,如下:
![](https://www.infinilabs.com/img/blog/2024/seamless-data-migration/4.png)

根据需要修改网关监听的端口,以及是否开启 TLS (如果应用客户端通过 http 协议访问 ES,请将entry.tls.enabled 值改为 false),如下:
![](https://www.infinilabs.com/img/blog/2024/seamless-data-migration/5.png)
不同的集群可以使用不同的配置,分别监听不同的端口,用于业务的分开访问。

4. 启动网关

启动网关并指定刚刚创建的配置,如下:

[root@iZbp1gxkifg8uetb33pvcoZ gateway]# ./gateway-linux-amd64 -config 5.4.2TO5.6.16.yml


/ \ /\ / \/\/ / /\ \ \/\ /_/\ / /\///\ / /\/\ \ \/ \/ //\_ / / /\/ \/ / // \ /\ / \/ \ ___/\/ \/\/ \/ \/ \/_/ _/_/

[GATEWAY] A light-weight, powerful and high-performance elasticsearch gateway. [GATEWAY] 1.6.0_SNAPSHOT, 2022-05-18 11:09:54, 2023-12-31 10:10:10, 73408e82a0f96352075f4c7d2974fd274eeafe11 [05-19 13:35:43] [INF] [app.go:174] initializing gateway. [05-19 13:35:43] [INF] [app.go:175] using config: /opt/gateway/5.4.2TO5.6.16.yml. [05-19 13:35:43] [INF] [instance.go:72] workspace: /opt/gateway/data1/gateway/nodes/ca2tc22j7ad0gneois80 [05-19 13:35:43] [INF] [app.go:283] gateway is up and running now. [05-19 13:35:50] [INF] [actions.go:358] elasticsearch [primary] is available [05-19 13:35:50] [INF] [api.go:262] api listen at: http://0.0.0.0:2900 [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [primary] hosts: [] => [192.168.0.19:9200] [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [backup] hosts: [] => [es-cn-tl32p9fkk0006m56k.elasticsearch.aliyuncs.com:9200] [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [primary] hosts: [] => [192.168.0.19:9200] [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [backup] hosts: [] => [es-cn-tl32p9fkk0006m56k.elasticsearch.aliyuncs.com:9200] [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [primary] hosts: [] => [192.168.0.19:9200] [05-19 13:35:50] [INF] [entry.go:322] entry [my_es_entry/] listen at: https://0.0.0.0:8000 [05-19 13:35:50] [INF] [module.go:116] all modules are started


5. 后台运行

[root@iZbp1gxkifg8uetb33pvcoZ gateway]# nohup ./gateway-linux-amd64 -config 5.4.2TO5.6.16.yml &


6. 应用授权

curl -XPOST http://localhost:2900/_license/apply -d' { "license": "XXXXXXXXXXXXXXXXXXXXXXXXX" }'

#### 部署 INFINI Console
为了方便在多个集群之间快速切换,使用 INFINI [Console](https://infinilabs.cn/products/console/) 来进行管理。

1. 下载安装

[root@iZbp1gxkifg8uetb33pvcpZ console]# wget http://release.infinilabs.com/console/snapshot/console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz --2022-05-19 10:57:24-- http://release.infinilabs.com/console/snapshot/console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz 正在解析主机 release.infinilabs.com (release.infinilabs.com)... 120.79.205.193 正在连接 release.infinilabs.com (release.infinilabs.com)|120.79.205.193|:80... 已连接。 已发出 HTTP 请求,正在等待回应... 200 OK 长度:13576234 (13M) [application/octet-stream] 正在保存至: “console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz”

100%[==============================================================================================================================================>] 13,576,234 33.2MB/s 用时 0.4s

2022-05-19 10:57:25 (33.2 MB/s) - 已保存 “console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz” [13576234/13576234])

[root@iZbp1gxkifg8uetb33pvcpZ console]# tar vxzf console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz console-linux-amd64 console.yml


2. 修改配置

[root@iZbp1gxkifg8uetb33pvcpZ console]# cat console.yml

for the system cluster, please use Elasticsearch v7.3+

elasticsearch:

  1. 启动服务

    [root@iZbp1gxkifg8uetb33pvcpZ console]# ./console-linux-amd64 -service install
    Success
    [root@iZbp1gxkifg8uetb33pvcpZ console]# ./console-linux-amd64 -service start
    Success
  2. 访问后台

访问该主机的 9000 端口,即可打开 Console 后台,http://x.x.x.x:9000/ 打开菜单 [System][Cluster] ,注册当前需要管理的 Elasticsearch 集群和网关地址,用来快速管理,如下:

测试 INFINI Gateway

为了验证网关是否正常工作,我们通过 INFINI Console 来快速验证一下。 首先通过走网关的接口来创建一个索引,并写入一个文档,如下: 查看 5.4.2 集群的数据情况,如下: 查看集群 5.6.16 的数据情况,如下: 说明网关配置都正常,验证结束。

调整网关的消费策略

因为我们需要在全量数据迁移之后,才能进行增量数据的追加,在全量数据迁移完成之前,我们应该暂停增量数据的消费。修改网关配置里面 Pipeline consume-queue_backup-to-backupconsume-queue_primary-failure-to-backup的参数 auto_startfalse,表示不自动启动该任务,具体配置方法如下: 修改完配置之后,需要重新启动网关。 为了方便管理,可以使用 INFINI Console 来注册和管理网关,如下: 待全量迁移完成之后,可以通过后台的 Task 管理来进行后续的任务启动、停止,如下:

切换流量

接下来,将业务正常写的流量切换到网关,也就是需要把之前指向 ES 5.4.2 的地址指向网关的地址,如果 5.4.2 集群开启了身份验证,业务端代码同样需要传递身份信息,和 5.4.2 之前的用法保持不变。 切换流量到网关之后,用户的请求还是以同步的方式正常访问自建集群,网关记录到的请求会按顺序记录到 MQ 里面,但是消费是暂停状态。 如果业务端代码使用的 ES 的 SDK 支持 Sniff,并且业务代码开启了 Sniff,那么应该关闭 Sniff,避免业务端通过 Sniff 直接链接到后端的 ES 节点,所有的流量现在应该都只通过网关来进行访问。

全量数据迁移

在流量迁移到网关之后,我们开始对自建 Elasticsearch 集群的数据进行全量迁移到云端 Elasticsearch 集群。 全量迁移已有的数据的方式有很多种:

  • 通过快照的方式进行恢复
  • 使用工具来导出导入,如: ESM

如果索引数量很多的话,可以按照索引依次进行导入,同时需要注意将 Mapping 和 Setting 提前导入。 以现在 5.4 集群的索引来为例,目前的待迁移索引为 demo_5_4_2,只有4 个文档: 我们使用网关自带的迁移功能来进行数据迁移,拷贝自带的样例文件,如下:

[root@iZbp1gxkifg8uetb33pvcpZ gateway]# cp sample-configs/es_migration.yml  5.4TO5.6.yml

修改其中代表集群和索引的相关配置,可以根据需要配置是否需要重命名索引和统一 Type( 用于跨版本统一 Type),如下图红框位置: 创建好模板和索引,如果目标集群不允许动态创建文档,需要提前创建好索引,如下图: 然后就可以开始数据的迁移了,执行网关程序并指定刚刚定义的配置,如下: 执行完成后,可以确认下数据的情况,如下图: 全量数据至此导入完成。

增量数据迁移

在全量导入的过程中,可能存在数据的增量修改,不过这部分请求都已经完整记录下来了,我们只需要开启网关的消费任务即可将挤压的请求应用到云端的 Elasticsearch 集群。 示例操作如下: 如果从 5.6 的集群来看的话,这部分的修改还没同步过来,如下: 这部分增量的数据变更,在网关层面都进行了完整记录,我们只需要开启网关的增量消费任务,如下: 通过观察队列是否消费完成来判断增量数据是否做完,如下: 现在我们再看一下 5.6 集群的数据情况,如下: 数据的增量更新就过来了。

执行数据比对

由于集群内部的数据可能比较多,我们需要进行一个完整的比对才能确保数据的完整性,可以通过网关自带的数据比对工具来进行,将样例自带的文件拷贝一份,如下:

[root@iZbp1gxkifg8uetb33pvcpZ gateway]# cp sample-configs/index-docs-diff.yml  5.4DIFF5.6.yml

修改需要比对的集群和索引信息,可以加上过滤条件,如时间范围窗口来进行增量 Diff,如下图:

执行网关程序,并指定该配置文件,如下图: 如图,两个集群完全一致。

切换集群

如果验证完之后,两个集群的数据已经完全一致了,可以将程序切换到新集群,或者将网关的配置里面的主备进行互换,同步写 5.6 集群。 双集群在线运行一段时间,待业务完全验证之后,再安全下线旧集群,如遇到问题,也可以随时回切到老集群。

小结

通过使用极限网关,自建 ES 集群可以安全无缝的迁移到移动云 ES,在迁移的过程中,两套集群通过网关进行了解耦,两套集群的版本也可以不一样,在迁移的过程中还能实现版本的无缝升级。 如有任何问题,请随时联系我,期待与您交流!

收起阅读 »

7 年+积累、 Elastic 创始人Shay Banon 等 15 位专家推荐的 Elasticsearch 8.X新书《一本书讲透Elasticsearch》已上线...

今天,非常高兴地跟大家宣布,经过 7 年多的努力和精心准备,我们的新书《一本书讲透 Elasticsearch》已正式出版上线! ​​

1.png

​​​​​​ 我从 2016 年接触 Elasticsearch 1.X、2.X 的版本,到现在已经接近 8 年+的时间。在这期间,我常常被问到:

如何系统性地学习 Elasticsearch ?

如何将现有的关系型数据库迁移到 ES ?

如何选择合适的版本?

如何规划和监控集群?

如何进行数据建模?

如何选择合适的检索方式?

如何基于现有数据进行可视化分析?

等一系列问题.......

这些问题促使我将之前的产品开发、项目实战经验和咨询经验进行全面整合,并精心梳理,融入到这本新书中,希望能让大家少走不必要的弯路。

一、书籍特点 本书具有以下几个显著特点:

最新版本,前沿知识点

本书基于 8.x 版本编写,涵盖了如索引生命周期管理、快照生命周期管理、数据流 datastream 等至关重要的新特性。

核心知识,系统认知

我们为您提供了清晰的学习路径,保留了最核心的“最少必要”知识点,并通过思维导图和大量图解内容,帮助读者更易理解和吸收。

实际应用,超越认证

覆盖Elastic官方认证的核心知识点,已帮助近200人通过Elastic专家认证考试。内容不仅限于认证,更注重实际应用。

来源于实战,应用于实战

书中内容源自真实项目案例和企业级问题解答(问题来自于Elasticsearch中文社区、死磕Elasticsearch知识星球、微信群、QQ群等)。涵盖3个实战项目,助力读者将技能应用到企业实战环境中。

代码开源,答疑服务

全书的代码、脚本在GitHub上开源,便于初学者通过实践学习。我们的答疑社群将持续跟踪最新问题,不断迭代更新内容。

二、5 个最尖锐问题快问快答 如下的问题来自 ChatGPT 4.0 的作为专业读者提出的 5 个最尖锐问题。

2.png

我快速回答一下:

2.1 问题1:市场竞争和定位问题 “市面上已有接近10本关于Elasticsearch的书籍,您的书与这些现有书籍相比有何独特之处?您是如何确保您的书在内容上与其他书籍区别开来,满足读者新的或更深入的需求的?”

铭毅天下:

1、独特之处:版本咱们是目前市场唯一的 8.X 版本。

2、区别开来:我从 2016 年开始搞 ElasticStack 到现在几乎平均每周一篇技术博客,从未间断。无需多说,时间能证明一切!这是咱们最大的不同之一。

3、还有不同:我自己公众号+博客有累计近 4.5 万+关注读者,知识星球有近2000人付费用户,这些大量的实战问题促使我唯有“自我革命”才能生存和成长!

2.2 问题2:实用性和更新性问题 “鉴于Elasticsearch技术持续发展和迭代,您的书籍是如何处理和包含最新版本的特性和变化的?在提供最新信息的同时,您如何保证书中内容的长期有效性和实用性?”

铭毅天下:

1、实话说结论,我做不到,市面上任何纸质书都不可能做到。受限于撰写、出版等相较于 Elastic技术栈体系更新的滞后性。

2、但是,我在筛选知识点的时候已充分考虑结合企业级实战以及 Elastic 官方认证考试的最核心、最关键的“最少必要知识”作为咱们的提纲,并且承诺后面继续根据读者反馈迭代和升级。

2.3 问题3:作者经验和权威性问题 “您能否分享一些您个人在Elasticsearch领域的实战经验或特殊贡献,这些经验如何在您的书中得到体现?作为作者,您相比其他书籍作者有哪些独特的优势或视角?”

铭毅天下:

1、本人持续深耕大数据存储和检索领域 7 年+,有博客为证!有丰富的项目实战经验和企业级实战问题咨询经验,已带领近200人+通过 Elastic 认证专家考试。

2、独特视角就是:来自全国乃至全球多个国家的实战问题——自己运营的知识星球、微信群、QQ群多达数千人,每天都有大量实战问题涌现。

3、作者是坚定的长期主义者:博客已写12年+,从未间断!相信积累的力量、相信坚持的力量、相信相信的力量!

2.4 问题4:读者受益问题 “您认为读者在阅读您的书籍之后,最具体和显著的收获会是什么?有哪些实际的技能或知识可以直接应用到他们的工作和项目中?”

铭毅天下:

1、少走不必要的弯路!

2、能获得属于自己的专属学习路线,能建立专属的知识体系,能将 Elasticsearch 原理、开发、运维、架构技能应用于实战。

2.5 问题5:内容深度和广度问题 “您的书籍是如何平衡Elasticsearch的基础知识和高级技术的?它是否适合所有水平的读者,从初学者到高级用户?对于那些已经具有深厚Elasticsearch知识背景的读者,您的书提供了哪些更深入的见解或独特内容?”

铭毅天下:

1、适合大数据存储和检索领域的初学者,也同样适合有工作经验的中级、高级工程师、架构师等。

2、对于深厚Elasticsearch知识背景的读者,本书可以当做工具书,需要时备查、常翻常新。

三、行业顶级大佬的推荐

3.png

值得一提的是,这本书获得了 Elastic 创始人兼CTO Shay Banon 、Elastic中文社区创始人兼极限科技CTO等15位顶级专家的强力推荐,是一本不可多得的Elasticsearch学习材料。

I am very happy to see that Elasticsearch has been widely used in China, which fully reflects the open source, free and open power of Elastic. This book is derived from the author's 7 years of technical accumulation and embodies the author's love for ElasticStack open source technology. I hope this book can help more people understand Elasticsearch and search technology, so as to discover the great value of data. I am convinced that this book will have a profound impact on Elastic's Chinese community.

我很高兴看到Elasticsearch在中国得到了广泛的应用,这充分体现了Elastic开源、自由、开放的力量。本书源自作者7年的技术积累,体现了作者对ElasticStack开源技术的热爱。希望这本书能够帮助更多的人了解Elasticsearch和搜索技术,从而发现数据的巨大价值。我相信这本书将对 Elastic 的中文社区产生深远的影响。

4.png

——Shay Banon Elastic公司创始人兼首席技术官

很高兴看到铭毅天下的新书出版,《一本书讲透Elasticsearch:原理、进阶与工程实践》是一本值得推荐的新书。它汇集了作者丰富的实战经验,深入探讨 Elasticsearch的 核心原理。书中丰富的图解和清晰的结构使得复杂的知识易于理解和吸收。同时,它覆盖了 Elastic 认证考试的所有考点,助力读者建立全面的认知。此外,书中还包含实战项目,帮助读者将所学技能应用到实际场景中。作者拥有多年实战经验和广泛的影响力,这本书将成为学习和应用 Elasticsearch 的重要指南。

——Medcl,Elastic 中文社区创始人、极限科技创始人

铭毅天下是ES中文社区里少有的常年坚持写作的技术博主,尤其擅长将点状发散的社区讨论进行归纳总结,结合自己的实践和再思考,形成系统性的系列技术文章。本书成于作者在Elasticsearch领域多年的理论知识沉淀,并涵盖了实际应用场景的最佳实践。无论你是Elasticsearch初学者还是有一定经验的开发者,相信都能通过阅读本书而受益匪浅。

—— 吴晓刚 (Wood大叔)携程旅行网 企业数字化平台部 研发总监

在大数据检索和分析领域,Elastic Stack 技术栈有广泛应用,本书从业务场景出发详细介绍了在 Elasticsearch 擅长的各类场景中完成业务系统开发所需的技术栈和技术手段,为用户系统选型和了解整体技术架构提供了指导,可以帮助用户少走弯路,快速完成系统建设。

——张超 《Elasticsearch 源码解析与优化实战》作者, Elasticsearch 内核资深研发工程师

本书基于Elasticsearch最新的8.X版本,涵盖了Elasticsearch更加完整、实时的功能。作者拥有丰富的Elasticsearch和写作经验,语言通俗易懂,内容详尽全面。无论你是初学者还是有一定经验的开发人员,本书都能够为你提供更深入的内容和最佳实践。如果你想系统地学习、掌握Elasticsearch,那么这本书绝对是你不可错过的参考书籍。

—— 魏子珺,阿里巴巴elasticsearch内核专家

很高兴为大家推荐这本关于Elasticsearch的技术书籍。本书涵盖了相当丰富的原理讲解和实现技术,更重要的是对实战场景给出了明确的指导案例和代码片段可供参考和使用。即面向开发人员深入讲解了搜索引擎的核心算法与数据结构,也同时给运维人员提供了关键指标的定义和解读。对于想系统学习的初、中级用户,可以按照章节循序渐进的阅读。对于高级用户来说,也可以从 遇到的问题为切入点,直接从某个具体章节入手来测试、寻求解决方案。铭毅天下是Elastic中文社区长期活跃和积极贡献的明星成员。非常兴奋看到他把自己日积月累的知识精华和经验总结在书中分享给广大读者。我相信本书一定可以帮助到处在任何阶段想学习探索Elasticsearch的用户。

——吴斌,Elastic中文社区主席

《一本书讲透Elasticsearch:原理、进阶与工程实践》是一本由一线开发人员撰写的实战指南。作者凭借多年的 Elasticsearch 咨询和教学经验,将复杂的概念以简明易懂的方式呈现给读者。这本书将帮助你深入了解 Elasticsearch,并理解其背后的原理和逻辑。通过学习本书,你将获得全面的知识,从而能够灵活应用 Elasticsearch 解决各种实际问题。相信这本书将成为你掌握 Elasticsearch 的必备工具。

——阮一鸣,eBay 高级研发经理、极客时间『Elasticsearch 核心技术与实战』课程讲师

铭毅在 Elasticsearch 领域深耕多年,勤奋且专注, 同时运营着国内最大的 ES 社群 ,帮助许多同学成功通过了有难度的 Elastic 认证工程师考试。很高兴看到他的新书出版,都说万事开头难,但我相信这本书能够为ES 初学者铺平道路,扫除障碍,澄清疑虑,快速上手!推荐大家阅读!

——魏彬,中国首位 Elastic 认证工程师

《一本书讲透Elasticsearch:原理、进阶与工程实践 》这本书是我极力推荐的一部作品!

我认识铭毅天下很久了,第一次见面记得是2019年在北京的Elastic开发者大会上,但在这之前,我就经常阅读他关于Elasticsearch的技术分享而神交已久。我了解的铭毅天下是一位拥有丰富的Elasticsearch领域知识和经验的专家,他曾在PB级大数据系统项目中发挥关键作用。实施这种大规模,长周期的复杂项目是非常不容易的,无论从系统设计,到实施过程中的问题解决。因此,来自于实践的真知产出,值得我们开卷。

多年来,铭毅天下一直积极、高效地在各种博客和社交媒体上分享与Elasticsearch相关的内容,并密切同步每个版本的更新。在Elasticsearch上,他不仅持续自我精进,还组织了学习小组和社区,帮助其他对Elasticsearch感兴趣的伙伴一起进步。他还带领150多人通过Elastic工程师认证,为许多人的职业发展贡献了力量。

这本书是铭毅天下多年经验的总结,内容涵盖了几乎全部的Elastic认证考点,而且它来自铭毅天下近7年的博客积累,每一章节都经得起时间的考验。因为抓住了平时学习和使用Elasticsearch当中痛点并总结了最佳实践,这些内容不仅阅读量高,而且转发度也很广泛。无论你是想深入了解Elasticsearch的基础知识还是应用实践,这本书都能满足你的需求。

我相信这本书将为读者提供一次全面而深入的学习体验,帮助他们在Elasticsearch领域取得突破。无论你是初学者还是有经验的专业人士,这本书都是不可或缺的指南。我由衷地推荐这本书,相信它会成为你在Elasticsearch学习和实践中的得力伙伴!

——李捷,Elastic 解决方案架构师 Principle Solution Architect

当得知本书成稿的消息时,我的心情是非常激动的,不管是作为一名技术人,还是作为一名搜索引擎的从业者,以及作为一名Elasticsearch中文社区的参与者和建设者。本书作者与我们一起见证了Elastic生态在国内的起步、发展以及到今天的繁荣;有所不同的是,作者有超强的毅力(就像铭毅天下的名字一样),坚持在这个技术方向上深耕了7年之久,在知识、技术和实践等方面有着深厚的经验积累,不但亲力亲为,而且深谙知识社群与实践社区CoP的操盘之道,在自我成长的同时也打造了优质的同行网络,积极影响了一批技术人,其中的优秀者更是通过了Elatics官方认证,极具含金量。本书的出版,一定会给更多技术人带来直接或间接的帮助,同时在个人成长、知识共享与实践社区等方面在业内树立成功的榜样。让我们一起用技术影响世界影响人!

—— 杨振涛,Elastisearch中文社区深圳主席|vivo互联网 研发总监

Elasticsearch是人工智能和大数据时代不可或缺的重要产品,已经成为开发者必备技能。本书汇集了作者多年开发经验、咨询经验、数千个Elasticsearch爱好者的最佳实战。因此在讲解原理的同时,能深入到最佳实践中去,做到深入浅出,非常适合Elasticsearch的初学者以及进阶者。

—— 付磊,快手Elasticsearch负责人,《Redis开发与运维》作者

Elasticsearch 作为一款强大又灵活的数据分析检索工具,值得每一位后端程序员认真学习。铭毅天下的这本《一本书讲透Elasticsearch:原理、进阶与工程实践》,用浅显易懂的语言介绍了Elasticsearch的概念、原理和实践,非常值得阅读!

—— 程序员小灰,公众号【程序员小灰】运营者,畅销书《漫画算法》作者

铭毅是我的老友,他是一个及其认证踏实和执着追究技术的人,这七年来他一直热心Elasticstack相关技术的步道,热忱帮助社区和公众号里的伙伴,成就不俗。本书是一本实用性极高的Elasticsearch的实践类书籍,更是铭毅倾尽所学之作。通读原稿后,让我非常欣赏的地方在于,它是市面上难得一见的把Elasticsearch原理,实现方式,最佳实践,以及实战案例串联在一起实操类书籍,无论是初学者还是需要进阶学习的人员都能从中获取想要的内容。十分适合想要在企业环境中落地Elasticsearch的人们,因此我诚意把它推荐给广大的技术爱好者和相关从业人员。

——周钰, IBM中国 企业架构师 中国前50 Elastic持证者

Elasticsearch作为一款优秀的开源分布式搜索引擎,被广泛应用在日志分析、站内搜索、指标监控、数据加速等场景,学习并掌握ES,已经成为一个技术工作人员不可或缺的重要技能之一。而本书深入浅出,对Elasticsearch的基本概念、设计原理及实践进行了详细介绍,是学习Elasticsearch的必备资料。诚挚推荐。

—— 吴荣,Elasticsearch平台资深研发工程师

一份专业、细致、用户友好的技术文档能给我们技术人员的日常工作带来多大的帮助,相信大家都有深刻的体会,特别是像Elasticsearch这种在搜索引擎领域最广泛应用的解决方案更是如此。虽然官方文档内容很详尽,更新很及时,但是限于语言、网速等问题,广大国内开发者并不能很准确高效的找到自己需要的内容。铭毅老师这本,兼顾了内容的专业性、严谨性、完整性,围绕着Elasticsearch及其相关组件所撰写,覆盖了从基础概念到高级用法的方方面面内容的专业书籍,能给各位带来的价值就不言而喻了。这本书适合从入门使用到高级调优的各层次的读者,是一本少有的适合放在案头常看常新的书。

—— 陈晨(死敌wen),资深搜索架构师、Elastic认证专家

5.png

15位大佬评价批量导入 Elasticsearch

15位大佬评价 Kibana 可视化

6.png

15位大佬评价词云图

7.png

无论您是大数据检索领域的初学者、开发和运维人员,还是架构师和管理人员,这本书都将成为实战路上的得力助手和“避坑指南”。

8.png

立即购买以获取专属福利:不论您从哪里购买、不论多少费用购买,记得保留购物链接和发票,费用都可以折算同等价格的星球优惠券。

私V信:elastic6 搞定后续一切流程。 ————————————————

                        本文为博主原创文章,未经博主书面授权不得转载。书面授权后方可转载,但转载请务必加上原作者:铭毅天下,原文地址:blog.csdn.net/laoyang360

原文链接:https://blog.csdn.net/laoyang360/article/details/135614659

继续阅读 »

今天,非常高兴地跟大家宣布,经过 7 年多的努力和精心准备,我们的新书《一本书讲透 Elasticsearch》已正式出版上线! ​​

1.png

​​​​​​ 我从 2016 年接触 Elasticsearch 1.X、2.X 的版本,到现在已经接近 8 年+的时间。在这期间,我常常被问到:

如何系统性地学习 Elasticsearch ?

如何将现有的关系型数据库迁移到 ES ?

如何选择合适的版本?

如何规划和监控集群?

如何进行数据建模?

如何选择合适的检索方式?

如何基于现有数据进行可视化分析?

等一系列问题.......

这些问题促使我将之前的产品开发、项目实战经验和咨询经验进行全面整合,并精心梳理,融入到这本新书中,希望能让大家少走不必要的弯路。

一、书籍特点 本书具有以下几个显著特点:

最新版本,前沿知识点

本书基于 8.x 版本编写,涵盖了如索引生命周期管理、快照生命周期管理、数据流 datastream 等至关重要的新特性。

核心知识,系统认知

我们为您提供了清晰的学习路径,保留了最核心的“最少必要”知识点,并通过思维导图和大量图解内容,帮助读者更易理解和吸收。

实际应用,超越认证

覆盖Elastic官方认证的核心知识点,已帮助近200人通过Elastic专家认证考试。内容不仅限于认证,更注重实际应用。

来源于实战,应用于实战

书中内容源自真实项目案例和企业级问题解答(问题来自于Elasticsearch中文社区、死磕Elasticsearch知识星球、微信群、QQ群等)。涵盖3个实战项目,助力读者将技能应用到企业实战环境中。

代码开源,答疑服务

全书的代码、脚本在GitHub上开源,便于初学者通过实践学习。我们的答疑社群将持续跟踪最新问题,不断迭代更新内容。

二、5 个最尖锐问题快问快答 如下的问题来自 ChatGPT 4.0 的作为专业读者提出的 5 个最尖锐问题。

2.png

我快速回答一下:

2.1 问题1:市场竞争和定位问题 “市面上已有接近10本关于Elasticsearch的书籍,您的书与这些现有书籍相比有何独特之处?您是如何确保您的书在内容上与其他书籍区别开来,满足读者新的或更深入的需求的?”

铭毅天下:

1、独特之处:版本咱们是目前市场唯一的 8.X 版本。

2、区别开来:我从 2016 年开始搞 ElasticStack 到现在几乎平均每周一篇技术博客,从未间断。无需多说,时间能证明一切!这是咱们最大的不同之一。

3、还有不同:我自己公众号+博客有累计近 4.5 万+关注读者,知识星球有近2000人付费用户,这些大量的实战问题促使我唯有“自我革命”才能生存和成长!

2.2 问题2:实用性和更新性问题 “鉴于Elasticsearch技术持续发展和迭代,您的书籍是如何处理和包含最新版本的特性和变化的?在提供最新信息的同时,您如何保证书中内容的长期有效性和实用性?”

铭毅天下:

1、实话说结论,我做不到,市面上任何纸质书都不可能做到。受限于撰写、出版等相较于 Elastic技术栈体系更新的滞后性。

2、但是,我在筛选知识点的时候已充分考虑结合企业级实战以及 Elastic 官方认证考试的最核心、最关键的“最少必要知识”作为咱们的提纲,并且承诺后面继续根据读者反馈迭代和升级。

2.3 问题3:作者经验和权威性问题 “您能否分享一些您个人在Elasticsearch领域的实战经验或特殊贡献,这些经验如何在您的书中得到体现?作为作者,您相比其他书籍作者有哪些独特的优势或视角?”

铭毅天下:

1、本人持续深耕大数据存储和检索领域 7 年+,有博客为证!有丰富的项目实战经验和企业级实战问题咨询经验,已带领近200人+通过 Elastic 认证专家考试。

2、独特视角就是:来自全国乃至全球多个国家的实战问题——自己运营的知识星球、微信群、QQ群多达数千人,每天都有大量实战问题涌现。

3、作者是坚定的长期主义者:博客已写12年+,从未间断!相信积累的力量、相信坚持的力量、相信相信的力量!

2.4 问题4:读者受益问题 “您认为读者在阅读您的书籍之后,最具体和显著的收获会是什么?有哪些实际的技能或知识可以直接应用到他们的工作和项目中?”

铭毅天下:

1、少走不必要的弯路!

2、能获得属于自己的专属学习路线,能建立专属的知识体系,能将 Elasticsearch 原理、开发、运维、架构技能应用于实战。

2.5 问题5:内容深度和广度问题 “您的书籍是如何平衡Elasticsearch的基础知识和高级技术的?它是否适合所有水平的读者,从初学者到高级用户?对于那些已经具有深厚Elasticsearch知识背景的读者,您的书提供了哪些更深入的见解或独特内容?”

铭毅天下:

1、适合大数据存储和检索领域的初学者,也同样适合有工作经验的中级、高级工程师、架构师等。

2、对于深厚Elasticsearch知识背景的读者,本书可以当做工具书,需要时备查、常翻常新。

三、行业顶级大佬的推荐

3.png

值得一提的是,这本书获得了 Elastic 创始人兼CTO Shay Banon 、Elastic中文社区创始人兼极限科技CTO等15位顶级专家的强力推荐,是一本不可多得的Elasticsearch学习材料。

I am very happy to see that Elasticsearch has been widely used in China, which fully reflects the open source, free and open power of Elastic. This book is derived from the author's 7 years of technical accumulation and embodies the author's love for ElasticStack open source technology. I hope this book can help more people understand Elasticsearch and search technology, so as to discover the great value of data. I am convinced that this book will have a profound impact on Elastic's Chinese community.

我很高兴看到Elasticsearch在中国得到了广泛的应用,这充分体现了Elastic开源、自由、开放的力量。本书源自作者7年的技术积累,体现了作者对ElasticStack开源技术的热爱。希望这本书能够帮助更多的人了解Elasticsearch和搜索技术,从而发现数据的巨大价值。我相信这本书将对 Elastic 的中文社区产生深远的影响。

4.png

——Shay Banon Elastic公司创始人兼首席技术官

很高兴看到铭毅天下的新书出版,《一本书讲透Elasticsearch:原理、进阶与工程实践》是一本值得推荐的新书。它汇集了作者丰富的实战经验,深入探讨 Elasticsearch的 核心原理。书中丰富的图解和清晰的结构使得复杂的知识易于理解和吸收。同时,它覆盖了 Elastic 认证考试的所有考点,助力读者建立全面的认知。此外,书中还包含实战项目,帮助读者将所学技能应用到实际场景中。作者拥有多年实战经验和广泛的影响力,这本书将成为学习和应用 Elasticsearch 的重要指南。

——Medcl,Elastic 中文社区创始人、极限科技创始人

铭毅天下是ES中文社区里少有的常年坚持写作的技术博主,尤其擅长将点状发散的社区讨论进行归纳总结,结合自己的实践和再思考,形成系统性的系列技术文章。本书成于作者在Elasticsearch领域多年的理论知识沉淀,并涵盖了实际应用场景的最佳实践。无论你是Elasticsearch初学者还是有一定经验的开发者,相信都能通过阅读本书而受益匪浅。

—— 吴晓刚 (Wood大叔)携程旅行网 企业数字化平台部 研发总监

在大数据检索和分析领域,Elastic Stack 技术栈有广泛应用,本书从业务场景出发详细介绍了在 Elasticsearch 擅长的各类场景中完成业务系统开发所需的技术栈和技术手段,为用户系统选型和了解整体技术架构提供了指导,可以帮助用户少走弯路,快速完成系统建设。

——张超 《Elasticsearch 源码解析与优化实战》作者, Elasticsearch 内核资深研发工程师

本书基于Elasticsearch最新的8.X版本,涵盖了Elasticsearch更加完整、实时的功能。作者拥有丰富的Elasticsearch和写作经验,语言通俗易懂,内容详尽全面。无论你是初学者还是有一定经验的开发人员,本书都能够为你提供更深入的内容和最佳实践。如果你想系统地学习、掌握Elasticsearch,那么这本书绝对是你不可错过的参考书籍。

—— 魏子珺,阿里巴巴elasticsearch内核专家

很高兴为大家推荐这本关于Elasticsearch的技术书籍。本书涵盖了相当丰富的原理讲解和实现技术,更重要的是对实战场景给出了明确的指导案例和代码片段可供参考和使用。即面向开发人员深入讲解了搜索引擎的核心算法与数据结构,也同时给运维人员提供了关键指标的定义和解读。对于想系统学习的初、中级用户,可以按照章节循序渐进的阅读。对于高级用户来说,也可以从 遇到的问题为切入点,直接从某个具体章节入手来测试、寻求解决方案。铭毅天下是Elastic中文社区长期活跃和积极贡献的明星成员。非常兴奋看到他把自己日积月累的知识精华和经验总结在书中分享给广大读者。我相信本书一定可以帮助到处在任何阶段想学习探索Elasticsearch的用户。

——吴斌,Elastic中文社区主席

《一本书讲透Elasticsearch:原理、进阶与工程实践》是一本由一线开发人员撰写的实战指南。作者凭借多年的 Elasticsearch 咨询和教学经验,将复杂的概念以简明易懂的方式呈现给读者。这本书将帮助你深入了解 Elasticsearch,并理解其背后的原理和逻辑。通过学习本书,你将获得全面的知识,从而能够灵活应用 Elasticsearch 解决各种实际问题。相信这本书将成为你掌握 Elasticsearch 的必备工具。

——阮一鸣,eBay 高级研发经理、极客时间『Elasticsearch 核心技术与实战』课程讲师

铭毅在 Elasticsearch 领域深耕多年,勤奋且专注, 同时运营着国内最大的 ES 社群 ,帮助许多同学成功通过了有难度的 Elastic 认证工程师考试。很高兴看到他的新书出版,都说万事开头难,但我相信这本书能够为ES 初学者铺平道路,扫除障碍,澄清疑虑,快速上手!推荐大家阅读!

——魏彬,中国首位 Elastic 认证工程师

《一本书讲透Elasticsearch:原理、进阶与工程实践 》这本书是我极力推荐的一部作品!

我认识铭毅天下很久了,第一次见面记得是2019年在北京的Elastic开发者大会上,但在这之前,我就经常阅读他关于Elasticsearch的技术分享而神交已久。我了解的铭毅天下是一位拥有丰富的Elasticsearch领域知识和经验的专家,他曾在PB级大数据系统项目中发挥关键作用。实施这种大规模,长周期的复杂项目是非常不容易的,无论从系统设计,到实施过程中的问题解决。因此,来自于实践的真知产出,值得我们开卷。

多年来,铭毅天下一直积极、高效地在各种博客和社交媒体上分享与Elasticsearch相关的内容,并密切同步每个版本的更新。在Elasticsearch上,他不仅持续自我精进,还组织了学习小组和社区,帮助其他对Elasticsearch感兴趣的伙伴一起进步。他还带领150多人通过Elastic工程师认证,为许多人的职业发展贡献了力量。

这本书是铭毅天下多年经验的总结,内容涵盖了几乎全部的Elastic认证考点,而且它来自铭毅天下近7年的博客积累,每一章节都经得起时间的考验。因为抓住了平时学习和使用Elasticsearch当中痛点并总结了最佳实践,这些内容不仅阅读量高,而且转发度也很广泛。无论你是想深入了解Elasticsearch的基础知识还是应用实践,这本书都能满足你的需求。

我相信这本书将为读者提供一次全面而深入的学习体验,帮助他们在Elasticsearch领域取得突破。无论你是初学者还是有经验的专业人士,这本书都是不可或缺的指南。我由衷地推荐这本书,相信它会成为你在Elasticsearch学习和实践中的得力伙伴!

——李捷,Elastic 解决方案架构师 Principle Solution Architect

当得知本书成稿的消息时,我的心情是非常激动的,不管是作为一名技术人,还是作为一名搜索引擎的从业者,以及作为一名Elasticsearch中文社区的参与者和建设者。本书作者与我们一起见证了Elastic生态在国内的起步、发展以及到今天的繁荣;有所不同的是,作者有超强的毅力(就像铭毅天下的名字一样),坚持在这个技术方向上深耕了7年之久,在知识、技术和实践等方面有着深厚的经验积累,不但亲力亲为,而且深谙知识社群与实践社区CoP的操盘之道,在自我成长的同时也打造了优质的同行网络,积极影响了一批技术人,其中的优秀者更是通过了Elatics官方认证,极具含金量。本书的出版,一定会给更多技术人带来直接或间接的帮助,同时在个人成长、知识共享与实践社区等方面在业内树立成功的榜样。让我们一起用技术影响世界影响人!

—— 杨振涛,Elastisearch中文社区深圳主席|vivo互联网 研发总监

Elasticsearch是人工智能和大数据时代不可或缺的重要产品,已经成为开发者必备技能。本书汇集了作者多年开发经验、咨询经验、数千个Elasticsearch爱好者的最佳实战。因此在讲解原理的同时,能深入到最佳实践中去,做到深入浅出,非常适合Elasticsearch的初学者以及进阶者。

—— 付磊,快手Elasticsearch负责人,《Redis开发与运维》作者

Elasticsearch 作为一款强大又灵活的数据分析检索工具,值得每一位后端程序员认真学习。铭毅天下的这本《一本书讲透Elasticsearch:原理、进阶与工程实践》,用浅显易懂的语言介绍了Elasticsearch的概念、原理和实践,非常值得阅读!

—— 程序员小灰,公众号【程序员小灰】运营者,畅销书《漫画算法》作者

铭毅是我的老友,他是一个及其认证踏实和执着追究技术的人,这七年来他一直热心Elasticstack相关技术的步道,热忱帮助社区和公众号里的伙伴,成就不俗。本书是一本实用性极高的Elasticsearch的实践类书籍,更是铭毅倾尽所学之作。通读原稿后,让我非常欣赏的地方在于,它是市面上难得一见的把Elasticsearch原理,实现方式,最佳实践,以及实战案例串联在一起实操类书籍,无论是初学者还是需要进阶学习的人员都能从中获取想要的内容。十分适合想要在企业环境中落地Elasticsearch的人们,因此我诚意把它推荐给广大的技术爱好者和相关从业人员。

——周钰, IBM中国 企业架构师 中国前50 Elastic持证者

Elasticsearch作为一款优秀的开源分布式搜索引擎,被广泛应用在日志分析、站内搜索、指标监控、数据加速等场景,学习并掌握ES,已经成为一个技术工作人员不可或缺的重要技能之一。而本书深入浅出,对Elasticsearch的基本概念、设计原理及实践进行了详细介绍,是学习Elasticsearch的必备资料。诚挚推荐。

—— 吴荣,Elasticsearch平台资深研发工程师

一份专业、细致、用户友好的技术文档能给我们技术人员的日常工作带来多大的帮助,相信大家都有深刻的体会,特别是像Elasticsearch这种在搜索引擎领域最广泛应用的解决方案更是如此。虽然官方文档内容很详尽,更新很及时,但是限于语言、网速等问题,广大国内开发者并不能很准确高效的找到自己需要的内容。铭毅老师这本,兼顾了内容的专业性、严谨性、完整性,围绕着Elasticsearch及其相关组件所撰写,覆盖了从基础概念到高级用法的方方面面内容的专业书籍,能给各位带来的价值就不言而喻了。这本书适合从入门使用到高级调优的各层次的读者,是一本少有的适合放在案头常看常新的书。

—— 陈晨(死敌wen),资深搜索架构师、Elastic认证专家

5.png

15位大佬评价批量导入 Elasticsearch

15位大佬评价 Kibana 可视化

6.png

15位大佬评价词云图

7.png

无论您是大数据检索领域的初学者、开发和运维人员,还是架构师和管理人员,这本书都将成为实战路上的得力助手和“避坑指南”。

8.png

立即购买以获取专属福利:不论您从哪里购买、不论多少费用购买,记得保留购物链接和发票,费用都可以折算同等价格的星球优惠券。

私V信:elastic6 搞定后续一切流程。 ————————————————

                        本文为博主原创文章,未经博主书面授权不得转载。书面授权后方可转载,但转载请务必加上原作者:铭毅天下,原文地址:blog.csdn.net/laoyang360

原文链接:https://blog.csdn.net/laoyang360/article/details/135614659

收起阅读 »

从白日梦到现实:推出 Elastic 的管道查询语言 ES|QL

原文:https://elasticstack.blog.csdn ... 86439


!(https://img-blog.csdnimg.cn/a5 ... 63.png)

今天,我们很高兴地宣布 Elastic® 的新管道查询语言 [ES|QL](https://www.elastic.co/guide/e ... .html "ES|QL")(Elasticsearch 查询语言)的技术预览版,它可以转换、丰富和简化数据调查。 ES|QL 由新的查询引擎提供支持,通过并发处理提供高级搜索功能,无论数据源和结构如何,都可以提高速度和效率。 通过在单个屏幕上创建聚合和可视化来快速解决问题,以实现迭代和流畅的工作流程。

ES|QL 介绍

Elasticsearch 的演变
-----------------

在过去 13 年中,[Elasticsearch®](https://www.elastic.co/elasticsearch/ "Elasticsearch®") 取得了显着发展,适应了用户需求和不断变化的数字环境。 Elasticsearch 最初用于全文搜索,后来根据用户反馈扩展到支持更广泛的用例。 在整个过程中,Elasticsearch [Query DSL](https://www.elastic.co/guide/e ... .html "Query DSL")(我们第一个采用的搜索语言)为过滤器、聚合和其他操作提供了丰富的查询集。 这种基于 JSON 的 DSL 最终成为我们 [_search](https://www.elastic.co/guide/e ... .html "_search") API 端点的基础。

随着时间的推移和需求的多样化,逐渐显现出用户需要的不仅仅是查询 DSL 所提供的功能。我们开始在查询 DSL 下引入和融合了其他 DSL,用于[脚本编写](https://www.elastic.co/guide/e ... .html "脚本编写")、安全调查中的[事件](https://www.elastic.co/guide/e ... .html "事件")等等。然而,尽管这些扩展功能非常多才多艺,它们并没有完全满足用户的一些需求。

用户想要一种能够:

*   简化威胁和安全调查,同时通过提供全面和迭代方法的单个查询观察和解决生产问题
*   通过单一界面搜索、丰富、聚合和可视化更多内容来简化数据调查
*   使用高级搜索功能(例如带有并发处理的查找)提高查询大量数据的速度和效率,无论来源和结构如何

更多阅读,请点击 https://elasticstack.blog.csdn ... 86439
继续阅读 »
原文:https://elasticstack.blog.csdn ... 86439


!(https://img-blog.csdnimg.cn/a5 ... 63.png)

今天,我们很高兴地宣布 Elastic® 的新管道查询语言 [ES|QL](https://www.elastic.co/guide/e ... .html "ES|QL")(Elasticsearch 查询语言)的技术预览版,它可以转换、丰富和简化数据调查。 ES|QL 由新的查询引擎提供支持,通过并发处理提供高级搜索功能,无论数据源和结构如何,都可以提高速度和效率。 通过在单个屏幕上创建聚合和可视化来快速解决问题,以实现迭代和流畅的工作流程。

ES|QL 介绍

Elasticsearch 的演变
-----------------

在过去 13 年中,[Elasticsearch®](https://www.elastic.co/elasticsearch/ "Elasticsearch®") 取得了显着发展,适应了用户需求和不断变化的数字环境。 Elasticsearch 最初用于全文搜索,后来根据用户反馈扩展到支持更广泛的用例。 在整个过程中,Elasticsearch [Query DSL](https://www.elastic.co/guide/e ... .html "Query DSL")(我们第一个采用的搜索语言)为过滤器、聚合和其他操作提供了丰富的查询集。 这种基于 JSON 的 DSL 最终成为我们 [_search](https://www.elastic.co/guide/e ... .html "_search") API 端点的基础。

随着时间的推移和需求的多样化,逐渐显现出用户需要的不仅仅是查询 DSL 所提供的功能。我们开始在查询 DSL 下引入和融合了其他 DSL,用于[脚本编写](https://www.elastic.co/guide/e ... .html "脚本编写")、安全调查中的[事件](https://www.elastic.co/guide/e ... .html "事件")等等。然而,尽管这些扩展功能非常多才多艺,它们并没有完全满足用户的一些需求。

用户想要一种能够:

*   简化威胁和安全调查,同时通过提供全面和迭代方法的单个查询观察和解决生产问题
*   通过单一界面搜索、丰富、聚合和可视化更多内容来简化数据调查
*   使用高级搜索功能(例如带有并发处理的查找)提高查询大量数据的速度和效率,无论来源和结构如何

更多阅读,请点击 https://elasticstack.blog.csdn ... 86439 收起阅读 »

ES 关于 remote_cluster 的一记小坑

最近有小伙伴找到我们说 Kibana 上添加不了 Remote Cluster,填完信息点 Save 直接跳回原界面了。具体页面,就和没添加前一样。

我们和小伙伴虽然隔着网线但还是进行了深入、详细的交流,梳理出来了如下信息:

  1. 两个集群:集群 A 和集群 B ,版本都是 7.10.0 ;
    1. 集群 A 没区分节点角色;
    2. 集群 B 设置了 独立的 master 节点、coordinator 节点和 data 节点,其中 data 节点还带 remote_cluster_client 角色;
  2. 在集群 A 的 Kibana 可以添加 集群 B 为远程集群;
  3. 在集群 B 添加 集群 A 就不行,Kibana 跳回之前的页面;
  4. 网络组确认已经放开策略,网络测试也正常;

翻看了 ES 和 Kibana 的日志, ES 日志中有连接失败的错误信息, Kibana 日志中无对应输出。

[2023-09-13T11:38:41,055][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.mode] from [SNIFF] to [sniff]
[2023-09-13T11:38:41,055][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.seeds] from [[]] to [["127.0.0.1:7102"]]
[2023-09-13T11:38:41,056][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.mode] from [SNIFF] to [sniff]
[2023-09-13T11:38:41,056][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.seeds] from [[]] to [["127.0.0.1:7102"]]
[2023-09-13T11:38:41,057][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.mode] from [SNIFF] to [sniff]
[2023-09-13T11:38:41,057][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.seeds] from [[]] to [["127.0.0.1:7102"]]
[2023-09-13T11:38:41,093][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.mode] from [SNIFF] to [sniff]
[2023-09-13T11:38:41,094][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.seeds] from [[]] to [["127.0.0.1:7102"]]
[2023-09-13T11:38:41,094][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.mode] from [SNIFF] to [sniff]
[2023-09-13T11:38:41,094][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.seeds] from [[]] to [["127.0.0.1:7102"]]
[2023-09-13T11:38:41,095][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.mode] from [SNIFF] to [sniff]
[2023-09-13T11:38:41,096][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.seeds] from [[]] to [["127.0.0.1:7102"]]
[2023-09-13T11:38:51,099][WARN ][o.e.t.RemoteClusterService] [710-1] failed to connect to new remote cluster test within 10s
[2023-09-13T11:39:11,101][WARN ][o.e.t.SniffConnectionStrategy] [710-1] fetching nodes from external cluster [test] failed
org.elasticsearch.transport.ConnectTransportException: [][127.0.0.1:7102] handshake_timeout[30s]
    at org.elasticsearch.transport.TransportHandshaker.lambda$sendHandshake$1(TransportHandshaker.java:73) ~[elasticsearch-7.10.2.jar:7.10.2]
    at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:684) ~[elasticsearch-7.10.2.jar:7.10.2]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) [?:?]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) [?:?]
    at java.lang.Thread.run(Thread.java:832) [?:?]

已经测试过网络是通的,开始尝试把集群 B 的角色配置统统去掉再尝试。
嘿,添加成功了。
接下来为了找出问题,开始一步一步给每个节点再加回原来的角色。而且如果节点原来没有 remote_cluster_client 角色,这次也一并加上。
操作过程

  • 先从 data 节点开始,恢复角色,尝试添加远程集群,失败。
  • 接着 coordinate 节点 , 恢复角色且新增 remote_cluster_client 角色,尝试添加远程集群,失败。
  • 最后 master 节点,恢复角色且新增 remote_cluster_client 角色,尝试添加远程集群,成功。

最终直到所有节点都有 remote_cluster_client 角色后,才成功添加远程集群。
结论: ES 集群添加远程集群所有节点都必须拥有 remote_cluster_client 角色。
事情到这里,似乎没什么问题。但当我们对这个结论进行检验时,又有了新发现。
上面的场景忽视了一个因素 -- Kibana 。于是我们搭建了一个两个节点的集群,其中节点 A 是全角色节点,节点 B 只是 data 节点。让 Kibana 分别连接两个节点进行测试。
验证结果

  • 当 Kibana 连接节点 A 时,可以正常添加。
  • Kibana 连接节点 B 时,添加失败,跳回界面。

结论:ES 集群添加远程集群时,Kibana 连接的 ES 节点必须拥有 remote_cluster_client 角色。
很显然,这个结论更合理。

原因分析
我们是通过 Kibana 界面操作去添加远程集群的, Kibana 连接的节点就被当作 remote_client 。该节点要向远程集群发起连接并执行相关调用。但这一切有个前提,该节点必须有 remote_cluster_client 角色才能向远程集群发起连接。 引申
我们的 CCS 操作也必须发送到一个具有 remote_cluster_client 角色的节点,才能成功执行。

参考连接 https://www.elastic.co/guide/en/elasticsearch/reference/7.10/modules-node.html

继续阅读 »

最近有小伙伴找到我们说 Kibana 上添加不了 Remote Cluster,填完信息点 Save 直接跳回原界面了。具体页面,就和没添加前一样。

我们和小伙伴虽然隔着网线但还是进行了深入、详细的交流,梳理出来了如下信息:

  1. 两个集群:集群 A 和集群 B ,版本都是 7.10.0 ;
    1. 集群 A 没区分节点角色;
    2. 集群 B 设置了 独立的 master 节点、coordinator 节点和 data 节点,其中 data 节点还带 remote_cluster_client 角色;
  2. 在集群 A 的 Kibana 可以添加 集群 B 为远程集群;
  3. 在集群 B 添加 集群 A 就不行,Kibana 跳回之前的页面;
  4. 网络组确认已经放开策略,网络测试也正常;

翻看了 ES 和 Kibana 的日志, ES 日志中有连接失败的错误信息, Kibana 日志中无对应输出。

[2023-09-13T11:38:41,055][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.mode] from [SNIFF] to [sniff]
[2023-09-13T11:38:41,055][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.seeds] from [[]] to [["127.0.0.1:7102"]]
[2023-09-13T11:38:41,056][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.mode] from [SNIFF] to [sniff]
[2023-09-13T11:38:41,056][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.seeds] from [[]] to [["127.0.0.1:7102"]]
[2023-09-13T11:38:41,057][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.mode] from [SNIFF] to [sniff]
[2023-09-13T11:38:41,057][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.seeds] from [[]] to [["127.0.0.1:7102"]]
[2023-09-13T11:38:41,093][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.mode] from [SNIFF] to [sniff]
[2023-09-13T11:38:41,094][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.seeds] from [[]] to [["127.0.0.1:7102"]]
[2023-09-13T11:38:41,094][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.mode] from [SNIFF] to [sniff]
[2023-09-13T11:38:41,094][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.seeds] from [[]] to [["127.0.0.1:7102"]]
[2023-09-13T11:38:41,095][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.mode] from [SNIFF] to [sniff]
[2023-09-13T11:38:41,096][INFO ][o.e.c.s.ClusterSettings  ] [710-1] updating [cluster.remote.test.seeds] from [[]] to [["127.0.0.1:7102"]]
[2023-09-13T11:38:51,099][WARN ][o.e.t.RemoteClusterService] [710-1] failed to connect to new remote cluster test within 10s
[2023-09-13T11:39:11,101][WARN ][o.e.t.SniffConnectionStrategy] [710-1] fetching nodes from external cluster [test] failed
org.elasticsearch.transport.ConnectTransportException: [][127.0.0.1:7102] handshake_timeout[30s]
    at org.elasticsearch.transport.TransportHandshaker.lambda$sendHandshake$1(TransportHandshaker.java:73) ~[elasticsearch-7.10.2.jar:7.10.2]
    at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:684) ~[elasticsearch-7.10.2.jar:7.10.2]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) [?:?]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) [?:?]
    at java.lang.Thread.run(Thread.java:832) [?:?]

已经测试过网络是通的,开始尝试把集群 B 的角色配置统统去掉再尝试。
嘿,添加成功了。
接下来为了找出问题,开始一步一步给每个节点再加回原来的角色。而且如果节点原来没有 remote_cluster_client 角色,这次也一并加上。
操作过程

  • 先从 data 节点开始,恢复角色,尝试添加远程集群,失败。
  • 接着 coordinate 节点 , 恢复角色且新增 remote_cluster_client 角色,尝试添加远程集群,失败。
  • 最后 master 节点,恢复角色且新增 remote_cluster_client 角色,尝试添加远程集群,成功。

最终直到所有节点都有 remote_cluster_client 角色后,才成功添加远程集群。
结论: ES 集群添加远程集群所有节点都必须拥有 remote_cluster_client 角色。
事情到这里,似乎没什么问题。但当我们对这个结论进行检验时,又有了新发现。
上面的场景忽视了一个因素 -- Kibana 。于是我们搭建了一个两个节点的集群,其中节点 A 是全角色节点,节点 B 只是 data 节点。让 Kibana 分别连接两个节点进行测试。
验证结果

  • 当 Kibana 连接节点 A 时,可以正常添加。
  • Kibana 连接节点 B 时,添加失败,跳回界面。

结论:ES 集群添加远程集群时,Kibana 连接的 ES 节点必须拥有 remote_cluster_client 角色。
很显然,这个结论更合理。

原因分析
我们是通过 Kibana 界面操作去添加远程集群的, Kibana 连接的节点就被当作 remote_client 。该节点要向远程集群发起连接并执行相关调用。但这一切有个前提,该节点必须有 remote_cluster_client 角色才能向远程集群发起连接。 引申
我们的 CCS 操作也必须发送到一个具有 remote_cluster_client 角色的节点,才能成功执行。

参考连接 https://www.elastic.co/guide/en/elasticsearch/reference/7.10/modules-node.html

收起阅读 »

如何在ES中搜索值为空的键值对

问题背景

今天早上,接到开发那边一个特殊的查询需求,在 Kibana 中搜索一个 json 类型日志中值为一个空大括号的键值对, 具体的日志示例如下:

{
    "clientIp": "10.111.121.51",
    "query": "{}",
    "serviceUrl": "/aaa/bbb/cc",
}

也就是说针对这个类型的日志过滤出 query 值为空的请求 "query": "{}", 开发同学测试了直接在 kibana 中查询这个字符串 "query": "{}" 根本查不到我们想要的结果。 我们使用的是 ELK 8.3 的全家桶, 这个日志数据使用的默认 standard analyzer 的分词器。

初步分析

我们先对这个要查询的字符串进行下分词测试:

GET /_analyze
{
"analyzer" : "standard",
"text": "\"query\":\"{}\""
}

结果不出所料,我们想要空大括号在分词的时候直接就被干掉了,仅保留了 query 这一个 token:

{
  "tokens": [{
    "token": "query",
    "start_offset": 1,
    "end_offset": 6,
    "type": "<ALPHANUM>",
    "position": 0
  }]
}

我们使用的 standard analyzer 在数据写入分词时直接抛弃掉{}等特殊字符,看来直接搜索 "query": "{}" 关键词这条路肯定是走不通。

换个思路

在网上搜索了一下解决的办法,有些搜索特殊字符的办法,但需要修改分词器,我们已经写入的日志数据量比较大,不太愿意因为这个搜索请求来修改分词器再 reindex。 但是我们的日志格式是固定的,serviceUrl 这个键值对总是在 query 后面的,那么我们可以结合前后文实现相同的 搜索效果:

GET /_analyze
{
"analyzer" : "standard",
"text": "\"query\":\"{}\",\"serviceUrl\""
}

可以看到这段被分为 2 个相邻的单词

{
"tokens": [{
"token": "query",
"start_offset": 1,
"end_offset": 6,
"type": "<ALPHANUM>",
"position": 0
},
{
"token": "serviceurl",
"start_offset": 14,
"end_offset": 24,
"type": "<ALPHANUM>",
"position": 1
}
]
}

那么通过搜索 query 和 serviceUrl 为相邻的 2 个字是完全可以实现 query 的值为空的同样的查询效果。 为了确认在我们已经写入的数据中 query 和 serviceurl 也是相邻的,我们通过 ES termvectors API 确认了已经在 es 中的数据和我们这里测试的情况相同:

GET /<index>/_termvectors/<_id>?fields=message

"query" : {
  "term_freq" : 1,
  "tokens" : [
    {
      "position" : 198,
      "start_offset" : 2138,
      "end_offset" : 2143
    }
  ]
},
"serviceurl" : {
  "term_freq" : 1,
  "tokens" : [
    {
      "position" : 199,
      "start_offset" : 2151,
      "end_offset" : 2161
    }
  ]
},

这里我们可以看到 query 在 message 字段里面出现一次,其 end_offset 和 serviceurl 的 start_offset 之前也是相差 8, 和我们测试的结果相同。 这个时候我们就将原来的查询需求,转化为了对 "query serviceurl" 进行按顺序的精准查询就行了, 使用 match_phrase 可以达到我们的目的。

GET /_search
"query": {
    "match_phrase": {
        "message": {
            "query": "query serviceurl",
            "slop" : 0

        }
    }
}

这里顺便说一下,slop 这个参数,slop=n 表示,表示可以隔 n 个字(英文词)进行匹配, 这里设置为 0 就强制要求 query 和 serviceurl 这 2 个单词必须相邻,0 也是 slop 的默认值,在这个请求中是可以省略的,这是为什么 match_phrase 是会获得精准查询的原因之一。 好了,我们通过 console 确定了有效的 query 之后,对于开发同学查看日志只需要在 Kibana 的搜索栏中直接使用双引号引起来的精确搜索 "query serviceurl" 就可以了。

继续深挖一下,ngram 分词器

虽然开发同学搜索的问题解决了,但我仍然不太满意,毕竟这次的问题我们的日志格式是固定的,如果我们一定要搜索到 "query": "{}" 这个应该怎么办呢? 首先很明确,使用我们默认的 standard analyzer 不修改任何参数肯定是不行的,"{}" 这些特殊字符都直接被干掉了, 参考了网上找到的这篇文章,https://blog.csdn.net/fox_233/article/details/127388058 按照这个 ngram 分词器的思路,我动手对我们的需求进行了下测试

首先先看看我们使用 ngram 分词器的分词效果, 我们这里简化了一下,去掉了原来的双引号,以避免过多 \:

GET _analyze
{
  "tokenizer": "ngram",
  "text": "query:{}"
}

{
  "tokens" : [
    {
      "token" : "q",
      "start_offset" : 0,
      "end_offset" : 1,
      "type" : "word",
      "position" : 0
    },
    ...
    {
      "token" : "{",
      "start_offset" : 6,
      "end_offset" : 7,
      "type" : "word",
      "position" : 12
    },
    {
      "token" : "{}",
      "start_offset" : 6,
      "end_offset" : 8,
      "type" : "word",
      "position" : 13
    },
    {
      "token" : "}",
      "start_offset" : 7,
      "end_offset" : 8,
      "type" : "word",
      "position" : 14
    }
  ]
}

可以很明显的看到大括号被成功的分词了,果然是有戏。 直接定义一个 index 实战一下搜索效果

PUT specialchar_debug
{
  "settings": {
    "analysis": {
      "analyzer": {
        "specialchar_analyzer": {
          "tokenizer": "specialchar_tokenizer"
        }
      },
      "tokenizer": {
        "specialchar_tokenizer": {
          "type": "ngram",
          "min_gram": 1,
          "max_gram": 2
        }
      }
    }
  },
  "mappings": {
      "properties": {
        "text": {
          "analyzer": "specialchar_analyzer",
          "type": "text"
        }
      }
    }
}

插入几条测试数据:

PUT specialchar_debug/_doc/1
{  "text": "query:{},serviceUrl"
}

PUT specialchar_debug/_doc/2
{  "text": "query:{aaa},serviceUrl"
}

PUT specialchar_debug/_doc/3
{  "text": "query:{bbb}, ccc, serviceUrl"
}

我们再测试一下搜索效果,

GET specialchar_debug/_search
{
  "query": {
    "match_phrase": {
      "text": "query:{}"
    }
  }
}

结果完全是我们想要的,看来这个方案可行

"hits" : [
  {
    "_index" : "specialchar_debug",
    "_id" : "1",
    "_score" : 2.402917,
    "_source" : {
      "text" : "query:{},serviceUrl"
    }
  }
]

小结

对于日志系统,我们一直在使用 ES 默认的 standard analyzer 的分词器, 基本上满足我们生产遇到的 99% 的需求,但面对特殊字符的这种搜索请求,确实比较无奈。这次遇到的空键值对的需求,我们通过搜索 2 个相邻的键绕过了问题。 如果一定要搜索这个字符串的话,我们也可以使用 ngram 分词器重新进行分词再进行处理, 条条大路通罗马。

作者介绍

卞弘智,研发工程师,10 多年的 SRE 经验,工作经历涵盖 DevOps,日志处理系统,监控和告警系统研发,WAF 和网关等系统基础架构领域,致力于通过优秀的开源软件推动自动化和智能化基础架构平台的演进。

继续阅读 »

问题背景

今天早上,接到开发那边一个特殊的查询需求,在 Kibana 中搜索一个 json 类型日志中值为一个空大括号的键值对, 具体的日志示例如下:

{
    "clientIp": "10.111.121.51",
    "query": "{}",
    "serviceUrl": "/aaa/bbb/cc",
}

也就是说针对这个类型的日志过滤出 query 值为空的请求 "query": "{}", 开发同学测试了直接在 kibana 中查询这个字符串 "query": "{}" 根本查不到我们想要的结果。 我们使用的是 ELK 8.3 的全家桶, 这个日志数据使用的默认 standard analyzer 的分词器。

初步分析

我们先对这个要查询的字符串进行下分词测试:

GET /_analyze
{
"analyzer" : "standard",
"text": "\"query\":\"{}\""
}

结果不出所料,我们想要空大括号在分词的时候直接就被干掉了,仅保留了 query 这一个 token:

{
  "tokens": [{
    "token": "query",
    "start_offset": 1,
    "end_offset": 6,
    "type": "<ALPHANUM>",
    "position": 0
  }]
}

我们使用的 standard analyzer 在数据写入分词时直接抛弃掉{}等特殊字符,看来直接搜索 "query": "{}" 关键词这条路肯定是走不通。

换个思路

在网上搜索了一下解决的办法,有些搜索特殊字符的办法,但需要修改分词器,我们已经写入的日志数据量比较大,不太愿意因为这个搜索请求来修改分词器再 reindex。 但是我们的日志格式是固定的,serviceUrl 这个键值对总是在 query 后面的,那么我们可以结合前后文实现相同的 搜索效果:

GET /_analyze
{
"analyzer" : "standard",
"text": "\"query\":\"{}\",\"serviceUrl\""
}

可以看到这段被分为 2 个相邻的单词

{
"tokens": [{
"token": "query",
"start_offset": 1,
"end_offset": 6,
"type": "<ALPHANUM>",
"position": 0
},
{
"token": "serviceurl",
"start_offset": 14,
"end_offset": 24,
"type": "<ALPHANUM>",
"position": 1
}
]
}

那么通过搜索 query 和 serviceUrl 为相邻的 2 个字是完全可以实现 query 的值为空的同样的查询效果。 为了确认在我们已经写入的数据中 query 和 serviceurl 也是相邻的,我们通过 ES termvectors API 确认了已经在 es 中的数据和我们这里测试的情况相同:

GET /<index>/_termvectors/<_id>?fields=message

"query" : {
  "term_freq" : 1,
  "tokens" : [
    {
      "position" : 198,
      "start_offset" : 2138,
      "end_offset" : 2143
    }
  ]
},
"serviceurl" : {
  "term_freq" : 1,
  "tokens" : [
    {
      "position" : 199,
      "start_offset" : 2151,
      "end_offset" : 2161
    }
  ]
},

这里我们可以看到 query 在 message 字段里面出现一次,其 end_offset 和 serviceurl 的 start_offset 之前也是相差 8, 和我们测试的结果相同。 这个时候我们就将原来的查询需求,转化为了对 "query serviceurl" 进行按顺序的精准查询就行了, 使用 match_phrase 可以达到我们的目的。

GET /_search
"query": {
    "match_phrase": {
        "message": {
            "query": "query serviceurl",
            "slop" : 0

        }
    }
}

这里顺便说一下,slop 这个参数,slop=n 表示,表示可以隔 n 个字(英文词)进行匹配, 这里设置为 0 就强制要求 query 和 serviceurl 这 2 个单词必须相邻,0 也是 slop 的默认值,在这个请求中是可以省略的,这是为什么 match_phrase 是会获得精准查询的原因之一。 好了,我们通过 console 确定了有效的 query 之后,对于开发同学查看日志只需要在 Kibana 的搜索栏中直接使用双引号引起来的精确搜索 "query serviceurl" 就可以了。

继续深挖一下,ngram 分词器

虽然开发同学搜索的问题解决了,但我仍然不太满意,毕竟这次的问题我们的日志格式是固定的,如果我们一定要搜索到 "query": "{}" 这个应该怎么办呢? 首先很明确,使用我们默认的 standard analyzer 不修改任何参数肯定是不行的,"{}" 这些特殊字符都直接被干掉了, 参考了网上找到的这篇文章,https://blog.csdn.net/fox_233/article/details/127388058 按照这个 ngram 分词器的思路,我动手对我们的需求进行了下测试

首先先看看我们使用 ngram 分词器的分词效果, 我们这里简化了一下,去掉了原来的双引号,以避免过多 \:

GET _analyze
{
  "tokenizer": "ngram",
  "text": "query:{}"
}

{
  "tokens" : [
    {
      "token" : "q",
      "start_offset" : 0,
      "end_offset" : 1,
      "type" : "word",
      "position" : 0
    },
    ...
    {
      "token" : "{",
      "start_offset" : 6,
      "end_offset" : 7,
      "type" : "word",
      "position" : 12
    },
    {
      "token" : "{}",
      "start_offset" : 6,
      "end_offset" : 8,
      "type" : "word",
      "position" : 13
    },
    {
      "token" : "}",
      "start_offset" : 7,
      "end_offset" : 8,
      "type" : "word",
      "position" : 14
    }
  ]
}

可以很明显的看到大括号被成功的分词了,果然是有戏。 直接定义一个 index 实战一下搜索效果

PUT specialchar_debug
{
  "settings": {
    "analysis": {
      "analyzer": {
        "specialchar_analyzer": {
          "tokenizer": "specialchar_tokenizer"
        }
      },
      "tokenizer": {
        "specialchar_tokenizer": {
          "type": "ngram",
          "min_gram": 1,
          "max_gram": 2
        }
      }
    }
  },
  "mappings": {
      "properties": {
        "text": {
          "analyzer": "specialchar_analyzer",
          "type": "text"
        }
      }
    }
}

插入几条测试数据:

PUT specialchar_debug/_doc/1
{  "text": "query:{},serviceUrl"
}

PUT specialchar_debug/_doc/2
{  "text": "query:{aaa},serviceUrl"
}

PUT specialchar_debug/_doc/3
{  "text": "query:{bbb}, ccc, serviceUrl"
}

我们再测试一下搜索效果,

GET specialchar_debug/_search
{
  "query": {
    "match_phrase": {
      "text": "query:{}"
    }
  }
}

结果完全是我们想要的,看来这个方案可行

"hits" : [
  {
    "_index" : "specialchar_debug",
    "_id" : "1",
    "_score" : 2.402917,
    "_source" : {
      "text" : "query:{},serviceUrl"
    }
  }
]

小结

对于日志系统,我们一直在使用 ES 默认的 standard analyzer 的分词器, 基本上满足我们生产遇到的 99% 的需求,但面对特殊字符的这种搜索请求,确实比较无奈。这次遇到的空键值对的需求,我们通过搜索 2 个相邻的键绕过了问题。 如果一定要搜索这个字符串的话,我们也可以使用 ngram 分词器重新进行分词再进行处理, 条条大路通罗马。

作者介绍

卞弘智,研发工程师,10 多年的 SRE 经验,工作经历涵盖 DevOps,日志处理系统,监控和告警系统研发,WAF 和网关等系统基础架构领域,致力于通过优秀的开源软件推动自动化和智能化基础架构平台的演进。

收起阅读 »

用极限网关实现ES容灾,简单!

身为 IT 人士,大伙身边的各种系统肯定不少吧。系统虽多,但最最最重要的那套、那几套,大伙肯定是捧在手心,关怀备至。如此重要的系统,万一发生故障了且短期无法恢复,该如何保障业务持续运行? 有过这方面思考或经验的同学,肯定脱口而出--切灾备啊。 是的,接下来我来介绍下我们的 ES 灾备方案。当然如果你有更好的,请使用各种可用的渠道联系我们。

总体设计

通过极限网关将应用对主集群的写操作,复制到灾备集群。应用发送的读请求则直接转发到主集群,并将响应结果转发给应用。应用对网关无感知,访问方式与访问 ES 集群一样。

方案优势

  • 轻量级

极限网关使用 Golang 编写,安装包很小,只有 10MB 左右,没有任何外部环境依赖,部署安装都非常简单,只需要下载对应平台的二进制可执行文件,启动网关程序的二进制程序文件执行即可。

  • 跨版本支持

极限网关针对不同的 Elasticsearch 版本做了兼容和针对性处理,能够让业务代码无缝的进行适配,后端 Elasticsearch 集群版本升级能够做到无缝过渡,降低版本升级和数据迁移的复杂度。

  • 高可用

极限网关内置多种高可用解决方案,前端请求入口支持基于虚拟 IP 的双机热备,后端集群支持集群拓扑的自动感知,节点上下线能自动发现,自动处理后端故障,自动进行请求的重试和迁移。

  • 灵活性

主备集群都是可读可写,切换迅速,只需切换网关到另一套配置即可。回切灵活,恢复使用原配置即可。

架构图

网关程序部署

下载

根据操作系统和平台选择下面相应的安装包: 解压到指定目录:

mkdir gateway
tar -zxf xxx.gz -C gateway

修改网关配置

在此 下载 网关配置,默认网关会加载配置文件 gateway.yml ,如果要指定其他配置文件使用 -config 选项指定。 网关配置文件内容较多,下面展示必要部分。

  #primary
  PRIMARY_ENDPOINT: http://192.168.56.3:7171
  PRIMARY_USERNAME: elastic
  PRIMARY_PASSWORD: password
  PRIMARY_MAX_QPS_PER_NODE: 10000
  PRIMARY_MAX_BYTES_PER_NODE: 104857600 #100MB/s
  PRIMARY_MAX_CONNECTION_PER_NODE: 200
  PRIMARY_DISCOVERY_ENABLED: false
  PRIMARY_DISCOVERY_REFRESH_ENABLED: false
  #backup
  BACKUP_ENDPOINT: http://192.168.56.3:9200
  BACKUP_USERNAME: admin
  BACKUP_PASSWORD: admin
  BACKUP_MAX_QPS_PER_NODE: 10000
  BACKUP_MAX_BYTES_PER_NODE: 104857600 #100MB/s
  BACKUP_MAX_CONNECTION_PER_NODE: 200
  BACKUP_DISCOVERY_ENABLED: false
  BACKUP_DISCOVERY_REFRESH_ENABLED: false

PRIMARY_ENDPOINT:配置主集群地址和端口
PRIMARY_USERNAME、PRIMARY_PASSWORD: 访问主集群的用户信息
BACKUP_ENDPOINT:配置备集群地址和端口
BACKUP_USERNAME、BACKUP_PASSWORD: 访问备集群的用户信息

运行网关

前台运行 直接运行网关程序即可启动极限网关了,如下:

./gateway-linux-amd64

后台运行

./gateway-linux-amd64 -service install
Success
./gateway-linux-amd64 -service start
Success

卸载服务

./gateway-linux-amd64 -service stop
Success
./gateway-linux-amd64 -service uninstall
Success

灾备功能测试

在灾备场景下,为保证数据一致性,对集群的访问操作都通过网关进行。注意只有 bulk API 的操作才会被复制到备集群。 在此次测试中,网关灾备配置功能为:

  • 主备集群正常时

读写请求正常执行; 写请求被记录到队列,备集群实时消费队列数据。

  • 当主集群故障时

写入请求报错,主备集群都不写入数据; 查询请求转到备集群执行,并返回结果给客户端。

  • 当备集群故障时

读写请求都正常执行; 写操作记录到磁盘队列,待备集群恢复后,自动消费队列数据直到两个集群一致。

主备集群正常时写入、查询测试

写入数据

# 通过网关写入数据
curl -X POST "localhost:18000/_bulk?pretty" -H 'Content-Type: application/json' -uelastic:password -d'
{ "index" : { "_index" : "test", "_id" : "1" } }
{ "field1" : "value1" }
{ "create" : { "_index" : "test", "_id" : "2" } }
{ "field2" : "value2" }
'

查询数据

# 查询主集群
curl 192.168.56.3:7171/test/_search?pretty -uelastic:password

# 查询备集群
curl 192.168.56.3:9200/test/_search?pretty -uadmin:admin

# 查询网关,网关转发给主集群执行
curl 192.168.56.3:18000/test/_search?pretty -uelastic:password

主备集群都已写入数据,且数据一致。通过网关查询,也正常返回。

删除和更新文档

# 通过网关删除和更新文档
curl -X POST "192.168.56.3:18000/_bulk?pretty" -H 'Content-Type: application/json' -uelastic:password -d'
{ "delete" : { "_index" : "test", "_id" : "1" } }
{ "update" : {"_id" : "2", "_index" : "test"} }
{ "doc" : {"field2" : "value2-updated"} }
'

查询数据
# 查询主集群
curl 192.168.56.3:7171/test/_search?pretty -uelastic:password

# 查询备集群
curl 192.168.56.3:9200/test/_search?pretty -uadmin:admin

两个集群都已执行删除和更新操作,数据一致。

主集群故障时写入、查询测试

为模拟主集群故障,直接关闭主集群。

写入数据

# 通过网关写入数据
curl -X POST "192.168.56.3:18000/_bulk?pretty" -H 'Content-Type: application/json' -uelastic:password -d'
{ "index" : { "_index" : "test", "_id" : "3" } }
{ "field3" : "value3" }
{ "create" : { "_index" : "test", "_id" : "4" } }
{ "field4" : "value4" }
'

写入数据报错

查询数据

# 通过网关查询,因为主集群不可用,网关将查询转发到备集群执行
curl 192.168.56.3:18000/test/_search?pretty -uelastic:password

正常查询到数据,说明请求被转发到了备集群执行。

备集群故障时写入、查询测试

为模拟备集群故障,直接关闭备集群。

写入数据

# 通过网关写入数据
curl -X POST "192.168.56.3:18000/_bulk?pretty" -H 'Content-Type: application/json' -uelastic:password -d'
{ "index" : { "_index" : "test", "_id" : "5" } }
{ "field5" : "value5" }
{ "create" : { "_index" : "test", "_id" : "6" } }
{ "field6" : "value6" }
'

数据正常写入。

查询数据

# 通过网关查询
curl 192.168.56.3:18000/test/_search?pretty -uelastic:password

查询成功返回。主集群成功写入了两条新数据。同时此数据会被记录到备集群的队列中,待备集群恢复后,会消费此队列追数据。

恢复备集群

启动备集群。

查询数据

等待片刻或通过 INFINI Console 确定网关队列消费完毕后,查询备集群的数据。 (生产和消费 offset 相同,说明消费完毕。)

# 查询备集群的数据
curl 192.168.56.3:9200/test/_search?pretty -uadmin:admin

备集群启动后自动消费队列数据,消费完后备集群数据达到与主集群数据一致。

灾备切换

测试了这么多,终于到切换的时刻了。切换前我们判断下主系统是否短期无法修复。

如果我们判断主用系统无法短时间恢复,要执行切换。非常简单,我们直接将配置文件中定义的主备集群互换,然后重启网关程序就行了。但我们推荐在相同主机上另部署一套网关程序--网关B,先前那套用网关A指代。网关B中的配置文件把原备集群定义为主集群,原主集群定义为备集群。若要执行切换,我们先停止网关A,然后启动网关B,此时应用连接到网关(端口不变),就把原备系统当作主系统使用,把原主系统当作备系统,也就完成了主备系统的切换。

灾备回切

当原主集群修复后,正常启动,就会从消费队列追写修复期间产生数据直到主备数据一致,同样我们可通过 INFINI Console 查看消费的进度。如果大家还是担心数据的一致性,INFINI Console 还能帮大家做[校验数据]()任务,做到数据完全一致后(文档数量及文档内容一致),才进行回切。

回切也非常简单,停止网关B,启动网关A即可。

网关高可用

网关自带浮动 IP 模块,可进行双机热备。客户端通过 VIP 连接网关,网关出现故障时,VIP 漂移到备网关。 视频教程戳这里

这样的优点是简单,不足是只有一个网关在线提供服务。如果想多个网关在线提供服务,则需搭配分布式消息系统一起工作,架构如下。

前端通过负载均衡将流量分散到多个在线网关,网关将消息存入分布式消息系统。此时,网关可看作无状态应用,可根据需要扩缩规模。

以上就是我介绍的ES灾备方案,是不是相当灵活了。有问题还是那句话 Call me 。

关于极限网关

INFINI Gateway 是一个面向搜索场景的高性能数据网关,所有请求都经过网关处理后再转发到后端的搜索业务集群。基于 INFINI Gateway,可以实现索引级别的限速限流、常见查询的缓存加速、查询请求的审计、查询结果的动态修改等等。

官网文档:https://www.infinilabs.com/docs/latest/gateway

继续阅读 »

身为 IT 人士,大伙身边的各种系统肯定不少吧。系统虽多,但最最最重要的那套、那几套,大伙肯定是捧在手心,关怀备至。如此重要的系统,万一发生故障了且短期无法恢复,该如何保障业务持续运行? 有过这方面思考或经验的同学,肯定脱口而出--切灾备啊。 是的,接下来我来介绍下我们的 ES 灾备方案。当然如果你有更好的,请使用各种可用的渠道联系我们。

总体设计

通过极限网关将应用对主集群的写操作,复制到灾备集群。应用发送的读请求则直接转发到主集群,并将响应结果转发给应用。应用对网关无感知,访问方式与访问 ES 集群一样。

方案优势

  • 轻量级

极限网关使用 Golang 编写,安装包很小,只有 10MB 左右,没有任何外部环境依赖,部署安装都非常简单,只需要下载对应平台的二进制可执行文件,启动网关程序的二进制程序文件执行即可。

  • 跨版本支持

极限网关针对不同的 Elasticsearch 版本做了兼容和针对性处理,能够让业务代码无缝的进行适配,后端 Elasticsearch 集群版本升级能够做到无缝过渡,降低版本升级和数据迁移的复杂度。

  • 高可用

极限网关内置多种高可用解决方案,前端请求入口支持基于虚拟 IP 的双机热备,后端集群支持集群拓扑的自动感知,节点上下线能自动发现,自动处理后端故障,自动进行请求的重试和迁移。

  • 灵活性

主备集群都是可读可写,切换迅速,只需切换网关到另一套配置即可。回切灵活,恢复使用原配置即可。

架构图

网关程序部署

下载

根据操作系统和平台选择下面相应的安装包: 解压到指定目录:

mkdir gateway
tar -zxf xxx.gz -C gateway

修改网关配置

在此 下载 网关配置,默认网关会加载配置文件 gateway.yml ,如果要指定其他配置文件使用 -config 选项指定。 网关配置文件内容较多,下面展示必要部分。

  #primary
  PRIMARY_ENDPOINT: http://192.168.56.3:7171
  PRIMARY_USERNAME: elastic
  PRIMARY_PASSWORD: password
  PRIMARY_MAX_QPS_PER_NODE: 10000
  PRIMARY_MAX_BYTES_PER_NODE: 104857600 #100MB/s
  PRIMARY_MAX_CONNECTION_PER_NODE: 200
  PRIMARY_DISCOVERY_ENABLED: false
  PRIMARY_DISCOVERY_REFRESH_ENABLED: false
  #backup
  BACKUP_ENDPOINT: http://192.168.56.3:9200
  BACKUP_USERNAME: admin
  BACKUP_PASSWORD: admin
  BACKUP_MAX_QPS_PER_NODE: 10000
  BACKUP_MAX_BYTES_PER_NODE: 104857600 #100MB/s
  BACKUP_MAX_CONNECTION_PER_NODE: 200
  BACKUP_DISCOVERY_ENABLED: false
  BACKUP_DISCOVERY_REFRESH_ENABLED: false

PRIMARY_ENDPOINT:配置主集群地址和端口
PRIMARY_USERNAME、PRIMARY_PASSWORD: 访问主集群的用户信息
BACKUP_ENDPOINT:配置备集群地址和端口
BACKUP_USERNAME、BACKUP_PASSWORD: 访问备集群的用户信息

运行网关

前台运行 直接运行网关程序即可启动极限网关了,如下:

./gateway-linux-amd64

后台运行

./gateway-linux-amd64 -service install
Success
./gateway-linux-amd64 -service start
Success

卸载服务

./gateway-linux-amd64 -service stop
Success
./gateway-linux-amd64 -service uninstall
Success

灾备功能测试

在灾备场景下,为保证数据一致性,对集群的访问操作都通过网关进行。注意只有 bulk API 的操作才会被复制到备集群。 在此次测试中,网关灾备配置功能为:

  • 主备集群正常时

读写请求正常执行; 写请求被记录到队列,备集群实时消费队列数据。

  • 当主集群故障时

写入请求报错,主备集群都不写入数据; 查询请求转到备集群执行,并返回结果给客户端。

  • 当备集群故障时

读写请求都正常执行; 写操作记录到磁盘队列,待备集群恢复后,自动消费队列数据直到两个集群一致。

主备集群正常时写入、查询测试

写入数据

# 通过网关写入数据
curl -X POST "localhost:18000/_bulk?pretty" -H 'Content-Type: application/json' -uelastic:password -d'
{ "index" : { "_index" : "test", "_id" : "1" } }
{ "field1" : "value1" }
{ "create" : { "_index" : "test", "_id" : "2" } }
{ "field2" : "value2" }
'

查询数据

# 查询主集群
curl 192.168.56.3:7171/test/_search?pretty -uelastic:password

# 查询备集群
curl 192.168.56.3:9200/test/_search?pretty -uadmin:admin

# 查询网关,网关转发给主集群执行
curl 192.168.56.3:18000/test/_search?pretty -uelastic:password

主备集群都已写入数据,且数据一致。通过网关查询,也正常返回。

删除和更新文档

# 通过网关删除和更新文档
curl -X POST "192.168.56.3:18000/_bulk?pretty" -H 'Content-Type: application/json' -uelastic:password -d'
{ "delete" : { "_index" : "test", "_id" : "1" } }
{ "update" : {"_id" : "2", "_index" : "test"} }
{ "doc" : {"field2" : "value2-updated"} }
'

查询数据
# 查询主集群
curl 192.168.56.3:7171/test/_search?pretty -uelastic:password

# 查询备集群
curl 192.168.56.3:9200/test/_search?pretty -uadmin:admin

两个集群都已执行删除和更新操作,数据一致。

主集群故障时写入、查询测试

为模拟主集群故障,直接关闭主集群。

写入数据

# 通过网关写入数据
curl -X POST "192.168.56.3:18000/_bulk?pretty" -H 'Content-Type: application/json' -uelastic:password -d'
{ "index" : { "_index" : "test", "_id" : "3" } }
{ "field3" : "value3" }
{ "create" : { "_index" : "test", "_id" : "4" } }
{ "field4" : "value4" }
'

写入数据报错

查询数据

# 通过网关查询,因为主集群不可用,网关将查询转发到备集群执行
curl 192.168.56.3:18000/test/_search?pretty -uelastic:password

正常查询到数据,说明请求被转发到了备集群执行。

备集群故障时写入、查询测试

为模拟备集群故障,直接关闭备集群。

写入数据

# 通过网关写入数据
curl -X POST "192.168.56.3:18000/_bulk?pretty" -H 'Content-Type: application/json' -uelastic:password -d'
{ "index" : { "_index" : "test", "_id" : "5" } }
{ "field5" : "value5" }
{ "create" : { "_index" : "test", "_id" : "6" } }
{ "field6" : "value6" }
'

数据正常写入。

查询数据

# 通过网关查询
curl 192.168.56.3:18000/test/_search?pretty -uelastic:password

查询成功返回。主集群成功写入了两条新数据。同时此数据会被记录到备集群的队列中,待备集群恢复后,会消费此队列追数据。

恢复备集群

启动备集群。

查询数据

等待片刻或通过 INFINI Console 确定网关队列消费完毕后,查询备集群的数据。 (生产和消费 offset 相同,说明消费完毕。)

# 查询备集群的数据
curl 192.168.56.3:9200/test/_search?pretty -uadmin:admin

备集群启动后自动消费队列数据,消费完后备集群数据达到与主集群数据一致。

灾备切换

测试了这么多,终于到切换的时刻了。切换前我们判断下主系统是否短期无法修复。

如果我们判断主用系统无法短时间恢复,要执行切换。非常简单,我们直接将配置文件中定义的主备集群互换,然后重启网关程序就行了。但我们推荐在相同主机上另部署一套网关程序--网关B,先前那套用网关A指代。网关B中的配置文件把原备集群定义为主集群,原主集群定义为备集群。若要执行切换,我们先停止网关A,然后启动网关B,此时应用连接到网关(端口不变),就把原备系统当作主系统使用,把原主系统当作备系统,也就完成了主备系统的切换。

灾备回切

当原主集群修复后,正常启动,就会从消费队列追写修复期间产生数据直到主备数据一致,同样我们可通过 INFINI Console 查看消费的进度。如果大家还是担心数据的一致性,INFINI Console 还能帮大家做[校验数据]()任务,做到数据完全一致后(文档数量及文档内容一致),才进行回切。

回切也非常简单,停止网关B,启动网关A即可。

网关高可用

网关自带浮动 IP 模块,可进行双机热备。客户端通过 VIP 连接网关,网关出现故障时,VIP 漂移到备网关。 视频教程戳这里

这样的优点是简单,不足是只有一个网关在线提供服务。如果想多个网关在线提供服务,则需搭配分布式消息系统一起工作,架构如下。

前端通过负载均衡将流量分散到多个在线网关,网关将消息存入分布式消息系统。此时,网关可看作无状态应用,可根据需要扩缩规模。

以上就是我介绍的ES灾备方案,是不是相当灵活了。有问题还是那句话 Call me 。

关于极限网关

INFINI Gateway 是一个面向搜索场景的高性能数据网关,所有请求都经过网关处理后再转发到后端的搜索业务集群。基于 INFINI Gateway,可以实现索引级别的限速限流、常见查询的缓存加速、查询请求的审计、查询结果的动态修改等等。

官网文档:https://www.infinilabs.com/docs/latest/gateway

收起阅读 »

给 ES 插上向量检索的翅膀 | DataFunSummit 2023 峰会演讲内容速达

近日,由 DataFun 主办的 DataFunSummit 2023 数据基础架构峰会 圆满落下帷幕,本次峰会邀请了腾讯、百度、字节、极限科技、Zilliz 等众多企业技术专家为大家带来分布式存储以及向量数据库的架构原理、性能优化与实践解析分享。

向量数据库架构与实践论坛 中,极限科技搜索引擎研发工程师张磊受邀出席做了《给 ES 插上向量检索的翅膀》的主题演讲。据介绍,本次演讲主要介绍了 Elasticsearch(ES)与向量技术的融合,展示其在不同行业中的应用场景和优势,同时也对 ES 与向量的技术细节进行详细讨论,并通过具体案例演示如何利用向量提升搜索能力。

讲师介绍

张磊,极限科技 Easysearch 引擎研发工程师,2013 年开始接触 Elasticsearch,10 余年搜索相关经验,之前主要做一些围绕 Elasticsearch 在日志检索和公安大数据相关业务的开发,对 Elasticsearch 和 Lucene 源码比较熟悉,目前专注于公司内部搜索产品的开发。

《给 ES 插上向量检索的翅膀》PPT 内容

更多 PPT 内容参见 https://elasticsearch.cn/slides/322

关于 Easysearch

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎,核心引擎基于开源的 Apache Lucene。Easysearch 衍生自基于开源协议 Apache 2.0 的 Elasticsearch 7.10 版本。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能。与 Elasticsearch 相比,Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。

官网文档:https://www.infinilabs.com/docs/latest/easysearch

下载地址:https://www.infinilabs.com/download

继续阅读 »

近日,由 DataFun 主办的 DataFunSummit 2023 数据基础架构峰会 圆满落下帷幕,本次峰会邀请了腾讯、百度、字节、极限科技、Zilliz 等众多企业技术专家为大家带来分布式存储以及向量数据库的架构原理、性能优化与实践解析分享。

向量数据库架构与实践论坛 中,极限科技搜索引擎研发工程师张磊受邀出席做了《给 ES 插上向量检索的翅膀》的主题演讲。据介绍,本次演讲主要介绍了 Elasticsearch(ES)与向量技术的融合,展示其在不同行业中的应用场景和优势,同时也对 ES 与向量的技术细节进行详细讨论,并通过具体案例演示如何利用向量提升搜索能力。

讲师介绍

张磊,极限科技 Easysearch 引擎研发工程师,2013 年开始接触 Elasticsearch,10 余年搜索相关经验,之前主要做一些围绕 Elasticsearch 在日志检索和公安大数据相关业务的开发,对 Elasticsearch 和 Lucene 源码比较熟悉,目前专注于公司内部搜索产品的开发。

《给 ES 插上向量检索的翅膀》PPT 内容

更多 PPT 内容参见 https://elasticsearch.cn/slides/322

关于 Easysearch

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎,核心引擎基于开源的 Apache Lucene。Easysearch 衍生自基于开源协议 Apache 2.0 的 Elasticsearch 7.10 版本。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能。与 Elasticsearch 相比,Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。

官网文档:https://www.infinilabs.com/docs/latest/easysearch

下载地址:https://www.infinilabs.com/download

收起阅读 »

ES数据没了?谁动了我的数据?

背景

我们在使用 Elasticsearch 的时候,可能会遇到数据“丢”了的情况。有可能是数据没成功写入 ES 集群,也可能是数据被误删了。

针对数据被误删,有没有好的解决办法呢?

其实我们可以把“删除数据”这个操作管理起来。当 ES 集群接收到删除数据命令的时候,先不执行该命令,而是生成一条删除数据的记录,经过管理人员批准后,该命令才会执行。这样不仅可以管理数据的删除,还可以进行删除操作的追踪:什么人,什么时间,发送了什么样的删除指令,从哪个 IP 发送的,以什么身份登录的等等。

要实现这个解决办法,我们可借助 INFINI Gateway 和 Console 的帮助。

方案架构

方案效果

  • INFINI Gateway 作为 ES 集群的代理,接收所有请求
  • INFINI Gateway 对删除数据操作进行拦截,在 Console UI 界面生成记录
  • 管理人员 在 Console UI 界面审批操作记录,审批通过操作被执行

方案演示

测试数据准备

测试索引 test1,一共有 3 条数据。message 内容分别是"line 1","line 2"和"line 3"。

启动 INFINI Gateway 及 Console

网关配置新增内容

增加对 DELETE 操作的捕获,不直接执行,写入队列中。后续由队列生成特定的记录。

router:
  - name: my_router
    default_flow: default_flow
    tracing_flow: logging_flow
    rules:
      - method:
          - "DELETE"
        pattern:
          - "/{any_index}"
          - "/{any_index}/{any_type}"
          - "/{any_index}/{any_type}/{any_docid}"
        flow:
          - audit_flow
      - method:
          - "*"
        pattern:
          - "/{any_index}/_delete_by_query"
          - "/_delete_by_query"
        flow:
          - audit_flow
flow:
  - name: audit_flow
    filter:
      - logging:
          queue_name: del_queue
pipeline:
  - name: del_queue_ingest
    auto_start: true
    keep_running: true
    processor:
      - json_indexing:
          input_queue: "del_queue"
          idle_timeout_in_seconds: 1
          elasticsearch: "logging-server"
          index_name: "del_requests"
          worker_size: 1
          bulk_size_in_kb: 1

执行删除操作

ES 支持多种删除操作,简单总结归纳如下:

  1. 删除指定文档 id
  2. 删除索引
  3. 根据查询删除指定数据(_delete_by_query)

执行删除操作之前,先通过 INFINI Gateway 访问 ES 集群,证明可正常访问数据。 执行上述的几种删除命令,注意要发给 INFINI Gateway 的 8000 端口。

数据查询验证数据还在

Console 界面查看未批准的删除记录

所有删除操作,都被记录,待审批

Console 界面进行审批通过

选择一条记录,批准执行。Operation-approve

数据查询验证数据

"message": "line 2"的文档已被删除。

Console 界面查看历史记录

继续批准测试

批准删除一条文档

"message": "line 1" 的文档不在了。

批准删除索引

索引不在了。

至此我们演示了如何利用 INFINI Gateway 和 Console 对 ES 集群删除操作进行管控,本文只是抛砖引玉,相信还有更多有意思的场景等待大家发掘。

继续阅读 »

背景

我们在使用 Elasticsearch 的时候,可能会遇到数据“丢”了的情况。有可能是数据没成功写入 ES 集群,也可能是数据被误删了。

针对数据被误删,有没有好的解决办法呢?

其实我们可以把“删除数据”这个操作管理起来。当 ES 集群接收到删除数据命令的时候,先不执行该命令,而是生成一条删除数据的记录,经过管理人员批准后,该命令才会执行。这样不仅可以管理数据的删除,还可以进行删除操作的追踪:什么人,什么时间,发送了什么样的删除指令,从哪个 IP 发送的,以什么身份登录的等等。

要实现这个解决办法,我们可借助 INFINI Gateway 和 Console 的帮助。

方案架构

方案效果

  • INFINI Gateway 作为 ES 集群的代理,接收所有请求
  • INFINI Gateway 对删除数据操作进行拦截,在 Console UI 界面生成记录
  • 管理人员 在 Console UI 界面审批操作记录,审批通过操作被执行

方案演示

测试数据准备

测试索引 test1,一共有 3 条数据。message 内容分别是"line 1","line 2"和"line 3"。

启动 INFINI Gateway 及 Console

网关配置新增内容

增加对 DELETE 操作的捕获,不直接执行,写入队列中。后续由队列生成特定的记录。

router:
  - name: my_router
    default_flow: default_flow
    tracing_flow: logging_flow
    rules:
      - method:
          - "DELETE"
        pattern:
          - "/{any_index}"
          - "/{any_index}/{any_type}"
          - "/{any_index}/{any_type}/{any_docid}"
        flow:
          - audit_flow
      - method:
          - "*"
        pattern:
          - "/{any_index}/_delete_by_query"
          - "/_delete_by_query"
        flow:
          - audit_flow
flow:
  - name: audit_flow
    filter:
      - logging:
          queue_name: del_queue
pipeline:
  - name: del_queue_ingest
    auto_start: true
    keep_running: true
    processor:
      - json_indexing:
          input_queue: "del_queue"
          idle_timeout_in_seconds: 1
          elasticsearch: "logging-server"
          index_name: "del_requests"
          worker_size: 1
          bulk_size_in_kb: 1

执行删除操作

ES 支持多种删除操作,简单总结归纳如下:

  1. 删除指定文档 id
  2. 删除索引
  3. 根据查询删除指定数据(_delete_by_query)

执行删除操作之前,先通过 INFINI Gateway 访问 ES 集群,证明可正常访问数据。 执行上述的几种删除命令,注意要发给 INFINI Gateway 的 8000 端口。

数据查询验证数据还在

Console 界面查看未批准的删除记录

所有删除操作,都被记录,待审批

Console 界面进行审批通过

选择一条记录,批准执行。Operation-approve

数据查询验证数据

"message": "line 2"的文档已被删除。

Console 界面查看历史记录

继续批准测试

批准删除一条文档

"message": "line 1" 的文档不在了。

批准删除索引

索引不在了。

至此我们演示了如何利用 INFINI Gateway 和 Console 对 ES 集群删除操作进行管控,本文只是抛砖引玉,相信还有更多有意思的场景等待大家发掘。

收起阅读 »

Elasticsearch:如何在 Elastic 中实现图片相似度搜索

原文: Elasticsearch:如何在 Elastic 中实现图片相似度搜索

作者:Radovan Ondas

在本文章,我们将了解如何通过几个步骤在 Elastic 中实施相似图像搜索。 开始设置应用程序环境,然后导入 NLP 模型,最后完成为你的图像集生成嵌入。

Elastic 图像相似性搜索概览 >>

Elasticsearch:如何在 Elastic 中实现图片相似度搜索

如何设置环境

第一步是为你的应用程序设置环境。 一般要求包括:

  • Git
  • Python 3.9
  • Docker
  • 数百张图片

使用数百张图像以确保获得最佳效果非常重要。

转到工作文件夹并检查创建的存储库代码。 然后导航到存储库文件夹。


1.  git clone https://github.com/radoondas/flask-elastic-image-search.git
2.  cd flask-elastic-image-search

1.  $ git clone https://github.com/radoondas/flask-elastic-image-search.git
2.  Cloning into 'flask-elastic-image-search'...
3.  remote: Enumerating objects: 105, done.
4.  remote: Counting objects: 100% (105/105), done.
5.  remote: Compressing objects: 100% (72/72), done.
6.  remote: Total 105 (delta 37), reused 94 (delta 27), pack-reused 0
7.  Receiving objects: 100% (105/105), 20.72 MiB | 9.75 MiB/s, done.
8.  Resolving deltas: 100% (37/37), done.
9.  $ cd flask-elastic-image-search/
10.  $ pwd
11.  /Users/liuxg/python/flask-elastic-image-search

因为你将使用 Python 来运行代码,所以你需要确保满足所有要求并且环境已准备就绪。 现在创建虚拟环境并安装所有依赖项。


1.  python3 -m venv .venv
2.  source .venv/bin/activate
3.  pip install -r requirements.txt

安装

如果你还没有安装好自己的 Elasticsearch 及 Kibana,请参考如下的文章来进行安装:

特别注意的是:我们将以最新的 Elastic Stack 8.6.1 来进行展示。请参考 Elastic Stack 8.x 的文章进行安装。

启动白金版试用功能

由于上传模型是一个白金版的功能,我们需要启动试用功能。更多关于订阅的信息,请参考网址:订阅 | Elastic Stack 产品和支持 | Elastic

这样我们就成功地启动了白金版试用功能。 

Elasticsearch 集群和嵌入模型

登录到你的帐户以启动 Elasticsearch 集群。 设置一个小型集群:

  • 一个具有 2GB 内存的 HOT 节点
  • 一个具有 4GB 内存的 ML(机器学习)节点(此节点的大小很重要,因为你将导入 Elasticsearch 的 NLP 模型会消耗约 1.5GB 的内存。)

部署准备就绪后,转到 Kibana 并检查机器学习节点的容量。 你将在视图中看到一个机器学习节点。 目前没有加载模型。

使用 Eland 库从 OpenAI 上传 CLIP 嵌入模型。 Eland 是一个 Python Elasticsearch 客户端,用于在 Elasticsearch 中探索和分析数据,能够处理文本和图像。 您将使用此模型从文本输入生成嵌入并查询匹配图像。 在 Eland 库的文档中找到更多详细信息。

对于下一步,你将需要 Elasticsearch 端点。 你可以从部署详细信息部分的 Elasticsearch 云控制台获取它。

 

在本示例中,我们将使用本地部署来进行展示,所以,我们并不必要完成上面的步骤。

Eland

Eland 可以通过 pip 从 PyPI 安装。在安装之前,我们需要安装好自己的 Python。


1.  $ python --version
2.  Python 3.10.2

可以使用 Pip 从 PyPI 安装 Eland:

python -m pip install eland

也可以使用 Conda 从 Conda Forge 安装 Eland:

conda install -c conda-forge eland

希望在不安装 Eland 的情况下使用它的用户,为了只运行可用的脚本,可以构建 Docker 容器:


1.  git clone https://github.com/elastic/eland
2.  cd eland
3.  docker build -t elastic/eland .

Eland 将 Hugging Face 转换器模型到其 TorchScript 表示的转换和分块过程封装在一个 Python 方法中; 因此,这是推荐的导入方法。

  1. 安装 Eland Python 客户端
  2. 运行 eland_import_hub_model 脚本。 例如:
1.  eland_import_hub_model --url <clusterUrl> \ 
2.  --hub-model-id elastic/distilbert-base-cased-finetuned-conll03-english \ 
3.  --task-type ner 

上传模型

我们使用如下的命令来进行上传模型:


1.  eland_import_hub_model --url https://<user>:<password>@<hostname>:<port> \
2.    --hub-model-id sentence-transformers/clip-ViT-B-32-multilingual-v1 \
3.    --task-type text_embedding \
4.    --ca-certs <your certificate> \
5.    --start

针对我的情况:


1.  eland_import_hub_model --url https://elastic:ZgzSt2vHNwA6yPn-fllr@localhost:9200 \
2.    --hub-model-id sentence-transformers/clip-ViT-B-32-multilingual-v1 \
3.    --task-type text_embedding \
4.    --ca-certs /Users/liuxg/elastic/elasticsearch-8.6.1/config/certs/http_ca.crt \
5.    --start

请注意: 你需要根据自己的 Elasticsearch 访问端点,用户名及密码来修改上面的设置,同时你需要根据自己的配置修改上面的证书路径。

运行上面的命令:

上面显示,我们已经成功地上传了模型。我们可以到 Kibana 中进行查看:

上面显示我们已经上传了所需要的 CLIP 模型,并且它的状态是 started。

如何创建图像嵌入

在设置 Elasticsearch 集群并导入嵌入模型后,你需要矢量化图像数据并为数据集中的每个图像创建图像嵌入。 

 要创建图像嵌入,请使用简单的 Python 脚本。 你可以在此处找到该脚本:create-image-embeddings.py。 该脚本将遍历你的图像目录并生成单独的图像嵌入。 它将使用名称和相对路径创建文档,并使用提供的映射将其保存到 Elasticsearch 索引 my-image-embeddings 中。

将所有图像(照片)放入文件夹 app/static/images。 使用带有子文件夹的目录结构来组织图像。 所有图像准备就绪后,使用几个参数执行脚本。

至少要有几百张图像才能获得合理的结果,这一点至关重要。 图像太少不会产生预期的结果,因为你要搜索的空间非常小,而且到搜索向量的距离也非常相似。我尝试在网上下载很多的照片,但是感觉一张一张地下载非常麻烦。你可以在谷歌浏览器中添加插件 Image downloader - Imageye。它可以方便地把很多照片一次下载下来。

在 image_embeddings 文件夹中,运行脚本并为变量使用你的值。


1.  cd image_embeddings
2.  python3 create-image-embeddings.py \
3.    --es_host='https://localhost:9200' \
4.    --es_user='elastic' --es_password='ZgzSt2vHNwA6yPn-fllr' \
5.    --ca_certs='/Users/liuxg/elastic/elasticsearch-8.6.1/config/certs/http_ca.crt'

根据图像的数量、它们的大小、你的 CPU 和你的网络连接,此任务将需要一些时间。 在尝试处理完整数据集之前,先试验少量图像。脚本完成后,你可以使用 Kibana 开发工具验证索引 my-image-embeddings 是否存在并具有相应的文档。

我们在Kibana 中进行查看:

GET _cat/indices/my-image-embeddings?v

 上面命令的响应为:


1.  health status index               uuid                   pri rep docs.count docs.deleted store.size pri.store.size
2.  yellow open   my-image-embeddings h6oUBdHCScWmXOZaf57oWg   1   1        145            0      1.4mb          1.4mb

查看文档,你会看到非常相似的 JSON 对象(如示例)。 你将在图像文件夹中看到图像名称、图像 ID 和相对路径。 此路径用于前端应用程序以在搜索时正确显示图像。JSON 文档中最重要的部分是包含 CLIP 模型生成的密集矢量的 image_embedding。 当应用程序正在搜索图像或类似图像时使用此矢量。

GET my-image-embeddings/_search

1.  {
2.     "_index": "my-image-embeddings",
3.     "_id": "_g9ACIUBMEjlQge4tztV",
4.     "_score": 6.703597,
5.     "_source": {
6.       "image_id": "IMG_4032",
7.       "image_name": "IMG_4032.jpeg",
8.       "image_embedding": [
9.         -0.3415695130825043,
10.         0.1906963288784027,
11.         .....
12.         -0.10289803147315979,
13.         -0.15871885418891907
14.         ],
15.       "relative_path": "phone/IMG_4032.jpeg"
16.     }
17.  }

使用 Flask 应用程序搜索图像

现在你的环境已全部设置完毕,你可以进行下一步,使用我们作为概念证明提供的 Flask 应用程序,使用自然语言实际搜索图像并查找相似图像。 该 Web 应用程序具有简单的 UI,使图像搜索变得简单。 你可以在此 GitHub 存储库中访问原型 Flask 应用程序。

后台应用程序执行两个任务。 在搜索框中输入搜索字符串后,文本将使用机器学习 _infer 端点进行矢量化。 然后,针对带有向量的索引 my-image-embeddings 执行带有密集向量的查询。

你可以在示例中看到这两个查询。 第一个 API 调用使用 _infer 端点,结果是一个密集矢量。


1.  POST _ml/trained_models/sentence-transformers__clip-vit-b-32-multilingual-v1/_infer
2.  {
3.    "docs" : [
4.      {"text_field": "Yellow mountain is the most beautiful mountain in China"}
5.      ]
6.  }

上面的响应如下:

在第二个任务中,搜索查询,我们将使用密集矢量并获得按分数排序的图像。 

`

1.  GET my-image-embeddings/_search
2.  {
3.    "fields": [
4.      "image_id",
5.      "image_name",
6.      "relative_path"
7.    ],
8.    "_source": false,
9.    "knn": {
10.      "field": "image_embedding",
11.      "k": 5,
12.      "num_candidates": 10,
13.      "query_vector": [
14.          0.03395160660147667,
15.          0.007704082876443863,
16.          0.14996188879013062,
17.          -0.10693030804395676,
18.          ...
19.          0.05140634626150131,
20.          0.07114913314580917
21.     ]
22.    }
23.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

要启动并运行 Flask 应用程序,请导航到存储库的根文件夹并配置 .env 文件。 配置文件中的值用于连接到 Elasticsearch 集群。 你需要为以下变量插入值。 这些与图像嵌入生成中使用的值相同。 

.env


1.  ES_HOST='URL:PORT'
2.  ES_USER='elastic'
3.  ES_PWD='password'

为了能够使得我们自构建的 Elasticsearch 集群能够被正确地访问,我们必须把 Elasticsearch 的根证书拷贝到 Flask 应用的相应目录中:

flask-elastic-image-search/app/conf/ca.crt


1.  (.venv) $ pwd
2.  /Users/liuxg/python/flask-elastic-image-search/app/conf
3.  (.venv) $ cp ~/elastic/elasticsearch-8.6.1/config/certs/http_ca.crt ca.crt
4.  overwrite ca.crt? (y/n [n]) y

在上面,我们替换了仓库中原有的证书文件 ca.crt。

准备就绪后,运行主文件夹中的 flask 应用程序并等待它启动。


1.  # In the main directory 
2.  $ flask run --port=5001

如果应用程序启动,你将看到类似于下面的输出,它在末尾指示你需要访问哪个 URL 才能访问该应用程序。

恭喜! 你的应用程序现在应该已启动并正在运行,并且可以通过互联网浏览器在 http://127.0.0.1:5001 上访问。

导航到图像搜索选项卡并输入描述你最佳图像的文本。 尝试使用非关键字或描述性文字。

在下面的示例中,输入的文本是 “Yellow mountain is the most beautiful mountain in China”。 结果显示在我们的数据集中。 如果用户喜欢结果集中的一张特定图像,只需单击它旁边的按钮,就会显示类似的图像。 用户可以无限次地这样做,并通过图像数据集构建自己的路径。

我们尝试另外的一个例子。这次我们输入:I love beautiful girls。

搜索也可以通过简单地上传图像来进行。 该应用程序会将图像转换为矢量并在数据集中搜索相似的图像。 为此,导航到第三个选项卡 “Similar Image”,从磁盘上传图像,然后点击 “Search”。

我们可以看到相似的图片。我们尝试使用一个女孩的照片再试试:

因为我们在 Elasticsearch 中使用的 NLP(sentence-transformers/clip-ViT-B-32-multilingual-v1)模型是多语言的,支持多语言推理,所以尽量搜索自己语言的图片。 然后也使用英文文本验证结果。我们尝试使用 “黄山是中国最漂亮的山”:

请务必注意,使用的模型是通用模型,这些模型非常准确,但你获得的结果会因用例或其他因素而异。 如果你需要更高的精度,则必须采用通用模型或开发自己的模型 —— CLIP 模型只是一个起点。

代码摘要

你可以在 GitHub 存储库中找到完整的代码。 你可能正在检查 routes.py 中的代码,它实现了应用程序的主要逻辑。 除了明显的路线定义之外,你还应该关注定义 _infer 和 _search 端点(infer_trained_modelknn_search_images)的方法。 生成图像嵌入的代码位于 create-image-embeddings.py文件中。

总结

现在你已经设置了 Flask 应用程序,你可以轻松地搜索你自己的图像集! Elastic 在平台内提供了矢量搜索的原生集成,避免了与外部进程的通信。 你可以灵活地开发和使用你可能使用 PyTorch 开发的自定义嵌入模型。

语义图像搜索具有其他传统图像搜索方法的以下优点:

  • 更高的准确度:向量相似性捕获上下文和关联,而不依赖于图像的文本元描述。
  • 增强的用户体验:与猜测哪些关键字可能相关相比,描述你正在寻找的内容或提供示例图像。
  • 图像数据库的分类:不用担心对图像进行分类——相似性搜索可以在一堆图像中找到相关图像,而无需对它们进行组织。

如果你的用例更多地依赖于文本数据,你可以在以前的博客中了解更多关于实现语义搜索和将自然语言处理应用于文本的信息。 对于文本数据,向量相似度与传统关键词评分的结合呈现了两全其美的效果。

准备好开始了吗? 在我们的虚拟活动中心报名参加矢量搜索实践研讨会,并在我们的在线论坛中与社区互动。

继续阅读 »

原文: Elasticsearch:如何在 Elastic 中实现图片相似度搜索

作者:Radovan Ondas

在本文章,我们将了解如何通过几个步骤在 Elastic 中实施相似图像搜索。 开始设置应用程序环境,然后导入 NLP 模型,最后完成为你的图像集生成嵌入。

Elastic 图像相似性搜索概览 >>

Elasticsearch:如何在 Elastic 中实现图片相似度搜索

如何设置环境

第一步是为你的应用程序设置环境。 一般要求包括:

  • Git
  • Python 3.9
  • Docker
  • 数百张图片

使用数百张图像以确保获得最佳效果非常重要。

转到工作文件夹并检查创建的存储库代码。 然后导航到存储库文件夹。


1.  git clone https://github.com/radoondas/flask-elastic-image-search.git
2.  cd flask-elastic-image-search

1.  $ git clone https://github.com/radoondas/flask-elastic-image-search.git
2.  Cloning into 'flask-elastic-image-search'...
3.  remote: Enumerating objects: 105, done.
4.  remote: Counting objects: 100% (105/105), done.
5.  remote: Compressing objects: 100% (72/72), done.
6.  remote: Total 105 (delta 37), reused 94 (delta 27), pack-reused 0
7.  Receiving objects: 100% (105/105), 20.72 MiB | 9.75 MiB/s, done.
8.  Resolving deltas: 100% (37/37), done.
9.  $ cd flask-elastic-image-search/
10.  $ pwd
11.  /Users/liuxg/python/flask-elastic-image-search

因为你将使用 Python 来运行代码,所以你需要确保满足所有要求并且环境已准备就绪。 现在创建虚拟环境并安装所有依赖项。


1.  python3 -m venv .venv
2.  source .venv/bin/activate
3.  pip install -r requirements.txt

安装

如果你还没有安装好自己的 Elasticsearch 及 Kibana,请参考如下的文章来进行安装:

特别注意的是:我们将以最新的 Elastic Stack 8.6.1 来进行展示。请参考 Elastic Stack 8.x 的文章进行安装。

启动白金版试用功能

由于上传模型是一个白金版的功能,我们需要启动试用功能。更多关于订阅的信息,请参考网址:订阅 | Elastic Stack 产品和支持 | Elastic

这样我们就成功地启动了白金版试用功能。 

Elasticsearch 集群和嵌入模型

登录到你的帐户以启动 Elasticsearch 集群。 设置一个小型集群:

  • 一个具有 2GB 内存的 HOT 节点
  • 一个具有 4GB 内存的 ML(机器学习)节点(此节点的大小很重要,因为你将导入 Elasticsearch 的 NLP 模型会消耗约 1.5GB 的内存。)

部署准备就绪后,转到 Kibana 并检查机器学习节点的容量。 你将在视图中看到一个机器学习节点。 目前没有加载模型。

使用 Eland 库从 OpenAI 上传 CLIP 嵌入模型。 Eland 是一个 Python Elasticsearch 客户端,用于在 Elasticsearch 中探索和分析数据,能够处理文本和图像。 您将使用此模型从文本输入生成嵌入并查询匹配图像。 在 Eland 库的文档中找到更多详细信息。

对于下一步,你将需要 Elasticsearch 端点。 你可以从部署详细信息部分的 Elasticsearch 云控制台获取它。

 

在本示例中,我们将使用本地部署来进行展示,所以,我们并不必要完成上面的步骤。

Eland

Eland 可以通过 pip 从 PyPI 安装。在安装之前,我们需要安装好自己的 Python。


1.  $ python --version
2.  Python 3.10.2

可以使用 Pip 从 PyPI 安装 Eland:

python -m pip install eland

也可以使用 Conda 从 Conda Forge 安装 Eland:

conda install -c conda-forge eland

希望在不安装 Eland 的情况下使用它的用户,为了只运行可用的脚本,可以构建 Docker 容器:


1.  git clone https://github.com/elastic/eland
2.  cd eland
3.  docker build -t elastic/eland .

Eland 将 Hugging Face 转换器模型到其 TorchScript 表示的转换和分块过程封装在一个 Python 方法中; 因此,这是推荐的导入方法。

  1. 安装 Eland Python 客户端
  2. 运行 eland_import_hub_model 脚本。 例如:
1.  eland_import_hub_model --url <clusterUrl> \ 
2.  --hub-model-id elastic/distilbert-base-cased-finetuned-conll03-english \ 
3.  --task-type ner 

上传模型

我们使用如下的命令来进行上传模型:


1.  eland_import_hub_model --url https://<user>:<password>@<hostname>:<port> \
2.    --hub-model-id sentence-transformers/clip-ViT-B-32-multilingual-v1 \
3.    --task-type text_embedding \
4.    --ca-certs <your certificate> \
5.    --start

针对我的情况:


1.  eland_import_hub_model --url https://elastic:ZgzSt2vHNwA6yPn-fllr@localhost:9200 \
2.    --hub-model-id sentence-transformers/clip-ViT-B-32-multilingual-v1 \
3.    --task-type text_embedding \
4.    --ca-certs /Users/liuxg/elastic/elasticsearch-8.6.1/config/certs/http_ca.crt \
5.    --start

请注意: 你需要根据自己的 Elasticsearch 访问端点,用户名及密码来修改上面的设置,同时你需要根据自己的配置修改上面的证书路径。

运行上面的命令:

上面显示,我们已经成功地上传了模型。我们可以到 Kibana 中进行查看:

上面显示我们已经上传了所需要的 CLIP 模型,并且它的状态是 started。

如何创建图像嵌入

在设置 Elasticsearch 集群并导入嵌入模型后,你需要矢量化图像数据并为数据集中的每个图像创建图像嵌入。 

 要创建图像嵌入,请使用简单的 Python 脚本。 你可以在此处找到该脚本:create-image-embeddings.py。 该脚本将遍历你的图像目录并生成单独的图像嵌入。 它将使用名称和相对路径创建文档,并使用提供的映射将其保存到 Elasticsearch 索引 my-image-embeddings 中。

将所有图像(照片)放入文件夹 app/static/images。 使用带有子文件夹的目录结构来组织图像。 所有图像准备就绪后,使用几个参数执行脚本。

至少要有几百张图像才能获得合理的结果,这一点至关重要。 图像太少不会产生预期的结果,因为你要搜索的空间非常小,而且到搜索向量的距离也非常相似。我尝试在网上下载很多的照片,但是感觉一张一张地下载非常麻烦。你可以在谷歌浏览器中添加插件 Image downloader - Imageye。它可以方便地把很多照片一次下载下来。

在 image_embeddings 文件夹中,运行脚本并为变量使用你的值。


1.  cd image_embeddings
2.  python3 create-image-embeddings.py \
3.    --es_host='https://localhost:9200' \
4.    --es_user='elastic' --es_password='ZgzSt2vHNwA6yPn-fllr' \
5.    --ca_certs='/Users/liuxg/elastic/elasticsearch-8.6.1/config/certs/http_ca.crt'

根据图像的数量、它们的大小、你的 CPU 和你的网络连接,此任务将需要一些时间。 在尝试处理完整数据集之前,先试验少量图像。脚本完成后,你可以使用 Kibana 开发工具验证索引 my-image-embeddings 是否存在并具有相应的文档。

我们在Kibana 中进行查看:

GET _cat/indices/my-image-embeddings?v

 上面命令的响应为:


1.  health status index               uuid                   pri rep docs.count docs.deleted store.size pri.store.size
2.  yellow open   my-image-embeddings h6oUBdHCScWmXOZaf57oWg   1   1        145            0      1.4mb          1.4mb

查看文档,你会看到非常相似的 JSON 对象(如示例)。 你将在图像文件夹中看到图像名称、图像 ID 和相对路径。 此路径用于前端应用程序以在搜索时正确显示图像。JSON 文档中最重要的部分是包含 CLIP 模型生成的密集矢量的 image_embedding。 当应用程序正在搜索图像或类似图像时使用此矢量。

GET my-image-embeddings/_search

1.  {
2.     "_index": "my-image-embeddings",
3.     "_id": "_g9ACIUBMEjlQge4tztV",
4.     "_score": 6.703597,
5.     "_source": {
6.       "image_id": "IMG_4032",
7.       "image_name": "IMG_4032.jpeg",
8.       "image_embedding": [
9.         -0.3415695130825043,
10.         0.1906963288784027,
11.         .....
12.         -0.10289803147315979,
13.         -0.15871885418891907
14.         ],
15.       "relative_path": "phone/IMG_4032.jpeg"
16.     }
17.  }

使用 Flask 应用程序搜索图像

现在你的环境已全部设置完毕,你可以进行下一步,使用我们作为概念证明提供的 Flask 应用程序,使用自然语言实际搜索图像并查找相似图像。 该 Web 应用程序具有简单的 UI,使图像搜索变得简单。 你可以在此 GitHub 存储库中访问原型 Flask 应用程序。

后台应用程序执行两个任务。 在搜索框中输入搜索字符串后,文本将使用机器学习 _infer 端点进行矢量化。 然后,针对带有向量的索引 my-image-embeddings 执行带有密集向量的查询。

你可以在示例中看到这两个查询。 第一个 API 调用使用 _infer 端点,结果是一个密集矢量。


1.  POST _ml/trained_models/sentence-transformers__clip-vit-b-32-multilingual-v1/_infer
2.  {
3.    "docs" : [
4.      {"text_field": "Yellow mountain is the most beautiful mountain in China"}
5.      ]
6.  }

上面的响应如下:

在第二个任务中,搜索查询,我们将使用密集矢量并获得按分数排序的图像。 

`

1.  GET my-image-embeddings/_search
2.  {
3.    "fields": [
4.      "image_id",
5.      "image_name",
6.      "relative_path"
7.    ],
8.    "_source": false,
9.    "knn": {
10.      "field": "image_embedding",
11.      "k": 5,
12.      "num_candidates": 10,
13.      "query_vector": [
14.          0.03395160660147667,
15.          0.007704082876443863,
16.          0.14996188879013062,
17.          -0.10693030804395676,
18.          ...
19.          0.05140634626150131,
20.          0.07114913314580917
21.     ]
22.    }
23.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

要启动并运行 Flask 应用程序,请导航到存储库的根文件夹并配置 .env 文件。 配置文件中的值用于连接到 Elasticsearch 集群。 你需要为以下变量插入值。 这些与图像嵌入生成中使用的值相同。 

.env


1.  ES_HOST='URL:PORT'
2.  ES_USER='elastic'
3.  ES_PWD='password'

为了能够使得我们自构建的 Elasticsearch 集群能够被正确地访问,我们必须把 Elasticsearch 的根证书拷贝到 Flask 应用的相应目录中:

flask-elastic-image-search/app/conf/ca.crt


1.  (.venv) $ pwd
2.  /Users/liuxg/python/flask-elastic-image-search/app/conf
3.  (.venv) $ cp ~/elastic/elasticsearch-8.6.1/config/certs/http_ca.crt ca.crt
4.  overwrite ca.crt? (y/n [n]) y

在上面,我们替换了仓库中原有的证书文件 ca.crt。

准备就绪后,运行主文件夹中的 flask 应用程序并等待它启动。


1.  # In the main directory 
2.  $ flask run --port=5001

如果应用程序启动,你将看到类似于下面的输出,它在末尾指示你需要访问哪个 URL 才能访问该应用程序。

恭喜! 你的应用程序现在应该已启动并正在运行,并且可以通过互联网浏览器在 http://127.0.0.1:5001 上访问。

导航到图像搜索选项卡并输入描述你最佳图像的文本。 尝试使用非关键字或描述性文字。

在下面的示例中,输入的文本是 “Yellow mountain is the most beautiful mountain in China”。 结果显示在我们的数据集中。 如果用户喜欢结果集中的一张特定图像,只需单击它旁边的按钮,就会显示类似的图像。 用户可以无限次地这样做,并通过图像数据集构建自己的路径。

我们尝试另外的一个例子。这次我们输入:I love beautiful girls。

搜索也可以通过简单地上传图像来进行。 该应用程序会将图像转换为矢量并在数据集中搜索相似的图像。 为此,导航到第三个选项卡 “Similar Image”,从磁盘上传图像,然后点击 “Search”。

我们可以看到相似的图片。我们尝试使用一个女孩的照片再试试:

因为我们在 Elasticsearch 中使用的 NLP(sentence-transformers/clip-ViT-B-32-multilingual-v1)模型是多语言的,支持多语言推理,所以尽量搜索自己语言的图片。 然后也使用英文文本验证结果。我们尝试使用 “黄山是中国最漂亮的山”:

请务必注意,使用的模型是通用模型,这些模型非常准确,但你获得的结果会因用例或其他因素而异。 如果你需要更高的精度,则必须采用通用模型或开发自己的模型 —— CLIP 模型只是一个起点。

代码摘要

你可以在 GitHub 存储库中找到完整的代码。 你可能正在检查 routes.py 中的代码,它实现了应用程序的主要逻辑。 除了明显的路线定义之外,你还应该关注定义 _infer 和 _search 端点(infer_trained_modelknn_search_images)的方法。 生成图像嵌入的代码位于 create-image-embeddings.py文件中。

总结

现在你已经设置了 Flask 应用程序,你可以轻松地搜索你自己的图像集! Elastic 在平台内提供了矢量搜索的原生集成,避免了与外部进程的通信。 你可以灵活地开发和使用你可能使用 PyTorch 开发的自定义嵌入模型。

语义图像搜索具有其他传统图像搜索方法的以下优点:

  • 更高的准确度:向量相似性捕获上下文和关联,而不依赖于图像的文本元描述。
  • 增强的用户体验:与猜测哪些关键字可能相关相比,描述你正在寻找的内容或提供示例图像。
  • 图像数据库的分类:不用担心对图像进行分类——相似性搜索可以在一堆图像中找到相关图像,而无需对它们进行组织。

如果你的用例更多地依赖于文本数据,你可以在以前的博客中了解更多关于实现语义搜索和将自然语言处理应用于文本的信息。 对于文本数据,向量相似度与传统关键词评分的结合呈现了两全其美的效果。

准备好开始了吗? 在我们的虚拟活动中心报名参加矢量搜索实践研讨会,并在我们的在线论坛中与社区互动。

收起阅读 »

Web Scraper + Elasticsearch + Kibana + SearchKit 打造的豆瓣电影top250 搜索演示系统

Web Scraper + Elasticsearch + Kibana + SearchKit 打造的豆瓣电影top250 搜索演示系统

作者:小森同学

声明:电影数据来源于“豆瓣电影”,如有侵权,请联系删除

1.png

2.png

Web Scraper

{
    "_id": "top250",
    "startUrl": ["https://movie.douban.com/top250?start=[0-225:25]&filter="],
    "selectors": [{
        "id": "container",
        "multiple": true,
        "parentSelectors": ["_root"],
        "selector": ".grid_view li",
        "type": "SelectorElement"
    }, {
        "id": "name",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "",
        "selector": "span.title:nth-of-type(1)",
        "type": "SelectorText"
    }, {
        "id": "number",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "",
        "selector": "em",
        "type": "SelectorText"
    }, {
        "id": "score",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "",
        "selector": "span.rating_num",
        "type": "SelectorText"
    }, {
        "id": "review",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "",
        "selector": "span.inq",
        "type": "SelectorText"
    }, {
        "id": "year",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "\\d{4}",
        "selector": "p:nth-of-type(1)",
        "type": "SelectorText"
    }, {
        "id": "tour_guide",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "^导演: \\S*",
        "selector": "p:nth-of-type(1)",
        "type": "SelectorText"
    }, {
        "id": "type",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "[^/]+$",
        "selector": "p:nth-of-type(1)",
        "type": "SelectorText"
    }, {
        "id": "area",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "[^\\/]+(?=\\/[^\\/]*$)",
        "selector": "p:nth-of-type(1)",
        "type": "SelectorText"
    }, {
        "id": "detail_link",
        "multiple": false,
        "parentSelectors": ["container"],
        "selector": ".hd a",
        "type": "SelectorLink"
    }, {
        "id": "director",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "",
        "selector": "span:nth-of-type(1) .attrs a",
        "type": "SelectorText"
    }, {
        "id": "screenwriter",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "(?<=编剧: )[\\u4e00-\\u9fa5A-Za-z0-9/()\\·\\s]+(?=主演)",
        "selector": "div#info",
        "type": "SelectorText"
    }, {
        "id": "film_length",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "\\d+",
        "selector": "span[property='v:runtime']",
        "type": "SelectorText"
    }, {
        "id": "IMDb",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "(?<=[IMDb:\\s+])\\S*(?=\\d*$)",
        "selector": "div#info",
        "type": "SelectorText"
    }, {
        "id": "language",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "(?<=语言: )\\S+",
        "selector": "div#info",
        "type": "SelectorText"
    }, {
        "id": "alias",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "(?<=又名: )[\\u4e00-\\u9fa5A-Za-z0-9/()\\s]+(?=IMDb)",
        "selector": "div#info",
        "type": "SelectorText"
    }, {
        "id": "pic",
        "multiple": false,
        "parentSelectors": ["container"],
        "selector": "img",
        "type": "SelectorImage"
    }]
}

elasticsearch

{
    "mappings": {
      "properties": {
        "IMDb": {
          "type": "keyword",
          "copy_to": [
            "all"
          ]
        },
        "alias": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "all": {
          "type": "text",
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "area": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "director": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "film_length": {
          "type": "long"
        },
        "id": {
          "type": "keyword"
        },
        "language": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "link": {
          "type": "keyword"
        },
        "name": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "number": {
          "type": "long"
        },
        "photo": {
          "type": "keyword"
        },
        "review": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "score": {
          "type": "double"
        },
        "screenwriter": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "type": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "year": {
          "type": "long"
        }
      }
    }
  }

kibana

需要使用pipeline对索引字段进行处理,如对type 通过空格进行分割为数组等,可以参照官方文档或其他博客。

制作仪表板省略, 请自行搜索

SearchKit

参考 https://github.com/searchkit/searchkit-starter-app

继续阅读 »

Web Scraper + Elasticsearch + Kibana + SearchKit 打造的豆瓣电影top250 搜索演示系统

作者:小森同学

声明:电影数据来源于“豆瓣电影”,如有侵权,请联系删除

1.png

2.png

Web Scraper

{
    "_id": "top250",
    "startUrl": ["https://movie.douban.com/top250?start=[0-225:25]&filter="],
    "selectors": [{
        "id": "container",
        "multiple": true,
        "parentSelectors": ["_root"],
        "selector": ".grid_view li",
        "type": "SelectorElement"
    }, {
        "id": "name",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "",
        "selector": "span.title:nth-of-type(1)",
        "type": "SelectorText"
    }, {
        "id": "number",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "",
        "selector": "em",
        "type": "SelectorText"
    }, {
        "id": "score",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "",
        "selector": "span.rating_num",
        "type": "SelectorText"
    }, {
        "id": "review",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "",
        "selector": "span.inq",
        "type": "SelectorText"
    }, {
        "id": "year",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "\\d{4}",
        "selector": "p:nth-of-type(1)",
        "type": "SelectorText"
    }, {
        "id": "tour_guide",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "^导演: \\S*",
        "selector": "p:nth-of-type(1)",
        "type": "SelectorText"
    }, {
        "id": "type",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "[^/]+$",
        "selector": "p:nth-of-type(1)",
        "type": "SelectorText"
    }, {
        "id": "area",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "[^\\/]+(?=\\/[^\\/]*$)",
        "selector": "p:nth-of-type(1)",
        "type": "SelectorText"
    }, {
        "id": "detail_link",
        "multiple": false,
        "parentSelectors": ["container"],
        "selector": ".hd a",
        "type": "SelectorLink"
    }, {
        "id": "director",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "",
        "selector": "span:nth-of-type(1) .attrs a",
        "type": "SelectorText"
    }, {
        "id": "screenwriter",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "(?<=编剧: )[\\u4e00-\\u9fa5A-Za-z0-9/()\\·\\s]+(?=主演)",
        "selector": "div#info",
        "type": "SelectorText"
    }, {
        "id": "film_length",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "\\d+",
        "selector": "span[property='v:runtime']",
        "type": "SelectorText"
    }, {
        "id": "IMDb",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "(?<=[IMDb:\\s+])\\S*(?=\\d*$)",
        "selector": "div#info",
        "type": "SelectorText"
    }, {
        "id": "language",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "(?<=语言: )\\S+",
        "selector": "div#info",
        "type": "SelectorText"
    }, {
        "id": "alias",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "(?<=又名: )[\\u4e00-\\u9fa5A-Za-z0-9/()\\s]+(?=IMDb)",
        "selector": "div#info",
        "type": "SelectorText"
    }, {
        "id": "pic",
        "multiple": false,
        "parentSelectors": ["container"],
        "selector": "img",
        "type": "SelectorImage"
    }]
}

elasticsearch

{
    "mappings": {
      "properties": {
        "IMDb": {
          "type": "keyword",
          "copy_to": [
            "all"
          ]
        },
        "alias": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "all": {
          "type": "text",
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "area": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "director": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "film_length": {
          "type": "long"
        },
        "id": {
          "type": "keyword"
        },
        "language": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "link": {
          "type": "keyword"
        },
        "name": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "number": {
          "type": "long"
        },
        "photo": {
          "type": "keyword"
        },
        "review": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "score": {
          "type": "double"
        },
        "screenwriter": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "type": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "year": {
          "type": "long"
        }
      }
    }
  }

kibana

需要使用pipeline对索引字段进行处理,如对type 通过空格进行分割为数组等,可以参照官方文档或其他博客。

制作仪表板省略, 请自行搜索

SearchKit

参考 https://github.com/searchkit/searchkit-starter-app

收起阅读 »

如何正确处理 Elasticsearch 摄取管道故障

Elasticsearch 中的 ingest node 给开发者们带来了极大的方便。Ingest node 是 Elasticsearch 集群中的一部分。相比较 Logstash 而言,它易于扩展。同时它有大量的处理器供开发者使用。我们可以充分利用它多数据进行清洗,转换,丰富等等操作。在我们摄入数据的时候,由于数据格式的问题,往往会发生错误,那么我们该如何处理这些错误呢?在 Logstash 的实现中,我们可以利用 Dead Letter Queue 来记录失败的文档。那么我们可以在 ingest pipeline 里,实现同样的机制吗?请详细阅读文章 “如何正确处理 Elasticsearch 摄取管道故障” https://elasticstack.blog.csdn ... 73575 在文章中,我们实例了一种叫做 Dead Letter Index,它可以记录失败的文档,并可以回放让我们修正摄入文档中的错误。
继续阅读 »
Elasticsearch 中的 ingest node 给开发者们带来了极大的方便。Ingest node 是 Elasticsearch 集群中的一部分。相比较 Logstash 而言,它易于扩展。同时它有大量的处理器供开发者使用。我们可以充分利用它多数据进行清洗,转换,丰富等等操作。在我们摄入数据的时候,由于数据格式的问题,往往会发生错误,那么我们该如何处理这些错误呢?在 Logstash 的实现中,我们可以利用 Dead Letter Queue 来记录失败的文档。那么我们可以在 ingest pipeline 里,实现同样的机制吗?请详细阅读文章 “如何正确处理 Elasticsearch 摄取管道故障” https://elasticstack.blog.csdn ... 73575 在文章中,我们实例了一种叫做 Dead Letter Index,它可以记录失败的文档,并可以回放让我们修正摄入文档中的错误。 收起阅读 »

Elasticsearch:使用 pipelines 路由文档到想要的 Elasticsearch 索引中去

原文地址 elasticstack.blog.csdn.net

路由文件

当应用程序需要向 Elasticsearch 添加文档时,它们首先要知道目标索引是什么。在很多的应用案例中,特别是针对时序数据,我们想把每个月的数据写入到一个特定的索引中。一方面便于管理索引,另外一方面在将来搜索的时候可以按照每个月的索引来进行搜索,这样速度更快,更便捷。

当你处于某种类型的文档总是转到特定索引的琐碎情况时,这似乎很明显,但当你的索引名称可能根据杂项参数(无论它们是否在你的系统外部 - 当前例如日期 - 或者你尝试存储的文档的固有属性 - 大多数时候是文档字段之一的值)。

当发生最后一种情况时(我们指的是索引名称可以变化的情况),在向 Elasticsearch 发出索引命令之前,你的应用程序需要计算目标索引的名称。

此外 —— 即使一开始这看起来像是一种反模式 —— 你可以有多个应用程序需要在索引中索引相同类型的文档,这些文档的名称可能会发生变化。 现在你必须维护跨多个组件重复的索引名称计算逻辑:就可维护性和敏捷性而言,这不是好消息。

Logstash —— Elastic Stack 的一个知名成员 —— 可以帮助集中这样的逻辑,但代价是维护另一个正在运行的软件,这需要配置、知识等。

我们想要在本文中展示的是通过将索引名称计算委托给 Elasticsearch 而不是我们的应用程序来解决此问题的解决方案。

Date index name processor 介绍

处理器的目的是通过使用日期数学索引名称支持,根据文档中的日期或时间戳字段将文档指向基于正确时间的索引。

处理器根据提供的索引名称前缀、正在处理的文档中的日期或时间戳字段以及提供的日期舍入,使用日期数学索引名称表达式设置 _index 元数据字段。

首先,此处理器从正在处理的文档中的字段中获取日期或时间戳。 或者,可以根据字段值应如何解析为日期来配置日期格式。 然后这个日期、提供的索引名称前缀和提供的日期舍入被格式化为日期数学索引名称表达式。 此处还可以选择日期格式指定日期应如何格式化为日期数学索引名称表达式。

将文档指向每月索引的示例管道,该索引以基于 date1 字段中的日期的 my-index-prefix 开头:


1.  PUT _ingest/pipeline/monthlyindex
2.  {
3.    "description": "monthly date-time index naming",
4.    "processors" : [
5.      {
6.        "date_index_name" : {
7.          "field" : "date1",
8.          "index_name_prefix" : "my-",
9.          "date_rounding" : "M"
10.        }
11.      }
12.    ]
13.  }

使用该管道进行索引请求:


1.  PUT /my-index/_doc/1?pipeline=monthlyindex
2.  {
3.    "date1" : "2016-04-25T12:02:01.789Z"
4.  }

上面命令运行的结果是:


1.  {
2.    "_index": "my-index-2016-04-01",
3.    "_id": "1",
4.    "_version": 1,
5.    "result": "created",
6.    "_shards": {
7.      "total": 2,
8.      "successful": 1,
9.      "failed": 0
10.    },
11.    "_seq_no": 0,
12.    "_primary_term": 1
13.  }

上面的请求不会将这个文档索引到 my-index 索引中,而是索引到 my-index-2016-04-01 索引中,因为它是按月取整的。 这是因为 date-index-name-processor 覆盖了文档的 _index 属性。

要查看导致上述文档被索引到 my-index-2016-04-01 中的实际索引请求中提供的索引的日期数学(date-math)值,我们可以使用模拟请求检查处理器的效果。


1.  POST _ingest/pipeline/_simulate
2.  {
3.    "pipeline" :
4.    {
5.      "description": "monthly date-time index naming",
6.      "processors" : [
7.        {
8.          "date_index_name" : {
9.            "field" : "date1",
10.            "index_name_prefix" : "my-",
11.            "date_rounding" : "M"
12.          }
13.        }
14.      ]
15.    },
16.    "docs": [
17.      {
18.        "_source": {
19.          "date1": "2016-04-25T12:02:01.789Z"
20.        }
21.      }
22.    ]
23.  }

上面命令返回结果:

`

1.  {
2.    "docs": [
3.      {
4.        "doc": {
5.          "_index": "<my-index-{2016-04-25||/M{yyyy-MM-dd|UTC}}>",
6.          "_id": "_id",
7.          "_version": "-3",
8.          "_source": {
9.            "date1": "2016-04-25T12:02:01.789Z"
10.          },
11.          "_ingest": {
12.            "timestamp": "2023-02-23T01:15:52.214364Z"
13.          }
14.        }
15.      }
16.    ]
17.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

以上示例显示 _index 设置为 <my-index-{2016-04-25||/M{yyyy-MM-dd|UTC}}>。 Elasticsearch 将其理解为 2016-04-01,如日期数学索引名称文档中所述。

日期索引名称选项

以下是使用 date index name 的一些选项

no-处理器的描述。 用于描述处理器的用途或其配置。
ifno-有条件地执行处理器。 请参阅有条件地运行处理器
ignore_failurenofalse忽略处理器的故障。 请参阅处理管道故障
on_failureno-处理处理器的故障。 请参阅处理管道故障
tagno-处理器的标识符。 用于调试和指标

使用案例 - 基于时间的时序索引

这是一个众所周知的用例,通常在您要处理日志时发现。这个想法是索引文档,索引的名称由根名称和根据日志事件的日期计算的值组成。 该日期实际上是你要索引的文档的一个字段。

这不是本文的重点,但以这种方式索引文档有几个优点,包括更容易的数据管理、启用冷/暖架构等。让我们举个例子。

假设我们必须处理来自多个来源的数据 —— 例如物联网。 我们的每个对象每分钟都会向不同的后端发送一些数据(是的,这真的很可悲,但我们的对象不通过相同的网络进行通信,因此选择通过多个系统来处理这个问题)。

对象发送的数据被转换成如下所示的 JSON 文档:


1.  POST data/_doc?pipeline=compute-index-name
2.  {
3.    "objectId": 1234,
4.    "manufacturer": "SHIELD",
5.    "payload": "some_data",
6.    "date": "2019-04-01T12:10:30.000Z"
7.  }

我们有一个用于传输数据的对象的 UID、一个制造商 ID、一个有效负载部分和一个日期字段。

索引名称计算

假设我们要将对象的数据存储在名为 data-{YYYYMMDD} 的索引中,其中根名称是数据后跟日期模式。基于上面的例子,后端收到这个文档应该怎么办呢?

首先它必须解析它以提取日期字段的值,然后它必须根据它在文档中找到的日期计算目标索引名称。 最后,它向 Elasticsearch 向刚刚计算出名称的索引发出索引请求。


1.  document.date = "2019-04-01T12:10:30Z"
2.  index.name = "" + "20190401"

在我们的例子中,我们有几个后端必须知道如何计算索引名称,因此必须知道索引的命名逻辑。

如果索引名的计算直接由 Elasticsearch 进行,岂不是更聪明?

Ingest pipeline 的力量

从 Elasticsearch 的第 5 版开始,我们现在有了一种称为摄取的节点。默认情况下,集群的所有节点都具有 ingest 类型。这些节点有权在索引文档之前执行所谓的管道。 管道是一组处理器,每个处理器都可以以某种特定方式转换输入文档。当一个文档被摄入到 Elasticsearch 集群时,它的工作流是这样的。

从上面,我们可以看出来,在文档被写入之前,它必须经过 ingest node 进行处理。我们可以通过 date index name processor 来获得我们想要的 index 名称,进而写入到我们想要的索引中去。 这里有用的是,管道不仅可以转换文档的固有数据,还可以修改文档元数据,特别是它的 _index 属性。

现在让我们回到我们的例子。我们建议定义一个管道来完成这项工作,而不是将索引名称计算委托给应用程序。根据文档,此处理器允许你定义包含日期的字段名称、索引的根名称(前缀)以及计算附加到此前缀的日期的舍入方法。

如果我们想将 IoT 数据添加到模式为 data-{YYYYMMDD} 的索引中,我们只需创建如下所示的管道:


1.  PUT _ingest/pipeline/compute-index-name
2.  {
3.    "description": "Set the document destination index by appending a prefix and its 'date' field",
4.    "processors": [
5.      {
6.        "date_index_name": {
7.          "field": "date",
8.          "index_name_prefix": "",
9.          "date_rounding": "d",
10.          "index_name_format": "yyyyMMdd"
11.        }
12.      }
13.    ]
14.  }

一个索引 = 一个管道?

好的,现在我们知道如何定义一个管道来为特定的目标索引建立一个名称。 但是我们可以通过操纵文档元数据来做更多的事情!

假设我们有不同类型的文档,每个文档都有一个日期字段,但需要在不同的索引中进行索引。计算目标索引名称的逻辑对于每种文档类型都是相同的,但使用上述策略将导致创建多个管道。

让我们试着做一些更简单和可重用的东西。

回到我们的示例,我们现在有两种文档类型:一种需要在 adata-{YYYYMMDD} 索引(和以前一样)中建立索引,另一种其目的地是名为 new_data-{YYYYMMDD} 的索引。

目标为 new_data 的文档具有以下结构:


1.  {
2.    "newObjectId": 1234,
3.    "source": "HYDRA",
4.    "payload": "some_data",
5.    "date": "2019-04-02T13:10:30.000Z"
6.  }

该结构与标准 IoT 文档略有不同,但重要的是日期字段存在于两个映射中。

现在我们要定义一个管道来计算我们两种文档类型的目标索引。 我们所要做的就是通过分析通过索引 API 发出的请求目的地来构建目的地索引名称。


1.  PUT _ingest/pipeline/compute-index-name
2.  {
3.    "description": "Set the document destination index by appending the requested index and its 'date' field",
4.    "processors": [
5.      {
6.        "date_index_name": {
7.          "field": "date",
8.          "index_name_prefix": "{{ _index }}-",
9.          "date_rounding": "d",
10.          "index_name_format": "yyyyMMdd"
11.        }
12.      }
13.    ]
14.  }

请注意,索引名称前缀现在位于名为_index 的索引元数据字段中。 通过使用这个字段,我们的管道现在是通用的并且可以与任何索引一起使用 —— 假设目标索引是根据相同的规则计算的。

使用我们的 “路由” 管道

现在我们有了一个能够根据文档的日期字段计算目标索引名称的通用管道,让我们看看如何让 Elasticsearch 使用它。

我们可以通过两种方式告诉 Elasticsearch 使用管道,让我们评估一下。

Index API 调用

第一个 —— 也是直接的解决方案——是使用 Index API 的管道参数。

换句话说:每次你想索引一个文档,你必须告诉 Elasticsearch 要使用的管道。


1.  POST data/_doc?pipeline=compute-index-name
2.  {
3.    "objectId": 1234,
4.    "manufacturer": "SHIELD",
5.    "payload": "some_data",
6.    "date": "2019-04-01T12:10:30.000Z"
7.  }

现在,每次我们通过指示 compute-index-name 管道将文档添加到索引中时,该文档将被添加到正确的基于时间的索引中。 在此示例中,目标索引将为 data-20190401 。

我们提供给 Index API 的 data 索引名称呢? 它可以被看作是一个索引:它只是用来执行 API 调用并且是真正目标索引的根,它不一定存在!

默认管道:引入 “虚拟索引”

索引默认管道(default pipeline)是使用管道的另一种有用方式:当你创建索引时,有一个名为 index.default_pipeline 的设置可以设置为管道的名称,只要你将文档添加到相应的索引就会执行该管道并且没有管道被添加到 API 调用中。 你还可以在索引文档时使用特殊管道名称 _none 来绕过此默认索引。 通过使用此功能,你可以定义我称之为 “虚拟索引” 的内容,并将其与默认管道相关联,该默认管道将充当我们上面看到的路由管道。

让我们将其应用到我们的示例中。

我们假设我们的通用路由管道 compute-index-name 已经创建。 我们现在可以创建一个名为 data 的索引,它将使用此管道作为其默认管道。


1.  PUT data
2.  {
3.    "settings" : {
4.      "index" : {
5.        "number_of_shards" : 3, 
6.        "number_of_replicas" : 1,
7.        "default_pipeline" : "compute-index-name"
8.      }
9.    }
10.  }

现在,每次我们要求 Elasticsearch 为数据索引中的文档编制索引时,计算索引名称管道将负责该文档的实际路由。 因此,数据索引中永远不会有单个文档被索引,但我们将调用管道的责任完全委托给 Elasticsearch。

运行完上面的命令后,我们来尝试写入一个文档:


1.  POST data/_doc
2.  {
3.    "objectId": 1234,
4.    "manufacturer": "SHIELD",
5.    "payload": "some_data",
6.    "date": "2019-04-01T12:10:30.000Z"
7.  }

上面的命令返回的结果是:


1.  {
2.    "_index": "data-20190401",
3.    "_id": "2DMGfIYBaog4blQ55Qr7",
4.    "_version": 1,
5.    "result": "created",
6.    "_shards": {
7.      "total": 2,
8.      "successful": 1,
9.      "failed": 0
10.    },
11.    "_seq_no": 1,
12.    "_primary_term": 1
13.  }

结论

我们刚刚在这里看到了如何利用 Elasticsearch 中的管道功能根据文档的固有属性来路由文档。Ingest pipeline 不仅仅可以替代 Logstash 过滤器:你可以定义复杂的管道,使用多个处理器(一个特定的处理器甚至允许你调用另一个管道)、条件等。有关 ingest pipeline 的更多文章,请参阅 “Elastic:开发者上手指南” 文章中的 “Ingest pipeline” 章节。

在我看来,本文末尾看到的 “虚拟索引” 非常有趣。 包含创建这样一个并非真正的索引的索引只是为了创建路由管道的入口点的功能甚至可以成为 Elasticsearch 的一个新的和有用的功能,为什么不呢?

继续阅读 »

原文地址 elasticstack.blog.csdn.net

路由文件

当应用程序需要向 Elasticsearch 添加文档时,它们首先要知道目标索引是什么。在很多的应用案例中,特别是针对时序数据,我们想把每个月的数据写入到一个特定的索引中。一方面便于管理索引,另外一方面在将来搜索的时候可以按照每个月的索引来进行搜索,这样速度更快,更便捷。

当你处于某种类型的文档总是转到特定索引的琐碎情况时,这似乎很明显,但当你的索引名称可能根据杂项参数(无论它们是否在你的系统外部 - 当前例如日期 - 或者你尝试存储的文档的固有属性 - 大多数时候是文档字段之一的值)。

当发生最后一种情况时(我们指的是索引名称可以变化的情况),在向 Elasticsearch 发出索引命令之前,你的应用程序需要计算目标索引的名称。

此外 —— 即使一开始这看起来像是一种反模式 —— 你可以有多个应用程序需要在索引中索引相同类型的文档,这些文档的名称可能会发生变化。 现在你必须维护跨多个组件重复的索引名称计算逻辑:就可维护性和敏捷性而言,这不是好消息。

Logstash —— Elastic Stack 的一个知名成员 —— 可以帮助集中这样的逻辑,但代价是维护另一个正在运行的软件,这需要配置、知识等。

我们想要在本文中展示的是通过将索引名称计算委托给 Elasticsearch 而不是我们的应用程序来解决此问题的解决方案。

Date index name processor 介绍

处理器的目的是通过使用日期数学索引名称支持,根据文档中的日期或时间戳字段将文档指向基于正确时间的索引。

处理器根据提供的索引名称前缀、正在处理的文档中的日期或时间戳字段以及提供的日期舍入,使用日期数学索引名称表达式设置 _index 元数据字段。

首先,此处理器从正在处理的文档中的字段中获取日期或时间戳。 或者,可以根据字段值应如何解析为日期来配置日期格式。 然后这个日期、提供的索引名称前缀和提供的日期舍入被格式化为日期数学索引名称表达式。 此处还可以选择日期格式指定日期应如何格式化为日期数学索引名称表达式。

将文档指向每月索引的示例管道,该索引以基于 date1 字段中的日期的 my-index-prefix 开头:


1.  PUT _ingest/pipeline/monthlyindex
2.  {
3.    "description": "monthly date-time index naming",
4.    "processors" : [
5.      {
6.        "date_index_name" : {
7.          "field" : "date1",
8.          "index_name_prefix" : "my-",
9.          "date_rounding" : "M"
10.        }
11.      }
12.    ]
13.  }

使用该管道进行索引请求:


1.  PUT /my-index/_doc/1?pipeline=monthlyindex
2.  {
3.    "date1" : "2016-04-25T12:02:01.789Z"
4.  }

上面命令运行的结果是:


1.  {
2.    "_index": "my-index-2016-04-01",
3.    "_id": "1",
4.    "_version": 1,
5.    "result": "created",
6.    "_shards": {
7.      "total": 2,
8.      "successful": 1,
9.      "failed": 0
10.    },
11.    "_seq_no": 0,
12.    "_primary_term": 1
13.  }

上面的请求不会将这个文档索引到 my-index 索引中,而是索引到 my-index-2016-04-01 索引中,因为它是按月取整的。 这是因为 date-index-name-processor 覆盖了文档的 _index 属性。

要查看导致上述文档被索引到 my-index-2016-04-01 中的实际索引请求中提供的索引的日期数学(date-math)值,我们可以使用模拟请求检查处理器的效果。


1.  POST _ingest/pipeline/_simulate
2.  {
3.    "pipeline" :
4.    {
5.      "description": "monthly date-time index naming",
6.      "processors" : [
7.        {
8.          "date_index_name" : {
9.            "field" : "date1",
10.            "index_name_prefix" : "my-",
11.            "date_rounding" : "M"
12.          }
13.        }
14.      ]
15.    },
16.    "docs": [
17.      {
18.        "_source": {
19.          "date1": "2016-04-25T12:02:01.789Z"
20.        }
21.      }
22.    ]
23.  }

上面命令返回结果:

`

1.  {
2.    "docs": [
3.      {
4.        "doc": {
5.          "_index": "<my-index-{2016-04-25||/M{yyyy-MM-dd|UTC}}>",
6.          "_id": "_id",
7.          "_version": "-3",
8.          "_source": {
9.            "date1": "2016-04-25T12:02:01.789Z"
10.          },
11.          "_ingest": {
12.            "timestamp": "2023-02-23T01:15:52.214364Z"
13.          }
14.        }
15.      }
16.    ]
17.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

以上示例显示 _index 设置为 <my-index-{2016-04-25||/M{yyyy-MM-dd|UTC}}>。 Elasticsearch 将其理解为 2016-04-01,如日期数学索引名称文档中所述。

日期索引名称选项

以下是使用 date index name 的一些选项

no-处理器的描述。 用于描述处理器的用途或其配置。
ifno-有条件地执行处理器。 请参阅有条件地运行处理器
ignore_failurenofalse忽略处理器的故障。 请参阅处理管道故障
on_failureno-处理处理器的故障。 请参阅处理管道故障
tagno-处理器的标识符。 用于调试和指标

使用案例 - 基于时间的时序索引

这是一个众所周知的用例,通常在您要处理日志时发现。这个想法是索引文档,索引的名称由根名称和根据日志事件的日期计算的值组成。 该日期实际上是你要索引的文档的一个字段。

这不是本文的重点,但以这种方式索引文档有几个优点,包括更容易的数据管理、启用冷/暖架构等。让我们举个例子。

假设我们必须处理来自多个来源的数据 —— 例如物联网。 我们的每个对象每分钟都会向不同的后端发送一些数据(是的,这真的很可悲,但我们的对象不通过相同的网络进行通信,因此选择通过多个系统来处理这个问题)。

对象发送的数据被转换成如下所示的 JSON 文档:


1.  POST data/_doc?pipeline=compute-index-name
2.  {
3.    "objectId": 1234,
4.    "manufacturer": "SHIELD",
5.    "payload": "some_data",
6.    "date": "2019-04-01T12:10:30.000Z"
7.  }

我们有一个用于传输数据的对象的 UID、一个制造商 ID、一个有效负载部分和一个日期字段。

索引名称计算

假设我们要将对象的数据存储在名为 data-{YYYYMMDD} 的索引中,其中根名称是数据后跟日期模式。基于上面的例子,后端收到这个文档应该怎么办呢?

首先它必须解析它以提取日期字段的值,然后它必须根据它在文档中找到的日期计算目标索引名称。 最后,它向 Elasticsearch 向刚刚计算出名称的索引发出索引请求。


1.  document.date = "2019-04-01T12:10:30Z"
2.  index.name = "" + "20190401"

在我们的例子中,我们有几个后端必须知道如何计算索引名称,因此必须知道索引的命名逻辑。

如果索引名的计算直接由 Elasticsearch 进行,岂不是更聪明?

Ingest pipeline 的力量

从 Elasticsearch 的第 5 版开始,我们现在有了一种称为摄取的节点。默认情况下,集群的所有节点都具有 ingest 类型。这些节点有权在索引文档之前执行所谓的管道。 管道是一组处理器,每个处理器都可以以某种特定方式转换输入文档。当一个文档被摄入到 Elasticsearch 集群时,它的工作流是这样的。

从上面,我们可以看出来,在文档被写入之前,它必须经过 ingest node 进行处理。我们可以通过 date index name processor 来获得我们想要的 index 名称,进而写入到我们想要的索引中去。 这里有用的是,管道不仅可以转换文档的固有数据,还可以修改文档元数据,特别是它的 _index 属性。

现在让我们回到我们的例子。我们建议定义一个管道来完成这项工作,而不是将索引名称计算委托给应用程序。根据文档,此处理器允许你定义包含日期的字段名称、索引的根名称(前缀)以及计算附加到此前缀的日期的舍入方法。

如果我们想将 IoT 数据添加到模式为 data-{YYYYMMDD} 的索引中,我们只需创建如下所示的管道:


1.  PUT _ingest/pipeline/compute-index-name
2.  {
3.    "description": "Set the document destination index by appending a prefix and its 'date' field",
4.    "processors": [
5.      {
6.        "date_index_name": {
7.          "field": "date",
8.          "index_name_prefix": "",
9.          "date_rounding": "d",
10.          "index_name_format": "yyyyMMdd"
11.        }
12.      }
13.    ]
14.  }

一个索引 = 一个管道?

好的,现在我们知道如何定义一个管道来为特定的目标索引建立一个名称。 但是我们可以通过操纵文档元数据来做更多的事情!

假设我们有不同类型的文档,每个文档都有一个日期字段,但需要在不同的索引中进行索引。计算目标索引名称的逻辑对于每种文档类型都是相同的,但使用上述策略将导致创建多个管道。

让我们试着做一些更简单和可重用的东西。

回到我们的示例,我们现在有两种文档类型:一种需要在 adata-{YYYYMMDD} 索引(和以前一样)中建立索引,另一种其目的地是名为 new_data-{YYYYMMDD} 的索引。

目标为 new_data 的文档具有以下结构:


1.  {
2.    "newObjectId": 1234,
3.    "source": "HYDRA",
4.    "payload": "some_data",
5.    "date": "2019-04-02T13:10:30.000Z"
6.  }

该结构与标准 IoT 文档略有不同,但重要的是日期字段存在于两个映射中。

现在我们要定义一个管道来计算我们两种文档类型的目标索引。 我们所要做的就是通过分析通过索引 API 发出的请求目的地来构建目的地索引名称。


1.  PUT _ingest/pipeline/compute-index-name
2.  {
3.    "description": "Set the document destination index by appending the requested index and its 'date' field",
4.    "processors": [
5.      {
6.        "date_index_name": {
7.          "field": "date",
8.          "index_name_prefix": "{{ _index }}-",
9.          "date_rounding": "d",
10.          "index_name_format": "yyyyMMdd"
11.        }
12.      }
13.    ]
14.  }

请注意,索引名称前缀现在位于名为_index 的索引元数据字段中。 通过使用这个字段,我们的管道现在是通用的并且可以与任何索引一起使用 —— 假设目标索引是根据相同的规则计算的。

使用我们的 “路由” 管道

现在我们有了一个能够根据文档的日期字段计算目标索引名称的通用管道,让我们看看如何让 Elasticsearch 使用它。

我们可以通过两种方式告诉 Elasticsearch 使用管道,让我们评估一下。

Index API 调用

第一个 —— 也是直接的解决方案——是使用 Index API 的管道参数。

换句话说:每次你想索引一个文档,你必须告诉 Elasticsearch 要使用的管道。


1.  POST data/_doc?pipeline=compute-index-name
2.  {
3.    "objectId": 1234,
4.    "manufacturer": "SHIELD",
5.    "payload": "some_data",
6.    "date": "2019-04-01T12:10:30.000Z"
7.  }

现在,每次我们通过指示 compute-index-name 管道将文档添加到索引中时,该文档将被添加到正确的基于时间的索引中。 在此示例中,目标索引将为 data-20190401 。

我们提供给 Index API 的 data 索引名称呢? 它可以被看作是一个索引:它只是用来执行 API 调用并且是真正目标索引的根,它不一定存在!

默认管道:引入 “虚拟索引”

索引默认管道(default pipeline)是使用管道的另一种有用方式:当你创建索引时,有一个名为 index.default_pipeline 的设置可以设置为管道的名称,只要你将文档添加到相应的索引就会执行该管道并且没有管道被添加到 API 调用中。 你还可以在索引文档时使用特殊管道名称 _none 来绕过此默认索引。 通过使用此功能,你可以定义我称之为 “虚拟索引” 的内容,并将其与默认管道相关联,该默认管道将充当我们上面看到的路由管道。

让我们将其应用到我们的示例中。

我们假设我们的通用路由管道 compute-index-name 已经创建。 我们现在可以创建一个名为 data 的索引,它将使用此管道作为其默认管道。


1.  PUT data
2.  {
3.    "settings" : {
4.      "index" : {
5.        "number_of_shards" : 3, 
6.        "number_of_replicas" : 1,
7.        "default_pipeline" : "compute-index-name"
8.      }
9.    }
10.  }

现在,每次我们要求 Elasticsearch 为数据索引中的文档编制索引时,计算索引名称管道将负责该文档的实际路由。 因此,数据索引中永远不会有单个文档被索引,但我们将调用管道的责任完全委托给 Elasticsearch。

运行完上面的命令后,我们来尝试写入一个文档:


1.  POST data/_doc
2.  {
3.    "objectId": 1234,
4.    "manufacturer": "SHIELD",
5.    "payload": "some_data",
6.    "date": "2019-04-01T12:10:30.000Z"
7.  }

上面的命令返回的结果是:


1.  {
2.    "_index": "data-20190401",
3.    "_id": "2DMGfIYBaog4blQ55Qr7",
4.    "_version": 1,
5.    "result": "created",
6.    "_shards": {
7.      "total": 2,
8.      "successful": 1,
9.      "failed": 0
10.    },
11.    "_seq_no": 1,
12.    "_primary_term": 1
13.  }

结论

我们刚刚在这里看到了如何利用 Elasticsearch 中的管道功能根据文档的固有属性来路由文档。Ingest pipeline 不仅仅可以替代 Logstash 过滤器:你可以定义复杂的管道,使用多个处理器(一个特定的处理器甚至允许你调用另一个管道)、条件等。有关 ingest pipeline 的更多文章,请参阅 “Elastic:开发者上手指南” 文章中的 “Ingest pipeline” 章节。

在我看来,本文末尾看到的 “虚拟索引” 非常有趣。 包含创建这样一个并非真正的索引的索引只是为了创建路由管道的入口点的功能甚至可以成为 Elasticsearch 的一个新的和有用的功能,为什么不呢?

收起阅读 »

Elasticsearch:如何在 Elasticsearch 中正确使用同义词功能

原文地址 elasticstack.blog.csdn.net

同义词用于提高搜索质量并扩大匹配范围。 例如,搜索 England 的用户可能希望找到包含 British 或 UK 的文档,尽管这三个词完全不同。

Elasticsearch 中的同义词功能非常强大,如果实施得当,可以使你的搜索引擎更加健壮和强大。 在本文中,我们将通过简单的代码片段介绍在实践中实现同义词功能的要点。 特别是,我们将介绍如何更新现有索引的同义词,这是一个相对高级的话题。

在今天的展示中,我将使用最新的 Elastic Stack 8.6.0,尽管版本不对我们的展示有任何的影响。

准备

我们将使用 Docker 在本地启动一个 Elasticsearch 服务器,并使用 Kibana 来管理索引和运行命令。 如果你以前从未使用过 Elasticsearch 或想快速复习一下,这篇文章可能会对你有所帮助。 如果你在 Docker 中运行 Elasticsearch 时遇到问题,这篇文章很可能会帮助你解决问题。在今天的文章中,我们尝试使用 docker 来部署一个没有安全功能的 Elasticsearch 集群。

准备就绪后,让我们开始探索 Elasticsearch 中的同义词功能的旅程。

我们将在本文中使用的 docker-compose.yaml 文件包含以下内容,稍后我们将向其添加更多功能:

docker-compose.yml

`

1.  version: "3.9"
2.  services:
3.    elasticsearch:
4.      image: elasticsearch:8.6.0
5.      environment:
6.        - discovery.type=single-node
7.        - ES_JAVA_OPTS=-Xms1g -Xmx1g
8.        - xpack.security.enabled=false
9.      volumes:
10.        - type: volume
11.          source: es_data
12.          target: /usr/share/elasticsearch/data
13.      ports:
14.        - target: 9200
15.          published: 9200
16.      networks:
17.        - elastic

19.    kibana:
20.      image: kibana:8.6.0
21.      ports:
22.        - target: 5601
23.          published: 5601
24.      depends_on:
25.        - elasticsearch
26.      networks:
27.        - elastic      

29.  volumes:
30.    es_data:
31.      driver: local

33.  networks:
34.    elastic:
35.      name: elastic
36.      driver: bridge

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

你可以使用以下命令之一启动 Elasticsearch 和 Kibana:

docker-compose up

或者

docker-compose up -d

如果加上 -d 选项的话,Elasticsearch 会以 daemon 的形式来运行。上面是一种最为简单的方式来启动 Elasticsearch 集群及 Kibana。由于它没有设置安全,我们无需输入任何凭证就可以直接进入到 Kibana 了。

使用带有同义词列表的标准同义词 token 过滤器

让我们首先使用带有同义词列表的标准同义词标记过滤器创建一个索引。 在 Kibana 中运行以下命令,我们将在稍后解释详细信息: 

`

1.  PUT synonyms
2.  {
3.    "settings": {
4.      "index": {
5.        "analysis": {
6.          "analyzer": {
7.            "index_analyzer": {
8.              "tokenizer": "standard",
9.              "filter": [
10.                "lowercase",
11.                "synonym_filter"
12.              ]
13.            }
14.          },
15.          "filter": {
16.            "synonym_filter": {
17.              "type": "synonym",
18.              "synonyms": [
19.                "elk => Elastic Stack",
20.                "elkb => Elastic Stack"
21.              ]
22.            }
23.          }
24.        }
25.      }
26.    },
27.    "mappings": {
28.      "properties": {
29.        "name": {
30.          "type": "text",
31.          "analyzer": "index_analyzer"
32.        }
33.      }
34.    }
35.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

这里的要点

  1. 请注意设置键的嵌套级别。 settings => index => analysis => analyzer/filter 都是内置关键字。 但是,index_analyzer 和 synonym_filter 分别是自定义分析器和过滤器的自定义名称。
  2. 我们需要创建一个 type 为 synonym 的自定义过滤器。 synonym 选项明确提供了同义词列表。 这通常应该只用于测试,因为更新同义词列表不方便,我们稍后会看到。
  3. 本文中使用了 Solr 同义词。 对于此示例,使用了显式映射,这意味着 => 左侧的标记将替换为右侧的标记。 稍后我们将使用等同的同义词,这意味着提供的 token 被等同对待。
  4. synonym_filter 添加到名为 index_analyzer 的新自定义分析器的过滤器列表中。 通常过滤器的顺序很重要。 然而,对于同义词过滤器来说,它有点特殊,可能会让我们中的许多人感到惊讶。 在此示例中,即使 synonym_filter 过滤器放在小写过滤器之后,此过滤器返回的标记也会传递给小写过滤器,因此也会变成小写。 因此,你不需要在同义词列表或同义词文件中提供小写 token。
  5. 最后,在文档的映射中,为名称字段指定了自定义分析器。

我们知道在早期的 Elastic 产品中 elk 就是 Elastic Stack 的代名词。之后随着 Beats 的加入,很多开发者也把 elkb 当做 Elastic Stack 的代名词。要测试在索引中创建的分析器,我们可以调用 _analyze 端点:


1.  GET /synonyms/_analyze
2.  {
3.    "analyzer": "index_analyzer",
4.    "text": "elk is powerful"
5.  }

上面命令的输出为:

`

1.  {
2.    "tokens": [
3.      {
4.        "token": "elastic",
5.        "start_offset": 0,
6.        "end_offset": 3,
7.        "type": "SYNONYM",
8.        "position": 0
9.      },
10.      {
11.        "token": "is",
12.        "start_offset": 4,
13.        "end_offset": 6,
14.        "type": "<ALPHANUM>",
15.        "position": 1
16.      },
17.      {
18.        "token": "stack",
19.        "start_offset": 4,
20.        "end_offset": 6,
21.        "type": "SYNONYM",
22.        "position": 1
23.      },
24.      {
25.        "token": "powerful",
26.        "start_offset": 7,
27.        "end_offset": 15,
28.        "type": "<ALPHANUM>",
29.        "position": 2
30.      }
31.    ]
32.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

从上面的输出中,我们可以看到 type 为 SNONYM 的 token 为 elastic 及 stack。让我们向索引中添加一些文档并测试它在搜索中是否正常工作:


1.  PUT /synonyms/_doc/1
2.  {
3.    "name": "elk is very powerful"
4.  }

6.  PUT /synonyms/_doc/2
7.  {
8.    "name": "elkb is useful"
9.  }

11.  PUT /synonyms/_doc/3
12.  {
13.    "name": "Elastic Stack is so widely used"
14.  }

我们可以使用 match 关键字进行简单的搜索:


1.  GET /synonyms/_search?filter_path=**.hits
2.  {
3.    "query": {
4.      "match": {
5.        "name": "elk"
6.      }
7.    }
8.  }

如果没有问题,所有三个文件都应该被搜索到:

`

1.  {
2.    "hits": {
3.      "hits": [
4.        {
5.          "_index": "synonyms",
6.          "_id": "2",
7.          "_score": 0.31931418,
8.          "_source": {
9.            "name": "elkb is useful"
10.          }
11.        },
12.        {
13.          "_index": "synonyms",
14.          "_id": "1",
15.          "_score": 0.29086044,
16.          "_source": {
17.            "name": "elk is very powerful"
18.          }
19.        },
20.        {
21.          "_index": "synonyms",
22.          "_id": "3",
23.          "_score": 0.24686477,
24.          "_source": {
25.            "name": "Elastic Stack is so widely used"
26.          }
27.        }
28.      ]
29.    }
30.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

索引时间 vs 搜索时间进行同义词操作

如你所见,在上面的示例中,只创建了一个分析器,它用于索引和搜索。

不鼓励在索引(indexing)步骤中对所有文档应用同义词,因为它有一些主要缺点:

  • 如果不重新索引所有内容,就无法更新同义词列表,这在实践中是非常低效的。
  • 搜索分数会受到影响,因为同义词 token 也会被计算在内。
  • 索引过程变得更加耗时并且索引将变得更大。 对于小数据集来说可以忽略不计,但对于大数据集来说非常重要。

因此,最好在搜索步骤中只应用同义词,这样可以克服所有三个缺点。 为此,我们需要创建一个用于搜索的新分析器。

使用 search_analyzer 并应用搜索时间同义词

在 Kibana 中运行以下命令以创建具有搜索时同义词的新索引:

`

1.  PUT synonym_graph
2.  {
3.    "settings": {
4.      "index": {
5.        "analysis": {
6.          "analyzer": {
7.            "index_analyzer": {
8.              "tokenizer": "standard",
9.              "filter": [
10.                "lowercase"
11.              ]
12.            },
13.            "search_analyzer": {
14.              "tokenizer": "standard",
15.              "filter": [
16.                "lowercase",
17.                "synonym_filter"
18.              ]
19.            }
20.          },
21.          "filter": {
22.            "synonym_filter": {
23.              "type": "synonym_graph",
24.              "synonyms": [
25.                "elk => Elastic Stack",
26.                "elkb => Elastic Stack"
27.              ]
28.            }
29.          }
30.        }
31.      }
32.    },
33.    "mappings": {
34.      "properties": {
35.        "name": {
36.          "type": "text",
37.          "analyzer": "index_analyzer",
38.          "search_analyzer": "search_analyzer"
39.        }
40.      }
41.    }
42.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

关键点

  • 该类型现在更改为 synonym_graph,这是一个更复杂的同义词过滤器,旨在仅用作搜索分析器的一部分。 它可以更恰当地处理多词同义词,推荐用于搜索时分析。 但是,你可以继续使用原来的 synonym 类型,它在这篇文章中的表现是一样的。
  • 同义词过滤器从索引时间分析器中删除并添加到搜索时间分析器中。
  • search_analyzer 是为 name 字段明确指定的。 如果未指定,则相同的分析器 (index_analyzer) 将用于索引和搜索。

分析器应该返回与以前相同的 token。 然而,当你用这些命令为三个文档建立索引并再次执行相同的搜索后,结果会有所不同:


1.  PUT /synonym_graph/_doc/1
2.  {
3.    "name": "elk is very powerful"
4.  }

6.  PUT /synonym_graph/_doc/2
7.  {
8.    "name": "elkb is useful"
9.  }

11.  PUT /synonym_graph/_doc/3
12.  {
13.    "name": "Elastic Stack is so widely used"
14.  }

我们使用如下的命令来进行搜索:


1.  GET /synonym_graph/_search?filter_path=**.hits
2.  {
3.    "query": {
4.      "match": {
5.        "name": "elk"
6.      }
7.    }
8.  }

这一次,只有如下的结果返回。甚至 “elk is very powerful” 这个文档也没有被返回:


1.  {
2.    "hits": {
3.      "hits": [
4.        {
5.          "_index": "synonym_graph",
6.          "_id": "3",
7.          "_score": 2.3589978,
8.          "_source": {
9.            "name": "Elastic Stack is so widely used"
10.          }
11.        }
12.      ]
13.    }
14.  }

原因是同义词过滤器仅在搜索时应用。 搜索查询 elk 被替换为同义词标记 “Elastic Stack”。 然而,索引中的文档没有被同义词过滤器(synonym_filter)过滤,因此 “elk” 只是被标记为 elk 而没有被 Elastic Stack 替换。 类似于 elkb。 结果,只能匹配 “Elastic Stack is so widely used”。

为了使其像前面的示例一样正常工作,我们需要将同义词规则从显式映射更改为等效同义词。 让我们按如下方式更新同义词过滤器:


1.  ......
2.    "filter": {
3.      "synonym_filter": {
4.        "type": "synonym_graph",
5.          "synonyms": [
6.             "elk, elkb, Elastic Stack"
7.          ]
8.      }
9.    }
10.  ......

要更改现有索引的同义词,我们可以重新创建索引并重新索引所有文档,这是愚蠢且低效的。

更好的方法是更新索引的设置。 但是,我们需要在更新设置之前关闭索引,然后重新打开它才能访问它:


1.  POST /synonym_graph/_close

4.  PUT /synonym_graph/_settings
5.  {
6.    "settings": {
7.      "index.analysis.filter.synonym_filter.synonyms": [
8.        "elk, elkb, Elastic Stack"
9.      ]
10.    }
11.  }

13.  POST /synonym_graph/_open

请注意更新索引设置的特殊语法。

运行上述命令后,我们可以通过如下命令的返回值来进行验证:

GET synonym_graph

上面的命令返回:

`

1.  {
2.    "synonym_graph": {
3.      "aliases": {},
4.      "mappings": {
5.        "properties": {
6.          "name": {
7.            "type": "text",
8.            "analyzer": "index_analyzer",
9.            "search_analyzer": "search_analyzer"
10.          }
11.        }
12.      },
13.      "settings": {
14.        "index": {
15.          "routing": {
16.            "allocation": {
17.              "include": {
18.                "_tier_preference": "data_content"
19.              }
20.            }
21.          },
22.          "number_of_shards": "1",
23.          "provided_name": "synonym_graph",
24.          "creation_date": "1673501061514",
25.          "analysis": {
26.            "filter": {
27.              "synonym_filter": {
28.                "type": "synonym_graph",
29.                "synonyms": [
30.                  "elk, elkb, Elastic Stack"
31.                ]
32.              }
33.            },
34.            "analyzer": {
35.              "index_analyzer": {
36.                "filter": [
37.                  "lowercase"
38.                ],
39.                "tokenizer": "standard"
40.              },
41.              "search_analyzer": {
42.                "filter": [
43.                  "lowercase",
44.                  "synonym_filter"
45.                ],
46.                "tokenizer": "standard"
47.              }
48.            }
49.          },
50.          "number_of_replicas": "1",
51.          "uuid": "UCIWtpQMTsCc1TwnvsywHA",
52.          "version": {
53.            "created": "8060099"
54.          }
55.        }
56.      }
57.    }
58.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

让我们使用 _analyzer 端点测试 search_analyzer 并查看生成的 token:


1.  GET /synonym_graph/_analyze
2.  {
3.    "analyzer": "search_analyzer",
4.    "text": "elk"
5.  }

上述命令返回:

它表明 elk 搜索查询被三个同义词的 token 替换和扩展(由 expand 选项控制)。 它还证明,如果在索引时应用等效同义词,则结果索引的大小可以显着增加。

然后当我们再次执行相同的搜索时:


1.  GET /synonym_graph/_search?filter_path=**.hits
2.  {
3.    "query": {
4.      "match": {
5.        "name": "elk"
6.      }
7.    }
8.  }

这次搜索的结果是:

`

1.  {
2.    "hits": {
3.      "hits": [
4.        {
5.          "_index": "synonym_graph",
6.          "_id": "3",
7.          "_score": 1.6949677,
8.          "_source": {
9.            "name": "Elastic Stack is so widely used"
10.          }
11.        },
12.        {
13.          "_index": "synonym_graph",
14.          "_id": "2",
15.          "_score": 1.1220688,
16.          "_source": {
17.            "name": "elkb is useful"
18.          }
19.        },
20.        {
21.          "_index": "synonym_graph",
22.          "_id": "1",
23.          "_score": 1.0126972,
24.          "_source": {
25.            "name": "elk is very powerful"
26.          }
27.        }
28.      ]
29.    }
30.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

我们可以看到三个文档都被搜索出来了。

使用同义词文件

上面我们一直在创建索引时直接指定同义词列表。 但是,当你有大量同义词时,将它们全部添加到索引中会很麻烦。 更好的方法是将它们存储在一个文件中,然后动态地将它们加载到索引中。 使用同义词文件有很多好处,其中包括:

  • 方便维护大量的同义词。
  • 可以被不同的索引使用。
  • 可以在不关闭索引的情况下动态重新加载。

首先,我们需要先将同义词放入一个文件中。 每行都是一个同义词规则,与上面演示的相同。 更多细节可以在官方文档中找到。

我们将创建的同义词文件称为 synonyms.txt,但可以任意命名。 它具有以下内容:


1.  $ pwd
2.  /Users/liuxg/data/docker8
3.  $ ls
4.  docker-compose.yml synonyms.txt
5.  $ cat synonyms.txt 
6.  # This is a comment! The file is named synonyms.txt.
7.  elk,elkb,Elastic Stack

然后我们需要将同义词文件绑定到 Docker 容器中。 更新 docker-compose.yaml 如下:

docker-compose.yml

`

1.  version: "3.9"
2.  services:
3.    elasticsearch:
4.      image: elasticsearch:8.6.0
5.      environment:
6.        - discovery.type=single-node
7.        - ES_JAVA_OPTS=-Xms1g -Xmx1g
8.        - xpack.security.enabled=false
9.      volumes:
10.        - type: volume
11.          source: es_data
12.          target: /usr/share/elasticsearch/data
13.        - type: bind
14.          source: ./synonyms.txt
15.          target: /usr/share/elasticsearch/config/synonyms.txt      
16.      ports:
17.        - target: 9200
18.          published: 9200
19.      networks:
20.        - elastic

22.    kibana:
23.      image: kibana:8.6.0
24.      ports:
25.        - target: 5601
26.          published: 5601
27.      depends_on:
28.        - elasticsearch
29.      networks:
30.        - elastic      

32.  volumes:
33.    es_data:
34.      driver: local

36.  networks:
37.    elastic:
38.      name: elastic
39.      driver: bridge

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

我们可以使用 CTRL+C 来终止之前运行的 docker,然后再次使用如下命令来启动:

docker-compose up

请注意,同义词文件已加载到容器中的 config 文件夹中。你可以进入容器并使用以下两个命令之一检查它:


1.  # User docker
2.  docker exec -it elasticsearch-1  bash

4.  # User docker-compose
5.  docker-compose exec elasticsearch bash

现在我们需要停止并重新启动服务以使更改生效。 请注意,仅重新启动服务将不起作用。


1.  docker-compose stop elasticsearch
2.  docker-compose up -d elasticsearch

1.  $ docker ps
2.  CONTAINER ID   IMAGE                 COMMAND                  CREATED          STATUS          PORTS                              NAMES
3.  3ae4b728dd44   kibana:8.6.0          "/bin/tini -- /usr/l…"   23 seconds ago   Up 21 seconds   0.0.0.0:5601->5601/tcp             docker8-kibana-1
4.  878c82384761   elasticsearch:8.6.0   "/bin/tini -- /usr/l…"   23 seconds ago   Up 22 seconds   0.0.0.0:9200->9200/tcp, 9300/tcp   docker8-elasticsearch-1
5.  $ docker exec -it docker8-elasticsearch-1 bash
6.  elasticsearch@878c82384761:~$ pwd
7.  /usr/share/elasticsearch
8.  elasticsearch@878c82384761:~$ ls
9.  LICENSE.txt  NOTICE.txt  README.asciidoc  bin  config  data  jdk  lib  logs  modules  plugins
10.  elasticsearch@878c82384761:~$ cd config/
11.  elasticsearch@878c82384761:~/config$ ls
12.  elasticsearch-plugins.example.yml  jvm.options             log4j2.properties  synonyms.txt
13.  elasticsearch.keystore             jvm.options.d           role_mapping.yml   users
14.  elasticsearch.yml                  log4j2.file.properties  roles.yml          users_roles

从上面的输出中,我们可以看到 synonyms.txt 已经被成功地加载到容器里了。

然后我们可以使用同义词文件创建一个新索引:

`

1.  PUT /synonym_graph_file
2.  {
3.    "settings": {
4.      "index": {
5.        "analysis": {
6.          "analyzer": {
7.            "index_analyzer": {
8.              "tokenizer": "standard",
9.              "filter": [
10.                "lowercase"
11.              ]
12.            },
13.            "search_analyzer": {
14.              "tokenizer": "standard",
15.              "filter": [
16.                "lowercase",
17.                "synonym_filter"
18.              ]
19.            }
20.          },
21.          "filter": {
22.            "synonym_filter": {
23.              "type": "synonym_graph",
24.              "synonyms_path": "synonyms.txt",
25.              "updateable": true
26.            }
27.          }
28.        }
29.      }
30.    },
31.    "mappings": {
32.      "properties": {
33.        "name": {
34.          "type": "text",
35.          "analyzer": "index_analyzer",
36.          "search_analyzer": "search_analyzer"
37.        }
38.      }
39.    }
40.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

关键点

  • 对于 synonyms_path,它是同义词文件相对于 Elasticsearch 服务器中 config 文件夹的路径。
  • 添加了一个新的 updateable 字段,它指定相应的过滤器是否可更新。 我们很快就会看到如何在不关闭和打开索引的情况下重新加载搜索分析器。

这个新索引 synonym_graph_file 的行为应该与前一个 synonym_graph 的行为相同。

现在让我们在同义词文件中添加更多的同义词,其内容如下:


1.  $ pwd
2.  /Users/liuxg/data/docker8
3.  $ ls
4.  docker-compose.yml synonyms.txt
5.  $ cat synonyms.txt 
6.  # This is a comment! The file is named synonyms.txt.
7.  elk,elkb,Elastic Stack
8.  JS => JavaScript
9.  TS => TypeScript
10.  Py => Python

添加同义词后,我们可以关闭并打开索引使其生效。 然而,由于我们将同义词过滤器标记为可更新,我们可以重新加载搜索分析器以使更改立即生效,而无需关闭索引,因此无需停机。

要重新加载索引的搜索分析器,我们需要调用 _reload_search_analyzers 端点:

POST /synonym_graph_file/_reload_search_analyzers

上面的命令输出为:

`

1.  {
2.    "_shards": {
3.      "total": 2,
4.      "successful": 1,
5.      "failed": 0
6.    },
7.    "reload_details": [
8.      {
9.        "index": "synonym_graph_file",
10.        "reloaded_analyzers": [
11.          "search_analyzer"
12.        ],
13.        "reloaded_node_ids": [
14.          "tZLy82KRTaiCdpsbkEYnuA"
15.        ]
16.      }
17.    ]
18.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

现在,当我们分析 JS 字符串时,我们将看到返回的 javascript token。


1.  GET /synonym_graph_file/_analyze
2.  {
3.    "analyzer": "search_analyzer",
4.    "text": "JS"
5.  }

上面的命令返回:


1.  {
2.    "tokens": [
3.      {
4.        "token": "javascript",
5.        "start_offset": 0,
6.        "end_offset": 2,
7.        "type": "SYNONYM",
8.        "position": 0
9.      }
10.    ]
11.  }

这里应该注意两件重要的事情:

  • 如果同义词过滤器的 updateable 设置为true,那么对应的分析器只能作为 search_analyzer 使用,不能用于索引,即使类型是同义词。
  • updateable 选项只能在同义词文件与 synonyms_path 选项一起使用时使用,而不是在同义词直接通过 synonyms 选项提供时使用。

恭喜你到达这里! 我们已经涵盖了在 Elasticsearch 中使用同义词功能的所有要点。

我们已经分别介绍了如何在索引时间和搜索时间分析步骤中使用同义词。 此外,还介绍了如何直接提供同义词列表,以及如何通过文件提供。 最后但同样重要的是,介绍了关于如何更新现有索引的同义词列表的不同方法。 建议重新加载索引的搜索分析器,因为它不会给服务带来停机时间。

继续阅读 »

原文地址 elasticstack.blog.csdn.net

同义词用于提高搜索质量并扩大匹配范围。 例如,搜索 England 的用户可能希望找到包含 British 或 UK 的文档,尽管这三个词完全不同。

Elasticsearch 中的同义词功能非常强大,如果实施得当,可以使你的搜索引擎更加健壮和强大。 在本文中,我们将通过简单的代码片段介绍在实践中实现同义词功能的要点。 特别是,我们将介绍如何更新现有索引的同义词,这是一个相对高级的话题。

在今天的展示中,我将使用最新的 Elastic Stack 8.6.0,尽管版本不对我们的展示有任何的影响。

准备

我们将使用 Docker 在本地启动一个 Elasticsearch 服务器,并使用 Kibana 来管理索引和运行命令。 如果你以前从未使用过 Elasticsearch 或想快速复习一下,这篇文章可能会对你有所帮助。 如果你在 Docker 中运行 Elasticsearch 时遇到问题,这篇文章很可能会帮助你解决问题。在今天的文章中,我们尝试使用 docker 来部署一个没有安全功能的 Elasticsearch 集群。

准备就绪后,让我们开始探索 Elasticsearch 中的同义词功能的旅程。

我们将在本文中使用的 docker-compose.yaml 文件包含以下内容,稍后我们将向其添加更多功能:

docker-compose.yml

`

1.  version: "3.9"
2.  services:
3.    elasticsearch:
4.      image: elasticsearch:8.6.0
5.      environment:
6.        - discovery.type=single-node
7.        - ES_JAVA_OPTS=-Xms1g -Xmx1g
8.        - xpack.security.enabled=false
9.      volumes:
10.        - type: volume
11.          source: es_data
12.          target: /usr/share/elasticsearch/data
13.      ports:
14.        - target: 9200
15.          published: 9200
16.      networks:
17.        - elastic

19.    kibana:
20.      image: kibana:8.6.0
21.      ports:
22.        - target: 5601
23.          published: 5601
24.      depends_on:
25.        - elasticsearch
26.      networks:
27.        - elastic      

29.  volumes:
30.    es_data:
31.      driver: local

33.  networks:
34.    elastic:
35.      name: elastic
36.      driver: bridge

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

你可以使用以下命令之一启动 Elasticsearch 和 Kibana:

docker-compose up

或者

docker-compose up -d

如果加上 -d 选项的话,Elasticsearch 会以 daemon 的形式来运行。上面是一种最为简单的方式来启动 Elasticsearch 集群及 Kibana。由于它没有设置安全,我们无需输入任何凭证就可以直接进入到 Kibana 了。

使用带有同义词列表的标准同义词 token 过滤器

让我们首先使用带有同义词列表的标准同义词标记过滤器创建一个索引。 在 Kibana 中运行以下命令,我们将在稍后解释详细信息: 

`

1.  PUT synonyms
2.  {
3.    "settings": {
4.      "index": {
5.        "analysis": {
6.          "analyzer": {
7.            "index_analyzer": {
8.              "tokenizer": "standard",
9.              "filter": [
10.                "lowercase",
11.                "synonym_filter"
12.              ]
13.            }
14.          },
15.          "filter": {
16.            "synonym_filter": {
17.              "type": "synonym",
18.              "synonyms": [
19.                "elk => Elastic Stack",
20.                "elkb => Elastic Stack"
21.              ]
22.            }
23.          }
24.        }
25.      }
26.    },
27.    "mappings": {
28.      "properties": {
29.        "name": {
30.          "type": "text",
31.          "analyzer": "index_analyzer"
32.        }
33.      }
34.    }
35.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

这里的要点

  1. 请注意设置键的嵌套级别。 settings => index => analysis => analyzer/filter 都是内置关键字。 但是,index_analyzer 和 synonym_filter 分别是自定义分析器和过滤器的自定义名称。
  2. 我们需要创建一个 type 为 synonym 的自定义过滤器。 synonym 选项明确提供了同义词列表。 这通常应该只用于测试,因为更新同义词列表不方便,我们稍后会看到。
  3. 本文中使用了 Solr 同义词。 对于此示例,使用了显式映射,这意味着 => 左侧的标记将替换为右侧的标记。 稍后我们将使用等同的同义词,这意味着提供的 token 被等同对待。
  4. synonym_filter 添加到名为 index_analyzer 的新自定义分析器的过滤器列表中。 通常过滤器的顺序很重要。 然而,对于同义词过滤器来说,它有点特殊,可能会让我们中的许多人感到惊讶。 在此示例中,即使 synonym_filter 过滤器放在小写过滤器之后,此过滤器返回的标记也会传递给小写过滤器,因此也会变成小写。 因此,你不需要在同义词列表或同义词文件中提供小写 token。
  5. 最后,在文档的映射中,为名称字段指定了自定义分析器。

我们知道在早期的 Elastic 产品中 elk 就是 Elastic Stack 的代名词。之后随着 Beats 的加入,很多开发者也把 elkb 当做 Elastic Stack 的代名词。要测试在索引中创建的分析器,我们可以调用 _analyze 端点:


1.  GET /synonyms/_analyze
2.  {
3.    "analyzer": "index_analyzer",
4.    "text": "elk is powerful"
5.  }

上面命令的输出为:

`

1.  {
2.    "tokens": [
3.      {
4.        "token": "elastic",
5.        "start_offset": 0,
6.        "end_offset": 3,
7.        "type": "SYNONYM",
8.        "position": 0
9.      },
10.      {
11.        "token": "is",
12.        "start_offset": 4,
13.        "end_offset": 6,
14.        "type": "<ALPHANUM>",
15.        "position": 1
16.      },
17.      {
18.        "token": "stack",
19.        "start_offset": 4,
20.        "end_offset": 6,
21.        "type": "SYNONYM",
22.        "position": 1
23.      },
24.      {
25.        "token": "powerful",
26.        "start_offset": 7,
27.        "end_offset": 15,
28.        "type": "<ALPHANUM>",
29.        "position": 2
30.      }
31.    ]
32.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

从上面的输出中,我们可以看到 type 为 SNONYM 的 token 为 elastic 及 stack。让我们向索引中添加一些文档并测试它在搜索中是否正常工作:


1.  PUT /synonyms/_doc/1
2.  {
3.    "name": "elk is very powerful"
4.  }

6.  PUT /synonyms/_doc/2
7.  {
8.    "name": "elkb is useful"
9.  }

11.  PUT /synonyms/_doc/3
12.  {
13.    "name": "Elastic Stack is so widely used"
14.  }

我们可以使用 match 关键字进行简单的搜索:


1.  GET /synonyms/_search?filter_path=**.hits
2.  {
3.    "query": {
4.      "match": {
5.        "name": "elk"
6.      }
7.    }
8.  }

如果没有问题,所有三个文件都应该被搜索到:

`

1.  {
2.    "hits": {
3.      "hits": [
4.        {
5.          "_index": "synonyms",
6.          "_id": "2",
7.          "_score": 0.31931418,
8.          "_source": {
9.            "name": "elkb is useful"
10.          }
11.        },
12.        {
13.          "_index": "synonyms",
14.          "_id": "1",
15.          "_score": 0.29086044,
16.          "_source": {
17.            "name": "elk is very powerful"
18.          }
19.        },
20.        {
21.          "_index": "synonyms",
22.          "_id": "3",
23.          "_score": 0.24686477,
24.          "_source": {
25.            "name": "Elastic Stack is so widely used"
26.          }
27.        }
28.      ]
29.    }
30.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

索引时间 vs 搜索时间进行同义词操作

如你所见,在上面的示例中,只创建了一个分析器,它用于索引和搜索。

不鼓励在索引(indexing)步骤中对所有文档应用同义词,因为它有一些主要缺点:

  • 如果不重新索引所有内容,就无法更新同义词列表,这在实践中是非常低效的。
  • 搜索分数会受到影响,因为同义词 token 也会被计算在内。
  • 索引过程变得更加耗时并且索引将变得更大。 对于小数据集来说可以忽略不计,但对于大数据集来说非常重要。

因此,最好在搜索步骤中只应用同义词,这样可以克服所有三个缺点。 为此,我们需要创建一个用于搜索的新分析器。

使用 search_analyzer 并应用搜索时间同义词

在 Kibana 中运行以下命令以创建具有搜索时同义词的新索引:

`

1.  PUT synonym_graph
2.  {
3.    "settings": {
4.      "index": {
5.        "analysis": {
6.          "analyzer": {
7.            "index_analyzer": {
8.              "tokenizer": "standard",
9.              "filter": [
10.                "lowercase"
11.              ]
12.            },
13.            "search_analyzer": {
14.              "tokenizer": "standard",
15.              "filter": [
16.                "lowercase",
17.                "synonym_filter"
18.              ]
19.            }
20.          },
21.          "filter": {
22.            "synonym_filter": {
23.              "type": "synonym_graph",
24.              "synonyms": [
25.                "elk => Elastic Stack",
26.                "elkb => Elastic Stack"
27.              ]
28.            }
29.          }
30.        }
31.      }
32.    },
33.    "mappings": {
34.      "properties": {
35.        "name": {
36.          "type": "text",
37.          "analyzer": "index_analyzer",
38.          "search_analyzer": "search_analyzer"
39.        }
40.      }
41.    }
42.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

关键点

  • 该类型现在更改为 synonym_graph,这是一个更复杂的同义词过滤器,旨在仅用作搜索分析器的一部分。 它可以更恰当地处理多词同义词,推荐用于搜索时分析。 但是,你可以继续使用原来的 synonym 类型,它在这篇文章中的表现是一样的。
  • 同义词过滤器从索引时间分析器中删除并添加到搜索时间分析器中。
  • search_analyzer 是为 name 字段明确指定的。 如果未指定,则相同的分析器 (index_analyzer) 将用于索引和搜索。

分析器应该返回与以前相同的 token。 然而,当你用这些命令为三个文档建立索引并再次执行相同的搜索后,结果会有所不同:


1.  PUT /synonym_graph/_doc/1
2.  {
3.    "name": "elk is very powerful"
4.  }

6.  PUT /synonym_graph/_doc/2
7.  {
8.    "name": "elkb is useful"
9.  }

11.  PUT /synonym_graph/_doc/3
12.  {
13.    "name": "Elastic Stack is so widely used"
14.  }

我们使用如下的命令来进行搜索:


1.  GET /synonym_graph/_search?filter_path=**.hits
2.  {
3.    "query": {
4.      "match": {
5.        "name": "elk"
6.      }
7.    }
8.  }

这一次,只有如下的结果返回。甚至 “elk is very powerful” 这个文档也没有被返回:


1.  {
2.    "hits": {
3.      "hits": [
4.        {
5.          "_index": "synonym_graph",
6.          "_id": "3",
7.          "_score": 2.3589978,
8.          "_source": {
9.            "name": "Elastic Stack is so widely used"
10.          }
11.        }
12.      ]
13.    }
14.  }

原因是同义词过滤器仅在搜索时应用。 搜索查询 elk 被替换为同义词标记 “Elastic Stack”。 然而,索引中的文档没有被同义词过滤器(synonym_filter)过滤,因此 “elk” 只是被标记为 elk 而没有被 Elastic Stack 替换。 类似于 elkb。 结果,只能匹配 “Elastic Stack is so widely used”。

为了使其像前面的示例一样正常工作,我们需要将同义词规则从显式映射更改为等效同义词。 让我们按如下方式更新同义词过滤器:


1.  ......
2.    "filter": {
3.      "synonym_filter": {
4.        "type": "synonym_graph",
5.          "synonyms": [
6.             "elk, elkb, Elastic Stack"
7.          ]
8.      }
9.    }
10.  ......

要更改现有索引的同义词,我们可以重新创建索引并重新索引所有文档,这是愚蠢且低效的。

更好的方法是更新索引的设置。 但是,我们需要在更新设置之前关闭索引,然后重新打开它才能访问它:


1.  POST /synonym_graph/_close

4.  PUT /synonym_graph/_settings
5.  {
6.    "settings": {
7.      "index.analysis.filter.synonym_filter.synonyms": [
8.        "elk, elkb, Elastic Stack"
9.      ]
10.    }
11.  }

13.  POST /synonym_graph/_open

请注意更新索引设置的特殊语法。

运行上述命令后,我们可以通过如下命令的返回值来进行验证:

GET synonym_graph

上面的命令返回:

`

1.  {
2.    "synonym_graph": {
3.      "aliases": {},
4.      "mappings": {
5.        "properties": {
6.          "name": {
7.            "type": "text",
8.            "analyzer": "index_analyzer",
9.            "search_analyzer": "search_analyzer"
10.          }
11.        }
12.      },
13.      "settings": {
14.        "index": {
15.          "routing": {
16.            "allocation": {
17.              "include": {
18.                "_tier_preference": "data_content"
19.              }
20.            }
21.          },
22.          "number_of_shards": "1",
23.          "provided_name": "synonym_graph",
24.          "creation_date": "1673501061514",
25.          "analysis": {
26.            "filter": {
27.              "synonym_filter": {
28.                "type": "synonym_graph",
29.                "synonyms": [
30.                  "elk, elkb, Elastic Stack"
31.                ]
32.              }
33.            },
34.            "analyzer": {
35.              "index_analyzer": {
36.                "filter": [
37.                  "lowercase"
38.                ],
39.                "tokenizer": "standard"
40.              },
41.              "search_analyzer": {
42.                "filter": [
43.                  "lowercase",
44.                  "synonym_filter"
45.                ],
46.                "tokenizer": "standard"
47.              }
48.            }
49.          },
50.          "number_of_replicas": "1",
51.          "uuid": "UCIWtpQMTsCc1TwnvsywHA",
52.          "version": {
53.            "created": "8060099"
54.          }
55.        }
56.      }
57.    }
58.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

让我们使用 _analyzer 端点测试 search_analyzer 并查看生成的 token:


1.  GET /synonym_graph/_analyze
2.  {
3.    "analyzer": "search_analyzer",
4.    "text": "elk"
5.  }

上述命令返回:

它表明 elk 搜索查询被三个同义词的 token 替换和扩展(由 expand 选项控制)。 它还证明,如果在索引时应用等效同义词,则结果索引的大小可以显着增加。

然后当我们再次执行相同的搜索时:


1.  GET /synonym_graph/_search?filter_path=**.hits
2.  {
3.    "query": {
4.      "match": {
5.        "name": "elk"
6.      }
7.    }
8.  }

这次搜索的结果是:

`

1.  {
2.    "hits": {
3.      "hits": [
4.        {
5.          "_index": "synonym_graph",
6.          "_id": "3",
7.          "_score": 1.6949677,
8.          "_source": {
9.            "name": "Elastic Stack is so widely used"
10.          }
11.        },
12.        {
13.          "_index": "synonym_graph",
14.          "_id": "2",
15.          "_score": 1.1220688,
16.          "_source": {
17.            "name": "elkb is useful"
18.          }
19.        },
20.        {
21.          "_index": "synonym_graph",
22.          "_id": "1",
23.          "_score": 1.0126972,
24.          "_source": {
25.            "name": "elk is very powerful"
26.          }
27.        }
28.      ]
29.    }
30.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

我们可以看到三个文档都被搜索出来了。

使用同义词文件

上面我们一直在创建索引时直接指定同义词列表。 但是,当你有大量同义词时,将它们全部添加到索引中会很麻烦。 更好的方法是将它们存储在一个文件中,然后动态地将它们加载到索引中。 使用同义词文件有很多好处,其中包括:

  • 方便维护大量的同义词。
  • 可以被不同的索引使用。
  • 可以在不关闭索引的情况下动态重新加载。

首先,我们需要先将同义词放入一个文件中。 每行都是一个同义词规则,与上面演示的相同。 更多细节可以在官方文档中找到。

我们将创建的同义词文件称为 synonyms.txt,但可以任意命名。 它具有以下内容:


1.  $ pwd
2.  /Users/liuxg/data/docker8
3.  $ ls
4.  docker-compose.yml synonyms.txt
5.  $ cat synonyms.txt 
6.  # This is a comment! The file is named synonyms.txt.
7.  elk,elkb,Elastic Stack

然后我们需要将同义词文件绑定到 Docker 容器中。 更新 docker-compose.yaml 如下:

docker-compose.yml

`

1.  version: "3.9"
2.  services:
3.    elasticsearch:
4.      image: elasticsearch:8.6.0
5.      environment:
6.        - discovery.type=single-node
7.        - ES_JAVA_OPTS=-Xms1g -Xmx1g
8.        - xpack.security.enabled=false
9.      volumes:
10.        - type: volume
11.          source: es_data
12.          target: /usr/share/elasticsearch/data
13.        - type: bind
14.          source: ./synonyms.txt
15.          target: /usr/share/elasticsearch/config/synonyms.txt      
16.      ports:
17.        - target: 9200
18.          published: 9200
19.      networks:
20.        - elastic

22.    kibana:
23.      image: kibana:8.6.0
24.      ports:
25.        - target: 5601
26.          published: 5601
27.      depends_on:
28.        - elasticsearch
29.      networks:
30.        - elastic      

32.  volumes:
33.    es_data:
34.      driver: local

36.  networks:
37.    elastic:
38.      name: elastic
39.      driver: bridge

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

我们可以使用 CTRL+C 来终止之前运行的 docker,然后再次使用如下命令来启动:

docker-compose up

请注意,同义词文件已加载到容器中的 config 文件夹中。你可以进入容器并使用以下两个命令之一检查它:


1.  # User docker
2.  docker exec -it elasticsearch-1  bash

4.  # User docker-compose
5.  docker-compose exec elasticsearch bash

现在我们需要停止并重新启动服务以使更改生效。 请注意,仅重新启动服务将不起作用。


1.  docker-compose stop elasticsearch
2.  docker-compose up -d elasticsearch

1.  $ docker ps
2.  CONTAINER ID   IMAGE                 COMMAND                  CREATED          STATUS          PORTS                              NAMES
3.  3ae4b728dd44   kibana:8.6.0          "/bin/tini -- /usr/l…"   23 seconds ago   Up 21 seconds   0.0.0.0:5601->5601/tcp             docker8-kibana-1
4.  878c82384761   elasticsearch:8.6.0   "/bin/tini -- /usr/l…"   23 seconds ago   Up 22 seconds   0.0.0.0:9200->9200/tcp, 9300/tcp   docker8-elasticsearch-1
5.  $ docker exec -it docker8-elasticsearch-1 bash
6.  elasticsearch@878c82384761:~$ pwd
7.  /usr/share/elasticsearch
8.  elasticsearch@878c82384761:~$ ls
9.  LICENSE.txt  NOTICE.txt  README.asciidoc  bin  config  data  jdk  lib  logs  modules  plugins
10.  elasticsearch@878c82384761:~$ cd config/
11.  elasticsearch@878c82384761:~/config$ ls
12.  elasticsearch-plugins.example.yml  jvm.options             log4j2.properties  synonyms.txt
13.  elasticsearch.keystore             jvm.options.d           role_mapping.yml   users
14.  elasticsearch.yml                  log4j2.file.properties  roles.yml          users_roles

从上面的输出中,我们可以看到 synonyms.txt 已经被成功地加载到容器里了。

然后我们可以使用同义词文件创建一个新索引:

`

1.  PUT /synonym_graph_file
2.  {
3.    "settings": {
4.      "index": {
5.        "analysis": {
6.          "analyzer": {
7.            "index_analyzer": {
8.              "tokenizer": "standard",
9.              "filter": [
10.                "lowercase"
11.              ]
12.            },
13.            "search_analyzer": {
14.              "tokenizer": "standard",
15.              "filter": [
16.                "lowercase",
17.                "synonym_filter"
18.              ]
19.            }
20.          },
21.          "filter": {
22.            "synonym_filter": {
23.              "type": "synonym_graph",
24.              "synonyms_path": "synonyms.txt",
25.              "updateable": true
26.            }
27.          }
28.        }
29.      }
30.    },
31.    "mappings": {
32.      "properties": {
33.        "name": {
34.          "type": "text",
35.          "analyzer": "index_analyzer",
36.          "search_analyzer": "search_analyzer"
37.        }
38.      }
39.    }
40.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

关键点

  • 对于 synonyms_path,它是同义词文件相对于 Elasticsearch 服务器中 config 文件夹的路径。
  • 添加了一个新的 updateable 字段,它指定相应的过滤器是否可更新。 我们很快就会看到如何在不关闭和打开索引的情况下重新加载搜索分析器。

这个新索引 synonym_graph_file 的行为应该与前一个 synonym_graph 的行为相同。

现在让我们在同义词文件中添加更多的同义词,其内容如下:


1.  $ pwd
2.  /Users/liuxg/data/docker8
3.  $ ls
4.  docker-compose.yml synonyms.txt
5.  $ cat synonyms.txt 
6.  # This is a comment! The file is named synonyms.txt.
7.  elk,elkb,Elastic Stack
8.  JS => JavaScript
9.  TS => TypeScript
10.  Py => Python

添加同义词后,我们可以关闭并打开索引使其生效。 然而,由于我们将同义词过滤器标记为可更新,我们可以重新加载搜索分析器以使更改立即生效,而无需关闭索引,因此无需停机。

要重新加载索引的搜索分析器,我们需要调用 _reload_search_analyzers 端点:

POST /synonym_graph_file/_reload_search_analyzers

上面的命令输出为:

`

1.  {
2.    "_shards": {
3.      "total": 2,
4.      "successful": 1,
5.      "failed": 0
6.    },
7.    "reload_details": [
8.      {
9.        "index": "synonym_graph_file",
10.        "reloaded_analyzers": [
11.          "search_analyzer"
12.        ],
13.        "reloaded_node_ids": [
14.          "tZLy82KRTaiCdpsbkEYnuA"
15.        ]
16.      }
17.    ]
18.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

现在,当我们分析 JS 字符串时,我们将看到返回的 javascript token。


1.  GET /synonym_graph_file/_analyze
2.  {
3.    "analyzer": "search_analyzer",
4.    "text": "JS"
5.  }

上面的命令返回:


1.  {
2.    "tokens": [
3.      {
4.        "token": "javascript",
5.        "start_offset": 0,
6.        "end_offset": 2,
7.        "type": "SYNONYM",
8.        "position": 0
9.      }
10.    ]
11.  }

这里应该注意两件重要的事情:

  • 如果同义词过滤器的 updateable 设置为true,那么对应的分析器只能作为 search_analyzer 使用,不能用于索引,即使类型是同义词。
  • updateable 选项只能在同义词文件与 synonyms_path 选项一起使用时使用,而不是在同义词直接通过 synonyms 选项提供时使用。

恭喜你到达这里! 我们已经涵盖了在 Elasticsearch 中使用同义词功能的所有要点。

我们已经分别介绍了如何在索引时间和搜索时间分析步骤中使用同义词。 此外,还介绍了如何直接提供同义词列表,以及如何通过文件提供。 最后但同样重要的是,介绍了关于如何更新现有索引的同义词列表的不同方法。 建议重新加载索引的搜索分析器,因为它不会给服务带来停机时间。

收起阅读 »