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 클러스터에서 Spark Application을 실행하는 모델 (Hadoop Yarn and Spark App model)

This article is based on Hortonworks Partner Content and Expertise

하둡 2.0의 리소스 관리 플랫폼이라고 할 수 있는 YARN(Yet Another Resource Negotiator)에 대해서는 여러 기사에서 소개를 드렸습니다.

하둡 2.0 YARN의 컨셉에 대한 검토와 적용방법
현대적인 하둡 아키텍쳐의 구성요소와 역할

일반적으로 하둡을 경험하면 하둡파일시스템(HDFS)와 맵리듀스(MapReduce)의 패러다임에서 생각을 하게 됩니다만 하둡 2.0에서 YARN의 컨셉이 적용되면서 맵리듀스도 많은 다양한 데이터 처리 방식 중의 하나로 받아들여 지게 되었습니다.
현재 맵리듀스 어플리케이션 다음으로 많이 적용되는 데이터 처리 방식이 스파크(Spark)가 아닐까 싶습니다.

바로 얼마전에 드디어 Spark 1.0이 발표가 되면서 비로소 기업 현장에서 적용할 수준으로 안정화가 되었다는 기대감을 갖게 됩니다.
스파크(Spark)는 맵리듀스가 가진 퍼포먼스에 대한 약점을 보완하는 가장 현실적인 방법으로 받아들여 지고 있지만 제대로 적용하기 위해서는 맵리듀스와의 차이점에 대해서 확실히 할 필요가 있습니다.

그 중에서 하둡 클러스터에서 적용하는 단계에서 가장 현실적인 차이점을 알아 보겠습니다.
간단히 요약하자면, 맵리듀스는 잡(Job)이 하나의 큰 단위로서 인풋 데이터를 받아서 Map task와 Reduce task를 실행시켜서 결과를 저장하는 흐름입니다.
스파크(Spark)는 물론 잡이라는 개념을 사용하고 있지만 많은 잡들을 순차적으로 혹은 병렬적으로 실행시키는 어플리케이션(Application)이라는 상위 단위를 가지고 있습니다.
이 부분은 많은 의미를 가지고 있고 YARN과의 연동 지점에서도 큰 의미를 가지고 있습니다.

“SQL문을 HIVE를 통해서 맵리듀스 잡으로 변환하여 처리하는 경우에 스파크를 사용하면 연관이 있는 잡들을 순차적 때로는 병렬적으로 실행시켜서 성능을 획기적으로 향상시킨다.”
아주 단순하게 얘기하자면 이렇게 요약할 수 있겠습니다.
이 부분을 기술적으로 이해하기 위해서는 DAG 처리 알고리즘에 대한 다른 문서들을 참조하시기 바랍니다.

간단한 스파크 어플리케이션의 구조를 살펴보겠습니다.

spark

스파크 어플리케이션의 본질은 SparkContext 클래스의 인스터스로 보면 됩니다.
물론 어플리케이션은 하나의 잡을 실행시켜서 맵리듀스와 동일한 동작을 하는 형태로도 이용가능하지만 그 힘은 잡을 실행시키고 있지 않더라도 독자적으로 실행되고 있는 ‘Executors’라는 요소에 있습니다.
이 구조를 통해서 데이터를 미리 메모리에 집적시켜서 처리하거나 여러 가지 잡을 실행할 수 있는 기반을 제공합니다.

아키텍쳐에서 보면 두 개의 잡이 있지만 각각 Executor에서 태스크들을 병렬적으로 실행할 수 있는 구조라는 점을 보여 줍니다.
위 다이어그램에서 스파크 드라이버(Spark Driver)는 맵리듀스의 잡트래커처럼 잡과 태스크를 분배하고 매니징하는 프로세스로 이해하시면 됩니다.

맵리듀스에서의 태스크는 각자 프로세스에서 돌아가고 태스크가 종료되면 프로세스도 종료되지만 스파크 구조에서는 하나의 프로세스에서 여러 개의 태스크를 실행할 수 있음으로써 성능을 향상시키고 보다 복잡한 데이터 처리를 할 수 있는 유연성을 제공한다는 점이 가장 큰 차이점입니다.

그러면 이러한 스파크 어플리케이션을 YARN 클러스터에서 어떻게 구현하고 있는 지 핵심적인 모델을 살펴보도록 하겠습니다.

yarnspark

YARN은 일종의 하둡 클러스트의 리소스를 전체적으로 관리하는 리소스 매니저라는 부분을 통해서 이 아키텍쳐를 보면 앞에서 설명했던 ‘Executors’는 YARN의 컨테이너로서 동작한다는 것을 이해할 수 있습니다.

맵리듀스가 YARN의 컨테이너에서 각 태스크마다 별도의 JVM을 실행시키는 것과 달리 스파크는 하나의 컨테이너에서 여러 개의 태스크를 실행하고 태스크가 종료되더라도 남아 있다라는 차이를 다시 한 번 생각해 볼 필요가 있습니다.

스파크 어플리케이션이 YARN에서 실행되면 먼저 어플리케이션 매스터(Application Master) 프로세스가 생성이 되는 데 이것이 바로 Spark Driver를 실행하는 컨테이너가 됩니다.
그리고 이 Spark Driver가 YARN의 리소스 매니저와 협상하여 이 어플리케이션을 실행하기 위한 리소스를 받아냅니다.
리소스를 받아내면 YARN 노드 매니저(Node Manager)에게 Spark Executor를 실행하기 위한 컨테이너를 생성하도록 지시합니다.
이 후에 이 Spark Executor가 태스크들을 할당받아서 실제로 태스크를 수행하는 프로세스입니다.

스파크에 대한 자세한 설명은 다음 문서를 참조하시기 바랍니다.
Spark Documentation <-- 다운로드

실제로 스파크는 성능 및 유연성에서 맵리듀스보다 구조적으로 월등하기 때문에 특히 SQL구문을 통해서 결과를 바로 얻어내기 위한 시나리오에서는 맵리듀스보다 탁월합니다.
그리고 자체적으로 맵리듀스의 기능도 포함하기 때문에 앞으로는 보다 더 많은 분야에 활용될 것으로 기대가 되고 있습니다.

하지만 스파크 어플리케이션을 YARN 클러스터에서 세팅하고 운영하는 부분은 아직 쉽지 않습니다.
호튼웍스 데이터 플랫폼은 이러한 스파크 어플리케이션을 위해 클러스터를 세팅하고 운영하는 부분을 직관적으로 하기 위해서 배포판에 통합하여 제공하고 있으니 실제 도입 시에는 통합 테스트가 된 배포판을 이용함으로써 많은 시행착오를 줄일 수 있을 것입니다.

앞으로는 Spark Application을 어떻게 활용할 것인지를 중심으로 소개드리도록 하겠습니다.

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

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

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

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

하둡 클러스터는 어느 정도 크기로 해야 할까? (How big is big anyway?)

This article is based on Hortonworks Blog.

빅데이터에 대한 도입을 결정하는 데 있어서 현실적인 문제 중의 하나는 아마도 어느 정도 규모의 하둡 클러스터를 구축해야 하는가?
라는 문제에 집중이 될 것 같습니다.

경험이 많은 아키텍트들은 기존의 IT 수요를 분석하는 나름의 방법론을 가지고 어느 정도 예측이 가능하지만
하둡에 대한 경험이 없는 경우에는 클러스터를 어떤 규모로 준비(Provisioning)해야 하는 지 고민이 많은 것도 사실입니다.

호튼웍스(Hortonworks)에서 재밌는 툴을 하나 공개했네요.
아주 간단하게 조건을 입력하면 대략적인 사이즈를 보여 주는 툴입니다.
그리고 하둡 클러스터를 설계할 때 필요한 백서도 공유하고 있는 데 이 백서는 하둡 도입을 고려하는 아키텍트에게는 권할 만한 내용입니다.

하둡 클러스터를 디자인하고 사이징하는 과정은 실제로 하둡 아키텍트들이 고객들과 가장 많은 시간을 들이는 과정이므로 기본적으로 어떤 가정들을 통해서 설계하는 지에 대한 인사이트는 아주 중요하다는 생각입니다.
스토리지 볼륨의 크기에서부터 성장률(Growth rate), 압축률까지 고려해야 할 사항은 아주 많습니다.

built a cluster-size-o-tron which performs a more simplistic calculation based on some assumptions on node sizes and data payloads to give an indication of how big your particular big is.

보다 자세한 내용은 Cluster Configuration Guide를 참조해서 인사이트를 얻으세요.

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

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

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

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

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

Page 1 of 712345...마지막페이지