Amazon Quick Chat 多数据集主题最佳实践
本文为数据架构师、BI工程师和分析工程师提供了使用Amazon Quick Sight多数据集主题进行自然语言聊天探索的最佳实践。重点介绍了如何通过语义指导层(包括数据集和主题级别的自定义指令、同义词和字段描述)使生成式AI引擎能够自动编写SQL,从而实现跨数据集的外连接、联合、子查询等复杂查询,无需预先定义关系。文章还对比了定义关系与AI生成SQL两种模式,给出了八个具体最佳实践、反模式和示例。
Amazon Quick Sight的多数据集主题功能允许分析团队将多个数据集引入单个主题,为自然语言驱动的数据探索开辟了新路径。传统上,跨表查询需要数据工程师预先连接表并交付单一数据集。现在,Quick Sight提供了两种方式:定义显式关系键(在另一篇博文中讨论)或为生成式AI引擎配备足够的语义上下文,使其自行编写SQL。本文聚焦后一种方式——聊天驱动的AI生成SQL。
当您为主题配置聊天功能时,无需提前定义关系。相反,您编写一个包含数据集级自定义指令、主题级指令、字段同义词和字段描述的语义层。AI在查询时利用该上下文生成上下文感知的SQL。这使得外连接、联合、子查询、自连接、跨粒度比较和条件连接逻辑都变得触手可及,且对关系图没有结构限制。
本文面向构建或优化Quick Sight主题以实现自然语言聊天探索的数据架构师、BI工程师和分析工程师。您将了解:聊天驱动的SQL生成与定义关系主题的差异;用于构建所有元数据的层次框架“语义指导栈”;八个具体的最佳实践及其示例和反模式;处理复杂模式(外连接、多对多、递归层次、角色扮演维度和跨粒度比较)的技术;选择定义关系、纯语义指导或混合方法的决策框架;以及一个完整的端到端零售分析示例。
聊天与定义关系的区别
在深入最佳实践之前,理解Quick Sight两种多数据集模式的基本架构区别很有帮助。当您为主题定义显式关系时,Quick Sight构建一个逻辑连接图,并在查询时执行内连接。该图必须是有向无环图(DAG),最多支持12个数据集,产生确定性的结果。这适用于需要精确控制表组合方式的受控报表场景。
当用户通过聊天提问时,Quick Sight的生成式AI读取定义的关系或主题的语义层(指令、描述和同义词),并生成SQL来回答问题。AI决定查询哪些数据集、使用哪些列、合适的连接类型以及如何聚合结果。没有预连接图,AI基于意图而非结构操作。
定义关系是护栏:它们防止尝试不正确的连接。语义元数据是指导:它引导AI生成正确、上下文合适的SQL。两者都有价值,正确选择取决于场景。参见后文的决策框架部分。
定义关系和语义指导并非互斥。混合主题可以为核心事实到维度的连接定义关系,同时依赖自定义指令处理预定义图之外的探索模式。
语义指导栈
驱动Quick Chat的AI引擎在生成SQL时依赖七层元数据,共同构成语义指导栈。理解每一层是编写有效元数据的基础。
- 第1层:数据集输出;数据集——数据集级指令:定义每个数据集的粒度、用途、键和业务规则。
- 第2层:主题——主题级指令:定义跨数据集逻辑、消歧规则和默认连接行为。
- 第3层:数据集输出;字段——同义词:将业务词汇映射到技术字段名。
- 第4层:数据集输出;字段——字段描述:解释列语义、单位、空值性和有效范围。
- 第6层:数据集转换——列排除:移除噪声,如内部键、ETL时间戳和废弃字段。
- 第7层:数据集转换——计算字段和命名过滤器:预构建AI可直接引用的通用业务指标和分段定义。
每一层减少AI对您数据的不确定性。各层填充得越精确,合理解释SQL的空间就越窄,生成结果越准确。稀疏描述的多数据集主题会产生不可靠结果,原因并非AI能力不足,而是缺乏做出正确选择所需的信息。
最佳实践1:编写数据集级指令作为数据字典
数据集级自定义指令是AI与每个表的首次接触点,并为涉及该数据集的每个问题设定上下文。要包含:表用途和粒度、主键、外键提示、业务规则、已知边界情况和聚合规则。
例如,对于SALES_FACT数据集,好的指令应明确:“SALES_FACT包含每个订单行项目一行。主键:order_line_id。粒度:一个行项目对应一个订单上的一个产品。关键列:order_id链接到ORDER_HEADER_DIM.order_id等。收入=数量*单价-折扣金额。始终SUM收入。排除order_status='VOID'的行。表每晚UTC 02:00刷新。”
避免的反模式:过于泛泛的指令、嵌入原始SQL片段、相互矛盾的规则。
最佳实践2:编写主题级指令处理跨数据集逻辑
主题级指令告诉AI表之间如何关联、术语歧义时哪个数据集优先以及如何处理跨数据集计算。包括:概念关系、消歧规则、默认连接行为、多事实解析、跨域业务定义和层次导航。
例如,零售分析主题的指令块可指定:“SALES_FACT和RETURNS_FACT都通过customer_id链接到CUSTOMER_DIM,通过product_id链接到PRODUCT_DIM。当用户询问‘销售’时,使用SALES_FACT;询问‘退货’或‘退款’时,使用RETURNS_FACT;对于‘净销售额’,连接两者。优先使用事实表LEFT JOIN维度表,以避免静默丢失无匹配维度记录的事实。”
文章还提供了更多最佳实践,包括使用同义词、字段描述、列排除、计算字段、处理复杂模式以及决策框架,并附有完整的零售分析主题端到端示例。