Apache Spark vs. Google BigQuery vs. Amazon Redshift

Apache Spark has rich APIs for regular data transformations or for ML workloads or for graph workloads, whereas other systems may not such a wide range of support. Choose it when you need to perform data transformations for big data as offline jobs, whereas use MongoDB-like distributed database systems for more realtime queries.

Incentivized

Google BigQuery is great for being the central datastore and entry point of data if you're on GCP. It seamlessly integrates with other Google products, meaning you can ingest data from other Google products with ease and little technical knowledge, and all of it is near real-time. Being serverless, BigQuery will scale with you, which means you don't have to worry about contention or spikes in demand/storage. This can, however, mean your costs can run away quickly or mount up at short notice.

Incentivized

If the number of connections is expected to be low, but the amounts of data are large or projected to grow it is a good solutions especially if there is previous exposure to PostgreSQL. Speaking of Postgres, Redshift is based on several versions old releases of PostgreSQL so the developers would not be able to take advantage of some of the newer SQL language features. The queries need some fine-tuning still, indexing is not provided, but playing with sorting keys becomes necessary. Lastly, there is no notion of the Primary Key in Redshift so the business must be prepared to explain why duplication occurred (must be vigilant for)

Incentivized

• It performs a conventional disk-based process when the data sets are too large to fit into memory, which is very useful because, regardless of the size of the data, it is always possible to store them.
• It has great speed and ability to join multiple types of databases and run different types of analysis applications. This functionality is super useful as it reduces work times
• Apache Spark uses the data storage model of Hadoop and can be integrated with other big data frameworks such as HBase, MongoDB, and Cassandra. This is very useful because it is compatible with multiple frameworks that the company has, and thus allows us to unify all the processes.

Incentivized

• Its serverless architecture and underlying Dremel technology are incredibly fast even on complex datasets. I can get answers to my questions almost instantly, without waiting hours for traditional data warehouses to churn through the data.
• Previously, our data was scattered across various databases and spreadsheets and getting a holistic view was pretty difficult. Google BigQuery acts as a central repository and consolidates everything in one place to join data sets and find hidden patterns.
• Running reports on our old systems used to take forever. Google BigQuery's crazy fast query speed lets us get insights from massive datasets in seconds.

Incentivized

• Redshift is fully managed. Small teams do not have the resources to maintain a cluster. CloudWatch metrics are provided out-of-the-box, and it is easy to configure alarms.
• Redshift's console allows you to easily inspect and manage queries, and manage the performance of the cluster.
• Redshift is ubiquitous; many products (e.g., ETL services) integrate with it out-of-the-box.
• Writing .csvs to S3 and querying them through Redshift Spectrum is convenient.

Incentivized

• Memory management. Very weak on that.
• PySpark not as robust as scala with spark.
• spark master HA is needed. Not as HA as it should be.
• Locality should not be a necessity, but does help improvement. But would prefer no locality

Incentivized

• It is challenging to predict costs due to BigQuery's pay-per-query pricing model. User-friendly cost estimation tools, along with improved budget alerting features, could help users better manage and predict expenses.
• The BigQuery interface is less intuitive. A more user-friendly interface, enhanced documentation, and built-in tutorial systems could make BigQuery more accessible to a broader audience.

Incentivized

• It could benefit from adding data integrity and programming tools common to other database management systems.
• Amazon Redshift is based on PostgreSQL 8.0.2. That version of PostgreSQL was released in December 2006. While PostgreSQL was much improved since then, the new features were not implemented in Redshift. Many basic features are missing from it.
• Primary keys can be declared but not enforced. Referential integrity (foreign keys) can be declared but not enforced. UNIQUE and CHECK constraints are not supported and cannot be declared.
• IDENTITY can be declared on a column, and Redshift will put unique values into it. However: IDENTITY values in the newly inserted rows won’t be incremental or sequential. To implement a sequential number, you need to write your own custom code.
• There are no stored procedures in Redshift. We are writing SQL script files, and then parsing and running them one statement at a time from a Python program. This also enabled us to implement execution-time error logging.
• In SQL scripts, to check for the row count of affected rows, a complicated join query against some system tables or views has to be executed.
• Data Control Language (DCL) does not exist. No statements like IF, WHILE, DO, RAISERROR, etc.
• On performance of views… Views do not “pass-through” a query parameter which is a potential problem for performance.
• When selecting against a view with the WHERE clause outside of the view, the inner query of the view will be executed first without consideration for the WHERE clause, and only then the WHERE clause will be applied.
• Certain clauses of SQL work many times faster than other clauses. So be careful and test your statements for performance earlier rather than later, especially if working with a large data set.
• There was a situation when DELETE FROM JOIN was unacceptably slow. Replacing JOIN with the USING clause made DELETE instantaneous.

Incentivized

Capacity of computing data in cluster and fast speed.

We have to use this product as its a 3rd party supplier choice to utilise this product for their data side backend so will not be likely we will move away from this product in the future unless the 3rd party supplier decides to change data vendors.

Incentivized

If the team looking to use Apache Spark is not used to debug and tweak settings for jobs to ensure maximum optimizations, it can be frustrating. However, the documentation and the support of the community on the internet can help resolve most issues. Moreover, it is highly configurable and it integrates with different tools (eg: it can be used by dbt core), which increase the scenarios where it can be used

Incentivized

web UI is easy and convenient. Many RDBMS clients such as aqua data studio, Dbeaver data grid, and others connect. Range of well-documented APIs available. The range of features keeps expanding, increasing similar features to traditional RDBMS such as Oracle and DB2

Overall it serves all our aspects of data management like data cleaning, data manipulation, and data reporting on the cloud platform. We can create stored procedures and triggers in it very easily as all the options are self suggested in it. We can easily attach the results of ARS to the other tools as well for drawing the statistical results.

Incentivized

I have never had any significant issues with Google Big Query. It always seems to be up and running properly when I need it. I cannot recall any times where I received any kind of application errors or unplanned outages. If there were any they were resolved quickly by my IT team so I didn't notice them.

Incentivized

I think Google Big Query's performance is in the acceptable range. Sometimes larger datasets are somewhat sluggish to load but for most of our applications it performs at a reasonable speed. We do have some reports that include a lot of complex calculations and others that run on granular store level data that so sometimes take a bit longer to load which can be frustrating.

Incentivized

1. It integrates very well with scala or python. 2. It's very easy to understand SQL interoperability. 3. Apache is way faster than the other competitive technologies. 4. The support from the Apache community is very huge for Spark. 5. Execution times are faster as compared to others. 6. There are a large number of forums available for Apache Spark. 7. The code availability for Apache Spark is simpler and easy to gain access to. 8. Many organizations use Apache Spark, so many solutions are available for existing applications.

BigQuery can be difficult to support because it is so solid as a product. Many of the issues you will see are related to your own data sets, however you may see issues importing data and managing jobs. If this occurs, it can be a challenge to get to speak to the correct person who can help you.

Incentivized

The support was great and helped us in a timely fashion. We did use a lot of online forums as well, but the official documentation was an ongoing one, and it did take more time for us to look through it. We would have probably chosen a competitor product had it not been for the great support

Incentivized

We used Surprise Kit for one of the other research works. It is more fine-tuned to Recommendation systems and their algorithms. Apache Spark has MLlib for majority of ML problems. Where as software like Surprse Kit - it suitable for a specific task of Recommendations only

Incentivized

Google BigQuery of course collects a much much larger array of raw data and can handle (practically) an unlimited amount of data. For a large enterprise like ours that relies on large-scale analytics, this is absolutely imperative. Google BigQuery can also combine GA4 data with external sources (like CRM tools), so our analytics can be unified. Due to our heavy reliance on GA4, Google BigQuery is the natural choice since it is a Google product and has better integration.

Incentivized

We evaluated [Amazon] Redshift vs BigQuery vs Amazon EMR, back in 2014. Back then BigQuery cost was slightly higher than that of [Amazon] Redshift price structure. Amazon EMR, needs lots more management (Admin tasks) and EMR is designed to be ephemeral and not designed to be a data store. [Amazon] Redshift was ideal with the price structure, performance and ROI[.]

Incentivized

We have continued to expand out use of Google Big Query over the years. I'd say its flexibility and scalability is actually quite good. It also integrates well with other tools like Tableau and Power BI. It has served the needs of multiple data sources across multiple departments within my company.

Incentivized

• Faster turn around on feature development, we have seen a noticeable improvement in our agile development since using Spark.
• Easy adoption, having multiple departments use the same underlying technology even if the use cases are very different allows for more commonality amongst applications which definitely makes the operations team happy.
• Performance, we have been able to make some applications run over 20x faster since switching to Spark. This has saved us time, headaches, and operating costs.

Incentivized

• In some places, Google BigQuery has helped us save some money by avoiding the need for expensive infrastructure and reducing some of the operational costs.
• Scalability is up-to-date and really helpful in multiple places.
• Knowledge transfer is easy as it is very user-friendly, so the learning curve has been reduced.
• Also, it gives us more insights from our data, helping us make smarter decisions for our business.

Incentivized

• It allows for an almost seamless integration of our data which can then be used by other departments for analytical purposes.
• No in house resources are needed for keeping the data alive and performing backup/migration tasks of the data in its end state.

Incentivized