📖 Scenario: You work for a company that stores large amounts of user activity data in Hadoop. Efficient data retrieval depends on how you design the row keys in your tables.Good row key design helps speed up queries and avoid data hotspots.
🎯 Goal: Build a simple example to understand how to create row keys using different strategies and see their effect on data organization.
📋 What You'll Learn
Create a dictionary called user_activities with user IDs as keys and lists of activity timestamps as values
Create a configuration variable called use_salted_key to decide if row keys should be salted
Write code to generate row keys for each user activity using either plain or salted keys based on use_salted_key
Print the list of generated row keys
💡 Why This Matters
🌍 Real World
Row key design is critical in Hadoop to ensure fast data access and balanced storage across servers.
💼 Career
Understanding row key strategies helps data engineers optimize big data storage and query performance.
Progress0 / 4 steps
1
Create the user activity data
Create a dictionary called user_activities with these exact entries: 'user1': ['2024-06-01T10:00:00', '2024-06-01T11:00:00'], 'user2': ['2024-06-01T10:30:00'], and 'user3': ['2024-06-01T09:45:00', '2024-06-01T12:00:00'].
Hadoop
Hint
Use curly braces to create a dictionary. Keys are user IDs as strings, values are lists of timestamp strings.
2
Add a configuration variable for salted keys
Create a boolean variable called use_salted_key and set it to True.
Hadoop
Hint
Just create a variable named use_salted_key and assign it the value True.
3
Generate row keys using the chosen strategy
Write code to create a list called row_keys. For each user and each timestamp in user_activities, generate a row key. If use_salted_key is True, prefix the user ID with a salt number (0 or 1) alternating for each activity. If use_salted_key is False, use the user ID directly. The row key format is salt_userID_timestamp or userID_timestamp. Use a for loop with variables user and timestamps to iterate over user_activities.items().
Hadoop
Hint
Use nested loops: outer for user, timestamps, inner for i, timestamp with enumerate. Use i % 2 for salt. Use f-strings to build keys.
4
Print the generated row keys
Write a print statement to display the row_keys list.
Hadoop
Hint
Use print(row_keys) to show the list of keys.
Practice
(1/5)
1. What is the main purpose of designing a good row key in Hadoop tables?
easy
A. To speed up data retrieval by organizing data efficiently
B. To increase the size of the data stored
C. To make data encryption easier
D. To reduce the number of columns in the table
Solution
Step 1: Understand the role of row keys
Row keys determine how data is stored and accessed in Hadoop tables, affecting retrieval speed.
Step 2: Identify the main goal of row key design
The goal is to organize data so that searches and reads are fast and efficient.
Final Answer:
To speed up data retrieval by organizing data efficiently -> Option A
Quick Check:
Row key design = speed up retrieval [OK]
Hint: Good row keys help find data faster [OK]
Common Mistakes:
Thinking row keys reduce data size
Confusing row keys with encryption keys
Assuming row keys reduce columns
2. Which of the following is a correct way to create a composite row key in Hadoop?
easy
A. row_key = user_id + '_' + timestamp
B. row_key = user_id * timestamp
C. row_key = timestamp - user_id
D. row_key = user_id / timestamp
Solution
Step 1: Understand composite row keys
Composite keys combine meaningful parts as strings to create unique keys.
Step 2: Check the syntax for combining parts
Concatenating with an underscore is a common and correct way to combine parts as strings.
Final Answer:
row_key = user_id + '_' + timestamp -> Option A
Quick Check:
Composite key = string concat with separator [OK]
Hint: Use string concat with separator for composite keys [OK]
Common Mistakes:
Using arithmetic operations instead of string concat
Not adding a separator between parts
Mixing data types without conversion
3. Given the following Python code to create row keys, what will be the output list?
user_ids = ['u1', 'u2']
timestamps = [100, 200]
row_keys = [f'{uid}_{ts}' for uid in user_ids for ts in timestamps]
print(row_keys)
medium
A. ['u1_100', 'u2_200', 'u1_200', 'u2_100']
B. ['u1_100', 'u2_100', 'u1_200', 'u2_200']
C. ['u2_100', 'u2_200', 'u1_100', 'u1_200']
D. ['u1_100', 'u1_200', 'u2_100', 'u2_200']
Solution
Step 1: Understand the nested loop order in list comprehension
The outer loop is over user_ids, inner loop over timestamps, so for each user_id, all timestamps are combined.
Step 2: Generate the list step-by-step
For 'u1': 'u1_100', 'u1_200'; for 'u2': 'u2_100', 'u2_200'.
Final Answer:
['u1_100', 'u1_200', 'u2_100', 'u2_200'] -> Option D
B. TypeError because user_id is string and timestamp is int
C. NameError because function is not defined
D. No error, code runs fine
Solution
Step 1: Analyze the function parameters and operation
user_id is a string, timestamp is an integer; adding them directly causes a type error.
Step 2: Understand Python type rules for + operator
Python cannot add string and int directly without conversion.
Final Answer:
TypeError because user_id is string and timestamp is int -> Option B
Quick Check:
String + int without conversion = TypeError [OK]
Hint: Cannot add string and int directly in Python [OK]
Common Mistakes:
Ignoring data types in addition
Assuming implicit conversion
Thinking syntax or name error
5. You want to design a row key for a large Hadoop table storing user activity logs. The goal is to avoid hot-spotting and allow fast range scans by time. Which strategy is best?
hard
A. Use only user ID as the row key
B. Use timestamp as the row key without modification
C. Use a reversed timestamp prefix followed by user ID, like row_key = reversed_timestamp + '_' + user_id
D. Use a random UUID as the row key
Solution
Step 1: Understand hot-spotting and range scan needs
Hot-spotting happens when many writes go to the same key range; reversed timestamp spreads writes.
Step 2: Evaluate each option for balancing and scan speed
Reversed timestamp prefix balances data and allows scanning by time; user ID alone or random UUIDs do not support range scans well.
Final Answer:
Use a reversed timestamp prefix followed by user ID, like row_key = reversed_timestamp + '_' + user_id -> Option C
Quick Check:
Reverse timestamp + user ID = balanced, fast scans [OK]
Hint: Reverse timestamp to avoid hot-spotting [OK]
Common Mistakes:
Using only user ID causes hot-spotting
Using raw timestamp causes write concentration
Random UUIDs prevent range scans
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.