반응형

 

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

반응형
반응형

데이터 엔지니어로 살아가기 112일째(분산환경 로깅)


spark yarn-cluster에서 돌아가고 있는 실시간 작업들에 대한 로깅이 정상적으로 log4j파일의 위치에 남지 않아 한참을 헤맸다.

실제로는 분산환경에서는 작업 뿐만아니라 로깅또한 driver와 각 executor가 동작하는 데이터노느들에 분산되어 저장되게 된다.

yarn logs -applicationId (appilicationId) 를 통해서 확인을 할 수 있었지만 실제로 오랫동안 실시간으로 돌아가고 있는

시스템에 대한 로그들이 워낙 큰고 빠르게 쌓이기 때문에 확인하기가 어려웠다.


그리고 왜 실제로그는 실시간 어플리케이션이 실행될 때 한 번만 찍히고 이 후 동작하는 stream들에 대해서는

로그가 안남는것인지 원인을 찾지 못하였다.


아직 갈길이 험난하고도 먼 것 같다.

반응형
반응형

데이터 엔지니어로 살아가기 100일 째 축하축하?


한 동안 이슈들이 너무 많이 발생해서 정신이 하나도 없었다.


최근 리타겟팅 광고 데이터가 인코딩이 깨져 적재되는 이슈와 관련해 복구작업을 하느라 6월6일 휴일도 반납한채 열심히 복구작업을 진행했다.


문제에 원인은 크론탭으로 jar를 실행할 때 실제 리눅스 시스템 설정파일들을 물고 들어가지 않아서 파일 인코딩 값이 


utf-8이 아닌 다른 값이 들어갔었던 걸로 확인이되었다. 이 부분은 추후에 포스팅으로 남기도록 하겠다.


해당 이슈도 이슈지만 특정 광고주 폰(안드로이드 Galaxy7)에서만 광고텍스트가 깨지는 현상도 발생하는 문제도 있었다.


이부분에 대해서는 좀 더 확인이 필요할 것 같다.


요즘 드는 생각은 시스템 개발도 중요하지만 더 중요한 것은 시스템에 대한 모니터링 그리고 데이터 엔지니어들에게는


데이터에 대한 모니터링이 훨씬 더 중요하다고 생각된다.


하루빨리 실시간 데이터들을 모니터링을 개발해 현재 시스템들에 적용하도록 해야겠다.


매일 블로그에 글을 1나씩 써나가는게 목표인데 요즘 일하랴 운동하랴...정신이 없다.


욕심부리지말고 하루에 글 하나씩이라도 적어볼 수 있도록 습관을 만들어보도록 하자.


6월 한달도 화이팅!

반응형
반응형

오늘은 카프카에서 hdfs 데이터를 적재하는 카뮤(camus) 대해서 학습하고 생각해보는 시간을 가졌다.


아직 카뮤? 카뮈? 내부 아키텍쳐가 어떻게 설계되어져 있는지 확인하지는 못했지만 카뮈를 이용하면 카프카에서 생각보다 쉽게 hdfs 적재가 가능하다. 카뮈가 아니였다면? 자바로 카프카 컨슈머를 구현하고 hdfs 적재하는 로직처리를 해줘야 겠지?


그렇게 어플리케이션을 개발하더라도 카뮤에서 카프카 offset 확인해 데이터 누락을 최소화해주는 부분에 대한 구현은 힘들었을 같다.


물론 자바로도 할수 있겠지만....카프카에서 offset정보를 가져와서 처리할 있는 api 제공하는지는 잘모르겠다.


아무쪼록 깊이 파고들어 카뮤를 이해하고 실제로 카프카 토픽의 데이터를 받아오는 작업을 진행해보자!


백문이불여일행

반응형

+ Recent posts