Tags

하둡과 스플렁크의 연동 모델 (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
———————————————————————————————————–

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

엔터프라이즈 레벨 실시간 시스템을 위한 최강 조합 (하둡 + 인메모리 데이터베이스)

This article is based on Hortonworks Partner Content

그 동안 실시간 혹은 리얼타임 하둡에 대해서 몇 번 소개를 했습니다.
하둡의 실시간 분석 시스템에 대한 Technical Preview
실시간 하둡 데모와 실행 코드
리얼타임 하둡의 가능성

실시간 하둡의 중심에는 스톰(Storm)이 자리하고 있습니다.
스톰(Storm)은 ‘실시간 하둡 데모와 실행 코드’에서 볼 수 있듯이 이벤트 스트리밍 데이터를 실시간으로 처리할 수 있는 하둡 2.0의 새로운 플랫폼입니다.

최근에 각종 센서와 머신로그, 데이터센터에서 대량으로 생산되는 서버 로그 및 이벤트, 통신사에서 지속적으로 발생하는 CDR 데이터, 운송 회사에서 각 운송장비들의 위치 정보 등등이 스톰을 통해서 처리할 수 있는 데이터의 예라고 볼 수 있겠습니다.

하둡 2.0은 YARN(Yet Another Resource Negotiator)의 도입과 함께 기존의 배치 처리는 물론이고 스트리밍 데이터에 대한 실시간 처리도 하나의 클러스터에서 처리할 수 있도록 진화했습니다.

하지만 기업에서 실제로 이러한 강력한 스트리밍 처리 기능을 실시간으로 분석하는 케이스를 고려해 보면 한 가지 비어 있는 부분이 있습니다.
즉, 아무리 하둡 데이터 플랫폼에서 스트리밍 데이터를 실시간으로 처리할 수 있더라도 이 데이터를 역시 실시간으로 분석하는 시스템이 준비되어 있지 않으면 그 효과는 반감될 것입니다.

아래 호튼웍스(Hortonworks)와 SAP(SAP AG)가 공동으로 발표한 아키텍쳐를 한 번 검토해 보도록 하겠습니다.
이 조합에서 SAP HANA는 ‘인메모리 데이터베이스’로서 분석 데이터 처리를 위해 하드디스크가 아니라 메모리에서 바로 처리하는 시스템입니다.

일전의 블로그에서 SAP HANA와 하둡의 연동에 대한 튜토리얼을 소개드린 적이 있었습니다.

saphanaphadoop

이 조합은 아래와 같이 네 가지 측면에서 아키텍쳐 상 스트리밍 데이터를 처리하기 위한 가장 ‘이상적인’ 형태를 보여 주고 있습니다.
• 각종 오프레이션 시스템(Operation System), 센서 네트워크, 모바일 기기 등의 데이터 소스로 부터 실시간 데이터 입력
• 스트리밍되는 데이터에 대한 패턴 인식, 이상 이벤트 식별, 그리고 스트리밍 분석의 실시간 적용
• 각종 데이터 사이언스 함수를 적용하기 위한 확장성 있는 오프라인 스토리지
• 즉각적인 혹은 실시간 시각화(Visualization)

짧게 요약하자면, 각종 이벤트들을 스톰(Storm)에서 실시간으로 읽어 들여서 전처리를 한 후에 하둡 파일시스템(HDFS)에 저장하면서 SAP HANA의 메모리에 올려서 실시간으로 분석하는 시나리오입니다.

보통 이러한 실시간 처리는 다음과 같은 두 가지 종류의 문제를 해결하는 데 유용하다고 합니다.
즉, 실시간으로 발생하는 이벤트에서 원하지 않는 이벤트를 ‘방지’하거나 아주 정밀하게 ‘최적화’하는 적용 사례입니다.

storm

예를 들어, 신용 카드 회사에서 실시간으로 발생하는 트랜잭션에서 어떤 불순한 카드 이용(Fraud)을 식별해서 실시간으로 조치해야 하거나 네트워크에서 해킹 공격의 징후를 식별해서 실시간으로 차단하거나 하는 등의 분야에 적용가능하겠습니다.

하지만, 실제로 이 아키텍쳐를 구축해보고 Test/Evaluation하는 것은 쉬운 일이 아닙니다. (SAP HANA 시스템을 어디서 구하지?)
가장 간단한 방법은 KT의 유클라우드에서 제공하는 SAP HANA 서버 이미지를 클라우드에서 론칭하고 하둡 시스템과 연동해서 본격적인 구축 작업 전에 poC를 먼저 해 보면 어떨까 싶습니다.

앞으로 스트리밍 데이터의 처리에 대한 부분은 이른바 사물인터넷으로 불리는 영역과도 연관되어서 많은 논의가 이루어 지고 있습니다.
호튼웍스 + SAP HANA 조합은 이러한 미래형 아키텍쳐에 힌트를 줄 수 있다는 점에서 본다면 많은 가능성을 발견할 수 있을 듯 합니다.

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

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

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

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

하둡 기반의 기업용 데이터 관리 시스템을 쉽게 구축할 수 있는 방법 (Apache Falcon Technical Preview)

This article is based on Hortonworks Partner Content

하둡이 기업용 데이터 관리 시스템으로 본격적으로 받아들여지기 위해서는 어떤 부분들이 더 보완되어져야 할까요?
하둡 에코 시스템은 기본적으로 다양한 데이터 소스의 데이터를 분산시켜서 저장하고 합리적인 시간 내에 처리하기 위한 플랫폼의 관점으로 접근해 봅시다.

일단 이러한 하둡 클러스터가 구축이 되고 나면 기업들은 이 클러스터에서 관리하는 데이터들에 대해서 여러 가지 작업을 하게 됩니다.
데이터셋을 다른 시스템으로 옮기거나, 백업하거나, 아카이빙 할 수도 있고 다른 데이터 파이프라인(Data Pipeline)의 어느 단계에 집어 넣거나 하는 등의 스케쥴링(Scheduling)하는 등의 작업이 진행이 됩니다.

그리고 데이터셋에 대해서도 기존의 라이프 싸이클(Life Cycle)관리 정책이 적용될 수도 있습니다.
예를 들면, 어느 정도 시간이 지난 데이터는 다른 스토리지로 이동하거나 삭제되거나 아니면 백업하거나 등등의 기존 정책이 이제는 하둡 클러스터 상의 데이터에도 적용이 될 필요가 있습니다.

이러한 본격적인 기업들의 데이터 관리에 대한 요구 사항을 충족하기 위한 프레임워크가 ‘아파치 팔콘(Apache Falcon)’입니다.
아직 초기 단계의 프로젝트이지만 하둡이 기업의 데이터 관리 시스템이 되기 위한 마지막 단추일 지도 모릅니다.

호튼웍스의 관점에서 정리한 아파치 팔콘(Apache Falcon)에 대한 Technical Preview 문서를 공유합니다.
Apache Falcon Technical Preview <-- 다운로드

아파치 팔콘(Apache Falcon)은 크게 다음의 세 가지 목적을 위한 범용 프레임워크입니다.
1. 데이터셋 복제(Dataset Replication)
하둡 파일시스템(HDFS)나 HIVE 테이블 등의 데이터셋을 백업, 아카이빙 혹은 재난 관리(Disaster Recover) 등의 다양한 경우에 따라서 복제하는 것을 자동화할 수 있습니다.
2. 데이터셋 라이프 싸이클(Life Cycle) 관리
데이터셋의 보유 기간 등의 정책을 적용해서 자동적으로 데이터셋의 수명 주기 등을 관리할 수 있습니다.
3. 데이터셋 간의 의존성(Dependency) 관리
하둡 클러스터, 데이터셋 혹은 프로세스 간의 의존 관계를 한 눈에 보여 주고 관리할 수 있습니다.
이 부분은 스케쥴링 등의 작업에 대해서 데이터셋 간의 관계를 쉽게 파악할 수 있게 합니다.

개략적인 아키텍쳐는 다음과 같습니다.

falcon

데이터셋의 관리 정책을 ‘Entity’라는 단위로 정리하여 입력하면 실제로 스케쥴링 작업은 ‘아파치 Oozie‘를 통해서 이루어지 지는 것을 볼 수 있습니다.
‘아파치 Oozie’는 하둡용으로 개발되고 있는 워크플로우 엔진입니다.

이상과 같이 하둡 클러스터의 데이터를 기업의 데이터 관리 플랫폼으로 진화시키는 과정도 빠르게 진행되고 있으니 더 자세한 내용은 아파치 팔콘(Falcon)의 프로젝트 사이트를 참조하시기 바랍니다.

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

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

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

SQL 서버에 있는 데이터를 하둡으로 임포트하는 방법(Import from Microsoft SQL Server into the Hortonworks Sandbox using Sqoop)

This article is based on Hortonworks Partner Content

기업 입장에서 하둡 클러스터를 구축하고 실제로 어떤 데이터를 분석할 것인가를 검토해 보면, 먼저 기존에 다양한 관계형 데이터베이스(Relational Database)에 저장되어 있는 데이터를 빼 놓고는 의미 있는 결과를 얻지 못 할 수도 있습니다.

기존에 관계형 데이터베이스에 저장된 데이터들은 어느 정도 정제되고 관리되는 데이터 소스이기 때문에 하둡 클러스터에 저장된 비정형 데이터들과 함께 검토함으로써 기업에 진정으로 의미 있는 인사이트를 얻어 낼 수 있을 것입니다.

아래는 스쿱(Sqoop)이라고 하는 하둡 에코시스템의 모듈을 가지고 마이크로소프트 SQL Server의 데이터를 하둡 클러스터로 옮기는 방법을 설명드립니다.
소스 코드는 이 곳에서 다운로드 하십시오.

스쿱(Sqoop)은 하둡과 관계형 데이터베이스 사이에서 대량의 데이터를 옮기는 것을 자동화해주는 툴입니다.
스쿱을 가지고 데이터를 옮기기 전에 SQL Server에서 몇 가지 세팅을 해 줄 필요가 있습니다.

SQL 서버에서 로그인 계정을 세팅합니다. (Create a login using SQL Server Authentication)
이 계정을 만들 때는 데이터에 접근하기 위한 충분한 권한(DBA 권한)을 부여하는 것이 필요합니다.

SQL Server에서 보안 세팅을 아래와 같이 진행합니다.
위에서 만든 로그인 계정이 인증될 수 있도록 아래와 같이 SQL Server Authentication을 추가하는 것이 필요합니다.

SQL Server에서 네트워크 프로토콜을 세팅합니다.
스쿱(Sqoop)이 SQL Server와 통신하기 위해서 TCP/IP 프로토콜을 사용하도록 세팅을 할 필요가 있습니다.
만약에, 현재 디폴트 프로토콜이 TCP/IP 이외의 프로토콜이면 이 시점에서 TCP/IP 프로토콜을 이용하도록 세팅하세요.
이 작업은 SQL Server의 “Configuration Manager”에서 세팅할 수 있습니다.

아래와 같이 TCP/IP 프로토콜을 통해서 통신할 수 있는 지 확인해 보시기 바랍니다.

이 예제에서 나온 ‘IP 어드레스’와 ‘TCP 포트 넘버’를 통해서 스쿱(Sqoop)이 SQL Server에 접근하게 됩니다.

호튼웍스 샌드박스를 설치해서 루트로 로그인하고 “SQL Server JDBC Driver”를 세팅합니다.
먼저 /usr/loca 디렉토리로 이동합니다.
‘SQL Server JDBC Driver’를 다운로드하고 압축을 풉니다.

curl -L 'http://download.microsoft.com/download/0/2/A/02AAE597-3865-456C-AE7F-613F99F850A8/sqljdbc_4.0.2206.100_enu.tar.gz' | tar xz

아래와 같이 폴더가 생성되었는 지 확인합니다.

이제 이 드라이버를 스쿱(Sqoop) 라이브러리로 옮깁니다.

cp sqljdbc_4.0/enu/sqljdbc4.jar /usr/lib/sqoop/lib

이제 호튼웍스 샌드박스를 리스타트하면 마무리가 됩니다.

스쿱(sqoop)을 통해서 데이터 이동하기
아래와 같이 스쿱(Sqoop)이 SQL Server에 연결 가능한 지를 체크해 봅니다.

이제 스쿱(Sqoop)의 임포트(Import) 명령을 통해서 아래와 같이 특정 데이터베이스의 특정 테이블을 임포트합니다.

이제 실제로 테이블이 임포트되어 있는 지 확인해 보면 되겠습니다.

이상과 같이 스쿱(Sqoop)이라는 툴을 통해서 데이터베이스의 정보를 대량으로 하둡 클러스터로 이동시킬 수 있습니다.
물론 SQL Server만이 아니라 JDBC를 지원하는 대부분의 데이터베이스를 임포트할 수 있습니다.

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

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

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