Altı ay önce, veri yönetimi sistemimizde yazmıştım. O zamanlar SQL ifadelerinin otomatik olarak oluşturulmasıyla uğraşıyorduk. Günler geçtikçe sizlere referans olabilecek ilerlemeler kaydettik ve yine buradayım. OLAP motoru olarak ClickHouse'u neden Apache Doris ile değiştirdiğimizi Doris tabanlı OLAP hizmetlerimizi güçlendirmek için Büyük Dil Modellerini (LLM) benimsedik. Yüksek Lisans + OLAP Amacımız dahili personelimizi SQL yazmanın zorlu öğrenme eğrisinden kurtarmaktı. Bu nedenle, LLM'yi ara madde olarak kullandık. Doğal dil sorularını SQL ifadelerine dönüştürür ve SQL'leri yürütülmek üzere OLAP motoruna gönderir. Yapay zekayla ilgili her deneyimde olduğu gibi bazı sürtüşmelerle karşılaştık: LLM, "alanlar", "satırlar", "sütunlar" ve "tablolar" gibi veri jargonlarını anlamaz. Bunun yerine, temel olarak alanların/satırların/sütunların konusu olan "kurumsal gelir" ve "DAU" gibi iş terimlerini mükemmel bir şekilde tercüme edebilirler. Bu, yalnızca analistlerin sorularını yazarken ihtiyaç duydukları metriğe atıfta bulunmak için tam olarak doğru kelimeyi kullanması durumunda iyi çalışabileceği anlamına gelir. Kullandığımız Yüksek Lisans, çıkarımda yavaştır. Cevap vermek 10 saniyeden fazla sürüyor. Ücretleri jetonla tahsil ettiğinden, maliyet etkinliği bir sorun haline geliyor. Yüksek Lisans, geniş bir kamuya açık veri seti koleksiyonu üzerinde eğitilmiş olmasına rağmen, niş bilgi konusunda yetersiz bilgi sahibidir. Bizim durumumuzda LLM indie şarkılara çok yabancı olduğundan, şarkılar veritabanımıza dahil edilse bile LLM onları doğru şekilde tanımlayamayacaktır. Bazen girdi sorularımız, bir eğitim veri setine veya bilgi tabanına dahil edilmesi zor olan yeterli ve en güncel yasal, politik, mali ve düzenleyici bilgileri gerektirir. Daha çeşitli görevleri yerine getirmek için Yüksek Lisans'ı daha geniş bilgi tabanlarına bağlamamız gerekiyor. Bu sorunları birer birer ortadan kaldırıyoruz. 1. Anlamsal bir katman 1 numaralı problem için, LLM ile OLAP motoru arasına anlamsal bir katman sunuyoruz. Bu katman iş şartlarını ilgili veri alanlarına çevirir. Çeşitli doğal dil ifadelerinden veri filtreleme koşullarını tanımlayabilir, bunları ilgili ölçümlerle ilişkilendirebilir ve ardından SQL ifadeleri oluşturabilir. Bunun yanı sıra anlamsal katman hesaplama mantığını optimize edebilir. Analistler, örneğin çok tablolu bir birleştirme gibi karmaşık bir sorgu içeren bir soru girdiğinde, anlamsal katman, anlamsal bozulmayı azaltmak için bunu birden çok tek tablolu sorguya bölebilir. 2. Yüksek Lisans ayrıştırma kuralları Yüksek Lisans kullanımında maliyet etkinliğini artırmak için, metrik hesaplama, ayrıntılı kayıt alma ve kullanıcı segmentasyonu gibi tüm senaryoların hesaplama karmaşıklığını değerlendiriyoruz. Daha sonra kurallar oluşturuyoruz ve LLM ayrıştırma adımını yalnızca karmaşık görevlere ayırıyoruz. Bu, basit hesaplama görevleri için ayrıştırmayı atlayacağı anlamına gelir. Örneğin, bir analist "bana büyük müzik platformlarının kazançlarını söyle" girişini yaptığında LLM, bu sorunun yalnızca birkaç ölçüm veya boyut gerektirdiğini belirler, dolayısıyla soruyu daha fazla ayrıştırmaz, doğrudan SQL oluşturma ve yürütme için gönderir. Bu, sorgu yanıt süresini büyük ölçüde kısaltabilir ve API masraflarını azaltabilir. 3. Şema Eşleyici ve harici bilgi tabanı Yüksek Lisans'ı niş bilgiyle güçlendirmek için Yüksek Lisans'ın yukarı akışına bir Şema Eşleyici ekledik. Şema Eşleyici, giriş sorusunu harici bir bilgi tabanına eşler ve ardından LLM ayrıştırmayı gerçekleştirir. Şema Eşleyiciyi sürekli olarak test ediyor ve optimize ediyoruz. İçeriği harici bilgi tabanında kategorilere ayırıp derecelendiriyoruz ve daha iyi anlamsal ayrıştırma sağlamak için çeşitli düzeylerde eşleme (tam metin eşleme ve bulanık eşleme) yapıyoruz. 4. Eklentiler Yüksek Lisans'ı daha fazla bilgi alanına bağlamak için eklentiler kullandık ve farklı eklenti türleri için farklı entegrasyon yöntemlerimiz var: : Bu, özellikle LLM'ye genellikle metin dosyaları olan en son düzenleme politikalarını "öğretmemiz" gerektiğinde kullanışlıdır. İlk olarak sistem, yerel metin dosyasını vektörleştirir, yerel dosyada eşleşen veya benzer terimleri bulmak için anlamsal aramalar yürütür, ilgili içerikleri çıkarır ve çıktı oluşturmak için bunları LLM ayrıştırma penceresine koyar. Yerel dosyaların yerleştirilmesi : Pazar yeri her türlü sektöre yönelik tasarlanmış üçüncü taraf eklentilerle doludur. Onlarla LLM geniş kapsamlı konuları ele alabilir. Her eklentinin kendi istemleri ve arama işlevi vardır. Giriş sorusu bir istemle karşılaştığında ilgili eklenti çağrılacaktır. Üçüncü taraf eklentiler Yukarıdaki dört optimizasyonu tamamladıktan sonra SuperSonic çerçevesi ortaya çıkıyor. SüperSonik çerçeve Şimdi size bu anlatayım: çerçeveyi Bir analist bir soru girer. Şema Eşleştiricisi soruyu harici bir bilgi tabanına eşler. Harici bilgi tabanında eşleşen alanlar varsa soru LLM tarafından ayrıştırılmayacaktır. Bunun yerine, bir metrik hesaplama formülü OLAP motorunun sorgulamaya başlamasını tetikleyecektir. Eşleşen alan yoksa soru LLM'ye girecektir. Yüksek Lisans, önceden tanımlanmış kurallara dayanarak sorunun karmaşıklık düzeyini derecelendirir. Basit bir sorgu ise doğrudan OLAP motoruna gidecektir; karmaşık bir sorgu ise anlamsal olarak ayrıştırılacak ve bir DSL ifadesine dönüştürülecektir. Anlamsal Katmanda, DSL bildirimi sorgu senaryosuna göre bölünecektir. Örneğin, çok tablolu bir birleştirme sorgusu ise, bu katman birden fazla tek tablolu sorgu SQL ifadesi üretecektir. Soru harici bilgi içeriyorsa LLM üçüncü taraf bir eklentiyi arayacaktır. Örnek: Belirli bir şarkının varyete şovlarında çalınıp çalınamayacağını yanıtlamak için sistem, şarkıyla ilgili ayrıntılar için OLAP veri ambarını alır ve onu Ticari Kullanım Sorgusu üçüncü taraf eklentisinden alınan sonuçlarla birlikte sunar. OLAP Mimarisi Bu çerçevenin OLAP kısmına gelince, birkaç tur mimari evrimden sonra mevcut OLAP boru hattımız böyle görünüyor. Ham veriler, analistler tarafından özel olarak tanımlanan etiketlere ve ölçümlere göre sıralanır. Tutarsız tanımlardan kaçınmak için etiketler ve metrikler birleşik yönetim altındadır. Daha sonra çeşitli sorgular için çeşitli etiket kümeleri ve metrik kümeleri halinde birleştirilirler. Mimari optimizasyon deneyimimizden sizin için iki ana sonuç çıkardık. 1. Bağlantıları kolaylaştırın Apache Doris'i benimsemeden önce, etiketlerin ve metriklerin hesaplanmasını hızlandırmak için ClickHouse'a ve boyutlu verileri işlemek için Elasticsearch'e sahiptik. Bu iki analitik motordur ve sorgu ifadelerini her ikisine de uyarlamamızı gerektirir. Yüksek bakım gerektiriyordu. Böylece ClickHouse'u Apache Doris ile değiştirdik ve işlevselliğini kullanarak Elasticsearch verilerini Doris'e bağladık. Bu şekilde Doris'i birleşik sorgu ağ geçidimiz haline getiriyoruz. Elasticsearch Katalog 2. Düz masaları bölün OLAP mimarimizin ilk sürümlerinde verileri düz tablolara koyardık, bu da işleri zorlaştırırdı. Öncelikle, düz tablolar yukarı akışlardan gelen tüm yazma gecikmesini emdi ve bu da veri gerçek zamanlılığında önemli bir kayba neden oldu. İkincisi, düz tablodaki verilerin %50'si nadiren güncellenen boyutlu verilerdi. Her yeni düz tabloyla birlikte, çok fazla depolama alanı tüketen bazı hacimli boyutlu veriler geldi. Bu nedenle düz tabloları metrik tablolar ve boyut tabloları olarak ayırdık. Farklı hızlarda güncellendiklerinden bunları farklı veri modellerine yerleştiririz. : Metrik verileri Apache Doris'in Aggregate Key modelinde düzenliyoruz; bu, yeni verilerin eski verilerle SUM, MAX, MIN vb. yoluyla birleştirileceği anlamına gelir. Metrik tablolar : Bu tablolar Apache Doris'in Unique Key modelindedir, yani yeni veri kaydı eskisinin yerini alacaktır. Bu, sorgu senaryolarımızda performansı büyük ölçüde artırabilir. Boyut tabloları Çoğu sorgu her iki tablo türünden de veri gerektirdiğinden, bu durum sorgularda sorun yaratıyor mu diye sorabilirsiniz. Merak etmeyin, Doris'in Toplama özelliğiyle bu sorunu çözüyoruz. Temel tabloları temel alarak, otomatik olarak çalıştıracak olan Toplama görünümleri oluşturmak için ihtiyacımız olan boyutları seçebiliriz. Bu bizi her Toplama görünümü için etiket tanımlama zorunluluğundan kurtarır ve sorguları büyük ölçüde hızlandırır. GROUP BY Diğer Hileler Apache Doris ile olan tecrübemize göre, başka bazı işlevleri de kullanışlı buluyoruz, bu yüzden onları da sizin için burada listeliyorum: 1. Gerçekleştirilmiş Görünüm Gerçekleştirilmiş Görünüm önceden hesaplanmış bir veri kümesidir. Belirli boyutlardaki verilere sıklıkla erişmeniz gerektiğinde sorguları hızlandırmanın bir yoludur. Bu senaryolarda türetilmiş etiketleri ve metrikleri orijinal olanları temel alarak tanımlarız. Örneğin Metrik 1, Metrik 2 ve Metrik 3'ü birleştirerek türetilmiş bir metrik oluşturuyoruz: . Daha sonra bunun için Materyalleştirilmiş Görünüm oluşturabiliriz. Doris'in yayın planına göre sürüm 2.1, çok tablolu Materyalleştirilmiş Görünümleri destekleyecektir ve bunu sabırsızlıkla bekliyoruz. sum(m1+m2+m3) 2. Flink-Doris-Konektörü Bu, veri alımında Tam Olarak Bir Kez garantisi içindir. Flink-Doris-Connector, bir kontrol noktası mekanizması ve iki aşamalı taahhüt uygular ve ilişkisel veritabanlarından Doris'e otomatik veri senkronizasyonuna olanak tanır. 3. Sıkıştırma Toplama görevlerinin sayısı veya veri hacmi Flink için çok fazla olduğunda, veri sıkıştırmada çok büyük gecikmeler yaşanabilir. Bunu Dikey Sıkıştırma ve Segment Sıkıştırma ile çözüyoruz. Dikey Sıkıştırma, sütunların yalnızca bir kısmının yüklenmesini destekler, böylece düz tablaları sıkıştırırken depolama tüketimini azaltabilir. Segment Sıkıştırma, veri yazma sırasında çok fazla segment oluşturulmasını önleyebilir ve aynı anda yazarken sıkıştırma yapılmasına olanak tanır. Sıradaki ne Maliyetleri azaltmak ve hizmet kullanılabilirliğini artırmak amacıyla, yeni yayımlanan Doris'in Depolama-Bilgisayar Ayrımı ve Kümeler Arası Çoğaltmasını test etmeyi planlıyoruz ve SuperSonic çerçevesi ve Apache Doris projesi hakkındaki her türlü fikir ve girdiyi benimsiyoruz.
