하둡 클러스터 이전을 위해 ETL 을 등록하는데 이상하게 old 서버에서는 잘되는게, new 서버에서는 너~~무 느린문제가 있었다. 일단 성능개선을 위해 동일한 Hive 버전도 아니었고, 플랜도 다르게 돌아가는 상황이라 답답한 상황이었다. 우선 결론부터 말하면 리듀서가 14~26개 정도가 할당되었는데, JOIN 과 카디널리티가 높은 Group By 였기 때문에 이정도수로는 어림도 없는 수준이었기 때문에 너무 오래걸린 문제였다. ---------------------------------------------------------------------------------------------- VERTICES MODE STATUS TOTAL COMPLETED RUNNING PENDING FAILED KI..
select 문을 사용할때 특정 필드만 선택할 경우는 필드명을 나열하면 된다. 근데 필드가 어마어마하게 많은데 1개 필드만 제외해서 select 하고 싶은 경우 어떻게 해야할지 고민이 된다. (쉽게 말해서 화이트 리스트로 필드를 골라내는게 아니라, 블랙 리스트로 필드를 골라내고 싶다는말) 예를 들어, 모든 필드를 조회할때는 select * from t_sample_users 로 간소화가 가능하다. 하지만 여기서 tel_num, ymd 만 제외해서 조회하려면 어떻게 해야할까? 가장 기본적인 방법은 아래 방법처럼 필요한 필드를 모두 나열하는 방법이다. (=화이트 리스트 방식) 하지만 필드가 너무 많다면 이건 너무 비효율적이다. 그럼 블랙리스트 방식으로 안쓰는 필드만 발라내는 방법은 어떻게 해야할까??? hi..
개요 희안하게 0건인 결과와 UNION ALL 하는 경우 null 오류가 발생했다. 더 특이했던건 hive client 에서는 쿼리가 성공하는데... jdbc 드라이버를 통하거나 beeline 을 통해서 쿼리를 날릴때만 발생했다는 점이다. (아마 두 설정에 차이가 있던건 아닌가 싶긴하다. Caused by: org.apache.hive.service.cli.HiveSQLException: Error while compiling statement: FAILED: NullPointerException null at org.apache.hive.service.cli.operation.Operation.toSQLException(Operation.java:315) at org.apache.hive.service..
개요 hive 는 쿼리기반으로 데이터를 분석하기 위한 도구이다. 스키마는 메타스토어의 DBMS에 저장되지만 실제 데이터는 기본적으로는 HDFS 에 저장되어 있다. 그래서 hive 에서 논리적으로 테이블, 파티션, 버킷이라고 부르지만, 물리적으로 데이터가 어떻게 저장되어있냐? 하는 관점에서 생각하면 HDFS 의 폴더와 파일로 생각할 수 있다. 하둡 패키지에 따라 root 폴더는 다르겠지만 아래와 같은 폴더 구조로 저장된다는말이다. /apps/hive/warehouse/.db//=/ 예를 들면, 이런 폴더 구조를 생각하면 쉽다 (db폴더) /apps/hive/warehouse/temp.db (table 폴더) /apps/hive/warehouse/temp.db/t_foo (파티션 없는 temp.t_foo 테..
오류내용 hive 에 STRUCT 형으로 필드가 있는 테이블을 JOIN 할 때 나타났던 문제이다. hql의 문법상 문제가 없는데 beeline 에서 뱉는 오류메시지는 다음과 같다. (tez 엔진을 사용했다) INFO : Map 1: 26(+2)/28 Map 5: 337(+33)/370 Map 6: 1(+1)/2 Reducer 3: 0(+0,-415)/377 Reducer 4: 0/208 ERROR : Status: Failed ERROR : Vertex re-running, vertexName=Map 5, vertexId=vertex_1475821062280_208694_1_01 ERROR : Vertex re-running, vertexName=Map 6, vertexId=vertex_147582106..
배치가 주기적으로 돌고 있는데, 분석을 위해 select 를 하게되면 더 골치아프다. 경험상 select 를 주기적으로 하면 락때문에 insert 는 무한히 밀려서 배치작업에 영향을 주기도 한다. 이런일이 자주 일어난다면 select 쿼리에서는 lock 정보를 사용하지 않는것이 정신건강에 좋다. hive lock 안쓰기? 하이브에서 주기적으로 배치가 돌고 있고, 쿼리가 복잡해서 오래 실행되면서 주키퍼에 lock 정보는 쌓였는데, yarn 에서는 작업을 무한대기 하는 상태인 경우가 종종 생긴다. 이럴땐 아예 lock 을 안걸고 쓰는게 안정적인 운영에 도움이 될수 있다. (hive 의 lock 체계는 우리가 주로 쓰는 dbms 의 lock 정책에 비하면 매우 초보적이다) hive> set hive.suppo..
hive 는 다양한 파일포맷과 스토리지 핸들러를 통해 hdfs 가 아닌 es 나 kafka 같은 외부 스토리지의 연결도 가능하게 해준다. 그래서 테이블이 어떤 파티션 정책을 갖고 있고 어떤 파일포맷이고 어떤 스토리지 핸들러를 쓰는지 확인해보고 싶은 경우가 생긴다. 특히 딴사람이 만든 테이블이라서 분석이 필요한 경우 더 그런듯 테이블 선언문(DDL) 확인 "show create table 테이블명" 을 하면 테이블 생성할때의 명령을 확인할 수 있다. 이러면 스키마 정보나, SERDE 정보 그리고 어떤 파일포맷과 압축정책을 썼는지 까지 쉽게 확인이 가능하다. 하지만, 코멘트가 한글일 경우 다음과 같이 깨져서 보이는게 조금 아쉽다. 꼭, 코멘트를 확인하고 싶다면 describe 명령을 이용해서 확인하면 가능하..
하이브에서 쿼리를 날릴때 이런 쿼리가 발생했고 구글링 하면 나오는 사이트중 그나마 힌트에 근접한 결과는 아래링크에서 얻을수 있었다. https://docs.treasuredata.com/display/public/PD/Hive+Known+Limitations 에러의 원인은 뭘까? 원인이 되는 쿼리를 패턴을 찾아보면 "LATERAL VIEW" 와 "UNION ALL" 를 복잡하게 섞었을때 종종 나타나는것 같다. 가끔 beeline 에서 오류나는게 hive 커멘드에서는 재현이 안되는 경우가 있으니 동일한 환경에서 쿼리를 테스트해야 재현되는경우가 있으니 참고하자. 상세한 오류(에러)메시지는 아래와 같다. 참고로 해결방법은 버그가 아닐까 싶을 정도로 단순하며 찜찜하다 ㅋㅋ etting log thread is ..