Partitioning for query performance in Hadoop - Mini Project: Build & Apply

Partitioning for query performance

📖 Scenario: You work with a large sales dataset stored in Hadoop. Queries on this dataset are slow because the data is not organized efficiently. Partitioning the data by a key column can speed up queries by reading only relevant parts.

🎯 Goal: You will create a partitioned table in Hadoop, configure the partition column, load data into partitions, and query the data to see improved performance.

📋 What You'll Learn

Create a Hive table with partitioning on the year column

Set a variable partition_column to 'year'

Load data into the table partitions using the partition column

Query the table filtering by the partition column and display results

💡 Why This Matters

🌍 Real World

Partitioning large datasets in Hadoop helps reduce query time by scanning only relevant data parts, saving computing resources and speeding up reports.

💼 Career

Data engineers and analysts use partitioning to optimize big data queries in Hadoop ecosystems, improving performance and cost efficiency.

1

Create a partitioned Hive table

Write a Hive query to create a table called sales_data with columns id INT, product STRING, amount FLOAT, and partitioned by year INT. Use STORED AS TEXTFILE format.

Hadoop

# Write the Hive CREATE TABLE statement for sales_data with partition on year
# Your code here

Hint

Use CREATE TABLE with PARTITIONED BY clause to specify the partition column.

2

Set the partition column variable

Create a Hive variable called partition_column and set it to the string 'year'.

Hadoop

CREATE TABLE sales_data (
  id INT,
  product STRING,
  amount FLOAT
)
PARTITIONED BY (year INT)
STORED AS TEXTFILE;

-- Set the partition_column variable
-- Your code here

Hint

Use SET to define a Hive variable.

3

Load data into partitions

Write a Hive query to load data from /user/hive/sales_data_2023.txt into the sales_data table partition where year=2023. Use LOAD DATA INPATH with INTO TABLE and PARTITION clauses.

Hadoop

CREATE TABLE sales_data (
  id INT,
  product STRING,
  amount FLOAT
)
PARTITIONED BY (year INT)
STORED AS TEXTFILE;

SET partition_column=year;

-- Load data into partition year=2023
-- Your code here

Hint

Use LOAD DATA INPATH 'path' INTO TABLE table_name PARTITION (partition_column=value).

4

Query data filtering by partition

Write a Hive query to select all columns from sales_data where year=2023. Print the results.

Hadoop

CREATE TABLE sales_data (
  id INT,
  product STRING,
  amount FLOAT
)
PARTITIONED BY (year INT)
STORED AS TEXTFILE;

SET partition_column=year;

LOAD DATA INPATH '/user/hive/sales_data_2023.txt' INTO TABLE sales_data PARTITION (year=2023);

-- Query sales_data filtering by year=2023
-- Your code here

Hint

Use SELECT * FROM sales_data WHERE year=2023; to query only the partitioned data.

Practice

1. What is the main benefit of partitioning data in Hadoop for query performance?

easy

A. It reduces the amount of data scanned by queries.

B. It compresses the data to save storage space.

C. It automatically indexes all columns for faster search.

D. It duplicates data to improve fault tolerance.

Solution

1. Step 1: Understand partitioning purpose

   Partitioning divides data into parts based on column values to limit data scanned.

2. Step 2: Connect partitioning to query speed

   Queries read only relevant partitions, reducing data scanned and speeding up queries.

3. Final Answer:

   It reduces the amount of data scanned by queries. -> Option A

4. Quick Check:

   Partitioning = less data scanned [OK]

Hint: Partitioning limits data scanned, speeding queries [OK]

Common Mistakes:

• Confusing partitioning with compression
• Thinking partitioning creates indexes
• Assuming partitioning duplicates data

2. Which of the following is the correct syntax to create a partitioned table in Hive by the column year?

easy

A. CREATE TABLE sales (id INT, amount FLOAT) PARTITIONED BY (year INT);

B. CREATE TABLE sales PARTITIONED BY (year INT) (id INT, amount FLOAT);

C. CREATE TABLE sales (id INT, amount FLOAT, year INT) PARTITIONED;

D. CREATE TABLE sales (id INT, amount FLOAT) WITH PARTITION year INT;

Solution

1. Step 1: Recall Hive partition syntax

   Hive syntax places partition columns after main columns using PARTITIONED BY clause.

2. Step 2: Match syntax to options

   CREATE TABLE sales (id INT, amount FLOAT) PARTITIONED BY (year INT); correctly uses PARTITIONED BY (year INT) after main columns.

3. Final Answer:

   CREATE TABLE sales (id INT, amount FLOAT) PARTITIONED BY (year INT); -> Option A

4. Quick Check:

   Partitioned BY after columns = correct syntax [OK]

Hint: Partition columns go after main columns with PARTITIONED BY [OK]

Common Mistakes:

• Placing PARTITIONED BY before columns
• Adding partition column inside main columns
• Using incorrect keywords like WITH PARTITION

3. Given a Hive table partitioned by country, what will be the effect of this query?

SELECT * FROM sales WHERE country = 'US';

medium

A. The query scans all data ignoring partitions.

B. The query scans only the partition where country='US'.

C. The query fails because partition filters are not allowed.

D. The query scans partitions for all countries except 'US'.

Solution

1. Step 1: Understand partition pruning

   When filtering on a partition column, Hive reads only matching partitions.

2. Step 2: Apply to given query

   Filtering WHERE country='US' reads only the 'US' partition, skipping others.

3. Final Answer:

   The query scans only the partition where country='US'. -> Option B

4. Quick Check:

   Partition filter = scan matching partition only [OK]

Hint: Filter on partition column scans only matching partitions [OK]

Common Mistakes:

• Thinking query scans all partitions
• Believing partition filters cause errors
• Assuming partitions except filter are scanned

4. You created a Hive table partitioned by date. Your query filtering on date still scans all data. What is the likely cause?

medium

A. You forgot to add the partition column in the WHERE clause.

B. Partition columns cannot be used in WHERE clauses.

C. You did not load data into partitions properly.

D. Hive does not support partition pruning.

Solution

1. Step 1: Check partition pruning requirements

   Partition pruning works only if data is loaded into correct partitions.

2. Step 2: Identify cause of full scan

   If data is not loaded into partitions properly, Hive scans all data ignoring partitions.

3. Final Answer:

   You did not load data into partitions properly. -> Option C

4. Quick Check:

   Missing partition data = no pruning, full scan [OK]

Hint: Load data into partitions correctly to enable pruning [OK]

Common Mistakes:

• Assuming partition columns can't be filtered
• Believing Hive lacks partition pruning
• Forgetting to filter on partition column

5. You have a large sales dataset with columns region, product, and sale_date. You often query sales by region and sale_date. Which partitioning strategy will best improve query performance?

hard

A. Partition by product only.

B. Do not partition; use full table scans.

C. Partition by sale_date only.

D. Partition by region and sale_date together.

Solution

1. Step 1: Analyze query patterns

   Queries filter by both region and sale_date, so partitioning should match these columns.

2. Step 2: Choose partition columns

   Partitioning by both region and sale_date allows pruning on both filters, speeding queries.

3. Step 3: Evaluate other options

   Partitioning only by product or sale_date misses one filter; no partitioning causes full scans.

4. Final Answer:

   Partition by region and sale_date together. -> Option D

5. Quick Check:

   Partition on query filter columns = best performance [OK]

Hint: Partition on columns used in filters together [OK]

Common Mistakes:

• Partitioning on unused columns
• Partitioning on only one filter column
• Skipping partitioning for large data