全部产品
开放搜索

产品架构

更新时间:2017-08-03 10:39:26   分享:   

实现原理

OpenSearch基础架构

  • 白色线为实时数据处理流
  • 红色线为全量数据处理流
  • 黑色线为搜索流程

开发者通过控制台和API与系统交互。典型的使用流程是开发者进入控制台,创建应用实例,配置应用字段结构、搜索属性,配置文本处理插件、定制相关性排序规则等。应用实例创建完成后,开发者再通过SDK/API将数据推送至云端(阿里云存储用户可以配置数据自动同步,只需在控制台中授权),数据实时流式进入Import子系统的数据导入服务模块(iStream Service),经过格式解析和数据处理后,存储在结构化数据存储系统中。随后,Dump子系统的数据导出服务(iStream Service)将数据经过一定处理后发送给实时消息队列系统(Swift),搜索系统(HA3)从消息队列中订阅数据,在内存中构建索引并提供搜索服务。这个数据实时流式处理过程(白色箭头)大概十秒左右。

当开发者修改了索引结构,需要对应用中的数据做增量索引重建。为了保证搜索效率,系统也会定期对所有数据做全量重建索引。索引重建流程参见红色箭头,这是一个非实时的流程,依数据大小不同可能需要几分钟到十几分钟,全量索引重建则需要数小时。

数据在云端经过一系列处理和索引构建后,开发者就可以通过API搜索应用实例中的数据。搜索请求首先发送到查询聚合服务Aggregator。如果开发者配置了查询改写处理逻辑(即将上线),Aggregator会将查询请求发送给查询改写服务QP,QP按照开发者配置的处理规则(例如:拼写纠错、同义词或者查询语义改写)改写查询请求,并将改写后的查询回传给Aggregator,Aggregator最终将查询请求发送给搜索系统HA3,HA3根据开发者定制的相关性排序规则对命中的结果文档排序,并最终通过Aggregator将结果返回给开发者。

为了保证不同开发者各个应用数据推送和搜索相互不受影响,资源合理利用。配额管理服务(Quota Server)会对进入系统的数据和搜索请求频率依据开发者的配额(文档总量、QPS)做限流控制。超出配额部分的数据推送将失败,查询请求将随机丢弃。

引擎实现原理

前面多次提到的HA3是阿里自主研发的新一代分布式实时搜索系统,中文名叫问天3,具备自动容灾、动态扩容、秒级实时等能力。下图是HA3系统模块组成图。

其中,Admin是整个系统的大脑,负责节点角色分配、调度决策、FailOver处理、状态监测、动态扩容等。Amonitor是系统的性能状态监控模块,收集和展示整个系统所有节点的性能参数。QRS是查询解析和改写服务,是系统对外的搜索接口。Proxy是搜索代理模块,负责接收QRS的查询请求,并转发给下辖的所有Searcher节点。Searcher节点执行实际的查询匹配计算,将搜索结果汇总后回传给QRS。DeployExpress是分布式链式数据实时分发系统,负责将离线集群构建好的索引数据分发到各个Searcher节点。DeployExpress的最大亮点是将1份数据分发多份拷贝到Searcher节点,其分发时间接近单份拷贝的数据分发时间,而且单节点故障能自动恢复,不影响数据拷贝。在同等硬件条件下,基于1200万数据做单机性能对比测试发现,HA3比ElasticSearch开源系统的QPS高4倍,查询延迟低4倍。

上图是HA3的多集群异构部署图,其中部署了两个异构逻辑集群Cluster1和Cluster2,两者的硬件配置、索引结构、服务能力可以不同。这种部署一般用来实现冷热数据分层查询、异构数据查询等功能。

OpenSearch利用异构逻辑集群优化资源配置,提升系统服务能力和降低机器成本。不同特性的应用实例被分配在不同的逻辑Cluster中。例如,QPS较高,数据量较少的应用实例分配在SSD磁盘的Cluster中,该Cluster列数较少,但行数较多,能承载较大的搜索流量;而一些QPS较低,数据量又较大的应用实例分配在普通磁盘Cluster中,该Cluster行数较少,但列数较多,能承载海量的用户数据。当每个逻辑集群的数据量增大时,系统可以通过增加列(Partition)来扩大系统数据容量;当搜索流量增大时,通过增加行(Replicas)来提升系统服务能力。

本文导读目录
本文导读目录
以上内容是否对您有帮助?