做搜索的同学应该都有过这种体验索引建好了、文档导进去了用户搜笔记本就是查不出来因为商品标题里写的是Laptop或者从网页抓来的内容带着HTML标签用户搜手机时倒是一堆被匹配进来了。这种找不到数据的诡异问题十有八九不是查询写错了而是分析器没配对。这是Elasticsearch系列的第9篇我要聊的就是自定义分析器的完整构建思路。先讲清楚分析器在索引和查询之间到底扮演什么角色然后把字符过滤器、分词器、Token过滤器这三件套拆开看最后用一个商品搜索的例子带你从零把它拼出来顺便把生产环境里几个大坑一并交代掉。1. 分析器到底在干什么一次搜索匹配事故的完整复盘1.1 一条文本从写入到被搜到的完整旅程很多刚接触Elasticsearch的人会把分析器当成一个分词工具这个理解方向没问题但不够准确。分析器不只是分词它是一条有固定顺序的文本预处理流水线。一条文档字段值从进入引擎到写进倒排索引会依次经过三个环节字符过滤char_filter、分词tokenizer、Token过滤token filter。默认情况下这三个环节对每条文本都要跑一遍搜索结果靠不靠谱基本就看这套流程设计得合不合理。我把这个过程用后厨备菜来类比字符过滤器就是洗菜去泥把HTML标签、特殊符号这些烂叶子先摘掉分词器是按菜谱决定切成丁还是切成块颗粒度在这里定死Token过滤器是切完之后的精加工该去重去重、该加同义词加同义词、想顺便做前缀扩展也在这里干。搜索能不能命中取决于用户说的话和文档里的话最终能不能在倒排索引里对上。索引写入时字段配置的analyzer会处理文档内容查询时搜索串也会被分析后变成词项再去匹配。这里有个容易忽略的细节match query会走搜索分析器而term query不会走分析器它拿原始词直接去倒排索引里找。所以很多人排查问题时会发现同样的词match能查出来term却查不出来原因就在分析链路上。这也说明理解分析器不只是为了配索引更是为了理解为什么某个查询行为会符合或违背直觉。1.2 默认分析器为什么不够用三种典型翻车现场Elasticsearch内置了standard、simple、whitespace、keyword、pattern、stop等一批现成分析器默认的standard分析器是standard分词器加lowercase过滤器的组合。可惜默认配置只能覆盖最通用的场景遇到真实业务基本不够用。翻车现场一中文按字切分。standard分词器对笔记本电脑的处理结果是一堆单字笔记本电脑。单字搜索能命中但短语匹配、同义词替换全废了而且索引体积被单字白白撑大。这种场景必须引入专门的中文分词组件不能裸用standard。翻车现场二大小写和同义表达。文档里写Laptop用户搜笔记本两边都是合法表达但倒排索引里根本没有能对上号的词项。大小写问题还能靠lowercase兜底同义词问题就只能靠自定义分析器里的同义词过滤器解决。翻车现场三脏数据和符号污染。网页采集过来的标题带着HTML标签、广告后缀、连接符默认分析器会把、div这些当词装进索引搜索结果自然一团糟。这三种情况有个共同特征问题都不是出现在查询阶段而是出现在文档入场之前的分析阶段。等到上线后才发现搜索结果不对再回头改分析器就得重建索引代价非常大。所以自定义分析器这件事最好在建模设计阶段就当成一等公民对待。2. 拆开分析器字符过滤器、分词器、Token过滤器的分工2.1 字符过滤器正式切词前的脏数据清理字符过滤器是所有文本进入分词前的第一道关卡它处理的是整个原始文本不是切分后的词。内置的三种类型足够覆盖大部分场景。html_strip是把HTML标签剥掉只留可见文本。采集类业务强烈建议加一道POST _analyze { char_filter: [html_strip], tokenizer: standard, filter: [lowercase], text: p全新 b笔记本电脑/b 现货/p }这段请求可以在不建索引的情况下直接调试返回结果里能看到全新、笔记本电脑、现货这些干净词项。mapping则用来做等号替换比如把统一成and、把统一成适合处理用户输入习惯和排版符号的差异{ type: mapping, mappings: [ and, ] }pattern_replace用正则做替换适合处理一些格式类噪音比如把连续的空格压成一个、把日期格式统一。需要提醒的是正则表达式在这里的执行成本是线性扫描整条文本字段越长开销越大所以字符过滤器的规则尽量精简能用mapping的别写复杂正则。2.2 分词器决定文本被切成什么形状分词器是分析器里唯一必选且只能选一个的环节。它决定了词项的颗粒度也直接决定了倒排索引的样子。内置分词器我按使用频率排序列个表方便你按需选型分词器行为典型场景standardUnicode规则按标点和空白切分通用文本、混合语言内容keyword整个输入保持一个token精确匹配、代码、ID类字段whitespace只按空白切分简单日志、原始短语保留pattern正则定义切分规则定制化格式文本ngram生成连续字符组合子串匹配、模糊检索edge_ngram生成前缀字符组合搜索建议、边输入边提示path_hierarchy把路径按层级拆开文件路径、多级分类树uax_url_email完整保留URL和邮箱地址社交内容、联系方式检索这里有两个常见误区。一是keyword分词器不是不做处理而是把整条输入当一个token所以Hello World会保持原样搜索hello反而匹配不到适合放在精确匹配的字段上二是ngram和edge_ngram看起来相似实际差别很大ngram会为elastic生成elalasasttic等所有子串edge_ngram只生成连续前缀eelelaelas……做搜索提示只需要edge_ngram就够了用ngram会让索引膨胀好几倍后面讲性能坑时再细说。2.3 Token过滤器顺序错了全盘皆输的后处理分析器里可以配置多个Token过滤器它们是按数组顺序依次执行的。常用的有lowercase做大小写规整、stop删停用词、synonym扩展同义词、stemmer做词干提取、asciifolding把非ASCII字符转成拉丁写法、edge_ngram做前缀衍生、length过滤超长词。过滤器顺序是个隐形的坑。举个最简单的例子同义词词典里如果有大小写不统一的词条比如把Apple映射到苹果那么过滤器顺序必须是先lowercase再synonym否则APPLE在synonym阶段匹配不上后面再lowercase也没用。再比如同义词和词干提取混用时先做词干会让同义词匹配变困难先做同义词又可能让词干提取把扩展出来的词变得面目全非。我自己的经验是先做字符级规整lowercase、asciifolding再做词典级操作stop、synonym最后做衍生类操作ngram、stemmer、shingle。之所以强调顺序是因为分析器问题最难排查的点就在这每个过滤器单独看都是对的组合起来结果就不对而且错误往往在产物词项上已经看不出是哪个环节造成的。3. 商品搜索场景实战从需求拆解到三段配置落地3.1 把产品需求翻译成分析器的组成清单纸上谈兵了半天现在用一个具体的商品搜索场景来组装分析器。假设我在维护一个电商项目的商品索引商品名是混合中英文的文本业务方提了一串搜索需求用户搜笔记本要能召回标题叫Laptop的商品标题里偶尔带着HTML标签和符号大小写不敏感前端搜索框需要在用户输入前缀时实时出建议。这些需求翻译成分析器的组成清单一共有五项洗掉HTML标签和符号噪音对应char_filter大小写统一对应lowercase过滤器笔记本与Laptop这类同义表达互通对应synonym过滤器输入前缀时能命中标题开头对应edge_ngram过滤器精确的商品编码不能拆碎单独用keyword类型承载。这里有个关键设计决定前缀补全只需要在索引侧做搜索侧不做edge_ngram。如果查询词也被切成一堆前缀比如用户输入gaming索引里匹配到的会是所有以g开头的商品词项精确度会被稀释。索引侧扩展、搜索侧收敛这是搜索提示场景的标准做法。3.2 完整配置索引级settings一把梭自定义分析器定义在索引的settings里通过analysis字段组织。下面是完整配置PUT /product_search { settings: { analysis: { char_filter: { strip_html: { type: html_strip }, clean_symbol: { type: mapping, mappings: [ and, ] } }, tokenizer: { mixed_tokenizer: { type: standard } }, filter: { lowercase_all: { type: lowercase }, product_synonym: { type: synonym, synonyms_path: analysis/synonym.txt, updateable: true }, prefix_ngram: { type: edge_ngram, min_gram: 1, max_gram: 15 } }, analyzer: { product_index: { type: custom, char_filter: [strip_html, clean_symbol], tokenizer: mixed_tokenizer, filter: [lowercase_all, product_synonym, prefix_ngram] }, product_search: { type: custom, char_filter: [strip_html, clean_symbol], tokenizer: mixed_tokenizer, filter: [lowercase_all, product_synonym] } } } } }同义词文件synonym.txt放在Elasticsearch配置目录下的analysis路径里内容格式是每行一条规则笔记本电脑, 笔记本, laptop 笔记本 手机, 智能机, 移动电话 手机等号右边的词是最终落库形态等号左边的词都会映射过去。实际业务里注意别把规则写成双向扩展比如笔记本, laptop这种写法表示两边互相扩展会让倒排索引里同时出现两种词的词项相同含义的词被拆散了相关性计算会受影响。3.3 挂到字段上索引分析器与搜索分析器为什么要分开分析器配置好之后还要在mapping里把它挂到具体字段上{ mappings: { properties: { name: { type: text, analyzer: product_index, search_analyzer: product_search }, sku: { type: keyword } } } }这里分出了索引分析器和搜索分析器两个角色是实现前缀补全同时不损害查询精度的关键。索引侧用product_index把Gaming扩展成g、ga、gam、gami、gaming搜索侧用product_search把查询词gam原样分析再去倒排索引里匹配由索引侧产生的gam这个前缀词项两边就能对上。sku字段用keyword类型而不是走分析器是为了保证GAM-512-BLK这串编码不被拆成gam、512、blk之类的碎片。商品编码、订单号这类字段如果误配了text分词之后想精确查询就只能靠term query碰运气了。4. 上线前的验收用Analyze API把分词结果验明白4.1 写配置前先用免索引调试确认思路构建自定义分析器期间我习惯先不建任何索引直接用_analyze接口反复调组件组合把思路验证清楚了再写正式配置。比如验证同义词加前缀ngram的组合顺序是否合理可以这样调试POST _analyze { tokenizer: standard, filter: [ lowercase, { type: synonym, synonyms: [ laptop, 笔记本 笔记本 ] }, { type: edge_ngram, min_gram: 2, max_gram: 10 } ], text: Laptop Gaming }返回结果里能看到笔记、笔记、笔记本这类前缀词项说明synonym先把laptop映射成了笔记本edge_ngram再基于这个词做前缀衍生链路是通的。如果输出的前缀还是la、lap这种英文碎片那就说明同义词没生效得回去检查词典格式和过滤器顺序。在线调试的好处是零成本试错不用建索引、不用导数据改一步看一步比建完索引再去分析要高效得多。4.2 建索引后用自定义分析器做整链路验证正式配置落地后再用自定义分析器做整链路验证。此时_analyze请求要指定索引名POST /product_search/_analyze { analyzer: product_index, text: Gaming bLaptop/b Smartphone 512GB }输出里能看到清洗和衍生过程都生效了HTML标签没了被替换成了andgaming被拆出了一串前缀512gb整体保留。把同样的文本用product_search分析器再跑一遍结果里没有前缀衍生只有规整后的完整词项。我把这两种结果的差异整理成对照表方便直观理解两端行为输入文本product_index分析器输出节选product_search分析器输出Gamingg, ga, gam, gami, gaminggamingLaptopl, la, lap, lapt, laptop, 笔记本laptop, 笔记本512GB5, 51, 512, 512g, 512gb512gb这张表就是分析器设计的最终验收物。如果索引侧和搜索侧的词项集合对不上比如搜索侧生成了索引侧没有的形态那某些查询就注定搜不到。4.3 数据入库后的端到端搜索用例分析器验证通过只是第一步还得灌几条真实文档验证搜索行为。先写入两件商品POST /product_search/_doc/1 { name: Gaming Laptop Smartphone 512GB, sku: GAM-512-BLK } POST /product_search/_doc/2 { name: 办公笔记本电脑 16英寸, sku: NOTE-16-SLV }然后分别验证三个核心场景前缀搜索输入gam应命中文档1同义词搜索笔记本应同时命中文档1通过laptop映射和文档2大小写混输GAMING LAPTOP应命中文档1。我在实际项目里习惯把这三类用例写成一个验收清单每次改分析器后先跑一遍再切流量能省很多线上事故。要注意match query默认的逻辑是分词后任意词项命中即召回所以分析器出来的词项质量直接决定召回质量。如果倒排索引里混入了div、p这类HTML标签词项用户随手搜个大写字母都可能被奇怪的东西召回这种问题在分析结果验收时就能一眼看穿。5. 生产环境绕不开的五个坑5.1 索引/搜索分析器不对称前缀搜索看着能用实则漏数据索引侧做了edge_ngram扩展、搜索侧忘记收敛是最常见的前缀搜索事故。表现是用户输入完整词能搜到输入前缀反而召回一堆不相关结果或者反过来完全搜不到。正确做法是索引搜索分离但很多人会图省事只配置一个analyzer两边共用。如果这个共用分析器带edge_ngram查询端gam会被扩展成g、ga、gam然后三个词项都参与匹配文档里任何以g开头的内容都会掺进来相关度排序直接崩掉。排查这类问题用_analyze分别跑索引侧和搜索侧对比输出词项集合就能定位。5.2 停用词别乱加中文场景尤其要克制很多团队建分析器时喜欢顺手把stop过滤器加上把的、了、是这类高频词过滤掉。这个操作在英文场景相对安全中文场景很容易引起反效果。的在我的世界里确实是噪音但在的士目的地这些词里它是语义的一部分。更麻烦的是停用词一旦被过滤phrase查询的短语结构就断了笔记本电脑如果被去掉笔和脑短语匹配会直接失配。我现在的做法是默认不加停用词除非有明显的高频噪音词影响搜索结果排序。索引膨胀的问题可以通过后面说到的其他手段缓解没必要靠停用词硬扛。5.3 同义词更新热加载只解决一半问题同义词词典不是上线后就能一劳永逸的。业务方今天加一个品牌别名明天换个营销叫法词典要持续维护。使用synonyms_path指向外部文件并配置updateable为true搜索侧可以在不重启集群的情况下热加载新词条触发重新加载用这个接口POST /product_search/_reload_search_analyzers但热加载只对搜索分析器生效。索引分析器侧的旧文档已经按旧词典生成了词项新词条不会追溯生效。也就是说同义词更新后新文档能按新词条索引但存量文档要想用新词条召回必须重建索引。这个一半生效的状态非常容易让人误判线上问题我在项目里专门在变更文档里写了一条提醒改同义词词典前先确认是否影响存量数据召回。5.4 ngram不是免费午餐索引膨胀和相关性稀释前缀补全的代价比大多数人想象中高。算一笔账一个10个字符的英文词edge_ngram设min_gram1、max_gram10会产生10个前缀词项如果换成ngram同样长度会产生55个子串词项。一个商品标题里十几个词叠加下来倒排索引的词项数可能多出好几倍。膨胀之外还有两个隐性成本。一是匹配噪声短前缀如g几乎能匹配所有g开头的词搜索结果会被无关内容淹没二是相关性稀释一个词被拆成多个词项后文档匹配的分数要分摊到多个词项上本来精确匹配的文档反而排不到前面。缓解方案有三个把edge_ngram限制在name这类短文本字段不要全字段铺开max_gram设到15-20就够覆盖绝大多数真实输入不用无限放大如果只是做搜索框联想可以优先考虑开箱即用的search_as_you_type字段类型它内部就是一套设计好的前缀分析方案比自己手搓更省心。5.5 修改分析器的正确姿态重建索引三步走最后一个坑也是改动成本最高的字段的analyzer一经创建就不能原地修改直接PUT mapping会收到报错。想改分析器只能建新索引、导数据、切换别名三步走。第一步用新分析器配置创建product_search_v2索引第二步用reindex接口把旧索引数据搬过去POST _reindex { source: { index: product_search }, dest: { index: product_search_v2 } }第三步用别名切换流量让业务方无感切换POST /_aliases { actions: [ {remove: {index: product_search, alias: product_search_alias}}, {add: {index: product_search_v2, alias: product_search_alias}} ] }切换前记得对比新旧索引的文档数和主要查询的召回结果我经历过一次reindex后文档数对得上、但某个聚合结果差了十万八千里的情况最后发现是nested字段的映射没同步过去。所以重建索引不是把mapping复制一遍就完事建议把分析器链路、字段类型、嵌套结构一起做diff。最后分享一个我自己的习惯分析器本质上是搜索业务需求的一部分不是纯技术配置。凡是新建索引我都会先写一份分词验收用例把分析器对核心查询的影响跑明白然后存档成回归测试。词表和同义词词典都是需要持续维护的资产别指望一次性配好就再也不动。这样后面每次改需求至少不用从头排查搜索行为为什么变了。