NL2SQL 在超大规模数仓场景的架构突破与工程实践¶
Ch01.1440 NL2SQL 在超大规模数仓场景的架构突破与工程实践¶
📊 Level ⭐⭐ | 2.8KB |
entities/nl2sql-在超大规模数仓场景的架构突破与工程实践.md
NL2SQL 在超大规模数仓场景的架构突破与工程实践¶
WeChat-阿里技术 | 发布于 2026-07-21 | 评分入库 v×c≥49
核心内容¶
原创 薛飞跃 2026-07-21 18:18 浙江 关于搭建面向企业数仓的 NL2SQL 系统，以及用 Agent Skill 架构解决需要大量领域知识的问题，本文或许能够提供一些经验和参考 这是2026年的第 39 篇文章 （ 本文阅读时间：约 20 分钟 ） 01 前言 在高德的数据驱动运营体系中，产运同学有大量的日常取数需求：“昨天美食行业的 GMV 是多少”“按城市看一下上周的广告消耗”“本月新客订单数趋势如何”，等等。这些问题看起来不复杂，但要得到一个准确的答案，传统路径是：提交需求给 BI 分析师 → 分析师理解口径、写 SQL、跑数 → 返回结果。一个简单的取数请求，从提出到拿到答案往往需要数小时甚至跨天。 我们面对的数仓并不简单。高德的数仓覆盖交易、业财、广告、流量、内容、供给（门店）、商品、服务、搜索归因转化等 9 个业务域，涉及数千张 ODPS 表，同一个「收入」在广告域和业财域的口径完全不同，同一个"供给"在门店和商品两个粒度各有定义。这种业务复杂度，让「让 AI 帮你写 SQL」这件事从技术可行到业务可用之间，横亘着巨大的鸿沟。 我们基于 QoderWork Agent Skill 构建了一套 NL2SQL 智能取数系统，系统定位很明确：以元数据为权威、以规则为约束、以 LLM 为规划器、以 ODPS 为执行引擎。它是一个深度绑定业务数仓的智能体系统：理解高德的业务术语，知道每张表该怎么用、不该怎么用，能在口径歧义时主动澄清，能在结果返回时附上完整的口径说明。 这篇文章记录了系统从 V1 到 V2 的架构演进过程，以及在这个过程中沉淀下来的知识工程方法。
关键要点¶
相关实体¶
Agent Architecture Agent Orchestration Patterns Harness Engineering Framework