Azure Data Lake Depolama hesabıyla birden çok HDInsight kümesi kullanma
HDInsight sürüm 3.5'den başlayarak, varsayılan dosya sistemi olarak Azure Data Lake Depolama hesaplarıyla HDInsight kümeleri oluşturabilirsiniz. Data Lake Depolama, yalnızca büyük miktarda veri barındırmak için değil, aynı zamanda tek bir Data Lake Depolama Hesabını paylaşan birden çok HDInsight kümesini barındırmak için de ideal hale getiren sınırsız depolamayı destekler. Depolama alanı olarak Data Lake Depolama ile HDInsight kümesi oluşturma yönergeleri için bkz. Hızlı Başlangıç: HDInsight'ta kümeleri ayarlama.
Bu makalede Data Lake Depolama yöneticisine birden çok etkin HDInsight kümesinde kullanılabilecek tek ve paylaşılan bir Data Lake Depolama Hesabı ayarlama önerileri sağlanır. Bu öneriler paylaşılan bir Data Lake Depolama hesabında birden çok güvenli ve güvenli olmayan Apache Hadoop kümesi barındırmak için geçerlidir.
Data Lake Depolama dosya ve klasör düzeyi ACL'leri
Bu makalenin geri kalanında Azure Data Lake Depolama'daki dosya ve klasör düzeyi ACL'ler hakkında iyi bilgi sahibi olduğunuz varsayılır. Bu bilgiler Azure Data Lake Depolama'daki Erişim denetimi bölümünde ayrıntılı olarak açıklanmıştır.
Birden çok HDInsight kümesi için Data Lake Depolama kurulumu
Data Lake Depolama hesabıyla birden çok HDInsight kümesi kullanma önerilerini açıklamak için iki düzeyli bir klasör hiyerarşisi alalım. /clusters/finance klasör yapısına sahip bir Data Lake Depolama hesabınız olduğunu düşünün. Bu yapıyla, Finans kuruluşu tarafından gereken tüm kümeler depolama konumu olarak /clusters/finance kullanabilir. Gelecekte Pazarlama gibi başka bir kuruluş aynı Data Lake Depolama hesabını kullanarak HDInsight kümeleri oluşturmak isterse /clusters/marketing oluşturabilir. Şimdilik yalnızca /clusters/finance kullanalım.
Bu klasör yapısının HDInsight kümeleri tarafından etkili bir şekilde kullanılmasını sağlamak için Data Lake Depolama yöneticisinin tabloda açıklandığı gibi uygun izinleri ataması gerekir. Tabloda gösterilen izinler Access-ACL'lere karşılık gelir ve Default-ACL'lere karşılık gelir.
| Klasör | İzinler | Sahip olan kullanıcı | Sahip olan grup | Adlandırılmış kullanıcı | Adlandırılmış kullanıcı izinleri | Adlandırılmış grup | Adlandırılmış grup izinleri |
|---|---|---|---|---|---|---|---|
| / | rwxr-x--x | yönetici | yönetici | Hizmet sorumlusu | --X | FINGRP | r-x |
| /Küme | rwxr-x--x | yönetici | yönetici | Hizmet sorumlusu | --X | FINGRP | r-x |
| /clusters/finance | rwxr-x--t | yönetici | FINGRP | Hizmet sorumlusu | rwx |
- | - |
Tabloda,
- yönetici, Data Lake Depolama hesabının oluşturucusu ve yöneticisidir.
- Hizmet sorumlusu , hesapla ilişkili Microsoft Entra hizmet sorumlusudur.
- FINGRP , Microsoft Entra Id'de oluşturulan ve Finans kuruluşundaki kullanıcıları içeren bir kullanıcı grubudur.
Microsoft Entra uygulaması oluşturma yönergeleri (hizmet sorumlusu da oluşturur) için bkz . Microsoft Entra uygulaması oluşturma. Microsoft Entra Id'de kullanıcı grubu oluşturma yönergeleri için bkz . Microsoft Entra Id'de grupları yönetme.
Dikkate alınması gereken bazı önemli noktalar.
İki düzeyli klasör yapısı (/clusters/finance/) kümeler için depolama hesabı kullanılmadan önce Data Lake Depolama yöneticisi tarafından uygun izinlerle oluşturulup sağlanmalıdır. Kümeler oluşturulurken bu yapı otomatik olarak oluşturulmaz.
Yukarıdaki örnek, sahip olan /clusters/finance grubunu FINGRP olarak ayarlamayı ve kökten başlayarak tüm klasör hiyerarşisine R-X'in FINGRP erişimine izin vermenizi önerir. Bu, FINGRP üyelerinin kökten başlayarak klasör yapısında gezinebilmesini sağlar.
Farklı Microsoft Entra hizmet sorumlularının /clusters/finance altında kümeler oluşturabilmesi durumunda, yapışkan bit (finans klasöründe ayarlandığında), bir Hizmet Sorumlusu tarafından oluşturulan klasörlerin diğerinin silinememesini sağlar.
Klasör yapısı ve izinleri uygulandıktan sonra HDInsight küme oluşturma işlemi /clusters/finance/ altında kümeye özgü bir depolama konumu oluşturur. Örneğin, fincluster01 adlı bir kümenin depolama alanı /clusters/finance/fincluster01 olabilir. HDInsight kümesi tarafından oluşturulan klasörlerin sahipliği ve izinleri buradaki tabloda gösterilmiştir.
Klasör İzinler Sahip olan kullanıcı Sahip olan grup Adlandırılmış kullanıcı Adlandırılmış kullanıcı izinleri Adlandırılmış grup Adlandırılmış grup izinleri /clusters/finanace/ fincluster01 rwxr-x--- Hizmet Sorumlusu FINGRP - - - -
İş giriş ve çıkış verileri için Öneriler
Bir işe veri girişi yapmanızı ve bir işten elde edilen çıkışların /clusters dışındaki bir klasörde depolanmasını öneririz. Bu, kümeye özgü klasör bir miktar depolama alanını geri kazanmak için silinse bile iş girişlerinin ve çıkışlarının gelecekte kullanılmak üzere kullanılabilir olmasını sağlar. Böyle bir durumda, iş girişlerini ve çıkışlarını depolamak için klasör hiyerarşisinin Hizmet Sorumlusu için uygun erişim düzeyine izin verdiğinden emin olun.
Tek bir depolama hesabını paylaşan kümelerde sınır
Tek bir Data Lake Depolama hesabını paylaşabilen küme sayısı sınırı, bu kümelerde çalıştırılan iş yüküne bağlıdır. Depolama hesabını paylaşan kümelerde çok fazla küme veya ağır iş yükü olması, depolama hesabı girişi/çıkışının kısıtlanmasına neden olabilir.
Default-ACL desteği
Adlandırılmış kullanıcı erişimine sahip bir Hizmet Sorumlusu oluştururken (tabloda gösterildiği gibi), adlandırılmış kullanıcıyı varsayılan ACL ile eklememenizi öneririz. Default-ACL'ler kullanılarak adlandırılmış kullanıcı erişimi sağlanması, sahip olan-kullanıcı, sahip olan-grup ve diğerleri için 770 izin ataması ile sonuçlandı. Bu varsayılan değer olan 770, sahip olan kullanıcı (7) veya sahip olan grup (7) izinlerini almasa da, diğer kullanıcıların tüm izinlerini alır (0). Bu, Bilinen sorunlar ve geçici çözümler bölümünde ayrıntılı olarak açıklanan belirli bir kullanım örneğinde bilinen bir sorunla sonuçlanır .
Bilinen sorunlar ve geçici çözümler
Bu bölümde, HDInsight'ı Data Lake Depolama ile kullanmaya yönelik bilinen sorunlar ve bunların geçici çözümleri listelenir.
Genel olarak görünür yerelleştirilmiş Apache Hadoop YARN kaynakları
Yeni bir Azure Data Lake Depolama hesabı oluşturulduğunda, kök dizin Access-ACL izin bitleri 770 olarak ayarlanmış olarak otomatik olarak sağlanır. Kök klasörün sahibi olan kullanıcı hesabı oluşturan kullanıcıya (Data Lake Depolama yöneticisi) ve sahip olan grup ise hesabı oluşturan kullanıcının birincil grubuna ayarlanır. "Diğerleri" için erişim sağlanmadı.
Bu ayarların YARN 247'de yakalanan belirli bir HDInsight kullanım örneğini etkilediği bilinmektedir. İş gönderimleri şu hata iletisiyle başarısız olabilir:
Resource XXXX is not publicly accessible and as such cannot be part of the public cache.
Daha önce bağlı YARN JIRA'da belirtildiği gibi, genel kaynakları yerelleştirirken yerelleştirici, uzak dosya sistemi üzerindeki izinlerini denetleyerek istenen tüm kaynakların gerçekten genel olduğunu doğrular. Bu koşula uymayan tüm LocalResource yerelleştirme için reddedilir. İzinleri denetleme, "diğerleri" için dosyaya okuma erişimi içerir. Azure Data Lake kök klasör düzeyinde "diğerlerine" tüm erişimi reddettiğından, Azure Data Lake'te HDInsight kümelerini barındırırken bu senaryo hazır çalışmaz.
Geçici çözüm
Hiyerarşi aracılığıyla başkaları için okuma-yürütme izinleri ayarlayın; örneğin, /tabloda gösterildiği gibi , /clusters ve /clusters/finance.