HIVE SQL - JOIN 이해(공식문서)

Hive Joins

• Hive Joins
  • Join Syntax
  • Examples
  • MapJoin Restrictions
  • Join Optimization
• Predicate Pushdown in Outer Joins

Join Syntax

Hive에서 제공하는 Join구문

join_table:

    table_reference [INNER] JOIN table_factor [join_condition]

  | table_reference {LEFT|RIGHT|FULL} [OUTER] JOIN table_reference join_condition

  | table_reference LEFT SEMI JOIN table_reference join_condition

  | table_reference CROSS JOIN table_reference [join_condition] (as of Hive 0.10)



table_reference:

    table_factor

  | join_table



table_factor:

    tbl_name [alias]

  | table_subquery alias

  | ( table_references )



join_condition:

    ON expression

 

Examples

조인쿼리 작성시 고려해야할 중요사항

• 복잡한 조인표현식이 허용된다.

SELECT a.* FROM a JOIN b ON (a.id = b.id)

SELECT a.* FROM a LEFT OUTER JOIN b ON (a.id <> b.id)

SELECT a.* FROM a JOIN b ON (a.id = b.id AND a.department = b.department)

 

• 2 개 이상의 테이블을 하나의 쿼리에 조인 할 수 있습니다.

SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key2)

 

• Hive는 모든 테이블에 대해 동일한 열이 조인 절에 사용되는 경우 여러 테이블에 대한 조인을 단일 매핑 / 축소 작업으로 변환합니다.

SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key1)

b에 대한 key1 열만 결합에 포함되므로 단일 맵 / 축소 작업으로 변환됩니다.

SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key2)

 반면에 b의 key1 열이 첫 번째 조인 조건에 사용되고 b의 key2 열이 두 번째 조건에 사용되기 때문에 두 개의 매핑 / 축소 작업으로 변환됩니다. 첫 번째 map / reduce 작업은 a와 b를 결합하고 결과는 두 번째 map / reduce 작업에서 c와 결합됩니다.

 

• JOIN의 모든 맵 / 리듀스 단계에서 시퀀스의 마지막 테이블은 다른 테이블이 버퍼링되는 리듀서를 통해 스트리밍됩니다. 따라서 가장 큰 테이블이 시퀀스에서 마지막에 나타나도록 테이블을 구성하여 조인 키의 특정 값에 대한 행을 버퍼링하기 위해 리듀서에 필요한 메모리를 줄이는데 도움이됩니다.

SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key1)

세 테이블 모두 단일 맵 / 리듀스 작업으로 조인되고 테이블 a 및 b에 대한 키의 특정 값에 대한 값은 리듀서의 메모리에 버퍼링됩니다. 그런 다음 c에서 검색된 각 행에 대해 버퍼링 된 행으로 JOIN이 계산됩니다.

SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key2)

JOIN을 계산하는데 관련된 두 가지 맵 / 리듀스 작업이 있습니다. 이 중 첫 번째는 a를 b와 결합하고 a의 값을 버퍼링하면서 리듀서에서 b의 값을 스트리밍합니다. 이러한 작업 중 두 번째 작업은 리듀서를 통해 c 값을 스트리밍하는 동안 첫 번째 조인의 결과를 버퍼링합니다.

 

• JOIN의 모든 맵 / 리듀스 단계에서 스트리밍 할 테이블은 HINT를 통해 지정할 수 있습니다.

SELECT /*+ STREAMTABLE(a) */ a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key1)

세 테이블 모두 단일 맵 / 리 스 작업으로 조인되고 테이블 b 및 c에 대한 키의 특정 값에 대한 값은 리듀서의 메모리에 버퍼링됩니다. 그런 다음 a에서 검색된 각 행에 대해 버퍼링 된 행으로 JOIN이 계산됩니다. STREAMTABLE HINT를 생략하면 Hive는 조인에서 가장 오른쪽 테이블을 스트리밍합니다.

 

• LEFT, RIGHT 및 FULL OUTER 조인은 일치 항목이없는 ON 절에 대한 더 많은 제어를 제공하기 위해 존재합니다. 예를 들어 쿼리는 다음과 같습니다.

SELECT a.val, b.val FROM a LEFT OUTER JOIN b ON (a.key=b.key)

a의 모든 행에 대해 행을 반환합니다. 이 출력 행은 a.key와 같은 b.key가있을 때 a.val, b.val이되고, 해당 b.key가 없으면 출력 행은 a.val, NULL이됩니다. 해당 a. 키가없는 b의 행은 삭제됩니다. 작동 방식을 이해하려면 "FROM a LEFT OUTER JOIN b"구문을 한 줄에 작성해야합니다. a는이 쿼리에서 b의 왼쪽에 있으므로 a의 모든 행이 유지됩니다. a RIGHT OUTER JOIN은 b의 모든 행을 유지하고 FULL OUTER JOIN은 a의 모든 행과 b의 모든 행을 유지합니다. OUTER JOIN 의미 체계는 표준 SQL 사양을 준수해야합니다.

 

• JOIN은 WHERE CLAUSES 전에 발생합니다. 따라서 JOIN의 OUTPUT을 제한하려면 요구 사항이 WHERE 절에 있어야하고 그렇지 않으면 JOIN 절에 있어야합니다. 이 문제에 대한 큰 혼란은 분할 된 테이블입니다.

SELECT a.val, b.val FROM a LEFT OUTER JOIN b ON (a.key=b.key)
WHERE a.ds='2009-07-07' AND b.ds='2009-07-07'

a on b에 가입하여 a.val 및 b.val 목록을 생성합니다. 그러나 WHERE 절은 조인의 출력에있는 a 및 b의 다른 열을 참조한 다음 필터링 할 수도 있습니다. 그러나 JOIN의 행이 a에 대한 키를 발견하고 b에 대한 키가 없을 때마다 ds 열을 포함하여 b의 모든 열은 NULL이 됩니다 . 즉, 유효한 b.key가없는 모든 조인 출력 행을 필터링하므로 LEFT OUTER 요구 사항을 능가합니다. 즉, WHERE 절에서 b의 열을 참조하는 경우 조인의 LEFT OUTER 부분은 관련이 없습니다. 대신 OUTER JOINing시 다음 구문을 사용하십시오.

SELECT a.val, b.val FROM a LEFT OUTER JOIN b
ON (a.key=b.key AND b.ds='2009-07-07' AND a.ds='2009-07-07')

..결과는 JOIN의 출력이 미리 필터링되고 유효한 a.key가 있지만 일치하는 b.key가없는 행에 대해 사후 필터링 문제가 발생하지 않습니다. 동일한 논리가 RIGHT 및 FULL 조인에 적용됩니다.

JOIN은 교환연산이 아닙니다! 조인은 LEFT 또는 RIGHT JOIN여부에 관계없이 왼쪽테이블이 연산의 주가 됩니다.

SELECT a.val1, a.val2, b.val, c.val
FROM a
JOIN b ON (a.key = b.key)
LEFT OUTER JOIN c ON (a.key = c.key)

... 먼저 a on b를 JOIN하여 다른 테이블에 해당 키가 없는 a, b의 모든 컬럼을 버립니다. 그런 다음 축소된 테이블이 c에서 조인됩니다. a와 c 모두에 존재하지만 b가 아닌 키가 있는 경우 직관적이지 않은 결과를 제공합니다. b에 없기 때문에 전체 행 (a.val1, a.val2 및 a.key 포함)이 "a JOIN b"단계에서 삭제됩니다. 결과에는 a.key가 없으므로 c와 함께 LEFT OUTER JOIN 된 경우 a.key와 일치하는 c.key가 없기 때문에 c.val이 입력되지 않습니다(a의 해당 행이 제거 되었기 때문 ) 마찬가지로, 이것이 LEFT 대신 RIGHT OUTER JOIN이라면, NULL, NULL, NULL, c.val과 같은 더 이상한 결과로 끝날 것입니다. a.key = c.key를 조인 키로 지정했지만 첫 번째 JOIN과 일치하지 않는 a의 모든 행을 삭제했기 때문입니다.
보다 직관적인 효과를 얻으려면 FROM c LEFT OUTER JOIN a ON (c.key = a.key) 대신 LEFT OUTER JOIN b ON (c.key = b.key)을 수행해야합니다.

 

• LEFT SEMI JOIN은 상관 관계가없는 IN / EXISTS 서브쿼리 의미를 효율적인 방식으로 구현합니다. Hive 0.13부터 IN / NOT IN / EXISTS / NOT EXISTS 연산자는 서브쿼리를 사용하여 지원 되므로 이러한 JOIN의 대부분은 더 이상 수동으로 수행 할 필요가 없습니다. LEFT SEMI JOIN 사용의 제한 사항은 오른쪽 테이블이 조인 조건 (ON 절)에서만 참조되어야하고 WHERE 또는 SELECT 절 등에서는 참조되지 않아야한다는 것입니다.

SELECT a.key, a.value
FROM a
WHERE a.key in
 (SELECT b.key
  FROM B);

SELECT a.key, a.val
FROM a LEFT SEMI JOIN b ON (a.key = b.key)

• LECT-clauses etc.

 

• JOIN되는 테이블의 크기가 작다면 맵으로만으로도 JOIN작업을 수행할 수 있다

SELECT /*+ MAPJOIN(b) */ a.key, a.value
FROM a JOIN b ON a.key = b.key

REDUCER는 필요하지 않습니다. 모든 MAPPER는 A B를 완벽하게 읽습니다. 하지만 FULL / RIGHT OUTER JOIN b 를 수행할수는 없습니다.

 

• JOIN되는 테이블이 JOIN열 에서 버킷화되고 한 테이블의 버킷 수가 다른 테이블의 버킷 수의 배수 인 경우 버킷을 서로 JOIN 할 수 있습니다. 테이블 A에 4 개의 버킷이 있고 테이블 B에 4 개의 버킷이있는 경우

SELECT /*+ MAPJOIN(b) */ a.key, a.value
FROM a JOIN b ON a.key = b.key

MAPPER에서만 수행 할 수 있습니다. A의 각 매퍼에 대해 B를 완전히 가져 오는 대신 필요한 버킷만 가져옵니다. 위 쿼리의 경우 A에 대한 매퍼 처리 버킷 1은 B의 버킷 1 만 가져옵니다. 이는 기본 동작이 아니며 다음 매개 변수에 의해 관리됩니다.

set hive.optimize.bucketmapjoin = true

 

• JOIN중인 테이블이 JOIN열에서 정렬되고 버킷화되고 버킷 수가 동일한 경우 merge-sort JOIN을 수행 할 수 있습니다. 해당 버킷은 MAPPER에서 서로 결합됩니다(A와 B에 모두 4 개의 버킷이있는 경우)

SELECT /*+ MAPJOIN(b) */ a.key, a.value
FROM A a JOIN B b ON a.key = b.key

MAPPER에서만 수행 할 수 있습니다. A의 버킷 MAPPER는 B의 해당 버킷을 순회합니다. 이는 기본 동작이 아니며 다음 매개 변수를 설정해야합니다.

set hive.input.format=org.apache.hadoop.hive.ql.io.BucketizedHiveInputFormat;
set hive.optimize.bucketmapjoin = true;
set hive.optimize.bucketmapjoin.sortedmerge = true;

 

MapJoin 제한

• JOIN되는 테이블 중 하나를 제외하고 모두 작은 경우 JOIN은 MAP 전용 작업으로 수행 할 수 있습니다.

SELECT /*+ MAPJOIN(b) */ a.key, a.value
FROM a JOIN b ON a.key = b.key

REDUCER가 필요하지 않습니다. A의 모든 MAPPER는 B를 완전히 읽을수 있습니다

• 다음은지원되지 않습니다
  • Union Followed by a MapJoin
  • Lateral View Followed by a MapJoin
  • Reduce Sink (Group By/Join/Sort By/Cluster By/Distribute By) Followed by MapJoin
  • MapJoin Followed by Union
  • MapJoin Followed by Join
  • MapJoin Followed by MapJoin

• The configuration variable hive.auto.convert.join (if set to true) automatically converts the joins to mapjoins at runtime if possible, and it should be used instead of the mapjoin hint. The mapjoin hint should only be used for the following query.
  • If all the inputs are bucketed or sorted, and the join should be converted to a bucketized map-side join or bucketized sort-merge join.

• Consider the possibility of multiple mapjoins on different keys:

• 구성 변수 hive.auto.convert.join (true로 설정된 경우)은 가능한 경우 런타임에 조인을 mapJOIN으로 자동 변환하며 mapJOIN 힌트 대신 사용해야합니다. mapJOIN 힌트는 다음 쿼리에만 사용해야합니다.
  • 모든 입력이 버킷화 되거나 정렬 된 경우 JOIN은 버킷화 된 MAP 측 JOIN 또는 버킷화 된 merge-sort JOIN으로 변환되어야 합니다.

 

• 서로 다른 KEY에서 여러 mapjoin의 가능성을 고려하십시오.

select /*+MAPJOIN(smallTableTwo)*/ idOne, idTwo, value FROM
  ( select /*+MAPJOIN(smallTableOne)*/ idOne, idTwo, value FROM
    bigTable JOIN smallTableOne on (bigTable.idOne = smallTableOne.idOne)                                                  
  ) firstjoin                                                            
  JOIN                                                                 
  smallTableTwo ON (firstjoin.idTwo = smallTableTwo.idTwo) 

• 위의 쿼리는 지원되지 않습니다. mapJOIN 힌트가 없으면 위 쿼리는 2 개의 MAP 전용 작업으로 실행됩니다. 사용자가 입력이 메모리를 고려해 작다는 것을 미리 알고있는 경우 다음 구성 가능한 매개 변수를 사용하여 쿼리가 단일 맵 축소 작업에서 실행되도록 할 수 있습니다.

  • hive.auto.convert.join.noconditionaltask-Hive가 입력 파일 크기에 따라 공통 JOIN을 mapJOIN으로 변환하는 것에 대한 최적화를 활성화할지 여부입니다. 이 매개 변수가 켜져 있고 n-way JOIN에 대한 테이블 / 파티션 n-1의 크기 합계가 지정된 크기보다 작으면 JOIN이 직접 mapJOIN으로 변환됩니다 (조건부 작업 없음).
  • hive.auto.convert.join.noconditionaltask.size-hive.auto.convert.join.noconditionaltask가 꺼져있는 경우이 매개 변수는 적용되지 않습니다. 그러나 이 기능이 켜져 있고 n-way JOIN에 대한 테이블 / 파티션 n-1의 크기 합계가이 크기보다 작으면 JOIN이 직접 맵 JOIN으로 변환됩니다 (조건부 작업 없음). 기본값은 10MB입니다.

 

Join Optimization

• Join Optimization
  • Improvements to the Hive Optimizer
  • Star Join Optimization
    • Star Schema Example
    • Prior Support for MAPJOIN
      • Limitations of Prior Implementation
    • Enhancements for Star Joins
      • Optimize Chains of Map Joins
        • Current and Future Optimizations
      • Optimize Auto Join Conversion
        • • Current Optimization
        • Auto Conversion to SMB Map Join
          • SMB Join across Tables with Different Keys
      • Generate Hash Tables on the Task Side
        • Pros and Cons of Client-Side Hash Tables
        • Task-Side Generation of Hash Tables
          • Further Options for Optimization

For a general discussion of Hive joins including syntax, examples, and restrictions, see the Joins wiki doc.

Improvements to the Hive Optimizer

이 문서에서는 JOIN의 효율성을 높이고 사용자 힌트의 필요성을 줄이기위한 Hive의 쿼리 실행 계획 최적화에 대해 설명합니다.

Hive는 다양한 사용 사례를 자동으로 인식하고 최적화합니다. Hive 0.11은 다음과 같은 경우에 대한 최적화 프로그램을 개선합니다.

• Joins where one side fits in memory. In the new optimization:
  • that side is loaded into memory as a hash table
  • only the larger table needs to be scanned
  • fact tables have a smaller footprint in memory
• Star-schema joins
• Hints are no longer needed for many cases.
• Map joins are automatically picked up by the optimizer.

 

Star Join Optimization

의사 결정 지원 시스템 또는 데이터웨어 하우스에 대한 간단한 스키마는 이벤트가 큰 팩트 테이블에 수집되는 반면 작은 지원 테이블 ( demensions )이 데이터를 설명하는 데 사용되는 스타 스키마 입니다.

The TPC DS is an example of such a schema. 이벤트가 판매이고 일반적인 차원이 판매 날짜, 판매 시간 또는 구매 당사자의 인구 통계 인 일반적인 소매 창고를 모델링합니다. 일반적인 쿼리는 차원 테이블의 속성을 따라 팩트 테이블을 집계하고 필터링합니다.

 

Star Schema Example

Select count(*) cnt
From store_sales ss
     join household_demographics hd on (ss.ss_hdemo_sk = hd.hd_demo_sk)
     join time_dim t on (ss.ss_sold_time_sk = t.t_time_sk)
     join store s on (s.s_store_sk = ss.ss_store_sk)
Where
     t.t_hour = 8
     t.t_minute >= 30
     hd.hd_dep_count = 2
order by cnt;

 

Prior Support for MAPJOIN

Hive는이 시나리오에 적합한 MAPJOIN을 지원합니다. 최소한 메모리에 맞을만큼 작은 차원에 적합합니다. 0.11 릴리스 이전에는 최적화 프로그램 힌트를 통해 MAPJOIN을 호출 할 수있었습니다.

 

select /*+ MAPJOIN(time_dim) */ count(*) from store_sales join time_dim on (ss_sold_time_sk = t_time_sk)

or via auto join conversion:

 

set hive.auto.convert.join=true;
select count(*) from 
store_sales join time_dim on (ss_sold_time_sk = t_time_sk)

hive.auto.convert.join 의 기본값 은 Hive 0.10.0에서 false였습니다. Hive 0.11.0은 기본값을 true로 변경했습니다 ( HIVE-3297 ). 참고 하이브 default.xml.template가 잘못 0.13.1 통해 하이브 0.11.0 false으로 기본을 제공합니다.

MAPJOIN은 더 작은 테이블을 메모리 내 해시 맵에로드하고 스트리밍 될 때 더 큰 테이블과 키를 일치시켜 처리됩니다. 이전 구현에는 다음과 같은 분업이 있습니다.

• Local work:
  • read records via standard table scan (including filters and projections) from source on local machine
  • build hashtable in memory
  • write hashtable to local disk
  • upload hashtable to dfs
  • add hashtable to distributed cache
• Map task
  • read hashtable from local disk (distributed cache) into memory
  • match records' keys against hashtable
  • combine matches and write to output
• No reduce task

Limitations of Prior Implementation

 

Enhancements for Star Joins

Hive 0.11의 최적화 프로그램 향상은 스타 스키마 구성에 필요한 조인의 효율적인 처리에 중점을 둡니다. 초기 작업은 필터링 및 프로젝션 후 모든 차원 테이블이 동시에 메모리에 맞는 스타 스키마 조인으로 제한되었습니다. 이제 일부 차원 테이블 만 메모리에 맞는 시나리오도 구현됩니다 ( HIVE-3996 ).

조인 최적화는 세 부분으로 그룹화 될 수 있습니다.

다음 쿼리는 실행될 때 두 개의 개별 맵 전용 작업을 생성합니다.

• Execute chains of mapjoins in the operator tree in a single map-only job, when maphints are used.
• Extend optimization to the auto-conversion case (generating an appropriate backup plan when optimizing).
• Generate in-memory hashtable completely on the task side. (Future work.)

The following sections describe each of these optimizer enhancements.

Optimize Chains of Map Joins

The following query will produce two separate map-only jobs when executed:

select /*+ MAPJOIN(time_dim, date_dim) */ count(*) from
store_sales 
join time_dim on (ss_sold_time_sk = t_time_sk) 
join date_dim on (ss_sold_date_sk = d_date_sk)
where t_hour = 8 and d_year = 2002

그러나 작은 차원 테이블의 경우 필요한 두 테이블의 부분이 동시에 메모리에 맞을 가능성이 있습니다. 이렇게하면 팩트 테이블을 두 번 읽고 작업간에 통신하기 위해 HDFS에 쓰는 대신 한 번만 읽으므로이 쿼리를 실행하는 데 필요한 시간이 크게 줄어 듭니다.

 

Current and Future Optimizations

1. Merge M*-MR patterns into a single MR.
2. Merge MJ->MJ into a single MJ when possible.
3. Merge MJ* patterns into a single Map stage as a chain of MJ operators. (Not yet implemented.)

이 hive.auto.convert.jointrue로 설정되면 옵티마이 저는 조인을 맵 조인으로 변환 할뿐만 아니라 가능한 한 많이 MJ * 패턴을 병합합니다.

Optimize Auto Join Conversion

auto join 활성화되면 더 이상 쿼리에 맵 조인 힌트를 제공 할 필요가 없습니다. 자동 결합 옵션은 두 가지 구성 매개 변수로 활성화 할 수 있습니다.

 

set hive.auto.convert.join.noconditionaltask = true;
set hive.auto.convert.join.noconditionaltask.size = 10000000;

기본값 hive.auto.convert.join.noconditionaltask은 true이며 이는 자동 변환이 활성화되었음을 의미합니다. (원래 기본값은 false였습니다 – HIVE-3784 참조  – Hive 0.11.0이 출시되기 전에 HIVE-4146에 의해 true로 변경 되었습니다.)

크기 구성은 메모리에 들어갈 수있는 크기의 테이블을 제어 할 수 있도록합니다. 이 값은 메모리에 맞는 해시 맵으로 변환 할 수있는 테이블 크기의 합계를 나타냅니다. 현재, 조인의 n-1 테이블은 맵 조인 최적화를 적용하려면 메모리에 맞아야합니다. 테이블이 압축 된 것인지 여부와 테이블의 잠재적 인 크기를 확인할 수있는 검사는 없습니다. 이 가정이 결과에 미치는 영향은 다음 섹션에서 설명합니다.

For example, the previous query just becomes:

select count(*) from
store_sales 
join time_dim on (ss_sold_time_sk = t_time_sk)
join date_dim on (ss_sold_date_sk = d_date_sk)
where t_hour = 8 and d_year = 2002

time_dim 및 date_dim이 제공된 크기 구성에 맞으면 각 조인이 맵 조인으로 변환됩니다. 테이블 크기의 합계가 구성된 크기에 맞을 수있는 경우 두 맵 조인이 결합되어 단일 맵 조인이됩니다. 이렇게하면 필요한 MR 작업 수가 줄어들고이 쿼리의 실행 속도가 크게 향상됩니다. 이 예제는 다자간 조인에 대해서도 쉽게 확장 할 수 있으며 예상대로 작동합니다.

외부 조인은 더 많은 도전을 제공합니다. 맵 조인 연산자는 하나의 테이블 만 스트리밍 할 수 있으므로 스트리밍 된 테이블은 모든 행이 필요한 테이블이어야합니다. 왼쪽 외부 조인의 경우 조인 왼쪽에있는 테이블입니다. 오른쪽 외부 조인의 경우 오른쪽에있는 테이블 등입니다. 이는 내부 조인을 맵 조인으로 변환 할 수 있지만 외부 조인을 변환 할 수 없음을 의미합니다. 외부 조인은 스트리밍해야하는 테이블이 아닌 테이블이 크기 구성에 맞을 수있는 경우에만 변환 할 수 있습니다. 두 테이블을 모두 스트리밍해야하므로 전체 외부 조인을 맵 조인으로 변환 할 수 없습니다.

Auto join conversion also affects the sort-merge-bucket joins.

Current Optimization

1. Group as many MJ operators as possible into one MJ.

Hive가 구성 플래그를 기반으로 조인 연산자를위한 맵 조인으로 변환하는 과정에서 이러한 변환이 끝날 때 최대한 많은 그룹을 그룹화하기 위해 노력합니다. 순서대로 진행하면서 개별 맵 조인 연산자에 참여하는 테이블 크기의 합이 noConditionalTask.size플래그로 구성된 제한 내에 있으면 이러한 MJ 연산자가 함께 결합됩니다. 이렇게하면 이러한 쿼리와 관련하여 더 빠른 속도가 보장됩니다.

Auto Conversion to SMB Map Join

SMB (Sort-Merge-Bucket) 조인도 SMB 맵 조인으로 변환 할 수 있습니다. SMB 조인은 테이블이 정렬되고 버킷 화 될 때마다 사용됩니다. 조인은 이미 정렬 된 테이블을 병합하는 것으로 요약되어이 작업이 일반 맵 조인보다 빠를 수 있습니다. 그러나 테이블이 분할 된 경우 각 매퍼가 단일 키가있는 매우 작은 파티션 청크를 가져와야하므로 속도가 느려질 수 있습니다.

다음 구성 설정을 사용하면 SMB를 맵 조인 SMB로 변환 할 수 있습니다.

set hive.auto.convert.sortmerge.join=true;
set hive.optimize.bucketmapjoin = true;
set hive.optimize.bucketmapjoin.sortedmerge = true;

There is an option to set the big table selection policy using the following configuration:

 

set hive.auto.convert.sortmerge.join.bigtable.selection.policy =
org.apache.hadoop.hive.ql.optimizer.TableSizeBasedBigTableSelectorForAutoSMJ;

기본적으로 선택 정책은 평균 파티션 크기입니다. 큰 테이블 선택 정책은 해싱 및 스트리밍과 비교하여 스트리밍 전용으로 선택할 테이블을 결정하는 데 도움이됩니다.

 

The available selection policies are:

 

org.apache.hadoop.hive.ql.optimizer.AvgPartitionSizeBasedBigTableSelectorForAutoSMJ (default)
org.apache.hadoop.hive.ql.optimizer.LeftmostBigTableSelectorForAutoSMJ 
org.apache.hadoop.hive.ql.optimizer.TableSizeBasedBigTableSelectorForAutoSMJ

The names describe their uses. This is especially useful for the fact-fact join (query 82 in the TPC DS benchmark).

SMB Join across Tables with Different Keys

예를 들어 테이블 A에 2 개의 SORT 열이 있고 테이블 B에 1 개의 SORT 열이있는 경우와 같이 테이블에 다른 수의 키가있는 경우 인덱스 범위를 벗어난 예외가 발생할 수 있습니다.

다음 쿼리는 emp_person에 1 개의 정렬 열이있는 반면 emp_pay_history에는 2 개의 정렬 열이 있다고 가정하여 인덱스 범위를 벗어난 예외가 발생합니다.

Error Hive 0.11

SELECT p.*, py.*
FROM emp_person p INNER JOIN emp_pay_history py
ON   p.empid = py.empid

Working query Hive 0.11

SELECT p.*, py.*
FROM emp_pay_history py INNER JOIN emp_person p
ON   p.empid = py.empid

This works fine.

Generate Hash Tables on the Task Side

향후 작업을 통해 작업 측에서 완전히 인 메모리 해시 테이블을 생성 할 수 있습니다.

Pros and Cons of Client-Side Hash Tables

클라이언트 컴퓨터에서 해시 테이블 (또는 다중 테이블 조인을위한 여러 해시 테이블)을 생성하는 것은 단점이 있습니다. ( 클라이언트 시스템 은 Hive 클라이언트를 실행하고 작업을 제출하는 데 사용되는 호스트입니다.)

 

• 데이터 지역성 : 클라이언트 시스템은 일반적으로 데이터 노드가 아닙니다. 액세스되는 모든 데이터는 원격이며 네트워크를 통해 읽어야합니다.
• 사양 : 같은 이유로이 처리를 실행하는 머신의 사양이 무엇인지 명확하지 않습니다. 작업 노드에없는 메모리, 하드 드라이브 또는 CPU에 제한이있을 수 있습니다.
• HDFS 업로드 : 데이터는 클러스터로 다시 가져 와서 작업 노드에서 사용하기 위해 분산 캐시를 통해 복제해야합니다.

 

 

Pre-processing the hashtables on the client machine also has some benefits:

 

• 분산 캐시에 저장되는 것은 원래 테이블 (필터 및 프로젝션)보다 작을 수 있습니다.
• 반대로 분산 캐시를 사용하여 작업 노드에 직접 해시 테이블을로드하는 것은 캐시의 더 큰 개체를 의미하므로 잠재적으로 MAPJOIN을 사용할 기회가 줄어 듭니다.

 

 

Task-Side Generation of Hash Tables

해시 테이블이 작업 측에서 완전히 생성되면 모든 작업 노드는 해시 테이블을 생성하기 위해 원본 데이터 소스에 액세스해야합니다. 정상적인 경우 병렬로 발생하므로 지연 시간에 영향을 미치지 않지만 Hive에는 저장소 처리기의 개념이 있으며 많은 작업이 동일한 외부 데이터 원본 (HBase, 데이터베이스 등)에 액세스하면 원본을 압도하거나 속도를 늦출 수 있습니다.

Further Options for Optimization

1. Increase the replication factor on dimension tables.
2. Use the distributed cache to hold dimension tables.

 

출처 : cwiki.apache.org