DII—算法服务利器-阿里云开发者社区

开发者社区> 搜索与推荐技术> 正文
登录阅读全文

DII—算法服务利器

简介: 随着集团内各种离线处理、实时反馈、在线学习和分析系统的发展壮大,为算法同学使用数据提供了更多的手段和玩法,能够从数据中挖掘出更多的宝藏。但是仅仅产出数据是不够的,他们需要将数据结合算法在线服务的方式应用到业务中去,才能真正产生价值。从搜索事业部的现状来看,算法的作用方式主要有两种,一种是嵌入引擎内.

随着集团内各种离线处理、实时反馈、在线学习和分析系统的发展壮大,为算法同学使用数据提供了更多的手段和玩法,能够从数据中挖掘出更多的宝藏。但是仅仅产出数据是不够的,他们需要将数据结合算法在线服务的方式应用到业务中去,才能真正产生价值。从搜索事业部的现状来看,算法的作用方式主要有两种,一种是嵌入引擎内部跟着引擎一起run,一种是作为独立的算法服务存在。前一种方式相对聚焦,一般不会做很发散的事情,主要是结合在线的特征做一些排序和打散。后一种方式下,可以做的事情更多也更加灵活,以这种方式作用的服务包括号称搜索大脑的QP,以及suggest, relatedsearch等等。DII的诞生,就是为了支持算法同学玩转这类系统。我很难用一句话就描述清楚什么是DII,还是先一起来看看DII设计上的一些思考吧。

DII的主要特点

一、增强的链式处理框架

链式处理框架的精髓在于,将业务逻辑拆分为多个相对独立的业务模块,每个模块完成一个比较内聚的功能,模块之间可以传递数据进行协作;当接入一个新业务时,可以通过组装现有模块(必要情况下增加新模块)的方式得到满足功能的一条模块链,简称服务链。一个DII服务中一般会同时存在多个服务链,提供业务线上不同的服务接口。一个示例DII服务逻辑如下图所示。
ServiceChain

链式处理框架是算法同学在长期工作中提炼出来的有效的运行模式。DII中对传统的链式处理框架进行了部分功能增强,主要包括:1.引入了参数传递的声明和限制机制,每个模块只能操作自己声明过的输入输出参数,这一方面使得模块的输入输出参数一目了然,带来了管理的便利性;另一方面也增强了安全性,避免参数的污染。2.在模块的process接口基础上增加了prepare接口,并且可以灵活定制处理链执行的分段策略,可以最大限度地增加对外部依赖访问的并发度,降低处理链的latency。
EnhancedServiceChain

二、丰富的本地索引支持

ODPS上产出的数据都是行列式的表格结构,在线使用时为了提升查询效率自然要建立一个合理的索引结构,因此DII提供了丰富的本地索引结构,也称为表。目前支持的表类型包括:
1. kv表。可以指定ODPS表的某一个字段作为key,其它的多个字段作为value fields。
2. index表。可以对若干需要进行倒排查询的字段按照某种分词方式建立索引。

与ODPS表对应,DII中表的记录也是分字段带类型的,可以直接按字段的方式使用。DII使用的是isearch5的索引实现indexlib,因此也天然具备了indexlib强大的检索功能和优秀的性能。在召回之上,DII还提供了过滤和排序机制,包括内置的过滤和排序规则以及用户自定义插件接口。此外,DII还封装了几种常用的组合查询方式,包括迭代、join、merge,使用起来更加便利。DII的索引机制是可扩展的,可以根据用户需求新增索引类型,例如目前正在开发的Trie树索引结构,用来满足一些使用前缀查询的业务场景。

ComplexQuery

三、原生的外部服务访问集成

"小而美”是DII服务的一个共同特点,也是DII设计的初衷,所以免不了会访问一些外部服务。在搜索内部,最集中的体现就是访问iGraph--一个在线图存储和查询服务。DII集成了iGraph访问的功能,并且在易用性和性能两方面都进行了重点考量。首先,通过让用户模块在prepare阶段声明访问请求,框架收集后统一并发访问,可以大大降低整个服务的延迟。其次,通过让用户以配置的方式声明访问请求,可以提升开发和发布效率。

四、完善的数据更新链路

数据更新包括两方面,一是ODPS表到DII表的全量更新,二是表数据的实时更新。DII在这两块都提供了完善的支持。用户只需要在自助接入的web上建立好ODPS表到DII表的映射关系,之后系统就会在ODPS表有新的分区产出时自动构建索引,触发线上DII表的全量更新,用户不需要参与。实时更新则有两种方式,一种是通过DII提供的工具来执行,另一种是调用API直接更新。前一种比较适合运营或算法同学手工干预,第二种适合由外部的实时更新系统持续调用。

DataFlow

五、简便的自助接入和配置

系统的自助接入曾经算是特色,现在应该已经成为标配了,DII自然也不例外,当然在用户体验上我们还需要不断学习和改进。

六、方便的本地开发调试

DII的服务大部分都是直接面向业务的,业务逻辑可能会比较复杂,用户直接接入集群环境进行调试不太方便,因此DII也提供了方便的本地开发调试工具,包括模块代码自动生成,本地索引构建脚本,外部依赖mock等等。用户可以在本地完成模块开发和功能调试,然后再接入日常环境使用真实数据进行性能测试和联调,最后再同步到线上环境对外提供服务。

七、快速的BTS迭代机制

BTS迭代效率从某种程度上来说是算法同学的生命线。DII作为算法服务的后台自然要支持快速的BTS迭代。我们利用了搜索事业部的bts server来进行bts流量管理和数据报表查看,同时自身提供了两方面的支持,一是快速部署,结合运维管理系统,几分钟之内可以完成部署一个新bts集群,这样就可以方便地将应用的正式集群和若干bts集群物理隔离,从而兼顾线上稳定性和bts效率。二是提供流量切分入口,有些调用方自身还没有接入bts server,因此DII服务本身提供一个流量切分入口,目前是通过一个nginx统一接入层来实现的,调用方看到的是nginx这一层,但是流量会根据bts参数设置落到应用不同的DII集群去。

Bts

八、强大的运维配套支撑

刚才说BTS时提到的是”快",对线上服务来说,可能更重要的又是”稳”,同时还要保证资源的利用率以及服务容量的弹性伸缩。DII集成了hippo的支持,所有的DII应用都是运行在hippo之上的,再配合上DII运维管理系统的水位监控和健康分机制,能够基本解决资源利用率和服务容量的问题。这里重点说明一下DII在稳定性方面做出的努力。一是对数据的校验,包括对离线数据的size检查,字段的类型校验,以及产出索引的size检查和完整性校验。二是对服务的校验,DII的运维管理系统中集成了业务的冒烟case检查,再加上完善的日志监控和服务指标监控,基本上可以在第一时间发现服务的异常,当然这点对冒烟case的要求也非常高,百分百的安全是做不到的。三是对灰度切换和上线支持,一般重要的线上应用都会部署规模不等的多个集群,DII在数据切换和上线时是可以自动灰度进行的,每次灰度之后进行服务校验,如果发现问题会立刻终止并发出报警。四是对快速回滚的支持,主要包括数据的回滚和应用配置的回滚,数据回滚可以支持到单表和多表级别,一般回滚处理的时间可以达到十分钟级别。

一口气罗列了DII的这么多目标,有些是基本已经达到了,有些还在努力建设中,像自助接入的体验和运维配套设施的完善,还需要时间打磨。下面再来看一看目前已经有哪些典型的应用正在使用DII,达到了什么样的业务效果。

典型应用

一、RTP

RTP(real time prediction)是业界标准的实时rank server,用于ctr,cvr等各种机器学习模型预估的特定服务器,主要是进行实时的特征提取,预估打分用于线上的排序。在刚刚过去的是双十一中,RTP 作为实时rank server 为”天坑一号“ ,购物链路,行业等50多个场景提供打分排序服务。 集群高峰流量达到20.1wqps,每秒对2890w宝贝进行打分,并且支持了部分实时性要求比较高的数据进行小时级别数据回流,为推荐算法效果助一臂之力。由于使用了DII框架,RTP系统可以只专注在特征提取和计算上,像数据更新,索引查询,集群管理这些问题统统不用操心。

二、基于lucy的相关搜索和下拉提示

lucy是Query理解和应用小组的词推荐业务算法库,服务的主要场景是根据用户输入词给出相关词,其中相关搜索和下拉提示是最典型的两个应用。lucy从设计之初就选定DII作为其服务的承载框架。基于lucy的相关搜索从诞生第一天起就与DII紧密结合,采用了DII的倒排召回、join查询、自定义排序等特性,支撑了更复杂的算法逻辑,取得了良好的效果提升。同时借助DII的快速开发和接入特性,除了原有的主搜pc相关搜索业务,还快速支持了海外淘等其他部门的类似业务。目前下拉提示后台服务也从老的系统向DII中进行迁移。

三、阿里翻译

阿里翻译是将指定的源语言翻译成目标语言的在线翻译服务。国际化作为阿里巴巴集团的三大战略之一,其重要性不言而喻,不同国家之间的商品实现便捷的在线交易,离不开翻译的影子。阿里翻译目标就是实现不同语种的相互翻译并不断提升翻译质量,用户不需要学习其它国家的语言,也可以方便地购买其产品。目前阿里翻译已经在天猫国际、淘宝海外、AE和SC等诸多场景下应用,正在发挥越来越重要的作用。阿里翻译也是DII上的一个重要应用,它利用了DII的kv表来存储短语数据,同时利用了表插件的机制来支持重排序模型和语言模型,整个翻译算法的过程也是以DII的插件来实现的。由于翻译语言的多样性,词典的数据量超过了单机容量,需要部署多个小集群来分别处理不同的语言,利用DII的快速部署功能也已经轻松的实现。

四、SCRankingService

SCRankingService是基于DII框架开发的国际广告SC引擎的在线算分服务。作为SC引擎相关算分的统一服务平台,一方面服务于imatch,提供对在线召回广告进行实时算分,以进行广告的排序;另一方面服务于bp(广告主后台),实时计算广告的排位排价以及广告与词之间的相关性星级。随着业务的发展,算法插件和模型越来越多,针对不同流量的算法策略都不尽相同。原先策略管理都在算法插件内部,算法插件不仅要进行各个处理单元的管理(如计算score的ectr模块和计算相关性的mlr模块),还要根据流量进行策略选择。因而算法插件越来越重,开发和维护成本越来越高;并且插件只能通过全量流程更新,更新较慢。在这种情况下,SCRankService2.0应运而生,利用DII的插件机制,将算法模块拆成各个处理Module,并进行统一管理;模块与模块组合成完整的处理链,使用DII框架进行流量策略选择,从而算法插件只需要专注自身的算法逻辑,简化了算法代码,优化整体处理性能。并且利用DII支持的UPC机制,可支持算法在线插件的分钟级更新。

五、QP

QP(QueryPlanner)是搜索算法同学的主战场,目前囊括了针对各个搜索业务线的query分析服务,包括主搜,天猫,1688,村淘,聚划算等等,以及一些提供给外部合作方的算法服务。QP中既有一些基础模块,比如分词、改写、纠错、打标、类目预测,也有一些业务相关的,比如个性化,协同,导航等等。QP是搜索的大脑,对效果和体验有巨大的影响。目前QP正在进行迁移DII的大动作,主要的目的包括以下几个方面:1.完成服务的合理拆分和解耦,保证多个业务线互不干扰。2.增强数据schema化和正确性、完整性校验。3.推动模块和服务链配置的web化、自助化。4.完善bts集群和流量划分机制,支持算法同学的快速试错。5.完善运维配套手段,包括异常监控和检测,灰色发布,快速回滚等等。这些都与DII的设计要点紧密贴合。

六、懒人购交互服务

懒人购交互式服务用于懒人购这一搜索、APASS共建的以服务为主导的导购类产品中,通过属性及场景的交互将用户的需求最终定位到淘宝的商品,并引导成交。这个目前来说还是一个创新型的小应用,但是它的快速接入恰恰验证了DII的价值。算法同学在离线做了大量工作,完成了比较复杂的数据挖掘,产出了几份词表数据,通过接入DII,将离线数据导入DII的表中,开发了几个并不复杂的在线处理模块,之后就快速完成了效果联调,资源申请,集群搭建,并最终实现对外提供服务。

这篇文章的主要目的,是向大家介绍一下什么是DII,以及我们为什么要做DII。总的来说,DII目前还是一个出生不久的婴孩,四肢和大脑都处在快速生长阶段,也还存在一些体验上的问题,不管怎么样,我们设计的初衷不会变,为算法同学提供最优支撑的理念不会变,在今后的发展中,期望与大家一起成长。

该文章来自于阿里巴巴技术协会(ATA)精选文章

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

分享: