우선 hive 를 MR 엔진으로 돌리면


set mapreduce.job.queuename=큐이름


형태로 지정한다. 하지만 tez엔진을 쓰면 이 옵션은 동작하지 않는다.


tez에서 큐 이름을 지정하는건 옵션이 다르다.


set tez.queue.name=큐이름;



추가적으로, hive에서는 job name이 hql의 앞쪽 명령어로 지정되어 yarn의 리소스를 보면 대충 어떤 쿼리가 yarn에서 돌고있는지 인지가 가능한데, 문제는 tez엔진에서는 job name을 지정하는 옵션이 안먹는다 


참고로, tez 엔진으로 hive쿼리를 실행하면 job name이 

HIVE-f737252c-20d3-4f32-9277-15f206f2b0f8 같은 UUID 패턴으로 생성되서 어떤 쿼리가 돌고 있는건지 알길이 없다.


결국 큐이름을 이용해 작업을 구분하고있다.


hive 상위버전에서는 해결되었다는 소문도 있던거 같은데 아직까진 모르겠다.


이 경우는 컨테이너 사이즈가 작기 때문이다.

yarn 에서 컨테이너 사이즈보다 메모리를 많이 쓰게되면 리소스 관리를 하다가 강제로 container를 죽여버린다.


그래서 hive.tez.container.size 와 set hive.tez.java.opts 사이즈를 늘려줘야한다.

참고로 hive.tez.java.opts는  컨테이너 크기의 80% 수준으로 지정하는것이 일반적이다.


만약, java.opt 값이 작게 지정된거라면 heap 어쩌구 하는 에러가 날것이다.



--------------------------------------------------------------------------------

        VERTICES      STATUS  TOTAL  COMPLETED  RUNNING  PENDING  FAILED  KILLED

--------------------------------------------------------------------------------

Map 1 ..........   SUCCEEDED      1          1        0        0       0       0

...

Map 46                FAILED      1          0        0        1       4       0

....


Status: Failed

Vertex failed, vertexName=Map 46, vertexId=vertex_1466764800233_14303_1_05, diagnostics=[Task failed, taskId=task_1466764800233_14303_1_05_000000, diagnostics=[TaskAttempt 0 failed, info=[Container container_1466764800233_14303_01_000024 finished with diagnostics set to [Container failed, exitCode=-104. Container [pid=19273,containerID=container_1466764800233_14303_01_000024] is running beyond physical memory limits. Current usage: 1.3 GB of 1 GB physical memory used; 3.8 GB of 2.1 GB virtual memory used. Killing container.

Dump of the process-tree for container_1466764800233_14303_01_000024 :

        |- PID PPID PGRPID SESSID CMD_NAME USER_MODE_TIME(MILLIS) SYSTEM_TIME(MILLIS) VMEM_USAGE(BYTES) RSSMEM_USAGE(PAGES) FULL_CMD_LINE

        |- 19354 19273 19273 19273 (java) 1006 76 3990794240 339542 /usr/java/jdk1.7.0_67-cloudera/bin/java -server -Djava.net.preferIPv4Stack=true -Dhadoop.metrics.log.level=WARN -Xmx3g -Dlog4j.configuratorClass=org.apache.tez.common.TezLog4jConfigurator -Dlog4j.configuration=tez-container-log4j.properties -Dyarn.app.container.log.dir=/var/log/hadoop-yarn/container/application_1466764800233_14303/container_1466764800233_14303_01_000024 -Dtez.root.logger=INFO,CLA -Djava.io.tmpdir=/data10/yarn/nm/usercache/user/appcache/application_1466764800233_14303/container_1466764800233_14303_01_000024/tmp org.apache.tez.runtime.task.TezChild 호스트명 34263 container_1466764800233_14303_01_000024 application_1466764800233_14303 1

        |- 19273 19259 19273 19273 (bash) 0 0 112906240 317 /bin/bash -c /usr/java/jdk1.7.0_67-cloudera/bin/java -server -Djava.net.preferIPv4Stack=true -Dhadoop.metrics.log.level=WARN  -Xmx3g -Dlog4j.configuratorClass=org.apache.tez.common.TezLog4jConfigurator -Dlog4j.configuration=tez-container-log4j.properties -Dyarn.app.container.log.dir=/var/log/hadoop-yarn/container/application_1466764800233_14303/container_1466764800233_14303_01_000024 -Dtez.root.logger=INFO,CLA  -Djava.io.tmpdir=/data10/yarn/nm/usercache/user/appcache/application_1466764800233_14303/container_1466764800233_14303_01_000024/tmp org.apache.tez.runtime.task.TezChild 호스트명 34263 container_1466764800233_14303_01_000024 application_1466764800233_14303 1 1>/var/log/hadoop-yarn/container/application_1466764800233_14303/container_1466764800233_14303_01_000024/stdout 2>/var/log/hadoop-yarn/container/application_1466764800233_14303/container_1466764800233_14303_01_000024/stderr




만약, 이렇게 설정되어있었다면, 좀더 사이즈를 늘려본다.


set hive.execution.engine=tez;
set hive.tez.container.size=1024;
set hive.tez.java.opts=-Xmx816m;


예를 들면, 이런식으로 

컨테이너 사이즈를 크게 잡으면 mapper/reducer 갯수가 상대적으로 줄어들기 때문에

메모리를 무조건 크게 잡는게 빠른건 아니다. 무조건 크게하기보다는 상황에 맞게 fit 하게 맞추는게 유용하다.


set hive.execution.engine=tez;
set hive.tez.container.size=2048;
set hive.tez.java.opts=-Xmx1632m;


tez엔진으로 쿼리를 돌릴때 dynamic partition 해서 insert 할때 나오는 버그이다.

파티셔닝 필드를 동적으로 지정하면 문제가 된다. 이 버그를 회피하는 방법은 파티션 필드의 값을 상수로 지정해주면된다.


물론, 이렇게 하면 여러데이터가 섞여있다면 수작업이 걸릴텐데.

스케쥴형태로 배치돌리는 구조라면 큰 문제는 안될듯...



Status: Running (Executing on YARN cluster with App id application_1465540766236_4158)
--------------------------------------------------------------------------------
        VERTICES      STATUS  TOTAL  COMPLETED  RUNNING  PENDING  FAILED  KILLED
--------------------------------------------------------------------------------
Map 1 ..........   SUCCEEDED    160        160        0        0       0       0
Map 3              SUCCEEDED      0          0        0        0       0       0
Map 4              SUCCEEDED      0          0        0        0       0       0
--------------------------------------------------------------------------------
VERTICES: 03/03  [==========================>>] 100%  ELAPSED TIME: 8.25 s
--------------------------------------------------------------------------------
Loading data to table temp.speed_test partition (base_dt=null, base_tm=null)
Failed with exception MetaException(message:Invalid partition key & values; keys [base_dt, base_tm, ], values [])
FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.MoveTask


[문제의 쿼리 패턴]

insert overwrite table temp.speed_test partition(base_dt, base_tm)

SELECT 

 ....

 , base_dt

 , base_tm 

FROM

 .....


[버그를 해결하려면?]

insert overwrite table temp.speed_test partition(base_dt='20160614', base_tm='16')

SELECT 

 ....

 , base_dt

 , base_tm 

FROM

 .....

  ymd = '20160614' and hh24=16


+ Recent posts