망고TV의 플링크 기반 실시간 데이터 웨어하우스 구축 실습

회사 프로필: Mango TV는 Hunan Radio and Television 산하의 인터넷 비디오 플랫폼으로서 "하나의 클라우드, 여러 화면, 여러 통합"이라는 전략적 지침에 따라 독점 방송과 고유성에서 독창성에 이르기까지 자체 제작 콘텐츠를 통해 핵심 경쟁력을 배양합니다. 시장지향적 운영을 통해 A라운드, B라운드 자금조달을 완료하고 2018년 6월 자산 구조조정을 성공적으로 실현하여 국내 최초 A주 국영 동영상 플랫폼이 되었습니다.

팁: 5000CU* 시간의 Flink 클라우드 리소스를 무료로 받으려면 "원문 읽기"를 클릭하십시오 .

망고TV 실시간 데이터 웨어하우스 구축 이력

Mango TV의 실시간 데이터 웨어하우스 구축은 3단계로 구분되며, 1단계는 2014년부터 2019년까지이며, 기술 선택은 Storm/Flink Java+Spark SQL을 채택합니다. 20-22년 상반기는 두 번째 단계이며 기술 선택은 Flink SQL+Spark SQL을 채택합니다. 22-now의 후반부는 세 번째 단계이며 기술 선택은 Flink SQL+StarRocks를 채택합니다. 더 포괄적인 기능, 더 빠른 속도 및 비즈니스 측면의 요구를 더 잘 충족하기 위해 각 업그레이드는 원래 기준으로 반복됩니다. 다음으로 하나씩 소개해드리겠습니다.

1세대는 Storm/Flink Java+Spark SQL을 기반으로 합니다.

Mango TV의 실시간 데이터 처리는 매우 일찍 시작되었습니다. 초기에는 Storm이 사용되었습니다. 2018년에 Flink가 탄생했습니다. Flink의 상태 및 스트림 처리의 장점은 인상적이며 오픈 소스 커뮤니티의 인기와 주요 제조업체의 성공으로 인해 거부할 수 없게 되었기 때문에 Flink를 사용하여 실시간 데이터 웨어하우스를 구축했지만 당시에는 주로 비즈니스 요구를 충족하기 위한 것이었고 굴뚝 스타일 개발은 당사자의 요구에 따라 수행됩니다. 기본 프로세스는 업스트림 Kafka 데이터를 연결하고 Flink Java를 사용하여 관련 비즈니스 로직을 처리한 다음 데이터를 오브젝트 스토리지로 출력하는 것입니다. 그런 다음 Spark SQL을 사용하여 데이터에 대한 통계와 같은 2차 처리를 수행한 다음 고객에게 전달합니다. 이 단계의 장점은 Flink의 강점을 활용하여 소스에서 터미널까지 데이터를 보다 실시간으로 만들어 데이터에 대한 비즈니스 측면의 적시성과 비즈니스 요구를 충족한다는 것입니다. 단점은 필요할 때 기능을 만들어 실시간 데이터 웨어하우스 구축 및 강수량이 없다는 점이다.

2세대는 Flink SQL+Spark SQL을 기반으로 합니다.

이전 단계에서 발견한 기술적 축적과 문제점을 바탕으로 실시간 데이터 웨어하우스 구축을 위한 새로운 방안을 제시한다. 현재 Flink SQL 기능은 예비적으로 완벽하여 데이터 웨어하우스 구축의 모든 측면의 요구를 충족할 수 있습니다.Flink Java와 비교하여 SQL은 개발, 유지 관리 및 기타 측면의 비용도 줄일 수 있습니다. 그래서 실시간 데이터 웨어하우스를 구축하기 위해 Flink SQL을 선택했습니다. 이 단계에서는 실시간 데이터 웨어하우스의 계층화된 아키텍처 설계가 수행되며 이에 대해서는 나중에 자세히 설명합니다. 기본 프로세스는 업스트림 Kafka 데이터를 연결하여 형식을 지정하고 Kafka로 출력하고, 하위 계층은 필드 처리, 가비지 데이터 필터링 및 기타 작업을 위해 Kafka 데이터를 수신한 다음 Kafka로 출력하고, 마지막 계층은 차원 확장을 위해 Kafka 데이터를 수신하고, 그런 다음 스토리지의 개체에 데이터를 씁니다. Spark SQL은 통계 및 기타 처리를 위해 객체 스토리지의 데이터를 읽은 후 고객에게 전달하여 사용합니다. 이 단계의 장점은 데이터 웨어하우스의 계층 구조 설계가 실현되고, 각 계층의 데이터 정의가 표준화되고, 각 계층의 데이터 분리가 실현되고, 굴뚝식 개발이 방지되고, 반복 개발의 문제가 있다는 것입니다. 해결되고 실시간 데이터 웨어하우스는 점진적으로 성숙 단계로 이동하고 있습니다. 단점은 후속 통계 및 요약에 Spark SQL을 사용할 만큼 유연하지 않다는 것입니다. 사전에 지표를 설계해야 하며 고객의 변화하는 요구에 직면했을 때 적시에 대응하지 못하는 경우가 많습니다.

3세대는 Flink SQL+StarRocks를 기반으로 합니다.

실시간 데이터 웨어하우스 구축이 점차 심화됨에 따라 Spark SQL은 유연성이 부족하고 처리 속도가 부족한 단점이 점점 더 두드러지고 있습니다. 이때 StarRocks가 눈에 들어왔는데, MPP 아키텍처, 벡터화 엔진, 다중 테이블 조인 및 기타 기능은 성능과 사용 편의성에서 장점을 보여주어 이 영역에서 Spark SQL의 단점을 모두 보완합니다. . 그래서 연구 끝에 실시간 데이터 웨어하우스에서 Spark SQL을 StarRocks로 교체하기로 결정했습니다. 이 단계에서 Flink SQL로 구축된 실시간 데이터 웨어하우스의 계층 구조는 변경되지 않았으며 Spark SQL로 통계 분석과 관련된 다운스트림 기능은 점차 StarRocks로 대체되었습니다. StarRocks의 장점과 실시간 데이터 웨어하우스 구축 시 발생하는 문제점을 바탕으로 이전 Spark SQL 모델을 복사하지 않고 새로운 모델을 선택했습니다. 임시 쿼리는 StarRocks를 사용하여 구현됩니다. 이전에는 Spark SQL을 사용하여 통계를 수집하고 데이터를 요약한 다음 최종 결과 데이터를 개체 스토리지에 기록했습니다. 그러나 이제 StarRocks는 세부 데이터를 요약하고 프런트 엔드 페이지에 표시하는 데 직접 사용됩니다. 이를 통해 비즈니스 측면의 요구 사항을 더 빠르고 유연하게 충족하고 개발 작업량을 줄이며 테스트 및 온라인 전환 시간을 줄일 수 있다는 장점이 있습니다. StarRocks의 뛰어난 성능은 ad hoc 쿼리 속도가 느려지지 않도록 하며 기능은 더 강력하고 유연하며 전송 속도는 더 빠릅니다.

자체 개발한 Flink 실시간 컴퓨팅 스케줄링 플랫폼 소개

기존 문제점

기본 작업 명령은 복잡하고 디버깅이 번거롭고 개발 비용이 상대적으로 높습니다.
커넥터, UDF, Jar 작업 패키지 등을 관리할 수 없고 디버깅이 복잡하며 종속성 충돌이 자주 발생합니다.
리소스에 대한 통합 모니터링 및 경보 및 권한 관리를 달성하는 것은 불가능합니다.
SQL 작업의 개발은 복잡하고 사용하기 쉬운 편집기와 코드 관리 및 저장 플랫폼이 없습니다.
기본 테이블, 차원 테이블 및 카탈로그에는 기록 및 시각화 플랫폼이 없습니다.
다중 버전 및 교차 클라우드 작업은 제대로 관리할 수 없습니다.
우수한 로그 관리 메커니즘이 없으면 프로덕션 환경에서 문제를 신속하게 찾는 것이 불가능합니다.

플랫폼 아키텍처 설계

실시간 Flink 스케줄링 플랫폼 아키텍처 다이어그램:

플랫폼은 크게 세 부분으로 나뉩니다.

1. Phoenix Web 모듈은 주로 대면 사용자를 담당합니다.

클러스터 배포 및 작업 제출.
회사의 내부 업무 권한 관리.
카탈로그 및 다중 소스 정보 관리를 지원합니다.
UDF 및 커넥터와 같은 세 당사자는 Jar 패키지 관리에 의존합니다.
다중 유형 모니터링 알람 및 로그 관리.
SQL 시각적 편집 및 검증 및 다중 버전 저장.

2. Flink SQL Gateway 및 Flink Jar Gateway 모두 오픈 소스 버전을 기반으로 수정 및 사용자 정의된 서비스입니다.비즈니스 시나리오 및 Jar 작업 제출에 따라 SQL 구문 분석 및 검증을 지원합니다.로컬 모드, Yarn-per-job을 지원합니다. 모드 및 응용 프로그램 모드 자동 저장점도 지원됩니다.

SQL 구문 분석 및 확인을 수행합니다.
SQL 및 Jar 작업을 로드하는 데 필요한 타사 종속성.
SQL 작업은 연결 및 매핑을 위해 카탈로그 저장소에 연결합니다.
Checkpoint 및 Savepoint의 자동 관리 및 복구.
Jar 유형 태스크 시작 매개변수 삽입.
적응형 런타임 구성.
여러 유형의 제출 방법이 적용됩니다.

3. 하이브리드 멀티클라우드 모듈은 클라우드 간 스타트업 업무 분배 및 정보 관리를 주로 담당한다.

Flink SQL 실시간 데이터 웨어하우스 계층화 실습

Flink SQL을 사용하여 실시간 데이터 웨어하우스를 구축할 때 첫 번째 문제는 데이터 웨어하우스의 계층 구조를 어떻게 해결할 것인가 하는 것입니다. 최종적으로 다음 데이터 웨어하우스 아키텍처를 채택했습니다.

ODS 계층: 원본 로그 계층 이 계층에서는 업스트림 Binlog 로그, 사용자 행동 로그 및 외부 데이터와 같은 데이터 소스가 데이터 웨어하우스에 동기화됩니다. 다양한 데이터 소스 및 형식의 데이터는 통합 UDF 기능을 통해 파싱 및 형식화됩니다. , 마지막으로 형식화된 JSON 데이터를 출력합니다.

DW 레이어: 오류 데이터 필터링, 필드 이스케이프, 통합 필드 이름 등이 주로 처리되는 데이터 세부 레이어이며 출력 데이터는 일일 기본 분석 사용을 충족할 수 있습니다.

DM 계층: 관련 공개 정보를 보완하기 위해 차원 확장이 수행되는 데이터 모델 계층입니다. 그런 다음 비즈니스에 따라 도메인으로 나뉘고 출력 데이터는 고급 분석의 데이터 사용 요구 사항을 충족할 수 있는 더 풍부한 차원을 갖습니다.

ST 레이어: 비즈니스, 기능 및 기타 차원에 따라 요약되고 표시를 위해 프런트 엔드 페이지로 전달되는 데이터 애플리케이션 레이어이며 출력 데이터는 웹, 앱, 애플릿 및 기타 기능으로 전달될 수 있습니다.

Flink SQL 실시간 데이터 웨어하우스 생산 과정에서 발생하는 문제

실시간 데이터 웨어하우스를 구축할 때 많은 문제에 직면했는데 솔루션 아이디어를 설명하는 몇 가지 일반적인 문제는 다음과 같습니다.

1. 다중 테이블 연관, 이것은 데이터 웨어하우스를 구축할 때 매우 중요하고 일반적으로 사용되는 기능입니다. 특히 다중 테이블 연관의 경우 일부 차원 테이블 데이터는 Hive에 있고 일부 차원 테이블 데이터는 MySQL에 있으며 일부 차원 테이블 데이터는 심지어 다른 OLAP에 있기 때문에 어떤 연관 방법을 선택해야 하는가가 큰 문제였습니다. 많은 시도 끝에 성능, 기능 및 기타 측면의 균형 하에서 다음 규칙이 요약됩니다.

플로우 테이블은 Lookup Join을 사용하여 차원 테이블(작은 데이터 볼륨)과 연결되며, 차원 테이블 데이터 볼륨이 100,000 미만인 경우 Hive 테이블은 차원 테이블로 사용할 수 있습니다. 오프라인 데이터 웨어하우스는 Hive에 있습니다.직접 재사용할 수 있어 데이터 가져오기 및 내보내기의 추가 작업을 절약하고 성능 병목 현상이 없습니다.차원 테이블이 매시간 업데이트된 후 Flink SQL은 최신 데이터를 읽을 수도 있습니다.
플로우 테이블은 차원 테이블(대용량 데이터)과 연결됨 Lookup Join 사용 차원 테이블 데이터 볼륨이 100,000-1,000만 미만인 경우 MySQL 테이블을 차원 테이블로 사용할 수 있음 이때 Hive 차원 테이블은 충족할 수 없음 성능 요건. 데이터를 MySQL로 내보낼 수 있으며 캐시 메커니즘을 사용하여 요구 사항을 충족할 수도 있습니다.
플로우 테이블은 인터벌 조인(Interval Join)을 사용하여 플로우 테이블과 연결되며, 두 플로우 테이블의 시간 필드는 연결 범위를 제어하는 데 사용되며, 이러한 연결 방법은 현재 더 많이 사용됩니다. 사용 방식도 오프라인에 가깝다.

2. 복잡한 테이블 처리 일부 복잡한 데이터 정리 시나리오에서 차원 테이블을 연결할 때 차원 테이블의 데이터는 사용되기 전에 하나 또는 여러 계층의 처리를 거쳐야 합니다. 이러한 시나리오에서 오프라인 데이터 웨어하우스는 직접 한 단계로 완료하려면 조인 중에 다단계 하위 쿼리를 작성하십시오. 그러나 Flink SQL에서는 지원되지 않으며 기본 메커니즘에서 거부됩니다. 수많은 시도와 고군분투 끝에 최종 해결책은 Hive에서 차원 테이블 데이터를 전처리하는 것이고, 실시간 데이터 웨어하우스는 전처리된 차원 테이블 데이터를 사용합니다. 그러나 이것은 과도기적 해결책일 뿐이며, 현재 우리는 차원 테이블에 대해 임의의 복잡한 계산을 수행한 후 차원 테이블의 연관을 실현하는 새로운 메커니즘이 미래에 있을 것이라고 커뮤니티에서 배웠습니다. Flink 커뮤니티의 업데이트는 여전히 매우 빠릅니다.

3. State가 너무 큰 경우 두 개의 흐름 테이블이 연결되거나 요약 통계가 수행될 때 Flink의 메커니즘은 State의 데이터를 캐시하는 것입니다. 이로 인해 State가 너무 커서 GC 및 작업 실패가 자주 발생합니다. 이러한 상황을 고려하여 Flink의 메모리 메커니즘을 연구한 결과 해결 방법은 다음과 같습니다.

시간 범위를 줄이고 비즈니스 요구 사항에 따라 연결하는 동안 두 스트림의 시간 범위를 적절하게 줄입니다.
관리 메모리의 크기를 조정하고 관리 메모리의 비율을 조정하고 다른 메모리의 사용을 적절하게 줄일 수 있습니다.
너무 많은 데이터를 캐싱하지 않도록 상태의 TTL을 설정합니다.

4. 완료하기 전에 체크포인트가 만료되는 예외가 태스크에 자주 나타납니다.실제 프로덕션 환경에서 일부 태스크가 이 오류를 자주 보고하는 것으로 나타났습니다. 데이터는 ExactlyOnce 정확합니다.일관성, 데이터 배치를 처리할 수 없으면 Checkpoint를 완료할 수 없습니다.관심 있는 사람은 가서 알아볼 수 있습니다. 이 오류에는 여러 가지 이유가 있으며 문제마다 답변이 다릅니다.다음으로 시나리오와 해결 방법은 다음과 같습니다.

체크포인트 시간 초과 기간이 너무 짧습니다. 이는 비교적 일반적이고 해결하기 쉬운 상황입니다. 그 이유는 체크포인트의 타임아웃 기간이 너무 짧게 설정되어 체크포인트가 완료되기 전에 타임아웃이 보고되는 현상이 발생하기 때문입니다.
작업에는 배압이 있으며 이 또한 매우 일반적입니다.작업에는 여러 작업이 있으며 작업 중 하나는 전체 작업의 실행에 영향을 미치기까지 오랜 시간이 걸립니다. 체크포인트 완성에도 영향을 미치며 관심이 있는 경우 확인할 수 있습니다. 해결 방법은 WebUi에서 느린 실행 Task를 찾아 특정 문제를 상세하게 분석하여 해결하는 것입니다.
메모리 부족, 먼저 배경에 대해 이야기하겠습니다. 우리는 일반적으로 프로덕션 환경에서 Rocksdb statebackend를 사용하며 전체 체크포인트는 기본적으로 예약됩니다. 이 경우 연관 및 그룹 통계와 같이 힙 상태 백엔드를 사용하는 작업을 만났을 때 계산의 중간 결과는 State에 캐시되며 State의 메모리는 기본적으로 전체 메모리의 40%입니다. 충분하지 않아 GC가 자주 발생하고 Checkpoint 실행에도 영향을 미칩니다. 해결책은 다음과 같습니다.
- TaskManager의 메모리를 늘립니다.TaskManager의 메모리가 늘어나면 그에 따라 다른 메모리 영역도 늘어납니다.
- Managed Memory의 메모리 비율을 높이려면 taskmanager.memory.managed.fraction 매개변수를 설정해야 하며 실제 상황에 따라 실제 프로덕션에서 최대 90%까지 조정할 수 있습니다. 이 방법은 ManagedMemory를 하나씩만 증가시키며, 메모리 리소스가 충분하지 않은 경우 이 방법을 사용할 수 있습니다.
- 대신 증분 체크포인트를 사용하고 실제 상황에 따라 State의 TTL 시간을 조정하고 증분 체크포인트를 활성화합니다. 메모리 크기를 조정하지 않아도 문제를 해결할 수 있습니다.

5. Flink SQL에서 if 함수를 사용할 때 우연히 발견한 문자열 반환 시 최대 길이에 따라 반환합니다. 예를 들어 if(condition, stringA, stringB)이면 stringA의 길이는 10이고 stringB의 길이는 2입니다. condition = false인 경우 stringB가 반환되면 stringB의 길이가 채워집니다. 10까지이며, 부족할 경우 공백이 부여됩니다. 이것은 주의해야 할 사항입니다. 하지만 나중에 알게 된 사실은 이 현상은 1.16.3 버전에서 수정되었고, 1.15를 사용하고 있으니 혹시라도 마주치게 된다면 CaseWhen으로 대체하거나 Flink 버전을 1.16.3 이상으로 업그레이드하여 해결할 수 있습니다.

스타록스 선정 배경 및 문제점

이전 프레임워크에서는 Flink 스트림 처리 엔진을 사용하여 원본 로그 정리, 데이터 확장 및 가벼운 집계를 완료한 다음 분산 파일 시스템 또는 개체 스토리지에 상륙하고 오프라인을 통해 5분 수준의 예약 배치를 수행했습니다. Spark SQL.처리 후 결과는 Presto와 같은 엔진을 통해 쿼리됩니다.이러한 아키텍처는 생산 환경에서 점차 많은 문제를 드러냅니다.

예를 들어:

반복 계산의 문제가 있습니다.원본 데이터는 다른 작업에서 반복적으로 정리되고 여러 원본 데이터가 필요한 일부 연결도 반복적으로 정리됩니다.이는 많은 컴퓨팅 리소스를 낭비하고 코드 및 데이터 흐름의 재사용 가능성이 있습니다. 가난한.
오프라인 일괄 처리의 과거 누적 값과 현재 5분 창의 계산 지수를 충족하기 위해 피크 트래픽 기간과 하루는 저녁까지 누적됩니다. 시간 초과의 큰 위험이 있으며 비즈니스는 실시간 지표에 대한 지연 시간을 피드백합니다.
다차원 결합 분석의 경우 오프라인 Spark 배치 처리가 다소 약하고 실시간 성능이 요구되기 때문입니다. 온라인 비즈니스는 많은 실시간 시나리오를 낳았고, 반면 운영의 정교화와 분석의 민간화는 다차원 분석 요구 사항을 낳았습니다.이러한 시나리오에는 매우 세분화되고 풍부한 차원의 기본 데이터가 필요합니다.이 두 가지 이러한 결과의 중첩은 실시간 다차원 분석 장면을 탄생시켰습니다. 이때 위의 시나리오를 충족하기 위해 지속적으로 차원 조합을 늘리고 결과 필드를 늘리고 컴퓨팅 리소스를 늘려야 하지만 여전히 약간 약합니다.
오늘날 데이터 적시성은 나날이 증가하고 있으며 많은 시나리오에서 데이터 적시성은 초 및 밀리초를 필요로 합니다.이전의 5분 방법은 비즈니스 요구를 충족할 수 없습니다.
이전 실시간 작업에서는 스트림과 Flink 메모리의 스트림을 결합해야 하는 경우가 많았습니다.이 모든 작업은 Flink 작업 메모리에서 수행해야 합니다.여러 업스트림 데이터 스트림의 데이터 도착 시간이 일치하지 않기 때문에 어렵습니다. 컴퓨팅에 적합한 창을 설계하기 위해 엔진의 넓은 데이터, Flink Interval Join을 사용할 때 여러 스트림 사이의 시간 간격이 너무 길고 상태 데이터가 매우 크며 mapState와 같은 상태 계산이 활성화됩니다. 너무 맞춤화되었습니다.
Flink 정리 또는 계산 결과를 위해 여러 개의 저장 매체가 필요할 수 있음 상세 데이터의 경우 분산 파일 시스템 또는 오브젝트 스토리지에 저장할 수 있음 이때 Flink+HDFS 비즈니스 업데이트 스트림 데이터의 경우 Flink CDC+hbase(cassandra 또는 기타 키-값 데이터베이스), Flink+MySQL(redis)를 사용하여 Flink에 대한 재추적 흐름 데이터를 생성할 수 있으며, Flink+elasticsearch를 위험 제어 데이터 또는 기존 세분화된 버전 보기에 사용할 수 있습니다. 대규모 로그 데이터 지표 분석은 Flink+clickhouse일 수 있는데, 이는 통합이 어렵고 많은 리소스가 소모되며 유지 관리 비용도 높습니다.
온라인에서 대규모 활동이나 대규모 프로그램이 있을 때 실시간 데이터의 양이 급격히 증가하는데, 실시간 대량 쓰기의 경우 쓰기 지연이 크고 쓰기 효율이 높지 않으며 데이터가 백로그.

전반적인 분석, 초기 아키텍처에는 몇 가지 문제가 있습니다.

데이터 소스가 다양하고 유지 관리 비용이 상대적으로 높습니다.
불충분한 성능, 큰 쓰기 지연, 대규모 판촉 시나리오의 데이터 백로그, 열악한 대화형 쿼리 경험.
각 데이터 소스는 단편화되어 상호 연관 및 쿼리할 수 없으므로 많은 데이터 섬을 형성합니다. 그러면 개발의 관점에서 각 엔진은 해당 학습 및 개발 비용에 투자해야 하며 프로그램 복잡성이 상대적으로 높습니다.
높은 실시간 요구 사항, 빠른 개발 효율성, 코드 또는 데이터의 강력한 재사용성.
실시간 작업 개발에는 동일한 표준 세트가 없으며 각각 독립적으로 작동합니다.

이를 위해 테스트 환경에서 간단한 성능 비교를 수행했으며 세부 사항은 다음과 같습니다.

비교 환경 StarRocks: 4 *16C*128G Presto: 22*32C*256G(비독점)

데이터 양: 이벤트 테이블(총 100억 데이터, 1일 1,000만 de-reuse)

테스트 케이스	곧	스타록
단일 테이블 집계 테스트	13.1	5
협회 테스트	19	8
유지하다	24	15
윈도우 기능	16	8
깔때기	3.5	3.2
다중 테이블 연결	36	19

이 테스트는 16C128G 메모리가 있는 4개의 BE 서버를 사용하며 테스트 결론은 기본적으로 수백억 데이터의 쿼리 요구 사항을 충족할 수 있습니다. 테스트 결과는 리소스 차이가 큰 경우 StarRocks의 성능이 Presto보다 훨씬 우수하며 평균 효율성이 2-3배 증가하는 것으로 나타났습니다.

Flink SQL+StarRocks 기반 데이터 웨어하우스 실시간 분석

구축된 Flink SQL 데이터 웨어하우스 계층화 시스템을 기반으로 StarRocks2.5X 버전에서 StarRocks3.0X 스토리지-컴퓨팅 분리 버전으로 업그레이드되어 대규모 프로덕션 환경에 투입되었습니다.

실시간 및 오프라인 호수 창고 통합의 아키텍처 다이어그램:

상세 모델

빅 데이터 생산 환경에서 가장 일반적인 로그 데이터는 많은 양의 데이터, 다차원 유연하고 복잡한 계산, 많은 계산 지표, 강력한 실시간 성능, 두 번째 수준의 고성능 쿼리, 간단하고 안정적인 특징이 있습니다. 실시간 스트림 쓰기, 대형 테이블 조인, 높은 카디널리티 중복 제거.

이러한 요소는 Flink SQL+StarRocks에 대해 충족될 수 있습니다.먼저 실시간 플랫폼에서 Flink SQL을 사용하여 실시간 스트리밍 로그 데이터를 신속하게 정리하고 확장합니다.동시에 StarRocks는 Flink-Connector-StarRocks 커넥터 아웃을 제공합니다. ExactlyOnce 및 트랜잭션을 지원합니다. Stream Load를 통한 낮은 대기 시간 및 빠른 가져오기를 지원합니다.

예를 들어:

효율적이고 간단한 Flink SQL 테이블 작성 모드를 통해 수백만 개의 데이터 배치가 작성되고 속도가 빠름과 동시에 하나 이상의 프로덕션 환경에서 단일 테이블에 대한 다차원 사용자 액세스 수 10억 데이터, 사용자 중복 제거 데이터는 두 번째 수준에 도달할 수 있습니다.

기본 키 모델

OLAP 데이터 웨어하우스에서 가변 데이터는 일반적으로 눈살을 찌푸리게 합니다.

데이터 웨어하우스의 데이터 변경 방법:

방법 1: 일부 OLAP 데이터 웨어하우스는 (clickhouse)와 같은 데이터 변경을 완료하기 위해 Merge on Read 모델의 업데이트 기능을 제공합니다.
방법 2: 간단히 말해서 새 파티션 테이블을 생성하고 이전 파티션 테이블의 데이터를 삭제한 다음 일괄적으로 플래싱하는 것입니다.

수정된 데이터를 새 파티션에 삽입하고 파티션 교환을 통해 데이터 변경을 완료합니다.

일괄 플래싱으로 인해 테이블이 재구축되고 파티션 데이터가 삭제되며 데이터 플래싱 프로세스가 복잡하고 오류가 발생할 수 있습니다.

Merge on Read 모드는 쓰기에는 간단하고 효율적이지만 읽기에는 버전 병합에 많은 리소스를 소모함과 동시에 병합 연산자의 존재로 인해 술어를 푸시다운할 수 없고 인덱스를 쿼리 성능에 심각한 영향을 미칩니다. StarRocks는 삭제 및 삽입 모드를 기반으로 한 기본 키 모델을 제공하여 버전 병합으로 인해 운영자가 푸시다운되지 않는 문제를 방지합니다. 기본 키 모델은 데이터를 실시간으로 업데이트해야 하는 시나리오에 적합합니다.행 수준 업데이트 작업을 더 잘 해결하고 백만 수준의 TPS를 지원할 수 있습니다.MySQL 또는 기타 비즈니스 라이브러리가 StarRocks에 동기화되는 시나리오에 특히 적합합니다. .

또한 Flink CDC와 StarRocks의 완벽한 조합은 비즈니스 데이터베이스에서 OLAP 데이터 웨어하우스까지 전체 + 증분 실시간 동기화를 실현할 수 있습니다.하나의 작업으로 모든 배치 및 실시간 문제를 높은 효율성과 안정성으로 해결할 수 있습니다. . 동시에 기본 키 모델은 Flink에서 retracement 스트림 출력 문제를 해결할 수 있고 조건별 업데이트를 지원하며 열별 업데이트를 지원하며 이는 기존 OLAP 데이터베이스가 동시에 가지고 있지 않은 많은 이점입니다.

Flink CDC+StarRocks 모델은 생산 환경의 많은 문제를 해결할 수 있습니다.StarRocks와 Flink의 공동 솔루션은 실시간 데이터 분석 시스템을 구축하여 기존의 일부 제한을 어느 정도 파괴하고 실시간 데이터의 새로운 패러다임을 형성합니다. 분석 및 통합 가속화 실시간 로그 데이터 및 비즈니스 데이터는 기존 오프라인 데이터의 일괄 추출 문제를 해결하고 오프라인 및 실시간 데이터의 통합을 실현하며 스트림 일괄 통합 프로세스를 가속화할 수 있습니다.

집계 모델

실시간 데이터 웨어하우스에 또 다른 시나리오가 있습니다.우리는 원본 상세 데이터에 대해 별로 신경 쓰지 않습니다.대부분은 SUM, MAX, MIN 및 기타 유형의 쿼리와 같은 요약 쿼리입니다.오래된 데이터는 업데이트되지 않습니다. 자주, 그리고 새로운 데이터만 추가될 것입니다. 이때 집계 모델 사용을 고려할 수 있습니다. 테이블을 생성할 때 정렬 키 및 인덱스 열 정의와 인덱스 열에 대한 집계 함수 지정을 지원합니다. 여러 데이터 조각이 동일한 정렬 키를 갖는 경우 인덱스 열이 집계됩니다. 통계를 분석하고 데이터를 요약할 때 집계 모델은 쿼리 중에 처리해야 하는 데이터를 줄이고 쿼리 효율성을 높일 수 있습니다.

과거에는 통계를 위해 이러한 작업을 Flink에 넣을 수 있습니다.상태 데이터는 메모리에 존재하므로 상태 데이터가 계속 증가하고 많은 리소스를 소비합니다.Flink의 단순 통계를 Flink SQL+StarRocks 집계 모델로 변경 , Flink 여기에서 세부 데이터를 정리하고 매우 효율적이고 안정적인 StarRocks로 가져오기만 하면 됩니다.

실제 제작에서는 주로 사용자 조회 시간, 클릭 수, 주문 통계 등을 계산하는 데 사용합니다.

구체화된 뷰

데이터 웨어하우스 환경의 애플리케이션은 여러 대형 테이블에 대해 복잡한 쿼리를 수행하는 경우가 많으며, 종종 여러 테이블에서 수십억 개의 데이터 행을 연결하고 집계하는 작업이 수반됩니다. 이러한 실시간 다중 테이블 연결 및 쿼리 결과 방법을 실현하기 위해 이 콘텐츠를 처리, 연결 레이어 처리, 병합, 통계 및 기타 작업을 위해 Flink 실시간 데이터 웨어하우스에 넣고 최종적으로 결과 레이어를 출력할 수 있습니다. 데이터, 이러한 쿼리를 처리하는 것은 일반적으로 많은 시스템 리소스와 시간을 소비하므로 매우 높은 쿼리 비용이 발생합니다.

이제 Flink SQL+StarRocks라는 새로운 아이디어를 사용하여 이 대규모 계층 컴퓨팅 문제를 처리하는 것을 고려할 수 있으므로 Flink SQL은 여기에서 몇 가지 간단한 정리 작업만 처리하고 많은 StarRocks에 반복 계산을 수행하여 실시간 스트림이 실시간으로 도착하고 다단계 구체화된 뷰의 모델링 방법을 StarRocks에서 설정할 수 있습니다. StarRocks의 구체화된 뷰는 내부 테이블과 내부 테이블 간의 연결을 지원할 뿐만 아니라 뿐만 아니라 내부 테이블과 외부 테이블 간의 연결도 지원합니다.예를 들어 데이터가 MySQL, Hudi, Hive 등에 있는 경우 StarRocks 구체화된 보기를 통해 가속할 수 있으며 정기적인 새로 고침 규칙을 설정하여 관련 작업의 수동 예약을 방지합니다. . 가장 큰 특징 중 하나는 우리가 설정한 구체화된 뷰로, 구체화된 뷰가 구축된 기본 테이블에 대한 새로운 쿼리가 있을 때 시스템은 구체화된 뷰에서 미리 계산된 결과를 재사용할 수 있는지 여부를 자동으로 판단합니다. 쿼리를 처리합니다. 재사용할 수 있는 경우 시스템은 관련 구체화된 뷰에서 미리 계산된 결과를 직접 읽어 시스템 리소스와 시간을 소모하는 반복 계산을 방지합니다. 쿼리 빈도가 높거나 쿼리 문이 복잡할수록 성능 향상이 더 분명해집니다.

실시간은 미래이며, StarRocks는 이 기능을 점차 실현하고 있습니다. 실시간 데이터 분석 시스템을 구축하기 위한 StarRocks와 Flink의 공동 솔루션은 기존의 일부 제한을 어느 정도 극복하고 실시간 데이터의 새로운 패러다임을 형성할 것입니다. 분석.

미래 전망

통합 호수 및 창고

현재 Mango TV는 스트림과 배치를 통합하는 데이터 웨어하우스 구축을 실현했으며 향후 초점은 통합 레이크 웨어하우스 구축에 맞춰질 것입니다.

데이터 레이크는 정형 데이터, 반정형 데이터 및 비정형 데이터를 포함하여 다양한 유형과 형식의 원시 데이터를 저장하는 기능이 특징입니다. 데이터 웨어하우스는 특정 비즈니스 요구 사항을 충족하기 위해 데이터를 구조화하고 구성하는 것입니다.

레이크와 웨어하우스의 통합은 데이터 웨어하우스와 데이터 레이크의 특성을 통합하여 통합 데이터 센터를 만들고 데이터의 중앙 집중식 관리를 실현합니다. 레이크와 웨어하우스의 통합 아키텍처는 더 나은 보안, 비용 효율성 및 개방성을 제공할 수 있으며 대량의 원시 데이터를 저장 및 관리할 수 있을 뿐만 아니라 데이터를 구조화된 형식으로 구성하여 분석 및 쿼리를 용이하게 합니다.

레이크와 웨어하우스의 통합을 통해 Mango TV는 회사에 더 풍부한 데이터 서비스를 제공하고 비즈니스 의사 결정 및 혁신을 지원하며 데이터 수집, 저장, 처리 및 분석을 포함한 데이터의 포괄적인 제어 및 관리를 실현할 수 있습니다. 동시에 레이크와 웨어하우스의 통합은 Flink, Spark, Hive 등과 같은 여러 컴퓨팅 엔진 및 도구의 사용을 지원하여 데이터 처리 및 분석을 보다 유연하고 효율적으로 만듭니다.

낮은 코드

현재 개발 방법은 자체 개발 플랫폼에서 SQL 제출 작업을 작성하는 것인데 일부 정리 시나리오에 직면했을 때 이 방법의 대부분은 반복 작업이며 개선의 여지가 많습니다. 로우 코드는 오늘날 대중적인 개념이며 비용 절감과 효율성 증가에 큰 이점이 있습니다. 우리의 다음 계획은 점진적으로 낮은 코드를 실현하는 것입니다.첫 번째 단계는 실시간 플랫폼과 데이터 보고 플랫폼을 연결하는 것입니다.보고 플랫폼에서 관련 메타 데이터를 읽어 해당 데이터 정리 작업을 자동으로 생성하고 생산성을 해방할 수 있습니다. 작업 개선 효율성 및 배송 속도.

로우코드의 장점은 개발 과정에서 반복적인 작업을 자동화하고 단순화하여 개발자의 코딩 작업량을 줄일 수 있다는 것입니다. 시각적으로 개발자는 드래그 앤 구성을 통해 많은 코드를 작성하지 않고도 작업을 완료할 수 있습니다. 이렇게 하면 개발 효율성이 향상될 뿐만 아니라 오류 위험도 줄어듭니다.

로우 코드 개발 접근 방식을 구현함으로써 Mango TV는 데이터 처리 및 분석 속도를 높이고 팀의 전반적인 효율성을 향상시킬 수 있습니다. 또한 로우 코드는 개발자의 기술적 요구 사항을 줄여 더 많은 사람들이 데이터 처리 및 분석에 참여할 수 있도록 합니다.

요약하면, Flink 기술의 특성을 기반으로 Mango TV는 미래 데이터 웨어하우스 구축에서 레이크와 웨어하우스의 통합 아키텍처를 실현하는 데 중점을 두어 데이터의 포괄적인 관리 및 활용을 실현할 것입니다. 이와 함께 망고TV는 개발 효율과 전달 속도를 높이기 위해 로우코드 개발 방식을 점진적으로 도입할 계획이다. 이러한 이니셔티브는 장편 비디오 데이터 분석 분야에서 Mango TV의 발전을 더욱 촉진하고 비즈니스 의사 결정 및 혁신을 위한 강력한 지원을 제공할 것입니다.

▼ " Apache Flink 공개 계정 제출 ", 장기 참여를 환영합니다 ▼