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

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

하둡을 도입할 때 반드시 고려해야 할 점 (5 Things to Consider for Hadoop Integration in the Enterprise)

This article is based on Hortonworks Blog

최근에 빅데이터를 활용해서 기업의 경쟁력을 높히기 위해서 많은 도입 논의가 있습니다.
하지만 아직 하둡의 도입의 관점에서 냉정하게 보면 아직도 초기 단계인 것은 확실합니다.

기술적인 앵글을 넘어서 빅데이터가 기존의 업무 프로세스와 데이터 처리 방식에 어떻게 영향을 줄 것인가의 관점에서 접근하는 논의는 이제 시작 단계라는 생각이 많이 듭니다.

그래서 기업의 도입 논의에서 고려해야 할 사항들을 5가지로 정리한 글을 소개하고자 합니다.

1. 데이터의 크기는 잊어 버려라. (Forget volume or don’t focus on it)
빅데이터라는 정의가 많은 혼란을 주곤 하지만 사실 빅데이터 프로젝트는 반드시 데이터 볼륨의 크기와 연관이 있는 것은 아닙니다.
빅데이터를 논의할 때는 데이터 볼륨의 크기 뿐만 아니라 데이터 소스(Data Source)의 다양성과 데이터 포맷(format)의 다양성과도 관련이 깊습니다.
하둡은 초기부터 관계형 데이터베이스와 데이터를 보는 관점에 차이가 있습니다.
즉, 하둡은 데이터 소스의 포맷을 그대로 유지하고 저장하면서 이것을 ‘처리’하는 단계에서 어떻게 데이터를 바라 볼 것인지를 정하는 방식입니다.
그래서 유연하게 다양한 데이터 소스와 포맷에 대응할 수 있습니다.

“의미 있는 데이터 소스를 식별하라” – 물론 그 크기보다는.
(Make sure you go after the “right” data: identify all the sources that are relevant, and don’t be embarrassed if you don’t need to scale your data computing cluster to hundreds of nodes right away!)

당연하게 들리겠지만 빅데이터 프로젝트를 진행하면 아무래도 데이터 볼륨의 크기나 확장성 등이 논의의 중심을 차지하는 경향이 있습니다.
그것보다는 그 회사의 전략 혹은 프로젝트의 목적에 적절한 데이터란 무엇인가에 대한 논의가 핵심이 되어야 한다는 취지입니다.

2. 데이터를 놓치고 가지 말고 포괄적으로 판단하라.(Don’t leave data behind – be comprehensive.)
실제로 도입 단계에서 우리에게 적절한 데이터를 판단할 때는 이른바 ’1차 데이터’라고 부르는 잘 정리되어 있고 그 데이터의 가치가 잘 알려져 있는 데이터를 위주로 생각하게 됩니다.
예를 들면, 재고 관리 시스템과 같은 비즈니스 어플리케이션에서 나오는 데이터를 예로 들 수 있겠습니다.
하지만 이러한 데이터 위주로 판단을 하게 되면 빅데이터 구축의 가능성을 많이 축소시킬 수 도 있습니다.

사실 기업의 중요한 인사이트는 각종 로그파일, 생산 시스템의 이벤트들, 각종 서버의 상태 정보들, 소셜 네트워크의 상품에 대한 의견들과 같이 기존에 여러 가지 이유로 다루어 지지 않은 데이터 소스들에 있습니다.

프로젝트의 규모를 정할 때 적절한 데이터를 좀 더 포괄적으로 보기 위한 관점이 중요하고 하둡은 합리적인 비용으로 이것을 처리할 수 있게 해 줍니다.

3. 모든 데이터를 모으려는 노력보다는 논리적으로 잘 분산시켜라. (Don’t move everything – distribute data “logically.”)
많은 기업들이 빅데이터 프로젝트를 진행할 때 기존에 데이터웨어 하우징(Dataware-housing) 프로젝트를 진행할 때처럼 모든 데이터를 중앙으로 모으거나 어떤 지점으로 옮기는 데 초점을 맞추고 있습니다.
물론 하둡은 데이터를 중앙화하는 데 적합한 기능을 가지고 있습니다.

하지만 하둡을 중심으로 무리하게 데이터를 옮기려는 노력보다는 적절히 분산시키는 것이 훨씬 효율적이고 성공 가능성이 높습니다.
이른바 “논리적인 데이터웨어하우스”라는 개념이 빅데이터 프로젝트에는 더 어울릴 지도 모릅니다.
(The “Logical Data Warehouse” concept applies well in the “non big data” world. Leverage it for big data.)

4. 스토리지 뿐만 아니라 데이터 처리 플랫폼에 대해서도 충분히 고려하라.(It’s not only about storage – think processing platform)
보통은 하둡이 가진 분산 스토리지에 초점을 두고 데이터를 어떻게 분산시켜서 관리할 지에 대한 논의가 많이 이루어 집니다.
물론 가장 기본적이고 중요한 논의이기는 하지만 이것은 하둡의 파일 시스템(HDFS)에 국한된 논의라고 봐도 되겠습니다.

하둡은 에코시스템을 통해서 데이터를 처리하고 의미 있는 인사이트를 주기 위한 효율적인 방법들을 많이 가지고 있습니다.
특히, 하둡 2.0의 YARN의 도입과 함께 데이터의 속성에 맞게 배치 처리부터 실시간 처리에 이르기까지 다양한 처리 방식을 지원합니다.

물론 R 등과 같은 통계 패키지부터 상용 분석툴에 이르기까지 하둡 기반의 데이터를 분석하기 위한 많은 방법들이 속속 발표되고 있습니다.
데이터 처리 플랫폼에 대한 폭넓은 고려를 해서 의사 결정을 하는 것이 중요합니다.

5. 빅데이터를 독립된 혹은 격리된 프로젝트로 진행하지 마라.
특히 한국에서는 도입 논의 시에 가장 중요한 포인트라고 생각합니다.
빅데이터를 기존의 IT 거버넌스(governance)난 업무 프로세스(Business Process)의 밖에서 독립된 프로젝트로 진행이 된다면 성공 가능성이 크지 않다고 봅니다.

빅데이터는 Poc(Proof of concept)단계부터 기존에 기업이 운영하고 있는 IT 인프라 및 운영 정책의 틀에서 논의되어져야 합니다.
Poc 단계를 단순히 하둡 클러스터의 구축 및 샘플 데이터의 처리 등과 같은 관점에서 진행하면 막상 최종 단계에 적용할 때 많은 부분을 다시 고려해야 하는 문제점이 발생할 가능성이 높습니다.

도입 단계에서 빅데이터 프로젝트를 포괄적인 관점에서 논의하는 것이 중요하다는 점으로 요약할 수 있겠습니다.

5 Things to Consider for Hadoop Integration in the Enterprise 원문 참조.

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

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

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

엔터프라이즈 하둡 및 “Data Lake”(Enterprise Hadoop and the Journey to a Data Lake

This article is based on Hortonworks Partner Content and Expertise

저의 고객과의 상호 작용이 저를 가르쳤다 한 가지가 있다면, 그것은 아파치 하둡은 데이터 센터를 파괴하지 않았지만 데이터는 그랬다는 것입니다. 최근 몇년 동안 새로운 유형의 데이터 폭발은 기술적으로도 경제적으로 데이터 센터에 큰 압력을 가하고 있으며, 엔터프라이즈 하둡은 결과의 현대 데이터 아키텍처의 역할은 점점 중요해 지고 있습니다.

다운로드: 하둡과 현대 데이터 아키텍처.

성공적인 Hadoop 여행은 일반적으로 “data lake”로 이어지는 새로운 분석 응용 프로그램에서 시작됩니다. 점점 더 많은 응용 프로그램은 데이터의 센서 / 기계 , 서버 로그 , 클릭 스트림 , 및 기타 소스 의 새로운 유형에서 가치를 이끌어 낼 수 있도록 합니다. Hadoop이 가지는 데이터 호수 모양으로 크고 광범위한간에 깊은 통찰력을 제공하는 공유 서비스로 실행하는 기존 엔터프라이즈 시스템과 도구와 통합하여 데이터의 호수 여행을 보완 할 수있는 방법으로 데이터가 다양합니다.

08

하둡과 기존 데이터 시스템 : 현대 데이터 아키텍처

그것은 데이터의 저장과 처리를 저렴한 비용으로 확장 접근을 제공하고, 세계에서 가장 큰 웹 속성의 요구에 확장이 증명되고 있기 때문에 기존의 데이터 시스템을 보완은 Hadoop을 사용하는 것은 매우 설득력이있습니다.

01

하둡과 “읽기에 대한 스키마”의 가치

그것도 데이터베이스에 로드 하기 전에 지정된 구조 ( 또는 스키마 ) 로 변환 하는 데이터를 필요로하고 기존의 관계형 데이터베이스 와 달리 Hadoop 은 분석가와 개발자는 다음 의 요구에 맞춘 구조 을 적용 할 수 있으며, 그 원시 형식으로 데이터를 저장 하기에 초점 을 맞추고 그들은 데이터에 액세스 할 때에는 자신의 애플리케이션에 이상적입니다 . Hadoop 의 ” 스키마 보기 설정 “접근은 즉시 어떤 형식으로 데이터를 저장하고 필요할 때 매우 유연하고 적시에 배치 · 구조를 적용 하기 위해 사용자에게 권한을 주는 반면 기존 의 ” 스키마 온 라이트 ‘ 의 접근 방식은 더 많은 전망과 IT 의 개입을 필요로 합니다.

 

예를 들어, 기존의 응용 프로그램은 그것이 고객 상호 작용의 단일 뷰를 얻으려면, 클릭 스트림 데이터 및 CRM 데이터를 결합하여 존재 하고 있다고 가정합니다. 새로운 유형의 데이터를 사용할 수있게되면 , 그것은 데이터를 쉽게 고객의 뷰를 풍부하게하기 위하여 추가 될 수 있습니다 ( 예 : 서버 로그 나 감정 데이터 ) 관련 될 수 있습니다. 키의 구분 은 데이터가 저장되어 있을 때 , 그것은 특정 응용 프로그램 에서 그 구조와 연결을 선언 할 필요가 없습니다.

하둡 여행은 일반적으로 새 분석의 응용 프로그램과 함께 시작 …

Hadoop의 사용량은 일반적으로 이전에 캡처되지 않은 데이터를 연료로하는 새로운 분석 응용 프로그램을 만드는 것부터 시작합니다. 응용 프로그램은 특정 산업이나 조직에만 경향이 있지만, 관련 데이터의 특정 유형의 렌즈를 통해 이러한 응용 프로그램의 많은 유사점이 있습니다.

산업에 걸쳐 분석 애플리케이션의 예는 다음과 같습니다 :

07

… 데이터 호수로 이어질

Hadoop은 다른 데이터 소스를 사용하는 응용 프로그램의 범위와 규모의 지속적인 성장과 엔터프라이즈 Data Lake의 비전을 구체화 하기 시작합니다. 내부 및 외부 데이터 소스를 포함한 여러 사일로 에서 데이터를 결합하여 당신의 조직은 모두 미리 듣고 어떻게 알았으며 복잡한 질문에 대한 답변을 찾을 수 있습니다.
예를들어, 연간 1억대의 고객 상호 작용에 대한 대규모 미국의 홈 센터의 데이터는 다양한 마케팅 캠페인 및 온라인 고객 브라우징 동작과 트랜잭션 데이터를 상호 연관에서 기업을 예방, 고립된 사일로 간에 저장 했다. 무엇이 이 큰 소매 업체가 필요한 것은 ” 골든 기록 “의 POS 거래, 택배 및 웹 사이트 트래픽을 포함한 모든 기간, 모든 채널에 걸쳐 통일된 고객 데이터 입니다 .
황금 레코드를 현실화 하는 것으로, 데이터의 호수는 주문을 받아서 만들어진 쿠폰, 프로모션, 이메일 등 타겟 마케팅 캠페인에 대한 중요한 통찰력을 제공 및 지원함으로써 여러 액세스 방법의 일반적인 데이터 세트 ( 일괄 처리, 실시간 스트리밍 , 메모리 등 ) 를 사용자가 변환하고 여러 가지 방법으로 뷰 데이터 (각종 스키마 사이) 및 폐쇄 루프 분석 을 확장 할 수 있습니다. 어느 때보다 가까운 실시간으로 타임 투 통찰력을 가진 응용 프로그램입니다.

실제 의미에서, Data Lake는 세 가지 주요 특성을 특징으로 합니다 :
1. 모든 데이터가 장기간 삶의 원천 뿐만 아니라 모든 처리된 데이터를 모두 수집합니다 .
2. 여러 사업 부문 전체의 사용자는 세련된 확인 조건에 관한 데이터를 제공 할 수 있습니다.
3. 공유 인프라를 통해 여러 데이터 액세스 패턴을 가능하게 합니다. 메모리 및 기타 처리 엔진, 검색 , 온라인 대화 형 배치 .

데이터가 기하 급수적으로 성장을 계속하고 있으며, 기업이 Hadoop 에 대한 투자는 현대 데이터 아키텍처의 효율성 및 엔터프라이즈 데이터 Lake 기회 모두를 위한 전략을 제공 할 수 있습니다.

최종 결과는 확장성과 낮은 비용을 기반으로 한 통찰력입니다.

Hadoop, the Data Lake, and the Modern Data Architecture의 좀더 자세한 설명을 원한다면 다운로드 하십시오. download our whitepaper.

—————————————————————————————————————————–
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 1012345...10...마지막페이지