阿里集团搜索中台TisPlus-阿里云开发者社区

开发者社区> 搜索与推荐技术> 正文

阿里集团搜索中台TisPlus

简介:                         阿里集团搜索中台TisPlus 搜索中台的发展     从阿里很多技术产品的发展路径来看都遵循着技术驱动、产品驱动、数据驱动三个阶段,那阿里巴巴的搜索技术的发展也基本基于上述的发展路径。

                       阿里集搜索中台TisPlus

搜索中台的

    从阿里很多技术产品的发展路径来看都着技术驱动、产驱动、数据驱动个阶段,那阿里巴巴的搜索发展也基本基于上述的展路径。第一个段我走了将近10年的时间,一直到在我仍然在持续优化和打造世界的搜索技。但如今的阿里集并不鼓励一杠子到底的小闭环的重复建,而是鼓励技体系中台化,所以搜索事部去承整个集的搜索业务需求是不容辞的职责,但只有技术强一个优势是很业务数量成模情况下取得突破,因为对业务都是以目的方式开展是不存在外延性的,只能投多少人做多少事情。搜索技体系必要有沉淀模化的复制能力,是复统发展到在所必要有的基本能力了。那个基于上述原因如何打造搜索中台降低业务支持成本和提高用接入体更好的模化管理业务的第二段和第三段重任就落在我们团队的肩膀上来,好在因有了第一段整个事部打下夯往第二和第三段行走的程中始都是站在巨人肩膀上松前行,接下来的章跟大家更加详细的分享下我们这些年在搜索中台Tisplus方向上做的一些事情。

效率提升品化

   的平台系的效率提升我们认为可以分三大内容,分是系率、业务迭代效率、源分配效率。源分配效率提升阿里有专门的基于docker容器+自研度框架来解决,Tisplus平台也是利用了集已有的方案来改善集群源分配效率,所以这块的内容不会是本文述的内容,大家可以另行从其它文章行了解。Tisplus平台主要是聚焦在搜索系效率和业务迭代效率的提升,最近一年平台主要做的效率提升的事情主要

标渐进的管控

    传统的管控平台对于管控的理解更多是过程式的驱动,举个搜索服务引擎全量的例子来说明什么叫过程式的管控,如下图所示:

                                                        b9ba07805d5ad84bf0f547c245b768c55a680bae

     
可以清晰的看到于一个引擎服全量程需要4段,每个段等待上个行完后按行,相信大部分目前的管控任务执行也都是基于种架构,也包括我第一版的tisplus基于序流程的任务执机制来务执行。这样的架行目定,前往目的路径也是确定的,最大的问题是中间执行的任务节点出现错误,遇到问题都需要人接入理,定正常状,再继续操作。这样的架构体系冒失并没有什么不妥的地方。就是典型的程式理的思路,其当我的系越来越复情况过程式管控是会不断来一系列问题的。首先程任断和恢复被排除在系之外,是完完全全交由人来负责,无形中加重运维&担。也有人会挑战说,异常概率并不高啊,偶尔处理下并没投入太多,但想下我的平台如果支持成百上千业务实例的候,故障概率也就被成倍放大。   其次很多候运管控操作是会出反复,比如正在做全量任流程中,出需要更机器怎么,比如升级A版本程中突然需要改回B版本了,又比如回滚B版本程中又得升C版本怎么?好吧遇到上述问题程式管控只能要么等待任流程束,要么中断任流程。选择前者只能延后理异常,很多线上并不能接受。选择后者如果遇到是中断成本比高的任,后的任重做、清理中的成本几乎不可接受,而且最的是能够处线上状的人需要有特深刻的了解和非常线上运能力,而问题的定位和解决依然取决于个人的能力高低,话说这些能力是和人相关的,并没有被沉淀到系里面,个人能力是不能被承。
     
所以基于上述问题,搜索各个在线管控平台提出了目标渐进式最一致性的自化运的想法,其核心思想如下所示: 

                                                           3424a1bffe01eb47ea3425170c98b207a525ae57

   
们认为态应该是在当前状current)到目target)的多迭代的回,具体什么意思呢,简单就是当前系A候我向系统设定一个目态B,系就开始朝着状态B执行前进,并且执行完所有的必要路径action 1234),如下所示:

                                                              3d87bddb1bebc7d8833088f4dbe6f8928785a162

  
但是如果突然候我重新统设定了新的目标C,那么系将会得最新目和当前渐进的目标进比,发现存在化,系止掉当前行路径和自清理系存在的不一致状,开始下放最新目路径行通知,各个点接受到最新命令后开始逐步像新的目标渐进,如下所示: 

                                                                 6a286789283e3186b606eb3718927476902f5172

  
当然整个程我并不会限定置次数,多次最于系只是通轮设定目找当前状到达最必要关路径行。当然如果状和状存在关路径的分支,那么如何选择一个当前状到目的最短最路径就会是一个新的挑方向,目前我正在对这研,希望未来系能沉淀出来更智能化的决策中心,不仅仅只是得目态变更的行关路径,更能在存在复分支的行路径中找到最路径行。

                                                             3db1d538a0cbb3931c0297f30993a9b7153c3350

 
上述文字的描述相信大家标渐进式的运管控有了一定了解,基于设计思想下的运管控体系很大程度上解决了之前程式的各种弊端,其中我个人认为有价的点是在于它真正做到了沉淀能力和放人力。什么强调这点是因得在可以预见的未来,搜索技体系一定会得越来越功能大但是同它的复度也会越来越高,肯定有一天会超越人能把控的程度,所以建一套能代替有经验的人做出很多有效决策、并且能保障在线健康度和定性的运管控体系就得尤重要。

端对端的管控设计

   关于效率提升最核心的应该还需要三点:首先管控技体系本身应该是服化的,不应该化操作,下却还是依靠脚本操作。其次品化需要做到端端更高的抽象,需要屏蔽到后端系统间同交互,不应该让做一次迭代开线还需要在平台中操作各种系统进行近10来次的操作修改。再次管控应该都是可化的,然可化不是什么新的概念,但也不能仅仅依靠everything变成可视化就解决了所以问题,整体可视化的设计应该有背后一套逻辑的,本文阐述下在tisplus新平台里可视化的概念应该涵盖的内容是:

  • 面向最的运操作可化操作
  • 线当前状态应该是可化的
  • 线任何任务执行状态应该是可化的 
  • 线务产生的数据经过分析后应该设计成可化数据化运营场

在离线的高效

     在复搜索景里在线引擎服是脱离不了离线输送数据而独立存在,所以线的数据得更加高效,我和离线团队共建了tisplus线组平台。平台的核心能力是可以在画布中通拖拽点的方式去定数据的关系和数据理流程。通种更高级别数据理抽象很好的屏蔽了用在复数据源情况下需要重复开数据关系及理数据流程的代问题,此外通一次性的数据关系和理流程的可化描述,就能将搜索引擎所需要全量和增量完美一。意味着你只需要拖拽描述下点,全量数据准实时增量更新就能完全交由平台系搞定,业务底解既写全量ODPS&Hive SQL又要去写实时增量数据理的问题极大的提升了业务接入搜索服效率。另外个核心功能是我支持各种异构数据源的自由合,话说任何来源(ODPSHDFSHBASEMYSQLRDSOTS、OSS)的构化数据(非构化数据也支持UDF进行处理)都能自由去定义他们之间的关系和处理流程(如下图所示):

                                                                c4f4ef92b1b30463bb736e89c6772c79a72d3890

     
引擎源数据全量&增量理的效率在tisplus离线组件上线后真正得到了飞跃,但我们绝不会只引擎索引源数据的全量&增量预处理,在未来将支持更多的数据源合之外,会一步考搜索景下需要融合算法的需求,将离线组件平台演化成可以支持算法特征提取、特征离散&归一化、模型训练、模型效果评估的算法数据处理的平台,从而让算法同学在利用tisplus平台到从在线到离线的一站式端端用

数据化运

   平台业务规模越来越大,平台对业务本身的管理、定性保障和成本控制就得越来越有挑,所以在段我开始从驱动逐步朝着数据化运营优化平台转变,在落地了容量估、一键诊断、日常巡测试中心、成本趋势等一系列数据化景来帮助化平台,主要也是了加整个平台的成本控制和定性化方面。在未来我希望通更多数据化景来引看懂数据,理解数据价,主会利用数据化建化自身业务

成本可控

成本可衡量

  搜索度框架(Hippo)做到了屏蔽机器概念,而通过资度机制使得物理机可以被多业务合理的复用的,而使用容器技也使得每个业务就可以被容器度量的源(cpumemoydisknetworkquoto单位来衡量,而为了让quoto可以被具体化成成本我打造了属于我自己的计费统costman,有了在我平台上任何的业务都可以被计费,一些源浪和成本化都可以被追踪,同数据化运值有了可以被衡量的数据化依据。

容量

   随着搜索业务日益增多,诸多系统都在走向平台化,平台上应用成千上万如此多的应用依靠传统的人肉资源管理方式,成本越来越高,特别是面临诸如以下问题,极易造成资源使用率低下,机器资源的严重浪费。

  • 业务方申请容器资源随意,造成资源成本浪费严重,需要基于容器成本耗费最小化明确指导业务方应该合理申请多少资源(包括cpu,内存及磁盘)或者资源管理对用户屏蔽。
  • 业务变更不断,线上真实容量(到底能扛多少qps)大家都不得而知,当业务需要增大流量(譬如各种大促)时是否需要扩容?如果扩是扩行还是增大单个容器cpu规格?当业务需要增大数据量时是拆列合适还是扩大单个容器的内存大小合适? 如此多的问号随便一个都会让业务方晕圈

  以上归结摆在我们面前的问题就是:如何能自动化的指导应用申请合理的机器资源,提供稳定的搜索服务的同提高资源使用率所以在这个需求背景上我们打造了容量评估平台Torch

                                        abf5c320c2e02fa6b9ab0499d9422cde9f0970d1

平台的主要核心行流程是:

  • 容量管控根据并发设置,将n个应用分别基于生产环境clone完整的一行clone的目的是要保证压测出来的极限容量是生产环境真实的容量,并且让压测不影响到线上服务。
  • 对clone环境进行自动化压测,自动压测到极限容量后(cpu 70%)停止。
  • 将压测数据及kmon日常数据传给IDST资源成本分析算法服务,经过成本计算和优化,给出合理资源申请建议(cpumemdisk,行列分布等)。
  • 根据算法建议更新克隆环境资源,并再次通过自动压测进行校验。
  • 将经过验证后的资源建议进行持久化保存。
  • 在tisplus console上进行展示及提供各种容量优建议,方便用户一键进行容量

   

     整个Torch系过airflow分布式任务调度平台)平台将tispluskmon实时mertic系统)、costman(成本系统)Heracles(压测)将数据分析同成个数据分闭环天周而复始的自动执行给建议,而不需要人工介入。而容量双11期间为参入优化的12个应用容器成本累计日均节省4.6W元, 整体相当于每年容器成本节省1600W。

稳定性可

  平台加速业务迭代和布效率,并不是意味舍弃定性环节为前提片面的追求效率,所以我在平台建的原上都是保障服务稳定性的前提上提升迭代效率,所以我依然会投入非常多的精力去打造平台定性能力,本章主要大家介定性方面做得相关事情。

测试技术体

  平台测试体系的建是我们团队跟搜索事-工程效率&术质量升龙团队一起同打造的,其中最核心的两个模是:

冒烟平台
  冒烟平台的核心目实现业务快速回、快速发现线上异常。平台降低了搜索线上回归测试的复度,提供了丰富的测试方法,如查询验证、流式case测试等,业务方可在tisplus平台行小白化case编写,轻松写case。冒烟case执行接入了Tisplus业务发布流程,实现了发布自动冒烟,保证了上线版本质量,同时也逐渐培养业务方无冒烟,不发布的质量意识。
压测平台
  搜索压测平台(heracles)支持多种服务发现方式(ip/cm2/vip/hsf/mtop),多种数据取方式(hdfs/odps/http),是一个分布式、高性能的压测平台。压测平台依托于搜索度系实现机自分配、容,压测过程不支持人工速;也支持多种自动调速模式,平台已支撑了搜索/推荐2017年双11大促压测QPS350w,同时压测链路超过500个。tisplus平台无缝对接了压测平台,所有平台业务无需准备测试数据、测试机器、测试脚本、只要填写压测,即可快速完成系性能压测,在极大提升了压测实施效率的同时也使TisPlus平台只能从大促压测演化到日常化压测变成了可能,而一步有了日常化压测的数据的出也容量平台动态调行成本了数据基

优化日常

   驱动时代平台的全部精力都只关注业务如何接入,怎么快速接入,至于接入后业务方怎用好搜索服,是否正确使用了搜索服平台并没有很好的关注,也就是整个tisplus平台有很一段时间线上服务稳定性的掌控是比弱,所以以前平台理的方式都是搜索业务线上服扛不住了(查询Load变高、磁盘不够)并报警了,运维人员才能参与处理线上问题,遇到核心业务事后亡羊补牢式的处理,但已经不能改变背P级故障的厄运,也许故障reivew过后发现是业务方查询使用不当或者数据量、查询量的预估不合理,最终故障单并不是平台方来背,但是故障的发生并给集团造成的损失还是存在的。面对这样的问题,平台方是不可能一对一保姆跟踪所有线上搜索业务状态的,但如果把职责给业务方,又面着搜索技并不像数据即使于普通开而言的普惠技,所以没有工具或者机制保障单纯依靠业务方的及时汇报是不可能很好地去保障搜索服务稳定性的。所以只能是平台方往前走一步,通提供更好的机制和手段,将服的潜在风险暴露出来,在问题终发生前将可能生的故障避免掉。在面对这问题,我很好的参考了windows电脑家的品思路,屏蔽搜索系的复性,户时刻知道自己搜索服的健康程度,并通恢复的方式,搜索服可以恢复到相健康的状目前我们打造的优化大师平台Hawkeye(好可爱)逐步很多核心搜索业务提供健康分断的功能,我几个常并特行之有效的定性提升手段,例如

  • 字段配置合理性分析:慎的字段型配置源成本高的问题得到根治。
  • 容量估合理性分析:数据、查询变化率分析,精准知道业务规趋势,准确知道当前服集群支撑业务的余量,达到源瓶前做出容保障定打下基
  • 算法feature分析:精确定位到算法字段性价比分析,通字段占用源和访问频次,排序打分的关分析后将成本高但是献度低的字段注并建做下线处理。
  • 查询Query性能分析:,通过对户查询Query的分析后,对查询慢、性能多的查询Query在搜索查询多个段的耗时进行精准定位,准确定位性能瓶,最分析后能予用户查询优化建,常查询优化有过滤转倒排,构建合索引,查询query改写等。

     上述似的分析手段,并通一种算健康分算法,平台就能业务进行健康度行打分,越高得分的业务线定性越高,源利用最合理,而得分越低的业务线上的业务肯定是不定或者使用不合理的

问题诊

      的搜索业务场景不仅仅只会是一个倒排的搜索引擎,都会涉及到多个服,所以面一个系架构、依赖链路复问题不能容易快速定位的问题,所以很大程度上线上故障的排都只能通经验的开或者PE来通多个系的日志分析、模拟现场等方式来行定位和修复。但是否问题只能通人工介入分析后才能做到精准定位并行后续动作呢?其很多情况下线问题是具有相关律的,所以我希望将些人的分析能力的经验沉淀到系中来,程序模拟人的行为作出判断,就像我们去医院看病一样,医生诊断病因也是通过几种常见手段(验血、CT)来断病因,那么我也希望有一些系可以提供似的断手段,精确的定位分布式系下的线问题,我们暂且称之路一键诊断系,当然此系可行性的前提是被检测的系本身存在可以被衡量、可以被识别准化的系业务数据,个方向依然困重重,我依然需要努力前行。

报警理念升级

     相信很多人使用控的同学都会遇到似的问题,首先阀值基本靠拍袋,如果阀值设格,生很多误报警接受人最终变得麻木,对报警失去警惕性,生漏,最终导致故障造成业务损失。所以一般的解法只能依靠使用者多次的主意愿、甚至是多次惨痛经历后才能慢慢的将阀值设置收,达到一个相正常的范,但种依靠多次事故后阀值敛设置更多是一种主意愿和经验驱动数据化,但是面一个需要支持海量业务场景的平台系而言,种人肉控体系去固定人力投入会致人力成本的直线上升,开都会持的投入到一些没有附加的重复劳动中去。所以面对这样问题,我提出智能化警平台的建展到在我一定要有个非常明确的概念,就是数据已仅仅是一种信息的体,更是一种能提高生力的力源,同理我们对搜索服自身生的业务数据也应该发知上的化:它不应该只是metics或者表可化数据入而已,它更应该反哺业务健康展的生产资料,它是可以通挖据其内部的价,建立警数据模型从而实现过历业务数据去业务动态报阀值、系异常点检测的目,所以我们认为的未来的应该是不再需要依靠人力投入支持,而是通过业务数据分析反后能动调整收的智能化警系

未来

     目前平台主要是提供基务输出,话说Paas层的服务本质上其实没有多少差别,那么这种技术可以被替换的门槛依然很低,但是搜索技术真的只能做到PaaS层吗?其实未必,在复杂搜索场景里其实更多的是结合数据和算法形成具有场景领域知识的排序和推荐服务,而以这种服务能力输出才具有非替换性门槛,所以我们大胆的认为依托于业务领域并结合数据和算法能力提供搜索行业Saas解决方案才是平台的未来。

总结

     中台价是什么?我认为中台价就是前面的业务走的更快更容易,前面的得更简单。基于这样的一个衡量准,Tisplus平台发展至今已经在搜索中台这个角色上初步展露头角,整个平台在默默在背后支持了很多里集团核心业务,耳熟能详的有商品中心IC、聚划算、lazadapaytm、天天特价、村淘、酷、闲鱼价、盒猪、菜等搜索排序和业务,而些核心业务业务始自助的使用平台能力快速迭代业务,截止到目前业务方每天基于Tisplus平台行几百次业务和算法更新代,Tisplus平台以前可能一周一次复杂业务迭代效率提升到可以一天多次更新代,大的了算和业务的生力。所以毫不夸说Tisplus平台沉淀的搜索准化管控功能在深刻的影响着集搜索业务、算法、搜索运同学日常的工作方式,同Tisplus平台也成了复分布式系业务迭代效率在中台略中的最佳在回想一路走来是很不容易,因做中台特是往上做的人,往往具有很多品不确定性,比如很知道品需要做成什么、很难评估其价值产出,但好在团队小伙伴一起信中台方向价,在人手有限的情况下并行拓展了很多核心方向并持落地,当然也是得益于平台的力量,精力更聚焦在平台展而不是业务支持上,但中台之路注定不简单未来需要去探和攻克的方向和困难还有很多。另外今年我们的下半平台年处于井喷式快速发展,急需各路英雄一同聚义共谋大事。所以如果你不惧怕挑战,并具有持续不断的学习激情和能力,对搜索公有云、专有云输出、搜索性能优化,算法端对端产品化这些搜索领域最头疼的问题充满兴趣,那么我们团队绝对是你发展的最佳平台,所以请你毫不犹豫的联系我:

                                                  4c0991fd8ae4d9d81dc139002d9dd4f5e72b3ea0

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

AI Online Serving,阿里巴巴集团搜索与推荐,算法与工程技术的大本营,大数据深度学习时代的创新主场。

官方博客
友情链接