>일반적인 문제 >통합 데이터 웨어하우스를 사용하여 데이터 사일로 해소: Apache Doris 기반 CDP

통합 데이터 웨어하우스를 사용하여 데이터 사일로 해소: Apache Doris 기반 CDP

百草
百草원래의
2024-03-20 13:47:561032검색

기업 데이터 소스가 점점 다양해지면서 데이터 사일로 문제가 일반화되었습니다. 보험 회사가 고객 데이터 플랫폼(CDP)을 구축할 때 구성 요소 집약적인 컴퓨팅 계층과 데이터 사일로로 인해 분산된 데이터 스토리지 문제에 직면합니다. 이러한 문제를 해결하기 위해 그들은 Apache Doris 기반의 CDP 2.0을 채택했으며 Doris의 통합 데이터 웨어하우스 기능을 사용하여 데이터 사일로를 무너뜨리고 데이터 처리 파이프라인을 단순화하며 데이터 처리 효율성을 향상시켰습니다.

통합 데이터 웨어하우스를 사용하여 데이터 사일로 해소: Apache Doris 기반 CDP

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

이 기사에서 논의할 보험 회사에서 일어나는 일이 바로 이것입니다. 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개 이상의 업데이트 삽입을 수행할 수 있는 것으로 나타났습니다. 실시간 데이터를 로드하기 위해 Flink-Doris-Connector와 Stream Load의 조합을 사용했습니다. 또한 여러 외부 데이터 소스에서 데이터를 가져와야 하는 실시간 보고에서는 통합 쿼리에 대한 다중 카탈로그 기능을 활용합니다.

본 CDP의 고객 분석 워크플로우는 다음과 같습니다. 먼저 고객 정보를 정리한 다음 각 고객에게 라벨을 붙입니다. 보다 표적화된 분석 및 조치를 위해 태그에 따라 고객을 그룹화합니다.

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

One ID

귀하의 제품과 서비스가 서로 다른 사용자 등록 시스템을 가지고 있을 때 이런 상황에 직면한 적이 있습니까? 한 제품 페이지에서 사용자 ID A의 이메일을 수집한 다음 다른 제품 페이지에서 사용자 ID B의 주민등록번호를 수집할 수 있습니다. 그런 다음 UserID A와 UserID B가 동일한 전화번호를 사용하기 때문에 실제로 동일한 사람에 속한다는 것을 알게 됩니다.

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

이것은 Apache Doris의 기능을 활용하여 동일한 사용자에게 속한 등록을 확인하는 방법입니다.

태그 서비스

이 CDP에는 총 2000개 이상의 태그가 첨부된 500개 이상의 소스 테이블에서 5억 명의 고객 정보가 저장됩니다.

태그는 적시성에 따라 실시간 태그와 오프라인 태그로 나눌 수 있습니다. 실시간 태그는 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. 라이브 라벨

라이브 라벨도 업데이트 속도가 다르기 때문에 부분 열 업데이트도 라이브 라벨에 사용할 수 있습니다. 필요한 것은 부분 열을 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. 높은 동시점 쿼리

以目前的业务规模,该公司正在以超过 5000 QPS 的并发水平接收标签查询请求。他们使用策略组合来保证高性能。首先,他们采用Prepared Statement来预编译和预执行SQL。其次,他们微调 Doris 后端和表的参数以优化存储和执行。最后,它们启用行缓存作为面向列的 Apache Doris 的补充。

微调 Doris 的后端参数be.conf:

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.标签计算(Join)

在实践中,很多标签服务都是通过数据库中的多表连接来实现的。这通常涉及 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,保险公司采用统一数据仓库Apache Doris替代Spark+Impala+HBase+NebulaGraph。通过打破数据孤岛和简化数据处理管道,提高了数据处理效率。在CDP 3.0中,他们希望通过结合实时标签和离线标签来对客户进行分组,以进行更加多样化和灵活的分析。Apache Doris 社区和VeloDB团队将继续作为此次升级期间的支持合作伙伴。

위 내용은 통합 데이터 웨어하우스를 사용하여 데이터 사일로 해소: Apache Doris 기반 CDP의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.