Partitioning for query performance in Hadoop - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to create a partitioned table by the column 'year'.

Hadoop

CREATE TABLE sales_data (id INT, amount FLOAT) PARTITIONED BY ([1] STRING);

Drag options to blanks, or click blank then click option'

Amonth

Bregion

Cyear

Dcategory

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing a non-time column like 'region' or 'category' for partitioning.

Forgetting to specify the partition column in the table definition.

The partition column is 'year' to organize data by year for better query performance.

2fill in blank

medium

Complete the code to insert data into the partition for year 2023.

Hadoop

INSERT INTO sales_data PARTITION (year=[1]) SELECT id, amount FROM raw_sales WHERE year = 2023;

Drag options to blanks, or click blank then click option'

A'2023'

B2023

C'2022'

Dyear

Attempts:

3 left

💡 Hint

Common Mistakes

Using the number 2023 without quotes.

Using a column name instead of a literal value.

The partition value must be a string literal, so '2023' is correct.

3fill in blank

hard

Fix the error in the query to select data only from the 2022 partition.

Hadoop

SELECT * FROM sales_data WHERE year [1] '2022';

Drag options to blanks, or click blank then click option'

A==

B=

CLIKE

DIN

Attempts:

3 left

💡 Hint

Common Mistakes

Using '==' instead of '=' causes syntax errors.

Using 'LIKE' without wildcards is incorrect here.

In SQL, the equality operator is a single '=' sign, not '=='.

4fill in blank

hard

Fill both blanks to create a dictionary comprehension that maps each word to its length if the length is greater than 3.

Hadoop

{word: [1] for word in words if [2]

Drag options to blanks, or click blank then click option'

Alen(word)

Blen(word) > 3

Cword

Dword > 3

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'word' instead of 'len(word)' for the value.

Using 'word > 3' which compares string to number incorrectly.

The dictionary maps words to their lengths (len(word)) and filters words with length greater than 3 (len(word) > 3).

5fill in blank

hard

Fill all three blanks to create a dictionary comprehension that maps uppercase keys to values only if the value is greater than 0.

Hadoop

result = [1]: [2] for [3], [2] in data.items() if [2] > 0}

Drag options to blanks, or click blank then click option'

Ak.upper()

Bv

Ck

Dvalue

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'value' instead of 'v' as the loop variable.

Not converting keys to uppercase.

Keys are converted to uppercase with k.upper(), values are v, and the loop variables are k and v.

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