하둡 Hadoop 01-2 하둡 개요
하둡 프로젝트
밑의 그림은 사용자가 가장 많이 사용하는 툴로 중점적으로 다뤘다.
맵 리듀스를 초보자가 구현하기에는 무리가 있으므로, 하둡 관련 프로젝트를 이용하자.
물리적 아키텍처
물리적 아키텍처는 다양한 컴포넌트를 설치하고 실행할 수 있는 기초가 된다.
밑의 그림은 하둡 및 다양한 물리적 아키텍처의 예제와 물리적 호스트 사이에서 어떻게 분산되는지 보여주다.
주키퍼(Zookeeper) 홀수 개의 쿼럼(quorum)을 필요로 하며, 보통 웬만한 크기의 클러스트에서는
최소 세 개의 쿼럼을 사용하는 것을 권장한다.
CPU, RAM 램, DISK 디스크, Network 네트워크를 이루는 물리적 아키텍처는 모두 클러스트의 쓰루풋과 성능에 영향을 미친다.
일반 하드웨어는 하둡의 하드웨어 요구 조건을 설명할때 종종 사용된다.
일반 하드웨어라는 용어는 듀얼 소켓, 에러를 수정할 수 있는 램을 가능한 한 많이 갖추고 있으며,
RAID 저장소를 위해 최적화된 SATA 드라이브를 갖춘 중급 수준의 서버를 말한다. 하지만 HDFS는 이미 복사 및 에러 검사 기능을 내장하고 있는 만큼 데이터 노드에서는 RAID 레이드 사용을 권장하지 않는다.
대신 네임 노드에서는 추가적인 안정성을 위해 RAID를 사용할 것을 권장한다.
스위치 및 방화벽과 관련한 네트워크 토폴로지 관점에서 보면 모든 마스터 및 슬레이브 노드는 서로 커넥션
(Connection)을 열 수 있어야 한다. 클러스터가 작다면 모든 호스트가 한 개의 고품질 스위치에 연결된 1Gb 네트워크 카드를 실행해도 된다. 더 큰 클러스터에서는 듀얼 중앙 스위치로 최소 1Gb의 다중 업링크를 가진 10Gb 스위치를 사용한다.
클라이언트는 모든 마스터 및 슬레이브 노드와 통신할 수 있어야 하는데, 필요에 따라 이 접근은 클라이언트 측에서만 연결을 맺을 수 있게 제한하는 방화벽 내에서 이뤄질 수 있다.
하둡을 사용하는 기업
구글 Google
자사의 맵 리듀스 논문에서 자체적인 맵 리듀스 버전을 사용해 크롤 데이터로부터 웹 인덱스를 생성했음을 밝힘. 또 구글은 맵 리듀스를 활요할 수 있는 분산 grep, URL 접근 빈도(로그 데이터) 호스트의 인기 키워드를 판단하는 용어 벡터(term vector) 알고리즘 같은 응용 사례도 강조
페이스북 Facebook
데이터 웨어하우징, 실시간 애플리케이션 지원을 위해 Hadoop, Hive, HBase를 사용
페이스북의 데이터 웨어하우징 클러스터는 크기가 페타바이트이며, 노드는 수천 개
메시지 및 실시간 데이터 분석을 위해 별도의 HBase 주도 실시간 클러스터를 사용
트위터 Twitter
데이터 분석, 시각화, 소셜 그래프 분석, 기계 학습(Machine Learning)을 위해 Hadoop, Pig, HBase를 사용
모든 데이터를 LZO로 압축하고 직렬화에 프로토콜 버퍼를 사용한다. 이 기술은 모두 저장소와 컴퓨팅 자원 사용을 최적화하기 위한 것이다.
야후! Yahoo!
데이터 분석, 기계 학습, 검색 순위, 이메일 스팸 방지, 최적화, ETL(추출, 변형, 로드) 등에 하둡을 사용한다.
총 170PB의 저장소를 갖춘 4만개 이상의 하둡 구동 서버를 갖춤.
* ETL
추출, 변형, 로드 ETL은 외부 소스로부터 데이터를 추출한 후 이를 프로젝트 요구 조건에 맞게 변형한 후,
타깃 데이터 싱크로 로드하는 과정을 말한다. ETL은 데이터 웨어 하우징에서는 흔한 처리 절차이다.
이베이, 삼성, 마이크로소프트
자사의 플랫폼이나 하둡에 막대한 투자를 하는 업체
하둡의 제약
흔히 HDFS와 맵 리듀스의 약점으로 가용성과 보안을 꼽는다.
이들 기술의 마스터 프로세느느 모두 단일 장애 지점(single points of failure)에 해당한다.
보안은 하둡의 또 다른 아킬레스건이다.
고가용성
하둡 2.x가 출시도기ㅣ 전 까지 HDFS와 맵 리듀스는 단일 마스터 모델을 사용했다.
이 때문에 결과적으로 단일 장애 지점이 생기게 됐다.
하둡 2.x 버전에서는 네임노드와 잡트래커 고가용성(HA) 지원 기능을 모두 제공한다.
2.x 네임 노드 HA 설계에는 네임노드 메타데이터를 위한 공유 저장소가 필요한데, 이를 위해서는 값비싼 HA 저장소가 필요할 수 있다.
보안
하둡에서는 보안 모델을 제공하지만, 기본적으로 비활성화돼 있다.
보안 모델이 비활성화된 상태에서 하둡에 존재하는 유일한 보안 기능은 HDFS 파일과 디렉터리 레벨의 소유권 및 권한 뿐이다. 기본적으로 다른 모든 서비스는 완전히 열려 있으며, 아무 사용자나 아무잡은 마음대로 할 수 있다.
하둡은 네트워크 인증 프로토콜인 커베로스(Kerberos)와 연동하도록 설정할 수 있다.
이를 위해서는 클라이언트(사용자 및 다른 하둡 컴포넌트)를 인증할 하둡 데몬이 필요하다.
하둡에는 저장소 또는 통신 레벨에서의 암호화가 전혀 없다.
HDFS
고가용성 부족과 관련이 있으며, 작은 파일을 효율적으로 처리하지 못한다는 점과 투명한 압축 방식의 부재를 꼽는다. HDFS는 한결같은 쓰루풋을 위한 최적화로 인해 크기가 작은 파일에 대한 랜덤 읽기에 비효율적이게끔 설계되었다.
맵 리듀스
맵 리듀스는 배치 기반의 아키텍처다. 이 말은 맵리듀스가 실시간 데이터를 접근 해야 하는 사용 사례(use case)에는 적합하지 않다는 뜻. 전역 동기화나 수정 가능 데이터의 공유 같은 작업은 맵 리듀스에서는 부적합하다. 이는 맵 리듀스의 무공유 아키텍처 때문이며, 일부 알고리즘에서는 이 방식을 사용할 경우 문제가 생김.
하둡 생태계의 버전 호환성
하둡 실행과 관련한 버존 의존성 문제도 있다.
HDFS의 동기화 요구 조건 때문이다. (동기화란 스트림에 대한 모든 쓰기가 모든 복제본의 디스크에 쓰이게끔 하는 매커니즘 )
'하둡' 카테고리의 다른 글
하둡 설치하기-2 CentOS7 기본 설정 및 JAVA 설치 (1) | 2016.05.06 |
---|---|
하둡 설치하기-1 VirtualBOX와 CentOS7 설치 (1) | 2016.05.04 |
하둡 Hadoop 02-1 Data logistics (0) | 2016.04.19 |
하둡 Flume (0) | 2016.04.19 |
하둡 Hadoop 01-1 하둡 개요 (0) | 2016.01.28 |