Baidu Akıllı İzleme Senaryosunda HBase Uygulaması
Baidunun büyük ölçekli zaman serisi veri depolama dizisi makalelerinin tanıtılmasıyla, okuyucular artık Baidunun akıllı izleme sistemi Noahın TSDB'sine aşina değil. Esas olarak Noah izleme sisteminin TSDB'sini depolamak için kullanılıyor. Zaman serisi gösterge verileri , Donanım ve yazılım kullanılabilirliği göstergeleri, kaynak kullanım göstergeleri ve performans göstergeleri dahil ancak bunlarla sınırlı değildir. "Baidu Büyük Ölçekli Zaman Serisi Veri Depolama (2) | Depolama Seçimi ve Veri Modeli Tasarımı" başlıklı makalede belirtildiği gibi, Noah-TSDB, temel depolama alanı olarak HBase temel alınarak bağımsız olarak geliştirilmiştir ve mükemmel performansı HBase'in katkısından ayrılamaz. . Bugün, Baidu'nun akıllı izleme sahnesindeki HBase ile ilgili pratik deneyimden bahsedeceğim, kısaca HBase'i tanıtmama izin verin.
HBase mimarisine giriş
HBase, Java tabanlı, açık kaynak kodlu, ilişkisel olmayan, sütun yönelimli depolamaya dayalı, dağıtılmış ve ölçeklenebilir bir büyük veri depolama veritabanıdır. HBase kümesi esas olarak iki rolden oluşur: HMater ve RegionServer Alt katman, HDFS'yi bir depolama tesisi olarak kullanır ve küme, Zookeeper'ın yardımıyla yönetilir. Mimarisi aşağıdaki şekilde gösterilmiştir:
Şekil 1 HBase mimari diyagramı
HBase'deki ilgili bileşenlerin rolünü kısaca tanıtın:
- HMaster
HMaster tüm küme içindir beyin , Veri tablosu operasyonu, küme yük dengeleme ve arıza kurtarma gibi küme yönetiminden sorumludur.
- Bölge Sunucusu
HBase tabloyu birçok davranış birimine ayırır Fragman , Her segmente Bölge adı verilir. Bu Bölgeler, yönetim için RegionServer'a atanır. Okuma ve yazma sürecinde, verilerin bulunduğu RegionServer'ı bulduktan sonra, İstemci ve RegionServer verileri okumak ve yazmak için doğrudan etkileşime girer.
- Hayvan bakıcısı
HBase büyük ölçekli dağıtılmış bir sistem olduğundan, Zookeeper'ın rolü çok önemlidir. Öncelikle Zookeeper, HMaster HA çözümü olarak en az bir HMaster'ın çalışmasını sağlar. İkinci olarak, Zookeeper, RegionServer'ı kalp atışı mekanizması aracılığıyla inceler ve RegionServer başarısız olduğunda, HMaster'ı hatayı ele alması için derhal bilgilendirir. Son olarak, Zookeeper, global meta bilgileri tutan META tablosuna giden yolu kaydeder İstemci HBase kümesiyle ilk kez etkileşime girdiğinde, hedef verilerin bulunduğu RegionServer'ı elde etmek için META tablosunu kullanması gerekir.
Yukarıda kısaca HBase mimarisi ve her bir bileşenin temel bilgileri tanıtılmaktadır Aşağıda, Baidu'nun en büyük zaman serisi veritabanı senaryosunda HBase kullanırken karşılaşılan bazı tipik sorunları ve optimizasyon şemalarını sizlerle paylaşacağım.
Sıcak Sorunlar
Namlu etkisini herkes bilir TSDB sistemi için sıcak Bölgenin bulunduğu RegionServer tüm "kova" nın en kısa kapasitesini etkileyen karttır. İdeal olarak, HBase'deki tüm istekler tüm RgionServers'ın tüm bölgelerine eşit olarak dağıtılmalıdır.Bir tek bölgenin aldığı okuma ve yazma taleplerinin sayısı diğer bölgelerin sayısını büyük ölçüde aştığında, bulunduğu bölge bir sıcak nokta haline gelebilir.
Şekil 2 Bölge Sunucusu bilgileri (Bu resmin kaynağı Baidu'nun gerçek verileri değildir)
Noah-TSDB, ilk günlerde meta veri tablolarının mantıksız izleme tasarımının neden olduğu sorunlu noktalar sorunuyla karşılaştı. O sırada Ar-Ge öğrencileri Noah-TSDB'yi aldı Yazma modülü kuyruğu engellendi Noah izleme sisteminden Noah'ın iş alarmları, HBase'e erişimin aynı zaman aralığında önemli ölçüde arttığını görebiliyoruz. HBase'deki bireysel RegionServer'lar sıklıkla GC gerçekleştirir, ağ G / Ç ve disk G / Ç'leri yoğundur ve işlem kuyruğundaki bekleyen istekler ciddi şekilde birikir ve yük diğer RegionServer'lardan önemli ölçüde daha yüksektir. Anormal RegionServer'ın günlükleri kontrol edildiğinde, aynı Bölgeye erişmek için çok sayıda istek olduğu bulundu: "tsdb-meta, *** 1.". İlk konumlandırma Bölge kaynaklıdır Yük çok yüksek , Bu da bulunduğu RegionServer'ın bir sıcak nokta haline gelmesine neden olur ve bu da sistemin veriminin düşmesine ve yukarı akış yazma modülü taleplerinin yığılmasına neden olur.
tsdb-meta, izleme göstergelerinin adı ve dönemi gibi meta bilgileri depolamak için kullanılan bir tablodur.Tabloda kırmızı dolu satırlar, sahip oldukları veri miktarının normal seviyeyi aştığını gösterir. Tablo yapısı aşağıdaki gibidir:
Tablo 1 Orijinal tsdb-meta tablosu
Yukarıdaki depolama yapısını analiz ederek şunları bilebiliriz:
Özetle, tek tek izleme nesnelerinin Çok fazla izleme göstergesi Zaman zaman tsdb-meta'nın sıcak sorunları olabilir. Aynı zamanda, sıcak noktalar haline gelen izleme nesneleri tarafından sahip olunan izleme göstergelerinin sayısının normal düzeyin yaklaşık 20 katı olduğunu doğrulayarak hatanın nedenini daha da doğruladık.
Temel nedeni bulduktan sonra, bu sorunu iki açıdan çözmeye karar verdik. bir taraftan, İzlenen nesnenin sahip olduğu gösterge sayısını düzenli olarak sayın , Anormal izleme yapılandırması ve mantıksız kullanım nedeniyle bireysel izleme nesnelerine ait aşırı izleme göstergeleri sorununu hemen keşfedin. İkinci yön, tsdb-meta tablo yapısının dönüştürülmesidir ve orijinal sütun tabanlı veriler, Parçayı satır bazında genişlet , Verileri tamamen düzleştirin ve yük dengelemeyi gerçekleştirmek için HBase'in otomatik parçalama mekanizmasını kullanın. İlk husus, esas olarak, işletme düzeyinde mantıksız kullanıma yönelik manuel müdahaledir. Bugün esas olarak ikinci konuya odaklanacağım.
- Tsdb-meta tablosunun şema dönüşümü
Önceki makale, aşırı tek satırlı verinin neden olduğu sıcak sorunları önlemek için genel olarak tablo yapısı dönüşümü fikrini tanıttı. İzlenen nesnenin ad bilgisini ve izlenen göstergeyi satır anahtarı olarak kullanırız ve gösterge bilgilerinin geri kalanını depolamak için yalnızca bir sütunu saklarız ve çok büyük tek satırlık verinin neden olduğu sorunlardan kaçınırız.
Tablo 2 Optimize edilmiş tsdb-meta tablosu
- Ön bölüm
Tsdb-meta tablosunun optimizasyonundan sonra, üretim ortamında verileri depolayan tsdb-data tablosunun da sıcak sorunları olduğunu gördük. tsdb-data, izleme göstergelerinin değerlerini saklamak için kullanılan bir tablodur.Üretim ortamı, zaman aralığına göre tablolara bölünür ve her iki günde bir veriler bir tabloda saklanır. Verinin satır anahtarı, ts_uid karakteristik değişkeni ve veriler karma hale getirildikten sonraki zaman tabanı timestamp_base'den oluşur.Farklı izleme göstergelerinin verileri, satır tuşlarının sözlük sırasına göre HBase depolama özelliği kullanılarak farklı bölgelere ve aynı izleme nesnesine hash edilir. Endeks verileri, sorguyu optimize etme etkisine ulaşmak için düzenlenir. Tsdb-veri tablosuna yapılan günlük ziyaretlerin geniş tabanı nedeniyle, izlenen bir nesnenin sahip olduğu gösterge sayısı ortalama seviyeden yüksek olduğunda, izlenen nesnenin izleme göstergeleri aynı Bölgeye yüksek olasılıkla atanacak ve bu da bölgenin çok büyük olmasına neden olacaktır. Bir sıcak nokta haline geldiğinde, küme, yük dengeleme durumunu sürdüremeyecek kadar büyük olan bölgeyi böler. Sık sık bölünmüş işlemler çok fazla kaynak tüketecek ve RegionServer'ın verimini etkileyecektir. Çok büyük Bölgelerin neden olduğu sıcak noktaları çözmek için Veri tablosunu önceden bölümleyin Yöntemler.
Tsdb-veri tablosunu ön bölümlere ayırırken, yalnızca bölge sayısını belirterek ön bölümlemenin etkisinin ideal olmadığını, çünkü gerçek yazma hacmi ve yuva tahsisi eşit olmayacaktır. HBase veri tablosu, depolanan gerçek veri miktarı yerine satır anahtarının bayt boşluğuna göre eşit olarak bölünür. Aşağıdaki şekilde gösterildiği gibi, şekildeki kırmızı kareler gerçek depolanan verileri temsil eder ve beyaz kareler gerçek veriler olmadan satırları temsil eder.
Şekil 3 Orijinal Bölgenin Önceden Bölümlenmesi
Yukarıdaki şekilde gösterildiği gibi, veri tablosu satır anahtarının bayt boşluğuna göre 3 bölgeye bölünmüş olmasına rağmen, Bölge 3'te depolanan gerçek veri miktarının Bölge 1 ve Bölge 2'den çok daha büyük olduğu açıktır. Bu durumda, Bölge 3 bir sıcak nokta haline gelebilir. Bu durumu iyileştirmek için Noah-TSDB, tabloyu eşit aralıklarla bölmek için üretim ortamındaki tsdb-data tablosunun özelliklerini birleştirir ve yeni tabloyu geçmiş tablonun kullanımına göre önceden bölümlemeye karar verir. Üretim ortamında üretilen gerçek satır anahtarına ve beklenen bölme boyutuna göre Bölge sınır değeri hesaplanır ve ardından tablo, sınır değerine göre benzer gerçek su seviyesine sahip Bölgelere bölünür, böylece her Bölgenin slot boyutu farklı olsa da, her Bölgenin gerçek büyüklüğü Depolama miktarı eşdeğerdir ve sıcak nokta riskini daha da azaltır.
Şekil 4 Optimizasyondan sonra bölge ön bölümlemesi
Bölge sayısı makul bir şekilde nasıl belirlenir
Yukarıda tanıtılan ön bölümleme stratejisinde, üretim ortamının fiili kullanımına ek olarak, makine kaynakları ve bölünmüş eşik gibi sistem parametrelerine dayalı olarak uygun Bölge büyüklüğünün tahmin edilmesi gerekir. Bölge boyutu belirlendikten sonra, genel olarak tahmin edebiliriz Bölge sayısı. Öyleyse, mevcut kümenin ayarlanmış Bölge sayısını taşıyıp taşıyamayacağına nasıl karar verilir? Bölge ise Mantıksız miktar Tehlikeler nelerdir? Bölge sayısının kümelenme üzerindeki etkisini tartışmadan önce, önce bazı temel bilgileri anlayalım:
Özetle, bir yandan, aynı RegionServer Memstore'u paylaştığı için, çok fazla Bölge Memstore Flush sıklığının daha hızlı olmasına, oluşturulan HFile'ların artmasına ve HBase'in sıkıştırmaya devam etmesine neden olur. Fırtınayı birleştir . Öte yandan, HBase Memstore'u düzenli olarak temizlediğinden, her yıkama yapıldığında, her bölgenin her sütun ailesine karşılık gelen Memstore'un dosyaya yazılması ve HDFS'de depolanması gerekir. Bölge ne kadar fazlaysa, her seferinde işlenmesi gereken dosya sayısı o kadar fazla olur. Rastgele bir gecikme mekanizması olsa bile, kısa sürede dosya oluşturma ve veri geçişi, küme yükünü artıracak, bu da anlık görüntü zaman aşımına, istemci zaman aşımına ve toplu yükleme zaman aşımına neden olabilir ve TSDB sisteminin performansını düşürebilir. Bu nedenle, çok fazla bölge sistem verimini azaltacaktır.
Çok az Bölge Sistem performansını azaltın . Veri miktarı aynı kaldığında, bölge sayısı çok küçük olduğu için, tek bir bölge çok büyük ve her bölge tarafından işlenen yazma taleplerinin sayısı çok yüksek olduğu için. Temizleme hızı yavaşça yazma hızına ve fazla mesaiye yakalandığında, Yazmaları engelleyecek, RPC'yi etkileyecek ve ardından HBase'in genel yazma ve sorgusunu etkileyecek ve sistemin verimini azaltacaktır.
Bölge sayısının mantıksız bir şekilde ayarlanması, TSDB sisteminin genel performansını ve güvenilirliğini azaltacaktır. Genel olarak, tek bir RegionServer tarafından yönetilen bölge sayısı için önerilen hesaplama yöntemi aşağıdaki gibidir:
Kodu kopyala
# {Bölge} = (RS belleği) * (toplam memstore kesri) / ((memstore boyutu) * (# {sütun aileleri}))Örneğin, RegionServer parametreleri aşağıdaki gibiyse:
O zaman # {Bölge} = 20 * 1024 * 0.4 / (128 * 2) = 32. Bu formül, tüm bölgelerin aynı oranda yazıldığı varsayımına dayanmaktadır.Sadece bazı bölgeler gerçekten veri yazıyorsa, sonuç orana göre ayarlanabilir ve işletme ile birleştirilebilir. Örneğin Noah-TSDB senaryosunda veriler zamana göre tablolara bölünür.Genel olarak iki günlük veriler bir veri tablosunda depolanır ve veri yazma en yakın tabloda yoğunlaştırılır, bu nedenle yazılan gerçek aktif bölge sayısı Bölgelerin toplam sayısı, dolayısıyla her bir RegionServer tarafından yönetilen gerçek Bölge sayısı, yukarıdaki formülle doğrudan hesaplanan sonucun yaklaşık 3 katıdır.
Tek bir Bölge Sunucusu tarafından yönetilen toplam Bölge sayısını ve Bölge sayısını tahmin ettikten sonra, makul bir şekilde ilerleyebilirsiniz. Kapasite planlaması , Küme ayarlandığında gerekli makine kaynaklarını tahmin edin.
sonuç olarak
Yukarıdakiler bugün tanıtılan tüm içeriktir HBase kullanımıyla ilgili bazı pratik deneyimleri kısaca paylaşacağım. Aslında, fiili kullanımda, HBase'in çok ağır olduğunu ve işletme ve bakım maliyetlerinin yüksek olduğunu da gördük.Ayrıca araştırma ve mimari yükseltmeleri yapmaya devam ediyoruz. Herhangi bir iyi öneriniz varsa, lütfen bize bildirmekten çekinmeyin. Ayrıca yazıda yetersiz bir anlayış veya sapma varsa lütfen beni düzeltin.
yazar hakkında
Zhang Yangyang, Baidu kıdemli araştırma ve geliştirme mühendisi. Baidu'nun akıllı operasyon ve bakım ürününün (Noah) dağıtılmış zaman serisi veri tabanının ve genel kota yönetimi platformunun tasarımından ve geliştirilmesinden sorumludur ve dağıtılmış depolama ve kota yönetimi yönünde kapsamlı pratik deneyime sahiptir.
Bu makale, resmi AIOps Intelligent Operation and Maintenance hesabından (ID: AI_Ops) çoğaltılmıştır.
Orijinal bağlantı: https://mp.weixin.qq.com/s/M_teW4hNNaLWbWghA02j9A
