年初加入搜索组到现在快一年过去了，期间有幸经历了团队由小变大、系统从若变强的原始积累过程，回顾下走过来的技术体系，也算是年终总结
搜索支撑的业务线包括商品、店铺、订单、用户等大大小小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系统，提供搜索数据服务、监控报警、配置管理、机器运维、元数据及权限管理的功能模块