airCloset 991張表困局：一個(gè)日本CTO用自然語言"拆

日本最大的服裝租賃平臺(tái)airCloset，數(shù)據(jù)庫里躺著991張表、15個(gè)Schema、橫跨11個(gè)SQL庫和6個(gè)MongoDB實(shí)例。CTO Ryan Tsuji上周公開了一個(gè)內(nèi)部工具——DB Graph MCP，讓客服用大白話就能查生產(chǎn)數(shù)據(jù)。這不是Demo，是跑了10年的老系統(tǒng)真實(shí)改造。

一個(gè)具體場景：用戶App顯示"退貨已完成"，倉庫到底收到貨沒有？

答案分散在4張表里，跨兩個(gè)數(shù)據(jù)庫，中間靠一個(gè)varchar字段硬連，沒有外鍵。全公司能理清這條路徑的人，一只手?jǐn)?shù)得過來。有人休假，調(diào)查就卡死。

這就是"數(shù)據(jù)民主化"最樸素的痛點(diǎn)：連接關(guān)系只存在特定人腦子里。

從"人形接口"到自然語言：工具設(shè)計(jì)拆解

Ryan Tsuji把解決方案拆成兩層。DB Graph是底層的元數(shù)據(jù)圖譜，把表、列、關(guān)系全部向量化；DB Graph MCP是暴露給Claude Code的接口層，遵循Anthropic的模型上下文協(xié)議（MCP，Model Context Protocol）。

核心工具只有三個(gè)。search_tables做語義檢索，輸入"return processing confirmation"，返回相關(guān)表及關(guān)系路徑；get_table_details拉取指定表的列信息、樣本值、關(guān)聯(lián)表；execute_sql執(zhí)行只讀查詢，帶權(quán)限管控。

工具返回格式經(jīng)過精心設(shè)計(jì)。search_tables會(huì)給出匹配分?jǐn)?shù)、表用途描述、關(guān)聯(lián)路徑示意圖；get_table_details包含列名、數(shù)據(jù)類型、是否可為空、樣本值分布、關(guān)聯(lián)表及連接字段；execute_sql返回結(jié)果集的同時(shí)，附帶執(zhí)行計(jì)劃和行數(shù)估算。

Ryan Tsuji特別強(qiáng)調(diào)：所有工具都返回結(jié)構(gòu)化數(shù)據(jù)，而非自然語言描述。這讓LLM能基于確定格式做二次推理，而非解析模糊的文本回答。

圖譜構(gòu)建：10年技術(shù)債的自動(dòng)化梳理

991張表的關(guān)系圖譜怎么建？airCloset的做法是分層掃描。

第一層讀數(shù)據(jù)庫元數(shù)據(jù)：表名、列名、主外鍵約束、索引定義。第二層分析查詢?nèi)罩荆崛「哳lJOIN模式——哪些表經(jīng)常被一起查，哪些字段頻繁用于關(guān)聯(lián)。第三層人工標(biāo)注關(guān)鍵業(yè)務(wù)路徑，比如上述退貨場景的四表鏈條。

三層數(shù)據(jù)融合后，用向量模型編碼。表和列的描述文本、業(yè)務(wù)標(biāo)簽、關(guān)聯(lián)路徑全部嵌入同一空間。語義搜索時(shí)，"return processing"能命中receive_record表的status字段，即使表名里完全沒有"return"字樣。

一個(gè)細(xì)節(jié)：airCloset把varchar匹配關(guān)系也納入圖譜。warehouse_order_code到shipping_order_code的跨庫關(guān)聯(lián)，原本是"隱式知識(shí)"，現(xiàn)在成了顯式邊。

這解決了老系統(tǒng)最頭疼的問題——沒有外鍵約束的"軟關(guān)聯(lián)"大量存在，新人根本無從下手。

安全與權(quán)限：生產(chǎn)數(shù)據(jù)的"只讀沙箱"

讓客服直接查生產(chǎn)庫，聽起來像事故預(yù)告。Ryan Tsuji的解法是多層隔離。

執(zhí)行層用只讀副本，物理隔離寫操作。權(quán)限層按角色分配Schema可見性——客服只能看aircloset和bridge，工程師按項(xiàng)目開放更多。查詢層加敏感字段脫敏，手機(jī)號(hào)、地址自動(dòng)哈希。審計(jì)層全量記錄自然語言提問、生成的SQL、返回行數(shù)。

一個(gè)設(shè)計(jì)選擇：execute_sql拒絕任何包含UPDATE/DELETE/INSERT的語句，不是正則過濾，而是解析AST（抽象語法樹）后白名單校驗(yàn)。Ryan Tsuji提到，曾有工程師試圖用CTE繞過限制，被AST掃描攔下。

脫敏規(guī)則也進(jìn)圖譜。客服查user表，看到的phone列是"138****1234"格式；工程師申請(qǐng)后，同一查詢返回完整值。權(quán)限差異體現(xiàn)在工具返回的樣本值里，LLM自動(dòng)適配。

實(shí)際效果：從"等人"到"直接問"

Ryan Tsuji給了一組內(nèi)部數(shù)據(jù)。退貨狀態(tài)核實(shí)類問題，平均解決時(shí)間從4.2小時(shí)降到11分鐘。不是查詢變快了，是"找到該問誰、等對(duì)方有空、再口述教一遍"的循環(huán)被砍掉。

更隱蔽的變化是提問方式。以前客服的描述是"用戶說退貨完成了但倉庫沒收到"，工程師需要翻譯為"查aircloset.delivery_order.status和bridge.receive_record.status的關(guān)聯(lián)"?，F(xiàn)在客服直接復(fù)制用戶原話丟給Claude Code，中間翻譯層消失。

一個(gè)意外發(fā)現(xiàn)：圖譜暴露了歷史設(shè)計(jì)問題。Ryan Tsuji團(tuán)隊(duì)發(fā)現(xiàn)，"return"相關(guān)邏輯分散在7個(gè)Schema、23張表里，有些是2015年遺留的命名，有些是新業(yè)務(wù)硬接的?？梢暬?，重構(gòu)優(yōu)先級(jí)變得清晰。

這套系統(tǒng)目前只供內(nèi)部使用，但Ryan Tsuji把MCP Server的實(shí)現(xiàn)細(xì)節(jié)全部開源。技術(shù)棧基于Python，圖譜存儲(chǔ)用Neo4j，向量檢索用pgvector，LLM層對(duì)接Claude 3.5 Sonnet。

他提到一個(gè)未解決的 tension：圖譜更新頻率。元數(shù)據(jù)變化實(shí)時(shí)同步，但查詢?nèi)罩镜腏OIN模式分析是T+1，人工標(biāo)注更是季度級(jí)。新表上線后，語義搜索可能"看不見"——直到有人手動(dòng)標(biāo)注或它出現(xiàn)在足夠多的查詢里。

10年積累的數(shù)據(jù)架構(gòu)，能用3個(gè)工具、自然語言接口重新組織。但"隱式知識(shí)"的顯式化，究竟能自動(dòng)化到什么程度？Ryan Tsuji在文末留了這個(gè)問題——那些最復(fù)雜的跨系統(tǒng)關(guān)聯(lián)，最終仍需老工程師的判斷，還是會(huì)被查詢?nèi)罩镜慕y(tǒng)計(jì)規(guī)律逐步捕獲？