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