어떻게 효율 적 인 storm 컴 퓨 팅 모델 을 구축 합 니까?

컴퓨터 프로필
        Storm 은 스 트림 컴 퓨 팅 모델 을 사용 하여 셸 과 유사 하 게 데 이 터 를 하나의 '파이프' 에서 처리 합 니 다.

스 팟 은 데이터 소스 에서 데 이 터 를 끌 어 내 는 역할 을 하 며 전체 시스템 의 생산자 에 해당 한다.

Bolt 는 소비 데 이 터 를 책임 지고 tuple 을 다음 계산 장치 에 보 냅 니 다.Bolt 는 여러 개의 spout 과 bolt 의 데 이 터 를 받 아들 일 수 있 습 니 다.

모든 spout, bolt 는 병렬 excuter 를 여러 프로 세 스 에 해당 하 는 설정 을 할 수 있 습 니 다. 모든 excuter 는 여러 task 를 설정 할 수 있 습 니 다.  

shuffle grouping 은 tuple 을 무 작위 로 모든 task 에 보 냅 니 다.fields grouping, 같은 field 값 의 tuple 을 같은 task 에 보 냅 니 다.

데이터 완전 성
        spout 에서 데 이 터 를 보 낼 때 모든 tuple 에 유일한 message id 를 만 듭 니 다.데이터 가 완전 하 게 처 리 될 때 bolt 는 응답 ack (성공) 또는 fail (실패) 이 발생 합 니 다. 데이터 가 (기본 30s) 를 초과 하면 시간 초과 로 간주 하고 버 립 니 다. (fail 을 조작 하 는 방법 으로 데 이 터 를 다시 보 낼 수 있 지만 높 은 계산 원 가 를 가 져 옵 니 다)동시에 spout 발사 tuple 최대 수의 제한 bole 의 처리 속 도 는 spout 의 발사 속도 에 영향 을 줄 수 있다.따라서 데이터 가 빠르게 소비 되 는 것 이 흐름 식 계산 속도 에 영향 을 주 는 관건 이 된다.
 
stom 컴 퓨 팅 모델
        간단 한 storm 컴 퓨 팅 모델 은 기본적으로 세 부분 을 포함한다. 데이터 소스 에서 데 이 터 를 끌 어 내 고 오프라인 과 관련 된 차원 표 는 결 과 를 데이터베이스 에 기록 합 니 다.
우 리 는 쇼핑 몰 상품 분류 목적 의 조회 수 를 통계 해 야 한다 고 가정 하고 이 사이트 의 데 이 터 는 매우 많다.대략적인 절 차 는 다음 과 같다.
    A. FF 는 상품 클릭 데이터 생 성 담당
    B. 관련 상품 유형
    C. 결 과 를 hbase 에 기록 합 니 다.
    상품 id: aucid   사용자 id: userid
 
A. 데이터 추출
         당신 의 임 무 는 매우 빨리 달 렸 고 자원 의 점용 도 적 었 습 니 다. 그런데 데이터 도 왜 이렇게 적 습 니까?좋 지 않 습 니 다. 데이터 가 모두 FF 데이터 원본 에 쌓 였 습 니 다.ok, spout 의 task 수 를 늘 리 고 병행 도 는 1 입 니 다.그런데 왜 데이터 가 이렇게 적은 지 코드 를 보 세 요.

    public  void nextTuple() {     

        while (true) {
            LogData log = null;
            try {
                log = queue.take(); 
            } catch (InterruptedException e1) {
                // TODO Auto-generated catch block
                e1.printStackTrace();
                return;
            }            

            if(log.getType() == null)
                continue;            
            
            collector.emit(streamId, new Values(log.getData(), uid));
        }
    }

        문 제 는 take 가 차단 방법 이 고 storm 의 다 중 스 레 드 는 같은 excuter 에서 제어 하 며 하나의 순환 이 여러 task 사이 에서 전환 하 는 것 과 같다.하나의 task 가 막 혔 을 때 다른 task 도 실행 할 수 없 지만 대부분의 스 레 드 는 데 이 터 를 얻 을 수 있 습 니 다. 전체적으로 단일 스 레 드 만 실행 하 는 것 과 같 습 니 다.해결 방법 은 막 히 지 않 는 poll 방법 으로 대기 열 에서 데 이 터 를 얻 는 것 이다.
        병행 도 를 늘 리 면?많이 바꾸다  excuter 단일 task 이후 단일 task 의 take 도  방법 차단 도 다른 task 에 영향 을 미 치지 않 고 효율 도 다 task 보다 높다.그러나 이에 따라 새로운 문제 가 생 겼 다. task 의 차단 으로 인해 작업 시간 초과 실패 율 이 증가 하고 일부 데이터 가 버 려 졌 으 니 차단 되 지 않 은 poll 방법 으로 순 순 히 바 꾸 자.
        더 빨리 하고 싶 으 면?응답 자체 도 자원 을 소모 하지만 실패 율 을 집계 하지 못 하 는 경우 에는 조심 하 세 요.

   conf.setNumAckers(0);

        요약 하면 데 이 터 를 끌 어 당 겨 병행 도 를 높이 고 task 수 를 1 로 설정 하 며 데 이 터 를 얻 는 데 막힘 이 없 는 방법 을 사용 하여 데이터 양 이 많 으 면 응답 을 없앤다.
B. 관련 상품 유형
        오프라인 상품 표?듣 기 에 매우 큰 모습 이다.이때 우 리 는 캐 시가 필요 하 다. LRUCache 는 좋 은 선택 이다. 그 는 양 방향 링크 의 데이터 구조 로 조회 횟수 가 높 을 수록 앞 에 있 고 조회 횟수 가 낮 으 면 뒤에 있 으 며 심지어 버 릴 것 이다.상품 표 가 너무 커서 hbase 도입 이 느 려 요?시계 나 눠.우리 가 해 야 할 일 은 상품 표를 n 개의 작은 시계 에 넣 고 대량으로 가 져 오 는 것 이다.검색 할 때 캐 시 에 명중 하지 않 으 면 aucid 해시 에서 해당 하 는 상품 표를 조회 합 니 다.
        이때 당신 은 상품 표를 조회 하고 누적 한 후에 결 과 를 hbase 에 저장 하 는 것 이 매우 긴 과정 이라는 것 을 알 게 될 것 입 니 다. 이것 은 당신 의 처리 시간 을 초과 한 후에 데 이 터 를 잃 어 버 릴 수 있 습 니 다.여기 서 우 리 는 BlockingQueue 를 도입 합 니 다. BlockingQueue 가 비어 있 으 면 취 수 작업 은 대기 상태 로 들 어 가 는 것 을 차단 하고 값 이 있어 야 깨 어 납 니 다. 메모리 가 가득 찼 을 때 대기 상태 로 들 어 가 는 것 을 차단 합 니 다. BlockingQueue 에 공간 이 있 을 때 깨 어 납 니 다.우 리 는 userid 해시 에서 n 개의 BlockingQueue (cpu n 을 cpu 수로 최대 이용 하기 위해) 까지 사용자 데 이 터 를 해당 하 는 BlockingQueue 에 삽입 한 후 직접 응답 하면 storm 은 다음 단 계 를 빠르게 처리 할 수 있 습 니 다.또한 이 BlockingQueue 에 대응 하 는 스 레 드 는 소비 데 이 터 를 담당 하고 모든 스 레 드 는 LRUCach 상품 표 캐 시 를 공유 합 니 다.
C. 결 과 를 hbase 에 기록 합 니 다.
        이 때 우 리 는 결 과 를 저장 할 대기 열 이 필요 합 니 다. Concurrent HashMap 은 안전 한 스 레 드 블록 없 는 배열 입 니 다.앞에서 말 한 데 이 터 는 서로 다른 스 레 드 로 분산 되 어 계산 한 것 이다.모든 스 레 드 는 결 과 를 같은 Concurrent HashMap 에 삽입 한 다음 Scheduled Thread PoolExecutor 를 통 해 입력 을 hbase 에 대량으로 가 져 옵 니 다.
       
D. 클릭 수 계산
        여기 서 또 다른 문 제 를 토론 합 니 다. 빅 데 이 터 를 중시 하고 비교적 간단 한 방법 은 user 를 직접 만 드 는 것 입 니 다.id 캐 시, 하지만 이렇게 하면 자원 이 많이 소모 된다.Bloomfilter 를 통 해 아주 작은 정확성 을 잃 을 수 있 는 상황 에서 무 게 를 제거 할 수 있 습 니 다.구체 적 참고http://blog.csdn.net/jiaomeng/article/details/1495500