반응형

[ 하둡 MR보다 스파크(SPARK)를 사용할 때 장점 ]

하둡MR보다 스파크(SPARK)를 사용했을 때의 대부분이 말하는 이점은 디스크 처리 기반에서 메모리 처리 기반으로 넘어오면서 연산처리 속도가 빨라졌다는 것이다.

뭐 틀린말은 아니지만 데이터 엔지니어 입장에서 뭔가 더 구체적으로 설명할 수 있어야 하지 않을까 하는 생각에 간단히 정리해 포스팅해본다.

1. 스파크(SPARK)의 연산 방식은 lazy evaluation으로 수행된다. 

Lazy evaluation(굳이 번역해 보자면 느긋한 연산 정도 되겠다)을 사용함으로써 action이 시작되는 시점에 트랜스포메이션(transformation)끼리의 연계를 파악해 실행 계획의 최적가 가능해진다. 사용자가 입력한 변환 연산들을 즉시 수행하지 않고 모아뒀다가 가장 최적의 수행 방법을 찾아 처리하는 장점을 가진다.
여기서 말하는 최적화란 대부분 지역성(locality)에 관한 것이다. 예를 들어 물건을 사오는 심부름을 시킬 때 A상점에서 파는 물건과 B상점에서 파는 물건을 따로따로 여러 번사오게 하는 것보다 필요한 물건을 한꺼번에 주문해서 한 번 방문했을 때 필요한 물건을 한 번에 사는 것이 효율적이기 떄문이다.

사실 fist() 액션에서도 스파크는 처음 일치하는 라인이 나올 때까지만 파일을 읽을 뿐 전체 파일을 읽거나 하지 않는다.

실제로 하둡 맵리듀스 같은 시스템에서는 맵리듀스의 데이터 전달 회수를 줄이기 위해 어떤 식으로 연산을 그룹화 할지 고민하느라 개발자들이 시간을 많이 빼앗기게 된다. 맵리듀스에서 연산 개수가 많다는 것은 곧 네트워크로 데이터를 전송하는 단계가 많아짐을 의미하고 그만큼 클러스터에 부하를 가져다 줄 수 있다. 스파크(SPARK)에서는 단순한 연산 들을 많이 연결해서 사용하는 것이나 하나의 복잡한 매핑 코드를 쓰는 것이나 큰 차이가 없는데 기본적으로 스파크에서 효율적인 계획을 세워서 수행하기 때문이다. 그렇다고 해서 rdd재사용 등을 고려하지 않고 아무렇게나 프로그래밍을 해도 된다는 의미는 아니다. 따라서 스파크 사용자들은 프로그램을 더 작게 만들고, 효율적인 연산의 코드를 만들어 내야 한다는 부담에서 좀 더 자유로울 수 있다.


2. RDD 재사용을 위한 캐싱 기능
기본적으로 메모리위에 캐싱을 하여 처리를 하게 되면 디스크 처리 기반의 MR작업보다 최소 10~20배 이상 빠를 수 밖에 없다. 여러 액션에서RDD 하나를 재사용하고 싶으면 RDD.persist()를 사용하여 계속 결과를 유지하도록 할 수 있다. 첫 연산이 이루어진 후 스파크는 RDD의 내용을 메모리에 저장하게 되며(클러스터의 여러 머신들에 나뉘어서) 이후의 액션들에서 재사용할 수 있게 된다.


3. RDD는 유연한 연산 방식을 제공한다.
분산 데이터로서의 RDD(Resilient Distributed Datasets)는 문자 그대로 해석하면 "회복력을 가진 분산 데이터 집합"으로  데이터를 처리하는 과정에서 집합을 이루고 있던 데이터의 일부에 문제가 생겨도 스스로 알아서 복구할 수 있다는 의미이다.  실제로 이것은 스파크(SPARK)가 RDD를 만들어 내는 방법을 기억하고 있기 때문에 가능한 것으로 스파크는 데이터의 일부가 유실되면 어딘가에 백업해둔 데이터를 다시 불러오는 것이 아니고 데이터를 다시 만들어내는 방식으로 복구를 수행하게 됩니다.


4. 코드 간결성 및 Interactive shell
하둡 MR을 해보신 분은 알겠지만 단어들을 aggregate하는 하둡 MR소스코드는 맵과 리듀스를 만들어주어야 하기 때문에 길고 복잡할 수 밖에 없는 반면에 스파크는 람다기반의 함수형 프로그래밍 기법으로코드가 매우 간단하며, interactive shell을 사용하여 실제 쉘에서 실시간으로 데이터 변화를 확인할 수 있다는 장점을 가지고 있습니다.


실제로 하둡 MR 대안으로 SQL을 MapReduce로 변환해주는 Hive 프로젝트가 있어 많은 사람이 잘 사용하고 있지만, 쿼리를 최적화하기가 어렵고 속도가 더 느려지는 경우가 많다는 어려움이 있다. 스파크는 이러한 단점들을 보안하며 위와 같은 장점들로 인해 분산 처리 툴로서 많은 관심과 사랑?을 받고 있다고 볼 수 있습니다.


반응형
반응형

하둡1.0과 하둡2.0의 차이는 YARN으로 인해 많은 부분이 변화되었다.

그 차이에 대해서 알아보도록 하자.

[ 아키텍처의 변화 ]


[ 하둡 1.0과 2.0에서 리소스 관리 차이 ]

하둡 1.0에서 맵리듀스를 실행할 때는 슬롯 단위로 맵/리듀스 태스크 갯수를 관리했다.따라서 맵퍼는 모두 동작하는데 리듀서는 놀고 있거나 반대의 경우로 인해 클러스터 전체 사용률이 낮았다.

하지만 하둡 2.0에서 YARN(얀)이 도입되면서 슬롯이 아닌 컨테이너 단위로 리소스를 할당하게 되었다. 얀의 리소스 매니저는 전체 클러스터의 리소스 정보를 토대로 할당 가능한 컨테이너 개수를 계산하며, 맵리듀스는 필요한 컨테이너들을 할당 받아서 맵리듀스 태스크를 실행하게 된다. 

이 때 컨테이너 개수와 맵과 리듀스 태스크의 관계는 1:1의 관계가 아니며, 맵과 리듀스 태스크는 상황에 따라서 하나 이상의 컨테이너를 실행할 수도 있다. 그래서 관리자는 전체 클러스터의 리소스 상황과 얀에서 실행하는 잡들의 워크로드를 고려하여 리소스 설정을 진행해야 한다.


[ YARN의 도입으로 JobTracker의 역할이 Resource Manager와 Application Master로 분리 ] 

하둡 1.0에서는 JobTracker(잡트래커)가 클러스터 리소스 관리 및 어플리케이션 스케쥴링 등을 모두 담당했었다.

하지만 하둡 2.0에서는 클러스터마다 Application Master(어플리케이션 마스터)가 존재하고 각 서버마다 Node Manager(노드 매니저)가 할당되어 있고 리소스관리는 Resource Manager(리소스 매니저)가 어플리케이션 수행 및 스케쥴링 관리는 Application Master(어플리케이션 마스터)로 역할이 분리되어 운영된다.


[ Spark 등 분산처리 환경 지원 ]

하둡의 맵/리듀스 작업보다 성능이 훨씬 개선된 SPARK 및 분산처리 프레임워크를 사용할 수 있게 되었다. 스파크는 배치 처리 작업에 있어서 맵리듀스보다 10배정도 빠르며 인메모리 분석에서 100배나 빠르다고 알려져 있다.




반응형
반응형

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


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


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



1. orc 파일 읽기

val data = sqlContext.read.format("orc").load("hdfs file directory")          //spark1.5,6 version


2. 읽어들인 데이터(dataframe형태)를 rdd로 변경하기

val rdd = data.rdd


3. rdd로 변경한 데이터 보기

rdd.first

rdd.take(n).foreach(println)         //n은 보고싶은 라인 개수




반응형
반응형

Spark 직렬화 포맷

spark는 네트워크로 데이터를 전송하거나 디스크에 쓸 때 객체들을 직렬화해 바이너리 포맷으로 변환한다.

기본적으로 Java에 내장된 직렬화를 이용하지만 spark는 java 직렬화보다 훨씬 향상된 서드파티 라이브러리인

kryo를 쓰는 것을 지원한다.

반응형
반응형

Scala 버전만 작성하였다.


Java, Python, R에 대해서도 정보가 필요하다면 글 하단의 참조 링크를 참고 바란다.


SparkConf( Spark 1.6 / Spark 2.x)

You will continue to use these classes (via the sparkContext accessor) to perform operations that require the Spark Core API, such as working with accumulators, broadcast variables, or low-level RDDs. However, you will not need to manually create it.

// Spark 1.6
val sparkConf = new SparkConf().setMaster("local[*]")
sparkConf.set("spark.files", "file.txt")
 
// Spark 2.x
val spark = SparkSession.builder.master("local[*]").getOrCreate()
spark.conf.set("spark.files", "file.txt")


SparkContext( Spark 1.6 / Spark 2.x)

The SQLContext is completely superceded by SparkSession. Most Dataset and DataFrame operations are directly available in SparkSession. Operations related to table and database metadata are now encapsulated in a Catalog (via the catalog accessor).

// Spark 1.6
val sparkConf = new SparkConf()
val sc = new SparkContext(sparkConf)
val sqlContext = new SQLContext(sc)
val df = sqlContext.read.json("data.json")
val tables = sqlContext.tables()
 
// Spark 2.x
val spark = SparkSession.builder.getOrCreate()
val df = spark.read.json("data.json")
val tables = spark.catalog.listTables()


HiveContext( Spark 1.6 / Spark 2.x)

The HiveContext is completely superceded by SparkSession. You will need enable Hive support when you create your SparkSession and include the necessary Hive library dependencies in your classpath.

// Spark 1.6
val sparkConf = new SparkConf()
val sc = new SparkContext(sparkConf)
val hiveContext = new HiveContext(sc)
val df = hiveContext.sql("SELECT * FROM hiveTable")
 
// Spark 2.x
val spark = SparkSession.builder.enableHiveSupport().getOrCreate()
val df = spark.sql("SELECT * FROM hiveTable")


ref : https://sparkour.urizone.net/recipes/understanding-sparksession/

반응형
반응형

오늘 스파크 작업중 No TypeTag available for 에러가 발생하였다. 


밑에 소스코드 부분에서 val df = sQLContext.createDataFrmae(test_rdd3) 부분에서 발생하였고 


case class의 위치를 메소드의 바깥 부분으로 빼내어서 처리하였다. 


원인에 대해 참고할 만한 stackoverflow 내용이 있어 참고하였다.

https://stackoverflow.com/questions/29143756/scala-spark-app-with-no-typetag-available-error-in-def-main-style-app





[ 에러 발생 코드 ] 




[ 에러 해결 ]

case class를 main method 바깥으로 빼서 처리





뭔가 컴파일 시점에 case class를 정의하는 시점과 case class를 통한 spark의 action이 일어나는 시점과 연관이 있을 것 같

은데 자세한 원인에 대해서는 파악하지 못했다ㅠ 혹시 조언해주실분 있으면 감사하겠습니다. 

스칼라 공부를 좀 더 심도있게해야 할듯 싶다.


반응형
반응형

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


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


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

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

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

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


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

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


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

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

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


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

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

반응형
반응형

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


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

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

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

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


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

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


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

반응형
반응형

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


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

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

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

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

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


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

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

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


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

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


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

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


반응형

+ Recent posts