5.0
关注
AI SCORE
工具产品2026-08-01 03:53
AWS Glue 数据目录新增 Agent 体验功能
AWS ML Blog#AWS#数据目录
Editor brief · 编辑速览
Amazon Quick 引入自然语言查询数据资源并自动创建 Dataset 的 AI 工作流。对数据工程师的生产力有帮助，但应用面相对专业化。
Amazon Quick 引入自然语言查询数据资源并自动创建 Dataset 的 AI 工作流。对数据工程师的生产力有帮助，但应用面相对专业化。
随着组织积极采用 AI 驱动的分析，自然语言（Text2SQL）答案的价值，取决于其背后的业务上下文质量。我们正在进入这样一个阶段：语义丰富度（表和列的描述及其关系）必须直接从上游数据目录和语义工具中的创建位置，流入面向最终用户的 AI 产品。Amazon Quick 等产品不能再孤立运行。它们需要原生使用数据团队在 AWS Glue Data Catalog、Databricks Unity Catalog 等系统中维护的定义、关系和治理元数据，并基于这些信息进行推理。从孤立的元数据转向互联且能够感知目录的 AI，正是实现大规模智能分析的关键。
企业数据团队已经完成了最艰巨的工作。他们在 AWS Glue、Databricks Unity Catalog、Snowflake Horizon、Collibra 和 dbt 等上游目录平台上投入了大量资源。在这些平台中，他们细致地定义了表描述、列语义、主键和外键关系、术语表条目以及指标定义。
然而，在帮助最终用户（例如销售经理、市场总监和财务负责人）使用可投入生产的 AI 和可信仪表板方面，仍然存在一道巨大的鸿沟。
当数据维护人员（商业智能工程师、分析负责人和高级分析师）需要在 Amazon Quick 中为业务用户提供支持时，他们会面临三个相互叠加的挑战：
可发现性有限： 企业目录中有数千张表，要从中找出经过维护并获准用于报告的正确上游资产，如同大海捞针。你无法描述自己的需求，然后让系统替你找到相应资产。
语义碎片化与手动重建： 上游已经存在的丰富元数据（表和列的业务描述，以及主键和外键关系）无法直接流转过来。维护人员必须从头重新创建资产、重新定义描述，并手动协调各种定义。“收入”指的是总收入还是净收入？“活跃客户”指的是在 30 天内还是 90 天内完成过购买的客户？这些定义已经存在于上游，却需要手动重新录入。
获得洞察需要数周，而不是数小时： 手动发现与手动重建叠加在一起，意味着从数据转化为可操作洞察所需的时间会从数小时延长至数周。更糟糕的是，当上游定义发生变化时，在 Quick Datasets 中手动创建的语义会变得过时，从而造成语义漂移，久而久之便会削弱用户对 AI 答案和仪表板的信任。
问题不在上游。元数据已经存在，治理规则已经定义，关系也已经完成映射。
问题在于最后一公里：如何将丰富的目录上下文转化为经过维护且易于使用的体验，为最终用户提供有依据的 AI 答案和确定性的仪表板，让他们能够放心信赖。
今天，我们宣布推出 Amazon Quick 智能体式目录体验。这是一套由 AI 驱动的工作流，可以帮助数据维护人员快速定义上下文边界、继承上游语义，并大规模支持最终用户使用有依据的问答和可信仪表板。
这一体验的核心是 Quick Agent，其工作范围限定于目录上下文中的发现、创建和继承任务。它利用目录连接中的语义上下文，一目了然地汇总整个目录，以自然语言与客户对话，根据客户的使用场景呈现最相关的表和关系，并评估元数据的就绪情况。随后，只需通过一次对话进行确认，它便会自动创建 Catalog-Generated Datasets 和 Topics，并继承上游目录中有针对性的元数据。
无需手动配置，无需切换上下文，也无需花费数周进行设置。
维护人员无需再滚动浏览数千张表来寻找正确的表，而是可以直接使用自然语言。借助智能体式目录体验，维护人员只需描述自己的需求：
维护人员：“我是财务团队的高级分析师。我需要用于季度收入报告和成本分析的表。”
Quick Agent 会搜索整个目录，利用所有可用的元数据（包括业务描述、标签、Gold/Silver/Bronze 分类、质量评分、表健康评分和术语表条目），立即呈现最相关的表。不再需要手动浏览，也不必再靠猜测。
维护人员选择表后，Quick Agent 会通过一个引导式工作流，大规模一次性创建目录表示形式（Datasets）。默认创建路径为 Direct Query，因此上游目录仍然是唯一事实来源。继承了语义的 Datasets 会带有清晰的“Semantics Inherited”徽章，其元数据为只读状态。作者可以按需选择同步按钮来刷新继承的元数据，从而与目录保持一致。
Quick Agent：“正在创建 6 个 Catalog-Generated Datasets：revenue_by_region 已创建（DirectQuery，只读元数据）、cost_centers 已创建，gl_transactions 已创建。”
Quick Agent 会将目录中有针对性的元数据传递到它所创建的资产中。目前，为避免引入噪声并保持 Datasets 简洁，继承功能刻意聚焦于两个关键领域：
从表和列定义继承到 Datasets： 业务描述和列定义会直接继承到所创建的 Datasets 中，让维护人员和最终用户获得所需的语义上下文。
从主键和外键关系继承到 Topics： Agent 会检测关系，并利用这些关系建议和创建多数据集结构（Topics），同时预先配置星型和雪花型模式连接。
注意： 尽管发现过程中会使用所有可用的元数据（Gold/Silver 分类、质量评分、标签和健康评分）来寻找正确的表，但目前继承到 Datasets 中的内容会有意限定为表和列定义。我们计划逐步向 Datasets 添加更多元数据类型。
Quick Agent：“我检测到这些表之间存在 3 个关系，并创建了名为 ‘Finance Revenue Model’ 的 Topic，其中已预先配置星型模式连接。表和列定义已从上游目录继承。”
经过维护的 Datasets 和 Topics 可以立即使用：
提出问题： 使用新的 Datasets 发起问答对话。AI 智能体会利用继承的业务描述、术语表条目和质量评分，提供有依据的答案。
创建仪表板： 在完整语义上下文已经就位的情况下，构建确定性的可视化内容。
与最终用户共享： 将 Datasets 添加到 Space，并与业务用户共享，供他们进行自助式问答。
创建完成后，与这些 Datasets 和 Topics 关联的元数据会进入 Amazon Quick 语义存储，为 AI 驱动的问答提供重新排序和统一上下文支持。从连接目录到提出第一个业务问题，只需几分钟，而不再是几周。
这一体验建立在一项关键设计原则之上：Amazon Quick 是上游目录元数据的使用方，而不是一个专用目录。这意味着：
不复制数据： Catalog-Generated Datasets 使用 DirectQuery，不会复制或移动任何数据。
将元数据用于上下文： 继承的语义在 Amazon Quick 中为只读状态，并会进入语义存储，为重新排序和 AI 答案溯源提供支持。上游目录仍然是权威来源。
手动同步语义： 作者可以按需选择同步按钮来刷新继承的元数据。定时自动同步功能已列入产品路线图。
兼具透明度的可扩展性： Catalog-Generated Datasets 会将继承的语义显示为只读状态（标记为目录表示形式）。如果作者选择编辑 Dataset，Amazon Quick 会明确通知作者：编辑操作将创建一个自定义 Dataset，且语义同步将不再适用。这既赋予作者完全的控制权，也能在默认情况下维护目录完整性。
对其他目录平台的支持即将推出。
为了保持 Datasets 简洁且可直接用于生产，元数据继承功能有意聚焦于以下内容：
表的业务和技术描述。
列描述和显示名称。
数据类型和可空性。
术语表条目和同义词。
主键和外键关系。
关系定义和基数。
星型和雪花型模式模型。
以下是这项功能对下游业务用户的意义：
一位销售经理提问：“我们第四季度按区域划分的销售额是多少？”
在后台，AI 智能体会：
使用业务描述和术语表条目搜索 Catalog-Generated Datasets。
识别 sales.revenue_by_product 表（Gold，质量评分 98%）。
应用 Topic 中预配置的连接来组合相关维度。
遵循目录元数据中的个人身份信息（PII）脱敏规则。
在几秒内返回有依据、可信赖的答案。
无需手动配置数据集。管理员只需通过 Quick Agent 定义一次上下文边界，每位最终用户都能立即受益。
Agentic Catalog Experience 并非孤立存在。结合 Amazon Quick 更广泛的平台能力（包括与 Slack、Outlook、文档和知识库的集成），最终用户可以获得完整的企业上下文：
来自目录、通过 Catalog-Generated Datasets 提供的结构化数据。
来自文档、电子邮件和对话的非结构化上下文。
来自术语表条目和指标定义的业务规则。
这种统一的上下文能够提供可用于生产环境的 AI 答案，并以贵组织特有的数据和语义为依据。
要开始使用 Agentic Catalog Experience，请在 Amazon Quick 中创建与 AWS Glue Data Catalog 的数据源连接。建立连接后，Quick Agent 会通过单一的对话式工作流，引导你完成发现、架构探索和 Topic 创建。在本演练中，我们将连接到 Glue Data Catalog，并构建一个 Financial Analytics Topic。
在 Amazon Quick 中创建新数据源。从连接类型列表中选择 Glue Data Catalog（预览版），然后选择 Next。此连接用于获取元数据。借助此连接，Amazon Quick 可以使用表和列定义，以及团队已经在 AWS Glue 中维护的关系。
图 1：在 Amazon Quick 中选择 Glue Data Catalog 连接类型
Glue Data Catalog 连接需要与 Amazon Athena 连接配合使用。Glue 提供元数据，而 Athena 提供查询 Amazon Simple Storage Service（Amazon S3）中实际数据的路径。同时创建 Athena 数据源，以便 Amazon Quick 对底层数据运行查询。二者都创建完成后，Data sources 页面会并排显示两个条目：用于元数据的 Glue Data Catalog 数据源，以及用于数据的 Athena 数据源。
图 2：并排列出的 Glue Data Catalog 和 Athena 数据源
打开 GDC-Demo 数据源详情页面。在 Data connections 下，可以看到 Amazon Quick 用于查询数据的关联 Athena 数据源。选择 Explore data，启动限定于此数据源的 Quick Agent。
图 3：从数据源详情页面启动 Quick Agent
Quick Agent 面板会在屏幕右侧打开，并自动限定于 Glue Data Catalog 数据源。“Specific data”模式处于选中状态，“GDC-Demo”被固定为上下文边界。因此，该智能体只会呈现来自这个特定目录连接的元数据。
图 4：限定于特定目录连接的 Quick Agent
让智能体探索你的目录。智能体会概括展示可用的目录和数据库，让你快速了解 Glue Data Catalog 中已维护的内容。在本文中，我们使用“fa-demo”数据库作为示例，它是一个用于银行分析的 Finance Analytics Demo 星型架构。本演练旨在说明该功能的工作方式，并非一个完全真实的场景，因此你可以将相同步骤应用于自己的目录。
图 5：智能体汇总可用的目录和数据库
让智能体探索 fa-demo 数据库。智能体识别出一个经典的星型架构，其中包含 7 张表：2 张事实表（fact_transactions 和 fact_loans），以及 5 张维度表（dim_account、dim_date_transactions、dim_date_loans、dim_merchant 和 dim_txn_category）。这些表都作为外部表存储在 Amazon S3 中。智能体识别出该架构涵盖客户账户交易和贷款组合，并通过商户、交易类别和日期层级等维度提供支持。
图 6：智能体识别 fa-demo 数据库中的事实表和维度表
让智能体为 fa-demo 创建星型架构图。智能体会分析这些表，识别主键和外键关系，并呈现完整的逻辑数据模型及架构摘要。它会特别指出，dim_account 是连接两张事实表的共享一致性维度。选择 Create datasets & Topic，让智能体自动构建所有内容。
图 7：为 fa-demo 架构生成的逻辑数据模型
智能体会创建一个完全配置好的 Topic，其中所有 Datasets 和关系均已就绪。在此示例中，它创建了“Financial Analytics”Topic，其中包含来自 fa-demo 数据库的全部 7 个 Datasets，以及 6 个预配置的星型架构连接。每个 Dataset 都继承了相应的业务描述，事实表与维度表之间的连接关系也会自动得到验证。该 Topic 可立即用于自然语言问答，因此你可以提出诸如“What is the total transaction amount by merchant category?”或“Show me delinquent loans by risk rating.”之类的问题。
图 8：完全配置好的 Financial Analytics Topic
现在，让我们看看从 Glue Data Catalog 创建的 Financial Analytics Topic 在实际使用中的表现。将该 Topic 固定为上下文后，最终用户可以使用自然语言提问，并立即获得有依据的答案。例如，用户可以询问“Total transaction amount by merchant category”，智能体会返回按排名排列的明细及关键要点。随后，用户可以继续询问“Delinquent loans by risk rating”，查看包含洞察的风险级别摘要。由于 Datasets 和关系继承自目录，每个答案都以在上游定义的可信架构、连接和业务定义为依据。这正是 Agentic Catalog Experience 的强大之处：管理员只需定义一次上下文边界，之后每位最终用户都可以通过对话方式探索数据。
图 9：针对 Financial Analytics Topic 提出自然语言问题
相同的体验也适用于 Databricks Unity Catalog。下面是一个快速示例，展示从配置连接到创建 Datasets 和 Topic 的完整流程。
创建 Databricks Unity Catalog 数据源，然后选择 Explore data 启动 Quick Agent。智能体会汇总目录，并在一次确认后创建 Datasets 和 Topic，其中的星型架构连接已配置完毕。
图 10：从 Databricks Unity Catalog 创建 Datasets 和 Topic
Topic 准备就绪后，最终用户可以提出跨越多张相关表的复杂问题。在此示例中，智能体通过 Topic 关系进行跨表连接，回答“Top 5 brands by revenue per region”，并返回有依据的可视化结果。
图 11：回答跨越 Topic 关系的多表问题
管理员能够以过去所需时间的一小部分，交付可信数据、完整的企业上下文，以及可用于生产环境的 AI 答案和仪表板。最终用户则能获得有依据且值得信赖的答案，这些答案由具备完整语义血缘的 Gold 标准数据提供支持。
从数周的手动配置，缩短为数分钟的引导式对话。
这就是 Amazon Quick 中的 Agentic Catalog Experience。