XL-LightHouse와 Flink, ClickHouse 스트리밍 빅데이터 통계 시스템

Flink 작업은 하나 또는 몇 개의 데이터 스트림만 병렬로 처리할 수 있는 반면, XL-LightHouse 작업은 수만 또는 수십만 개의 데이터 스트림을 병렬로 처리할 수 있습니다.

Flink 작업은 하나 또는 몇 개의 데이터 표시기만 구현할 수 있는 반면, 단일 XL-LightHouse 작업은 수만 개의 데이터 표시기로 구성된 대규모 배치를 지원할 수 있습니다.

1、XL-라이트하우스:

  •  1. 데이터 실행을 위해 Flink, Spark, ClickHouse 또는 Redis 기반의 비대하고 번거로운 솔루션을 사용할 필요가 없습니다.
  •  2. 개인의 가치 향상에 큰 도움이 되지 않는 데이터 통계 요구 사항을 처리하느라 더 이상 지치지 않고, 사소하고 반복되는 데이터 통계 요구 사항을 없애고 보다 가치 있는 데이터에 집중할 수 있습니다. 개인적인 발전과 사업 발전에 관한 문제;
  •  3. 세분화된 모니터링 지표를 쉽게 달성할 수 있도록 지원합니다. 이는 서비스 운영 상태를 모니터링하고 다양한 비즈니스 데이터 변동 및 지표 이상 현상을 해결하는 데 도움이 됩니다.
  •  4. 데이터 사고를 함양하고, 귀하가 참여하는 업무에 대한 데이터 지표 시스템을 구축하도록 지원하며, 업무 성과를 정량화하고, 전문적이고 엄격한 직장인이 되어 더 큰 개인적 가치를 창출합니다.

2. 스트리밍 통계는 스트리밍 컴퓨팅의 계산 형태이지만,

        스트리밍 통계는 Count 연산, Sum 연산, Bitcount 연산(개별 개수), Max 연산, Min 연산, Avg 연산, Seq 연산(시계열 데이터), Dimens 연산(차원 분할), Limit 연산(topN/lastN) 외에는 없습니다.

3. Flink는 스트리밍 통계에 사용할 때 결함이 있습니다.

3-1.낮은 자원 활용률

Flink의 낮은 자원 활용도는 두 가지 관점에서 볼 수 있는데, 하나는 클러스터 운영의 토폴로지이고, 다른 하나는 Flink 작업 실행의 특성입니다.

3-2.낮은 컴퓨팅 성능

3-3. 접근 비용이 높다

(1) 플링크는 빅데이터 전문 R&D 인력을 대상으로 하며, 수많은 통계지표를 구현하려면 많은 R&D 비용이 필요하다.
(2) 스트리밍 통계 분야에서 Flink의 기본 기능은 완벽하지 않기 때문에 많은 시나리오에서는 개발자가 통계 작업의 데이터 양, 통계 주기의 세분성 및 데이터 왜곡과 같은 요소를 기반으로 특정 최적화를 수행해야 합니다. . 따라서 Flink는 유사한 기능을 많이 구현하는 데 사용되며 데이터 양과 통계 기간의 차이로 인해 프로그램 구현 방법도 완전히 다를 수 있습니다.

3-4.높은 운영 및 유지 비용과 높은 컴퓨팅 자원 비용

XL-LightHouse와 비교할 때 Flink의 운영 및 유지 관리 비용은 더 높으며 이는 여러 측면에 반영됩니다.
(1) 동일한 스트리밍 통계 요구 사항을 달성하기 위해 Flink 클러스터 크기가 XL-LightHouse보다 훨씬 더 커서 작업이 증가합니다. 그리고 유지비.
(2) Flink 클러스터는 전문 R&D 인력을 지향하므로 Flink 클러스터의 운영은 클러스터 유지관리자와 Flink 업무 R&D 인력이 공동으로 참여하며, 클러스터가 버전 업그레이드, 클러스터 확장, 일일 유지 관리, 데이터 마이그레이션 및 마이그레이션 작업을 수행해야 하는 경우 R&D 담당자와 사전에 소통하고 암묵적인 이해를 해야 합니다. 버전 업그레이드와 유사한 많은 작업에는 관련 작업의 업그레이드 및 변환이 포함됩니다. 클러스터의 규모가 크고, R&D 인력이 참여하고, 관련 작업이 많으면 이 프로세스에는 필연적으로 유지 관리 비용이 많이 듭니다.

4. ClickHouse는 스트리밍 통계에 사용될 때 결함이 있습니다.

  • ClickHouse 적용 시나리오의 특징
    (1) 단일 또는 소수의 응용 시나리오와 각 응용 시나리오에는 엄청난 양의 데이터가 있습니다.
    (2) 비즈니스 시나리오에는 차원 필드가 많아 수십 개로 나누어야 할 수도 있습니다. 또는 수십 개의 필드까지 차원을 결합하여 다차원 임시 쿼리 작업을 수행할 수 있습니다.
    (3) 비즈니스 시나리오에는 자세한 쿼리가 필요합니다.
    (4) 서로 다른 데이터 소스 간의 조인 쿼리에 대한 요구 사항이 있을 수 있습니다.

  • ClickHouse의 단점
    (1) 각 쿼리마다 방대한 양의 데이터를 순회해야 하기 때문에 동시성 지원이 제한적입니다.
    (2) 시스템이 방대한 양의 세부 데이터를 저장하기 때문에 클러스터 크기가 크고 구조가 복잡하며 유지 관리 비용이 많이 듭니다. (3 )
    각 쿼리 각 쿼리는 데이터를 탐색하고 실시간 통계 계산을 수행해야 하며, 이를 위해서는 많은 양의 메모리와 CPU 리소스가 필요합니다. (4)
    데이터 액세스는 높은 임계값을 사용하여 다양한 수준에서 최적화되어야 합니다. (5) 접근
    비용이 높고, 유지 관리 비용이 높으며, 서버 비용이 높고, 사용 기준치가 높으며, 중소 규모에 우호적이지 않습니다. 기업;

5. XL-LightHouse의 특징

(1) 높은 동시 쿼리 통계 결과를 지원할 수 있습니다.

(2) 세부 쿼리는 지원되지 않으며, 세부 쿼리를 지원하려면 다른 도구를 사용해야 합니다.

(3) 세부 쿼리는 지원되지 않으며, 세부 쿼리를 지원하려면 다른 도구를 사용해야 합니다.

6. 응용 시나리오 통계

클릭 수:
1. 5분마다_클릭
2개, 5분마다_각 ICON_클릭
3, 매 시간_클릭
4, 매 시간_각 ICON_클릭
5, 매일_총 클릭
6, 매일_ 각 탭_총 클릭
7, 매일_각 ICON_총 클릭

UV 클릭:
1. 5분마다_UV 클릭
2. 매시간_UV 클릭
3. 매시간_Each ICON_Click UV
4. Every day_Total click UV
5. Every day_Each ICON_Total click UV

성공적인 결제 주문에 대한 통계

주문량 :
1. 10분마다_주문량
2. 10분마다_가맹점별_주문량
3. 10분마다_시도별_주문량
4. 10분마다_도시별_주문량
5. 매시간_주문량
6, 일일 주문량
7, 가맹점별
일일 주문량 8 , 지역별 일일 주문량
9, 도시별 일일 주문량
10, 가격대별 일일 주문량 11,
일일 애플리케이션별 주문량 Scenario_Order Volume

거래금액 :
1. 10분마다_거래금액
2. 10분마다_가맹점_거래금액 상위100
3. 10분마다_시도_거래금액 4.
10분마다_도시_거래금액
5. 매시간_거래금액
6, 시간_가맹점_거래금액
7, 매일_거래금액
8, 매 일_각 가맹점_거래금액 9
, 매일_각 도_거래금액
10, 매일_각 도시_거래금액
11, 매일_가맹점마다 적용시나리오_거래금액

주문 사용자 수:
1. 10분마다_주문 사용자 수
2. 10분마다_가맹점별_주문 사용자 수
3. 10분마다_각 도_주문 사용자 수
4. 10분마다_도시별_시간당 주문 사용자 수
는 5명 시간당 주문자 수는
6명, 일일 주문자 수는
7명, 가맹점별 일일 주문자 수는
8명, 도별 일일 주문자 수는 9명, 일별 주문자 수는 9명이다.
일별 도시별 9명입니다. 주문자 수
일별 10_가격대별 주문자 수_
일별 적용 시나리오_주문자 수 11명

프로젝트 주소:

https://github.com/xl-xueling/xl-lighthouse

https://github.com/xl-xueling/xl-lighthouse.git

https://gitee.com/mirrors/XL-LightHouse.git

참조 문서:

1. 프로젝트 소개
2. Git 주소
3. 커뮤니케이션 커뮤니티
4. 프로젝트 디자인
5. 원클릭 배포
6. XL-Formula 사용
7. 웹서비스 운영안내
8、안녕하세요 세계
9. 적용 가능한 시나리오
10. 저작권 진술
11. 피드백을 활용하라
12. 종속 구성 요소

추천

출처blog.csdn.net/ejinxian/article/details/132775981