Hadoop, 3.x çağını başlattı: Eski büyük veri hegemonu, bulut bilişimin zorluklarına nasıl yanıt veriyor?
Depolamanın üç evrim yönü
Depolama, temel olarak üç yönde gelişiyor: Ölçeklenebilirlik, Bulut ve Makine Öğrenimi.
Ölçeklenebilirlik temel olarak Hadoop'un dağıtılmış dosya sistemi HDFS'sinin ölçeklenebilirliği iyileştirmek için hala ihtiyaç ve alana sahip olduğu anlamına gelir; bu, daha sonra ayrıntılı olarak tartışılacaktır. Bulut da çok önemli bir yön. Bulutta nesne depolaması, bulut büyük verileri için varsayılan depolama alanı olarak HDFS'nin yerini bile aldı, bu nedenle HDFS'nin bulut nesne depolamayla nasıl çalıştığı önemli bir trend. . Öte yandan, makine öğrenimi yapay zekasının yükselişiyle, veri depolama perspektifinden bakıldığında, bu geleneksel büyük veri depolama yöntemlerinden çok farklıdır.Örneğin, birçok yeni senaryoyu ve yeni mücadele.
Artan ölçeklenebilirlik
Öncelikle ölçeklenebilirlik konusuna bakalım, önce HDFS mimarisini gözden geçirelim.
Şekilde gösterildiği gibi, Ana düğümde temel olarak iki çalışma bölümü vardır, yani Namenode: Biri ad alanı yönetimi ve diğeri veri bloğu yönetimidir. İş bölümü de çok açıktır: İlki, dosya yolundan veri bloğu kimliğine kadar eşlemeyi sürdürmekten sorumludur ve ikincisi, veri bloğu kimliğinden Datanode üzerindeki veri bloğunun konumuna eşlemeden sorumludur. Veri erişimi için uygun olan dosya yolundan belirli veri bloğu saklama konumunu bulmak için iki eşleme birleştirilebilir.
Burada birkaç temel özellik vardır:
Bu mimarinin güçlü yönleri aynı zamanda zayıf yönleridir. Küme 4000'den fazla düğüme genişletildiğinde ve 500 milyondan fazla dosya depolandığında, tüm meta verilerin (ad alanı, blok yönetimi vb.) Namenode belleğinde saklanması ve eşzamanlı dosya işlemleri ve verilerin dikkate alınması gerektiğini hayal edin. Blok raporlama ve RPC yanıtı gibi faktörler şu anda genişleme darboğazlarıyla karşılaşacaktır. Daha da önemlisi, küme çok sayıda küçük dosya depolarsa, bu darboğaz dönemi daha erken gelecektir.
Yukarıdan da görebileceğiniz gibi, Namenode kolayca tüm kümenin ölçeklenebilirliğinin darboğazı haline gelebilir, bu nedenle pek çok optimizasyon buna odaklanmıştır. İlk önce gözlemci Namenode'nin özelliğine bakın. Namenode erişiminin yarısından fazlasının okuma erişimi olduğunu fark ettik ve yüksek kullanılabilirlik elde etmek için HDFS zaten bir aktif bekleme mimarisi uyguladı. Okuma talebine önceden boşta duran Namenode tarafından yanıt verilebiliyorsa, birincil Namenode üzerindeki basınç etkili bir şekilde azaltılabilir. Topluluk tarafından bildirilen bazı üretim kümelerinin gerçek ölçümlerinden, bu özelliğin ana Namenode üzerindeki baskının yaklaşık% 20'sini hafifletebileceği görülebilir.
Ardından, Namenode Federasyonu Özelliğine bir göz atalım. Bu özelliğin iki sürümü vardır: Birincisi erken bir uygulama Kümenin tüm düğümlerini farklı alt kümelere bölerek, alt kümelerin bağımsız ad alanları vardır ve kullanıcıların / istemcilerin alt kümelerin ad alanını açıkça belirtmeleri gerekir. Bu yaklaşımın dezavantajı açıktır, yani mantıksal olarak tüm veriler birleşik bir ad alanını kullanamaz ve birden çok küme arasında dengelenemez.
Diğeri ise yeni geliştirilen Router Based Federation (RBF) özelliğidir. Bu özelliğin tasarım fikri daha genel bir yoldur, YARN da benzer bir şema benimser. Temel tasarım konsepti, iki modül içeren ayrı bir federasyon katmanı sağlamaktır: Router ve State Store. Yönlendirme, Namenode ile aynı hizmeti sağlar, ancak tüm ziyaretler yönlendirme yoluyla karşılık gelen HDFS alt kümesine girer ve ilgili sonuçları geri bildirir. Durum depolaması, kayıtları izlemek ve karşılık gelen hizmetleri sağlamak için yönlendirmeyi kolaylaştırmak üzere ad alanı ile alt küme arasındaki eşleme ilişkisini kaydedecektir. Bu uygulama müşteri için daha dostça ve müşteriye karşı tamamen şeffaf olabilir.
Bulut odaklı evrim
Hadoop depolamanın buluta doğru evrilmesi, temel olarak HDFS'nin buluttaki nesne depolamayla nasıl çalıştığına bağlıdır.
Dört farklı mimari vardır: Şekilde gösterildiği gibi, ilk mimari ana gövdenin HDFS'yi benimsemesi ve bulut nesnesi depolamasının esas olarak yedekleme ve kurtarma rolünü oynamasıdır; ikinci mimari, bulut nesne depolamasında girdi ve HDFS'ye çıktıdır; Üç mimaride, giriş ve çıkışın tümü bulut nesne depolamasında bulunur ve ara sonuçları dökmek için HDFS kullanılır; son olarak, uygulamaların nesne depolamasını algılaması gerekmez ve nesne depolamasına veri yazmak ve yüklemek HDFS'nin sorumluluğundadır. Sonuncusunun ideal bir durum olduğunu düşünüyoruz, çünkü çevrimdışı olarak iyi çalışan büyük veri uygulamaları herhangi bir değişiklik yapılmadan buluta taşınabilir.
Dördüncü mimari için, HDFS topluluğu nesne depolama bağlama özelliğini geliştirdi.
Şekilde gösterildiği gibi, BAĞLANTI NOKTALARI, SAĞLANAN düzey olarak tanımlanan uzak ad alanını monte etmek için HDFS ad alanında herhangi bir yere ayarlanabilir. HDFS, StoragePolicy aracılığıyla farklı düzeyler arasında veri aktarımını yönetir.
Makine öğrenme
Bulut ve makine öğrenimi senaryoları için Hadoop topluluğu, OZone projesini geliştirdi. Bu gelecek vaat eden ürün, sınırsız ölçeklenebilirlik, güçlü tutarlı nesne depolama yetenekleri, temel bilgi işlem planlama çerçeveleri YARN ve Kubernetes ile sorunsuz entegrasyon ve nesne depolaması ve HDFS API'leri ile uyumluluk gibi birçok özelliğe sahiptir. Şu anda Ozon hala Alfa aşamasındadır ve bir sonraki Sürüm, 0.5 Sürüm, Beta sürümüdür. Ozon projesinde, Tencent mühendisleri de Topoloji Farkındalığı (topoloji bilinci), performans optimizasyonu vb. Birçok katkı yaptı.
Az önce bahsedilen büyük sahne atılımlarına ek olarak, burada listelenen bazı sürekli iyileştirmeler ve optimizasyonlar da vardır: geçici olmayan depolama desteği, yeni izleme çerçevesi izleme için destek ve ölçeklenebilirlik baskısı Test aracı Dinamometre vb.
Hesaplama için yeni fonksiyonlar
Aşağıdakiler, özellikle YARN ve Denizaltı dahil olmak üzere hesaplama kısmının (Hesaplama) güncellenmesine odaklanmaktadır. Gelecekte, giderek daha fazla bilgi işlem kaynağı kapsayıcıya alınacak. Geçmişte, konteynerleştirme esas olarak DevOps ve mikro hizmetler tarafından kullanılıyordu.Son zamanlarda, büyük veri uygulamalarının bağımlılığı giderek daha karmaşık hale geldiğinden, daha iyi bağımlılık yönetimi ve kaynak izolasyonu için konteynerleştirmeyi de kullanmamız gerekiyor.
Aşağıdakiler, bilgi işlemdeki bazı önemli yeni işlevlerdir.
İlk özellik, YARN-5139 Global Scheduling Framework'tür. Bu, 3.0.0'da eklenen bir işlevdir. Bir seferde birden fazla düğüme bakabilir.Bazı Yetenek optimizasyonları buna eklenmiştir.Sadece bir Thread olsa bile, daha hızlı çalışabilir. Ek olarak, paralel olarak tahsis edilebilen birden çok tahsis dizisi ekler. Bazı simülasyon testlerinden sonra birçok senaryoda tahsis veriminin 5-10 katına ulaştığı görülebilmektedir Şimdi saniyede 3000 ve 4000 Konteyner tahsisi, testi geçen nispeten normal bir değerdir. Tabii gerçekte bazı farklılıklar olabilir, daha kesin rakamlar varsa, umarım toplum içinde bizimle iletişime geçersiniz.
Konteynırlaştırma için aşağıdakiler ilgili iyileştirmelerdir. İlki, Docker konteynerinin 3.1.0'da üretime hazır olduğu söyleniyor; 3.2 ve 3.3'ün de birçok işlevi ve stabilizasyonu var. 3.3 İlk işlev Interactive Docker Shell'i desteklemektir.Kullanıcılar Docker konteynerinizde oturum açabilir ve SSH yerine bazı komutları karşılık gelen düğüme çalıştırabilir, bu da hata ayıklama için daha uygundur. İkinci parça OCI / squashfs (runc gibi) desteğidir. Buradaki eğilim, birçok kişinin Docker konteynerlerini kullanmak istememesi, ancak diğer çalışma zamanlarını kullanmayı ummasıdır. OCI ve Squashfs karşılık gelen standartlardır ve topluluk aktif olarak bunu teşvik etmektedir. Çoğu Testin zaten 3.3'te görünmesi gereken yamalar vardır. Üçüncü parça Docker görüntü yerelleştirmesi ve ilgili iyileştirmelerdir. Daha önce, YARN görüntüyü kırdığında, ne kadar yatırıldığı belli değildi. Bu bölüm, kullanıcıların Docker görüntüsü nispeten büyük olduğunda ilerlemenin nasıl olduğunu anlamalarına yardımcı olabilir.
YARN + Bulut ortamında, ilgili bazı iyileştirmeler de vardır. İyileştirmenin bu kısmı hala devam ediyor, umarım daha fazla gereksinimden bahsedebilir ve ilgili senaryonun ne olduğunu görebilirsiniz. İlk parça, bulut üzerindeki kapasiteyi genişletmek ve küçültmek için Otomatik Ölçeklendirmedir; ikinci parça, Konteyner'i mümkün olan en küçük huniye paketlemek gibi daha iyi Planlama yapmaktır. Spot bulut sunucuları gibi üçüncü parça, bazı Spot bulut sunucuları göründüğünde iyi işler üzerindeki etkinin mümkün olduğunca az olmasını sağlamak için nasıl tahsis edileceğidir. Bulutta, dönüşüm hunisinin aniden kullanılamadığı durumlar vardır.Bu, nispeten özel bir veri merkezinde görünmesi nispeten kolaydır. Bu alanın ayrıca Hizmetten Çıkarmayı nasıl daha iyi yapacağını ve Hizmet verilerinin işlenmesini bilmesi gerekir.
Bu senaryoda, herhangi bir fikriniz varsa veya bulut üzerinde halihazırda bazı çalışmalarınız varsa, YARN-9548'e yorum yapabilirsiniz.
Makine öğreniminin işi esas olarak Denizaltıdır. Denizaltı, YARN'ın bir alt projesi olarak Hadoop'a ilk defa 3.2.0 eklendi. Bu yılın başlarında, onu Hadoop altında YARN ve HDFS ile aynı olan bir alt projeye ayırdık. Bundan sonra 0.2.0 Sürümünü de yaptık. 0.3.0'da birçok yeni şey var.
Aşağıdaki resim, topluluğun yayın planıdır:
Önce 2018 Sürümünü inceleyelim. 2018'de 2.6, 2.7 ve 2.8 Bakım Sürümleri yapılmıştır. 2.9 yeni bir Sürümdür. Her ikisi de Microsoft tarafından yapılan YARN Federation ve Optimistic Container ile ilgilidir. 3.0, EC, global zamanlayıcı, Kaynak türleri, Zaman Çizelgesi V2'yi ekler, 3.1, bazı ilgili işleri yapmak için GPU / FPGA, YARN Hizmeti ve Yerleştirme Kısıtlaması ekler.
2019'da şimdiye kadar iki Sürüm yapıldı. 3.1.2 bir Stabilizasyon Sürümüdür, 3.2 Eklenen Düğüm Özniteliği, Tach'a gidebilirsiniz, Düğüm zamanlama sırasında ilgili planlamayı yapabilir, ayrıca Denizaltı, HDFS SPS, bulut Bağlayıcısı da nispeten büyük iyileştirmelere sahiptir.
Bu yılın kalan dört ayında birkaç yayın daha yapmayı planlıyoruz. İlki 2.8.6 topluluğu. Bazı Bakım Yamaları yapmayı umuyorum. 3.1.3 ve 3.2.1 ayrıca iki Bakım Sürümü yapmaya hazırlanıyor. HDFS ve Hadoop topluluklarında Federasyon, Opentracing gibi pek çok çalışma başlattım. Bu işlevin çoğu 3.3'e konulmaya hazırdır ve Docker kapsayıcısı ve benzeri hakkında az önce bahsedilen bazı işlevler vardır. Artık 3.3'te 1.000'den fazla Yama var ve tüm Hadoop topluluğu bu sürümü mümkün olan en kısa sürede yayınlamak için her türlü çabayı gösteriyor.
Son olarak, büyük veriyi öğrenmek istiyorsanız, sınırlı bir süre için ücretsiz materyaller ve kurslar almaktan bahsedeyim.
