데이터 사일로 해소: Apache Doris가 고객 데이터 통합을 간소화하는 방법

데이터 사일로 문제는 거의 모든 사람이 나이가 들면서 발생하기 때문에 온라인 비즈니스의 관절염과 같습니다. 기업은 웹사이트, 모바일 앱, H5 페이지, 최종 장치를 통해 고객과 상호 작용합니다. 어떤 이유로든 이러한 모든 소스의 데이터를 통합하는 것은 까다롭습니다. 데이터는 현재 위치에 유지되며 추가 분석을 위해 상호 연관될 수 없습니다. 이것이 데이터 사일로가 형성되는 방식입니다. 비즈니스가 성장할수록 고객 데이터 소스가 더욱 다양해지고 데이터 사일로에 갇힐 가능성이 높아집니다.

이것이 바로 제가 이번 포스팅에서 이야기할 보험회사에 일어나는 일입니다. 2023년까지 그들은 이미 5억 명 이상의 고객에게 서비스를 제공하고 570억 건의 보험 계약을 체결했습니다. 이러한 데이터 크기를 수용하기 위해 고객 데이터 플랫폼(CDP)을 구축하기 시작했을 때 그들은 여러 구성 요소를 사용했습니다.

CDP의 데이터 사일로

대부분의 데이터 플랫폼과 마찬가지로 CDP 1.0에는 일괄 처리 파이프라인과 실시간 스트리밍 파이프라인이 있었습니다. 오프라인 데이터는 Spark 작업을 통해 Impala로 로드되었으며, 여기서 태그가 지정되고 그룹으로 나누어졌습니다. 한편 Spark는 OneID 계산을 위해 이를 NebulaGraph에도 보냈습니다(이 게시물의 뒷부분에서 자세히 설명). 반면, 실시간 데이터는 Flink에 의해 태그된 후 HBase에 저장되어 쿼리할 준비가 되었습니다.

이로 인해 CDP에 Impala, Spark, NebulaGraph 및 HBase와 같은 구성 요소가 많은 계산 계층이 생겼습니다.

결과적으로 오프라인 태그, 실시간 태그, 그래프 데이터가 여러 구성 요소에 분산되었습니다. 추가 데이터 서비스를 위해 이를 통합하는 데는 중복된 스토리지와 대용량 데이터 전송으로 인해 비용이 많이 들었습니다. 게다가 스토리지 불일치로 인해 CDH 클러스터와 NebulaGraph 클러스터의 크기를 확장해야 했고 이로 인해 리소스 및 유지 관리 비용이 추가되었습니다.

Apache Doris 기반 CDP

CDP 2.0의 경우 혼란을 정리하기 위해 통합 솔루션을 도입하기로 결정했습니다. CDP 2.0의 계산 계층에서 Apache Doris는 실시간 및 오프라인 데이터 저장과 계산을 모두 수행합니다.

오프라인 데이터를 수집하기 위해 스트림 로드 방법을 활용합니다. 30개 스레드 수집 테스트를 통해 초당 300,000회 이상의 upsert를 수행할 수 있는 것으로 나타났습니다. 실시간 데이터를 로드하기 위해 Flink-Doris-Connector 와 Stream Load의 조합을 사용합니다. 또한 여러 외부 데이터 소스에서 데이터를 추출해야 하는 실시간 보고에서는 통합 쿼리를 위한 다중 카탈로그 기능을 활용합니다.

이 CDP의 고객 분석 워크플로는 다음과 같습니다. 첫째, 고객 정보를 정리합니다. 그런 다음 각 고객에게 태그를 부착합니다. 태그를 기반으로 고객을 그룹으로 나누어 보다 타겟화된 분석 및 운영을 수행합니다.

다음으로 이러한 워크로드를 자세히 살펴보고 Apache Doris가 이를 가속화하는 방법을 보여 드리겠습니다.

원아이디

귀하의 제품과 서비스에 대해 서로 다른 사용자 등록 시스템이 있을 때 이런 일이 발생한 적이 있습니까? 한 제품 웹 페이지에서 UserID A의 이메일을 수집하고 나중에 다른 제품 웹 페이지에서 UserID B의 주민등록번호를 수집할 수 있습니다. 그러다가 UserID A와 UserID B가 같은 전화번호를 사용하기 때문에 실제로는 같은 사람이라는 것을 알게 됩니다.

그래서 OneID는 아이디어로 탄생한 것입니다. 모든 사업 분야의 사용자 등록 정보를 아파치 도리스에서 하나의 큰 테이블로 모아서 정리한 뒤, 한 명의 사용자가 고유한 OneID를 갖도록 하는 것입니다.

이는 Apache Doris의 기능을 활용하여 동일한 사용자에게 속한 등록 정보를 파악하는 방법입니다.

태깅 서비스

이 CDP는 500개 이상의 소스 테이블 에서 온 5억 명의 고객 정보를 수용하고 총 2000개 이상의 태그 에 첨부됩니다.

적시에 태그는 실시간 태그와 오프라인 태그로 나눌 수 있습니다. 실시간 태그는 Apache Flink에 의해 계산되어 Apache Doris의 플랫 테이블에 기록되는 반면, 오프라인 태그는 Doris의 사용자 속성 테이블, 비즈니스 테이블 및 사용자 행동 테이블에서 파생되므로 Apache Doris에 의해 계산됩니다. 데이터 태그 지정에 대한 회사의 모범 사례는 다음과 같습니다.

1. 오프라인 태그:

데이터 쓰기가 최고조에 달하는 동안 전체 업데이트는 데이터 규모가 크기 때문에 쉽게 OOM 오류를 일으킬 수 있습니다. 이를 방지하기 위해 Apache Doris의 INSERT INTO SELECT 기능을 활용하고 부분 열 업데이트를 활성화합니다. 이렇게 하면 메모리 소비가 크게 줄어들고 데이터를 로드하는 동안 시스템 안정성이 유지됩니다.

 set enable_unique_key_partial_update=true; insert into tb_label_result(one_id, labelxx) select one_id, label_value as labelxx from .....

2. 실시간 태그:

실시간 태그는 다양한 속도로 업데이트되므로 부분 열 업데이트도 실시간 태그에 사용할 수 있습니다. 필요한 것은 partial_columns true 로 설정하는 것뿐입니다.

 curl --location-trusted -u root: -H "partial_columns:true" -H "column_separator:," -H "columns:id,balance,last_access_time" -T /tmp/test.csv http://127.0.0.1:48037/api/db1/user_profile/_stream_load

3. 동시성이 높은 쿼리:

현재 비즈니스 규모로 볼 때 이 회사는 5000QPS가 넘는 동시성 수준으로 태그에 대한 쿼리 요청을 받고 있습니다. 그들은 높은 성능을 보장하기 위해 여러 가지 전략을 조합하여 사용합니다. 첫째, SQL의 사전 컴파일 및 사전 실행을 위해 준비된 명령문을 채택합니다. 둘째, Doris Backend와 테이블의 매개변수를 미세 조정하여 저장 및 실행을 최적화합니다. 마지막으로 열 기반 Apache Doris를 보완하기 위해 행 캐시를 활성화합니다.

• be.conf 에서 Doris 백엔드 매개변수를 미세 조정합니다.

 disable_storage_row_cache = false storage_page_cache_limit=40%

• 테이블 생성 시 테이블 매개변수를 미세 조정합니다.

 enable_unique_key_merge_on_write = true store_row_column = true light_schema_change = true

4. 태그 계산(조인):

실제로 많은 태깅 서비스는 데이터베이스의 다중 테이블 조인을 통해 구현됩니다. 여기에는 10개 이상의 테이블이 포함되는 경우가 많습니다. 최적의 계산 성능을 위해 Doris에서는 코로케이션 그룹 전략을 채택합니다.

고객 그룹화

CDP 2.0의 고객 그룹화 파이프라인은 다음과 같습니다. Apache Doris는 고객 서비스로부터 SQL을 수신하고, 계산을 실행하고, SELECT INTO OUTFILE을 통해 결과 세트를 S3 객체 스토리지로 보냅니다. 회사는 고객을 100만 개의 그룹으로 나누었습니다. Impala에서 완료하는 데 50초가 걸리던 고객 그룹화 작업이 이제 Doris에서는 10초만 필요합니다.

보다 세부적인 분석을 위해 고객을 그룹화하는 것 외에도 때로는 반대 방향으로 분석을 수행하는 경우도 있습니다. 즉, 특정 고객을 타겟으로 하고 그 고객이 어느 그룹에 속하는지 알아내는 것입니다. 이를 통해 분석가는 고객의 특성은 물론 다양한 고객 그룹이 어떻게 겹치는지 이해하는 데 도움이 됩니다.

Apache Doris에서는 이는 BITMAP 함수로 구현됩니다. BITMAP_CONTAINS 는 고객이 특정 그룹의 일부인지 확인하는 빠른 방법이고 BITMAP_OR , BITMAP_INTERSECT 및 BITMAP_XOR 은 교차 분석을 위한 선택입니다.

결론

CDP 1.0부터 CDP 2.0까지 보험 회사는 Spark+Impala+HBase+NebulaGraph를 대체하기 위해 통합 데이터 웨어하우스인 Apache Doris를 채택했습니다. 이는 데이터 사일로를 허물고 데이터 처리 파이프라인을 간소화하여 데이터 처리 효율성을 높입니다. 향후 CDP 3.0에서는 보다 다양하고 유연한 분석을 위해 실시간 태그와 오프라인 태그를 결합하여 고객을 그룹화하려고 합니다. Apache Doris 커뮤니티 와 VeloDB 팀은 이 업그레이드 기간 동안 계속해서 지원 파트너가 될 것입니다.

여기에도 게시되었습니다.