Modern bir veri ambarı için dosya biçimlerini ve yapısını anlama
Verileri veri ambarınıza yüklediğinizde, verileri almak için dosya türleri ve yöntemleri kaynağa göre değişir. Örneğin, şirket içi dosya sistemlerinden, ilişkisel veri depolarından veya akış veri kaynaklarından veri yüklemek için veri gölüne veya ara veri deposuna veri alımından rafine edilmiş verilerin sunum katmanına alınmasına kadar farklı yaklaşımlar gerekir. Farklı dosya türlerini ve analiz sorguları için ham depolama ve geliştirilmiş sürümler için hangilerinin kullanılacağını anlamak önemlidir. Tasarımda dikkat edilmesi gereken diğer noktalar arasında sorguları ve veri yükleme etkinliklerini iyileştirmeye yönelik hiyerarşik yapılar yer alır. Bu ünitede dosya türleri ve bunların en iyi kullanım örnekleri ve bunları veri gölünüzde en iyi şekilde nasıl düzenleyeceğiniz açıklanmaktadır.
Toplu olarak ham verileri almak için desteklenen dosya biçimleri
Veri mühendisliğinde veri yükleme hızını üç gecikme süresinden biri olarak tanımlama eğilimindeyiz:
- Batch: Tamamlanması on dakika, saat veya gün sürebilen sorgular veya programlar. Etkinlikler arasında ilk veri düzenleme, tam ETL işlem hattı veya aşağı akış analizi hazırlığı yer alabilir.
- Etkileşimli sorgu: Toplu iş verilerinin "insan" etkileşimli hızlarda sorgulanması, mevcut teknoloji nesliyle sonuçların saniyelerle dakika cinsinden ölçülen zaman çerçevelerinde hazır olduğu anlamına gelir.
- Gerçek zamanlı / neredeyse gerçek zamanlı: Sonuçlara kadar geçen süre kısa olan tipik sonsuz bir giriş verisi akışının (akış) işlenmesi(en uzun durumlarda milisaniye veya saniye cinsinden ölçülür).
Ham verileri yeni veri kaynaklarından toplu olarak alma söz konusu olduğunda, bu veri biçimleri Synapse tarafından yerel olarak desteklenir:
- CSV
- Parquet
- ORC
- JSON
Ancak Synapse Notebooks ile Apache Spark kullanıyorsanız ham verileriniz için daha fazla dosya türünü inceleyebilir ve işleyebilirsiniz.
Akış verilerini Synapse ayrılmış SQL havuzlarına alma
Üçüncü gecikme süresine ulaşan verileri işleme (gerçek zamanlı/neredeyse gerçek zamanlı) akış verisi işleme olarak da adlandırılır. Akış veri kaynakları ioT cihazları ve algılayıcıları, finansal işlemleri, web tıklama akışı verilerini, fabrikaları ve tıbbi cihazları içerebilir.
Azure, Azure IoT Hub ve Azure Event Hubs (Kafka desteğiyle veya desteği olmadan) gibi sağlam, kanıtlanmış ve performanslı amaca yönelik akış alımı hizmetleri sunar. Veri işlem hattınızda, bu veya benzer hizmetlerden ileti toplamanız ve bunları Azure Stream Analytics, Azure İşlevleri, Azure Databricks veya akış verilerini alıp işlemenizi sağlayan diğer hizmetleri kullanarak işlemeniz gerekir.
Amacınız bu verileri Synapse Analytics çalışma alanınızla ilişkili Azure Data Lake Depolama (ADLS) 2. Nesil hesabı gibi veri gölünüze getirmek, ardından verileri keşfetmek ve dönüştürmek için sunucusuz sql havuzuyla Synapse Spark not defterlerini veya T-SQL sorgularını kullanmak olabilir. Bu durumda, büyük olasılıkla bu verileri CSV veya JSON gibi ham biçimlerden birinde kaydedersiniz. Azure Stream Analytics, IoT Hub'a veya Event Hubs'a giriş kaynağı olarak bağlanarak ve dosyaları ADLS 2. Nesil depolama hesabına çıkış olarak çıkararak bu görevi basitleştirir. Yol tabanlı veri ayıklama yoluyla verilerinizi en uygun analitik iş yükleri için yapılandırmanıza yardımcı olacak bir yol deseni belirtebilirsiniz. Örneğin, ADLS 2. Nesil çıkışında aşağıdaki yol desenini ayarlayabilirsiniz: tran/sensor/{datetime:yyyy}/{datetime:MM}/{datetime:dd}. Diğer seçenekler JSON gibi serileştirmeyi, UTF-8 gibi kodlamayı, dosya başına en az 100 gibi satır sayısını ayarlamanızı sağlar.
Ancak, akış verilerini ayrılmış bir SQL havuzuna yerleştirmek istiyorsanız, kullanabileceğiniz birkaç seçenek, yukarıda açıklandığı gibi verileri ilk olarak işlemek ve veri gölünüzde depolamaktır. Ardından Synapse Pipelines, Synapse Spark havuzları veya COPY deyimleri gibi çeşitli veri yükleme tekniklerinden biriyle verileri ayrılmış bir SQL havuzuna yükleyin. Bu, data lake'i hazırlama alanı olarak kullanmanıza veya ayrılmış SQL havuzundaki verilerin daha iyileştirilmiş bir sürümüne ek olarak veri gölünde ham biçimi korumanıza olanak tanır.
Bir diğer seçenek de Azure Stream Analytics işleriyle yüksek aktarım hızına sahip veri alımı için çıkış havuzu olarak Azure Synapse Analytics (ayrılmış SQL havuzu) ile Azure Stream Analytics'i kullanmaktır.
Synapse Analytics çıkışını oluşturduktan sonra Stream Analytics sorgusunda hedef olarak ayarlayabilirsiniz. Aşağıdaki örnekte adlı bir Event Hubs girişi ve adlı CallStreamsqlpool-demo-asaoutputbir Synapse Analytics çıkışımız vardır. SQL sorgusu yalnızca tüm gelen verileri doğrudan ayrılmış SQL havuzuna yazar. Alternatif olarak, yalnızca belirli özellikleri seçip gelen akıştan veri türlerini dönüştürebilir ve verileri ayrılmış SQL havuzuna yazmadan önce toplamak için pencereleme işlevlerinden birini kullanabilirsiniz.
Synapse Analytics ile Stream Analytics'i bu şekilde kullanmak, Stream Analytics sorgusunun akış verilerini yazacağı ayrılmış SQL havuzu veritabanınızı ve tablonuzu seçmenize olanak tanır. Bu yerel akış alımı, verileri önce başka bir yere getirmek zorunda kalmadan verileri doğrudan ayrılmış SQL havuzuna hızlı bir şekilde yazacak şekilde iyileştirilmiştir.
Önerilen dosya türleri
Ham veri
Ham veriler için verilerin yerel biçiminde depolanması önerilir. İlişkisel veritabanlarındaki veriler genellikle CSV biçiminde depolanmalıdır. Bu, çoğu sistem tarafından desteklenen biçimdir, bu nedenle en büyük esnekliği sağlar.
Web API'lerinden ve NoSQL veritabanlarından gelen veriler için JSON önerilen biçimdir.
Veriler için geliştirilmiş sürümler
Olası sorgulama için verilerin geliştirilmiş sürümlerini depolama söz konusu olduğunda, önerilen veri biçimi Parquet'dir.
Depolama katmanında (örneğin, Hadoop, Databricks ve SQL altyapısı senaryolarında) veri paylaşmak için Parquet biçimi etrafında sektör hizalaması vardır. Parquet, büyük veri senaryoları için iyileştirilmiş yüksek performanslı, sütun odaklı bir biçimdir.
Parquet gibi sütunlu biçimlerin depolama ve performans avantajları vardır. Değerler sütuna göre kümelenir, böylece sıkıştırma daha verimli olur (depolama alanı ayak izini küçültmek için) ve sorgu altyapısı sütun projeksiyonlarını aşağı itebilir (istenmeyen sütunları atlayarak ağ ve diskten okuma G/Ç'sini azaltmak için), aksi halde sütun ayıklama olarak da bilinir. Benzer veri türleri (sütun için) Parquet dosyalarında birlikte depolanır ve verimli veri sıkıştırma ve kodlama düzenlerine yol açar.
Parquet, dosya şemasını dosya meta verilerinde depolar. CSV dosyaları dosya meta verilerini depolamaz, bu nedenle okuyucuların şemayla birlikte sağlanması veya şemanın çıkarılması gerekir. Şema sağlamak yorucudur ve şemanın çıkarılması hataya açık /pahalıdır.
Analitik sorgular için dosya yapısını düzenleme
Veri gölüne veri alırken göz önünde bulundurmanız gereken ilk şey, verileri veri gölü içinde nasıl yapılandırabileceğiniz veya düzenleyeceğinizdir. Azure Data Lake Depolama (ADLS) 2. Nesil'i (Azure portalında, hiyerarşik ad alanı etkinleştirilmiş bir Azure Depolama hesabıdır) kullanmalısınız.
ADLS 2. Nesil'in, hiyerarşik ad alanına ek olarak nesne depolama ölçeğinde dosya sistemi performansı ve fiyatları sağlamasını sağlayan önemli bir mekanizma. Bu, bir hesaptaki nesne/dosya koleksiyonunun, bilgisayarınızdaki dosya sistemiyle aynı şekilde dizinler ve iç içe alt dizinler hiyerarşisi halinde düzenlenmesini sağlar. Hiyerarşik ad alanı etkinleştirildiğinde, depolama hesabı analiz altyapılarına ve çerçevelerine aşina olan dosya sistemi semantiğiyle nesne depolamanın ölçeklenebilirliğini ve uygun maliyetliliğini sağlar.
ADLS 2. Nesil'de, üretim için ayrılmış bir Depolama Hesabına ve geliştirme ve test iş yükleri için ayrı bir Depolama Hesabına sahip olmak en iyi uygulamadır. Bu, geliştirme veya test iş yüklerinin üretimle hiçbir zaman karışmamasını sağlar.
Veri gölü içindeki klasörleri yapılandırmanın yaygın yöntemlerinden biri, verileri iyileştirme derecesine göre ayrı klasörlerde düzenlemektir. Örneğin, bronz bir klasör ham veri içerebilir, gümüş temizlenmiş, hazırlanmış ve tümleşik verileri içerir ve altın, önceden hesaplanan toplamalar gibi son iyileştirmeleri de içerebilen analizi desteklemeye hazır veriler içerir. Daha fazla iyileştirme düzeyi gerekiyorsa, bu yapı gerektiğinde daha fazla klasör içerecek şekilde değiştirilebilir.
Data Lake Storage 2. Nesil ile çalışırken aşağıdakiler dikkate alınmalıdır:
- Veriler Data Lake Storage 2. Nesil depolandığında dosya boyutu, dosya sayısı ve klasör yapısı performansı etkiler.
- Verilerinizi çok sayıda küçük dosya olarak depolarsanız, bu durum performansı olumsuz etkileyebilir. Genel olarak, daha iyi performans için verilerinizi daha büyük boyutlu dosyalar halinde düzenleyin (boyutu 256 MB ile 100 GB arası).
- Bazı altyapılar ve uygulamalar, boyutu 100 GB'tan büyük dosyaları verimli bir şekilde işlerken sorun yaşayabilir.
- Bazen veri işlem hatlarının ham veriler üzerinde denetimi sınırlıdır ve bu da çok sayıda küçük dosyaya sahiptir. Aşağı akış uygulamaları için kullanılacak daha büyük dosyalar oluşturan bir "pişirme" işlemine sahip olmanız önerilir.