搜索平台化总结

传统搜索有什么问题

• 摆脱业务接入时的人肉成本。
  早期只服务于淘宝主搜场景，数据结构及算法模型过于定制化不能扩展。天猫有个需求找过来，投一个人进去；聚划算有个需求也投一个进去。人就这么多，招个新人过来还要培训不能立即上手，怎么办？排期呗。有时候业务方只想就要加个字段而已，一个多月才给人搞定，非常头疼。
• 大促扩容，负载。
  今年老板说要完成什么什么多少亿了，评估一下客单价，流量。。。发现机器要翻翻，那垂直家机器吧。但是数据量暴增，机器磁盘就那么大，需要重新水平切。所以就加班加点，大半夜的起新下老，担心受怕数据会不会丢。所以需要能够在页面点吧点吧就能自动给把机器加上下掉，包括一些基础的运维操作。
• 配置繁琐，后期维护成本高。
  引擎，dump，算法的配置太多了，早期为了业务快速，每个人的配置风格不一样，后面想完全交给业务方自己搞，发现抽不了身，言传身教都不一定能搞懂。到后面每个开发背负了多个业务维护还需要开发新功能，很累。非常需要一个傻瓜化的console，业务只需要说我要什么功能，捆绑一批默认plugin及配置的能力。
• 集群机器消耗太大，浪费资源
  业务方接入时会评估机器数，上线时会分配上去，大促了再加上去，流量小了在下掉。总不能有人一直盯着他吧，需要有这么一个东西能够动态的在物理级别达到资源共享，我设定一些系统参数，自动帮我start kill，节约成本。
• 集群中每天多个定时或者手动散落各地。
  每天每个业务线需要全量动作，落在每个业务线的每个角落，出问题时，无法定位。需要一个统一的调度框架来。
• 高峰期全量导致磁盘IO飙升，影响查询。
• 增量实时性不高，需要提高至秒级别内可见。

为了解决这些问题，所以经过多次大的版本升级，孵化出搜索平台化服务。服务输出能力有富余时，相继再衍生出公有云，私有云场景。

平台化

• 资源管理
  依赖yarn的解决方案，物理机切成多个适合java场景的虚拟机，组成自己的机器池资源，做资源隔离。业务初始化时，根据指标，自动从池子里虚化满足要求的列表，同时依赖flume agent做原始日志及系统资源的信息的收集，统一到日志中心做清洗，计算并且反向作用到集群。
• 任务调度
  依赖hadoop的job-task方案。封装jobclient，对任务有个统一的管理维护，提供任务的执行状态，进度，日志结果追踪。
• 应用视图管理
  从业务-->应用维度切分app，app与配置挂钩。维护M*N的集群视图，需要什么引擎，需要加入什么算法模块及功能，cache需要怎么配置。。。都在这里统一维护。

全量流程

增量流程/实时索引/读position

• Master与slave可以做读写分离，只会写master，防止单点，可以多master。
• 批量写入事务日志，落地持久化，消费加上position，防止机器挂了或重启，能够追随。
• 异步消费增量，往Ram中add，Ram设置阈值刷磁盘索引段。
• 全量磁盘索引通常很大，增量不会影响，只做标记删除，防止IO。
• 增量索引段会形成碎片，查询会分段查，影响性能，需要做合并策略。
• 对外提供MultiReader包含RamReader,IncReader，FullReader。ReLoad操作会重新切换reader。

查询流程