Partitioning for query performance in Hadoop - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is partitioning in the context of Hadoop data storage?

Partitioning means dividing a large dataset into smaller, manageable parts based on a column's values. This helps Hadoop process queries faster by scanning only relevant parts.

beginner

How does partitioning improve query performance in Hadoop?

Partitioning reduces the amount of data scanned during a query by filtering partitions based on query conditions. This means less data to read and faster results.

beginner

What is a common column type used for partitioning in Hadoop tables?

Columns with discrete values like dates, regions, or categories are commonly used for partitioning because they split data into meaningful groups.

intermediate

What happens if you over-partition your data in Hadoop?

Over-partitioning creates many small files, which can slow down query performance due to overhead in managing many partitions and files.

intermediate

Explain the difference between partitioning and bucketing in Hadoop.

Partitioning divides data into folders based on column values, while bucketing splits data into a fixed number of files within partitions for better sampling and joins.

What is the main benefit of partitioning data in Hadoop?

A Encrypting data for security

B Compressing data to save space

C Backing up data automatically

D Faster query by scanning only relevant partitions

Partitioning helps queries run faster by scanning only the partitions that match the query filter.

Which type of column is best suited for partitioning?

A Continuous numeric values like temperature

B Unique IDs like user IDs

C Categorical values like dates or regions

D Text descriptions

Categorical columns with limited distinct values are best for partitioning to create meaningful data groups.

What is a downside of having too many partitions?

A Queries become slower due to overhead

B Data gets deleted automatically

C Partitions merge into one big file

D Data becomes unsearchable

Too many small partitions cause overhead in managing files, slowing down queries.

Partitioning in Hadoop physically stores data in:

A Random locations

B Separate folders based on partition column values

C Encrypted blocks

D Single large file

Partitioning stores data in separate folders named after partition column values.

Which technique complements partitioning for better query performance?

A Bucketing

B Indexing

C Compression

D Replication

Bucketing splits data inside partitions into fixed files, improving joins and sampling.

Describe how partitioning helps improve query performance in Hadoop.

Think about how filtering works on partitioned data.

What are the risks of over-partitioning data and how can it affect Hadoop queries?

Too much splitting can cause problems too.

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