데이터가 미래를 주도합니다. 빅 데이터 생태계에서 데이터 분석 시스템은 데이터 생성 과정에서 매우 중요한 역할을하여 비즈니스 의사 결정의 효율성과 품질에 직접적인 영향을 미칩니다. 대용량 빅 데이터의 신속한 분석을 지원하는 MPP 데이터베이스 인 Apache Doris는 데이터 분석 분야에서 단순성, 사용 용이성 및 고성능이라는 장점을 가지고 있습니다.
9 월 20 일 아파치 도리스는 온라인 밋업을 조직했고, 취업 도우미가 참여하도록 초청 받았으며, "도리스 in the job help 실시간 데이터웨어 하우스 응용 및 실습"테마 공유를 가져 왔습니다.
현장에서 본질 공유
여러분 좋은 오후입니다. 숙제의 실시간 데이터웨어 하우스에서 도리스의 적용과 실습을 소개하겠습니다.
이 공유는 주로 세 가지 테마로 나뉩니다.
1. 첫째, 팀의 사업 및 배경 소개
2. 다음으로 도리스 기반의 질의 시스템과 작업 도움말이 어떻게 구축되는지, 그리고 그것이 해결하는 주요 문제를 소개하겠습니다.
3. 향후 계획
우리 팀은 숙제 빅 데이터 팀으로, 회사의 디지털웨어 하우스 구축을 주로 담당하고 있으며, 수업 시간, 응답 상태 및 기타 비즈니스 데이터와 같은 비즈니스 중심 데이터 정보를 각 제품 라인에 제공하고 다음과 같은 교통 데이터를 제공합니다. pv, uv 및 활동, 신규, 교육 및 BI와 같은 많은 중요한 비즈니스 라인에 서비스를 제공합니다.
데이터웨어 하우스 시스템에서 빅 데이터 팀은 주로 ODS-DWS 구축을 담당하며, DWS에서 ADS까지 일반적으로 데이터웨어 하우스 시스템과 비즈니스 라인 시스템의 경계입니다.
과거에는 효과적이고 통합 된 쿼리 시스템이 부족하여 다양한 비즈니스 라인의 개발을 지원하기 위해 많은 모델을 탐색했습니다.
일부 비즈니스 라인은 빅 데이터 관련 기술을 더 잘 이해하고 스파크와 같은 컴퓨팅 시스템에 익숙하며 스스로 계산을 처리 할 수 있습니다. 따라서 Kafka는 데이터를받은 후 스파크 컴퓨팅 모델을 사용하여 빅 데이터 팀에 연결하지만 다른 비즈니스 라인은이 기술 스택에 익숙하지 않을 수 있으므로이 솔루션의 주요 문제를 다른 비즈니스 라인에 복제 할 수 없습니다. 또한 Spark 클러스터는 여러 비즈니스 라인에서 사용되므로 그 자체로 비즈니스 라인에 추가 유지 관리 비용이 발생합니다.
Kafka + Spark 모델은 널리 홍보 할 수 없기 때문에 ES 기반 솔루션, 즉 빅 데이터가 ES에 데이터를 쓴 다음 기업이 ES에 직접 액세스하여 데이터를 얻지 만, 한편으로는 높은 성능의 ES를 사용합니다. 비용이 많이 들고 ES에 매우 익숙합니다. 비즈니스 라인이이를 수행하는 에너지를 갖기 어렵습니다. 둘째, ES를 사용하는 시스템의 품질이 고르지 않아 파괴 문제가 발생합니다. ES 클러스터가 가끔 발생합니다. 안정성도 제어 할 수 없습니다. 마지막으로 ES-Sql 구문이 부족하여 조인, 다중 열 그룹 별 (버전 6.3) 등을 지원하지 않습니다.
따라서 우리는 안정성 측면에서 더 나은 솔루션을 기대하면서 API 인터페이스 개발을 모색하고 있습니다. API는 제어가 가능하지만 API가 Sql 기능을 제공하지 않기 때문에 수요 시나리오를 기반으로 한 지속적인 API 개발이 전달 효율성에 영향을 미치는 주요 병목 현상이되었습니다.
위의 대부분은 세부 데이터 쿼리를 지원합니다. pv, uv와 같은 대규모 트래픽 쿼리가 포함되면 druid 시스템을 도입해야하지만 duird의 인터페이스는 다른 시스템의 인터페이스와 일치하지 않으며 사용자는 다시 배우기 위해 Druid는 Details를 지원하지 않습니다. 일단 세부 정보가 필요하면 ES로 이동하여 쿼리해야합니다. 두 시스템이 관련되어 있기 때문에 때로는 세부 데이터와 집계 데이터의 불일치를 처리해야합니다.
수요가 증가함에 따라 시스템 유지 관리가 점점 더 어려워지고 배달 효율성이 특히 낮으며 수요 대기열이 매우 심각합니다.
따라서 효율적이고 통합 된 쿼리 시스템을 제공하는 것은 비즈니스 지원 효율성을 향상시키고 유지 관리 비용을 절감하는 데있어 실시간 데이터웨어 하우스 구축에 매우 중요합니다.
수개월 간의 탐구와 실습 끝에 도리스를 기반으로 한 실시간 쿼리 시스템을 구축했습니다. 동시에 전체 실시간 데이터웨어 하우스의 데이터 컴퓨팅 시스템의 대대적 인 재구성이 이루어졌으며 최종 전체 아키텍처 다이어그램은 다음과 같습니다.
그림과 같이 (아래에서 위로) 원본 비즈니스 계층 로그는 데이터 수집 시스템을 통해 데이터웨어 하우스에 입력됩니다. 데이터 정리 계산 계층에서는 원본 Spark 시스템을 Flink로 업그레이드하고 Flink 기반의 통합 데이터를 제공했습니다. -Sql 개발 프레임 워크는 데이터 연구 및 개발의 효율성을 향상시키기 위해 원래 코드 개발에서 Sql 개발로 업그레이드되었습니다.
이후 쿼리 시스템은 실시간으로 Kafka 데이터를 쿼리 엔진에 동기화하고 OpenAPI의 통합 인터페이스를 통해 외부 쿼리 서비스를 제공합니다.
Doris 기반 쿼리 시스템이 출시 된 후 우리는 과거와 같이 프로그램 연구, 인터페이스 개발, 공동 디버깅 테스트를 할 필요가 없었습니다. 이제 데이터가 기록되는 한 비즈니스는 계층은 SQL을 기반으로 데이터 쿼리 및 비즈니스 개발을 완료 할 수 있으며, 전달 효율성 (읽을 수있는 서비스를 제공하기 위해 계산 된 데이터)은 지난 몇 주에서 시간당 수준으로 가속화되었습니다.
성능면에서는 ES 나 mysql 기반이었는데, 조회 할 데이터의 양이 많을 때는 수십 시간에서 몇 분 정도의 지연 만 견딜 수있었습니다. Doris 솔루션을 기반으로 몇 분 또는 몇 초.
Doris의 전체 아키텍처는 매우 간단하고 타사 구성 요소에 의존하지 않으며 커뮤니티 지원도 매우 훌륭합니다. 출시부터 오늘까지 가벼운 작동 및 유지 관리 사양 만 작성하면 높은 안정성을 보장 할 수 있습니다.
따라서 도리스 도입을 통해 작업 도우미에서 실시간 데이터웨어 하우스 쿼리의 느린 전달과 느린 쿼리의 문제점이 해결되었으며, 이는 후속 데이터웨어 하우스 시스템의 개발에서 매우 중요한 역할을했습니다.
다음으로 쿼리 시스템의 작업에 중점을 둡니다.
쿼리 시스템 아키텍처 선택 및 원리, 응용 및 실습의 두 부분으로 나뉩니다.
쿼리 엔진에 대해 이야기하기 전에 비즈니스 시나리오에 대해 이야기 해 보겠습니다.
직업 도움말에는 두 가지 주요 비즈니스 시나리오가 있습니다.
하나는 pv, uv, active ...와 같은 전통적인 트래픽 유형입니다. 작업 도움말에서 많은 경우에 더 자세한 정보를 확인해야합니다.
예를 들어, 하루 중 각 시간에 숙제 앱의 활성 사용자 수는 각 시간에 각 숙제 앱 버전의 활성 사용자 수에 따라 다릅니다.
두 번째 유형은 가르치는 교사와 같은 비즈니스 라인을위한 작업대입니다.
예를 들어, 선생님이 수업을 마치면 수업에 참여하는 학생들의 출석 데이터와 교실 테스트 데이터를 살펴볼 것입니다.
이 두 시나리오에서 연구 비용, 팀 기술 생태학, 유지 관리 비용 및 기타 요인을 고려하여 마침내 Doris를 쿼리 엔진으로 선택했습니다. 주로 Doris는 위의 두 가지 시나리오에서 비즈니스 요구를 일관되게 충족 할 수 있습니다.
먼저 도리스를 소개합니다.
Doris는 mpp 아키텍처의 쿼리 엔진입니다.
전체 아키텍처는 매우 간단합니다. FE와 BE의 두 가지 서비스 만 있습니다. FE는 Sql 분석, 계획 및 메타 데이터 저장을 담당하고 BE는 Sql-Plan 실행 및 데이터 저장을 담당합니다. 전체 작업은 어떤 것에 의존하지 않습니다. 타사 시스템 및 기능도 매우 풍부합니다. 풍부한 데이터 업데이트 모델, Mysql 프로토콜, 지능형 라우팅 등을 지원합니다. 비즈니스 라인 배포, 운영 및 유지 관리에 매우 친숙합니다.
다음으로 앞서 언급 한 비즈니스 시나리오의 문제를 해결하기 위해 Doris를 사용하는 방법에 대해 이야기 해 보겠습니다.
Doris에는 다양한 데이터 모델이 있으며 집계 모델은 교통 시나리오에서 일반적으로 사용됩니다. 예를 들어 앞서 언급 한 시나리오의 경우 작업 도우미 앱의 각 버전에 대한 자세한 데이터를 기본 테이블에 저장합니다. 데이터 행이 더 많기 때문에 기본 테이블에서 직접 크로스 데이 집계 데이터를 읽으면 지연 문제가 나타날 수 있으므로 일반적으로 사용되는 일 수준 데이터를 롤업하여 사전 집계를 통해 쿼리 할 데이터 양을 줄이고 쿼리 대기 시간을 가속화 할 수 있습니다.
Doris의 집계 모델을 효율적으로 사용하기 위해서는 키 컬럼을 기준으로 데이터 행을 필터링하는 것이 전제입니다. 값 컬럼을 사용하는 경우 Doris는 결과 집합에 속하는지 여부를 결정하기 전에 모든 관련 행을 집계해야하므로 효율성이 상대적으로 높습니다. 낮은.
교육 및 연구 워크 벤치의 경우 앞서 언급 한 필터링이 값을 기반으로하므로 Doris on ES 모델이 사용됩니다. 주요 고려 사항은 ES 열을 검색하는 기능을 사용하여 쿼리 속도를 높일 수 있다는 것입니다.
실무에서 Doris on ES가 ES 또는 Presto on ES와 같은 다른 커뮤니티 솔루션을 직접 사용하는 것에 비해 성능이 크게 향상되었음을 발견했습니다. 다음으로 Doris on ES의 고성능 설계 원칙을 소개합니다.
ES에서 Doris의 전체 아키텍처가 그림에 나와 있습니다. FE는 위치, 샤드 등의 ES 메타 데이터 정보를 쿼리하고 BE는 ES 데이터 노드에서 데이터를 검색하는 역할을합니다.
Doris on ES는 고성능을 제공합니다. 베어 ES와 비교하여 몇 가지 최적화 지점이 있습니다.
ES를 거의 사용하지 않는 경우 ES는 Query then Fetch 모델을 사용합니다. 예를 들어 1000 개의 문서가 요청되면 ES에는 10 개의 샤드가 있습니다. 이때 각 샤드는 1000 개의 문서 ID를 조정에 반환 한 다음 조정 노드는 실제로 10 개를 얻습니다. * 1000 문서 ID를 선택한 다음 1000을 선택합니다. 실제로 각 샤드는 900 개를 더 반환합니다.
ES의 Doris는 조정 노드를 우회하고 데이터 노드를 직접 운영합니다. 너무 많은 docid가 반환되지 않도록 각 데이터 노드에서 예상되는 docid를 쿼리합니다.
둘째, Doris는 ES에서 데이터를 스캔 할 때 많은 최적화를 수행했습니다. 예를 들어, 스캐닝 속도 측면에서 순차 스캐닝, 컬럼 저장 최적화, 술어 푸시 다운 등이 사용됩니다. 데이터가 ES에서 Doris로 전송 될 때 근접 원칙이 채택됩니다. 예를 들어 BE는 액세스에 우선 순위를 부여합니다. 기계의 데이터 노드, 사용하지 않는 필드를 필터링하는 소스 필터 등. 전송 속도를 높이기 위해.
우리의 연구에서 ES에서 Doris의 성능은 ES에서 Presto보다 수십 배 더 빠릅니다.
작업 도움말에서는 위에서 설명한 Doris 데이터 모델을 기반으로 한 기본 응용 프로그램 외에도 비즈니스를 완벽하게 지원하고 안정성을 보장하며 효율성을 향상시키기 위해 다른 주변 시스템 구성도 필요합니다.
다음으로 Doris 기반 작업 도움말 쿼리 시스템 아키텍처의 전체 디자인 및 작업 모드를 소개합니다.
이것은 작업 도움말 쿼리 시스템의 전체 아키텍처입니다.
위에서 아래로, 첫 번째는 주로 각 장면의 인간 효율성을 향상시키기 위해 다양한보고 플랫폼, 메타 데이터 관리 플랫폼 등을 포함한 우리의 플랫폼입니다.
아래의 빨간색 부분은 통합 API 인터페이스 계층입니다. 여기서는 주로 시스템 간의 도킹 비용을 줄이기 위해 요청 응답 방법 및 반환 코드와 같은 API 사양을 공식화합니다.
API 기반의 주요 읽기-쓰기 인터페이스를 제공하는 것 외에도 메타 데이터 관리, 스케줄링 시스템 등과 같은 주변 서비스 구성도 포함합니다.
다음으로 전체 프로세스를 기반으로 시스템의 각 부분을 소개합니다.
첫 번째는 메타 데이터입니다. Doris는 mysql 문법을 기반으로 테이블을 작성하고 이미 메타 데이터가 있습니다. 여기에 메타 데이터에 대한 몇 가지 추가 고려 사항이 있습니다.
첫 번째는 쿼리 성능을 보장하는 것입니다. 테이블을 생성 할 때 테이블이 잘못 구성되면 쿼리 성능이 매우 저하됩니다. 예를 들어 ES의 인덱스 매핑에서 docvalue가 꺼져 있거나 열 저장 모드가 Doris 테이블이 활성화되어 있지 않으면 쿼리가 행으로 저하되고 저장 모드에서는 성능이 상대적으로 낮기 때문에 성능을 최대화하려면 테이블 생성 프로세스를 완전히 자동화하고 표준화해야합니다. 이것은 그들 중 하나입니다.
Doris의 자체 저장소에는 문자열 길이와 같은 강력한 스키마 제약 조건이 적용됩니다. 그러나 ES에는 명확한 길이 제약이 없습니다. 키워드 유형 필드의 경우 128B 또는 256B 쓰기는 성공할 수 있지만 문제가 발생합니다. es 테이블이 Doris 테이블과 동기화되면 동기화 성공률을 보장 할 수 없습니다. … 또한 Doris 테이블에서 선언 한 유형 (예 : bigint)과 ES 인덱스의 유형 (예 : 키워드)이 일치하지 않으면 Sql도 실패합니다. 따라서 이러한 문제를 피하기 위해서는 통합 데이터 모델을 구축해야합니다.
셋째 : 사용 효율성. 우리가 사용하는 과정에서 테이블을 생성, 삭제, 수정하는 것은 일반적인 작업입니다. 다양한 비즈니스 라인 (Doris를 알든 모르 든)의 학생들이 테이블을 빠르게 생성 할 수 있도록하기위한 통합 메타 데이터이자 통합 모델이기도합니다. 재단.
마지막으로, 우리의 전체 컴퓨팅 시스템도 flink-sql로 재구성되고 있다고 이전에 언급했습니다. flink-sql은 kafka의 테이블, redis의 테이블과 같은 메타 데이터에 크게 의존합니다.
메타 데이터를 통합하고 데이터 모델을 통합하려면 전체 데이터 테이블의 구조를 추상화하여 서로 다른 저장소에있는 테이블을 관리해야합니다. 기본 단위로 env, db, table을 기반으로 테이블을 관리합니다. 데이터베이스와 테이블은 비교적 친숙합니다. env is 우리가 소개 한 새로운 네임 스페이스는 주로 Baidu Cloud의 데이터웨어 하우스 클러스터 및 Tencent Cloud의 데이터웨어 하우스 클러스터와 같은 다양한 클러스터 / 비즈니스 라인의 정의를 제공하는 데 사용됩니다. 테이블 단위는 주로 필드 (열 유형, 값 범위)를 포함합니다. ), 인덱스 (예 : 롤업, 비트 맵 인덱스 등), 스토리지 (스토리지 속성).
컬럼 속성은 주로 표준화 된 타입 시스템이며, json-schema는 풍부한 검증 규칙과 강력한 설명 기능을 가지고 있다는 점을 감안할 때 json-schema를 사용하여 컬럼 값에 대한 제약을 통합합니다.
데이터 유형의 경우 공개 데이터 유형과 개인 데이터 유형을 설계했습니다. varchar, int 등과 같은 공용 클래스에는 서로 다른 스토리지 시스템에서 해당 구현이 있으며 Doris :: bitmap과 같은 개인 유형도 지원되어 개인 시스템의 호환성 및 확장을 용이하게합니다. 이 모드를 통해 각 스토리지 시스템을 기반으로 한 테이블을 균일하게 관리 할 수 있습니다.
이것은 우리 라인의 실제 시계입니다. 여기에는 열 정보와 해당 스토리지 구성이 포함됩니다.
왼쪽의 빨간색 세로 상자는 값 범위를 정규화하기위한 json-schema에 대한 설명입니다. 가로 빨간색 상자는 docid 및 데이터 업데이트 시간과 같은 ES 테이블의 일부 메타 필드입니다. 이러한 필드는 데이터 문제를 쉽게 추적하고 데이터를 필터링하는 데 사용할 수 있습니다.
데이터 모델을 통합했기 때문에 이러한 메타 필드를 모든 테이블에 대해 균일하게 설정하는 것이 매우 편리합니다.
메타 데이터의 통합 관리를 통해 구성된 테이블의 품질이 매우 높습니다. 모든 테이블은 성능을 극대화하기 위해 쿼리 서비스를 제공하고 있으며 데이터로 인한 쿼리 사용 불가 사례는 0입니다. 그리고 Doris를 알고 있든 모르 든 모든 비즈니스 라인의 학생들을 위해 이러한 고품질 테이블을 몇 분만에 만들 수 있습니다.
테이블이 빌드 된 후 데이터를 쓰고 읽습니다. 통합은 openapi를 기반으로합니다.
실제로 api 인터페이스는 기본적으로 시스템 기능을 제공한다는 전제하에 시스템의 안정성과 사용 편의성을 더욱 보장하는 것입니다.
예를 들어, 비즈니스 라인의 오용을 제어하고 (예 : 연결 수가 가득 찬 경우) 통합 항목을 제공하여 es, Doris를 작성하고 데이터 품질을 제어해야합니다.
먼저 데이터 쓰기 인터페이스를 소개합니다.
테이블 모델이 통합됨에 따라 통합 쓰기 인터페이스 프로토콜을 쉽게 제공 할 수 있습니다. 또한 사용자는 실제 테이블의 스토리지가 es인지 Doris인지, 이기종 시스템을 처리하는 시스템인지에주의를 기울일 필요가 없습니다.
둘째, 쓰기 인터페이스가 통합되면 데이터의 크기, 종류 등 쓰기 데이터를 균일하게 확인할 수있어 쓰기의 품질과 정확성을 보장 할 수있다. 이것은 데이터의 2 차 처리에 매우 중요합니다.
셋째, 데이터 버전과 같은 키워드가 액세스 프로토콜에 추가됩니다. 데이터 장애 문제를 해결하고 통합 쓰기 모니터링을 구축 할 수 있습니다. 다음 그림은 전체 쓰기 데이터 스트림의 qps와 엔드-투-엔드 (데이터 쓰기 저장 시간 및 데이터 생성 시간) 지연 Quantile 값을 보여 주며, 이는 시스템의 관찰 가능성과 화이트 박스를 향상시킬 수 있습니다.
다음으로 작가가 무질서 문제를 어떻게 해결하는지 구체적인 시나리오에 대해 이야기 해 봅시다.
정상적인 상황에서 실시간 데이터 스트림은 flink 또는 spark에 의해 계산 된 다음 kafka에 기록 된 다음 쿼리 시스템에 의해 Doris / es에 동기화됩니다.
데이터를 수정해야 할 때 직접 쓰면 같은 키의 데이터를 덮어 쓰게되므로 순서대로 데이터를 덮어 쓰지 않도록 실시간 스트림을 중지해야합니다. 데이터 적시성이 손상됩니다.
따라서 쓰기 측면을 기반으로 개선했습니다. 실시간 데이터 스트림과 오프라인 복구 데이터 스트림은 서로 다른 주제에 기록됩니다. 동기화 서비스는 각 주제의 소비를 제한합니다. 예를 들어, 실시간 스트림은 높은 적시성 및 할당량을 더 크게 조정할 수 있습니다., 보장 할당량, 오프라인 적시성은 할당량을 줄이거 나 비즈니스의 낮은 피크 기간 동안 할당량을 늘릴 수 있으며 데이터 키 및 열 버전 저장소를 기준으로 필터링합니다. 이러한 방식으로 적시성을 보장한다는 전제하에 예상대로 숫자를 수정할 수 있습니다.
마지막 부분은 읽기 부분입니다.
SQL 기능 제공을 전제로 캐싱 및 통합 시스템 구성과 같은 몇 가지 추가 솔루션도 만들었습니다. 시스템 지연 및 안정성이 크게 개선되었습니다. 그리고 통합 된 읽기 인터페이스로 인해 위에서 언급 한 변환은 비즈니스 라인에 투명합니다.
기존 조건에서 지연 시간이 짧은 읽기 외에도 처리량 지향 읽기를위한 시나리오 클래스도 있습니다.
예를 들어 특정 부서 (각 교사)에 속한 학생의 수업 상태 (수업 수, 수업 시간 등)를 세고 싶은 장면을 소개합니다.
과거에는 이러한 문제를 해결하기 위해 spark / flink를 사용했습니다. 예를 들어 spark는 Kafka에서 수업 데이터를 사용합니다. 각 데이터에 대해 redis로 이동하여 교사 정보를 쿼리하여 차원을 완성합니다.
일반적으로 수업 데이터가 도착하면 교사 정보가 준비되어 있으므로 문제 없습니다. 그러나 차원 스트림의 늦게 도착, 저장 쿼리 실패 등과 같은 비정상적인 상황에서, 클래스 스트림이 도착하면 해당 교사 정보를 얻을 수 없으며, 그에 대한 통계와 같은 관련 차원은 부서를 계산할 수 없습니다.
과거에는 이러한 상황에 직면했을 때 이런 종류의 이상 현상 만 발생할 수있었습니다. 예를 들어 재 시도를 해결할 수없는 경우에는이를 폐기하거나 꼬리가 종료 된 후 클래스 테이블로 돌아가는 등 긴급 수동 개입 만 가능합니다. 준비되고, 업스트림 Kafka 데이터 만료가 발생하면 ods 레이어 또는 오프라인에서만 복구 할 수 있습니다. 이는 매우 비효율적이며 사용자 경험이 매우 좋지 않습니다.
Doris 모드를 기반으로 마이크로 배치 스케줄링 모드를 사용합니다.
스케줄링 시스템은 주기적으로 (분 단위) 스케줄링 작업을 실행하고 SQL 조인을 기반으로 데이터 선택을 완료합니다. 이와 같이 예외가 있어도 수업 흐름에서 교사 데이터를 찾을 수 없기 때문에 조인 결과에는 교사 데이터를 찾을 수 있다는 정보 만 포함됩니다.
교사 데이터가 준비되면이 단원의 데이터 차원이 자동으로 완성 될 수 있습니다. 전체 프로세스가 완전히 자동화되어 결함을 허용합니다. 효율성이 매우 높습니다.
따라서이 모델의 주요 이점은
비즈니스 측 지연을 제어 할 수 있고 안정성이 좋습니다. 전체 프로세스는 주로 스케줄링 기간과 Sql의 실행 시간에 따라 다릅니다. 스케줄링주기를 제어 할 수 있으며 ES에서 Doris의 고성능으로 인해 Sql의 실행 시간은 거의 몇 분 내에 완료 될 수 있습니다.
데이터 복원은 비용이 저렴하고 유지 관리가 쉽습니다. 데이터가 비정상이면 해당 데이터 창을 자동으로 트리거하여 재 계산할 수 있습니다.
마지막으로, 다른 제안 된 방법에 대해 이야기하십시오. 이것은 비교적 간단하지만 실제 적용에서 간과하기 매우 쉽습니다.
ADS 계층 테이블, 특히 플랫폼 측 애플리케이션의 경우 조인을주의해서 사용하십시오. Doris는 브로드 캐스트, 셔퍼 등 많은 조인 전략을 가지고 있습니다. 원칙을 이해해야한다면 고급 사용자 범주에 속합니다. 빠른 반복이 강조되는 시나리오의 경우 마이크로 배치 모드를 사용하여 데이터 업데이트 지연을 약간 줄이고 데이터 쿼리의 효율성을 높일 수 있습니다.
ES에서 Doris를 사용할 때, 특히 ES 클러스터로드가 높을 때 지연이 허용되는 경우 es의 스캔 시간 제한을 30 초 이상과 같은 더 큰 값으로 설정하는 것이 좋습니다.
배치 크기는 크지 않을수록 좋습니다. 우리는 실제로 4096이 최고이며 초당 최대 30w의 스캔 속도에 도달 할 수 있음을 발견했습니다.
Doris가 정확한 중복 제거를 위해 비트 맵을 사용하는 경우 Sql 지연이 상대적으로 높지만 시스템 CPU 사용률이 낮은 경우가 있으므로 fragment_instance_num 값을 늘릴 수 있습니다.
Doris를 운영하고 유지할 때 비정상적인 서비스 중단 문제를 피할 수있는 감독자를 사용하는 것이 좋습니다. 코어를 나갈 때 비효율적 인 위치 지정을 방지하기 위해 모든 시스템이 ulimit -c로 활성화됩니다.
현재는 버그 수정이 적시 적이라는 점을 중심으로 마스터 버전을 사용하고 있지만 새로운 코드 및 기능 버그의 도입도 피해야하므로 커뮤니티 문제에주의를 기울이고 실제 생산에서 마스터의 안정성을 보장하기 위해 사용 모드의 케이스 회귀 및 고형화와 같은 일련의 조치.
마지막으로 계획에 대해 이야기하십시오.
Doris는 실시간 데이터웨어 하우스 구축에 중요한 역할을했습니다.
실제 응용 프로그램에서 우리는 현재 몇 가지 단점도 발견했습니다.
예를 들어, ES의 Doris가 큰 테이블의 조인 쿼리에 직면 할 때 현재 지연은 여전히 상대적으로 크기 때문에 추가 최적화가 필요합니다.
Doris의 자체 olap 테이블은 동적으로 분할 될 수 있지만 현재 ES 테이블의 제어 가능성은 충분하지 않습니다.
둘째, ES가 필드를 추가하는 등 테이블을 수정하면 Doris 테이블 만 삭제하고 다시 작성할 수 있으며, 자동 동기화가 필요하거나 온라인 핫 수정을 지원하는 단기 테이블 사용 불가가 발생할 수 있습니다.
마지막으로 ES의 Doris는 개수와 같은 더 많은 술어 푸시 다운을 지원할 수 있습니다.
또한 커뮤니티와 함께 Doris를 더 잘 만들 수 있기를 바랍니다.
확인. 내 공유는 여기서 끝납니다. 모두 감사합니다.
멋진 Q & A
질문 1 : ES의 Doris VS ES의 sparksql, 기능 및 성능 측면에서 조사 했습니까? 어떤 것을 사용할 것인지에 대한 제안이 있습니까?
답변 : ES의 SparkSql과 ES의 Doris는 모두 Sql이지만 실제 프로덕션 환경에는 여전히 큰 차이가 있습니다.
기능적으로 SparkSql과 Doris-Sql은 구문의 호환성을 고려할 필요가 있으며 결국 두 시스템이므로 구문 호환성이 실제로는 어렵습니다. 일관성이 없으면 클라이언트는 다른 시스템에 적응해야합니다.
성능 측면에서 ES의 SparkSql 또는 Doris는 ES에 액세스하는 원칙은 비슷하지만 구현에 차이가있을 수 있습니다. 이러한 차이로 인해 성능에 큰 차이가 발생합니다. 예를 들어 SparkSql 커넥터는 열 저장 모드를 지원하지 않습니다. .
시나리오 측면에서 SparkSql을 사용한다면 스트리밍 컴퓨팅 시나리오에서 사용하는 것이 좋습니다. 처리량 문제를 해결하기 위해 더 많은 것입니다. 유사한 시스템이 Flink-Sql이어야합니다. 라인에 따라 데이터를 스캔 한 후 Spark의 분산 컴퓨팅 기능과 원사의 자원 관리를 기반으로합니다. ES의 Doris는 지연 시간이 짧은 시나리오에 더 적합합니다.
질문 2 : Doris는 Hive Metastore를 지원합니다. Flink SQL과의 관계는 무엇입니까? 말이 너무 빨라 이해가 안 돼
답변 : Doris는 Hive MetaStore를 지원하지 않습니다. HDFS에서 파일을로드 한 다음 Doris의로드 구문에서 해당 열을 지정하면됩니다.
FlinkSql은 이것과 거의 관련이 없습니다. 하지만 당신이 말하는 것이 우리의 메타 데이터 여야한다는 것을 이해합니다.이 부분의 배경은 Flink-Sql이 실행할 때 redis 기반 테이블에있는 열과 유형과 같은 ddl 문을 설정해야하기 때문입니다. 통합 된 방식으로 관리되며 현재 메타 데이터 시스템에 저장됩니다. 인터페이스를 통해 Flink 시스템으로 도킹을 완료합니다.
질문 3 : _version 필드가 내부 필드입니까? 클라이언트가 쓰는시기를 지정해야합니까? 아니면 시스템에서 자동으로 작성합니까? HBase 버전과 애플리케이션 시나리오에 차이가 있습니까?
답변 : _version은 데이터 스트림의 내장 프로토콜 필드입니다. 데이터 전송 과정에서 사용자는 생성 내용을 표시하지 않고 값만 설정하면됩니다. 특정 값은 데이터 필드의 쓰기 서비스에 따라 설정할 수 있습니다. 예를 들어, ods 계층에서는 수집 측 서비스에서 작성해야합니다. flink 정리 링크가 중간에있는 경우에는 flink 시스템 아키텍처 서비스를 균일하게 설정하고 안정성을 확보하십시오.
_version 필드는 결국 아키텍처에서도 기록되는 스토리지 시스템의 UpdateTime 필드에 매핑됩니다. 비즈니스 측면의주의가 필요하지 않습니다.
HBase 버전은 데이터 롤백과 같은 다중 버전 관리에 더 많이 사용됩니다. 여기서 쿼리 시스템의 _version은 데이터의 최신 성을 보장하기위한 것입니다. 즉, 쿼리 시스템에서 사용자가 읽은 데이터는 항상 최신 상태입니다. 이를위한 전제 조건은 주로 ES와 같은 질의 시스템이 여러 버전의 데이터 컬럼을 잘 지원하지 않기 때문이며, 데이터 스트림 업데이트시 버전 관리가 없으면 아웃 오더 커버리지가 발생하기 쉽습니다. HBase의 버전 장면과 다릅니다.
ES 내부에도 _version이 있지만이 _version은 일반적으로 ES에서 내부적으로 높은 동시성에서 낙관적 잠금을 구현하는 데 사용됩니다. 현재의 장면과 다릅니다.
더 많은 읽기 추천