Kuaishou Druid'in hassas veri tekilleştirmesinin tasarımı ve uygulaması
Bu paylaşım için içerik taslağı:
- Kuaishou Druid platformuna genel bakış
- Druid hassas veri tekilleştirme işlevi tasarımı
- Druid diğer iyileştirmeler
- Kuaishou Druid Yol Haritası
Kuaishou Druid platformuna genel bakış
1. İş ihtiyaçları açısından Kuaishou neden Druid'i seçti?
Kuaishounun iş özellikleri arasında ultra büyük veri ölçeği, milisaniye sorgu gecikmesi, yüksek veri gerçek zamanlı gereksinimleri, yüksek eşzamanlı sorgular, yüksek kararlılık ve yüksek şema esnekliği gereksinimleri bulunmaktadır; bu nedenle Kuaishou, temel mimari olarak Druid platformunu seçti. Druid, kesin veri tekilleştirme işlevini yerel olarak desteklemediğinden ve hızlı iş, faturalama gibi senaryoları içerecek ve kesin veri tekilleştirmeye ihtiyaç duyulacaktır. Bu nedenle, bu makale Druid platformunda hassas tekilleştirmenin nasıl gerçekleştirileceğine odaklanmaktadır. Öte yandan, Druidin harici arabirimi, SQL için uygun olmayan json biçimindedir (SQL, Druid sürüm 0.9'dan sonra kademeli olarak desteklenmektedir). Bu makalenin son bölümü, Druid platformu ile MySQL arasındaki etkileşimde yapılan bazı iyileştirmeleri kısaca açıklayacaktır.
2. Aşağıdakiler, Kuaishou Druid platformunun mimarisine odaklanmaktadır:
- Çoğu veri platformunda olduğu gibi, Kuaishou için iki ana veri kaynağı türü vardır: Kafka'ya dayalı gerçek zamanlı veri kaynakları ve hadoop'ta yerleşik çevrimdışı veri kaynakları. Bu iki veri kaynağı, sırasıyla kafka indeksi ve hadoop indeksi aracılığıyla platform-Druid modelinin çekirdeğine aktarılır.
- Druid'de veriler işten izole edilir ve soğuk ile sıcak arasında katmanlandırılır (örneğin: sabit diskteki soğuk veriler, SSD'deki sıcak veriler)
- Harici iş arayüzü açısından, API aracılığıyla iş modüllerinin kendi kendine geliştirilmesini ve Kwai BI aracılığıyla görselleştirmeyi destekler; aynı zamanda, az sayıda insanın ihtiyaçları için tablo artık desteklenmektedir (tableau, kovandan Druid'e bağlanır).
- Veri platformunun yardımcı sistemi, metrik izleme (CPU doluluğunun gerçek zamanlı izlenmesi, işlem durumu, gecikme bilgileri vb.), Prob sistemi (sorgulama, sorgulama ısısını, boyutları ve optimizasyona yardımcı olan diğer bilgileri tanımlamak için kullanılır), yönetim sistemini (orijinal ekolojide) içerir. Druid'in json arayüzüne dayanan yönetim sistemi, görevlerin görsel olarak içe aktarılması gibi yönetim işlemlerini gerçekleştirmek için özelleştirilir)
Druid hassas tekilleştirmeye genel bakış
1. Yerel Druid tekilleştirme işlevi desteği
a. Boyut sütunu
- hll'ye bağlı olarak kardinalite agg, belirsiz. Karma işlevi sorgu sırasında daha fazla CPU tüketir
- Hassas ve kaynak tüketen iç içe grup
- Community DistinctCount eklentisi, doğru, ancak çok sınırlı:
- Yalnızca tek boyut desteklenir ve karma bölümün oluştururken bu boyutu temel alması gerekir
- Aralık boyunca hesaplanamaz
b. Gösterge sütunu
- HyperUniques / Sketch, kesin olmayan, hll'ye dayalı, yutulduğunda hesaplamalar yapar, kardinalite agg'den daha yüksek performans
Sonuç: Druid, ön toplama, düşük kaynak kullanımı ve güçlü çok yönlülüğü destekleyen kesin bir tekilleştirme desteğinden yoksundur.
2. Kesin veri tekilleştirme programı
a. Doğru veri tekilleştirme şeması: hashset
Hashset kullanarak depolamanın basitlik ve genellik gibi avantajları vardır, ancak çok fazla kaynak gerektirir. Aşağıdaki şekilde gösterildiği gibi, sol üst köşedeki orijinal veriler için hashset yöntemini, boyut sütunu olarak Yıl ve gösterge sütunu olarak şehir kullanın; bunları boyut sütununa göre 2 Segmente bölün ve sağ üst köşedeki veri formatına dönüştürün; ardından gösterge sütununu Komisyoncuda, nihai sonucu elde etmek için boyutu hesaplayın. Tüm süreç aşağıdaki şekilde gösterilmektedir:
Ancak hashset tekilleştirme yönteminin kullanılması çok fazla kaynak tüketir; özellikle, ortalama 10B (toplam 500MB) uzunluğunda 5000W dizge olduğunu varsayarsak, ortada oluşturulan Hashset, 5G'ye ulaşabilen bir bellekle sonuçlanan bir dizi bağlantılı liste yapısı oluşturacaktır. Yani hafıza 10 kata kadar genişletilebilir. Bu nedenle, doğrudan hashset kullanma yöntemi tamamen uygulanamaz olabilir.
Hashset yöntemi temelinde, bazı optimizasyon fikirleri düşünülebilir: örneğin, verileri farklı makinelere dağıtmak için düğümler ekleyerek, sorgu her makinede toplanır ve sonra toplanır; başka bir yöntem, hesaplamadan önce kullanılarak MapReduce'a benzer Karıştırma modeli verileri böler. Ancak, bu iki optimizasyon fikri Druid platformunun özellikleriyle çelişiyor, bu nedenle Druid platformuna uygulanamıyorlar.
b. Kesin veri tekilleştirme şeması: sözlük kodlaması + Bitmap
Bitmap yöntemi, bir veri parçasını temsil etmek için bir bit kullanır (bu teorik olarak minimumdur). Bu şemanın fikri şudur: tekilleştirilecek veri sütununu kodlayın, dizeyi veya diğer veri türlerini int-tip kodlamaya dönüştürün ve Druid'e aktarıldıktan sonra Bitmap biçiminde saklayın; sorgulama sırasında birden çok Bitmap kesişir Sonucu almak için. Bitmap aralığı 4,2 milyardır ve kaplanan maksimum alan yaklaşık 500M'dir; alan işgalini büyük ölçüde azaltmak için sıkıştırma algoritmaları da kullanılabilir.
Bu nedenle, sözlük kodlama + Bitmap yöntemi, daha az depolama ve sorgu kaynağı kullanma avantajına sahiptir ve yapı ile sorguyu ayırabilir (yani, sözlük sorguya katılmaz); dezavantajı: sözlüğün global olarak kodlanması gerekir ve yapım süreci daha karmaşıktır.
Kylin'in bu tür bir şemayı kullandığını göz önünde bulundurarak, Kuaishou'nun sonraki optimizasyon şeması, bu şemaya dayanarak optimize etmeyi seçiyor.
3. Sözlük kodlama şeması
a. Sözlük kodlama şemasının kullanımı
Redis şeması
Redis, gerçek zamanlı kodlama gerçekleştirebilir ve hem çevrimdışı görevleri hem de gerçek zamanlı görevleri destekleyebilir.Bu nedenle, aynı şema gerçek zamanlı veri işleme ve çevrimdışı veri işleme için kullanılabilir.
Bununla birlikte, Redis'in kimlik oluşturma hızında bir darboğaz vardır, maksimum 5W / s'dir; sorgu üzerindeki baskı da büyüktür, bu da etkileşimde bazı sorunlara neden olur; aynı zamanda Redis'in kararlılığı da nispeten yüksektir.
Çevrimdışı MR şeması
Çevrimdışı MR çözümü, daha yüksek kodlama ve sorgu çıkışı elde etmek için MR'ın dağıtılmış depolamasını kullanır ve ayrıca daha yüksek hata toleransı kullanır. Ancak MR yalnızca çevrimdışı içe aktarma görevlerini destekler.
Bu iki sözlük kodlama şemasının artılarını ve eksilerini birleştirerek aşağıdaki sonuçlar elde edilir:
- Çevrimdışı görevler, saatlik görev çözümü aracılığıyla neredeyse gerçek zamanlı elde etmek için çevrimdışı MR kodlamasını kullanır
- Gerçek zamanlı görevler yalnızca orijinal int tekilleştirmeyi destekler (kodlama gerekmez)
b. Sözlük kodlama şeması modeli
Kuaishounun sözlük kodlama şeması, aşağıdaki şekilde gösterilen Kylin'in AppendTrie ağaç modeline atıfta bulunmaktadır.
Trie ağaç modeli temelde kodlama için dizeler kullanır; Kuaishou, farklı veri türlerini tek tip olarak dize türlerine dönüştürebilen ve ardından kodlama için Trie ağaç modelini kullanan çeşitli veri türlerini destekler. Trie ağaç modeli, Append'i iki şekilde uygulayabilir:
- Kimlik, düğüme göre (konuma değil) saklanır, böylece mevcut kimlik değişmeden tutulur.
- Yeni düğümlere kimlik atamasını kolaylaştırmak için mevcut modelin maksimum kimliğini kaydedin.
Ancak bu model bir problemi beraberinde getirecek: Eğer kardinalite özellikle büyükse, Trie ağacı hafızada sonsuza kadar genişleyecektir. Bellek doluluk oranını kontrol etmek için, bir eşik ayarlamak üzere tek bir alt ağaç seçilir ve aşıldığında bölünür, böylece tek bir alt ağacın bellek tüketimini kontrol eder. Bölünmeden sonra, her ağaç bir aralıktan sorumludur (HBase'deki bölge bölümüne benzer); sorgu için yalnızca bir alt ağaç gereklidir.
Guava LoadingCache tabanlı CPU kaynaklarından tasarruf etmek için, talebe göre alt ağaçlar yüklenir (yani, tembel yükleme) ve alt ağaçlar LRU yöntemi kullanılarak değiştirilir.
LRU (En Son Kullanılan), bellek yönetimi için bir değiştirme algoritmasıdır, yani bellek yetersiz olduğunda, son kullanılan alt ağaç bellekten temizlenir ve diske yüklenir. LRU algoritması, verilerin geçmiş erişim kayıtlarına dayalı verileri ortadan kaldırır. Temel fikri, "Verilere yakın zamanda erişilmişse, gelecekte erişim olasılığı da daha yüksektir."
c. Sözlüklerin eşzamanlı oluşturulması:
Sözlük, sırasıyla MVCC ve Zookeeper dağıtılmış kilitleri kullanarak eşzamanlı inşa sorunu yaşayacaktır.
MVCC'yi (hdfs üzerinde kalıcı) kullanarak, en son sürüm, okurken, inşaat için çalışmaya kopyalarken ve yeni bir sürüm numarası oluştururken kullanılacaktır; çok fazla geçmiş veri varsa, sürümlerin sayısına ve TTL'ye bağlı olacaktır. Temizlemek.
Sözlüğün oluşturulması sırasında, geçici dizin çalıştırılacaktır.Aynı anda geçici dizine yazılan birden fazla işlem varsa, çakışmalar olacaktır; bu nedenle, Zookeeper dağıtılmış kilidi devreye girer ve aynı sözlüğün aynı anda olmasını sağlamak için benzersiz konumlandırma DataSource ve sütuna dayanır. Yalnızca bir süreç olabilir.
d. Kesin veri tekilleştirmenin gerçekleştirilmesi
Benzersiz dizin depolaması ekleyin
- Bir göstergenin nasıl Serde tutulacağını, yani serileştirme ve serileştirmeyi kaldırmak için ComplexMetricSerde kullanın;
- Toplayıcıyı, kullanıcıların bir gösterge için toplama, yani toparlama için nasıl gerçekleştireceklerini tanımlamalarına izin vermek için kullanın;
- Toplayıcının yerine BufferAggregator'ı Toplayıcının Buffer sürümü kullanın;
- Göstergenin adını tanımlamak ve belirli Aggregator'ı almak için AggregatorFractory'yi kullanın.
Hassas tekilleştirmenin genel sürecine giriş
- Son segment parçalanmasını hesaplamak için DetermineConfigurationJob'u kullanın.
- BuildDictJob kullanarak, Map aynı veri tekilleştirme sütununu bir indirgeyiciye gönderir (ilk olarak Harita birleştirilebilir); her indirgeyici bir küresel sözlükler sütunu oluşturur; sözlük yapısının her sütunu ZK kilidi için geçerlidir.
- IndexGeneratorJob, sözlüğü Haritaya yükler ve veri tekilleştirme sütununu int olarak kodlar; Reducer, int'i Bitmap depolamasında toplar; her indirgeyici bir Segment oluşturur.
Bu kesin veri tekilleştirme seti nasıl kullanılır:
- İçe aktarırken benzersiz tür göstergeleri tanımlayın
- Sorgu yaparken benzersiz tür sorgusunu kullanın
e. Performans optimizasyonu ve testi
Sözlük sorgusunu optimize edin
· Bir ultra yüksek kardinalite sütunu (UHC) tekilleştirme göstergesi vardır: Her harita tarafından işlenen uhc sütun verilerinin sıralı olduğundan emin olmak ve birden fazla takasın girip çıkmasını önlemek için IndexGenerator'dan önce ClusterBy UHC görevini ekleyin.
· Çok yüksek kardinalite sütunları için birden fazla tekilleştirme göstergesi vardır: birden çok Veri Kaynağına bölün, IndexGenerator görevinin harita belleğini artırın ve sözlüğün belleğe yüklenebilmesini sağlayın
Bitmap sorgu optimizasyonu
TargetPartitionSize değerini azaltın veya numShards'ı artırın, segment sayısını artırın ve paralelliği iyileştirin.
Bitmap'i yapmak veya hesaplamak için kullanırken, satır-satır yerine batchOr yönteminin kullanılması veya önbellek sürekli olarak yenilendiğinden ve performans düşüşüne neden olduğu için alternatif G / Ç ve / veya hesaplamalardan kaçınılması önerilir. BatchOr seçimiyle ilgili olarak, rolling_bitmap bazı arayüzler sağlar. Varsayılan olarak, naive_or (hesaplama modelini geciktirmeyi deneyin) seçilir. Normalde performansı daha iyidir. Priorityqueue_or yığın sıralamayı kullanır. Her seferinde daha fazla bellek tüketen en az iki bitmap'i birleştirir. Resmi öneri kıyaslama yapmaktır. Kullanım; sonuç uzun ve sürekli bir diziyse, manuel olarak yerinde veya sıralı olarak seçebilirsiniz.
Başka bir fikir, Croaring-yüksek performanslı düşük seviyeli uygulama
Dönen bitmap, Simd'yi C dilinde uygular.Java sürümü ile karşılaştırıldığında, Smid sürümü, performansı% 80 artıran vektör talimatlarından (avx2) daha fazla yararlanır.
Kuaishou, Smid'i JNI modunda sunar, 100W Bitmap üzerinde Or işlemi gerçekleştirir, Java sürümü tek iş parçacıklı işlemi kullanır, hesaplama süresi 13 saniyedir; Croaring'i çağırmak için JNI kullanır, verilerin serileştirilmesi kaldırılır (memcpy 6.5 saniye sürer) ve hesaplama 7.5 saniye tüketir , Toplam süre 14sn'dir (java sürümünden daha yavaştır). Croaring geçici olarak yerinde seriyi kaldırmayı (ImmutableRoaringBitmap) desteklemez, bu da gerçek işletim verimliliğinin resmi% 80 artışla tutarsız olmasına neden olur.
Taşıma katmanı kodlaması
Broker ve Geçmiş verileri http protokolü aracılığıyla değiş tokuş edilir ve gzip sıkıştırması varsayılan olarak açıktır (sıkıştırmamayı, yani düz json'u da seçebilirsiniz). Test, gzip sıkıştırma işleminin çok fazla CPU tükettiğini buldu, bu nedenle 10G ağı altında sıkıştırılmaması önerilir.
Yukarıdaki sorgu optimizasyon adımlarının sırayla performans testi:
8 boyut, 1 milyar temel veri, 150 W satırları aldıktan sonra, tekilleştirme indeksi olarak yazar_id sütununu seçin; 10 tarihi makine:
Yinelemeleri kaldırmak için optimizasyon yapılmadığında, sorgu süresi 50 saniyedir;
Segment sayısını 10'a yükseltin ve sorgu süresi 7 saniyedir, bu da performansı yaklaşık 7 kat artırır;
Veya stratejisini TopluOr olarak ayarlayın ve sorgu süresi 4 sn'dir;
Gzip sıkıştırmasını kapatın, sorgu süresi 2 saniyedir.
Yukarıdakiler 1 milyar temel verinin tekilleştirilmesi için sorgu süresidir; veri tabanı 100 milyondan azsa, sorgu süresi milisaniyedir.
Druid'in diğer yönlerinde yapılan iyileştirmeler
1. Kaynak izolasyonu dağıtım planı
Bu çözüm, Druid'in resmi olarak tavsiye ettiği dağıtım çözümüdür.Druid'in hiyerarşik özelliklerini tam olarak kullanır.İşletmeye göre sıcak ve soğuk verilere göre farklı proxy'lere bölünerek her işletmenin birbirinden etkilenmemesi sağlanır.
2. Materyalleştirilmiş Görünüm
Gerçekleştirilmiş bir görünüm, bir sorgu sonucunu içeren bir veritabanı nesnesidir. Uzak verilerin yerel bir kopyası olarak anlaşılabilir veya veri tablolarının toplamına dayalı bir özet tablosu oluşturmak için kullanılabilir. Bu kopyalar salt okunurdur.
Yerel kopyayı değiştirmek istiyorsanız, gelişmiş kopyalama işlevini kullanmanız gerekir; bir tablodan veya görünümden veri çıkarmak istiyorsanız, somutlaştırılmış bir görünümden ayıklamayı kullanabilirsiniz. Gerçekleştirilmiş görünümler, veritabanının dahili mekanizması aracılığıyla düzenli olarak güncellenebilir ve bazı büyük zaman alan tablo bağlantıları, gerçekleştirilmiş görünümlerle gerçekleştirilebilir ve bu da sorgu verimliliğini artıracaktır.
a. Boyutsal materyalizasyon
Druid topluluğu 0.13 görüşleri somutlaştırmaya başladı ve topluluk boyutların somutlaşmasının farkına vardı. Uygulama senaryosu şu şekildedir: orijinal veriler çok yüksek boyutlara sahiptir ve gerçek sorguda kullanılan boyutlar, orijinal boyutların bir alt kümesidir; bu nedenle, orijinal boyutların küçük bir toplamasını yapmak daha iyidir (Kylin'deki cube ve cubeid'e benzer); bazı sıkça sorgulanan boyutlar için Materyalizasyon yapın.
b. Zaman serisi gerçekleştirme
Boyutsal materyalizasyona ek olarak, ham verilerin saat ve dakika olarak bir araya getirilmesi gibi zaman serisi gerçekleştirmeyi de içerir.
c. Fiziksel ve kimyasal etkiler
Burada asıl endişe, materyalizasyon genişleme oranı ve materyalizasyon isabet oranıdır, iki gösterge son sorgu verimliliğini etkileyecektir. Gerçekleştirme genişleme oranı, gerçekleştirildikten sonra veri depolamanın kaynak tüketimini gösterir; gerçekleştirme isabet oranı, gerçekleştirme ve gerçek uygulama senaryoları arasındaki eşleşme derecesini tanımlayabilir. Tabloda, hem ds4 hem de ds5 çok düşük bir materyalizasyon genişleme oranı ve yüksek bir materyalizasyon isabet oranı elde etti, bu nedenle sorgu verimliliği 7 ila 9 kat artırılabilir.
3. Geçmişe dönük hızlı yeniden başlatma
Kuaishou veri platformunun donanım kaynakları, 2T kapasiteli yaklaşık 12 SATA sabit disktir. Ortalama veri hacmi 10W segmenttir ve veriler 10T alan kaplar. Yeniden başlatma yaklaşık 40 dakikadır.
Druid'de, varsayılan olarak, tüm veriler yeniden başlatılırken yüklenecektir; başlangıçta 10T'yi aşan meta bilgilerin gerekli olmadığı göz önüne alındığında, verilerin yüklenmesi sorgu zamanına ertelenebilir. Bu nedenle, veri yükleme bilgilerini geciktirmek ve sütunları yalnızca sorgulama sırasında yüklemek için Guava Suppliers.memoize komutunu kullanın. Bu işlem bir parametre (LazyLoad) tarafından kontrol edilir.
(Bu kod Druid topluluğuna gönderildi: druid.segmentCache.lazyLoadOnStart (pr: 6988))
Optimizasyondan sonra, yeniden başlatma işlemi yalnızca 2 dakika sürer, bu da 20 katlık bir artış demektir.
4. Kafka Dizinindeki İyileştirmeler
a. TaskCount otomatik ölçeklendirme
TaskCount adlı Kafka dizin görevlerinin sayısı sabittir ve yoğun olmayan saatlerde kaynak israfına yol açan yoğun görevlerin sayısına göre ayarlanması gerekir.
Burada uygulanan bir optimizasyon stratejisi:
- KafkaSupervisor, DynamicTaskCountNotice ekler
- Görev cpu kullanımı ve kafka gecikme eşiğine bağlı olarak, görev sayısını% 25 artırın veya azaltın
- Süpervizörü yeniden başlatmaya gerek yok
b. İnce planlama
Orta Yöneticinin indeksleme görevi kaynak tahsisi yuvadan bellek boyutu tahsisine değiştirildi (MapReduce'un 1.0'dan 2.0'a geliştirilmesine benzer şekilde), özel optimizasyon yöntemi aşağıdaki gibidir:
- Kafka indeksleme görevi ile Hadoop indeksleme görevi arasında ayrım yapın (genellikle Hadoop indeksleme görevinin hafızayı işgal etmesi gerekmez)
- Görevi gönderirken görev bellek boyutunu belirtmeye izin verilir.
Bu optimizasyon yöntemini kullanarak, gerçek zamanlı veri görevi işleme, bellek kullanımında% 65'ten fazla tasarruf sağlayabilir ve çevrimdışı veri görevi işleme, bellek kullanımında% 87'den fazla tasarruf sağlayabilir.
5. Meta veri etkileşimi
Ara veriler, aktarım verileri olarak da bilinen meta veriler (Meta veriler), temel olarak depolama konumunu, geçmiş verileri, kaynak aramayı, dosya kaydetmeyi belirtme gibi işlevleri desteklemek için kullanılan veri özelliklerinin (mülk) bilgilerini açıklar. Bu, verilerin organizasyonu ile ilgilidir. Veri alanları ve bunların ilişkileri hakkındaki bilgiler elektronik bir katalog olarak kabul edilebilir. Kısacası, meta veriler, verilerle ilgili verilerdir.
a. Overlord ve MySQL etkileşim optimizasyonu
Overlord düğümü, görevleri almaktan, görevleri koordine etmek ve atamaktan, görevler için kilitler oluşturmaktan ve görev durumunu görev gönderene geri döndürmekten sorumludur Overlord'un iki çalışma modu vardır: yerel mod veya uzak mod (varsayılan yerel mod).
Overlord konsolu, bekleyen görevleri, çalışan görevleri, mevcut çalışanları, son oluşturulan ve biten çalışanları vb. Görüntüleyebilir.
Segment, Druid'deki en temel veri depolama birimidir.Belirli bir veri kaynağına (dataSource) ait verilerin bir kısmına karşılık gelen tüm boyut değerlerini, ölçüm değerlerini, zaman boyutlarını ve indeksleri belirli bir aralıkta (aralık) sütun şeklinde depolar.
Segmentin mantıksal ad yapısı şu şekildedir:
< veri kaynağı > < intervalStart > < intervalEnd > < versiyon > < partitionNum >
< veri kaynağı > Veri kaynağını (veya tabloyu) temsil eder; < intervalStart > ile < intervalEnd > Dönemin başlangıç ve bitiş zamanını sırasıyla belirtin; < versiyon > Birden çok kez yüklenen aynı verilere karşılık gelen Segmenti ayırt etmek için kullanılan sürüm numarasını gösterir; < partitionNum > Bölüm numarasını temsil eder (her aralıkta birden fazla bölüm olabilir)
Segmentler, HDFS'de fiziksel depolama yolu altında iki dosya içerir: descriptor.json ve index.zip. İlki, Segmentin açıklama dosyasını kaydeder (örnekler için aşağıdaki tabloya bakın) ve içeriği ayrıca Druid kümesinin meta verilerinin druid_segments tablosunda saklanır; index.zip veri dosyasıdır.
Kodu kopyala
Açıklayıcı dosya descriptor.json örneği: { "dataSource": "AD_active_user", "aralık": "2018-04-01T00: 00: 00.000 + 08: 00 / 2018-04-02T00: 00: 00.000 + 08: 00", "sürüm": "2018-04-01T00: 04: 07.022 + 08: 00", "loadSpec": { "type": "hdfs", "yol": "/druid/segments/AD_active_user/20180401T000000.000+0800_20180402T000000.000+0800/2018-04-01T00_04_07.022+08_00/1/index.zip" }, "boyutlar": "appkey, spreadid, pkgid", "metrics": "myMetrics, count, offsetHyperLogLog", "shardSpec": { "type": "numaralı", "partitionNum": 1, "bölümler": 0 }, "binaryVersion": 9, "boyut": 168627, "tanımlayıcı": "AD_active_user_2018-04-01T00: 00: 00.000 + 08: 00_2018-04-02T00: 00: 00.000 + 08: 00_2018-04-01T00: 04: 07.022 + 08: 00_1" }Druid_segments indeksini (dataSource, used, end) artırın, sorgu süresini 10 saniyeden 1 saniyeye optimize edin.
b. Koordinatör ve MySQL etkileşim optimizasyonu
Druid'in Koordinatör düğümü esas olarak segment yönetimi ve dağıtımından sorumludur. Özellikle, Koordinatör, geçmiş düğümlerle yapılandırma ve iletişime dayalı olarak Segmentleri yükleyecek veya atacaktır. Druid Koordinatörü, yeni Segmentlerin yüklenmesinden, süresi dolan Segmentlerin atılmasından, Segment kopyalarının yönetilmesinden ve Segment yük dengelemesinden sorumludur.
Koordinatör, konfigürasyon parametrelerinde ayarlanan olaylara göre periyodik olarak çalışacak ve her bir spesifik işlem yürütülmeden önce kümenin durumunu tahmin edecektir. Aracı düğümü ve geçmiş düğümüne benzer şekilde, Koordinatör düğümü de, küme bilgisinin değiş tokuşu için Zookeeper kümesiyle bir bağlantıyı sürdürecektir. Koordinatör aynı zamanda Segment ve kural bilgilerini depolayan veri kaynağı ile iletişimi de sürdürecektir. Kullanılabilir Segmentler Segment tablosunda saklanacak ve küme tarafından yüklenmesi gereken tüm Segmentler listelenecektir. Kural, kural tablosunda saklanır ve Segment ile nasıl başa çıkılacağını gösterir.
Segment keşfi
Okumaları artırmak, druid_segments için indeksler (kullanılan, oluşturulan_date) eklemek ve sorgu süresini 1,7 dakikadan 30 ms'ye optimize etmek için Koordinatör'deki varsayılan tam tarama druid_segments tablosunu değiştirin.
Tüm koordinasyon döngüsü
- Daha önce en son segmenti yükleme önceliğini sağlamak için zamana göre sıralamak için TreeSet kullanılan Segment, şimdi ConcurrentHashSet olarak optimize edilmiştir ve en son gün ve bir gün öncesine ait iki kümeye bölünmüştür, en son günü ilk olarak çalıştırın;
- Kuralları uygularken, önce küme kopyasının LoadRule yapılandırmasıyla tutarlı olup olmadığına karar verin, evet ise, eşzamanlılığı iyileştirmek için atlayın;
- Temizleme ve gölgeleme işlemlerinin iki işlemi birleştirildi;
- Sorgu süresi 3 dakikadan 30 saniyeye kadar optimize edilmiştir.
Kuaishou Druid Yol Haritası
1. Çevrimiçi
Bu yıl, çevrimiçi iş için SLA sağlamaya odaklanarak ve aynı zamanda çevrimiçi iş için otorite yönetimine odaklanarak çoklu kümelenme ve yüksek kullanılabilirlik elde edeceğiz.
2. Kullanım kolaylığı
Kuaishou'nun BI ürünleri uygun şekilde yükseltilip optimize edilirken SQL desteğini gerçekleştirin.
3. Performans ve optimizasyon (Druid kernel için toplulukla işbirliği yapın)
- Uyarlanabilir gerçekleştirilmiş görünüm, akıllı
- Sayısal dizin
- Vektorizasyon motoru
Son olarak, topluluğa gönderdiğimiz kodu ekleyin:
https://github.com/apache/incubator-druid/pull/7594 (hassas tekilleştirme işlevi)
https://github.com/apache/incubator-druid/pull/6988 (tarihsel hızlı yeniden başlatma)
yazar hakkında:
Kuaishou büyük veri mimarisi ekibinin Ar-Ge mühendisi olan Deng Fanyuan, Zhejiang Üniversitesi'nden mezun oldu, şu anda Kuaishou Druid platformunun Ar-Ge'sinden sorumlu olan Baidu ve Shell'de çalıştı, altta yatan kümenin ve OLAP motor araştırma ve geliştirmesinin geliştirilmesinde ve dağıtılmış sistemlerin optimizasyonunda uzun yıllara dayanan deneyime sahip. / kylin / druid ve diğer topluluklar kodla katkıda bulundu.
Bu makale DataFun topluluğundan geliyor
Orijinal bağlantı :
https://mp.weixin.qq.com/s/jDW1sordtki-O5-tsVE94g
