작가 | 언젠가

소개

본 글에서는 주로 비즈니스 인텔리전스(BI)와 튜링 데이터 분석(TDA)의 개념과 응용을 소개합니다. BI는 데이터를 수집, 구성, 분석 및 제시함으로써 기업이 더 나은 결정을 내리고 전략적 계획을 세울 수 있도록 도와줍니다. 그러나 기존 BI 구축 아이디어에는 비즈니스에서 데이터 요구 사항이 변경될 때 재개발이 필요하고 기본 데이터 분석의 효율성이 낮은 등 문제가 있습니다. 따라서 TDA는 세부 데이터를 기반으로 분석 주제에 따라 공개 데이터 세트를 구축하고, 한 번의 클릭으로 분석 결과를 자유롭게 저장할 수 있으며, 다른 사용자와 공유할 수도 있는 원스톱 셀프 서비스 분석 플랫폼으로 등장했습니다. 다른 사람들은 볼 수 있습니다. 그러나 TDA 구축에는 종합적인 분석 차원 지표, 정확한 데이터 규모, 쿼리 성능 등의 과제도 직면해 있습니다. 이러한 과제에 대응하여 우리는 완전성, 정확성, 효율성 및 속도의 목표를 제시하고 MPP 데이터 엔진뿐만 아니라 프로세스 메커니즘과 기능 구성을 통해 이러한 목표를 달성합니다.

전체 텍스트는 4766 단어이며 예상 읽기 시간은 15분입니다.

01 배경과 목적

BI는 비즈니스 인텔리전스(Business Intelligence)를 의미하며, 데이터를 수집, 구성, 분석 및 제시함으로써 기업이 경쟁사보다 앞서고 더 나은 비즈니스 결정과 전략 계획을 세울 수 있도록 지원합니다. 수집하고 정리하는 과정이 데이터 웨어하우스의 구축이고, 데이터의 분석과 제시가 시각적 분석 플랫폼의 구축입니다.

업계에서 흔히 볼 수 있는 BI 구축 아이디어: 기업이 특정 지표의 데이터 변화를 보고자 할 경우 미들 오피스에 데이터 RD를 ODS>DWD>DWS>ADS 순으로 모델링한 후 맞춤형으로 구성한다. ADS 결과 테이블은 Palo/Mysql에서 개발 및 구현되며, 최종적으로 여러 차트를 구성하고 보고서에 저장하여 비즈니스 보기에 적합합니다. 이 구축 아이디어는 비즈니스의 데이터 분석 요구 사항을 충족하지만 두 가지 문제에 직면합니다. 1. 비즈니스에서 데이터 요구 사항이 변경되면 ADS 결과 테이블을 사용자 정의하고 다시 개발해야 하며 이는 반복적으로 R&D 인력을 차지합니다. 2. 문제만 해결합니다. 비즈니스 분석의 문제. 변동 원인을 더 자세히 분석하고 싶다면 기본 테이블이 현재 차트 데이터만 포함된 집계 테이블이므로 분석하려는 경우 다운로드만 가능합니다. 상세한 데이터를 수집한 후 엑셀이나 다른 방법으로 분석하는 것은 상대적으로 비효율적입니다.

TDA(Turing Data Analysis)는 위에서 언급한 BI의 긴 분석 링크 문제를 해결하기 위해 구축된 원스톱 셀프 서비스 분석 플랫폼입니다.

TDA 구축 아이디어: DWD 상세 와이드 테이블을 기반으로 분석 주제에 따라 공개 데이터 세트를 구성합니다(1일 데이터는 수천만 개 이상). 사용자는 공개 데이터 세트를 기반으로 분석을 드래그 앤 드롭할 수 있습니다. 자유롭게 분석 결과를 개인 대시보드에 저장하거나 한 번의 클릭으로 게시할 수 있습니다. 공개 대시보드를 만들어 다른 사람들과 공유할 수 있습니다. 공개 대시보드에서 변동 추세를 확인하고 시각적 분석 페이지로 드릴다운하여 계속 탐색할 수 있습니다. 변동요인을 파악하고, "추세를 보고, 차원을 세분화하고, 세부사항을 찾아내는" 3개의 축으로 원스톱 분석을 완료합니다.

다음 그림은 TDA 구축 아이디어의 전반적인 과정을 보여줍니다.

이 건설 아이디어는 다음과 같은 몇 가지 과제에도 직면하게 됩니다.

1. 분석 차원 지표가 완전해야 합니다. 그렇지 않으면 여러 데이터 세트를 구성해야 하므로 데이터 세트가 많고 분산되어 이전 보고서 구성과 동일한 문제가 발생합니다.

2. 데이터 수준은 정확하고 신뢰할 수 있어야 합니다.

3. 하루에 수천만 건의 데이터가 처리되므로 쿼리 성능은 큰 과제입니다.

위의 과제에 대응하여 효율적인 비즈니스 분석 요구 사항을 충족하기 위해 해당 목표도 수립했습니다.

1. 완전함(분석 차원 지표가 완전해야 하며 비즈니스 요구 사항의 80% 이상을 포괄해야 함)

2. 정확함(균일한 구경, 정확한 데이터)

3. 적시성(데이터 출력 적시성은 T+10h입니다)

4. 빠르다(10초 안에 10억급 데이터 조회).

TDA 플랫폼은 프로세스 메커니즘 및 기능 구성 관점에서 완전하고 정확하며 효율적인 데이터 세트 구성을 보장하고 MPP 데이터 엔진과 결합하여 쿼리 성능을 보장하며 BI의 시각적 드래그 앤 드롭, 장면 분석, 셀프 서비스 모델링 및 기타 기능.

02 기술 솔루션

위의 분석을 바탕으로 TDA의 제품 포지셔닝은 사용자가 원스톱 셀프 서비스 쿼리를 수행할 수 있도록 하는 BI 플랫폼입니다. 사용자는 데이터 세트를 자유롭게 드래그 앤 드롭하고 시각적 데이터 분석을 수행하며 핵심 대시보드를 구축할 수 있습니다. 사용자가 다음과 같은 관점에서 원스톱 쿼리 분석 경험을 얻을 수 있도록 지원합니다.

비즈니스 Kanban 반복 및 효율성 향상(셀프 서비스) : 데이터 보고서 반복 모드가 PM 요청 RD 스케줄링 모드에서 PM/운영 셀프 서비스 운영(Kanban 작성/데이터 분석)으로 점진적으로 전환되었습니다.

데이터 인사이트 분석 효율성 향상(매우 빠름) : 단일 데이터 쿼리가 분에서 초로 단축되고, 지표 변동 분석 효율성이 20배 향상되며, 단일 지표 변동 귀속의 엔드투엔드 분석이 2시간 이내로 완료됩니다. -> 5분.

원스톱 셀프 서비스 비즈니스 분석(원스톱) : 데이터 추세 관찰, 차원 드릴다운 분석, 세부 내보내기 및 기타 기능을 실현하여 데이터 모니터링 및 데이터 분석의 통합 경험을 실현합니다.

이 제품의 기능 매트릭스는 다음과 같습니다.

1. 데이터 소스 액세스 : 기업은 TDS를 사용하여 계산 엔진을 통해 업스트림 Turing 테이블 데이터를 계산한 다음 clickhouse/mysql/palo와 같은 엔진에 데이터를 쓰고 직접 연결을 통해 액세스하거나 기업이 자체 팔로를 제공합니다. / mysql 데이터 소스 액세스.

a. 데이터 소스 관리: 데이터 소스 추가, 삭제, 수정 및 쿼리, clickhouse/mysql/palo 및 기타 엔진 드라이버 적용

2. 데이터 모델링 : 데이터 소스에 연결한 후 원본 테이블에서 직접 SQL을 작성하여 데이터를 제품에 로드할 수 있습니다. 그러나 이러한 테이블을 분석할 수 있는 데이터 세트로 변환하려면 일반적으로 몇 가지 간단한 보조 처리가 필요합니다.

a. 데이터 세트 관리: 추가, 삭제, 수정, 데이터 미리보기, 스키마 보기, 원클릭 시각적 분석 등의 기능

b. 데이터 세트 필드 관리: 추가, 삭제, 수정, 필드 정렬, 사용자 정의 필드 등

c. 데이터 세트 카테고리 관리: 필드가 속한 카테고리의 추가, 삭제, 수정, 사용자 정의 정렬 등

d. 데이터 세트 디렉토리 관리: 데이터 세트 디렉토리의 추가, 삭제, 수정, 사용자 정의 정렬 등

3. 데이터 분석 : 데이터 세트를 기반으로 지표, 차원, 필터를 자유롭게 드래그 앤 드롭하고 적절한 차트 유형 및 시나리오 분석 방법을 선택하고 분석 및 계산을 수행할 수 있습니다.

a. 데이터 구성: 데이터 세트 전환, 사용자 정의 필드 추가

b. 차트 구성: 테이블, 꺾은선형 차트, 막대형 차트, 원형 차트 및 기타 차트 유형 구성, 범례 색상 설정, 데이터 형식 설정 등

c. 시나리오 분석: 일일 평균값, 전년 대비 비교, 비율, 합계 등 다양한 시나리오 분석 기능을 지원합니다.

d. 속성 분석: 셀프 서비스 속성 분석 기능

e. 대화형 분석: 드릴다운 분석 등

4. 데이터 활용 : 사용자는 분석 결과를 대시보드에 저장하거나, 타사 플랫폼에 내장하거나, 큰 화면에 저장하거나, 지능형 분석 등에 직접 사용할 수 있습니다.

a. 대시보드 관리: 대시보드 추가, 삭제, 수정, 맞춤 정렬, 게시 및 오프라인, 데이터 내보내기, 구독 알림 등

b. 임베디드 분석: ifame 임베디드, SDK 임베디드 및 기타 임베디드 모드

c. 대형 화면: 실시간 대형 화면

d. 지능형 분석: LUI 대화형 분석

2.1 전체 디자인

TDA의 전체 아키텍처는 아래 그림에 나와 있습니다.

전체 프로세스: 사용자가 쿼리를 시작하고, 서버가 쿼리 컨텍스트를 통합하고, 쿼리 개체를 구성하고, 기본 엔진 방언을 조정하고, 통합된 데이터 형식을 반환한 다음 프런트 엔드 렌더링 프레임워크가 차트 유형에 따라 조정 및 렌더링합니다. .

섬기는 사람:

1. 통합 쿼리 컨텍스트 : 추후 다른 차트 기능 확장 시 공통 기능의 재사용을 용이하게 하기 위해 통합 쿼리 컨텍스트를 설계합니다.

2. 쿼리 생성자 : 요청에 따라 쿼리 개체를 구성합니다(여러 개가 될 수 있습니다. 예를 들어 테이블을 페이지 매김하려면 두 개의 쿼리 개체를 구성해야 합니다. 하나는 페이징 쿼리 개체이고 다른 하나는 계산 쿼리 개체입니다). 프런트엔드에서 전달된 매개변수입니다.

3. 쿼리 커넥터 :

a. 현재는 SQL 쿼리 엔진(mysql, palo, clickhouse 등)을 충족하는 데 사용되는 SQL 커넥터만 있습니다. 다른 엔진, 구문 또는 일부 기능은 다를 수 있으며 다른 엔진을 통해 조정해야 합니다. 규칙 구성;

b. 향후 비SQL 쿼리를 충족하기 위해 다른 커넥터를 확장할 수 있습니다.

4. 캐시 쓰기 : 쿼리 성능을 보장하기 위해 사용자가 처음 접속할 때 쓰기, 셀러리 예약 작업을 통해 캐시를 예열하는 두 가지 쓰기 방법이 있습니다.

5. 데이터 세트 모듈 : 데이터 지원을 제공하고 기본 데이터 소스와의 링크를 설정하며 데이터 품질을 보장합니다.

6. 시스템 보장 모듈 : 구독, 조기 경보 및 공지는 데이터 조기 경보 기능을 구현하며, 공유, 게시 및 승인은 데이터 순환 효율성을 향상시킵니다. 관리 센터 및 권한은 데이터에 대한 기본 관리 및 권한 지원을 제공합니다.

프런트 엔드:

1. 구성 요소 라이브러리 : 구성 분석, 다양한 차트 렌더링 구성 요소, 필터 구성 요소 및 사용자 정의 구성 요소 기능을 제공합니다.

2. 상호 작용 : 드래그 앤 드롭 편집기, 드릴다운 연결, 보조 바로 가기 기능, 캔버스 기능 및 기타 이벤트 상호 작용을 포함한 페이지 상호 작용 기능을 캡슐화합니다.

3. 응용 프로그램 : 대시보드, 대형 화면 등과 같이 다양한 사용자 및 사용 시나리오에 맞게 다양한 시각적 응용 프로그램을 구현합니다.

2.2 상세설계

2.2.1 핵심 쿼리

원스톱 셀프 서비스 BI는 공개 데이터 세트 모델링 아이디어를 통해 다음과 같은 많은 과제에 직면하게 될 "추세, 차원 및 세부 사항"의 3점 분석 아이디어를 실현합니다.

다중 소스 데이터, 다중 차트 프레젠테이션 및 다중 시나리오 분석 및 계산 : BI 시스템에는 데이터 소스를 유연하게 확장하기 위해 프레젠테이션 스타일에도 풍부한 차트 지원이 필요합니다. 동시에 다양한 시나리오에서 분석을 충족하려면 월별 및 일일 평균 값과 같은 일반적인 분석 기능을 지원해야 합니다.
수천만 개의 데이터를 몇 초 만에 쿼리 : 공개 데이터 세트를 구축한다는 아이디어는 분석을 용이하게 하지만 새로운 과제도 야기합니다. 하루에 수천만 건의 데이터가 쿼리 성능에 큰 부담을 줍니다.

위의 문제에 대응하여 해당 솔루션이 공식화되었습니다.

통합 쿼리 : 쿼리 컨텍스트를 통합하고, 쿼리 개체를 구성하고, 기본 엔진 방언을 조정하고, 통합 데이터 형식을 반환하고, 프런트 엔드 렌더링 프레임워크가 차트 유형에 따라 렌더링을 조정합니다.
쿼리 최적화 : Ⅰ> 공개 대시보드 요청의 70%를 처리하는 캐싱 + 자동 롤링, Ⅱ> SQL 쿼리 구성 최적화 및 엔진 측 집계 기능 활용 III> 다중 도메인 이름 동시 요청 및 다중 코루틴 응답 처리 .

통합 쿼리:

플랫폼 사용자를 위한 통합 쿼리 프로세스는 다음과 같습니다.

1. 사용자는 페이지에서 분석을 자유롭게 드래그 앤 드롭할 수 있습니다 . 데이터 세트 전환, 다양한 차트 유형 간 전환, 지표, 차원, 필터 및 쿼리 드래그 앤 드롭이 가능하며 일부 고급 장면 분석 기능을 사용하려는 경우 전환할 수 있습니다. 한 번의 클릭으로 구성.

2. 프런트 엔드 요청은 데이터 소스, 쿼리 개체 및 반환 양식을 포함하는 통합 쿼리 컨텍스트로 처리됩니다. 쿼리 개체는 기본 지표, 차원, 필터링 정보 및 전년 대비 고급 분석 구성을 캡슐화합니다. 비교 및 일일 평균값.

3. 통합 인증 서비스 : 대시보드와 데이터셋의 이중 인증을 핵심으로 행 및 행 권한에 대한 보다 세분화된 권한 제어도 지원합니다.

4. 쿼리 개체 구성 : 먼저 지표, 차원 및 필터링 트리플을 기반으로 기본 SQL 구성(집계, 그룹화, 필터링)을 완료한 다음 정렬 규칙에 따라 정렬 논리를 조합하고 일부 고급 분석 옵션(예: 월별, 일일 평균 등) 추가 어셈블리 로직과 페이징 처리를 방언 적응과 결합해야 합니다. 데이터를 쿼리할 때 다른 엔진에 따라 다른 데이터베이스(예: mysql, palo, clickhouse 등)를 쿼리해야 합니다. 링커.

5. 데이터 조회 및 처리 : 링커를 통해 데이터를 조회한 후 데이터를 처리합니다(날짜 형식 처리, 꺾은선형 차트 관점 등).

6. 캐시 : 처리된 데이터를 캐시에 기록하거나, 쿼리 도중 캐시에 직접 적중된 경우 캐시된 데이터를 직접 읽어서 반환합니다.

7. 프런트 엔드 렌더링 프레임워크 통합 렌더링 : 통합 데이터 형식을 반환하고 프런트 엔드는 차트, 스타일 등의 적응형 렌더링을 완료합니다.

쿼리 최적화: Ⅰ>캐시 + 자동 롤업, 공개 대시보드 요청의 70%를 처리합니다.

1. 두 가지 캐싱 방법 :

첫 번째 쿼리: 사용자가 먼저 액세스(캐시 침투)하여 데이터베이스를 쿼리한 후 캐시에 씁니다.

오프라인 작업 준비: 공개 대시보드 차트 기록을 스캔하고 차트 요청(업데이트당 500개 이상)을 시뮬레이션하여 캐시 플러시를 강제합니다.

2. 오토매틱 와인딩 :

기록 쿼리의 3중(지표, 차원, 필터링)을 기반으로 롤업 테이블이 생성되고, 쿼리가 롤업 테이블에 도달하면 쿼리되는 데이터의 양이 대폭 줄어들고 성능이 향상됩니다.

쿼리 최적화: Ⅱ> SQL 쿼리 구성을 최적화하고 MPP 아키텍처 엔진(예: clickhouse/palo 등)의 집계 기능을 최대한 활용합니다.

공개 데이터 세트 분석 시나리오에서는 데이터를 질의한 후 메모리에서 집계 및 계산하는 것이 거의 불가능합니다. (예를 들어 (a + b)/c는 세부 데이터 a, b를 기반으로 집계 및 계산해야 함) , c) 그리고 엔진 측 MPP를 사용해야 합니다. 아키텍처의 쿼리 기능은 월별 집계와 마찬가지로 실행을 위해 엔진 측에 대한 집계 계산을 세분화합니다. 데이터 볼륨에는 수백억 개가 포함됩니다. 엔진 측 집계 계산 후 볼륨이 수십 배 감소하고 성능도 여러 배 향상되었습니다.

쿼리 최적화: III>다중 도메인 이름 동시 요청, 다중 코루틴 응답 처리.

1. 브라우저 동시성 제한 6 : 여러 도메인 이름을 사용하면 차트 요청이 다른 요청에서 오프로드되어 원활한 플랫폼 상호 작용과 차트 요청 동시성이 향상되어 전반적인 성능이 향상됩니다.

운영 체제 포트 자원을 고려하십시오. PC 포트의 총 개수는 65536이므로 TCP(http는 tcp이기도 함) 링크가 하나의 포트를 차지합니다. 운영 체제는 일반적으로 포트 수가 빨리 소진되는 것을 방지하기 위해 전체 포트의 절반을 외부 요청에 개방합니다.

과도한 동시성으로 인해 빈번한 전환 및 성능 문제가 발생합니다. 하나의 스레드가 하나의 http 요청을 처리하므로 동시성 수가 많으면 빈번한 스레드 전환이 발생합니다. 그리고 스레드 컨텍스트 전환은 때때로 가벼운 리소스가 아닙니다. 이로 인해 이득보다 손실이 더 많아지므로 이전 연결을 재사용하기 위해 요청 컨트롤러에 연결 풀이 생성됩니다. 따라서 동일한 도메인 이름 하에서 최대 연결 풀 수는 4~8개라고 생각하면 됩니다. 연결 풀을 모두 사용하면 후속 요청 작업이 차단되고 무료 링크가 있을 때 후속 작업이 실행됩니다.

동일한 클라이언트의 많은 동시 요청이 서버의 동시성 임계값을 초과하지 않도록 방지: 서버는 일반적으로 악의적인 공격을 피하기 위해 동일한 클라이언트 소스에 대해 동시성 임계값을 설정합니다. 브라우저가 동일한 도메인 이름에 대해 동시성 제한을 설정하지 않으면 서버의 동시성 임계값이 초과될 수 있습니다.

클라이언트 양심 메커니즘: 두 애플리케이션이 리소스를 점유하는 것을 방지하기 위해 강한 쪽이 제한 없이 리소스를 획득하여 약한 쪽이 영구적으로 차단됩니다.

2. 서버 측 다중 프로세스 + 다중 코루틴 동시성 :

여러 프로세스로 개발할 때 여러 프로세스가 동일한 이벤트를 기다리는 "천둥 떼 문제"가 발생할 수 있습니다. 이벤트가 발생하면 모든 프로세스가 커널에 의해 깨어나지만, 깨어난 후에는 한 프로세스만 이벤트를 획득하여 처리합니다. 다른 프로세스는 시간 획득에 실패한 것을 발견한 후 계속 대기 상태에 들어갑니다. 동일한 이벤트를 수신하면 프로세스가 많아질수록 CPU에 대한 경합이 더 심해지며 심각한 컨텍스트 비용이 발생합니다.

따라서 이러한 상황에 대응하여 uwsgi 서비스는 하나의 프로세스만 동시에 이벤트를 모니터링하도록 공유 잠금 메커니즘을 설계하고 구현하여 Thundering Herd 문제를 해결했습니다.

하지만 그렇다고 해도 프로세스 수를 제한 없이 확장할 수는 없습니다. 일반적으로 CPU 코어 수의 2배를 권장합니다.

그렇다면 프로세스 수가 제한되어 있으므로 처리량을 향상시키는 방법은 무엇입니까? 일반적인 상황에서는 IO가 차단됩니다. 데이터베이스나 파일을 읽을 때 현재 프로세스나 스레드는 IO 작업이 결과를 반환할 때까지 기다린 후 후속 코드를 계속 실행합니다. 멀티스레딩을 통해 처리량을 늘리고 IO 차단이 발생하면 스레드가 중단되고 다른 동시 요청은 스레드에서 처리되지 않습니다. 대신 IO일 때 각 스레드에 대해 비동기 IO가 구현됩니다. IO 결과를 기다리는 동안 먼저 새 요청을 처리하고 IO가 완료될 때까지 기다린 다음 IO를 기다려야 하는 코드로 다시 점프합니다. 이런 식으로 우리는 프로그램의 모든 스레드를 최대한 활용하고 항상 할 일이 있습니다. 이 방법은 개별 시간 소모에 영향을 주지 않으면서 전체 처리량을 향상시키고 전체 시간 소모를 줄입니다.

2.2.2 시스템 보증

알림을 구독하세요:

사용자는 보고서에 대한 보고서를 구성하고, 구독 관리 인터페이스에 따라 생성된 구독 보고서를 관리하고, 시스템의 실행 로그, 즉 보고서의 푸시 상태를 볼 수 있습니다.

보고서 구성에는 주로 푸시 콘텐츠, 푸시 양식, 트리거 조건 및 푸셔의 네 부분이 포함됩니다.

푸시 내용 : 단일 차트, 전체 보고서

푸시 형태 : 푸시의 세 가지 형태

차트 스크린샷

차트 CSV 데이터 이메일 첨부

스크린샷 신고

발동조건 :

예약된 푸시, cron 표현식을 기반으로 하는 예약된 푸시입니다.

데이터 동기화가 완료되면 푸시됩니다. 보고서의 모든 차트와 연결된 데이터 세트가 데이터 동기화를 완료하면 푸시 조건이 트리거되고 이메일 알림이 완료됩니다.

푸셔 : 이메일 계정이 여러 개인 경우 ","로 구분합니다.

권한:

데이터 권한 계층적 관리 및 제어: 데이터 세트 및 대시보드 이중 레이어 인증 코어를 기반으로 규칙 세분성에 따라 권한을 신청할 수 있는 행 및 열 권한을 지원하고 사용자 권한을 유연하게 제어합니다.

효율적인 협업: MPS(통합 권한 관리 시스템) 통합 권한 서비스를 개시하고, 권한 승인, 만료 복구, 사직 동결 및 기타 기능을 실현하고, 원활한 사무실을 열고, 권한 승인의 고속 순환을 가속화합니다.

03 요약 및 기획

3.1 요약

지속적인 반복을 통해 TDA는 기본적으로 원스톱 셀프 서비스 분석 기능을 개발했으며 다음 지표를 달성했습니다.

규모 성장: pv는 0에서 2w+로 증가하고 uv는 0에서 1000+로 증가하며 일일 새 차트는 0에서 300+로 증가했습니다.

성능 개선: 대시보드 첫 화면의 90번째 백분위수에 도달하는 데 걸리는 시간이 10초 이상에서 5초로 단축되었습니다.
업무 효율 개선: 핵심 업무 셀프 서비스 비율 80% 이상 추진, 변동 분석 효율 20배 향상, 단일 지표 변동에 대한 엔드투엔드 기여 분석을 2시간에서 5분으로 단축합니다.