[HADOOP] hadoop 클러스터에서 id 생성을 처리하는 방법은 무엇입니까?

hadoop 클러스터에서 id 생성을 처리하는 방법은 무엇입니까?

내가 hadoop 클러스터에 사전을 구축하고 각 토큰에 대한 숫자 ID를 생성해야합니다. 어떻게해야합니까?

해결법

1. ==============================

   1.두 가지 문제가 있습니다. 먼저 각 토큰마다 정확하게 하나의 id를 할당해야합니다. 이를 수행하려면 토큰별로 레코드를 정렬하고 그룹화하고 감속기에 지정해야합니다. 감속기 메서드가 각 토큰마다 정확히 한 번 호출 되었다면 컨텍스트의 파티션 번호와 감속기가 유지하는 고유 숫자 ID (파티션 당 하나의 인스턴스)를 사용할 수 있습니다. 인스턴스 변수를 1로 초기화하면됩니다. 설정 방법에서는 증가하고 감소 방법에서는 증가합니다.

   두 가지 문제가 있습니다. 먼저 각 토큰마다 정확하게 하나의 id를 할당해야합니다. 이를 수행하려면 토큰별로 레코드를 정렬하고 그룹화하고 감속기에 지정해야합니다. 감속기 메서드가 각 토큰마다 정확히 한 번 호출 되었다면 컨텍스트의 파티션 번호와 감속기가 유지하는 고유 숫자 ID (파티션 당 하나의 인스턴스)를 사용할 수 있습니다. 인스턴스 변수를 1로 초기화하면됩니다. 설정 방법에서는 증가하고 감소 방법에서는 증가합니다.

2. ==============================

   2.동기화를 피하기 위해 비즈니스 논리의 일부가 아닌 정렬 및 그룹화를하면 더 빨리 할 수있는 몇 가지 트릭을 사용할 수 있습니다.

   동기화를 피하기 위해 비즈니스 논리의 일부가 아닌 정렬 및 그룹화를하면 더 빨리 할 수있는 몇 가지 트릭을 사용할 수 있습니다.

   가장 간단한 방법은 각 키 UUID UUID.randomUUID ()마다 하나씩 Reducer에서 UUID를 생성하는 것입니다. 그러나 숫자가 아닙니다.

   연속적인 숫자 형 식별자를 원한다면 하나의 감속기가 처리하기에 충분히 작은 출력이 필요하다면 org.apache.hadoop.mapreduce.Job.setNumReduceTasks (int tasks)를 통해 감속기 하나를 강제로 수행하면 모든 키가 하나의 감속기로 보내야합니다.

   Mapper의 출력이 여전히 하나의 Reducer에 비해 너무 크고 ID의 시퀀스 연속성에 관심이 없거나 사전을 파티션 할 수있는 경우 Partitioner ()에서 몇 가지 트릭을 사용할 수 있습니다. 키 길이를 알고있는 N 개의 범위 (예 : 범위 1은 1로 시작하고 범위 4는 3500000으로 시작하는 500 개의 ID를 가질 수 있음)로 논리적으로 키를 분할 할 수 있다는 아이디어입니다. 논리:

   범위에 대한 비즈니스 지식이 없으면 키를 구별하고 범위와 길이를 계산할 시간을 할애 할 수 있습니다. 이 함수를 사용하면 결과 집합에서 ID 시퀀스를 연속적으로 얻을 수 있습니다.

   다른 키를 사용하여 각 감속기의 ID를 시작하는 것이 목표가 아닌 경우 (감속기 1은 1 (1, 10, 124523, 1341243)로만 시작하는 ID를 생성하고, 감속기 2는 2 (2, 23, 234234532) 등). 이렇게하려면 키의 첫 번째 바이트의 mod 10을 계산하고 10 개의 이퀄라이저를 강제로 1과 동일한 파티션에 0을 지정합니다 (그 주된 이유는 0부터 시작하는 2 자리 정수가 없으므로 ID와의 충돌이 발생할 수 있음). 다른 파티션에서), 따라서 파티션 0에 대한 출력은 비어 있습니다. 감속기 측면에서 (2 문자열을 연결 !!!) 0 (키 mod 10의 첫 번째 바이트) 카운터를 추가합니다. 각 감속기는 1에서 무한대까지의 카운터를 가지며 해당 파티션에 사용 된 마지막 ID를 포함하는 파일.

   전의.

   key = "abc", ascii of 'a' is 97, 97 % 10 = 7 and id for that key is '7' + '1' = '71', 
   for "asd" it will be '7' + '244' = '7244', 
   for "bbv" is '8' + '1' = '81', 
   for "bgh" is '8' + '2' = '82', 
   for "ddv", 'd' is ascii 100, 100 % 100 = 0 , convert to 1, '1' + '1' = '11', 
   for "edv" is 101 % 100 = 1, '1' + '2234' = '12234'. 
   

   모든 키는 다른 자릿수로 시작하기 때문에 중복되지 않으므로 여러 개의 이퀄라이저간에 동기화 할 필요가 없습니다. MOD 결과와 카운터의 문자열 연결에 의해 보장되므로 다음 접두사 / 선행 숫자로 오버플로가 발생하지 않습니다. 또 다른 장점은 비즈니스 로직의 일부가 아닌 사전 정렬을 수행 할 필요가 없다는 것입니다. Reducer가 닫히면 id 생성에 사용 된 마지막 카운터를 파일에 기록 할 수 있습니다.이 카운터는 다음 실행에 사용될 수 있으며 사전의 파티션에 ID의 연속성을 제공합니다.

   파티션 수를 10 개에서 100 개로 늘리려면 mod 100을 사용하고 한 자리 결과를 두 자리 숫자로 병합하십시오 (다시 10 개의 감속기 출력을 낭비합니다). 100 % = 10, 100 % 1 = 10, 100 % 1 = 10으로 변환, 102 % 100 = 2는 문자열로 '0'을 추가하거나 10을 곱하여 20으로 변환합니다. 모든 접두어가 동일한 자릿수 ,이 경우에는 2입니다.

   영리한 논리를 사용하면 생략 된 파티션을 낭비하지 않아도됩니다 (mod 100의 경우 0, 1,2, 9).

   경고 :이 논리는 데이터 왜곡에 취약합니다.

   나는 그것이 도움이되기를 바란다. 건배.

3. ==============================

   3.우리가 사용하는 또 다른 옵션은 ID 블록을 작업에 할당하는 것입니다.이 작업을 위해서는 트랜잭션을 관리하는 메커니즘이 필요합니다. 우리는 AWS의 SimpleDB를 사용하여 사용되었거나 사용되지 않은 트랜잭션 및 ID를 추적합니다.

   우리가 사용하는 또 다른 옵션은 ID 블록을 작업에 할당하는 것입니다.이 작업을 위해서는 트랜잭션을 관리하는 메커니즘이 필요합니다. 우리는 AWS의 SimpleDB를 사용하여 사용되었거나 사용되지 않은 트랜잭션 및 ID를 추적합니다.

   작업이 시작되면 Simple DB에있는 ID 블록 전체를 잠급니다 (단 하나의 속성이 '잠김'으로 변경됨). 그런 다음 각 작업은 간단한 db를 호출하여 사용하는 ID 블록을 '체크 아웃'합니다.

   작업이 실패하면 블록을 '잠금 해제'하지 않고 마지막으로 사용한 ID를 업데이트하지 않으므로 이러한 ID는 실패한 작업에 의해 소비되지 않습니다. 마지막에 ID 블록 전체를 잠금 해제하면 실패한 작업으로 인해 확보 된 ID 블록의 잠금이 해제됩니다.

   간단한 DB에서 ID 블록을 가져 오거나 내보내는 방법으로이 프로세스를 개선하여 외부 리소스를 업데이트 할 필요가 없습니다. 대신 데이터와 함께 저장된 파일에서 사용 가능한 ID를 읽고 간단한 DB에 쓰고 간단한 DB를 사용하여 블록을 개별 작업 (매퍼, 축소 기)에 할당 한 다음 성공적인 결과로 다시 작성할 수 있습니다.

   일단 우리가 코드를 공개하면 코드가 공개 될 것입니다. 따라서이 접근법에 관심이있는 사람이라면 언제든지 저와 함께 자유롭게 체크 인하십시오. 끝나면이 게시물을 코드로 업데이트 할 것입니다.

from https://stackoverflow.com/questions/11737750/how-to-handle-id-generation-on-a-hadoop-cluster by cc-by-sa and MIT license