有赞搜索中台的探索与实践

见贤思齐

、、点击关注“有赞coder”获取更多技术干货哦～作者：王爷团队：搜索中台概述有赞搜索中台作为有赞企业级搜索能力复用平台，在解决各个业务域搜索问题时是如何探索与实践的，这个过程中有哪些心得，本文与大家一起分享探讨下。一、问题域跟绝大多数烟囱式架构面临的问题是相似的，业务自建搜索，独立选型往往会遇到以下问题：技术选型单一或跟风，比如公司有业务用 ES 做搜索，那我也用，而业务对实时性的要求，准确性的要求都是不一样的。一致性保障困难，多数据源触发，并发场景下各自尝试的一致性保证方案，参差不齐，有的设计很重。数据孤岛，领域意识加强后会使得系统间的业务串联变的困难，一个需求支持起来业务双方都找不到发力点。需求支持起来耗时久，且做了各种方案妥协。可扩展性预留问题，比如数据量级，到达多少需要拆分，按什么维度拆分，拆分后代码还要改不，每来个搜索需求是否都需要 DDL 一下。还有很多，不赘述。搜索中台=企业级 搜索能力 复用平台再看下搜索中台的定义，面对这些问题域，围绕着搜索能力、可复用平台、企业级几个关键词，将中台抽象成了两层。围绕着这张图展开，它不是标准意义上的业务架构图，更像是做这个事情的思维架构图，所以里面有很多边界没有界定的特别清晰，只要是有助于搭建这两层的，搜索都会主动参与建设，同时也会邀请业务方同学一起加入共建。二、探索篇2.1 折叠效应打造折叠效应这个词是从罗胖精选中听到的认知折叠这个概念引用过来的，受益匪浅。认知折叠是将巨大的复杂性折叠成简单的解决方案。讲的是在二战时期，午餐肉的发明为美国最终取得胜利奠定了坚实的基础。这是因为靠着午餐肉，美国大兵每日可摄取4300卡热量，而在德国、日本军队中，这一数值分别为3000卡和2000卡。同时午餐肉方便士兵携带，不易过期腐烂，不需要生火做饭，暴露军队位置。相当于把整个战区复杂关键的战士口粮问题折叠成了一盒小小的午餐肉罐头。折叠效应无处不在，我们敲击的键盘，跑的代码，开的汽车，都是无数前辈为我们折叠好的，于是我们找到了搜索中台的方向。将搜索完整链路的复杂性折叠成一个简单完整的搜索产品，让业务方直击搜索需求本身，无需费心搜索实现。搜索的复杂度可以抽象为索引管理，索引写，索引读三个方面，我们简单展开下。2.2 索引管理索引设计有必要将索引设计作为搜索的关键环节，磨刀不误砍柴工，一个好的设计，会事半功倍的效果。如果手里只有一把锤子，那么看什么都像钉子。索引选型设计 MYSQL HBASE KV ES TIDBMYSQL 实时性要求高 联合索引可以 cover 的场景HBASE 正排查询，大批量in查询KV 统计接口，实时性要求不那么高的，优先从 KV 中取ES 模糊搜索，多条件查询进 ESTIDB 联合索引查询，海量数据归档自动拆分进 TIDB其他索引存储选型索引拆分设计增量存量是多少，是否需要拆索引？按什么维度拆，按时间或者 id ？拆分了之后还有数据热点倾斜要如何处理？索引可扩展性设计每次来需求都需要索引 DDL 刷数据支持么？用户自定义搜索需求可以支持么？2.3 索引写配置化同步能力围绕配置化同步能力将整个同步抽象成input-filter-output 三步：input 索引数据源层 索引数据来自哪里，一般都是消息 可以是 binlog 消息，也可以是二次加工的业务消息。filter 索引数据加工层，可以联查业务表，调用业务 api 构建索引数据。output 索引数据输出层，比如是用的ES MONGODB MYSQL HBASE 等存储，配置输出即可。增量写这里简单提下同步的扩展点设计，与业务解耦，业务同学不需要关心同步细节，搜索中台又可以不涉及业务太深，通过扩展点方式来解耦。离线写离线写这块主要有一点就是注意版本覆盖问题，避免版本乱序。初始数据刷入一次场景，这种离线选择 create 操作即可，如果增量有数据则被过滤掉。例行刷数据指标场景，走批量更新版本加1，如果有离线覆盖增量风险，可以将增量版本步长设置1000或者更大即可，看业务需求。?一致性保证一致性保证是同步的关键，做到柔性最终一致。2.4 索引读配置化路由索引为什么需要配置化路由？如果手里只有一把锤子，那么看什么都像钉子。再细品下这句话，搜索绝不只可能是 MYSQL 或者 ES ，之前跟业务方聊也知道很多场景可能不适合 MYSQL 或者 ES ，不过为了代码的整洁性，不希望写一堆 if-else ，再有就是对这些琳琅满目的存储的特性很难全面掌握，有明确的区分该用哪个。于是我们搭建了LOS(League Of Search 搜索联盟)层，来配置化收拢路由策略。通用DSL语言这个不用赘述，由于不同存储的 sql 语法是不同的，如果让业务前置感知就侵入太大了，而且同一存储的不同版本有时候变动也较大，业务方兼容不实际。搜索流程编排不同业务对搜索流程的诉求是不一样的，举个例子普通的查询基本就是一次粗排就可以了，有的就需要改写加精排，有的需要组装详情返回，有的需要精排后直接返回，就需要用到流程引擎来编排。2.5 通用监控能力哪一种搜索场景是业务方的top场景，产品需求也可以通过这个指标来衡量对应的价值，优化也可以针对对应的场景来有的放矢的去执行，让数据赋能业务。三、实践篇3.1 协同效应飞轮打造协同效应这个词是曾鸣教授在全球物流峰会上提出的概念。很有共鸣。网络协同是一种合作的机制，它产生的就是协同网络，而协同网络创造的价值，就是协同效应。结合罗胖跨年演讲中介绍的信用飞轮，这里把这两个概念合一，更有助于描述搜索中台目前的落地实践策略。3.2 领域解耦营销商品搜索连通一个比较典型的例子，优惠券凑单按价格、销量、好评排序，营销团队不希望耦合商品域数据，商品团队更不希望耦合营销域数据，所以一个折中的技术方案是营销保存了活动与商品的对应关系，优惠券可用商品先查一次营销，拿到大批量goodsId后再去商品里做相关排序。而这个商品和营销都比较纠结的事情，由搜索中台来做这个桥梁协同，大家都还是专注在自己域的数据中，通过消息解耦，由中台通过配置化同步再同步过程中将数据连接构建 ic+ump 索引，缩短搜索链路，提升搜索体验。通用跨域连接搜索方案共享业务协同飞轮一旦转起来，那么对上游业务的赋能会更加迅速。比如CPS商品搜索，场景主播选品，进行分佣商品搜索，按分佣金额大于某一值的查询。通过在同步过程中完成数据互联，业务方无感知实现数据互联。3.3 业务滋养中台搜索中台设计之初，想到的是些通用基础能力，上文已经介绍，当赋能业务方时候发现还是会遇到各种各样始料未及的问题，通过解决这些通用问题的过程中，让中台又沉淀了不少通用能力，更好的赋能业务方，下面简单介绍下索引管理的三板斧。索引重建产品化在赋能业务阶段，发现很多索引的分片设置少了，或者是单索引大了需要拆分，再有就是需要迁移集群，都会涉及到索引重建，这个普世需求，而索引数据重建，耗时又风险大，于是发起了索引重建产品化项目，目前有赞搜索中台可以做到百万级别索引秒级重建，千万级索引分钟级重建，亿级索引小时级重建，百亿级索引半天内重建完，且数据一致性得到最终保证，极大的提升了业务迭代及集群索引管理速度，具体设计会在后面搜索中台系列技术博文中会详细介绍。为了致敬认知折叠里提到的午餐肉案例，我们把这个索引快速重建项目命名为 spam (午餐肉)。索引无感知重建在赋能业务索引重建过程中发现业务方的同步配置有自建代码实现的，有通过配置化实现的，多种场景，配置化同步的还好，只要复制下同步任务，写到重建新索引中，增量数据同步就可以完成了，但是对于自建同步的业务来说，这个改造的侵入成本就很大，很多散落的代码同时写一个索引中，会有大量的代码复制成本，所以中台就在想能否可以在不侵入业务代码中，就可以做到索引重建。念念不忘 必有回响。搜索中台通过监听自建索引双机房同步的消息中，做了一层配置化路由双写，来做到索引无感知重建。vip索引配置化迁移有了上面两板斧，一般业务索引的常见问题都已经解了，不过发现仍然有热点商家问题导致整个集群不稳，于是在索引无感知重建基础上加了层vip路由，在活动期间，将 vip 商家的流量路由到活动集群中，活动结束后流量可以再配置化迁移回来，极大的提升了系统的稳定性。3.4 中台赋能业务当业务协同飞轮转起来后，搜索中台收集到了更多业务场景的痛点，比如交易订单从单店上升到总店 MU 管理订单搜索要怎么支持，商品搜索也有类似需求，营销搜索也有总店设定优惠券，然后下发到各个门店使用中，都是一种裂变搜索的场景。再比如数据归档搜索，当数据量级大到一定程度，势必要进行归档，归档方案的选型，随着各个业务量级和对归档数据搜索的诉求，痛点，集成后，中台产出通用解决方案，做到无感知数据归档，搜索集成，配置化路由到对应索引中。心得这里简单谈几点心得，能够参与到有赞搜索中台的搭建从无到有是蛮幸运的，过程中有很多兄弟团队的支持，使得整个中台的初步落地还算顺利，回顾这期间有些关键节点感悟。中台不是某一门技术，更像是一种组织架构和思维架构，需要联动，需要协同。关键抓手牢牢抓住，一口吃不了一个胖子，能解决大部分能力复用，服务好核心业务方就很不错了不过度设计，贴着业务需求做能力搭建，方便快速落地。展望搜索中台刚刚成立不到一年，很多场景和设定还相对初级，对业务方的赋能还有很大的提升空间，诚邀搜索专家同学加入一起共建有赞搜索中台大业。简历直通车 wangye@youzan.com。总结本文简单回顾了下有赞搜索中台在赋能业务搜索过程中的探索与实践，业务场景可能不同，不过这套折叠+协同的思维框架模型是相似的，这里希望引用下《企业IT架构转型之道-阿里中台战略思想与架构实战》钟华老师的话作为结语，受益匪浅。我们从小学开始学习很多基础知识，更多的是知识点的掌握；随着我们掌握知识点的增多，我们开始有意识地将一些知识点组合在一起，解决一些复杂的问题，关联这些知识点的过程实际上是将这些相关的知识点串成了知识线；随着在知识领域的继续积累，越来越多知识线的汇聚，我们有机会更全面地了解到这一知识领域（知识面），从而构建了对这一领域自身的知识体系，而这时的你相信已经成为这个领域的专家。扩展阅读有赞订单管理的三生三世与十面埋伏有赞订单搜索AKF架构演进之路有赞订单导出的配置化实践有赞亿级订单同步的探索与实践有赞数据中台建设实践有赞零售财务中台架构设计与实践有赞业务对账平台的探索与实践Vol.292