Azure Data Lake'i kullanmanın en iyi Depolama 2. Nesil

Bu makalede, Azure Data Lake Depolama 2. Nesil ile çalışmaya yönelik en iyi yöntemler ve önemli noktalar hakkında bilgi edinebilirsiniz. Bu makalede Data Lake Depolama 2. Nesil için güvenlik, performans, Depolama ve izleme hakkında bilgi velanmıştır. Data Lake Depolama 2. Nesil'den önce, veri kaynağı gibi hizmetlerde gerçek Azure HDInsight çalışmak karmaşıktı. Petabayt depolama ve bu ölçekte en iyi performansı elde etmek için verileri birden çok Blob depolama hesabı arasında parçalamanız gerekirdi. Data Lake Depolama 2. Nesil, 190,7 TiB'ye kadar olan tek tek dosya boyutlarını destekler ve performans için sabit sınırların çoğu kaldırılmıştır. Ancak, Data Lake 2. Nesil ile en iyi performansı elde etmek için bu makalenin üzerinde Depolama vardır.

Güvenlik konuları

Azure Data Lake Depolama 2. Nesil, Azure Active Directory ( Azure AD) kullanıcıları, grupları ve hizmet sorumluları için POSIX erişim denetimleri sunar. Bu erişim denetimleri var olan dosya ve dizinlere ayar olabilir. Erişim denetimleri, yeni dosyalara veya dizinlere otomatik olarak uygulanan varsayılan izinler oluşturmak için de kullanılabilir. Data Lake Depolama 2. Nesil ACL'ler hakkında daha fazla bilgi için Azure Data Lake Depolama 2. Nesil'de erişim denetimine bakın.

Güvenlik gruplarını bireysel kullanıcılarla karşılaştırmalı kullanma

Data Lake Depolama 2. Nesil'de büyük verilerle çalışırken, Azure HDInsight gibi hizmetlerin verilerle çalışmasına izin vermek için büyük olasılıkla bir hizmet sorumlusu kullanılır. Ancak, tek tek kullanıcıların da verilere erişmesi gereken durumlar olabilir. Her durumda, dizinlere ve Azure Active Directory tek kullanıcılar atamak yerine güvenlik gruplarını kullanmayı kesinlikle göz önünde bulundurabilirsiniz.

Güvenlik grubuna izinler atandıktan sonra, gruptan kullanıcı eklemek veya gruptan kaldırmak için Data Lake Depolama 2. Nesil güncelleştirmeleri gerekli değildir. Bu, erişim denetim listesi (ACL) başına erişim denetimi girdisi sayısı üst sınırını aşmamanıza da yardımcı olur. Şu anda bu sayı 32'dir (her dosya ve dizinle ilişkilendirilmiş dört POSIX stili ACL dahil): sahip olan kullanıcı, sahip olan grup, maske ve diğer. Her dizin, toplam 64 erişim denetimi girdisi için erişim ACL'sini ve varsayılan ACL'sini olmak üzere iki tür ACL'ye sahip olabilir. Bu ACL'ler hakkında daha fazla bilgi için bkz. Azure Data Lake Depolama 2. Nesil'de erişim denetimi.

Gruplar için güvenlik

Siz veya kullanıcılarınız hiyerarşik ad alanı etkinleştirilmiş bir depolama hesabı içinde verilere erişmeye ihtiyaç Azure Active Directory en iyisidir. Başlangıç olarak önerilen bazı gruplar, kapsayıcının kökü için ReadOnlyUsers, WriteAccessUsers ve FullAccessUsers, hatta anahtar alt dizinleri için ayrı gruplar olabilir. Daha sonra eklense de henüz belirlenmemiş başka beklenen kullanıcı grupları varsa, belirli klasörlere erişimi olan sahte güvenlik grupları oluşturmayı düşünebilirsiniz. Güvenlik grubunu kullanmak, binlerce dosya için yeni izinler atarken uzun işlem süresiyle kaçınabilirsiniz.

Hizmet sorumluları için güvenlik

Azure Active Directory sorumluları genellikle Data Lake Azure Databricks 2. Nesil'de verilere erişmek için Depolama kullanılır. Birçok müşteri için tek Azure Active Directory hizmet sorumlusu yeterli olabilir ve Data Lake Depolama 2. Nesil kapsayıcısı kökünde tam izinlere sahip olabilir. Diğer müşteriler, bir kümenin verilere tam erişime sahip olduğu farklı hizmet sorumlularına sahip birden çok kümeye ve yalnızca okuma erişimine sahip başka bir kümeye ihtiyaç kullanabilir.

Azure hizmet erişimiyle Data Lake Depolama 2. Nesil güvenlik duvarını etkinleştirme

Data Lake Depolama 2. Nesil, bir güvenlik duvarını açma ve yalnızca Azure hizmetleriyle erişimi sınırlama seçeneğini destekler. Bu, dış saldırıların vektörü için önerilir. Güvenlik duvarı, güvenlik duvarının hizmet Azure portal Güvenlik Duvarını Etkinleştir > (ON) Azure hizmetleri için erişime izin ver seçenekleri > aracılığıyla etkinleştirilebilir.

Depolama hesabınıza sanal ağdan Azure Databricks için, Azure Databricks sanal ağınıza dağıtın ve ardından bu sanal ağı güvenlik duvarınıza ekleyin. Bkz. Azure Depolama güvenlik duvarlarını ve sanal ağları yapılandırma.

Dayanıklılık konuları

Data Lake Depolama 2. Nesil veya herhangi bir bulut hizmetine sahip bir sistem mimarisini benimserken kullanılabilirlik gereksinimlerinizi ve hizmette olası kesintilere nasıl yanıt verebilirsiniz? Bir sorun belirli bir örnek için yerelleştirilmiş, hatta bölge genelinde olabilir, bu nedenle her ikisi için de bir plan yapmak önemlidir. İş yükünüz için kurtarma süresi hedefine ve kurtarma noktası hedefi SLA'larına bağlı olarak, yüksek kullanılabilirlik ve olağanüstü durum kurtarma için daha fazla veya daha az agresif bir strateji seçebilirsiniz.

Yüksek kullanılabilirlik ve olağanüstü durum kurtarma

Yüksek kullanılabilirlik (HA) ve olağanüstü durum kurtarma (DR) bazen bir arada kullanılabilir, ancak özellikle veri söz konusu olduğunda her biri biraz farklı bir stratejiye sahip olabilir. Data Lake Depolama 2. Nesil, yerelleştirilmiş donanım hatalarına karşı koruma için 3 kat çoğaltmayı zaten idare ediyor. Buna ek olarak, ZRS veya GZRS gibi diğer çoğaltma seçenekleri HA'yı iyilerken GRS & RA-GRS DR'yi iyiler. Yüksek kullanılabilirlik planı hazırlarken, hizmet kesintisi durumunda iş yükünün en son verilere mümkün olan en kısa sürede erişmesi ve yerel olarak veya yeni bir bölgede ayrı çoğaltılmış bir örnekle geçiş yapılması gerekir.

Bir DR stratejisinde, bir bölgenin yıkıcı bir hatanın olası olmayan olayına hazırlanmak için verilerin GRS veya RA-GRS çoğaltması kullanılarak farklı bir bölgeye çoğaltılması da önemlidir. Geri dönmek için düzenli anlık görüntüler oluşturmak istemeniz gereken veri bozulması gibi uç durumlarla ilgili gereksinimlerinizi de göz önünde bulundurabilirsiniz. Verilerin önemine ve boyutuna bağlı olarak, risk toleransları dikkate alınarak 1,6 ve 24 saatlik dönemlerin delta anlık görüntülerinin kayan bir şekilde kaydedilmesini göz önünde bulundurabilirsiniz.

Data Lake Depolama 2. Nesil ile veri resilisi için verilerinizi GRS veya RA-GRS aracılığıyla coğrafi olarak çoğaltmanız önerilir. Buna ek olarak, Data Lake Depolama 2. Nesil'i kullanarak uygulamanın izleme tetikleyicileri veya başarısız denemelerin uzunluğu aracılığıyla otomatik olarak ikincil bölgeye yük devretmesi için yolları göz önünde bulundurabilirsiniz veya en azından el ile müdahale için yöneticilere bir bildirim gönderebilirsiniz. Bir hizmetin yeniden çevrimiçine geri dönmelerini beklemek yerine, üzerine adelenin üzerinde işlem yapma konusunda bir takas olduğunu unutmayın.

İki konum arasında veri taşıma için Distcp kullanma

Dağıtılmış kopyanın kısası olan DistCp, Hadoop ile birlikte gelen ve iki konum arasında dağıtılmış veri hareketi sağlayan bir Linux komut satırı aracıdır. İki konum Data Lake Depolama 2. Nesil, HDFS veya S3 olabilir. Bu araç, MapReduce ölçeğini bir Hadoop kümesinde (hdInsight gibi) kullanarak ölçeğini genişletin. Distcp, özel ağ sıkıştırma gereçleri olmadan büyük verileri taşımanın en hızlı yolu olarak kabul edilir. Distcp ayrıca yalnızca iki konum arasındaki deltaları güncelleştirme seçeneği sağlar, otomatik yeniden denemeleri işlemenin yanı sıra işlem dinamik ölçeklendirmesini de sağlar. Bu yaklaşım, tek bir dizinde çok sayıda büyük dosyaya sahip olan Hive/Spark tabloları gibi şeyleri çoğaltmak söz konusu olduğunda ve yalnızca değiştirilen veriler üzerinde kopyalama yapmak istediğinizde son derece verimlidir. Bu nedenlerden dolayı Distcp, büyük veri depoları arasında veri kopyalama için en çok önerilen araçtır.

Kopyalama işleri, sıklık veya veri tetikleyicileri ve Linux cron işleri kullanılarak Apache Oozie iş akışları tarafından tetiklenir. Yoğun çoğaltma işleri için, kopyalama işleri için özel olarak ayarlayıp ölçeklendirilen ayrı bir HDInsight Hadoop kümesi oluşturmanız önerilir. Bu, kopyalama işlerinin kritik işlere müdahale etmemelerini sağlar. Çoğaltmayı yeterince geniş bir sıklıkta çalıştırıyorsanız, küme her iş arasında aşağı bile kaldırabilirsiniz. İkincil bölgeye başarısız oluyorsanız, yeni verileri birincil Data Lake Depolama 2. Nesil hesabına çoğaltmak için ikincil bölgede başka bir kümenin de kullanılabilir olduğundan emin olun. Distcp kullanma örnekleri için bkz. Azure Depolama Blobları ile Data Lake Depolama 2. Nesil arasında veri kopyalamak için Distcp kullanma.

Kopyalama Azure Data Factory zamanlaması için Azure Data Factory'i kullanma

Azure Data Factory Kopyalama Etkinliği kullanarak kopyalama işleri zamanlaması için de kullanılabilir ve hatta Kopyalama Sihirbazı aracılığıyla bir sıklıkta da ayarlandırabilirsiniz. Bulut veri taşıma Azure Data Factory (DMU) sınırı olduğunu ve sonunda büyük veri iş yükleri için aktarım hızını/hesaplamayı sınırlaya kadar olduğunu unutmayın. Ayrıca, Azure Data Factory Data Lake Depolama 2. Nesil hesapları arasında delta güncelleştirmeler sunmayıp Hive tabloları gibi dizinlerin çoğaltmak için tam bir kopya gerektirmesi gerekir. Veri fabrikası ile kopyalama hakkında daha fazla bilgi için veri fabrikası makalesine Data Factory.

İzlemeyle ilgili dikkat edilmesi gerekenler

Data Lake Depolama 2. Nesil, Data Lake Azure portal 2. Nesil hesabı altında ve Depolama veri Azure İzleyici. Data Lake Depolama 2. Nesil'in kullanılabilirliği Azure portal. Data Lake Depolama 2. Nesil hesabının en güncel kullanılabilirliğini elde etmek için, kullanılabilirliği doğrulamak için kendi yapay testlerinizi çalıştırmanız gerekir. Toplam depolama alanı kullanımı, okuma/yazma istekleri ve giriş/çıkış gibi diğer ölçümler izleme uygulamaları tarafından kullanılabilir ve eşikler (örneğin, Ortalama gecikme süresi veya dakika başına hata sayısı) aşılırsa uyarılar tetikler.

Dizin düzeninde dikkat edilmesi gerekenler

Verileri bir veri gölüne giriş sırasında, güvenliğin, bölümlemenin ve işlemenin etkili bir şekilde kullanılaması için verilerin yapısını önceden planlamak önemlidir. Aşağıdaki önerilerin çoğu tüm büyük veri iş yükleri için geçerlidir. Her iş yükünün verilerin nasıl tüketildiğiyle ilgili farklı gereksinimleri vardır, ancak aşağıda IoT ve toplu iş senaryolarıyla çalışırken göz önünde bulundurabilirsiniz.

IoT yapısı

IoT iş yüklerinde çok sayıda ürün, cihaz, kuruluş ve müşteriyi kapsayan veri deposuna çok sayıda veri inebilir. Aşağı akış tüketicileri için verilerin düzenleme, güvenlik ve verimli işleme için dizin düzenini önceden planlamak önemlidir. Göz önünde olacak genel bir şablon aşağıdaki düzen olabilir:

{Region}/{SubjectMatter(s)}/{yyyy}/{mm}/{dd}/{hh}/

Örneğin, Birleşik Krallık'ta bulunan bir uçak motorunun giriş telemetrisi aşağıdaki yapıya benzer olabilir:

UK/Planes/BA1293/Engine1/2017/08/11/12/

Tarihi dizin yapısının sonuna koymak için önemli bir neden vardır. Belirli bölgeleri kilitlemek veya önemli olan kullanıcıları/grupları kilitlemek için POSIX izinleriyle bunu kolayca yapabilirsiniz. Aksi takdirde, belirli bir güvenlik grubunun yalnızca Birleşik Krallık verilerini veya belirli düzlemleri görüntülemesini kısıtlamak gerekirse, tarih yapısı önünde saat dizini altında çok sayıda dizin için ayrı bir izin gerekir. Buna ek olarak, tarih yapısının önünde olması, zaman devam etti olarak dizin sayısını üstel olarak artıracaktır.

Batch işleri yapısı

Yüksek düzeyden, toplu işlemede yaygın olarak kullanılan bir yaklaşım, verileri "in" dizinine indirerek yapmaktır. Ardından, veriler işlendikten sonra aşağı akış işlemlerinin tüketilmesi için yeni verileri bir "out" dizinine alın. Bu dizin yapısı bazen tek tek dosyalarda işleme gerektiren işler için görülür ve büyük veri kümeleri üzerinde yüksek oranda paralel işleme gerektirmeyebilirsiniz. Yukarıda önerilen IoT yapısında olduğu gibi, iyi bir dizin yapısı bölge ve konu konuları (örneğin, kuruluş, ürün/üretici) gibi şeyler için üst düzey dizinlere sahiptir. Bu yapı, kuruluş genelindeki verilerin güvenliğinin sağlanmasına ve iş yükleriniz içinde verilerin daha iyi yönetimine yardımcı olur. Ayrıca işlemede daha iyi bir kuruluş, filtrelenmiş arama, güvenlik ve otomasyona olanak vermek için yapıda tarih ve saati göz önünde bulundurabilirsiniz. Tarih yapısının ayrıntı düzeyi verilerin karşıya yüklenme veya işlenme aralığına (saatlik, günlük, hatta aylık gibi) göre belirlenir.

Bazen veri bozulması veya beklenmeyen biçimler nedeniyle dosya işleme başarısız olur. Bu gibi durumlarda, dizin yapısı bir /Bad klasöründen daha fazla inceleme için dosyaları taşımak için faydalanabilir. Toplu iş, el ile müdahale için bu Hatalı dosyaların raporlamasını veya bildirimini de işleyebilir. Aşağıdaki şablon yapısını göz önünde bulundurun:

{Region}/{Subjectınsınlar}/ın/{yyyy}/{mm}/{dd}/{ss}/
{Region}/{Subjectler}/Out/{yyyy}/{mm}/{dd}/{ss}/
{Region}/{Subjectönemi}/Bad/{yyyy}/{mm}/{dd}/{ss}/

Örneğin, bir pazarlama firması, müşteri güncelleştirmelerinin Kuzey Amerika içindeki istemcilerinden günlük veri ayıklar. İşlenmeden önce ve sonra aşağıdaki kod parçacığına benzeyebilir:

NA/ayıklar/ACMEPaperCo/ın/2017/08/14/updates_08142017.csv
NA/ayıklar/ACMEPaperCo/Out/2017/08/14/processed_updates_08142017.csv

toplu iş verilerinin doğrudan hive veya geleneksel SQL veritabanları gibi veritabanlarına işlendiği durumlarda, çıkış zaten hive tablosu veya dış veritabanı için ayrı bir klasöre geçtiğinde, /ın veya /out klasörüne gerek yoktur. Örneğin, müşterilerden günlük ayıklamalar ilgili klasörlerine giderek Azure Data Factory, Apache Oozie veya Apache Airflow gibi bir şey tarafından düzenleme, günlük bir Hive veya Spark işinin verileri bir Hive tablosuna işlemesi ve yazması için tetikleyecektir.