- July 8, 2020
- Posted by: ninjaadmin
- Category: Big Data, Data Analytics
As mentioned in the first post in our series, Seagate Technology asked Mactores Cognition to evaluate and deliver a data platform to process petabytes of data with consistent performance, lower query processing time, lower total cost of ownership (TCO), and the scalability required to support about 2,000 daily users.
Mactores, an AWS Partner Network (APN) Advanced Consulting Partner with the Amazon EMR Service Delivery designation, explored several Amazon EMR capabilities for its Seagate solution. Mactores also holds the AWS Data & Analytics Competency.
We previously described how Seagate used Presto on Amazon EMR to handle queries on 10TB of memory or less. In this post, we describe how to use Apache Hive on Apache Spark for queries larger than 10TB, combined with the use of transient Amazon EMR clusters leveraging Amazon EC2 Spot Instances.
Seagate Technology is a United States-based data storage company with worldwide manufacturing facilities that generate huge amounts of manufacturing and testing data.
With petabytes of data accumulated over 20 years, and more being generated each day, it was imperative for Seagate to have systems in place to ensure the cost of collecting, storing, and processing data did not exceed their return on investment (ROI).
Amazon EMR Capabilities
When you combine Amazon EMR with the dynamic scalability of Amazon Elastic Compute Cloud (Amazon EC2) and scalable storage of Amazon Simple Storage Service (Amazon S3), you get the elasticity to run petabyte-scale analysis for a fraction of the cost of traditional on-premises clusters.
Apache Spark and Hive are natively supported in Amazon EMR, so you can create managed Apache Spark or Apache Hive clusters from the AWS Management Console, AWS Command Line Interface (CLI), or the Amazon EMR API.
Migration Options We Tested
We deployed Mactores’s own comprehensive big data assessment process called HEXA Audit, which performed in-depth analysis of Seagate’s big data requirements.
To reduce the time and cost of the query execution, we recommended transforming Seagate’s current data platform to the Amazon EMR platform. Seagate chose to move forward with two query engines: Apache Hive on Apache Spark and Presto on Amazon EMR.
To meet the query and scale performance requirements, Seagate would use Presto on Amazon EMR for queries less than 10TB of memory. For larger queries, it would use Apache Hive on Apache Spark with the use of transient Amazon EMR clusters leveraging Amazon EC2 Spot Instances to further reduce costs.
Mactores performed a quick proof of concept (PoC) with Seagate data. These are the results we obtained for Amazon EMR with Apache Tools.
Migrating to Amazon EMR with S3 for storage allowed Seagate to keep its compute and storage resources separate, reducing TCO significantly. Queries that used to execute in 7-8 hours on Seagate’s legacy platform now took less than 20 minutes.
Here are some details of the migration:
- Apache MapReduce was the slowest query execution engine due to high disk IO required to process customers’ queries.
- Apache Tez was significantly faster than Apache MapReduce while keeping disk IO the same.
- Apache Spark was slightly faster than Apache Tez with no IO blocking, and was best suited for the solution.
While Spark was fast enough to increase the query processing, it could not match the query execution time Seagate was expecting. Spark, on the other hand, could execute very large queries and jobs that required 10TB of memory or more.
How to Configure Spark as the Execution Engine for Hive
Figure 1 shows the Spark on Hive setup.
Figure 1 – Overall architectural diagram.
To run Spark as an execution engine in Amazon EMR, we will assume your Amazon EMR cluster is up and running with the services shown in Figure 2.
Figure 2 – Amazon EMR services selected.
We will use Amazon EMR release 5.28, along with the following services:
- Hadoop 2.8.5
- Hive 2.3.4
- Spark 2.4.0
- Tez 0.9.1
- Livy 0.5.0
Figure 3 shows the details of the Amazon EMR cluster, which are:
- Task Node on Demand: – 3 Nodes
- Core Node on Demand: – 3 Nodes
- Task Node Spot Instance with Auto Scaling rule (Apache Hadoop YARN memory available percentage): – Min 3 Max 30 Nodes
- Master Node: – 1
Figure 3 – Amazon EMR cluster details instance group.
To run Hive on Spark, follow these steps.
Step 1: Specify Spark as the execution engine for Hive
Add the following configurations in
/usr/lib/hive/conf/hive-site.xml, but replace
ip-xx-xx-xx-xx.dns.awsuw2.mactores.com with your master IP.
For example, if your master is 10.219.3.112, then replace it with ip-10–219–3–.
Step 2: Update the JAR paths in yarn-site.xml
Ensure the following properties shown are present in
yarn-site.xml. If the properties are missing, please add them.
The JAR paths listed below are required when configuring Spark as the execution engine for Hive. We recommend using absolute paths instead of environmental variables, as environment variables do not work. Also, ensure these paths refer to the Hadoop installation directories.
ip-xx-xx-xx-xx.dns.awsuw2.mactores.com with your master IP. If your master is 10.x.x.x, then replace with ip-10–x–x–x.dns.awsuw2.mactores.com and replace the master-IP address with 10.x.x.x.
Link Scala and Spark jars in the Hive lib folder using these commands:
Step 3: Verify the symbolic links
Verify the symbolic links by running the
ls -lsrta /usr/lib/hive/lib
Step 4: Remove the old version of Hive JAR files from the Spark JARs folder
Implement this step according to your version of Hive JAR files in the Spark JARs folder. You can determine the version by looking at the content of $SPARK_HOME/jars folder in this command:
For example, if the JARs are of version 1.2.1, remove them using the
Step 5: Copy the new version of Hive JARs to the Spark JARs folder
These JARs are necessary to run Hive with the new Spark. Use the
cp -r /usr/lib/hive/lib/*hive*.jar /usr/lib/spark/jars
Step 6: Copy Spark JARs on the HDFS park-jars folder
Use these commands:
Step 7: Assign the YARN node label
In Amazon EMR, the core node by default has YARN node label ‘CORE’ as a non-exclusive partition. Since the core node is a non-exclusive partition, any other container can be launched in core node. This can lead to inconsistent performance and affect spark engine stability.
To prevent launching the Spark executor container on the core node, you should make it an exclusive partition.
For more information on node partitions:
- Exclusive: Containers will be allocated to nodes with an exact match node partition. For example, asking partition = “x” will be allocated to the node with partition = “x”, while asking DEFAULT partition will be allocated to DEFAULT partition nodes.
- Non-exclusive: If a partition is non-exclusive, it shares an idle resource to the container requesting DEFAULT partition.
Another approach is to assign the YARN node label to all of your task nodes as ‘TASK’ and use this configuration in the Spark submit command:
Step 8: Restart the following services
To restart the following services, use these commands:
Step 9: Verify YARN Web UI port 8080
The YARN Node label after the restarting of YARN services should look like this:
Figure 4 – YARN Node label.
The application queues of YARN should look like this:
Figure 5 – Application queries.
Step 10: Test Hive on Spark engine
Run count query in Hive on a large table and see how long it takes to complete. It will take some time for the job to start due to the query execution plan, which is being prepared by Hive.
The screen should look like this:
Figure 6 – Hive Shell with Spark as the execution engine.
In the following figure, it can be observed that the application type is “SPARK” and the application name is “Hive on Spark.” Hive engine is responsible to submit Spark jobs in cluster mode, which provides high scalability and stability.
Figure 7 – YARN Web UI after submitting the job in Hive shell.
The chart in Figure 8 is the output of the row count. The execution time of Hive on Spark is 2x less than Hive on Tez and 3x less than Hive on MapReduce.
Figure 8 – YARN Web UI after submitting the job in Hive shell.
Hive on Spark is faster than Hive on Tez, but there are also some drawbacks of Hive on Spark:
- We could not visualize a query execution plan on Spark Web UI.
- The query plan generated by Hive was taking too much time.
Moving to Hive on Spark enabled Seagate to continue processing petabytes of data at scale with significantly lower total cost of ownership. While Seagate achieved lower TCO, the internal users were also experiencing a 2x improvement in the execution time of queries returning 27 trillion rows, as compared to Tez.
Since Mactores deployed the solution with network load balancing, Seagate could switch clusters without impacting end users. Seagate saved an average of 60 percent of CPU time per query, and their end users could get query results in minutes rather than hours, improving the overall efficiency of both their Amazon EMR cluster and business operations.