AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。
In the first post in this series, we built a semantic layer on AWS using Stardog’s knowledge graph over Amazon Aurora and Amazon Redshift. We ran a Strands agent on Amazon Bedrock AgentCore against that layer. The second post kept the same customer 360 (C360) pattern and swapped in Denodo’s data virtualization platform, extending the source mix to include an on-premises PostgreSQL cluster. This post uses the same C360 pattern again, with AtScale as the semantic layer. AtScale takes a different shape from the first two. The semantic model is dimensional (dimensions, hierarchies, and measures) rather than a graph of triples or a set of views. AtScale authors the model in the Semantic Modeling Language, an open, YAML-based specification versioned in Git, and exposes it simultaneously, from a single deployed model, over three protocols: SQL, XML for Analysis (XMLA), and the Model Context Protocol (MCP). The Strands agent and the business intelligence (BI) tools the enterprise already uses get the same computed answer from the same definitions. The rest of the pattern carries over from the earlier posts. A foundation model on Amazon Bedrock (Anthropic Claude Sonnet 4.6 for the walkthrough) plans and writes queries. Amazon Bedrock AgentCore hosts the Strands agent and manages the outbound credential the agent presents to AtScale. The joins, metric definitions, and row and column filters that apply to the caller live inside the semantic layer rather than the prompt. We assume you’re familiar with the semantic-layer architecture from the first post in the series: what a semantic layer is, what it’s for, and why the model plans queries without owning the joins. If any of that is new, the first post covers the ground. By the end of this post, you will know: How to model a C360 domain in the Semantic Modeling Language (SML): datasets, dimensions and hierarchies, facts, measures, calculated measures, and perspectives, versioned in Git. How AtScale plans a dimensional query against Amazon Redshift, and how AtScale’s autonomous aggregate management accelerates the query patterns an agent generates. How to expose the model to an AgentCore-hosted Strands agent through the AtScale MCP server, and how to register that MCP server with AgentCore Gateway, a capability of Amazon Bedrock AgentCore. How the human user’s identity propagates from the enterprise identity provider through AgentCore Identity, a capability of Amazon Bedrock AgentCore, to AtScale, and how AtScale enforces role-based access control (RBAC), row security, and perspectives at query time. How to deploy AtScale on Amazon Elastic Kubernetes Service (Amazon EKS) using the AtScale Helm chart and the AtScale K8S Blueprints repository. The source of truth for the walkthrough is the AtScale C2026.7 release. Where a specific tool name or endpoint applies, we cite the AtScale documentation. The example: Customer 360 on Amazon Redshift The customer 360 pattern from the first two posts stays in place. A retail enterprise has customer records, orders, products, and rewards enrollments spread across systems, and business users want to ask cross-cutting questions without knowing which system holds which fact. The Stardog C360 Knowledge Kit we adapted for the first post in the series models this scenario with Customer, Order, Product, and Address entities joined on an integer cid that appears as a primary key in the customer table and as a plain column in the purchase table. Where this post differs from the first two is where the data physically sits. Stardog and Denodo federate at query time across two engines. AtScale plans a dimensional query as native warehouse SQL and pushes it to one engine per query, so cross-engine data is consolidated upstream. For this walkthrough, all analytical C360 data lives in Amazon Redshift Serverless. Amazon Aurora PostgreSQL remains the operational system of record, and a replication path (AWS Database Migration Service or Amazon Aurora zero-ETL to Amazon Redshift) keeps the analytical copy current. The agent queries a single AtScale model that maps to the Amazon Redshift tables. The schema in Amazon Redshift: Table Key columns customer cid (PK), first_name, last_name, email, ssn, phone, location address id (PK), city, state, zip, street_name credit_card id (PK), cid, card_num, card_type rewards_account id (PK), cid, account_id, create_date purchase id (PK), pid, purchase_date, quantity, price, cid, card product id (PK), name, brand, price, dept category id (PK), dept_name, parent vendor id (PK), vendor_name, industry Nine columns of interest across eight tables. cid links customer records to purchases. pid links purchases to products. dept links products to categories. Everything analytical is in Amazon Redshift, so joins push down to native SQL rather than being resolved in the semantic layer or in an extract, transform, and load (ETL) pipeline. A representative question that exercises the whole model: Which of our top 20 customers by lifetime spend haven’t enrolled in the rewards program yet? This is the auto-enrollment question from the Denodo post, carried over so a reader following the series can see the same request answered by a different semantic layer. It touches customer profile, address, purchase history, and enrollment status: one row per customer across four logical entities. AtScale terms used in this post AtScale implements the semantic layer as a dimensional model over a warehouse. The AtScale documentation and the SML specification use a specific set of primitives that come up throughout this post. A short reference is useful before we get to the walkthrough. Semantic Modeling Language (SML) – An open, YAML-based specification for describing semantic models. Every SML object (model, dataset, dimension, hierarchy, metric, calculation, perspective, row security) is a YAML file. The specification lives at github.com/semanticdatalayer/SML. Model – The top-level artifact. A model references datasets, dimensions, facts, and metrics, and exposes them through the AtScale query engine. Dimension and hierarchy – A dimension groups related attributes (customer, product, date). A hierarchy inside a dimension organizes those attributes into levels (product → category → department, or year → quarter → month → day). Fact and measure – A fact is a dataset that holds measurable events joined to dimensions on key columns. A measure is a quantity aggregated from a fact column, for example SUM(price * quantity) for revenue. Calculation – A derived measure expressed as a formula against other measures. Perspective – A publishable subset of the model exposed to a specific role or group. Perspectives are how AtScale controls which dimensions and measures a caller can see. Row security – A model object that filters rows returned to the caller based on the caller’s identity or attributes. Autonomous aggregate management – AtScale watches query patterns across consumers and materializes summary tables in the warehouse when a pattern is expensive enough to justify one. Subsequent queries that match the pattern route to the aggregate transparently. Design Center – The AtScale authoring surface. A modeler edits SML through a visual canvas or a text editor. Either way the artifact on disk is SML YAML in Git. AtScale MCP server – The in-product MCP endpoint at /mcp that exposes the semantic model to any MCP client. Where more detail is useful, the AtScale documentation and the SML specification are the authoritative references. Reference architecture The runtime splits into an inbound path and an outbound path, following the same shape as the Stardog and Denodo posts. Inbound. A client sends the user’s question to the Strands agent through AgentCore Gateway. Gateway validates the JSON Web Token (JWT) that identifies the human user against the enterprise identity provider (IdP), then routes the request to AgentCore runtime (a capability of Amazon Bedrock AgentCore), which hosts the agent process. The agent invokes Claude Sonnet 4.6 on Amazon Bedrock to interpret the prompt and plan the query. Outbound. When the agent decides to query the semantic model, it invokes a tool call to the AtScale MCP server. AgentCore Gateway serves as the outbound proxy: the AtScale MCP server is registered as an MCP target on Gateway, so tool calls route through Gateway and AgentCore Identity injects the credential at that hop. AtScale’s MCP endpoint accepts either a bearer token (for development and single-identity scenarios) or an OAuth 2.0 access token issued by AtScale’s bundled Keycloak instance (the production path). The AtScale engine validates the token, resolves the caller to an AtScale role, and plans the query against the deployed C360 model. The query request travels down through the AtScale engine, and the results travel back up. There’s no ETL job that pre-materializes cross-database joins. The analytical copy in Amazon Redshift is the source of truth for the semantic model, kept fresh from Aurora by the upstream replication path. Figure 1: Inbound authentication path and outbound query path between the client, Amazon Bedrock AgentCore components, the AtScale MCP server, the AtScale engine, and Amazon Redshift Serverless The architecture is deliberately opinionated on identity. Gateway and Identity hold the tokens at the runtime edges. The agent doesn’t see them and only orchestrates the conversation and the tool calls. Build the semantic layer AtScale’s semantic model is a collection of SML objects (datasets, dimensions, facts, measures, calculations, perspectives, row security) versioned in Git. A working model has a shape a data engineer will recognize from a star schema, but every object is expressed as YAML rather than data definition language (DDL), and every object is a separate file. Building the C360 model happens in three passes: datasets over the Amazon Redshift tables, dimensions and hierarchies with the joins between them, and measures and calculations that express the business logic. Datasets. Each Amazon Redshift table becomes an SML dataset. A dataset declares the physical connection, the schema, the table, and the columns AtScale will surface. Datasets can be authored visually in Design Center or edited directly as YAML. Either surface writes the same SML file to Git. Dimensions and hierarchies. The C360 model has seven dimensions. dim_customer holds customer profile attributes and joins to dim_address through the location key and to dim_rewards through cid. dim_product holds product attributes and organizes them into a hierarchy through dim_category. dim_date supports date-based analysis. dim_vendor groups products by supplier. dim_rewards holds one row per enrolled customer with account_id and create_date, and snowflakes off dim_customer so that never-enrolled customers surface as null in the enrollment attributes. AtScale’s hierarchy primitive is the concise expression of the product-to-category relationship. A query against the model can navigate product → category → parent category without a recursive SQL common table expression, and the large language model (LLM) sees a single dimensional path rather than a join graph. A representative SML fragment for the product hierarchy: # dim_product.yml unique_name: dim_product object_type: dimension label: Product hierarchies: - unique_name: product_category label: Product Category levels: - unique_name: department dataset: category key_columns: [dept_name] - unique_name: category dataset: category key_columns: [id] - unique_name: product dataset: product key_columns: [id] secondary_attributes: - unique_name: brand - unique_name: product_name key_column: name Facts and measures. The fact table for C360 is fact_purchase, mapped to the Amazon Redshift purchase table. It joins to dim_customer on cid, to dim_product on pid, and to dim_date on purchase_date. Measures come off the [truncated for AI cost control]