搜索技术架构

        年初加入搜索组到现在快一年过去了，期间有幸经历了团队由小变大、系统从若变强的原始积累过程，回顾下走过来的技术体系，也算是年终总结

      

         搜索支撑的业务线包括商品、店铺、订单、用户等大大小小20多个，双11期间搜索量在2亿/天，实体服务器超过100台。按功能分为分布式实时引擎、dump中心、数据分析和运维平台几大块

    dump中心，

实质是根据实例搜索与展现的需求将数据库中相关字段组装成document，并生成索引替换上线的过程。我们的dump分为全量和增量模式。

       全量模式，依赖hadoop的批处理方式流程如下

 (1)将业务涉及到的db数据表加载到hdfs上，db表的每天快照对应hive上的一个日期分区 

  (2)通过hive sql脚本过滤表中的业务字段，结合多表做join生成基础表，基础表也对应到hdfs上一个文件目录

（3）   运行mapreduce任务，对数据进行加工处理，并最终在dump机上生成索引文件。其中dump机可看作是一个不对外服务的搜索实例，它拥有与线上实例一样的schema和config配置文件。数据的加工可能包括以下几种：

a.     对字段进行重命名

b.     对字段赋缺省值

c.      根据已有字段生成新字段

d.     对字段值做数值转化、归一化处理

e.     调用业务外部依赖接口，获取额外组装信息

（4）   对线上leader的索引数据做替换，并结合增量补全数据

（5）   同步replica到leader的数据更新 整个流程逻辑比较简单，但其中有几个重难点还是值得关注：

a. 流程的自动化和配置化

b.索引文件的分发和管理，特别是在分布式大数量的场景下

c.数据完整性和准确性的检验

增量模式，binlog+canal+mq的方式

采用canal解析db主库binlog，将update/insert的record主键信息存入mq，消费mq拿到主键后查询slave库，组装record生成document并实时写入。这里有个细节需要注意，就是当binlog的解析比数据库自身主从同步快时，可能会导致从slave库查不出更新的记录导致增量丢失，在我们的实际场景中确实发生过

索引替换上线过程较复杂，涉及到增量数据备份（一般从当天凌晨开始）、追补增量数据、堆积mq阻塞写请求替换索引等步骤

 

基于solr的分布式实时引擎

 

分布式上采用了solrcloud，主要有shard的分片和路由、leader选举、容灾恢复等特性，具体请关注我总结的思维导图

http://dl2.iteye.com/upload/attachment/0104/4903/55cffb54-be33-3ec3-b3b4-61158260f6c9.png

 

实时内核上参考了zoie的设计，即两个内存索引core和一个磁盘索引core实现

（1）   在添加索引的过程中，索引是同时写入到disk core和ram0 core（当前可用）的，此时检索disk和ram0后merge就可以实时返回新增的文档

（2）   当ram0写入到达一定阈值后，开始flush数据到disk上，在这个合并过程中会创建ram1 core。新的文档全部添加到ram1上，而ram0是只读的，此时检索文档需要通过ram0、ram1、disk。因为ram0和disk合并中并没有重新打开indexReader，无需对数据去重

（3）   当ram0全部flush到disk上后，重新打开indexReader，并将ram1和ram0进行swap

（4）   文档更新，写入当前ram core并在disk上进行标记删除，合并过程中先真实删除disk上的标记文档，然后在将ram上的更新向disk合并

（5）   分布式去重

 

数据分析

主要是基于埋点日志的数据挖掘，支撑了业务指标计算、商品离线导航、相关性统计排序、链路监控优化等日常工作

 

hesearch平台

是我们的后台MVC系统，提供搜索数据服务、监控报警、配置管理、机器运维、元数据及权限管理的功能模块