Veri Silolarını Parçalamak: Apache Doris Müşteri Veri Entegrasyonunu Nasıl Kolaylaştırır?

Veri siloları sorunu, çevrimiçi işletmelerde artrit gibidir çünkü neredeyse herkes yaşlandıkça bu soruna yakalanır. İşletmeler müşterilerle web siteleri, mobil uygulamalar, H5 sayfaları ve son cihazlar aracılığıyla etkileşime giriyor. Şu ya da bu nedenle, tüm bu kaynaklardan gelen verileri entegre etmek zordur. Veriler olduğu yerde kalır ve daha fazla analiz için birbiriyle ilişkilendirilemez. Veri siloları bu şekilde oluşur. İşletmeniz büyüdükçe, daha çeşitli müşteri veri kaynaklarına sahip olursunuz ve veri silolarının tuzağına düşme olasılığınız da artar.

Bu yazıda bahsedeceğim sigorta şirketinin başına gelen de tam olarak budur. 2023 yılına kadar 500 milyondan fazla müşteriye hizmet vermiş ve 57 milyar sigorta sözleşmesi imzalamış durumdalar. Böyle bir veri boyutuna uyum sağlamak için bir müşteri veri platformu (CDP) oluşturmaya başladıklarında birden fazla bileşen kullandılar.

CDP'deki veri siloları

Çoğu veri platformu gibi CDP 1.0'ın da toplu işleme hattı ve gerçek zamanlı akış hattı vardı. Çevrimdışı veriler Spark işleri aracılığıyla Impala'ya yüklendi, burada etiketlendi ve gruplara bölündü. Bu arada Spark, OneID hesaplaması için bunu NebulaGraph'a da gönderdi (bu yazının ilerleyen bölümlerinde ayrıntılı olarak ele alınacaktır). Öte yandan, gerçek zamanlı veriler Flink tarafından etiketlendi ve ardından sorgulanmaya hazır şekilde HBase'de saklandı.

Bu, CDP'de bileşen ağırlıklı bir hesaplama katmanının oluşmasına yol açtı: Impala, Spark, NebulaGraph ve HBase.

Sonuç olarak çevrimdışı etiketler, gerçek zamanlı etiketler ve grafik verileri birden fazla bileşene dağıldı. Yedekli depolama ve hacimli veri aktarımı nedeniyle bunları daha fazla veri hizmetleri için entegre etmek maliyetliydi. Dahası, depolamadaki farklılıklar nedeniyle CDH kümesinin ve NebulaGraph kümesinin boyutunu genişletmek zorunda kaldılar, bu da kaynak ve bakım maliyetlerini artırdı.

Apache Doris tabanlı CDP

CDP 2.0 için karışıklığı ortadan kaldıracak birleşik bir çözüm sunmaya karar verdiler. Apache Doris , CDP 2.0'ın hesaplama katmanında hem gerçek zamanlı hem de çevrimdışı veri depolama ve hesaplamayı üstlenir.

Çevrimdışı verileri almak için Akış Yükleme yöntemini kullanırlar. 30 iplik alımı testi, saniyede 300.000'den fazla yükseltme gerçekleştirebildiğini gösteriyor. Gerçek zamanlı verileri yüklemek için Flink-Doris-Connector ve Stream Load kombinasyonunu kullanıyorlar. Ayrıca, birden fazla harici veri kaynağından veri çıkarmaları gereken gerçek zamanlı raporlamada, birleştirilmiş sorgular için Çoklu Katalog özelliğinden yararlanırlar.

Bu CDP'deki müşteri analitiği iş akışları şu şekildedir. İlk önce müşteri bilgilerini sıralıyorlar; daha sonra her müşteriye etiket yapıştırırlar. Etiketlere dayanarak, daha hedefe yönelik analiz ve operasyon için müşterileri gruplara ayırırlar.

Daha sonra bu iş yüklerini derinlemesine inceleyeceğim ve size Apache Doris'in bunları nasıl hızlandırdığını göstereceğim.

OneID

Ürün ve hizmetleriniz için farklı kullanıcı kayıt sistemleriniz varken bu durum başınıza geldi mi? Kullanıcı Kimliği A'nın e-postasını bir ürünün web sayfasından ve daha sonra Kullanıcı Kimliği B'nin sosyal güvenlik numarasını başka birinden toplayabilirsiniz. Daha sonra Kullanıcı Kimliği A ve Kullanıcı Kimliği B'nin aslında aynı kişiye ait olduğunu, çünkü aynı telefon numarasını kullandıklarını öğreniyorsunuz.

OneID'nin bir fikir olarak ortaya çıkmasının nedeni budur. Tüm iş kollarının kullanıcı kayıt bilgilerini Apache Doris'te tek bir büyük tabloda toplamak, sıralamak ve bir kullanıcının benzersiz bir OneID'ye sahip olduğundan emin olmaktır.

Apache Doris'teki işlevlerden yararlanarak hangi kayıt bilgilerinin aynı kullanıcıya ait olduğunu bu şekilde anlarlar.

Etiketleme hizmetleri

Bu CDP, 500'den fazla kaynak tablodan gelen ve toplamda 2000'den fazla etikete eklenen 500 milyon müşteriye ait bilgileri barındırır.

Zamanlılık açısından, etiketler gerçek zamanlı etiketler ve çevrimdışı etiketler olarak ikiye ayrılabilir. Gerçek zamanlı etiketler Apache Flink tarafından hesaplanır ve Apache Doris'teki düz tabloya yazılır; çevrimdışı etiketler ise Doris'teki kullanıcı öznitelik tablosundan, iş tablosundan ve kullanıcı davranışı tablosundan türetildiği için Apache Doris tarafından hesaplanır. İşte şirketin veri etiketlemedeki en iyi uygulaması:

1. Çevrimdışı etiketler:

Veri yazmanın en yoğun olduğu dönemlerde, devasa veri ölçekleri göz önüne alındığında, tam bir güncelleme kolayca OOM hatasına neden olabilir. Bunu önlemek için Apache Doris'in INSERT INTO SELECT işlevini kullanırlar ve kısmi sütun güncellemesini etkinleştirirler. Bu, bellek tüketimini önemli ölçüde azaltacak ve veri yükleme sırasında sistem kararlılığını koruyacaktır.

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

2. Gerçek zamanlı etiketler:

Gerçek zamanlı etiketler farklı hızlarda güncellendiğinden, gerçek zamanlı etiketler için kısmi sütun güncellemeleri de mevcuttur. Gereken tek şey, partial_columns true olarak ayarlamaktır.

 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. Yüksek eşzamanlılık noktası sorguları:

Mevcut işletme boyutuyla şirket, etiketler için 5000 QPS'nin üzerinde eş zamanlılık düzeyinde sorgu istekleri alıyor. Yüksek performansı garanti altına almak için çeşitli stratejilerin bir kombinasyonunu kullanırlar. İlk olarak, SQL'in ön derlenmesi ve çalıştırılması için Hazırlanmış İfadeyi benimserler. İkinci olarak, depolamayı ve yürütmeyi optimize etmek için Doris Backend ve tablolara ilişkin parametrelere ince ayar yapıyorlar. Son olarak, sütun odaklı Apache Doris'in tamamlayıcısı olarak satır önbelleğini etkinleştirirler.

• be.conf dosyasında Doris Backend parametrelerine ince ayar yapın:

 disable_storage_row_cache = false storage_page_cache_limit=40%

• Tablo oluşturulduktan sonra tablo parametrelerine ince ayar yapın:

 enable_unique_key_merge_on_write = true store_row_column = true light_schema_change = true

4. Etiket hesaplaması (birleştirme):

Uygulamada birçok etiketleme hizmeti, veritabanındaki çoklu tablo birleştirmeleriyle uygulanır. Bu genellikle ondan fazla tabloyu içerir. Optimum hesaplama performansı için Doris'teki ortak yerleşim grubu stratejisini benimserler.

Müşteri Gruplaması

CDP 2.0'daki müşteri gruplandırma hattı şu şekildedir: Apache Doris, müşteri hizmetlerinden SQL alır, hesaplamayı yürütür ve sonuç kümesini SELECT INTO OUTFILE aracılığıyla S3 nesne deposuna gönderir. Şirket müşterilerini 1 milyon gruba ayırdı. Impala'da tamamlanması 50 saniye süren müşteri gruplandırma görevi artık Doris'te yalnızca 10 saniye sürüyor.

Daha detaylı analiz için müşterileri gruplamak dışında bazen ters yönde analiz yapıyorlar. Yani belirli bir müşteriyi hedef alıp onun hangi gruplara ait olduğunu öğrenmek. Bu, analistlerin müşterilerin özelliklerini ve farklı müşteri gruplarının nasıl örtüştüğünü anlamalarına yardımcı olur.

Apache Doris'te bu, BITMAP işlevleri tarafından uygulanır: BITMAP_CONTAINS , bir müşterinin belirli bir grubun parçası olup olmadığını kontrol etmenin hızlı bir yoludur ve BITMAP_OR , BITMAP_INTERSECT ve BITMAP_XOR çapraz analiz seçenekleridir.

Çözüm

Sigorta şirketi, CDP 1.0'dan CDP 2.0'a kadar Spark+Impala+HBase+NebulaGraph'ın yerine birleşik bir veri ambarı olan Apache Doris'i benimsiyor. Bu, veri silolarını ortadan kaldırarak ve veri işleme hatlarını düzene sokarak veri işleme verimliliğini artırır. Gelecek CDP 3.0'da, daha çeşitli ve esnek analiz için gerçek zamanlı etiketleri ve çevrimdışı etiketleri birleştirerek müşterilerini gruplandırmak istiyorlar. Apache Doris topluluğu ve VeloDB ekibi bu yükseltme sırasında destek ortağı olmaya devam edecek.

Burada da yayınlandı.