- Let's take a look at some
of the details of the Athena service.
And the first thing that we need to understand is
going to be the pricing model,
because this is gonna help us figure
out how we are going to optimize the placement of our data
as well as its basic organization.
We are going to pay per query to use the service.
There's no actual storage charges
because the data actually exists in S3 or other services,
but we are going to be paying
based on the amount of data that is returned by the query
but also on the amount of data that was queried
in the first place to get that response.
And because of this,
we may want to think a little bit more carefully
about how we organize data, especially in S3
into prefixes that would match the different types
of queries that we would be issuing
against the data to minimize the size
of the overall data set that gets queried.
Next, we have the option of enforcing asset compliance.
So if we need to issue strongly consistent queries
that's a parameter that we can provide as well.
We have the ability to use more
than just the AWS CLI or SDK.
You can treat your Athena service
as a JDBC or ODBC endpoint,
so your applications can issue queries directly.
You can also partition the data
beyond just the individual prefixes in the S3 buckets.
And finally, you can use a feature called Federated Query.
And this is another one
of those elements that helps to separate this service
from anything that you could conceive of implementing
in an on-prem data center and reminding us
of the power that comes with being cloud native.
And so let's take a look at Federated Query,
assuming that you're using a glue data catalog
which is the current feature set
of Athena and not the old Athena catalog.
You have the ability
to query services that are not just S3 buckets
and prefixes within those buckets.
So what else can you query?
Well, it could be a cloud watch log group
with logs that are either space delimited
or JSON objects or whatever happens to be in there.
You can federate your query against a DynamoDB table.
You can federate against DocumentDB.
So you have a couple of different
NoSQL options on the backend.
And since Athena takes data
and makes it available for SQL based queries
you're basically treating your backend data
as if it were relational.
Well, it can actually be relational.
It could be an RDS database
or even an EC two instance that is running
either MySQL or a Postgres engine.
And finally, you can even federate your Athena queries
against custom external endpoints.