本文出自《程式員》與阿裡雲聯合主辦的《淩雲》雜志。
作者：郭瑞傑
随着網際網路資料規模的爆炸式增長，如何從海量的曆史、實時資料中快速擷取有用資訊，變得越來越具有挑戰性。搜尋是擷取資訊最高效的途徑之一，是以也是各類網站、應用的基礎标配功能。開發者想在自己的産品中實作搜尋功能一般都是基于某個開源搜尋系統（如elasticsearch、solr、sphinx）搭建搜尋服務。然而，除了購買主機或托管伺服器，從系統熟悉、服務搭建、功能定制，再到服務上線，通常需要耗費較長時間。
雲搜尋是一種結構化資料的搜尋托管服務，開發者可将資料上傳至雲端進行資料處理和索引建構，再通過api使用雲搜尋服務。它的出現很好地解決了以上問題。opensearch（開放搜尋服務）是阿裡雲推出的一套自助式、可定制的雲搜尋服務，初衷是将阿裡巴巴積累近10年的搜尋引擎技術平台化、服務化，并開放給廣大開發者，降低實作專業搜尋産品的門檻，讓開發者以較低的成本輕松擁有跟淘寶、天貓、一淘等應用的搜尋工具類似的專業搜尋産品。本文将介紹opensearch的發展曆程、基本功能及實作原理和架構，以實際應用場景為例講述應用實踐過程。
發展背景
2012年初，我們組建了雲搜尋技術團隊，嘗試将當時剛剛替換掉雅虎搜尋的搜尋引擎平台服務化和産品化。初期，opensearch的功能雖然簡單，但已完全展現雲服務的概念：使用者通過各種方式上傳資料到雲端，雲端進行資料處理和索引建構，使用者再通過api使用雲端搜尋服務，并整合到自己産品中。産品beta版釋出後，在未做任何推廣的情況下，服務了1200多家活躍網站，包括一些較大的垂直門戶網站，例如威鋒網、青島新聞網等。
opensearch幫助開發者簡化了使用搜尋服務的複雜度，降低開發成本，加快産品疊代速度。以作文網為例，其站長僅靠自己摸索，從接觸産品到上線僅用了一天時間。但我們也逐漸發現僅僅通過現有幾個預制的應用場景模闆遠遠滿足不了開發者需求，因為不同屬性的網站往往有不同的資料結構，千差萬别的相關性排序規則。
當時，我們内部在并行研發另外一款名為站内雲搜尋的産品，也是一款在雲端提供搜尋服務的産品，其資料結構固定，搜尋結果樣式可定制。站長開通這一服務後，網站資料可以被自動采集并進入系統。該産品的系統背景是從當時阿裡雲全網搜尋系統（現為神馬搜尋）中剝離出來的，本質上類似谷歌、百度等站内搜尋工具，隻是實時性更好。但由于無法滿足對資料結構、相關性排序等做深度定制等需求，産品被叫停。
這些事例讓我們認識到，雖然使用者對雲搜尋服務的需求很大，但一定要有深度定制的服務，否則無法滿足開發者複雜多變的搜尋需求。
2013年初，我們将精力集中在降低服務成本和提升産品功能上：一方面優化存儲和搜尋服務架構；另一方面開發資料結構、相關性排序、資料處理定制功能。一年時間内，opensearch快速疊代，服務了阿裡集團内部上百個産品和應用。這段時間的技術積累和内部業務的錘煉對opensearch至關重要，促使其系統架構更加完善、性能更高、穩定性更好，定制能力也能滿足絕大部分搜尋産品的需求，同時服務成本降到了一個較低的水準。2014年7月，opensearch完成全面改版，并向外部開發者開放，在公測階段受到了廣大開發者的歡迎。預計在今年底，opensearch将正式開始商業化售賣。
産品功能
opensearch有以下一些主要功能。
■ 支援文檔索引結構定制，以及自由修改。opensearch将搜尋引擎複雜的索引結構概念簡單化、可視化和自助定制化。開發者可以通過控制台建立搜尋執行個體，定制文檔字段的結構和屬性，包括字段名稱、類型、分詞方式、搜尋屬性等。搜尋執行個體在運作過程中可以自由修改，滿足了産品快速變化的需求，極大縮短了需求變更到上線的過程。
■ 支援多種資料接入方式，資料自動同步更新。開發者的資料如果在阿裡雲oss、odps等服務上，開發者隻需要在opensearch控制台中授權，資料就可以自動同步至opensearch中，後續資料的更新也可以自動實時同步（odps除外）。而且在同一區域中，從雲存儲同步資料至opensearch免收流量費用。資料不在阿裡雲上的開發者，可以通過restful api或者sdk上傳資料，小資料量也可以直接在控制台上傳。
■ 支援多表，插件式資料處理。類似于資料庫，每個搜尋執行個體可以建立一張或者多張表，每張表的字段上可以内置資料處理插件，對字段内容做文本處理和轉換，例如拼音轉換、html标簽剔除、json資料解釋等，多個表可以join在一起實作多表聯合查詢。資料存放在rds資料庫裡的開發者，可以用此功能替代資料庫全文檢索，實作更高的性能和搜尋體驗。
■ 支援搜尋結果相關性兩階段排序定制，線上實時相關性調試。使用者使用搜尋功能的目的是從海量資料中找到自己想要的資訊，搜尋結果相關性排序是影響使用者體驗最關鍵的一環。opensearch支援開發者定制兩輪相關性排序規則來準确控制搜尋結果的排序。
第一輪為粗排，從命中的文檔集合裡海選出相關文檔。支援配置字段、文本相關性和實效性算分特征的權重。第二輪為精排，對粗排的結果做更精細篩選，支援任意複雜的表達式和文法。這樣做除了友善開發者能更準确控制排序效果之外，更重要的是能優化系統性能，提高搜尋響應速度。開發者可以通過排序規則直接在控制台中調試效果，并在效果滿意後直接切換到線上。
實作原理和技術架構
opensearch底層搜尋服務基于阿裡自主研發的大規模分布式實時引擎平台isearch 5，該平台有靈活的相關性計算架構和統一的業務服務層，并且有自動容錯和自動伸縮機制，承載了阿裡集團包括淘寶、天貓、神馬搜尋等在内的所有主要搜尋業務流量，搜尋請求峰值數十萬qps。圖1是opensearch的整體架構圖。
開發者通過控制台和api與系統互動。典型的使用流程是開發者進入控制台，建立應用執行個體，配置應用字段結構、搜尋屬性、文本處理插件、定制相關性排序規則等。應用執行個體建立完成後，開發者再通過sdk/api将資料推送至雲端（阿裡雲存儲使用者可以使用資料自動同步機制），資料實時進入import子系統的資料導入服務子產品（istream service），經過格式解析和資料處理後，存儲在結構化資料存儲系統中。随後，dump子系統的資料導出服務（istream service）将資料經過一定處理後發送給實時消息隊列系統（swift），搜尋系統（ha3）從消息隊列中訂閱資料，在記憶體中建構索引并提供搜尋服務。這個資料實時流式處理過程（見圖1白色箭頭）大概十秒鐘。
當開發者修改了索引結構後，需要對應用中的資料做增量索引重建。為了保證搜尋效率，系統也會定期對所有資料做全量重建索引。索引重建流程參見圖1紅色箭頭，這是一個非實時的流程，依資料大小不同可能需要幾分鐘到十幾分鐘，全量索引重建則需要數小時。
資料在雲端經過一系列處理和索引建構後，開發者就可以通過api搜尋應用執行個體中的資料，搜尋請求會被發送到查詢聚合服務aggregator中。如果開發者配置了查詢改寫處理邏輯（即将上線），aggregator會将查詢請求發送給查詢改寫服務qp，qp按照開發者配置的處理規則（如拼寫糾錯、同義詞或者查詢語義改寫）改寫查詢請求，并将改寫後的查詢回傳給aggregator，aggregator最終将查詢請求發送給搜尋系統ha3，ha3根據開發者定制的相關性排序規則對命中的結果文檔排序，并最終通過aggregator将結果傳回給開發者。為了保證不同開發者各個應用資料推送和搜尋互相不受影響，配額管理服務（quota server）會依據開發者的配額（文檔規模、qps等）對進入系統的資料和搜尋請求頻率做限流控制。
前面多次提到的ha3是阿裡自主研發的新一代分布式實時搜尋系統，中文名叫問天3，具備自動容災、動态擴容、秒級實時等能力。圖2是ha3系統子產品組成圖。
其中，admin是整個系統的大腦，負責節點角色配置設定、排程決策、failover處理、狀态監測、動态擴容等。amonitor是系統的性能狀态監控子產品，收集和展示整個系統所有節點的性能參數。qrs是查詢解析和改寫服務，是系統對外的搜尋接口。proxy是搜尋代理子產品，負責接收qrs的查詢請求，并轉發給下轄的所有searcher節點。searcher節點執行實際的查詢比對計算，将搜尋結果彙總後回傳給qrs。deployexpress是分布式鍊式資料實時分發系統，負責将離線叢集建構好的索引資料分發到各個searcher節點。deployexpress的最大亮點是将1份資料分發多份拷貝到searcher節點，其分發時間接近單份拷貝的資料分發時間，而且單節點故障能自動恢複，不影響資料拷貝。在同等硬體條件下，基于1200萬資料做單機性能對比測試發現，ha3比elasticsearch開源系統的qps高4倍，查詢延遲低4倍。
圖3是ha3的多叢集異構部署圖，其中部署了兩個異構邏輯叢集cluster1和cluster2，兩者的硬體配置、索引結構、服務能力可以不同。這種部署一般用來實作冷熱資料分層查詢、異構資料查詢等功能。
opensearch利用異構邏輯叢集優化資源配置，提升系統服務能力和降低機器成本。不同特性的應用執行個體被配置設定在不同的邏輯cluster中。例如，qps較高，資料量較少的應用執行個體配置設定在ssd磁盤的cluster中，該cluster列數較少，但行數較多，能承載較大的搜尋流量；而一些qps較低，資料量又較大的應用執行個體配置設定在普通磁盤cluster中，該cluster行數較少，但列數較多，能承載海量的使用者資料。當每個邏輯叢集的資料量增大時，系統可以通過增加列（partition）來擴大系統資料容量；當搜尋流量增大時，通過增加行（replicas）來提升系統服務能力。
應用實踐
基于opensearch，開發者可以實作各種功能的搜尋産品。例如，淘點點實作了基于地理位置的餐廳、外賣、代金券搜尋，天貓魔盒實作了電影、電視劇搜尋，寶寶樹實作了問答、知識搜尋，威鋒網實作了論壇文章搜尋，書旗網實作了小說搜尋，來往實作了紮堆内容搜尋。這些産品，不同程度地使用了opensearch索引結構定制、資料自動同步、兩階段相關性排序等定制功能。下面結合實際應用場景，講述opensearch的應用實踐過程。
■ 簡單示例：小說搜尋。
假設開發者做了一個小說網站，小說迷們可以線上搜尋、閱讀小說。網站小說數量突破100萬大關，活躍使用者已過千萬。随着使用者數量增長，搜尋量越來越大，小說搜尋功能剛剛從資料庫全文檢索遷移到某搜尋引擎的站内搜尋上。遷移後，雖然解決了搜尋并發問題，但新的煩惱來了：搜尋結果不全，新增小說無法及時搜尋到，搜尋功能單一，不支援按作者、章節搜尋，不支援按分類、章節、狀态、時間、閱讀數、評分等條件過濾。在這個場景下，opensearch可以為其排憂解難。
開發者先登入opensearch控制台，在控制台中建立一個應用執行個體，例如my_novel。建立過程中選擇“小說類（builtin_novel）”模闆。這個模闆已依據小說搜尋的應用場景，預先定義好了小說類資料的字段結構、搜尋屬性、排序規則、搜尋結果高亮配置等功能。
建立完應用執行個體後，可以編寫代碼上傳資料。以php sdk為例：
如果開發者的小說資料在阿裡雲雲存儲服務oss中，一篇小說一個檔案，存放在一個bucket下，在建立應用過程中，可以直接配置使用這個bucket作為資料源，小說資料将自動同步至opensearch中。 接下來使用api/sdk搜尋雲端的小說資料，代碼示例：
$search = new cloudsearchsearch($client);
// 添加指定搜尋的應用：
$search->addindex("my_novel");
// 指定搜尋的關鍵詞，
$search->setquerystring("default:'鬼吹燈'");
// 指定搜尋傳回的格式。
$search->setformat('json');
// 傳回搜尋結果。
$search->search();
到這裡，小說搜尋雲端部分的工作就完成了。開發者可以前往控制台“下載下傳中心”下載下傳小說搜尋結果的模闆，做簡單修改後，一個專業的小說搜尋産品就可以上線了。此時，更新的小說能即刻搜尋，搜尋結果全而且結構豐富；搜尋功能上不僅支援按書名和作者搜尋，而且支援按分類、字數、狀态過濾，按預設相關性、更新時間、評分數、閱讀數、推薦數、點選數排序。
■ 複雜場景：外賣搜尋（場景中所有配置均為示例，開發者需按實際需求調整）。
假設開發者開發了一個外賣app，聚合了上百萬的外賣商家資料，使用者可以在app中基于地理位置搜尋附近的商家，支援按菜品、商家名搜尋，按配送範圍、配送速度、配送時間、菜品類型等條件過濾，按人均消費、評價、距離遠近排序。開發者基于資料庫在實作這些功能的過程中碰到了一些問題：菜品或商家搜尋比對效果不理想，基于地理位置的排序效果不好，搜尋結果無法定制（例如實作一些商業排序邏輯）。
對于這個場景，opensearch的内置模闆目前并沒有覆寫，但開發者仍然可以基于opensearch解決上述問題。首先，在建立應用執行個體流程裡，選擇“自定義結構”，配置資料表的字段結構、資料處理方式、索引屬性，最後送出建立應用執行個體。表1中是配置的字段和類型（限于篇幅字段數量做了精簡）示例。激活應用執行個體後，進入“應用詳情”配置頁，選擇“搜尋結果相關性配置”，添加一個粗排配置，可以配置數值類型字段、文本相關性特征（static_bm25）、時效性（timeliness）特征的權重，例如：
static_bm25()*0.3 +speed_score*0.2 + sold_score*0.5
在粗排排序過程中，每家商家将按上述表達式計算分值。在這個例子裡， 商家名的文本相關性特征的分值比重是0.3，配送評價分值比重是0.2，外賣評價分值比重是0.2。
接着，在“搜尋結果相關性配置”界面中，繼續添加一個精排配置，這裡可以是一個非常複雜的表達式，例如：
text_relevance(auction_title)*3+if(text_relevance(auction_title)>0.1, speed_score*1.5, speed_score*0.6) + atan(speed_score + sold_score)*0.5
在精排排序過程中，粗排計算得到的商家按上述表達式計算分值。這個表達式用自然語言描述是：auction_title字段上的文本相關性分值乘以3倍，如果auction_title字段的文本相關性分值大于0.1，則配送速度speed_score分值乘以1.5，否則乘以0.6。speed_score、sold_score累加後做atan數學運算，比重是0.5。各部分分值累加後作為商家的最後分值，所有商家按分值高低排序後作為最終搜尋結果傳回。将添加的粗排、精排配置設定為預設，搜尋結果就會按照自定義的規則排序。開發者也可以直接在api或sdk中指定粗排、精排名稱，具體參考api說明文檔。
最後，在“應用詳情”配置頁中進入“搜尋結果摘要”，添加需要做摘要和高亮的文本類型字段，配置摘要片段長度、片段數量、高亮标簽。這樣配置後，将會在搜尋傳回的商家清單中将命中的搜尋關鍵詞高亮顯示。
至此，商家搜尋應用執行個體定制基本完成，開發者可以依據上一執行個體介紹的方法上傳資料，并且設計和開發産品的搜尋結果頁。
另外一個基于地理位置排序效果不好的問題，可以在搜尋查詢串中使用distance文法實作，例如：
sort=-distance(lon, lat, "20.23", "20.84349")
從上述介紹的應用實踐案例可以看出，使用opensearch，對搜尋了解不多的開發者可以輕松上手；當資料結構複雜時，對相關性要求高的開發者也能靈活定制。
下一步規劃
為了給開發者提供更簡潔、流暢的雲搜尋服務體驗，我們将在以下幾方面發力。
■ 進一步降低搜尋門檻，讓開發者零成本接入。持續簡化搜尋概念和産品互動流程，api、sdk相容開源标準，并在主流cms系統、移動開發工具中内嵌搜尋插件。一些搜尋外圍功能将很快開放給開發者，例如下拉提示、搜尋熱詞、拼音搜尋等。
■ 增強相關性定制功能、提升定制靈活性。在粗排和精排規則中增加電商搜尋、o2o地理位置搜尋、圖檔搜尋、音視訊搜尋等常見業務場景的相關性特征函數。這些特征函數将進一步提高相關性排序效果。精排規則将允許使用成熟的腳本語言（例如lua），來編寫更加複雜的相關性排序邏輯。此外，我們正在研發查詢處理服務（qp），将支援使用者配置複雜的查詢處理插件鍊，更準确了解和處理使用者查詢。
■ 豐富應用場景模闆。在應用場景模闆方面，将預制更多模闆，并豐富搜尋結果頁樣式，允許開發者定制樣式，并将結果頁在雲端托管。再進一步，将支援開發者分享和交易自己建立的模闆，傳承開發者在各個領域積累的搜尋經驗。
■ 幫助開發者盈利。通過流量盈利：我們将對接廣告系統，允許開發者通過api在自己的搜尋結果頁中嵌入廣告，或者在雲端托管的搜尋結果頁中定制和嵌入廣告，将搜尋流量轉換成廣告收益。通過資料盈利：開發者以搜尋服務的方式共享資料源線上交易，其他開發者利用這些資料定制和建立自己的産品。
雲搜尋服務在國内外都還剛剛起步，還沒有廣泛應用。但在可預見的未來，雲搜尋必将像其他基礎雲服務一樣，成為網際網路産品的基礎設施。我們希望能和廣大開發者一起努力，打造更為好用、更為強大的雲搜尋服務。
2008年博士畢業于中國科學院計算技術研究所，畢業後加入阿裡巴巴，負責阿裡巴巴新一代搜尋引擎平台ha3的設計和
研發工作。2012年開始專注于開放搜尋（opensearch）産品研發。新浪微網誌：ruijieguo