隨著互聯網數據規模的爆炸式增長，如何從海量的歷史、實時數據中快速獲取有用信息，變得越來越具有挑戰性。搜索是獲取信息最高效的途徑之一，因此也是各類網站、應用的基礎標配功能。開發者想在自己的產品中實現搜索功能一般都是基于某個開源搜索系統（如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搜索云端的小說數據，代碼示例：
到這里，小說搜索云端部分的工作就完成了。開發者可以前往控制臺“下載中心”下載小說搜索結果的模板，做簡單修改后，一個專業的小說搜索產品就可以上線了。此時，更新的小說能即刻搜索，搜索結果全而且結構豐富；搜索功能上不僅支持按書名和作者搜索，而且支持按分類、字數、狀態過濾，按默認相關性、更新時間、評分數、閱讀數、推薦數、點擊數排序。
復雜場景：外賣搜索（場景中所有配置均為示例，開發者需按實際需求調整）。
假設開發者開發了一個外賣App，聚合了上百萬的外賣商家數據，用戶可以在App中基于地理位置搜索附近的商家，支持按菜品、商家名搜索，按配送范圍、配送速度、配送時間、菜品類型等條件過濾，按人均消費、評價、距離遠近排序。開發者基于數據庫在實現這些功能的過程中碰到了一些問題：菜品或商家搜索匹配效果不理想，基于地理位置的排序效果不好，搜索結果無法定制（例如實現一些商業排序邏輯）。
對于這個場景，OpenSearch的內置模板目前并沒有覆蓋，但開發者仍然可以基于OpenSearch解決上述問題。首先，在創建應用實例流程里，選擇“自定義結構”，配置數據表的字段結構、數據處理方式、索引屬性，最后提交創建應用實例。表1中是配置的字段和類型（限于篇幅字段數量做了精簡）示例。激活應用實例后，進入“應用詳情”配置頁，選擇“搜索結果相關性配置”，添加一個粗排配置，可以配置數值類型字段、文本相關性特征（static_bm25）、時效性（timeliness）特征的權重，例如：
在粗排排序過程中，每家商家將按上述表達式計算分值。在這個例子里， 商家名的文本相關性特征的分值比重是0.3，配送評價分值比重是0.2，外賣評價分值比重是0.2。
接著，在“搜索結果相關性配置”界面中，繼續添加一個精排配置，這里可以是一個非常復雜的表達式，例如：
在精排排序過程中，粗排計算得到的商家按上述表達式計算分值。這個表達式用自然語言描述是：auction_title字段上的文本相關性分值乘以3倍，如果auction_title字段的文本相關性分值大于0.1，則配送速度speed_score分值乘以1.5，否則乘以0.6。speed_score、sold_score累加后做atan數學運算，比重是0.5。各部分分值累加后作為商家的最后分值，所有商家按分值高低排序后作為最終搜索結果返回。將添加的粗排、精排配置設置為默認，搜索結果就會按照自定義的規則排序。開發者也可以直接在API或SDK中指定粗排、精排名稱，具體參考API說明文檔。
最后，在“應用詳情”配置頁中進入“搜索結果摘要”，添加需要做摘要和高亮的文本類型字段，配置摘要片段長度、片段數量、高亮標簽。這樣配置后，將會在搜索返回的商家列表中將命中的搜索關鍵詞高亮顯示。
至此，商家搜索應用實例定制基本完成，開發者可以依據上一實例介紹的方法上傳數據，并且設計和開發產品的搜索結果頁。
另外一個基于地理位置排序效果不好的問題，可以在搜索查詢串中使用distance語法實現，例如：
從上述介紹的應用實踐案例可以看出，使用OpenSearch，對搜索了解不多的開發者可以輕松上手；當數據結構復雜時，對相關性要求高的開發者也能靈活定制。
下一步規劃
為了給開發者提供更簡潔、流暢的云搜索服務體驗，我們將在以下幾方面發力。
進一步降低搜索門檻，讓開發者零成本接入。持續簡化搜索概念和產品交互流程，API、SDK兼容開源標準，并在主流CMS系統、移動開發工具中內嵌搜索插件。一些搜索外圍功能將很快開放給開發者，例如下拉提示、搜索熱詞、拼音搜索等。
增強相關性定制功能、提升定制靈活性。在粗排和精排規則中增加電商搜索、O2O地理位置搜索、圖片搜索、音視頻搜索等常見業務場景的相關性特征函數。這些特征函數將進一步提高相關性排序效果。精排規則將允許使用成熟的腳本語言（例如Lua），來編寫更加復雜的相關性排序邏輯。此外，我們正在研發查詢處理服務（QP），將支持用戶配置復雜的查詢處理插件鏈，更準確理解和處理用戶查詢。
豐富應用場景模板。在應用場景模板方面，將預制更多模板，并豐富搜索結果頁樣式，允許開發者定制樣式，并將結果頁在云端托管。再進一步，將支持開發者分享和交易自己創建的模板，傳承開發者在各個領域積累的搜索經驗。
幫助開發者盈利。通過流量盈利：我們將對接廣告系統，允許開發者通過API在自己的搜索結果頁中嵌入廣告，或者在云端托管的搜索結果頁中定制和嵌入廣告，將搜索流量轉換成廣告收益。通過數據盈利：開發者以搜索服務的方式共享數據源在線交易，其他開發者利用這些數據定制和創建自己的產品。
云搜索服務在國內外都還剛剛起步，還沒有廣泛應用。但在可預見的未來，云搜索必將像其他基礎云服務一樣，成為互聯網產品的基礎設施。我們希望能和廣大開發者一起努力，打造更為好用、更為強大的云搜索服務。
京公網安備 11010502049343號