1. 플랫폼 소개

금융자체운영과금은 주로 공급망 전체의 C단에서 B단으로 JD의 자체운영 데이터를 전송하는 기능을 담당하며, 전체 공급망의 후기단계에 해당합니다. B 엔드로 집계됩니다.

2. 문제 설명

최근 몇 년 동안 자체 운영 청구 데이터의 양이 크게 증가하여 데이터 양이 100억 개가 넘고 요약이 하루 데이터베이스 리소스의 절반을 차지합니다.

1. 매일 하나의 테이블에서 수천만 개의 W+에서 수만 개의 데이터를 찾아 요약 수행, 즉 모든 데이터베이스 및 모든 테이블, 32개 데이터베이스 * 32개 테이블에 대해 그룹별 작업을 수행하며 처리 시간은 12시간 소요 매일.

2. 집계 기간 동안 시스템은 기본적으로 정체되어 메시지 및 작업 처리 속도가 느려지고 백로그가 커지며 적시에 데이터를 청구할 수 없게 되었습니다.

3. 데이터베이스는 큰 압박을 받고 있으며 언제든지 충돌할 위험이 있습니다.

4. 공급업체 경험에 영향을 미칩니다.대규모 프로모션 기간 동안 공급업체는 판매 데이터와 전투 보고서를 실시간으로 확인해야 하며 시스템이 적시에 응답할 수 없습니다.

3. 원천기술 소개

시스템 요약의 핵심은 MySQL 물리적 머신에 의존하여 각 데이터베이스와 각 테이블에서 그룹화를 수행합니다. 요약은 비용 유형별로 나누어 정복됩니다. 각 요약 차원의 유형은 다릅니다. 새로운 요약 차원이 도입될 때마다, 새로운 요약 로직은 주로 새로운 차원의 데이터 범위를 잠그고 필드별로 새로운 그룹을 결정하는 것입니다. 이전 로직은 회귀 테스트를 거쳐야 했는데 어리석은 것 같습니다.

4. 문제 해결을 위한 아이디어와 방법

위의 배경과 문제점을 바탕으로 문제에 대한 대략적인 해결책을 결정합니다.

1. 우선 MySQL 요약에서 벗어나야 합니다. 데이터베이스는 매우 취약하므로 데이터베이스를 보호해야 합니다. 그렇지 않으면 규모가 계속 증가하여 언젠가는 하늘이 무너질 것입니다.

2. 새로운 요구 사항의 반복 개발로 인한 단점을 부수적으로 해결합니다.

5. 실제 과정에 대한 설명

용량이 크기 때문에 비즈니스에서는 T+1 처리가 허용되며, 오프라인 데이터 처리이므로 일반적으로 Spark, Spring Batch, Finlk 등을 생각할 수 있으며, 기술 연구 단계에서는 성숙도와 커뮤니티 활동이 주로 이루어집니다. 고려하고 있으며, 스파크 기술이 주로 사용됩니다. 요약 프로세스를 4단계로 나눕니다. 다음 내용에서는 이해를 돕기 위해 논리를 단순화하고 간략하게 설명합니다.

1. 데이터 캡처

집계 이전의 데이터는 비즈니스 데이터이며, Type은 일반적으로 비즈니스 데이터에서 데이터 비용 유형을 구분하는 필드를 의미하며, ou 및 dept는 일반적으로 소스 데이터의 차원을 의미하며 하나 이상의 다른 필드일 수 있습니다. 요약해서 합산할 필드입니다. 여기에 표현되는 금액은 금액입니다.

구성 테이블은 원본 데이터에서 파생되며 많은 구성 데이터가 있을 수 있으며 이는 일반적인 용어로 이 시스템에서는 하나의 테이블만 사용합니다. type은 비용 유형이 소스 데이터와 연결되는 데 사용됨을 나타냅니다. 연결은 하나 이상의 필드와 연결될 수 있습니다. 여기서는 필드를 예로 사용했습니다. merge_key는 요약 필드이고 필드 값은 하나 이상입니다. 소스 데이터의 테이블 구조에서 필드 구성. voice_type은 집계된 결과 집합에 채워야 하는 공개 필드를 나타내며 일반적으로 여기서는 송장 유형이라고 합니다. 채워진 필드에 따라 확장될 수 있으며 확장된 경우 나중에 구성 테이블에 열을 추가하면 됩니다. 다음 예제 다이어그램은 단일 필드에서 이 의미를 표현합니다.

2. 규칙 매칭

첫 번째 처리가 수행됩니다. 즉, 소스 데이터의 각 행은 아래 그림과 같이 구성 테이블의 유일한 행과 연관됩니다. 특별한 지시에 따라 소스 데이터의 각 행은 구성 테이블의 한 행에만 연관될 수 있습니다. 즉, 연관될 수 없는, 즉 구성이 없는 Left 조인은 필터링되어 요약되지 않습니다 . 처리 작업의 첫 번째 단계는 메모리에서 완료됩니다.

그런 다음 처리의 두 번째 단계로 진행합니다.이 단계에서는 구성 테이블에서 가져온 merge_key 필드를 현재 Left Join 행에 해당하는 필드의 특정 값으로 추가로 구문 분석해야 합니다. 파싱된 결과는 아래와 같으며, 본 단계의 설명에 따르면 merge_key의 필드(예: 첫 번째 행 ou)에 따라 이 행의 해당 열의 필드 값인 81을 구하는 원리가 구현됩니다. Java 리플렉션을 통해 다양한 오픈 소스 도구가 있습니다.스프링 표현식 및 기타 도구와 같은 패키지를 직접 사용할 수 있습니다. 비유적으로 여러 필드의 값을 얻을 수도 있으며 특정 연결 기호에 따라 여러 필드를 연결할 수 있습니다. 이 그림은 _로 연결됩니다. 채워진 필드도 동시에 추가됩니다.

3. 데이터 요약

규칙 일치 데이터가 처리된 후 처리된 merge_key 필드만 요약하면 됩니다. 요약 엔진은 고정된 요약 필드만 따르면 됩니다(여기의 예는 두 번째 단계가 처리된 후의 merge_key 필드입니다). 요약 논리는 다음과 같습니다. 이를 구체화할 수 있으며, 모든 비용 유형의 요약을 구현하기 위해서는 하나의 일반 SQL만 필요하며, 최종 요약 결과가 생성됩니다.

4. 요약 결과

집계된 데이터는 원천기술을 통해 집계된 데이터와 동일한 결과를 유지할 수 있으며 동시에 일부 공통 필드를 채울 수 있습니다. 아래 그림과 같이 소스 데이터의 녹색 2행은 ou로 요약되어 결과 테이블의 1행이 되고, 주황색 소스 데이터의 3행은 dept로 요약되어 결과 테이블의 2행이 되며, 노란색의 소스는 ou로 요약되어 1행이 됩니다. 데이터는 ou, dept 필드로 요약되며 요약은 3줄로 구성됩니다.

마지막으로 요약 결과를 MySQL에 다시 작성합니다.

6. 실제적인 프로세스 사고와 효과 평가

1. 테스트 환경 검증 과정에서 테스트 테이블과 온라인 테이블의 수치 레벨이 다르며 처음 온라인에 접속할 때 데이터 읽기 속도가 매우 느립니다. 스파크는 단일 테이블을 매우 빠르게 읽기 때문에 하위 데이터베이스 및 하위 테이블에서 데이터를 읽는 효율성이 떨어지는데, 여기서는 멀티스레딩 방식을 사용하여 조건에 맞는 요약되지 않은 데이터를 읽어 최종적으로 큰 세트를 요약한다.

2. 온라인 상태로 일정 시간 동안 안정적으로 실행한 후, 성능 비교 차트를 보면 MySQL에서 작업별 그룹을 제거함으로써 요약 시간이 단축되고, 데이터베이스 성능이 향상되었으며, 메시지 및 처리 능력이 향상되었음을 알 수 있습니다. 비동기 작업도 개선되어 전반적인 상황에 영향을 미칩니다.

3. 향후 새로운 요약 요구 사항이 온라인에 추가되면 구성을 통해 새로운 차원 요약 기능을 구현할 수 있으므로 연구 개발 작업이 단순화되고 수요 전달의 적시성이 향상됩니다. 단점도 있는데, 현재 Spark는 비즈니스 데이터를 읽을 때 기본 테이블만 읽고 확장 테이블은 읽지 않기 때문에 요약 차원의 필드를 기본 테이블에서 가져와야 합니다. 향후 Hive 테이블의 데이터 품질에 자신이 있다면 Spark로 변경하여 Hive 테이블을 직접 읽거나 es, ck 및 기타 라이브러리에서 읽을 수 있습니다.

4. 스파크 프레임워크 도입으로 대용량 데이터베이스 요약이 온라인에서 오프라인으로 변경되어 데이터베이스에 대한 부담이 완화되고, 데이터베이스 성능이 향상되면 과금 효율성도 향상되어 안정성도 높아진다. 시스템을 개선하고 공급업체의 경험을 향상시킵니다.

저자 : 왕시겐

출처 : JD Cloud 개발자 커뮤니티 전재시 출처를 밝혀주세요

금융 데이터 처리 문제 및 솔루션 공유