有贊搜索中臺的探索與實踐

概述

有贊搜索中臺作為有贊企業級搜索能力複用平臺,在解決各個業務域搜索問題時是如何探索與實踐的,這個過程中有哪些心得,本文與大家一起分享探討下。

一、問題域

跟絕大多數煙囪式架構面臨的問題是相似的,業務自建搜索,獨立選型往往會遇到以下問題:

  • 技術選型單一或跟風,比如公司有業務用 ES 做搜索,那我也用,而業務對實時性的要求,準確性的要求都是不一樣的。
  • 一致性保障困難,多數據源觸發,併發場景下各自嘗試的一致性保證方案,參差不齊,有的設計很重。
  • 數據孤島,領域意識加強後會使得系統間的業務串聯變的困難,一個需求支持起來業務雙方都找不到發力點。需求支持起來耗時久,且做了各種方案妥協。
  • 可擴展性預留問題,比如數據量級,到達多少需要拆分,按什麼維度拆分,拆分後代碼還要改不,每來個搜索需求是否都需要 DDL 一下。
  • 還有很多,不贅述。

搜索中臺=企業級 搜索能力 複用平臺

再看下搜索中臺的定義,面對這些問題域,圍繞著搜索能力、可複用平臺、企業級幾個關鍵詞,將中臺抽象成了兩層。圍繞著這張圖展開,它不是標準意義上的業務架構圖,更像是做這個事情的思維架構圖,所以裡面有很多邊界沒有界定的特別清晰,只要是有助於搭建這兩層的,搜索都會主動參與建設,同時也會邀請業務方同學一起加入共建。

有贊搜索中臺的探索與實踐

二、探索篇

2.1 摺疊效應打造

摺疊效應這個詞是從羅胖精選中聽到的認知摺疊這個概念引用過來的,受益匪淺。

認知摺疊是將巨大的複雜性摺疊成簡單的解決方案。講的是在二戰時期,午餐肉的發明為美國最終取得勝利奠定了堅實的基礎。這是因為靠著午餐肉,美國大兵每日可攝取4300卡熱量,而在德國、日本軍隊中,這一數值分別為3000卡和2000卡。同時午餐肉方便士兵攜帶,不易過期腐爛,不需要生火做飯,暴露軍隊位置。相當於把整個戰區複雜關鍵的戰士口糧問題摺疊成了一盒小小的午餐肉罐頭。

摺疊效應無處不在,我們敲擊的鍵盤,跑的代碼,開的汽車,都是無數前輩為我們摺疊好的,於是我們找到了搜索中臺的方向。

將搜索完整鏈路的複雜性摺疊成一個簡單完整的搜索產品,讓業務方直擊搜索需求本身,無需費心搜索實現。

搜索的複雜度可以抽象為索引管理,索引寫,索引讀三個方面,我們簡單展開下。

2.2 索引管理

索引設計

有必要將索引設計作為搜索的關鍵環節,磨刀不誤砍柴工,一個好的設計,會事半功倍的效果。

如果手裡只有一把錘子,那麼看什麼都像釘子。

  • 索引選型設計 MYSQL HBASE KV ES TIDB
    • MYSQL 實時性要求高 聯合索引可以 cover 的場景
    • HBASE 正排查詢,大批量in查詢
    • KV 統計接口,實時性要求不那麼高的,優先從 KV 中取
    • ES 模糊搜索,多條件查詢進 ES
    • TIDB 聯合索引查詢,海量數據歸檔自動拆分進 TIDB
    • 其他索引存儲選型
  • 索引拆分設計
    • 增量存量是多少,是否需要拆索引?
    • 按什麼維度拆,按時間或者 id ?
    • 拆分了之後還有數據熱點傾斜要如何處理?
  • 索引可擴展性設計
    • 每次來需求都需要索引 DDL 刷數據支持麼?
    • 用戶自定義搜索需求可以支持麼?

2.3 索引寫

配置化同步能力

圍繞配置化同步能力將整個同步抽象成input-filter-output 三步:

  • input 索引數據源層 索引數據來自哪裡,一般都是消息 可以是 binlog 消息,也可以是二次加工的業務消息。
  • filter 索引數據加工層,可以聯查業務表,調用業務 api 構建索引數據。
  • output 索引數據輸出層,比如是用的ES MONGODB MYSQL HBASE 等存儲,配置輸出即可。
有贊搜索中臺的探索與實踐

增量寫

這裡簡單提下同步的擴展點設計,與業務解耦,業務同學不需要關心同步細節,搜索中臺又可以不涉及業務太深,通過擴展點方式來解耦。

有贊搜索中臺的探索與實踐

離線寫

離線寫這塊主要有一點就是注意版本覆蓋問題,避免版本亂序。

  • 初始數據刷入一次場景,這種離線選擇 create 操作即可,如果增量有數據則被過濾掉。
  • 例行刷數據指標場景,走批量更新版本加1,如果有離線覆蓋增量風險,可以將增量版本步長設置1000或者更大即可,看業務需求。
有贊搜索中臺的探索與實踐

一致性保證

一致性保證是同步的關鍵,做到柔性最終一致。

有贊搜索中臺的探索與實踐

2.4 索引讀

配置化路由

索引為什麼需要配置化路由?

如果手裡只有一把錘子,那麼看什麼都像釘子。

再細品下這句話,搜索絕不只可能是 MYSQL 或者 ES ,之前跟業務方聊也知道很多場景可能不適合 MYSQL 或者 ES ,不過為了代碼的整潔性,不希望寫一堆 if-else ,再有就是對這些琳琅滿目的存儲的特性很難全面掌握,有明確的區分該用哪個。於是我們搭建了LOS(League Of Search 搜索聯盟)層,來配置化收攏路由策略。

有贊搜索中臺的探索與實踐

通用DSL語言

這個不用贅述,由於不同存儲的 sql 語法是不同的,如果讓業務前置感知就侵入太大了,而且同一存儲的不同版本有時候變動也較大,業務方兼容不實際。

搜索流程編排

不同業務對搜索流程的訴求是不一樣的,舉個例子普通的查詢基本就是一次粗排就可以了,有的就需要改寫加精排,有的需要組裝詳情返回,有的需要精排後直接返回,就需要用到流程引擎來編排。

有贊搜索中臺的探索與實踐

2.5 通用監控能力

有贊搜索中臺的探索與實踐

哪一種搜索場景是業務方的top場景,產品需求也可以通過這個指標來衡量對應的價值,優化也可以針對對應的場景來有的放矢的去執行,讓數據賦能業務。

三、實踐篇

3.1 協同效應飛輪打造

協同效應這個詞是曾鳴教授在全球物流峰會上提出的概念。很有共鳴。

網絡協同是一種合作的機制,它產生的就是協同網絡,而協同網絡創造的價值,就是協同效應。

結合羅胖跨年演講中介紹的信用飛輪,這裡把這兩個概念合一,更有助於描述搜索中臺目前的落地實踐策略。

有贊搜索中臺的探索與實踐

3.2 領域解耦

營銷商品搜索連通

一個比較典型的例子,優惠券湊單按價格、銷量、好評排序,營銷團隊不希望耦合商品域數據,商品團隊更不希望耦合營銷域數據,所以一個折中的技術方案是營銷保存了活動與商品的對應關係,優惠券可用商品先查一次營銷,拿到大批量goodsId後再去商品裡做相關排序。

有贊搜索中臺的探索與實踐

而這個商品和營銷都比較糾結的事情,由搜索中臺來做這個橋樑協同,大家都還是專注在自己域的數據中,通過消息解耦,由中臺通過配置化同步再同步過程中將數據連接構建 ic+ump 索引,縮短搜索鏈路,提升搜索體驗。

通用跨域連接搜索方案

共享業務協同飛輪一旦轉起來,那麼對上游業務的賦能會更加迅速。

比如CPS商品搜索,場景主播選品,進行分傭商品搜索,按分佣金額大於某一值的查詢。通過在同步過程中完成數據互聯,業務方無感知實現數據互聯。

有贊搜索中臺的探索與實踐

3.3 業務滋養中臺

搜索中臺設計之初,想到的是些通用基礎能力,上文已經介紹,當賦能業務方時候發現還是會遇到各種各樣始料未及的問題,通過解決這些通用問題的過程中,讓中臺又沉澱了不少通用能力,更好的賦能業務方,下面簡單介紹下索引管理的三板斧。

索引重建產品化

在賦能業務階段,發現很多索引的分片設置少了,或者是單索引大了需要拆分,再有就是需要遷移集群,都會涉及到索引重建,這個普世需求,而索引數據重建,耗時又風險大,於是發起了索引重建產品化項目,目前有贊搜索中臺可以做到百萬級別索引秒級重建,千萬級索引分鐘級重建,億級索引小時級重建,百億級索引半天內重建完,且數據一致性得到最終保證,極大的提升了業務迭代及集群索引管理速度,具體設計會在後面搜索中臺系列技術博文中會詳細介紹。

為了致敬認知摺疊裡提到的午餐肉案例,我們把這個索引快速重建項目命名為 spam (午餐肉)。

索引無感知重建

在賦能業務索引重建過程中發現業務方的同步配置有自建代碼實現的,有通過配置化實現的,多種場景,配置化同步的還好,只要複製下同步任務,寫到重建新索引中,增量數據同步就可以完成了,但是對於自建同步的業務來說,這個改造的侵入成本就很大,很多散落的代碼同時寫一個索引中,會有大量的代碼複製成本,所以中臺就在想能否可以在不侵入業務代碼中,就可以做到索引重建。

念念不忘 必有迴響。

搜索中臺通過監聽自建索引雙機房同步的消息中,做了一層配置化路由雙寫,來做到索引無感知重建。

vip索引配置化遷移

有了上面兩板斧,一般業務索引的常見問題都已經解了,不過發現仍然有熱點商家問題導致整個集群不穩,於是在索引無感知重建基礎上加了層vip路由,在活動期間,將 vip 商家的流量路由到活動集群中,活動結束後流量可以再配置化遷移回來,極大的提升了系統的穩定性。

3.4 中臺賦能業務

當業務協同飛輪轉起來後,搜索中臺收集到了更多業務場景的痛點,比如交易訂單從單店上升到總店 MU 管理訂單搜索要怎麼支持,商品搜索也有類似需求,營銷搜索也有總店設定優惠券,然後下發到各個門店使用中,都是一種裂變搜索的場景。

再比如數據歸檔搜索,當數據量級大到一定程度,勢必要進行歸檔,歸檔方案的選型,隨著各個業務量級和對歸檔數據搜索的訴求,痛點,集成後,中臺產出通用解決方案,做到無感知數據歸檔,搜索集成,配置化路由到對應索引中。

心得

這裡簡單談幾點心得,能夠參與到有贊搜索中臺的搭建從無到有是蠻幸運的,過程中有很多兄弟團隊的支持,使得整個中臺的初步落地還算順利,回顧這期間有些關鍵節點感悟。

  • 中臺不是某一門技術,更像是一種組織架構和思維架構,需要聯動,需要協同。
  • 關鍵抓手牢牢抓住,一口吃不了一個胖子,能解決大部分能力複用,服務好核心業務方就很不錯了
  • 不過度設計,貼著業務需求做能力搭建,方便快速落地。

展望

搜索中臺剛剛成立不到一年,很多場景和設定還相對初級,對業務方的賦能還有很大的提升空間,誠邀搜索專家同學加入一起共建有贊搜索中臺大業。簡歷直通車 [email protected]

總結

本文簡單回顧了下有贊搜索中臺在賦能業務搜索過程中的探索與實踐,業務場景可能不同,不過這套摺疊+協同的思維框架模型是相似的,這裡希望引用下《企業IT架構轉型之道-阿里中臺戰略思想與架構實戰》鍾華老師的話作為結語,受益匪淺。我們從小學開始學習很多基礎知識,更多的是知識點的掌握;隨著我們掌握知識點的增多,我們開始有意識地將一些知識點組合在一起,解決一些複雜的問題,關聯這些知識點的過程實際上是將這些相關的知識點串成了知識線;隨著在知識領域的繼續積累,越來越多知識線的匯聚,我們有機會更全面地瞭解到這一知識領域(知識面),從而構建了對這一領域自身的知識體系,而這時的你相信已經成為這個領域的專家。

作者:王爺

團隊:有贊搜索中臺


分享到:


相關文章: