가장 일반적인 7 가지 Hadoop 및 Spark 프로젝트

다음과 같은 오래된 공리가 있습니다. 누군가에게 완전히 지원과 재정적 지원을 제공하여 다른 혁신적인 일을한다면, 그들은 결국 다른 사람들이하는 일을하게 될 것입니다.

따라서 Hadoop, Spark 및 Storm과 함께 사용됩니다. 모두가 이러한 새로운 빅 데이터 기술로 특별한 일을하고 있다고 생각하지만 동일한 패턴을 반복해서 만나는 데 오래 걸리지 않습니다. 구체적인 구현은 다소 다를 수 있지만 내 경험을 바탕으로 가장 일반적인 7 가지 프로젝트가 있습니다.

프로젝트 No. 1 : 데이터 통합

이를 "엔터프라이즈 데이터 허브"또는 "데이터 레이크"라고합니다. 아이디어는 서로 다른 데이터 소스가 있고 이들에 대한 분석을 수행하려는 것입니다. 이 유형의 프로젝트는 모든 소스 (실시간 또는 일괄)에서 피드를 가져 와서 Hadoop에 밀어 넣는 것으로 구성됩니다. 때때로 이것은 "데이터 기반 회사"가되기위한 첫 번째 단계입니다. 때로는 단순히 예쁜 보고서를 원합니다. 데이터 레이크는 일반적으로 Hive 또는 Impala의 HDFS 및 테이블에 파일로 구체화됩니다. HBase와 Phoenix는 앞으로도 Hive가 느리기 때문에이 중 많은 부분이 나타나는 대담하고 새로운 세상이 있습니다.

영업 사원은 "읽기시 스키마"와 같은 말을 좋아하지만 실제로 성공하려면 사용 사례가 무엇인지 잘 알고 있어야합니다. 엔터프라이즈 데이터웨어 하우스). 데이터 레이크의 진정한 이유는 수평 적 확장 성과 Teradata 또는 Netezza보다 훨씬 저렴한 비용 때문입니다. "분석"을 위해 많은 사람들이 프런트 엔드에 Tableau 및 Excel을 설정합니다. "실제 데이터 과학자"(나쁜 Python을 작성하는 수학 괴짜)가있는보다 정교한 회사는 Zeppelin 또는 iPython 노트북을 프런트 엔드로 사용합니다.

프로젝트 No. 2 : 전문 분석

많은 데이터 통합 ​​프로젝트가 실제로 여기서 시작됩니다. 여기서 특별한 필요가 있고 한 종류의 분석을 수행하는 시스템에 대해 하나의 데이터 세트를 가져옵니다. 이는 은행의 유동성 위험 / Monte Carlo 시뮬레이션과 같이 엄청나게 도메인에 특화된 경향이 있습니다. 과거에 이러한 전문 분석은 데이터처럼 확장 할 수없고 제한된 기능 세트로 자주 고통받는 구식의 독점 패키지에 의존했습니다 (부분적으로는 소프트웨어 공급 업체가 기관만큼 도메인에 대해 많이 알 수 없었기 때문입니다. 그것에 몰입).

Hadoop 및 Spark 세계에서 이러한 시스템은 데이터 통합 ​​시스템과 거의 동일하게 보이지만 종종 더 많은 HBase, 사용자 지정 비 SQL 코드 및 더 적은 데이터 소스 (하나만 포함하지 않는 경우)가 있습니다. 점점 더 Spark 기반입니다.

프로젝트 No. 3 : Hadoop as a Service

"전문 분석"프로젝트 (아이러니하게도 1 ~ 2 개의 "데이터 통합"프로젝트)가있는 대규모 조직에서는 서로 다르게 구성된 몇 가지 Hadoop 클러스터를 관리하는 "즐거움"(즉, 고통)을 느끼기 시작할 것입니다. 공급 업체. 다음으로 그들은 노드의 절반을 유휴 상태로 유지하는 대신 "이것을 통합하고 리소스를 풀링해야합니다."라고 말합니다. 그들은 클라우드로 갈 수 있지만, 많은 회사는 보안 (내부 정치 및 직업 보호) 이유로 인해 할 수 없거나 그렇지 않을 수 있습니다. 이것은 일반적으로 많은 Chef 레시피와 이제 Docker 컨테이너 패키지를 의미합니다.

아직 사용하지 않았지만 Blue Data는 여기에서 바로 사용할 수있는 솔루션에 가장 가까운 것으로 보이며 이는 Hadoop을 서비스로 배포 할 수있는 수단이 부족한 소규모 조직에도 어필 할 것입니다.

프로젝트 번호 4 : 스트리밍 분석

많은 사람들이 이것을 "스트리밍"이라고 부르지 만 스트리밍 분석은 장치에서의 스트리밍과는 다소 다릅니다. 종종 스트리밍 분석은 조직이 일괄 적으로 수행 한 작업의보다 실시간 버전입니다. 자금 세탁 방지 또는 사기 감지 : 거래 단위로 수행하고주기가 끝날 때가 아니라 발생하는대로 포착하는 것이 어떻습니까? 재고 관리 또는 다른 모든 것도 마찬가지입니다.

경우에 따라 이것은 데이터를 분석 시스템으로 병렬로 분류 할 때 데이터를 비트별로 분석하는 새로운 유형의 트랜잭션 시스템입니다. 이러한 시스템은 일반적인 데이터 저장소로 HBase를 사용하여 Spark 또는 Storm으로 나타납니다. 스트리밍 분석이 모든 형태의 분석을 대체하는 것은 아닙니다. 여전히 과거 추세를 표면화하거나 고려하지 않은 것에 대한 과거 데이터를보고 싶을 것입니다.

프로젝트 No. 5 : 복잡한 이벤트 처리

여기서는 1 초 미만이 중요한 실시간 이벤트 처리에 대해 이야기하고 있습니다. 하이 엔드 거래 시스템과 같은 매우 짧은 지연 시간 (피코 초 또는 나노초) 애플리케이션에는 여전히 충분히 빠르지는 않지만 밀리 초 응답 시간을 예상 할 수 있습니다. 예를 들어 통신사에 대한 통화 데이터 기록의 실시간 등급 또는 사물 인터넷 이벤트 처리가 있습니다. 때로는 그러한 시스템이 Spark 및 HBase를 사용하는 것을 볼 수 있지만 일반적으로 얼굴에 떨어지고 LMAX 교환에서 개발 한 Disruptor 패턴을 기반으로하는 Storm으로 변환해야합니다.

과거에는 이러한 시스템이 맞춤형 메시징 소프트웨어 (또는 고성능, 기성품, 클라이언트-서버 메시징 제품)를 기반으로했지만 오늘날의 데이터 볼륨은 둘 중 하나에 비해 너무 많습니다. 레거시 시스템이 생성 된 이래로 거래량과 휴대폰 사용자 수가 급증하고 의료 및 산업용 센서가 너무 많은 비트를 펌핑합니다. 아직 사용하지 않았지만 Apex 프로젝트는 유망 해 보이며 Storm보다 빠르다고 주장합니다.

프로젝트 번호 6 : ETL로 스트리밍

때로는 스트리밍 데이터를 캡처하고 어딘가에웨어 하우스를 지정하려고합니다. 이러한 프로젝트는 일반적으로 1 번 또는 2 번과 일치하지만 자체 범위와 특성을 추가합니다. (일부 사람들은 4 번 또는 5 번이라고 생각하지만 실제로 디스크에 버리고 나중에 데이터를 분석합니다.) 이들은 거의 항상 Kafka 및 Storm 프로젝트입니다. Spark도 사용되지만 인 메모리 분석이 실제로 필요하지 않기 때문에 정당화되지 않습니다.

프로젝트 No. 7 : SAS 교체 또는 보강

SAS는 괜찮습니다. SAS는 훌륭합니다. SAS는 또한 비용이 많이 들고 데이터를 "재생"할 수 있도록 모든 데이터 과학자 및 분석가를위한 상자를 구입하지 않습니다. 게다가, 당신은 SAS가 할 수있는 것과 다른 것을하고 싶거나 더 예쁜 그래프를 만들고 싶었습니다. 여기에 멋진 데이터 레이크가 있습니다. 다음은 iPython Notebook (현재) 또는 Zeppelin (나중에)입니다. 결과를 SAS에 입력하고 여기에 SAS의 결과를 저장합니다.

다른 Hadoop, Spark 또는 Storm 프로젝트를 본 적이 있지만 이들은 "일반적인"일상적인 유형입니다. Hadoop을 사용하고 있다면 아마 알아볼 것입니다. 이 시스템의 일부 사용 사례는 다른 기술과 함께 작업하면서 몇 년 전에 구현했습니다.

빅 데이터의“큰”또는 Hadoop의“할 일”을 너무 두려워하는 노년이라면 그렇게하지 마십시오. 더 많은 것이 변할수록 동일하게 유지됩니다. 배포에 사용한 물건과 Hadooposphere 주변에서 소용돌이 치는 힙 스터 기술 사이에는 많은 유사점이 있습니다.