DII—算法服務利器

隨著集團內各種離線處理、實時反饋、在線學習和分析系統的發展壯大，為算法同學使用數據提供了更多的手段和玩法，能夠從數據中挖掘出更多的寶藏。但是僅僅產出數據是不夠的，他們需要將數據結合算法在線服務的方式應用到業務中去，才能真正產生價值。從搜索事業部的現狀來看，算法的作用方式主要有兩種，一種是嵌入引擎內部跟著引擎一起run，一種是作為獨立的算法服務存在。前一種方式相對聚焦，一般不會做很發散的事情，主要是結合在線的特征做一些排序和打散。后一種方式下，可以做的事情更多也更加靈活，以這種方式作用的服務包括號稱搜索大腦的QP，以及suggest, relatedsearch等等。DII的誕生，就是為了支持算法同學玩轉這類系統。我很難用一句話就描述清楚什么是DII，還是先一起來看看DII設計上的一些思考吧。

DII的主要特點

一、增強的鏈式處理框架

鏈式處理框架的精髓在于，將業務邏輯拆分為多個相對獨立的業務模塊，每個模塊完成一個比較內聚的功能，模塊之間可以傳遞數據進行協作；當接入一個新業務時，可以通過組裝現有模塊(必要情況下增加新模塊)的方式得到滿足功能的一條模塊鏈，簡稱服務鏈。一個DII服務中一般會同時存在多個服務鏈，提供業務線上不同的服務接口。一個示例DII服務邏輯如下圖所示。

鏈式處理框架是算法同學在長期工作中提煉出來的有效的運行模式。DII中對傳統的鏈式處理框架進行了部分功能增強，主要包括：1.引入了參數傳遞的聲明和限制機制，每個模塊只能操作自己聲明過的輸入輸出參數，這一方面使得模塊的輸入輸出參數一目了然，帶來了管理的便利性；另一方面也增強了安全性，避免參數的污染。2.在模塊的process接口基礎上增加了prepare接口，并且可以靈活定制處理鏈執行的分段策略，可以最大限度地增加對外部依賴訪問的并發度，降低處理鏈的latency。

二、豐富的本地索引支持

與ODPS表對應，DII中表的記錄也是分字段帶類型的，可以直接按字段的方式使用。DII使用的是isearch5的索引實現indexlib，因此也天然具備了indexlib強大的檢索功能和優秀的性能。在召回之上，DII還提供了過濾和排序機制，包括內置的過濾和排序規則以及用戶自定義插件接口。此外，DII還封裝了幾種常用的組合查詢方式，包括迭代、join、merge，使用起來更加便利。DII的索引機制是可擴展的，可以根據用戶需求新增索引類型，例如目前正在開發的Trie樹索引結構，用來滿足一些使用前綴查詢的業務場景。

三、原生的外部服務訪問集成

"小而美”是DII服務的一個共同特點，也是DII設計的初衷，所以免不了會訪問一些外部服務。在搜索內部，最集中的體現就是訪問iGraph--一個在線圖存儲和查詢服務。DII集成了iGraph訪問的功能，并且在易用性和性能兩方面都進行了重點考量。首先，通過讓用戶模塊在prepare階段聲明訪問請求，框架收集后統一并發訪問，可以大大降低整個服務的延遲。其次，通過讓用戶以配置的方式聲明訪問請求，可以提升開發和發布效率。

四、完善的數據更新鏈路

數據更新包括兩方面，一是ODPS表到DII表的全量更新，二是表數據的實時更新。DII在這兩塊都提供了完善的支持。用戶只需要在自助接入的web上建立好ODPS表到DII表的映射關系，之后系統就會在ODPS表有新的分區產出時自動構建索引，觸發線上DII表的全量更新，用戶不需要參與。實時更新則有兩種方式，一種是通過DII提供的工具來執行，另一種是調用API直接更新。前一種比較適合運營或算法同學手工干預，第二種適合由外部的實時更新系統持續調用。

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

系統的自助接入曾經算是特色，現在應該已經成為標配了，DII自然也不例外，當然在用戶體驗上我們還需要不斷學習和改進。

六、方便的本地開發調試

DII的服務大部分都是直接面向業務的，業務邏輯可能會比較復雜，用戶直接接入集群環境進行調試不太方便，因此DII也提供了方便的本地開發調試工具，包括模塊代碼自動生成，本地索引構建腳本，外部依賴mock等等。用戶可以在本地完成模塊開發和功能調試，然后再接入日常環境使用真實數據進行性能測試和聯調，最后再同步到線上環境對外提供服務。

七、快速的BTS迭代機制

BTS迭代效率從某種程度上來說是算法同學的生命線。DII作為算法服務的后臺自然要支持快速的BTS迭代。我們利用了搜索事業部的bts server來進行bts流量管理和數據報表查看，同時自身提供了兩方面的支持，一是快速部署，結合運維管理系統，幾分鐘之內可以完成部署一個新bts集群，這樣就可以方便地將應用的正式集群和若干bts集群物理隔離，從而兼顧線上穩定性和bts效率。二是提供流量切分入口，有些調用方自身還沒有接入bts server，因此DII服務本身提供一個流量切分入口，目前是通過一個nginx統一接入層來實現的，調用方看到的是nginx這一層，但是流量會根據bts參數設置落到應用不同的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 ）精選文章