[오류] Hive 의 deadLock 문제 - lock 사용안하기

배치가 주기적으로 돌고 있는데, 분석을 위해 select 를 하게되면 더 골치아프다.

경험상 select 를 주기적으로 하면 락때문에 insert 는 무한히 밀려서 배치작업에 영향을 주기도 한다.

이런일이 자주 일어난다면 select 쿼리에서는 lock 정보를 사용하지 않는것이 정신건강에 좋다.

hive lock 안쓰기?

하이브에서 주기적으로 배치가 돌고 있고, 쿼리가 복잡해서 오래 실행되면서 

주키퍼에 lock 정보는 쌓였는데, yarn 에서는 작업을 무한대기 하는 상태인 경우가 종종 생긴다.

이럴땐 아예 lock 을 안걸고 쓰는게 안정적인 운영에 도움이 될수 있다.

(hive 의 lock 체계는 우리가 주로 쓰는 dbms 의 lock 정책에 비하면 매우 초보적이다)

hive> set hive.support.concurrency=false;

왜냐면 일반적으로 hive 에서는 파티션별 insert 되는 패턴으로 운영되지 update 되는 케이스는 드믈기 때문에 lock 을 사용했을때의 이득이 생각보다 많지 않다. 참고로 이와 유사한 jira 이슈는 다음과 같다

https://issues.apache.org/jira/browse/HIVE-12258

 

hive lock 문제는 왜 일어났을까?

명확한 결론은 내지 못했지만, lock 을 해제하고 쓰면서 데드락 문제는 해결되었고 뇌피셜이긴 하지만 다음과 같은 가정으로 문제가 발생된게 아닐까 의심하고 있다. (왜냐면 query가 엄청 오래 대기하다가 나타났었기 때문에)

• lock 때문에 쿼리 실행이 대기됨
• 대기중인 클라이언트 or 요청된곳에서 문제 발생 (=세션이 명시적으로 안끊기고 좀비화)
• 좀비화된 세션에서 락을 놓지 않아서, 데드락이 된건 아닐까?

 

hive의 lock 정보 확인하기

하이브에서  "show locks" 명령으로 lock 거린 테이블이나 파티션 정보 확인이 가능하다.

근데, 문제가 발생한걸 추적하려면 어떤 쿼리가 실행되다가 문제가 되었는 알아야 한다. 이럴땐 lock정보가 저장되는 주키퍼에 직접 접근해서 내용을 확인하면 쿼리도 확인이 가능하다.

hive> show locks;
OK
temp@data_20210101 SHARED
temp@data_20210102 SHARED
mart@prod_data@stat_dt=20210101  SHARED
mart@prod_data  SHARED
mart@sales_data SHARED
mart@sales_data@ymd=2021-11-12 SHARED
mart@sales_data@ymd=2021-11-12/hh24=1300 EXCLUSIVE
Time taken: 13.632 seconds, Fetched: 7 row(s)

접근해서 주키퍼의 폴더를 확인하면 락이 걸린 db, table, partition 형태의 폴더 구조를 볼 수 있고, 

마지막 LOCK-SHARED-xxxxx 같은 내용을 보면 확인해보면 쿼리 정보까지 확인이 가능하다.

주키퍼에서 직접 락정보와 쿼리도 확인가능

참고로 주키퍼의 내용을 확인하는건 command 툴을 써도 되지만, 나는 UI 가 편해서 아래 툴을 사용했다.

https://github.com/echoma/zkui

GitHub - echoma/zkui: zkui is a GUI client of Apache ZooKeeper. Download: