정선생의 데이터 팡팡

최근 검색량이 높은 키워드가 무엇인지를 알고 싶을때, flink 에서는 호핑윈도우(슬라이딩 윈도우) 기반으로 지정하고, 슬라이드 사이즈와 데이터 간격을 지정해서 로직을 유도하여 만드는걸 구성했다. 이해를 돕기위해 대충 쿼리를 표현하면 아래와 같다. 하지만, 처음에는 잘 동작하다가 어느순간 backpress 가 발생해서 데이터 지연으로 제대로 처리안되는 문제가 발생했다. INSERT INTO top_keyword_slide ...생략.... FROM TABLE( HOP( DATA => TABLE kafka_log, TIMECOL => DESCRIPTOR(log_time), SLIDE => INTERVAL '30' SECOND, SIZE => INTERVAL '10' MINUTES) ) WHERE valid..

airflow 의 best practices 글을 읽어보면, Variable.get(키) 형태로 직접 값을 가져오지 않고, 바인딩처리해서 {{var.value.키}} 표현해서 사용하는것을 기본 가이드로 하고 있다. 그 이유는 일단 DAG 를 구성할때 top level code 에 관련된 로직이 존재한다면 DAG 실행뿐 아니라, 로딩되는 시점에서도 그 코드가 동작되기 때문에 성능에 문제가 될 수 있다. https://airflow.apache.org/docs/apache-airflow/stable/best-practices.html#airflow-variables from airflow.models import Variable # Bad example foo_var = Variable.get("foo")..

하둡 클러스터 이전을 위해 ETL 을 등록하는데 이상하게 old 서버에서는 잘되는게, new 서버에서는 너~~무 느린문제가 있었다. 일단 성능개선을 위해 동일한 Hive 버전도 아니었고, 플랜도 다르게 돌아가는 상황이라 답답한 상황이었다. 우선 결론부터 말하면 리듀서가 14~26개 정도가 할당되었는데, JOIN 과 카디널리티가 높은 Group By 였기 때문에 이정도수로는 어림도 없는 수준이었기 때문에 너무 오래걸린 문제였다. ---------------------------------------------------------------------------------------------- VERTICES MODE STATUS TOTAL COMPLETED RUNNING PENDING FAILED KI..

보통 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 데이터 문제 이런 데이터 쏠림현상은 생각보다 흔하다. 우리나라 성씨만 봐도 "김씨" 가 압도적으로 많다. 아마 ㄱㄴㄷ 형태로 담당자를 정하면 ㄱ을 담당한 사람은 숫자 카운팅할때 엄~~청 오래걸릴수 밖에 없을것이다. 이런 문제를 해결하려면 데이터 쏠림이 심한 테이터를 분산처리할 수 있도록 유도해주어야 한다...