TIS我是谁

今天非常高兴地向大家宣布一个消息,TIS2.0经过一年多时间的代码开发,终于将开发分支代码合并到了 主干上分支上

想通过这篇博客向大家简要地介绍一下TIS的前世今生,如果可以对各位日常工作中构建企业搜索应用有所帮助,那真是不胜荣幸。

前传

我们最早开始接触搜索技术是2010年,还是在阿里淘宝事业部工作的时候。那时,数据还没有像今天这样呈现爆炸式增长,行业中只有少数几家大型互联网平台才会用到搜索引擎技术, 而搜索引擎技术在当时也没有形成标准,基本都是头部几家寡头技术公司如谷歌、雅虎,内部的自研项目,而各家采用不相同的算法数据结构来实现,对于外人多多少少带有一些保密且神秘的色彩。

就算是当时的阿里巴巴也没有一套成熟的搜索技术来应对日益复杂多样且高并发的数据搜索需求。之后阿里巴巴全资收购了雅虎中国100%的股权,业务上倒是没有进一步发展, 反倒是获得了一整套成熟的搜索引擎框架,对阿里来说如获至宝,这套搜索框架被命名为isearch,被应用于集团各个事业部门,搜索的体验也有了长足的进步。

随着isearch在阿里内部逐步推广落地,发现一个问题,就是isearch这整一套架构比较重,例如在天猫事业部场景中需要运行起来,需要构建Suggest,Configsrv,CM,QP,Forest,UPS以及isearch集群等组件才能 组建一套完整可用的搜索应用。每个组件都有一个独立的团队负责技术维护,开发一个新的功能需求需要跨团队协作才能完成上线,可想而知这不是小团队可以使用的。而阿里内部比较鼓励创新,大量新的业务如雨后春笋地冒了出来, 团队成员技术偏业务层,业务推进需要短平快,这些新的业务团队亟需底层敏捷的技术中台支持,例如,搜索技术就是其中之一。渐渐地,上层业务团队快速发展、需要频繁试错与底层中间件团队不够敏捷的技术架构, 功能开发周期长形成了明显的矛盾。

诞生

搜索技术团队成为最早吃螃蟹的团队。当时找了几个志同道合的小伙伴,组建了一支四人虚拟队伍专注于开源搜索技术,服务对象是刚创建的业务团队,亟需搜索技术但是又不能得到主搜团队支持。 2010年时Lucene已经是3.0版本了,依托于社区协作,功能点已经相对比较完整,性能也日趋强大。当时我们选择了Apache Lucene的孪生兄弟Solr作为基础进行了二次开发,并且针对可用性,及Solr底层性能吞吐方面 开发了不少改造基本能够满足本事业部内部的业务团队需要。之后我们团队还把搜索技术输出到集团其他事业部,例如小微,蚂蚁,阿里云等。

为什么是选择Solr?

为啥选择Solr?其实这个问题一点也不纠结。将时间推回到2010年,Solr是业界最成熟的企业级搜索产品,且是Lucene的孪生项目(它俩就是在一个项目中的两个子目录), 我至今也没有明白明明是两个项目为却放在一个工程中lucene-solr,好处是每次Lucene第一时间发布的new features都能第一时间在Solr中尝鲜, 例如:LUCENE-6825 在Lucene中加入了KDTree数据结构,能够优化之前使用空间区间搜索的场景,几乎在同一个发布版本中Solr已经能用到利用这一 数据结构的PPoint字段类型来替换之前Solr TrieTree来实现的区间查询功能,从而大大提高了查询效率。

那时Elastic Search虽然已经面世,但功能还远不成熟,所以压根没有在考虑范范围之内。

选择Solr还有一个好处是它是Apache下的一个纯开源项目,不会带有任何商业目的,如果在使用中碰到任何问题可以求助mailList,可以迅速得到来自社区专业解答,这是我们喜欢的特质。

Solr落寞了吗?

时间拉回到2020年,这么多年过去了,现在谈及搜索引擎技术就必提Elastic Search,俨然成为行业标准。下图是百度指数 中ES 和Solr的搜索对比图,很明显Solr处于劣势:

Solr真的就日落西山了吗?答案是否定的,无可否认,ES(Elastic Search)在商业上是成功的,他找到了一个使用搜索引擎非常好的切入点, 那就是利用搜索引擎来实现运维数据的可视化分析,因为运维数据是天然是时序化的,时序化的数据只有添加没有更新,这个特性对搜索引擎来说太友好了,因为这搜索引擎处理更新的数据 是一件非常操蛋的事儿,搜索引擎内部对数据的操作只支持添加删除两种数据操作,一旦有更新操作,会形成大量碎片文件后续会产生一系列问题。

ES由于他的业务特性巧妙地规避了这些技术难题,再加上logstash和kibana开源套件整合,构成了ELK开发套件,能够在运维数据分析方面做到开箱即用,逐渐深受广大用户的认可。

要强调的是,运维数据分析只是搜索引擎技术应用的一个分支,并不是全部

对于搜索,更多的场景是处理企业业务数据搜索,例如,商品系统、订单系统、基于地理位置LBS地理位置、会员画像的数据的搜索。企业业务数据搜索场景对ES和Solr来说目前还没发做到开箱即用,必须要进行二次整合开发, 并没有形成技术标准。

涅槃

TIS立项之初的使命非常明确:

TIS使命:构建一站式企业搜索中台产品,让开发工程师像使用数据库一样使用搜索引擎

花了12个月的时间终于把新版本搞出来了,TIS2.0是在1.0版本上重新开发,将离线、实时、引擎部分进行无缝对接,使其可用性大大提高,可以通过TIS控制台对搜索实例 进行全生命周期维护。

TIS3.0新功能规划

我了实现我们的愿景,需要不断迭代TIS功能,需要对未来的实现的功能作一下规划,计划在下一个TIS版本中实现以下功能:

  • 支持更多数据源类型,如:TIDB等,目前只支持Mysql
  • 构建基于插机制的的生态圈。TIS搜索中台产品不是一个封闭的产品,按照OCP原则对于功能添加应该是开放的,在TIS平台上需求方需要对搜索引擎的组件作方便地扩展,但是可能他自己没有相应的开发能力, 此时可以引入第三方ISV(具备开发能力),提供相应封装好的插件在TIS平台上供用户选择使用。这样TIS平台上将需求方和提供方作对接,形成闭环,可以良性健康发展
  • 多用户鉴权,授权机制:在TIS平台上有多种角色,每个角色有相应权限,高权限的角色用户可以给低权限的角色用户授权。这样可是实现在TIS平台上多用户之间相互协作,以达到提供工作效率的目的。