행복한디벨로퍼

[ 100번의 도전(10) ] 운동&식단 일지(0613 - 가슴&삼두 운동) 

언제 벤치프레스 100을 칠수 있을까...

너무 욕심은 부리지말되 1RM씩이라도 무게를 늘려나가자

[ 100번의 도전(9) ] 운동&식단 일지(0612 - 등&팔운동)

데드리프트 무게를 많이 못쳤다 ㅠㅠ

1RM이라도 MAX에 도전해보자...

바벨로우도 고중량을 좀 더 섞어보자

[ 100번의 도전(8) ] 운동&식단 일지(0610 - 가슴운동)

[ 100번의 도전(7) ] 운동&식단 일지(0608 - 어깨운동)

어깨운동

바벨프레스

숄더프레스

사이드레터럴레이즈

바벨프론트레이즈

벤트오버레터럴레이즈

루틴을 바꿔서 여러부위에 자극을 더 주도록하자

[ 100번의 도전(6) ] 운동&식단 일지(0607 -등운동)

데드리프트 max 120x2

바벨로우는 가벼운 무게로 자극에 집중하며 올바른 자세를 유지하자

운동량이 좀 부족한듯 ㅜ.ㅜ

데이터 엔지니어로 살아가기 163일째(kafka, camus) 

기존에 kafka가 2개의 broker로 동작하고 있었는데 broker한대를 추가하게 되었다.

broker추가와 동시에 partition, replica 설정을 변경하는 작업을 하였다.

알파에서 테스트가 진행되었고 리얼에 적용을 하였는데 특정 topic으로 데이터를 처리하지 못하는 이슈가 발생하였다.

topic중 nginx - fluentd를 통해서 들어오는 데이터는 정상적으로 받고 있었지만

api서버에서 kafkaAppender로 로그를 produce하고 있는 topic이 정상적으로 동작하지 않았다.

원인은 api서버의 hosts파일에 kafka브로커들의 ip와 hostname이 등록되어 있지 않았기 때문이다.

기본적으로 api통신을 할 경우 acl이 뚫려 있고 어플리케이션 내부에서 ip로 목적지가 등록이 되어 있는 경우

문제없이 동작하여야 하지만 클라우데라를 통해 운영되고 있는 주키퍼, 카프카 등 하둡에코시스템이 호스트네임을 기반으로

서로 통신을 하고 있었기 때문에 ip정보만으로는 카프카 브로커를 찾아가지 못하는 문제가 있었다.

이번 문제로 많은 시간을 삽질을 하게되었지만 카프카 offset부터 camus가 어떤식으로 offset을 관리하고 있는지에 대해서

좀 더 깊게 들여다 볼수 있는 시간이 되었다.

camus는 현재 gobblin이라는 프로젝트로 넘어가 관리되고 있는 듯 싶었다.

카프카 특정 topic의 데이터를 hdfs에 적재해야한다면 gobblin을 검토해보면 좋을 듯 싶다.

이상~

데이터 엔지니어로 살아가기 149일째(spark2.1.1) 

오늘 문득 spark2.1.1버전에서 java8 람다식을 활용한 데이터 처리 속도와 

spark1.5(현재 클러스터에서 사용버전)에서 java7을 통한 spark 데이터 처리 속도가 얼마나 나는지 궁금해졌다.

덤으로 scala spark이 동일한 데이터 처리 프로세스를 가지고 spark1.5, spark2.1.1버전에서 돌았을 때 성능도 궁금해져

간단히 70만 라인의 텍스트 파일로 파싱하고 필터링 처리를 하고 text파일과 orc파일로 변환해 적재하는 테스트를 진행하였다.

아직 scala를 spark2.1.1에서 테스트하는 부분은 확인하진 못했지만 확실히 spark2.1.1대 버전에서 java8 람다식을 활용해 처리하는 것

이 제일 빨랐다. 이부분은 좀더 테스트 후 포스팅 하도록 하겠다.

그리고 오전에는 딥러닝에 대한 세미나를 들었다. 세미나 발표를 통해 큰 깨달음이나 감명을 받진 못했지만

꾸준히 관심을 가지고 학습해 추후에 지금 처리하고 있는 데이터들에도 적용할 수 있는 방법을 연구해보면 좋을 것 같다.

아 그리고 틈틈히 scala공부도 하도록하자!

데이터 엔지니어로 살아가기 143일째(커스텀타겟팅) - 0721금요일

광고주 태그매니저에서 들어오는 데이터들을 orc로 적재하는 작업을 마무리하였다.

camus를 통해 kafka에서 데이터를 가져와 매시간 데이터를 적재하고 있지만

커스텀타겟팅에 사용하기에는 부적합하다는 판단에 orc로 적재하기로 결정하였다.

작업을 완료하기까지 많은 수행착오를 겪었다. 인입되는 로그에서 실제 bid별 관심사를

추출해 적재하기로 사전에 얘기가 되었지만 실제로 작업을 완료하고 확인해보니 

생각보다 관심사를 추출하는 부분에서 처리시간이 많이 소모되었다. 

관심사 추출 후 date, action별로 partitioning하여 적재하는 시간이 단순 컬럼으로만 분리해서

적재했을 때의 시간보다 15배정도의 시간이 더 걸렸다.t.t

결국에는 일단 orc로 적재한 후 관심사 데이터가 필요할 경우 bid별 관심사 추출데이터와

join해서 사용하는 편이 리소스 활용측면이나 확장성 측면에서 더 효율적이겠다는 결정을 내렸고 

scala spark으로 다시 orc 적재하도록 마무리하였다.

orc적재 작업을 진행하면서 java-spark에 어느정도 더 익숙해졌고 관심사 추출로직에 대해

심도있게 파악할 수 있었다는 점에서 삽질도 많이했지만 좋은 기회가 되었던 것 같다.

이제 실제 커스텀타겟팅 메인 프로젝트 작업에 슬슬 시동을 걸어봐야겠다~

아! 그리고 틈틈히 scala공부를 하도록하자~scala 와 spark는 뗄래야 뗄 수 없는 관계

데이터 엔지니어로 살아가기 140일째(커스텀타겟팅) - 0718화요일

저번주 후반부터 이번주 계속해서 광고주 데이터를 orc로 적재하는 프로젝트 작업을 진행하고 있다.

단순 로그를 orc로 적재하는라면 scala spark을 통해서 쉽게 할 수 있겠지만 tag manager를 통해

유입된 요청들의 url에 매핑되어 있는 상품정보들을 형태소 분석기를 통해 관심사 번호와 매핑작업이 필요하기에

scala spark으로 작업을 진행 할 수 없었다. 

형태소 분석모듈과 관심사를 뽑아내는 로직이 자바로 되어져 있었기에 자바스파크로 작업을 진행중이다.

현재 관심사 추출 후 orc 적재하는 프로젝트가 80%이상 완성이 되었고 그 이후 spark sql을 통해

Custom Targeting을 진행할 메인 프로젝트 진행이 필요한 상황이다.

구글의 빅쿼리와 같이 쿼리 한번으로 사업측이나 기획측이 타겟팅하고 싶어하는 대상들의 uv를 뽑아내는 것이

목표이기 때문에 UI, 요청 처리하는 프로세스, API등 생각해봐야 할 문제들이 한 두 가지가 아니다.

오늘 하루 집에오는 길 내내 어떻게 시스템 구성 및 전체적인 custom타겟팅의 처리 flow들에 대해서 생각했던 것 같다.

그만큼 할 일은 많지만 요즘은 일이 너무 재밌다.

좀 더 불태워보자 화이팅:)