AWS Big Data Blog
Query a Teradata database using Amazon Athena Federated Query and join with data in your Amazon S3 data lake
If you use data lakes in Amazon Simple Storage Service (Amazon S3) and use Teradata as your transactional data store, you may need to join the data in your data lake with Teradata in the cloud, Teradata running on Amazon Elastic Compute Cloud (Amazon EC2), or with an on-premises Teradata database, for example to build a dashboard or create consolidated reporting.
In these use cases, the Amazon Athena Federated Query feature allows you to seamlessly access the data from Teradata database without having to move the data to your S3 data lake. This removes the overhead in managing such jobs.
In this post, we will walk you through a step-by-step configuration to set up Athena Federated Query using AWS Lambda to access data in a Teradata database running on premises.
For this post, we will be using the Oracle Athena Federated Query connector developed by Trianz. The runtime includes a Teradata instance on premises. Your Teradata instance can be on the cloud, on Amazon EC2, or on premises. You can deploy the Trianz Oracle Athena Federated Query connector from the AWS Serverless Application Repository.
Let’s start with discussing the solution and then detailing the steps involved.
Data federation is the capability to integrate data in another data store using a single interface (Athena). The following diagram depicts how Athena Federated Query works by using Lambda to integrate with a federated data source.
Athena is an interactive query service that makes it easy to analyze data in Amazon S3 using standard SQL. If you have data in sources other than Amazon S3, you can use Athena Federated Query to query the data in place or build pipelines to extract data from multiple data sources and store them in Amazon S3. With Athena Federated Query, you can run SQL queries across data stored in relational, non-relational, object, and custom data sources.
When a federated query is run, Athena identifies the parts of the query that should be routed to the data source connector and executes them with Lambda. The data source connector makes the connection to the source, runs the query, and returns the results to Athena. If the data doesn’t fit into Lambda RAM runtime memory, it spills the data to Amazon S3 and is later accessed by Athena.
Athena uses data source connectors which internally use Lambda to run federated queries. Data source connectors are pre-built and can be deployed from the Athena console or from the Serverless Application Repository. Based on the user submitting the query, connectors can provide or restrict access to specific data elements.
To implement this solution, we complete the following steps:
- Create a secret for the Teradata instance using AWS Secrets Manager.
- Create an S3 bucket and subfolder for Lambda to use.
- Configure Athena federation with the Teradata instance.
- Run federated queries with Athena.
Before you start this walkthrough, make sure your Teradata database is up and running.
Create a secret for the Teradata instance
Our first step is to create a secret for the Teradata instance with a username and password using Secrets Manager.
- On the Secrets Manager console, choose Secrets.
- Choose Store a new secret.
- Select Other types of secrets.
- Set the credentials as key-value pairs (username, password) for your Teradata instance.
- For Secret name, enter a name for your secret. Use the prefix
TeradataAFQso it’s easy to find.
- Leave the remaining fields at their defaults and choose Next.
- Complete your secret creation.
Set up your S3 bucket for Lambda
On the Amazon S3 console, create a new S3 bucket and subfolder for Lambda to use. For this post, we create
Configure Athena federation with the Teradata instance
To configure Athena federation with Teradata instance, complete the following steps:
- On the AWS Serverless Application Repository console, choose Available applications.
- Select Show apps that create custom IAM roles or resource policies.
- In the search field, enter
- Choose the application.
- For SecretNamePrefix, enter
- For SpillBucket, enter
- For JDBCConnectorConfig, use the format
- For DisableSpillEncryption, enter
- For LambdaFunctionName, enter
- For SecurityGroupID, enter the security group ID where the Teradata instance is deployed.
Make sure to apply valid inbound and outbound rules based on your connection.
- For SpillPrefix, create a folder under the S3 bucket you created and specify the name (for example,
- For Subnetids, use the subnets where the Teradata instance is running with comma separation.
Make sure the subnet is in a VPC and has NAT gateway and internet gateway attached.
- Select the I acknowledge check box.
- Choose Deploy.
Make sure that the AWS Identity and Access Management (IAM) roles have permissions to access AWS Serverless Application Repository, AWS CloudFormation, Amazon S3, Amazon CloudWatch, Amazon CloudTrail, Secrets Manager, Lambda, and Athena. For more information about Athena IAM access, see Example IAM Permissions Policies to Allow Athena Federated Query.
Run federated queries with Athena
Run your queries using
lambda:teradataconnector to run against tables in the Teradata database.
teradataconnector is the name of lambda function which we have created in step 7 of previous section of this blog.
lambda:teradataconnector references a data source connector Lambda function using the format
lambda:MyLambdaFunctionName. For more information, see Writing Federated Queries.
The following screenshot shows the query that joins the dataset between Teradata and the S3 data lake.
Key performance best practices
If you’re considering Athena Federated Query with Teradata, we recommend the following best practices:
- Athena Federated query works great for queries with predicate filtering because the predicates are pushed down to the Teradata database. Use filter and limited-range scans in your queries to avoid full table scans.
- If your SQL query requires returning a large volume of data from the Teradata database to Athena (which could lead to query timeouts or slow performance), you may consider moving data from Teradata to your S3 data lake.
- The star schema is a commonly used data model in Teradata. In the star schema model, unload your large fact tables into your S3 data lake and leave the dimension tables in Teradata. If large dimension tables are contributing to slow performance or query timeouts, unload those tables to your S3 data lake.
- When you run federated queries, Athena spins up multiple Lambda functions, which causes a spike in database connections. It’s important to monitor the Teradata database WLM queue slots to ensure there is no queuing. Additionally, you can use concurrency scaling on your Teradata database cluster to benefit from concurrent connections to queue up.
In this post, you learned how to configure and use Athena Federated Query with Teradata. Now you don’t need to wait for all the data in your Teradata data warehouse to be unloaded to Amazon S3 and maintained on a day-to-day basis to run your queries.
You can use the best practices outlined in the post to help minimize the data transferred from Teradata for better performance. When queries are well written for Athena Federated Query, the performance penalties are negligible.
For more information, see the Athena User Guide and Using Amazon Athena Federated Query.
About the Author
Navnit Shukla is an AWS Specialist Solution Architect in Analytics. He is passionate about helping customers uncover insights from their data. He has been building solutions to help organizations make data-driven decisions.