Amazon EMR is a cloud-native big data platform for processing vast amounts of data quickly, at scale. Using open source tools such as Apache Spark, Apache Hive, Apache HBase, Apache Flink, Apache Hudi (Incubating), and Presto, coupled with the scalability of Amazon EC2 and scalable storage of Amazon S3, EMR gives analytical teams the engines and elasticity to run Petabyte-scale analysis.
N/A
Db2 Big SQL
Score 8.7 out of 10
N/A
IBM offers Db2 Big SQL, an enterprise grade hybrid ANSI-compliant SQL on Hadoop engine, delivering massively parallel processing (MPP) and advanced data query. Big SQL offers a single database connection or query for disparate sources such as HDFS, RDMS, NoSQL databases, object stores and WebHDFS.
We are running it to perform preparation which takes a few hours on EC2 to be running on a spark-based EMR cluster to total the preparation inside minutes rather than a few hours. Ease of utilization and capacity to select from either Hadoop or spark. Processing time diminishes from 5-8 hours to 25-30 minutes compared with the Ec2 occurrence and more in a few cases.
My recommendation obviously would depend on the application. But I think given the right requirements, IBM DB2 Big SQL is definitely a contender for a database platform. Especially when disparate data and multiple data stores are involved. I like the fact I can use the product to federate my data and make it look like it's all in one place. The engine is high performance and if you desire to use Hadoop, this could be your platform.
Amazon Elastic MapReduce works well for managing analyses that use multiple tools, such as Hadoop and Spark. If it were not for the fact that we use multiple tools, there would be less need for MapReduce.
MapReduce is always on. I've never had a problem getting data analyses to run on the system. It's simple to set up data mining projects.
Amazon Elastic MapReduce has no problems dealing with very large data sets. It processes them just fine. With that said, the outputs don't come instantaneously. It takes time.
Sometimes bootstrapping certain tools comes with debugging costs. The tools provided by some of the enterprise editions are great compared to EMR.
Like some of the enterprise editions EMR does not provide on premises options.
No UI client for saving the workbooks or code snippets. Everything has to go through submitting process. Not really convenient for tracking the job as well.
I give Amazon EMR this rating because while it is great at simplifying running big data frameworks, providing the Amazon EMR highlights, product details, and pricing information, and analyzing vast amounts of data, it can be run slow, freeze and glitch sometimes. So overall Amazon EMR is pretty good to use other than some basic issues.
IBM DB2 is a solid service but hasn't seen much innovation over the past decade. It gets the job done and supports our IT operations across digital so it is fair.
There's a vast group of trained and certified (by AWS) professionals ready to work for anyone that needs to implement, configure or fix EMR. There's also a great amount of documentation that is accessible to anyone who's trying to learn this. And there's also always the help of AWS itself. They have people ready to help you analyze your needs and then make a recommendation.
IBM did a good job of supporting us during our evaluation and proof of concept. They were able to provide all necessary guidance, answer questions, help us architect it, etc. We were pleased with the support provided by the vendor. I will caveat and say this support was all before the sale, however, we have a ton of IBM products and they provide the same high level of support for all of them. I didn't see this being any different. I give IBM support two thumbs up!
Snowflake is a lot easier to get started with than the other options. Snowflake's data lake building capabilities are far more powerful. Although Amazon EMR isn't our first pick, we've had an excellent experience with EC2 and S3. Because of our current API interfaces, it made more sense for us to continue with Hadoop rather than explore other options.
MS SQL Server was ruled out given we didn't feel we could collapse environments. We thought of MS-SQL as more of a one for one replacement for Sybase ASE, i.e., server for server. SAP HANA was evaluated and given a big thumbs up but was rejected because the SQL would have to be rewritten at the time (now they have an accelerator so you don't have to). Also, there was a very low adoption rate within the enterprise. IBM DB2 Big SQL was not selected even though technically it achieved high scores, because we could not find readily available talent and low adoption rate within the enterprise (basically no adoption at the time). We ended up selecting Exadata because of the high adoption rate within the enterprise even though technically HANA and Big SQL were superior in our evaluations.
