Tags

하둡 데이터를 오픈소스 분석툴인 펜타호를 통해 분석하는 방법

This article is based on Hortonworks and Pentaho Partner Content

하둡 클러스터를 구축한 이후에 누가 이용할 것인가에 대한 문제를 한 번 검토해 볼 필요가 있습니다.
초기에는 주로 개발 부서가 인발브가 되어서 논의가 이루어 지지만 궁극적으로 누가 이용할 것인지를 살펴 보면 어떤 요소들이 더 필요한 지에 대한 인사이트를 얻을 수 있을 것입니다.

기존에 BI를 활용하는 부서의 입장에서 보면 기본적으로 마케팅 분석가나 생산관리 혹은 품질 관리 부서에서 가장 많이 활용을 하고 있으며, 그 외에 데이터웨어하우스를 구축하는 데 필요했던 각 데이터마트의 데이터를 이용하던 조직들이 활발하게 이용하고 있습니다.

이런 관점에서 보면 빅데이터 하둡 클러스터에 모인 데이터를 이러한 분석가들이 쉽고 직관적으로 이용해서 인사이트를 얻도록 도와 주는 쪽의 구성 요소는 하둡 클러스트의 구축 못지 많게 중요한 부문으로 떠오르고 있습니다.

다른 글에서 다양한 연동 방법에 대해서 소개를 드렸습니다.
HIVE를 이용해서 다른 분석툴과 연동하는 방법
하둡과 SAP 제품들을 연동하는 방법
자사의 미들웨어를 하둡과 연동한다는 것의 의미와 방법

일반적으로 HIVE는 하둡 클러스터의 데이터셋에 대해서 테이블 뷰를 제공하고 JDBC와 같은 표준 데이터베이스 연동툴을 통해서 접근하는 것이 가능하기 때문에 가장 쉬운 연동 포인트 중의 하나입니다.

기본적으로는 HIVE의 테이블 뷰를 하둡 클러스터에서 구성하고 분석툴에서 이러한 테이블 뷰를 다른 데이터셋과 마찬가지 방법으로 다룰 수 있도록 구성하는 것이 일반적인 솔루션 개발 프로세스입니다.

다양한 상용 분석툴이 하둡과의 연동을 발표하고 있지만 오픈 소스 분석툴인 펜타호(Pentaho)도 빅데이터 분석 및 시각화에 많은 노력을 기울이고 있어서 분석가들을 위한 다양한 솔루션을 제공하고 있습니다.

그래서 하둡 데이터 통합(Data Integration)의 관점에서 펜타호의 접근 방법을 간단히 소개하고자 합니다.

시각적인 ETL 툴을 통한 데이터 정제 과정

hadoop-drag-and-drop

펜타호는 하둡 데이터셋을 포함한 다양한 데이터 소스의 데이터를 액세스하고 변환하기 위한 다양한 라이브러를 제공하는 방식으로 접근하고 있습니다.
이러한 라이브러리를 활용하는 시각화툴을 통해서 드래그-앤-드롭 방식으로 메타데이터를 생성하도록 지원하고 있습니다.
이러한 시각화툴을 통해서 데이터 맵핑, 정합성 테스트 등을 하나의 파이프라인으로 연결해서 자동화함으로써 분석가들이 실제로 분석을 하기 위한 데이터셋을 손쉽게 준비할 수 있도록 하고 있습니다.

시각적인 툴을 통해서 코딩없이 데이터 분석 및 시각화
이렇게 정제된 데이터셋에 대해서 맵리듀스(MapReduce) 잡을 생성하거나 SQL문을 통해서 원하는 결과를 얻는 방법도 있지만 하둡 클러스터의 데이터셋을 보다 많은 사람들이 이용하기 위해서는 코딩 없이 분석이 가능한 툴이 중요한 요소 중의 하나입니다.

map_0

펜타호는 기존의 데이터베이스를 병렬적으로 분석해서 속도를 높히는 엔진을 보완하여 하둡의 데이터셋에 대해서도 병렬적으로 분석하여 결과를 빠르게 도출할 수 있도록 진화시키고 시각화 툴에 연동시킴으로써 별도의 코딩없이 데이터를 분석하는 방법을 제공합니다.

하둡 클러스터의 데이터셋 이외에도 몽고디비 등의 NoSQL 데이터와의 통합 분석 등의 기능을 지원함으로써 기업이 보유하고 있는 모든 데이터 자산을 가장 효율적으로 이용하기 위한 분석툴을 제공합니다.

이러한 다양한 기능이 오픈소스 커뮤니티를 통해서 플러그인 방식으로 계속 통합됨으로써 기존의 상용 솔루션이 커버하지 못 하는 영역의 분석에 대해서도 지속적으로 그 범위를 확대하고 있습니다.

구체적인 연동 방법과 분석툴에 대한 소개는 계속 드리도록 하겠습니다.

—————————————————————————————————————————–
ASD Technologies는 호튼웍스(Hortonworks Inc)와의 Consulting Partnership을 통해서
빅데이터에 대한 도입 컨설팅 및 구축을 도와드리고 있습니다.

ASD Technologies는 펜타호(Pentaho Inc)와의 Consulting and Distribution Partnership을 통해서
빅데이터에서 비즈니스 인사이트를 얻기 위한 방법을 함께 모색하고 있습니다.

호튼웍스 파트너 홈페이지
ASD Technologies Korea 홈페이지

Contact Point : sunung@asdtech.co
—————————————————————————————————————————–

호튼웍스 하둡을 검색엔진과 연동하는 방법과 아키텍쳐

This article is based on Hortonworks Partner Content and Expertise

그 동안 호튼웍스 하둡과 다른 솔루션을 연동해서 기업에 최적화된 데이터 플랫폼을 구축하기 위한 사례들을 많이 소개해 왔습니다.

자사의 미들웨어를 하둡과 연결한다는 것의 의미와 방법
호튼웍스 하둡과 NoSQL을 연동하는 방법
엔터프라이즈 레벨 실시간 시스템의 최강 조합 (하둡 + 인메모리 데이터베이스)
HIVE를 통해 다른 분석툴과 연동하는 방법
엑셀로 하둡 데이터를 간단하게 연동하는 방법

이상과 같이 하둡은 기존의 데이터 처리 시스템을 대체하는 부분보다는 기존의 엔터프라이즈 데이터 시스템을 보완하면서 확장성 있게 다양한 데이터셋을 처리할 수 있는 플랫폼이라는 관점에서 보는 것이 좋겠다는 의견입니다.

최근에 하둡 2.0이 YARN(Yet Another Resource Negotiator)를 도입하면서 다른 솔루션과 연동할 수 있는 포인트가 다양해 졌기 때문에 기존의 솔루션이 가진 특성이나 컨셉에 최적화된 연동 방법을 고민하고 아키텍쳐를 구성하는 것이 필수적인 요건이 되었습니다.

이번에는 검색엔진과의 연동을 통해서 대량의 데이터를 인덱싱(Indexing)하여 필요한 때에 실시간으로 데이터를 분석하고 검증할 수 있는 방법에 대해서 소개해 드리려고 합니다.
이미 빅데이터와 검색엔진과의 연동을 통한 효과는 다른 많은 기업들에 의해서 검증이 되고 있습니다.
예를 들어, 스플렁크(Splunk)는 이른바 ‘머신 로그 데이터의 구글’이라는 별명답게 데이터 센터에서 생성되는 많은 머신 로그들을 인덱싱하여 문제가 있는 부분을 실시간으로 식별하고 문제를 해결하는 데 커다란 역할을 하고 있습니다.
최근에는 하둡과의 커텍터(Connector)를 제공하여 하둡과의 연동을 강화화고 있는 추세이니 관련 자료를 참조해 보면 좋은 힌트를 얻을 수 있겠습니다.

오늘은 ElasticSearch라는 빅데이터 검색 엔진과 호튼웍스 하둡의 연동 시나리오를 통해서 검색 엔진과의 연동을 통해서 대량의 데이터셋에 대한 실시간 검색과 데이터 접근 방법에 대한 사례를 살펴 보겠습니다.

아래 아키텍쳐는 ElasticSearch와 하둡이 연동되는 구성도이지만 일반적인 검색엔진 솔루션과 하둡을 연동하는 데도 비슷한 방법이 적용됩니다.

es1

검색엔진
검색엔진은 새로운 문서(Documents)를 거의 실시간으로 인덱싱해서 사용자가 키워드를 쿼리(Querying)했을 때 바로 접근할 수 있도록 하는 것이 주 역할입니다. 이 예에서 쓰인 ElasticSearch도 역시 아파치의 루씬(Lucene)을 기반으로 해서 인덱스 파일을 클러스터에 분산시켜서 확장성 있게 저장하는 기능을 지원합니다.
만약에 인덱스를 저장하는 노드에 문제가 생길 경우에는 자동으로 다른 노드로 그 인덱스를 저장하여 분산 환경에서도 문제가 없도록 관리합니다.
위 아키텍쳐에서는 하둡 파일시스템(HDFS)를 이용해서 인덱스 파일을 분산시켜서 저장하는 모델을 가져 갔습니다.
컨피규레이션(Configuration)에서는 각 인덱스를 몇 개의 부분(Shards)으로 나눌 것인지와 이 부분(Shards)을 몇 개까지 복제할 것인 지 등을 설정하여 클러스터를 관리할 수 있습니다.

플룸(Flume)
플룸(Flume)은 여러 번 소개를 드렸던 하둡 에코 시스템의 컴포넌트입니다.
많은 데이터 소스에서 로그 데이터를 수집하여 안정적으로 스트리밍(Streaming)하여 하둡 파일시스템(HDFS)에 저장하는 기능을 담당합니다.
위 예에서는 각 머신 혹은 서버에 인스톨되어 있는 에이전트(Agent)를 통해서 Flume Collector가 데이터를 수집한 다음에 ‘저장’을 하기 위한 스트리밍 모듈과 ‘인덱싱’을 위한 스트리밍 모듈에서 각각 데이터를 처리하도록 데이터 파이프라인(Data Pipeline)을 만들었습니다.
하둡 파일시스템(HDFS)에 저장된 데이터는 이 후에도 HIVE/Pig/MapReduce 등의 처리툴을 통해서 검색엔진에서 언제든지 활용 가능하도록 구성되었습니다.

시각화 및 검색 데이터 인터페이스
이 예제에서는 Kibana라는 웹브라우저 기반의 분석 및 검색 엔진 인터페이스를 제공하는 툴을 통해서 결과를 검색하도록 구성했습니다.
Kibana도 역시 아파치 오픈 소스 프로젝트이고 특히 루씬(Lucene)과 같은 검색엔진에 대한 인터페이스를 제공하고 그 결과를 시각화하는 데 특화된 툴입니다.

es4

대용량의 데이터셋에 검색 기능을 제공하는 것은 특히 데이터 센터에서 각종 서버 및 네트워크의 문제를 바로 식별하는 데 이미 검증이 된 사례입니다.
그 외에도 보안 및 각종 Fraud 문제에 대한 접근 방법으로도 많은 주목을 받고 있습니다.
완전히 비정형 데이터라고 볼 수 있는 문서에 대한 가장 효과적인 접근 방법이라는 측면에서도 하둡 에코 시스템과의 연동을 통해서 이 후에 ECM 등의 다른 분야로도 확장될 수 있는 영역이라는 생각입니다.

ElasticSearch와 하둡의 연동에 대한 세부 사항‘을 참조하시면 다른 검색엔진을 하둡과 연동하기 위한 많은 팁을 얻을 수 있습니다.

—————————————————————————————————————————–
ASD Technologies는 호튼웍스(Hortonworks Inc)와의 Consulting Partnership을 통해서
빅데이터에 대한 도입 컨설팅 및 구축을 도와드리고 있습니다.

ASD Technologies는 펜타호(Pentaho Inc)와의 Consulting and Distribution Partnership을 통해서
빅데이터에서 비즈니스 인사이트를 얻기 위한 방법을 함께 모색하고 있습니다.

호튼웍스 파트너 홈페이지
ASD Technologies Korea 홈페이지

Contact Point : sunung@asdtech.co
—————————————————————————————————————————–

현대적인 하둡 아키텍쳐의 구성 요소와 역할

This article is based on Hortonworks Partner Content and Expertise

광고 산업(Advertising)이 가지고 있는 데이터 처리 플랫폼에 대한 니즈와 사례에 대해서 간단히 소개드리면서 아래와 같이 호튼웍스 데이터 플랫폼으로 구성한 아키텍쳐에 대해서도 보여 드렸습니다.
광고 산업의 혁신을 위한 하둡 아키텍쳐

Advertising Data Architecture

advertising-data-architecture

현대적인 하둡 아키텍쳐에 대해서 호튼웍스가 다양한 사례들을 중심으로 구성을 하고 있기 때문에 앞으로도 다양한 산업군 별로 구축 사례들과 최적화된 아키텍쳐에 대한 정보들이 나올 것으로 생각합니다.

그렇다면 이러한 아키텍쳐를 구성하는 각 구성요소들은 구체적으로 어떤 역할을 담당하고 어떻게 다른 요소들과 연동되는 지에 대해서 간단히 검토해 보도록 하겠습니다.

Data Sources and Ingest stage
광고 산업의 경우에는 다양한 채널을 통해서 사용자의 행동 정보를 수집해야 하기 때문에 데이터 소스가 아주 다양하고 데이터셋의 포맷도 다양하다는 특성을 가지고 있습니다.
즉, 광고를 집행하는 채널에서 나오는 데이터 뿐만 아니라 고객의 소셜 데이터 그리고 ‘POS 데이터 분석을 통해 충성도 높은 고객을 식별하기’의 사례에서 보는 것처럼 실시간 구매 트랜잭션 데이터까지 포괄적으로 고려 해야 합니다.

그래서 대략적인 예를 들어도 아래와 같은 다양한 데이터 소스에서 데이터를 수집해야 합니다.
- Oracle 등의 관계형 데이터베이스
- Transaction data
- POS data
- Server logs
- Click streams

그래서 이러한 다양한 데이터 소스의 데이터셋을 하둡 파일시스템(HDFS)으로 저장하기 위해서는 여러 가지 구성 요소를 그 특성에 맞게 활용해야 합니다.
Sqoop
일전에 ‘SQL Server에 있는 데이터를 하둡으로 임포트하는 방법에서 소개드린 것처럼 Sqoop은 관계형 데이터베이스와 HDFS간에 데이터를 ‘대량으로’ 이동하기 위한 툴입니다.
SQL Server뿐만이 아니라 JDBC를 지원하는 대부분의 관계형 데이터베이스를 지원하고 성능이 중요한 경우에는 각 벤더에서 제공하는 Sqoop-Database Connector를 이용해서 성능을 향상시킬 수도 있습니다.

sqoop

Sqoop은 크게 두 가지 과정을 거쳐서 실행을 합니다.
먼저 데이터베이스를 검토해서 테이블에 대한 ‘메타데이터’를 먼저 구성한 다음에 각 맵(Map) 잡을 실행하여 하둡 파일시스템에 분산 저장합니다.
물론 HIVE 혹은 HBase에 저장하는 것도 가능합니다.

Flume
Flume은 원래 대량의 로그 데이터를 수집하기 위한 툴에서 발전을 했고 이 후에 하둡 에코시스템의 하나로서 각 수집하고자 하는 머신에 일종의 에이전트가 인스톨되고 이 후에 데이터를 스트리밍해서 하둡 파일시스템(HDFS)에 저장하는 시스템입니다.

호튼웍스 플랫폼으로 서버 로그데이터를 분석하는 방법‘에서 소개 드린 것처럼 Flume은 다음과 같은 중요한 일을 안정적으로 수행합니다.
- 다양한 데이터 소스로부터 데이터를 수집하여 하둡 파일시스템(HDFS)으로 읽어 들인다.
- 대용량의 웹로그 데이터를 실시간으로 수집한다.
- 입력되는 데이터가 하둡 파일시스템(HDFS)에 원활하게 저장할 수 없을 만한 속도로 들어 오면 자동으로 읽는 속도를 조정한다.
- 데이터 이동시의 문제를 확인해서 재실행 등의 방법으로 데이터 이동을 보장한다.
- 분산 아키텍쳐로 입력되는 데이터의 양에 따라서 수평적으로 확장할 수 있다.

Governance and HCatalog
일단 이러한 데이터를 로드한 이후에는 어떤 뷰를 가지고 이러한 데이터를 볼 것인지에 대한 비즈니스 혹은 분석 관점의 ‘메타데이터’ 관리가 필요합니다.
HCatalog를 활용하여 테이블 뷰를 적용하는 방법‘에서 소개드렸던 것처럼 HCatalog는 PIg, MapReduce를 포함한 다양한 데이터 처리 툴에게 일종의 테이블 뷰(Table View)를 제공하는 모듈입니다.

즉, 사용자는 실제로 데이터가 어떤 포맷으로 되어 있는 지에 상관없이 이용할 수 있습니다.
정확하게는 SerDe(Serializer-Deserializer)를 작성할 수 있는 모든 파일 형식이고 디폴트로 다양한 파일 형식(RCFile, CSV, JSON, and SequenceFile, and ORC file formats)을 지원합니다.
사용자가 특정한 포맷을 이용하려면 InputFormat, OutputFormat, SerDe에 특정한 데이터 형식을 처리하는 코드를 작성함으로써 자유롭게 확장할 수 있습니다.

HCatalog로 비즈니스 니즈의 잦은 변동에도 테이블 뷰에 대한 메타데이터만 통합적으로 관리함으로써 신속하게 대처할 수 있습니다.

Analysis
HIVE를 통해 다른 분석툴과 연동하는 방법‘에서도 소개드렸던 것처럼 기존에 이용하고 있는 분석툴과 연동하기 위한 방법은 다양합니다.
하둡의 HIVE는 하둡 파일시스템(HDFS)에 저장된 데이터셋에 대해서 일종의 RDB의 테이블과 같은 뷰(View)를 제공하고 ODBC, JDBC와 같은 표준 인터페이스를 통해서 다른 분석툴에서 접근할 수 있게 해 줍니다.

그리고 최근에는 분석툴에서 HIVE 인터페이스를 이용하지 않고 직접 하둡 파일시스템(HDFS)에 접근하거나 HBase와의 연동을 강화하는 등의 다양한 연동 방식을 제공하기 때문에 비즈니스 니즈에 맞게 적용이 가능합니다.

물론 별도의 Data Repository Layer를 두어서 중요한 분석 데이터만 요약해서 관계형 데이터베이스에 임포트해서 이용하는 방법도 있습니다.

YARN
YARN의 컨셉과 의미에 대해서는 여러 기사에서 비교적 상세하게 다루었습니다.
YARN의 컨셉과 적용 방법

YARN은 특정한 어플리케이션의 처리 라이브러리를 별도의 AM에 올림으로써 하나의 하둡 클러스터에서 다양한 어플리케이션이 돌아 가도록 하는 것이 핵심입니다.
이러한 구조의 변화에 의해서 사용자는 데이터의 속성에 맞는 다양한 어플리케이션을 처리하는 별도의 AM을 만들어서 확장시킬 수 있습니다.

데이터의 처리에 대한 니즈가 배치, SQL 인터랙티브 처리, 온라인 데이터베이스, 스트리밍 등의 다양한 용도에 맞추어서 각각의 어플리케이션을 하둡 클러스터에 세팅함으로써 유연한 데이터 처리 시스템을 구성할 수 있습니다.

YARN

이상과 같이 하둡 에코시스템의 구성 요소들은 각 산업군 별로 특화된 니즈에 대해서 데이터 처리의 전체 프로세스를 커버할 수 있는 단계로 진화하고 있습니다.

각 산업군 별 적용 사례는 계속 소개하도록 하겠습니다.

—————————————————————————————————————————–
ASD Technologies는 호튼웍스(Hortonworks Inc)와의 Consulting Partnership을 통해서
빅데이터에 대한 도입 컨설팅 및 구축을 도와드리고 있습니다.

ASD Technologies는 펜타호(Pentaho Inc)와의 Consulting and Distribution Partnership을 통해서
빅데이터에서 비즈니스 인사이트를 얻기 위한 방법을 함께 모색하고 있습니다.

호튼웍스 파트너 홈페이지
ASD Technologies Korea 홈페이지

Contact Point : sunung@asdtech.co
—————————————————————————————————————————–

솔루션을 하둡과 연동한다는 것의 의미와 방법 (SAP HANA case)

This article is based on Hortonworks Partner Content

최근에 레드헷, EMC, SAP, DELL 등의 다양한 벤더들이 하둡과의 연동을 발표하고 있습니다.
그 동안 단편적으로 하둡과 연동해서 기존의 다양한 분석툴을 활용하는 방법에 대해서는 소개를 드렸습니다.
엔터프라이즈 레벨 실시간 시스템의 최강 조합 (하둡 + 인메모리데이터베이스)
하이브를 통해 다른 분석툴과 연동하는 방법
하둡과 SAP 제품들을 연동하는 방법
SQL 서버에 있는 데이터를 하둡으로 임포트하는 방법

그렇다면 자사의 솔루션이 하둡과 연동한다는 것은 어떤 의미일까요?
하둡 2,0의 두 가지 요소인 YARN(Yet Another Resource Negotiator)와 하둡 파일시스템(HDFS) 2.0의 도입으로 다른 솔루션과 연동할 수 있는 ‘포인트’가 다양해 지고 연동 방법도 각 시스템의 구축 형태에 맞게 비교적 자유롭게 선택할 수 있습니다.

그래서 이번에는 SAP HANA라는 인메모리 데이터베이스(In-Memory Database)의 관점에서 호튼웍스의 HDP 2.0과 연동하는 방법과 그 의미에 대해서 조금 자세히 살펴 볼까 합니다.
다양한 사례 중에서 SAP HANA를 선택한 이유는 단순히 HIVE를 이용해서 ODBC Connector로 연결하는 방법처럼 독립적인 연동 방식이 아니라 다양한 연동 포인트에서 마치 하나의 플랫폼처럼 연동하기 위해서 많은 고려를 하고 있다는 측면때문입니다.

조만간 한국의 다양한 기업용 솔루션들도 하둡과의 연동을 통해서 빅데이터를 지원하는 솔루션으로 포지셔닝하는 데 있어서 많은 참고가 되지 않을까 싶습니다.

먼저 SAP HANA가 하둡과의 연동을 위해서 가져 가려고 했던 목표는 “다양한 데이터 소스에서 발생하는 대량의 데이터를 실시간으로 처리하기 위한 플랫폼”입니다.
즉, SAP HANA는 인메모리 데이터베이스이므로 기본적으로 메모리에서 연산이 이루어지는 실시간성을 가지고 있지만 그 약점은 필연적으로 대량의 데이터를 ‘전처리’해서 메모리에 로딩한 이후에 그 진정한 힘을 발휘할 수 있다는 점입니다.

만약 하둡이 가진 대량의 데이터를 저장하고 비교적 실시간으로 그 데이터의 테이블 뷰를 만들어 내는 능력을 SAP HANA에서 활용할 수 있다면 아키텍쳐적으로 빅데이터에도 대응할 수 있는 실시간 플랫폼이 될 수 있을 거라는 계산입니다.

그래서 아래와 같은 연동 포인트를 통해서 하둡을 충분히 이용하고자 했습니다.
맵리듀스(MapReduce)의 다양한 패턴들을 빅데이터에 적용하기
일반적으로 맵리듀스는 5가지 형태의 패턴을 통해서 비정형 데이터를 SAP HANA와 같은 관계형 데이터베이스가 친숙한 형태로 데이터를 가공할 수 있습니다.
- Optimized repartition joins
- Implementing a semi-join
- Implementing a secondary sort
- Sorting keys across multiple reducers
- Reservoir sampling
각각의 패턴에 대한 자세한 방법 및 예제는 아래 링크를 활용하기 바랍니다.

예를 들어, Optimized repartition joins에 대해서만 간단히 설명드리겠습니다.
아래와 같이 2개의 텍스트파일이 있다고 가정해 봅니다.
1,Stephanie Leung,555-555-5555
2,Edward Kim,123-456-7890
3,Jose Madriz,281-330-8004
4,David Stork,408-555-0000

3,A,12.95,02-Jun-2008
1,B,88.25,20-May-2008
2,C,32.00,30-Nov-2007
3,D,25.02,22-Jan-2009
맨 앞에 있는 칼럼이 고객 ID라고 가정해서 맵리듀스를 통해서 조인을 시키면 아래와 같은 결과를 ‘미리’ 얻을 수 있습니다.
1,Stephanie Leung,555-555-5555,B,88.25,20-May-2008
2,Edward Kim,123-456-7890,C,32.00,30-Nov-2007
3,Jose Madriz,281-330-8004,A,12.95,02-Jun-2008
3,Jose Madriz,281-330-8004,D,25.02,22-Jan-2009
즉, SAP HANA가 메모리에서 최종적으로 결과를 얻기위해서 꼭 필요한 데이터셋을 미리 하둡을 통해서 구성해 놓음으로써 연동을 손쉽게 하는 방법입니다.

하둡 파일시스템의 데이터를 실시간으로 스트리밍하기
아무리 빠른 데이터베이스라도 결국에는 파일시스템에서 빠르게 읽어 들이지 못 하면 그 효과는 반감될 것입니다.
그래서 SAP HANA는 아래와 같은 4가지 방법을 이용하여 하둡 파일시스템의 데이터셋을 실시간으로 스트리밍합니다.
- Using Avro to store multiple small files
- Picking the right compression codec for your data
- Compression with HDFS, MapReduce, Pig, and Hive
- Splittable LZOP with MapReduce, Hive, and Pig.
각각의 방법에 대한 자세한 적용 방법은 HDFS 문서를 참조하시기 바랍니다.

첫 번째에서 활용하는 Avro는 하둡에서 사용하는 데이터 시리얼라이제이션(Serialization) 모듈입니다.
즉, 일반적으로 데이터 소스에서 발생하는 로그파일은 작은 용량의 파일이 대량으로 생성되는 경우가 많습니다.
이러한 작은 용량의 파일들을 하나의 큰 파일처럼 시리얼라이제이션(Serialization)해서 하둡 파일시스템(HDFS)에 저장함으로써 처리 속도 및 효율성을 크게 향상시킬 수 있으며 SAP HANA에서도 마치 하나의 큰 ‘테이블’처럼 다룰 수 있게 됩니다.

SAP HANA / Hadoop Integration Process
그래서 하둡을 SAP HANA와 연동하기 위해서 다음과 같은 프로세스를 구성했습니다.

hana-integration

- 정형 및 비정형 데이터를 하둡 파일시스템(HDFS)에 분산시켜서 저장하기
- 하둡의 다양한 에코시스템을 활용하여 이러한 데이터를 ‘전처리’하기
- 다양한 데이터셋을 미리 ‘조인’하여 ‘하둡/HANA Connector’로 SAP HANA에 적재하기
- SAP HANA에서 스토어드 프로지셔(Stored Procedure)를 적용하여 실시간으로 처리하기
- SAP Business Objec와 같은 BI툴을 활용하여 실시간으로 분석하기

hana

그 다음에는 관리툴을 통해서 하둡의 기능을 활용할 수 있도록 통합을 하는 과정으로 하둡의 데이터셋도 다른 데이터베이스처럼 인식할 수 있도록 합니다.
즉, 데이터 페더레이션(Data Federation)을 직관적으로 하기 위한 관리툴을 제공함으로써 SAP HANA의 관점에서 하둡 데이터를 기존의 데이터와 함께 처리할 수 있도록 합니다.

이상의 과정은 어떤 솔루션이 하둡과 연동하기 위한 접근 방법과 프로세스를 SAP HANA를 통해서 설명을 드렸습니다.
꼭 SAP HANA가 아니더라도 다양한 회사들이 가진 기업용 솔루션과 하둡을 연동하기 위해서 고려해야 할 점과 프로세스라고 생각하므로 이 부분을 잘 검토해서 빅데이터를 지원하는 기업용 솔루션으로 포지셔닝한다면 여러 가지 다양한 기회를 얻을 수 있는 힌트가 되리라고 생각합니다.

—————————————————————————————————————————–
ASD Technologies는 호튼웍스(Hortonworks Inc)와의 Consulting Partnership을 통해서
빅데이터에 대한 도입 컨설팅 및 구축을 도와드리고 있습니다.

ASD Technologies는 펜타호(Pentaho Inc)와의 Consulting and Distribution Partnership을 통해서
빅데이터에서 비즈니스 인사이트를 얻기 위한 방법을 함께 모색하고 있습니다.

호튼웍스 파트너 홈페이지
ASD Technologies Korea 홈페이지

Contact Point : sunung@asdtech.co
—————————————————————————————————————————–

현 시점에서 하둡 프로젝트는 반드시 하둡 2.0 기반으로 해야 하는가?

This article is based on Hortonworks Partner Content

지금까지 여러 가지 사례들을 소개할 때 당연히 하둡 2.0을 전제로하고 논의를 진행해 왔습니다.
이 시점에서 하둡 2.0이 어떻게 진화했는 지에 대해서 큰 그림으로 파악해 볼 필요가 있을 거 같습니다.

왜냐하면, 하둡 2.0은 단순한 업그레이드를 넘어서 전혀 새로운 아키텍쳐로 변모했다는 관점도 많이 있기 때문입니다.
현 시점에서 하둡을 실제 프로젝트에 도입한다고 가정한다면 안정적인 하둡 1.0을 기반으로 할 것인지 아니면 보다 유연한 하둡 2.0을 기반으로 할 것인지에 대한 의사 결정은 그 이후의 많은 요소들에 영향을 미치는 중요한 결정 사항입니다.

이미 하둡 1.0기반으로 진행된 프로젝트들도 많이 있다는 점도 결정을 어렵게 만드는 부분입니다.

먼저 하둡 2.0이 어떻게 변모하고 앞으로 어떤 방향으로 진화할 것인지에 대한 로드맵도 함께 검토해 보는 단계가 필요한 시점입니다.

hadoop2.0

이 다이어그램은 하둡 1.0과 비교해서 하둡 2.0 아키텍쳐가 어떻게 변모했는 지를 보여 주고 있습니다.
그렇다면 하둡 2.0과 1.0의 가장 결정적인 차이점은 무엇일까요?
사실 세부적인 요소들이 추가되고 수정되는 부분에 집중하다 보면 도입을 위한 의사 결정에 잘못된 판단을 할 수도 있습니다.

Single Use System -> Multi Use System
가장 핵심적인 차이는 배치 처리에 특화된 시스템인가 아니면 배치, 인터랙티브, 온라인, 스트리밍과 같이 다양한 데이터 처리 형태를 지원하는 가입니다.
하둡 1.0은 가용성과 확장성이 높은 하둡 파일시스템(HDFS)과 이렇게 분산된 대량의 데이터를 읽어 들여서 하나의 결과를 도출하는 맵리듀스(MapReduce)로 이루어진 단일 용도 시스템의 성격이 큽니다.

이전에 HDFS 2.0의 진화와 로드맵에 대해서 설명을 드렸지만 기본적으로는 그 철학을 그대로 유지하고 컨셉이 변모하지는 않았습니다.
하지만 데이터 처리에 대한 부분에서 맵리듀스(MapReduce)는 다른 많은 처리 방법 중의 하나로 그 위상이 크게 변모했습니다.

그 이유는 YARN(Yet Another Resource Negotiator)라는 레이어가 HDFS와 결합했다는 것이 가장 큰 의미를 내포하고 있습니다.
YARN의 가장 핵심적인 아이디어는 하둡 1.0에서 데이터 처리를 주관하던 잡트랙커(JobTracker)의 두 가지 기능을 분리하자는 것입니다.
기존에 잡트랙커(JobTracker)는 하둡 클러스터의 리소스를 관리하는 것과 맵리듀스 잡(MapReduce Job)을 스케쥴링하고 모니터링하는 두 가지 역할을 하고 있었습니다.

이것을 하둡 클러스터의 전체적인 리소스를 관리하는 리소스 매니저(RM)와 ‘각’ 어플리케이션의 스케쥴링과 모니터링을 담당하는 어플리케이션 매스터(AM)로 나누었습니다.
그래서 하나의 RM에서 맵리듀스 AM, 스트리밍 AM, SQL AM 등 특정한 어플리케이션을 동시에 운영하도록 됐습니다.
(그래서 YARN은 ‘또 하나의 리소스 협상자’입니다. 각 어플리케이션이 써야 하는 리소스를 중앙에서 중재해 줍니다.)

이른바 “Interact with all data in multiple ways simultaneously”라는 멀티 유스 플랫폼으로 변모한 것입니다.

즉, 기업의 입장에서 일 주일에 한 번이나 혹은 한 달에 한 번 특정 데이터셋에 대한 분석 데이타를 만들어야 하는 상황이라면 하둡 1.0이 훨씬 빠르고 안정적으로 구축할 수 있으며 운영 측면에서도 버든이 없습니다.

그러나 다양한 데이터셋에 대해서 기업 환경의 변화에 맞게 유연한 환경을 구축하는 로드맵을 가져가려고 한다면 하둡 2.0으로 시작할 필요가 있습니다.
이 경우에는 하나의 클러스터에서 다양한 형태의 AM이 운영된다는 측면 때문에 각 어플리케이션이 가지는 속성들을 이해하고 이른바 ‘클러스트 리소스 튜닝’ 작업을 해서 최적화시키는 단계가 하나 더 필요하다는 점을 숙지할 필요가 있습니다.

—————————————————————————————————————————–
ASD Technologies는 호튼웍스(Hortonworks Inc)와의 Consulting Partnership을 통해서
빅데이터에 대한 도입 컨설팅 및 구축을 도와드리고 있습니다.

ASD Technologies는 펜타호(Pentaho Inc)와의 Consulting and Distribution Partnership을 통해서
빅데이터에서 비즈니스 인사이트를 얻기 위한 방법을 함께 모색하고 있습니다.

호튼웍스 파트너 홈페이지
ASD Technologies Korea 홈페이지

Contact Point : sunung@asdtech.co
—————————————————————————————————————————–

Page 1 of 3123