Building a Semantic Layer for Agentic AI with AWS Tools

There's some pretty exciting stuff happening with agentic AI on AWS. Take Strategy Mosaic and Amazon Bedrock AgentCore, for instance—they're collaborating to craft a semantic layer that's quite compelling. This approach effectively unifies data from various sources without the headache of traditional ETL processes. For those of us immersed in the field, it's a notable step forward in streamlining data access and ramping up the efficiency of AI-driven decision-making.

Building the Bridge: Semantic Layer Mechanics

Strategy Mosaic has constructed a semantic layer that acts like a bridge, seamlessly connecting disparate data sources such as Amazon Redshift and Amazon Aurora. They're using a dimensional model filled with attributes, hierarchies, facts, and metrics to keep the data organized. This setup supports various protocols: Model Context Protocol (MCP) for AI agents, JDBC/ODBC for SQL clients, and REST for custom applications. It's versatile, fitting into different use cases like a glove.

What makes this approach stand out is how it executes queries across these sources without needing to physically cobble all the data together in one spot. Mosaic cleverly uses model linking via shared attributes—like customer IDs—to perform joins at the semantic level. This ensures data stays consistent and secure. Better still, the linked-model pattern isn't just limited to Amazon Redshift and Amazon Aurora. It's scalable across various setups, making the whole architecture more adaptable.

In this configuration, a Strands agent, operating on AgentCore runtime (a feature of Amazon Bedrock AgentCore), connects to Mosaic via the MCP endpoint. The joins, metric definitions, and specific row and column filters are housed within Mosaic itself, not in the agent prompt. This simplifies integration and eases the management of security protocols.

Impacts on Production Codebases

For folks managing production codebases, this method significantly cuts down the complexity tied to handling multiple data sources. A semantic layer here means you can dodge the usual pitfalls of data inconsistency and security headaches that come with traditional ETL processes. Plus, with Row-Level Security (RLS) and Object-Level Security (OLS) applied end-to-end, data governance gets a thorough workout across the full spectrum.

Putting It to Work

Picture yourself running a retail operation with customer details on Amazon Aurora and purchase histories stored on Amazon Redshift. You might want to know which of the top 20 customers by lifetime spending haven’t joined the rewards program yet. Queries like this, which combine data from both systems, are far more straightforward and efficient with Mosaic. By using model linking rather than a cumbersome materialized cross-engine join, data accuracy and timeliness are maintained.

Getting Started: Implementing the Semantic Layer

If you're thinking about taking this plunge, here's my take:

• Assess Your Current Architecture: Start with mapping out existing data sources and their interactions. Look for spots where traditional ETL pipelines could be replaced by the semantic layer. This will help gauge the impact on data flow and processing times.
• Develop Mosaic Models: Craft Mosaic Models for each data source, defining needed relationships and hierarchies, akin to our customer and purchase data example. Make sure these models are certified, as only certified ones are accessible through the MCP server.
• Implement Security: Leverage Mosaic's RLS and OLS features to keep data access secure and comply with your organization's policies. It's crucial to manage user identity propagation to uphold security protocols end-to-end.
• Test and Tweak: Run comprehensive tests to check that queries are performing as expected. Fine-tune performance by weighing live pushdown against in-memory execution. Each has trade-offs, as live pushdown might reduce latency but increase the load on source systems.

Things to Keep in Mind

This approach has its perks, but here are a few caveats to consider:

• Setup Complexity: Initially setting up Mosaic Models can be intricate, requiring a deep understanding of your data architecture. The dimensional modeling demands a clear grasp of business logic and data relationships.
• Performance Choices: The decision between live pushdown and in-memory execution affects performance. You'll need to decide which best suits your particular workload. Live pushdown shines in real-time analytics, whereas in-memory might be better for batch processing.
• Data Governance: While the semantic layer simplifies integration, managing data governance across numerous models and settings is no small feat. Formulating a solid data governance framework is essential for navigating these challenges effectively.

From where I stand, adopting a semantic layer can vastly enhance data integration and access, especially in settings with diverse data sources. But it's essential to balance the advantages against the complexity and ensure your team is up for the learning curve ahead.

If you're interested in exploring more about AI and data architectures, you might check out my posts on Accessing OpenAI GPT Models from Canada with Amazon Bedrock and Connecting AWS DevOps Agent to OpenSearch for Incident Management. They cover related themes around AI and AWS integration.

A Closer Look at Mosaic's Dimensional Model

In Strategy Mosaic’s semantic layer, they use a dimensional model that organizes data into attributes, hierarchies, facts, and metrics. This setup efficiently expresses and queries complex data relationships. Attributes, like Customer, are defined with multiple forms—such as an ID form for joining and a display form for reading. This makes querying and reporting more intuitive.

Hierarchies map out parent-child relationships between attributes, aiding roll-up operations. For instance, a Category might roll up to a Department, or an Address could roll up to City to State.

Facts and metrics in Mosaic denote numeric data and its aggregations. A fact might be a numeric column like Purchase Amount, while a metric could be the aggregation of this fact. Advanced metrics might include named conditions or appear in compound metrics, which are formulas that reference other metrics.

Filter objects and level qualifiers offer added flexibility to metrics. Filters allow named conditions to be used in metrics without placing predicates inline, and level qualifiers define the aggregation grain, keeping results consistent no matter how queries are sliced.

This rich syntax captures the business definitions needed for AI agents and other applications to work over, providing a strong framework for data analysis and decision-making.

Execution Modes: Live vs. In-Memory Decisions

Deciding between live pushdown and in-memory execution is pivotal when implementing a semantic layer with Strategy Mosaic. Live pushdown directs queries to the data sources for processing, which is great for real-time data and cutting latency. However, it could ramp up the load on data sources, possibly affecting performance.

In-memory execution, alternatively, processes queries in a Mosaic-resident cube. This is advantageous for batch processing or when minimizing load on data sources is a priority. However, it might introduce latency due to data caching and retrieval times.

Each option comes with its trade-offs, and the decision largely depends on the distinct needs of your workload. If real-time analytics drive your application, live pushdown might be your best bet. Conversely, if reducing the performance impact on data sources is your goal, in-memory execution could be more appealing.