빅데이터 플랫폼 Pilot 프로젝트 03 feat. Cloudera Data Platform

1. 요구사항

1.1 요구사항 1

• 실시간 데이터

 

1.2 요구사항 2

• 배치 데이터

2. 요구사항 구체화

2.1 원천 데이터 수집/ 적재

• HDFS, Flume

2.2 통합/ 처리된 데이터 적재

• Hbase, MariaDB

2.3 전처리 과저에 사용성 확보, 워크플로우 관리

• Hue, Hive, Spark, Oozie

2.4 보안성, 활용성 확보 (시간상 스킵, 공부가 더 필요한 부분입니다.)

• Kerberos, Sentry, Ranger

 

3. 아키텍처 구현

3.1 Task

• 수집 및 적재된 원천 데이터를 탐색해서 최종 분석 마트 데이터까지 만들어지는 과정을 위한 빅데이터 플랫폼을 구축한다

3.2 Consideration 

• 가용성/최신성/사용성 측면을 고려한 소프트웨어 설계

3.3 Stage : 수집-적재-처리-분석-응용 단계 중에서, 처리 단계 까지라 할 수 있는 Data Mart구성을 위한 소프트 웨어 설계

• External - Managed  - Mart
  •  External
    • 빅데이터 레이크
    • HDFS
    • 비정형의 3V 데이터가 쌓임. 
    • 스키마 의존성이 작은 영역
  •  Managed
    • 데이터 웨어하우스
    • 정형화된 데이터
    • 스키마 의존성이 큰 영역

 

3.4 아키텍처 구성

3.4.1 가용성/ 사용성/ 최신성 고려한 서버 별 설치 구성도

 

3.2 Node별 목적, 역할 분배

host1host[2-5]host[2-5]

Master Hosts	Utility Hosts	Worker Hotsts
NameNode YARN ResourceManager JobHistory Server ZooKeeper : host[1-3]	Secondary NameNode : host2 Cloudera Manager : host5 Hive Metastore : host[2-4] HiveServer2 : host3 Spark History Server host3 Impala Catalog Server : host3 Impala StateStore : host3 Oozie : host3 Hue Server : host[2-4] Hue Load Balancer : host5 Data Analysis Studio host5	NodeManager DataNode Impala demon Spark Gateway Hive Gateway

 

3.3 에코시스템 서버별 설치 및 배치 목적과 이유

• HDFS
  • Fault Tolerance를 위해 Name Node를 host#1에 그리고 Secondary NameNode를 host#2에 분리하여 구성하였습니다.
• Zookeeper
  • Sync, Fault Tolerance를 위해 Zookeeer를 최소 3대이상의 홀수개의 서버에 구성하라는 지침에 따랐습니다. 이유는 다음과 같습니다.

  •  zookeeper를 구성하는 경우 과반수 선출(majority voting/quorums)을 위해 
    zookeeper server의 수를 홀수로 구성할 것을 권고 

    개발/테스트 환경을 위해서 1대로 구성하는 경우가 아니라면,
    보통 3대로 구성하며 더 failure에 대해 견고하게 구성하고자 한다면 5대로 앙상블ensemble을 구성하게 됨.

    Q) zookeeper를 짝수로 구성하면 어떠한 문제가 생기는지?

    A) 결론적으로 짝수로 구성한다고 해서 문제가 생기지는 않음.
    다만 4대로 구성하는 경우는 결함failure 에 대한 수준이 3대로 구성한 것과 다르지 않으며,
    6대로 구성한 경우도 5대로 구성한 경우와 다르지 않음.

    예를들어, zookeeper server 4대로 운영하던 중 leader역할을 수행하던 zookeeper 서버에
    문제(N/W, machine issue, etc..)가 발생하여 3대가 남았다고 가정
    이 경우 남은 follower 역할을 수행하던 zookeeper server 중 랜덤한 zookeeper server 한대가 leader 역할을 수행하게 됨
    이는 전체 앙상블을 이루던 4대 중 과반수인 3대가 정상적으로 서비스 되기 때문.

    만약 추가적으로 1대의 zookeeper server가 문제가 발생해 2대의 zookeeper server만 남는 경우라면 
    과반수(>=3)을 넘지 못함으로 문제가 없는 것으로 판단되었던 다른 2대의 zookeeper server도 서비스를 종료하게 됨.

    3대로 zookeeper 앙상블을 구성한 경우도 동일. 과반수(>=2)를 유지하기 위해서는 1대의 결함만을 허용. 
    4대의 구성과 3대의 구성으로 인한 결함 허용 수준이 1대로 다르지 않기 때문에 홀수로 zookeeper 앙상블을 구성하라고 권고하는 것. 

    결과적으로 결함 허용수준(F) 에 따라서 다음과 같이 앙상블을 구성하는 zookeeper server 수(N)을 결정하면 됨. 

    → N = 2*F+1 (N : 구성 서버 수, F : 결함 허용 수준)

     
• Spark Gateway, Hive Gateway, Impala Demon
  • 가용성과 성능을 위해 Data Node host#[2-5]에 모두 구성하였습니다.

• Hive Metastore
  • Impala, Hive 쿼리 수행시 참고해야하는 중요한 테이블 정보가 담겨있습니다.  따라서 3개의 서버에 구성하였습니다.
  • → HA를 위해선 실제 스토어당 DB가 하나씩 연결이 되어있어야 하기 때문에, 사실상 1개의 서버에 구성한 것과 같은 상황입니다.
  • → 따라서 수정이 필요한 부분입니다.

• Impala
  • 부하분산(Load Balancing) 및 고가용성(HA)에 대한 아키텍처 고려사항은 Impala Daemon에게만 적용되어 설계되었습니다. Impala StateStore 및 Catalog 서비스에 장애가 발생하더라도 데이터 유실과 같은 심각한 장애가 발생하지 않기 때문에 해당 컴포넌트에 대해서는 고가용성이 고려되어 설계되지 않았습니다. 만일 Impala StateStore 및 Catalog 서비스에 장애가 발생한 경우, Cloudera Manager를 활용하여 실행중인 Impala Service를 중지하고, 기존에 배포된 Impala StateStore 및 Impala Catalog Server 역할을 삭제한 뒤, 가용한 다른 노드에 해당 컴포넌트(Impala StateStore / Catalog Server) 역할을 추가하여 빠르게 조치할 수 있습니다.

• Spark Job history server
  • spark application이 완료된 수행 결과를 모니터링 할 수 있는 서버입니다. 데이터 유실 이슈와 관련이 없기 때문에 host#3에 단일 구성하였습니다. 
• Cloudera Manager
  • 클러스터 모니터링 역할을 담당하도록 host#5에 따로 분리를 했습니다.
•  
• Data Analysis Studio
  • 기존 빅데이터 기술이 플랫폼 구축에 집중되었다면, 앞으로 분석 및 응용 자동화에 더욱 집중하는 패러다임의 변화의 시발점이라 생각됩니다. 단, 팀내 사용 여부 및 활용 방안에 대해 정확히 파악이 되지 않은 관계로 우선, host#5에 단일 구성하였습니다.
• YARN Resource Manager
  • 이중화를 위해 host#1, host#2에 이중 구성하였지만, 실제로 활성화 되는 것은 host#1 한개입니다.

• HUE
  • 멀티 유저 사용시 워크로드 자원 관리를 위해 3개의 서버에 구성하였습니다.