빅 데이터 Druid 의 몇 가지 데이터 입력 방식 에 대한 연구

Kafka, RabbitMQ, Storm 에서 실시 간 데이터 흐름 을 섭취 할 때 부터 Druid 로 이동 할 때 는 리 얼 타임 노드, Index Server, Tranquility 를 사용 해 데이터 섭 취 를 할 수 있다.본 고 는 주로 이 몇 가지 데이터 섭취 방식 의 차 이 를 탐색 한다.
Realtime Node
Realtime Node 는 Firehose 가 Kafka, RabbitMQ 등 메시지 큐 에서 데 이 터 를 가 져 오 는 것 을 직접 설정 할 수 있 으 며, 데 이 터 를 섭취 하면 곧 조회 할 수 있 으 며, Realtime Node 는 섭취 한 데 이 터 를 주기 적 으로 Segment 로 합 쳐 DeepStorage 에 제출 하고 Historical Node 에 불 러 와 실시 간 데 이 터 를 조회 하 는 기능 을 수행 하기 도 한다.
Realtime Node 의 한계 성
그러나 이런 모델 은 약간의 결함 이 있다.
카 프 카 섭취 결함
Realtime Node 가 다운 되면 이 노드 에 제출 되 지 않 은 데 이 터 를 모두 잃 어 버 립 니 다.
정상 적 인 이 럴 때 우 리 는 replica 사본 을 만들어 서 높 은 사용 을 확보 해 야 하지만 Kafka 를 사용 하여 데 이 터 를 섭취 하 는 장면 에 약간의 결함 이 있 을 수 있 습 니 다. 여기 서 Segment 와 관련 된 것 입 니 다. 공유 메커니즘 。
쉽게 말 하면 대량의 데 이 터 를 섭취 하 는 장면 에서 보통 하나의 Segment 는 여러 개의 Shard 분 편 으로 나 뉘 는데 각 분 편 마다 다르다 partitionNum. 지역 번호.던 전이 설정 되 어 있 을 때, 어떤 분 편의 던 전 은 이 분 편의 동일 한 분 구 번 호 를 가지 게 됩 니 다.데 이 터 를 조회 할 때 Druid 는 같은 지역 번호 의 블록 버스터 에서 데이터 조회 데 이 터 를 무 작위 로 선택 할 것 을 알 수 있 습 니 다.
그리고 구체 적 인 장면 을 들 어 보면 만약 에 Kafka 의 Topic 에 번호 가 1, 2, 3 인 partitions 가 있 고 2 개의 실시 간 노드 가 이 Topic 를 소비 하면 노드 1 은 partitions 1 과 2 를 소비 하고 노드 2 는 partitions 3 를 소비 합 니 다.그들 은 같은 그룹 을 가지 고 있다.
이 럴 때 는 Replication 을 통 해 높 은 가용성 을 확보 해 야 하기 때문에 다른 2 개의 실시 간 노드 를 시작 하고 새로운 Kafka Topic 으로 데 이 터 를 소비 합 니 다.이때 노드 3 을 보면 partitons 1 을 소 비 했 을 수도 있 고 노드 4 는 partitions 2 와 3 을 소 비 했 을 수도 있다.
앞에서 언급 한 Segment partition Num 조회 의 특성 은 이 럴 때 Druid 는 노드 3 과 4 가 같은 구역 이 라 고 생각 하기 때문에 데이터 조 회 는 그 중에서 한 노드 만 선택 하여 조회 하지만 그들의 데 이 터 는 다르다 는 것 이 분명 하 다.
데이터 손실 위험
또한, 현재 작업 을 수행 하고 있다 고 가정 하여 오늘 매 시간의 데 이 터 를 모 으 는 동시에 오프라인 클 러 스 터 에서 데 이 터 를 가 져 와 Segment 를 다시 만 들 고 현재 Segment 를 덮어 씁 니 다.
계산 작업 을 수행 하 는 동안 Segment 덮어 쓰기 가 발생 하면 이 장면 에서 데이터 손실 이 발생 할 수 있 습 니 다.
Schema 업 데 이 트 는 노드 를 다시 시작 해 야 합 니 다.
Schema 가 업 데 이 트 될 때 새로운 설정 을 적용 하기 위해 Realtime Node 를 다시 시작 해 야 합 니 다. 이 는 대규모 클 러 스 터 관리 에서 효율 이 매우 낮 습 니 다.
Indexing Service
다음은 Druid 공식 Indexing Service 구성 도 입 니 다.
Indexing Service 는 다음 과 같은 몇 가지 부분 으로 나 뉜 다.
Overload: 요청 접수 담당, Middle Manager 에 게 퀘 스 트 할당 Middle Manager: 제출 한 작업 을 수행 하 는 작업 자 노드 는 단독 JVM 을 실행 하 는 Peon 에 게 작업 을 나 누 어 줍 니 다.
Peon: Task 의 용 기 를 지정 합 니 다 Task: Middle Manager 가 관리 하 는 Peon 에서 수행 하 는 임 무 는 Hadoop 섭취, Kafka 섭취 등 다양한 임 무 를 지원 합 니 다.동시에 개발 자 는 업무 수 요 를 만족 시 키 기 위해 스스로 작업 을 맞 출 수 있다 ZooKeeper: 유지 보수 작업 정보 간단하게 말하자면 Indexing Service 는 분포 식 임무 스케줄 링 시스템 으로 계획 에 따라 데이터 섭취, Segment 합병, 압축, 삭제 등 임 무 를 수행한다.사용자 정의 작업 확장 도 지원 합 니 다.
심지어 확장 을 통 해 Indexing Service 를 Autoscaling 자동 신축 서비스 에 연결 할 수 있 습 니 다. 작업 줄 이 너무 길 때 Middle Manager 노드 를 자동 으로 만 들 고 노드 가 비어 있 을 때 자동 으로 축소 할 수 있 습 니 다.
자물쇠 메커니즘
Task 의 잠 금 메커니즘 위 에서 설명 한 Realtime Node Segment 를 덮어 쓸 때 발생 할 수 있 는 데이터 손실 위험 을 피하 기 위해 publish segment 등 을 진행 할 때 지정 한 시간 대의 segment 의 배타 적 잠 금 이나 공유 잠 금 을 가 져 올 수 있 습 니 다.
Kafka Indexing Service
Kafka Indexing Service Indexing Service 에 포 장 된 확장 입 니 다. Kafka 자체 의 파 티 션 과 오프셋 체 제 를 사용 하여 데 이 터 를 읽 기 때문에 정확 한 서비스 보증 을 제공 할 수 있 습 니 다.리 얼 타임 노드 의 카 프 카 데이터 섭취 결함 해결.
Tranquility 와 비교 하면 그 는 Kafka 에서 온 최근 이 아 닌 데 이 터 를 읽 을 수 있 고 창구 기 (window period) 가 다른 섭취 체제 에 미 치 는 영향 을 받 지 않 는 다 는 것 이 장점 이다.색인 작업 을 관리 하 는 상 태 를 지원 합 니 다. 전환 을 조율 하고 고장 을 관리 하 며 확장 성과 복사 요 구 를 확보 합 니 다.
현재 Druid 0.11.0 Kafka Indexing server 가 완전히 출시 되 지 않 았 으 므 로 생산 에 신중 해 야 합 니 다.
Tranquility
Tranquility 는 Index Service 에 포 장 된 라 이브 러 리 로 Kafka, Hadoop, HTTP, Storm, Samza, Spark Streaming 또는 자신의 JVM 프로그램 에서 Indexing Service 에 데 이 터 를 보 낼 수 있 도록 도와 줍 니 다.
Tranquility 실현 원리
Tranquility 는 Indexing Service 가 Partitioning 구역, Replication 사본, Service Discover 서비스 에서 Schema rollover Schema 가 부 드 럽 게 변경 하 는 어 려 운 문 제 를 해결 하 는 데 도움 을 주 었 습 니 다.
Tranquility 는 Indexing Service 의 EventReceiver Firehose 를 기반 으로 이 루어 집 니 다. 이 Firehose 는 Tranquility 실시 간 Push 데 이 터 를 Indexing Service 에 제공 하 는 HTTP API 를 노출 합 니 다.
파 티 션 과 사본 문 제 를 해결 하 는 데 있어 서 Tranquility 는 모든 Segment + parition Num 에 Task 를 할당 하여 데이터 섭 취 를 진행 합 니 다. Window Period 를 초과 하면 Task 는 데 이 터 를 받 지 않 고 Segment 를 합 친 다음 Deep Storage 에 제출 합 니 다.
한편, 던 전의 실현 에 있어 Tranquility 는 모든 던 전 을 서로 다른 Task 를 만 들 고 같은 Segment 와 paritionNum, 같은 Segment 와 paritionNum 의 데 이 터 는 동료 에 게 같은 던 전의 Task 를 보 내 며 던 전의 Task 는 통신 이 되 지 않 습 니 다.
Schema 가 바 뀌 었 을 때 Indexing Service 에서 작업 을 다시 시작 해 야 유효 합 니 다.그리고 Tranquility 의 방법 은 새로운 시간 대 에 만 생 성 되 는 Segment 이 고 낡은 Segment 강 의 는 변 하지 않 습 니 다.이 시간 에 멈 추 지 않 고 Schema 를 수정 합 니 다.
마지막 으로 저 희 는 인 스 턴 스 를 시작 하여 데이터 처 리 를 하고 Druid 에 보 내야 합 니 다. Tranquility 는 Zookeeper 를 사용 하여 서로 다른 인 스 턴 스 의 작업 을 조율 하여 데이터 가 해당 하 는 Task 에 정확하게 떠 오 르 도록 합 니 다.
Tranquility 의 결함
Window Period 를 초과 한 데 이 터 는 버 려 집 니 다. 오프라인 클 러 스 터 에서 정기 적 으로 Segment 를 다시 만들어 데이터 상호 보완 을 실현 해 야 합 니 다.
Tranquility 와 Indexing Service 의 통신 이상 은 재 시도 로 이 어 질 수 있 습 니 다. 재 시도 가 성공 하거나 실패 하 더 라 도 데이터 손실 이나 중복 데이터 를 초래 할 수 있 습 니 다.