Need advice about which tool to choose?Ask the StackShare community!
AWS Glue vs Amazon Athena vs Apache Spark: What are the differences?
Introduction
AWS Glue, Amazon Athena, and Apache Spark are all popular tools used in big data processing and analytics tasks. Each tool has its own unique features and use cases that cater to different needs of data processing.
Data Catalog and Metadata Store: AWS Glue is a fully managed data catalog and ETL service that provides a centralized metadata repository for all data assets, making it easy to discover, understand, and manage data. In contrast, Amazon Athena is a serverless interactive query service that does not have a built-in data catalog but can directly query data stored in Amazon S3. Apache Spark, on the other hand, relies on external tools like Apache Hive or Apache Hadoop for metadata management.
Query Execution Engine: Amazon Athena is specifically designed for querying data stored in Amazon S3 using standard SQL, making it well-suited for ad-hoc querying and analysis of data lakes. On the other hand, AWS Glue does not provide a query execution engine and is more focused on ETL (Extract, Transform, Load) tasks. Apache Spark, a distributed computing framework, comes with its built-in query engine that provides high-performance data processing capabilities for large-scale data processing.
Programming Support: Apache Spark offers a rich set of APIs in languages like Scala, Java, Python, and R, allowing developers to write complex data processing workflows and applications. In comparison, AWS Glue provides an SQL-based interface for defining ETL jobs, making it easier for users with SQL skills to perform data transformations. Amazon Athena supports standard SQL queries for data analysis and does not require any programming language knowledge.
Scalability and Performance: Apache Spark is known for its scalability and performance, as it can handle large volumes of data and distribute processing across a cluster of machines efficiently. While AWS Glue and Amazon Athena are also scalable, they may have limitations based on the underlying infrastructure and service configurations. AWS Glue can automatically scale resources based on the workload, while Amazon Athena scales automatically to accommodate query volume but may have performance implications for complex queries.
Cost Structure: AWS Glue and Amazon Athena follow a pay-as-you-go pricing model based on the amount of data processed and resources used. Apache Spark, being an open-source framework, is free to use but requires management of infrastructure and resources. This cost structure can vary based on the specific use case and requirements of each tool, making it important to consider the cost implications when choosing a tool for data processing.
In Summary, the key differences between AWS Glue, Amazon Athena, and Apache Spark lie in their data catalog capabilities, query execution engines, programming support, scalability, performance, and cost structures, each catering to specific use cases and requirements in big data processing and analytics tasks.
We need to perform ETL from several databases into a data warehouse or data lake. We want to
- keep raw and transformed data available to users to draft their own queries efficiently
- give users the ability to give custom permissions and SSO
- move between open-source on-premises development and cloud-based production environments
We want to use inexpensive Amazon EC2 instances only on medium-sized data set 16GB to 32GB feeding into Tableau Server or PowerBI for reporting and data analysis purposes.
You could also use AWS Lambda and use Cloudwatch event schedule if you know when the function should be triggered. The benefit is that you could use any language and use the respective database client.
But if you orchestrate ETLs then it makes sense to use Apache Airflow. This requires Python knowledge.
Though we have always built something custom, Apache airflow (https://airflow.apache.org/) stood out as a key contender/alternative when it comes to open sources. On the commercial offering, Amazon Redshift combined with Amazon Kinesis (for complex manipulations) is great for BI, though Redshift as such is expensive.
You may want to look into a Data Virtualization product called Conduit. It connects to disparate data sources in AWS, on prem, Azure, GCP, and exposes them as a single unified Spark SQL view to PowerBI (direct query) or Tableau. Allows auto query and caching policies to enhance query speeds and experience. Has a GPU query engine and optimized Spark for fallback. Can be deployed on your AWS VM or on prem, scales up and out. Sounds like the ideal solution to your needs.
We have a Kafka topic having events of type A and type B. We need to perform an inner join on both type of events using some common field (primary-key). The joined events to be inserted in Elasticsearch.
In usual cases, type A and type B events (with same key) observed to be close upto 15 minutes. But in some cases they may be far from each other, lets say 6 hours. Sometimes event of either of the types never come.
In all cases, we should be able to find joined events instantly after they are joined and not-joined events within 15 minutes.
The first solution that came to me is to use upsert to update ElasticSearch:
- Use the primary-key as ES document id
- Upsert the records to ES as soon as you receive them. As you are using upsert, the 2nd record of the same primary-key will not overwrite the 1st one, but will be merged with it.
Cons: The load on ES will be higher, due to upsert.
To use Flink:
- Create a KeyedDataStream by the primary-key
- In the ProcessFunction, save the first record in a State. At the same time, create a Timer for 15 minutes in the future
- When the 2nd record comes, read the 1st record from the State, merge those two, and send out the result, and clear the State and the Timer if it has not fired
- When the Timer fires, read the 1st record from the State and send out as the output record.
- Have a 2nd Timer of 6 hours (or more) if you are not using Windowing to clean up the State
Pro: if you have already having Flink ingesting this stream. Otherwise, I would just go with the 1st solution.
Please refer "Structured Streaming" feature of Spark. Refer "Stream - Stream Join" at https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html#stream-stream-joins . In short you need to specify "Define watermark delays on both inputs" and "Define a constraint on time across the two inputs"
I have to collect different data from multiple sources and store them in a single cloud location. Then perform cleaning and transforming using PySpark, and push the end results to other applications like reporting tools, etc. What would be the best solution? I can only think of Azure Data Factory + Databricks. Are there any alternatives to #AWS services + Databricks?
Hi all,
Currently, we need to ingest the data from Amazon S3 to DB either Amazon Athena or Amazon Redshift. But the problem with the data is, it is in .PSV (pipe separated values) format and the size is also above 200 GB. The query performance of the timeout in Athena/Redshift is not up to the mark, too slow while compared to Google BigQuery. How would I optimize the performance and query result time? Can anyone please help me out?
you can use aws glue service to convert you pipe format data to parquet format , and thus you can achieve data compression . Now you should choose Redshift to copy your data as it is very huge. To manage your data, you should partition your data in S3 bucket and also divide your data across the redshift cluster
First of all you should make your choice upon Redshift or Athena based on your use case since they are two very diferent services - Redshift is an enterprise-grade MPP Data Warehouse while Athena is a SQL layer on top of S3 with limited performance. If performance is a key factor, users are going to execute unpredictable queries and direct and managing costs are not a problem I'd definitely go for Redshift. If performance is not so critical and queries will be predictable somewhat I'd go for Athena.
Once you select the technology you'll need to optimize your data in order to get the queries executed as fast as possible. In both cases you may need to adapt the data model to fit your queries better. In the case you go for Athena you'd also proabably need to change your file format to Parquet or Avro and review your partition strategy depending on your most frequent type of query. If you choose Redshift you'll need to ingest the data from your files into it and maybe carry out some tuning tasks for performance gain.
I'll recommend Redshift for now since it can address a wider range of use cases, but we could give you better advice if you described your use case in depth.
It depend of the nature of your data (structured or not?) and of course your queries (ad-hoc or predictible?). For example you can look at partitioning and columnar format to maximize MPP capabilities for both Athena and Redshift
you can change your PSV fomat data to parquet file format with AWS GLUE and then your query performance will be improved
Pros of Amazon Athena
- Use SQL to analyze CSV files16
- Glue crawlers gives easy Data catalogue8
- Cheap7
- Query all my data without running servers 24x76
- No data base servers yay4
- Easy integration with QuickSight3
- Query and analyse CSV,parquet,json files in sql2
- Also glue and athena use same data catalog2
- No configuration required1
- Ad hoc checks on data made easy0
Pros of AWS Glue
- Managed Hive Metastore9
Pros of Apache Spark
- Open-source61
- Fast and Flexible48
- One platform for every big data problem8
- Great for distributed SQL like applications8
- Easy to install and to use6
- Works well for most Datascience usecases3
- Interactive Query2
- Machine learning libratimery, Streaming in real2
- In memory Computation2
Sign up to add or upvote prosMake informed product decisions
Cons of Amazon Athena
Cons of AWS Glue
Cons of Apache Spark
- Speed4