StarRocks의 OLAP 요구 사항 사례를 기반으로 항목 가져오기

1. 스타록이란?

• StarRocks를 사용하여 다양한 데이터 분석 시나리오의 초고속 분석을 지원할 수 있는 차세대 초고속 전체 장면 MPP 데이터베이스
• 포괄적인 벡터화 엔진을 사용하고 새롭게 설계된 CBO 옵티마이저를 갖춘 단순한 아키텍처, 쿼리 속도(특히 다중 테이블 연관 쿼리);
• 실시간 데이터 분석을 잘 지원하고 실시간 업데이트 데이터의 효율적인 쿼리를 실현할 수 있으며 쿼리를 더욱 가속화하기 위해 현대적인 구체화된 뷰도 지원합니다.
• 사용자는 대형 와이드 테이블, 스타 모델, 눈송이 모델을 포함한 다양한 모델을 유연하게 구축할 수 있습니다.
• MySQL 프로토콜과 호환되고, 표준 SQL 구문을 지원하고, 사용하기 쉽고, 전체 시스템에 외부 종속성이 없으며, 고가용성, 쉬운 작동 및 유지 관리 관리가 가능합니다.

2. 시스템 아키텍처

 

 

핵심 프로세스: FE(프론트엔드), BE(백엔드).

참고: 모든 노드는 상태를 저장합니다.

• FE(프론트엔드)는 메타데이터 관리, 클라이언트 연결 관리, 쿼리 계획 및 쿼리 일정 수행을 담당합니다.
•      수행원
•               리더: 팔로워는 Paxos와 같은 BDBJE 프로토콜을 통해 리더를 선택하고 모든 트랜잭션 제출은 리더가 시작하고 완료합니다.
•               팔로워: 쿼리 동시성 향상, 투표 참여, 메인 선거 작업 참여.
•      옵저버: 주 선택 작업에 ​​참여하지 않고 비동기식으로 동기화하고 로그만 재생하며 주로 클러스터의 쿼리 동시성 기능을 확장하는 데 사용됩니다.
• BE(Backend)는 데이터 저장 및 SQL 실행을 담당합니다.

3. 스토리지 아키텍처

StarRocks에서 테이블의 데이터는 여러 개의 태블릿으로 분할되고 각 태블릿은 다음 그림과 같이 여러 복사본의 형태로 BE 노드에 저장됩니다.

 

 

테이블 데이터 분할 + 태블릿 3개 사본의 데이터 배포:

 

StarRocks는 Hash 배포 및 Range-Hash 결합 데이터 배포(권장)를 지원합니다.

더 높은 성능을 기다리기 위해서는 Range-Hash의 결합된 데이터 분산, 즉 파티셔닝 후 버킷팅 방식을 사용하는 것이 좋습니다.

• 범위 파티션은 동적으로 추가 및 삭제할 수 있습니다.
• 해시 버킷이 결정되면 조정할 수 없으며 생성되지 않은 파티션만 새 버킷 수를 설정할 수 있습니다.

 

파티셔닝과 버킷팅의 선택은 매우 중요합니다. 테이블을 작성할 때 좋은 파티션과 버킷 열을 선택하면 클러스터의 전체 성능을 효과적으로 향상시킬 수 있습니다.

 

다음은 특수 애플리케이션 시나리오에 대한 파티션 및 버킷 선택에 대한 몇 가지 제안 사항입니다.

• 데이터 편향: 비즈니스 측에서 데이터가 크게 편향되어 있다고 판단하면 데이터 버킷팅을 위해 편도가 큰 열만 사용하는 것보다 여러 열의 조합을 사용하여 버킷팅하는 것이 좋습니다.
• 높은 동시성: 파티셔닝 및 버킷팅은 쿼리 문의 조건을 최대한 포함해야 하므로 스캔 데이터를 효과적으로 줄이고 동시성을 향상시킬 수 있습니다.
• 높은 처리량: 데이터 분할을 시도하고 클러스터가 더 높은 동시성으로 데이터를 스캔하고 해당 계산을 완료하도록 합니다.

‍

3.1 테이블 보관

테이블을 저장할 때 테이블은 두 개의 레이어로 분할되고 버킷화되며 테이블의 데이터는 저장 및 관리를 위해 여러 시스템에 배포됩니다.

 

 

• 파티셔닝 메커니즘: 쿼리 성능을 개선하기 위한 효율적인 필터링.

        파티셔닝은 파티션 키에 따라 테이블을 나누는 테이블 파티셔닝과 유사하며 시간으로 파티션을 나눌 수 있고 데이터 양에 따라 일/월/년으로 나눌 수 있습니다. 적은 수의 액세스에 대해 파티션 프루닝을 사용하거나 데이터의 콜드(cold) 정도에 따라 데이터를 다른 미디어로 나눌 수 있습니다.

• 버킷 공유 메커니즘: 클러스터 성능을 최대한 활용하고 핫스팟 문제를 방지합니다.

             버킷팅 키 Hash를 사용한 후 데이터는 모든 BE에 고르게 분포되며 버킷 데이터가 치우치지 않아야 합니다.버킷 키의 선택 원칙은 높은 카디널리티 열 또는 여러 열을 높은 카디널리티 열로 결합하는 것입니다. 데이터를 충분히.

             참고: 버킷 수는 적당해야 합니다. 성능을 최대한 활용하려면 BE 수 * CPU 코어/2로 설정할 수 있습니다. 태블릿을 약 1GB로 제어하는 ​​것이 가장 좋습니다. 태블릿 수가 너무 적으면 병렬 처리가 충분하지 않을 수 있습니다. 데이터가 너무 많으면 너무 멀리 있을 수 있습니다. 스캔 동시성이 너무 많으면 성능이 저하됩니다.

• 태블릿: 병렬 컴퓨팅 리소스를 유연하게 설정할 수 있는 가장 작은 데이터 논리 단위.

             하나의 테이블은 여러 개의 타블렛으로 나누어져 있으며, StarRocks는 SQL문을 실행할 때 모든 타블렛에 대해 동시 처리를 구현하여 멀티 컴퓨터와 멀티 코어가 제공하는 연산 능력을 최대한 활용할 수 있습니다.

             레플리카 개수는 테이블 생성 시 지정할 수 있으며, 다수의 레플리카를 통해 데이터 저장의 높은 신뢰성과 서비스의 고가용성을 보장할 수 있다.

• 행 집합: 각 데이터 변경에 대해 행 집합이 생성됩니다.

             그룹 열 저장소에 구성된 일부 파일입니다. 각 커밋은 새 버전을 생성하고 각 버전에는 어떤 행 집합이 포함됩니다.

             버전은 작성될 때마다 추가됩니다(단일 파일이든, 수 기가바이트의 스트림 로드가 있는 파일이든).

• Segment: Rowset의 데이터 양이 상대적으로 크면 여러 세그먼트 데이터로 분할되어 디스크가 잘립니다.

 

4. 요구사항 배경

사례 번호 1:

• 사업 배경

표시기 공장 서비스는 주로 비즈니스 직원을 대상으로 하며 비즈니스 표시기의 수집 및 처리를 통해 실시간으로 제품 상태를 반영하고 운영에 대한 데이터 지원을 제공하며 제품 취약성 또는 서비스 이상을 감지하고 표시기 이상 경보 기능을 제공할 수 있습니다.

 

• 비즈니스 시나리오 분석

비즈니스 지표를 묻어두는 방법은 다양하며 특정 방법에 국한되지 않는다. 묻어있는 지점이 명확하고 비즈니스 매개 변수가 풍부하고 데이터가 구문 분석의 기본 요구 사항을 충족하는 한 다음과 같이 사용할 수 있습니다. 데이터 소스는 크게 SDK, MySQL BinLog, 비즈니스 로그, Alibaba Cloud ODPS 데이터 분석으로 나눌 수 있습니다.

기존 과제, 다양한 비즈니스 시나리오 조정이 어려우며 요약된 데이터 특성은 다음과 같습니다.

1. 전체 로그 세부 정보가 필요합니다.
2. 데이터는 항상 최신 상태여야 합니다. 즉, 실시간 업데이트 시나리오를 충족해야 합니다.
3. 데이터는 수준에서 집계되어야 합니다. 즉, 월, 주, 일, 시간 등이 될 수 있습니다.
4. 더 큰 쓰기 볼륨을 전달할 수 있어야 합니다.
5. 각 비즈니스 데이터는 데이터 저장 시간을 유연하게 구성해야 합니다.
6. 데이터 소스의 소스가 많고 보고서의 사용자 정의가 비교적 높으며 여러 데이터 소스가 큰 넓은 테이블에 병합되는 시나리오가 있으며 다중 테이블 연결에 대한 요구 사항도 있습니다.
7. 각종 모니터링 그래프, 보고서 프레젠테이션, 실시간 비즈니스 쿼리 등, 즉 상위 항목은 쿼리가 아닙니다.

 

• 스타록스를 소개합니다

다행히 StarRocks는 위의 모든 비즈니스 시나리오, 즉 세부 모델, 업데이트 모델, 집계 모델, 기본 키 모델의 요구를 충족하는 비교적 풍부한 데이터 모델을 가지고 있으며 큰 넓은 테이블 대신 더 유연한 스타 모델을 선택합니다. 즉, 다중 테이블 연결을 사용하여 직접 쿼리합니다.

 

• 상세 모델:

1. 매장 포인트 데이터는 세부 사항에 따라 전체 구조화 및 저장됩니다.
2. 이 시나리오는 데이터 볼륨이 1억일 때 DB의 쿼리 성능에 대한 요구 사항이 더 높습니다.
3. 데이터는 동적 파티션을 구성하여 만료 정책을 구성할 수 있습니다.
4. 시나리오를 사용하는 경우 온라인 집계 쿼리를 위해 구조화된 데이터에서 개별 필드 차원을 선택합니다.

 

• 집계 모델:

1. 매몰점 데이터의 양이 방대하고 세부 데이터는 추적성이 필요하지 않으며 PV 및 UV 시나리오와 같은 집계 계산이 직접 수행됩니다.
2. 동적 파티션을 구성하여 만료 정책으로 데이터를 구성할 수 있습니다.

 

• 모델 업데이트:

1. 매몰 포인트 데이터의 상태가 변경되고 데이터를 실시간으로 업데이트해야 합니다.업데이트된 데이터 범위는 주문, 쿠폰 상태 등과 같은 여러 파티션에 걸쳐 있지 않습니다.
2. 동적 파티션을 구성하여 만료 정책으로 데이터를 구성할 수 있습니다.

 

위의 비즈니스 시나리오 분석을 기반으로 이 세 가지 모델은 데이터 문제를 완벽하게 해결할 수 있습니다.

 

실시간 데이터 쓰기가 필요한 경우에도 업계에서 널리 사용되는 솔루션, 즉 데이터를 Kafka에 수집한 후 Flink를 사용하여 StarRocks에 실시간 쓰기를 수행하는 솔루션을 따릅니다. StarRocks는 매우 유용한 Flink-connector 플러그인을 제공합니다.

 

 

작은 팁:

1. StarRocks는 쓰기 성능을 아주 잘 최적화 시켰지만 쓰기 압력이 높으면 쓰기 거부가 계속 발생합니다. 한 번에 가져오는 데이터의 양을 늘리고 빈도를 줄이는 것이 좋습니다. 데이터 저장 지연 증가. 따라서 이익을 극대화하려면 특정 절충안이 필요합니다.

2. Flink의 싱크 측을 너무 크게 구성하면 너무 많은 동시 트랜잭션이 오류를 보고할 수 있으므로 각 flink 작업 소스를 더 많이 구성할 수 있고 싱크 연결 수가 너무 많아서는 안 됩니다. .

 

• 요약

클러스터 크기: 5 FE(8c32GB), 5 BE(32c128GB)

현재 이 솔루션은 수십 개의 대규모 지표 표시 및 경보, 데이터 저장 테라바이트, 수백 기가바이트의 일일 순 증가 및 전반적으로 안정적인 운영을 포함하는 수백 개의 비즈니스 지표에 대한 액세스를 지원했습니다.

 

사례 2:

• 사업 배경

내부 시스템 비즈니스 간판은 주로 회사 전체의 직원에게 서비스를 제공하며 프로젝트 및 작업 추적과 같은 기능을 제공합니다.

• 비즈니스 시나리오 분석

비즈니스 특성 분석:

1. 데이터가 자주 변경(업데이트)되고 변경 시간 범위가 깁니다.
2. 쿼리 시간 범위
3. 보고서는 실시간으로 업데이트되어야 합니다.
4. 관련 차원 테이블 쿼리, 부서/사업부/자원 도메인 등이 많이 있습니다.
5. 핫 및 콜드 데이터, 최근 데이터 쿼리가 빈번함

 

• 역사적 아키텍처 및 문제점

초기 데이터베이스 선택 시 비즈니스 특성과 결합하여 사용자가 자신의 작업을 동적이고 유연하게 추가 및 삭제해야 하므로 애플리케이션 코드와 스토리지 계층 간의 임피던스를 줄이기 위해 JOSN 모델을 선택하고 MongoDB를 선택합니다. 데이터 저장고.

 

회사의 신속한 제공으로 보고서 표시가 필요한 경우, 특히 시간 범위가 상대적으로 크고 여러 부서, 다차원, 세분화 및 기타 보고서 표시가 포함되는 경우 MongoDB에서 쿼리 시간을 실행해야 합니다. 10초 이상.

 

• 스타록스를 소개합니다

분석 데이터베이스가 우수한 StarRocks와 ClickHouse를 조사해 보았는데, 모델을 선택할 때 주로 단일 테이블 집계 쿼리, 다중 테이블 연관 쿼리, 실시간 업데이트 읽기-쓰기 쿼리를 중심으로 비즈니스 응용 시나리오를 분석했습니다. 차원 테이블은 수시로 업데이트되는데, 즉 MySQL에 저장되는데, StarRocks는 외관 관련 쿼리를 더 잘 지원하여 개발의 어려움을 크게 줄여줍니다.결국 StarRocks를 스토리지 엔진으로 사용하기로 결정했습니다.

 

변환 단계에서 원본 MongoDB의 컬렉션은 세 개의 테이블로 분할됩니다. 상세 모델을 이용하여 해당 인원의 업무 정보를 매일 기록하고, 이전의 1인 1인 1레코드부터 이벤트 단위까지 1인 1일 단위로 나누어서 1인이 하루에 여러 개의 기록을 가질 수 있습니다.

 

자주 업데이트되는 차원 테이블을 구현하려면 외부 테이블을 사용하여 차원 데이터를 StarRocks에 동기화하는 복잡성을 줄이십시오. \

 

• 요약

변환 전에는 MongoDB 쿼리가 복잡하고 여러 번 쿼리되었습니다.

db.time_note_new.aggregate(
    [
       {'$unwind': '$depart'},
       {'$match': {
           'depart': {'$in': ['部门id']},
           'workday': {'$gte': 1609430400, '$lt': 1646064000},
           'content.id': {'$in': ['事项id']}, 
           'vacate_state': {'$in': [0, 1]}}
       }, 
       {'$group': { 
           '_id': '$depart', 
           'write_hour': {'$sum': '$write_hour'}, 
           'code_count': {'$sum': '$code_count'}, 
           'all_hour': {'$sum': '$all_hour'}, 
           'count_day_user': {'$sum': {'$cond': [{'$eq': ['$vacate_state', 0]}, 1, 0]}}, 
           'vacate_hour': {'$sum': {'$cond': [{'$eq': ['$vacate_state', 0]}, '$all_hour', 0]}}, 
           'vacate_write_hour': {'$sum': {'$cond': [{'$eq': ['$vacate_state', 0]}, '$write_hour', 0]}}}
           -- ... more field
       }, 
       {'$project': {
           '_id': 1, 
           'write_hour': {'$cond': [{'$eq': ['$count_day_user', 0]}, 0, {'$divide': ['$vacate_write_hour', '$count_day_user']}]}, 
           'count_day_user': 1, 
           'vacate_hour': 1, 
           'vacate_write_hour': 1, 
           'code_count': {'$cond': [{'$eq': ['$count_day_user', 0]}, 0, {'$divide': ['$code_count', '$count_day_user']}]}, 
           'all_hour': {'$cond': [{'$eq': ['$count_day_user', 0]}, 0, {'$divide': ['$vacate_hour', '$count_day_user']}]}}
           -- ... more field
       }
    ]
)

변환 후 SQL과 직접 호환되며 한 번에 집계할 수 있습니다.

WITH cont_time as (
    SELECT b.depart_id, a.user_id, a.workday, a.content_id, a.vacate_state
        min(a.content_second)/3600 AS content_hour,
        min(a.write_second)/3600 AS write_hour,
        min(a.all_second)/3600 AS all_hour
    FROM time_note_report AS a
    JOIN user_department AS b ON a.user_id = b.user_id
    -- 更多维表关联
    WHERE b.depart_id IN (?)  AND a.content_id IN (?) 
      AND a.workday >= '2021-01-01' AND a.workday < '2022-03-31' 
      AND a.vacate_state IN (0, 1)
    GROUP BY b.depart_id, a.user_id, a.workday, a.content_id,a.vacate_state
)
SELECT M.*, N.*
FROM ( 
    SELECT t.depart_id,
         SUM(IF(t.content_id = 14, t.content_hour, 0))   AS content_hour_14,
         SUM(IF(t.content_id = 46, t.content_hour, 0))   AS content_hour_46,
         -- ...more
    FROM cont_time t
    GROUP BY t.depart_id
) M
JOIN ( 
    SELECT depart_id                                  AS join_depart_id,
      SUM(write_hour)                                 AS write_hour,
      SUM(all_hour)                                   AS all_hour
      -- 更多指标
    FROM cont_time
    GROUP BY depart_id
) N ON M.depart_id = N.join_depart_id
ORDER BY depart_id ASC

쿼리 보고서에서 2021/01/01~2022/03/01 사이의 데이터를 비교하려면:

• StarRocks: 295ms가 소요되는 복잡한 SQL 집계 함수를 통해 완전히 계산할 수 있는 쿼리 집계 1개
• Mongodb: 2개의 쿼리 + 계산으로 나누어야 하며, 총 3초+9초=12초가 걸립니다.

 

5. 경험 공유

StarRocks를 사용할 때 발생하는 몇 가지 오류 및 해결 방법(온라인 정보가 적은 오류 정보):

 

a. 데이터 가져오기 스트림 로드 오류: "db 13003에서 현재 실행 중인 txns는 100이며 제한 100보다 큽니다."

원인: 데이타베이스당 실행 중인 가져오기 작업의 최대 수를 초과했습니다. 기본값은 100입니다. 가져오기당 작업 수는 max_running_txn_num_per_db 매개변수를 조정하여, 가급적이면 작업 제출 일괄 처리를 조정하여 늘릴 수 있습니다. 즉, 일괄 처리를 저장하고 동시성을 줄이는 것입니다.

 

b.  FE에서 오류 보고: "java.io.FileNotFoundException: /proc/net/snmp(열린 파일이 너무 많음)"

이유: 불충분한 파일 핸들 여기에서 감독자가 프로세스를 관리하는 경우 파일 핸들의 구성을 fe의 시작 스크립트에 추가해야 합니다.

if [[ $(ulimit -n) -lt 60000 ]]; then
  ulimit -n 65535
fi

 

c.  StarRocks는 Java 언어를 사용하여 사용자 정의 함수 UDF를 작성하는 것을 지원하며 실행 함수에서 오류가 보고됩니다: "rpc failed, host: xxxx", 그리고 오류가 be.out 로그에 보고됩니다:

start time: Tue Aug 9 19:05:14 CST 2022
Error occurred during initialization of VM
java/lang/NoClassDefFoundError: java/lang/Object

이유: 수퍼바이저를 사용하여 프로세스를 관리할 때 JAVA_HOME 환경 변수를 늘리는 데 주의해야 합니다. BE 노드에서도 Java의 일부 기능을 호출해야 하며 BE 시작 스크립트에 JAVA_HOME 환경 변수 구성을 직접 추가할 수 있습니다. .

 

d.  삭제 작업이 실행될 때 다음 오류가 보고됩니다.

SQL > delete from tableName partition (p20220809,p20220810) where `c_time` > '2022-08-09 15:20:00' and `c_time` < '2022-08-10 15:20:00';
ERROR 1064 (HY000): Where clause only supports compound predicate, binary predicate, is_null predicate and in predicate

이유: 현재 삭제 후 where 조건은 사이 및 연산을 지원하지 않으며 현재는 =, >, >=, <, <=, !=, IN, NOT IN만 지원합니다.

 

e.  Routine Load를 사용하여 kakfa 데이터를 소비할 때 많은 수의 임의의 group_id가 생성됩니다.

제안: 루틴 로드를 빌드할 때 그룹 이름을 지정하십시오.

 

f.  StarRocks 연결 시간이 초과되었고 쿼리 문에서 "ERROR 1064(HY000): scanNode Backend가 없습니다" 오류를 보고했습니다. BE 노드를 다시 시작한 후 잠시 복구되었습니다. 로그 오류는 다음과 같습니다.

kafka log-4-FAIL, event: [thrd:x.x.x.x:9092/bootstrap]: x.x.x.x:9092/1: ApiVersionRequest failed: Local: Timed out: probably due to broker version < 0.10 (see api.version.request configuration) (after 10009ms in state APIVERSION_QUERY)

이유: kafka에 연결하는 루틴 로드에 문제가 있는 경우 BrpcWorker 스레드가 고갈되어 StarRocks에 대한 정상적인 액세스에 영향을 줍니다. 임시 해결책은 문제가 있는 작업을 찾아 작업을 일시 중단하고 다시 시작하는 것입니다.

 

6. 미래 계획

다음으로 기존 OLAP 쿼리 엔진을 대체하기 위해 더 많은 서비스를 StarRocks에 연결하고 더 많은 비즈니스 시나리오를 사용하여 경험을 축적하고 클러스터 안정성을 개선할 것입니다. 앞으로 StarRocks가 기본 키 모델의 메모리 사용량을 최적화 및 늘리고, 일부 열을 업데이트하는 보다 유연한 방법을 지원하고, Bitmap 쿼리 성능을 지속적으로 최적화 및 개선하고, 다중 테넌트 리소스 격리를 최적화하기를 바랍니다. 앞으로도 스타록 커뮤니티 토론회에 적극적으로 참여하여 비즈니스 시나리오에 대한 피드백을 제공할 예정입니다.

 

 

*텍스트 /선루이

 Dewu Technology에 주목하고 매주 월요일, 수요일, 금요일 밤 18:30에 기술 건조물을 업데이트합니다.

글이 도움이 되셨다면 공감, 댓글, 좋아요 부탁드립니다~

 

{{o.name}}

{{m.name}}