使用DeepSeek拯救資料中臺

OSCHINA
↑點選藍字 關注我們
在數字化轉型浪潮中,資料中臺作為企業核心資產的“樞紐站”,卻長期面臨“建而難用”的尷尬境地 —— 業務團隊抱怨資料獲取門檻高、技術團隊困於複雜的資料治理任務,如何打通資料價值落地的“最後一公里”始終是行業痛點。
PowerData 社群主理人李奇峰給出了一個充滿技術想象力的答案:透過深度結合 DeepSeek 大模型的邏輯推理與結構化資料處理能力,重構資料中臺的技術棧。
3 月 22 日,PowerData 社群主理人李奇峰將出席 OSC 源創會南京站,並發表《使用 DeepSeek 拯救資料中臺》主題分享,探討如何藉助大模型通用化與生成式的資料處理能力,結合資料中臺中的落地痛難點,對其進行針對性的最佳化改造。
在活動正式開始前,我們也和李奇峰聊了聊一些“入門級”問題,感興趣的開發者可週六到活動現場,與李奇峰交流探討關於資料中臺的建設問題。
報名連結:https://www.oschina.net/event/2423811
OSCHINA:在眾多大模型中為何選擇 DeepSeek 作為資料中臺改造的核心技術?與其他開源模型相比,DeepSeek 在資料處理場景下有哪些優勢?
李奇峰:我作為一個數據中臺的從業者,核心訴求還是提升資料中臺本身的能力。對於大模型的瞭解並不深入,其只是我的一個工具而已。所以從工具的屬性來說,我選擇 deepseek 主要有以下幾點原因:
成本:無論是訓練成本、還是推理成本,相較於其他模型都有顯著降低。同時支援國產化硬體,在合規性方面也有保證。
熱度:在風口到來的時候,不說乘風而飛,但是至少還是需要蹭一下的。
能力:DeepSeek R1 是 LMSYS Chinese 榜單最強的 from China 的模型,V3 是上面榜單中開源的最強非 Reasoner 模型,基礎能力優越。同時相較於其他模型,DeepSeek 在邏輯推理 + 結構化資料解析處理的能力優秀,同時其支援的上下文視窗較大,在資料血緣解析、資料分類分級、資料質量治理等任務中,其準確性較其他模型都有顯著提升。
OSCHINA:開發者最關心的部署成本問題:在私有化部署場景下,DeepSeek 模型針對資料中臺做了哪些輕量化改造?是否支援量化壓縮後的模型在常規 GPU 伺服器叢集執行?
李奇峰:Deepseek 不會為企業應用場景訓練各種量化模型的,市面上的量化模型都是社群和開發者上傳的。如果為了降低部署成本,採購算力伺服器之前先測試各個量化模型的能力能否滿足應用場景,確定好使用哪版量化模型後,根據視訊記憶體去採購價效比最高算力伺服器,推理伺服器建議買 Nvdia 遊戲卡。
OSCHINA:能否用具體程式碼片段說明 DeepSeek 如何與資料中臺元件整合?例如如何透過 API 呼叫實現“自然語言轉資料服務介面”這類典型場景,過程中需要哪些中介軟體做適配?
李奇峰:下面是一個非常簡單的透過大模型進行資料自動標註的程式碼:
import

openai

import

pandas

as

pd

import

json

from

typing

import

List, Dict

classMetadataAutoTagger:
def__init__(self, api_key: str, business_context: str):

self.client = openai.OpenAI(api_key=api_key)

self.business_context = business_context

# 公司業務背景說明

defgenerate_prompt(self, table_name: str, columns: List[str]) -> str:
"""構造大模型提示詞"""
return

f"""

# 任務說明

根據提供的元資料和業務背景,生成資料資產的業務標註資訊,要求:

1. 業務名稱:體現資料在業務中的核心作用

2. 業務型別:交易型/分析型/主資料/日誌型...

3. 業務實體:對應業務物件(客戶/訂單/產品...)

4. 分類分級:按公司資料分類分級標準

5. 欄位說明:用業務語言解釋欄位含義
# 業務背景

{self.business_context}

# 待標註元資料

表名:

{table_name}

欄位列表:

{', '.join(columns)}

請用JSON格式返回結果,結構如下:

{{

"table_name": "

{table_name}

",

"business_name": "",

"business_type": "",

"business_entity": "",

"data_classification": "",

"columns": {{

"column1": "業務說明",

"column2": "業務說明"

}}

}}

"""

deftag_metadata(self, metadata_df: pd.DataFrame) -> pd.DataFrame:
"""批次處理元資料"""

results = []

for

_, row

in

metadata_df.iterrows():

response = self._call_llm(row[

'table_name'

], row[

'columns'

])

if

response:

results.append(response)

return

pd.DataFrame(results)

def_call_llm(self, table_name: str, columns: List[str]) -> Dict:
"""呼叫大模型API"""
try

:

prompt = self.generate_prompt(table_name, columns)

response = self.client.chat.completions.create(

model=

"gpt-4"

,

messages=[{

"role"

:

"user"

,

"content"

: prompt}],

temperature=

0.2

,

response_format={

"type"

:

"json_object"

}

)

return

json.loads(response.choices[

0

].message.content)

except

Exception

as

e:

print(

f"Error processing {table_name}: {str(e)}"

)

returnNone

# 示例用法
if

__name__ ==

"__main__"

:

# 初始化配置

config = {

"api_key"

:

"your_openai_key"

,

"business_context"

:

"某電商公司,主要業務包含商品交易、使用者畫像、訂單履約等..."

}

# 示例元資料(實際從資料庫或檔案讀取)

sample_data = {

"table_name"

: [

"user_info"

,

"order_detail"

],

"columns"

: [

[

"user_id"

,

"registration_date"

,

"last_login"

],

[

"order_id"

,

"product_sku"

,

"payment_amount"

]

]

}

metadata_df = pd.DataFrame(sample_data)

# 執行自動標註

tagger = MetadataAutoTagger(**config)

result_df = tagger.tag_metadata(metadata_df)

# 儲存結果

result_df.to_csv(

"tagged_metadata.csv"

, index=

False

)

print(

"標註結果示例:"

)

print(result_df.head())

典型輸出結果如下:

{

"table_name"

:

"user_info"

,

"business_name"

:

"使用者基本資訊表"

,

"business_type"

:

"主資料"

,

"business_entity"

:

"使用者"

,

"data_classification"

:

"PII/LEVEL-2"

,

"columns"

: {

"user_id"

:

"使用者唯一識別符號,用於跨系統使用者識別"

,

"registration_date"

:

"使用者註冊電商平臺的具體日期"

,

"last_login"

:

"記錄使用者最近一次登入平臺的時間"

}

}

OSCHINA:在處理非結構化資料場景中(如日誌解析 / 圖片 OCR),DeepSeek 與傳統 ETL 工具的結合方案是怎樣的?
李奇峰:非結構化資料基本用不上 Deepseek,月更好的選擇,圖片用多模態 LLM 可以總結,圖片型別的文件用 OCR,OCR 一般用百度 paddle,表格解析有開源的讀光模型。這些都是資料處理,處理完才是抽取 – 轉換 – 載入(Sqoop、Flume、Cannel、DataX)到下游。
OSCHINA:在資料關係複雜的中臺環境,如何透過 prompt engineering 確保大模型輸出的 SQL/SHELL 指令碼符合安全規範?是否有開發自定義的語法校驗中介軟體?
李奇峰:提示詞來確保大模型輸出的 SQL/SHELL 指令碼符合安全規範,是有問題的。LLM 是用來理解和處理自然語言的,更多的是互動上的提升。
推薦使用 sqlcheck 和 shellcheck 這種工具,指令碼安全做的還可以。
OSCHINA:遇到模型“幻覺”導致的資料質量問題,是否有設計技術兜底方案?
李奇峰:可以透過 RAG + 外掛知識庫的方式最佳化幻覺問題。
OSCHINA:PowerData 社群在構建 DeepSeek 外掛生態方面有哪些規劃?
李奇峰:後續會實現一些 MCP 介面。
OSCHINA:對想參與資料中臺智慧化改造的開發者,建議從哪些具體模組入手貢獻?
李奇峰:可以先嚐試進行 text to sql 的功能開發,具體入門教程可參考此篇文章:https://mp.weixin.qq.com/s/Wk9OmB80JC7NFG2T7VjNRA
OSCHINA:在 Data+AI 的架構演進中,您認為未來 3 年資料中臺的核心元件會發生哪些顛覆性變化?傳統資料倉庫工程師需要優先補充哪些 AI 工程化能力?
李奇峰:顛覆性變化談不上,資料中臺的核心還是資料資產化、服務化,一切的功能目標都是往這個方向走。隨著大模型的快速進化與深度結合,資料中臺可能會在以下能力進行進化:
  • 自然語言互動:大模型出色的自然語言互動能力可準確理解使用者意圖,大幅提升數 據查詢分析的便利性,提升使用者體驗
  • 智慧洞察分析:大模型可分析文字、圖表等多維資料,智慧歸因、預測、總結,降 低員工利用資料、分析資料的門檻
  • 整合大模型服務鏈路:整合 LangChain、向量檢索、finetune 等大模型應用所 需技術元件,提升企業除錯、使用大模型的效率
傳統數倉需要補充哪些 AI 工程化能力?這個我們社群之前內部討論過,工程化能力談不上,更多的還是把 AI 當成一個全能小助手,幫助自己解決問題和提效吧。
🔥 報名連結:https://www.oschina.net/event/2423811
⏰ 時間:03-22 14:00 至 18:00
🚗 地點:南京瑞瀾庭院酒店(南京秦淮區瑞金路街道解放路 46 號)
END
熱門文章
分享在看點贊~Orz

相關文章