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. , CDP 2.0'ın hesaplama katmanında hem gerçek zamanlı hem de çevrimdışı veri depolama ve hesaplamayı üstlenir. Apache Doris almak için yöntemini kullanırlar. 30 iplik alımı testi, saniyede 300.000'den fazla yükseltme gerçekleştirebildiğini gösteriyor. yüklemek için ve Stream Load kombinasyonunu kullanıyorlar. Ayrıca, birden fazla harici veri kaynağından veri çıkarmaları gereken gerçek zamanlı raporlamada, için özelliğinden yararlanırlar. Çevrimdışı verileri Akış Yükleme Gerçek zamanlı verileri Flink-Doris-Connector birleştirilmiş sorgular Çoklu Katalog 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, gelen ve toplamda eklenen ait bilgileri barındırır. 500'den fazla kaynak tablodan 2000'den fazla etikete 500 milyon müşteriye 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 işlevini kullanırlar ve etkinleştirirler. Bu, bellek tüketimini önemli ölçüde azaltacak ve veri yükleme sırasında sistem kararlılığını koruyacaktır. INSERT INTO SELECT kısmi sütun güncellemesini 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, olarak ayarlamaktır. 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. 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 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 etkinleştirirler. Hazırlanmış İfadeyi satır önbelleğini dosyasında Doris Backend parametrelerine ince ayar yapın: be.conf 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 stratejisini benimserler. ortak yerleşim grubu 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ı. süren müşteri gruplandırma görevi artık sürüyor. Impala'da tamamlanması 50 saniye Doris'te yalnızca 10 saniye 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: , bir müşterinin belirli bir grubun parçası olup olmadığını kontrol etmenin hızlı bir yoludur ve , ve çapraz analiz seçenekleridir. BITMAP_CONTAINS BITMAP_OR BITMAP_INTERSECT BITMAP_XOR Çö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. ve ekibi bu yükseltme sırasında destek ortağı olmaya devam edecek. Apache Doris topluluğu VeloDB da yayınlandı. Burada
