垂直搜索开发：垂直搜索引擎开发全过程[原创]

//http://blog.csdn.net/chengg0769 转载保留此行 

//这只是我随笔涂鸦，我并不是一个完整实践者，只是准备如此施行。勿笑话我。

//070817增加忠告部分；070823增加难度和差异化部分。070824增加多种技术融合

//071121append G part

//071229 append K Part 对开源代码lucene,nutch,以及用java作搜索后台的意见。

 A. 准备阶段

a.1 搜索的发展历史(必读)

a.2 平面搜索的基本原理和垂直搜索的原理，区别，异同之处(蜘蛛+锚点分析+存储+压缩+分词+索引+顺排+倒排+pagerank+查询+分布式存储+任务拆解+伪并行计算+流水作业协调)

a.3 服务器方案(了解为什么可以用廉价pc来组成集群，搜索的瓶颈在哪里(索引和rank计算，高并发查询的返回速度)，分布式冗余存储，价格的低廉，平台的灵活，有许多免费软件可使用或可改造。)

a.4 软件平台(操作系统，开发语言，哪些语言适合开发蜘蛛，哪些语言适合开发效率敏感部分，365*24H如何保证健壮性，不同的语言开发是否会出现矛盾，是完全自开发，还是借助一些开源项目，开源项目是否可商用，支持是否好，参考资料是否多，版本是否升级很多次(完善性)，不要用刚出的开源项目或有漏洞的项目，除非你完全掌握并可再造，否则很困难)

a.5 找出搜索，垂直搜索，全文检索，分词，排序，web抽取，数据库，集群，分布式等文章文献若千篇细读。

a.6 找出正在进行的项目，正在编写垂直搜索的人，看他们在作什么，他们的经验，心得体会。

a.7平面搜索+垂直搜索的评测，特别是与你设计目的类似的已经存在的垂直搜索的评测，并自己评测，找出优点与缺点

a.8 市场分析：流量如何提升，竞争，广告模式，商业模式，如何生存，前期投入资金，投入期，竞争力。。

a.9 用户调研：发出自己的构思，请一线使用者，目标用户评论，反馈意见，抓住你要作好的方面，需要改善的关键点。他们能使用你的产品的绝对理由，找不到答案，不如放弃。

a.10你的方案的难点在哪里，问题在哪里，你如何解决，对每一个你提出的问题，用户提出的问题，如果解答不了，或是哪一关你无法证明你能走通，不如放弃

B.设计阶段

b.1设计你的总体方案，细化方案，细化到每一步该怎么作，从理论验证它的可行性，技术上达到的高度，门槛，别人可以摹仿的难易度。

b.2从具体的垂直层面，用户的具体运用层面，从理论上有突破，只有在理论上有突破，才能超越业以存在的你的同类的水平。比如对手提供黄页，你也提供黄页，一模一样，不如放弃。更快，更集中，更多信息，更方便，更加互动，更加人性化，更简单，更能吸引用户。必须作到这几个，否则不如放弃

b.3先在三五台电脑上试验你的模型，可通过有固定IP的地方挂一台电脑当服务器，或者托管一台电脑。在流量没有起来之前，你最多把它当一个试验品，不要冒然出动，最开始你的模型无法达到同类产品的水平，问题很多，比如蜘蛛当机，数据抓取不到，逻辑有矛盾，或者设计有重大缺陷。测试期间，你最好把在线服务器数量定在一台，不要太多，资金方面你无法承受，也是不必要的。因为你还没有访问者，最多就是几个熟人来测试。这个过程反复改进，也许半年，也许一年，也许两年。从单一的技术层面讲，抛开平面搜索的海量和高并发查询这两个因素，垂直搜索的技术复杂性和处理的步骤的繁杂不会低于平面搜索。因为垂直搜索面对更具体的运用，不是处理单一网页一种形式，是多维和多逻辑的。而且资料会准确到逻辑关系式的相等。

b.4在线服务器增加到3-5台，线下处理增加到20-50台。这个是否必要，除非你有资金，否则你连托管费用和电费都无法支付，更不谈硬件成本了，但对于采集量，更新频率，及时性而言，没有计算能力不行，没有带宽也不行。所谓一分钱难倒英雄汉。就在这里。这部分主要解决多工作单元的协调处理，整个机群如流水线一样有条不紊的工作，彼此配合，有序进行，这个阶段还要解决后台管理问题，对于系统管理，配置等，必须在控制台能监控和处理。还应该考虑任务的管理，没有任务执行时，有些机器需要停机或休眠(省电考虑)，某台机器出现异常如何告警，某些机器出现问题，是否会中断全过程处理，哪些机器是单一路径，哪些是冗余路径。效率，可控，协调，监控，管理是这个阶段的核心。这个过程也是进行原始资料积累的时间，主要是改进。

b.5正式上线测试。希望每天有3000-5000IP访问，可实际承受负载，解决一些真正用户提供的反馈。

b.6一些资料的静态化处理，便于平面搜索来抓取。这个是必要的。baidu不会抓一个纯搜索引擎的。

b.7推广，拉流量，加入一些推广链。目的使得用户迅速增加。软文，宣传，SEO，博客宣传，论坛宣传，都是必要的，因为目前阶段无人知道你的搜索，这是个关键阶段，也是个决定生死的阶段。高昂的费用，修改的费用，都在这个阶段达到一个最危险的阶段，支撑不下去，只有放弃，亏钱大把。死得很难看。

b.8流量稳定后，对用户作详细调查，改进，用户体验的深入改进。

b.9投放一下别家的关键字广告，平面广告等，来赚取一些基本费用，使得网站的巨大开销得以维系。

b.10发展终端目标广告客户。

b.11发展地区代理，最好是已经有全国网络的企业，不要给那些只有钱没有网络的公司去作。他们会要太高的分成，你前期本来没什么收入。

b.12服务器，线下服务器数量增加一个数量级。这时，必须考虑自己在电讯网通的机房附近建机房，才能放置那么多机器，有自己的机房，资料更新才会在一个局网里进行，才会方便管理。如果你的机房离电讯的机房太远，光纤成本太高，而且容易受到光纤切割的影响。

b.13到这一步，资金和技术投入是时候了。如果无法完成，对待你的就是厄运。因为作搜索的成本太高了。技术人员，编辑人员在这时也特别需要。如果这一步无法完成，你是必死无疑的了。很多公司就是作到这一步，无法继续了。就卡在这里上不上下不了。技术，资金，竞争在这时都是危机四伏了。

b.14如果能融资，不管是风险还是民间的资金，我想必须把它切分成几个部分，而不是一次就把它投入进去，因为市场增长得没那么快，你的宣传，流量提升，盈利也是很漫长，很困难的，难度大于你从开发到现在的全部困难。你必须得消除浮躁，细水长流，走一步看一步。垂直搜索还在探索阶段，广告商还在尝试阶段，垂直搜索重要的是活下去并累计客户，累计口碑，不可能走平面搜索那样的直接上市之路。因为你只是平面搜索的万分之一不到的流量，你的层面也不同，需要更多时间去尝试。所以钱会不够用。不要把很少的钱一下子花出去，否则就是马上死亡。

b.15让尽量多的用户认知你的网站，能使用，能回头使用。否则，只有死掉。让更多的心思花在要为用户服务的思路上，而不是要啃用户一口，要啃投资人一口，要啃广告商一口。以平和的心态来面对。或者只是写软文夸夸其谈，称自己是全国第一，全国最大，全国最牛，都没用。如果你的客户能增长，能持续使用，才能活下去。

b.16服务就是垂直搜索，垂直搜索就是服务。作不好这个，死掉。好象我分析得几个产品搜索，既然都搜不到资料，谁还会来用啊，这不是大白天说梦话嘛。

b.17积极探索新的模式和盈利模式。因为目前还没有直接的答案和可拷贝的模板。这些都是未知数。

b.18做好一件事情，技术只占1%不到。“使能----使你的技术，你的构思，你的概念能通过技术实现，服务你的受众，并赚到钱”，这个不是技术问题。而是商业问题。我经常问别人一句话，我说李彦宏能再造一个baidu吗，大家都说能，但为什么自己就不能造一个baidu呢？答案就在这。

b.19埋头编程是徒劳无功的。单机设计思路是错误的。理想化模型是误入歧途的。不从用户需求分析开始并反复进行是灭顶之灾。急功近利是自杀行为。资金是门槛，这个可以得到越来越多的验证。小资金无法支撑垂直搜索，因为垂直搜索不简单，至少没有一部分急公近利的人看得那么简单。

C.忠告

c.1为了写论文研究这个没用。

c.2学院派不用研究这个，搜索要给用户产生价值，节约人力和时间成本，只是呆在实验室没意义。

c.3没有架构能力的人不要研究这个。

c.4认为编码就是开发的全部，不要搞这个。

c.5认为不需要资金就可以作成一个搜索的人不要搞这个。

c.6你的经济能力不能养10个人，并且在不盈利的情况下支撑三年的，不要搞这个。

c.7你认为作这个可以一夜暴富的不要作这个。

c.8认为这个很简单的人不要搞这个。认为这个很复杂的人更不要搞这个。

c.9迷信百度，google的人不要搞这个。跟在别人屁股后面瞎嚷嚷的人不要作这个。

c.10不知道要从用户切身利益出发的人不要搞这个。

c.11不知道改进只知道SEO，软文推广的不要搞这个，搞不起来的。东西好不好请直接问用户。

c.12不会编程的人不要搞这个。这个是起码要求。

c.13没有项目能力和经验的人不要搞这个，这个是一个大项目，而且会历经数千次改进，数年时间改进。

c.14不分析市场，无法面对激烈，残酷竞争的不要作这个。

c.15不是某个行业有5年以上工作背景的人不要作这个。

c.16对电脑，上网，搜索缺乏热诚和不痴迷的人不要搞这个。

c.17对商业没有天分，只知道写代码的不要搞这个。

c.18不上网，不用搜索，不研究搜索的不要搞这个。

c.19没有为人服务的强烈意识的人不要弄这个。七分服务意识，三分经济意识比较恰当。

c.20太没有钱的和钱太多的不要弄这个。

c.21曾经作过，但是失败的人不要作这个。失败不在技术，而在人，没那个综合能力，或缺少核心人物。

c.22自诩专家，评论家不要作这个，实干家从来就是看准就搞，看不准也搞。而评论家总是喜欢作假设，分析，总结。不是空谈就是闷骚，或者马后炮，或者纸上谈兵，兴趣盎然，滔滔不绝于耳。

D.难点

d.1麻雀虽小，五脏俱全，哪怕你要作的是一个居于主题的检索，应该具备的要素都是这些。索引，分词，网页收集，存储，查询这些都是技术。

d.2受众面窄，无法获得很大的流量，虽然目标人群比较集中。但影响力也小，致使VC和广告商关注度也低，难于形成一个生存链条。

d.3口碑效应难于实现。因为垂直搜索或多或少比较专业，专门化。如果100人中，或者1000个人中才有一个使用你的网站，口碑作用是失效的。

d.4很多开发者都是当实验或个人在从事开发，只是作为实验，或者技术储备，虽然大家普遍看好，但我们讲，这种生存需要环境，缺乏环境，难于成型。

d.5专业网站，门户网站，行业网站的站内搜索与想独立运营的垂直搜索存在严重重叠。而行业网站又与行业B2B存在很大的暧昧情节。而作为站内搜索的话，体现自己的资料和体现外部的资料就存在一个矛盾。

E.差异化

e.1不管你是自己开发还是借助开源代码，作出来的是形同一个模板的呆板模型，形成一个搜索或者检索数据库的必要的技术，如蜘蛛，索引，分词，存储等，并不能做到差异化，只能构成一个必要条件。

e.2搜索的功能是提供给人们不需要浏览分类目录就可以按关键字找到准确的资料的途径，而垂直搜索主要居于专门化运用而定义的，但不是说不需要深度和广度。如果面向java运用的主题搜索，只能收集到100篇文章是不行的，只能检索中文文章也是不行的。展现方式，阅读方式，推荐方式，摘要等都是比较考人的方面。

e.3差异化最终的设计得归结到：你的目标人群的特殊性，他们使用的习惯，他们查询的方式，他们需要的资料归类和抽取方式。就是说，好象是一个面向具体的运用，这里面充满索引的概念，更充满逻辑对应，对比的概念。需要以具体人群的特殊方式方法来展现特殊的资料。这就是差异化。这个是独立于编码之外必须进行设计的地方。

e.4时间成本问题：这个是平面搜索的缺陷或者说目前无法做到的事情，就是广度原则下的用户时间成本消耗问题。而就是要垂直搜索很好的解决它。

e.5有用性和可比性是我们必须注意的。网站必须有用，最好的办法就是问你的目标客户。他们说了算，不要自我为中心，凡事由心想是不行的。可比性就是跟别人的网站相比，能提供什么好处。这些东西比较基层，从用户口里去得知比较好。

F.多技术多概念融合

单一的索引技术，或者说居于KeyWord的倒索引技术，只能解决一个查询的广度和速度的问题。我理解的垂直技术应该向用户精准需求更进一步，在垂直层面作广度和深度研究，并联系外部相关性。从文字检索的单一功能向检索+情报+决策分析+市场导向方面进发。目前考虑要融合以下技术：

F.1管理技术

针对具体的运用通常会涉及到具体的行业，必须融合行业和企业管理技术的概念。比如采购在寻找商品，就涉及到比价，而比价的背景是：采购管理，成本控制，供应商链管理等父级需求。

另外一些概念如QOS，ISO，SGS等与具体环境息息相关的管理，技术都在你考量的范围内。

所以我提出垂直要有经验五年。当然这还不够全面，针对问题得作具体分析。平平常常的规律，不去总结，终难发现。比如长尾效应，不说破大家还不当回事。

F.2情报学

这个主要是居于竞争性和前瞻性而考量的。

F.3统计学

这个是居于普遍规律性而考量的。并可由此定量定性证明问题。

F.4 BI分析

这个是居于问题总结和改善而考量的。不过BI概念通常被吹嘘或被扭曲。BI我理解就是PDCA循环中的C->A过程所要提出的，是螺旋上升的推动力。

F.5决策分析

这个是居于战略和战术考量的。BI的数据正好为此用。

F.6商业规则

这个当然没有特别的考量。凡事皆商品化的年代。这个是不得不查的规则。

比如垂直网站的盈利模式，必然决定相应的技术融合。

G.lucene和nutch是一个可以参考的绣花枕头

为什么这么说。以我的感觉，apache这样的组织，它的目的不在于作一个商业运用，而在于未来霸居服务端市场的野心。GPL等形式只不过是另外一种零成本的发布和测试形式，以渗水的方式或者说类似盗版方式在使用者中传播。达到开发和市场占领的野心，并借此削减其它公司退出类似技术的目的。虽然lucene搞了这么多年，但我们没看到一个基于lucene的类似google,baidu这样能容纳上亿网页并被浏览器用户普遍使用的搜索引擎。类似google这样的公司是一直追求实用和商用化改进的，只有这样的商业开发才会适用公司开发。而类似lucene和java这种优雅的，着重结构，着重完美和可拓展性等只是绣花枕头。所以可以下一个结论：lucene和nutch是可以参考的，但勿陷入这样的陷阱中，认为凭一个开源的东西你就可以拥有自己的技术。对技术开发而言，是掌握它的来龙去脉，并能自主发展自有技术。

J.开发者要求：

有人曾问我，他只会asp,适合开发一个垂直搜索吗？我的回答(我自己认为)----不可能。开发搜索引擎需要对这个领域有相当研究的人材，需要经验丰富的架构师和高级编程人员。所以近段时间也抽空看c++的书，主要是抽象的思想在过去自己一点都没有(快速IDE下我们多半在写event函数)，试想连oop都有问题，怎么能搞懂这个lucene和nutch的代码嘛。很遗憾地断言，1000个人当中也可能就一两个人能钻得进去，因为水平臭的人占绝大多数嘛。虽然我只是当学习，但我知道其中有太多自己不懂的技术了，所以还是老老实实地学习吧。所以这半年什么都没作，倒退回到基础的学习了。所以说，学好c++和数据结构是必须的。

K. 对开源代码lucene,nutch,以及用java作搜索后台的意见。

开源是个好东西，不仅让您了解外部接口API,更可在内部派生新的变种类，以处理特殊情节。但之所以作者要开放源代码出来，就是给大家来读懂，并深刻了解其设计内涵，而不是教会谁作简单的调用，否则像win32API一样只需要公布API即可。我想cutting的意思就是要告诉大家搜索是怎么回事情，并且告诉大家看似神秘的搜索技术背后是什么样的实现。据我了解，作者的本意是要普及搜索或全文检索的运用，并扼制大象的垄断行为。也就是是说，告诉你基本原理，如何实现，以及如何架构，如何灌注OOP思想使得支持plugin等，如何整和到自己的项目中，或者开发更强大的搜索功能，这是我理解的作者的意图。而不是有些人理解的拼凑的概念。我感觉非常多的人在搞拿来主义和拼凑。从嘴巴到肛门直通，不求消化吸收。

java一直以简单和雅致著称，但我们说，如果要实现一个工业级的搜索，可能不是java应该干的事。我们需要的，是他的思路和巧妙框架。我们要延伸，要用效率更高的语言比如c/c++来实现关键部件。cutting选择用java实现，其意图是他熟悉java的OOP而且运用得出色，而且包括nutch的实现，但这只是他的sample他要给人渔而非鱼。所以我们不会看到一个工业运用的搜索用java来实现(大搜索),当然垂直搜索例外，因为数量上差了五个数量级。今天在<<开发自己的搜索引擎>>上看到一段低劣的设计代码，而作者似乎还洋洋得意，神乎其神。

//文本预先处理，全角变半角,大概的代码，记得不清楚了。
string repacestring(const string  str_source){
        hashmap mapx = new hashmap();

       mapx.put("。",".");
       ....
       int lenx = str_source.lenght;
       for(int i = 0,i< lenx,i++){
             string charx = str_source.substring(i,i+1)  //这里记得不清楚了,可看原书...
             if (mapx.get(charx)==TRUE){
                   //repalce it
            }
      }
}
具体的代码我记得不是太清楚了。但我认为对简单的字符串遍历替换。引入太多高级封装的函数以及hashmap的东西，使得效率是最大问题。一个char本来使用一个固定的2byte空间可重复的利用，而在java中似乎会new得没有一点谱(作者要处理的是一个225K的文本，那string charx应该也是要执行255000次)。效率是跟代码展开的行数成大致反比的。会c的人很容易写出一个效率最高的方法，能满足google那种海量级的数据处理。优雅和易用的极端就是恶劣。很多书的作者对事物理解有限，倒误导读者是大问题。更有激动的言语称某某NB的人一个月踏平lucene和另外一个开源框架，作了一个什么什么搜索出来。SB的语言想误导SB的读者。大家千万小心。

##单一的一个char,或者wchar,他的内码本身就是一个不重复的散列，我们可以用65535个bits来表示其是否需要作处理，当然用不了这么多,毕竟这样的符号集中在一段之内。用线性关系直接找到他的标志位来进行相应处理，如何对一个字符也要用散列？？<<VC++开发视频会议>>这本书里用到非常多的静态数组，为什么？一个目的，高效率处理要求下，最快的算法就是预处理一些值到线性表里，然后根据索引直接查表。这就是思路。

如何使得数据体积最小？考虑bitset,因为这是计算机最小的按bit存储的方式。另外，还有一些压缩的思想也可以利用，利用到bit,char,拆分char,利用到指针，利用到偏移量，利用到压缩概念，利用到分页，分段，分组,定义变体类型，都会产生很好的效果。此处只是抛砖引砖，不想多说。

标点在作索引时是没有意义的，其实算法上来讲，任何标点符号都等同一个分隔符号，我们可以将其建立在一个外部的表中间(利于配置和添加),而如: (1)是否替换成1,类似的符号到文字的替换倒也有上百个不等，也是建立在一个表中，当然不可能在hashmap中去写死。如此而已。

为什么我们宣讲马克思主义就要预先认定马克思主义绝对正确无误呢？则成教条主义矣。开源的东西本身就需要每一个看到它代码的人对它提出意见和建议，为它注入新鲜血液，而不是把它当教条或神明。