使用DeepSeek拯救数据中台

在数字化转型浪潮中，数据中台作为企业核心资产的"枢纽站"，却长期面临"建而难用"的尴尬境地——业务团队抱怨数据获取门槛高、技术团队困于复杂的数据治理任务，如何打通数据价值落地的"最后一公里"始终是行业痛点。

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 class MetadataAutoTagger: def __init__(self, api_key: str, business_context: str): self.client = openai.OpenAI(api_key=api_key) self.business_context = business_context # 公司业务背景说明 def generate_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": "业务说明" }} }} """ def tag_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)}") return None # 示例用法 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当成一个全能小助手，帮助自己解决问题和提效吧。