转载

DII—算法服务利器

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

DII的主要特点

一、增强的链式处理框架

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

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

二、丰富的本地索引支持

ODPS上产出的数据都是行列式的表格结构，在线使用时为了提升查询效率自然要建立一个合理的索引结构，因此DII提供了丰富的本地索引结构，也称为表。目前支持的表类型包括：

1. kv表。可以指定ODPS表的某一个字段作为key，其它的多个字段作为value fields。

2. index表。可以对若干需要进行倒排查询的字段按照某种分词方式建立索引。

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

DII—算法服务利器

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

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

四、完善的数据更新链路

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

DII—算法服务利器

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

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

六、方便的本地开发调试

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

七、快速的BTS迭代机制

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

DII—算法服务利器

八、强大的运维配套支撑

刚才说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 ）精选文章

原文 http://yq.aliyun.com/articles/2951

正文到此结束