확장 가능한 저장소 + 처리 클러스터 (하둡 무엇입니까?)

Question

목표
웹 응용 프로그램의 파일 저장 및 처리 백 엔드를 구현해야합니다. 응용 프로그램은 다음과 같은 특징이 있습니다

클라이언트는 다양한 형식과 크기의 파일을 (기가 바이트 범위에있을 수 있습니다) 저장합니다 (1 #)
(# 2) 가끔 클라이언트가 파일을 검색해야합니다 자체
(# 3) 때때로 클라이언트는 OD를 생성하기 위해 이전에 저장된 파일에서 처리가 수행되는 출력 데이터 ("OD")를 검색해야합니다. 중요 참고 사항 : OD 크기는 일반적으로 매우 작음 원본 파일 크기의 일부 - 2GB 파일은 1MB OD를 생성 할 수 있음).
(# 4) 경우에 따라 클라이언트가 파일에 변형을 적용합니다 (예 : 파일 패치). I는 # 1, # 2, # 3, # 4에 대한 다음 계산 클러스터를 달성하기 위해 스토리지 클러스터 (예 : SAN)를 사용할 수있는 솔루션
고려

. 그러나 SAN과 컴퓨팅 클러스터간에 수많은 데이터를 전송하려면 (파일을 요청하거나 사용자가 파일을 패치하는 등) 파일 구조가 거대 할 수 있고 클라이언트가 작은 OD 나 아무것도 (패칭 작업은 클라이언트 입력을 소비하지만 클라이언트에 데이터를 반환하지 않습니다).

그래서 지금 생각해 보면 스토리지 노드와 프로세싱 클러스터 사이의 트래픽을 피하기 위해 각 노드가 큰 데이터 노드와 유능한 프로세싱 노드 인 노드 클러스터가 필요하다고 생각합니다. 노드는 저장 한 파일에 대한 처리를 담당하므로 네트워크 대역폭이 사용되지 않습니다. 노드가 처리 요청으로 인해 과부하가 발생하면 해당 노드는 일부 작업을 이웃 노드로 오프로드 할 수 있습니다 (따라서 대역폭 비용은 여전히 ​​발생하지만 필요시에만 발생합니다).

질문
(1) 위키 미디어는 "파일 서버"와 별도의 "이미지 스케일러"서버를 사용합니다 ...하지만 내 경우에는 내가 큰, 불필요한 대역폭에 대한 걱정. 내 걱정은 정당한가? 따라서 내 경우에는 부적절한 스토리지/프로세싱 노드를 분리 하는가?

(2) 내 접근법 (대용량 저장소 + 강력한 처리 노드 클러스터)이 바람직합니까? 아니면 다른 아키텍처를 고려해야합니까?

(2) 나는 하둡을 고려해 보았지만 그것이 작업에 적합한 지 모르겠다. (막대한 대역폭 비용과 나는 빅 데이터를 실제로 처리하지 않는다). 또한 Hadoop이 작업에 적합하다면 이유를 말해주십시오.

(3)이 서버 클러스터를 관리하는 데 사용할 수있는 오픈 소스/다른 프레임 워크가 있습니까?

(4)없는 경우에는 사내 솔루션을 개발해야한다고 생각합니다. 어떻게 시작할 수 있습니까?

휴. 그것은 많은 것이었다. 미리 감사드립니다!

Answer 1

HDFS와 MR을 모두 사용하면 가능합니다. 주의 사항 및하지만 고려 사항 :

1. 당신이 일반적으로 병렬에서 "OD"를 만드는 데 사용하는 알고리즘이 있습니까?그렇지 않은 경우, 데이터 지역성의 이점을 얻지 못할 수 있으며, hadoop은 파일을 처리하는 단일 노드로 파일을 보유하고있는 데이터 노드에서 파일의 데이터를 복사합니다.

2. mapreduce를 사용하면 파일을 제 위치에서 수정할 수 없습니다. 따라서 출력 파일의 이름이 입력 파일로 변경되고 기타 이러한 하우스 키핑이 처리되는 후 처리 단계도 고려해야합니다.

3. 클러스터 관리/배포는 그리 어렵지 않습니다. Cloudera Manager와 Hortonworks Data Platform을 확인하십시오. 이는 배포부터 관리 및 모니터링에 이르기까지 모든 것을 제공해야합니다. 그러나 Cloudera 제품에는 특정 노드 수를 초과하는 라이센스 비용이있을 수 있습니다. HDP에는 AFAIK 같은 제한이 없습니다.