hadoop 이란 (20170329)

서버 한 대로 처리할 수 없는 규모의 데이터

• 아마존의 data scientist의 존 라우저가 2012년 아마존 클라우드 컨퍼런스에서 정의한 말
• 가지고 있는 데이터를 제대로 처리하기 위해 분산 화ㄴ경이 필요하느냐에 포커스를 둔 정의

경영 컨설팅 회사들은 20TB를 빅데이터의 기준점이라 말하며, 3V라는 정의(현재는 4V라고도 함)를 내새웁니다.

1. Volume(규모) : 데이터의 크기
2. Velocity(속도) : 데이터가 얼마나 빠르게 생성되는지
3. Variety(다양성) : 데이터가 구조화/비구조화된 데이터를 다 포함하는지 여부
4. Variability(변동성) : Variety와 연관된 것으로 데이터의 형태가 아예 알려져 있지 않은지 아니면 급변하는지 여부

1. 웹 검색 엔진인 아파치 너치(Apache Nutch)의 일부 - 창시자 : 더그 커팅
2. 웹 사이트를 크롤하고 색인하는 소프트웨어와 서버와 데이터의 관리가 필요
3. Nutch는 2002년에 개발 시작하였지만 수십 억 웹 페이지로 확장될 수 없었음.
4. 2003년 GFS(Google File System)라는 구글 분산 파일시스템의 아키텍처가 기술된 논문 공개
5. 2004년 NDFS(Nutch Distributed File System)을 오픈소스로 구현
6. 2004년 구글의 MapReduce를 소개하는 논문 출판
7. 2005년초 너치에 맵리듀스를 구현, 2005년 중반까지 주요 너치 알고리즘이 MapReduce + NDFS 를 사용하기 위해 포팅
8. NDFS + MapReduce는 검색 분야 외의 여러 분야에서 응용
9. 2006년 2월에 NDFS + MapReduce는 하둡이라고 명명된 독립 서브 프로젝트를 구성하기 위해 너치 밖으로 빠져나옴 (이때, NDFS를 HDFS로 이름을 변경)
10. 비슷한 시기에 더그 커팅은 야후에 합류
11. 2008년 2월 웹 규모의 시스템으로 전환하기 위해 전용 팀과 리소스를 제공
12. 이후 하둡은 야후 뿐만 아니라 다양한 회사에서 사용
13. 대기업 벤더인 EMC, IBM, MS, Oracle, Cloudera, Hortonworks, MapR 같은 하둡 전문 기업이 하둡을 배포

• 데이터 수집 : 수집 후 분산 파일 시스템에 저장 (Flume, Chukwa, Kafka)

• 데이터 저장 및 처리 : MapReduce

  • 하둡은 기본적으로 큰 데이터릐 배치 프로세싱에 적합하고, 실시간으로 데이터를 분석하는 용도로 사용하기에는 버겁다는 점

• 처리데이터 액세스 모듈

  • 기존 관계형 데이터베이스 : sqoop( RDB to HDFS or HDFS to RDB )
  • NoSQL : HBase, Cassandra, MongoDB
  • 검색 엔진 : Lucene, Solr, ElasticSearch

• 데이터의 분포 등을 보여주는 시각화 : Matlab, R(R-Hadoop), (Datameer, Pentaho 의 제품)

  • R-Hadoop 이란 RMR(R-MapReduce), RHDFS, RHBase등 하둡 기반 기술들에 R 인터페이스를 접목한 프로젝트

• 작업 워크플로우 관리 정의 모듈 : Cascading, Oozie, Azkaban, Ambrose

Oozie : xml로 잡들을 어떻게 이어서 실행할지 설정 Cascading :자바 API를 통해 설정 Azkaban : 링크드인 내부에서 사용하는 워크플로우 관리 오픈소스 툴 Ambrose : 트위터 내부에서 사용하는 워크플로우 툴을 오픈소스 화

• 오픈소스 : 무료
• 스케일 아웃
  • 단, 스케일 업이 어느정도 적용된 스케일 아웃
  • 너무 낮은 사양을 사용할 경우 공간적 제약이 너무 심함
  • 서버 수를 어느정도 늘린 후에는 서버의 스펙을 올리는 편
• 병렬처리를 가능하게 해주는 단순한 데이터 모델
  • MapReduce 프로그래밍 특징 상 데이터는 다음과 같아야 합니다.
    • 데이터는 레코드의 집합
    • 각 레코드는 Key와 Value를 갖는다.
• 오프라인 배치 프로세싱에 최적화
  • Hadoop은 오프라인 배치를 처리하는데 적합한 framework
  • 현재는 Spark, Storm, Kafka 등으로 오프라인 배치라는 제약이 약해짐.
• 불편 파일만 저장
  • 파일은 HDFS의 업로드 후에는 내용을 변경하지 않는다는 가정
• NameNode
  • 파일 시스템의 namespace를 namenode의 메모리상에서 관리하기 때문에 Hadoop의 저장할 수 있는 파일과 디렉토리의 개수는 namenode의 제약을 받는다.
  • SPOF(Single Point Of Failure)
    • 이는 Secondary NameNode를 구성하면 NameNode의 데이터를 주기적으로 백업함으로써 어느정도 해결 할수 있다.