2
상황을 줄일 수 있습니다. 우리가 달성하고자하는 것은 우리가 관측하고있는 메트릭스의 전부 또는 일부 조합을 기반으로 한 라이브 통계입니다. 고려 된 전략은 대기열에서 데이터를 보내고 데이터의 작업자 프로세스 델타를 가져 와서 원래 데이터의 집합으로서 대기열에 다시 데이터를 보내는 것입니다.분산 컴퓨팅/
관측 : 나에게
,이 하둡과 같은위한 작업처럼 보이지만 우려 (와 방패는) 주로 속도에 대해 제기되었다. 두 가지 모두를 벤치 마크 할 시간이 없었습니다. 대기열 (10 ~ 100 mb/s 주변 어디에서나)을 통해 많은 양의 데이터를 펌프 할 것으로 예상됩니다. 여전히 분산 컴퓨팅 시스템의 경우와 같다고 생각합니다. 또한 대기열 솔루션이 분산 컴퓨팅 솔루션보다 규모가 작아 질 것으로 생각합니다.
질문 :
간단히 말해서, 맞습니까? Hadoop + HDFS에서 조금 읽었습니다. Lustre 나 다른 것과 같은 다른 FS를 사용하여 NodeName SPOF를 회피하고 어떤 종류의 노드가 실패했을 때 어떤 종류의 허용 오차를 가지기 위해 어떤 종류의 솔루션을 사용하려고 생각했습니다. 전체 클러스터.
귀하의 질문은 같습니다 : 기존지도 축소 프레임 워크를 사용하거나 자체 프레임 워크를 사용해야합니까? 그리고 대답은 : 당신의 목표에 달려 있습니다. 만약 당신이 (심지어 관련된 학습을해도) 작동하는 무언가가 필요하다면 기존의 것을 사용하십시오. 새로운 것을 만들고 싶다면 - 자신 만의 것을 씁니다. – kofemann
그래, 나는 하나 또는 하나를 사용하는 것을 꺼려하지 않는다. 데이터를 실시간으로 펌핑하기 위해 매일 수십 GB의 데이터를 실시간으로 분리하는 가장 좋은 방법을 찾고있다. 우리는 현재 메시지 대기 행렬을 보려고합니다. 그러나 Map/Reduce를 사용하는 분산 계산이 아마도 그렇게 할 수있을 것이라고 생각했습니다. –
글쎄, 하둡이 당신을위한 올바른 도구입니다. 물론 HDFS로 데이터를 복사해야합니다 (하루 90GB는 그리 많지 않습니다). – kofemann