搜索技术架构

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

      

         搜索支撑的业务线包括商品、店铺、订单、用户等大大小小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系统，提供搜索数据服务、监控报警、配置管理、机器运维、元数据及权限管理的功能模块