導語 | 搜索和推薦是用戶獲取信息的兩種主要方式，在貝殼也是幫助客戶找到房子的主要手段，那么二者都有哪些相似和不同之處？是否可以使用同一套架構來實現？統一架構之后又能帶來哪些收益呢？本文是對貝殼搜索推薦部平台架構負責人——高攀在雲+社區沙龍online的分享整理，希望與大家一同交流。
一、貝殼搜索推薦使用場景
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 流等等。
和很多公司一樣，在貝殼，搜索和推薦之前是分屬於兩個不同的團隊各自發展的，整體代碼架構差異都很大，所以我下面會先分別介紹兩個平台各自的演進過程，然后再介紹搜索推薦架構統一的過程。
二、貝殼搜索平台架構演進
貝殼搜索平台主要經歷了四個階段：搜索服務、搜索平台、搜索雲平台和搜索中台。
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 的糾錯、改寫、分類和理解。然后調用召回，召回模塊會根據召回策略或召回模型進行底層數據的召回。然后再調用排序模塊，經過實時排序模型的精排后將最終結果返回給用戶。
同時我們進一步完善了統一的服務治理平台：包括注冊中心、配置中心、負載均衡、消息總線、熔斷降級、鏈路追蹤、監控報警和服務編排等模塊，最終形成了我們的搜索中台。
三、貝殼推薦平台的架構演進
貝殼推薦平台的架構演進也經歷了四個大的迭代，最早期就是簡單的基於內容和規則的推薦引擎，后面進一步增加了用戶畫像和協同過濾進行個性化推薦，再通過實時計算和實時模型實現實時個性化推薦，最后為了提升業務接入和迭代效率，推薦平台做了一個大的升級重構，支持業務配置化接入，最終升級為智能推薦平台。
1. 基於內容的推薦
早期基於內容的推薦非常簡單，底層通過對一些房源數據（二手房源、租賃房源等等）進行離線計算，使用Content-based推薦算法，直接離線算出相似房源、熱門房源等，然后寫入 Redis。
在線推薦服務再從 Redis 中查出離線計算好的可能感興趣的房源，然后直接返回給用戶進行推薦。
2. 實時個性化推薦
在內容推薦的基礎上，我們引入房源特征、實時用戶畫像和實時用戶行為記錄，升級為實時個性化推薦。
個性化推薦底層新增經紀人作業數據、用戶行為日志等數據，然后通過離線計算進行數據清洗和特征工程，生成房源特征和用戶畫像。
再通過協同過濾算法，進行協同過濾推薦，然后把這些數據批量更新到在線存儲引擎，包括離線計算好的召回數據、特征池和過濾集等。
和之前的架構類似，各業務線都有獨立的推薦服務，直接查詢在線存儲得到召回數據和特征數據等，然后根據策略計算后返回給用戶。
業務系統會經過 AB 實驗平台對流量進行分流，進行效果迭代實驗。同時，業務系統和推薦服務都會將實時埋點日志回流到實時計算服務和離線數倉中。從而實時更新召回數據和特征實現實時個性化推薦。
3. 智能平台推薦
為了提升業務接入效率和效果迭代效率，實時個性化推薦進一步升級迭代，將在線推薦服務進行拆分重構，下層離線計算和實時計算基本不變。
重構的目的主要用於解決早期的“煙囪模式”，不再每個業務場景對應一個獨立的推薦服務，而是用同一套推薦服務支撐上層的所有業務，新接業務直接復用上線，而非重新開發啟動一個服務，從而極大的提升效率。
為了達成這個目的，我們對整個推薦服務做了拆分，進行邏輯分層，分為應用層、計算層、數據層和模型層。
應用層主要對外提供API接口，以及處理簡單的業務規則和配置管理。計算層包含推薦的幾個核心流程，如召回、融合、排序和過濾，會分別調用數據層和模型層。數據層統一對下層的在線存儲系統進行基礎的數據查詢。模型層進行在線特征工程后會調用模型服務進行在線預測。計算層拿到數據層返回的結果后進行策略融合，然后調用模型層進行模型精排，最終返回給業務系統。
四、貝殼搜索推薦架構統一
我們回憶一下搜索平台和推薦平台的大體架構，可以發現他們有很多地方是相通或相似的。我們可以先對比一下搜索系統和推薦系統的相同點和不同點。
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”可以去除規則。
通過這個工作流機制，我們很多方法都可以復用，通過簡單的配置決定走哪些規則，不走哪些規則，這樣絕大多數場景都可以通過配置化的上線去滿足。
其實當前我們的架構統一還在進行中，因為我們的服務比較多，但已經取得了一些階段性成果，至少從人效上已經提了一倍。
原來搜索工程是六個人，推薦四個人，一共十個人，現在合並后只需要五個人。效果迭代效率上也有三倍的提升，之前一些策略規則調整，從開發到測試到上線平均需要十天，現在通過配置化上線基本三天就夠了。
五、未來規划
未來規划主要有兩點。
第一，沉淀通用策略模型組合，形成類似“策略套餐”，非核心業務可以自主選擇，快速復用。
因為現在不管是算法還是工程，我們的資源都還是有限的，我們現在的業務量很大，接了成百上千個，不可能每一個業務都做優化。
我們希望可以通過沉淀一些通用的策略模型組合，把它打包成一個類似套餐的形式，一些非核心的業務就可以自主選擇套餐復用配置好的模型和算法，進一步提升整體的優化效率。
第二，我們希望可以打造一個一站式的效果優化平台。
我們前面提到的很多系統，比如雲平台、實驗平台、模型管理平台等，目前都比較分散，並且有些平台工具是已經開發完善的，但有一些是還未開發完成的，比如樣本管理、特征管理、實驗管等。
我們后續會把各個平台和工具統一完善起來，同時全部打通，然后統一集成到一站式的效果優化平台中，包含業務管理、效果指標、機器學習、效果預測、流量實驗、干預運營等各模塊，從而進一步提升效果優化迭代的效率。
六、Q&A
Q：問下老師，雲平台如何監控的，都監控了哪些指標？
A：我們雲平台監控的指標非常多，比如數據流方面，包括各模塊寫入耗時、寫入量、寫入QPS、實時率、丟失率等。查詢方面：整體查詢耗時、各模塊查詢耗時、平均耗時、999分位耗時、9999分位耗時、查詢QPS、整體流量的大小、整體流量穩定性、各狀態碼（200、400、499、5XX）數量、比率等等。還包括慢查詢的監控，比如超過100ms的數量、超過500ms的數量、比率等等。
以上主要是性能和穩定性的監控，還有一些效果的監控指標，比如點擊率、曝光率和商機轉化率等等。這些監控有的是通過日志監控，有的是指標上報監控，使用了各種監控系統。
Q：自動編輯生成數據結構，會不會引起結構不合理的情況？怎么避免？
A：其實會有，這個我們遇到過，其實剛才可以看到我們雲平台有一個數據接口自動校驗，早前我們沒有那個功能，經常遇到用戶自己編輯、自己填寫表結構，什么字段、什么類型。
因為他編輯可能出錯，當我們拉數據的時候，會發現他的數據源 MySQL中的字段結構和他編輯的是不一樣的，有時是多了一個字段，有時是少了，有時表結構里寫的是字符串類型實際上是數字類型。經常會出現這樣的問題，然后發現數據導不進去、同步不了，導致數據阻塞。
所以我們后來增加了數據接口的自動校驗，他填完之后，系統會馬上他的拉取少量數據，幾百條、幾千條做驗證，拉出來的數據和表完全一致才能夠進行下一步。
Q：老師，這個鏈路追蹤是如何做的，是全鏈路嗎？
A：我們現在是全鏈路追蹤，基於ES 的 APM做的。大家如果了解的話就會知道，它可以自動的收集各個模塊的耗時，最終放到一個 ES 日志集群中，然后可以界面分析各個環節的耗時、整體的耗時等等。
Q：問一下老師，如何實現推薦多路並行召回的？
A：多路並行召回主要通過線程池並行的發送多個請求或查詢多個搜索引擎，比如向量引擎、文本引擎等，拿到多條召回流的結果后再跟進融合策略進行多路融合。
Q：網關是 openresty+lua 做？
A：網關我們用的是 Zuul，Spring Cloud 中的網關組件。
Q：老師，搜索和推薦質量保證方面，有沒有什么好辦法？
A：搜索推薦質量保證，這個指的是什么保證？穩定性剛才已經提到，如果是穩定性方面，我們確實做了很多，剛才提到，有整套的服務治理穩定性保障體系。其次我們的服務肯定是分布式多機部署的，單個服務掛掉了，對整體服務沒有任何影響，同時做很完善的限流熔斷降級機制。包括我們底層的存儲引擎，也都是雙機房互備部署的。
我們也搭建了完善的監控報警系統，比如499、5XX，超過千分之一就會短信或者電話報警。效果指標同樣有監控報警，比如點擊率轉化率突然大幅度降低，也會及時報警，然后定位分析。
一方面是完善監控報警，另外，從一開始設計的時候，就要考慮這方面的問題，比如剛才說的中控降級，就是在設計的時候就充分考慮下層每一個服務掛掉的時候我們該怎么辦？我們要做到的就是任何一個服務掛掉，都不會影響整體的查詢。其次還會進行季度性的線上壓測，及時發現一些線上隱患，摸清線上實際的吞吐量。
Q：老師，數據中台是必須的嗎？這個如何取舍？
A：其實數據中台跟我們今天講的關系不是很大，但既然同學問到，我個人覺得不是必須的，肯定看公司場景，如果小公司數據沒有那么多，肯定不需要建數據中台，如果是大公司數據非常多，需要各部門打通的話，就可能需要做數據中台。
Q：底層服務器是自己構建還是使用公有雲，人效提高以后，大家還要加班么？
A：現在貝殼是既有自建機房，又有騰訊雲的機房。我們現在是雙機房備份的。最壞的情況下，有一個機房掛了，對業務不會有太大影響，可以實時的切換到另一個機房去。
然后是否需要加班，加班這個東西跟人效關系不大，如果業務需求比較着急的話，一般還是需要加班的。如果不是很着急，大家按常規迭代，基本上加班不會太多。
人效提升之后，大家就可以去做更多的事情，探索更新的技術。比如我們整體人效提升之后，原來需要十個人做的事情，現在只需要五個人就夠了，騰出來的五個人就可以做新技術方向的探索，比如說新的向量引擎的探索，新的圖數據庫引擎，包括新的模型算法的研究等等，實際上就是盤子更大，做的事情更多，當然產出也會更多。
Q：監控都是自己開發的嗎 有第三方廠商的產品嗎？
A：都有吧，有一些開源的組件，也有自己研發的，還有一些公司其他平台提供的統一的監控系統。
Q：搜索平台和搜索中台最本質的區別是什么？
A：其實現在我們內部也不太說中台這個概念。如果一定要說區別的話，個人覺得就是中台相對平台更深入業務吧。做平台的時候，我們想的更多的是通用性，盡量少的在平台里做業務邏輯，不然的話就會覺得平台不夠通用了。但做中台的時候，更多的是思考沉淀一些業務共性的問題解決方案。如果說只有一個業務有這種問題，可能讓這個業務自己解決就行了，但如果像我們這樣接了好幾百個業務，很多業務都有某個相同或相似的問題，與其說每個業務分別去解決，倒不如由中台來思考一個統一的解決方案。
Q：可以內推嗎？
A：我們現在也比較缺人，歡迎大家投遞簡歷。郵箱：gaopan013@ke.com