ClickHouse'u gerçek uygulamalarda kullanma teorisi ve pratiği. Alexander Zaitsev (2018)

Artık neredeyse her yerde çok fazla veri olmasına rağmen, analitik veritabanları hala oldukça egzotik. Yeterince bilinmiyorlar ve daha da kötüsü onları etkili bir şekilde kullanabiliyorlar. Birçoğu, diğer senaryolar için tasarlanmış MySQL veya PostgreSQL ile "kaktüs yemeye" devam ediyor, NoSQL ile sıkıntı yaşıyor veya ticari çözümler için fazla ödeme yapıyor. ClickHouse, oyunun kurallarını değiştirir ve analitik DBMS dünyasına giriş eşiğini önemli ölçüde düşürür.

BackEnd Conf 2018 raporundan olup, konuşmacının izni ile yayınlanmıştır.

Ben kimim ve neden ClickHouse'tan bahsediyorum? LifeStreet'te ClickHouse kullanan bir geliştirme direktörüyüm. Ayrıca Altinity'nin kurucusuyum. ClickHouse'u tanıtan ve Yandex'in ClickHouse'u daha başarılı yapmasına yardımcı olan bir Yandex iş ortağıdır. Ayrıca ClickHouse hakkında bilgi paylaşmaya hazır.

Ve ben Petya Zaitsev'in kardeşi değilim. Sık sık bu soru soruluyor. Hayır, biz kardeş değiliz.

ClickHouse'un şunları "herkes biliyor":

• Çok hızlı,
• Çok konforlu
• Yandex'de kullanılır.

Hangi şirketlerde ve nasıl kullanıldığı biraz daha az biliniyor.

Yandex dışında ClickHouse'un neden, nerede ve nasıl kullanıldığını anlatacağım.

Size farklı şirketlerde ClickHouse yardımıyla belirli görevlerin nasıl çözüldüğünü, görevleriniz için hangi ClickHouse araçlarını kullanabileceğinizi ve bunların farklı şirketlerde nasıl kullanıldığını anlatacağım.

ClickHouse'u farklı açılardan gösteren üç örnek seçtim. Bence ilginç olacak.

İlk soru şudur: "Neden ClickHouse'a ihtiyacımız var?". Oldukça açık bir soru gibi görünüyor, ancak birden fazla cevabı var.

• İlk cevap performans içindir. ClickHouse çok hızlıdır. ClickHouse'daki analizler de çok hızlıdır. Genellikle başka bir şeyin çok yavaş veya çok kötü olduğu durumlarda kullanılabilir.
• İkinci cevap maliyettir. Ve her şeyden önce, ölçeklendirme maliyeti. Örneğin, Vertica kesinlikle harika bir veritabanıdır. Çok fazla terabayt veriniz yoksa çok iyi çalışır. Ancak yüzlerce terabayt veya petabayt söz konusu olduğunda, bir lisans ve desteğin maliyeti oldukça önemli miktarlara ulaşıyor. Ve pahalı. Ve ClickHouse ücretsizdir.
• Üçüncü cevap işletme maliyetidir. Bu biraz farklı bir yaklaşım. RedShift harika bir analogdur. RedShift'te çok hızlı karar verebilirsiniz. İyi çalışacak ama aynı zamanda her saat, her gün ve her ay Amazon'a oldukça pahalıya ödeme yapacaksınız çünkü bu oldukça pahalı bir hizmet. Google BigQuery de. Birisi bunu kullandıysa, orada birden fazla istekte bulunabileceğinizi ve birdenbire yüzlerce dolarlık bir fatura alabileceğinizi bilir.

ClickHouse'da bu sorunlar yok.

ClickHouse şu anda nerede kullanılıyor? Yandex'e ek olarak, ClickHouse bir grup farklı işletme ve şirkette kullanılmaktadır.

• Her şeyden önce, bu web uygulama analitiğidir, yani bu Yandex'den gelen bir kullanım durumudur.
• Birçok AdTech şirketi ClickHouse kullanıyor.
• Farklı kaynaklardan işlem günlüklerini analiz etmesi gereken çok sayıda şirket.
• Birkaç şirket, güvenlik günlüklerini izlemek için ClickHouse'u kullanır. Bunları ClickHouse'a yükler, raporlar hazırlar ve ihtiyaç duydukları sonuçları alırlar.
• Şirketler bunu finansal analizde kullanmaya başlıyor, yani yavaş yavaş büyük işletmeler de ClickHouse'a yaklaşıyor.
• bulut parlaması Birisi ClickHouse'u takip ediyorsa, muhtemelen bu şirketin adını duymuştur. Bu, topluluğun önemli katkılarından biridir. Ve çok ciddi bir ClickHouse kurulumları var. Örneğin, ClickHouse için Kafka Engine'i yaptılar.
• Telekomünikasyon şirketleri kullanmaya başladı. Birkaç şirket, ClickHouse'u konsept kanıtı olarak veya zaten üretimde kullanıyor.
• Bir şirket, üretim süreçlerini izlemek için ClickHouse kullanıyor. Mikro devreleri test ediyorlar, bir sürü parametre yazıyorlar, yaklaşık 2 özellik var. Sonra oyunun iyi mi kötü mü olduğunu analiz ediyorlar.
• Blockchain analitiği. Bloxy.info diye bir Rus şirketi var. Bu, ethereum ağının bir analizidir. Bunu ClickHouse'da da yaptılar.

Ve boyut önemli değil. Küçük bir sunucu kullanan birçok şirket var. Ve sorunlarını çözmelerine izin veriyor. Hatta daha fazla şirket, çok sayıda sunucudan veya düzinelerce sunucudan oluşan büyük kümeler kullanır.

Ve kayıtlara bakarsanız, o zaman:

• Yandex: 500'den fazla sunucu, orada günde 25 milyar kayıt depolar.
• LifeStreet: 60 sunucu, günde yaklaşık 75 milyar kayıt. Yandex'den daha az sunucu, daha fazla kayıt var.
• CloudFlare: 36 sunucu, günde 200 milyar kayıt kaydediyorlar. Daha az sunucuları var ve daha da fazla veri depoluyorlar.
• Bloomberg: 102 sunucu, günde yaklaşık bir trilyon giriş. Rekortmen.

Coğrafi olarak, bu da çok fazla. Bu harita, ClickHouse'un dünyada kullanıldığı yerlerin bir ısı haritasını gösterir. Rusya, Çin, Amerika burada açıkça öne çıkıyor. Az sayıda Avrupa ülkesi var. Ve 4 küme var.

Bu karşılaştırmalı bir analizdir, kesin rakamlar aramaya gerek yoktur. Bu, Altinity web sitesinde Rusça konuşan hiç malzeme olmadığı için İngilizce materyalleri okuyan ziyaretçilerin bir analizidir. Ve Rusya, Ukrayna, Beyaz Rusya, yani topluluğun Rusça konuşan kısmı, bunlar en çok sayıda kullanıcıdır. Ardından ABD ve Kanada geliyor. Çin çok fazla yetişiyor. Altı ay önce orada neredeyse hiç Çin yoktu, şimdi Çin çoktan Avrupa'yı geride bıraktı ve büyümeye devam ediyor. Eski Avrupa da çok geride değil ve ClickHouse kullanımında lider, garip bir şekilde Fransa.

Tüm bunları neden anlatıyorum? ClickHouse'un büyük veri analizi için standart bir çözüm haline geldiğini ve halihazırda birçok yerde kullanıldığını göstermek. Kullanıyorsanız, doğru trenddesiniz. Henüz kullanmıyorsanız, yalnız kalacağınızdan ve kimsenin size yardım etmeyeceğinden korkamazsınız çünkü çoğu bunu zaten yapıyor.

Bunlar, birkaç şirkette gerçek ClickHouse kullanımına örneklerdir.

• İlk örnek bir reklam ağıdır: Vertica'dan ClickHouse'a geçiş. Ve Vertica'dan geçiş yapan veya geçiş sürecinde olan birkaç şirket biliyorum.
• İkinci örnek, ClickHouse üzerindeki işlemsel depolamadır. Bu, anti-kalıplar üzerine inşa edilmiş bir örnektir. Geliştiricilerin tavsiyesi üzerine ClickHouse'da yapılmaması gereken her şey burada yapılır. Ve o kadar etkili bir şekilde yapılır ki işe yarar. Ve tipik işlemsel çözümden çok daha iyi çalışır.
• Üçüncü örnek, ClickHouse üzerinde dağıtılmış bilgi işlemdir. ClickHouse'un Hadoop ekosistemine nasıl entegre edilebileceği hakkında bir soru vardı. Bir şirketin çok önemsiz olmayan bir görevi hesaplamak için ClickHouse'daki harita küçültme kapsayıcısına benzer bir şeyi nasıl yaptığını, veri yerelleştirmesini vb. takip ettiğini göstereceğim.

• LifeStreet, bir reklam ağıyla birlikte gelen tüm teknolojiye sahip bir Ad Tech şirketidir.
• Reklam optimizasyonu, programatik teklif verme ile uğraşıyor.
• Çok fazla veri: günde yaklaşık 10 milyar olay. Aynı zamanda, oradaki olaylar birkaç alt olaya bölünebilir.
• Bu verilerin birçok müşterisi var ve bunlar sadece insanlar değil, çok daha fazlası - bunlar programatik teklif vermeyle ilgilenen çeşitli algoritmalar.

Şirket uzun ve dikenli bir yoldan geldi. HighLoad'da bundan bahsetmiştim. İlk olarak, LifeStreet MySQL'den (Oracle'da kısa bir mola ile) Vertica'ya taşındı. Ve bununla ilgili bir hikaye bulabilirsiniz.

Ve her şey çok iyiydi, ancak verilerin arttığı ve Vertica'nın pahalı olduğu kısa sürede anlaşıldı. Bu nedenle çeşitli alternatifler arandı. Bazıları burada listelenmiştir. Ve aslında, 13. yıldan 16. yıla kadar piyasada bulunan ve işlevsellik açısından yaklaşık olarak uygun olan hemen hemen tüm veritabanlarının konsept kanıtını veya bazen performans testini yaptık. Ayrıca HighLoad'da bazılarından bahsetmiştim.

Görev, veriler büyüdüğü için ilk etapta Vertica'dan geçiş yapmaktı. Ve yıllar içinde katlanarak büyüdüler. Sonra rafa gittiler ama yine de. Ve bu büyümeyi, üzerinde bir tür analitik yapılması gereken veri miktarı için iş gereksinimlerini tahmin ederek, yakında petabaytların tartışılacağı açıktı. Ve petabaytlar için ödeme yapmak zaten çok pahalı, bu yüzden nereye gideceğimize dair bir alternatif arıyorduk.

Nereye gitmeli? Ve uzun süre nereye gidileceği hiç belli değildi, çünkü bir yandan ticari veritabanları var, iyi çalışıyor gibi görünüyorlar. Bazıları neredeyse Vertica kadar iyi çalışır, bazıları daha kötü. Ama hepsi pahalı, daha ucuzu ve daha iyisi bulunamadı.

Öte yandan, çok fazla olmayan açık kaynaklı çözümler var, yani analitik için parmakla sayılabilirler. Ve ücretsiz veya ucuzdurlar, ancak yavaştırlar. Ve genellikle gerekli ve kullanışlı işlevsellikten yoksundurlar.

Ve ticari veritabanlarındaki mallarla açık kaynaktaki tüm ücretsizleri birleştirecek hiçbir şey yoktu.

Beklenmedik bir şekilde Yandex, bir tavşan gibi şapkadan bir sihirbaz gibi ClickHouse'u çıkarana kadar hiçbir şey yoktu. Ve beklenmedik bir karardı, yine de "Neden?" Sorusunu soruyorlar, Ama yine de.

Ve 2016 yazında hemen ClickHouse'un ne olduğuna bakmaya başladık. Ve bazen Vertica'dan daha hızlı olabileceği ortaya çıktı. Farklı isteklerde farklı senaryolar test ettik. Ve sorgu yalnızca bir tablo kullanıyorsa, yani herhangi bir birleştirme (birleştirme) olmadan, ClickHouse Vertica'dan iki kat daha hızlıydı.

Çok tembel değildim ve geçen gün Yandex testlerine baktım. Orada da aynı: ClickHouse, Vertica'dan iki kat daha hızlı, bu yüzden sık sık bundan bahsediyorlar.

Ancak sorgularda birleştirmeler varsa, o zaman her şey çok açık bir şekilde ortaya çıkmaz. Ve ClickHouse, Vertica'dan iki kat daha yavaş olabilir. Ve isteği biraz düzeltip yeniden yazarsanız, bunlar yaklaşık olarak eşittir. Fena değil. Ve özgür.

Ve test sonuçlarını alıp farklı açılardan inceleyen LifeStreet, ClickHouse'a gitti.

Bu 16. yıl, hatırlatırım. Ağlayan ve kendini yaralayan ama kaktüsü yemeye devam eden fareler hakkında bir şaka gibiydi. Ve bu ayrıntılı olarak anlatıldı, bununla ilgili bir video var vs.

Bu nedenle ayrıntılı olarak konuşmayacağım, sadece sonuçlardan ve o zaman bahsetmediğim birkaç ilginç şeyden bahsedeceğim.

Sonuçlar:

• Başarılı geçiş ve bir yıldan fazla bir süredir sistem üretimde çalışıyor.
• Verimlilik ve esneklik arttı. Günlük ve daha sonra kısa bir süre için saklayabildiğimiz 10 milyar kayıttan LifeStreet artık günde 75 milyar kayıt saklıyor ve bunu 3 ay veya daha uzun süre yapabiliyor. Zirvede sayarsanız, bu saniyede bir milyon olaya kadardır. Bu sisteme, çoğu farklı robotlardan günde bir milyondan fazla SQL sorgusu geliyor.
• ClickHouse için Vertica'dan daha fazla sunucu kullanılmasına rağmen, Vertica'da oldukça pahalı SAS diskleri kullanıldığı için donanımdan da tasarruf ettiler. ClickHouse, SATA kullandı. Ve neden? Çünkü Vertica'da insert senkrondur. Ve senkronizasyon, disklerin çok fazla yavaşlamamasını ve ayrıca ağın çok fazla yavaşlamamasını gerektirir, yani oldukça pahalı bir işlemdir. Ve ClickHouse'da ekleme eşzamansızdır. Ayrıca, her zaman her şeyi yerel olarak yazabilirsiniz, bunun için ek bir maliyet yoktur, bu nedenle veriler daha yavaş sürücülerde bile Vertika'dan çok daha hızlı bir şekilde ClickHouse'a eklenebilir. Ve okumak yaklaşık olarak aynıdır. RAID'deyse SATA'da okumak, o zaman bu yeterince hızlıdır.
• Lisansla sınırlı değildir, yani 3 sunucuda 60 petabayt veri (20 sunucu bir kopyadır) ve gerçekler ve toplamalarda 6 trilyon kayıt. Vertica'da böyle bir şey karşılanamaz.

Şimdi bu örnekte pratik şeylere dönüyorum.

• İlki verimli bir şemadır. Çok şey şemaya bağlıdır.
• İkincisi, verimli SQL üretimidir.

Tipik bir OLAP sorgusu bir seçimdir. Bazı sütunlar gruplandırmaya, bazı sütunlar toplama işlevlerine gider. Küpün bir dilimi olarak temsil edilebilecek bir yer var. Grubun tamamı bir izdüşüm olarak düşünülebilir. Bu yüzden buna çok değişkenli veri analizi deniyor.

Ve genellikle bu, merkezi bir gerçek ve bu gerçeğin özellikleri yanlarda, ışınlar boyunca olduğunda, bir yıldız şeması şeklinde modellenir.

Ve fiziksel tasarım açısından, masaya nasıl oturduğu, genellikle normalleştirilmiş bir sunum yaparlar. Denormalize edebilirsiniz, ancak diskte pahalıdır ve sorgularda çok verimli değildir. Bu nedenle, genellikle normalleştirilmiş bir temsil oluştururlar, yani bir olgu tablosu ve birçok, birçok boyut tablosu.

Ancak ClickHouse'da iyi çalışmıyor. İki sebep var:

• İlki, ClickHouse'un çok iyi birleştirmelere sahip olmamasıdır, yani birleştirmeler vardır, ancak bunlar kötüdür. Kötü iken.
• İkincisi, tabloların güncellenmemesidir. Genellikle yıldız devresinin etrafındaki bu plakalarda bir şeylerin değiştirilmesi gerekir. Örneğin, müşteri adı, şirket adı vb. Ve işe yaramıyor.

Ve ClickHouse'da bundan kurtulmanın bir yolu var. hatta iki:

• Birincisi sözlüklerin kullanımıdır. Harici Sözlükler, yıldız şeması, güncellemeler vb. ile sorunu %99 oranında çözmeye yardımcı olan şeydir.
• İkincisi, dizilerin kullanılmasıdır. Diziler ayrıca birleştirmelerden ve normalleştirme sorunlarından kurtulmaya yardımcı olur.

• Katılmak gerekmez.
• yükseltilebilir. Mart 2018'den bu yana, sözlükleri kısmen, yani değişen girişleri güncellemek için belgelenmemiş bir fırsat ortaya çıktı (bunu belgelerde bulamazsınız). Pratik olarak bir masa gibidir.
• Her zaman bellekte, bu nedenle bir sözlükle birleştirmeler, diskteki bir tablodan daha hızlı çalışır ve önbellekte olduğu henüz bir gerçek değildir, büyük olasılıkla değildir.

• Birleştirmelere de ihtiyacınız yok.
• Bu kompakt bir 1'den çoğa gösterimdir.
• Ve bence diziler inekler için yapılıyor. Bunlar lambda fonksiyonları vb.

Bu kırmızı kelimeler için değil. Bu, pek çok şeyi çok basit ve zarif bir şekilde yapmanıza izin veren çok güçlü bir işlevselliktir.

Dizileri çözmeye yardımcı olan tipik örnekler. Bu örnekler yeterince basit ve açıktır:

• Etiketlere göre ara. Orada hashtag'leriniz varsa ve hashtag'e göre bazı gönderiler bulmak istiyorsanız.
• Anahtar/değer çiftlerine göre arama yapın. Bir değeri olan bazı nitelikler de vardır.
• Başka bir şeye çevirmeniz gereken anahtar listelerini saklamak.

Tüm bu görevler diziler olmadan çözülebilir. Etiketler bir satıra konabilir ve düzenli bir ifadeyle veya ayrı bir tabloda seçilebilir, ancak daha sonra birleştirmeler yapmanız gerekir.

ClickHouse'da ise herhangi bir şey yapmanıza gerek yok, hashtag'ler için string dizisini tanımlamanız veya key-value sistemleri için iç içe bir yapı yapmanız yeterli.

İç içe yapı en iyi isim olmayabilir. Bunlar, adında ortak bir kısmı ve bazı ilgili özellikleri olan iki dizidir.

Ve etikete göre arama yapmak çok kolaydır. bir işleve sahip olmak has, dizinin bir öğe içerip içermediğini kontrol eder. Herkes, konferansımızla ilgili tüm kayıtları buldu.

Subid ile arama biraz daha karmaşıktır. Önce anahtarın indeksini bulmamız, sonra bu indekse sahip elemanı almamız ve bu değerin ihtiyacımız olan şey olup olmadığını kontrol etmemiz gerekiyor. Ancak, çok basit ve kompakt.

Hepsini tek bir satırda tutsaydınız yazmak isteyeceğiniz normal ifade, öncelikle beceriksiz olurdu. İkincisi, iki diziden çok daha uzun süre çalıştı.

Başka bir örnek. Kimliği sakladığınız bir diziniz var. Ve onları isimlere çevirebilirsin. İşlev arrayMap. Bu tipik bir lambda işlevidir. Orada lambda ifadelerini iletirsiniz. Ve sözlükten her kimliğin adının değerini çıkarıyor.

Arama aynı şekilde yapılabilir. Öğelerin neyle eşleştiğini kontrol eden bir yüklem işlevi iletilir.

Bu şeyler devreyi büyük ölçüde basitleştirir ve bir dizi sorunu çözer.

Ancak karşı karşıya olduğumuz ve bahsetmek istediğim bir sonraki sorun verimli sorgulardır.

• ClickHouse'un bir sorgu planlayıcısı yoktur. Kesinlikle hayır.
• Bununla birlikte, karmaşık sorguların hala planlanması gerekmektedir. Hangi durumlarda?
• Sorguda birden fazla birleştirme varsa, bunları alt seçimlere kaydırırsınız. Ve yürütüldükleri sıra önemlidir.
• Ve ikincisi - istek dağıtılırsa. Çünkü dağıtılmış bir sorguda, yalnızca en içteki alt seçim dağıtılmış olarak yürütülür ve geri kalan her şey, bağlandığınız ve orada çalıştırdığınız bir sunucuya iletilir. Bu nedenle, çok sayıda birleştirme (birleştirme) içeren sorguları dağıttıysanız, sırayı seçmeniz gerekir.

Ve daha basit durumlarda bile, bazen zamanlayıcının işini yapmak ve sorguları biraz yeniden yazmak da gerekir.

İşte bir örnek. Sol tarafta ilk 5 ülkeyi gösteren bir sorgu var. Ve bence 2,5 saniye sürüyor. Ve sağ tarafta, aynı sorgu, ancak biraz yeniden yazılmış. Diziye göre gruplamak yerine, anahtara (int) göre gruplamaya başladık. Ve daha hızlı. Ve sonra sonuca bir sözlük bağladık. İstek 2,5 saniye yerine 1,5 saniye sürer. Bu iyi.

Yeniden yazma filtreleriyle benzer bir örnek. İşte Rusya için bir talep. 5 saniye boyunca çalışır. Bunu, bir diziyi değil, sayıları Rusya ile ilgili bazı anahtarlarla karşılaştıracak şekilde yeniden yazarsak, o zaman çok daha hızlı olacaktır.

Bu tür birçok numara var. Ayrıca, zaten hızlı çalıştığını veya tersine yavaş çalıştığını düşündüğünüz sorguları önemli ölçüde hızlandırmanıza olanak tanırlar. Daha da hızlı yapılabilirler.

• Dağıtılmış modda maksimum çalışma.
• Int'lere göre yaptığım gibi minimum türlere göre sıralama.
• Herhangi bir birleştirme (birleştirme), sözlük varsa, bunları son çare olarak yapmak daha iyidir, zaten en azından kısmen gruplandırılmış verileriniz olduğunda, birleştirme işlemi veya sözlük çağrısı daha az çağrılacak ve daha hızlı olacaktır. .
• Filtrelerin değiştirilmesi.

Başka teknikler de var ve sadece benim gösterdiklerim değil. Ve hepsi bazen sorguların yürütülmesini önemli ölçüde hızlandırabilir.

Bir sonraki örneğe geçelim. ABD'den X şirketi. O ne yapıyor?

Bir görev vardı:

• Reklam işlemlerinin çevrimdışı bağlanması.
• Farklı bağlama modellerinin modellenmesi.

senaryo nedir?

Sıradan bir ziyaretçi siteye gelir, örneğin ayda 20 kez farklı reklamlardan veya bunun gibi bazen reklamsız gelir, çünkü bu siteyi hatırlamaktadır. Bazı ürünlere bakar, sepete koyar, sepetten çıkarır. Ve sonunda bir şey satın alır.

Makul sorular: "Gerekirse reklam için kim ödeme yapmalı?" ve "Varsa, onu hangi reklam etkiledi?". Yani neden satın aldı ve bu kişi gibi insanları da satın almaya nasıl ikna edecek?

Bu sorunu çözmek için web sitesinde meydana gelen olayları doğru şekilde bağlamanız, yani aralarında bir şekilde bağlantı kurmanız gerekir. Daha sonra analiz için DWH'ye gönderilirler. Ve bu analize dayanarak, kime ve hangi reklamların gösterileceğine dair modeller oluşturun.

Bir reklam işlemi, bir reklamın gösterilmesiyle başlayan, ardından bir şey olan, ardından bir satın alma işlemi olan ve ardından bir satın alma içinde satın almalar olabilen bir dizi ilgili kullanıcı etkinliğidir. Örneğin, bu bir mobil uygulama veya bir mobil oyun ise, o zaman uygulamanın kurulumu genellikle ücretsiz olarak gerçekleşir ve orada bir şey yapılırsa bunun için para gerekebilir. Ve bir kişi uygulamada ne kadar çok harcıyorsa o kadar değerlidir. Ancak bunun için her şeyi bağlamanız gerekir.

Birçok bağlama modeli vardır.

En popüler olanlar:

• Etkileşimin bir tıklama veya bir gösterim olduğu Son Etkileşim.
• İlk Etkileşim, yani bir kişiyi siteye getiren ilk şey.
• Doğrusal kombinasyon - hepsi eşit.
• zayıflama
• Vb.

Ve her şey ilk etapta nasıl çalıştı? Runtime ve Cassandra vardı. Cassandra, işlem deposu olarak kullanıldı, yani ilgili tüm işlemler içinde saklandı. Ve Çalışma Zamanında bir olay geldiğinde, örneğin bir sayfa veya başka bir şey gösterildiğinde, Cassandra'ya bir talepte bulunuldu - böyle bir kişi var mı yok mu? Daha sonra bununla ilgili işlemler elde edildi. Ve bağlantı yapıldı.

İsteğin bir işlem kimliği olduğu için şanslıysanız, o zaman kolaydır. Ama genellikle şans yok. Bu nedenle, son işlemi veya son tıklama ile işlemi vb. bulmak gerekiyordu.

Ve bağlama son tıklamaya kadar olduğu sürece her şey çok iyi çalıştı. Çünkü diyelim ki günde 10 milyon, ayda 300 milyon tıklama var, eğer bir ay için bir pencere ayarlarsak. Ve Cassandra'da hızlı çalışması için hepsinin bellekte olması gerektiğinden, Çalışma Zamanının hızlı yanıt vermesi gerektiğinden, yaklaşık 10-15 sunucu sürdü.

Ve bir işlemi ekrana bağlamak istediklerinde, bunun o kadar da eğlenceli olmadığı hemen ortaya çıktı. Ve neden? 30 kat daha fazla olayın saklanması gerektiği görülmektedir. Ve buna göre, 30 kat daha fazla sunucuya ihtiyacınız var. Ve bunun bir tür astronomik rakam olduğu ortaya çıktı. Çalışma Zamanında önemli ölçüde daha az sunucu olmasına rağmen, bağlantıyı yapmak için 500 adede kadar sunucu tutmak, o zaman bu bir tür yanlış rakamdır. Ve ne yapacaklarını düşünmeye başladılar.

Ve ClickHouse'a gittik. Ve ClickHouse'da nasıl yapılır? İlk bakışta, bunun bir dizi anti-kalıp olduğu anlaşılıyor.

• İşlem büyüyor, ona giderek daha fazla olay bağlıyoruz, yani değiştirilebilir ve ClickHouse değiştirilebilir nesnelerle pek iyi çalışmıyor.
• Bir ziyaretçi bize geldiğinde, onun işlemlerini key olarak, ziyaret id'sine göre çekmemiz gerekiyor. Bu aynı zamanda bir nokta sorgusudur, bunu ClickHouse'da yapmazlar. Genellikle ClickHouse'un büyük taramaları vardır, ancak burada bazı kayıtlar almamız gerekiyor. Aynı zamanda bir anti-desen.
• Ayrıca işlem json'daydı ama yeniden yazmak istemediler, bu yüzden json'u yapılandırılmamış bir şekilde depolamak ve gerekirse ondan bir şeyler çıkarmak istediler. Ve bu aynı zamanda bir anti-kalıptır.

Yani, bir dizi anti-kalıp.

Ancak yine de çok iyi işleyen bir sistem ortaya çıktı.

Ne yapıldı? Kayıtlara bölünmüş günlüklerin atıldığı ClickHouse ortaya çıktı. ClickHouse'dan günlükleri alan atfedilen bir hizmet ortaya çıktı. Bundan sonra, her giriş için, ziyaret kimliğine göre, henüz işlenmemiş olabilecek işlemleri ve ayrıca anlık görüntüleri, yani zaten bağlı olan, yani önceki çalışmanın sonucu olan işlemleri aldım. Zaten onlardan mantık yaptım, doğru işlemi seçtim, yeni olaylar bağladım. Tekrar oturum açıldı. Günlük, ClickHouse'a geri döndü, yani sürekli döngüsel bir sistem. Ayrıca, orada analiz etmek için DWH'ye gittim.

Bu formda çok iyi çalışmadı. Ve ClickHouse'un işini kolaylaştırmak için, ziyaret kimliğine göre bir istek olduğunda, bu istekleri 1-000 ziyaret kimliğinden oluşan bloklara ayırdılar ve 2-000 kişi için tüm işlemleri çıkardılar. Ve sonra hepsi işe yaradı.

ClickHouse'un içine bakarsanız, tüm bunlara hizmet eden yalnızca 3 ana tablo vardır.

Günlüklerin yüklendiği ve günlüklerin neredeyse işlenmeden yüklendiği ilk tablo.

İkinci masa. Gerçekleştirilmiş bakış açısıyla, bu günlüklerden, henüz ilişkilendirilmemiş, yani ilgisiz olaylar ısırıldı. Gerçekleştirilmiş görünüm aracılığıyla, bir anlık görüntü oluşturmak için işlemler bu günlüklerden çıkarıldı. Yani, özel bir gerçekleştirilmiş görünüm, işlemin son birikmiş durumu olan bir anlık görüntü oluşturdu.

İşte SQL ile yazılmış metin. İçinde birkaç önemli şey hakkında yorum yapmak istiyorum.

İlk önemli şey, ClickHouse'da json'dan sütunları ve alanları çıkarma yeteneğidir. Yani, ClickHouse'un json ile çalışmak için bazı yöntemleri vardır. Onlar çok, çok ilkel.

VisitParamExtractInt, json'dan öznitelikleri çıkarmanıza izin verir, yani ilk isabet çalışır. Ve bu şekilde işlem kimliğini veya ziyaret kimliğini çıkarabilirsiniz. Bu zaman.

İkinci olarak, burada hileli bir somutlaştırılmış alan kullanılmaktadır. Bu ne anlama geliyor? Bu, onu tabloya ekleyemeyeceğiniz anlamına gelir, yani eklenmez, eklenirken hesaplanır ve saklanır. Yapıştırırken, ClickHouse işi sizin yerinize yapar. Ve daha sonra ihtiyacınız olan şey zaten json'dan çıkarılmıştır.

Bu durumda, gerçekleştirilmiş görünüm ham satırlar içindir. Ve pratik olarak ham günlükleri olan ilk tablo yeni kullanılır. Ve o ne yapıyor? Birincisi, sıralamayı değiştirir, yani sıralama şimdi ziyaret kimliğine göre yapılır, çünkü belirli bir kişi için onun işlemini hızlı bir şekilde çıkarmamız gerekir.

İkinci önemli şey index_granlarity'dir. MergeTree'yi gördüyseniz, varsayılan olarak index_granlarity genellikle 8'dir. Ne olduğunu? Bu, dizin seyrekliği parametresidir. ClickHouse'da dizin seyrektir, asla her girişi dizine eklemez. Bunu her 192'de bir yapıyor ve bu, hesaplanması için çok fazla veri gerektiğinde iyidir, ancak az olduğunda kötüdür, çünkü büyük bir ek yük vardır. Dizin ayrıntı düzeyini azaltırsak, ek yükü de azaltırız. Bire indirgenemez, çünkü yeterli hafıza olmayabilir. Dizin her zaman bellekte saklanır.

Anlık Görüntü ayrıca bazı diğer ilginç ClickHouse özelliklerini kullanır.

Birincisi, AggregatingMergeTree'dir. Ve AggregatingMergeTree, argMax'i depolar, yani bu, son zaman damgasına karşılık gelen işlemin durumudur. İşlemler, belirli bir ziyaretçi için her zaman oluşturulur. Ve bu işlemin en son haline bir event ekledik ve yeni bir halimiz oldu. ClickHouse'u tekrar vurdu. Ve bu gerçekleştirilmiş görünümde argMax aracılığıyla her zaman mevcut durumu elde edebiliriz.

• Bağlama, Çalışma Zamanından "ayrılmıştır".
• Ayda 3 milyara kadar işlem depolanır ve işlenir. Bu, Cassandra'da, yani tipik bir işlem sisteminde olduğundan çok daha büyük bir mertebedir.
• 2x5 ClickHouse sunucuları kümesi. 5 sunucu ve her sunucunun bir kopyası vardır. Bu, tıklamaya dayalı ilişkilendirme yapmak için Cassandra'da olduğundan bile daha azdır ve burada gösterime dayalıyız. Yani sunucu sayısını 30 kat artırmak yerine azaltmayı başardılar.

Ve son örnek, hisse senedi fiyatlarındaki değişikliklerin korelasyonlarını analiz eden finans şirketi Y'dir.

Ve görev şuydu:

• Yaklaşık 5 adet hisse bulunmaktadır.
• Her 100 milisaniyede bir alıntılar bilinmektedir.
• Veriler 10 yılda birikmiştir. Görünüşe göre, bazı şirketler için daha fazla, bazıları için daha az.
• Toplamda yaklaşık 100 milyar satır vardır.

Ve değişikliklerin korelasyonunu hesaplamak gerekiyordu.

İşte iki hisse senedi ve fiyatları. Biri yükselirken diğeri yükselirse, bu pozitif bir korelasyondur, yani biri yükselirken diğeri yükselir. Biri grafiğin sonunda olduğu gibi yükselir ve diğeri düşerse, bu negatif bir korelasyondur, yani biri yükselirken diğeri düşer.

Bu karşılıklı değişimler analiz edilerek finans piyasasında tahminler yapılabilir.

Ancak görev zor. Bunun için neler yapılıyor? Şunlara sahip 100 milyar kaydımız var: zaman, stok ve fiyat. Fiyat algoritmasından hareket eden Farkın ilk 100 milyar katını hesaplamamız gerekiyor. RunningDifference, ClickHouse'ta iki dize arasındaki farkı sırayla hesaplayan bir işlevdir.

Ve bundan sonra, korelasyonu hesaplamanız gerekir ve korelasyon her bir çift için hesaplanmalıdır. 5 hisse için çift 000 milyondur. Ve bu çok fazla, yani böyle bir korelasyon fonksiyonunu hesaplamak için 12,5 kat gereklidir.

Ve eğer biri unutursa, o zaman x ve y mat olur. örnekleme beklentisi Yani sadece kökleri ve toplamları değil, bu toplamların içinde bir toplam daha hesaplamak gerekir. Bir sürü hesaplamanın 12,5 milyon kez yapılması ve hatta saatlere göre gruplandırılması gerekiyor. Ayrıca çok saatimiz var. Ve bunu 60 saniyede yapmanız gerekiyor. Bu bir şaka.

En azından bir şekilde zamana sahip olmak gerekiyordu çünkü tüm bunlar ClickHouse gelmeden önce çok çok yavaş çalışıyordu.

Hadoop'ta, Spark'ta, Greenplum'da hesaplamaya çalıştılar. Ve tüm bunlar çok yavaş ya da pahalıydı. Yani, bir şekilde hesaplamak mümkündü, ancak o zaman pahalıydı.

Sonra ClickHouse geldi ve işler çok daha iyi hale geldi.

Size veri yerelliğiyle ilgili bir sorunumuz olduğunu hatırlatırım çünkü korelasyonlar yerelleştirilemez. Verilerin bir kısmını bir sunucuya, bir kısmını diğerine koyup hesap yapamayız, tüm verilere her yerde sahip olmamız gerekir.

Onlar ne yaptı? Başlangıçta, veriler yerelleştirilir. Her sunucu, belirli bir hisse grubunun fiyatlandırmasına ilişkin verileri depolar. Ve örtüşmezler. Bu nedenle, logReturn'ü paralel ve bağımsız olarak hesaplamak mümkündür, tüm bunlar şimdiye kadar paralel ve dağıtılmış olarak gerçekleşir.

Ardından, ifade gücünü kaybetmeden bu verileri azaltmaya karar verdik. Dizileri kullanmayı azaltın, yani her dönem için bir dizi hisse senedi ve bir dizi fiyat yapın. Bu nedenle, çok daha az veri alanı kaplar. Ve onlarla çalışmak biraz daha kolay. Bunlar neredeyse paralel işlemlerdir, yani kısmen paralel olarak okuruz ve ardından sunucuya yazarız.

Bundan sonra çoğaltılabilir. "r" harfi, bu verileri kopyaladığımız anlamına gelir. Yani, üç sunucuda da aynı verilere sahibiz - bunlar dizilerdir.

Daha sonra hesaplanması gereken bu 12,5 milyon korelasyon setinden özel bir komut dosyası ile paketler yapabilirsiniz. Yani, 2 çift korelasyona sahip 500 görev. Ve bu görev, belirli bir ClickHouse sunucusunda hesaplanacak. Tüm verilere sahiptir, çünkü veriler aynıdır ve sırayla hesaplayabilir.

Bir kez daha, göründüğü gibi. İlk olarak, bu yapıdaki tüm verilere sahibiz: zaman, hisse senetleri, fiyat. Sonra logReturn'ü hesapladık, yani aynı yapıdaki veriler, ancak fiyat yerine zaten logReturn'ümüz var. Sonra yeniden yapıldılar, yani hisse senetleri ve fiyatlar için zaman ve groupArray aldık. Çoğaltılmış. Ve ondan sonra, bir dizi görev oluşturduk ve onları sayması için ClickHouse'a besledik. Ve çalışıyor.

Kavram ispatında, görev bir alt görevdi, yani daha az veri alındı. Ve sadece üç sunucu.

Bu ilk iki aşama: Log_return'ü hesaplamak ve dizilere sarmak yaklaşık bir saat sürdü.

Ve korelasyonun hesaplanması yaklaşık 50 saattir. Ama 50 saat yetmez çünkü haftalarca çalışırlardı. Bu büyük bir başarıydı. Ve sayarsanız, bu kümede saniyede 70 kez her şey sayıldı.

Ancak en önemli şey, bu sistemin pratikte darboğaz olmaması, yani neredeyse doğrusal olarak ölçeklenmesidir. Ve kontrol ettiler. Başarıyla ölçeklendirdi.

• Doğru plan savaşın yarısıdır. Ve doğru şema, gerekli tüm ClickHouse teknolojilerinin kullanılmasıdır.
• Summing/AggregatingMergeTrees, bir durum anlık görüntüsünü toplamanıza veya özel bir durum olarak değerlendirmenize izin veren teknolojilerdir. Ve birçok şeyi büyük ölçüde basitleştirir.
• Gerçekleştirilmiş Görünümler, bir dizin sınırını atlamanıza izin verir. Belki çok net söylemedim ama logları yüklediğimizde ham loglar tek indeksli tablodaydı ve özellik logları tablodaydı yani aynı veriler sadece filtrelenmişti ama indeks tamamen diğerleri. Aynı veriler gibi görünüyor, ancak farklı sıralama. Ve Materyalleştirilmiş Görünümler, ihtiyacınız varsa, böyle bir ClickHouse sınırlamasını atlamanıza olanak tanır.
• Nokta sorguları için dizin ayrıntı düzeyini azaltın.
• Ve verileri akıllıca dağıtın, sunucu içindeki verileri mümkün olduğunca yerelleştirmeye çalışın. Ve isteklerin mümkün olduğu kadar yerelleştirmeyi de kullanmasını sağlamaya çalışın.

Ve bu kısa konuşmayı özetlersek, ClickHouse'un artık hem ticari veritabanlarının hem de açık kaynak veritabanlarının, yani özellikle analitik için, alanını sağlam bir şekilde işgal ettiğini söyleyebiliriz. Bu manzaraya mükemmel bir şekilde uyuyor. Dahası, yavaş yavaş diğerlerini dışlamaya başlar çünkü ClickHouse'a sahip olduğunuzda InfiniDB'ye ihtiyacınız olmaz. Normal SQL desteği yaparlarsa Vertika'ya kısa sürede ihtiyaç kalmayabilir. Eğlence!

-Rapor için teşekkürler! Çok ilginç! Apache Phoenix ile herhangi bir karşılaştırma var mıydı?

Hayır, kimsenin karşılaştırdığını duymadım. Biz ve Yandex, farklı veritabanları ile tüm ClickHouse karşılaştırmalarını takip etmeye çalışıyoruz. Çünkü aniden bir şeyin ClickHouse'dan daha hızlı olduğu ortaya çıkarsa, Lesha Milovidov geceleri uyuyamaz ve onu hızla hızlandırmaya başlar. Ben böyle bir karşılaştırma duymadım.

• (Aleksey Milovidov) Apache Phoenix, Hbase tarafından desteklenen bir SQL motorudur. Hbase, temel olarak anahtar-değer çalışma senaryosu içindir. Orada, her satırda, rastgele adlara sahip isteğe bağlı sayıda sütun olabilir. Bu, Hbase, Cassandra gibi sistemler hakkında söylenebilir. Ve onlar için normal şekilde çalışmayacak olan tam olarak ağır analitik sorgulardır. Ya da ClickHouse ile herhangi bir deneyiminiz yoksa iyi çalıştıklarını düşünebilirsiniz.

• Teşekkürler

  • Tünaydın Bu konuyla zaten oldukça ilgileniyorum çünkü analitik bir alt sistemim var. Ancak ClickHouse'a baktığımda, ClickHouse'un olay analizi için çok uygun olduğu hissine kapılıyorum, değiştirilebilir. Ve bir sürü büyük tabloyla çok sayıda iş verisini analiz etmem gerekirse, o zaman anladığım kadarıyla ClickHouse benim için pek uygun değil mi? Özellikle değişirlerse. Bu doğru mu yoksa bunu çürütebilecek örnekler var mı?

  • Bu doğru. Ve bu, çoğu özel analitik veri tabanı için geçerlidir. Değişken olan bir veya daha fazla büyük tablo olduğu gerçeğine ve yavaş değişen birçok küçük tabloya göre uyarlanmıştır. Yani ClickHouse, her şeyi koyabileceğiniz ve bazı çok karmaşık sorgular oluşturabileceğiniz Oracle gibi değildir. ClickHouse'u etkin bir şekilde kullanmak için, ClickHouse'da iyi çalışacak şekilde bir şema oluşturmanız gerekir. Yani, aşırı normalleştirmeden kaçının, sözlükler kullanın, daha az uzun bağlantı kurmaya çalışın. Şema bu şekilde oluşturulmuşsa, benzer iş görevleri ClickHouse'da geleneksel bir ilişkisel veritabanından çok daha verimli bir şekilde çözülebilir.

Rapor için teşekkürler! Son mali durumla ilgili bir sorum var. Analizleri vardı. Nasıl inip çıktıklarını karşılaştırmak gerekiyordu. Anladığım kadarıyla sistemi özellikle bu analitik için kurmuşsunuz? Örneğin yarın, bu verilerle ilgili başka bir rapora ihtiyaç duyarlarsa, şemayı yeniden oluşturmaları ve verileri yüklemeleri gerekir mi? Yani, talebi almak için bir tür ön işleme yapmak mı?

Elbette bu, ClickHouse'un çok özel bir görev için kullanılmasıdır. Hadoop içinde daha geleneksel bir şekilde çözülebilir. Hadoop için bu ideal bir görevdir. Ancak Hadoop'ta çok yavaş. Ve amacım, ClickHouse'un genellikle tamamen farklı yollarla çözülen görevleri çözebileceğini, ancak aynı zamanda bunu çok daha verimli bir şekilde yapabildiğini göstermek. Belirli bir görev için uyarlanmıştır. Benzer bir şeyle ilgili bir sorun varsa, o zaman benzer şekilde çözülebileceği açıktır.

Apaçık. 50 saatin işlendiğini söylediniz. En başından mı, verileri ne zaman yüklediniz veya sonuçları aldınız?

Evet, evet.

Tamam çok teşekkür ederim.

Bu, 3 sunucu kümesinde.

Selamlar! Rapor için teşekkürler! Her şey çok ilginç. Biraz işlevsellik hakkında değil, ClickHouse'un kararlılık açısından kullanımı hakkında soru soracağım. Yani, hiç var mıydı, geri yüklemek zorunda mıydınız? ClickHouse bu durumda nasıl davranır? Ve sende de bir kopyası olduğu oldu mu? Örneğin, ClickHouse hala limitinin dışına çıkıp düştüğünde bir sorunla karşılaştık.

Elbette ideal sistemler yoktur. Ve ClickHouse'un da kendi sorunları var. Ancak Yandex.Metrica'nın uzun süredir çalışmadığını duydunuz mu? Muhtemelen değil. ClickHouse üzerinde 2012-2013 yılından beri güvenilir bir şekilde çalışmaktadır. Deneyimlerim için de aynı şeyi söyleyebilirim. Hiçbir zaman tam bir başarısızlık yaşamadık. Bazı kısmi şeyler olabilir, ancak bunlar hiçbir zaman işi ciddi şekilde etkileyecek kadar kritik olmadı. Asla olmadı. ClickHouse oldukça güvenilirdir ve rastgele çökmez. Bunun için endişelenmene gerek yok. Ham bir şey değil. Bu birçok şirket tarafından kanıtlanmıştır.

Merhaba! Veri şemasını hemen düşünmeniz gerektiğini söylediniz. Ya olduysa? Verim dökülüyor ve dökülüyor. Altı ay geçti ve böyle yaşamanın imkansız olduğunu anlıyorum, verileri yeniden yüklemem ve onlarla bir şeyler yapmam gerekiyor.

Bu elbette sisteminize bağlıdır. Bunu neredeyse hiç durmadan yapmanın birkaç yolu var. Örneğin, benzersiz bir şekilde eşlenebiliyorsa farklı bir veri yapısı oluşturmak için Materyalleştirilmiş bir Görünüm oluşturabilirsiniz. Yani, ClickHouse kullanarak eşlemeye izin veriyorsa, yani bazı şeyleri ayıklayın, birincil anahtarı değiştirin, bölümlemeyi değiştirin, o zaman bir Materyalleştirilmiş Görünüm oluşturabilirsiniz. Oradaki eski verilerinizin üzerine yazın, yenileri otomatik olarak yazılacaktır. Ve sonra Materyalleştirilmiş Görünümü kullanmaya geçin, ardından kaydı değiştirin ve eski tabloyu sonlandırın. Bu genellikle kesintisiz bir yöntemdir.

Teşekkür ederim.

Kaynak: habr.com