Bu, iş yükü izolasyonu yeteneklerine derinlemesine bir giriş niteliğindedir. Ancak öncelikle iş yükü izolasyonuna neden ve ne zaman ihtiyacınız var? Aşağıdaki durumlardan herhangi biriyle karşılaşırsanız okumaya devam edin, sonunda bir çözüm bulacaksınız: Apache Doris'in Aynı kümeyi paylaşan farklı iş departmanlarınız veya kiracılarınız var ve iş yükünün karışmasını önlemek istiyorsunuz. Farklı öncelik düzeylerine sahip sorgu görevleriniz var ve kaynaklar ve yürütme açısından kritik görevlerinize (gerçek zamanlı veri analizi ve çevrimiçi işlemler gibi) öncelik vermek istiyorsunuz. İş yükü yalıtımına ihtiyacınız var ama aynı zamanda yüksek maliyet etkinliği ve kaynak kullanım oranları da istiyorsunuz. Apache Doris, Kaynak Etiketi ve İş Yükü Grubuna dayalı iş yükü izolasyonunu destekler. Kaynak Etiketi, farklı iş yükleri için CPU ve bellek kaynaklarını arka uç düğümleri düzeyinde izole ederken, İş Yükü Grubu mekanizması, daha yüksek kaynak kullanımı için bir arka uç düğümü içindeki kaynakları daha da bölebilir. https://www.youtube.com/watch?v=Wd3l5C4k8Ok&embedable=true Kaynak Etiketine dayalı kaynak izolasyonu Apache Doris'in mimarisiyle başlayalım. Doris'in iki vardır: ön uçlar (FE'ler) ve arka uçlar (BE'ler). FE düğümleri meta verileri depolar, kümeleri yönetir, kullanıcı isteklerini işler ve sorgu planlarını ayrıştırır; BE düğümleri ise hesaplama ve veri depolamadan sorumludur. Bu nedenle BE düğümleri ana kaynak tüketicileridir. tür düğümü Kaynak Etiketi tabanlı izolasyon çözümünün ana fikri, aynı etiketin BE düğümlerinin bir Kaynak Grubu oluşturduğu bir kümedeki BE düğümlerine etiketler atayarak bilgi işlem kaynaklarını gruplara bölmektir. Kaynak Grubu, veri depolama ve hesaplama birimi olarak düşünülebilir. Doris'e alınan veriler için sistem, veri kopyalarını yapılandırmalara göre farklı Kaynak Gruplarına yazacaktır. Sorgular ayrıca yürütülmek üzere karşılık gelen atanacaktır. Kaynak Gruplarına Örneğin, bir 3-BE kümesinde okuma ve yazma iş yüklerini ayırmak istiyorsanız şu adımları takip edebilirsiniz: : 2 BE'yi "Oku" etiketine ve 1 BE'yi "Yaz" etiketine bağlayın. Kaynak Etiketlerini BE düğümlerine atayın : Tablo 1'in 3 replikaya sahip olduğunu varsayarak, bunlardan 2'sini "Read" etiketine ve 1'ini "Write" etiketine bağlayın. Replika 3'e yazılan veriler Replika 1 ve Replika 2 ile senkronize edilecektir ve veri senkronizasyonu işlemi BE 1 ve BE2'nin az sayıda kaynağını tüketir. Kaynak Etiketlerini veri replikalarına atayın : SQL'lerinde "Okuma" etiketini içeren sorgular otomatik olarak "Okuma" ile etiketlenen düğümlere (bu durumda BE 1 ve BE 2) yönlendirilecektir. Veri yazma görevleri için, bunları ilgili düğüme (BE 3) yönlendirilebilmeleri için "Yazma" etiketiyle de atamanız gerekir. Bu şekilde, replika 3'ten replika 1 ve 2'ye kadar olan veri senkronizasyonu ek yükleri dışında okuma ve yazma iş yükleri arasında herhangi bir kaynak çekişmesi olmayacaktır. Kaynak Etiketlerine iş yükü grupları atayın Kaynak Etiketi aynı zamanda Apache Doris'te da olanak tanır. Örneğin, "Kullanıcı A" ile etiketlenen bilgi işlem ve depolama kaynakları yalnızca Kullanıcı A içindir, "Kullanıcı B" ile etiketlenenler ise Kullanıcı B'ye özeldir. Doris, BE tarafında Kaynak Etiketleri ile çok kiracılı kaynak izolasyonunu bu şekilde uygular. . çoklu kiracılığa BE düğümlerinin gruplara bölünmesi sağlar: yüksek düzeyde izolasyon Farklı kiracıların CPU, bellek ve G/Ç'leri fiziksel olarak yalıtılmıştır. Bir kiracı, başka bir kiracının arızalarından (süreç çökmeleri gibi) asla etkilenmeyecektir. Ancak birkaç dezavantajı var: Okuma-yazma ayrımında veri yazma durduğunda "Yazma" etiketli BE düğümleri boşta kalır. Bu, genel küme kullanımını azaltır. Çoklu kiracılık altında, aynı kiracının farklı iş yüklerini her birine ayrı BE düğümleri atayarak daha fazla yalıtmak istiyorsanız önemli maliyetlere ve düşük kaynak kullanımına katlanmanız gerekecektir. Kiracı sayısı veri kopyalarının sayısına bağlıdır. Yani 5 kiracınız varsa 5 veri kopyasına ihtiyacınız olacaktır. Bu çok büyük bir depolama yedekliliğidir. . Bunu geliştirmek için Apache Doris 2.0.0'da Workload Group'u temel alan bir iş yükü izolasyon çözümü sağladık ve bunu geliştirdik Apache Doris 2.1.0'da İş Yükü Grubuna dayalı iş yükü izolasyonu tabanlı çözüm, kaynakların daha ayrıntılı bir şekilde bölünmesini gerçekleştirir. Ayrıca BE düğümlerindeki işlemler içindeki CPU ve bellek kaynaklarını böler; bu, bir BE düğümündeki sorguların bir dereceye kadar birbirinden izole edilebileceği anlamına gelir. Bu, BE süreçlerindeki kaynak rekabetini önler ve kaynak kullanımını optimize eder. Workload Group Kullanıcılar sorguları İş Yükü Gruplarıyla ilişkilendirebilir, böylece bir sorgunun kullanabileceği CPU ve bellek kaynaklarının yüzdesi sınırlanabilir. Yüksek küme yükleri altında Doris, bir İş Yükü Grubundaki en fazla kaynak tüketen sorguları otomatik olarak sonlandırabilir. Düşük küme yükleri altında Doris, birden fazla İş Yükü Grubunun boşta kalan kaynakları paylaşmasına izin verebilir. Doris hem CPU yumuşak limitini hem de CPU sabit limitini destekler. Yumuşak sınır, İş Yükü Gruplarının sınırı aşmasına ve boşta kalan kaynakları kullanmasına olanak tanıyarak daha verimli kullanım sağlar. Kesin sınır, İş Yükü Gruplarının karşılıklı etkisini önlediği için istikrarlı performansın kesin garantisidir. (CPU yumuşak limiti ve CPU sabit limiti birbiriyle çelişkilidir. Kendi kullanım durumunuza göre bunlar arasında seçim yapabilirsiniz.) Kaynak Etiketi tabanlı çözümden farklılıkları şunlardır: Süreçler içerisinde İş Yükü Grupları oluşturulur. Birden fazla İş Yükü Grubu aynı BE düğümü içindeki kaynaklar için rekabet eder. Veri çoğaltma dağıtımının dikkate alınması, İş Yükü Grubunun yalnızca bir kaynak yönetimi yolu olması nedeniyle konunun dışındadır. CPU yumuşak sınırı CPU yumuşak sınırı, kavramsal olarak ağırlıklara benzeyen parametresi tarafından uygulanır. Daha yüksek değerine sahip İş Yükü Gruplarına, bir zaman dilimi boyunca daha fazla CPU zamanı tahsis edilecektir. cpu_share cpu_share Örneğin, Grup A, 1 ve Grup B, 9 ile yapılandırıldıysa. 10 saniyelik bir zaman diliminde, hem Grup A hem de Grup B tamamen yüklendiğinde, Grup A ve Grup B, 1'leri tüketebilecek ve Sırasıyla 9 saniye CPU süresi. cpu_share Gerçek dünyadaki durumlarda, kümedeki tüm iş yükleri tam kapasiteyle çalışmaz. Yumuşak sınır altında, Grup B'nin iş yükü düşük veya sıfırsa, Grup A 10 saniyelik CPU zamanının tamamını kullanabilecek ve böylece kümedeki genel CPU kullanımı artacaktır. Yumuşak limit esneklik ve daha yüksek kaynak kullanım oranı sağlar. Öte yandan, performans dalgalanmalarına neden olabilir. CPU sabit sınırı Apache Doris 2.1.0'daki CPU sabit sınırı, istikrarlı performansa ihtiyaç duyan kullanıcılar için tasarlanmıştır. Basit bir ifadeyle CPU donanım sınırı, bir İş Yükü Grubunun, boş CPU kaynakları olsun veya olmasın, kendi sınırından daha fazla CPU kaynağı kullanamayacağını tanımlar. Bu nasıl çalışır: Grup A'nın ve Grup B'nin ile ayarlandığını varsayalım. Hem Grup A hem de Grup B tam yükte çalışırsa, Grup A ve Grup B sırasıyla toplam CPU süresinin %10'unu ve %90'ını kullanacaktır. Fark, B Grubunun iş yükünün azalmasından kaynaklanmaktadır. Bu gibi durumlarda A Grubunun sorgu yükü ne kadar yüksek olursa olsun kendisine tahsis edilen %10 CPU kaynağından fazlasını kullanmaması gerekmektedir. cpu_hard_limit=10% cpu_hard_limit=90% Yumuşak sınırın aksine, sert sınır, esneklik ve daha yüksek kaynak kullanım oranı olasılığı pahasına istikrarlı sistem performansını garanti eder. Bellek kaynağı sınırı Bir BE düğümünün belleği aşağıdaki parçalardan oluşur: İşletim sistemi için ayrılmış bellek. İş Yükü Grubunun bellek istatistiklerinde dikkate alınmayan, sorgulanmayan bellek tarafından tüketilen bellek. Bellek, veri yazma da dahil olmak üzere sorgular tarafından tüketilir. Bu, Workload Group tarafından takip edilebilir ve kontrol edilebilir. parametresi, BE süreci içerisinde bir İş Yükü Grubunun kullanabileceği maksimum belleği (%) tanımlar. Ayrıca Kaynak Gruplarının önceliğini de etkiler. memory_limit Başlangıç durumunda, yüksek öncelikli Kaynak Grubuna daha fazla bellek ayrılacaktır. ayarını yaparak, boş alan olduğunda Kaynak Gruplarının limitlerden daha fazla bellek işgal etmesine izin verebilirsiniz. Bellek kısıtlı olduğunda Doris, taahhüt ettikleri bellek kaynaklarını geri kazanmak için görevleri iptal edecektir. Bu durumda sistem, yüksek öncelikli kaynak grupları için mümkün olduğu kadar çok bellek kaynağını tutacaktır. enable_memory_overcommit Sorgu kuyruğu Kümenin kaldırabileceğinden daha fazla yük üstlendiği görülür. Bu durumda yeni sorgu istekleri göndermek hem sonuçsuz kalacak hem de devam eden sorguları kesintiye uğratacaktır. Bunu geliştirmek için Apache Doris mekanizmasını sağlar. Kullanıcılar, kümede eş zamanlı olarak çalıştırılabilecek sorgu sayısına bir sınır koyabilir. Sorgu kuyruğu dolduğunda veya bekleme zaman aşımından sonra sorgu reddedilir, böylece yüksek yükler altında sistem kararlılığı sağlanır. sorgu kuyruğu Sorgu kuyruğu mekanizması üç parametre içerir: , ve . max_concurrency max_queue_size queue_timeout Testler CPU yumuşak limitinin ve sabit limitinin etkinliğini göstermek için birkaç test yaptık. Ortam: tek makine, 16 çekirdek, 64 GB Dağıtım: 1 FE + 1 BE Veri Kümesi: ClickBench, TPC-H Yük test aracı: Apache JMeter CPU yumuşak limit testi İki istemci başlatın ve İş Yükü Gruplarını kullanarak ve kullanmadan sırasıyla sorguları (ClickBench S23) sürekli olarak gönderin. Test sonuçlarını etkilemesini önlemek için Sayfa Önbelleğinin devre dışı bırakılması gerektiğini unutmayın. Her iki testte de iki istemcinin aktarım hızı karşılaştırıldığında şu sonuca varılabilir: , iki istemci CPU kaynaklarını eşit şekilde tüketir. İş Yükü Gruplarını yapılandırmadan ve 2:1 olarak ayarlama, iki istemcinin üretim oranı 2:1 olur. Daha yüksek bir değeriyle, İstemci 1'e daha yüksek miktarda CPU kaynağı sağlanır ve daha yüksek bir verim sağlanır. İş Yükü Gruplarını yapılandırma cpu_share cpu_share CPU sabit limit testi Bir istemci başlatın, İş Yükü Grubu için değerini ayarlayın ve ClickBench Q23'ü sırasıyla 1, 2 ve 4 eşzamanlılık düzeyinde 5 dakika boyunca çalıştırın. cpu_hard_limit=50% Sorgu eşzamanlılığı arttıkça CPU kullanım oranı %800 civarında kalıyor, bu da 8 çekirdeğin kullanıldığı anlamına geliyor. 16 çekirdekli bir makinede bu, beklendiği gibi demektir. Ayrıca CPU sabit limitleri uygulandığından eşzamanlılık arttıkça TP99 gecikmesinin artması da beklenen bir sonuçtur. %50 kullanım Simüle edilmiş üretim ortamında test edin Gerçek dünya kullanımında, gecikme kullanıcı deneyiminde daha kolay algılanabildiğinden, kullanıcılar yalnızca sorgu veriminden ziyade özellikle sorgu gecikmesiyle ilgilenirler. Bu nedenle Workload Group'un etkinliğini simüle edilmiş bir üretim ortamında doğrulamaya karar verdik. Tek tablo toplamaları ve birleştirme sorguları da dahil olmak üzere, 1 saniye içinde tamamlanması gereken sorgulardan (ClickBench Q15, Q17, Q23 ve TPC-H Q3, Q7, Q19) oluşan bir SQL seti seçtik. TPC-H veri kümesinin boyutu 100 GB'tır. Benzer şekilde İş Yükü Gruplarını yapılandırarak ve yapılandırmadan testler gerçekleştiriyoruz. Sonuçların gösterdiği gibi: (Test 1 ve 2'yi karşılaştırarak): İstemci 2'nin eş zamanlılığını çevirirken, her iki istemci de sorgu gecikmesinde 2~3 kat artış yaşar. İş Yükü Grubu Olmadan (Test 3 ve 4'ün karşılaştırılması): İstemci 2'nin eşzamanlılığı arttıkça, İstemci 1'deki performans dalgalanması çok daha küçüktür; bu, iş yükü yalıtımıyla nasıl etkili bir şekilde korunduğunun kanıtıdır. İş Yükü Grubunu Yapılandırma Öneriler ve planlar Kaynak Etiketi tabanlı çözüm, kapsamlı bir iş yükü izolasyon planıdır. İş Yükü Grubu tabanlı çözüm, kaynak yalıtımı ve kullanımı arasında daha iyi bir denge sağlar ve kararlılık garantisi için sorgu kuyruğu mekanizmasıyla tamamlanır. Peki kullanım durumunuz için hangisini seçmelisiniz? İşte önerimiz: : departmanların farklı iş kollarının aynı kümeyi paylaştığı, böylece kaynakların ve verilerin farklı kiracılar için fiziksel olarak yalıtıldığı kullanım durumları için. Kaynak Etiketi : esnek kaynak tahsisi için bir kümenin çeşitli sorgu iş yüklerini üstlendiği kullanım durumları için. İş Yükü Grubu Gelecek sürümlerde İş Yükü Grubunun kullanıcı deneyimini ve sorgu kuyruğu özelliklerini geliştirmeye devam edeceğiz: Sorguları iptal ederek bellek alanını boşaltmak acımasız bir yöntemdir. Bunu, sorgu performansında daha yüksek kararlılık sağlayacak olan disk dağıtma yoluyla uygulamayı planlıyoruz. BE'de sorgulanmayanlar tarafından tüketilen bellek, İş Yükü Grubunun bellek istatistiklerine dahil edilmediğinden, kullanıcılar BE işlem belleği kullanımı ile İş Yükü Grubu bellek kullanımı arasında bir eşitsizlik gözlemleyebilir. Karışıklığı önlemek için bu konuyu ele alacağız. Sorgu kuyruğu mekanizmasında küme yükü, maksimum sorgu eşzamanlılığı ayarlanarak kontrol edilir. BE'deki kaynak kullanılabilirliğine bağlı olarak dinamik maksimum sorgu eşzamanlılığını etkinleştirmeyi planlıyoruz. Bu, müşteri tarafında karşı baskı oluşturur ve böylece müşteriler yüksek yükler göndermeye devam ettiğinde Doris'in kullanılabilirliğini artırır. Kaynak Etiketinin ana fikri BE düğümlerini gruplandırmakken, İş Yükü Grubunun ana fikri tek bir BE düğümünün kaynaklarını daha da bölmektir. Bu fikirleri kavramak için kullanıcıların öncelikle Doris'teki BE düğümleri kavramını öğrenmeleri gerekir. Ancak operasyonel açıdan bakıldığında kullanıcıların yalnızca her bir iş yükünün kaynak tüketim yüzdesini ve küme yükü doygunluğa ulaştığında hangi önceliğe sahip olmaları gerektiğini anlaması gerekir. Bu nedenle, BE düğümleri kavramını kara kutuda tutmak gibi, kullanıcılar için öğrenme eğrisini düzleştirmenin bir yolunu bulmaya çalışacağız. Apache Doris'te iş yükü izolasyonu konusunda daha fazla yardım için katılın. Apache Doris topluluğuna
