Alternatives to Amazon EMR logo

Alternatives to Amazon EMR

Amazon EC2, Hadoop, Amazon DynamoDB, Amazon Redshift, and Azure HDInsight are the most popular alternatives and competitors to Amazon EMR.
520
638
+ 1
54

What is Amazon EMR and what are its top alternatives?

It is used in a variety of applications, including log analysis, data warehousing, machine learning, financial analysis, scientific simulation, and bioinformatics.
Amazon EMR is a tool in the Big Data as a Service category of a tech stack.

Top Alternatives to Amazon EMR

  • Amazon EC2
    Amazon EC2

    It is a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale computing easier for developers. ...

  • Hadoop
    Hadoop

    The Apache Hadoop software library is a framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models. It is designed to scale up from single servers to thousands of machines, each offering local computation and storage. ...

  • Amazon DynamoDB
    Amazon DynamoDB

    With it , you can offload the administrative burden of operating and scaling a highly available distributed database cluster, while paying a low price for only what you use. ...

  • Amazon Redshift
    Amazon Redshift

    It is optimized for data sets ranging from a few hundred gigabytes to a petabyte or more and costs less than $1,000 per terabyte per year, a tenth the cost of most traditional data warehousing solutions. ...

  • Azure HDInsight
    Azure HDInsight

    It is a cloud-based service from Microsoft for big data analytics that helps organizations process large amounts of streaming or historical data. ...

  • Databricks
    Databricks

    Databricks Unified Analytics Platform, from the original creators of Apache Spark™, unifies data science and engineering across the Machine Learning lifecycle from data preparation to experimentation and deployment of ML applications. ...

  • Apache Spark
    Apache Spark

    Spark is a fast and general processing engine compatible with Hadoop data. It can run in Hadoop clusters through YARN or Spark's standalone mode, and it can process data in HDFS, HBase, Cassandra, Hive, and any Hadoop InputFormat. It is designed to perform both batch processing (similar to MapReduce) and new workloads like streaming, interactive queries, and machine learning. ...

  • Snowflake
    Snowflake

    Snowflake eliminates the administration and management demands of traditional data warehouses and big data platforms. Snowflake is a true data warehouse as a service running on Amazon Web Services (AWS)—no infrastructure to manage and no knobs to turn. ...

Amazon EMR alternatives & related posts

Amazon EC2 logo

Amazon EC2

44.3K
32.4K
2.5K
Scalable, pay-as-you-go compute capacity in the cloud
44.3K
32.4K
+ 1
2.5K
PROS OF AMAZON EC2
  • 647
    Quick and reliable cloud servers
  • 515
    Scalability
  • 393
    Easy management
  • 277
    Low cost
  • 270
    Auto-scaling
  • 89
    Market leader
  • 80
    Backed by amazon
  • 79
    Reliable
  • 67
    Free tier
  • 58
    Easy management, scalability
  • 13
    Flexible
  • 10
    Easy to Start
  • 9
    Widely used
  • 9
    Web-scale
  • 9
    Elastic
  • 7
    Node.js API
  • 5
    Industry Standard
  • 4
    Lots of configuration options
  • 2
    GPU instances
  • 1
    Extremely simple to use
  • 1
    Amazing for individuals
  • 1
    All the Open Source CLI tools you could want.
  • 1
    Simpler to understand and learn
CONS OF AMAZON EC2
  • 13
    Ui could use a lot of work
  • 6
    High learning curve when compared to PaaS
  • 3
    Extremely poor CPU performance

related Amazon EC2 posts

Ashish Singh
Tech Lead, Big Data Platform at Pinterest · | 38 upvotes · 1.2M views

To provide employees with the critical need of interactive querying, we’ve worked with Presto, an open-source distributed SQL query engine, over the years. Operating Presto at Pinterest’s scale has involved resolving quite a few challenges like, supporting deeply nested and huge thrift schemas, slow/ bad worker detection and remediation, auto-scaling cluster, graceful cluster shutdown and impersonation support for ldap authenticator.

Our infrastructure is built on top of Amazon EC2 and we leverage Amazon S3 for storing our data. This separates compute and storage layers, and allows multiple compute clusters to share the S3 data.

We have hundreds of petabytes of data and tens of thousands of Apache Hive tables. Our Presto clusters are comprised of a fleet of 450 r4.8xl EC2 instances. Presto clusters together have over 100 TBs of memory and 14K vcpu cores. Within Pinterest, we have close to more than 1,000 monthly active users (out of total 1,600+ Pinterest employees) using Presto, who run about 400K queries on these clusters per month.

Each query submitted to Presto cluster is logged to a Kafka topic via Singer. Singer is a logging agent built at Pinterest and we talked about it in a previous post. Each query is logged when it is submitted and when it finishes. When a Presto cluster crashes, we will have query submitted events without corresponding query finished events. These events enable us to capture the effect of cluster crashes over time.

Each Presto cluster at Pinterest has workers on a mix of dedicated AWS EC2 instances and Kubernetes pods. Kubernetes platform provides us with the capability to add and remove workers from a Presto cluster very quickly. The best-case latency on bringing up a new worker on Kubernetes is less than a minute. However, when the Kubernetes cluster itself is out of resources and needs to scale up, it can take up to ten minutes. Some other advantages of deploying on Kubernetes platform is that our Presto deployment becomes agnostic of cloud vendor, instance types, OS, etc.

#BigData #AWS #DataScience #DataEngineering

See more
Simon Reymann
Senior Fullstack Developer at QUANTUSflow Software GmbH · | 29 upvotes · 5.1M views

Our whole DevOps stack consists of the following tools:

  • GitHub (incl. GitHub Pages/Markdown for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
  • Respectively Git as revision control system
  • SourceTree as Git GUI
  • Visual Studio Code as IDE
  • CircleCI for continuous integration (automatize development process)
  • Prettier / TSLint / ESLint as code linter
  • SonarQube as quality gate
  • Docker as container management (incl. Docker Compose for multi-container application management)
  • VirtualBox for operating system simulation tests
  • Kubernetes as cluster management for docker containers
  • Heroku for deploying in test environments
  • nginx as web server (preferably used as facade server in production environment)
  • SSLMate (using OpenSSL) for certificate management
  • Amazon EC2 (incl. Amazon S3) for deploying in stage (production-like) and production environments
  • PostgreSQL as preferred database system
  • Redis as preferred in-memory database/store (great for caching)

The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:

  • Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
  • Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
  • Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
  • Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
  • Scalability: All-in-one framework for distributed systems.
  • Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.
See more
Hadoop logo

Hadoop

2.1K
2.2K
56
Open-source software for reliable, scalable, distributed computing
2.1K
2.2K
+ 1
56
PROS OF HADOOP
  • 39
    Great ecosystem
  • 11
    One stack to rule them all
  • 4
    Great load balancer
  • 1
    Amazon aws
  • 1
    Java syntax
CONS OF HADOOP
    Be the first to leave a con

    related Hadoop posts

    Shared insights
    on
    KafkaKafkaHadoopHadoop
    at

    The early data ingestion pipeline at Pinterest used Kafka as the central message transporter, with the app servers writing messages directly to Kafka, which then uploaded log files to S3.

    For databases, a custom Hadoop streamer pulled database data and wrote it to S3.

    Challenges cited for this infrastructure included high operational overhead, as well as potential data loss occurring when Kafka broker outages led to an overflow of in-memory message buffering.

    See more
    Conor Myhrvold
    Tech Brand Mgr, Office of CTO at Uber · | 7 upvotes · 1.2M views

    Why we built Marmaray, an open source generic data ingestion and dispersal framework and library for Apache Hadoop :

    Built and designed by our Hadoop Platform team, Marmaray is a plug-in-based framework built on top of the Hadoop ecosystem. Users can add support to ingest data from any source and disperse to any sink leveraging the use of Apache Spark . The name, Marmaray, comes from a tunnel in Turkey connecting Europe and Asia. Similarly, we envisioned Marmaray within Uber as a pipeline connecting data from any source to any sink depending on customer preference:

    https://eng.uber.com/marmaray-hadoop-ingestion-open-source/

    (Direct GitHub repo: https://github.com/uber/marmaray Kafka Kafka Manager )

    See more
    Amazon DynamoDB logo

    Amazon DynamoDB

    3.5K
    3.1K
    195
    Fully managed NoSQL database service
    3.5K
    3.1K
    + 1
    195
    PROS OF AMAZON DYNAMODB
    • 62
      Predictable performance and cost
    • 56
      Scalable
    • 35
      Native JSON Support
    • 21
      AWS Free Tier
    • 7
      Fast
    • 3
      No sql
    • 3
      To store data
    • 2
      Serverless
    • 2
      No Stored procedures is GOOD
    • 1
      ORM with DynamoDBMapper
    • 1
      Elastic Scalability using on-demand mode
    • 1
      Elastic Scalability using autoscaling
    • 1
      DynamoDB Stream
    CONS OF AMAZON DYNAMODB
    • 4
      Only sequential access for paginate data
    • 1
      Scaling
    • 1
      Document Limit Size

    related Amazon DynamoDB posts

    Praveen Mooli
    Engineering Manager at Taylor and Francis · | 18 upvotes · 2.6M views

    We are in the process of building a modern content platform to deliver our content through various channels. We decided to go with Microservices architecture as we wanted scale. Microservice architecture style is an approach to developing an application as a suite of small independently deployable services built around specific business capabilities. You can gain modularity, extensive parallelism and cost-effective scaling by deploying services across many distributed servers. Microservices modularity facilitates independent updates/deployments, and helps to avoid single point of failure, which can help prevent large-scale outages. We also decided to use Event Driven Architecture pattern which is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. The event-driven architecture is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events.

    To build our #Backend capabilities we decided to use the following: 1. #Microservices - Java with Spring Boot , Node.js with ExpressJS and Python with Flask 2. #Eventsourcingframework - Amazon Kinesis , Amazon Kinesis Firehose , Amazon SNS , Amazon SQS, AWS Lambda 3. #Data - Amazon RDS , Amazon DynamoDB , Amazon S3 , MongoDB Atlas

    To build #Webapps we decided to use Angular 2 with RxJS

    #Devops - GitHub , Travis CI , Terraform , Docker , Serverless

    See more
    Julien DeFrance
    Principal Software Engineer at Tophatter · | 16 upvotes · 2.6M views

    Back in 2014, I was given an opportunity to re-architect SmartZip Analytics platform, and flagship product: SmartTargeting. This is a SaaS software helping real estate professionals keeping up with their prospects and leads in a given neighborhood/territory, finding out (thanks to predictive analytics) who's the most likely to list/sell their home, and running cross-channel marketing automation against them: direct mail, online ads, email... The company also does provide Data APIs to Enterprise customers.

    I had inherited years and years of technical debt and I knew things had to change radically. The first enabler to this was to make use of the cloud and go with AWS, so we would stop re-inventing the wheel, and build around managed/scalable services.

    For the SaaS product, we kept on working with Rails as this was what my team had the most knowledge in. We've however broken up the monolith and decoupled the front-end application from the backend thanks to the use of Rails API so we'd get independently scalable micro-services from now on.

    Our various applications could now be deployed using AWS Elastic Beanstalk so we wouldn't waste any more efforts writing time-consuming Capistrano deployment scripts for instance. Combined with Docker so our application would run within its own container, independently from the underlying host configuration.

    Storage-wise, we went with Amazon S3 and ditched any pre-existing local or network storage people used to deal with in our legacy systems. On the database side: Amazon RDS / MySQL initially. Ultimately migrated to Amazon RDS for Aurora / MySQL when it got released. Once again, here you need a managed service your cloud provider handles for you.

    Future improvements / technology decisions included:

    Caching: Amazon ElastiCache / Memcached CDN: Amazon CloudFront Systems Integration: Segment / Zapier Data-warehousing: Amazon Redshift BI: Amazon Quicksight / Superset Search: Elasticsearch / Amazon Elasticsearch Service / Algolia Monitoring: New Relic

    As our usage grows, patterns changed, and/or our business needs evolved, my role as Engineering Manager then Director of Engineering was also to ensure my team kept on learning and innovating, while delivering on business value.

    One of these innovations was to get ourselves into Serverless : Adopting AWS Lambda was a big step forward. At the time, only available for Node.js (Not Ruby ) but a great way to handle cost efficiency, unpredictable traffic, sudden bursts of traffic... Ultimately you want the whole chain of services involved in a call to be serverless, and that's when we've started leveraging Amazon DynamoDB on these projects so they'd be fully scalable.

    See more
    Amazon Redshift logo

    Amazon Redshift

    1.4K
    1.3K
    107
    Fast, fully managed, petabyte-scale data warehouse service
    1.4K
    1.3K
    + 1
    107
    PROS OF AMAZON REDSHIFT
    • 40
      Data Warehousing
    • 27
      Scalable
    • 17
      SQL
    • 14
      Backed by Amazon
    • 5
      Encryption
    • 1
      Cheap and reliable
    • 1
      Isolation
    • 1
      Best Cloud DW Performance
    • 1
      Fast columnar storage
    CONS OF AMAZON REDSHIFT
      Be the first to leave a con

      related Amazon Redshift posts

      Julien DeFrance
      Principal Software Engineer at Tophatter · | 16 upvotes · 2.6M views

      Back in 2014, I was given an opportunity to re-architect SmartZip Analytics platform, and flagship product: SmartTargeting. This is a SaaS software helping real estate professionals keeping up with their prospects and leads in a given neighborhood/territory, finding out (thanks to predictive analytics) who's the most likely to list/sell their home, and running cross-channel marketing automation against them: direct mail, online ads, email... The company also does provide Data APIs to Enterprise customers.

      I had inherited years and years of technical debt and I knew things had to change radically. The first enabler to this was to make use of the cloud and go with AWS, so we would stop re-inventing the wheel, and build around managed/scalable services.

      For the SaaS product, we kept on working with Rails as this was what my team had the most knowledge in. We've however broken up the monolith and decoupled the front-end application from the backend thanks to the use of Rails API so we'd get independently scalable micro-services from now on.

      Our various applications could now be deployed using AWS Elastic Beanstalk so we wouldn't waste any more efforts writing time-consuming Capistrano deployment scripts for instance. Combined with Docker so our application would run within its own container, independently from the underlying host configuration.

      Storage-wise, we went with Amazon S3 and ditched any pre-existing local or network storage people used to deal with in our legacy systems. On the database side: Amazon RDS / MySQL initially. Ultimately migrated to Amazon RDS for Aurora / MySQL when it got released. Once again, here you need a managed service your cloud provider handles for you.

      Future improvements / technology decisions included:

      Caching: Amazon ElastiCache / Memcached CDN: Amazon CloudFront Systems Integration: Segment / Zapier Data-warehousing: Amazon Redshift BI: Amazon Quicksight / Superset Search: Elasticsearch / Amazon Elasticsearch Service / Algolia Monitoring: New Relic

      As our usage grows, patterns changed, and/or our business needs evolved, my role as Engineering Manager then Director of Engineering was also to ensure my team kept on learning and innovating, while delivering on business value.

      One of these innovations was to get ourselves into Serverless : Adopting AWS Lambda was a big step forward. At the time, only available for Node.js (Not Ruby ) but a great way to handle cost efficiency, unpredictable traffic, sudden bursts of traffic... Ultimately you want the whole chain of services involved in a call to be serverless, and that's when we've started leveraging Amazon DynamoDB on these projects so they'd be fully scalable.

      See more
      Ankit Sobti

      Looker , Stitch , Amazon Redshift , dbt

      We recently moved our Data Analytics and Business Intelligence tooling to Looker . It's already helping us create a solid process for reusable SQL-based data modeling, with consistent definitions across the entire organizations. Looker allows us to collaboratively build these version-controlled models and push the limits of what we've traditionally been able to accomplish with analytics with a lean team.

      For Data Engineering, we're in the process of moving from maintaining our own ETL pipelines on AWS to a managed ELT system on Stitch. We're also evaluating the command line tool, dbt to manage data transformations. Our hope is that Stitch + dbt will streamline the ELT bit, allowing us to focus our energies on analyzing data, rather than managing it.

      See more
      Azure HDInsight logo

      Azure HDInsight

      28
      129
      0
      A cloud-based service from Microsoft for big data analytics
      28
      129
      + 1
      0
      PROS OF AZURE HDINSIGHT
        Be the first to leave a pro
        CONS OF AZURE HDINSIGHT
          Be the first to leave a con

          related Azure HDInsight posts

          Databricks logo

          Databricks

          382
          614
          8
          A unified analytics platform, powered by Apache Spark
          382
          614
          + 1
          8
          PROS OF DATABRICKS
          • 1
            Best Performances on large datasets
          • 1
            True lakehouse architecture
          • 1
            Scalability
          • 1
            Databricks doesn't get access to your data
          • 1
            Usage Based Billing
          • 1
            Security
          • 1
            Data stays in your cloud account
          • 1
            Multicloud
          CONS OF DATABRICKS
            Be the first to leave a con

            related Databricks posts

            Jan Vlnas
            Developer Advocate at Superface · | 5 upvotes · 17.2K views

            From my point of view, both OpenRefine and Apache Hive serve completely different purposes. OpenRefine is intended for interactive cleaning of messy data locally. You could work with their libraries to use some of OpenRefine features as part of your data pipeline (there are pointers in FAQ), but OpenRefine in general is intended for a single-user local operation.

            I can't recommend a particular alternative without better understanding of your use case. But if you are looking for an interactive tool to work with big data at scale, take a look at notebook environments like Jupyter, Databricks, or Deepnote. If you are building a data processing pipeline, consider also Apache Spark.

            Edit: Fixed references from Hadoop to Hive, which is actually closer to Spark.

            See more
            Apache Spark logo

            Apache Spark

            2.7K
            3.2K
            139
            Fast and general engine for large-scale data processing
            2.7K
            3.2K
            + 1
            139
            PROS OF APACHE SPARK
            • 60
              Open-source
            • 48
              Fast and Flexible
            • 8
              Great for distributed SQL like applications
            • 8
              One platform for every big data problem
            • 6
              Easy to install and to use
            • 3
              Works well for most Datascience usecases
            • 2
              Interactive Query
            • 2
              In memory Computation
            • 2
              Machine learning libratimery, Streaming in real
            CONS OF APACHE SPARK
            • 3
              Speed

            related Apache Spark posts

            Eric Colson
            Chief Algorithms Officer at Stitch Fix · | 21 upvotes · 2.6M views

            The algorithms and data infrastructure at Stitch Fix is housed in #AWS. Data acquisition is split between events flowing through Kafka, and periodic snapshots of PostgreSQL DBs. We store data in an Amazon S3 based data warehouse. Apache Spark on Yarn is our tool of choice for data movement and #ETL. Because our storage layer (s3) is decoupled from our processing layer, we are able to scale our compute environment very elastically. We have several semi-permanent, autoscaling Yarn clusters running to serve our data processing needs. While the bulk of our compute infrastructure is dedicated to algorithmic processing, we also implemented Presto for adhoc queries and dashboards.

            Beyond data movement and ETL, most #ML centric jobs (e.g. model training and execution) run in a similarly elastic environment as containers running Python and R code on Amazon EC2 Container Service clusters. The execution of batch jobs on top of ECS is managed by Flotilla, a service we built in house and open sourced (see https://github.com/stitchfix/flotilla-os).

            At Stitch Fix, algorithmic integrations are pervasive across the business. We have dozens of data products actively integrated systems. That requires serving layer that is robust, agile, flexible, and allows for self-service. Models produced on Flotilla are packaged for deployment in production using Khan, another framework we've developed internally. Khan provides our data scientists the ability to quickly productionize those models they've developed with open source frameworks in Python 3 (e.g. PyTorch, sklearn), by automatically packaging them as Docker containers and deploying to Amazon ECS. This provides our data scientist a one-click method of getting from their algorithms to production. We then integrate those deployments into a service mesh, which allows us to A/B test various implementations in our product.

            For more info:

            #DataScience #DataStack #Data

            See more
            Conor Myhrvold
            Tech Brand Mgr, Office of CTO at Uber · | 7 upvotes · 1.2M views

            Why we built Marmaray, an open source generic data ingestion and dispersal framework and library for Apache Hadoop :

            Built and designed by our Hadoop Platform team, Marmaray is a plug-in-based framework built on top of the Hadoop ecosystem. Users can add support to ingest data from any source and disperse to any sink leveraging the use of Apache Spark . The name, Marmaray, comes from a tunnel in Turkey connecting Europe and Asia. Similarly, we envisioned Marmaray within Uber as a pipeline connecting data from any source to any sink depending on customer preference:

            https://eng.uber.com/marmaray-hadoop-ingestion-open-source/

            (Direct GitHub repo: https://github.com/uber/marmaray Kafka Kafka Manager )

            See more
            Snowflake logo

            Snowflake

            872
            1K
            19
            The data warehouse built for the cloud
            872
            1K
            + 1
            19
            PROS OF SNOWFLAKE
            • 4
              Public and Private Data Sharing
            • 3
              Good Performance
            • 3
              Multicloud
            • 2
              Great Documentation
            • 2
              User Friendly
            • 2
              Serverless
            • 1
              Innovative
            • 1
              Usage based billing
            • 1
              Economical
            CONS OF SNOWFLAKE
              Be the first to leave a con

              related Snowflake posts

              I'm wondering if any Cloud Firestore users might be open to sharing some input and challenges encountered when trying to create a low-cost, low-latency data pipeline to their Analytics warehouse (e.g. Google BigQuery, Snowflake, etc...)

              I'm working with a platform by the name of Estuary.dev, an ETL/ELT and we are conducting some research on the pain points here to see if there are drawbacks of the Firestore->BQ extension and/or if users are seeking easy ways for getting nosql->fine-grained tabular data

              Please feel free to drop some knowledge/wish list stuff on me for a better pipeline here!

              See more
              Shared insights
              on
              Google BigQueryGoogle BigQuerySnowflakeSnowflake

              I use Google BigQuery because it makes is super easy to query and store data for analytics workloads. If you're using GCP, you're likely using BigQuery. However, running data viz tools directly connected to BigQuery will run pretty slow. They recently announced BI Engine which will hopefully compete well against big players like Snowflake when it comes to concurrency.

              What's nice too is that it has SQL-based ML tools, and it has great GIS support!

              See more