Need advice about which tool to choose?Ask the StackShare community!
Apache Spark vs Serverless: What are the differences?
Introduction:
Apache Spark and Serverless are two popular technologies used for big data processing and analytics. Although they both provide solutions for handling large datasets, there are key differences between them. In this article, we will discuss the six main differences between Apache Spark and Serverless.
Deployment Model: Apache Spark is typically deployed on a cluster of machines, where data is distributed and processing is done in parallel. On the other hand, Serverless technologies like AWS Lambda or Azure Functions are event-driven and allow developers to run code on demand without having to manage the underlying infrastructure.
Resource Allocation: In Apache Spark, resources need to be pre-allocated and managed manually, specifying how much memory or cores should be allocated for each job. Serverless platforms, on the other hand, automatically allocate resources based on the demand, scaling up or down as needed. This allows for better resource utilization and cost optimization.
Scalability: Apache Spark provides horizontal scalability, meaning it can scale by adding more machines to the cluster. Serverless platforms also provide scalability, but at the function level. Each function can scale independently based on the incoming workload, without affecting other functions.
State Management: Apache Spark provides an in-memory computing model, allowing users to persist data in memory for faster processing. Serverless platforms, on the other hand, are stateless by design. They are designed to handle short-lived functions that process small units of data and do not provide built-in support for persistent state.
Cost Model: Apache Spark requires the setup and management of a dedicated cluster, which may require upfront costs for hardware and infrastructure. Serverless platforms follow a pay-as-you-go pricing model, where users only pay for the actual execution time and resources used by their functions, leading to potential cost savings, especially for sporadic workloads.
Flexibility: Apache Spark provides a wide range of data processing and analysis capabilities through its extensive library ecosystem. It supports batch processing, interactive queries, machine learning, and graph processing. Serverless platforms, on the other hand, are more focused on event-driven functions and are optimized for short-lived, stateless operations.
In Summary, Apache Spark and Serverless differ in their deployment model, resource allocation, scalability, state management, cost model, and flexibility. Apache Spark requires a dedicated cluster, manual resource allocation, and is capable of handling large and complex workloads. Serverless platforms are event-driven, automatically allocate resources, and are optimized for short-lived functions with lower upfront costs.
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"
When adding a new feature to Checkly rearchitecting some older piece, I tend to pick Heroku for rolling it out. But not always, because sometimes I pick AWS Lambda . The short story:
- Developer Experience trumps everything.
- AWS Lambda is cheap. Up to a limit though. This impact not only your wallet.
- If you need geographic spread, AWS is lonely at the top.
Recently, I was doing a brainstorm at a startup here in Berlin on the future of their infrastructure. They were ready to move on from their initial, almost 100% Ec2 + Chef based setup. Everything was on the table. But we crossed out a lot quite quickly:
- Pure, uncut, self hosted Kubernetes — way too much complexity
- Managed Kubernetes in various flavors — still too much complexity
- Zeit — Maybe, but no Docker support
- Elastic Beanstalk — Maybe, bit old but does the job
- Heroku
- Lambda
It became clear a mix of PaaS and FaaS was the way to go. What a surprise! That is exactly what I use for Checkly! But when do you pick which model?
I chopped that question up into the following categories:
- Developer Experience / DX 🤓
- Ops Experience / OX 🐂 (?)
- Cost 💵
- Lock in 🔐
Read the full post linked below for all details
Pros of Serverless
- API integration14
- Supports cloud functions for Google, Azure, and IBM7
- Lower cost3
- 3. Simplified Management for developers to focus on cod1
- Auto scale1
- 5. Built-in Redundancy and Availability:1
- Openwhisk1
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 Serverless
Cons of Apache Spark
- Speed4