2015.08.24

가장 흔해빠진 7가지 하둡 및 스파크 프로젝트

Andrew C. Oliver | InfoWorld
뭔가 색다르고 혁신적인 것을 하는 이에게 필요한 모든 지원과 자금을 제공하면 결국 그 사람은 다른 사람과 똑같은 것을 하게 된다는 격언이 있다.

이 격언은 하둡, 스파크, 스톰에도 적용된다. 모두가 자신은 새로운 빅데이터 기술을 사용해 뭔가 특별한 것을 한다고 생각하지만 사실은 똑같은 패턴의 끊임없는 반복일 수 있다. 구체적인 구현은 다소 다를 수 있지만 다음은 필자의 경험을 바탕으로 간추린 가장 흔한 7가지 프로젝트다.

프로젝트 No. 1: 데이터 통합(Data consolidation)
'엔터프라이즈 데이터 허브(enterprise data hub)' 또는 '데이터 레이크(Data lake)'라고 한다. 이질적인 데이터 소스들이 있고 이 소스 전반에 걸쳐 분석을 수행하는 것이 기본 개념이다.

이런 형태의 프로젝트는 모든 소스로부터 피드를 받아 실시간으로 또는 일괄 처리로 하둡으로 밀어넣는 과정으로 구성된다. 이 과정은 '데이터 주도형 회사(data-driven company)'가 되기 위한 첫 번째 단계인 경우도 있지만 단순히 보기 좋은 보고서가 필요한 경우도 있다.

데이터 레이크는 일반적으로 HDFS 파일과 하이브(Hive) 또는 임팔라(Impala)의 테이블로 구체화된다. 하이브는 느리기 때문에 미래에는 대부분이 H베이스(HBase)와 피닉스(Phoenix)를 통해 구현될 것이다.

영업 사원은 '스키마 온 리드(schema on read)'와 같은 말을 즐겨 하지만 사실 성공적인 결과를 위해서는 사용 사례를 정확히 예측해야 한다. 하이브 스키마는 엔터프라이즈 데이터웨어하우스를 대상으로 한 작업과 크게 다르지 않을 것이다. 스키마-온-리드는 '전혀 계획하지 않음'을 의미하는 것이 아니라, '질문할 수도 있는 모든 질문을 다 계획하진 않는 것'을 의미한다.

데이터 레이크를 사용하는 진짜 이유는 수평 확장성(horizontal scalability), 그리고 테라데이타(Teradata)나 네티자(Netezza)보다 훨씬 더 낮은 비용에 있다. 많은 이가 '분석'을 위해 프론트 엔드에 태블로(Tableau)와 엑셀을 두지만 "진짜 데이터 과학자(파이썬 코딩 실력이 형편없는 수학 전문가)'가 있는 더 앞서가는 회사에서는 제플린(Zeppelin)이나 아이파이썬 노트북(iPython notebook)을 프론트 엔드로 사용한다.

프로젝트 No. 2: 전문적인 분석(Specialized analysis)
사실 많은 데이터 통합 프로젝트가 여기서부터 시작된다. 특수한 요구 사항이 있고 한 가지 종류의 분석을 수행하는 시스템을 위한 하나의 데이터 집합을 구성한다.

예를 들어 은행의 유동성 리스크/몬테 카를로 시뮬레이션과 같이 특정 분야를 대상으로 하는 경향이 강하다. 과거 이런 전문적인 분석은 폐쇄적인 구형 패키지에 의존했는데 이런 패키지는 데이터와 함께 확장이 불가능했고 기능도 제한적인 경우가 많았다. 소프트웨어 개발업체가 어떤 분야에서 활동하는 기관만큼 그 분야에 대해 많이 알지 못한다는 것도 그 이유 가운데 하나다.

하둡과 스파크 세계에서 이런 시스템은 얼핏 데이터 통합 시스템과 비슷해 보이지만 H베이스와 맞춤 제작된 비SQL 코드를 더 많이 사용하는 반면, 데이터 소스는 더 적다. 이 시스템은 스파크를 기반으로 하는 경우가 증가하고 있다.

프로젝트 No. 3: 서비스로서의 하둡(Hadoop as a service)
'전문 분석' 프로젝트, 그리고 역설적으로 한두 개의 데이터 통합 프로젝트가 있는 모든 대기업은 필연적으로 서로 다르게 구성된 하둡 클러스터를 관리하는 고통을 겪게 된다.

그리고는 노드의 절반이 절반의 시간 동안 유휴 상태로 방치되도록 하는 것보다는 "이걸 통합하고 리소스를 풀링해야 한다"는 생각을 하게 된다. 클라우드를 선택하는 방법이 있지만 많은 기업은 명목상 보안(사실상은 내부 정책과 밥그릇 지키기)을 이유로 클라우드를 선택하지 못하거나 선택하지 않는다. 일반적으로 이는 다수의 셰프(Chef) 레시피와 도커 컨테이너 패키지로 이어진다.

필자는 아직 사용해 본 적이 없지만 블루 데이터(Blue Data)는 여기서 완제품 솔루션에 가장 가깝고, 따라서 하둡을 서비스로 구축할 만한 여력이 없는 중소기업에게 매력적이다.

프로젝트 No. 4: 스트리밍 분석(Streaming analytics)
'스트리밍'이라는 용어가 일반적으로 사용되지만 스트리밍 분석은 기기의 스트리밍과는 다르다. 많은 경우 스트리밍 분석은 과거 기업 조직이 수행했던 일괄 처리의 실시간 버전이라고 하는 편이 더 정확하다.

자금세탁 방지와 사기 적발을 예로 들면, 트랜잭션 기반으로 실행해 사이클 전부가 아닌 발생하는 데로 포착하면 된다. 재고 관리를 비롯한 모든 분야가 다 마찬가지다.

데이터를 병렬로 분석 시스템으로 옮기면서 데이터 비트를 하나하나 분석하는 새로운 형태의 트랜잭션 시스템이 사용되는 경우도 있다. 이런 시스템은 H베이스를 일반적인 데이터 저장소로 사용하는 스파크 또는 스톰의 형태를 취한다.

스트리밍 분석이 모든 형식의 분석을 대체하지는 않는다. 앞으로도 역사적 추세를 파악하거나 과거 데이터를 봐야 하는 경우는 여전히 있을 것이다.

프로젝트 No. 5: 복합 이벤트 처리(Complex event processing)
실시간 이벤트 처리는 1초 미만 단위로 생각해야 하는 분야다. 고도의 거래 시스템과 같은 피코초 또는 나노초 단위의 초 저지연 애플리케이션에 사용할 만큼 아직 빠르진 않지만 밀리초 단위의 응답 시간은 가능하다.

예를 들어 통신 사업자를 위한 호출 데이터 레코드의 실시간 레이팅, 또는 사물인터넷 이벤트 처리가 있다. 이런 시스템이 스파크와 H베이스를 사용하는 경우도 가끔 있는데, 보통은 제대로 되지 않아 LMAX 익스체인지(LMAX exchange)가 개발한 디스럽터(Disruptor) 패턴을 기반으로 하는 스톰으로 바꾼다.

과거 이런 시스템은 맞춤 제작된 메시징 소프트웨어 또는 완제품 형태의 고성능 클라이언트-서버 메시징 제품을 기반으로 했지만, 두 가지 모두 현재의 방대한 데이터 볼륨을 감당하기가 어렵다.

거래 규모와 휴대폰 사용자 수는 이들 레거시 시스템이 만들어진 이후 폭발적으로 증가했으며, 의료 및 산업용 센서도 많은 양의 데이터를 쏟아낸다. 필자는 아직 사용해 본 적이 없지만 에이펙스(Apex) 프로젝트는 괜찮아 보이고, 스톰보다 빠른 속도를 내세우고 있다.

프로젝트 No. 6: ETL로 스트리밍(Streaming as ETL)
스트리밍 데이터를 캡처해 이를 어딘가에 저장해야 하는 경우가 있다. 이런 프로젝트는 일반적으로 1번 또는 2번 프로젝트와 동시에 수행되지만 독자적인 범위와 특성이 추가된다.

일부 사람들은 자신이 4번 또는 5번 프로젝트를 하고 있다고 생각하지만 실제로는 디스크에 던져 넣고 나중에 데이터를 분석한다. 이 프로젝트는 거의 항상 카프카(Kafka)와 스톰 프로젝트다. 스파크도 사용되지만 메모리 내 분석은 사실 필요가 없으므로 적합한 선택은 아니다.

프로젝트 No. 7: SAS 대체 혹은 증강
SAS는 좋다. 하지만 데이터 과학자와 분석가가 데이터를 '갖고 놀기'에는 SAS 시스템은 비싸다. 게다가 원하는 것은 SAS로 할 수 있는 것과는 다르거나 더 멋진 그래프를 만드는 것이다.

여기 좋은 데이터 레이크가 있다. 현재는 아이파이썬 노트북(iPython Notebook)이, 향후에는 제플린(Zeppelin)이 바로 그것이다. 이는 결과를 SAS로 피드하고, SAS 결과를 여기에 저장한다.

또 다른 하둡, 스파크 또는 스톰 프로젝트도 봤지만 이런 프로젝트는 '일반적인', '흔한' 형태다. 하둡을 사용한다면 알아볼 수 있을 것이다. 이런 시스템의 사용 사례 가운데 일부는 필자가 몇 년 전에 다른 기술과 함께 작업하면서 구현한 것들이다.

빅데이터의 'big', 하둡의 'do'에 겁을 먹을 필요는 없다. 많은 것이 변한다고 하지만 본질은 변하지 않는다. 과거에 구축했던 것과, 지금 하둡 세계에서 소용돌이치는 최신 유행 기술 사이에는 유사점이 무척 많다. editor@itworld.co.kr


2015.08.24

가장 흔해빠진 7가지 하둡 및 스파크 프로젝트

Andrew C. Oliver | InfoWorld
뭔가 색다르고 혁신적인 것을 하는 이에게 필요한 모든 지원과 자금을 제공하면 결국 그 사람은 다른 사람과 똑같은 것을 하게 된다는 격언이 있다.

이 격언은 하둡, 스파크, 스톰에도 적용된다. 모두가 자신은 새로운 빅데이터 기술을 사용해 뭔가 특별한 것을 한다고 생각하지만 사실은 똑같은 패턴의 끊임없는 반복일 수 있다. 구체적인 구현은 다소 다를 수 있지만 다음은 필자의 경험을 바탕으로 간추린 가장 흔한 7가지 프로젝트다.

프로젝트 No. 1: 데이터 통합(Data consolidation)
'엔터프라이즈 데이터 허브(enterprise data hub)' 또는 '데이터 레이크(Data lake)'라고 한다. 이질적인 데이터 소스들이 있고 이 소스 전반에 걸쳐 분석을 수행하는 것이 기본 개념이다.

이런 형태의 프로젝트는 모든 소스로부터 피드를 받아 실시간으로 또는 일괄 처리로 하둡으로 밀어넣는 과정으로 구성된다. 이 과정은 '데이터 주도형 회사(data-driven company)'가 되기 위한 첫 번째 단계인 경우도 있지만 단순히 보기 좋은 보고서가 필요한 경우도 있다.

데이터 레이크는 일반적으로 HDFS 파일과 하이브(Hive) 또는 임팔라(Impala)의 테이블로 구체화된다. 하이브는 느리기 때문에 미래에는 대부분이 H베이스(HBase)와 피닉스(Phoenix)를 통해 구현될 것이다.

영업 사원은 '스키마 온 리드(schema on read)'와 같은 말을 즐겨 하지만 사실 성공적인 결과를 위해서는 사용 사례를 정확히 예측해야 한다. 하이브 스키마는 엔터프라이즈 데이터웨어하우스를 대상으로 한 작업과 크게 다르지 않을 것이다. 스키마-온-리드는 '전혀 계획하지 않음'을 의미하는 것이 아니라, '질문할 수도 있는 모든 질문을 다 계획하진 않는 것'을 의미한다.

데이터 레이크를 사용하는 진짜 이유는 수평 확장성(horizontal scalability), 그리고 테라데이타(Teradata)나 네티자(Netezza)보다 훨씬 더 낮은 비용에 있다. 많은 이가 '분석'을 위해 프론트 엔드에 태블로(Tableau)와 엑셀을 두지만 "진짜 데이터 과학자(파이썬 코딩 실력이 형편없는 수학 전문가)'가 있는 더 앞서가는 회사에서는 제플린(Zeppelin)이나 아이파이썬 노트북(iPython notebook)을 프론트 엔드로 사용한다.

프로젝트 No. 2: 전문적인 분석(Specialized analysis)
사실 많은 데이터 통합 프로젝트가 여기서부터 시작된다. 특수한 요구 사항이 있고 한 가지 종류의 분석을 수행하는 시스템을 위한 하나의 데이터 집합을 구성한다.

예를 들어 은행의 유동성 리스크/몬테 카를로 시뮬레이션과 같이 특정 분야를 대상으로 하는 경향이 강하다. 과거 이런 전문적인 분석은 폐쇄적인 구형 패키지에 의존했는데 이런 패키지는 데이터와 함께 확장이 불가능했고 기능도 제한적인 경우가 많았다. 소프트웨어 개발업체가 어떤 분야에서 활동하는 기관만큼 그 분야에 대해 많이 알지 못한다는 것도 그 이유 가운데 하나다.

하둡과 스파크 세계에서 이런 시스템은 얼핏 데이터 통합 시스템과 비슷해 보이지만 H베이스와 맞춤 제작된 비SQL 코드를 더 많이 사용하는 반면, 데이터 소스는 더 적다. 이 시스템은 스파크를 기반으로 하는 경우가 증가하고 있다.

프로젝트 No. 3: 서비스로서의 하둡(Hadoop as a service)
'전문 분석' 프로젝트, 그리고 역설적으로 한두 개의 데이터 통합 프로젝트가 있는 모든 대기업은 필연적으로 서로 다르게 구성된 하둡 클러스터를 관리하는 고통을 겪게 된다.

그리고는 노드의 절반이 절반의 시간 동안 유휴 상태로 방치되도록 하는 것보다는 "이걸 통합하고 리소스를 풀링해야 한다"는 생각을 하게 된다. 클라우드를 선택하는 방법이 있지만 많은 기업은 명목상 보안(사실상은 내부 정책과 밥그릇 지키기)을 이유로 클라우드를 선택하지 못하거나 선택하지 않는다. 일반적으로 이는 다수의 셰프(Chef) 레시피와 도커 컨테이너 패키지로 이어진다.

필자는 아직 사용해 본 적이 없지만 블루 데이터(Blue Data)는 여기서 완제품 솔루션에 가장 가깝고, 따라서 하둡을 서비스로 구축할 만한 여력이 없는 중소기업에게 매력적이다.

프로젝트 No. 4: 스트리밍 분석(Streaming analytics)
'스트리밍'이라는 용어가 일반적으로 사용되지만 스트리밍 분석은 기기의 스트리밍과는 다르다. 많은 경우 스트리밍 분석은 과거 기업 조직이 수행했던 일괄 처리의 실시간 버전이라고 하는 편이 더 정확하다.

자금세탁 방지와 사기 적발을 예로 들면, 트랜잭션 기반으로 실행해 사이클 전부가 아닌 발생하는 데로 포착하면 된다. 재고 관리를 비롯한 모든 분야가 다 마찬가지다.

데이터를 병렬로 분석 시스템으로 옮기면서 데이터 비트를 하나하나 분석하는 새로운 형태의 트랜잭션 시스템이 사용되는 경우도 있다. 이런 시스템은 H베이스를 일반적인 데이터 저장소로 사용하는 스파크 또는 스톰의 형태를 취한다.

스트리밍 분석이 모든 형식의 분석을 대체하지는 않는다. 앞으로도 역사적 추세를 파악하거나 과거 데이터를 봐야 하는 경우는 여전히 있을 것이다.

프로젝트 No. 5: 복합 이벤트 처리(Complex event processing)
실시간 이벤트 처리는 1초 미만 단위로 생각해야 하는 분야다. 고도의 거래 시스템과 같은 피코초 또는 나노초 단위의 초 저지연 애플리케이션에 사용할 만큼 아직 빠르진 않지만 밀리초 단위의 응답 시간은 가능하다.

예를 들어 통신 사업자를 위한 호출 데이터 레코드의 실시간 레이팅, 또는 사물인터넷 이벤트 처리가 있다. 이런 시스템이 스파크와 H베이스를 사용하는 경우도 가끔 있는데, 보통은 제대로 되지 않아 LMAX 익스체인지(LMAX exchange)가 개발한 디스럽터(Disruptor) 패턴을 기반으로 하는 스톰으로 바꾼다.

과거 이런 시스템은 맞춤 제작된 메시징 소프트웨어 또는 완제품 형태의 고성능 클라이언트-서버 메시징 제품을 기반으로 했지만, 두 가지 모두 현재의 방대한 데이터 볼륨을 감당하기가 어렵다.

거래 규모와 휴대폰 사용자 수는 이들 레거시 시스템이 만들어진 이후 폭발적으로 증가했으며, 의료 및 산업용 센서도 많은 양의 데이터를 쏟아낸다. 필자는 아직 사용해 본 적이 없지만 에이펙스(Apex) 프로젝트는 괜찮아 보이고, 스톰보다 빠른 속도를 내세우고 있다.

프로젝트 No. 6: ETL로 스트리밍(Streaming as ETL)
스트리밍 데이터를 캡처해 이를 어딘가에 저장해야 하는 경우가 있다. 이런 프로젝트는 일반적으로 1번 또는 2번 프로젝트와 동시에 수행되지만 독자적인 범위와 특성이 추가된다.

일부 사람들은 자신이 4번 또는 5번 프로젝트를 하고 있다고 생각하지만 실제로는 디스크에 던져 넣고 나중에 데이터를 분석한다. 이 프로젝트는 거의 항상 카프카(Kafka)와 스톰 프로젝트다. 스파크도 사용되지만 메모리 내 분석은 사실 필요가 없으므로 적합한 선택은 아니다.

프로젝트 No. 7: SAS 대체 혹은 증강
SAS는 좋다. 하지만 데이터 과학자와 분석가가 데이터를 '갖고 놀기'에는 SAS 시스템은 비싸다. 게다가 원하는 것은 SAS로 할 수 있는 것과는 다르거나 더 멋진 그래프를 만드는 것이다.

여기 좋은 데이터 레이크가 있다. 현재는 아이파이썬 노트북(iPython Notebook)이, 향후에는 제플린(Zeppelin)이 바로 그것이다. 이는 결과를 SAS로 피드하고, SAS 결과를 여기에 저장한다.

또 다른 하둡, 스파크 또는 스톰 프로젝트도 봤지만 이런 프로젝트는 '일반적인', '흔한' 형태다. 하둡을 사용한다면 알아볼 수 있을 것이다. 이런 시스템의 사용 사례 가운데 일부는 필자가 몇 년 전에 다른 기술과 함께 작업하면서 구현한 것들이다.

빅데이터의 'big', 하둡의 'do'에 겁을 먹을 필요는 없다. 많은 것이 변한다고 하지만 본질은 변하지 않는다. 과거에 구축했던 것과, 지금 하둡 세계에서 소용돌이치는 최신 유행 기술 사이에는 유사점이 무척 많다. editor@itworld.co.kr


X