저자 | 꿈처럼 떠다니는 돌

가이드

실시간 컴퓨팅 기술이 빅 데이터에 광범위하게 적용됨에 따라 데이터의 적시성이 크게 향상되었지만 실제 적용 시나리오에서는 적시성 외에도 더 높은 기술 요구 사항에 직면해 있습니다.

이 논문은 수위 기술의 개념과 관련 이론 실습, 특히 실제 수위의 특성, 경계 정의 및 적용에 중점을 두고 플로우 배치 통합 데이터 웨어하우스에서 실시간 컴퓨팅 수위 기술의 탐색 및 실습을 결합합니다. -타임 컴퓨팅 시스템, 그리고 마지막으로 설명에 초점을 맞춘 개선된 설계와 정확한 수위 구현이 제시됩니다. 기술 아키텍처는 현재 Baidu의 실제 비즈니스 시나리오에서 성숙하고 안정적이며 모든 사람에게 참조 가치가 되기를 바라며 공유하고 싶습니다.

원문은 7118단어, 예상 열람시간은 18분이다.

01 사업 배경

제품 개발, 전략 반복, 데이터 분석 및 운영 의사 결정의 효율성을 개선하기 위해 기업은 데이터의 적시성에 대한 요구 사항이 점점 더 높아지고 있습니다.

우리는 실시간 컴퓨팅을 기반으로 한 실시간 데이터 웨어하우스의 구축을 아주 초기에 실현했지만 여전히 오프라인 데이터 웨어하우스를 대체할 수 없습니다.실시간 및 오프라인 데이터 웨어하우스 세트의 개발 및 유지 비용이 높으며, 그리고 가장 중요한 것은 사업의 자질이 100%가 될 수 없다는 것입니다. 따라서 전체 데이터 처리 효율성을 높일 수 있을 뿐만 아니라 데이터가 오프라인 데이터만큼 신뢰할 수 있고 100% 비즈니스 시나리오를 지원할 수 있는 스트림 배치 통합 데이터 웨어하우스를 구축하기 위해 노력했습니다. 전반적인 비용 절감 및 효율성 향상을 달성하기 위해.

△스트림-배치 통합 데이터 웨어하우스 구축 아이디어

02 Stream-Batch 통합 데이터 웨어하우스의 기술적 어려움

엔드투엔드 통합 스트리밍 및 배치 데이터 웨어하우스를 기반 기술 아키텍처의 실시간 컴퓨팅 시스템으로 실현하기 위해서는 다음과 같은 많은 기술적 어려움과 과제에 직면해 있습니다.

1. 종단 간 데이터는 데이터의 무결성을 보장하기 위해 엄격히 반복되거나 손실되지 않습니다.

2. 데이터를 포함한 실시간 데이터 창과 오프라인 데이터 창 정렬(99.9% ~ 99.99%) ;

3. 실시간 계산은 실시간 부정 행위 방지 전략의 정확한 효과를 보장하기 위해 정확한 창 계산을 지원해야 합니다.

4. 실시간 컴퓨팅 시스템은 Baidu의 내부 빅 데이터 생태와 통합되어 대규모 온라인 안정적인 운영이 실제로 실행됩니다.

위의 2 및 3 지점은 모두 진행 상황 인식 및 실시간 데이터의 정확한 세분화를 보장하기 위해 매우 안정적인 수위 메커니즘이 필요합니다.

따라서 이 기사에서는 스트림 배치 통합 데이터 웨어하우스에서 정확한 수위에 대한 탐색 및 실제 경험을 공유합니다.

03 수위 개념 및 일반 시행 현황

3.1 수위의 필요성

워터마크 개념을 도입하기 전에 두 가지 개념을 삽입해야 합니다.

이벤트 시간, 이벤트가 발생한 시간입니다. 우리는 일반적으로 사용자의 실제 행동이 발생한 시간으로 이해하며 특히 로그에서 사용자의 행동이 발생한 타임스탬프에 해당합니다.
처리 시간, 데이터 처리 시간. 우리는 일반적으로 시스템이 데이터를 처리하는 시간으로 이해합니다.

워터마크의 구체적인 용도는 무엇입니까?

실제 실시간 데이터 처리 프로세스에서 데이터는 무한(Unbounded)하므로 Window 또는 기타 유사한 시나리오를 기반으로 하는 창 컴퓨팅은 실용적인 문제에 직면합니다.

특정 창의 데이터가 완전하다는 것을 어떻게 알 수 있습니까? window compute()는 언제 트리거될 수 있습니까?

대부분의 경우 이벤트 시간을 사용하여 기간 계산(또는 데이터 파티션 분할 및 오프라인 정렬)을 트리거합니다. 그러나 실제 상황은 실시간 로그는 항상 지연 정도(로그 수집, 로그 전송 및 로그 처리 단계)가 다릅니다. 즉, 아래 그림과 같이 워터마크의 왜곡은 실제로 발생합니다(즉, 데이터가 잘못된 순서로 표시됨). 이 경우 데이터의 무결성을 보장하기 위해 워터마크 메커니즘이 필요합니다.

△수위 기울기 현상

3.2 수위의 정의 및 특성

워터마크(watermark)의 정의는 현재 업계에서 획일적이지 않은데 책 ** Streaming Systems **(저자는 Google Dataflow R&D 팀임)의 정의와 결합하면 개인적으로 더 정확하다고 생각합니다.

워터마크는 아직 완료되지 않은 가장 오래된 작업의 단조롭게 증가하는 타임스탬프입니다.

정의에서 수위의 두 가지 기본 특성을 요약할 수 있습니다.

수위가 지속적으로 상승(반환불가)
수위는 타임 스탬프입니다.

그러나 실제 생산 시스템에서는 수위를 어떻게 계산하고 실제 효과는 어떠한가? 업계의 다양한 실시간 컴퓨팅 시스템과 결합하여 수위 지원은 여전히 다릅니다.

3.3 현재 수위 상태 및 과제

Apache Flink(Google Dataflow의 오픈 소스 구현) 및 Apache Spark(Structured Streaming 프레임워크에만 제한됨)와 같은 현재 업계의 실시간 컴퓨팅 시스템에서는 모두 수위를 지원합니다. 다음은 가장 인기 있는 것입니다. 커뮤니티의 Apache Flink 수위 구현 메커니즘 나열:

그러나 위 수위의 구현 메커니즘 및 효과는 로그 소스에서 로그 전송이 지연되는 넓은 영역의 경우 수위는 여전히 업데이트되고(신규 및 기존 데이터가 순서 없이 전송됨) 이로 인해 해당 창의 데이터가 불완전해지고 창 계산이 부정확해집니다. 따라서 Baidu 내에서 로그 수집 및 전송 시스템과 실시간 컴퓨팅 시스템을 기반으로 개선되고 상대적으로 정확한 수위 메커니즘을 탐색하여 창에서 실시간 데이터가 계산되고 데이터 랜딩(Sink to AFS)을 보장합니다. /Hive) 및 기타 응용 시나리오 다음으로 윈도우 데이터의 무결성 문제는 스트림 배치 통합 데이터 웨어하우스를 구현하기 위한 요구 사항을 충족하는 것입니다.

△Flink 수위 생성 전략

괴짜 토크

04 전지구수위 설계 및 적용

4.1 집중 수위 관리 설계

실시간 계산에서 수위를 보다 정확하게 만들기 위해 중앙 집중식 수위 관리 아이디어를 설계했습니다. 즉, 소스, 운영자, 싱커 등을 포함한 실시간 계산의 각 노드가 수위를 보고합니다. 자체적으로 계산한 정보를 글로벌 Watermark Server로 전송하여 Watermark Server에서 수위 정보를 통합 관리합니다.

△중앙 수위 설계

Watermark Server : 실시간 계산 프로그램(APP)의 전체 토폴로지 정보(Source, Operator, Sinker 등)의 각 레벨에 해당하는 수위 정보를 포함하는 수위 정보 테이블(hash_table)을 유지하므로 전역 수위(예: 낮은 워터마크)의 계산을 용이하게 하기 위해 Watermark Server는 정기적으로 상태와 상호 작용하여 수위 정보가 손실되지 않도록 합니다.

Watermark Client : 수위 업데이트 클라이언트는 Source, Worker, Sinker 등의 실시간 운영자에서 Watermark Server에 수위 정보(Upstream 또는 Global 수위 등)를 보고 및 요청하고 baidu-rpc를 통해 콜백을 요청하는 역할을 담당합니다. 서비스.

Low watermark (low water level) : Low watermark는 실시간 데이터 처리 과정에서 가장 오래된(가장 오래된) 미처리 데이터의 시간을 표시하기 위해 사용하는 타임스탬프입니다 . 시스템이 알고 있는 기록. ). 미래의 데이터는 해당 타임스탬프보다 일찍 도착하지 않을 것이라고 약속합니다. 여기서 시간 계산은 일반적으로 eventtime, 즉 로그에서 사용자 행동이 발생한 시간과 같은 이벤트가 발생한 시간과 데이터 처리 시간(처리 시간, 일부 시나리오에서도 사용할 수 있음)을 기반으로 합니다. )는 덜 사용됩니다.워터마크 계산 공식은 (Google MillWheel 논문 에서 ):

A의 로우 워터마크 = min(A의 가장 오래된 작업, C의 로우 워터마크 : C가 A로 출력)

그러나 실제 시스템 설계에서는 다음과 같이 오퍼레이터 처리의 경계에 따라 로우 워터마크를 구분할 수 있습니다.

입력 로우 워터마크 : 아직 이 스트리밍 단계로 전송되지 않은 가장 오래된 작업입니다.

InputLowWatermark(단계) = min { OutputLowWatermark(단계') | Stage'는 Stage의 업스트림입니다.}

현재 작업자에게 입력될 워터마크, 즉 상위 작업자가 처리한 데이터로 이해될 수 있는 가장 낮은 수위를 입력합니다.
Output Low Watermark : 이 스트리밍 단계에서 아직 완료되지 않은 가장 오래된 작업입니다.

OutputLowWatermark(단계) = min { InputLowWatermark(단계), OldestWork(단계) }

현재 작업자가 처리하지 않은 데이터의 가장 초기(가장 오래된) 수위, 즉 처리된 데이터의 수위로 이해할 수 있는 최저 수위를 출력합니다.

아래 그림과 같이 이해가 더욱 생생해집니다.

△Low watermark의 경계 정의

4.2 정확한 수위를 얻는 방법

4.2.1 정확한 수위를 위한 전제 조건

현재 실시간 데이터 웨어하우스의 실시간 컴퓨팅 시스템 애플리케이션 시나리오에서 우리는 모두 낮은 워터마크를 사용하여 창 계산을 트리거합니다(더 안정적이기 때문).3.1의 낮은 워터마크 정의에서 알 수 있습니다. : 로우 워터마크는 계층적 반복에 의해 계산되며 수위가 정확한지 여부는 가장 상류(즉, 소스) 수위의 정확도에 따라 달라집니다. 따라서 수원 수위 계산의 정확성을 향상시키기 위해서는 다음과 같은 전제 조건이 필요합니다.

서버측 단일 서버에서 시간(event_time)에 따라 순차적으로 로그 생성
로그가 수집될 때 실제 사용자 행동 로그 외에도 다음 그림과 같이 서버 태그(호스트 이름) 및 로그 시간(msg_time)과 같은 다른 정보도 포함해야 합니다.

△ 로그 패키징 정보

로그는 메시지 대기열의 단일 파티션 내에서 단일 서버의 로그가 엄격하게 정렬되도록 실시간 점대점으로 메시지 대기열에 게시됩니다.

△소스 로그는 단일 파티션 로그가 정돈되어 있는지 확인하기 위해 메시지 대기열에 점대점으로 게시됩니다.

4.2.2 수위계산방법

1、워터마크 서버

초기화 :

처음에는 별도의 스레드(스레드)로 시작했습니다. 구성된 로그 전송 작업의 BNS(Baidu Naming Service, 서비스 이름에서 서버의 실행 중인 모든 인스턴스로의 매핑을 제공하는 Baidu 이름 서비스)에 따라 로그 소스의 서버 목록(호스트 이름 목록)이 구문 분석됩니다. 구성된 APP 토폴로지 관계에 따라 워터마크는 정보 테이블 및 영구 쓰기 테이블(Baidu 분산 kv 스토리지 엔진)로 초기화됩니다.

일반 수위 정보 업데이트 : 클라이언트로부터 수위 정보를 받아 해당 입도(프로세서 입도 또는 키그룹 입도)의 수위를 업데이트하고 로컬 수위를 업데이트

정확한 수위 계산 :

실제로 소스의 로그가 100% 정확하게 도착해야 하는 경우 잦은 지연 또는 너무 긴 지연이 발생합니다(글로벌 로우 워터마크 논리가 배포에 사용되는 경우). 그 이유는: 로그 측에 너무 많은 서버 인스턴스가 있는 경우(예: 실제로 6000-10000개의 로그 인스턴스가 있음) 유선 온라인 서비스 인스턴스에서 로그의 실시간 업로드가 항상 지연됩니다. , 따라서 이것은 백분율 형식으로 지연을 허용하는 인스턴스 수를 정확하게 제어하는 것과 같이 데이터 무결성과 적시성 간의 절충안에서 수행되어야 합니다(예: 소스를 허용하는 비율을 설정하려면 99.9% 또는 99.99%를 구성) . 지연될 로그 ), 정확하게 소스에서 수위의 정확도를 제어합니다.

정확한 수위는 특별한 구성이 필요합니다.소스의 출력 저수위는 서버와 소스가 실시간으로 보고하는 로그 진행 간의 매핑 관계 및 구성된 지연 인스턴스의 비율에 따라 계산됩니다.

글로벌 최저 워터마크 계산 : 글로벌 최소 수위를 계산하여 클라이언트 요청에 반환

State Persistence : 쉬운 상태 복구를 위해 정기적으로 글로벌 수위 정보 지속성을 외부 저장소에 기록

2、워터마크 클라이언트

소스 끝 : 로그 패키지를 구문 분석하고 로그 패키지의 컴퓨터 이름 및 원래 로그와 같은 정보를 가져옵니다. ETL에서 원본 로그를 처리하고 원본 로그에 따라 최신 타임스탬프(event_timestamps)를 얻은 후 Source는 주기적으로 Watermark 클라이언트 API(현재 구성 1000ms) 워터마크 서버.

△소스 로그를 파싱하여 얻은 서버와 로그 진행 매핑 관계

운영자 측 :

입력 로우 워터마크 계산: 입력 로우 워터마크로서 업스트림(Upstream)의 출력 로우 워터마크를 획득하여 윈도우 계산 및 기타 작업을 트리거할지 여부를 결정합니다.

출력 로우 워터마크 계산: 로그, 상태(상태) 및 기타 처리 진행(가장 오래된 작업)을 기반으로 자체 출력 로우 워터마크를 계산하고 다운스트림 운영자(다운로드 프로세서)가 사용할 수 있도록 워터마크 서버에 보고합니다.

△워터마크 클라이언트 워크플로우

싱커 쪽 :

싱커 측은 위의 일반 실시간 연산자(Operator)와 동일하게 Input Low Watermark와 Output Low Watermark를 계산하여 자체 수위를 업데이트하며,

또한 데이터 출력 창을 닫았는지 여부를 확인하려면 전역 Low Watermark를 요청해야 합니다.

4.3 시스템 간 정확한 수위 전송

수위 이송의 필요성

많은 경우 실시간 시스템은 격리되지 않고 여러 실시간 컴퓨팅 시스템 간에 데이터 상호 작용이 있으며 가장 일반적인 방법은 두 개의 실시간 데이터 처리 시스템이 업스트림과 다운스트림에 있는 것입니다.

구체적인 성능은 다음과 같습니다. 두 개의 실시간 데이터 처리 시스템이 메시지 대기열(예: 커뮤니티의 Apache Kafka)을 통해 데이터 전송을 구현하므로 이 경우 정확한 수위 전송을 달성하는 방법은 무엇입니까?

구체적인 구현 단계는 다음과 같습니다 .

1. 업스트림 실시간 컴퓨팅 시스템의 로그 소스는 로그가 지점 간 공개되도록 보장하여 전 세계 수위의 정확성을 보장할 수 있습니다(특정 비율은 조정 가능).

2. 업스트림 실시간 컴퓨팅 시스템의 출력단(메시지 대기열 끝으로의 싱커/익스포트)에서 글로벌 로우 워터마크가 발행되었는지 확인해야 합니다. 현재 글로벌 수위 정보를 인쇄하는 데 사용합니다. 배달을 달성하기 위해 각 로그에서;

3. 하류 실시간 데이터 계산 시스템의 소스 끝에서 (상류 실시간 계산 시스템에서) 로그에 포함된 수위 정보 필드를 분석하고 이를 입력으로 사용하기 시작해야 합니다. 수위(낮은 수위 입력), 층별 수위 및 전체 수위 계산의 반복 계산을 시작합니다.

4. 다운스트림 실시간 데이터 컴퓨팅 시스템의 Operator/Sinker 측에서는 로그의 이벤트 시간을 사용하여 창 계산의 입력으로 특정 데이터 분할을 달성할 수 있지만 창 계산을 트리거하는 메커니즘은 여전히 기반입니다. Watermark Server가 반환한 전역 데이터에 대해 Low Watermark가 우선하여 데이터 무결성을 보장합니다.

△실시간 컴퓨팅 시스템 간 정확한 수위 전송 메커니즘

05 실제 효과 및 후속 전망

5.1 실제 온라인 효과

5.1.1 착륙 데이터의 측정 효과(완전성)

실제 온라인 테스트는 정확한 수위를 채택하고(구성된 수위 정확도는 99.9%, 즉 소스 인스턴스 지연의 1/1000만 허용됨) 로그에 지연이 없으면 실시간 착륙 데이터 및 오프라인 데이터는 동일한 시간 창(이벤트 시간)에 있습니다. 효과 비교는 다음과 같습니다(기본적으로 모두 100,000포인트 미만).

△소스 로그가 지연되지 않을 때 데이터 무결성의 영향

소스 로그가 지연되면(소스 로그 인스턴스의 <=0.1%가 지연되고 수위가 계속 업데이트됨) 전체 데이터 차이 효과는 기본적으로 약 1/1,000입니다(로그 소스 지점의 가능성에 따라 다름). -to-point 로그 자체가 데이터 비균질성의 영향):

정확한 수위 메커니즘(수위 정확도 99.9%)의 사용으로 인해 소스 로그의 지연 영역이 큰 경우(소스 로그 인스턴스 지연의 >0.1%) 글로벌 수위는 업데이트되지 않고 실시간 데이터가 AFS에 기록됩니다. 창은 닫히지 않으며, 지연된 데이터의 도착과 글로벌 수위 업데이트를 기다린 후에만 창을 닫아 시스템의 무결성을 보장합니다. 실제 테스트 결과는 다음과 같습니다.

5.2 요약 및 프레젠테이션

실제 정밀 수위 및 실제 온라인 적용에 대한 연구를 거친 후 정밀 수위에 기반한 실시간 데이터 창고는 적시성을 향상시킬 뿐만 아니라 더 높고 유연한 데이터 정밀 메커니즘을 가지고 있습니다.안정성 최적화 후 실제로 완전히 이전의 오프라인 및 실시간 데이터 웨어하우스 시스템 대신 진정한 스트림 배치 통합 데이터 웨어하우스가 실현됩니다.

동시에 중앙 집중식 수위 메커니즘을 기반으로 성능 최적화, 고가용성(오류 복구 메커니즘 개선), 더 미세한 세분성 및 정확한 수위(창 계산 트리거 메커니즘 아래)의 문제에 직면하게 됩니다.

--끝--

참조:

[1] T. Akidau, A. Balikov, K. Bekiroğlu, S. Chernyak, J. Haberman, R. Lax, S. McVeety, D. Mills, P. Nordstrom 및 S. Whittle. Millwheel: 인터넷 규모의 내결함성 스트림 처리. 절차 VLDB Endow., 6(11):1033–1044, 2013년 8월.

[2] T. Akidau, R. Bradshaw, C. Chambers, S. Chernyak, RJ Fernández-Moctezuma, R. Lax, S. McVeety, D. Mills, F. Perry, E. Schmidt 등. 데이터 흐름 모델: 대규모의 무한하고 비순차적 데이터 처리에서 정확성, 대기 시간 및 비용의 균형을 맞추는 실용적인 접근 방식입니다. VLDB 기부금 절차, 8(12):1792–1803, 2015.

[3] T. Akidau, S. Chernyak 및 R. Lax. 스트리밍 시스템. O'Reilly Media, Inc., 1판, 2018.

[4] "워터마크 - 스트리밍 파이프라인의 시간 및 진행률 측정", Slava Chernyak, Google Inc

[5] P. Carbone, A. Katsifodimos, S. Ewen, V. Markl, S. Haridi 및 K. Tzoumas. Apache flink: 단일 엔진에서 스트리밍 및 일괄 처리. 데이터 엔지니어링에 관한 IEEE 컴퓨터 학회 기술 위원회 공지, 36(4), 2015.

Flow-batch 통합 데이터 웨어하우스에서 정확한 수위 탐색 및 실습