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
Apache Sqoop
Score 8.8 out of 10
N/A
Apache Sqoop is a tool for use with Hadoop, used to transfer data between Apache Hadoop and other, structured data stores.
N/A
Oracle GoldenGate
Score 8.7 out of 10
N/A
Oracle Cloud Infrastructure (OCI) GoldenGate is a managed service providing a real-time data mesh platform, which uses replication to keep data highly available, and enabling real-time analysis.
Sqoop comes preinstalled on the major Hadoop vendor distributions as the recommended product to import data from relational databases. The ability to extend it with additional JDBC drivers makes it very flexible for the environment it is installed within.
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.
Sqoop is great for sending data between a JDBC compliant database and a Hadoop environment. Sqoop is built for those who need a few simple CLI options to import a selection of database tables into Hadoop, do large dataset analysis that could not commonly be done with that database system due to resource constraints, then export the results back into that database (or another). Sqoop falls short when there needs to be some extra, customized processing between database extract, and Hadoop loading, in which case Apache Spark's JDBC utilities might be preferred
I think it's a great product. We apply Oracle GoldenGate to several use cases in our organization. 1. Business Continuity Planning, 2. Query Offloading through data replication to a reporting instance of our data, 3. looking into data transformations to help support various queries for different teams within the business.
EMR does well in managing the cost as it uses the task node cores to process the data and these instances are cheaper when the data is stored on s3. It is really cost efficient. No need to maintain any libraries to connect to AWS resources.
EMR is highly available, secure and easy to launch. No much hassle in launching the cluster (Simple and easy).
EMR manages the big data frameworks which the developer need not worry (no need to maintain the memory and framework settings) about the framework settings. It's all setup on launch time. The bootstrapping feature is great.
It would have been better if packages like HBase and Flume were available with Amazon EMR. This would make the product even more helpful in some cases.
Products like Cloudera provide the options to move the whole deployment into a dedicated server and use it at our discretion. This would have been a good option if available with EMR.
If EMR gave the option to be used with any choice of cloud provider, it would have helped instead of having to move the data from another cloud service to S3.
Sqoop2 development seems to have stalled. I have set it up outside of a Cloudera CDH installation, and I actually prefer it's "Sqoop Server" model better than just the CLI client version that is Sqoop1. This works especially well in a microservices environment, where there would be only one place to maintain the JDBC drivers to use for Sqoop.
Documentation is quite good and the product is regularly updated, so new features regularly come out. The setup is straightforward enough, especially once you have already established the overall platform infrastructure and the aws-cli APIs are easy enough to use. It would be nice to have some out-of-the-box integrations for checking logs and the Spark UI, rather than relying on know-how and digging through multiple levels to find the informations
Once set up, it's very easy to use and keep running, it's getting to that point that can make it cumbersome to some. Also, depending on the data that you want to replicate, the configuration files can become quite cumbersome to maintain. Learning curve can be high for some who are not as experienced with databases and transactions.
I give the overall support for Amazon EMR this rating because while the support technicians are very knowledgeable and always able to help, it sometimes takes a very long time to get in contact with one of the support technicians. So overall the support is pretty good for Amazon EMR.
Oracle Support for Oracle GoldenGate has been quite responsive and quite helpful in the few situations where we've needed it. Furthermore, the documentation on Oracle GoldenGate is so good that we often do not need to contact support with issues as the fix is already documented and able to be run by us without needing to open a ticket.
We've had Oracle consultants come as well for training days to talk about new features, parts of Oracle GoldenGate we may not be using and things of that nature. The consultants they send are great as they're very knowledgeable about all things Oracle GoldenGate and great resources for any questions or concerns you may have with the product.
We used Oracle University for our Oracle Golden Gate Training and it was top notch. We were able to turn our whole DBA team to Oracle GoldenGate newbies to Oracle GoldenGate troubleshooting experts in a matter of a few days, while this obviously did not come cheap, the company felt that it was worth the investment.
If Oracle GoldenGate is new to your organization, expose as many DBAs as possible to it. Having your whole team fluent in it will overcome early operational hurdles and allow it to more quickly become an accepted and supported part of your supported platform for your team that will enable the business to use it to its fullest.
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.
Sqoop comes preinstalled on the major Hadoop vendor distributions as the recommended product to import data from relational databases. The ability to extend it with additional JDBC drivers makes it very flexible for the environment it is installed within.
Spark also has a useful JDBC reader, and can manipulate data in more ways than Sqoop, and also upload to many other systems than just Hadoop.
Kafka Connect JDBC is more for streaming database updates using tools such as Oracle GoldenGate or Debezium.
Streamsets and Apache NiFi both provide a more "flow based programming" approach to graphically laying out connectors between various systems, including JDBC and Hadoop.
We use Oracle Data Guard as a backup tool, but not for data replication. Data Guard is not suited for real-time data replication in our non-normalized reporting database nor for the database we are using for our upgrade project, as Data Guard is not able to transform data and is not able to synchronize data into different schemas, which is necessary for our project. Additionally, our project database is on Oracle 12g not 11i: I am not 100% sure Data Guard is able to replicate from 11i to 12g
Have never had any issues with scaling Oracle GoldenGate itself, however Oracle GoldenGate Monitor does have scaling issues, but with Oracle GoldenGate now able to be monitored by Oracle Enterprise Manager, this is no longer an issue, in my opinion.
It was obviously cheaper and convenient to use as most of our data processing and pipelines are on AWS. It was fast and readily available with a click and that saved a ton of time rather than having to figure out the down time of the cluster if its on premises.
It saved time on processing chunks of big data which had to be processed in short period with minimal costs. EMR solved this as the cluster setup time and processing was simple, easy, cheap and fast.
It had a negative impact as it was very difficult in submitting the test jobs as it lags a UI to submit spark code snippets.
When combined with Cloudera's HUE, it can enable non-technical users to easily import relational data into Hadoop.
Being able to manipulate large datasets in Hadoop, and them load them into a type of "materialized view" in an external database system has yielded great insights into the Hadoop datalake without continuously running large batch jobs.
Sqoop isn't very user-friendly for those uncomfortable with a CLI.
In earlier versions, DDL support was limited as well as the need of primary key constraints in the source tables. This made me create partitions, sub-partitions, truncatations and perform other operations upon they are performed in source systems and I need to discuss with source system administrators and need to convince them to let them create primary keys for replicated tables.
But both issues are solved now.
Installation is straightforward, easy.
Deployed everything within Oracle Data Integrator.
Developing 1000 of ODI interfaces for loading into Operational Data Store took not more than 100 man/days. But, adding them to Golden Gate is taking not more than 5 man/days.
Management Pack and VeriData are additional packs for your management and data verification needs.
