在某大型醫(yī)院的數(shù)據(jù)同步項(xiàng)目中260條同步鏈路同時(shí)運(yùn)行源端涉及Oracle、MySQL、SQL Server、KES V8R6、Vastbase等10多種數(shù)據(jù)庫(kù)并持續(xù)向目標(biāo)庫(kù)匯聚數(shù)據(jù)。在這樣的環(huán)境里把數(shù)據(jù)同步過去并不難。真正讓鏈路“卡住”的是業(yè)務(wù)系統(tǒng)里不斷發(fā)生的結(jié)構(gòu)變化新增字段、改類型、調(diào)索引、加約束它們都以DDL數(shù)據(jù)定義語(yǔ)言的形式發(fā)生。源端結(jié)構(gòu)一改目標(biāo)端還在老結(jié)構(gòu)上后續(xù) DML 即使能捕獲也可能因字段或類型對(duì)不上而寫不進(jìn)去。更麻煩的是異構(gòu)數(shù)據(jù)庫(kù)的DDL很難一一對(duì)應(yīng)。同樣加一個(gè)字段Oracle、MySQL、SQL Server 的數(shù)據(jù)類型、默認(rèn)值和語(yǔ)法寫法都可能不同一條在源端跑得通的ALTER TABLE原樣送到目標(biāo)端很可能直接報(bào)錯(cuò)。如果每次結(jié)構(gòu)變化都要人工分析SQL、寫轉(zhuǎn)換規(guī)則、驗(yàn)證后再恢復(fù)鏈路幾條鏈路還能應(yīng)付放到260條長(zhǎng)期運(yùn)行的鏈路里就是一項(xiàng)只增不減的運(yùn)維工作。KFS的DDL自動(dòng)轉(zhuǎn)換能力就是用來(lái)解決這件事的。第一步先“拆”DDL很多DDL轉(zhuǎn)換方案靠字符串替換或正則改SQL。簡(jiǎn)單語(yǔ)句沒問題一遇到復(fù)雜DDL規(guī)則就會(huì)膨脹一條ALTER TABLE可能同時(shí)改列A的類型、給列B加默認(rèn)值、給列C加約束繼續(xù)按整條字符串處理匹配條件只會(huì)越疊越多規(guī)則之間還會(huì)打架。KFS的方案是先搞清楚這條SQL到底做了什么。在源端增量解析過程中KFS會(huì)先判斷這次變化屬于DML還是DDL。對(duì)DDL繼續(xù)拆成更細(xì)的結(jié)構(gòu)信息DDL類型、操作對(duì)象、涉及哪些字段、每個(gè)字段做了什么動(dòng)作以及對(duì)應(yīng)的數(shù)據(jù)類型、默認(rèn)值、約束。以一條同時(shí)修改多個(gè)字段的ALTER TABLE為例進(jìn)入轉(zhuǎn)換環(huán)節(jié)后它被拆成“ALTER TABLE表對(duì)象各字段操作”等多個(gè)結(jié)構(gòu)化單元。后面所有處理依據(jù)的都是這次結(jié)構(gòu)到底變了什么。第二步把異構(gòu)數(shù)據(jù)庫(kù)之間的差異變成可映射的規(guī)則數(shù)據(jù)庫(kù)之間有一部分差異是穩(wěn)定、反復(fù)出現(xiàn)的比如數(shù)據(jù)類型如何對(duì)應(yīng)、基礎(chǔ) DDL 語(yǔ)法如何表達(dá)。每個(gè)項(xiàng)目重配一遍就是重復(fù)勞動(dòng)所以 KFS 內(nèi)置了數(shù)據(jù)類型映射和基礎(chǔ)語(yǔ)法映射規(guī)則自動(dòng)適配。但真實(shí)業(yè)務(wù)不會(huì)只有“標(biāo)準(zhǔn)寫法”字段精度、長(zhǎng)度、默認(rèn)值、特殊約束、對(duì)象名稱往往帶著項(xiàng)目特征通用規(guī)則覆蓋不了。這種方式在大規(guī)模鏈路下價(jià)值尤其明顯。260條鏈路連著不同業(yè)務(wù)系統(tǒng)但其中大量Oracle、MySQL、SQL Server之間的類型和基礎(chǔ)語(yǔ)法差異是重復(fù)的沉淀到產(chǎn)品里就不必每條鏈路都從零配一遍。目前KFS已經(jīng)覆蓋建表、增刪改字段、表與字段重命名、索引變更、約束增刪及啟停等常見結(jié)構(gòu)變化。在項(xiàng)目典型DDL樣本中約95%的常規(guī)變化可以直接進(jìn)入自動(dòng)轉(zhuǎn)換只有少量帶特殊默認(rèn)值、復(fù)雜約束或業(yè)務(wù)定制邏輯的DDL需要人工補(bǔ)規(guī)則。第三步按目標(biāo)端語(yǔ)法重新生成DDL完成結(jié)構(gòu)拆解和規(guī)則映射后還有最關(guān)鍵的一步把這些結(jié)構(gòu)信息重新變成目標(biāo)數(shù)據(jù)庫(kù)真正能夠執(zhí)行的 DDL。這也是KFS DDL自動(dòng)轉(zhuǎn)換和簡(jiǎn)單正則替換之間最大的區(qū)別。正則轉(zhuǎn)換是在源SQL上做修改刪一段字符、換個(gè)關(guān)鍵詞、改個(gè)類型。而 KFS 在拆解和映射之后會(huì)按目標(biāo)庫(kù)的語(yǔ)法結(jié)構(gòu)把操作對(duì)象、字段動(dòng)作、數(shù)據(jù)類型和相關(guān)規(guī)則重新組織生成目標(biāo)庫(kù)能直接執(zhí)行的DDL。還是那條改三個(gè)字段的ALTER TABLE。字段A、B、C的結(jié)構(gòu)動(dòng)作已經(jīng)被識(shí)別出來(lái)類型和規(guī)則也映射完成這時(shí)不需要再猜源SQL該改成什么樣只要按目標(biāo)庫(kù)支持的語(yǔ)法把這些明確的操作單元重新組合成新的ALTER TABLE語(yǔ)句。整個(gè)過程更接近源端DDL→結(jié)構(gòu)化解構(gòu)→數(shù)據(jù)類型與語(yǔ)法映射→目標(biāo)語(yǔ)法重構(gòu)→生成目標(biāo)DDL。這也是為什么DDL越來(lái)越復(fù)雜、數(shù)據(jù)庫(kù)類型不斷增加“先拆后組”會(huì)比不斷堆字符串替換規(guī)則更容易擴(kuò)展。源端怎么寫是一回事目標(biāo)端要求怎么表達(dá)是另一回事中間靠結(jié)構(gòu)信息和映射規(guī)則解耦同一套機(jī)制才能適應(yīng)更多異構(gòu)場(chǎng)景。生成DDL不是終點(diǎn)目標(biāo)端執(zhí)行成功才算完成一條SQL看起來(lái)“翻譯對(duì)了”不代表DDL同步就完成了。生產(chǎn)環(huán)境只有一個(gè)標(biāo)準(zhǔn)目標(biāo)庫(kù)能不能執(zhí)行。KFS生成目標(biāo)端DDL后會(huì)下發(fā)執(zhí)行并檢測(cè)執(zhí)行結(jié)果。成功結(jié)構(gòu)變化同步完成后續(xù)DML按新表結(jié)構(gòu)繼續(xù)寫入異常則捕獲錯(cuò)誤信息。當(dāng)前規(guī)則轉(zhuǎn)不了的DDLKFS不會(huì)硬湊一個(gè)不確定的結(jié)果而是保留原始DDL并跳過。如果后續(xù)DML已經(jīng)依賴這次沒做完的結(jié)構(gòu)變化鏈路會(huì)中斷并進(jìn)入人工干預(yù)。這種機(jī)制對(duì)生產(chǎn)系統(tǒng)非常重要。DDL轉(zhuǎn)換真正危險(xiǎn)的是那條轉(zhuǎn)錯(cuò)的語(yǔ)句被悄悄執(zhí)行導(dǎo)致目標(biāo)端結(jié)構(gòu)與源端出現(xiàn)偏差后續(xù)問題反而更難定位。因此KFS的處理原則很明確能夠確定轉(zhuǎn)換結(jié)果的自動(dòng)完成無(wú)法確定的及時(shí)暴露。在項(xiàng)目典型場(chǎng)景抽樣驗(yàn)證中經(jīng)過自動(dòng)轉(zhuǎn)換的常規(guī) DDL目標(biāo)端一次執(zhí)行通過率可達(dá)到98%以上。KFS把原本依賴工程師經(jīng)驗(yàn)的過程拆成幾個(gè)系統(tǒng)能完成的步驟識(shí)別變化、拆解結(jié)構(gòu)、匹配規(guī)則、按目標(biāo)語(yǔ)法重構(gòu)再用真實(shí)執(zhí)行結(jié)果做最后一道驗(yàn)證。一條DDL自動(dòng)走完這套流程解決的是一次問題260條鏈路都具備這個(gè)能力解決的才是規(guī)模化問題。KFS把原本依賴工程師經(jīng)驗(yàn)的過程拆成幾個(gè)系統(tǒng)能完成的步驟識(shí)別變化、拆解結(jié)構(gòu)、匹配規(guī)則、按目標(biāo)語(yǔ)法重構(gòu)再用真實(shí)執(zhí)行結(jié)果做最后一道驗(yàn)證。一條DDL自動(dòng)走完這套流程解決的是一次問題260條鏈路都具備這個(gè)能力解決的才是規(guī)模化問題。