반응형

 

데이터 엔지니어로 살아가기 212일째(리타겟팅 시스템)

리타겟팅 시스템에 대해 요즘 매력을 느끼고 있다. 

어떻게 보면 단순한 프로세스이지만 단순한 프로세스로 부터나오는 효율은 단순하다고 말하기 힘들 같다내가 상품에 대한 데이터를 가지고 있다가 후에 내가 다른 사이트에 접근 했을 해당 광고를 내보낸다는게 쉬워보이지만  대상이 100만명 200만명이 되면 말이 달라진다. 

이면에는 수많은 작업들이 돌아가고 있을 것이고 작업 혹은 시스템에 문제가 없는지에 대해 모니터링을 하기 위한 시스템들이 열심히 돌아가고 있을 것이다.  많은 작업들 위에서 데이터 엔지니어들은 작업들이 정상적으로 돌아가고 있는지, 예외적인 케이스로 인해 문제가 발생하지 않는지에 대해 경계하며  효율적으로 작업들을 처리하기 위한 방안들을 모색하고 있다. 

요즘 모색하고 있는 방안 중에 하나는 현재 리타겟팅을 위해 광고주별로 추천 상품을 뽑고, 상품들에 대한 비슷한 맥락의 추천상품을 뽑아내는 작업에 대한 부분이다. 부분이 현재 pyspark으로 작업이 돌고 있는데 pyspark javaspark 비해서도 성능이 많이 떨어진다. 추후에 기회가 된다면 pyspark으로 작업되어 있는 부분들에 대한 개선 작업을 진행해보고 싶다는 것이다. 


반응형
반응형

데이터 엔지니어로 살아가기 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는 뗄래야 뗄 수 없는 관계

반응형
반응형

데이터 엔지니어로 살아가기 104일째 (곰발바닥 뭔가 귀엽다...)


오늘 하루는 오전에는 브루클린이라는 키워드 타겟팅 시스템에서 사용하는 알파 RabbitMQ의 큐들을 모두 priority큐들로 바꿔서 테스트 하는 작업을 진행하였다. priority를 높게준 메세지들부터 정상적으로 consume 하는 것을 확인을 하며 RabbitMQ가 제공해주는 모니터링 관리 페이지부터 시작해서 꽤나 괜찮은 메세지큐라는 생각을 다시 한 번 했다. 기존에 ActiveMQ를 잠깐 사용했을 때는 별도의 관리 페이지를 제공해주지 않아 불편함이 있었는데 요즘은 지원해주려나???


오후즈음에는 실시간 관심사 타겟팅 로직에서 카산드라에 데이터를 넣을 때 에러 처리가 하나도 되어 있지 않아 실제로 데이터가 들어가지 않아도 관리자 입장에서는 알 수 있는 방법이 딱히 없다. 그래서 해당 부분에 에러처리를 해서 정상적으로 데이터가 upsert되지 않았을 경우 알림을 받도록 기능을 추가하고자 마음먹고 Git 에서 소스코드를 받아 로컬환경에 셋팅을 하기 시작하였다. 기존 작업을 하셨던 분이 repository를 잘관리하지 않으시고 실제로 배포 프로세스를 따르지 않고 실제 서버에서 수정해서 사용하기도 했던 것 같다. 따라서 소스코드를 다운받았을 때 메이븐 디펜던시며 소스코드들이 피를 토해내고 있었다...어쩜 이렇게 관리가 안될 수 있는지..왜 컴파일은 자바5버전으로 되도록 메이븐에 설정되어있는건지...왜 위키페이지에는 별도의 내용이 하나도 없는건지...답답함 투성이였다. 

실시간 관심사쪽과 실시간 리타겟팅쪽 코드를 같이 셋팅했는데 생각보다 리타겟팅쪽 코드들은 빠르게 셋팅하고 .gitignore도 등록해주었다. 기존에는 .gitignore도 없이 어떻게 사용하신건지...그냥 빌드되는 target 모든 jar파일과 class파일들을 서버에 반영하고 사용하셨던 것 같다....


이번 한 주는 관리하고 있는 프로젝트들에 대한 소스코드 및 배포 프로세스를 바로 잡는데 시간을 많이 보내야 할 것 같다.

그럼 오늘 하루도 안녕~

반응형
반응형

데이터 엔지니어로 살아가기 101일 째


어제(0609 금요일) 하루는 최근 회사 내에서  IDC 네트워크 장애에 대해 공유하는 시간을 가졌다. 

서버룸중 특저 서버룸의 스위치가 문제를 일으키며 해당 룸의 서버들의 네트워크 통신이 정상적으로 되지 않았다. 

사내에서 서비스하는 서비스들 모두가 장애시간동안 정상동작 하지 않았던 대형 이슈였다.

큰 장애가 터진 문제의 시발점은 access switch OS 버그에서 기인했다고 설명해주셨다. 

네트워크적인 지식이 많이 부족해 공유된 내용 모두를 이해하진 못했지만 사소한 버그들이 맞물려 큰 사고로 이어졌고 이에 대한 대응책등을 공유하는 시간을 가졌다.


오후에 저번주 리타겟팅 시스템 장애로 작업이 진행되지 못했던 실시간 모니터링 시스템에 대한 작업을 진행하였다.

실시간으로 처리되고 있는 데이터들이 정상적으로 데이터를 카산드라에 적재하고 있는지 모니터링 하기 위한 시스템이다.

작업을 하면서 어려움을 느꼈던 부분은 현재 알파 클러스터와 리얼클러스터에서 스파크 버전이 1.5에 맞춰져 있어 kafka stream, spark의 maven dependency버전 맞추는 부분에서 시간을 많이 빼앗겼다. 스칼라로 작업했으면 훨씬 빠르게 했을 것을 다른 시스템과의 연동이 많이 필요할 것 같아 자바(java8 이 아닌 java7)로 스파크 작업을 하다보니 시행착오를 많이 겪었다.


알파 클러스터에는 실시간으로 데이터들이 적재되지 않고 있기 때문에 curl을 통해 실시간으로 로그를 쏴주는 스크립트를 작성 후 

카프카에서 실시간 처리하는 시스템 작업으로 생각보다 고려할점들이 많았다.


간만에 시스템 설계부터 코딩작업에 시간은 잘갔던 것 같다. 

시행착오들, 경험들이 쌓여 이후 작업에서는 시스템 설계와 구현시 같은 이유로 시간을 많이 빼앗기지 않도록 열심히 배우고 공부하자.


반응형

+ Recent posts