select 문을 사용할때 특정 필드만 선택할 경우는 필드명을 나열하면 된다. 근데 필드가 어마어마하게 많은데 1개 필드만 제외해서 select 하고 싶은 경우 어떻게 해야할지 고민이 된다. (쉽게 말해서 화이트 리스트로 필드를 골라내는게 아니라, 블랙 리스트로 필드를 골라내고 싶다는말) 예를 들어, 모든 필드를 조회할때는 select * from t_sample_users 로 간소화가 가능하다. 하지만 여기서 tel_num, ymd 만 제외해서 조회하려면 어떻게 해야할까? 가장 기본적인 방법은 아래 방법처럼 필요한 필드를 모두 나열하는 방법이다. (=화이트 리스트 방식) 하지만 필드가 너무 많다면 이건 너무 비효율적이다. 그럼 블랙리스트 방식으로 안쓰는 필드만 발라내는 방법은 어떻게 해야할까??? hi..
참고로 이 문제는 Flink 1.14.x 버전대에서 JDK11 버전을 이용할때 아래와 같은 문제가 발생된다. 나같은 경우 hadoop 2.6.x 버전에 hive 2.3.6 을 사용하는데, JDK 호환성의 영향이 존재했었다. https://issues.apache.org/jira/browse/HIVE-22415 https://issues.apache.org/jira/browse/HADOOP-12760 $ java -version openjdk version "11.0.13" 2021-10-19 LTS OpenJDK Runtime Environment 18.9 (build 11.0.13+8-LTS) OpenJDK 64-Bit Server VM 18.9 (build 11.0.13+8-LTS, mixed mod..
Flink 1.14 에서는 잘 동작하던 쿼리가 Flink 1.15 에서 오류가 발생되었다. 쿼리는 kafka 테이블을 mysql 혹은 hdfs 에 sink 하는 로직이었고, 1.15.2 버전이 나와서 그걸 써도 동일한 문제가 발생되었다. Flink SQL> > INSERT INTO MysqlSource > SELECT > DATE_FORMAT(window_start, 'yyyy-MM-dd') AS ymd, > DATE_FORMAT(window_start, 'HHmm') AS hh24, > keyword, > COUNT(*) as cnt > FROM TABLE( > TUMBLE( > DATA => TABLE KafkaSource, > TIMECOL => DESCRIPTOR(logTime), > SIZE =..
Airflow 에서 "hive_cli_default" Connection 을 설정할때, Extra 옵션에 {"use_beeline": true} 를 추가하면, beeline 을 통해 쿼리를 실행한다. 근데, 기본적으로 -hiveconf 옵션에 airflow.ctx.* 패턴의 값이 추가되면서 아래와 같은 오류가 발생될 때가 존재한다. java.lang.IllegalArgumentException: Cannot modify airflow.ctx.dag_id at runtime. It is not in list of params that are allowed to be modified at runtime 이 오류를 재현하는 방법은 beeline 을 실행할때 -hiveconf airflow.ctx.dag_id=..
보통 Unique Count 를 구하기위해서 다음과 같은 쿼리를 많이 사용한다. 유니크 카운트가 필요한 대표적인 사례가 방문한 사람이 몇명인지 카운팅하는 User Count 를 구할때이다. 단순한 count 가 아니라, 중복 방문을 제거후 카운팅을 해야하다보니 비용이 비싼 쿼리이다. SELECT count(distinct user_id) FROM logs WHERE ymd = '2022-01-02'; 1개의 리듀서로 처리된다? count(distinct ...) 형태로 쿼리를 날리면, "mapred.reduce.tasks=100" 같이 리듀서 갯수를 강제로 키워도 1개의 리듀서로 처리된다. 즉, 병렬처리가 안되기 때문에 매우 큰 데이터에서 이런 쿼리를 돌리게 되면?? 결과 보기가 하늘의 별따기가 된다. ..
Hive 에서 쿼리를 돌리다보면, 특정 리듀서 하나에서 작업이 안끝나고 무한정 대기하는 경우가 종종있다. 이런 경우 skewed 형태의 데이터구조일 확률이 높다. skewed 라는건 데이터가 균일하지 않고, 특정 key 에 데이터가 쏠려있음을 의미한다. 특정 리듀서에 데이터가 쏠려있어서 병목이 되는 현상이다. (이미지에서 1개의 task 만 끝나지 않는 상황인걸 보면 쉽게 이해 할수 있다) Skewed 데이터 문제 이런 데이터 쏠림현상은 생각보다 흔하다. 우리나라 성씨만 봐도 "김씨" 가 압도적으로 많다. 아마 ㄱㄴㄷ 형태로 담당자를 정하면 ㄱ을 담당한 사람은 숫자 카운팅할때 엄~~청 오래걸릴수 밖에 없을것이다. 이런 문제를 해결하려면 데이터 쏠림이 심한 테이터를 분산처리할 수 있도록 유도해주어야 한다...
Flink 의 "streaming-source.enable" 기능을 이용해서 hive의 데이터를 스트림 데이터스럽게 처리하려고 했는데 희안하게 어떤 테이블은 잘 되는데, 어떤 테이블은 또 안되는 현상이 발생되었다. 그 이유는 결론부터 말하면 파티션이 약 3만개를 넘어가면 새로운 파티션이 생긴걸 인지 못하는 문제가 있다. (지원안하면 오류를 내야지... 뭔가 버그가 아닌가 싶다) 파티션 감지할때 갯수제한이 있다고? 기능 테스트를 위해 새로 만든테이블에서는 잘 되는데, 기존테이블을 이용해 시도하는데 안된다면 이 문제일 확률이 높다. 소스코드를 분석해보면 알겠지만, 메타스토어에서 파티션 정보를 리턴받고, 이 데이터를 어플리케이션에서 필터링하고 기준값보다 큰 파티션이 무엇인가를 찾아가는 과정을 반복한다. 문제는..
flink 에서 hive 는 unbounded sacn 을 지원한다. 더 정확히 말하면 파티션이나 파일이 생기는걸 주기적으로 감시하다가 데이터를 조회하는 한다는게 더 맞을지도 모르겠다. 이게 뭔 의미가 있나 싶겠지만 스트림 데이터를 다루는것처럼 로직을 flink 에 submit 하면 새로운 파티션이 생길때마다 별도의 스케쥴링 없이 운영이 가능하다는 말이다. 즉, 배치형태로 작업을 구성하지 않고, 스트리밍 데이터를 다루듯 운용할수 있다는 말이다. Hive 데이터를 스트림 데이터처럼 다루기 hive 에 데이터를 적재할때 보통 파티션 단위로 데이터를 적재한다. 만약, airflow 를 이용해 데이터를 데이터를 재가공하는 로직을 등록한다면 특정 파티션을 센싱하고 있다가 생성이 되면 로직이 실행되는 구조로 DAG..