AWS发布系列教程：用AtScale、Denodo、Strategy Mosaic为Agent接语义层
AWS机器学习博客连续发布三篇技术文章，分别演示以Stardog、Denodo、Strategy Mosaic和AtScale作为语义层，让托管在Amazon Bedrock AgentCore上的Strands Agent通过MCP查询企业数据，并按调用者身份执行行级、列级权限。这些文章描述的是参考架构与部署步骤，未公布效果数据。
AI解读：”它们分别以不同语义层产品回答这个问题。
Strand与Denodo的方案在查询时联邦多个数据源：Denodo把Amazon Aurora、Amazon Redshift和本地PostgreSQL的查询计划推送到各自引擎，在Denodo内合并结果，数据不在源之间移动。
AtScale的方案先把分析数据集中到Amazon Redshift Serverless，再以YAML格式的语义模型（SML）定义维度和度量，查询被改写为Redshift原生SQL，并可命中预建聚合表。
三篇教程都强调把连接关系、指标定义和行/列过滤条件放在语义层内，而不是写进Agent提示词；用户身份从企业IdP经AgentCore传递到语义层，权限按调用者评估。
来源称自动聚合管理能让Agent产生的高频查询命中汇总表，从而加快返回；但没有给出耗时或成本对比数据。
三篇文章均为AWS官方博客教程，带有产品演示性质，公司说法需与独立评测区分。
AWS机器学习博客近期发布三篇系列技术文章，演示如何在Amazon Bedrock AgentCore上托管Strands Agent，并通过Model Context Protocol（MCP）让Agent查询由Denodo、Strategy Mosaic和AtScale等产品构建的语义层。三篇文章沿用同一套客户 360 示例，回答“按生命周期消费额排名前 20 的客户中，哪些尚未加入奖励计划”这一问题，但各产品的数据接入与查询方式不同。
这些文章由AWS员工与厂商人员合写，属于参考架构和分步部署教程，并附有代码与配置说明。文章描述的是单套演示环境的搭建方式，未公布生产环境的性能、成本或安全审计结果。
Denodo：跨引擎联邦查询
第二篇文章以Denodo Platform作为语义层，把Amazon Aurora、Amazon Redshift和一台本地PostgreSQL集群映射为六个基础视图，再组合出customer_360派生视图和lifetime_customer_value指标视图。Denodo称这种模式为数据虚拟化，查询不预先物化跨库连接。
Agent使用Denodo的SQL方言VQL发起查询。文章给出的执行计划显示，Denodo将客户档案连接推送到Aurora，将消费汇总推送到Redshift，将奖励账户投影推送到本地PostgreSQL，最后在Denodo内按cid合并结果并做Top-N过滤。
访问控制由Global Security Policy在查询时执行，按调用者身份对带标签的列（如ssn、card_num）和行应用过滤。文章称数据不在源系统之间移动。
- 来源：AWS Machine Learning博客，作者Suntosh Murthy
- 数据源：Aurora、Redshift、本地PostgreSQL
- 查询语言：VQL
- 部署选项：Denodo Agora托管服务，或在EC2/EKS上自管
Strategy Mosaic：两个关联模型
第三篇文章使用Strategy Mosaic，将分析侧数据建为Purchase模型（Amazon Redshift），运营侧建为Customer模型（Amazon Aurora），两个模型通过Customer和Time属性关联。Mosaic不跨引擎联邦行数据，而是向每个源推送原生SQL，再在Mosaic引擎内合并中间结果。
指标定义支持基础、带命名过滤条件的进阶指标、复合指标和时间智能指标。文章举例，Customer Lifetime Spend使用层级限定符，确保无论查询如何切片都按客户全量历史计算。
Mosaic以MCP、JDBC/ODBC over Trino、XMLA和REST四种协议发布同一套定义。文章称只有经过认证的模型才能通过MCP服务器访问，行级和对象级安全按调用者评估。
- 来源：AWS Machine Learning博客，作者Zhili Cheng等
- 数据源：Amazon Redshift与Amazon Aurora
- 关联键：Customer、Time
- 认证要求：仅认证模型可经MCP访问
AtScale：单仓库维度模型与聚合管理
第四篇文章使用AtScale，先把分析数据集中到Amazon Redshift Serverless，再以YAML格式的Semantic Modeling Language定义数据集、维度、层级、事实、度量和计算度量，全部文件纳入Git版本管理。文章称同一模型可同时通过SQL、XMLA和MCP三种协议提供查询。
AtScale的AI Computation Engine将查询改写为Redshift原生SQL；其聚合管理器会观察查询模式，在仓库内预建汇总表，并将匹配的查询透明地路由到汇总表。文章称Agent发起的查询量高于人工分析，聚合管理是让这类负载可行的机制，但没有给出具体加速倍数。
权限方面，AtScale在查询时执行基于角色的访问控制、行安全和透视（perspective）范围限制。文章还提到，审计记录会同时保存LLM生成的维度SQL和AtScale改写后的仓库SQL，以及查询是否由聚合表服务。
- 来源：AWS Machine Learning博客，作者Frank Lapolito
- 基准版本：AtScale C2026.7
- 部署方式：Amazon EKS上的AtScale Helm chart
- 数据集中方式：AWS DMS或Aurora zero-ETL复制到Redshift
共同的身份与权限链路
三篇文章采用相同的入站与出站路径。客户端请求经AgentCore Gateway校验JWT后进入AgentCore runtime，由Amazon Bedrock上的Anthropic Claude Sonnet 4.6解析问题并规划查询。出站时，MCP服务器注册为Gateway目标，AgentCore Identity将用户令牌换成面向语义层的凭证。
文章共同强调，Agent本身不接触底层数据源的凭证，连接关系、指标定义和过滤条件存放在语义层而非提示词中。这一设计是否在实际部署中降低越权风险，文章未提供测试数据。