5

많은 수의 사용자 트랜잭션을 분석하고 집계 된 측정 값 (예 : 추세 등)을 생성해야하는 시스템을 설계하고 있습니다. 시스템은 빠르고 견고하고 확장 성이 있어야합니다. 시스템은 Java 기반 (Linux)입니다.실시간 분석 처리 시스템 설계

사용자 트랜잭션의 로그 파일 (CSV 기반)을 생성하는 시스템에서 데이터가 도착합니다. 시스템은 매분마다 파일을 생성하고 각 파일에는 다른 사용자의 트랜잭션 (시간순으로 정렬 됨)이 포함되어 있으며 각 파일에는 수천 명의 사용자가있을 수 있습니다.

CSV 파일의 샘플 데이터 구조 :

10 : 30 : 01, 사용자 1, ...
10 : 30 : 01, 사용자 1, ...
10시 30분 2초 사용자 (78), ...
10 : 30 : 02, 사용자 2, ...
10 : 30 : 03, 사용자 1, ...
10 : 30 : 04, 사용자 2, ...
. . .

내가 계획하고있는 시스템은 파일을 처리하고 실시간으로 몇 가지 분석을 수행해야합니다. 입력을 수집하고 여러 알고리즘 및 다른 시스템으로 보내고 계산 된 결과를 데이터베이스에 저장해야합니다. 데이터베이스에는 실제 입력 레코드가 들어 있지 않지만 트랜잭션에 대한 상위 수준의 집계 된 분석 만 포함됩니다. 예를 들어 추세 등

내가 사용하려고하는 첫 번째 알고리즘은 최소 10 개의 사용자 레코드를 필요로하며, 5 분 후에 10 개의 레코드를 찾을 수 없다면 사용할 수있는 데이터를 사용해야합니다.

구현을 위해 Storm을 사용하고 싶지만이 토론을 가능한 한 디자인 수준에 두는 것을 선호합니다.

시스템 구성 요소의 목록 : 입력 파일 분마다 모니터링

  1. 작업입니다.

  2. 파일을 읽고 구문 분석하여 다른 시스템 구성 요소 및 알고리즘에서 사용할 수 있도록하는 작업입니다.

  3. 10 개의 레코드가 수집되거나 5 분이 경과 한 경우 추가 처리를 위해 알고리즘에 데이터를 보낼 시간입니다. 요구 사항은 알고리즘에 대해 최소 10 개의 레코드를 제공하는 것이므로 Storm Field Grouping (동일한 작업이 동일한 사용자에게 호출됨을 의미)을 사용하고 작업 내 10 개의 사용자 레코드 컬렉션을 추적합니다. 물론 이러한 작업 중 몇 가지를 계획하고 각각은 사용자의 일부를 처리합니다.

  4. 단일 트랜잭션에서 작동하는 다른 구성 요소가 있습니다. 다른 트랜잭션과 병행하여 구문 분석 될 때 각 트랜잭션을 수신하는 다른 작업을 생성 할 계획입니다.

# 3으로 귀하의 도움이 필요합니다.

이러한 구성 요소를 설계하는 가장 좋은 방법은 무엇입니까? 사용자 당 10 개의 레코드에 대한 데이터를 유지해야한다는 것은 분명합니다. 키 값지도가 도움이 될 수 있습니다.지도 자체를 작업 자체 또는 분산 캐시를 사용하여 관리하는 것이 더 좋습니까? 예를 들어 키 값 저장소를 Redis (이전에는 사용하지 않았습니다).

도움 주셔서 감사합니다.

답변

5

나는 꽤 자주 작업했습니다. 그래서, 내가 레디 스

의 # 3를 사용하여 당신의 생각에 대해 언급하겠습니다 것은 매 5 분 만료되는 10 작업

  • 에 대한 3 개 요구 사항

    1. 버퍼 사용자 당에게

    2. 버퍼를 가지고

    1. 버퍼 P er User : Redis는 키 값 저장소 일뿐입니다. datatypes의 다양한 종류를 지원하지만 항상 STRING 키에 매핑되는 값입니다. 따라서 사용자 당 버퍼가 필요한 경우 사용자를 고유하게 식별하는 방법을 결정해야합니다. redis에서는 키 값을 무시할 때 오류가 발생하지 않기 때문입니다. 한 가지 해결책은 쓰기 전에 존재를 확인하는 것입니다.

    2. 10 버퍼 용 버퍼 : 분명히 queue을 redis로 구현할 수 있습니다. 그러나 크기를 제한하는 것은 당신에게 맡겨져 있습니다. 예 : LPUSHLTRIM을 사용하거나 길이를 확인하고 프로세스를 실행할지 여부를 결정하는 LLEN 사용. 이 대기열과 관련된 키는 1 부에서 결정한 키 여야합니다.

    3. 5 분 내에 버퍼 만료 : 이것은 가장 힘든 작업입니다. 값이있는 기본 데이터 유형에 관계없이 모든 키는 expiry 일 수 있습니다. 그러나 만료 과정은 조용합니다. 어떤 열쇠가 만료 될 때 통보를받지 못할 것입니다. 따라서이 속성을 사용하면 자동으로 버퍼가 손실됩니다. 이를 해결하기위한 하나의 방법은 색인을 갖는 것입니다. 즉, 인덱스는 타임 스탬프를 해당 타임 스탬프 값에서 모두 만료되어야하는 키에 매핑합니다. 그런 다음 백그라운드에서 매 순간 인덱스를 읽을 수 있고 수동으로 키를 삭제하고 버퍼 데이터로 원하는 프로세스를 호출 할 수 있습니다. 그러한 색인을 얻으려면 Sorted Sets을 볼 수 있습니다. 타임 스탬프가 score하고 열쇠가 될 것입니다 member을 설정합니다 경우 해당 타임 스탬프에 삭제하려면 [사용자 당 고유 키는 대기열에 매핑 1 부 결정]. 큐를 구현하는

    사용 레디 스 목록 : 당신은

    전반적으로 지정된 타임 스탬프와 함께 모든 세트 구성원을 읽을 수 zrangebyscore을 할 수 있습니다.

    사용 LLEN 당신이 당신의 열 제한을 초과하지 않는 확인합니다.

    새 목록을 만들 때마다 [Sorted Set] 색인에 점수가 Current Timestamp + 5 min이고 목록의 키가 Value가되는 항목을 만듭니다.

    LLEN이 10에 도달하면, 다음 읽기 인덱스 [소트 세트]에서 키를 제거하고 DB에서 [키 -> 목록을 삭제] 기억. 그런 다음 데이터로 프로세스를 트리거하십시오.

    1 분마다 현재 타임 스탬프를 생성하고 인덱스를 읽고 모든 키에 대해 데이터를 읽은 다음 db에서 키를 제거하고 프로세스를 트리거하십시오.

    이것이이를 구현하는 방법 일 수 있습니다. [아파치 수로 또는 카프카] 귀하의 요구 사항 # 3

    : [스톰 내부 에스퍼 볼트 요구 사항 1 & 2의 레디 스

  • 0

    으로 데이터를 모델링하는 다른 더 좋은 방법이있을 수 있습니다. Redis에서이 작업을 수행하려면 Esper 논리를 다시 작성해야합니다.]