스케일러블하고 함수형이며 오브젝트 지향인 Scala 입문 (1)

[번역] Eclipse로 Scala 프로그래밍을 시작하기 위한 기초 지식 (2/3)

 

2012.02.10 [나카무라 슈타, 주식회사 클래스 메소드]

 

일어 원문: http://www.atmarkit.co.jp/ait/articles/1202/10/news122_2.html - 일본 IT 관련 사이트

 

- 본 글은 위 일어 원문 링크의 글을 번역하였습니다.

 


 

 

Scala 프로그래밍을 시작하기 위한 준비

 

1. JDK 인스톨

 

 Scala를 구동하기 위해서는 Java가 필요합니다만, Java 인스톨에 대해서는 본 글에서는 생략합니다. 다른 글을 참고하여 JDK 사이트에서 다운로드와 인스톨을 실시하고 적절한 path를 설정해 주세요. (※ Mac OS X를 이용하는 분은 애플 사이트에서 다운로드 해 주세요)

(*주: 원문에서는 다른 일어 사이트 링크가 걸려있지만 여기서는 생략함)

 

2. Scala 인스톨

 

 Java 인스톨이 완료되면 다음은 Scala 인스톨을 할 차례입니다. Scala는 공식 사이트에 있는 Scala 다운로드 페이지에서 다운로드 할 수 있습니다.

 

 Scala의 최신 안정판은 2012년 2월 4일 현재 Scala 2.9.1.final 입니다. 여기서는 Windows 버전 Scala를 다운로드 해서 설치해 보겠습니다.

(*주: 원문 글이 쓰여진 시점은 2012년 2월로 현재는 버전 다름)

 

 Scala 다운로드 페이지에서 Windows용 'scala-2.9.1.final.zip'을 다운로드 해주세요.

 

 다음으로 다운로드한 zip 파일을 적당한 위치에 압축을 풉니다. (※ 본 글에서는 위치를 'C:/scala-2.9.1.final'로 하겠습니다)

 

           [그림 1] 운영체제에 맞는 Scala를 다운로드

 

 

3. 환경변수 추가

 

 zip 파일을 풀었으면, 해당 디렉토리를 환경변수로 셋팅합니다.

 

 환경변수명

설정 예 

 SCALA_HOME

C:/scala-2.9.1.final 

 PATH

~;%SCALA_HOME%/bin 

 

 Windows 버전에 따라 약간 다르지만, '내컴퓨터'를 마우스 오른쪽 클릭하고 '속성' → '상세설정' 탭은 선택 → '환경변수' 버튼을 클릭합니다. 윈도우 창이 뜨면, 'SCALA_HOME' 환경변수를 새롭게 추가하고, 'PATH' 환경변수에 '%SCALA_HOME%/bin' 디렉토리를 추가해 주세요.

(*주: windows 7인 제 컴퓨터에서는 '컴퓨터' 마우스 우클릭 → '속성' → '설정변경' → '고급' 탭 → '환경변수' 클릭)

 

 

 환경변수 설정이 완료되면 커맨드 창을 열고 'scala -version' 이라고 입력해 봅시다. Scala 버전이 아래와 같이 나타나면 인스톨 성공입니다.

 

           [그림 2] 인스톨 되어있으면 Scala 버전이 표시된다

 

 ※ Windows 이외 OS에 인스톨하는 경우는 다른 사이트를 참고해 주세요.

 (*주: 일본어 사이트 링크가 있으나, 별도로 번역하지는 않음)

 


 

대화형 실행 환경 'REPL'로 'Hello World!'


 Scala는 Java와 같이 소스 파일을 컴파일해서 바이트 코드로 바꾸어 실행합니다만, 대화형 실행 환경 ('Read-eval-print loop'의 약어로 'REPL(리플)'이라고 합니다)도 사용 가능합니다.

 

 REPL에서는 한 행씩 코드를 입력해서, 그 때마다 동작을 확인하면서 실행할 수 있기 때문에 약간의 코드를 시험해 보고 싶다거나 할 때 자주 사용합니다.

 

 커맨드 창을 열고 'scala'를 입력하면 'REPL'이 기동됩니다. 이 REPL상에서 'println("Hello World")' 라고 입력해봐 주세요. 아래와 같이 결과가 'Hello World'라고 표시됩니다.

 

           [그림 3] REPL을 실행하고 있는 상태. 실행 결과가 바로 나오기 때문에 편리함

 

 REPL을 종료시키려면 ':quit' 이라고 입력합니다. '콜론(:)'을 적는걸 잊지 마세요.

 


 

Eclipse 플러그인의 Scala-IDE를 사용하려면

 

 콘솔에서 REPL을 사용해서 Scala를 실행할 수 있다는 것은 알게 되었습니다. 하지만 통합개발환경(IDE)에서 Scala를 사용하고 싶은 경우는 어떻게 하면 될까요?

 

 'Eclipse', 'NetBeans', 'IntelliJ'와 같은 현재 자주 사용되고 있는 IDE에는 Scala로 개발하기 위한 플러그인이 있습니다. 이번에는 Eclipse 상에서 Scala를 이용한 프로그래밍을 하기 위한 플러그인, 'Scala IDE for Eclipse 2.0'을 소개합니다.

 

 Scala IDE for Eclipse는 Scala 관련 기술을 제공하는 Typesafe사가 지원하는 Eclipse용 플러그인으로, 아래와 같은 기능을 가지고 있어 Scala 개발을 지원해 줍니다.

  • 코드 자동완성

  • 자동 컴파일

  • import 해야할 패키지 후보를 알려줌

  • 불필요한 import 제거

  • 소스 코드 정리

 'Ctrl'+ '스페이스' 키로 코드 자동완성이 된다거나, 'Ctrl' + 'Shift' + 'F' 키로 소스 코드 정리가 되거나 해서 JDT와 같은 감각으로 쓸 수 있습니다.

 

 또, 좀 전에는 콘솔에서 REPL을 사용했지만 Eclipse로 작성한 Scala 프로젝트를 오른쪽 클릭하여 메뉴에서 REPL을 사용하는 것도 가능합니다. (※ 자동완성이 안되는 등 콘솔상의 REPL 보다 다소 사용하기 어려운 점이 있으니 주의해 주세요)

 

 Scala IDE for Eclipse를 인스톨 해 봅시다.

 

1. Eclipse를 다운로드하고 압축 풀기 

 

 Scala IDE가 공식적으로 지원하는 Eclipse 버전은 Eclipse 3.6 (Helios) 입니다.

 

 일단은 Eclipse 3.7 (Indigo) 에서도 문제없이 작동할 것이라 생각합니다만, 플러그인끼리의 상성 때문에 불안정하게 될 가능성이 있습니다. 공식적으로 지원하고 있는 Eclipse 3.6 (Helios)를 깨끗한 상태에서 사용할 것을 추천합니다.

 

 여기에서 다운로드 해서 압축을 풉시다. 다운로드 하는 패키지는 'Eclipse IDE for Java Developers 나 Eclipse IDE for Java EE Developers'가 문제 없을 것입니다.

 

          [그림 4] Eclipse 3.6 다운로드 페이지. 자신의 환경에 맞는 Eclipse를 다운로드

 

2. Scala IDE for Eclipse를 인스톨 

 

 Eclipse를 기동하고 메뉴에서 'Help' → 'Install New Software...'를 선택합니다. 'Add' 버튼을 클릭하여 Scala 2.9용 Update Site를 입력합니다.

 

 필드명

설정 예 

 NAME

Scala IDE for Eclipse 2.0

 Location

http://download.scala-ide.org/releases-29/stable/site

 

 

 인스톨하는 플러그인 후보가 나오기 때문에 모두 선택해서 인스톨 합니다.

 

 

           [그림 5] 플러그인을 인스톨하는 사이트를 지정 (※ 화면은 Mac OS X 환경)

 

다시 시작하라고 나오니 Eclipse를 재기동 합시다. 이걸로 Scala IDE for Eclipse 인스톨은 완료입니다. 다음 페이지에서는 Eclipse로 Scala 프로그램을 실행해 봅시다.

(*주: 다음 페이지는 작성 중...)

 

 

Posted by 이슈타르네스

스케일러블하고 함수형이며 오브젝트 지향인 Scala 입문 (1)

[번역] Eclipse로 Scala 프로그래밍을 시작하기 위한 기초 지식 (1/3)

 

2012.02.10 [나카무라 슈타, 주식회사 클래스 메소드]

 

일어 원문: http://www.atmarkit.co.jp/ait/articles/1202/10/news122.html - 일본 IT 관련 사이트

 

- 본 글은 위 일어 원문 링크의 글을 번역하였습니다.

 


 

 

인기인 'Scala'를 처음부터 배워보자

 

 최근에 제 주변에도 Scala에 관한 화제가 늘어나고 있습니다. Twitter나 블로그, 기술계 뉴스 사이트에서 매일같이 Scala에 관한 이야기가 보입니다.

 

 또, 필자가 현재 연관되어 있는 프로젝트에서도 실제로 Scala를 써서 개발하고 있습니다. 지금까지는 Java로 개발하는 일이 많았지만, 그것보다 간결하고 유연성 있게 작성할 수 있어, Scala로 개발하는 것은 매우 생산성이 높다고 느끼고 있습니다.

 

 본 연재는 Scala의 특징을 소개하고, 기본 구문이나 함수, 클래스 등 Scala의 기본적인 기능에 대해 설명하려 합니다. 어떤 프로그래밍 언어를 배운 적이 있고, 프로그래밍의 기본적인 부분을 알고 있는 사람을 대상으로 하고 있습니다. 딱히 언어를 따지지는 않지만, 오브젝트 지향 언어의 경험자라면 이해하기 쉬울 것이라 생각합니다.

 

 첫 연재인 이번 글에서는 Scala의 특징을 소개하고, 개발을 시작하기 위한 준비부터 최초 Scala 프로그램 실행까지를 소개합니다.

 

 


 

 

Twitter나 Foursquare, LinkedIn이 사용하는 'Scala'란 


 
'Scala'란, 표준 Java 플랫폼 상에서 동작할 수 있는 프로그래밍 언어입니다. 2003년쯤 등장한 비교적 최신 언어입니다만, 이미 Twitter나 Foursquare, LinkedIn에서 사용한바 있습니다. 일본에서도 몇 가지 사용 사례가 있는 듯 합니다.

 

 

 Scala (스칼라) 란 이름은 '스케일러블(Scalable) (확장가능)한 언어' 를 의미합니다. Scala는 Java의 Generics (제네릭형) 의 설계 등에도 관련되었던 스위스 연방 공과대학 (EPFL)의 Martin Odersky(마틴 오더스키) 교수에 의해 설계, 개발 되었습니다.

 

 교수에 의하면, Scala 언어 개발의 동기로, 아래의 두 가지가 있다고 합니다. (일본 Wikipedia 에서 인용)

 

 1. 범용 언어는 스케일러블(확장가능) 해야한다. 같은 개념으로 작은 프로그램도 큰 프로그램도 작성할 수 있어야 한다.

 

2. 스케일러빌리티 (확장성)는 함수형 언어오브젝트 지향 언어의 두 가지 프로그래밍 개념을 통합하고, 일반화 함으로써 실현 가능하다.

 

 개발 동기에 써있듯이 Scala는 작은 스크립트 용도에서 대규모 시스템에서 사용하는 언어로써의 용도까지 다양한 니즈에 응할 수 있도록 되어 있습니다. 그리고, 그 확장성을 실현하기 위해서 '오브젝트 지향 언어와 함수형 언어의 개념을 결합하고 있다'라는 특징을 가지고 있습니다.

 

 또 Scala 공식 사이트의 Scala 소개문에서는 맨 처음에 아래와 같이 기술되어 있습니다. 

(Scala 공식 사이트에서 인용)

 

Scala is a general purpose programming language designed to express common programming patterns in a concise,  

elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages,

enabling Java and other programmers to be more productive.

Code sizes are typically reduced by a factor of two to three when compared to an equivalent Java application

 

 그 일본어 번역입니다. (프로그래밍 언어 Scala 일본어 정보 사이트에서 인용)

 

Scala는 범용적인 프로그래밍 패턴을 간결하고 세련되게 그리고 형안전하게(type-safe) 표현하기 위한 범용 프로그래밍 언어입니다.

Scala는 오브젝트 지향의 기능과 함수형 언어의 기능을 잘 결합하고 있어, Scala를 사용함으로써, Java나 그 외 프로그래머의 생산성은 보다 향상될 것입니다. 

Scala의 코드 사이즈는 전형적으로는 같은 기능을 실현한 Java 어플리케이션과 비교해서 2분의 1에서 3분의 1 정도입니다.

 

 '오브젝트 지향, 함수형 언어의 기능을 결합함으로써 보다 간결하게 코드를 작성할 수 있어 생산성이 향상된다' 고 이야기하고 있습니다.

 

 


 

 

코드를 Java 와 Scala로 비교해 보자 

 

 여기서 한 가지 예를 들어봅시다. 아래의 코드는 '인수로 전달된 문자열인 리스트 중 제 2 인수로 지정한 길이 이상의 요소를 모두 대문자로 변환하고, 그 요소를 함수 내부에서 새롭게 정의한 리스트에 추가하여 반환한다' 는 함수를 Java에서 작성한 것입니다.

 

Java의 소스 코드

 

 리스트를 루프로 돌리고, 요소마다 길이를 체크해서 조건에 맞는 요소를 함수 내부에서 정의한 리스트에 추가하고 있습니다.

 

 같은 처리를 Scala에서 작성하면 이렇게 됩니다.

 

Scala의 소스 코드

 

 전달된 리스트를 길이 (len)로 필터링하고 결과 리스트의 요소마다 모두 대문자로 변환한 리스트를 반환합니다. 어떻습니까? 확실히 Java 코드 보다 훨씬 작은 코드량을 보입니다. 

 

 이것은 극히 간단한 예이지만, Scala라면 간결하고 알기 쉬운 코드를 쓸 수 있다는 걸 알 수 있습니다.

 

 


 

 

기존의 언어에서 좋은 것만 가져온 'Scala'의 다섯가지 특징

 

 

 Scala는 아래와 같은 특징을 가지고 있습니다. 다양한 기능을 가지고 있지만, Scala만이 가지고 있는 특수한 기능이란 건 별로 없고, 기존의 프로그래밍 언어에서 좋은 부분만을 받아 들여 밸런스를 잘 맞추고 있다고 생각합니다.

 

 

[1] Scala는 오브젝트 지향 언어

 

 Scala는 순수한 '오브젝트 지향' 언어입니다. 모든 값은 '오브젝트' 이며, 모든 조작은 '메소드' 입니다. 

 

 Java의 int형이나 double형과 같은 프리미티브형은 존재하지 않습니다. 예를 들어 Scala에서 '1+2' 라는 코드는 'Int 클래스 (값은 1) 의 '+' 라는 이름의 메소드에 인수 2를 전달한다'는 의미입니다.

 

 또 Scala에서는 오브젝트 지향을 실현하기 위해 클래스 베이스의 상속과 '믹스인(mixin) 합성'을 지원하고 있습니다.

 

 '믹스인 합성' 이란 '트레이트(trait)' (Ruby에서 말하는 '모듈', Java로 따지자면 '구현을 가질 수 있는 인터페이스와 같은 것')을 사용하여 하나의 클래스에 대해서 복수의 구현을 가지는 기능을 맞출 수 있게 되는 것입니다.

 

[2] 함수형 프로그래밍이 가능

 

 '함수형 프로그래밍'이란 단어는 최근에 자주 듣는 용어일지도 모릅니다. 이것은 간단하게 말하자면, 부작용(데이터의 내부 상태를 변경하는 것)이 없는 '함수'를 사용해서 프로그램을 구축하는 프로그래밍 수법입니다.

 

 함수형 프로그래밍의 이점으로, '함수가 자기 완결하고 '상태'가 없기 때문에, 가독성이나 보수성, 테스트, 리팩토링이 쉬워진다'는 장점이 있습니다.

 

 Scala에서는 함수를 '퍼스트 클래스'로써 취급합니다. 즉, '정수나 문자열 등과 같이 함수를 인수나 리턴값으로 할 수 있다'는 것입니다.

 

 또 '정수'(val)이나 '불변 콜렉션'을 사용해서 프로그래밍 할 수 있습니다.

 (※ 변수 (var)나 가변 콜렉션을 사용해도 상관없습니다)

 

 이러한 특징을 가지고 있기 때문에 표현력이 좋아 간결하게 작성할 수 있습니다.

 

 오브젝트 지향과 함수형 프로그래밍은 대립하는 개념이 아니라, Scala에서는 이것들이 잘 어우러져 간결한 작성과 유연성을 실현하고 있습니다.

 

[3] 정적 타이핑

 

 '정적 타이핑'이란 변수나 함수가 미리 정해진 데이터형을 처리하도록 엄밀한 작성을 요구하는 프로그래밍 언어의 특성입니다.

 

 Scala는 정적 타이핑 언어여서 안전하게 추상화 할 수 있는 타입 시스템을 가지고 있습니다. 그 때문에 타입에 의한 에러는 실행할 때가 아니라, 컴파일 때 알 수 있습니다.

 

 "정적 타이핑이면, 타입 작성에서 프로그램이 장황해 지는 것 아니냐?"라고 생각하는 분들도 있을지도 모릅니다. 하지만, Scala에서는 타입 추론에 의해 타입 기술을 생략할 수 있어 간결한 표현을 할 수 있게 합니다.

 

[4] Java와의 연계

 

 Scala의 소스 파일을 컴파일하면, JVM (Java 가상 머신)의 바이트 코드가 됩니다. Java 가상 머신 상에서 동작하기 위해 Scala에서 Java의 메소드나 필드도 불러 들일 수 있고, 역으로도 가능합니다.

 

 즉, 기존의 풍부한 Java 라이브러리를 그대로 활용할 수 있습니다.

 (※ 일부 예외는 있습니다)

 

[5] 병행처리

 

 현재는 CPU의 멀티코어화 (하나의 프로세서에 복수의 프로세서, 코어를 집어넣은 기술) 가 당연해졌습니다. Java에서 병렬처리를 실행할 때는 java.lang.Thread 클래스나 java.util.concurrent 패키지를 사용해서 병렬처리를 실현합니다.

 

 Scala에서는 멀티 코어를 의식해서 효율좋게 병렬처리를 행하기 위한 'Actor'라고 불리는 라이브러리를 가지고 있습니다. 이것은 '액터 모델(actor model)'에 기반한 라이브러리로, 액터끼리 서로 메세지를 보내 처리를 하는 프로그래밍 모델입니다.

 

 거기에 Scala 2.9에서부터는 병렬처리 대응 콜렉션 (palallel collection)이 사용 가능해 졌습니다. 이것은 콜렉션을 병렬화하여 각각의 스레드에서 실행하는 처리를 간단히 작성할 수 있습니다.

 

 다음 페이지에서는 Scala를 인스톨 해 봅시다.

 

 다음 페이지: [번역] Eclipse로 Scala 프로그래밍을 시작하기 위한 기초 지식 (2/3)

 

 

 

Posted by 이슈타르네스

[Cloudera 블로그 번역] 왜 우리들은 HDFS상에 플랫폼을 구축하는가

 

일어 원문 : http://www.cloudera.co.jp/blog/why-we-build-our-platform-on-hdfs.html - 일본 Cloudera Blog

영어 원문 : http://blog.cloudera.com/blog/2012/07/why-we-build-our-platform-on-hdfs/ - 미국 Cloudera Blog

 

- 본 글은 위 일어 원문 링크의 글을 번역하였습니다.

- 일어 원문 글은 위 영어 원문 글을 번역한 글입니다.

 


 

 

 본 글은 Cloudera Cloudera 프로덕트 바이스 프레지던트인 Charles Zedlewski가 쓴 글을 번역한 것입니다.

 

 Hortonworks의 E14와 같은 의견을 가질 기회는 좀처럼 없습니다만, 그의 최근 블로그 글은 그 절호의 기회를 가져다 주었습니다. 저는 E14가 지적한 부분 중 몇 가지를 토대로 저의 의견을 추가하려 합니다.

 

 최근 GigaOm의 기사에서 HDFS를 대체하는 8개의 제품이 소개 되었습니다. 그들은 실제로는 그 외에도 적어도 4개 제품을 소개하지 않았습니다. 1년 이상에 걸쳐 ParaScale은 HDFS의 대체로 자사제품을 판매하였습니다. (Hitachi(히타치)에 자산을 매각하기 전까지). Appistry는 HDFS의 대체품을 계속 판매하고 있습니다. 아직 릴리즈 되었는지 안되었는지는 모르겠지만, Symantec(시만텍)의 Veritas 부문도 HDFS를 대체하는 클러스터 파일 시스템(CFS)를 제안하고 있는 것은 명백합니다. HP Ibrix는 여러 해 전부터 HDFS API를 지원하고 있습니다.

 

 GigaOm의 기사가 의미하고 있는 것은, 대체물을 추진하고 있는 12개의 다른 벤더의 존재는 HDFS의 어떤 결함을 지적해야만 한다는 것입니다. 그 외에 누가 그런 지적을 하겠습니까. 이건 정말 틀린 결론입니다. 저는 이 일에 대해 묻고 싶습니다.

 

 우리들은 아래의 사실에서 어떤 결론을 끌어낼 수 있을까요.

  • 12종류의 파일 시스템은 HDFS의 대체로써 자기자신을 홍보하고 있습니다.
  • 12개의 대체품 대부분은 HDFS보다도 6~14년 더 긴 역사를 가지고 있습니다. (시장에 오래 남아있다는 것은 그것들에 우세한 부분이 있다는 것을 의미하는 것이겠지요)
  • 하지만 HDFS는 다른 대체품을 압도할 정도의 엔터프라이즈 데이터(수백 페타바이트)를 저장하고 있습니다.
  • HDFS는 대규모 벤더 지원 (Cisco, Dell, HP, IBM, NetApp, Oracle, SAP, SGI, SuperMicro)의 광범위한 기반을 가지고 있습니다.

 저희 Cloudera는 HDFS가 데이터 매니지먼트 업계 표준으로써 이들 레거시 파일 시스템을 한창 압도하고 있다고 결론 내렸습니다.

 

 실제로 저희는 전에도 비슷한 스토리를 봐왔습니다. 20년전으로 돌아갈 수 있다면, 우린 비슷한 상황을 떠올릴 수 있겠죠. 그 때의 시장에는,

 

  • 12 이상의 선택지가 있었습니다. 그것들은, AIX, HP-UX, Solaris, Seequent, Darwin, BSD, SCO, Unixware 등으로 불리고 있었습니다.
  • 모든 대체품은 아주 먼 옛날에 기능 포화 상태에 이르렀고, 엔터프라이즈 마케팅 담당자는 이를 감추려고 고심하고 있었죠. 쓸데없는 질문일 수 있겠습니다만, SCO와 OpenBSD 사이의 기능적 차이를 기억하고 계십니까?
  • 그들은 종종 독자적인 고가의 하드웨어에 밀접하게 결합 시켰습니다.
  • 그런 단편화는 한 번의 R&D 사이클로 폭넓은 시장을 타겟으로 하는 어플리케이션 개발자와 하드웨어 제조업자에게 있어서는 악몽이었습니다.

 이 상황은 Linux의 점화를 기다리는 화약 창고와 같은 것이었습니다. Linux가 성숙해 지고 인기가 늘어남에 따라 많은 Unix 벤더가 유행과 맞서 싸우려고 했습니다. 많은 마케팅과 PR 비용은 운영 시스템의 새로운 것에 대한 공포, 불확실성, 의문을 만들어 내기 위해 쓰여졌습니다. 하지만 이 일은 헛되이 끝났고, 시간이 지남에 따라 Linux는 IT 업계에 매우 큰 임팩트를 주게 되었습니다. Linux가 모든 하드웨어 벤더에게 공평한 경쟁의 장을 만들어줌에 따라 하드웨어 비용 절감으로 이어지게 되었습니다. Linux가 플랫폼의 단편화를 줄여줌에 따라 보다 많은 어플리케이션 도입으로 이어졌습니다. 그리고 또 Linux는 호환성을 확보하기 위해 소프트웨어, 하드웨어, 디바이스 제조업자가 Linux에 공헌하게 되는 공유 R&D 시스템으로 이어져 나갔습니다.

 

 HDFS 단편화, 과도한 마진, 수상한 도구의 불필요한 기능에 대한 답답한 마케팅에 지쳐 있던 고객들의 시장에 Linux 같은 역할로 뛰어 나갈 준비가 되어 있습니다. 오늘날도 아직 독점적인 Unix 운영 시스템은 넓게 사용되어 오고 있습니다. 독점적인 파일 시스템에 대해서도 분명 같은 얘기를 있을 것입니다. 오래된 제품은 죽지 않습니다, 단지 관련성을 잃을 뿐인 것입니다.

 

 Eric HDFS 경제성, 데이터 처리의 대역폭과 신뢰성을 강조하였습니다. 기능 레벨에서는 우수한 보안, 내장애성, 고가용성 (그렇습니다, 이것은 SPOF 문제를 해결해 줍니다. CDH4 다운로드는 여기서!) 추가합니다. HDFS 제공하는 엔터프라이즈 고객용 기능보다도 아마 중요한 것은,

  • 선택 - 고객은 임의의 거대 하드웨어 벤더와 협력하여 가능한 한 최적의 비용으로 손에 넣을 수 있습니다. 결정권은 고객에게 있는 것으로, 벤더가 번들로 하기로 결정한 것이 아닙니다.
  • 이식성 - 고객은 클러스터 재포맷이나 대량 데이터를 복사할 필요 없이 HDFS 기반의 Hadoop 분산에서 다른 HDFS 기반의 분산으로 옮길 수 있습니다. 만약 페타바이트 데이터를 가지고 있을 경우, 이런 이식성은 매우 중요합니다. 만약 이식성이 없다면, 다음 리뉴얼 교섭 때, 벤더는 믿기 어려울 정도의 힘을 가지게 됩니다.
  • 공유의 업계 R&D - 저희는 Cloudera에서 개개인의 사원에 의한, HDFS에 대한 개별 공헌을 자랑스럽게 생각합니다. 우리는 모두 Hortonworks의 동업자들과 협력하고 있습니다. 하지만 오늘날에는 IBM, 마이크로소프트, VMWare가 각 회사의 제품을 향상시키기 위해 HDFS에 공헌하고 있는 것을 발견할 수 있겠죠. 이 후에는 하드 드라이브, 네트워크, 서버 등의 벤더도 자사의 제품이 HDFS에 최적화 가능하도록 HDFS에 패치를 추가할 것으로 저는 예상하고 있습니다.

 역사가 완전 같은 방식으로 반복되는 일은 매우 드문 일로, 이건 HDFS에 대해서도 마찬가지 입니다. 오늘날 HDFS는 컨텐츠용 스토리지(Content Addressable Storage)나 니어 라인 아카이브(nearline archive)로써는 최적의 파일 시스템이 아닐지도 모릅니다. 하지만 Linux가 노트북이나 라우터(네트워크에서 데이터의 전달을 촉진하는 중계 장치), 휴대폰이나 공항의 키오스크 단말에 사용되는 등의 일을 15년전에 누가 상상이나 했을까요?

 

 Linux는 우리에게 지도를 그려주었습니다. 현명한 투자가는 이미 뒤따라오고 있습니다.

 

관련 글

 

 CDH4.1의 컬럼 베이스 저널링 (일어 원문사이트)

 

 MR2와 YARN에 대한 짧은 해설 (한국어 번역글)

 

 Cloudera 5주년! (일어 원문사이트)

 

 

Posted by 이슈타르네스
TAG cloudera, HDFS

[Cloudera 블로그 번역] MR2와 YARN에 대한 짧은 해설

 

일어 원문 : http://www.cloudera.co.jp/blog/mr2-and-yarn-briefly-explained.html - 일본 Cloudera Blog

영어 원문 : http://blog.cloudera.com/blog/2012/10/mr2-and-yarn-briefly-explained/ - 미국 Cloudera Blog

 

- 본 글은 위 일어 원문 링크의 글을 번역하였습니다.

- 일어 원문 글은 위 영어 원문 글을 번역한 글입니다.

 


 

 

 MapReduce에 대해 배울 수 있는, Cloudera 개발자 트레이닝

본 글은 Cloudera 커스터머 오퍼레이션즈 엔지니어 Harsh Chouraria가 쓴 글을 번역한 것입니다.

 

 CDH4 이후, Apache Hadoop의 컴포넌트는 Hadoop 사용자에 대응하여 두 가지 새로운 용어를 도입했습니다. MR2와 YARN입니다. 아쉽게도 이 용어들은 혼동되어 있어 많은 사람들이 혼란스러워하고 있습니다. 두 개는 같은 의미일까요, 다른 의미일까요?

 

 본 글은 이들 두 가지 용어를 명확하게 하는 것이 목표입니다.

 

YARN이란?

 

 YARN은 "Yet-Another-Resource-Negotiator"를 의미합니다. 이것은 임의의 분산처리 프레임워크나 어플리케이션의 작성을 쉽게 만드는 새로운 프레임워크입니다.

 

 YARN은 범용적인 분산어플리케이션 개발이나, 그런 어플리케이션에서 오는 (메모리나 CPU와 같은) 리소스 요구의 핸들링, 스케줄링을 실시하여, 실행을 감독하기 위한 데몬과 API를 제공합니다.

 

 YARN의 실행 모델은 이전의 MapReduce 구현보다도 범용적인 것입니다. YARN은 오리지널 Apache Hadoop의 MapReduce (MR1이라고도 부름) 와는 달리, MapReduce 모델에 따르지 않는 어플리케이션을 실행할 수 있습니다.

 

MR2란?

 

 YARN의 출현으로, 잡을 실행하는 단일의 JobTracker와 잡 태스크를 실행하기 위한 TaskTracker는 이제 사용할 수 없습니다. 기존 MR1의 프레임워크는 YARN상에 서밋(submit)된 어플리케이션 안에서 실행되도록 고쳐 쓰여졌습니다. 이 어플리케이션은 MR2 혹은 MapReduce 버전2로 이름 붙여졌습니다. 이것은 실행플로우 (예를 들면 태스크 스케줄링이나, 투기적 실행(speculative execution)의 핸들링, 장애처리 등)를 살피는 ApplicationMaster를 경유하여 각 잡이 자신의 운명을 컨트롤하는 경우를 빼고는, 실은 많이 봐온 MapReduce 실행입니다. 이것은 단일의 JobTracker가 모든 리소스 관리, 스케줄링, 태스크 감시 작업을 실행하는 MR1과 비교하여 보다 분리되어 있고 확대축소 가능한(scalable) 모델입니다.

 

 MR2와 DistributedShell이라 불리는 새로운 컨셉을 실증하는 어플리케이션은 CDH4의 YARN API를 사용하는 최초의 두 가지 어플리케이션입니다.

 

요약

 

 YARN이 어떤 형태의 분산 어플리케이션이라도 실행할 수 있는 범용적인 플랫폼인 반면, MR2는 그 중 하나의 어플리케이션으로 YARN상에서 동작하는 MapReduce 프레임워크입니다. 이 주제에 관한 보다 많은 내용은 여기를 확인 해 주세요.

 

 

관련 글

 

 CDH5와 Cloudera Manager 5가 릴리즈 되었습니다! (일어 원문사이트)

 

 Spark 활용하기 : 빅데이터 어플리케이션용 고속 인메모리 컴퓨팅 (한국어 번역글)

 

 왜 우리들은 HDFS상에 플랫폼을 구축하는가 (한국어 번역글)

 

 

Posted by 이슈타르네스
TAG cludera, mr2, yarn

[Cloudera 블로그 번역] 2014/03/07 Spark 활용하기 : 빅데이터 어플리케이션용 고속 인메모리 컴퓨팅

 

일어 원문 : http://www.cloudera.co.jp/blog/putting-spark-to-use-fast-in-memory-computing-for-your-big-data-applications.html - 일본 Cloudera Blog

영어 원문 : https://blog.cloudera.com/blog/2013/11/putting-spark-to-use-fast-in-memory-computing-for-your-big-data-applications/ - 미국 Cloudera Blog

 

- 본 글은 위 일어 원문 링크의 글을 번역하였습니다.

- 일어 원문 글은 위 영어 원문 글을 번역한 글입니다.

 


 

 

 Apache Spark (incubating)을 서포트 하는 Databricks에서 아래와 같은 게스트 글을 기고 받았습니다. Cloudera와 Databricks는 최근에 CDH내에서 Spark를 제공하고 지원 하겠다고 발표 했습니다. 앞으로 Spark 내부 아키텍처나 Spark + CDH 사용법 등을 블로그 기사로 소개 해 드릴 예정입니다.

 

 Apache Hadoop은 매우 낮은 코스트로 방대한 양의 데이터를 저장하고 처리 할 수 있도록 하여 빅데이터 처리에 혁명을 가져 왔습니다. MapReduce가 시스템 로그 분석부터 ETL 실행, Web 인덱스 작성, 개인 추천 시스템의 실행 기반에 이르기까지 복잡한 배치 어플리케이션을 구현하기 위한 이상적인 플랫폼이라는 것은 이미 증명 되었습니다. 하지만, 내장애성과 단일 패스 계산 모델을 제공하기 위해 영속적 스토리지에 의존 하는 점 때문에, MapReduce는 로우 레이턴시(저 지연)의 어플리케이션이나 기계학습, 그래프 알고리즘 등에서 사용하는 반복적인 계산 처리에는 적합하지 않습니다. 


 Apache Spark는 성능과 편의성을 극적으로 향상시키면서, MapReduce의 계산 모델을 일반화 하여 이러한 제한 사항들에 대처 하고 있습니다.

 

Spark로 신속, 간단하게 빅데이터 처리

 

 기본적으로 Spark는 Mapper, Reducer, JOIN, GROUP BY, 필터 등의 임의의 연산자에 의해 어플리케이션을 쓸 수 있도록 하는 프로그래밍 모델입니다. 이 조합에 의해 반복되는 기계학습, 스트리밍, 복잡한 쿼리, 배치 등 넓은 영역을 간단히 표현 할 수 있습니다.

 

 또 Spark는 연산자 각각이 생성하는 데이터를 추적하여 어플리케이션이 확실히 메모리 내에 이 데이터를 보존 할 수 있게 합니다. 이로 인해 어플리케이션은 높은 코스트의 디스크 접근을 피할 수 있기 때문에, 이 점이 Spark 성능의 키 포인트라 할 수 있습니다. 아래 그림에 나타나는 바와 같이 이 기능에 의해 아래 항목들이 가능하게 됩니다.


 ・ 메모리내 작업 데이터셋을 캐시하여, 메모리 속도로 계산을 실행함으로써 로우 레이턴시 계산

 ・ 뒤에 따르는 반복 처리의 공유 데이터를 메모리상에 유지 하거나, 반복하여 같은 데이터셋으로 접근함에 따른 효율적인 반복 알고리즘

 

 

 Spark의 사용 편의성은 유저가 많은 Map과 Reduce 처리에 매이지 않고 어플리케이션을 구축할 수 있다는 일반적인 프로그래밍 모델로부터 유래 합니다. Spark의 병렬 프로그램은 순차 프로그램과 매우 닮아 있어, 그에 따라 개발과 리뷰를 간단히 할 수 있습니다. 마지막으로 Spark에 의해 유저는 단일 어플리케이션으로 배치 처리, 인터랙티브 처리, 스트리밍 잡을 간단하게 구성 할 수 있습니다. 그 결과, Spark 잡은 Hadoop 잡에 비해 1/2 부터 1/10의 코드 양으로 최대 100배까지의 속도로 실행 할 수 있습니다.


고도 데이터 분석과 데이터 사이언스를 위한 Spark 이용

 

인터랙티브한 데이터 분석

 

 Spark의 가장 편리한 기능 중 하나는 인터랙티브(대화형) 쉘 입니다. 이것으로 유저는 바로 Spark 성능을 시험 해 볼 수 있습니다. IDE도 코드 컴파일도 필요 없습니다. 쉘은 데이터를 인터랙티브하게 탐색하거나, 개발 중의 어플리케이션 중 일부를 테스트 하기 위한 주요한 툴로 사용 가능합니다.

 

 아래의 스크린샷은 유저가 파일을 로드하고, 'Holiday'를 포함하는 행 수를 카운트하는 Spark Python 쉘을 보여 줍니다.

 

 

 이 예에서 나타나듯이 Spark는 HDFS로부터 데이터를 읽고 쓸 수 있습니다. 이와 같이, Hadoop 이용자는 Spark를 인스톨 하면 바로 HDFS 데이터 분석을 시작 할 수 있습니다. 그리고, 메모리 내의 데이터셋을 캐시 해서 유저가 대화식으로 여러 종류의 복잡한 계산을 실행 할 수 있습니다!


 Spark는 스탠드얼론 어플리케이션을 위한 Scala 쉘 및 Java, Scala, Python으로 API를 제공 합니다.


보다 빠른 배치

 

 Spark 초기 구현 중에는 기존의 MapReduce 어플리케이션의 성능을 개선 할 방법에 초점을 맞춘 것도 있었습니다. MapReduce는 실제로는 범용적인 처리 플레임 워크로, 코어 Hadoop에서 가장 잘 알려진 구현에만 한하는 것은 아니라는것을 기억 해 주세요. Spark도 MapReduce를 제공하며 Spark는 메모리를 효율 좋게 쓸 수 있기 때문에 (필요하다면 장애를 복구하기 위한 계통을 사용한다고 해도), 반복 처리 프로그램에서 캐시를 쓰지 않아도 Spark의 MapReduce 구현 중 몇 가지는 Hadoop의 MapReduce와 비교해서 정말 빠릅니다.


 아래 예는 MapReduce의 가장 유명한 예인 워드 카운트의 Spark 구현을 보여줍니다. 여기서 Spark는 연산자 체인을 지원하고 있는 것을 알 수 있습니다. 이것은 데이터 필터링을 복잡한 MapReduce 잡 실행 전에 행하는 등, 데이터 전처리나 후처리를 행할 때 매우 편리합니다.

 

 

 

 Spark의 배치 처리 능력은 현실 세계의 시나리오에서 증명 되었습니다. 한 매우 거대한 실리콘 벨리의 인터넷 기업은 모델의 트레이닝 파이프라인에 있어서 특징량 추출을 구현한 하나의 MR 잡을 그대로 이식한 것 만으로 3배의 속도 개선을 꾀할 수 있었습니다.


반복 알고리즘

 

 Spark는 유저나 어플리케이션이 명시적으로 cache() 오퍼레이션을 호출 하는 것으로 데이터 셋을 캐시 할 수 있습니다. 이것은 어플리케이션이 디스크가 아닌, RAM에서 데이터로 접근 할 수 있다는 것을 의미 하는 것으로, 이에 따라 같은 데이터셋에 반복해서 접근하는 반복 알고리즘 성능을 극적으로 개선 할 수 있습니다. 모든 기계학습과 그래프 알고리즘은 본질적으로 반복적이도록, 이 유즈케이스는 어플리케이션의 중요한 영역을 커버 하고 있습니다.

 

 

 세계 최대급의 인터넷 기업 두 곳이 광고 타겟팅과 컨텐츠 추천을 제공하기 위해 Spark의 효율적인 반복 실행을 활용하고 있습니다. 로지스틱 회귀와 같은 기계학습 알고리즘은 기존 Hadoop 기반의 구현과 비교하여 100배 빠르게 실행 할 수 있습니다. (오른쪽 그림을 봐 주세요). 한편 협조 필터링이나 ADMM(alternating direction method of multipliers) 과 같은 알고리즘에서는 15배 고속화에 머물렀습니다.

 

 

 아래의 예는 다차원 특징 공간내의 점의 두 부분을 분리하는 가장 좋은 초평면을 찾아내기 위해 로지스틱 회귀를 사용하고 있습니다. MapReduce 중 각 이터레이션에서는 디스크로부터 데이터를 읽어 들여 거대한 오버헤드가 발생하는 한편, Spark에서는 캐시된 데이터 셋을 'points'가 메모리로부터 반복 접근 하고 있는 점에 주의 해 주세요.

 

 

실시간 스트림 처리

 

 자유롭게 쓸 수 있는 로우 레이턴시 데이터 분석 시스템이 손에 있을 때, 그 엔진을 라이브 데이터 스트림 처리로 확장하는 것은 당연한 일입니다. Spark에는 스트림 조작을 위한 API가 있어 정확히 한 번 뿐인 시멘틱과 stateful(상태유지) 연산자의 완전 복구를 제공합니다. 스트림 처리에 같은 Spark API를 제공하고 있어 보통의 Spark 어플리케이션 코드를 재이용 할 수 있다는 명확한 이점도 있습니다.


 아래의 코드는 해쉬태그로 시작하는 단어의 워드 카운트를 10초마다 데이터에 대해 필터 처리하도록 하는 심플한 네트워크 스트림 처리 잡을 보여 주고 있습니다. 전의 워드 카운트 예와 비교 해 보면 거의 같은 코드가 사용되어 있다는 것을 알 수 있지만 이번에는 라이브 데이터 스트림을 처리하고 있습니다.

 

 

 Spark Streaming API가 릴리즈 되고 나서 아직 1년도 지나지 않았지만, 유저는 그 API를 사용한 어플리케이션을 실제 환경에 도입함으로써 시스템 로그를 집약한 stateful 데이터에 대해 감시와 알림을 제공하고, 불과 몇 초의 레이턴시 만으로 매우 빠른 처리를 달성하고 있습니다.

 

의사 결정의 신속화

 

 많은 기업은 추천 시스템, 광고 타겟 설정 혹은 예측 분석의 형태로 유저의 의사결정 혹은 의사결정의 촉진을 위해 빅데이터를 사용하고 있습니다. 어떤 의사결정에 있어서든 중요한 요소는 레이턴시입니다. 즉, 입력 데이터가 이용 가능하게 되고 나서부터 의사결정을 실행하기 까지 걸리는 시간을 말합니다. 의사결정의 기다리는 시간을 줄이는 것은 폭넓게 그 유효성을 높여 최종적으로는 기업의 투자대효과(ROI)를 늘릴 수 있습니다. 이런 결정들의 대부분은 (예를 들어 기계학습이나 통계적 알고리즘 등의) 복잡한 계산에 기반하고 있기 때문에 Spark가 의사결정을 스피드업 하기 위해 이상적이라는 것을 알 수 있습니다.


 당연한 얘기겠지만, Spark는 기다리는 시간을 절감하기 위한 것 뿐만 아니라 결정의 질을 향상 시키기 위하여 이용 되고 있습니다. 예를 들면, 광고 타겟팅에서 인터넷 상에서의 영상 전송의 품질을 향상 시키기 까지의 폭넓은 범위에 적용되고 있습니다.

 

통일된 파이프라인

 

 오늘날 빅데이터의 대부분은 MapReduce뿐 아니라 스트리밍, 배치, 인터랙티브 처리 플레임워크를 통합함에 따라 전개 되고 있습니다. 많은 시스템을 Spark로 바꿈으로써 유저는 데이터 처리 파이프라인의 복잡함을 극적으로 절감 시킬 수 있습니다.


 예를 들면, 오늘날 많은 기업은 MapReduce를 사용하여 리포트를 생성하고 이력 쿼리에 대해 답하고 별도의 시스템을 구축하여 리얼타임으로 중요한 메트릭스를 추적하기 위한 스트림 처리를 실행 하고 있습니다. 이 방법은 2가지의 다른 계산 모델 어플리케이션을 개발하는 것 뿐 아니라, 2개의 다른 시스템의 유지 관리도 필요로 합니다. 또, 2개의 스택으로 생성되는 결과에 일관성이 있다는 것을 보증할 필요성도 생기겠죠 (예를 들어, 스트리밍 어플리케이션과 MapReduce에 의해 계산된 카운터가 같은지 어떤지).


 최근에는 유저가 이력 리포트를 제공하기 위한 배치 처리 뿐 아니라, 스트림 처리를 구현하기 위해 Spark를 이용하고 있습니다. 이에 따라 디플로이와 보수를 간소화 할 뿐만 아니라, 어플리케이션 개발을 극적으로 심플하게 할 수 있습니다. 같은 코드로 처리하고 있는 것이라면, 리얼타임과 이력 메트릭스의 일관성을 유지 하는 것은 문제가 되지 않습니다. 통일화의 마지막 이점은, 다른 시스템 간에서의 데이터 이동이 불필요 하게 됨에 따른 성능 향상입니다. 일단 메모리 상에 보존 되면 그 데이터는 스트리밍 처리와 이력 (혹은 인터랙티브한) 쿼리 사이에서 공유 할 수 있습니다.

 

당신의 차례 : 시작합시다

 

 Spark로 파워풀한 빅데이터 어플리케이션을 만드는 일이 매우 간단 해 집니다. 당신이 이미 가지고 있는 Hadoop과 프로그래밍 스킬에 의해 몇 분만에 생산적으로 데이터를 활용 할 수 있겠죠. 시작 한다면 지금입니다


 다운로드 : http://spark.incubator.apache.org/downloads.html

 퀵스타트 : http://spark.incubator.apache.org/docs/latest/quick-start.html

 

Posted by 이슈타르네스

[Cloudera 블로그 번역] 2014/01/07 Impala 와 Hive 전략에 관해서

 

일어 원문 : http://www.cloudera.co.jp/blog/20140107-impala-v-hive.html - 일본 Cloudera Blog

영어 원문 : http://vision.cloudera.com/impala-v-hive/ - 미국 Cloudera Blog

 

- 본 글은 위 일어 원문 링크의 글을 번역하였습니다.

- 일어 원문 글은 위 영어 원문 글을 번역한 글입니다. 번역투가 많아 영어 원문도 살짝 참조하였습니다.

 


 


 새해 복 많이 받으세요. 여러분들 덕분에 올해도 무사히 새로운 한 해를 맞이할 수 있게 되었습니다.

 

 자 그럼, 올해 첫 블로그 기사는 작년말에 CSO (Chief Strategy Officer) Mike Olson(@mikeolson)이 공개한 블로그 포스트, Impala v Hive를 소개하려 합니다. 2014년도 잘 부탁 드립니다.

 

 


 

 저희 회사는 일 년여 전에 Cloudera Impala를 공개 했습니다. 회사에게 있어 좋은 런칭 이었죠. 플랫폼에서 고객들이 중요하게 여기는 몇 가지 점들이 더욱 좋아졌고, 사업면에서 큰 성과를 거둘 수 있게 되었습니다. 이전의 제품은 대화형 SQL 처리량에 대응하지 못 했거든요.

 

 Impala 공개의 영향으로 Apache Hadoop 에코시스템에서 SQL 시장의 공유를 바라는 벤더들 간의 격한 경쟁에 불을 붙여 여러 주장과 반론이 난무했습니다. 성능 면에서 과장된 말들이 자주 보이는데 (저희는 저희의 성능 평가 결과가 꽤 마음에 들었습니다만) 여기서는 다른 방향에서 이 문제에 대해 접근 하려 합니다.


 저는 기존 Apache Hive 프로젝트 개선에 의한 것이 아니라, 새로운 프로젝트로 처음부터 Impala를 개발하게 된 Cloudera의 결정에 대해 자주 질문을 받습니다. 사람들은 기존의 코드가 있다면 거기서부터 출발 하는 것이 최선이라고 생각하니까요.

 

 하지만 그것은 틀립니다. 저희는 그 문제에 대해 장기간 진지하게 생각 했고, 최선의 방법은 Hive와는 다른 원리를 기반으로 새로운 오픈소스 프로젝트를 설계하는 것이라고 결론 내렸습니다. 그게 바로 Impala 입니다. 작년 1년간 저희의 경험은 이 전략에 대한 확신을 강하게 만들었습니다.
 어떤 것인지 한 번 보시죠.

 

Pig와 Hive 의 기원

 

 Hadoop 초창기 버전은 데이터를 다루기 위한 방법으로는 오직 한가지, MapReduce만 지원 했습니다. 이 플랫폼은 대량 데이터를 저장, 처리, 분석 할 목적으로 Yahoo! 와 Facebook 에서 넓게 사용 되었습니다. 두 회사 모두 이 플랫폼의 가치를 잘 이해했지만, 시스템에서 유용한 성과를 얻기 위해 MapReduce에서 동작하는 Java 코드를 짜는데 많은 시간이 필요 했습니다.

 

 두 회사는 보다 빠르게 동작하고, 비개발자가 데이터를 직접 다룰 수 있기를 원했습니다. Yahoo!는 이를 위해 Apache Pig란 명칭의 독자 언어를 만들어 냈습니다. Facebook은 사람들에게 새로운 기술을 교육하는 것 보다 기존 기술을 활용하는 방안을 생각하여 Hive 라는 명칭의 SQL 시스템을 구축 했습니다.


 이 두 가지는 매우 흡사한 원리로 동작합니다. 유저는 Pig 나 Hive 중 하나로 쿼리를 날립니다. 파서(parser)는 쿼리를 읽어 들여 유저가 무엇을 바라는지를 이해하고, 일련의 MapReduce Job을 실행하여 동작하게 합니다. MapReduce를 사용함으로써, Pig와 Hive를 쉽게 구축 할 수 있었기 때문에 Yahoo! 와 Facebook의 엔지니어는 다른 새로운 기능에 시간을 쓸 수 있었습니다.


역사의 대상

 

 보통 Hadoop에 대한 비판은 MapReduce가 배치(batch) 데이터 처리 엔진이란 것입니다. Hadoop은 데이터 매니지먼트 업계를 근본적으로 변화 시키는, 굉장히 유용한 배치 데이터 처리 엔진임은 분명합니다. 하지만 설계상 MapReduce는 매우 무거운데다, 하이 레이턴시(high-latency) 실행 플레임워크입니다. 또, job 개시가 느리고 여러 종류의 오버헤드를 갖고 있다는 것은 공정한 비판이라고 생각합니다.
 Pig와 Hive는 이들 특성을 이어 받고 있습니다.

 

 초기에 이런 것들은 별 문제 되지 않았습니다. 분석이나 보고를 위해 자신의 BI 툴을 Hadoop과 연결하는 사람은 없었습니다. Yahoo!와 Facebook은 보다 많은 유저가 데이터를 직접 다룰 수 있기를 원했습니다. 그 유저들이 동작이 실행 되고 있는 사이에 컴퓨터 화면을 보면서 잠시 가만히 앉아 있어야 해도 그리 큰 문제는 아니었습니다. 느린 쿼리라도 쿼리가 없는 것 보다는 나으니까요. 이런 초기 워크로드의 대부분은 데이터 변환 처리일 뿐 쿼리도 분석도 아닙니다. 배치는 이 부분에 대해서는 문제 없었습니다.


 관계형 데이터 베이스에 데이터를 전송 하기 위해 ODBC나 JDBC를 이용하는 툴은 많은 벤더를 통해 입수 할 수 있습니다. 하지만 이런 툴을 Hadoop에서 동작 하도록 하는 것은 정말 큰 문제입니다. 데이터를 이런 방법으로 쉽게 다루고 싶어하는 비즈니스 유저는 굉장히 많습니다.


 이에 저희는 먼저 광범위하게 이용 가능한 Hive용 ODBC 드라이버를 릴리즈 했습니다. 대형 벤더들은 보고용 툴을 저희 플랫폼에 연결 하기 위해 그 드라이버를 사용하였습니다. 하지만 이런 툴을 사용하는 것은 정말 참기 힘든 일이었죠. 유저는 쿼리를 작성하고 버튼을 누른 후 기다리고, 기다리고, 또 기다립니다. 몇 십 년에 걸친 경험에 의해 사람들은 데이터베이스에 실시간 반응을 기대하게 되었습니다. MapReduce 상에 구축된 Hive는 기대에 따른 결과를 낼 수 없었습니다.

 

 실제로 Hive 성능은 일부 벤더의 툴이 전혀 동작하지 않는 것을 의미 했습니다. 툴은 응답이 빨리 오지 않았을 때에 데이터베이스가 고장 났다고 여겨 유저에게 에러를 보냈습니다.
 이에 많은 유저들이 화를 냈습니다.


Impala 개발

 

 저희 회사에서는 Hadoop 에코시스템에서 SQL의 활용성에 중점을 두었고 차분히 대체 방안에 대한 작업을 시작했습니다.


 데이터베이스 업계에서는 스케일아웃 분산쿼리 실행 엔진의 구축에 관해 수십 년의 경험이 있습니다. 이는 학술 및 상용 연구가 활발한 분야입니다. 매우 우수하고 빠른 분산 SQL 시스템이 다수 존재 하지만, 그 중 어느 것도 MapReduce형 아키텍처를 사용하지 않습니다.

 

 여기서 저희는 Hadoop 아키텍처를 처음 만들어 낸 Google에 눈을 돌렸습니다. Google은 빅데이터로의 SQL 액세스를 얻기 위해, MapReduce 를 기반으로 하지 않는 독자적인 새로운 분산 쿼리 실행 엔진을 개발하고 있었습니다.


 저희는 모든 선택지를 깊이 생각한 후, Google과 완전 똑같은 일을 해보기로 선택했습니다.  성능에 대해서는 낙관적이었기 때문에 Impala라고 명명했습니다.


 동시에 프로젝트 리더로 Marcel Kornacker를 고용했습니다. Marcel은 한 때 Google에서 일한 적이 있었고, 또 1990년대에 캘리포니아 대학 버클리 캠퍼스 대학원에서 데이터베이스 시스템에 대한 연구를 했던 인물입니다. Marcel은 분산 시스템 및 데이터베이스 커널에 관해 숙련된 엔지니어 팀을 편성하여 개발에 착수했습니다.


 Cloudera 클러스터 내의 모든 노드에는 Impala 코드가 들어가 있어 SQL 쿼리가 실행 되는 것을 기다립니다. 그 코드는 각 노드 상에서 바로 MapReduce 엔진과 함께 - 그리고 Apache HBase 엔진 (MapReduce 를 기반으로 하지 않는), 검색엔진 (MapReduce를 기반으로 하지 않는) 및 고객이 선택해서 디플로이(deploy) 할 수 있는 SAS 및 Apache Spark 와 같은 서드파티 제품 엔진과 함께 동작합니다. 이들 엔진은 모두 완전 동일한 데이터로 접근 가능하며, 유저는 해결하려는 문제에 따라, 그 중 어떤 것을 사용할지 선택 할 수 있습니다.


 Impala는 SQL 쿼리를 오늘날 Hive가 의존하고 있는 map/shuffle/reduce 등의 다른 처리 플레임워크로 번역할 필요가 없습니다. 이 때문에 Impala는 그들 단계에서 받는 레이턴시의 영향을 받지 않습니다. Impala 쿼리는 바로 결과를 돌려줍니다. Impala는 MapReduce와 같은 범용 분산 처리 시스템과는 달라, SQL 쿼리 실행에 관해서 처음부터 설계 되어 있기 때문에 그 특정 워크로드에 대해서는 굉장히 우수한 성능을 제공할 수가 있는 것입니다.

 

왜 Hive를 개선하지 않는가?

 

 

 단도직입적으로 말해, Hive는 리얼타임 분산 SQL 처리에 있어서는 틀린 아키텍처이기 때문에 저희는 Impala 개발을 선택했습니다. 병렬 SQL 데이터베이스 업계는 포화 상태입니다. 어느 전통적인 관계형 데이터베이스 벤더도 (즉 IBM, Oracle, Microsoft, ParAccel, Greenplum, Teradata, Netezza, Vertica) MapReduce와 같은 것은 사용하지 않습니다.

 

 shared nothing 으로 스케일 아웃 하는 시스템의 차세대 (지명도가 높은 것은 Google의 F1 이지만, 이 외에도 그렇게 알려지지는 않은 NuoDB 등의 선택지도 있습니다) 는 모두 MapReduce 기반이 아닌 네이티브 분산 쿼리 실행에 의존하고 있습니다.

 

 

 Facebook은 초기에 MapReduce 상에 Hive를 구축했지만, 그건 Hadoop SQL 로 최단의 길이었기 때문입니다. 시간 요건을 전제로 했을 때에 현명한 결단이었죠. 하지만 이 회사는 최근 SQL 을 통한 데이터로의 리얼 타임 접근을 위한 차세대 쿼리 실행 엔진인 Presto 를 발표 했습니다. Presto는 Impala와 같이 분산 쿼리 실행 엔진으로써 새로 처음부터 구축 되었습니다.

 

 

 Hive를 개선, MapReduce 튜닝 외 고속화 및 레이턴시 단축은 확실히 가능합니다. 하지만 Hive는 설계상 항상 오버헤드가 존재합니다. 또 네이티브 분산 SQL 엔진으로써 구축된 후속 시스템이 회피하는, 성능에 불리한 조건이 발생합니다.

 

 

 Hive를 잘 실행하기 위해 MapReduce를 튜닝 하는 것은 잘못된 일입니다. MapReduce는 범용 배치 처리 워크로드에 뛰어나며, MapReduce를 특정 쿼리 워크로드로 특수화 하는 대책은 SQL을 쓰지 않는 유저에게 있어 부담을 더하는 일이 될 수 있습니다. 초기에는 단일 엔진이 Hadoop상에서 모든 작업을 실행한다는 생각은 의미가 있었습니다. 오늘날에는 (Hbase, Apache Accumulo, Search, Myrrix, Spark 그 외의) 전용 엔진이 급증하고 있습니다. 이것은 대체로 각 엔진이 특별히 튜닝 되어 있는 다른 워크로드를 희생 시키는 일 없이 플랫폼 기능을 확장합니다.

 

Impala 커뮤니티

 

 Cloudera에서는 2012년 후반 Apache 소프트웨어 라이센스에서 발표하기 전까지 거의 2년간 Impala에 몰두 해 왔습니다. 저희가 그렇게 한 것은 Hadoop 상에서의 리얼 타임 SQL이 중요한 문제라고 생각 했기 때문입니다. 그리고 저희는 실제로 제품을 전달 할 수 있기 전까진 저희의 의도를 나타내고 싶지 않았습니다. 저희 회사에는 Impala 개발에 전념하는 중요한 팀이 있습니다.


 Hive는 리얼타임 SQL용의 최신 분산 쿼리 엔진과 성능 면에서 경쟁할 수는 없습니다. 하지만 Hive 에코시스템에는 MapReduce에 의존하지 않는 구성요소가 있습니다. 저희 회사는 그것들을 Impala와 통합 하는 일에 전념 해 왔습니다. 그리고 이런 성과로 Hive 기능 강화에 계속 공헌하고 있습니다.

 


 예를 들면 메타데이터 레파지토리로써 HCatalog나 Hive 메타스토어 커뮤니티와 협력하고 있습니다. 다수의 다른 엔진 간에서 데이터를 공유하는 것은 그것을 기술하는 메타데이터 공유를 필요로 하며, HCatalog는 저희 회사의 엔터프라이즈 데이터 허브 전략의 핵심 부분을 이룹니다. 저희 회사에 따른 Hive 메타스토어나 HCatalog의 이용은 Hive, Impala, MapReduce, Pig 및 REST의 각 어플리케이션이 테이블을 공유 할 수 있는 것을 의미합니다.


 Twitter 사, Cloudera 및 Criteo 사는 Impala가 애널리틱스 데이터베이스 워크로드를 훨씬 빠르게 실행 할 수 있도록 하는 Columnar format 인 Parquet(파케이) 로 협력하고 있습니다. 기여하고 있는 사람들은 Parquet 를 Cascading, Pig, Hive 까지와도 통합하려 하고 있습니다.


 데이터베이스 어플리케이션에서 유저 베이스 및 롤 베이스 인가와 접근 제어는 중요합니다. Cloudera는 Impala를 위한 보안 정책을 정의하고 적용하기 위해 Sentry 프로젝트를 만들어 Oracle이나 그 외 벤더와 협력하고 있습니다. Sentry가 없으면 각 Hive 유저는 다른 여러 Hive 유저에 속하는 모든 테이블과 모든 레코드를 참조 해 버릴 수 있게 됩니다. 저희 회사는 Sentry를 Hive 에 통합하기 위한 코드에 기여 해 왔습니다. 하지만 아직 상용 배포에는 포함되어 있지 않습니다.

 

누가 Impala를 제공하는가?

 

 오픈 소스는 엔터프라이즈 유저가 소프트웨어와 서비스의 최고의 조합을 최선의 가격으로 제공하는 기업과 함께 일할 수 있는 것을 의미 하는 것으로 훌륭한 일입니다. 엔터프라이즈 유저는 단일 벤더에게 구애받지 않습니다.


 Impala가 성공하기 위해선 다수의 기업이 제공하고 지원 해야만 합니다.

 


 물론 여러분은 Impala를 Cloudera에서 받을 수 있습니다. Impala는 저희 회사 플랫폼의 중요 핵심이자, 저희 회사 엔터프라이즈 데이터 허브 전략의 중요 부분입니다. Impala는 저희 회사의 재판매업자로부터도 구입 가능합니다. Oracle은 Big Data Appliance에 있어서 Impala를 포함하는 Cloudera의 완전한 엔터프라이즈 데이터 허브 소프트웨어 세트를 제공하고 있습니다. IBM의 Softlayer 자회사 Verizon Business Systems, CenturyLink Savvis, T-Systems 그 외를 포함하는 클라우드 벤더가, 각 회사가 관리하는 클라우드 내에서의 '서비스형 엔터프라이즈 데이터 허브'를 제공하고 있으며 그 안에는 Impala가 포함되어 있습니다.


 Amazon은 Elastic MapReduce 또는 EMR 이라 불리는 독자적인 빅데이터 서비스를 제공하고 있습니다. 마침 지난주 Amazon은 MapReduce 및 HBase와 함께 그 회사의 EMR 제품의 일부로써 포함되는 서드파티 제품 엔진으로 Impala 제공을 발표 했습니다. Amazon의 지지는 저희 회사에겐 정말 멋진 일이었습니다. 이는 저희 회사의 아키텍쳐를 신뢰하고 있다고 여기는 증거이며, 잠재 유저를 새로 얻을 수 있는 일입니다. 마찬가지로 보다 많은 어플리케이션 및 툴 벤더가 Impala와 통합할 것을 의미합니다.


 제 견해로 가장 흥미 깊은 것은 Cloudera의 경쟁 상대가 지금은 고객에게 Impala를 제공하고 있다는 사실입니다. MapR의 고객은 그 회사의 상용 제품으로 Impala를 이용할 수 있습니다.


 5년 이상에 걸쳐 Cloudera는 Hadoop 에코시스템에 있어서 새로운 오픈 소스 코드를 구축하고 서비스하고 있습니다. 저희 회사는 아주 광범위한 프로젝트에 걸쳐 일하고 있는 공헌자와 커미터를 거느리고 있습니다. 저희 회사는 경쟁 상대에게 그 제품의 일부로 거론된 프로젝트 - Apache Flume, Apache Sqoop, Hue, Apache Bigtop - 을 생산 해 왔습니다.


 Impala는 그 리스트에 이어진 새로운 하나의 예에 지나지 않습니다. 또, 저희 회사 오픈 소스 플랫폼과의 관계가 깊고, 진짜라는 증거의 한 측면에 지나지 않습니다. 말로만 그런 것이 아니라, 저희는 초창기 때부터 스스로의 발언에 따라 살아 왔습니다. 여러분이 오늘날 저희 회사의 파트너와 경쟁 상대 양 쪽을 포함하는 8개 이상의 서로 다른 벤더로부터 Impala를 손에 넣을 수 있다는 사실은 저희 회사 오픈 소스 전략을 틀림없이 증명 하고 있습니다.

 

왜 이렇게 많은 SQL 엔진이 있는가?

 

 이 업계를 잘 보세요. 시장에 존재하는 벤더 수와 적어도 같은 수의 Hadoop에서 동작하는 SQL 엔진이 존재하고 있다는 걸 알게 될 겁니다. Cloudera는 Impala를 제공합니다. IBM은 그 회사의 BigSQL 제품을 좋아 하겠죠. Pivotal은 오로지 HAWQ에 커밋하고 있습니다. Hortonworks는 Hive에 충성을 선언 했습니다. 초기 참가자인 Hadapt은 NoSQL 워크로드도 받아 들이는 방향으로 야심을 확대 하였지만, 여전히 Hadoop 플레임워크 상의 SQL을 제공하고 있습니다. 이 외에도 아직 더 있습니다.


 이것은 기존의 관계형 데이터베이스 기업을 수십 년에 걸쳐 내몰아 온 것과 같은 원동력입니다. 모두가 표준 언어 구조를 구현하고 모든 벤더가 성능과 서비스 확대 면에서 경쟁합니다. 시장에는 이들 제품을 뭉개고 단일 제품으로 만들 수 있는 수 보다도 훨씬 많은 수의 기존 제품이 존재 합니다. 솔직히 말해서 너무 많은 액수의 자금을 벌어 들이고 있어 투자 공유를 내모는 것까지는 다다르지 않았습니다.

 


 그렇다고는 해도 좋은 소식이 있습니다. 이들 SQL, JDBC 및 ODBC 엔진에 데이터를 전송하는 어플리케이션은 이식 가능하며, 유저에게 어려운 일이 아닙니다. 저희는 오픈 소스는 기본 원칙이며 Impala가 승리한다고 믿고 있습니다. 그럼에도 언어 표준의 존재에 따라 자사제품과 연계하는 서드파티 제품에 의한 최고의 에코시스템과 결합된 성능 및 순수한 계산 능력, 이 두 관점에서 경쟁을 하지 않을 수 없다고 인식하고 있습니다. 이 경쟁의 원동력은 저희 회사의 고객에게 있어서도, 시장 전체에 있어서도 최선일 것입니다.

 

Pig 와 Hive는 어디로 가는가?

 

 Yahoo!가 작성한 데이터 플로우형 언어인 Pig는 기존 벤더와의 경쟁이 없습니다. 그 언어는 강력하지만 그 유저 기반은 대체가 되는 구현을 제공할 수 있는 대형 벤더의 주목을 모으기에는 너무 작습니다. Pig 쿼리를 실행하는데에 MapReduce 보다 뛰어난 방법은 존재 하겠지만, 그것이 지원하는 워크로드 (거의 대부분은 변환입니다) 를 기본으로 했을 때에 그것은 중요하지 않습니다. 이 소프트웨어는 현행의 형식으로 충분히 좋으며, Pig 커뮤니티는 그 기능을 계속 강화하고 있습니다.


 다른 한 편으로 Hive는 SQL 이고, SQL은 우주에서 가장 사용되고 있는 데이터베이스 언어입니다. 모두가 그것을 알고 있죠. 모두가 Hive가 빨라지는 것을 기대하고 있고 많은 기업이 Hive를 지원하고 있습니다.

 


 따라서, Hive는 확실히 치열한 경쟁 압력 아래에 놓여지게 됩니다. 보다 많은 대형 벤더가 시장에 참가함에 따라 그것은 착실히 악화 되어 갈 겁니다 저희 회사는 Hive 구현이 높은 성능의 대화형 쿼리 및 애널리틱스의 수요에 따라 갈 수 있을 거라고는 생각하지 않습니다. 아무리 엄하게 채찍질을 가한대도 말은 그만큼 빨리 나아갈 수 없습니다. 유저나 툴이나 어플리케이션을 제공하는 벤더는 보다 좋은 제품으로 옮겨 가겠죠.


 Hive는 데이터 처리 job을 잘 다룹니다. 또한 그 목적으로만 Cloudera의 고객이 넓게 사용하고 있습니다. 무엇보다 Hive는 과거 5년간, Cloudera의 상용 제품의 일부가 되어 왔으므로, Hive는 인스톨 하면 그대로 쓸 수 있기 때문에 저희 회사는 계속해서 Hive를 지원 할 것입니다. 특히 Impala와의 중복 영역을 위에 기재한 Hive Sentry 및 Parquet과의 통합의 장으로 만들려고 생각하고 있습니다.


 하지만 저희는 저희 회사의 엔터프라이즈 데이터 허브에 최상급 리얼 타임 오픈 소스 SQL 엔진을 보유할 필요가 있습니다. 데이터 분석, 리얼타임 쿼리 및 높은 성능의 SQL 어플리케이션에 관한 저희 회사의 장래를 향한 확신은 틀림없이 Impala에 있습니다. 물론 편향된 측면이 있었을지 모르지만, 그래도 저희는 Impala는 이미 Hadoop 에코 시스템에서 이용 가능한 SQL 제품으로서는 실로 최고의 제품이 되었다고 확신하고 있습니다. 고객이나 시장에 있어서 다른 기업이 Impala를 도입하는 것은 매우 기쁜 일 입니다. 또 앞으로 몇 몇 릴리즈로 공개될 서비스나 신기능을 기대 해 주시기 바랍니다.


 


 

Posted by 이슈타르네스

[LINE 블로그 번역] ‘캐쥬얼’한 규모의 데이터 클러스터상의 데이터 분석 처리

by just_do_neet on 2012.9.11

원문 출처 : http://tech.naver.jp/blog/?p=2127  - LINE Engineer's Blog

- 본 글은 위 링크의 LINE Engineer's Blog 를 번역 하였습니다.


LINE 서비스의 통계 분석 기반

 

 현재 저는 LINE의 통계 분석 기반 개발을 담당하고 있습니다. 기반자체는 일년도 전부터 운영되고 있으며, 저는 근래 작업으로 최근 1,2개월 정도는 주로 기반 데이터 구조 재검토와 튜닝을 담당하고 있습니다.

 

 LINE의 통계 분석 기반은, 많은 회사에서 이와 같은 시스템은 존재하겠지만, LINE의 로그 데이터나 RDB 데이터 등을 사용하여 주로 KPI에 참고되는 다양한 통계적 수치를 산출하여 표시 해 주는 시스템 입니다. 그 외에 서비스 운용을 위한 보조적인 기능 등도 몇 가지 있습니다.

 

 시스템 아키텍처에 관해, 특히 통계 처리에 관련한 처리 부분을 뽑아보면 아래와 같습니다.

Input

 

  • 유저의 조작 이력 로그

    • Redis Queue에서 취득 (Streaming)

  • 마스터 데이터 (유저 데이터, 스탬프 정보 등)

    • MySQL 에서 (Batch)

Processing 


Output

 

  • 각종 통계 결과

    • MySQL에 보존 (Batch)

 LINE 서비스는 일반적인Web 어플리케이션과는 아키텍처가 다르기 때문에 접속 로그와 같은 것은 존재 하지 않습니다. 그러므로 유저의 조작 이력 로그를 Redis Queue를 통해서 비동기로 취득하여, 그 쪽을 분석 대상으로 삼고 있습니다.
 또한 분석 처리는 주로 쓰는 조합입니다만, Hadoop과 Hive를 사용하고 있습니다.

직면 해 있던 문제
 감사하게도 많은 분들이 LINE 서비스를 사용하고 있습니다. 유저 증가에 비해서 백엔드 분석 기반으로 처리해야만 하는 데이터 사이즈도 크게 증가하고 있습니다.
 예를 들면, 유저 조작 이력 로그는 최근에는 하루에 약 700 GB 정도 사이즈를 차지합니다.

 

 

 이들 로그 데이터와 마스터 데이터를 합쳐서, 날마다 수십 종류 항목의 분석 처리를 실시하고 있습니다.


 이런 상황 때문에, 날마다 실시하는 데이터 분석 처리도 갈수록 시간이 걸리게 되어, 예를 들어 하루 한 번 실시하고 있는 큰 daily batch process는 최대 11시간반 정도의 시간이 걸리게 된 상태였습니다.

 

 

 거기서 이러한 문제를 해결 하기 위해서, 가능한 한 처리를 빨리 끝내도록 하는 분석 처리 튜닝을 실시할 필요가 있었던 것입니다.

 

튜닝에 앞서
 자 튜닝이다! 라고 단단히 마음 먹는 것은 좋습니다만, 실제 상황을 이야기 하자면 저는 팀에 막 합류한 시기로, 시스템에 뭐가 문제고 뭐가 느린건지를 정확히 파악하지 못하고 있었습니다. 이 때문에, 시작점으로서 우선은 정보를 눈으로 바로 확인 할 수 있게 하는 작업을 실행하였습니다.

 기존의 분석 기반에서는, 분석 처리의 거의 전부가 Python으로 쓰여 있어서, Python에서 Hive Thrift Server를 통해 HQL을 날리는 것으로 분석 처리를 실시하고 있었습니다. 물론 처리 로그 같은 건 비교적 제대로 출력, 보존 되고 있었습니다만, 예를 들어 각 분석 처리의 처리 시간이나 발생한 에러 등을 확인 하기 위해서는 서버에 로그인 할 필요가 있었습니다.
 이것들을 한시라도 빨리 눈으로 확인 할 수 있게 하기 위한 수단으로서 Hadoop과 친화성이 높은 워크 플로우 엔진으로 유명한 ‘Azkaban’을 채용하여 그 쪽에서 분석 처리 컨트롤을 행하도록 하였습니다.

 

 

 Azkaban에 대한 자세한 설명에 대해서는 이 글에서는 생략하지만, 본래 목적인 워크 플로우의 제어 이외에도 각각의 처리 실행 시간이 그래프로 가시화 되기 때문에 어느 처리가 느린 것인지를 특정하기가 편리합니다.
 그러므로, 기존의 분석 처리를 모두 Azkaban상에서 컨트롤 하도록 변경 하고, 처리 내용이나 소요된 처리 시간을 가시화 하여, 이것을 시작으로 튜닝 포인트를 찾기로 하였습니다.

 

튜닝 포인트
 처리 속도 상의 문제점으로 나타난 것은 아래와 같습니다.

  • 마스터 데이터 (MySQL)의 Hadoop, Hive 로의 import 처리가 느림

  • MapReduce 태스크의 가동수가 capacity(용량)을 넘고 있음

    • Hadoop 상의 데이터 구조에 문제

    • 애시당초 서버 리소스 부족

 우선, 데이터 import 처리입니다만, 마스터 데이터의 내용을 Hive에 반영하기 위해 정기적으로 데이터 갱신을 하고 있었습니다만, 그 처리가 single process로 동작하도록 되어 있어, 데이터 급증에 따른 처리 시간이 늘어나 있었습니다. 또한, Hadoop Cluster 대수를 늘리는 등의 방식으로 해결되지 않는 조정하기 어려운 구조였기 때문에 개선 작업이 급선무였습니다.


 근본적으로는 서버 증설 밖에는 대책이 없었습니다만, Hadoop 상에 보존되어 있는 데이터 구조에 몇 가지 개선 가능한 포인트가 있었기 때문에 그 부분을 손보았습니다.


Import 처리의 개선 (Sqoop)
 데이터 import에 대해서는Sqoop이라는 OSS를 채용 하였습니다.
 Sqoop은 현재는 Apache의 Top-Level Project 로서 개발이 진행되고 있는 OSS로, 주로 RDB와 Hadoop, Hive 간에 효율적으로 데이터 import, export를 실행하기 위한 툴입니다.
 기본적인 구조에 관한 그림은 Cloudera 블로그에서 인용하였습니다.

 

(출처 : http://www.cloudera.com/blog/2012/01/apache-sqoop-highlights-of-sqoop-2/

 Sqoop은 기본적으로 커맨드라인으로 동작하는 툴입니다. 몇 가지 옵션을 지정하면 꽤 괜찮게 RDB와 Hadoop, Hive 간의 import, export 처리를 해 줍니다.
 (참고 : Sqoop의 import 커맨드 옵션 일람)


 Sqoop에서 import 처리를 실행하면, MapReduce 의 Job (정확히는 Map Only) 이 기동하여, Map Task 중에 설정 내용에 따라 원래 데이터를 가지는 데이터베이스에 접속하여 dump를 하고, 그 결과를 직접 HDFS에 써넣는 방식으로 작동합니다.

 

 

(출처 : https://blogs.apache.org/sqoop/entry/apache_sqoop_overview
Import 처리 효율화 관점에서 말하자면, 아래 2가지가 고속화에 기여하고 있습니다.

  • 병렬적 import 처리가 가능

  • dump한 데이터를 직접 HDFS에 써넣을 수 있음

 Hadoop을 사용하여 비교적 간단히 병렬 import가 가능한 것도 편리하구요. 이러한 import 처리를 자신의 스크립트에 써두면 우선 로컬 파일상의 dump를 보존하여 이를 HDFS에 put하는 여러 단계의 처리를 거치는 경우가 많아, 특히 HDFS로 큰 파일을 put 하는 것은 아무래도 시간이 걸리는 작업이기 때문에 이러한 부분에서 시간을 절약합니다.
 그런 의미로, Hadoop이나 Hive에서 사용하는 데이터 import에는 Sqoop은 비교적 적합하다고 생각합니다.

튜닝 결과 (Sqoop)
 이번 Sqoop 도입에 의해 처리가 2시간 정도 고속화 되었습니다.

 

 

데이터 구조 개선
 이어서 데이터 구조 개선입니다.

 

 

 LINE의 통계 분석 기반에서는 Hive Table에서 다루는 데이터는 기본적으로는 TextFile 형식으로 보존되고 있었습니다. 물론 Text 형식인 편이 운용면에서는 여러가지 편리한 면도 있고, 이전에는 이걸로 성능적인 문제는 없었습니다만, 이 정도로 데이터가 커지고 나니 좀 더 효율적인 데이터 형식으로 변경할 필요가 있었습니다.
 또한, 다루는 데이터가 크기 때문에 데이터 압축에 대해서도 신경 쓸 필요가 있었습니다.
 이 외에도 데이터에 따라서는 한 파일 당 사이즈가 너무 작은 (HDFS의 한 블록 사이즈 보다도 극단적으로 작은) 것이 존재하고 있어 퍼포먼스에 악영향을 주고 있었습니다.

 이러한 몇가지 점을 착실히 개선 해 보았습니다.

 

TextFile->RCFile로의 마이그레이션
 우선은 Hive 처리에 적합하면서 또한, 데이터 사이즈를 가능한 한 작게 할 수 있는 파일 포맷을 선정합니다. 여러가지로 조사한 결과, 이번 케이스에서는 RCFile이라는 데이터 형식을 채용하는 것이 좋지 않을까 라는 결론이 나왔습니다.
 RCFile은 Hadoop (HDFS) 상에서, 예를 들어 Hive와 같이 구조적인 데이터를 다룰 때에 적합한 파일 포맷입니다. 자세한 내용은 아래 논문을 참조 바랍니다.

RCFile: A Fast and Space-efficient Data Placement Structure in MapReduce-based Warehouse Systems (ICDE’11)

 

 

 특히 개인적으로 좋았던건, 데이터 사이즈를 가능한 한 작게 만들기 위한 고민이 여기저기 녹아 있는 점입니다. 메타데이터의 run length 부호화도 그렇고, 동일한 컬럼 단위로 데이터가 보존되어 있기 때문에 연속해서 같은 경향의 데이터가 출현할 확률이 높아, 압축 알고리즘에 따른 압축을 쉽게 할 수 있습니다.
  실제로 다른 데이터 형식 (TextFile, SequenceFile) 과 비교해도, RCFile이 데이터 사이즈면에서는 가장 우수 했습니다. 아래는 완전 동일한 데이터군을 각각의 파일 형식으로 '압축하지 않은 것'과 '압축 상태인 것'으로 저장하여 어느 정도 사이즈 차이가 나는지를 비교한 것입니다.

 

 

 

 기존의 데이터 중에는 TextFile이면서 압축하지 않은 상태로 저장되어 있는 것도 있었기 때문에, 이번에는 Hive Table의 데이터는 전부 'RCFile + GZIP' 형식으로 저장하도록 변경 했습니다.

※ 실제로는 아직 일부 마이그레이션 중입니다.

 

너무 자잘한 파일의 merge
 Hadoop HDFS 상에서는 블럭 사이즈보다도 극단적으로 작은 파일이 많이 있으면 별로 효율적으로 처리를 하지 못합니다. 이 부분은 매우 유명한 이야기로, Cloudera의 'The Small Files Problem' 이란 블로그 기사가 매우 쉽게 쓰여 있어 참고 할 만 합니다. 


 자잘한 파일의 merge는 일반적으로는 HAR를 사용하는 경우가 많은 것 같습니다만, 이번에는 Hive merge와 관련된 옵션을 사용했습니다.

 

 

 'hive.merge.mapfiles', 'hive.merge.mapredfiles' 로 출력 파일의 merge 처리 on/off 설정을 합니다. 사이즈 조정은 'hive.merge.size.per.task', 'hive.merge.smallfiles.avgsize' 에서 처리 합니다. 이것들을 조합하여, 블록을 유효하게 쓸 수 있는 사이즈로 조정해서 파일을 출력할 수 있습니다.

 아래는 약간 실무와는 좀 별개의 수치이긴 합니다만, 실제 merge 전후에 어느 정도의 처리시간 차이가 나는지, count 문과 select 문 (where hoge=xxx)를 발행 해 본 비교 결과 입니다.

 

 

튜닝 결과 (데이터 구조 변경)
 이번에 측정한 시점에서는 모든 데이터 마이그레이션 아직 끝나지 않았기에 효과는 어중간 했지만, 그래도 1시간 정도 처리 속도가 개선 되었기 때문에, 위에서 얘기한 수법은 튜닝 방향으로서는 틀리지 않았다고 생각합니다.

 

 

서버 증설
 자, 주저리주저리 길게 썼는데요. 튜닝 작업에는 한계가 있어, 마지막에는 서버 증설 (돈)에 의지해야만 하는 경우도 있습니다.
 이번 같은 경우에도 본질적으로는 그런 상황이었기 때문에, 기존의 Hadoop Cluster의 DataNode/TaskTracker 대수를 2배로 늘렸습니다.

 

 

 

 단번에 6시간이나 단축...
 어쨌든 뭐랄까, 최종적으로는 돈이 중요하다는 현실에 직면하게 되었네요.

 실제로 데이터 구조 튜닝에 의해 잠재적으로 처리는 효율화 되었지만, 그래도 아직 남아있었던 용량 부족 문제는 서버 증설 작업으로 해결되었습니다. 아무것도 하지 않았던 때보다 처리속도 개선 효과가 컸다고 생각합니다.

 

정리
 어쨌든지 간에 다양한 수단을 구사하여 분석 시간을 9시간 정도 단축 할 수 있었습니다.

 

 

 마지막으로, 이번 튜닝 과정 중 느낀 점을 정리하는 측면에서 적고 이 글을 마치고자 합니다.

 

 

 

 이상으로, '캐쥬얼'한 규모의 데이터 클러스터에서의 분석 처리 튜닝 과정에 대해 적어 보았습니다.
 이 블로그 내용이 여러분에게 조금이라도 도움이 된다면 기쁠 것입니다.


Appendix.
 통계분석 기반에서 현재 다루고 있는 데이터는 기껏해야 PB 클래스의 '캐쥬얼'한 사이즈의 데이터입니다만, 이후 데이터 사이즈 증가를 고려 했을 땐 현재 상황 보다 효율적인 데이터 구조를 검토할 필요가 있습니다.
 또한, 현재는 거의 Daily 혹은 Hourly 분석이 중심이지만, 좀 더 빠른 데이터 분석을 하고 리얼타임에 가까운 형태로 분석 결과를 표시하는 구조도 필요하게 될겁니다.

 

 데이터 구조에 대해서는, 현재 개인적으로 관심을 가지고 있는 것이 'CIF(ColumnInputFormat)' 이라 불리는 것입니다. 데이터 로컬리티에 신경을 써서 같은 데이터 스키마를 동일한 DataNode로 나눠 할당하는 방법이나, 시리얼라이즈(serialize)나 데이터 압축 등을 고안해서 처리 고속화를 실현하는 수법이라 합니다. 
 아직 실제로 실험 해 보지는 않았지만, 논문 베이스로는 데이터를 읽어 들이는 속도가 RCFile보다 38배 빠르다고 합니다.
Column-Oriented Storage Techniques for MapReduce(VLDB ’11)
Sandeep’s Research Notes: RCFile and CIF


 또, 실 서비스 예로는, Treasure Data 에서는 내부 데이터 구조에 MessagePack을 이용하여 높은 압축률을 실현하고 있다고 합니다.
Five Criteria of Next Generation Data Warehouse | Treasure Data Blog

 Check. We achieve a 5-10x compression ratio. Columnar data storage helps with compression considerably, but our secret sauce is a binary serializer called MessagePack. MessagePack is space-efficient and incredibly fast to serialize and deserialize. One of our co-founders is the original author of MessagePack, and we use it extensively throughout our stack.

 

 이런 실사례를 참고하면서, 보다 효율적인 데이터 구조 채용을 검토 해 나가고 싶습니다.

 데이터의 준 리얼타임 분석에 관해서는 이른바 Streaming Processing의 개념과 이를 실현할 미들웨어 필요 해 집니다.
 가장 유명한 것으로는 Twitter 회사가 도입하고 있다는 'Storm' 일까요.
 또, 로그 콜렉터로 유명한 'Fluentd' 에관해서도, Aggregation을 실행하는 플러그인 등도 있고, 생각하기에 따라 Streaming Processing이 가능 해 질 거라 생각합니다.

 이것들도 여러가지로 실험 해 보고 싶습니다.


 잘나가는 서비스의 뒷면에는, 잘나가는 데이터 분석 기반이 존재한다는 것이 통설(?)이기에, 저희들도 가능한 그 경지에 가까이 다가갈 수 있도록 노력 해 나가고자 합니다.

 

 

 

Posted by 이슈타르네스