Alternatives to Apache Spark logo

Alternatives to Apache Spark

Hadoop, Splunk, Cassandra, Apache Beam, and Apache Flume are the most popular alternatives and competitors to Apache Spark.
1.1K
852
+ 1
98

What is Apache Spark and what are its top alternatives?

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.
Apache Spark is a tool in the Big Data Tools category of a tech stack.
Apache Spark is an open source tool with 24.5K GitHub stars and 20.8K GitHub forks. Here鈥檚 a link to Apache Spark's open source repository on GitHub

Apache Spark alternatives & related posts

Hadoop logo

Hadoop

1.1K
923
48
1.1K
923
+ 1
48
Open-source software for reliable, scalable, distributed computing
Hadoop logo
Hadoop
VS
Apache Spark logo
Apache Spark

related Hadoop posts

StackShare Editors
StackShare Editors
| 4 upvotes 107.1K views
atUber TechnologiesUber Technologies
Kafka
Kafka
Kibana
Kibana
Elasticsearch
Elasticsearch
Logstash
Logstash
Hadoop
Hadoop

With interactions across each other and mobile devices, logging is important as it is information for internal cases like debugging and business cases like dynamic pricing.

With multiple Kafka clusters, data is archived into Hadoop before expiration. Data is ingested in realtime and indexed into an ELK stack. The ELK stack comprises of Elasticsearch, Logstash, and Kibana for searching and visualization.

See more
StackShare Editors
StackShare Editors
Prometheus
Prometheus
Chef
Chef
Consul
Consul
Memcached
Memcached
Hack
Hack
Swift
Swift
Hadoop
Hadoop
Terraform
Terraform
Airflow
Airflow
Apache Spark
Apache Spark
Kubernetes
Kubernetes
gRPC
gRPC
HHVM (HipHop Virtual Machine)
HHVM (HipHop Virtual Machine)
Presto
Presto
Kotlin
Kotlin
Apache Thrift
Apache Thrift

Since the beginning, Cal Henderson has been the CTO of Slack. Earlier this year, he commented on a Quora question summarizing their current stack.

Apps
  • Web: a mix of JavaScript/ES6 and React.
  • Desktop: And Electron to ship it as a desktop application.
  • Android: a mix of Java and Kotlin.
  • iOS: written in a mix of Objective C and Swift.
Backend
  • The core application and the API written in PHP/Hack that runs on HHVM.
  • The data is stored in MySQL using Vitess.
  • Caching is done using Memcached and MCRouter.
  • The search service takes help from SolrCloud, with various Java services.
  • The messaging system uses WebSockets with many services in Java and Go.
  • Load balancing is done using HAproxy with Consul for configuration.
  • Most services talk to each other over gRPC,
  • Some Thrift and JSON-over-HTTP
  • Voice and video calling service was built in Elixir.
Data warehouse
  • Built using open source tools including Presto, Spark, Airflow, Hadoop and Kafka.
Etc
See more
Splunk logo

Splunk

163
90
0
163
90
+ 1
0
Search, monitor, analyze and visualize machine data
    Be the first to leave a pro
    Splunk logo
    Splunk
    VS
    Apache Spark logo
    Apache Spark

    related Splunk posts

    Kibana
    Kibana
    Splunk
    Splunk
    Grafana
    Grafana

    I use Kibana because it ships with the ELK stack. I don't find it as powerful as Splunk however it is light years above grepping through log files. We previously used Grafana but found it to be annoying to maintain a separate tool outside of the ELK stack. We were able to get everything we needed from Kibana.

    See more
    Cassandra logo

    Cassandra

    2.1K
    1.6K
    443
    2.1K
    1.6K
    + 1
    443
    A partitioned row store. Rows are organized into tables with a required primary key.
    Cassandra logo
    Cassandra
    VS
    Apache Spark logo
    Apache Spark

    related Cassandra posts

    Thierry Schellenbach
    Thierry Schellenbach
    CEO at Stream | 17 upvotes 93.6K views
    atStreamStream
    Redis
    Redis
    Cassandra
    Cassandra
    RocksDB
    RocksDB
    #InMemoryDatabases
    #DataStores
    #Databases

    1.0 of Stream leveraged Cassandra for storing the feed. Cassandra is a common choice for building feeds. Instagram, for instance started, out with Redis but eventually switched to Cassandra to handle their rapid usage growth. Cassandra can handle write heavy workloads very efficiently.

    Cassandra is a great tool that allows you to scale write capacity simply by adding more nodes, though it is also very complex. This complexity made it hard to diagnose performance fluctuations. Even though we had years of experience with running Cassandra, it still felt like a bit of a black box. When building Stream 2.0 we decided to go for a different approach and build Keevo. Keevo is our in-house key-value store built upon RocksDB, gRPC and Raft.

    RocksDB is a highly performant embeddable database library developed and maintained by Facebook鈥檚 data engineering team. RocksDB started as a fork of Google鈥檚 LevelDB that introduced several performance improvements for SSD. Nowadays RocksDB is a project on its own and is under active development. It is written in C++ and it鈥檚 fast. Have a look at how this benchmark handles 7 million QPS. In terms of technology it鈥檚 much more simple than Cassandra.

    This translates into reduced maintenance overhead, improved performance and, most importantly, more consistent performance. It鈥檚 interesting to note that LinkedIn also uses RocksDB for their feed.

    #InMemoryDatabases #DataStores #Databases

    See more
    Laravel
    Laravel
    Zend Framework
    Zend Framework
    MySQL
    MySQL
    MongoDB
    MongoDB
    Cassandra
    Cassandra
    React
    React
    AngularJS
    AngularJS
    jQuery
    jQuery
    Docker
    Docker
    Linux
    Linux

    React AngularJS jQuery

    Laravel Zend Framework

    MySQL MongoDB Cassandra

    Docker

    Linux

    See more
    Apache Beam logo

    Apache Beam

    22
    14
    0
    22
    14
    + 1
    0
    A unified programming model
      Be the first to leave a pro
      Apache Beam logo
      Apache Beam
      VS
      Apache Spark logo
      Apache Spark
      Apache Flume logo

      Apache Flume

      15
      8
      0
      15
      8
      + 1
      0
      A service for collecting, aggregating, and moving large amounts of log data
        Be the first to leave a pro
        Apache Flume logo
        Apache Flume
        VS
        Apache Spark logo
        Apache Spark
        Apache Storm logo

        Apache Storm

        130
        116
        18
        130
        116
        + 1
        18
        Distributed and fault-tolerant realtime computation
        Apache Storm logo
        Apache Storm
        VS
        Apache Spark logo
        Apache Spark

        related Apache Storm posts

        Marc Bollinger
        Marc Bollinger
        Infra & Data Eng Manager at Lumosity | 4 upvotes 81.9K views
        atLumosityLumosity
        Node.js
        Node.js
        Ruby
        Ruby
        Kafka
        Kafka
        Scala
        Scala
        Apache Storm
        Apache Storm
        Heron
        Heron
        Redis
        Redis
        Pulsar
        Pulsar

        Lumosity is home to the world's largest cognitive training database, a responsibility we take seriously. For most of the company's history, our analysis of user behavior and training data has been powered by an event stream--first a simple Node.js pub/sub app, then a heavyweight Ruby app with stronger durability. Both supported decent throughput and latency, but they lacked some major features supported by existing open-source alternatives: replaying existing messages (also lacking in most message queue-based solutions), scaling out many different readers for the same stream, the ability to leverage existing solutions for reading and writing, and possibly most importantly: the ability to hire someone externally who already had expertise.

        We ultimately migrated to Kafka in early- to mid-2016, citing both industry trends in companies we'd talked to with similar durability and throughput needs, the extremely strong documentation and community. We pored over Kyle Kingsbury's Jepsen post (https://aphyr.com/posts/293-jepsen-Kafka), as well as Jay Kreps' follow-up (http://blog.empathybox.com/post/62279088548/a-few-notes-on-kafka-and-jepsen), talked at length with Confluent folks and community members, and still wound up running parallel systems for quite a long time, but ultimately, we've been very, very happy. Understanding the internals and proper levers takes some commitment, but it's taken very little maintenance once configured. Since then, the Confluent Platform community has grown and grown; we've gone from doing most development using custom Scala consumers and producers to being 60/40 Kafka Streams/Connects.

        We originally looked into Storm / Heron , and we'd moved on from Redis pub/sub. Heron looks great, but we already had a programming model across services that was more akin to consuming a message consumers than required a topology of bolts, etc. Heron also had just come out while we were starting to migrate things, and the community momentum and direction of Kafka felt more substantial than the older Storm. If we were to start the process over again today, we might check out Pulsar , although the ecosystem is much younger.

        To find out more, read our 2017 engineering blog post about the migration!

        See more

        related Kafka posts

        Eric Colson
        Eric Colson
        Chief Algorithms Officer at Stitch Fix | 19 upvotes 354.5K views
        atStitch FixStitch Fix
        Kafka
        Kafka
        PostgreSQL
        PostgreSQL
        Amazon S3
        Amazon S3
        Apache Spark
        Apache Spark
        Presto
        Presto
        Python
        Python
        R
        R
        PyTorch
        PyTorch
        Docker
        Docker
        Amazon EC2 Container Service
        Amazon EC2 Container Service
        #AWS
        #Etl
        #ML
        #DataScience
        #DataStack
        #Data

        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
        John Kodumal
        John Kodumal
        CTO at LaunchDarkly | 15 upvotes 190.7K views
        atLaunchDarklyLaunchDarkly
        Amazon RDS
        Amazon RDS
        PostgreSQL
        PostgreSQL
        TimescaleDB
        TimescaleDB
        Patroni
        Patroni
        Consul
        Consul
        Amazon ElastiCache
        Amazon ElastiCache
        Amazon EC2
        Amazon EC2
        Redis
        Redis
        Amazon Kinesis
        Amazon Kinesis
        Kafka
        Kafka

        As we've evolved or added additional infrastructure to our stack, we've biased towards managed services. Most new backing stores are Amazon RDS instances now. We do use self-managed PostgreSQL with TimescaleDB for time-series data鈥攖his is made HA with the use of Patroni and Consul.

        We also use managed Amazon ElastiCache instances instead of spinning up Amazon EC2 instances to run Redis workloads, as well as shifting to Amazon Kinesis instead of Kafka.

        See more
        PySpark logo

        PySpark

        27
        17
        0
        27
        17
        + 1
        0
        The Python API for Spark
          Be the first to leave a pro
          PySpark logo
          PySpark
          VS
          Apache Spark logo
          Apache Spark

          related Amazon Athena posts

          Amazon Athena
          Amazon Athena
          Google BigQuery
          Google BigQuery

          I use Amazon Athena because similar to Google BigQuery , you can store and query data easily. Especially since you can define data schema in the Glue data catalog, there's a central way to define data models.

          However, I would not recommend for batch jobs. I typically use this to check intermediary datasets in data engineering workloads. It's good for getting a look and feel of the data along its ETL journey.

          See more

          related Apache Flink posts

          Surabhi Bhawsar
          Surabhi Bhawsar
          Technical Architect at Pepcus | 6 upvotes 45.3K views
          Kafka
          Kafka
          Apache Flink
          Apache Flink

          I need to build the Alert & Notification framework with the use of a scheduled program. We will analyze the events from the database table and filter events that are falling under a day timespan and send these event messages over email. Currently, we are using Kafka Pub/Sub for messaging. The customer wants us to move on Apache Flink, I am trying to understand how Apache Flink could be fit better for us.

          See more
          Apache Hive logo

          Apache Hive

          119
          54
          0
          119
          54
          + 1
          0
          Data Warehouse Software for Reading, Writing, and Managing Large Datasets
            Be the first to leave a pro
            Apache Hive logo
            Apache Hive
            VS
            Apache Spark logo
            Apache Spark

            related Apache Hive posts

            Ashish Singh
            Ashish Singh
            Tech Lead, Big Data Platform at Pinterest | 20 upvotes 35.6K views
            Apache Hive
            Apache Hive
            Kubernetes
            Kubernetes
            Kafka
            Kafka
            Amazon S3
            Amazon S3
            Amazon EC2
            Amazon EC2
            Presto
            Presto
            #DataScience
            #DataEngineering
            #AWS
            #BigData

            To provide employees with the critical need of interactive querying, we鈥檝e worked with Presto, an open-source distributed SQL query engine, over the years. Operating Presto at Pinterest鈥檚 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
            Presto logo

            Presto

            114
            192
            46
            114
            192
            + 1
            46
            Distributed SQL Query Engine for Big Data
            Presto logo
            Presto
            VS
            Apache Spark logo
            Apache Spark

            related Presto posts

            Ashish Singh
            Ashish Singh
            Tech Lead, Big Data Platform at Pinterest | 20 upvotes 35.6K views
            Apache Hive
            Apache Hive
            Kubernetes
            Kubernetes
            Kafka
            Kafka
            Amazon S3
            Amazon S3
            Amazon EC2
            Amazon EC2
            Presto
            Presto
            #DataScience
            #DataEngineering
            #AWS
            #BigData

            To provide employees with the critical need of interactive querying, we鈥檝e worked with Presto, an open-source distributed SQL query engine, over the years. Operating Presto at Pinterest鈥檚 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
            Eric Colson
            Eric Colson
            Chief Algorithms Officer at Stitch Fix | 19 upvotes 354.5K views
            atStitch FixStitch Fix
            Kafka
            Kafka
            PostgreSQL
            PostgreSQL
            Amazon S3
            Amazon S3
            Apache Spark
            Apache Spark
            Presto
            Presto
            Python
            Python
            R
            R
            PyTorch
            PyTorch
            Docker
            Docker
            Amazon EC2 Container Service
            Amazon EC2 Container Service
            #AWS
            #Etl
            #ML
            #DataScience
            #DataStack
            #Data

            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
            Druid logo

            Druid

            107
            152
            17
            107
            152
            + 1
            17
            Fast column-oriented distributed data store
            Druid logo
            Druid
            VS
            Apache Spark logo
            Apache Spark
            AWS Glue logo

            AWS Glue

            63
            38
            0
            63
            38
            + 1
            0
            Fully managed extract, transform, and load (ETL) service
              Be the first to leave a pro
              AWS Glue logo
              AWS Glue
              VS
              Apache Spark logo
              Apache Spark
              Apache Impala logo

              Apache Impala

              58
              56
              8
              58
              56
              + 1
              8
              Real-time Query for Hadoop
              Apache Impala logo
              Apache Impala
              VS
              Apache Spark logo
              Apache Spark
              Amazon Redshift Spectrum logo

              Amazon Redshift Spectrum

              38
              36
              0
              38
              36
              + 1
              0
              Exabyte-Scale In-Place Queries of S3 Data
                Be the first to leave a pro