행복한디벨로퍼

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

최근 작업중 unix date를 파싱해야는 경우가 있어서 아무렇지 않게

다음과 같이 썼는데 파싱된 데이터에 값이 안들어있다는...

확인해보니 split의 인자로 들어가는  .(dot)이 정규식이기 때문이었다. 

정규식에서는 .(dot)은 무작위의 한글자를 의미하므로 모든 문자가 토큰이 되기 때문에 배열에 남는게 없게 되는 것이다.

그렇기 때문에 이를 피하기 위해서는 이스케이프(\\)를 문자앞에 써줘야 한다.

뭔가 split 메서드를 사용해 parsing을 했는데 값이 정상적으로 나오지 않는다면 정규식을 의심하자.

[ 참고 ]

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

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

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

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

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

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

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

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

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

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

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

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

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

Collect연산?

Spark에서 Collect연산은 RDD의 모든 원소를 모아서 배열로 돌려줍니다.

반환 타입이 RDD가 아닌 배열이므로 이 연산은 액션에 속하는 연산입니다.

[ Collect연산을 사용하실 때 주의사항 ]

Collect 연산을 수행하면 RDD에 있는 모든 요소들이 collect 연산을 호출한 서버의 메모리에 수집되기 때문에

전체 데이터를 모두 담을 수 있을 정도의 충분한 메모리 공간이 확보되어 있는 상태에서만 사용해야 합니다.

그렇지 않을 경우에는 out of memory exception이 발생할 수 있습니다.

따라서 작은 크기으 데이터를 디버깅하거나 처리할 때 제한적으로 사용하시길 바랍니다.

데이터 엔지니어로 살아가기 135일째(카산드라) - 0713목요일

역시 꾸준한게 제일 어려운 것 같다...못해도 3일에 한번씩은 기록하고자 마음먹었는데 생각보다 쉽지 않다.

그래도 잊지말고 앞으로라도 꾸준히 써나가도록 하자.

최근에는 알파 환경에서 리얼환경처럼 데이터가 유입되도록 하는 작업을 진행했었다.

실제 데이터 파이프라인은 구축이 되어있었지만 알파환경에서는 작동하는 태그매니저들이 없기 때문에

데이터가 실제로 유입이되지 않고 있었고 데이터가 없어 spark job들에 대해서도 매번 테스트하기가 너무 힘들었다.

이럴거면 알파환경을 도대체 왜쓰는가? 서버비 아깝게...

그래서 실제 리얼 태그매니저들을 통해 들어오는 데이터의 일부를 rsync로 알파서버에 daily로 받아오게 하여

알파 수집서버로 api를 호출하도록 작업하였다.

요즘은 CustomTargeting 프로젝트를 진행하고 있다.

기획부터 시스템설계까지 진행을 하고 있고 구글의 빅쿼리를 모티베이션 삼아 진행하고 있다.

관심사 추출하는 로직과 기존 클러스터 환경상 java7로 스파크작업을 하는데 삽질을 많이 하고 있긴 하지만

스칼라로 작업을 할 때보다 map, flatmap 등 연산작업들의 내부 구현에 대해 좀더 자세히 배우고 있는 느낌이든다.

요즘은 일하는게 너무 재밌어서 시간가는 줄 모르고 일하는 것 같다.

일도 일이지만 데이터 처리하는 기술들에 대해 공부에 대한 욕심도 많이 생긴다.

너무 욕심부리지 말고 천천히 꾸준히 일도 공부도 운동도 열심히 하도록 하자~!

클라우드 네트워크 교육(0627)

사내에서 클라우드 네트워크 교육(0627)을 듣고 새롭게 알게된 내용에 대해 간략하게 정리.

공해야할 것 들이 너무 나도 많음을 느낀다.

[ 교육들으며 새로 알게 된 내용 ]

1. 실제 네트워크 확인시 패킷을 뜬다고 소위 말하는데 실제로는 OSI Layer상의 Datalink Layer의 Frame을 의미한다

2. Frame, Packet, Segment의 주요한 차이는 header가 가지는 정보의 차이에 있다고 볼 수 있다.

세그먼트(Segment, OSI 7계층의 전송 계층(Transport Layer)) : 데이터를 네트워크를 통한 실질적인 전송을 위하여 적절한 크기로 분할한 조각.

패킷(Packet, OSI 7계층의 네트워크 계층(Network Layer)) : 전송을 위해 분할된 데이터 조각(세그먼트)에 목적지까지의 전달을 위하여 Source IP 와 Destination IP가 포함된 IP Header가 붙은 형태의 메세지

프레임(Frame, OSI 7계층의 데이터링크 계층(Data Link Layer)) : 최종적으로 데이터를 전송하기 전에 패킷에 Header(Mac Address 포함)와 CRC를 위한 Trailer가 붙은 메세지

3. 리눅스에서 MAC ADDRESS확인시 ifconfig외에 ip link 및 ip -4 addr로 확인 가능 (가급적이면 ip 명령어에 익숙해지자 - 네트워크관련 모든 명령 처리가능)

4. MAC ADDRESS는 유니크한가? 로컬 LAN안에서는 유니크해야한다.

5. MAC ADRRESS는 permanent한가? permanent하지 않다. ip link set을 통한 abusing가능. 그렇기 때문에 MAC ADDRESS를 통한 인증처리는 지양하자.

6. 패킷 전송 크기를 정하는 MTU(Maximum Transmission Unit) 가 작을 경우 header에 의한 overhead를 초래할 수 있다.

ex) 
데이터 사이즈 3000byte
MTU=500 (byte) 인경우 6frame 으로 나눠 전송, 각 프레임에 헤더는 14byte * 6이된다
MTU=1500 (byte, 일반적 설정) 2frame, 헤더는 14byte * 6이 된다.

     [ MTU 더 궁금하면참고 ] http://www.packetinside.com/2013/02/mtumaximum-transmission-unit.html

7. 네트워크 연결 확인시 ping보다는 arping 명령어 이용 ping의 경우는 어떤 layer에서 막혔는지 확인이 힘들다.

8. 네트워크 대역폭 확인 시 iperf3 명령어 사용 (참고, http://sola99.tistory.com/374)

9. 토스트 클라우드 네트워크는 각 서비스별에 맞춰 tenant하게 설계되어짐 (share x) - 서로간 통신을 위해서는 floating IP 필요

10. AWS에서는 virtual private cloud를 사용해 각 계정 전용 가상 네트워크 제공

네트워크에 대한 공부도 틈틈히 시간내서 하도록 하자. 

알고개발하는 것과 모르고 개발하는 것은 천지차이

데이터 엔지니어로 살아가기 113일째(카산드라) - 0621

실시간으로 데이터를 처리해서 카산드라에 밀어넣고 있는데 알파에 같은 환경을 구축해서 데이터파이프라인 구축하는게 생각보다 너무 오래걸리고 있다. 그동안 알파환경이 관리가 제대로 되고 있지 않아 생각보다 여러가지 문제들에 부딪히며 해결하고 있는 중이다.

오늘 실시간 잡 로그를 보던 중 마이크로배치(10초)단위로 데이터를 읽어와 처리할 때마다 카산드라 커넥션을 맺었다 끊는 작업을 하고 있었다. 당연히 커넥션풀을 이용해 처리가 될 줄 알았는데...

무튼 알파환경에서도 리얼 환경과 동일한 데이터 파이프라인을 구축해 실제 테스트를 진행할 수 있도록 해야겠다.

알파환경이 구축되는 대로 카산드라와 HBASE에 대한 학습이 좀 더 체계적으로 필요할 듯 싶다.

100일 간의 운동&식단 일지(0606-8일차)

4일만에 하는 운동은 역시나 힘들다.

가슴 운동 진행

벤치프레스 인클라인 벤치프레스 이후

딥스 할 때 확실히 가슴에 집중력이 확떨어짐을 느낀다.

후엔 루틴을 조금 변경해보자.

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

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

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

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

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

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

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

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