맨땅에 헤딩하는 사람

2020 하반기 금융결제원 공채 전산직 2차 면접 후기

purplechip — Sat, 12 Dec 2020 10:14:47 +0900

이전 글은 아래 포스팅을 참고바랍니다.

2020/11/12 - [취업] - 2020 하반기 금융결제원 공채 전산직 1차 면접 후기

운이 좋았다. 더 정확히 말하자면 1차 면접에서 생각보다 많은 인원을 합격시켜 내가 포함된 것 같다.

1차 면접 6배수, 2차 면접 3배수라 추정된다. 그렇기에 내가 그동안 붙었던 것 같다.

2차면접은 임원면접이다. 예전 임원면접은 느낌이란 것이 상당히 중요했던 것으로 여겨졌고 실제로 결과도 그러했다고 생각한다. 일례로 어떤 블로그에서 본 글이었는데, 다대다 면접에서 "성실하신가요?"란 단 하나의 질문에 "네" 라는 단 하나의 답변만을 했던 지원자가 붙었다고 한다 (물론 그러면 안된다). 면접관 입장에서는 애초에 낙이라고 생각했던 지원자가 단순명료한 대답을 한 것에 대해 흥미를 보이고 호기심이 생겨 합격시켰다는 것이다. 이처럼 과거의 임원면접은 정성적인 성격을 띄고 있었다.

그러나 금융결제원의 임원면접은 정량적이라는 느낌이 강하게 들었다. 면접위원들은 임원 뿐만이 아니라 외부위원과 인사팀장을 더한 7명으로 구성되어 있었고 질문은 일관성을 확인하는 질문, 인성적인 부분을 검토하는 질문 등으로 이루어져 있었다. 특히 일관성을 중요하게 여기는 것 같다.

질문은 철저하게 자기소개서 및 질문에 대한 자신의 대답을 기반으로 나온다. 긴장했던 것도 있고 생각지도 못한 질문을 받았기에 면접은 철저하게 망했다.

그리고 결과가 나왔다. 이번에도 "그러나 그것이 실제로 일어났습니다" 같은 일을 바랐지만 현실은 더더욱 냉정하고 엄격하단 사실을 다시 한번 깨달았다. 준비가 되어있지 않은 사람에게 기회는 주어지지 않는다. 초심자의 행운은 여기까지였다.

금결원 취업을 준비하며 깨달은 사실 중 하나는 금융결제원의 채용 정보가 인터넷에서 찾아볼 수 없을 정도로 드물다는 것이었다. 있다고 해도 2007년 안팎의 정보니 크게 와닿질 않는다. 그러던 와중 금결원 지원자 오픈채팅방에서 필기시험 기출문제 정보를 선배들에게 받은 지원자들끼리 정보를 공유하는 현상을 바라보며 사회에 진출하기도 전에 사회의 격차를 느끼는 아이러니함을 맛보았다. 그래서 누군가에게 조금이나마 정보가 되길 바라는 마음에서 이 글을 쓴다. 이번 채용 시즌에서 많은 기업에 지원했지만 전부 후기를 작성하지 않는 이유가 바로 이것이다. 다른 것들은 어느 정도 정보를 찾을 수 있었다.

마지막으로 억울한 점 하나. 채용 검진은 되도록 합격자 발표 후 시행했음 하는 바람이다. 피뽑탈은 너무나 가슴이 아프다.

2020 하반기 금융결제원 공채 전산직 1차 면접 후기

purplechip — Thu, 12 Nov 2020 03:03:46 +0900

이 글은 아래 포스팅에서 연결되는 글이다.

2020/10/10 - [취업] - 2020 하반기 금융결제원 공채 전산직 필기 후기

운이 좋아 필기 시험을 합격해 1차 면접까지 보고 왔다. 대체 어떤 부분에서 타 지원자에 비해 우위를 점했는 지 짐작이 안가지만 나에겐 정말 좋은 기회가 주어졌다 생각한다.

금융결제원의 전형 절차 내 디테일한 진행 방식은 매년 조금씩 달라지고 있는 듯 하다. 면접의 경우도 블로그에서 알아본 정보(매우 적은 표본이지만)와 다른 방식으로 진행되었다. 토론면접과 일반면접 총 두 가지 면접을 진행했다.

토론면접

A, B조가 나뉘어 하나의 계약을 양사의 입장에서 협상하는 방식으로 진행되었다. 계약 관련된 문서를 읽고 조별로 전략을 토의한 후 단가 등 각 부분에 대해 양사가 협상을 진행한다. 협상이 이루어지면 점수를 얻는 방식이라 협상이 원활하게 합의가 되도록 조율하는 것이 중요하게 작용하지 않을까 하는 생각이다. 이런 토론 면접은 처음이라 당황스러웠는데, 두 가지 측면에서 평가가 가능할 것 같다. 첫 번째는 논리적인 근거를 제시할 수 있는 논리력, 두 번째는 협상을 이루기 위한 조율 또는 협의 능력이다. 난 두 번째에 비중을 좀 더 두었는데 평가 기준이 어떤 지는 모르기에 잘한 지는 모르겠다.

일반면접

먼저 전산직의 경우 코딩테스트를 본다. 그러나 이번 코딩테스트는 못푸는 사람이 없을 정도로 난이도가 상당히 쉬웠기에 변별력은 떨어졌다. 이러한 조건에서 중요한 것은 얼마나 깔끔한 코드를 구현하는가일 것이다. 면접은 다대일 면접으로 코딩에 대한 설명, 그리고 자소서 기반 설명을 위주로 진행된다고 면접 대기 시간에 공지받았지만 내 경우 실제 면접에서 자소서에 관한 질문은 크게 받지 않았다. 오히려 인성검사를 기반으로 한 결과에서 내 특성들이 다양한 상황에서 어떻게 발현되는지를 중점적으로 물어보는 인성면접의 느낌이 강했다. 직무에 대한 면접은 크게 이루어지지 않아 그 점이 조금 아쉬웠다.

결과적으로 이번에도 크게 기대는 하지 않는다. 너무 어려웠고 다른 것들에 집중해야겠다.

+ 설마 붙을까 싶었다. 그러나 그것이 또 일어났습니다.. 다음 과정은 아래 포스팅에서 확인할 수 있다. 과연 이 길의 끝은 어떻게 될 것인가?

2020/12/12 - [취업] - 2020 하반기 금융결제원 공채 전산직 2차 면접 후기

+ 채용시즌이라 그런지 많은 분들께서 댓글로 코딩테스트 관련 문의를 하고 계신다. 자세히 기술은 못하지만, 체감 난이도는 프로그래머스 1.5 레벨 정도가 아니었나 싶다. 그러나 이후에도 이 정도의 난이도로 출제되겠단 단정은 안했으면 좋겠다. 난이도를 조절하는 과정에서 극단적인 난이도가 출제됐을 뿐이고 2021년에는 문제가 훨씬 더 어려워질 것이라 생각한다.

2020 하반기 NH투자증권 공채 IT직무 필기시험 후기

purplechip — Thu, 12 Nov 2020 01:36:23 +0900

잠도 안오고 이전에 봤던 NH투자증권 공채 필기시험에 대한 후기를 작성한다.

농협은 공개채용 시즌 모든 계열사가 동시에 필기 시험을 보는 방식으로 진행된다. NH투자증권을 비롯한 여러 계열사가 같은 장소에서 동시에 시험을 봤다. 다만 시험 내용은 계열사마다 논술이 추가되는 등 약간씩 다르다.

NH투자증권의 경우 인성평가, 직무능력평가(PSAT), 직무상식평가로 구성되었다. 인성평가에서 특이한 점은 서류 지원을 하면서 온라인으로도 본다는 점이다. 필기시험의 인성평가와 서류 접수의 인성평가가 크로스체크되어 신뢰도를 판단하고 성향을 판단하는 지는 물음부호가 붙지만 웬만하면 일관성있게 해주는 것이 좋아보인다.

직무능력평가

직무능력평가의 난이도는 상당히 어려운 편이었다. 이전 금융결제원의 필기시험 후기와 비슷하게 의사소통 영역 문제 다수, 수리 자료해석 문제 다수가 나왔다. 특히 글을 읽고 정보를 파악하는 능력을 중요시여기는 것처럼 느껴졌는데 HTML의 태그 관련 설명 글을 제시하고 HTML을 작성하거나 틀린 부분을 찾는 문제, 통계 언어 R의 일부 함수에 대한 글을 제시하고 이에 대한 사용법을 묻는 문제 등 참신하다면 참신했다.

직무상식평가

뒤통수를 세게 얻어맞은 느낌이다. 분명히 데이터베이스, 전자계산기 구조 등의 문제가 출제된다고 홈페이지에 명시돼 있었는데 딥러닝, 블록체인에 관한 문제가 거의 대부분이었다. 또한 농협의 경우 필기시험은 항상 농업 이해, 농협 추진 사업 등의 문제가 출제된다 명시했지만 3문제밖에 안나왔다. 그것도 협동조합의 정말 디테일한 역사(가령 미국의 어떤 협동조합이 최초고 이는 실패로 끝났다 등), 협동조합의 이해를 묻는 문제, 대한민국의 농업운동(여러가지가 있다)을 순서대로 기재하라는 등 문제가 출제되었다.

준비했던 것과 영 딴판의 문제들이라 많이 애를 먹었고 아마 탈락이 아닐까 싶다. 정말 어려웠다. 또한 삼성의 GSAT와 같이 오답 선택 시 감점이 존재하였다. 운이 좋다면 붙겠지..

키움증권 Open API+ 구현 상 issue 해결 | python

purplechip — Sat, 24 Oct 2020 23:34:43 +0900

일봉 데이터를 DB화하는 과정을 구현하며 여러 issue를 겪었다. 키움증권 Open API+는 사용 메뉴얼이 있지만 반환 데이터나, 제약사항에 대한 자세한 내용은 기술되어 있지 않다. 이러한 문제들은 키움 Open API+ 고객문의 게시판에서 질의를 통해 해결해야 한다. 나 역시 고객 문의 게시판과 사용 메뉴얼을 참고해가며 당면한 여러 issue를 해결하였고 이 글에서는 그 과정들을 게시하겠다.

1. 조회데이터 부호

가끔씩 몇몇 데이터를 수신받으면 '--4500' 혹은 '+-4500'와 같은 꼴을 가진다. 이는 키움 HTS나 MTS에서 매수/매도 여부와 직전대비 증감 여부를 동시에 표현하기 위해 사용하는 부호 방법이다. 과 고객문의 게시판에서 종종 이런 질문들이 올라오며 이에 대한 답은 다음과 같다.

해당 부호의 의미는 첫번째 부호가 색상(빨강/파랑)표시이고, 두번째 부호는 등락을 의미합니다.
가령 +-4000 이면 해당데이터를 화면상 빨강색으로 표시하라는 의미이고 전일/전틱 대비 하락 이라는 의미 입니다.
이러한 부호값은 영웅문4 HTS, 영웅문S MTS 등의 매체들에서 사용되고 있는 값이며
OpenAPI 역시 동일한 포맷의 데이터를 수신하고 가공없이 전달하는 것을 원칙으로 하기에 그대로 전달되고 있습니다.
불필요한 경우 Trim 하거나 Left, Right 등의 문자열 편집함수로 짤라내어 사용하셔도 되겠습니다.

개발단계에서 사용하시는 TR의 데이터들을 영웅문4 HTS 와 비교/검증 하며 진행하시기 바랍니다.

이는 요청 OPT에 따라 조금씩 다른 의미를 가진다. 일봉같은 가격의 경우 음수 값이 없으므로 아예 Trim 하는 것도 좋은 방법이지만 기관투자자별 거래량의 경우 음수가 의미를 가지므로 부호를 잘 살려주어야 한다. 통상적으로 거래량은 빨간색이 매수, 파란색이 매도를 의미하므로 첫 번째 부호에 따라 값을 결정하면 된다. 그 외 다른 OPT에 데이터를 수신받을 때는 TR 데이터를 영웅문4 HTS와 비교하거나 키움증권 Open API+ 고객문의 게시판을 이용하는 수 밖에 없겠다.

2. Zip Error 14

multiprocessing을 사용하다보니 다음과 같은 에러를 발견하였다.

[그림 1] multiprocessing 사용 시 에러

이에 대해 역시 고객문의 게시판에 문의한 결과 OPT 계열의 동일한 TR 서비스를 여러 프로세스가 반복적으로 요청할 경우 해당 오류가 발생할 가능성이 높다는 답변을 얻었다. multiprocessing을 사용해서 일봉, 거래량 데이터를 업데이트 하던 방식은 각각의 프로세스가 여러 기업 코드를 할당받아 일봉, 거래량 데이터를 한번에 계산하는 방식이라 에러가 발생한 것이다. 이에 따라 DB 업데이트를 위해서는 프로세스를 최대 2개밖에 사용하지 못하는 제약이 생김을 알게 되었다. (일봉, 기관투자자별 거래량 OPT이므로 2개)

3. 최적화

(1) Pandas 최적화

아래 링크에서와 같이 vectorization, apply 함수 사용해서 DataFrame 최적화, DB 반영해주었다.

2020/08/25 - [파이썬/이론] - [Python] pandas DataFrame 최적화 (삽입, 생성, 반복, 문자열)

(2) GetCommDataEx 사용

메뉴얼을 보면 TR 조회 요청에 대해 데이터를 얻는 함수가 두 가지가 있다. GetCommData 와 GetCommDataEx 인데 후자의 함수는 차트 데이터를 대량으로 받는 경우만 사용이 가능하다. GetCommData가 따로 원하는 속성의 데이터를 함수의 parameter로 받아 그에 해당하는 값을 리턴한다면, GetCommDataEx는 한번에 모든 속성, 모든 Row에 대한 값을 리턴한다. 코드로 보면 다음과 같다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

def _get_comm_data(self, tr_code, rq_name, idx, item):
    data = self.GetCommData(tr_code, rq_name, idx, item)
    return data.strip()
 
 
def _get_comm_data_ex(self, tr_code, rq_name):
    data = self.GetCommDataEx(tr_code, rq_name)
    return data
 
 
# GetCommData 사용
data = []
data_cnt = self._get_repeat_cnt(tr_code, rq_name)
    for i in range(data_cnt):
        date = self._get_comm_data(tr_code, rq_name, i, "일자")
        fore = self._get_comm_data(tr_code, rq_name, i, "외국인투자자")
        inst = self._get_comm_data(tr_code, rq_name, i, "기관계")
        indi = self._get_comm_data(tr_code, rq_name, i, "개인투자자")
        temp = [date, '1', '2', '3', indi, fore, inst]
        data.append(temp)
 
 
# GetCommDataEx 사용
data = self._get_comm_data_ex(tr_code, rq_name)

cs

보면 코드도 간단해질 뿐 아니라 속도도 월등하게 빠르다. 내 경우 삼성전자 모든 일봉 데이터 기준, 약 11,000 튜플 기준 5초 → 3.5초로 시간 단축을 할 수 있었다. (물론 TR 조회 대기 시간까지 고려된 것이다.)

최종적으로 초기 최적화 전 15.99초에서 5.76초로 단축되었다. 최적화의 힘을 다시 느낀다.

2020 하반기 우리FIS 공채 역량평가 후기

purplechip — Wed, 21 Oct 2020 23:46:19 +0900

우리FIS 역량평가는 코딩테스트, 인/적성, IT상식을 한번에 테스트하기 때문에 강행군이었다. 오전엔 인/적성을 봤고, 오후엔 특이한 방식이지만 코딩테스트/IT상식을 한번에 봤다.

1. 인/적성

인성평가는 생략한다. SKCT와 정말 비슷하게 나왔다. 언어, 수리/자료해석, 상황판단 영역이 나왔다. 시간은 못재봤지만 아마 각각 20문항 20분 / 20문항 20분 / 25문항 15분 이었을 것으로 추정된다. 이 링크를 근거로 추정한 시간인데 동원 그룹 인적성에 대한 글이지만 문항과 유형이 같고 시간이 비슷한 느낌이 들었기 때문이다. 아마 난이도도 비슷할 것으로 예상된다. (한 기업에서 수주받아 문제 출제하는 거 같다)

언어는 예상보다 짧은 지문의 문제가 많이 출제되었고 수리/자료해석의 경우 수리 문제의 비중이 절반 이상을 차지할 정도로 많다. SKCT와 정말 똑같은 느낌이다. 상황판단은 검색하면 자료가 많이 나올테니 참고하면 된다.

2. 코딩테스트/IT상식

프로그래머스에서 둘 다 진행되었다. IT상식은 객관식으로 프로그래머스 사이트에서 이런 형식도 지원하는 지는 처음 알았다. 어쨌든 20개 정도의 문제 중 SQL 위주의 문제가 매우 다수 출현했다. 시간은 2시간 30분을 주었고 IT 객관식 문제, 4개의 코딩 문제가 주어지는데 특이한 점은 4개의 코딩 문제 중 3개에 3개 언어를 선택해서 각각 풀어야 한다. 언어는 C, Java, Python, SQL이 주어진다. 문제에 언어가 귀속된 형태는 아니다. 자기가 하고싶은 문제에 하고싶은 언어를 적용하면 된다.

SQL을 제외한 나머지는 일반 코딩테스트와 똑같고 난 SQL이 트리거나 프로시저를 짜는 형식일 줄 알았는데 단순히 질의문 생성이었다.. 앞으로의 SQL 테스트는 모두 쿼리라 생각하면 될 것 같다.

2020 하반기 금융결제원 공채 전산직 필기 후기

purplechip — Sat, 10 Oct 2020 20:09:49 +0900

2021 금융결제원 전산직 필기시험을 보고 왔다.

생각보다 문제는 쉬웠으나, 그것 이상으로 내가 모르는 것이 많다는 것을 느끼며 탈락을 예감하고 있다. 금융결제원 전산직 필기의 경우 인터넷에 정보가 매우 없다. 이 글에서나마 형식을 파악하고 참고하길 바란다. 물론 2021년도 신입직원 공채 기준이기 때문에 추후 변경될 여지는 다분하긴 하다. 금융결제원 홈페이지에서 안내하고 있는 내용은 다음과 같다.

[그림 1] 2021년도 금융결제원 신입사원 공개채용 필기전형 안내

시간은 잘 기억이 안나는데 전산학 1시간 30분, 직무역량평가 1시간인 걸로 기억한다.

1. 전산학

객관식 50문제, 주관식 서술형 6문제 정도 출제된 것으로 기억한다. 문제는 전산학 전반을 다룬다. OS, 컴퓨터구조, SW설계, 보안 등 정보처리기사 정도 혹은 그 이상의 문제들이 출제되었다. C 관련 문제가 많이 나왔으므로 C의 기본적인 부분을 숙지하는 것이 좋아 보인다.

2. 직무역량평가

NCS 문제집 중 의사소통 영역에 해당하는 문제가 절반, 나머지 절반 중 1/5가 주사위나 입체도형 전개도, 1/5가 수열 파악, 3/5이 시사상식으로 기억한다. 의사소통 영역 문제는 NCS를 풀어본 사람은 알 것이다. 가령 유연근무제에 대한 개조식 글을 읽고 옳은 설명이나 틀린 설명을 찾는 문제이다. 하여튼 정보를 찾아내어 보기와 비교하는 문제라 생각하면 된다.

개인적으로 NCS를 풀어보면서 위와 같은 문제는 출제되지 않겠지란 안일한 생각을 가졌다가 당혹스러웠다. 아마 탈락이 확실하니 비우고 다른 걸 준비해야겠다.

에이 합격이 될까 싶었다. 그러나 그것이 실제로 일어났습니다.. 이에 대한 다음 포스팅은 아래 링크를 참고바란다.

2020/11/12 - [취업] - 2020 하반기 금융결제원 공채 전산직 1차 면접 후기

Python DataFrame 최대 scalar 값의 index, column 구하기

purplechip — Mon, 31 Aug 2020 12:56:03 +0900

pandas는 idxmax(), idxmin()이란 method를 제공한다. parameter axis에 따라(column 혹은 row 기준에 따라) 최대값의 index, column Series를 반환하는 기능을 가진다. 많이 사용하진 않겠지만 DataFrame의 2차원 데이터 중 가장 큰 스칼라 값 하나의 index와 column이 궁금한 경우가 있다. 이는 간단하게 idxmax()를 두 번 적용하는 것으로 해결할 수 있다. 아래 예제 코드를 보자.

>>> import pandas as pd
>>> import numpy as np
 
>>> df = pd.DataFrame(np.array([[5,2,4],[6,1,5],[7,1,3]]),
...                   columns=['a', 'b', 'c'])
>>> df
   a  b  c
0  5  2  4
1  6  1  5
2  7  1  3
 
>>> idx = df.idxmax()
>>> idx
a    2
b    0
c    1
dtype: int64
 
>>> sr = pd.Series([df.at[idx[i], i] for i in idx.index],
...                index=idx.index)
>>> sr
a    7
b    2
c    5
dtype: int64
 
>>> idx_s = sr.idxmax()
>>> idx_s
'a'
 
>>> print(f"max : df.at[{idx[idx_s]}, {idx_s}] = {sr[idx_s]}")
max : df.at[2, a] = 7
Colored by Color Scripter

cs

2차원의 DataFrame에서 idxmax() 메소드를 사용하여 각 column마다 가장 큰 값의 index를 얻는다. (변수명 idx)
이를 바탕으로 각 column마다 최대값을 가지는 Series를 생성한다. (변수명 sr)
Series에서 idxmax() 메소드를 사용하여 최대 column 값을 얻는다. (변수명 idx_s)
최대값의 column은 idx_s이고 index는 idx[idx_s]임을 알 수 있으므로 값까지 추출해낼 수 있다. df.at[idx[idx_s], idx] 혹은 sr[idx_s]

최소값의 column과 index를 구하는 방법 역시 idxmin()을 사용하여 동일하게 구하면 된다.

Python multiprocessing에서 logging 사용하기 (QueueHandler)

purplechip — Sun, 30 Aug 2020 23:42:05 +0900

logging은 파이썬에서 자체적으로 제공하는 로그 패키지다. 여러가지 기능을 제공하므로 굳이 다른 패키지를 찾지 않더라도 유용하게 사용이 가능하지만 멀티프로세스 환경을 자체적으로 보장하지 못하는 문제를 가지고 있다. (멀티 쓰레드에서는 안전하게 동작한다.) logging Cookbook에서는 이러한 점을 언급하며 예제 코드를 제공하고 있으며 이를 참고하여 내가 사용할 클래스를 구현하였다.

QueueHandler

logging 패키지는 QueueHandler를 제공한다. QueueHandler란 말 그대로 Queue에 logging 할 수 있게 구현된 Handler다. 이 자체는 FileHandler, StreamHandler와 다르게 log 기록 시 파일이나 표준 출력에 기록되지 않고 Queue에 출력이 저장된다. 그 후 위 Handler에서 Queue에 저장된 log를 꺼내 기록하는 과정으로 logging을 할 수 있다. 만약 multiprocess라면 여러 프로세스가 다중 생산자로 Queue에 log 내역을 저장하고, 하나의 쓰레드 혹은 프로세스가 Queue에서 log를 get() 해서 기록하는 역할을 수행하는 것이다. 아래 그림은 구현된 Class를 도식화한 것이다.

[그림 1. QueueHandler logging 사용 구조]

구현 코드

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147

import logging
import logging.handlers
import multiprocessing
from threading import Thread
from random import choice, random
import time
import platform
'''
Class Log performs logger configuration, creation, multiprocess listener.
'''
class Log():
    def __init__(self):
        self.th = None
 
    def get_logger(self, name):
        return logging.getLogger(name)
 
    def listener_start(self, file_path, name, queue):
        self.th = Thread(target=self._proc_log_queue, args=(file_path, name, queue))
        self.th.start()
 
    def listener_end(self, queue):
        queue.put(None)
        self.th.join()
        print('log listener end...')
 
    def _proc_log_queue(self, file_path, name, queue):
        self.config_log(file_path, name)
        logger = self.get_logger(name)
        while True:
            try:
                record = queue.get()
                if record is None:
                    break
                logger.handle(record)
            except Exception:
                import sys, traceback
                print('listener problem', file=sys.stderr)
                traceback.print_exc(file=sys.stderr)
 
    def config_queue_log(self, queue, name):
        '''
        if you use multiprocess logging,
        call this in multiprocess as logging producer.
        logging consumer function is [self.listener_start] and [self.listener_end]
        it returns logger and you can use this logger to log
        '''
        qh = logging.handlers.QueueHandler(queue)
        logger = logging.getLogger(name)
        logger.setLevel(logging.DEBUG)
        logger.addHandler(qh)
        return logger
 
    def config_log(self, file_path, name):
        '''
        it returns FileHandler and StreamHandler logger
        if you do not need to use multiprocess logging,
        just call this function and use returned logger.
        '''
        # err file handler
        fh_err = logging.handlers.RotatingFileHandler(file_path + '_error.log', 'a', 300, 10)
        fh_err.setLevel(logging.WARNING)
        # file handler
        fh_dbg = logging.handlers.RotatingFileHandler(file_path + '_debug.log', 'a', 300, 10)
        fh_dbg.setLevel(logging.DEBUG)
        # console handler
        sh = logging.StreamHandler()
        sh.setLevel(logging.INFO)
        # logging format setting
        ff = logging.Formatter('''[%(asctime)s] %(levelname)s : %(message)s''')
        sf = logging.Formatter('''[%(levelname)s] %(message)s''')
        fh_err.setFormatter(ff)
        fh_dbg.setFormatter(ff)
        sh.setFormatter(sf)
        if platform.system() == 'Windows':
            import msvcrt
            import win32api
            import win32con
            win32api.SetHandleInformation(msvcrt.get_osfhandle(fh_dbg.stream.fileno()),
                                          win32con.HANDLE_FLAG_INHERIT, 0)
            win32api.SetHandleInformation(msvcrt.get_osfhandle(fh_err.stream.fileno()),
                                          win32con.HANDLE_FLAG_INHERIT, 0)
        # create logger, assign handler
        logger = logging.getLogger(name)
        logger.setLevel(logging.DEBUG)
        logger.addHandler(fh_err)
        logger.addHandler(fh_dbg)
        logger.addHandler(sh)
        return logger
 
'''
The code below tests the multiprocess logging.
Main process and child process produce log messasge. (put message into queue.) 
(random choice in variable LEVEL, MESSAGES)
Listener process produced by main process consume log message. (write log message in stdout and file)
'''
LEVELS = [logging.DEBUG, logging.INFO, logging.WARNING,
          logging.ERROR, logging.CRITICAL]
MESSAGES = ['Random message #1', 
            'Random message #2',
            'Random message #3',
           ]
 
 
def worker(queue):
    # multi process log producer start
    logger = Log().config_queue_log(queue, 'mp')
    name = multiprocessing.current_process().name
    print('Worker started: %s' % name)
    for i in range(10):
        time.sleep(random())
        level = choice(LEVELS)
        message = choice(MESSAGES)
        logger.log(level, f"{name} - {message}")
    print('Worker finished: %s' % name)
    # multi process log producer end
 
 
def main():
    queue = multiprocessing.Queue(-1)
    listener = Log()
    listener.listener_start('test', 'listener', queue)  # log consumer thread start
    
    workers = []
    for i in range(10):  # multiprocess loop
        w = multiprocessing.Process(target=worker, args=(queue,))
        workers.append(w)
        w.start()
    # main process log producer start
    logger = Log().config_queue_log(queue, 'mp')
    name = multiprocessing.current_process().name
    print('Worker started: %s' % name)
    for i in range(10):
        time.sleep(random())
        level = choice(LEVELS)
        message = choice(MESSAGES)
        logger.log(level, f"{name} - {message}")
    print('Worker finished: %s' % name)
    # main process log producer end
    for w in workers:
        w.join()
    listener.listener_end(queue)  # log consumer thread end
 
 
if __name__ == '__main__':
    main()
 
Colored by Color Scripter

cs

line 18 - 39 : listener_start() 함수는 _proc_log_queue() 를 Thread로 실행시킨다. _proc_log_queue 는 Queue에서 log data를 get()하고 logger.handle()을 통해 기록하는 동작을 계속 반복한다. Queue.get() 함수는 timeout parameter가 없을 경우 Queue에 데이터가 없으면 블록된다(waiting 상태). get()한 데이터가 None인 경우 종료된다. 종료는 Queue에 None 데이터를 삽입하는 listener_end() 함수를 통해 이루어진다.
line 41 - 52 : QueueHandler를 할당받은 logger를 선언하고 반환한다.
line 54 - 90 : FileHandler와 StreamHandler를 할당받은 logger를 선언하고 반환한다. 만약 multiprocessing을 사용하지 않는다면 이 logger만 사용하여 log를 수행할 수 있다.
line 75 - 82 : 위 코드에서는 config_log()가 _proc_log_queue()에서만 사용된다. 하지만 단일 프로세스를 사용하면서 config_log()를 사용하다가 multiprocessing을 사용하며 listener_start()를 호출해 _proc_log_queue()가 호출된다면 단일 프로세스와 listener_start()를 사용한 쓰레드(코드에서는 Thread()지만 Process()로 사용할 수도 있다.)가 동일한 log file을 참조하게 된다. 이에 따라 Handler가 log file의 이름을 자동적으로 바꿔줄 때 윈도우 운영체제를 사용할 경우 에러가 발생하는데 이에 대한 참조를 허용하는 코드이다.
line 91 - : logging level과 message를 무작위로 선택하여 로그를 기록하는 코드다. 10개의 child process와 main process에서 QueueHandler로 Queue에 log를 기록하고 listener.start()를 통해 Queue에서 log 내역을 받아 file 및 stdout 출력을 하는 Thread를 생성한다.

logging 패키지를 사용하며 굳이 logger의 이름을 정의할 필요가 있을까란 의문을 잠깐 했었다. logging 패키지는 한 번 logger의 name을 할당하여 생성되면 메모리 공간에 남아 프로세스 내에서 언제든 호출할 경우 같은 logger를 획득하게 된다. 따라서 실제로 logging 패키지를 사용하면서 다양한 Handler나 다양한 조건에 따른 log 출력을 원할 경우 각기 다른 logger 설정이 필요하므로 name을 통해 logger를 쉽게 할당받는 방법은 아주 효율적이라 생각한다.

참고

logging Cookbook

https://docs.python.org/ko/3/howto/logging-cookbook.html

[Python] pandas DataFrame 최적화 (삽입, 생성, 반복, 문자열)

purplechip — Tue, 25 Aug 2020 01:27:04 +0900

pandas DataFrame은 데이터 분석에 있어 매우 강력한 도구이다. 그러나 그만큼 올바른 사용법이 필요하고 잘못된 사용법을 적용할 경우 매우 답답한 프로그램을 경험하게 된다. 그만큼 DataFrame 최적화는 프로그램의 효율성을 위해 어느정도 필요하다. 이번 포스팅에서는 pandas DataFrame을 최적화하는 방법을 알아본다.

반복 최적화

DataFrame에서 row 값을 사용한 어떤 수행을 반복한다고 하자. 이 때 고려해야 할 순서는 다음과 같다.

벡터화 (vectorization)
pandas apply 사용 (Cython에서 실행)
itertuples() 사용
index 사용(속도 df.at() > df.loc())
iterrows() 사용
len 단순 반복

이에 대한 자세한 설명은 "판다스 코드 속도 최적화를 위한 초보자 안내서"에서 자세히 소개한다. 그렇다면 '대체 왜 pandas 최적화를 사용하는 것이 속도 절감이 되는 것일까?' 하는 의문을 갖지 않을 수 없다. 그 이유는 3가지 정도로 압축할 수 있는데 파이썬 자료구조의 런타임 오버헤드 제거, C 배열 캐싱, SIMD이다.

파이썬은 동적으로 프로그램이 실행되는 인터프리터 언어이기 때문에 파이썬 내 list 등 배열의 각 요소에 대해 참조 시 런타임 오버헤드가 있다. 가령 list의 경우 슬라이싱 등을 판단해야 하기 때문에 인덱스에 들어가는 값을 decode 해야한다. 하지만 pandas는 C언어 array 기반이기 때문에 처음 참조 시만 오버헤드가 생기며 이 차이는 큰 차이를 만들어낸다. 반복의 모든 부분에서 오버헤드가 생기는 것과 반복이 시작될 때만 오버헤드가 발생하는 것을 고려하면 2n과 n의 차이만큼 속도 변화가 있음을 알 수 있다. 또한 C array라는 차이가 또 다른 부분에서 적용이 된다. 캐시 활용 측면에서도 C array를 반복하는 것이 캐시 친화적이다. (물론 DataFrame을 각 요소에 대해 참조 시간이 부여될 수 있도록 코딩할 수 있다. 이런 코딩 방식은 DataFrame을 사용할 때 반드시 지양해야 한다.)

추가적으로 SIMD 명령어를 통해 벡터화가 가능하다. SIMD란 Single Instruction Multiple Data의 약자로 하나의 CPU 명령어로 다수의 데이터를 한번에 처리하는 방식을 의미한다. 아래 그림이 SIMD를 도식화한 것이다.

[그림 1. SIMD 동작구조 (출처 : Wikipedia)]

쉽게 C array 배열이 있다고 보면 그 배열 자체를 한꺼번에 계산한다고 생각하면 된다. 이렇게 되면 DataFrame 내 row 갯수만큼 명령어가 반복실행되는 것이 크게 한 번의 명령어 실행으로 해결되는 것이다. 당연히 속도면에서 큰 체감이 생길 수 밖에 없다.

문자열 최적화

C array가 문자열 함수에도 적용이 될까 싶은 의문이 있는데 pandas에서는 그 고민을 말끔히 날려준다. Series 자료구조는 str() 이라는 문자열 벡터화 함수를 제공한다. 이에 대한 내용은 pandas document에서 자세히 확인 가능하다. regular expression 사용도 가능하며 다재다능한 여러 기능을 가지고 있다. 위 링크 글에서는 실수 연산을 예로 들고 있으므로 한번 위에 제시된 여러 반복 처리 방식을 문자열 column에 적용하여 속도 측정을 해보자. 코드는 다음과 같다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

from pandas import DataFrame 
import pandas
import re
import string
import random
 
alphabet = string.ascii_uppercase
 
def str_cat(s1, s2):
    s1 = s1.replace('-', '')
    return s1.join(s2)
 
list1 = [random.choice(alphabet) + '-' for _ in range(100000)]
list2 = [random.choice(alphabet) for _ in range(100000)]
 
df = DataFrame(zip(list1, list2), columns=['s1', 's2'])
 
## len을 이용한 반복
%%timeit
s3_list = []
for idx in range(len(df)):
    s3 = str_cat(df.iloc[idx]['s1'], df.iloc[idx]['s2'])
    s3_list.append(s3)
df['s3'] = s3_list
 
## iterrow을 이용한 반복
%%timeit
s3_list = []
for idx, row in df.iterrows():
    s3 = str_cat(row['s1'], row['s2'])
    s3_list.append(s3)
df['s3'] = s3_list
 
## index loc를 이용한 반복
%%timeit
s3_list = []
for idx in df.index:
    s3 = str_cat(df.loc[idx, 's1'], df.loc[idx, 's2'])
    s3_list.append(s3)
df['s3'] = s3_list
 
## index at를 이용한 반복
%%timeit
s3_list = []
for idx in df.index:
    s3 = str_cat(df.at[idx, 's1'], df.at[idx, 's2'])
    s3_list.append(s3)
df['s3'] = s3_list
 
## itertuple을 이용한 반복
%%timeit
s3_list = []
for row in df.itertuples():
    s3 = str_cat(getattr(row, 's1'), getattr(row, 's2'))
    s3_list.append(s3)
df['s3'] = s3_list
 
## apply 함수 사용
%%timeit
df['s3'] = df.apply(lambda row: str_cat(row['s1'], row['s2']), axis=1)
 
## str 함수 사용 (벡터화)
%%timeit
df['s3'] = df['s1'].str.replace('-', '').str.cat(df['s2'])

cs

위 코드는 's1'에서 '-'를 제거한 후 's2'를 cat한 결과를 's3'에 할당하는 코드들이다. df 를 출력하면 다음과 같다.

>>> df
       s1 s2  s3
0      D-  M  DM
1      Q-  J  QJ
2      P-  V  PV
3      G-  K  GK
4      V-  U  VU
...    .. ..  ..
99995  B-  C  BC
99996  C-  L  CL
99997  I-  K  IK
99998  A-  T  AT
99999  B-  D  BD
 
[100000 rows x 3 columns]

cs

코드 설명을 하면 %%timeit 은 ipython(jupyter, spyder 등)에서 셀의 실행 시간을 측정해주는 기능이다. 또한 df.loc 함수를 df.loc[idx][col], df.loc[idx, col] 두 가지로 표현할 수 있는데 후자가 속도가 월등히 빠른 대비 전자는 len 사용과 비슷한 수준임을 확인했다. 전자는 두 번 참조라면 후자는 한 번에 위치를 정해주기 때문으로 추측한다. 그리고 df.loc이 슬라이싱 기능까지 있는거에 비해 df.at은 scalar 참조만 가능하므로 속도가 훨씬 빠르다. 요소만 참조하는 코드라면 df.at을 사용하는 것이 효율적이다. 결과를 정리하면 아래와 같다.

방식	소요시간	직전 대비 증가율
len 단순 반복 iterrows() 사용 apply 함수 index loc 사용 index at 사용 itertuples() 사용 벡터화 (str 함수)	13.2 s ± 85.8 ms per loop 7.19 s ± 43.8 ms per loop 1.98 s ± 45.5 ms per loop 1.22 s ± 38.2 ms per loop 754 ms ± 34 ms per loop 103 ms ± 1.25 ms per loop 48.8 ms ± 672 µs per loop	0 1.84x 3.63x 1.62x 1.61x 7.32x 2.11x

결과에서 apply 함수를 사용한 경우가 index, itertuples()를 사용한 경우보다 느렸는데 이는 문자열을 다루다보니 apply 가 Cython에서 동작하지 않은 것으로 추측된다. 최고 속도와 최저 속도는 약 270배가 차이난다.

삽입, 생성 최적화

DataFrame이 C array 기반이라는 사실을 알면 삽입, 생성에서 어떤 것이 더 빠른 속도를 가지는 것일지 예상이 갈 것이다. 결론부터 말하면 삽입보단 생성이 빠르다. 반복문을 통해 계속 배열 사이즈를 늘려가며 삽입하는 것보다 애초부터 큰 메모리 할당을 받아 생성하는 것이 C array 기준에서 빠를 수 밖에 없다. 이것 역시 코드를 직접 실행하면서 결과를 확인해보자. 비교 대상은 총 4개로 (1) append, (2) loc, (3) 미리 할당된 loc, (4) DataFrame 생성이다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

from pandas import DataFrame 
import string
import random
 
alphabet = string.ascii_uppercase
 
## append
%%timeit
df = DataFrame(columns=['s1', 's2'])
for i in range(1000):
    df.append([random.choice(alphabet), random.choice(alphabet)])
 
## loc 
%%timeit
df = DataFrame(columns=['s1', 's2'])
for i in range(1000):
    df.loc[i] = [random.choice(alphabet), random.choice(alphabet)]
 
## 정의된 loc
%%timeit
index = [i for i in range(1000)]
df = DataFrame(columns=['s1', 's2'], index=index)
for i in index:
    df.loc[i] = [random.choice(alphabet), random.choice(alphabet)
 
## DataFrame 생성
%%timeit
index = [i for i in range(1000)]
list1 = [[random.choice(alphabet), random.choice(alphabet)] for _ in range(1000)]
df = DataFrame(list1, columns=['s1', 's2'], index=index)

cs

원래 십만 번을 하려고 했지만 엄청 느릴 것 같아서 천 번만 반복시키기로 했다. 결과는 아래와 같다.

방식	소요시간	직전 대비 증가율
loc() append() 정의된 loc() DataFrame 생성	1.63 s ± 23.7 ms per loop 1.26 s ± 26.2 ms per loop 83.9 ms ± 1.31 ms per loop 1.69 ms ± 20.9 µs per loop	0 1.29x 15x 49.6x

엄청난 차이를 확인할 수 있다. 제일 빠른 방식과 느린 방식은 약 960배의 차이를 보인다. 작은 데이터는 상관없지만 큰 데이터를 DataFrame으로 만들 때 반드시 생성하는 것을 추천한다.

마치며

pandas는 정말 강력한 도구이지만, 잘못 사용할 경우 굼벵이같은 속도를 경험할 것이다. 코드 가독성 면으로나, 효율적인 면으로 보나 벡터화는 필수이다.

참고

DataFrame 반복 최적화

aldente0630.github.io/data-science/2018/08/05/a-beginners-guide-to-optimizing-pandas-code-for-speed.html

DataFrame 반복 최적화 (2)

www.it-swarm.dev/ko/python/pandas-iterrows%EC%97%90-%EC%84%B1%EB%8A%A5-%EB%AC%B8%EC%A0%9C%EA%B0%80-%EC%9E%88%EC%8A%B5%EB%8B%88%EA%B9%8C/1048592965/

DataFrame append, loc, iloc, 생성 속도 비교

stackoverflow.com/questions/10715965/add-one-row-to-pandas-dataframe/10716007#comment101375152_47979665

Pandas 최적화에 대한 이해

https://towardsdatascience.com/understanding-the-need-for-optimization-when-using-pandas-8ce23b83330c

Pandas str document

pandas.pydata.org/pandas-docs/stable/user_guide/text.html

[Python] tqdm을 사용하여 for 반복, 함수 진행률 출력하기

purplechip — Sun, 23 Aug 2020 14:11:02 +0900

실행 시간이 긴 프로그램의 경우 간혹 어느 정도 진행되었는지 확인할 필요가 있다. 물론 print()와 carriage return \r 을 사용해서 직접 구현할 수 있지만 계속 출력되는 line이 지저분해 보이기도 하고 매번 직접 구현한 것을 옮겨 사용하기도 애매하다. python에서는 tqdm 이라는 모듈을 사용하여 프로그램의 진행 상황을 깔끔하게 출력할 수 있다. ProgressBar라는 또 다른 모듈이 있긴 하지만 개발이 몇 년 전부터 이루어지지 않고 있으며 속도는 800ns/iter로 tqdm의 60ns/iter보다 느린 속도를 가진다.

tqdm 모듈에서 tqdm 클래스를 사용하며 parameter는 다음과 같다.

class tqdm():

""" Decorate an iterable object, returning an iterator which acts exactly like the original iterable, but prints a dynamically updating progressbar every time a value is requested. """

def __init__(self, iterable=None, desc=None, total=None, leave=True, file=None, ncols=None, mininterval=0.1, maxinterval=10.0, miniters=None, ascii=None, disable=False, unit='it', unit_scale=False, dynamic_ncols=False, smoothing=0.3, bar_format=None, initial=0, position=None, postfix=None, unit_divisor=1000):

iterable : 반복가능한 객체. range, list, tuple, dict 등을 넣을 수 있음.
desc : 진행바에 출력할 문구.
total : 진행바의 최대 수치. 값이 없으면 iterable의 length가 된다.
file : 어디에 출력할 지를 나타내는 값. 기본값은 std.err 이다.
unit : 반복의 단위를 나타내는 값.
unit_scale : 큰 단위에 대해 자동적으로 scale 적용할지 여부(Kilo, Mega, Giga 등)

주로 사용하는 것은 이 정도인 듯 하고 나머지는 tqdm document에서 확인하길 바란다. 사용 예제는 다음과 같다.

사용 예

from tqdm import tqdm, import time 은 생략한다.

1
2

for _ in tqdm(range(10), desc='tqdm test'):
    time.sleep(0.1)

cs

출력 :

tqdm test: 100%|██████████| 10/10 [00:01<00:00,  9.53it/s]

cs

Manual로 사용

1
2
3
4

with tqdm(total=100, desc='tqdm manual', unit='unit', ascii=True) as pbar:
    for _ in range(10):
        time.sleep(0.1)
        pbar.update(10)
Colored by Color Scripter

cs

출력 :

tqdm manual: 100%|##########| 100/100 [00:01<00:00, 95.65unit/s]

cs

Manual은 선언해서 사용하는 방법도 있다.

1
2
3
4
5

pbar = tqdm(total=1000**3, unit='unit', unit_scale=True)
for _ in range(20):
    time.sleep(0.1)
    pbar.update(1000**3 / 20)
pbar.close()
Colored by Color Scripter

cs

출력 :

100%|██████████| 1.00G/1.00G [00:02<00:00, 478Munit/s]

cs

참고

tqdm gitgub

https://github.com/tqdm/tqdm#latest-conda-release