# 沒API的老系統(tǒng)數(shù)據怎么取——異構對接的數(shù)據庫只讀路線## 引言企業(yè)做數(shù)據集成碰到的第一個攔路虎往往不是技術多復雜而是手里壓根沒有像樣的接口。一套ERP是十幾年前上的原廠早就停維接口文檔跟著離職的開發(fā)一起沒了MES是某廠商的封閉產品開放接口要另外付費WMS倒是有幾個REST但字段對不上需求。技術決策者面對的現(xiàn)實是要打通的十幾個系統(tǒng)里能直接拿來用的API可能不到三成。異構系統(tǒng)對接這道關繞不開沒API怎么辦這個最樸素的難題。## 一、沒API的幾種典型情況情況一老系統(tǒng)無API。這是最難的一類。企業(yè)IT底座里普遍有一兩套運行了十年以上的系統(tǒng)這些系統(tǒng)設計時壓根沒有API的概念所有數(shù)據交互走數(shù)據庫直連或者文件導出。要拿數(shù)據真正穩(wěn)的入口是數(shù)據庫本身。情況二有API但字段不全。某裝備制造企業(yè)的MES開放了工單查詢接口但只返回工單號、狀態(tài)、完工數(shù)量三個字段工藝參數(shù)、班次、設備這些關鍵字段沒有。接口看似通了實際能用起來的數(shù)據不到業(yè)務需要的四成。這種半接口對接往往比無接口更折騰因為給了希望又滿足不了。情況三接口要收費或審批周期長。一些商業(yè)系統(tǒng)的開放接口是收費模塊或者要走廠商審批周期兩三個月起步。業(yè)務側等不起這種節(jié)奏技術側又不能繞過廠商亂改系統(tǒng)。異構系統(tǒng)對接在這種場景下被接口的商業(yè)策略卡死了。向量空間JBoltAI在項目里反復遇到的正是這三類加在一起的局面——純無API的占大頭有接口不完整的中等接口要花錢花時間等審批的也不少。指望靠寫接口把所有系統(tǒng)打通在大多數(shù)企業(yè)里不現(xiàn)實。## 二、數(shù)據庫只讀沒API時的務實路線既然接口這條路走不通退一步的路線是數(shù)據庫只讀。核心原則就一條不修改原系統(tǒng)結構只架在現(xiàn)有系統(tǒng)之上讀數(shù)據。向量空間JBoltAI做異構對接時把這條原則當成底線——對客戶業(yè)務系統(tǒng)零侵入只讀不改。為什么強調只讀。老系統(tǒng)最怕被改壞。一套跑了十年的ERP數(shù)據庫結構是當年廠商設計的表之間有隱含的觸發(fā)器、有存儲過程、有歷史遺留的臟數(shù)據依賴。一旦寫操作進去很可能破壞原系統(tǒng)的數(shù)據一致性。只讀連接從根上規(guī)避這個風險原系統(tǒng)一行代碼、一條記錄都不動只是在旁邊讀一份。只讀連接的工程做法分幾步。第一步拿到數(shù)據庫的只讀賬號權限只給SELECT不給INSERT、UPDATE、DELETE。第二步對核心業(yè)務表做結構分析搞清楚訂單、工單、庫存這些核心實存在哪些表、字段含義是什么。第三步建一層只讀視圖把原始表的字段翻譯成業(yè)務可理解的名稱比如把MES里字段名wo_status3翻譯成工單完工。向量空間JBoltAI在對接某裝備制造企業(yè)老ERP時就是用這套只讀路線原系統(tǒng)一行沒動把訂單、BOM、庫存三張核心表的數(shù)據取了出來。關鍵工程細節(jié)有兩個。一個是連接池要單獨建不要復用原系統(tǒng)的連接避免讀操作的負載拖垮生產庫建議用獨立的只讀副本或者跑在業(yè)務低峰期。另一個是增量同步而非全量拉取訂單表幾百萬行全量拉一次很慢按update_time做增量只讀每天變化的那幾千行對生產庫的壓力小一個數(shù)量級。## 三、連數(shù)據庫文檔都沒有怎么辦比沒API更極端的情況是連數(shù)據庫表結構文檔都沒有。某紡織企業(yè)的老MES是十年前外購的廠商早就聯(lián)系不上數(shù)據庫里幾百張表表名是拼音縮寫字段是c001、c002這種編號沒人知道每張表裝的是什么。這種情況下向量空間JBoltAI用的辦法是讓AI分析數(shù)據庫表結構。把數(shù)據庫的schema導出來——表名、字段名、字段類型、注釋連同少量的樣例數(shù)據一起喂給AI模型。AI根據字段命名規(guī)律、數(shù)據分布、表之間的外鍵關聯(lián)推斷每張表的業(yè)務含義。比如c001字段全是訂單號格式c002全是日期格式表之間c001有外鍵關聯(lián)AI就能推斷這張表是訂單明細表。這套做法的核心是把人去理解數(shù)據庫變成AI去理解數(shù)據庫。幾百張表人工梳理需要一兩個月AI輔助下能把核心業(yè)務表的識別壓縮到幾天。需要強調的是AI推斷的結果要人工核驗尤其是涉及金額、庫存這些關鍵指標AI猜錯一個字段含義后面所有分析全錯。某紡織企業(yè)的MES經過AI輔助分析加人工核驗一周內理清了訂單、工藝、庫存三類核心表剩下的輔助表邊用邊補。## 四、只讀路線的邊界與配套數(shù)據庫只讀不是萬能的它解決的是數(shù)據取出來這一層取出來之后還有兩道關。第一道關是語義統(tǒng)一。十幾個系統(tǒng)都用只讀取出來數(shù)據確實都拿到了但ERP叫客戶編碼、CRM叫客戶編號、WMS叫客戶簡稱拉到一起還是對不上。只讀路線只完成連接層沒解決語義層。這就是異構對接的真正難點不在接口而在語義——取數(shù)是體力活對語義是腦力活。向量空間JBoltAI的做法是用本體語義模型做統(tǒng)一翻譯把不同系統(tǒng)的同義字段關聯(lián)到同一個業(yè)務實體讓跨系統(tǒng)查詢能跑通。第二道關是實時性。只讀同步往往是定時批量不是實時流。老板想看的是現(xiàn)在的庫存而不是昨晚的庫存。對實時性要求高的場景只讀路線要配合CDC——捕獲數(shù)據庫的變更日志增量推送到語義層。CDC對源庫有額外壓力要權衡哪些表值得實時、哪些表日批就夠。向量空間JBoltAI在對接某裝備制造企業(yè)時訂單和庫存走CDC實時工藝和設備數(shù)據走日批按業(yè)務對實時性的真實需求分級處理。## 五、實戰(zhàn)建議第一對接策略按系統(tǒng)分檔。沒API的老系統(tǒng)走數(shù)據庫只讀有完整API的系統(tǒng)走接口半接口系統(tǒng)兩者結合。不要指望一套策略打天下異構對接的本質就是分類處理。第二只讀賬號權限給最小。只給SELECT連表權限都收緊只開業(yè)務必需的那幾張表。這是對客戶系統(tǒng)零侵入的底線也是技術決策者向業(yè)務側證明安全性的憑證。第三沒有文檔的系統(tǒng)先用AI分析表結構再人工核驗關鍵表。幾百張表全靠人摸不現(xiàn)實全靠AI又不保險AI初篩加人工精修是效率和質量平衡點。第四只讀只解決取數(shù)語義統(tǒng)一必須跟上。取出來的數(shù)據不對齊對接工作只做了一半。把異構數(shù)據關聯(lián)到統(tǒng)一語義模型才是跨系統(tǒng)查詢和經營分析能跑通的關鍵。向量空間JBoltAI的實踐反復證明只讀路線是務實的起手式本體語義統(tǒng)一是收尾的關鍵缺了后者前者的取數(shù)價值發(fā)揮不出來。## 總結沒API不是異構對接的終點而是數(shù)據庫只讀路線的起點。對客戶系統(tǒng)零侵入、只架在現(xiàn)有系統(tǒng)之上讀數(shù)據這條路線繞開了接口缺失、字段不全、商業(yè)審批三重障礙。連文檔都沒有的老系統(tǒng)靠AI分析表結構也能把核心實體識別出來。但要清醒的是只讀路線只解決了連接層取出來的數(shù)據要真正可用后面還有語義統(tǒng)一這一道更難的關。異構系統(tǒng)對接不是接口通了就通了是連接、數(shù)據、語義三層都要打透數(shù)據庫只讀是務實的起手式本體語義統(tǒng)一是收尾的關鍵。