[[239181]]

　　2015 年底，阿里宣布啟動(dòng)阿里巴巴集團(tuán)中臺(tái)戰(zhàn)略。戰(zhàn)略定義為：構(gòu)建符合 DT 時(shí)代的更具創(chuàng)新性、靈活性的“大中臺(tái)、小前臺(tái)”組織機(jī)制和業(yè)務(wù)機(jī)制。其中，前臺(tái)作為一線業(yè)務(wù)，更敏捷更快速適應(yīng)市場，中臺(tái)將集合整個(gè)集團(tuán)的數(shù)字運(yùn)營能力、產(chǎn)品技術(shù)能力，對(duì)各業(yè)務(wù)前臺(tái)形成強(qiáng)力支撐，而集團(tuán)在中臺(tái)布局中一個(gè)非常重要的一環(huán)便是搜索中臺(tái)化，但因搜索技術(shù)本身的復(fù)雜度和業(yè)務(wù)規(guī)模的挑戰(zhàn)，讓搜索中臺(tái)在技術(shù)上、產(chǎn)品上都遇到了***的挑戰(zhàn)。

　　面對(duì)挑戰(zhàn)，阿里選擇走上中臺(tái)開發(fā)運(yùn)維一體化實(shí)踐之路。這條路究竟要怎么走？下面跟隨阿里搜索事業(yè)部高級(jí)技術(shù)專家柳明，一起來了解。

　　背景

　　阿里搜索中臺(tái)的初心是支持前臺(tái)業(yè)務(wù)更敏捷更快速適應(yīng)市場的變化，愿景是讓天下沒有難用的搜索，基于初心和愿景我們從 0 到 1 建設(shè)搜索中臺(tái) 3 年，三年期間在 DevOps、AIOps、offline 平臺(tái)化上都有了不少業(yè)內(nèi)前沿的沉淀，而我作為一名阿里搜索老兵，有幸見證了整個(gè)阿里搜索中臺(tái)的技術(shù)發(fā)展，所以在這里通過一些我個(gè)人有限的經(jīng)驗(yàn)跟大家去分享一個(gè)后端服務(wù)該如何解決規(guī)?；?、成本、效率、質(zhì)量問題，朝著平臺(tái)化產(chǎn)品前進(jìn)的經(jīng)驗(yàn)。

　　搜索中臺(tái)技術(shù)發(fā)展

　　下圖即是搜索中臺(tái)從技術(shù)角度發(fā)展趨勢的一個(gè)判斷，也是經(jīng)過 3 年多落地實(shí)踐的一個(gè)過程。

　　可以從圖上看到***個(gè)階段應(yīng)該是我加入阿里的時(shí)候，無論是搜索事業(yè)部還是開源搜索技術(shù)都是靠人來負(fù)責(zé)系統(tǒng)和業(yè)務(wù)運(yùn)維。當(dāng)時(shí)人力資源是隨著業(yè)務(wù)規(guī)模成正比增長的，這期間消耗了大量的人力資源在做著低效而重復(fù)工作，這是人工管控的階段。

　　之后隨著經(jīng)驗(yàn)沉淀，PE 逐漸發(fā)現(xiàn)一些常見重復(fù)的運(yùn)維工作可以通過自動(dòng)化腳本實(shí)現(xiàn)，在一定程度上減少了人力成本，提高了運(yùn)維效率，也初步有了專家經(jīng)驗(yàn)和領(lǐng)域知識(shí)沉淀的影子，這是自動(dòng)化腳本運(yùn)維階段，這也是絕大部分開源技術(shù)體系所處的階段。但是這樣的運(yùn)維方式天然地分割了開發(fā)和運(yùn)維兩種角色。

　　因?yàn)榇蠹业氖姑煌?，讓兩種角色天然的站在了對(duì)立面上，開發(fā)希望快速迭代，運(yùn)維希望盡可能保障線上穩(wěn)定而減少迭代次數(shù)，因?yàn)榇蠹叶贾澜^大部分線上故障都其實(shí)是因?yàn)榕渲米兏蛙浖?jí)導(dǎo)致的，天然的分割造成了相互之間存在著對(duì)對(duì)方的不信任，所以也就有了雙方***的妥協(xié)：固定每周周二和周四的發(fā)布窗口進(jìn)行發(fā)布，但這是犧牲了業(yè)務(wù)運(yùn)營效率為前提的。

　　其實(shí)這里存在了一個(gè)系統(tǒng)能力和業(yè)務(wù)方迭代需求上的一個(gè)很大 gap，為了解決上述矛盾基于運(yùn)維開發(fā)一體化的 devOps 概念的全新管控系統(tǒng)建設(shè)應(yīng)運(yùn)而生，也就有了***階段的開發(fā)運(yùn)維一體化的建設(shè)，通過這些 ops 也較好地解決一些發(fā)布迭代問題。

　　但是我們的業(yè)務(wù)場景天然是一個(gè)技術(shù)體系的管控，所以我們認(rèn)為 devops 不應(yīng)該還停留在單個(gè)系統(tǒng)開發(fā)運(yùn)維一體化的方法論認(rèn)知上，所以希望我們的 devops 的定義是單個(gè)系統(tǒng) ops 之上的“ops”，所以本質(zhì)上我們和集團(tuán)其他所謂的 devOps 平臺(tái)有著非常大本質(zhì)上的區(qū)別。

　　集團(tuán)比較有代表性 devops 平臺(tái)就是天基平臺(tái)，它主要解決的是服務(wù)源代碼到部署再到升級(jí)的一個(gè)全過程的管理，面向的用戶本質(zhì)上還是運(yùn)維人員。所以在這個(gè)基礎(chǔ)上，天基利用 IAC（Infrastructure As Code，基礎(chǔ)設(shè)施即代碼）的維度 +Git 管理部署配置去打造產(chǎn)品其實(shí)已經(jīng)足夠，這是一種典型 devops 的平臺(tái)設(shè)計(jì)思路，但是僅僅如此的設(shè)計(jì)其實(shí)對(duì)于我們來講也許并不夠，因?yàn)閷?duì)于我們來說我們的用戶是最終用戶，他并不具備線上系統(tǒng)運(yùn)維專業(yè)知識(shí)，只看到配置或者 code，他一定會(huì)暈菜。

　　所以從根本上來講我們需要將對(duì) DevOps 理解上繼續(xù)往前走一步，朝著面向平臺(tái)產(chǎn)品化的角度上前進(jìn)一步：一是對(duì)用戶屏蔽配置或者 code 或者領(lǐng)域知識(shí)復(fù)雜度，二是將系統(tǒng)協(xié)同變成一種端對(duì)端體驗(yàn)的管控，因?yàn)橹挥凶龅搅撕喕瘡?fù)雜度和全鏈路端對(duì)端體驗(yàn)的管控才能真正讓復(fù)雜搜索業(yè)務(wù)迭代效率得到本質(zhì)上的提升，為了達(dá)成上述 2 個(gè)目標(biāo)我們經(jīng)過多年努力逐步落地了 sophon、bahamut、Maat 等系統(tǒng)，也取得了很好的業(yè)務(wù)迭代效率提升。

　　但只做到 DevOPS 對(duì)于阿里這樣體量的平臺(tái)就***了嗎？顯然不是，全鏈路的 DevOps 只是有效解決了研發(fā)、PE、用戶配合效率和用戶使用體驗(yàn)的問題，但是對(duì)于平臺(tái)方來講隨著業(yè)務(wù)規(guī)模的急劇膨脹，以及搜索服務(wù)類型的復(fù)雜多樣及多變，業(yè)務(wù)跟平臺(tái)的矛盾其實(shí)又發(fā)生了本質(zhì)性的轉(zhuǎn)移：如何給在海量規(guī)模下為每個(gè)業(yè)務(wù)提供更好的穩(wěn)定性保障和合理的資源利用率、以及更高的迭代效率等就成為了我們平臺(tái)新目標(biāo)。

　　目前我們基于在 AIOPS 數(shù)據(jù)化運(yùn)營的 3 年實(shí)踐中落地了 Hawkeye -在線服務(wù)優(yōu)化平臺(tái)、Torch-容量治理平臺(tái)、Heracles-日常壓測服務(wù)化平臺(tái)、CostMan-成本服務(wù)等系統(tǒng)。這些服務(wù)系統(tǒng)幫助平臺(tái)在容量管理，日常巡檢、一鍵診斷優(yōu)化上取得了一定的階段性成果，也讓我們對(duì)未來統(tǒng)一集團(tuán)搜索運(yùn)維管控，業(yè)務(wù)數(shù)量即使超過 10000+ 規(guī)模效應(yīng)下平臺(tái)也能應(yīng)對(duì)自如，樹立了堅(jiān)定的信心。

　　雖然經(jīng)過 3 年的數(shù)據(jù)化運(yùn)營的實(shí)踐，但我們離真正的 AIOps 還有較遠(yuǎn)距離，因?yàn)橹拔覀兊男阅芷款i分析、問題診斷、故障自愈、復(fù)雜運(yùn)維決策主要還是停留在專家經(jīng)驗(yàn)沉淀上，說白了還是把人的經(jīng)驗(yàn)沉淀到系統(tǒng)來解決線上運(yùn)維的問題，而 AIOPS 期待的是用數(shù)據(jù)和算法能力幫我們自動(dòng)地發(fā)現(xiàn)規(guī)律問題并解決問題，從這點(diǎn)上看 AIOps 在我們的平臺(tái)依然還有非常多的潛力可挖，所以我們希望未來在效率提升、質(zhì)量保障、成本優(yōu)化上能真正借助 AI 的能力幫平臺(tái)更好地適應(yīng)未來的發(fā)展。 

　　搜索中臺(tái)開發(fā)運(yùn)維一體化實(shí)踐-Sophon

　　開發(fā)運(yùn)維一體化-DevOPS

　　在我們介紹開發(fā)運(yùn)維一體化-sophon 的系統(tǒng)前，我們先看看一個(gè)稍微復(fù)雜搜索場景的業(yè)務(wù)接入時(shí)需要涉及到的系統(tǒng)以及他們是如何協(xié)調(diào)工作的。

　　從上圖其實(shí)大家看到整個(gè)系統(tǒng)模塊大致分為 3 大模塊，OPS、Online、Offline。其中如圖所示 Ops 層很明顯分成了在線有狀態(tài)服務(wù) ops、在線無狀態(tài)服務(wù) ops 和離線 ops。

　　就是說每個(gè)服務(wù)都是單獨(dú) OPS 進(jìn)行單獨(dú)管控，但實(shí)際上如上圖所示一個(gè)復(fù)雜業(yè)務(wù)就是一個(gè)多服務(wù)體系協(xié)同的結(jié)果，所以在我的記憶里當(dāng) tisplus 沒上線前，我們接入復(fù)雜業(yè)務(wù)之前***件事情就是召集在線有狀態(tài)服務(wù)團(tuán)隊(duì)、在線無狀態(tài)服務(wù)團(tuán)隊(duì)、離線 DUMP 團(tuán)隊(duì)、業(yè)務(wù)方、PE 開個(gè)會(huì)互通下有無，然后安排怎么合作推進(jìn)這個(gè)項(xiàng)目上線，上線后的線上變更和問題處理也是支持群里相互吼：“我已經(jīng)做完這一步了，你可以做下一步了”，“你稍等下再操作，我還要重新發(fā)下”。所以可以想象這樣的業(yè)務(wù)接入合作效率得有多低，相信大家從我剛才的描述中也能知道為啥我們之前支持 10 來個(gè)業(yè)務(wù)已經(jīng)是極限的原因了吧。

　　有了這些痛點(diǎn)需求，那再回過頭來說說我們我們在實(shí)踐過程中認(rèn)為復(fù)雜搜索系統(tǒng)的 devops 建設(shè)必須有：

1. 提供端對(duì)端體驗(yàn)的全鏈路 OPS 才是我們認(rèn)為符合我們場景的 devops 標(biāo)準(zhǔn)定義。

2. 復(fù)雜的運(yùn)維管控鏈路中基于我們常識(shí)認(rèn)知的過程式運(yùn)維方式需要升級(jí)到基于目標(biāo)驅(qū)動(dòng)式的運(yùn)維管控。

3. 較好的運(yùn)維抽象及產(chǎn)品抽象，更好的賦能用戶。

4. 提高業(yè)務(wù)迭代效率必須是保障業(yè)務(wù)穩(wěn)定性為基礎(chǔ)。

　　有了這些需求痛點(diǎn)，也就有了我們在這個(gè)領(lǐng)域的技術(shù)平臺(tái)布局-Sophon，接下來我們將分章節(jié)詳細(xì)介紹下該系統(tǒng)。

　　搜索中臺(tái) devops 實(shí)踐-Sophon

　　目標(biāo)驅(qū)動(dòng)式運(yùn)維

　　什么叫基于目標(biāo)驅(qū)動(dòng)式的運(yùn)維？其實(shí)乍一聽，會(huì)覺得太過于抽象，其實(shí)如果聽完我的解釋，你會(huì)覺得非常簡單，我們舉個(gè)實(shí)際搜索的運(yùn)維場景來說明也許更容易明白為什么我們要提倡基于目標(biāo)的運(yùn)維管控。

　　比如我們的搜索系統(tǒng)現(xiàn)在的索引版本是A版本，然后要求系統(tǒng)執(zhí)行切換索引B版本，但正在 rollingB 版本的時(shí)候，我后悔了我要 rolling C 版本。這其實(shí)在早些年的時(shí)候，線上這種狀況是非常讓人崩潰的，如果這事讓 PE 去做的話 ， 只能殺掉切換流程，檢查系統(tǒng)每個(gè)節(jié)點(diǎn)到哪一步了，清理中間狀態(tài)，重新發(fā)起運(yùn)維流程，可以想象過程式的運(yùn)維管控方式在復(fù)雜運(yùn)維體系下是多么低效的事情。

　　但如果是基于目標(biāo)驅(qū)動(dòng)的調(diào)度，我們只需要重新給系統(tǒng)設(shè)定新的 rolling C 版本，那么系統(tǒng)將會(huì)獲得***目標(biāo)和當(dāng)前執(zhí)行漸進(jìn)的目標(biāo)進(jìn)行對(duì)比，發(fā)現(xiàn)目標(biāo)狀態(tài)存在變化，系統(tǒng)會(huì)馬上終止掉當(dāng)前執(zhí)行路徑和自動(dòng)清理系統(tǒng)存在的不一致狀態(tài)，開始下放***目標(biāo)狀態(tài)關(guān)鍵路徑執(zhí)行通知，各個(gè)節(jié)點(diǎn)接受到***命令后開始逐步向新的目標(biāo)漸進(jìn)，所以只看最終狀態(tài)的漸進(jìn)式最終一致性運(yùn)維方式自然而然屏蔽了運(yùn)維中間狀態(tài)的復(fù)雜性，讓復(fù)雜運(yùn)維管控變得更加簡單更靈活，這也是為什么我們平臺(tái)自上而下所有的運(yùn)維方式都升級(jí)成了基于目標(biāo)驅(qū)動(dòng)的原因。

　　運(yùn)維概念簡化

　　我們平臺(tái)一直提到從托管到賦能，言下之意是希望讓最終用戶承擔(dān)起自己應(yīng)當(dāng)要承擔(dān)的責(zé)任才能享受更強(qiáng)大的搜索能力。但談到要賦能，那也不能將搜索系統(tǒng)復(fù)雜的領(lǐng)域知識(shí)和運(yùn)維概念直接暴露給最終用戶，否則這肯定不叫賦能用戶，而是叫做折騰用戶了。所以如何將系統(tǒng)的運(yùn)維概念簡化，將復(fù)雜和潛在領(lǐng)域知識(shí)留給系統(tǒng)內(nèi)部就是 sophon 需要解決的核心問題之一。

　　上圖下方是從 PE 視角看到的各個(gè)數(shù)據(jù)中心的基礎(chǔ)設(shè)施和各種在線服務(wù)，如果沒有一層管控抽象，讓最終用戶和 PE 看到的是一樣的復(fù)雜度，我相信用戶一定會(huì)暈菜。

　　所以 sophon 做的一個(gè)事情就是將運(yùn)維管控對(duì)象抽象成一組數(shù)據(jù)關(guān)系模型，也就是運(yùn)維管控模型，如上圖右側(cè)所示，但是這一層運(yùn)維抽象依然足夠復(fù)雜，用戶不應(yīng)該也不需要去了解這層運(yùn)維抽象，我們應(yīng)該給用戶看到的是觸達(dá)業(yè)務(wù)場景的業(yè)務(wù)抽象，所以 sophon 在***層運(yùn)維抽象之上又抽象了業(yè)務(wù)抽象，如左上角的三層概念：業(yè)務(wù)邏輯（插件、配置）、服務(wù)（部署關(guān)系）、數(shù)據(jù)（數(shù)據(jù)源&離線數(shù)據(jù)處理）。這層的定義用戶是幾乎無成本就能接受的，所以通過 sophon 做到的抽象運(yùn)維概念和簡化業(yè)務(wù)概念的能力也讓我們平臺(tái)從托管到賦能用戶成為了可能。 

　　穩(wěn)定性保障

　　sophon 保障服務(wù)穩(wěn)定性主要體現(xiàn)在 2 個(gè)方面：

• 當(dāng)平臺(tái)支持越來越多的頭部核心業(yè)務(wù)，我們需要對(duì)業(yè)務(wù)的搜索服務(wù)進(jìn)行 SLA 保障，同時(shí)也能適應(yīng)各個(gè)業(yè)務(wù)根據(jù)自己的穩(wěn)定性要求進(jìn)行靈活的在離線服務(wù)的部署，同時(shí)還需要具備自動(dòng)容災(zāi)切換能力。目前 sophon 服務(wù)穩(wěn)定性方面能夠支持搜索在線服務(wù)單元化、在離線服務(wù)單元化、離線數(shù)據(jù)冷備部署以及查詢鏈路和數(shù)據(jù)回流鏈路自動(dòng)容災(zāi)切切換的能力，如下圖所示：

• 我們前面提到迭代效率提升有一點(diǎn)就是讓原先基于時(shí)間窗口的線上發(fā)布迭代變成了可以 24 小時(shí)隨時(shí)隨地可以發(fā)布，但我們說的隨時(shí)隨地并不是代表我們只是提供了發(fā)布按鈕功能，而不去考慮快速發(fā)布過程可能帶來的潛在危險(xiǎn)，所以高效且安全的發(fā)布迭代才是我們追求的目標(biāo)，這個(gè)背后非常重要的基礎(chǔ)就是我們設(shè)計(jì)和標(biāo)準(zhǔn)化了一套發(fā)布迭代規(guī)范。

  例如一次正常的業(yè)務(wù)迭代，需要經(jīng)過日常、預(yù)發(fā) 2 套環(huán)境進(jìn)行驗(yàn)證，同時(shí)在預(yù)發(fā)發(fā)布線上的發(fā)布流程中我們加入了多重校驗(yàn)機(jī)制來進(jìn)行發(fā)布的穩(wěn)定性，比如插件、算法策略升級(jí)時(shí)，我們會(huì)要求 clone 壓測對(duì)比，如果性能差距太大，發(fā)布流程會(huì)被回退，同時(shí)基于單機(jī)房切流灰度發(fā)布和冒煙驗(yàn)證等能力可以在發(fā)布流程里被定義，所以有了 sophon 提供的強(qiáng)大的多重校驗(yàn)機(jī)制和快速容災(zāi)切換的能力，讓業(yè)務(wù)快速迭代中再也沒有了后顧之憂，可以將業(yè)務(wù)運(yùn)營迭代效率提升到***，如下圖所示：

　　專家經(jīng)驗(yàn)沉淀

　　搜索技術(shù)體系雖然功能強(qiáng)大，但強(qiáng)大的背后也有很多專業(yè)潛規(guī)則，所以如果平臺(tái)把復(fù)雜的運(yùn)維管控和業(yè)務(wù)迭代需要遵循的專業(yè)知識(shí)暴露給普通用戶，用戶肯定歇菜，所以我們在 devops 這層一定要將引擎服務(wù)領(lǐng)域知識(shí)下沉讓平臺(tái)去屏蔽這些復(fù)雜性。

　　舉個(gè)真實(shí)的搜索場景來說，如果業(yè)務(wù)方有一個(gè)字段的修改，但真實(shí)情況下一個(gè)字段的修改其實(shí)是可能涉及到在線和離線的配置聯(lián)動(dòng)修改，換句話說你不能說讓用戶在修改配置的時(shí)候讓他判斷我這次修改是只會(huì)影響到在線服務(wù)、還是影響到離線服務(wù)，還是在離線服務(wù)都會(huì)影響到，此外配置推送需要先離線服務(wù)生效還是在線服務(wù)先生效，還是說配置必須做全量后一起生效等等，這些都是引擎服務(wù)的專家知識(shí)。

　　目前我們依靠 sophon devOPS 這層將這些領(lǐng)域知識(shí)都在背后默默消費(fèi)掉了，用戶完全不需要關(guān)注這些潛在知識(shí)，運(yùn)維平臺(tái)內(nèi)部會(huì)分解復(fù)雜運(yùn)維操作，然后會(huì)根據(jù)我們定義好的專家運(yùn)維 DAG 圖來有條不紊分階段的進(jìn)行運(yùn)維執(zhí)行，如下圖所示：

　　通過我們不斷將運(yùn)維專家經(jīng)驗(yàn)沉淀到系統(tǒng)（運(yùn)維 DAG 執(zhí)行流程圖），用戶對(duì)平臺(tái)的使用成本會(huì)不斷變小，同時(shí)迭代效率也會(huì)越來越高。當(dāng)然如果運(yùn)維操作變得越來越復(fù)雜（比如我們暴露給用戶的業(yè)務(wù)視角需要涵蓋越來越多的服務(wù)），運(yùn)維 DAG 執(zhí)行鏈從簡單就會(huì)發(fā)展到可能存在多種執(zhí)行分支，那么如何在運(yùn)維執(zhí)行中尋找到***執(zhí)行鏈路就會(huì)成為一個(gè)有趣的話題（如上圖右邊所示），目前我們稱之為最短路徑選擇，這是智能化運(yùn)維一個(gè)有趣的嘗試，這也是未來我們持續(xù)努力的方向。

從系統(tǒng)到全鏈路

　　前面其實(shí)也介紹了我們的所有業(yè)務(wù)場景都是一個(gè)技術(shù)體系協(xié)同的結(jié)果，而這個(gè)過程中最重要也***挑戰(zhàn)的點(diǎn)便是如何將在線和離線高效協(xié)同提供給用戶端對(duì)端的體驗(yàn)。

　　從上圖可以看到最終用戶使用離線數(shù)據(jù)永遠(yuǎn)看到的是可視化數(shù)據(jù)關(guān)系定義和簡單的 dump->Build->switchindex 任務(wù)執(zhí)行列表。但是實(shí)際上是我們把所有的復(fù)雜度屏蔽掉，系統(tǒng)背后卻是有一個(gè)復(fù)雜的狀態(tài)機(jī)在管控在離線的協(xié)同，這張圖不打算展開講，整個(gè)在離線協(xié)同，狀態(tài)機(jī)不是關(guān)鍵，關(guān)鍵是我們?nèi)绾螌⒚總€(gè)在線搜索業(yè)務(wù)對(duì)離線數(shù)據(jù)處理的個(gè)性化需求轉(zhuǎn)換成一種抽象，***通過平臺(tái)方式來支撐的。

　　在展開介紹離線平臺(tái)技術(shù)前，稍微跟大家介紹下一個(gè)搜索業(yè)務(wù)對(duì)離線處理的普世需求，而這些需求也是沒有離線平臺(tái)之前支持復(fù)雜業(yè)務(wù)在離線跨團(tuán)隊(duì)合作中被重復(fù)討論過多次的話題。那就是到引擎的業(yè)務(wù)數(shù)據(jù)并不是一個(gè)簡單的數(shù)據(jù)庫表，它可能來源于多個(gè)同構(gòu)或者異構(gòu)數(shù)據(jù)源，同時(shí)每個(gè)搜索業(yè)務(wù)都有全量和增量的需求，所以如何將這些根據(jù)業(yè)務(wù)不同而不同數(shù)據(jù)源關(guān)系處理變成一種高層抽象并且屏蔽內(nèi)部處理環(huán)節(jié)和統(tǒng)一增量和全量處理流程就變得非常重要，否則來一個(gè)業(yè)務(wù)我們都要為其實(shí)現(xiàn)全量和增量數(shù)據(jù)處理代碼簡直是不可忍的事情。

　　現(xiàn)在來回顧之前我們離線支持效率低的原因還是我們之前對(duì)引擎 schema 定義的數(shù)據(jù)源都是被弱化成一對(duì)對(duì)的資源進(jìn)行抽象和管理，也就導(dǎo)致我們沒有把本應(yīng)該的基礎(chǔ)的抽象給提煉出來，其實(shí)仔細(xì)想下來我們目前接入的所有數(shù)據(jù)資源都是 Dynamic Table，所以如果我們以表的抽象去定義這些資源，那一些通用的類似創(chuàng)建表、刪除表、修改表、增刪改查表數(shù)據(jù)，定義表之間關(guān)系等 API 都應(yīng)該可以被收斂掉而不會(huì)存在重復(fù)開發(fā)問題，所以有了這樣一個(gè)思考，也就有了我們打造離線組件平臺(tái)-bahamut 的整體設(shè)計(jì)思路。

　　平臺(tái)支持用戶在平臺(tái)畫布上定義好各自數(shù)據(jù)源信息和表之間關(guān)系定義后（我們可以支持異構(gòu)表之間的 join，例如 odps 和 mysql），我們會(huì)將這個(gè)前端的 Graph 提交給 Bahamut 進(jìn)行翻譯，bahamut 將這個(gè)前端的 Graph 解析、優(yōu)化、拆分、翻譯成成若干個(gè) blink 可執(zhí)行的 graph，比如增量的 syncBlink 、全量的 BulkLoad MR 任務(wù)，和 Blink Join 任務(wù)等。

　　這里最重要的兩個(gè)關(guān)鍵的 graph 節(jié)點(diǎn)是 merge 和 left join。merge 是將所有的1：1 和1：N關(guān)系表的處理通過行轉(zhuǎn)列到一個(gè) HBASE 中間表，而N：1 的關(guān)系處理以下圖的例子來說，我們目前只支持主表N這邊（商品表）驅(qū)動(dòng)，也就是說N這方的通過 blink sync 更新后利用 blink Join 合并 1 這方（即用戶表）成完整的行記錄發(fā)送到 SwiftSink（增量）&HDFSSink（全量）最終回流到到 BuildService 構(gòu)建索引，如下圖所示：

　　通過在線離線管控協(xié)同和 BaHamut 組件平臺(tái)的打造，可以讓用戶通過可視化的手段就能享受到強(qiáng)大的離線復(fù)雜數(shù)據(jù)關(guān)系處理和計(jì)算能力，極大地提升了業(yè)務(wù)支持效率，同時(shí)也讓我們平臺(tái)成為***個(gè)可以整合離線提供在離線端對(duì)端體驗(yàn)的里程碑式的產(chǎn)品。另外我們還在做一件事情將離線能力變成在線服務(wù)通用能力，相信不遠(yuǎn)的將來離線組件平臺(tái)不會(huì)是 HA3 搜索場景的離線組件平臺(tái)，而是整個(gè)搜索在線服務(wù)的離線組件平臺(tái)。

　　本文是阿里搜索中臺(tái)技術(shù)系列 Devops 實(shí)踐的分享，接下來還會(huì)陸續(xù)推出搜索離線組件平臺(tái)、搜索 AIOps 實(shí)踐的多篇分享，敬請(qǐng)期待。

　　搜索中臺(tái)從 0 到 1 建設(shè)已經(jīng)走過了 3 年，但它離我們心目中讓天下沒有難用的搜索的遠(yuǎn)大愿景還離得非常遠(yuǎn)，在這個(gè)前行的道路上一定會(huì)充滿挑戰(zhàn)，無論是業(yè)務(wù)視角的 SaaS 化能力、搜索算法產(chǎn)品化、云端 DevOps&AIOps，還是業(yè)務(wù)建站等都將遇到***的難題。