Tags

하둡 파일 시스템의 이기종 스토리지 지원 모델의 진화

This article is based on Hortonworks Partner Content and Expertise

하둡 2.0은 기존의 하둡 1.0과는 전혀 다른 아키텍쳐라는 의견들이 많습니다.
이러한 빠른 발전때문에 오히려 초창기부터 하둡을 접했던 아키텍트들은 이러한 많은 변화를 수용하는 데 어려움을 많이 느끼고 있다는 생각이 듭니다.

그 동안 데이터를 처리하는 YARN(Yet Another Resource Negotiator)의 관점에서 많은 토픽을 잡았지만 사실 하둡 파일 시스템 자체도 많은 컨셉의 변화가 있었습니다.

그 동안 다뤘던 부분은 다음과 같습니다.
하둡 파일 시스템의 새로운 아키텍쳐
하둡 파일 시스템을 기업의 다양한 스토리지 환경에 적용하는 방법

전통적으로 하둡 파일 시스템은 균일한 로컬 하드디스크에 초점을 두고 만들어졌습니다.

대용량 파일을 일정한 단위(Data Block)로 쪼개서 많은 서버의 로컬 하드디스크에 저장하고 분석을 위한 코드를 직접 이 서버에 보내서 각 서버 상에서 분석을 실행한다

아마 일반적으로 하둡에 대한 이미지는 위의 컨셉을 기반으로 하고 있습니다.
하지만 엔터프라이즈 환경은 많은 다양한 스토리지 시스템에 대한 투자가 이미 이루어져 있으며 최근에 이른바 메모리 기반 스토리지(Full SSD Stoage) 등이 보다 신속하고 실시간 분석을 위해서 도입이 되고 있습니다.

하둡 파일 시스템은 본격적으로 엔터프라이즈의 이러한 니즈에 대응하기 위해서 기업의 다양한 스토리지 환경을 최대한 이용해서 최고의 성능을 낼 수 있도록 진화를 했습니다.

heterostorage

위의 다이어그램에서 보는 것처럼 워크로드에 따라서 메모리, SSD Storage, 하드디스크 그리고 분산파일시스템의 스토리지까지 이른바 이기종(Heterogeneous) 환경을 지원하는 형태로 변화했습니다.

최근에는 각 서버의 메모리 용량이 커지고 가격도 지속적으로 하락하여 처리 속도를 향상시키기 위해서 메모리를 캐싱(Caching Storage) 스토리지로 이용하고자 하는 니즈가 더욱 커졌습니다.

현재는 이른바 요청이 많은 파일(hot file)에 일종의 태그(Tag)를 붙임으로써 이러한 파일이 캐싱이 되는 형태로 구현이 되어 있습니다.

하지만 앞으로는 파일의 사용 패턴에 따라서 이 과정을 자동화하기 위한 연구가 계속되고 있으며 하둡 에코시스템의 성능을 전반적으로 향상시키기 위해서 많은 노력을 기울이고 있는 분야입니다.

그 중에서 핵심적이라고 할 수 있는 DDM(discardable distributed memory)라는 새로운 컨셉에 대해서 잠깐 더 살펴보고자 합니다.

향후 실시간 분석에 대한 니즈가 커지고 분석 성능을 향상시키고 기존의 인프라 투자를 최대한 효율적으로 이용한다는 여러 가지 측면에서 반드시 검토해 볼 필요가 있습니다.

DDM의 목적은 메모리 스토리지를 추상화시켜서 하둡 에코시스템 및 어플리케이션이 이용할 수 있도록 하는 형태로 제공하는 것입니다.

DDM은 SSD 스토리지를 이용하는 정책 등과 함께 연동되어서 위의 다이어그램에서 본 것처럼 이기종 스토리지를 충분히 활용하기 위해서 메모리를 스토로지의 한 형태로 제공하는 기술입니다.

보다 자세한 사항은 아래 페이지를 참조하시기 바랍니다.
HDFS-5851

이러한 기술들은 워크로드의 데이터 니즈에 따라서 가장 효과적인 스토리지로 데이터를 자동으로 옮기는 이른바 스토리지 티어링(Storage tiering)을 위해서도 핵심적인 요소입니다.

이기종 스토리지의 동작 방식은 다음과 같습니다.

- 데이터노드(Datanode)는 데이터 블록을 저장할 스토리지의 타입을 인식하여 이것을 네임노드(NameNode)에 리포트합니다.

- 네임노드는 각 데이터블록의 위치뿐만 아니라 각 데이터노드가 관리하는 스토리지의 타입도 지속적으로 추적해서 업데이트합니다.

- 클라이언트는 데이터 블록의 위치와 더불어 저장되어 있는 스토리지 타입에 대한 정보도 네임노드를 통해서 얻게 됩니다.

이러한 이기종 스토리지 지원을 통해서 다양한 용도에 이 모델을 적용할 수 있습니다.

1. 특정 어플리케이션은 파일을 생성하고 이 파일을 구성하는 데이터 블록(Data Block)을 특정한 스토리지 타입에 저장되도록 지정할 수 있습니다.

예를 들어, 3개의 복제 데이터 중에 2개는 일반적인 하드디스크에 저장하고 1개는 빠른 SSD타입 스토리지에 저장되도록 세팅할 수도 있습니다.
이러한 세팅은 기존의 값비싼 SSD 타입 스토리지의 투자를 충분히 활용할 수 있습니다.

2. 특정 어플리케이션은 어떤 파일의 저장 스토리지를 다른 타입으로 변경해서 저장할 수 있습니다.

즉, 일전에는 분석 작업의 주기가 길어서 하드디스크에 저장했던 데이터를 분기나 혹은 특정 시기에 빠른 분석이 필요할 때 SSD와 같은 빠른 스토리지 타입으로 옮긴 이후에 작업을 진행할 수 있습니다.

3. 하둡 시스템 관리자는 각 스토리지 타입별로 쿼터(Quata)를 지정해서 효율적으로 관리할 수 있습니다.

4. 파일에 대한 액세스 패턴(Access Pattern)에 따라서 가장 많이 쓰이는 데이터를 가장 빠른 스토리지로 자동으로 옮기도록 세팅할 수 있습니다.

하둡 파일 시스템은 엔터프라이즈 데이터 플랫폼으로 진하하는 데 반드시 필요한 스토리지 자원의 극대화에 대해서도 점차 완전하게 지원하는 쪽으로 진화하고 있습니다.

이러한 진화에 대해서는 앞으로도 자주 소개하도록 하겠습니다.

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

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

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

하둡과 스플렁크의 연동 모델 (Unlocking the Business Value of Big Data with Splunk and HDP 2.1)

This article is based on Hortonworks Partner Content and Expertise

그 동안 하둡이 가진 유연한 플랫폼으로서의 속성때문에 많은 솔루션들이 다양한 연동 포인트를 통해서 하둡을 활용하는 방법에 대해서 많이 소개드렸습니다.

하둡과 SAP의 제품들을 연동하는 방법
하이브와 다른 분석툴을 연동하는 방법
자사의 솔루션을 하둡과 연동한다는 것의 의미와 방법 (SAP HANA case)
미들웨어를 하둡과 연동한다는 것의 의미와 방법

하둡은 이른바 엔터프라이즈 데이터 허브(Enterprise Data Hub)에 적합한 유연성을 가지고 있습니다.
필요에 따라서 기존의 솔루션을 하둡과 연동함으로써 빅데이터를 가장 비용 효율적으로 수용하는 방법은 앞으로도 많은 시도가 있을 것으로 봅니다.

특히, YARN이 도입이 되면서 다양한 어플리케이션이 하둡 클러스터에서 공존하는 프레임워크가 만들어 지면서 이러한 움직임은 더 가속화되고 있습니다.

얼마전에 스플렁크(Splunk)와 호튼웍스 하둡의 연동 테스트가 마무리되면서 기존의 스플렁크 이용자들도 하둡과 연동하여 보다 비용 효율적으로 빅데이터 시스템을 확장할 수 있는 방법이 생겼습니다.

스플렁크와 하둡 연동의 의미

스플렁크는 일종의 ‘Google for Machine Log’라는 별명답게 주로 서버 로그나 센서 데이터 처럼 실시간으로 생성되고 스트리밍되는 데이터를 모아서 ‘인덱싱’하는 과정을 통해서 검색, 분석, 비쥬얼라이제이션을 실시간으로 처리하는 빅데이터 솔루션입니다.

이번에 Hunk 6.1을 발표하면서 하둡에 저장되어 있는 데이터셋을 간단히 지정하는 것만으로 위의 스플렁크의 기능을 바로 사용할 수 있도록 연동성이 강화되었습니다.

Splunk1-1024x834

위 다이어그램에서 보는 것처럼 스플렁크와 하둡의 연동을 통해서 가장 확실하게 효용성이 있는 데이터셋들은 주로 다양한 소스에서 실시간으로 생성되고 스트리밍되는 데이터셋이라는 특성을 가집니다.

이 부분은 기존에 스플렁크가 가장 강점을 가지고 적용이 되었던 분야입니다.

기존에는 스플렁크의 독자적인 Repository를 통해서 이런 로그데이터를 저장했던 것에 비해서 하둡의 파일 시스템(HDFS)에 이러한 데이터셋을 통합해서 저장하고 스플렁크에서 ‘Natively’ 처리할 수 있습니다.

구체적으로는 하둡의 YARN 클러스터에서 스플렁크의 어플리케이션이 돌아가도록 한 부분과 기존의 맵리듀스를 아파치 Tez 기반으로 재설계한 점을 들 수 있습니다.
그리고 하둡 파일시스템(HDFS)뿐만 아니라 Apache Accumulo, Cassandra, MongoDB, Neo4j 등에 저장된 데이터셋에 대해서도 간단히 지정하고 인덱싱해서 분석할 수 있도록 개발을 진행했습니다.

스플렁크는 다른 분석툴이 일반적으로 하는 것처럼 HIVE의 JDBC 인터페이스를 기반으로 연동하는 방식이 아니라 하둡 에코시스템의 다양한 플랫폼들을 직접 연동할 수 있도록 아키텍쳐를 재설계했다는 점에서 가장 전방위적인 접근이 아닌가 싶습니다.

만약에 스플렁크와 비교적 동일한 효과를 하둡 에코시스템에서 구현하기 위해서는 많은 노력이 필요합니다.
하둡을 검색엔진과 연동하는 방법 및 아키텍쳐

이미 검증된 스플렁크를 활용함으로써 이른바 Operational Intelligence를 하둡 기반으로 구축하는 방법으로 기업 환경에서 다양하게 적용가능한 옵션이 되었습니다.

실제로 스플렁크와 하둡을 연결하는 방법은 아래 페이지를 참조하시기 바랍니다.
스플렁크와 하둡의 연동

우리도 많은 기업용 솔루션이 있고 하둡과의 연동을 통해서 빅데이터를 수용하는 솔루션으로 새로운 가치를 발견할 수 있다는 측면에서 이 사례를 검토해 보면 많은 힌트를 얻을 수 있을 것입니다.

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

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

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

기존의 어플리케이션을 하둡 YARN 기반으로 손쉽게 전환하는 방법 (Apache Slide technical preview)

This article is based on Hortonworks Partner Content and Expertise

하둡에서 YARN이 도입이 되는 것이 어떤 의미인지는 그 동안 다른 기사들을 통해서 많이 소개드리고 있습니다.
하둡 2.0 YARN의 컨셉에 대한 검토와 도입 방법
현 시점에서 하둡 2.0을 도입해야 할 필요가 있는가?
하둡 YARN 기반으로 Spark 어플리케이션을 도입하는 방법

하둡의 YARN은 하둡 클러스터의 전체 리소스를 관리하는 기능을 담당하고 각 어플리케이션은 별도로 Application Master를 통해서 관리하도록 분리시키는 방법으로 하둡 위에서 다양한 처리 방식을 지원하는 어플리케이션을 개발할 수 있는 기반을 제공합니다.

즉, 각 어플리케이션은 YARN의 리소스 매니저에게 필요한 리소스를 할당받은 이후에 어플리케이션을 실행하는 방법으로 하나의 클러스터에서 다양한 어플리케이션을 운용할 수 있는 아키텍쳐를 가능하게 했습니다.

YARN 아키텍쳐에서 현재 어떤 형태의 데이터 처리 방식이 가능한 지 다이어그램을 보겠습니다.

slider

하둡의 에코시스템을 시스템, 엔진, API라는 세 가지 틀로 단순화시키면 위의 다잉어그램에서 보는 것과 같은 형태로 파악할 수 있습니다.

하둡파일시스템의 위에 YARN이 하둡 클러스터의 리소스를 담당하고 그 위에 배치 작업인지 SQL문을 실행시키는 방식인지 아니면 스트리밍 데이터를 실시간으로 처리하는 방식인지에 따라서 일종의 플랫폼이라고 할 수 있는 세 가지 엔진이 그 위에서 돌아갑니다.

이 세 가지 엔진 중에서 물론 맵리듀스와 같은 배치 처리 엔진이나 Tez와 같이 인터랙티브 쿼리(Interactive Query)를 실행하는 부분은 소개를 드렸지만 실시간 처리에 대한 슬라이드(Slide)에 대해서는 생소할 겁니다.

그 동안 스트리밍에 대해서는 스톰(Storm)을 직접 이용하는 형태로 도입이 이루어졌지만 점차 NoSQL의 연동을 통한 실시간 처리에 대한 수요가 부각되면서 비교적 최근에 하둡 에코시스템에 도입이 되었습니다.

그 외에도 YARN의 기능을 이용하는 다양한 어플리케이션을 손쉽게 개발하기 위한 방법이 필요하다는 니즈가 커지면서 본격적으로 그 효용성이 받아들여 지고 있습니다.

아파치 슬라이드(Slide)는 한 마디로 기존에 YARN 환경을 고려하지 않고 개발된 분산 어플리케이션을 YARN 환경에서 돌아갈 수 있도록 해 주는 플랫폼입니다.

아파치 슬라이드(Slide)는 호튼웍스에서 다음 네 가지 목표에 초점을 두고 프로젝트화한 플랫폼입니다.

Simplified on-boarding of existing apps to Hadoop YARN
그 동안 기업에서 많은 분산 어플리케이션을 개발해 왔는 데 이러한 어플리케이션을 거의 코드를 재수정하지 않고도 YARN에서 운용할 수 있도록 해 줍니다.

Full capabilities of a YARN application
아파치 슬라이드(Slide)는 어플리케이션이 론칭되고 모니터링하고 데이터 처리 수요에 따라 하둡 클러스터에서 확장되는 등의 많은 업무를 처리하는 플랫폼을 제공하여 분산 어플리케이션을 개발하는 업무에 집중할 수 있는 장점이 있습니다.

Automated lifecycle management
아파치 슬라이드(Slide)는 YARN상의 어플리케이션을 암바리와 연동하여 관리할 수 있는 옵션을 제공합니다.

호튼웍스에서 HBase, Accumulo, Storm의 세 가지에 대해서 슬라이드와 연동해서 운영할 수 있는 샘플을 제공하고 있으니 자세한 사항은 이 부분을 참조해 주시기 바랍니다.

기존의 분산 어플리케이션을 슬라이드를 이용해서 연동하기 위한 방법

이 링크에서 실제로 YARN에서 돌아가는 세 가지 어플리케이션의 버전을 직접 다운로드할 수 있습니다.

기존에 기업들이 개발해 온 많은 데이터 처리 어플리케이션을 하둡 위에서 운용하기 위한 부분은 아주 중요한 영역이지만 많은 노력이 필요로 합니다.

아직은 인큐베이팅 프로젝트이지만 슬라이드(Slide)가 가진 가능성은 아주 크다고 생각합니다.

아래 Technical Preview 문서를 참조해서 직접 샘플을 돌려 보시고 기존의 어플리케이션을 어떻게 하둡과 연동할 지에 대한 방법도 함께 고려하면 좋을 듯 합니다.

Apache Slide Technical Preview <-- 클릭

아파치 슬라이드의 도입과 더불어서 많은 기업용 어플리케이션들이 하둡과 연동해서 빅데이터 어플리케이션으로 효용성을 높힐 수 있는 계기가 되었으면 합니다.

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

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

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

몽고 DB와 하둡의 연동 모델 (Mongo DB hadoop connector)

This article is based on Hortonworks Partner Content and Expertise
그 동안 여러 가지 엔터프라이즈 솔루션과 하둡과의 연동 모델에 대해서 소개를 해 드렸습니다.
하둡이 가진 ‘데이터 글루’ 혹은 ‘데이터 통합’의 가능성에 대한 좋은 실례들이라고 할 수 있겠습니다.

하둡 2.0으로 넘어 오면서 데이터를 처리하는 상이한 유스케이스에 맞게 다양한 어플리케이션들이 연동이 되면서 기업의 다양한 데이터를 수용할 수 있는 저장 방법은 물론이고 처리 방법에 대해서도 통합적인 관점을 제시하고 있습니다.

하지만, 근본적으로 데이터베이스와 하둡 사이에는 간극이 존재합니다.
그 이유는 하둡의 문제점이라기 보다는 대용량의 파일을 읽어서 합리적인 시간 내에 분석한다는 하둡의 기본 철학 때문에 발생합니다.

그래서 기존의 데이터베이스와 하둡을 연동해서 양 쪽의 장점을 취하는 방법은 여러 가지 방법으로 접근이 이루어 지고 있습니다.
물론 SQL in Hadoop 혹은 SQL on Hadoop 등 하둡에서 부터 수용을 해 나가는 여러 가지 프로젝트들이 있습니다.

최근에는 이미 안정된 noSQL 기반의 기술과 하둡을 연동하면 보다 더 다양한 유스케이스를 지원할 수 있다는 점에서 몽고 DB 등과 하둡을 연동해서 최적화 하기 위한 방법들이 많이 소개되고 있습니다.

몽고 DB는 이미 다양한 기업에서 검증이 되고 있는 오픈소스 기반의 NoSQL이고 바로 얼마 전에 호튼웍스와의 공동 노력으로 보다 안정된 방법으로 연동이 가능해 졌습니다.
‘MongoDB Hadoop Connector on Hortonworks’라는 솔루션을 통해서 보다 간편하게 하둡과 연동 모델을 만드는 것이 가능해 졌습니다.

reference_mongodb_arch

이 연동 모델을 검토해 보면 몽고 DB는 결론적으로 ‘실시간 Operational Database’의 역할에 집중해서 하둡으로 이러한 유스케이스를 처리하기 위한 오버헤드를 제거할 수 있습니다.
이 모델에서 하둡의 역할은 몽고 DB를 통해서 실시간으로 처리한 데이터들을 가지고 다양한 분석을 하는 형태로 지원 기능을 담당하도록 구성할 수 있습니다.

실제로 기업에 하둡을 적용하는 데 있어서 가장 어려운 부분이 이러한 ‘실시간 트랜잭션 데이타’에 대한 부분인데 하둡을 통해서 이 기능까지 수용하려는 노력보다는 몽고 DB를 연동함으로써 보다 효율적으로 대응할 수 있을 것입니다.

이 모델에서 몽고 DB의 데이터는 바로 호튼웍스 하둡 플랫폼으로 스냅샷되어서 ‘Near realtime’ 분석을 가능하게 해 줍니다.
역으로 이렇게 분석된 데이터는 다시 몽고 DB로 보내져서 다른 트랙잭션에 활용할 수 있습니다.

보다 자세한 사항은 아래 문서를 참조하세요.
Mongo DB Hadoop Connector Documentation

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

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

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

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

금융산업의 혁신을 위한 호튼웍스 하둡 아키텍쳐 (Modern Financial Services Architectures Built with Hadoop)

This article is based on Hortonworks Partner Content and Expertise

그 동안 각 산업의 버티컬 영역별로 안고 있는 문제점들과 하둡을 통해서 이러한 문제를 어떻게 해결할 수 있는 지에 대해서 소개해 드리고 있습니다.

의료 산업의 혁신을 위한 하둡 아키텍쳐
제조업을 위한 하둡 아키텍쳐
통신사를 위한 하둡 아키텍쳐
유통업을 위한 하둡 아키텍쳐
광고 산업을 위한 하둡 아키텍쳐
정유 산업을 위한 하둡 아키텍쳐

실제 하둡 데이터 플랫폼을 어떻게 구축할 것인지에 대한 기술적인 부분보다는 이러한 산업 별로 경험하고 있는 문제들에 대한 인사이트를 얻는 부분이 더 중요하다는 생각입니다.

금융업은 실제로 하둡을 적용한 사례가 많고 앞으로 더 많이 적용될 것으로 예상되는 영역입니다.
우리나라는 빅데이터와 보안에 대한 오해들이 조금 있어서 상대적으로 도입 논의가 더딘 것은 사실입니다만 하둡이 가지고 있는 장점과 보안 체계에 대한 이해가 점차 컨센서스를 이루어 가면 급속도로 도입 논의가 진행될 것입니다.

사실 하둡은 전체적으로 데이터를 다루는 플랫폼이다보니 보안이 아주 중요한 이슈로서 핵심분야 중의 하나로 가장 많은 노력을 기울이고 있는 분야 중의 하나입니다.

호튼웍스 하둡과 NoSQL을 연동하는 방법 (Accumulo case)
하둡에서 데이터 전송 시의 암호화
하둡의 보안을 위한 체계

금융업을 데이터 플랫폼의 관점에서 고려하면 리스크(Risk)를 최소화하고 기회(Opportunity)를 극대화하는 과정에서 특히 많은 데이터에 직접적으로 의존하는 분야로 정의할 수 있습니다.
예를 들어, 보험회사들이 보험 상품을 기획할 때의 모든 프로세스에는 각종 통계 데이터와 향후 예측 모델링에 이르기까지 이미 산업 전체가 Data-driven organization으로 분류할 수 있을 정도로 많은 데이터를 분석하는 업종입니다.

하지만 데이터에 대한 각종 규제과 규칙이 가장 엄격하게 적용되어야 하는 분야라는 상충되는 부분도 함께 존재합니다.
한 개인의 실수 혹은 나쁜 의도에 의해서도 회사 전체에 영향을 미칠 정도로 데이터에 대한 관리 방식이 중요한 분야입니다.

금융업을 위한 하둡 아키텍쳐를 설계할 때 가장 기본적인 목표는 이러한 리스크(Risk)와 기회(Opportunity) 양 쪽에 가장 명확한 인사이트를 주는 것으로 설정할 수 있겠습니다.
금융업을 규정하는 사업에 대한 보다 많은 정보를 누수없이 실시간으로 처리함으로써 운영 효율성을 극대화하고 새로운 기회를 모색하는 분야와 리스크의 원천에 대한 이상 패턴을 조기에 파악하는 작업을 통해서 위험을 회피할 수 있습니다.

Financial companies do Hadoop.

Financial-Services-Ref-Arch.20140310

위 아키텍쳐의 기본 구성은 “현대적인 하둡 아키텍쳐의 구성 요소와 역할”에서 설명드린 컴포넌트들로 이루어져 있습니다.

그러면 금융업에서 바로 적용할 수 있는 하둡의 적용 분야에 대해서 살펴 보겠습니다.

Screen New Account Applications for Risk of Default
특히 은행의 경우에는 매일 수만 건의 신규 계좌 개설 및 해지 등의 요청이 들어 옵니다. 은행은 이러한 계좌 신청 등에 대해서 제3의 신용 정보 기관에 정보를 조회하는 과정을 거쳐서 잠재적인 리스크를 줄이는 과정을 진행합니다.
하지만 이러한 신용 정보 기관의 조회를 통한 방법은 극히 한정된 거래 내역이나 정보를 기반으로 하고 있어서 각 계좌에 대한 보다 명확한 등급의 설정이나 리스크의 예측을 어렵게 만들 가능성도 있습니다.

예를 들면, 이른바 대포통장 등의 문제는 우리나라만의 문제가 아니라 광범위하게 골치를 앓고 있는 분야 중의 하나입니다.
이러한 통장 개설에서의 충분한 스크리닝(Screening)이 이루어 지지 않은 문제는 다른 각종 금융 사기(Fraud)와 연결되는 시발점이 된다는 측면에서 리스크를 급속도록 증대시킵니다.

하둡은 단순한 이전의 거래 내역뿐만 아니라 실시간으로 거래 현황을 종합적으로 분석하고 패턴을 감지함으로써 잠재적인 리스크가 되기 이전에 관리하는 것이 가능합니다.
점차로 이러한 이상 패턴에 대한 정보가 쌓이고 Mahout 등을 이용한 머신 러닝 알고리즘을 적용해서 계좌에 대한 각종 정책을 지정하는 데에도 확실한 근거 자료를 제공합니다.

Monetize Anonymous Banking Data in Secondary Markets
은행이 처리하는 각종 데이터와 정보는 다른 산업 주체들의 입장에서도 아주 중요한 기반 데이터라는 측면이 부각되고 있습니다.
은행이 가지고 있는 수많은 계좌들의 트랜잭션 데이터와 정보는 경제 전체의 트렌드에 대한 인사이트도 함께 가지고 있으며 이러한 정보는 각종 투자자들, 기업들, 정책 입안자들과 같이 은행 외부에 있는 사람들에게도 가치 있는 데이터가 됩니다.

Retail banks have turned to Apache Hadoop as a common cross-company data lake for data from different LOBs: mortgage, consumer banking, personal credit, wholesale and treasury banking. Both internal managers and consumers in the secondary market derive value from the data.

은행은 모기지 정보나 신용카드 사용 추이 등의 중요한 정보를 다른 2차 시장의 회사들과 공유함으로써 새로운 가치를 만드는 것에 주목을 하고 있고 실제로 하둡 기반으로 이러한 정보들을 조인해서 실시간 분석 결과를 제공하는 시스템이 운영 중에 있습니다.

Improve Underwriting Efficiency for Usage-Based Auto Insurance
자동차 보험은 고객의 사고 이력 등의 데이터를 바탕으로 사업이 이루어지는 대표적인 데이터 기반 의사결정 조직(Data-driven Organization)입니다.
최근에는 실제로 고객이 운행한 실적에 따라서 요금을 달리하는 등의 비즈니스 모델이 도입되는 것처럼 실시간으로 처리해서 분석해야 할 데이터 볼륨은 급속도로 늘어 나고 있습니다.

Advances in GPS and telemetry technologies have reduced the cost of capturing the driving data used to price PAYD policies, but the data streaming from vehicles grows very quickly, and it needs to be stored for analysis.

GPS 등의 각종 운행 정보를 바탕으로 유연한 비즈니스 모델을 도입하는 데 있어서 하둡 기반 플랫폼을 적용하는 사례가 많아지고 있습니다.

Analyze Insurance Claims with a Shared Data Lake
Maintain Sub-Second SLAs with a Hadoop “Ticker Plant”
Surveillance of Trading Logs for Anti-Laundering Analysis

그 외에도 각종 금융 사기(Fraud)의 패턴을 바탕으로 실시간으로 검열하는 시스템이나 보험 청구에 대한 정당함을 증명하기 위해서 보험 회사 내외의 각종 데이터 정보를 조인해서 문제점을 발견하는 등의 다양한 분야에서 적용이 되고 있습니다.

금융업의 실제 프로젝트 적용 사례에 대해서는 앞으로도 지속적으로 살펴 보겠습니다.

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