[HADOOP] Oozie에서 여러 Hive QL 최적화

Oozie에서 여러 Hive QL 최적화

나는 하이브에 익숙하지 않으므로 여기에 있습니다. 우리는 Oozie를 사용하여 많은 하이브 ql 작업을 연결합니다. 프로덕션 환경에서 이미 실행중인 응용 프로그램을 최적화해야했습니다. 비즈니스 파트너는 1.5 시간 이상 걸리는 것을 원하지 않습니다. 내가 처음 발견 한 것 중 하나는이 하나의 작업 흐름 내에 약 90 개의 oozie 동작이 있다는 것입니다. 또한 다른 응용 프로그램과 원사 대기열을 공유합니다. 이러한 조치 중 절반은 hive2 조치이며 각 Hive QL 조치는 하나의 HQL 문만 수행합니다. Oozie 실행기가 대기열에서 대기 한 다음 HiveQL이 대기열에서 대기하기 때문에 때때로 HiveQL 작업간에 지연이있는 것 같습니다. 그게 정상인가요? 이 주위에 방법이 있습니까?

시간에 민감한 Hive 쿼리의 경우 : 1) Oozie는 시간에 민감한 HiveQL 스크립트를 연결하는 데 사용해야하는 올바른 도구입니까? 2) 몇 가지 대안은 무엇입니까 (Java 또는 Python을 사용하여 HQL 간의 흐름을 시작하고 처리 할 수 ​​있습니까?)? 3) HQL 자체에서 할 수있는 일이 있습니까? (저는 MapReduce / Spark 및 간단한 워크 플로에 대한 경험을 주로 경험했습니다 (20 개 미만의 작업). 4) 언급하지 않은 다른 성능 고려 사항이 있습니까?

고맙습니다,

해결법

1. ==============================

   1.Oozie는 자체적으로 아무것도 실행하지 않습니다. 기본 명령 ( "hive"에 대한 Hive CLI fat 클라이언트, "hive2"에 대한 Beeline 씬 클라이언트, Pig CLI, Sqoop, Spark)을 실행하기 위해 Launcher를 먼저 시작합니다 (더미 YARN 작업 (1 AppMaster + 1 Mapper)). Driver, Bash shell 등) 그런 다음 해당 명령은 일련의 YARN 작업을 생성 할 수 있습니다.

   Oozie는 자체적으로 아무것도 실행하지 않습니다. 기본 명령 ( "hive"에 대한 Hive CLI fat 클라이언트, "hive2"에 대한 Beeline 씬 클라이언트, Pig CLI, Sqoop, Spark)을 실행하기 위해 Launcher를 먼저 시작합니다 (더미 YARN 작업 (1 AppMaster + 1 Mapper)). Driver, Bash shell 등) 그런 다음 해당 명령은 일련의 YARN 작업을 생성 할 수 있습니다.

   YARN은 실행기와 생성 된 작업 간의 종속성을 인식하지 못합니다. 특히 "hive2"작업의 경우 실행기가 HiveServer2에 연결되고 작업을 생성하는 HiveServer2이기 때문에!

   조언 # 1-런처 작업에는 조정이 거의 필요하지 않으므로 (매퍼 1 명만 기억하십시오) RAM을 너무 많이 사용하지 않아 대기열을 차단하지 않도록 AppMaster 자원을 다소 낮게 설정해야합니다. oozie.launcher.yarn.app.mapreduce.am.resource.mb (총 RAM) 및 oozie.launcher.yarn.app.mapreduce.am.command-opts (아쉽게 문서화되지 않음) 작업 속성으로 기본 설정을 재정의 할 수 있습니다. ( "-Xmx"매개 변수, 일반적으로 RAM의 80 % 인 Java 힙 크기에 대한 명시 적 할당량-너무 낮고 OutOfMemory 오류가 너무 높으며 YARN이 할당량 오용으로 인해 컨테이너를 종료 할 수 있음)

   조언 # 2- "hive2"의 경우 실행기 작업에는 자원이 거의 필요하지 않습니다 (Beeline은 얇은 JDBC 클라이언트 임). ㅋㅋㅋ

   조언 # 3-우선 순위가 높은 YARN 대기열에 액세스 할 수있는 경우 (Biswajit Nayak의 조언에 따라) oozie.launcher.mapreduce.job.queuename과 함께 Launcher를 사용하십시오. 실제 Hive 쿼리의 경우 다음에 따라 다릅니다.

   조언 # 4-기본 AM 리소스가 Hive 쿼리에 비해 너무 큰 경우 크기를 조정 해 볼 수도 있습니다

   # 1-2-4에 대한 경고 : yarn.scheduler.minimum-allocation-mb 미만을 요청할 수 없습니다 (그리고 ResourceManager 서비스에 대해 설정되어 있으므로 작업별로이를 재정의 할 수 없습니다).

   조언 # 5-일부 단계가 동일한 HQL 스크립트에 연결될 수있는 경우, Oozie 폴링 YARN의 오버 헤드를 줄여 첫 번째 쿼리의 끝을 감지 한 다음 다른 시작 관리자를 시작한 다음 시작 관리자가 다른 Hive 세션을 시작합니다. 물론 오류가 발생하면 실행 제어가 세분화되지 않고 다시 시작하기 전에 일부 수동 정리가 필요할 수 있습니다.

   조언 # 6-일부 단계를 병렬로 수행 할 수 있고 실제로 병렬로 실행할 충분한 YARN 자원이있는 경우, Biswajit Nayak의 조언에 따라 Oozie Fork / Join의 다른 분기에 배치하십시오.

   조언 # 7-아직 TEZ를 사용하지 않은 경우 사용해보십시오. 클러스터에 적합한 매개 변수 세트를 찾는 것이 까다로울 수 있지만 작동하는 경우 MapReduce보다 훨씬 효율적입니다 (예 : Map 및 Reduce 단계와 동일한 쿼리에 대해 동일한 YARN 컨테이너를 재사용 함). YARN 오버 헤드 감소, 중간 디스크 I / O 감소 등)

   ~~~~~~~~

   그건 그렇고, 어떤 곳에서 이전의 "하이브"액션을 사용하는 좋은 이유가 있습니까? "로컬 모드"를 강제하는 옵션이있을 수 있습니다. 예를 들어 YARN을 건너 뛰고 추가 오버 헤드없이 Launcher 내에서 작은 쿼리를 실행합니까? 아니면 그들은 자세한 로그를 원했을까요?

2. ==============================

   2.Oozie는 예약을위한 완벽한 도구입니다. 다음은 살펴볼 몇 가지 사항입니다.

   Oozie는 예약을위한 완벽한 도구입니다. 다음은 살펴볼 몇 가지 사항입니다.

   "Oozie 실행기가 대기열에서 대기 한 후 HiveQL이 대기열에서 대기하기 때문에 때때로 HiveQL 작업간에 지연이 발생하는 것 같습니다. 정상입니까?", 다른 작업에서 대기열 용량을 완전히 사용하는 경우 새 작업 누군가가 용량을 확보 할 때까지 기다립니다. 그래서 포인트 3에 전용 대기열을 요청했습니다.

from https://stackoverflow.com/questions/35538621/optimize-multiple-hive-ql-in-oozie by cc-by-sa and MIT license