• 企业级内部信息统一搜索解决方案


    前段时间在给一家世界500强企业做咨询,课题是企业级门户的搜索策略。

    光看这个课题,大家肯定会联想到谷歌,Bing,百度之类的搜索引擎。对企业搜索有些接触的人,也许会联想到Autonomy(国外知名搜索服务提供商),或是拓尔思(国内知名企业搜索服务商)。

    虽然说采用这些成熟产品不失为是一种快捷有效的实现方法,但是,企业的特有业务形态和长远技术规划将往往促使他们做出更稳妥的决定:比如,从世界的顶级咨询公司购买解决方案,再决定是否采购成熟的技术和服务组件或与本土IT公司合作开发,打造企业自主知识产权的产品。

    为什么这么做?我认为有三个原因:1、地域及环境因素;2-制约与反制约的博弈。3-长远规划需要。

    那么到底该如何为一个企业来做搜索策略的设计呢?

    具体到这个案例,我们首先来看看具体的客户需求(场景):一个数十万员工的企业,分支机构分布在世界各地,需要在企业内部门户上提供面向全体员工的统一搜索服务,搜索的内容包括企业内应用所产生的业务数据以及企业员工相关信息。其次,用户基于预算及长远考虑,并不打算购买成熟的企业搜索产品。

    再来看看数据分析,企业内部每天产生的有效业务数据在300万条记录左右,假设这300万条数据都属于可被搜索的范围。

    从案例的背景,我们可以理解和分析得出:

    1-以企业内部应用为搜索界定范围,以应用产生的业务数据为搜索目标(属于ESI范畴),以企业的所有员工为搜索服务的提供对象。因此,是横跨企业内部多业务域、多应用的核心级别项目。

    2-设计的重点在于数据的获取(创建索引)和隐私的控制(安全搜索)。

    3-需要采用开源的搜索组件和服务,比如基于Solr技术。

    4-索引数据将非常庞大,需要做一些优化策略来解决性能风险。

     

    Ø  首先,做业务的顶层设计

    我们将这种搜索应用称为“企业统一搜索”。企业统一搜索的入口将放置在企业的内部门户portal,这也是因为需要基于portal的一部分有效资源。比如,4A访问控制,搜索结果对应app的sso访问跳转。

    对于搜索的信息分类设计,从搜索结果的展现形式上来看,可以将搜索划分为搜索信息,搜索企业员工,搜索应用,搜索知识,搜索图片,搜索视频等。

    对于搜索的展现设计,要符合流行的google,百度展现要求,即以标题+简介+关键项为展现基础,其中关键项基于业务的不同而所指不同,比如,包括图片缩略,时间,作者,tags,url,icon等。具体由企业统一搜索应用提供不同的展现模版供其它应用调用。

    对于搜索的准确性要求,需要通过搜索权重管理,faccted search,Poka-yoke技术,相关搜索技术等来满足。

    对于数据采集的设计,要求企业统一搜索提供统一的index索引接口,由其它app进行推送。同时,也要考虑索引失效的问题和人工干预的需要。另外,采用爬虫技术解决某些app无法通过接口调用推送数据而提供搜索服务的问题,爬虫技术(Spider)将主动定期爬取目标系统页面有价值的数据。

    对于权限设计是企业搜索和互联网搜索的最大不同,企业内部的业务信息大都是有浏览范围控制的,因此在做搜索的数据访问权限设计时,最大问题是权限的推送和搜索控制。

     

    Ø  接下来,做技术解决方案的探讨

    常见搜索的逻辑如下所示:

                                 

    或者:

    而在企业搜索中,我们需要这样的技术架构:

    在处理逻辑上,我们采用下面的流程:

    从搜索的技术层面考虑,主要解决这么几个问题:

    1-   数据采集

    提供统一的数据index接口,接口内容包括数据类型,来源,URL,主题,正文,标签,摘要,创建人,创建时间,保存期限,可访问角色,可访问用户,可访问组织等。

    提供一个spider程序,定向爬取目标系统页面内容,并自动调用index接口,建立索引。

    提供一个中间数据文本,部分对应系统可以通过导出数据到中间文本方式提供索引数据。

    2-权限控制

    通过接口采集数据的可浏览角色,用户和组织范围,将实际业务中可能出现的场景基本覆盖。

    还提供两种场景,其一,搜索结果中可展示,但点击无法浏览详情,即通过目标应用来控制实际的浏览权限。但此方案将导致部分重要信息出现标题或摘要泄漏情况。其二,通过solr控制搜索结果,将无权限访问的数据直接过滤掉,不出现在搜索结果中。但这种处理方式非常容易出现效率问题。

    因此,我们一般会建议用户建立企业内部信息索引建立规范,比如,允许全员公开的数据推送索引,允许以组织层级公开的数据推送索引,允许以角色公开的数据推送索引,允许以好友圈子公开的数据推送索引;其它类型的数据建议不推送索引,如有必要,可以由应用提供单独的搜索服务调用方式,供企业统一搜索调用,进行统一的UI展现。

    3-规则引擎

    规则引擎主要解决除搜索权重,faccted search,相关搜索,敏感词等之外的业务逻辑规则。比如,关键用户信息的隐藏处理,索引外信息的获取和拼装,索引自修复规则等。

    4-UE设计

    除了前面提到的Poka-yoke技术,faccted技术,相关搜索技术,在搜索展现上还要体现不同信息的汇聚关联性。比如,关联搜索提示,高级搜索,搜索纠错等。

    搜索的体验异常重要,例如,在搜索员工时,在搜索结果中需要将本部门的同事放在首位,其次是本公司的员工,再是关键用户。

    5-性能和命中率设计

    如果一次搜索花费了30秒才出现结果,而且没有满意的搜索内容,那么这种体验将是致命的。

    因此,对于性能的设计要考虑的index的检索效率优化,规则逻辑处理效率优化,UI渲染效率优化等。比如,就用户每天300万条业务数据推送到索引来看,如果不及时有效的做索引数据的清理,将会在很短的时间内让索引库庞大不堪,在不采取分布式的存储策略前,只能定期的做清理来缓解效率的问题。况且,企业内能真正采用分布式存储架构的还真为数不多。

    关于命中率的问题,一般通过调整权重指标,做好日常的受控词表维护往往能很快解决。关于权重指标,这里一般分为业务权重和数据项权重,比如业务权重是按照数据来源app重要程度来划分权重,数据项权重一般是基于数据的业务属性的重要性来划分权重,比如关键词出现在标题中就比出现在正文中的权重要高。

    6-非结构化数据的展现问题

    现在企业的数据中有 80% 属于非结构化信息。这其中包括了Word文档,Excel表格,PDF文件,扫描图片,电子邮件,电话记录、语音留言、纸质文档、照片、网页、视频以及其他形式的内容。由于很多企业缺乏能够理解并有效利用这些内容的技术,使得非常有价值又充满战略意义的资源常常无法发挥其作用。因此,在搜索的展现过程中,要充分的考虑这类非格式化数据的展现,比如,搜索到的是图片,一般需要在搜索结果中直线展现缩略图,点击伸展浏览大图;如果搜索的是一段音频或视频,那么需要在结果展现中能进行快捷播放,而不是仅仅跳转到目标页面。

  • 相关阅读:
    MVC 【Razor 视图引擎】基础操作 --页面跳转,传值,表单提交
    MVC 【ASPX视图引擎】
    js弹出对话框的方法总结
    MVC 基础
    [转]C#中Split用法~
    对话框控件延伸文本框制作
    WinForm LIstView
    WinForm多窗体间操作
    WinForm 控件ComboBox数据绑定
    WinForm布局
  • 原文地址:https://www.cnblogs.com/javawebsoa/p/3106701.html
Copyright © 2020-2023  润新知