用自然语言建数仓：AI重构数仓开发全流程

AI 如何改变数仓开发方式

传统数仓开发已经形成一套稳定流程：业务需求进入后，依次完成需求分析、数据接入、数据建模、SQL 开发、调度配置、测试发布和结果验证。问题也很明确：开发人员需要掌握多种 SQL 方言以及 Java、Python、建模和调度等技能；需求从提出到落地链路长；任务故障、数据质量和性能调优持续消耗人工；指标口径、字段语义和业务逻辑又往往散落在人员经验和零散文档中。

AI 带来的变化，不是取消这些环节，而是改变完成这些工作的方式。自然语言可以成为新的开发入口，由 AI 辅助建模、生成 SQL、配置调度，进一步参与数据质量、语义治理和作业诊断；同时，把开发过程中的规则、口径和知识沉淀为可复用资产，最终服务自然语言问数。

在云器的产品架构中，底层仍是统一的 Lakehouse，负责结构化、半结构化和非结构化数据的存储与处理。向上提供三类入口：Studio 面向人，JDBC、Java SDK、Python SDK 等面向应用，ClickZetta CLI（CZ-CLI）面向 Agent。平台上内置数据工程 Agent 和数据分析 Agent，并通过 AI Gateway 统一管理模型接入、模型路由、API 密钥和版本等能力。

这样，一套 Lakehouse 可以同时服务人、应用与 AI Agent，共享同一份数据和同一套权限。

端到端流程被拆成两个阶段：前半段完成需求理解、数据建模、数据准备、质量检查和语义层建设；后半段进入日常治理，业务人员持续问数，问题反馈再回到语义治理与评测，形成循环。

数据工程 Agent：从需求理解到数据准备

演示使用一个虚构的“沐林咖啡”连锁零售场景。需求中包含全国门店、自营与联营、会员、SKU、优惠券等业务要素，并预设业务波动和异常，用于验证从建仓到问数的完整链路。

第一步交给数据工程 Agent。它面向数据工程师，覆盖数据集成与同步、数据开发与调度、SQL 转换与流式计算、数仓建模与语义层、数据质量与运维诊断、探索分析与资源管理等环节。传统方式下需要在开发界面逐项创建任务、写 SQL、配置调度；现在可以直接提交需求文档，让 Agent 先理解业务画像、数据模型、数据规模和异常设计，再生成 DDL、创建任务并准备数据。

需求文档被放入任务目录后，Agent 先完成需求理解和建模，再生成相关 SQL 与任务。

为了完整展示流程，样例数据由 Agent 生成；真实生产环境中更常见的做法是先通过数据集成接入已有数据源，再根据业务逻辑生成 DWD、DWS、ADS 等下游加工链路。核心变化在于，开发人员不再需要手工完成每一个界面动作和代码草稿，而是把业务逻辑交给 Agent 执行，再对结果进行确认。

最终准备出 5 张维度表和 5 张事实表，总量约100 万行，同时定义12 个核心指标和11 个参考 SQL，作为后续分析和治理的基础。

CZ-CLI：先治理数据质量，再创建分析域

数据准备完成后，下一步不是立即问数，而是先处理数据质量。CZ-CLI 把 SQL 执行与数据探索、Studio 任务开发与调度、数据集成与实时同步、任务运维诊断、数据质量校验以及数据分析 Agent 的调用统一到一个命令行入口中。它本身也可以作为 Agent 使用，或者作为其他智能体的子 Agent，被外部开发工具和业务智能体调用。

在样例中，CZ-CLI 先扫描数据质量，识别订单时间、优惠券核销和门店缺货等问题，并给出对应的检查与修复过程。

订单时间原本全部停留在 00:00:00，修复后98.3%的记录包含非零分钟或秒；优惠券数据原先无法形成有效核销关联，修复后核销率为13%，即15,573 / 119,989，并补齐 coupon 与 order 的双向关联；缺货数据原本只有2,971条缺货事件，没有正常状态作为分母，补入18,160条正常记录后，可以计算约14.1%的断货率。

这里的“修复”并不意味着生产环境把业务判断完全交给 AI。质量规则中既有通用规则，也有按行业和业务沉淀的规则，可以作为 Skill 持续扩充。AI 负责发现问题、分析影响并生成修复建议，真实场景仍需要数据开发人员确认业务逻辑，再执行修改。

完成第一轮数据质量治理后，开始创建分析域。数据分析 Agent 面向自然语言分析，不要求业务人员知道 SQL 和物理表名；管理员负责分析域、语义层、指标和知识的建设。CZ-CLI 可以基于已有 Schema 一句话创建分析域，自动加载相关表，并识别字段语义、表关联关系和分析上下文。

分析域创建后还要进行冒烟测试。表能够加入分析域并不等于已经具备可靠的问数能力，关键在于表之间的关系、字段类型、可过滤维度和指标口径是否正确。CZ-CLI 可以继续创建域级提示词和基础指标，也可以根据已有指标文档批量生成指标。对于新业务域，一部分基础指标可以直接从表结构和业务语义中生成，再由人工补充复杂口径。

语义层治理：从基础问数到复杂业务口径

基础问数跑通后，重点转向语义层质量。首先对分析域进行评估，检查字段语义是否一致、维度和指标标记是否正确、表关联是否缺失、关键指标是否遗漏。问题确认后，可以通过 CZ-CLI 修改别名、Comment、关联关系、字段语义类型或指标定义，再用实际问题做验证。

简单指标之外，还需要处理复杂业务逻辑。答案构建器通过 SQL 的声明式表达能力，把复杂计算固化成可复用模板；知识库则承载业务口径、场景规则和业务知识。已有文档可以直接用于生成知识库，没有现成文档时，也可以先基于 Schema、表关系和业务内容生成基础知识，再持续补充。两者共同为复杂问数提供更明确的上下文和计算约束。

语义层不是一次建设后就保持稳定。新增表、字段、指标或业务场景，都可能重新引入歧义。演示重点展示了三类二义性：同名异义，例如门店城市与会员常驻城市都叫 city；同义异名，例如优惠券渠道和订单渠道对同一业务渠道采用不同字符串；粒度混淆，例如 discount_amount 在订单表和订单明细表中的聚合层级不同。危险之处在于，这类 SQL 往往可以正常执行，只是结果并非用户真正想要的答案。

除了二义性，还有更隐蔽的逻辑问题。比如指标公式没有按业务口径过滤订单状态；被标记为维度的字段几乎没有区分度；同一业务实体在不同表中的数据值不一致；同类字段的语义类型标记存在残余。样例中，campaign_tag 和 product_family 的 NULL 率分别达到98%和95%，属于典型“死维度”；stockout_flag 的语义标记不一致，则会影响按断货状态进行 GROUP BY 分析。

用真实问题和评测集形成持续回归

这些问题通过“发现—确认—修复—验证”的方式处理。CZ-CLI 和数据分析 Agent 先扫描语义层，给出问题清单、影响和建议；业务逻辑确认后，再修改指标公式、字段描述、关联关系和语义标记。目标不是追求一次性自动化，而是降低排查成本，把原来依赖人工逐表检查的工作转成可重复执行的治理流程。

治理完成后，需要用真实问题验证结果。演示中构造 10 个业务问题，覆盖单均毛利、毛利率、GMV、渠道核销率、触达点击率和断货率等指标，通过预期值、Agent 回答和判定结果逐项检查。

验证后的问题继续沉淀为评测集，后续可以定时运行，或在模型、表结构、字段和业务逻辑变化后重新回归。

在随后的一次日常评测任务中，10 条样本全部执行完成，通过率为80%。这也说明语义层治理不是“建完即结束”：业务人员的正确问答可以沉淀为基线，错误问答通过反馈进入治理流程，修复后再加入回归集。随着问题不断积累，分析域形成持续的质量闭环。

回到完整链路，需求进入后先由数据工程 Agent 完成理解、建模和数据准备，再由 CZ-CLI 处理数据质量和语义构建；进入日常阶段后，数据分析 Agent 承接业务问数，管理员围绕语义问题持续评测与治理。

数据工程 Agent 负责 SQL 开发、数仓建模、调度发布和运维诊断；数据分析 Agent 为业务人员提供自然语言问数，并承载分析域、指标和语义能力；CZ-CLI 则连接数仓、Studio 与数据分析 Agent，作为可程序化调用的统一接口。三个 Agent 围绕同一个 Lakehouse 串成一条协作链路。

自然语言建数仓的重点，不只是“用一句话生成 SQL"。更完整的路径是：需求进入后用 AI 建模和开发，用规则和 AI 做数据质量治理，再建立分析域、指标、答案构建器和知识库，随后持续识别语义二义性与隐性问题，并通过真实问题和评测集做日常回归。代码编写和重复操作被更多交给 AI，业务口径判断、修复确认和最终决策仍然保留在人这一侧。