Tags

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

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
—————————————————————————————————————————–

하둡 HBase를 기업 환경에 도입할 때 고려해야 할 점

This article is based on Hortonworks Partner Content and Expertise

하둡과 다양한 NoSQL을 연동해서 확장성과 성능이 높은 데이터 처리 시스템을 구축하는 부분은 소개를 드린 적이 있습니다.
호튼웍스 하둡과 NoSQL을 연동하는 방법 – Accumulo Case
HBase의 가능성과 한계점

지난 주에 HBase 0.98.0 버전이 발표가 되었고 이제는 실제 기업 환경에 도입될 수 있을 수준의 안정성을 점차 확보해 나가고 있습니다.
HBase는 구글의 빅데이블의 설계 철학과 데이터 모델에 맞추어서 개발되어서 로우(Row)가 수조개에 이르는 ‘빅’ 테이블의 데이터를 분산시켜서 처리할 수 있는 NoSQL 데이터베이스입니다.

반드시 염두해 두어야 할 것은 HBase는 기업에 도입할 때 그 가능성과 한계점에 대해서 확실히 이해한 이 후에 도입할 필요가 있습니다.
즉, HBase는 관계형 데이터베이스가 가지고 있는 ‘보증하는’ ACID를 지원하는 것이 아니라 각 목적에 맞게, 좀 심하게 얘기하면, ‘조금만 기다리면’ 전체적으로 만족시키는 접근 방법입니다.
HBase의 관점에서 본 ACID에 대해서는 이 링크를 꼭 참조하시기 바랍니다.
예를 들면, 원자성(Atomicity)에 대해서도 HBase는 ‘All mutations are atomic within a row’의 의미입니다. HBase의 원자성은 하나의 로우(Row)에 대해서 PUT 작업이 이루어 질 때 완전히 성공하거나 완전히 실패하거나 두 가지를 보증한다는 정보의 의미만을 가지고 있습니다.

그렇다면 기존의 관계형 데이터베이스가 기업 내부의 데이터 처리 시스템으로 오랜 기간 검증이 된 상황에서 HBase와 같은 NoSQL이 등장한 이유는 무엇일까요?
여러 가지 이유가 있지만 가장 핵심적인 것은 관계형 데이터베이스가 오히려 너무 많은 다양한 데이터 처리 작업에 쓰이고 있다는 것에 대한 재검토일 것입니다.

페이스북과 같은 인터넷 기업들에서 몇 초만에 수십만 개의 댓글이 달리는 케이스를 생각해 보면 이해가 가실 겁니다.
만약에 이 처리를 관계형 데이터베이스를 통해서 한다면 급격히 테이블이 늘어나는 것도 문제지만 응답속도도 급격히 느려질 것입니다. 그래서 완벽하게 ACID를 보증하는 접근 방법이 아니라 일단 간단한 스키마로 신속하게 처리하는 것에 중점을 둔 데이터베이스에 대한 개념들이 나오기 시작했습니다.

기업에 적용하는 경우에도 트랜잭션이 짧은 시간에 일어 나는 경우에 프론트엔드에서 NoSQL이 작업을 하고 중간 결과 등을 관계형 데이터베이스에 저장하는 것과 같이 서로 보완을 할 수 있는 접근 방법이 좋습니다.

조금 더 상세히 그 핵심적인 기능을 좀 더 살펴 보겠습니다.
Features of HBase

Linear and modular scalability.
Strictly consistent reads and writes.
Automatic and configurable sharding of tables
Automatic failover support between RegionServers.
Convenient base classes for backing Hadoop MapReduce jobs with Apache HBase tables.
Easy to use Java API for client access.
Block cache and Bloom Filters for real-time queries.
Query predicate push down via server side Filters
Thrift gateway and a REST-ful Web service that supports XML, Protobuf, and binary data encoding options
Extensible jruby-based (JIRB) shell
Support for exporting metrics via the Hadoop metrics subsystem to files or Ganglia; or via JMX

다양한 기능 중에서 빅데이터블의 설계 철학과 연관해서 중요한 점만 살펴 보겠습니다.
보통 관계형 데이터베이스에서 테이블이 크기가 커졌을 때 해야 하는 작업은 샤딩(Sharding)이라는 작업입니다.
즉, 테이블의 로우(Row)를 잘라서 분산시킴으로써 처리 성능을 향상시키려는 방식인데 HBase는 샤딩을 기본적으로 실행해서 스토리지를 늘리는 것에 맞추어서 처리 속도도 확장가능하도록 하는 것이 핵심입니다.

아마 이 부분은 실제로 테이블 크기가 더 커져서 샤딩을 다시 해야 하는 상황(Re-Sharding)을 경험해 본 DBA들은 그 작업의 어려움을 실감하고 있을 듯 합니다.

그 외에도 블록 단위의 캐싱 기능을 이용해서 급격하게 처리 요청이 많아 지는 케이스에 대해 실시간으로 대응하는 유연한 설정이 가능하다는 점이나 칼럼 단위로 테이블을 구성할 수 있는 옵션 등등이 있습니다.

즉, HBase는 엄격한 ACID를 처리하기 위한 버든(Burden)보다는 심플한 Key-Value 방식의 데이터 모델로 급격히 늘어 나는 테이블의 사이즈와 급격히 늘어나는 데이터 처리 요청을 앞단에서 신속하게 처리하는 데 그 장점이 있습니다.

이 부분에서 왜 하둡과 HBase과 상성이 맞는 지는 명확해 집니다.
하둡의 파일 시스템(HDFS)는 기본적으로 커다란 파일을 블록으로 나누어서 많은 노드에 분산되어서 저장이 되어 있습니다.
즉, 이미 분산시켜서 데이터를 처리할 수 있도록 미리 준비가 되어져 있고 리소스를 늘리면 선형적으로 처리 능력이 확장됩니다.

그래서 하둡과 HBase는 다음과 같이 연동되어서 아키텍쳐를 구성하게 됩니다.
hbase

일전에 데이터 정제 아키텍처로서의 하둡이라는 기사에서도 소개드린 것처럼 하둡과 HBase를 데이터 처리 앞 단의 ‘다양한 데이터 소스의 데이터를 신속하게 처리하는 시스템’의 역할을 부여해서 기존의 데이터베이스 시스템에 대한 투자와 버든을 줄이면서 기업 전체의 처리 능력을 높히는 방향으로 이용하는 사례가 적절합니다.

datacleansing

이상과 같이 NoSQL이 기존 데이터베이스 시스템을 대체할 수 있는 지 등등에 대한 의미 없는 논쟁보다는 그 가능성과 한계점에 맞게 가장 적절한 역할이 무엇인지 먼저 판단하는 것이 중요한 포인트입니다.

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

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

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

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

호튼웍스 하둡과 NoSQL 데이터베이스의 연동 방법 (Apache Accumulo case – Security)

This article is based on Hortonworks Partner Content and Expertise

지금까지 다양한 솔루션을 하둡과 연동하는 것의 의미와 방법에 대해서 소개를 드렸습니다.
자사의 솔루션을 하둡과 연동하는 것의 의미와 방법
엔터프라이즈 레벨 실시간 시스템의 최강 조합(하둡 + 인메모리 데이터베이스)
HIVE를 통해 다른 분석툴과 연동하는 방법

하지만 최근에 그 확장성과 빠른 성능때문에 많은 주목을 받고 있는 NoSQL 데이터베이스와의 연동 트렌드에 대해서는 특별히 소개드린 적이 없습니다.
가장 큰 이유는 이미 HBase라고 하는 데이터베이스가 하둡 에코시스템의 중요한 부분으로서 긴밀하게 연동하면서 발전하고 있기 때문입니다.
HBase는 구글의 빅테이블의 설계를 구현하면서 Billion 단위의 많은 로우(Row)를 가진 큰 테이블을 처리할 수 있는 확장성을 가지고 있고 이미 여러 가지 레퍼런스를 통해서 그 효용성을 입증하고 있습니다.

이번에 호튼웍스와 ‘Apache Accumulo’의 개발자들이 독립한 회사인 ‘Sqrrl Inc’과의 제휴를 통해서 공개한 레퍼런스 아키텍쳐를 소개드리려고 합니다.

그렇다면 이미 검증된 HBase가 엔터프라이즈 레벨로 진화해 나가는 상황에서 역시 빅데이블의 철학을 계승한 또 하나의 NoSQL 데이터베이스와의 협력 혹은 연동이 필요한 이유는 무엇일까요?

Apache Accumulo는 최근에 3 ~ 4번 째로 가장 적용이 많이 되는 NoSQL 데이터베이스라고 합니다만 주로 금융회사나 정부 기관 및 의료 기관에서 급격히 보급되고 있는 빅테이블 클론입니다.
태생이 NSA(National Security Agency)에서 2008년에 시작된 프로젝트라는 것에서 부터 특히 보안 부분에 특화되었다는 인상을 받을 수도 있겠습니다.
그 시작점이 암시하는 것처럼 보안을 강화하고 성능을 높히기 위한 아키텍쳐를 가지고 있습니다.

빅데이터도 역시 데이터를 다루는 시스템이기 때문에 보안이라는 측면은 항상 양날의 칼과 같습니다.
일전에도 하둡의 저장 및 전송시의 암호화API Gateway를 통한 보안 시스템에 대한 글을 소개드렸습니다만 데이터베이스 관점에서 보안을 강화한다는 점은 역시나 중요한 출발점이 되겠습니다.

그래서 ‘Apache Accumulo’의 가장 큰 특징인 ‘Cell-level Security’에 대해서 간략하게 소개하겠습니다.
용어는 어려워 보이지만 컨셉은 간단합니다. 기존의 빅데이블 데이터 모델(Data Model)에 이 칼럼 혹은 ‘(Key, Value)’를 읽을 수 있는 권한을 명시한 다른 Key를 하나 더 추가한 것입니다.

유저가 쿼리(Query)를 실행시켜서 이 칼럼을 읽을 수 있으려면 위의 Key에 저장된 ‘보안 라벨’을 만족시켜야 한다는 컨셉입니다.
이것은 계속 변화하는 보안 정책에 맞춰서 각 칼럼의 ‘보안 라벨’의 값을 유연하게 지정함으로써 금융회사나 공공 기관 등의 보안 수준을 유지할 수 있게 해 주는 역할을 가지고 있습니다.
즉, 유저는 본인이 인증되어서 접근할 수 있는 칼럼에만 접근할 수 있도록 아주 세밀하게 보안 정책을 적용할 수 있습니다.

하둡 에코시스템이 빅데이터의 기반 플랫폼이 되면서 일전에 설명드린 하둡 파일시스템(HDFS)과 API 호출 레벨의 보안 플랫폼과 더불어서 에코 시스템 요소들의 전체적인 보안도 큰 고려 요소입니다.

호튼웍스는 Accumulo가 가지고 있는 이 아키텍쳐를 통해서 보다 보안 정책이 중요한 기업 고객들에게도 어플하려고 합니다.
실제로 미국의 의료기관에서는 ‘Affordable Care Act’에서 파생하는 엄격한 데이터 보안 정책이 요구되는 데 Accumulo는 이러한 데이터의 보안성을 유지하면서 데이터를 공유할 수 있는 레퍼런스를 많이 제공하면서 급격히 보급이 되었습니다.

호튼웍스는 이러한 Accumulo를 호튼웍스 데이터 플랫폼(Hortonworks Data Platform)에 통합하면서 아래와 같이 다양한 관점에서 보안성을 향상시켰습니다.
- Secure SQL search to enable real-time aggregations of multi-structured data
- Secure full-text search, using the Lucene syntax to enable keyword search
- Secure graph search, to enable exploration of how data is connected
- JSON support, to enable development of document-style data models
- High concurrency to power applications supporting large numbers of users
- A policy engine and labeling engine to simplify the application of fine-grained security labels to datasets and to enable both Attribute Based and Role Based Access Controls.
이러한 보안성 향성은 결국 Accumulo가 각 칼럼 별로 접근 권한을 유연하게 적용할 수 있다는 특징에서 나온다는 것을 바로 캐치할 수 있을 것입니다.

squirll

위 레퍼런스 아키텍쳐를 보면 기존의 HBase를 ‘Apache Accumulo’로 완전히 대체하는 것이 가능합니다.
이 연동을 통해서 보안에 민감한 금융 기관, 정부 기관, 의료 기관의 빅데이터 프로젝트에 중요한 컴포넌트의 하나로 적용될 수 있을 것으로 기대합니다.

호튼웍스 데이터 플랫폼은 ‘Apache Accumulo’에 대한 기술 지원도 함께 담당하고 있으니 연동 아키텍쳐에 대한 좀 더 자세한 사항은 아래에서 다운로드받아서 검토해 보기 바랍니다.
호튼웍스와 Apache Accumulo의 레퍼런스 아키텍쳐 <-- 다운로드

-----------------------------------------------------------------------------------------------------------------------------
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
—————————————————————————————————————————–

하둡 프레임워크와 구성 요소

Hadoop의 Framework및 구성요소에 대해서 한번 이야기 해보겠습니다.

Hadoop은 크게 2가지 구성요소를 가지고있습니다. 하나는 HDFS 이며 또 하나는 MapReduce입니다.

위에 그림을 보셨듯이 크게 HDFS layer과 MapReduce layer로 나눠지는데요. 2가지 핵심기술에대해서는 자세히 설명하지 않겠습니다. 좌측 메뉴에 보시면 대 분류로 나와있고 그곳에서 설명드리겠습니다.

간단히 2개의 핵심 주요 기능을 간단히 설명하자면

HDFS : 파일 저장기술 ( html, 이미지, 동영상, PDF, 로그 등등 )
MapReduce : 위에 저장된 내용을 병렬로 분석하는 기능

또한 Hadoop은 다른 sub 프로젝트로 구성되어 있습니다. 다른 연관 Project와 연동시 아키텍처는 아래와 같습니다.

위에 보면 회색과 연두색 2가지 종류로 구분되어있는데요. 연두색부분이 Hadoop안에 구성되어있는 부분이며 나머지부분은 연관된 sub project입니다.각각의 Subproect는 저의 Blog의 좌측 메뉴를 보시면 Detail한 내용을 접하실수 있습니다.

간단히 Sub Project를 설명하자면 아래와 같습니다. Subproject로 없는것도 있겠지만 참고만 해주세요.

Avro™: A data serialization system.
Cassandra™: A scalable multi-master database with no single points of failure.
Chukwa™: A data collection system for managing large distributed systems.
HBase™: A scalable, distributed database that supports structured data storage for large tables.
Hive™: A data warehouse infrastructure that provides data summarization and ad hoc querying.
Mahout™: A Scalable machine learning and data mining library.
Pig™: A high-level data-flow language and execution framework for parallel computation.
ZooKeeper™: A high-performance coordination service for distributed applications

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

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

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

Page 1 of 212