행복한디벨로퍼

Dataframe count중 scala.MatchError 발생 ( show 명령어는 정상적으로 먹는데??? )

간만에 스파크 작업을 진행하다가 다음과 같은 에러문구를 만났다.

Text 파일을 sc.textFile("path") 로 읽어와 해당 RDD를 Dataframe으로 변환하고 dataframe.count시 발생하였다.

문제의 원인은  실제 텍스트파일내의 내용을 RDD로 읽어와 split으로 나눈 후 Dataframe으로 변형하는 과정에서 

컬럼개수가 일치하지 않는 데이터가 있었다.

text파일의 포맷은 다음과 같았다.

이러한 RDD를 다음과 같이 Dataframe으로 만들려고 하였다.

전혀 문제가 없을 것 같지만 이렇게 변경 후 count명령을 내려보면 MatchError가 발생하는 것이다.

알고보니 itemName에 상품명중 탭 구분자("\t")가 들어가 있었던 상품명이 있었던 것이다.

그래서 실제로는 4개의 컬럼으로 나누어져서 Dataframe이 만들어져야 하지만 상품명에 탭구분자가 있는 경우

Array length가 4이상이되면서 macth case 조건에 정상적으로 매칭되지 않았던 것이다.

이럴 경우 Dataframe을 show로 보았을 때는 전혀 문제가 없어보일 수 있지만 count로 모든 데이터의 수를 세게 될 떄

특정 데이터에 문제가 있을 경우 matchError가 발생하게 되는 것이다.

해결방법은 map처리에서 flatMap처리로 변경 후 조건에 맞지 않는 데이터는 None처리를 진행하였다.

또 다시 같은 삽질을 하지 않기 위해 포스팅 남겨본다.

스파크 작업을 하다보면 데이터 처리시 쿼리 기반의 spark sql, hive를 이용하기위해 orc로 데이터를 적재하는 경우가 많다.

이 때 spark-shell로 orc파일을 읽어들여 데이터를 보게되면 컬럼보다 데이터내용이 길게되면 잘려서 노출된다.

따라서 데이터 내용을 보고싶다면 dataframe형태의 데이터를 rdd로 만들어서 first나 rdd.take(n).foreach(println)식으로 보도록 하자

Spark scala.reflect.api.JavaUniverse.runtimeMirror 에러

spark-submit으로 spark 작업 실행 중 다음과 같은 에러 메세지가 떨어졌다면 build.sbt의 scala버전과 spark library의 버전이

서버에서 사용중인 spark 버전과 맞는지 확인하기 바란다.

나의 경우는 spark2.1.1 에서 동작하는 scala spark프로젝트 내부 scalaVersion을 2.10.5에서 2.11.5로 변경하여 해결하였다.

데이터 엔지니어로 살아가기 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들에 대해서 생각했던 것 같다.

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

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