Özel | Bir makalede Hadoop'u anlama (2) HDFS (açık)
Küresel ekonominin sürekli gelişmesiyle birlikte, büyük veri çağı sessizce geldi ve Hadoop, büyük veri ortamının temelini oluşturdu.Büyük veri endüstrisine girmek istiyorsanız, önce Hadoop'un bilgisini anlamanız gerekir. Apache, 2017'nin başında Hadoop3.0'ı piyasaya sürdü, bu da bir grup insanın sürekli olarak Hadoop'u optimize ettiği anlamına geliyor.Sadece bu değil, birçok şirket Hadoop'un ticari değerini de doğrulayan ticari sürümlerini kullanıyor.
Okuyucular, "Hadoop'u Anlamak İçin Bir Makale" yazı dizisini okuyarak Hadoop teknolojisi hakkında kapsamlı bir anlayışa sahip olabilirler. Hadoop resmi web sitesinin tüm bilgi noktalarını kapsar ve anlaşılması kolaydır. Kötü İngilizce'ye sahip okuyucular bu makaleyi okuyarak tamamen anlayabilirler. Hadoop.
Bu sayıdaki "Hadoop'u Tek Bir Makalede Anlamak" yazı dizisindeki özel içerik Hadoop'a ilk giriş ve ardından HDFS, MAPREDUCE ve YARN'ın tüm bilgi noktalarının çerçevesine ayrıntılı bir girişe dayanarak, İçerik dört konuya bölünmüş ve son birkaç gün içinde yayınlanmıştır. Takip içeriği için bizi izlemeye devam edin.
Bu sayı size HDFS'nin ayrıntılı bir açıklamasını verecektir.Kelimelerin sayısının sınırlı olmasından dolayı, bu makale sırasıyla birinci ve ikinci makaleler olmak üzere iki makaleye ayrılmıştır.
1. HDFS avantajları ve dezavantajları
1.1 Avantajlar
1.1.1 Yüksek hata toleransı
-
Yüzlerce veya binlerce sunucu makinesinden oluşabilir ve her sunucu makinesi dosya sistemi verilerinin bir bölümünü depolar;
-
Birden çok veri kopyası otomatik olarak kaydedilir;
-
Kopya kaybolduktan sonra, arızayı hızlı bir şekilde algılar ve otomatik olarak kurtarır.
1.1.2 Toplu işlem için uygun
-
Veri yerine mobil bilgi işlem;
-
Veri konumu, bilgi işlem çerçevesine açıktır;
-
Yüksek veri erişimi işleme hızı;
-
Çalışan uygulama, veri setine akış erişimi sağlar.
1.1.3 Büyük veri işleme için uygundur
-
Tipik dosya boyutu gigabayttan terabayta kadar değişir;
-
Tek bir örnekte on milyonlarca dosyayı destekleyin;
-
10K + düğüm.
1.1.4 Ucuz makinelere kurulabilir
-
Birden çok kopya ile güvenilirliği artırın;
-
Hata toleransı ve kurtarma mekanizması sağlar.
1.1.5 Heterojen donanım ve yazılım platformları arasında güçlü taşınabilirlik
-
Bir platformdan diğerine kolayca geçiş yapın.
1.1.6 Basit tutarlılık modeli
-
Uygulama, bir kez yazan ve dosyaları birden çok kez okuyan bir erişim modeline ihtiyaç duyar;
-
Ekleme ve kesme dışında oluşturulan, yazılan ve kapatılan dosyaların değiştirilmesine gerek yoktur;
-
Veri tutarlılığı sorununu basitleştirin ve yüksek verimli veri erişimi sağlayın;
-
Birçok kurulum için çok uygun olan varsayılan konfigürasyonlarla son derece yapılandırılabilir. Çoğu zaman, yalnızca çok büyük kümeler için yapılandırmayı ayarlamanız gerekir.
1.2 Dezavantajlar
1.2.1 Düşük gecikmeli veri erişimi için uygun değil
-
HDFS tasarımı, kullanıcı etkileşimi yerine daha fazla toplu işlemdir. Odak noktası, veri erişiminin düşük gecikmesi değil, yüksek veri erişim hızıdır.
1.2.2 Küçük dosya erişimi için uygun değil
-
NameNode'da çok fazla bellek kaplar;
-
Arama süresi okuma süresini aşıyor.
1.2.3 Aynı anda yazılamaz ve dosya hemen değiştirilir
-
Bir dosya için yalnızca bir yazar olabilir;
-
Yalnızca ekleme ve kesme desteklenir.
2. Temel kompozisyon
2.1 Namenode
2.1.1 Müşterinin okuma ve yazma hizmetlerini kabul edin
Dosya ve dizinleri açma, kapatma ve yeniden adlandırma gibi dosya sistemi ad alanı işlemlerini gerçekleştirin.
2.1.2 Dosya Sistemi Ad Alanını Yönetin
Dosya sistemi ad alanında veya özniteliklerinde yapılan değişiklikleri kaydedin.
2.1.3 meta veri bileşimi
Meta veriler, Namenode'da depolanan meta veri bilgisidir Diskte depolanan dosya adı fsimage'dir. Ve meta verilerin işlem günlüğünü kaydetmek için düzenlemeler adlı bir dosya var. Genel olarak, fsimage ve düzenleme dosyaları izin bilgilerini Metadata'ya ve dosyanın içerdiği dosya sistemi dizin ağacına kaydeder, bloğun DataNode ile eşleşmesini belirler ve bloğun hangi DataNode'da depolandığını belirler (DataNode başlatıldığında rapor edilir).
NameNode bu bilgileri belleğe yükler ve tam bir meta veri bilgisi olacak şekilde birleştirir.
2.1.4 Dosya Sistemi Ad Alanı
HDFS, geleneksel hiyerarşik dosya organizasyonunu destekler. Kullanıcılar veya uygulamalar dizinler oluşturabilir ve dosyaları bu dizinlerde saklayabilir. Dosya sistemi ad alanı hiyerarşisi, mevcut diğer dosya sistemlerinin çoğuna benzer: dosyaları oluşturabilir ve silebilir, dosyaları bir dizinden diğerine taşıyabilir veya dosyaları yeniden adlandırabilirsiniz. HDFS, kullanıcı kotalarını ve erişim izinlerini destekler. Ancak, sabit veya yumuşak bağlantılar desteklenmez.
NameNode, dosya sistemi ad alanını korur. Dosya sistemi ad alanında veya özniteliklerinde yapılan herhangi bir değişiklik, Ad Düğümü tarafından kaydedilir. Uygulama, dosyanın HDFS tarafından tutulması gereken kopya sayısını belirleyebilir. Bir dosyanın kopya sayısına dosyanın kopya faktörü denir. Bu bilgiler NameNode tarafından saklanır.
2.1.5 Dosya sistemi meta verilerinin kalıcılığı
NameNode'un metadata bilgisi başlatıldıktan sonra hafızaya yüklenecektir Hafızaya yüklenen veriler çok güvensiz olduğundan ve bir elektrik kesintisinden sonra kaybolacağından hafızada saklanan bilgilerin kalıcı olması gerekir.
HDFS ad alanı Namenode'da saklanır. Dosya sistemi meta verilerindeki herhangi bir değişiklik için Namenode, bunu kaydetmek için Edits adlı bir işlem günlüğü kullanır. Örneğin, HDFS'de bir dosya oluşturulursa, Namenode bunu belirtmek için Düzenlemeler'e bir kayıt ekler; benzer şekilde, dosyanın kopyalama katsayısını değiştirmek de Düzenlemelere bir kayıt ekler. Namenode, bu Düzenlemeleri yerel işletim sisteminin dosya sisteminde depolar. Veri bloklarının dosyalara eşlenmesi ve dosya öznitelikleri de dahil olmak üzere tüm dosya sisteminin ad alanı, Namenode'un bulunduğu yerel dosya sistemine de yerleştirilen FsImage adlı bir dosyada saklanır.
Namenode, tüm dosya sisteminin ad alanını ve dosya veri blok haritası (Blok Haritası) görüntüsünü bellekte depolar. Bu anahtar meta veri yapısı çok kompakt olacak şekilde tasarlanmıştır, bu nedenle 4G belleğe sahip bir Namenode, çok sayıda dosya ve dizini desteklemek için yeterlidir. Namenode başladığında, Düzenlemeleri ve FsImage'ı sabit diskten okur, Düzenlemelerdeki tüm işlemleri bellekteki FsImage'a uygular ve FsImage'ın yeni sürümünü bellekten yerel diske kaydeder ve ardından eski Düzenlemeleri siler. , Çünkü bu eski Düzenlemeler işlemi FsImage'a uygulandı. Bu işleme kontrol noktası denir.
Datanode, HDFS verilerini yerel dosya sisteminde dosyalar biçiminde depolar ve HDFS dosyaları hakkındaki bilgileri bilmez. Her bir HDFS veri bloğunu yerel dosya sisteminde ayrı bir dosyada depolar. Datanode tüm dosyaları aynı dizinde oluşturmaz, aslında her dizindeki optimal dosya sayısını belirlemek için buluşsal yöntemler kullanır ve uygun olduğunda alt dizinler oluşturur. Tüm yerel dosyaları aynı dizinde oluşturmak en uygun seçim değildir, çünkü yerel dosya sistemi tek bir dizinde çok sayıda dosyayı verimli bir şekilde destekleyemeyebilir. Bir Datanode başladığında, yerel dosya sistemini tarar, bu yerel dosyalara karşılık gelen tüm HDFS veri bloklarının bir listesini oluşturur ve ardından bunu bir rapor olarak Namenode'a gönderir Bu rapor blok durum raporudur.
2.2 İkincilAdıDüğümü
Bu, NameNode'un bir yedeği değildir, ancak NameNode'un bir yedeği olarak kullanılabilir.Güç kapatıldığında veya sunucu hasar gördüğünde, SecondNameNode'daki birleştirilmiş fsimage dosyası, NameNode'a geri yüklemek için bir yedekleme dosyası olarak kullanılabilir, ancak birleştirme işleminde kaybolması muhtemeldir Yeni oluşturulan düzenleme bilgileri. Bu nedenle tam bir yedekleme değildir.
NameNode, başlangıç sırasında yalnızca fsimage'ı birleştirdiği ve dosyaları düzenlediği için, yoğun bir kümede zamanla düzenleme günlük dosyası çok büyük hale gelebilir. Daha büyük bir düzenleme dosyasının bir başka yan etkisi de, bir dahaki sefere NameNode'u yeniden başlatmanın daha uzun sürmesidir. SecondNameNode'un ana işlevi, NameNode'un düzenlemeleri ve fsimage dosyalarını birleştirmesine yardımcı olmak ve böylece NameNode başlatma süresini azaltmaktır.
2.2.1 SNN yürütme zamanlaması
-
Yapılandırma dosyasında yapılandırılan zaman aralığına göre, fs.checkpoint.period varsayılan olarak 1 saattir;
-
dfs.namenode.checkpoint.txns, varsayılan ayar 1 milyondur, yani Düzenlemelerdeki işlem sayısı 1 milyona ulaştığında, kontrol noktası dönemine ulaşılmasa bile bir birleştirme tetiklenecektir.
2.2.2 SNN birleşme süreci
-
İlk olarak, birleştirme işlemi sırasında oluşturulan günlük bilgilerini kaydetmek için edits.new adlı bir dosya oluşturun;
-
Belirli bir zamanlama tetiklendiğinde (zaman aralığı 1 saate ulaştığında veya Düzenlemelerde işlem sayısı 1 milyona ulaştığında), SecondaryNamenode düzenleme dosyasını ve fsimage dosyasını NameNode'dan SecondNamenode'a okur;
-
Düzenleme dosyasını ve fsimage'ı bir fsimage.ckpt dosyasında birleştirin;
-
Elde edilen birleştirilmiş fsimage.ckpt dosyasını NameNode'a dönüştürün;
-
NameNode'daki orijinal fsimage dosyasını değiştirmek için fsimage.ckpt'i NameNode'da fsimage dosyası olarak değiştirin ve NameNode'daki orijinal düzenleme dosyasını değiştirmek için edits.new dosyasını düzenleme dosyası olarak değiştirin.
SNN, hadoop2.x ve üstü yüksek kullanılabilirlik durumunda olmadığında hala mevcuttur, ancak SNN, hadoop2.x ve üzeri yüksek kullanılabilirlik durumunda ve yüksek kullanılabilirlik durumunda hadoop2.x ve üzeri sürümlerde mevcut değildir, beklemededir Birleştirme işlemini yapmak için Durum Adı Düğüm.
2.3 Veri Düğümü
-
Üzerinde çalıştıkları düğümlere bağlı depolamayı yönetin ve kullanıcı verilerinin dosyalarda depolanmasına izin verin;
-
Dahili olarak, dosya bir veya daha fazla bloğa (Blok) bölünür ve bu bloklar bir DataNode grubunda saklanır;
-
Dosya sistemi istemcisinden okuma ve yazma talepleri sağlamaktan sorumlu;
-
Blok oluşturma ve silme işlemini gerçekleştirin;
-
DN işlemi başlatılırken blok bilgileri NN'ye bildirilecektir;
-
NN'ye bir sinyal göndererek (her 3 saniyede bir) NN ile iletişim halinde olun (her 3 saniyede bir) NN, DN'den 10 dakika içinde sinyal almazsa, DN kaybedilmiş olarak kabul edilir ve üzerindeki Blok diğer DN'lere kopyalanır.
2.3.1 HDFS depolama birimi (blok)
2.3.1.1 Dosya, sabit boyutlu veri bloklarına bölünmüştür
-
Varsayılan veri bloğu boyutu 64MB (hadoop1.x), 128MB (hadoop2.x), 256MB (hadoop3.x), yapılandırılabilir;
-
Dosya boyutu blok boyutundan küçükse, ayrı olarak blok olarak saklanır Blok blok mantıksal bir kavramdır. Dosya boyutu kadar alan.
2.3.1.2 Bir dosya depolama yöntemi
-
Boyuta göre farklı bloklara bölün ve bunları farklı düğümlerde saklayın;
-
Varsayılan olarak, her bloğun 3 kopyası vardır;
-
Blok boyutu ve kopya sayısı, dosya istemciye yüklendiğinde ayarlanır.Kopya sayısı dosya başarıyla yüklendikten sonra değiştirilebilir ve blok boyutu değiştirilemez.
2.3.1.3 Tasarım Fikri
Büyük dosyaları 256MB'lık blok bloklara bölün ve her blok bloğu rastgele farklı bir düğümde depolanır, böylece veri çarpıklığı problemi ortadan kalkar.Ancak geliştirme sürecinde algoritma ve program iyi yazılmazsa aynı şey olur Veri çarpıklığı sorunu var.
2.3.2 Veriler karmaşık sistemi
2.3.2.1 Veri çoğaltmaya genel bakış
HDFS, çok büyük dosyaları büyük bir kümedeki makineler arasında güvenilir bir şekilde depolamak için tasarlanmıştır. Sonuncusu hariç her dosyayı bir dizi veri bloğu olarak depolar, tüm veri blokları aynı boyuttadır. Hata toleransı için, dosyanın tüm veri bloklarının kopyaları olacaktır. Her dosyanın veri bloğu boyutu ve kopyalama katsayısı yapılandırılabilir. Uygulama, bir dosyanın kopya sayısını belirleyebilir. Kopya katsayısı, dosya oluşturulduğunda belirtilebilir veya daha sonra değiştirilebilir. HDFS'deki dosyaların tümü bir kez yazılır ve herhangi bir zamanda yalnızca bir yazar olması kesinlikle gereklidir.
Namenode, veri bloklarının replikasyonunu tam olarak yönetir.Kümedeki her Datanode'dan periyodik olarak kalp atışı sinyalleri ve blok durum raporları (Blok raporu) alır. Bir kalp atışı sinyali almak, Datanode'un normal çalıştığı anlamına gelir. Blok durumu raporu, Datanode üzerindeki tüm veri bloklarının bir listesini içerir.
HDFS veri düğümü
2.3.2.2 Bloğun kopya yerleştirme stratejisi
Kopyaların depolanması, HDFS güvenilirliğinin ve performansının anahtarıdır. Optimize edilmiş kopya depolama stratejisi, HDFS'yi diğer birçok dağıtılmış dosya sisteminden ayıran önemli bir özelliktir. Bu özellik, çok fazla ayarlama ve deneyim birikimi gerektirir. HDFS, veri güvenilirliğini, kullanılabilirliğini ve ağ bant genişliği kullanımını iyileştirmek için raf duyarlı adı verilen bir strateji kullanır. Şu anda uygulanan kopya depolama stratejisi, bu yöndeki yalnızca ilk adımdır. Bu stratejiyi uygulamanın kısa vadeli amacı, bir üretim ortamındaki etkinliğini doğrulamak, davranışını gözlemlemek ve daha gelişmiş stratejilerin gerçekleştirilmesi için test ve araştırma için bir temel oluşturmaktır.
Büyük ölçekli HDFS örnekleri genellikle birden çok rafı kapsayan bilgisayarlardan oluşan bir kümede çalışır ve farklı raflardaki iki makine arasındaki iletişimin bir anahtardan geçmesi gerekir. Çoğu durumda, aynı raftaki iki makine arasındaki bant genişliği, farklı raflardaki iki makine arasındaki bant genişliğinden daha büyük olacaktır.
Bir raf farkındalığı süreci aracılığıyla Namenode, her bir Datanode'nin ait olduğu raf kimliğini belirleyebilir. Basit ancak optimize edilmemiş bir strateji, kopyaları farklı raflarda saklamaktır. Bu, tüm raf arızalandığında veri kaybını etkili bir şekilde önleyebilir ve verileri okurken birden çok rafın bant genişliğinin tam olarak kullanılmasına izin verir. Bu ilke ayarı, eşlemeleri kümede eşit olarak dağıtabilir, bu da bileşen arızası durumunda yük dengelemeye elverişlidir. Ancak, bu stratejinin bir yazma işleminin veri bloklarını birden çok rafa aktarması gerektiğinden, bu, yazma maliyetini artırır.
Çoğu durumda, kopyalama katsayısı 3'tür. HDFS depolama stratejisi, bir kopyayı yerel raftaki bir düğümde, bir kopyayı aynı raftaki başka bir düğümde ve son kopyayı farklı bir rafta depolamaktır. Düğüm. Bu strateji, raflar arasındaki veri aktarımını azaltır ve bu da yazma işlemlerinin verimliliğini artırır. Raf hataları düğüm hatalarından çok daha azdır, bu nedenle bu strateji verilerin güvenilirliğini ve kullanılabilirliğini etkilemeyecektir. Aynı zamanda, veri blokları yalnızca iki (üç değil) farklı rafa yerleştirildiğinden, bu strateji, verileri okumak için gereken toplam ağ iletim bant genişliğini azaltır. Bu stratejiye göre, kopyalar farklı raflara eşit olarak dağıtılmaz. Replikaların üçte biri bir düğümde, replikaların üçte ikisi bir rafta ve diğer replikalar kalan raflarda eşit olarak dağıtılır Bu strateji veri güvenilirliğinden ve okuma performansından ödün vermez. Geliştirilmiş yazma performansı.
2.3.2.3 Seçimi kopyala
Genel bant genişliği tüketimini ve okuma gecikmesini azaltmak için HDFS, okuyucunun kendisine en yakın kopyayı okumasına izin vermeye çalışacaktır. Okuyucunun aynı rafında bir kopya varsa, kopya okunur. Bir HDFS kümesi birden çok veri merkezini kapsıyorsa, istemci önce yerel veri merkezinin kopyasını da okuyacaktır.
2.3.2.4 Güvenli Mod
-
NameNode başladığında, güvenli mod denen özel bir duruma girecektir.İlk olarak görüntü dosyasını (fsimage) belleğe yükler ve düzenleme günlüğünde (düzenlemeler) çeşitli işlemleri yürütür;
-
Dosya sistemi meta veri eşlemesi bellekte başarıyla kurulduktan sonra, yeni bir fsimage dosyası (bu işlem İkinciAdıDüğümü gerektirmez) ve boş bir düzenleme günlüğü oluşturun;
-
Şu anda, ad kodu güvenli modda çalışmaktadır, yani, isim modunun dosya sistemi istemci için salt okunurdur, dizinleri görüntüler, dosya içeriklerini görüntüler, vb., Yazma, silme ve yeniden adlandırma başarısız olur;
-
Bu aşamada, namenode her bir veri düğümünden raporlar toplar.Veri bloğu minimum kopya sayısına ulaştığında, "güvenli" olarak kabul edilecektir. Veri bloklarının belirli bir yüzdesinin güvenli (ayarlanabilir) olduğu kabul edildikten sonra, belirli bir süre geçecektir. , Güvenli mod sona erer;
-
Bir veri bloğu için kopya sayısının yetersiz olduğu tespit edildiğinde, minimum kopya sayısına ulaşılana kadar blok kopyalanacaktır.Sistemdeki veri bloğunun konumu isim kodu tarafından korunmaz, ancak veri bloğu içinde blok listesi şeklinde saklanır.
2.4 Veri organizasyonu
2.4.1 Veri Bloğu
HDFS, büyük dosyaları desteklemek için tasarlanmıştır ve HDFS, büyük ölçekli veri kümelerini işlemesi gereken uygulamalar için uygundur. Bu uygulamalar yalnızca bir kez veri yazar, ancak bir veya daha fazla kez okur ve okuma hızı, akışlı okuma ihtiyaçlarını karşılayabilmelidir. HDFS, dosyaların "bir kez yaz ve birçok kez oku" semantiğini destekler. Tipik bir veri bloğu boyutu 256MB'dir. Bu nedenle, HDFS'deki dosyalar her zaman 256M'ye göre farklı bloklara bölünür ve her blok, mümkün olduğunca farklı bir Datanode'da saklanır.
2.4.2 Bölümleme
İstemcinin bir dosya oluşturma isteği aslında hemen Namenode'a gönderilmez.Aslında, HDFS istemcisi ilk olarak dosya verilerini yerel bir geçici dosyaya önbelleğe alır. Uygulamanın yazma işlemi şeffaf bir şekilde bu geçici dosyaya yeniden yönlendirilir. Bu geçici dosyanın birikmiş veri hacmi bir veri bloğunun boyutunu aştığında, müşteri Namenode ile iletişime geçecektir. Namenode, dosya adını dosya sisteminin hiyerarşisine ekler ve ona bir veri bloğu tahsis eder. Daha sonra Datanode ve hedef veri bloğunun tanımlayıcısını istemciye iade edin. Ardından müşteri bu veri parçasını yerel geçici dosyadan belirlenen Datanode'a yükler. Dosya kapatıldığında, geçici dosyada kalan yüklenmemiş veriler de belirlenen Datanode'a aktarılacaktır. Ardından müşteri Namenode'a dosyanın kapatıldığını söyler. Şu anda Namenode, dosya oluşturma işlemini depolama için günlüğe gönderir. Dosya kapatılmadan önce Namenode düşerse, dosya kaybolur.
Yukarıdaki yöntem, HDFS üzerinde çalışan hedef uygulamanın dikkatli bir şekilde değerlendirilmesinin sonucudur. Bu uygulamalar, dosyaların akışını gerektirir. İstemci önbelleğe alma kullanılmazsa, ağ hızı ve ağ tıkanıklığı iş hacmi üzerinde daha büyük bir etkiye sahip olacaktır. Bu yöntem emsalsiz değildir.AFS gibi eski dosya sistemleri, performansı artırmak için istemci tarafı önbelleğe almayı kullandı. Daha yüksek veri yükleme verimliliği elde etmek için POSIX standardının gereksinimleri gevşetilmiştir.
2.4.3 Boru Kopyalama
Bir istemci bir HDFS dosyasına veri yazdığında, başlangıçta yerel bir geçici dosyaya yazılır. Dosyanın kopyalama katsayısının 3 olarak ayarlandığı varsayıldığında, yerel geçici dosya bir veri bloğu boyutunda biriktiğinde, müşteri kopyayı saklamak için Namenode'dan bir Datanode listesi alacaktır. Daha sonra müşteri ilk Datanode'a veri göndermeye başlar İlk Datanode, verileri küçük parçalar halinde alır (4 KB), her bir parçayı yerel depoya yazar ve eşzamanlı olarak parçayı listedeki ikinci Datanode'a iletir. düğüm. Aynısı ikinci Datanode için de geçerlidir, küçük bir kısmı veriyi alır, yerel depoya yazar ve aynı zamanda üçüncü Datanode'a iletir. Son olarak, üçüncü Datanode verileri alır ve yerel olarak depolar. Bu nedenle, Datanode bir boru hattındaki önceki düğümden veri alabilir ve aynı anda bir sonraki düğüme iletebilir.Veri, bir boru hattında önceki Datanode'dan bir sonrakine kopyalanır.
3. Okuma ve yazma süreci
3.1 HDFS okuma işlemi
-
İlk olarak, HDFS istemcisi DistributedFileSystem'i geçer;
-
DistributedFileSystem aracılığıyla NameNode'a bir istekte bulunun ve aynı zamanda kullanıcı bilgilerini ve dosya adı bilgilerini NameNode'a gönderin ve dosyada bulunan bloğun bulunduğu DistributedFileSystem'e geri gönderin;
-
HDFS istemcisi, DataNode'daki blok bilgilerini FSDataInputStream aracılığıyla sırayla okur (bloğu okumak için en düşük yüke veya istemciye en yakın olan DataNode'u seçecektir);
-
FSDataInputStream, tüm bloklar okunana kadar sırayla tek tek okur;
-
FSDataInputStream okuduktan sonra kapatılacak.
3.2 HDFS yazma işlemi
-
İlk olarak, HDFS istemcisi Dağıtılmış Dosya Sistemini (HDFS'de API'deki bir nesne) geçirir;
-
İstemcinin talebini Dağıtılmış Dosya Sistemi aracılığıyla Ad Düğümüne gönderin (Ad Düğümü esas olarak istemci isteklerini kabul eder) ve bunu kaydedilecek dosyanın konumu, dosya adı ve işlemin kullanıcı adı gibi bilgilerle birlikte Ad Düğümüne gönderir;
-
NameNode, istemciye bir FSDataOutputStream döndürür ve ayrıca dosyanın hangi DataNode'lara yazılması gerektiğini (daha düşük yüklü olan) döndürür;
-
FSDataOutputStream aracılığıyla yazma işlemleri, yazmadan önce dosyayı bölün, dosyayı birden çok bloğa bölün, ilk yazma işlemini DataNode üzerinde nispeten düşük bir yükle yazın ve bu bloğu diğer DataNode'lara kopyalayın;
-
Tüm blok kopyalar kopyalandığında, FSDataOutputStream'e geri besleneceklerdir;
-
Tüm blok kopyalar kopyalandığında, FSDataOutputStream akışı kapatılabilir;
-
Dağıtılmış Dosya Sistemi aracılığıyla Ad Düğümündeki kaynak veri bilgilerini güncelleyin.
4. Mimarlık
4.1 NameNode ve DataNode
HDFS, bir ana / çalışan mimarisi kullanır. Bir HDFS kümesi, bir Namenode ve belirli sayıda Datanode'dan oluşur. Namenode, dosya sisteminin ad alanını yönetmekten ve dosyalara istemci erişiminden sorumlu merkezi bir sunucudur. Kümedeki veri düğümleri genellikle, bulunduğu düğümdeki depolamayı yönetmekten sorumlu bir düğümdür. HDFS, dosya sisteminin ad alanını ortaya çıkarır ve kullanıcılar üzerinde dosyalar biçiminde veri depolayabilir. Dahili bir bakış açısından, bir dosya aslında bir Datanode grubu üzerinde depolanan bir veya daha fazla veri bloğuna bölünmüştür. Namenode, dosya sisteminde dosya veya dizinleri açma, kapama ve yeniden adlandırma gibi ad alanı işlemleri gerçekleştirir. Ayrıca, veri bloklarının belirli Datanode düğümlerine eşlenmesinin belirlenmesinden de sorumludur. Datanode, dosya sistemi istemcilerinden gelen okuma ve yazma taleplerinin işlenmesinden sorumludur. Namenode'un birleşik zamanlaması altında veri blokları oluşturun, silin ve çoğaltın.
HDFS mimarisi
Namenode ve Datanode, sıradan ticari makinelerde çalışacak şekilde tasarlanmıştır. Bu makineler genellikle GNU / Linux işletim sistemini (OS) çalıştırır. HDFS, Java dilinde geliştirildiğinden, Java'yı destekleyen her makine Namenode veya Datanode'u dağıtabilir. Oldukça taşınabilir Java dili nedeniyle, HDFS birden çok makineye dağıtılabilir. Tipik bir dağıtım senaryosu, bir makinede Namenode'un yalnızca bir örneğinin çalışması ve kümedeki diğer makinelerin bir Datanode örneğini çalıştırmasıdır. Bu mimari aynı zamanda bir makinede birden fazla Datanode çalıştırabilir, ancak bu tür durumlar nispeten nadirdir.
Kümedeki tek bir Namenode'un yapısı, sistem mimarisini büyük ölçüde basitleştirir. Namenode, tüm HDFS meta verilerinin yöneticisidir ve kullanıcı verileri asla Namenode üzerinden akmayacaktır.
4.1.1 İletişim protokolü
Tüm HDFS iletişim protokolleri, TCP / IP protokolüne dayanır. İstemci, yapılandırılabilir bir TCP bağlantı noktası aracılığıyla Namenode'a bağlanır ve ClientProtocol protokolü aracılığıyla Namenode ile etkileşime girer. Datanode, Namenode ile etkileşim için DatanodeProtocol protokolünü kullanır. ClientProtocol ve Datanodeprotocol protokollerini kapsüllemek için bir uzaktan yordam çağrısı (RPC) modeli soyutlanmıştır. Namenode, tasarım gereği RPC'yi proaktif olarak başlatmaz, ancak istemcilerden veya Datanode'lardan gelen RPC isteklerine yanıt verir.
4.2 Altyapı
Hadoop Dağıtılmış Dosya Sistemi (HDFS), genel amaçlı donanım üzerinde çalışmaya uygun dağıtılmış bir dosya sistemi olarak tasarlanmıştır. Mevcut dağıtılmış dosya sistemleriyle birçok ortak noktası vardır. Ancak aynı zamanda, onunla diğer dağıtılmış dosya sistemleri arasındaki fark da çok açıktır. HDFS, oldukça hataya dayanıklı bir sistemdir ve ucuz makinelerde kullanıma uygundur. HDFS, büyük ölçekli veri kümelerindeki uygulamalar için çok uygun olan yüksek verimli veri erişimi sağlayabilir. HDFS, dosya sistemi verilerinin akış amacına ulaşmak için bazı POSIX kısıtlamalarını gevşetir. HDFS, başlangıçta Apache Nutch arama motoru projesinin altyapısı olarak geliştirildi. HDFS, Apache Hadoop Core projesinin bir parçasıdır.
-
Tüm istemci istekleri NameNode'a düşer;
-
Meta veri bilgileri NameNode'da saklanır;
-
Hadoop kümesinde Etkin durumda bir ve yalnızca bir NameNode vardır;
-
SecondaryNameNode, NameNode'un bir yedek düğümü veya ikincil düğümü değildir (tam olarak, NameNode'un yalnızca bir bölümünü yedekleyebilir, ancak tümünü değil);
-
NameNode ve DataNode arasında bir kalp atışı mekanizması vardır, böylece NameNode, DataNode'un çalışma durumunu ve yükünü bilebilir.
4.2.1 Sağlamlık
HDFS'nin temel amacı, hata durumunda bile veri depolamanın güvenilirliğini sağlamaktır. Üç yaygın hata durumu şunlardır: Namenode hatası, Datanode hatası ve ağ bölümü.
4.2.1.1 Disk veri hatası, kalp atışı algılama ve yeniden kopyalama
Her Datanode düğümü, Namenode'a periyodik olarak bir kalp atışı sinyali gönderir. Ağ nedenleri, bazı Datanode'ların Namenodes ile iletişimini kaybetmesine neden olabilir. Namenode, bu durumu kalp atışı sinyallerinin yokluğu yoluyla algılar ve son zamanlarda kalp atışı sinyalleri göndermeyen bu Datanodları işaretler ve bunlara yeni IO istekleri göndermez. Aşağı Datanode'de depolanan veriler artık geçerli olmayacaktır. Datanode kesinti süresi, bazı veri bloklarının kopyalama katsayısının belirtilen değerden daha düşük olmasına neden olabilir Namenode, kopyalanması gereken bu veri bloklarını sürekli olarak algılar ve bulunduğunda kopyalama işlemini başlatır. Aşağıdaki durumlarda yeniden çoğaltma gerekebilir: bir Datanode düğümü başarısız olur, bir kopya zarar görür, Datanode üzerinde bir sabit disk hatası veya bir dosyanın kopyalama katsayısı artar.
4.2.1.1.1 DataNode çalışırken takılabilir sürücü
Datanode, çalışırken değiştirilebilir sürücüleri destekler. DataNode'u kapatmadan HDFS veri birimlerini ekleyebilir veya değiştirebilirsiniz. Aşağıda kısaca tipik çalışırken takılabilir sürücü tanıtılmaktadır:
-
Yeni depolama dizinleri varsa, bunlar uygun şekilde biçimlendirilmeli ve yüklenmelidir;
-
Veri birimi dizinini, DataNode'un dfs.datanode.data.dir yapılandırmasına güncelleyin;
-
Dfsadmin -reconfig datanode HOST komutunu çalıştırın: PORT, yapılandırdığımız dizini etkin hale getirmek için başlar ve dfsadmin -reconfig datanode HOST: yeniden yapılandırma görevinin çalışma durumunu sorgulamak için PORT durumu;
-
Yeniden yapılandırma görevi tamamlandığında, güvenli bir şekilde bağlantısını kesebilir, veri birimi dizinini silebilir ve diski fiziksel olarak silebiliriz.
4.2.1.2 Yük Dengeleme
HDFS mimarisi, veri dengeleme stratejilerini destekler. Bir Datanode düğümündeki boş alan belirli bir kritik noktadan daha düşükse, sistem bu Datanode'daki verileri denge stratejisine göre diğer boş Datanodlara otomatik olarak taşıyacaktır. Belirli dosyalar için ani yüksek talep olması durumunda, bu çözüm dinamik olarak ek kopyalar oluşturabilir ve kümedeki diğer verileri yeniden dengeleyebilir.
4.2.1.2.1 Dengeleyici
HDFS verileri, Veri Düğümleri arasında eşit olarak dağıtılmayabilir. Yaygın bir neden, yeni DataNode düğümlerinin genellikle mevcut kümelere eklenmesidir. Yeni bir veri bloğu eklerken (bir dosyanın verileri bir dizi blok içinde saklanır), NameNode, veri bloğunu almak için DataNode'u seçmeden önce birçok faktörü dikkate alacaktır. Bu hususlardan bazıları şunlardır:
-
Veri bloğunu yazan düğüme veri bloğunun bir kopyasını koyun;
-
Veri bloklarının farklı kopyalarını farklı raflara dağıtmaya çalışın, böylece küme bir rafın tamamen kaybolmasına dayanabilir;
-
Bir kopya genellikle dosyayı yazan düğümle aynı raftaki bir düğüme yerleştirilir ve bu, raftaki ağ G / Ç'sini azaltabilir;
-
HDFS verilerini kümenin DataNode'larında olabildiğince eşit bir şekilde dağıtın.
4.2.1.2.2 Disk Dengeleyici
Diskbalancer, verileri bir veri düğümünün tüm disklerine eşit olarak dağıtabilen bir komut satırı aracıdır. Bu araç, küme çapında veri dengelemeden sorumlu olması açısından dengeleyiciden farklıdır. Çeşitli nedenlerden dolayı, verilerin düğümdeki diskler arasında eşit olmayan dağılımı olabilir. Bu, çok sayıda yazma ve silme işleminden veya disk değişiminden kaynaklanabilir. Araç, belirli bir veri kodlaması üzerinde çalışır ve blokları bir diskten diğerine taşır.
4.2.1.2.2.1 Mimari
Disk dengeleyici bir plan oluşturarak çalışır ve ardından veri düğümlerinde planı yürütür. Plan, verileri iki disk arasında taşımayı tanımlayan bir dizi ifadedir. Bir plan birden çok adımdan oluşur. Taşıma adımında kaynak disk, hedef disk ve taşınacak bayt sayısı bulunur. Plan, işlem veri düğümü için yürütülebilir.
Toplam 3 aşama, Keşfet (keşif) ila Plan (plan) ve ardından Plan (plan) ila Yürütme (yürütme):
4.2.1.2.2.1.1 Keşfet
Keşif aşamasının yaptığı şey aslında her düğümdeki disk kullanımını hesaplamak ve ardından veri dengelemesine ihtiyaç duyan disklerin bir listesini almaktır.Burada, Hacim Veri Yoğunluğu disk kullanım yoğunluğu kavramı değerlendirme için bir kriter olarak kullanılacaktır. Bu standart değer olacaktır. Karşılaştırma değeri olarak düğümün toplam kullanım oranını alın. Örneğin, bir düğümün toplam kullanım oranı% 75 ise, yani 0,75 ve A diskinin kullanım oranı 0,5 (% 50) ise A diskinin volumeDataDensity değeri 0,75-0,5'e eşittir. = 0.25. Benzer şekilde, aşarsa, yoğunluk değeri negatif olacaktır. Bu nedenle, toplam mutlak değer toplanırsa, bu düğümdeki diskler arasındaki verilerin dengesini değerlendirmek için düğümdeki her diskin volumeDataDensity'nin mutlak değerini kullanabiliriz. Değer ne kadar büyükse, veriler de o kadar dengesizdir ve bu, varyans kavramına biraz benzerdir. Keşif aşaması aşağıdaki bağlayıcı nesnelerini kullanır:
-
DBNameNodeConnector
-
JsonConnector
-
NullConnector
İlk nesne, küme düğümünü ve disk verilerini okumak için Dengeleyici paketi altındaki NameNodeConnector nesnesini çağırır.
4.2.1.2.2.1.2 Plan
Bir önceki aşamanın rapor sonuç verisi alındıktan sonra, yürütme planı oluşturulacaktır.Plan en küçük bir yürütme birimi değildir, adımlardan oluşur. Adımda kaynak ve hedef diskler belirtilecektir.Buradaki disk nesnesi Bu, paketlenmiş nesnelerin bir katmanıdır: DiskBalancerVolume, orijinal FsVolume değil. Bu arada, DiskBalancer'daki disk düğümleri gibi kavramların dönüştürülmesi burada:
-
DiskBalancerCluster Bu nesne aracılığıyla, kümedeki düğüm bilgileri okunabilir ve buradaki düğüm bilgileri DiskBalancerDataNode biçiminde sunulur;
-
DiskBalancerDataNode Bu nesne, paketlenmiş bir DataNode'u temsil eder;
-
DiskBalancerVolume ve DiskBalancerVolumeSet DataNode disk nesnesi ve disk nesnesi koleksiyonu DiskBalancerVolumeSet'teki disk depolama dizini türlerinin aynı StorageType olması gerekir.
4.2.1.2.2.1.3 Yürütme
Son kısım, yürütme aşamasıdır.Tüm plan planları oluşturulduktan sonra, yürütme aşamasındadır.Bu planlar ilgili DataNode'larına gönderilecek ve ardından DiskBalancer sınıfında çalıştırılacaktır.Diskler için DiskBalancer sınıfında özel sınıf nesneleri vardır. Bu sınıfın adı DiskBalancerMover olarak adlandırılır.Diskler arasında veri dengeleme sürecinde, yüksek kullanım diskleri veri bloklarını nispeten düşük kullanımlı disklere taşıyacaktır. Belirli bir eşik ilişkisi karşılandığında, DiskBalancer Yavaş yavaş çıkın. DiskBalancer'in yürütme aşamasında, dikkat edilmesi gereken aşağıdaki noktalar vardır:
-
Bant genişliği sınırlaması DiskBalancer ayrıca bant genişliği sınırlamasını da destekleyebilir, varsayılan değer 10M'dir ve bu, dfs.disk.balancer.max.disk.throughputInMBperSec'i yapılandırarak kontrol edilir;
-
Hata sayısının sınırı. DiskBalancer'da hata sayısının kontrolü vardır. Blok verilerini kopyalarken, bir IOException meydana gelecek ve hata sayısı artacaktır.Maksimum tolerans değeri aşılırsa, DiskBalancer da çıkacaktır;
-
Veri dengesi eşik kontrolü DiskBalancer, verileri dengelemeye devam edip etmeme konusunda standart olarak kullanılabilen diskler arasında bir veri dengesi eşiği sağlayabilir Yapılandırma öğesi dfs.disk.balancer.block.tolerance.percent'tir.
4.2.1.3 Veri bütünlüğü
Bir Datanode'den elde edilen veri bloğu hasar görmüş olabilir Hasar, bir Datanode depolama cihazı hatası, ağ hatası veya yazılım hatasından kaynaklanabilir. HDFS istemci yazılımı, HDFS dosyalarının içeriği üzerinde bir sağlama toplamı denetimi uygular. İstemci yeni bir HDFS dosyası oluşturduğunda, dosyanın her veri bloğunun sağlama toplamını hesaplar ve sağlama toplamını aynı HDFS ad alanında ayrı bir gizli dosya olarak kaydeder. Müşteri dosyanın içeriğini aldığında, Datanode'den elde edilen verilerin ilgili sağlama toplamı dosyasındaki sağlama toplamı ile eşleşip eşleşmediğini kontrol edecektir.Eğer eşleşmezse, müşteri diğer Datanode'lardan veri bloğunun bir kopyasını almayı seçebilir.
4.2.1.3.1 Geri Dönüşüm Kutusu Mekanizması
4.2.1.3.1.1 Dosya silme ve kurtarma
Geri dönüşüm kutusu işlevi etkinleştirilirse, FS Shell tarafından silinen dosyalar HDFS'den hemen silinmez. Bunun yerine, onu geri dönüşüm dizinine taşıyın (her kullanıcı / user / dizinindedir. < Kullanıcı adı > /.Trash'in kendi kurtarma dizini vardır). Dosya geri dönüşüm kutusunda kaldığı sürece, dosya hızla geri yüklenebilir.
Yakın zamanda silinen dosyalar mevcut geri dönüşüm dizinine (/ user / < Kullanıcı adı > /.Trash/Current) ve yapılandırılabilir bir zaman aralığı içinde, HDFS bir / user / çifti oluşturur < Kullanıcı adı > /.Çöp/ < tarih > Dizinin altındaki bir kontrol noktası ve süresi dolduktan sonra eski kontrol noktasını silin.
Dosya geri dönüşüm kutusunda sona erdiğinde, NameNode dosyayı HDFS ad alanından siler. Bir dosyanın silinmesi, dosyayla ilişkili bloğun serbest bırakılmasına neden olur. Bir dosyanın kullanıcı tarafından silinmesi ile karşılık gelen alanın serbest bırakılması arasında bariz bir zaman gecikmesi olduğu unutulmamalıdır.
4.2.1.3.1.2 Kopyaları küçültün
Bir dosyanın kopyalama faktörü azaldığında, Ad Düğümü silinebilecek gereksiz kopyaları seçer. Sonraki sinyal, bu bilgiyi DataNode'a iletir. DataNode daha sonra ilgili bloğu siler ve karşılık gelen alanı serbest bırakır. Benzer şekilde, çoğaltma faktörünün ayarlanmasının tamamlanması ile kümede yeni alanın ortaya çıkması arasında bir zaman gecikmesi vardır.
4.2.1.4 Meta Veri Disk Hatası
FsImage ve Edits, HDFS'nin temel veri yapılarıdır. Bu dosyalar hasar görürse, HDFS örneğinin tamamı geçersiz hale gelir. Bu nedenle, Namenode, FsImage ve Edits'in birden çok kopyasının korunmasını desteklemek için yapılandırılabilir. FsImage veya Düzenlemelerde yapılan herhangi bir değişiklik, kopyalarına senkronize edilecektir. Birden fazla kopyanın bu senkronizasyonu, Namenode'un saniyede işlediği ad alanı işlemlerinin sayısını azaltabilir. Bununla birlikte, bu fiyat kabul edilebilir, çünkü HDFS uygulamaları veri yoğun olsa bile, meta veri bilgileri çok büyük olmayacaktır. Namenode yeniden başladığında, kullanılacak en son FsImage ve Düzenlemeleri seçecektir.
4.2.1.4.1 Kontrol noktası düğümü
NameNode, ad alanı bilgilerini kaydetmek için iki dosya kullanır: en son kontrol noktalı ad alanı bilgisi olan fsimage: denetim noktası gerçekleştirildikten sonra ad alanı değişikliklerinin bir günlük dosyası olan düzenlemeler. NameNode başladığında, en son dosya sistemi meta verilerini sağlamak için fsimage ve düzenlemeler birleştirilir ve ardından NameNode yeni HDFS durumunu fsimage'a yazar ve yeni bir düzenleme günlüğü başlatır.
Denetim noktası düğümü, düzenli olarak ad alanının denetim noktalarını oluşturur. NameNode'dan fsimage ve düzenlemeleri indirir, bunları yerel olarak birleştirir ve aktif NameNode'a geri gönderir. Denetim noktası düğümü, aynı bellek gereksinimlerine sahip oldukları için genellikle NameNode ile aynı makinede değildir. Denetim noktası düğümü, yapılandırma dosyasındaki bin / hdfs namenode -checkpoint tarafından başlatılır.
Denetim Noktası (veya Yedekleme) düğümünün ve ekli web arabiriminin konumu, dfs.namenode.backup.address ve dfs.namenode.backup.http-address parametreleriyle belirtilir.
Checkpoint işleminin işleyişi iki yapılandırma parametresi tarafından kontrol edilir:
-
dfs.namenode.checkpoint.period, iki ardışık denetim noktası arasındaki maksimum zaman aralığı, varsayılan değer 1 saattir;
-
dfs.namenode.checkpoint.txns, kontrol noktası gerçekleştirmemiş maksimum işlem sayısı, varsayılan ayar 1 milyondur, yani Düzenlemelerdeki işlem sayısı 1 milyona ulaştığında, kontrol noktası dönemine ulaşılmasa bile bir birleştirme tetiklenecektir;
Denetim Noktası düğümüne kaydedilen en son denetim noktasının dizin yapısı, Ad Düğümü'ndekiyle aynıdır, böylece gerekirse Ad Düğümü gerçekleştirilen denetim noktasının dosya görüntüsünü her zaman okuyabilir. Küme yapılandırma dosyasında birden çok Denetim Noktası düğümü belirtilebilir.
4.2.1.4.2 Yedek düğüm
Yedekleme düğümü ve Kontrol Noktası düğümü, aynı kontrol noktası oluşturma işlevini sağlar, tek fark, aynı zamanda, NameNode ile senkronize olan en son ad alanının bir kopyasını bellekte kaydetmektedir.NameNodeeditsBackupedits
BackupNameNodefsimageeditsCheckpointNameNodeBackupfsimageedits
BackupNameNodeNameNodeBackupBackupCheckpont
BackupCheckpointbin/hdfs namenode backupBackup(Checkup)webdfs.namenode.backup.address dfs.namenode.backup.http-address
BackupNameNodeBackupNameNode-importCheckpointNameNodeeditsdfs.namenode.edits.dir
4.2.1.4.3
editsNameNode
-
dfs.namenode.name.dir
-
dfs.namenode.checkpoint.dir
-
-importCheckpointNameNode
NameNodedfs.namenode.checkpoint.dirdfs.namenode.name.dirdfs.namenode.name.dirNameNodeNameNodedfs.namenode.checkpoint.dir
4.2.1.4.4
metadatametadataNameNodenamenode recoverNameNode-forceeditsfsimage
4.2.1.4.5 Edits
EditsEditsXMLEditsHadoop 0.19Hadoop
-
binary Hadoop
-
xml XMLxmlfilename.xml
EditsEdits
-
binary Hadoop
-
xml XML
-
stats Edits
4.2.1.4.6 Image
Imagehdfs fsimageWebHDFS APIHadoopimageHadoop2.4oiv_legacy CommandImagefsimageImageHadoop
Image
-
WebHTTPWebHDFS APIHTTP REST API
-
XMLfsimageXMLfsimageXML
-
FileDistributionImagemaxSizes s ).maxSizeSizeNumFilesSizenumFilesImage-format
-
inodeinodeinode\t-delimiter
-
ReverseXMLXMLXMLfsimagefsimages
4.2.1.5
HDFSHDFS
HDFS
-
O1**inode
-
OMM/
-
datanode
-
HDFS
4.2.1.5.1 Snapshottable
snaphottable65,536
snaphottablesnaphottablesnaphottable
4.2.2
4.2.2.1
HDFSWebTCPHDFSwebHDFS
NameNodeDataNodeWebNameNode
4.2.2.2
hadoop-eclipse-plugin-version.jareclipsepluginseclipseHDFSwindows
4.2.2.3 JAVA
HDFSFileSystem Java API,javaHDFS
4.2.3
HadoopHDFSNameNodeNameNodeHDFSNameNode
4.2.4
LinuxR:read w:write x:executexzhangsanlinuxhadoopHDFSownerzhangsan
HDFSKerberos
4.2.4.1 HDFS
HadoopHDFSPOSIXrwrwx
POSIXsetuidsetgidsetuidsetgid bitsUnixBSD
HDFSPOSIX ACLHDFSHDFSfoo
-
foo;
-
foo
-
foo
4.3 HDFSQJM
Hadoop 2.0.0NameNodeHDFSSPOFNameNodeNameNode
HDFS
-
NameNode
-
NameNode
HDFS/3.0.0NameNodeNameNode
4.3.1
hadoop2.xCloueraQJM/Qurom Journal ManagerPaxosHDFS HA, HANameNodeNameNodeNameNodeStandby
JNJNJN
2N+1 JN Edits > =N+1NNPaxos
HASecondaryNameNodestandby NNActive NNJournalNode
Active NNJNlogJN Standby NN JN log JN log
Active NN Standby NN Active NN JNNN
DataNodeNameNodeNameNode
4.3.2 QJM
-
-
spof
-
-
JNJNNNJN
4.3.3 NNDN
-
NNDN
-
DNfailoverNNDNactiveDNNNactive
-
active NNDNactiveDNNN
4.3.4 NN
standby nnRPCFailoverProxyProviderNNNNNN
HadoopZKFailoverControllerNameNodedeamon, zkfc
4.3.5 FailoverController
-
HealthMonitor NameNodeunavailableunhealthyRPCNN
-
ActiveStandbyElector ZK
-
ZKFailoverController HealthMonitor ActiveStandbyElector NameNode
4.3.6 ZKFailoverController
-
NNNameNodezkfc
-
NNzkfczookeeperNameNodeActivezkfcZookeeperznodeNNznodeNNNNActive
-
NNzookeperznodeStandbyNN
-
masterzookeeperznodeNameNodeActive
HAStandby NameNodeHASecondary NameNodeCheckpointNodeBackupNode
4.4 HDFSNFS
NFSHAQJMactive namenodestandby namenodeeditsQJMjournalnodeeditsNFSNFSedits
NFSNFSHDFSHDFSHDFSNFS gatewayNFSHDFS
4.5 HDFS Federation
4.5.1 HDFS
-
Namenode
Datanode
-
depolama
Datanodes/
HDFSNamenodeHDFS FederrationHDFSNamenodes /
4.5.2
Active NNHDFSNNGNN
1G164T (1KB/block)
FederrationNamenodes/NamenodesDatanodesNamenodeDatanodeNamenodeDatanodesNamenode
,Hadoop 2.xHadoop 3.xHDFS Federation,
NNNN
NNidDN
DNidNNDNNN
NNNNNN
4.5.3
-
NNNN
-
-
NNFederation
4.5.4 ViewF
ViewViewFsHadoopHDFS FederationViewFUnix/LinuxViewF
ViewHadoop
4.5.4.1 Namenode
HDFSDatanodes
4.5.4.2 FederationViewF
namenodenamenodenamenodenamenode
namenode/user/ < Kullanıcı adı > feed/data/projects
4.5.4.3 ViewF
ViewFNamenodeUnix/user/data/projects/tmp
ViewFHadoopHDFSshellViewFSHDFS
5.
hadoopbin/hdfshdfs
hdfs COMMAND
Hadoop
Daha heyecan verici kuru ürün içeriği için lütfen Tsinghua-Qingdao Veri Bilimi Enstitüsü "Datapai THU" nun resmi kamu platformunu araştırın ve takip edin
