Memecahkan silo data menggunakan gudang data bersatu: CDP berdasarkan Apache Doris

Memandangkan sumber data perusahaan menjadi semakin pelbagai, masalah silo data telah menjadi perkara biasa. Apabila syarikat insurans membina platform data pelanggan (CDP), mereka menghadapi masalah lapisan pengkomputeran intensif komponen dan storan data bertaburan yang disebabkan oleh silo data. Untuk menyelesaikan masalah ini, mereka menggunakan CDP 2.0 berdasarkan Apache Doris, menggunakan keupayaan gudang data bersatu Doris untuk memecahkan silo data, memudahkan saluran paip pemprosesan data dan meningkatkan kecekapan pemprosesan data.

Masalah data silo adalah seperti arthritis untuk perniagaan dalam talian kerana hampir semua orang menghadapinya apabila usia mereka meningkat. Perniagaan berinteraksi dengan pelanggan melalui tapak web, apl mudah alih, halaman HTML5 dan peranti akhir. Atas sebab tertentu, menyepadukan data daripada semua sumber ini adalah rumit. Data kekal di tempatnya dan tidak boleh dikaitkan antara satu sama lain untuk analisis selanjutnya. Ini adalah bagaimana silo data terbentuk. Semakin besar perniagaan anda, semakin banyak sumber data pelanggan yang anda miliki dan semakin besar kemungkinan anda terperangkap dalam silo data.

Inilah yang berlaku dengan syarikat insurans yang akan saya bincangkan dalam artikel ini. Menjelang 2023, mereka telah berkhidmat kepada lebih 500 juta pelanggan dan menandatangani 57 bilion kontrak insurans. Apabila mereka mula membina Platform Data Pelanggan (CDP) mereka untuk menampung skala data yang begitu besar, mereka menggunakan berbilang komponen.

Silo Data dalam CDP

Seperti kebanyakan platform data, CDP 1.0 mereka mempunyai kedua-dua saluran paip kelompok dan saluran paip penstriman masa nyata. Data luar talian dimuatkan ke dalam Impala melalui kerja Spark, di mana ia ditag dan dibahagikan kepada kumpulan. Pada masa yang sama, Spark juga menghantarnya ke NebulaGraph untuk pengiraan OneID (lebih lanjut mengenai perkara ini kemudian dalam artikel ini). Sebaliknya, data masa nyata ditandakan oleh Flink dan kemudian disimpan dalam HBase untuk pertanyaan.

Ini menghasilkan lapisan pengkomputeran intensif komponen dalam CDP: Impala, Spark, NebulaGraph dan HBase.

Akibatnya, label luar talian, label langsung dan data graf bertaburan merentasi berbilang komponen. Mengintegrasikan mereka untuk menyediakan perkhidmatan data selanjutnya adalah mahal disebabkan oleh storan yang berlebihan dan pemindahan data yang besar. Lebih penting lagi, disebabkan perbezaan penyimpanan, mereka terpaksa mengembangkan skala kelompok CDH dan kelompok NebulaGraph, meningkatkan kos sumber dan penyelenggaraan.

CDP berasaskan Apache Doris

Untuk CDP 2.0, mereka memutuskan untuk memperkenalkan penyelesaian bersatu untuk membersihkan kucar-kacir. Dalam lapisan pengkomputeran CDP 2.0, Apache Doris bertanggungjawab untuk penyimpanan dan pengiraan data masa nyata dan luar talian.

Untuk mencerna data luar talian, mereka menggunakan kaedah pemuatan penstriman. Ujian penyerapan 30 utas mereka menunjukkan bahawa ia boleh melakukan lebih daripada 300,000 sisipan kemas kini sesaat. Untuk memuatkan data masa nyata, mereka menggunakan gabungan Flink-Doris-Connector dan Stream Load. Selain itu, dalam pelaporan masa nyata yang memerlukan penarikan data daripada berbilang sumber data luaran, mereka memanfaatkan keupayaan berbilang katalog untuk pertanyaan bersekutu.

Aliran kerja analisis pelanggan pada CDP ini adalah seperti berikut. Pertama, mereka menyusun maklumat pelanggan dan kemudian melabel setiap pelanggan. Mereka mengumpulkan pelanggan mengikut teg untuk analisis dan tindakan yang lebih disasarkan.

Seterusnya, saya akan menyelami beban kerja ini dan menunjukkan kepada anda cara Apache Doris mempercepatkannya.

Satu ID

Pernahkah anda menghadapi situasi ini apabila produk dan perkhidmatan anda mempunyai sistem pendaftaran pengguna yang berbeza? Anda boleh mengumpulkan e-mel ID pengguna A dari satu halaman produk, dan kemudian mengumpul nombor keselamatan sosial ID pengguna B dari halaman produk lain. Anda kemudian akan mendapati bahawa UserID A dan UserID B sebenarnya adalah milik orang yang sama kerana mereka menggunakan nombor telefon yang sama.

Itulah sebabnya OneID muncul sebagai idea. Ia adalah untuk mengumpul maklumat pendaftaran pengguna semua baris perniagaan ke dalam jadual besar dalam Apache Doris, mengaturnya dan memastikan setiap pengguna mempunyai OneID yang unik.

Beginilah mereka memanfaatkan kefungsian dalam Apache Doris untuk menentukan pendaftaran mana yang dimiliki oleh pengguna yang sama.

Tag Service

CDP ini menempatkan 500 juta maklumat pelanggan daripada lebih 500 jadual sumber dengan jumlah lebih daripada 2000 tag dilampirkan.

Mengikut ketepatan masa, tag boleh dibahagikan kepada tag masa nyata dan tag luar talian. Teg masa nyata dikira oleh Apache Flink dan ditulis pada jadual rata dalam Apache Doris, manakala teg luar talian dikira oleh Apache Doris kerana ia berasal daripada jadual atribut pengguna, jadual perniagaan dan jadual tingkah laku pengguna dalam Doris. Berikut ialah amalan terbaik syarikat dalam pelabelan data:

1. Pelabelan luar talian

Semasa tempoh puncak penulisan data, disebabkan oleh skala data yang besar, kemas kini penuh boleh membawa kepada ralat OOM dengan mudah. Untuk mengelakkan ini, mereka memanfaatkan fungsi INSERT INTO SELECT Apache Doris dan mendayakan kemas kini separa lajur. Ini akan mengurangkan penggunaan memori dengan ketara dan mengekalkan kestabilan sistem semasa pemuatan data.

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

2 Label Langsung

Kemas kini separa lajur juga tersedia untuk label langsung kerana label langsung dikemas kini pada kelajuan yang berbeza. Apa yang diperlukan ialah menetapkan partial_columns kepada benar.

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. Pertanyaan mata konkurensi tinggi

以目前的业务规模，该公司正在以超过 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团队将继续作为此次升级期间的支持合作伙伴。

Atas ialah kandungan terperinci Memecahkan silo data menggunakan gudang data bersatu: CDP berdasarkan Apache Doris. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!