MapReduce Table Join Pre-Partitioning

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In the MapReduce model, joining large tables such as transaction records with customer records is resource-intensive and requires significant data loading and partitioning, leading to inefficiencies in data processing.

Innovation Solution

Pre-organizing tables by hash partitioning based on a common key, reducing the need for further partitioning during the MapReduce procedure, allowing for faster data processing and reduced resource usage by loading only necessary data into memory for join operations.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If tables are joined in MapReduce without pre-partitioning, then the join operation can be performed, but data loading requirements increase and resource usage increases

Engineering Contradiction:
Improvejoin operation speedVSAvoiddata loading volume
Core Design Contradiction:
ProductivityVSQuantity of substance

Solution Approach 1:

The patent applies preliminary action by pre-partitioning tables into shards before the MapReduce join operation. The data is partitioned and stored in a share-nothing parallel database system beforehand, so that during the join operation, only the necessary partitions need to be loaded into memory, rather than loading entire tables. This pre-organization enables faster joins with reduced data loading requirements.

Inventive Principle:
Principle #10Preliminary action

2Productivity

If tables are joined in MapReduce without pre-partitioning, then the join operation can be performed, but resource usage increases

Engineering Contradiction:
Improvejoin operation speedVSAvoidresource usage
Core Design Contradiction:
ProductivityVSUse of energy by moving object

Solution Approach 1:

The patent applies preliminary action by pre-partitioning tables into shards before the MapReduce join operation. The data is partitioned and stored in a share-nothing parallel database system beforehand, so that during the join operation, only the necessary partitions need to be loaded into memory, rather than loading entire tables. This pre-organization enables faster joins with reduced data loading requirements.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent applies segmentation by dividing large tables into smaller shards based on partition keys. This segmentation allows the join operation to process data in manageable chunks across multiple nodes, reducing the memory footprint and computational resources required for each individual join operation while maintaining overall processing throughput.

Inventive Principle:
Principle #1Segmentation

3Productivity

If tables are joined in MapReduce, then data processing can be performed, but additional partitioning is required during the procedure

Engineering Contradiction:
Improvedata processing speedVSAvoidpartitioning complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent applies preliminary action by pre-partitioning tables into shards before the MapReduce join operation. The data is partitioned and stored in a share-nothing parallel database system beforehand, so that during the join operation, only the necessary partitions need to be loaded into memory, rather than loading entire tables. This pre-organization enables faster joins with reduced data loading requirements.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentEP2702510B1Joining tables in a mapreduce procedure
Publication Date: 2019.09.18 GOOGLE LLC
  • EP2702510B1 patent drawingFigure 1
  • EP2702510B1 patent drawingFigure 2
  • EP2702510B1 patent drawingFigure 3

AI summary

Systems and techniques by which tables can be joined in a mapreduce procedure. In some implementations, when a large table of business data (e.g., having one billion transaction records or more) is to be joined with a large table of customer data (e.g., having hundreds of millions of customer records), then these two tables can be organized before the mapreduce procedure to speed up the table join. For example, the business data and the customer data can both be hash partitioned, based on the same key, into shards of business data and shards of customer data, respectively. The number of shards in these two groups has an integer relationship with each other: for example such that there are two business data shards for every customer data shard, or vice versa.