Problème de scan de table complet avec LEFT OUTER JOIN dans Hive

Question

J'essaye d'effectuer une opération LEFT OUTER JOIN sur 2 de mes tables dans la ruche. Pourrait comprendre que nous avons inclure des conditions de filtre avec les conditions de jointure dans le cas de jointures, en les imitant d'où les conditions pour éviter les analyses de table complètes. Référence: https://gist.github.com/randyzwitch/9abeb66d8637d1a0007c

Malgré cela, ma requête se traduit par un nombre élevé de mappeurs et de réducteurs comme si elle effectuait une analyse de table complète.

Voici ma requête et mon plan d'explication. Je ne suis pas bon à comprendre ce plan d'explication. m.date_id et d.REC_CREATED_DATE sont les colonnes partitionnées dans les tables respectives de sorte qu'il ne devrait effectivement analyser que ces partitions.

Toutes les suggestions pour améliorer ma requête seraient d'une grande aide.

hive> EXPLAIN SELECT m.execution_id 
> ,m.operation_name 
> ,m.return_code 
> ,m.explanation 
> ,d.REC_CREATED_DATE 
> FROM web_log_master m LEFT OUTER JOIN web_log_detail d 
> on (m.execution_id = d.execution_id AND m.date_id='2015-07-14' and d.REC_CREATED_DATE='2015-07-14') ; 
OK 
ABSTRACT SYNTAX TREE: 
    (TOK_QUERY (TOK_FROM (TOK_LEFTOUTERJOIN (TOK_TABREF (TOK_TABNAME web_log_master) m) (TOK_TABREF (TOK_TABNAME web_log_detail) d) (and (AND (= (. (TOK_TABLE_OR_COL m) execution_id) (. (TOK_TABLE_OR_COL d) execution_id)) (= (. (TOK_TABLE_OR_COL m) date_id) '2015-07-14')) (= (. (TOK_TABLE_OR_COL d) REC_CREATED_DATE) '2015-07-14')))) (TOK_INSERT (TOK_DESTINATION (TOK_DIR TOK_TMP_FILE)) (TOK_SELECT (TOK_SELEXPR (. (TOK_TABLE_OR_COL m) execution_id)) (TOK_SELEXPR (. (TOK_TABLE_OR_COL m) operation_name)) (TOK_SELEXPR (. (TOK_TABLE_OR_COL m) return_code)) (TOK_SELEXPR (. (TOK_TABLE_OR_COL m) explanation)) (TOK_SELEXPR (. (TOK_TABLE_OR_COL d) REC_CREATED_DATE))))) 

STAGE DEPENDENCIES: 
    Stage-4 is a root stage , consists of Stage-1 
    Stage-1 
    Stage-0 is a root stage 

STAGE PLANS: 
    Stage: Stage-4 
    Conditional Operator 

    Stage: Stage-1 
Map Reduce 
    Alias -> Map Operator Tree: 
    d 
     TableScan 
     alias: d 
     Reduce Output Operator 
      key expressions: 
       expr: execution_id 
       type: string 
      sort order: + 
      Map-reduce partition columns: 
       expr: execution_id 
       type: string 
      tag: 1 
      value expressions: 
       expr: rec_created_date 
       type: string 
    m 
     TableScan 
     alias: m 
     Reduce Output Operator 
      key expressions: 
       expr: execution_id 
       type: string 
      sort order: + 
      Map-reduce partition columns: 
       expr: execution_id 
       type: string 
      tag: 0 
      value expressions: 
       expr: execution_id 
       type: string 
       expr: operation_name 
       type: string 
       expr: return_code 
       type: string 
       expr: explanation 
       type: string 
       expr: date_id 
       type: string 
    Reduce Operator Tree: 
    Join Operator 
     condition map: 
      Left Outer Join0 to 1 
     condition expressions: 
     0 {VALUE._col0} {VALUE._col1} {VALUE._col2} {VALUE._col3} 
     1 {VALUE._col3} 
     filter predicates: 
     0 {(VALUE._col13 = '2015-07-14')} 
     1 
     handleSkewJoin: false 
     outputColumnNames: _col0, _col1, _col2, _col3, _col19 
     Select Operator 
     expressions: 
       expr: _col0 
       type: string 
       expr: _col1 
       type: string 
       expr: _col2 
       type: string 
       expr: _col3 
       type: string 
       expr: _col19 
       type: string 
     outputColumnNames: _col0, _col1, _col2, _col3, _col4 
     File Output Operator 
      compressed: false 
      GlobalTableId: 0 
      table: 
       input format: org.apache.hadoop.mapred.TextInputFormat 
       output format: org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat 

    Stage: Stage-0 
    Fetch Operator 
     limit: -1 


Time taken: 13.616 seconds, Fetched: 90 row(s) 

Answer 1

Le nombre de mappeurs et de réducteurs dépend du fait que le travail est parallélisable et de la capacité de votre cluster. Si vous avez beaucoup de machines, vous obtenez plus de mappeurs et de réducteurs. Si vous avez moins de machines, vous en aurez moins. Si le travail n'est pas parallélisables alors vous obtiendrez un réducteur comme dans le cas ici:

select count(distinct column) from x; 

Ce qui nécessite un seul réducteur lorsqu'il est écrit de cette façon.

En fait, vous voulez que de nombreux mappeurs et réducteurs fonctionnent. C'est ainsi que la carte réduit les échelles. Beaucoup de mains font le travail léger pour ainsi dire. Dans tous les cas, votre jointure externe gauche fonctionne comme prévu.