Flink Checkpoint 2단계 제출의 연습 및 최적화를 기반으로 하는 ByteDance 스트리밍 데이터 통합

ByteDance 스트리밍 데이터 통합은 Flink Checkpoint 2단계 제출의 실습 및 최적화 배경을 기반으로 합니다.

배경

ByteDance Development Kit 데이터 통합팀(DTS, Data Transmission Service)은 ByteDance에서 Flink를 기반으로 하는 스트림 배치 통합 데이터 통합 ​​서비스를 구현했습니다. 일반적인 시나리오 중 하나는 Kafka/ByteMQ/RocketMQ -> HDFS/Hive입니다. Kafka/ByteMQ/RocketMQ -> HDFS/Hive(이하 MQ 덤프, ByteDance의 Flink 기반 MQ-Hive 실시간 데이터 통합에 대한 자세한 소개) 데이터 웨어하우스 구축의 첫 번째 계층에서 정확성과 실시간 성적 요구 사항이 상대적으로 높습니다. ​

현재 ByteDance China의 일상적인 MQ 덤프 작업의 수는 엄청나고 일일 평균 트래픽은 PB 수준입니다. 엄청난 양의 작업과 데이터는 MQ 덤프의 안정성과 정확성에 큰 문제를 가져옵니다. ​

이 문서에서는 주로 극단적인 시나리오에서 DTS MQ 덤프가 발생하는 데이터 손실 문제의 문제 해결 및 최적화를 소개하고 마지막으로 온라인 효과를 소개합니다.

온라인 질문

하드웨어 오류로 인해 HDFS 클러스터의 메타데이터 노드가 다운되었습니다. 메타데이터 노드가 종료되고 30분이 지나면 HDFS의 수동 작업 및 유지 관리 작업이 HDFS를 백업 노드로 전환한 후 HDFS가 서비스를 재개합니다. 실패 복구 후 사용자는 MQ 덤프가 실패 중에 데이터를 손실하고 출력 데이터가 MQ의 데이터와 일치하지 않는다고 보고했습니다.

피드백을 받은 후 즉시 문제 해결을 수행합니다. 다음은 Flink Checkpoint 및 MQ 덤프 작성 프로세스를 간략하게 소개한 다음 문제 해결 프로세스 및 솔루션을 소개하고 마지막으로 온라인 효과 및 요약을 소개합니다. ​

플링크 체크포인트 소개​

Flink는 정확히 한 번 또는 적어도 한 번 의미 체계를 제공할 수 있는 Chandy-Lamport 분산 스냅샷 알고리즘을 기반으로 하는 체크포인트 메커니즘을 구현합니다. ​

Flink는 데이터 스트림에 장벽을 삽입하여 데이터를 세그먼트로 분할하여 각 노드가 데이터 스트림 처리를 종료하지 않고 자체 스냅샷을 저장하기 위해 독립적으로 체크포인트를 생성할 수 있도록 합니다. 각 배리어에는 스냅샷 ID가 있으며, 스냅샷 ID 이전의 데이터는 이 스냅샷에 들어가고 그 이후의 데이터는 다음 스냅샷에 들어갈 것입니다. ​

Checkpoint가 Operator 상태의 스냅샷을 만드는 프로세스는 두 단계로 나눌 수 있습니다.

• 스냅샷 상태 단계: 2PC 준비 단계에 해당합니다. Checkpoint Coordinator는 Source Operator에 장벽을 주입합니다. 연산자는 입력 연산자의 모든 동시 막대를 수신하고 현재 상태를 상태에 쓰고 막대를 다음 연산자에게 전달합니다. ​
• 체크포인트 알림 완료 단계: 2PC의 커밋 단계에 해당합니다. Checkpoint Coordinator는 Sink Operator의 모든 Checkpoint의 완료 신호를 받은 후 Operator에게 Notify 신호를 보냅니다. 오퍼레이터는 신호를 수신한 후 해당 함수를 호출하여 알림 작업을 수행합니다. 작업이 실패한 후 ​

MQ 덤프 쓰기 프로세스 정렬​

MQ 덤프는 Flink 체크포인트 메커니즘과 2PC(2단계 커밋) 메커니즘을 사용하여 정확히 한 번 의미 체계를 구현하며 데이터는 반복되거나 손실될 수 없습니다. ​

Flink Checkpoint의 프로세스에 따르면 MQ 덤프의 전체 쓰기 프로세스는 네 가지 프로세스로 나눌 수 있습니다.​

• 데이터 쓰기 단계​
• SnapshotState 단계​
• 체크포인트 완료 단계 알림​
• 체크포인트 복구 단계​

전체 프로세스는 다음 순서도로 나타낼 수 있습니다 . 위 단계의 주요 작업은 아래에 자세히 설명되어 있습니다. Flink 태스크의 현재 Checkpoint id가 n이고 현재 태스크의 태스크 id가 x라고 가정합니다. ​

데이터 쓰기 단계​

쓰기 단계에는 주로 다음 두 가지 작업이 있습니다.​

• 현재 체크포인트의 첫 쓰기(트랜잭션)이라면 우선 /tmp/cp-n/task-x에 쓸 임시 폴더를 정리한다​
• 임시 폴더에 파일 생성 및 데이터 쓰기​

데이터를 쓰기 전에 임시 디렉토리를 정리합니다. 이렇게 하는 이유는 최종 데이터의 정확성을 보장해야 하기 때문입니다.​

체크포인트 n 쓰기 단계(임시 폴더 /tmp/cp-n/task-x에 데이터의 일부 쓰기) 동안 작업 x가 실패했다고 가정하면 작업은 이전 체크포인트 n-1에서 재개되고 다음 쓰기 체크포인트 아이디는 여전히 n입니다. 쓰기 전에 임시 디렉토리를 정리하지 않으면 오류가 발생하기 전에 남은 일부 더티 파일이 유지되고 더티 파일은 체크포인트 단계에서 공식 디렉토리로 이동됩니다. ​

SnapshotState 단계​

SnapshotState 단계는 2PC의 두 단계 중 첫 번째 단계에 해당합니다. 주요 작업은 작성 중인 파일을 닫고 작업 상태(주로 현재 체크포인트 ID 및 작업 ID)를 저장하는 것입니다. ​

체크포인트 완료 단계 알림​

이 단계는 2PC의 두 단계 중 두 번째 단계에 해당합니다. 주요 작업은 다음과 같습니다.​

• 임시 디렉토리 폴더/tmp/cp-n/task-x 나열​
• 임시 디렉토리 폴더 아래에 있는 모든 파일의 이름을 공식 디렉토리로 바꿉니다​
• 임시 디렉토리 폴더 삭제 /tmp/cp-n/task-x​

체크포인트 복구 단계​

체크포인트 복구 단계는 비정상적인 시나리오에서 작업이 가벼운 분산 스냅샷에서 복구되는 단계입니다. 주요 작업은 다음과 같습니다.​

• Flink 상태에서 태스크의 체크포인트 id n 및 태스크의 태스크 id x 복구​
• 작업의 체크포인트 ID와 작업 ID x에 따라 임시 디렉토리 폴더 /tmp/cp-n/task-x를 얻습니다.
• 임시 디렉토리 폴더 아래에 있는 모든 파일의 이름을 공식 디렉토리로 바꿉니다​
• 임시 디렉토리 폴더 삭제 /tmp/cp-n/task-x​

문제 해결 프로세스​

관련 작성 프로세스를 이해한 후 문제 해결로 돌아갑니다. 사용자 작업 구성의 동시성은 8이며, 이는 실행 프로세스 중에 8개의 작업이 동시에 실행됨을 의미합니다. ​

플링크 로그 보기​

문제 해결 과정에서 HDFS 장애 시 Flink Job Manager 및 Task Manager의 로그를 먼저 확인했으며, Checkpoint id가 4608일 때 태스크 2/3/6/7에서 여러 파일을 생성하는 것을 발견했습니다. 태스크 0/1/4/5의 Checkpoint id가 4608인 경우 파일이 삭제되어 데이터 쓰기 또는 파일 닫기에 실패한다 예를 들어 태스크 0의 실패는 /xx/_DUMP_TEMPORARY/cp 파일로 인한 것이다. -4608/task -0/date=20211031/18_xx_0_4608.1635674819911.zstd가 삭제되어 실패했습니다. ​

그런데 공식 디렉토리에 있는 관련 파일 정보를 보면 태스크 2와 태스크 3의 두 태스크에 체크포인트 4608 파일이 없는 것을 알 수 있다. 작업은 Checkpoint가 생성되는 동안 공식 디렉토리의 파일 이름을 기반으로 함). 따라서 초기에 결정된 이유는 일부 파일이 실수로 삭제되어 데이터가 손실되었기 때문입니다. 작업 2/3/6/7은 파일 삭제 후 파일 쓰기 및 닫기 작업이 없기 때문에 정상적으로 실행되지만 작업 0/1/4/5는 파일 삭제 후에도 여전히 파일 쓰기 및 닫기 작업이 있으므로 결과적으로 작업이 실패했습니다. ​

HDFS 메타데이터 보기​

다음 단계는 파일 손실의 원인을 조사하는 것입니다. HDFS 추적 레코드 테이블을 통해 작업 2 체크포인트 4608 임시 디렉토리 작업 레코드를 봅니다(HDFS 추적 레코드 테이블은 분석 및 운영 및 유지 관리 목적을 위해 사용자 및 시스템 호출의 동작을 기록함). 해당 경로는 /xx/_DUMP_TEMPORARY/입니다. cp-4608 /작업-2. ​

HDFS 추적 작업 기록에서 폴더 삭제 작업이 여러 번 수행되었음을 알 수 있습니다. ​

그런 다음 작업 2 체크포인트 4608의 임시 디렉터리에 있는 파일 작업 레코드를 쿼리합니다. 실제로 2021-10-31 18:08:58경에 2개의 파일이 생성된 것을 알 수 있지만, 생성된 2개의 파일은 삭제 작업의 반복 실행으로 인해 삭제된 것을 알 수 있습니다. ​

문제의 초기 원인이 발견되었습니다. 삭제 작업의 반복 실행으로 인한 데이터 손실입니다. ​

근본 원인​

하나는 삭제 작업이 반복되는 이유이고, 다른 하나는 쓰기 과정에서 삭제 작업이 데이터가 쓰기 전이나 데이터가 공식 디렉토리로 이동된 후에 발생한다는 것입니다. 어떻게 데이터 손실이 발생할 수 있습니다. 의심스럽게 우리는 더 분석합니다. ​

Flink Checkpoint의 복구 과정과 Flink 상태의 동작 과정을 무시하고 HDFS와의 상호작용과 관련된 단계만 유지하며, DTS MQ dump 및 HDFS 의 . 전체 쓰기 프로세스는 다음 두 위치를 포함합니다: 하나는 파일을 쓰기 전이고 다른 하나는 임시 파일의 이름을 공식 디렉토리로 바꾼 후입니다. 두 번째 삭제 작업에서는 삭제 작업을 반복하더라도 최종 데이터의 정확도에 영향을 미치지 않습니다. 모든 데이터는 이전 이름 ​​바꾸기 프로세스 중에 임시 폴더에서 공식 디렉토리로 이동되었기 때문입니다. ​

따라서 파일에 쓰기 전에 삭제 작업을 반복적으로 실행하면 최종 데이터가 손실된다는 것을 확신할 수 있습니다. ​

작업 2의 로그에서 HDFS 클라이언트가 18:03:37-18:08:58에서 임시 디렉토리를 삭제하기 위해 HDFS 삭제 인터페이스를 호출하려고 시도했지만 java.net으로 인해 삭제가 실패했음을 발견했습니다. .SocketTimeout 예외. 삭제 작업이 18:08:58 시점에 성공적으로 실행되었습니다. 그리고 이 시점은 기본적으로 HDFS 추적 데이터에서 찾은 삭제 작업의 실행 기록 시간에 해당합니다. 로그를 통해 기본적으로 HDFS 추적 기록에 해당하는 18:08:58 시점에 파일 생성 및 파일 닫기 작업이 완료되었음을 알 수 있습니다. ​

HDFS와 상의한 후 HDFS는 HDFS 삭제 작업이 멱등성을 보장하지 않는다고 말했습니다. 또한 문제의 근본 원인은 실패 시 HDFS NameNode에서 데이터 쓰기 전의 삭제 작업을 여러 번 재시도하고 우리가 쓴 데이터가 삭제되고 최종 데이터가 손실되기 때문이라고 판단했습니다. 파일을 닫기 전에 중복 제거 작업을 수행하면 작성된 파일이 없기 때문에 작업이 실패하고 파일을 닫은 후 중복 제거 명령을 수행하면 데이터가 손실됩니다. ​

솔루션​

MQ 덤프가 비정상적인 시나리오에서 데이터를 잃는 근본적인 이유는 삭제 작업과 쓰기 작업의 순서에 의존하기 때문입니다. 그러나 HDFS NameNode는 비정상적인 시나리오에서 두 작업의 순서를 보장할 수 없습니다. ​

옵션 1: HDFS는 작업의 멱등성을 보장합니다.

이 문제를 해결하기 위해 우리가 먼저 생각한 것은 HDFS가 삭제 동작의 멱등성을 보장하여 삭제 동작이 반복적으로 반복되더라도 후속 쓰기에 영향을 미치지 않아 데이터의 정확성을 보장한다는 것입니다. 그러나 HDFS와 협의한 후 HDFS는 HDFS가 기존 아키텍처에서 삭제의 멱등성을 보장할 수 없다고 밝혔습니다. ​

인과 관계의 정의에 대해서는 DDIA(데이터 집약적 응용 프로그램 설계) 9장을 참조하십시오. 인과 관계는 이벤트에 순서를 부과합니다. 원인은 결과에 선행합니다. 데이터를 쓰기 전에 발생하는 MQ 덤프 프로세스에서 삭제 작업의 원인에 해당합니다. 우리는 이 두 관계의 인과관계를 보장해야 합니다. 인과 문제를 해결하는 방법에 따르면 HDFS가 각 클라이언트 요청에 시퀀스 번호 시퀀스를 가져와 HDFS NameNode에서 단일 클라이언트의 요청 인과성을 보장할 수 있다는 것이 한 가지 해결 방법입니다. HDFS와 논의한 결과, 이 솔루션의 구현 비용이 상대적으로 클 것으로 나타났습니다. ​

옵션 2: 파일 상태 사용​

HDFS가 작업의 멱등성을 보장하기 어렵다는 것을 이해한 후 쓰기 전 삭제 작업을 제거할 수 있는지, 즉 HDFS에 쓰기 전에 폴더를 정리하는 대신 데이터를 직접 파일이므로 인과관계를 보증할 필요가 없습니다. ​

임시 폴더의 어떤 파일이 필요한지 알면 이름 바꾸기 단계에서 필요한 파일의 이름을 공식 디렉토리로 직접 바꿀 수 있고 임시 폴더의 더티 파일을 무시할 수 있으므로 쓰기 전에 파일을 삭제할 필요가 없습니다. . 폴더. 따라서 우리의 솔루션은 작성된 파일 경로를 Flink 상태로 저장하여 커밋 단계와 복구 단계에서 필요한 파일을 공식 디렉토리로 이동할 수 있도록 하는 것입니다. ​

결국 우리는 이 문제를 해결하기 위해 두 번째 솔루션을 선택했으며 파일 상태를 사용하기 전과 후의 처리 흐름을 비교하면 다음 그림과 같습니다.​

현재 파일 상태를 온라인으로 사용하고 있으므로 구현 시 발생하는 관련 문제를 먼저 소개하고 온라인 상태가 된 후의 효과를 설명하겠습니다. ​

파일 상태 구현 세부정보​

파일 이동 멱등성 ​파일 상태를 통해 현재 파일이 있는 임시 디렉터리와 작성할 공식 디렉터리를 확인할 수 있습니다. 다음 프로세스를 통해 이동의 멱등성을 보장합니다. ​

위와 같은 과정을 통해 파일 이동이 실패하더라도 재시도 시 파일 이동의 멱등성을 보장할 수 있다. ​

관찰 가능성​

파일 상태를 구현한 후 메트릭 레코드에 의해 생성된 파일 수와 공식 디렉토리로 성공적으로 이동한 파일 수를 늘려 시스템 관찰 가능성을 개선했습니다. 임시 디렉토리와 공식 디렉토리 모두에 파일이 존재하지 않는 경우, 이동 실패에 대한 메트릭을 추가했으며, 파일 이동이 실패했을 때까지 기다리지 않고 시간에 감지할 수 있는 알람을 추가했습니다. 사용자는 확인하기 전에 데이터 손실을 보고해야 합니다. ​

온라인 상태가 된 후 온라인 메트릭 효과는 다음과 같습니다 .

생성된 파일 수, 성공적으로 이름 변경한 파일 수, 무시된 이름 변경 파일 수, 이름 변경에 실패한 파일 수의 총 4가지 지표가 있으며 의미는 다음과 같습니다.​

• 생성된 파일 수: 상태의 모든 파일 수, 즉 현재 체크포인트 처리 데이터 단계에서 생성된 모든 파일의 수입니다. ​
• 성공적으로 이름이 변경된 파일 수: NotifyCheckpointComplete 단계에서 임시 파일을 공식 디렉토리로 성공적으로 이동한 파일 수입니다.
• 이름이 변경된 파일 수 무시: NotifyCheckpointComplete 단계는 공식 디렉토리로 이동된 파일 수를 무시합니다. 즉, 임시 폴더에는 존재하지 않지만 공식 디렉토리에는 존재하는 파일입니다. 이는 일반적으로 작업에 장애 조치가 있을 때 발생합니다. Failover 후 체크포인트에서 태스크가 복구되고, 실패 전에 성공적으로 이름이 변경된 파일은 현재 단계에서 이름 변경을 무시합니다.
• 이름 변경에 실패한 파일 수: 임시 디렉토리와 공식 디렉토리에 모두 존재하지 않는 파일 수입니다. 이 상황은 일반적으로 작업의 예외로 인한 데이터 손실로 인해 발생합니다. 온라인에서 더 일반적인 경우 중 하나는 일정 기간 동안 작업을 닫은 후 작업이 열리는 것입니다. HDFS TTL 설정은 작업 종료 기간보다 짧기 때문에 임시 디렉터리에 기록된 파일은 HDFS TTL 정책에 의해 지워집니다. 이 결과는 실제로 예상과 일치합니다.

순방향 호환성

기록할 임시 파일은 파일 상태가 온라인 상태가 된 후 데이터를 쓰기 전에 삭제할 필요가 없지만 업그레이드 후 상위 호환성을 보장하기 위해 파일 상태를 두 단계로 시작했습니다.

• 삭제 작업은 첫 번째 단계에서 데이터를 쓰기 전에 예약됩니다.
• 두 번째 단계는 데이터를 쓰기 전에 삭제 작업을 삭제합니다.

첫 번째 단계에서 삭제 작업을 유지하는 이유 파일 상태가 온라인 상태가 된 후 이상이 있는 경우 이전 버전으로 롤백하여 데이터의 정확성을 보장해야 합니다. 삭제 작업을 유지해야만 롤백 후 데이터의 정확성을 보장할 수 있습니다. 그렇지 않으면 이전 Checkpoint 폴더에 더티 파일이 있고 파일 상태 이전 버전으로 롤백하면 파일 상태가 없기 때문에 더티 파일도 공식 디렉토리로 이동하여 최종 데이터의 정확도에 영향을 미칩니다.

온라인 효과

주요 관행 잘라내기

온라인 접속 후 HDFS로 HDFS 클러스터 스위칭 교육을 진행했습니다. 다음 두 가지 시나리오가 리허설되었습니다.

• HDFS 클러스터는 정상적으로 마스터로 전환됩니다.
• HDFS 클러스터의 기본 노드는 10분 이상 실패했으며 테스트 프로세스는 동일한 Kafka 주제를 사용하고 다른 Hive 테이블에 쓰는 두 개의 다른 작업 세트를 만드는 것이었습니다. 그런 다음 두 작업 데이터 집합의 일관성을 확인하기 위해 데이터 확인 작업이 설정됩니다. 한 작업 세트는 HDFS 테스트 클러스터를 사용하고 다른 작업 세트는 일반 클러스터를 사용합니다.

테스트 클러스터는 여러 HDFS 정상 및 비정상 1차 전환을 거치며 검증 작업은 운동 전후의 두 작업 그룹이 작성한 데이터의 일관성을 보여줍니다. 결과는 이 방식이 HDFS 연산의 멱등성이 아닌 손실 수 문제를 효과적으로 해결할 수 있음을 확인합니다.

성능 효과

파일 상태를 사용한 후에는 Notify Checkpoint 완료 단계에서 HDFS 목록 인터페이스를 호출할 필요가 없습니다. 이는 하나의 HDFS 호출을 줄이고 이론적으로 Notify Checkpoint 단계와 HDFS 간의 상호 작용 시간을 줄일 수 있습니다. 아래 그림은 온라인으로 전환하기 전과 후(약 18:26) 알림 단계에서 HDFS와 상호 작용하는 메트릭을 보여줍니다. 접속 전 평균 처리 시간은 약 300ms, 접속 후 평균 처리 시간은 약 150ms로 처리 시간이 절반으로 단축되는 것을 알 수 있습니다.

요약하다

ByteDance 제품 비즈니스의 급속한 발전과 함께 ByteDance의 원스톱 빅 데이터 개발 플랫폼은 점점 더 기능적이 되어 오프라인, 실시간, 증분 및 기타 시나리오에서 글로벌 데이터 통합 ​​솔루션을 제공합니다. 비즈니스 데이터의 양의 증가와 비즈니스의 다각화는 데이터 통합에 큰 도전을 가져왔습니다. 예를 들어, 실시간 데이터 웨어하우스의 거의 실시간 추가 시나리오를 지원하도록 Hive 파티션을 추가하는 전략을 확장하여 데이터 사용 대기 시간을 75% 줄였습니다.

ByteDance 스트리밍 데이터 통합은 아직 개발 중이며 미래는 다음 측면에 중점을 둘 것입니다.

1. 향상된 기능, 간단한 데이터 변환 로직 추가, 스트리밍 데이터 처리 링크 단축, 처리 지연 감소
2. 아키텍처 업그레이드, 오프라인 통합 및 실시간 데이터 통합 ​​아키텍처 통합
3. 자동 스케일링 기능 지원, 비즈니스 피크 및 낮은 피크 동안 자동으로 용량 확장 및 축소, 리소스 활용도 향상 및 리소스 낭비 감소

이 기사에서 소개한 "Flink Checkpoint Two-Phase Commitment에 기반한 ByteDance 스트리밍 데이터 통합의 실습 및 최적화"는 Volcano Engine의 데이터 제품에 대한 빅 데이터 R&D 거버넌스 제품군인 DataLeap을 통해 외부 기업에 수출되었습니다.

빅 데이터 R&D 거버넌스 제품군인 DataLeap 은 원스톱 빅 데이터 미들 오피스 솔루션으로 모든 시나리오 데이터 통합, 전체 링크 데이터 연구 및 개발, 전체 주기 데이터 거버넌스 및 전면 데이터 보안을 실현할 수 있습니다.

참조

• Flink의 MQ-Hive 실시간 데이터 통합 ​​기반 ByteDance
• ByteDance 단일 지점 복구 기능 및 지역 체크포인트 최적화 실습
• 데이터 집약적 애플리케이션 설계
• 상태 저장 스트림 처리

ByteDance 데이터 플랫폼의 동명의 공개 계정에 오신 것을 환영합니다.

{{o.name}}

{{m.name}}