降本提效，貝殼搜索推薦架構統一之路

1、貝殼搜索推薦使用場景

1. 人、房、客匹配鏈接

貝殼爲你們提供了找房、買房的一整套服務。因爲買房是一個很是重要且複雜的事情，它的流程很長，不可能像買書、買衣服同樣，線上下單支付就完成了。買房的過程通常都會有一個線下的經紀人蔘與，就是咱們俗稱的「中介」。
因此貝殼的主要業務場景是人、房、客三者的鏈接匹配。人是指經紀人，房是房子，客就是咱們的 C 端用戶。
這三者的鏈接和匹配都是搜索的幾個核心場景，好比「人客」的鏈接，咱們有客源檢索系統（經紀人找客戶）和經紀人檢索系統（客戶找經紀人）。
而「人房」鏈接主要對應 B 端的房源搜索，就是提供給經紀人使用的房源搜索。好比當你們去線下的鏈家門店，告訴經紀人想要什麼樣的房子後，經紀人通常就會經過 B 端房源搜索系統幫你到合適的房子。


B 端搜索比 C 端搜索更復雜一些，是專門給有經驗的經紀人使用的，是另外一套搜索系統，包括新房、二手房、租房、鏈家直營、海外等各場景的B端房源檢索，這些都屬於「人房」鏈接。
「房客」匹配就是你們比較熟悉的 C 端的搜索推薦了。好比你們不管是上貝殼APP，仍是PC站或者小程序，都會常常見到的二手房、新房、租房、海外、地圖找房等各頻道的搜索。以及各類首頁推薦、相關推薦、猜你喜歡等推薦頁面。
對咱們來講，C 端目前是更核心的場景，由於 C 端的搜索推薦會直接影響到公司的線上商機轉化率，須要咱們持續不斷的去優化搜索推薦的效果，提高點擊率、轉化率等，因此後面的介紹會主要圍繞 C 端展開。
爲了更好的支撐這些核心業務場景，做爲搜索推薦平臺而言，咱們主要關注三個點：效率、成本和穩定性。效率包括「房客」匹配效率和研發迭代效率，成本包括人員成本和機器成本，穩定便是服務須要保證99.99%以上的高可用性。

2. 場景示例

下圖就是你們能夠在貝殼 APP 上看到的，搜索推薦的常見場景：貝殼 APP 首頁中的主搜框、二手房、新房、租房、海外、必看好房、商業辦公、查成交、找小區、地圖找房等等。
隨手進入一個頻道，好比二手房頻道，在上面輸入本身想要的小區名、商圈名等等，就會返回給你想要的結果。

若是不進入搜索頻道，在首頁往下滑的話，會進入到推薦的首頁。不須要任何關鍵詞，直接給你推薦你可能感興趣的小區、房子等等。

3. 場景概覽

做爲平臺，除了核心業務，咱們還賦能了不少其餘場景，好比搜索平臺當前一共賦能了 500 多個場景。
C端搜索包括上面提到的新二租等，目前承接了貝殼 60% 的線上商機。B 端的搜索包括房源搜索、客源搜索、裝修搜索等等。除此以外，還支持了不少內部其餘事業部須要用到搜索的業務，好比籤中平臺、交易平臺、人事行政等等。
推薦方面，目前賦能了 300 多個場景，主要是在C端，一樣包括二手房、新房、租賃等等，承接了 15% 的線上商機。場景主要有首頁的推薦、相關推薦、猜你喜歡、feed 流等等。

和不少公司同樣，在貝殼，搜索和推薦以前是分屬於兩個不一樣的團隊各自發展的，總體代碼架構差別都很大，因此我下面會先分別介紹兩個平臺各自的演進過程，而後再介紹搜索推薦架構統一的過程。

2、貝殼搜索平臺架構演進

貝殼搜索平臺主要經歷了四個階段：搜索服務、搜索平臺、搜索雲平臺和搜索中臺。
2017 年時還只是一個簡單的搜索服務，主要用於鏈家二手房的搜索。隨着公司業務的快速發展，不少其餘業務線也都須要搜索能力。因而本着不重複造輪子的原則，咱們把搜索服務進行平臺化，開放它的能力，對各業務進行賦能，從而成爲了搜索平臺。

搜索平臺到 2018 年的時候，已經接入了 100 多個業務，日均有 5 個億的流量。
成爲搜索平臺以後，咱們發現 接入的 業務越接越多， 每接一個業務都須要佔用必定的時間，形成 你們大部分 的時間 都花在業務 對接 上， 沒有多少時間能夠用於自己平臺的技術迭代，久而久之，將很難有技術提高和沉澱，不管是對平臺仍是團隊的同窗，都是極爲不利的。
因此咱們在2019年的時候，把原來的搜索平臺 的 整個業務對接 部分 ，進行了流程化、線上化、產品化、自助化， 進而升級爲 搜索雲平臺。
到2019 年時，整個搜索雲平臺接入了 300 多個業務，日均 10 億流量。因爲有了搜索雲平臺，業務方能夠經過雲平臺在線上自助完成絕大部分的業務接入和上線工做，釋放咱們大部分搜索研發人力，因此咱們能夠將更多研發資源投入到搜索效果的優化和穩定性優化等方面。
因而在2020 年的時候，咱們的搜索雲平臺進一步升級爲搜索中臺，到目前爲止咱們已經接入了500多個業務，日均20億流量。能夠看到咱們整個系統的架構是隨着業務的發展不斷的去迭代進化的。

1. 第一階段，簡單的搜索服務

搜索服務最開始的架構很是簡單，底層使用的是 SolrCloud，上層是兩個服務：寫入服務和查詢服務。
寫入服務提供全量更新數據和增量更新數據的功能，查詢服務有簡單的 Query 解析、召回服務和排序服務，上層是一個統一的 API 接口，提供寫的接口和讀的接口，還有配置變動的接口，是一個很是簡單的搜索服務。
           

2. 平臺階段

升級爲平臺以後，咱們爲了下降業務接入的成本，快速對接業務數據，在數據流這塊有一個大的改進。能夠直接監聽業務方的數據變動，經過MySQL binglog同步到搜索平臺。底層的引擎也升級爲了 ES 集羣。
查詢服務作了一個拆分，上層是帶效果的查詢服務，包括Query解析、召回、排序在內的SearchService，下層是一個基礎的查詢服務BasicSearch，直接和ES 集羣對接，作一些基礎的召回。
一些不須要特殊召回排序策略的業務能夠直接查詢BasicSearch。上層會有統一的網關，作流量收口，統一對全部的業務方的請求進行鑑權，而後分發到下層各個服務。                      前面提到，成爲搜索平臺後接入的業務愈來愈多，致使RD 有大量的時間都花在業務接入上。
由於早期一個業務接入有不少步驟，好比須要先發郵件作需求溝通，而後再發郵件作需求的排期，RD 進行開發聯調，而後發郵件說明聯調經過，而後 QA 聯調，發郵件QA聯調測試經過，最後才能進行業務上線。                      能夠看到這整個流程很是繁瑣，從最開始的提需求到最後的上線須要通過8個步驟，當業務多了以後，若是老是走這種線下人工對接的方式，效率是很是低下的。

3. 搜索雲平臺階段

爲了改變這個情況，咱們開發了搜索雲平臺，搜索雲平臺的核心思路，是把整個業務對接的流程進行線上化、產品化、自助化。以前 RD 聯調經過以後還須要手動修改 QA 測試環境的配置，QA 聯調經過再去修改線上環境的配置。
這裏會有兩個問題，一是總體效率低下，另外因爲大部分是人工配置上線，因此很容易出錯，從而形成線上故障。
爲了解決這個問題，咱們搜索雲平臺的實現方案是，把配置統一放到 Mongo 中，聯調經過後能夠一鍵把 RD 環境的配置同步到 QA 環境。QA驗證經過以後，再一鍵同步到線上環境，省去了中間人工修改測試環境配置和線上環境配置的整個過程，從而大大提升了效率。
其次是整個業務接入功能的平臺化。上層咱們開發了各個可視化模塊，包括分詞效果的可視化：能夠直接看到不一樣分詞器的分詞效果，從而選擇本身想要的分詞器。數據流的可視化：能夠看到數據流的同步狀況，包括性能如何，還有多少數據未同步等等。接下來是 SLA 可視化、數據變動記錄、配置變動記錄等等。
下面是各模塊耗時統計，包括業務 RD 耗時、業務 QA 耗時、搜索 RD 耗時、搜索 QA 耗時和長耗時主動干預。
整個搜索雲平臺就是爲了提高業務接入的速度，經過耗時統計能夠方便的看出耗時比較長的是哪一個環節，從而針對性去優化該環節，就像慢查詢優化同樣。
平臺管理方面第一步是打通數據流的依賴，而後是自助接入和自助運維：包括索引管理、集羣管理、分詞管理、服務複製等功能。
這些功能大大提升了RD的接入效率和運維效率，因而咱們進一步再去提升QA的測試效率，開發了自助測試和自動審覈上線等功能。
底層是監控報警平臺，包括全鏈路追蹤平臺、監控平臺、報警平臺和值班管理。以下是咱們整個搜索雲平臺的功能模塊圖。

舉例來講，業務方經過平臺填寫需求而後申請接入，到搜索 RD 這邊根據需求會填一些對應的配置，以後業務方能夠本身進一步完善配置，好比數據源的地址，而後會自動同步到 ES 集羣中。
業務方還能夠經過平臺建立本身的表結構，指定有哪些字段，哪些字段須要分詞、哪些須要建索引等。經過配置監聽數據源、回調地址、索引結構後，再進行數據檢驗，最後就能夠配置生效，返回給業務對應的搜索接口，業務方就能夠本身去聯調了，聯調經過開發環境、測試環境、線上環境同步配置後，整個流程就走完了。在順利的狀況下，一個業務從接入到上線最快可能半天就完成了。
最終經過雲平臺的上線，咱們總體的業務接入效率提高了 3 倍，以前平均下來一個業務接入須要 9 天，如今只要 3 天就夠了，搜索 RD 人效提高了 6 倍。以前是經過人工變動上限，如今是經過平臺自動化同步，故障率也下降了 60%。
經過這些效率的提高，咱們釋放了大量的研發人力，這些人力就能夠投入到效果優化和穩定性優化上，從而進一步升級爲搜索中臺。                       

4. 搜索中臺

以下是搜索中臺的架構圖，上層的網關和以前的同樣，負責統一的鑑權、分發、限流、熔斷、降級。數據流會經過事件構造、數據構造等模塊寫入分佈式搜索引擎。
查詢層會經過中控模塊進行各個服務的調用，進行 Query 的糾錯、改寫、分類和理解。而後調用召回，召回模塊會根據召回策略或召回模型進行底層數據的召回。而後再調用排序模塊，通過實時排序模型的精排後將最終結果返回給用戶。
同時咱們進一步完善了統一的服務治理平臺：包括註冊中心、配置中心、負載均衡、消息總線、熔斷降級、鏈路追蹤、監控報警和服務編排等模塊，最終造成了咱們的搜索中臺。                        

3、貝殼推薦平臺的架構演進

貝殼推薦平臺的架構演進也經歷了四個大的迭代，最先期就是簡單的基於內容和規則的推薦引擎，後面進一步增長了用戶畫像和協同過濾進行個性化推薦，再經過實時計算和實時模型實現實時個性化推薦，最後爲了提高業務接入和迭代效率，推薦平臺作了一個大的升級重構，支持業務配置化接入，最終升級爲智能推薦平臺。                          

1. 基於內容的推薦

早期基於內容的推薦很是簡單，底層經過對一些房源數據（二手房源、租賃房源等等）進行離線計算，使用Content-based推薦算法，直接離線算出類似房源、熱門房源等，而後寫入 Redis。
在線推薦服務再從 Redis 中查出離線計算好的可能感興趣的房源，而後直接返回給用戶進行推薦。                      

2. 實時個性化推薦

在內容推薦的基礎上，咱們引入房源特徵、實時用戶畫像和實時用戶行爲記錄，升級爲實時個性化推薦。
個性化推薦底層新增經紀人做業數據、用戶行爲日誌等數據，而後經過離線計算進行數據清洗和特徵工程，生成房源特徵和用戶畫像。
再經過協同過濾算法，進行協同過濾推薦，而後把這些數據批量更新到在線存儲引擎，包括離線計算好的召回數據、特徵池和過濾集等。                        和以前的架構相似，各業務線都有獨立的推薦服務，直接查詢在線存儲獲得召回數據和特徵數據等，而後根據策略計算後返回給用戶。
業務系統會通過 AB 實驗平臺對流量進行分流，進行效果迭代實驗。同時，業務系統和推薦服務都會將實時埋點日誌迴流到實時計算服務和離線數倉中。從而實時更新召回數據和特徵實現實時個性化推薦。

3. 智能平臺推薦

爲了提高業務接入效率和效果迭代效率，實時個性化推薦進一步升級迭代，將在線推薦服務進行拆分重構，下層離線計算和實時計算基本不變。
重構的目的主要用於解決早期的「煙囪模式」，再也不每一個業務場景對應一個獨立的推薦服務，而是用同一套推薦服務支撐上層的全部業務，新接業務直接複用上線，而非從新開發啓動一個服務，從而極大的提高效率。                      爲了達成這個目的，咱們對整個推薦服務作了拆分，進行邏輯分層，分爲應用層、計算層、數據層和模型層。
應用層主要對外提供API接口，以及處理簡單的業務規則和配置管理。計算層包含推薦的幾個核心流程，如召回、融合、排序和過濾，會分別調用數據層和模型層。數據層統一對下層的在線存儲系統進行基礎的數據查詢。模型層進行在線特徵工程後會調用模型服務進行在線預測。計算層拿到數據層返回的結果後進行策略融合，而後調用模型層進行模型精排，最終返回給業務系統。

4、貝殼搜索推薦架構統一

咱們回憶一下搜索平臺和推薦平臺的大致架構，能夠發現他們有不少地方是相通或類似的。咱們能夠先對比一下搜索系統和推薦系統的相同點和不一樣點。

1. 搜索推薦對比

先看相同的地方，首先搜索推薦兩個系統的目的都是爲了解決信息過載的問題，而且從貝殼的業務場景來看目的也是相同的，都是爲了提高線上的商機轉化率，進行房客的匹配。
從流程來看，兩者都包含了幾個核心模塊：召回融合、模型排序、業務重排和推薦理由。
數據上，特別是貝殼的搜索推薦，都會用到這幾份核心的數據：房源詳情、房源特徵、用戶畫像、用戶行爲特徵等等。算法模型也是能夠複用的，好比咱們如今使用的 WDL 和 DeepFM模型，均可以用於搜索推薦兩種場景。
平臺工具一樣是能夠複用的，搜索和推薦都會用到 AB 實驗平臺、機器學習平臺、模型管理平臺和效果分析平臺等。           
再看不一樣點，從行爲上來看，搜索是很是主動的行爲，推薦是被動的。從意圖上來看，搜索的意圖通常都很明確，而推薦只須要有模糊的偏好就能夠。Query 是顯而易見的，搜索大部分場景都會有 Query，可是推薦沒有。
搜索對個性化要求是比較弱的，推薦是很是強的根據用戶畫像進行個性化推薦的需求。多樣性一樣搜索會比較弱，推薦會比較強。搜索是強相關的，推薦相關性不須要太強，會但願能夠推出一些「驚喜」。
搜索的數據實時性要求是特別高的，數據要求秒級更新，好比一個房子已經賣出後就不能再被搜出來了。而推薦的數據不少都是天級更新的。還有一個不一樣點是已讀過濾，推薦基本是讀過的就不會再推薦了，可是搜索就不會，讀過也會展示。

2. 爲何要作架構統一

上面相同和不一樣的對比也部分解釋了咱們爲何要作架構統一，這裏我再具體說明一下。
第一個緣由就是咱們前面介紹的，他們是徹底能夠統一的，從總體的目的、功能、流程、架構上都是相通的、類似的。
第二個緣由是咱們統一的核心目的：降本提效，也便是本次分享的標題。
既然它的目的、流程、功能架構都是相通類似的，那咱們用同一套架構、同一個套代碼來完成確定是能夠提高咱們總體效率的。咱們的工程和算法人員均可以複用。代碼、數據和特徵模型也均可以複用，從而下降開發和維護成本。
以前因爲是兩套徹底獨立的系統，搜索團隊有本身的工程研發和算法研發，推薦團隊也有本身的工程和算法，各自維護本身的系統，這樣確定是會有不少重複工做在裏面。統一以後，兩邊都須要用到的一些平臺、工具也均可以複用了，避免重複造輪子。
             
以上三點經過架構統一均可以直接解決，後面兩點是咱們但願在統一的過程當中優化的。好比常規策略的效果迭代能夠支持界面配置上線，簡化流程，下降上線成本。
其次須要把召回、排序、重排、理由各模塊進行解耦，支持分層實驗，能夠專人專項，各司其職，好比有的人專門負責優化召回，有的人專門負責優化排序，進一步提高總體的研發效率。
因此總體而言，咱們核心目的就是但願作到搜索推薦架構統一後，達成一個1+1大於2的效果，在各方面都下降成本，提高效率。
其次還有一些附帶的好處，好比說提高總體的穩定性。由於搜索相對而言穩定性的要求會比推薦更高，而且整個搜索的流量比推薦大不少，因此以前搜索團隊的服務治理更加完善一些，有整套的服務治理體系，推薦這邊偏少一些，完成架構統一後，推薦能夠直接複用以前搜索的整套服務治理體系。
另外還能夠進一步的提高性能。以前貝殼推薦系統的召回是基於搜索的，推薦召回會直接調用搜索的網關，而後搜索服務再去調用底層引擎，好比說 ES 等等，因此會通過好幾回的網絡傳輸。
當咱們把架構統一以後，就不須要區分搜索和推薦了，推薦的服務能夠和搜索服務同樣，直接查詢底層 ES，減小網絡調用，從而提高推薦系統的性能。

3. 架構統一方案

                      上圖是搜索推薦架構統一以後的總體架構圖。其實和以前的架構類似，但把搜索和推薦作了一個集成。上層仍是各個業務線：二手房、新房、海外、租賃等等各業務線調用統一的網關，進行流量分發、鑑權、熔斷、限流、降級等，而後調用底層各服務。
前面提到的搜索雲平臺統一進行各業務接入，以及總體的配置化管理和上線。而後會複用以前搜索整套服務治理體系：註冊中心、配置中心等等。數據流會對業務方數據變動進行監聽，實時同步數據到在線存儲引擎中。
咱們作的主要的大的重構是在查詢層，對原搜索和推薦系統的各模塊進行了統一的整合。
最新的查詢層主要分爲六個核心模塊，請求一開始會經過中控模塊作參數校驗、策略調度、緩存和兜底，而後中控會去調用下層各模塊，先是意圖解析模塊（搜索使用，推薦不須要），拿到意圖解析的結果後再去調用召回模塊，召回的時候會先獲取一些用戶畫像和特徵，而後進行多路召回和融合過濾，返回給中控。
中控獲得召回的數據後調用排序，排序包括粗排和精排，接下來是重排，再以後調用理由模塊，補充推薦理由，好比「滿五惟一」，「近地鐵」等等。拿到理由以後就會最終反饋給業務方，完成整個搜索推薦調用的過程。
中控負責各個模塊的調度，好比推薦能夠直接調用召回，而後排序、重排等。
同時在存儲方面，咱們增長了幾個新的引擎能力，以前只有文本檢索的 ES 引擎，後面增長了向量檢索引擎和圖檢索引擎。
剩下的模塊和以前推薦和搜索都是同樣的，一樣會實時迴流業務方的埋點日誌而後進行實時計算和離線計算。以上就是咱們架構統一以後的搜索推薦新架構。
介紹一下幾個比較核心的服務：

（1）中控服務

中控服務的設計原則是但願它儘可能不要有業務邏輯，經過減小迭代最大化的保證中控服務的穩定性。
咱們看到中控的核心是決定下層各個模塊的調度，中控會對下游各個模塊作降級，因此下游各個模塊的異常都不會影響總體搜索和推薦的請求，但若是中控出了問題可能就會對線上的穩定性有影響，因此咱們須要儘可能保證中控服務的穩定性。
中控主要負責參數校驗、調度、緩存、降級等功能。好比推薦不須要走 NLU 就能夠直接跳過這個模塊，還有一些場景不須要走重排或理由也均可以經過中控的配置直接跳過。                      其次中控能夠對一些對模塊進行緩存，好比 NLU 和理由結果均可以緩存。
最後中控最大的做用就是降級，任何下游服務超時或異常都不會形成業務方的查詢異常，各個模塊都有默認超時時間設置，但同時會實時計算剩餘時間，各模塊的實際超時時間是該模塊默認超時時間和剩餘時間的最小值。
好比一個常規的調用鏈，開始調用意圖解析，再調用召回，再反饋給業務方。假設咱們調完重排要調用理由的時候，發現理由服務掛掉或者響應超時，中控則會跳過理由模塊直接返回，至關因而降級返回。
若是召回模塊超時，中控也會跳過召回模塊，直接訪問 ES 或 Redis，而後再拿這些結果去走後續的流程，至關於跳過整個召回邏輯直接拿基礎引擎返回的召回數據傳給排序走後面的流程。
最壞的狀況下若是底層的存儲引擎都掛掉的話，中控會直接去查 Redis 的緩存數據或者默認數據而後返回給用戶。
下一個模塊的超時時間是根據上一個調用超時的時間決定的，業務方通常設置的超時時間爲 1 秒鐘，但實際上咱們的平響是 50ms 左右。
好比在異常狀況下咱們調重排的時候發現已經花了 950ms，因爲只剩下50ms，因此再去調理由的時候，理由模塊的超時時間會被實時設置爲 50ms，而忽略其默認的超時時間。

（2）召回服務

召回服務包括請求的構造，拿到 NLU 結果後會對請求進行糾錯和改寫，而後獲取用戶畫像、房源特徵等，再執行多路召回、融合和過濾。                      文本召回會去調 Elasticsearch，策略召回會去查 Redis，向量召回查 Milvus，商業召回會去調用業務方的接口，過濾召回是推薦特有的，好比一些已讀過濾。在多路召回以後會作一個總體的融合過濾，而後返回給中控走下一個流程。

（3）重排服務

重排服務涉及到很是多的業務規則，每一個業務線都不同，有一些是能夠複用的，有一些是不能複用的，好比強插、置頂、混排等等。
爲了便利的組合複用這些規則邏輯，重排實現了workflow的工做流機制。例如默認配置中會有去重、融合、計算得分、按字段排序等默認規則，而「opt-in」能夠增長規則，「opt-out」能夠去除規則。
           經過這個工做流機制，咱們不少方法均可以複用，經過簡單的配置決定走哪些規則，不走哪些規則，這樣絕大多數場景均可以經過配置化的上線去知足。
其實當前咱們的架構統一還在進行中，由於咱們的服務比較多，但已經取得了一些階段性成果，至少從人效上已經提了一倍。
原來搜索工程是六我的，推薦四我的，一共十我的，如今合併後只須要五我的。效果迭代效率上也有三倍的提高，以前一些策略規則調整，從開發到測試到上線平均須要十天，如今經過配置化上線基本三天就夠了。           

5、將來規劃

將來規劃主要有兩點。                         第一，沉澱通用策略模型組合，造成相似「策略套餐」，非核心業務能夠自主選擇，快速複用。
由於如今無論是算法仍是工程，咱們的資源都仍是有限的，咱們如今的業務量很大，接了成百上千個，不可能每個業務都作優化。
咱們但願能夠經過沉澱一些通用的策略模型組合，把它打包成一個相似套餐的形式，一些非核心的業務就能夠自主選擇套餐複用配置好的模型和算法，進一步提高總體的優化效率。
第二，咱們但願能夠打造一個一站式的效果優化平臺。
咱們前面提到的不少系統，好比雲平臺、實驗平臺、模型管理平臺等，目前都比較分散，而且有些平臺工具是已經開發完善的，但有一些是還未開發完成的，好比樣本管理、特徵管理、實驗管等。
咱們後續會把各個平臺和工具統一完善起來，同時所有打通，而後統一集成到一站式的效果優化平臺中，包含業務管理、效果指標、機器學習、效果預測、流量實驗、干預運營等各模塊，從而進一步提高效果優化迭代的效率。

6、Q&A

Q：問下老師，雲平臺如何監控的，都監控了哪些指標？ A： 咱們雲平臺監控的指標很是多，好比數據流方面，包括各模塊寫入耗時、寫入量、寫入QPS、實時率、丟失率等。查詢方面：總體查詢耗時、各模塊查詢耗時、平均耗時、999分位耗時、9999分位耗時、查詢QPS、總體流量的大小、總體流量穩定性、各狀態碼（200、400、49九、5XX）數量、比率等等。還包括慢查詢的監控，好比超過100ms的數量、超過500ms的數量、比率等等。
以上主要是性能和穩定性的監控，還有一些效果的監控指標，好比點擊率、曝光率和商機轉化率等等。 這些監控有的是經過日誌監控，有的是指標上報監控，使用了各類監控系統。
Q：自動編輯生成數據結構，會不會引發結構不合理的狀況？怎麼避免？ A：其實會有，這個咱們遇到過，其實剛纔能夠看到咱們雲平臺有一個數據接口自動校驗，早前咱們沒有那個功能，常常遇到用戶本身編輯、本身填寫表結構，什麼字段、什麼類型。
由於他編輯可能出錯，當咱們拉數據的時候，會發現他的數據源 MySQL中的字段結構和他編輯的是不同的，有時是多了一個字段，有時是少了，有時表結構裏寫的是字符串類型其實是數字類型。常常會出現這樣的問題，而後發現數據導不進去、同步不了，致使數據阻塞。
因此咱們後來增長了數據接口的自動校驗，他填完以後，系統會立刻他的拉取少許數據，幾百條、幾千條作驗證，拉出來的數據和表徹底一致纔可以進行下一步。
Q：老師，這個鏈路追蹤是如何作的，是全鏈路嗎？ A： 咱們如今是全鏈路追蹤，基於ES 的 APM作的。你們若是瞭解的話就會知道，它能夠自動的收集各個模塊的耗時，最終放到一個 ES 日誌集羣中，而後能夠界面分析各個環節的耗時、總體的耗時等等。
Q：問一下老師，如何實現推薦多路並行召回的？ A： 多路並行召回主要經過線程池並行的發送多個請求或查詢多個搜索引擎，好比向量引擎、文本引擎等，拿到多條召回流的結果後再跟進融合策略進行多路融合。
Q：網關是 openresty+lua 作？ A： 網關咱們用的是 Zuul，Spring Cloud 中的網關組件。
Q：老師，搜索和推薦質量保證方面，有沒有什麼好辦法？ A： 搜索推薦質量保證，這個指的是什麼保證？穩定性剛纔已經提到，若是是穩定性方面，咱們確實作了不少，剛纔提到，有整套的服務治理穩定性保障體系。其次咱們的服務確定是分佈式多機部署的，單個服務掛掉了，對總體服務沒有任何影響，同時作很完善的限流熔斷降級機制。包括咱們底層的存儲引擎，也都是雙機房互備部署的。
咱們也搭建了完善的監控報警系統，好比49九、5XX，超過千分之一就會短信或者電話報警。效果指標一樣有監控報警，好比點擊率轉化率忽然大幅度下降，也會及時報警，而後定位分析。
一方面是完善監控報警，另外，從一開始設計的時候，就要考慮這方面的問題，好比剛纔說的中控降級，就是在設計的時候就充分考慮下層每個服務掛掉的時候咱們該怎麼辦？咱們要作到的就是任何一個服務掛掉，都不會影響總體的查詢。其次還會進行季度性的線上壓測，及時發現一些線上隱患，摸清線上實際的吞吐量。
Q：老師，數據中臺是必須的嗎？這個如何取捨？ A： 其實數據中臺跟咱們今天講的關係不是很大，但既然同窗問到，我我的以爲不是必須的，確定看公司場景，若是小公司數據沒有那麼多，確定不須要建數據中臺，若是是大公司數據很是多，須要各部門打通的話，就可能須要作數據中臺。
Q：底層服務器是本身構建仍是使用公有云，人效提升之後，你們還要加班麼？ A： 如今貝殼是既有自建機房，又有騰訊雲的機房。咱們如今是雙機房備份的。最壞的狀況下，有一個機房掛了，對業務不會有太大影響，能夠實時的切換到另外一個機房去。
而後是否須要加班，加班這個東西跟人效關係不大，若是業務需求比較着急的話，通常仍是須要加班的。若是不是很着急，你們按常規迭代，基本上加班不會太多。
人效提高以後，你們就能夠去作更多的事情，探索更新的技術。好比咱們總體人效提高以後，原來須要十我的作的事情，如今只須要五我的就夠了，騰出來的五我的就能夠作新技術方向的探索，好比說新的向量引擎的探索，新的圖數據庫引擎，包括新的模型算法的研究等等，實際上就是盤子更大，作的事情更多，固然產出也會更多。
Q：監控都是本身開發的嗎 有第三方廠商的產品嗎？ A：都有吧，有一些開源的組件，也有本身研發的，還有一些公司其餘平臺提供的統一的監控系統。
Q：搜索平臺和搜索中臺最本質的區別是什麼？ A： 其實如今咱們內部也不太說中臺這個概念。若是必定要說區別的話，我的以爲就是中臺相對平臺更深刻業務吧。作平臺的時候，咱們想的更多的是通用性，儘可能少的在平臺裏作業務邏輯，否則的話就會以爲平臺不夠通用了。但作中臺的時候，更多的是思考沉澱一些業務共性的問題解決方案。若是說只有一個業務有這種問題，可能讓這個業務本身解決就好了，但若是像咱們這樣接了好幾百個業務，不少業務都有某個相同或類似的問題，與其說每一個業務分別去解決，倒不如由中臺來思考一個統一的解決方案。