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

Bu makale, Performansı iyileştirmenize, maliyetleri azaltmanıza ve Data Lake Depolama 2. Nesil etkin Azure Depolama yönergeleri sağlar.

Belgeleri bulma

Azure Data Lake Depolama 2. Nesil ayrılmış bir hizmet veya hesap türü değildir. Yüksek aktarım hızı analiz iş yüklerini destekleyen bir dizi özelliktir. Data Lake Depolama 2. Nesil belgeleri, bu özellikleri kullanmaya yönelik en iyi yöntemler ve rehberlik sağlar. Ağ güvenliğini ayarlama, yüksek kullanılabilirlik için tasarlama ve olağanüstü durum kurtarma gibi hesap yönetiminin diğer tüm yönleri için Blob depolama belgeleri içeriğine bakın.

Özellik desteğini ve bilinen sorunları değerlendirme

Blob depolama özelliklerini kullanmak için hesabınız yapılandırılırken aşağıdaki düzeni kullanın.

1. Bir özelliğin Depolama olup olmadığını belirlemek için Azure Depolama hesaplarında Blob depolama özelliği desteği makalesini gözden geçirebilirsiniz. Bazı özellikler henüz desteklenmiyor veya Data Lake 2. Nesil etkin hesaplarda Depolama desteğine sahip değil. Özellik desteği her zaman genişlemektedir, bu nedenle güncelleştirmeler için bu makaleyi düzenli aralıklarla gözden geçirmeyi emin olun.

2. Kullanmakta olduğu özellikle ilgili sınırlamalar veya özel rehberlik olup Depolama 2. Nesil'de Azure Data Lake ile ilgili bilinen sorunlar makalesini gözden geçirebilirsiniz.

3. Data Lake 2. Nesil etkin hesaplara özgü tüm Depolama için özellik makalelerini tarayın.

Belgelerde kullanılan terimleri anlama

İçerik kümeleri arasında ilerlerken bazı küçük terminoloji farkları fark edersiniz. Örneğin, Blob depolama belgelerinde öne çıkan içerik,dosyası yerine blob terimini kullanır. Teknik olarak, depolama hesabınıza alan dosyalar, hesapta bloblar haline geliyor. Bu nedenle terimi doğru. Ancak, dosya terimini kullanıyorsanız bu karışıklığa neden olabilir. Ayrıca, bir dosya sistemine başvurmak için kullanılan kapsayıcı terimini de görüyorsunuz. Bu terimleri eş anlamlı olarak düşünün.

Premium'a dikkat

İş yükleriniz düşük tutarlı gecikme süresi ve/veya saniye başına yüksek sayıda giriş çıkış işlemleri (IOP) gerektirirse premium blok blobu depolama hesabı kullanmayı göz önünde bulundurabilirsiniz. Bu hesap türü, verileri yüksek performanslı donanımlar aracılığıyla kullanılabilir yapar. Veriler, düşük gecikme süresi için iyileştirilmiş katı hal sürücülerinde (SDD) depolanır. SSD'ler geleneksel sabit sürücülere kıyasla daha yüksek aktarım hızı sağlar. Premium performansın depolama maliyetleri daha yüksektir, ancak işlem maliyetleri daha düşüktür, bu nedenle iş yükleriniz çok sayıda işlem yürütürse premium performans blok blobu hesabı ekonomik olabilir.

Depolama hesabınız analiz için kullanılacaksa, Premium blok blobu depolama hesabıyla birlikte Azure Data Lake Depolama 2. Nesil'i de kullanmanızı kesinlikle öneririz. Premium blok blobu depolama hesaplarının ve Data Lake Depolama hesabı kullanmanın bu birleşimi, Azure Data LakeDepolama.

Veri toplama için iyileştirme

Bir kaynak sistemden veri alan kaynak donanım, kaynak ağ donanımı veya depolama hesabınıza ağ bağlantısı bir performans sorunu olabilir.

Kaynak donanım

Azure'da ister şirket içi makineler ister Sanal Makineler (VM) kullanıyor olun, uygun donanımı dikkatli bir şekilde seçin. Disk donanımı için Katı Hal Sürücülerini (SSD) kullanmayı ve daha hızlı sürücüleri olan disk donanımlarını seçmeyi göz önünde bulundurabilirsiniz. Ağ donanımı için mümkün olan en hızlı Ağ Arabirimi Denetleyicilerini (NIC) kullanın. Azure'da uygun güçlü disk ve ağ donanımına sahip Azure D14 VM'lerini öneririz.

Depolama hesabına ağ bağlantısı

Kaynak verilerinizle depolama hesabınız arasındaki ağ bağlantısı bazen bir performans sorunu olabilir. Kaynak verileriniz şirket içinde olduğunda, veri kaynağı ile ayrılmış bir bağlantı Azure ExpressRoute. Kaynak verileriniz Azure'da ise, veriler Data Lake'iniz ve 2. Nesil etkin hesabınızla aynı Azure bölgesinde olduğunda Depolama en iyi performanstır.

Maksimum paralelleştirme için veri alımı araçlarını yapılandırma

En iyi performansı elde etmek için mümkün olduğunca çok okuma ve yazmayı paralel olarak gerçekleştirerek tüm kullanılabilir aktarım hızını kullanın.

Aşağıdaki tabloda, çeşitli popüler veri alımı araçlarının temel ayarları özetlenmiştir.

Hesabınız tüm analiz senaryoları için gerekli aktarım hızını sağlayacak şekilde ölçeklendirebilirsiniz. Data Lake Depolama 2. Nesil hesabı varsayılan olarak, geniş bir kullanım örnekleri kategorisinin ihtiyaçlarını karşılamak için varsayılan yapılandırmasında yeterli aktarım hızı sağlar. Varsayılan sınıra ulaşıyorsanız, hesap ile iletişim kurarak daha fazla aktarım hızı sağlayacak şekildeAzure Desteği.

Veri kümelerini yapılandır

Verilerinizin yapısını önceden planlamayı göz önünde bulundurabilirsiniz. Dosya biçimi, dosya boyutu ve dizin yapısı performansı ve maliyeti etkileyebilir.

Dosya biçimleri

Veriler çeşitli biçimlerde alındı. Veriler JSON, CSV veya XML gibi insanlar tarafından okunabilir biçimlerde veya gibi sıkıştırılmış ikili biçimlerde .tar.gz görünebilir. Veriler farklı boyutlarda da gelebilir. Veriler, şirket içi sistemlerinizin bir tabloyu dışarı aktarması gibi büyük dosyalardan (birkaç terabayt) SQL olabilir. Veriler, bir şeyler İnterneti (IoT) çözümünden gelen gerçek zamanlı olaylar gibi çok sayıda küçük dosya (birkaç kilobayt) şeklinde de gelebilir. Uygun bir dosya biçimi ve dosya boyutu seçerek verimliliği ve maliyetleri en iyi duruma getirmenizi sağlar.

Hadoop, yapılandırılmış verileri depolamak ve işlemek için iyileştirilmiş bir dizi dosya biçimlerini destekler. Avro, Parquet ve İyileştirilmiş Satır Sütunlu (ORC) biçim bazı yaygın biçimlerdir. Bu biçimlerin hepsi makine tarafından okunabilir ikili dosya biçimleridir. Dosya boyutunu yönetmenize yardımcı olmak için sıkıştırılırlar. Her dosyaya eklenmiş bir şemaya sahipler ve bu da kendilerini açıklayan bir şemaya sahip olur. Bu biçimler arasındaki fark, verilerin depolandığı biçimdir. Avro, verileri satır tabanlı biçimde depolar ve Parquet ve ORC biçimleri de verileri sütun biçiminde depolar.

Avro dosya biçimini, I/O desenlerinin daha yoğun yazması veya sorgu desenlerinin tamamen birden çok kayıt satırı alma tercihi olduğu durumlarda kullanmayı göz önünde bulundurabilirsiniz. Örneğin Avro biçimi, Olay Hub'ı veya Kafka gibi bir ileti verisi ile birlikte çalışır ve bu verilerle aynı anda birden çok olay/ileti yazar.

I/O desenleri daha yoğun okunur olduğunda veya sorgu desenleri kayıtlarda sütunların bir alt kümesine odaklanıyorsa Parquet ve ORC dosya biçimlerini göz önünde bulundurabilirsiniz. Okuma işlemleri, kaydın tamamını okumak yerine belirli sütunları almak için iyileştirilmiş olabilir.

Apache Parquet, yoğun okumalı analiz işlem hatları için iyileştirilmiş bir açık kaynak dosya biçimidir. Parquet'in sütunlu depolama yapısı, ilgili olmayan verileri atlar. Sorgularınız, depolamadan analiz altyapısına hangi verilerin göndernsin daha dar kapsamda olacak şekilde daraltılaya kadar çok daha verimlidir. Ayrıca, benzer veri türleri (bir sütun için) birlikte depolandığı için Parquet, veri depolama maliyetlerini düşüren verimli veri sıkıştırma ve kodlama düzenlerini destekler. Azure Synapse Analytics, Azure Databricks ve Azure Data Factory, Parquet dosya biçimlerinden yararlanan yerel işlevlere sahiptir.

Dosya boyutu

Daha büyük dosyalar daha iyi performansa ve daha düşük maliyetlere neden olur.

HdInsight gibi analiz altyapıları genellikle listeleme, erişimi denetleme ve çeşitli meta veri işlemlerini gerçekleştirme gibi görevleri içeren dosya başına ek yüke sahiptir. Verilerinizi çok sayıda küçük dosya depolarsanız bu, performansı olumsuz etkileyebilir. Genel olarak, daha iyi performans (256 MB ile 100 GB arasında boyut) için verilerinizi daha büyük boyutlu dosyalar olarak düzenleyebilirsiniz. Bazı altyapılar ve uygulamalar, boyutu 100 GB'ın üzerinde olan dosyaları verimli bir şekilde işleme konusunda sorun olabilir.

Dosya boyutunu artırmak işlem maliyetlerini de düşürebilirsiniz. Okuma ve yazma işlemleri 4 megabayt artışla faturalandırılır, bu nedenle dosyanın 4 megabayt veya yalnızca birkaç kilobayt içerdiğinde işlem için ücret tahsil edilecektir. Fiyatlandırma bilgileri için bkz. Azure Data Lake Depolama fiyatlandırması.

Bazen veri işlem hatları, çok sayıda küçük dosya bulunan ham veriler üzerinde sınırlı denetime sahip olur. Genel olarak, sisteminizin küçük dosyaları aşağı akış uygulamaları tarafından kullanmak üzere daha büyük dosyalar olarak toplamak için bir tür işleme sahip olması önerilir. Verileri gerçek zamanlı olarak işıyorsanız, verilerinizi daha büyük dosyalar olarak depolamak için bir ileti aracısı (Event Hub veya Apache Kafkagibi) ile birlikte gerçek zamanlı bir akış altyapısı (Azure Stream Analytics veya Spark Streaminggibi) kullanabilirsiniz. Küçük dosyaları daha büyük dosyalar haline getirirken, bunları aşağı akış işleme için Apache Parquet gibi okuma için iyileştirilmiş bir biçimde kaydetmeyi göz önünde bulundurabilirsiniz.

Dizin yapısı

Her iş yükü, verilerin nasıl tüketildiğini gösteren farklı gereksinimlere sahiptir, ancak bunlar Nesnelerin İnterneti (IoT), Batch senaryolarıyla çalışırken veya zaman serisi verilerine en iyi duruma getirirken göz önünde bulundurmanız gereken bazı yaygın düzenlerdir.

IoT yapısı

IoT iş yüklerinde, çok sayıda ürüne, cihaza, kuruluşa ve müşterilere yayılmakta olan verilerin büyük bir bölümü olabilir. Sağ Akış tüketicilerine yönelik verilerin kuruluş, güvenlik ve verimli işlenmesi için Dizin düzeninin önceden planlanmak önemlidir. Göz önünde bulundurmanız gereken genel bir şablon aşağıdaki düzen olabilir:

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

Örneğin, UK içindeki bir uçak altyapısının giriş telemetrisi aşağıdaki yapıya benzeyebilir:

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

Bu örnekte, tarihi dizin yapısının sonuna yerleştirerek, belirli kullanıcı ve grupların bölgelerini ve konusunu daha kolay güvenli hale getirmek için ACL 'Leri kullanabilirsiniz. Veri yapısını başlangıca yerleştirirseniz, bu bölgelerin ve konunun güvenliğini sağlamak çok daha zordur. Örneğin, yalnızca UK verilerine veya belirli düzlemler için erişim sağlamak istiyorsanız, her saat dizininde bulunan çok sayıda dizin için ayrı bir izin uygulamanız gerekir. Bu yapı aynı zamanda, tarihinde zaman içinde geçen dizin sayısını da üstel olarak artırır.

Toplu iş işleri yapısı

Toplu işlemede yaygın olarak kullanılan bir yaklaşım, verilerin bir "ın" dizinine yerleştirmeidir. Ardından, veriler işlendikten sonra, yeni verileri, aşağı akış işlemlerinin kullanacağı bir "Out" dizinine yerleştirin. Bu dizin yapısı bazen tek tek dosyalarda işleme gerektiren işler için kullanılır ve büyük veri kümeleri üzerinde yüksek düzeyde paralel işleme gerektirmeyebilir. Yukarıda önerilen IoT yapısı gibi, iyi bir dizin yapısı, bölge ve konu açısından önemli (örneğin, kuruluş, ürün veya üretici) gibi şeyler için üst düzey dizinlere sahiptir. İşleme göre daha iyi kuruluş, filtrelenmiş aramalar, güvenlik ve Otomasyon sağlamak için yapıdaki tarih ve saati göz önünde bulundurun. Tarih yapısına yönelik ayrıntı düzeyi, verilerin karşıya yüklendiği veya işlendiği aralığa göre belirlenir; Örneğin, saatlik, günlük, hatta aylık.

Bazen veri bozulması veya beklenmeyen biçimler nedeniyle dosya işleme başarısız olur. Bu gibi durumlarda, bir dizin yapısı, dosyaları daha fazla inceleme için uygulamasına taşımak için /Bad klasöründen yarar sağlayabilir. 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}/{SubjectMatter(s)}/In/{yyyy}/{mm}/{dd}/{hh}/*\ *{Region}/{SubjectMatter(s)}/Out/{yyyy}/{mm}/{dd}/{hh}/*\ *{Region}/{SubjectMatter(s)}/Bad/{yyyy}/{mm}/{dd}/{hh}/*

Ö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/Extracts/ACMEPaperCo/In/2017/08/14/updates_08142017.csv*\ *NA/Extracts/ACMEPaperCo/Out/2017/08/14/processed_updates_08142017.csv*

toplu iş verilerinin hive veya geleneksel SQL veritabanları gibi veritabanlarına doğrudan işlenmekte olan genel durumda, çıkış zaten hive tablosu veya dış veritabanı için ayrı bir klasöre gittiğinden, /ın veya /out dizinine gerek yoktur. Örneğin, müşterilerden günlük ayıklar, ilgili dizinleriyle birlikte olacaktır. Daha sonra, Azure Data Factory, Apache Oozieveya Apache Airflow gibi bir hizmet, günlük bir Hive veya Spark işini, verileri bir Hive tablosuna işlemek ve yazmak üzere tetikler.

Zaman serisi veri yapısı

Hive iş yükleri için, zaman serisi verilerinin bölümlenmesi bazı sorguların verilerin yalnızca bir alt kümesini okumasına yardımcı olabilir ve bu da performansı geliştirir.

Zaman serisi verileri alan işlem hatları, genellikle dosyalarını dosya ve klasörler için yapılandırılmış bir adlandırma ile yerleştirir. Şu tarihe göre yapılandırılmış veriler için görtiğimiz yaygın bir örnek aşağıda verilmiştir:

\DataSet\YYYY\MM\DD\ datafile_YYYY_MM_DD. tsv

Tarih saat bilgilerinin hem klasör hem de dosya adında göründüğünü unutmayın.

Tarih ve saat için aşağıdaki genel bir örüntü

\DataSet\YYYY\MM\DD\HH\mm\ datafile_YYYY_MM_DD_HH_mm. tsv

Yine, klasör ve dosya kuruluşunda yaptığınız seçim, daha büyük dosya boyutları ve her klasörde makul sayıda dosya için iyileştirmelidir.

Güvenliği ayarla

BLOB depolama Için güvenlik önerileri makalesindeki önerileri inceleyerek başlayın. verilerinizi yanlışlıkla veya kötü amaçlı silmenin yanı sıra bir güvenlik duvarının arkasındaki verileri güvenli hale getirme ve kimlik yönetiminin temeli olarak Azure Active Directory (Azure AD) kullanma hakkında en iyi yöntem kılavuzunu bulacaksınız.

daha sonra, Data Lake Storage 2. etkin hesaplara özgü rehberlik için Azure Data Lake Storage 2. makalesindeki erişim denetim modelini gözden geçirin. Bu makale, hiyerarşik dosya sisteminizdeki dizinler ve dosyalar üzerinde güvenlik izinleri zorlamak için Azure rol tabanlı erişim denetimi (Azure RBAC) rollerini erişim denetim listeleriyle (ACL 'Ler) birlikte nasıl kullanacağınızı anlamanıza yardımcı olur.

Alma, işleme ve çözümleme

birçok farklı veri kaynağı ve verilerin Data Lake Storage 2. etkin bir hesaba alındığı farklı yolları vardır.

Örneğin, HDInsight ve Hadoop kümelerinden büyük veri kümelerini veya prototip oluşturma uygulamaları için daha küçük geçici veri kümelerini içe aktarabilirsiniz. Uygulamalar, cihazlar ve sensörler gibi çeşitli kaynaklar tarafından oluşturulan akış verilerini elde edebilirsiniz. Bu tür veriler için, araçları kullanarak verileri gerçek zamanlı olarak olay temelinde yakalayıp işleyebilir ve sonra olayları toplu olarak hesabınıza yazabilirsiniz. Ayrıca, sayfa isteklerinin geçmişi gibi bilgileri içeren Web sunucusunu alabilirsiniz. Günlük verileri için, karşıya yüklemek üzere özel komut dosyaları veya uygulamalar yazmayı düşünün. böylece, büyük veri uygulamanızın bir parçası olarak karşıya veri yükleme bileşeninizi ekleme esnekliği elde edersiniz.

hesapta veriler kullanılabildiğinde, bu verilerde analiz çalıştırabilir, görselleştirmeler oluşturabilir ve hatta verileri yerel makinenize veya Azure SQL veritabanı ya da SQL Server örneği gibi diğer depolara indirebilirsiniz.

Aşağıdaki tabloda, verileri almak, çözümlemek, görselleştirmek ve indirmek için kullanabileceğiniz araçlar önerilmektedir. Her aracın nasıl yapılandırılacağı ve kullanılacağı hakkında rehberlik bulmak için bu tablodaki bağlantıları kullanın.

Telemetri izleme

Kullanımı ve performansı izlemek, hizmetinizi kullanmanın önemli bir parçasıdır. Sık kullanılan işlemler, yüksek gecikme süresine sahip işlemler veya hizmet tarafı azaltmasına neden olan işlemler verilebilir.

depolama hesabınıza yönelik tüm telemetri azure izleyici 'de azure Depolama günlükleriaracılığıyla kullanılabilir. Bu özellik, depolama hesabınızı Log Analytics ve Event Hubs bütünleştirir, ayrıca günlükleri başka bir depolama hesabında arşivlemenize imkan tanır. ölçüm ve kaynak günlüklerinin ve bunlarla ilişkili şemanın tam listesini görmek için bkz. Azure Depolama izleme veri başvurusu.

Günlüklerinizi depolamayı tercih ettiğiniz yer, bunlara erişmeyi nasıl planladığınıza bağlıdır. Örneğin, günlüklerinize neredeyse gerçek zamanlı olarak erişmek ve günlüklerdeki olayları Azure Izleyici 'deki diğer ölçümlerle ilişkilendirmek istiyorsanız günlüklerinizi bir Log Analytics çalışma alanında saklayabilirsiniz. Bu, çalışma alanınızdaki tabloyu gösteren KQL ve yazar sorgularını kullanarak günlüklerinizi sorgulamanızı sağlar StorageBlobLogs .

Günlüklerinizi hem neredeyse gerçek zamanlı sorgu hem de uzun süreli saklama için depolamak istiyorsanız, tanılama ayarlarınızı, günlükleri hem Log Analytics çalışma alanına hem de depolama hesabına gönderecek şekilde yapılandırabilirsiniz.

Günlükleriniz ile splunk gibi başka bir sorgu altyapısı arasında erişmek istiyorsanız, tanılama ayarlarınızı bir olay hub 'ına Günlükler gönderecek şekilde yapılandırabilir ve Olay Hub 'ından seçtiğiniz hedefe alma günlüklerini alabilirsiniz.

azure izleyici 'de azure Depolama günlükleri Azure portal, PowerShell, Azure clı ve Azure Resource Manager şablonları aracılığıyla etkinleştirilebilir. Azure Ilkesi, büyük ölçekli dağıtımlar için düzeltme görevleri için tam destek ile kullanılabilir. daha fazla bilgi için bkz. Azure/Community-Policy ve ciphertxt/azurestoraygepolicy.

Ayrıca bkz.

• Azure Data Lake Storage 2. 'de erişim denetimi modeli
• Data Lake için itchhiker Kılavuzu
• Azure Data Lake Storage 2. genel bakış