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.
450
519
+ 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

36.1K
25.1K
2.5K
Scalable, pay-as-you-go compute capacity in the cloud
36.1K
25.1K
+ 1
2.5K
PROS OF AMAZON EC2
  • 644
    Quick and reliable cloud servers
  • 515
    Scalability
  • 391
    Easy management
  • 276
    Low cost
  • 269
    Auto-scaling
  • 88
    Market leader
  • 80
    Backed by amazon
  • 78
    Reliable
  • 66
    Free tier
  • 57
    Easy management, scalability
  • 12
    Flexible
  • 10
    Easy to Start
  • 9
    Web-scale
  • 8
    Widely used
  • 8
    Elastic
  • 7
    Node.js API
  • 4
    Industry Standard
  • 3
    Lots of configuration options
  • 2
    GPU instances
  • 1
    Amazing for individuals
  • 1
    Extremely simple to use
  • 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 · | 35 upvotes · 750K 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 · | 28 upvotes · 2.6M 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

1.9K
1.9K
55
Open-source software for reliable, scalable, distributed computing
1.9K
1.9K
+ 1
55
PROS OF HADOOP
  • 38
    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

    Conor Myhrvold
    Tech Brand Mgr, Office of CTO at Uber · | 7 upvotes · 938.3K 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
    Shared insights
    on
    Kafka
    Hadoop
    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
    Amazon DynamoDB logo

    Amazon DynamoDB

    3K
    2.6K
    195
    Fully managed NoSQL database service
    3K
    2.6K
    + 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
      Document Limit Size

    related Amazon DynamoDB posts

    Julien DeFrance
    Principal Software Engineer at Tophatter · | 16 upvotes · 2.3M 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
    Dmitry Mukhin

    Uploadcare has built an infinitely scalable infrastructure by leveraging AWS. Building on top of AWS allows us to process 350M daily requests for file uploads, manipulations, and deliveries. When we started in 2011 the only cloud alternative to AWS was Google App Engine which was a no-go for a rather complex solution we wanted to build. We also didn’t want to buy any hardware or use co-locations.

    Our stack handles receiving files, communicating with external file sources, managing file storage, managing user and file data, processing files, file caching and delivery, and managing user interface dashboards.

    At its core, Uploadcare runs on Python. The Europython 2011 conference in Florence really inspired us, coupled with the fact that it was general enough to solve all of our challenges informed this decision. Additionally we had prior experience working in Python.

    We chose to build the main application with Django because of its feature completeness and large footprint within the Python ecosystem.

    All the communications within our ecosystem occur via several HTTP APIs, Redis, Amazon S3, and Amazon DynamoDB. We decided on this architecture so that our our system could be scalable in terms of storage and database throughput. This way we only need Django running on top of our database cluster. We use PostgreSQL as our database because it is considered an industry standard when it comes to clustering and scaling.

    See more
    Amazon Redshift logo

    Amazon Redshift

    1.2K
    1K
    103
    Fast, fully managed, petabyte-scale data warehouse service
    1.2K
    1K
    + 1
    103
    PROS OF AMAZON REDSHIFT
    • 37
      Data Warehousing
    • 27
      Scalable
    • 16
      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.3M 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

      24
      98
      0
      A cloud-based service from Microsoft for big data analytics
      24
      98
      + 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

          243
          404
          0
          A unified analytics platform, powered by Apache Spark
          243
          404
          + 1
          0
          PROS OF DATABRICKS
            Be the first to leave a pro
            CONS OF DATABRICKS
              Be the first to leave a con

              related Databricks posts

              Apache Spark logo

              Apache Spark

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

              related Apache Spark posts

              Eric Colson
              Chief Algorithms Officer at Stitch Fix · | 21 upvotes · 1.8M 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 · 938.3K 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

              541
              664
              6
              The data warehouse built for the cloud
              541
              664
              + 1
              6
              PROS OF SNOWFLAKE
              • 2
                Good Performance
              • 1
                Public and Private Data Sharing
              • 1
                Multicloud
              • 1
                Great Documentation
              • 1
                Serverless
              CONS OF SNOWFLAKE
                Be the first to leave a con

                related Snowflake posts

                Shared insights
                on
                Google BigQuery
                Snowflake

                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
                Shared insights
                on
                Snowflake
                Hadoop
                MarkLogic

                For a property and casualty insurance company, we currently use MarkLogic and Hadoop for our raw data lake. Trying to figure out how snowflake fits in the picture. Does anybody have some good suggestions/best practices for when to use and what data to store in Mark logic versus Snowflake versus a hadoop or all three of these platforms redundant with one another?

                See more