Azure Databricks'te tabloları bölümleme zamanları

Not

Databricks, tüm yeni Delta tabloları için sıvı kümeleme kullanılmasını önerir. Bkz. Delta tabloları için sıvı kümeleme kullanma.

Sıvı kümeleri bazen "sıvı bölümleri" olarak da adlandırılır. Bu makale yalnızca eski Delta bölümlemesi anlamına gelir ve sıvı kümelemesi anlamına gelir.

Bu makalede, Azure Databricks'te tabloları nasıl bölümleyebileceğinize ilişkin genel bir bakış ve Delta Lake tarafından desteklenen tablolar için bölümleme kullanmanız gereken zamanlarla ilgili belirli öneriler sağlanmaktadır. Yerleşik özellikler ve iyileştirmeler nedeniyle, 1 TB'tan az veri içeren tabloların çoğu bölüm gerektirmez.

Azure Databricks varsayılan olarak tüm tablolar için Delta Lake kullanır. Aşağıdaki önerilerde tüm tablolar için Delta Lake ile çalıştığınız varsayılır.

Databricks Runtime 11.3 LTS ve üzerinde Azure Databricks, bölümlenmemiş tablolardaki verileri alma süresine göre otomatik olarak kümeler. Bkz . Alma süresi kümelemesi kullanma.

Küçük tabloların bölümlenmiş olması gerekiyor mu?

Databricks, terabayttan az veri içeren tabloları bölümlememenizi önerir.

Tablodaki her bölüm için minimum boyut nedir?

Databricks, tüm bölümlerin en az bir gigabayt veri içermesini önerir. Daha az, daha büyük bölümleri olan tablolar, çok daha küçük bölümleri olan tablolardan daha iyi performans gösterir.

Alma zamanı kümelemesi kullanma

Delta Lake ve Databricks Runtime 11.3 LTS veya üzerini kullanarak bölümlenmemiş tablolar, alma zamanı kümelemesinden otomatik olarak yararlanmış olursunuz. Veri alımı süresi, verilerinizi iyileştirmeye veya ayarlamaya gerek kalmadan tarih saat alanlarına göre bölümleme stratejilerine benzer sorgu avantajları sağlar.

Not

Bir tablodaki veya MERGE deyimlerini kullanarak UPDATE çok sayıda değişiklik yaptığınızda alma süresi kümelemesini korumak için Databricks, alma sırasıyla eşleşen bir sütun kullanarak ile ZORDER BY çalıştırmayı OPTIMIZE önerir. Örneğin, bu bir olay zaman damgası veya oluşturma tarihi içeren bir sütun olabilir.

Delta Lake ve Parquet bölümleme stratejilerini paylaşıyor mu?

Delta Lake, verileri depolamak için birincil biçim olarak Parquet kullanır ve bölümleri belirtilen bazı Delta tabloları, Apache Spark ile depolanan Parquet tablolarına benzer bir düzenleme gösterir. Apache Spark, verileri Parquet biçiminde kaydederken Hive stili bölümleme kullanır. Hive stili bölümleme Delta Lake protokolünün bir parçası değildir ve iş yükleri Delta tablolarıyla etkileşime geçmek için bu bölümleme stratejisini kullanmamalıdır.

Birçok Delta Lake özelliği, Parquet, Hive veya daha önceki Delta Lake protokolü sürümlerinden aktarılmış olabilecek veri düzeniyle ilgili varsayımları bozar. Delta Lake'te depolanan verilerle resmi olarak desteklenen istemcileri ve API'leri kullanarak her zaman etkileşim kurmalısınız.

Delta Lake bölümlerinin diğer veri göllerindeki bölümlerden farkı nedir?

Azure Databricks ve Delta Lake Apache Spark, Parquet, Hive ve Hadoop gibi açık kaynak teknolojileri temel alırken, bu teknolojilerde yararlı olan bölümleme motivasyonları ve stratejileri Azure Databricks için genel olarak geçerli değildir. Tablonuzu bölümlemeyi seçerseniz, bir strateji seçmeden önce aşağıdaki olguları göz önünde bulundurun:

• İşlemler bölüm sınırlarıyla tanımlanmaz. Delta Lake, işlem günlükleri aracılığıyla ACID sağlar, bu nedenle atomik bulma sağlamak için bir veri toplu işlemini bölüme ayırmanız gerekmez.
• Azure Databricks işlem kümelerinde fiziksel medyaya bağlı veri yerelliği yoktur. Lakehouse'a alınan veriler bulut nesne depolama alanında depolanır. Veri işleme sırasında veriler yerel disk depolamada önbelleğe alınırken, Azure Databricks paralel yükleme için en az miktarda veriyi belirlemek için dosya tabanlı istatistikleri kullanır.

Z sırası ve bölümler birlikte nasıl çalışır?

Büyük veri kümelerindeki sorguları hızlandırmak için bölümlerin yanı sıra Z sırası dizinlerini de kullanabilirsiniz.

Not

Çoğu tablo, Z sırası ve bölüm ayarlama konusunda endişelenmeye gerek kalmaması için alım süresi kümelemesinden yararlanabilir.

Bölüm sınırlarına ve Z sırasına göre bir sorgu iyileştirme stratejisi planlarken aşağıdaki kuralları göz önünde bulundurmak önemlidir:

• Z sırası komutuyla OPTIMIZE birlikte çalışır. Dosyaları bölüm sınırları arasında birleştiremezsiniz ve bu nedenle Z sırası kümelemesi yalnızca bir bölüm içinde gerçekleşebilir. Bölümlenmemiş tablolar için dosyalar tablonun tamamında birleştirilebilir.
• Bölümleme yalnızca düşük veya bilinen kardinalite alanları (örneğin, tarih alanları veya fiziksel konumlar) için iyi çalışır, ancak zaman damgaları gibi yüksek kardinaliteye sahip alanlar için çalışmaz. Z düzeni, yüksek kardinalite alanları ve sonsuz olarak büyüyebilecek alanlar (örneğin, zaman damgaları veya bir işlemler veya siparişler tablosundaki müşteri kimliği) dahil olmak üzere tüm alanlar için çalışır.
• Bölümleme için kullanılan alanlarda Z düzeni yapamazsınız.

Bölümler bu kadar kötüyse, neden bazı Azure Databricks özellikleri bunları kullanıyor?

Bölümler, özellikle çok büyük tablolar için yararlı olabilir. Bölümlemeyle ilgili birçok performans geliştirmesi, çok büyük tablolara (yüzlerce terabayt veya üzeri) odaklanır.

Birçok müşteri Parquet tabanlı veri göllerinden Delta Lake'e geçiş yaptı. deyimi, CONVERT TO DELTA mevcut parquet tabanlı bir tabloyu, var olan verileri yeniden yazmadan Delta tablosuna dönüştürmenizi sağlar. Bu nedenle, birçok müşterinin önceki bölümleme stratejilerini devralan büyük tabloları vardır. Databricks tarafından geliştirilen bazı iyileştirmeler, mümkün olduğunda bu bölümlerden yararlanmaya çalışır ve Delta Lake için iyileştirilmemiş bölümleme stratejileri için bazı olası dezavantajları azaltır.

Delta Lake ve Apache Spark açık kaynak teknolojilerdir. Databricks bölümlemeye olan dayanıklılığı azaltan özellikler eklemeye devam etse de, açık kaynak topluluğu karmaşıklık katan yeni özellikler oluşturmaya devam edebilir.

Özel bölümleme ile Azure Databricks yerleşik iyileştirmelerinden daha iyi performansa sahip olmak mümkün mü?

Apache Spark ve Delta Lake'in bazı deneyimli kullanıcıları, alma zamanı kümelemesinden daha iyi performans sağlayan bir desen tasarlayabilir ve uygulayabilir. Hatalı bölümleme durum bilgisi uygulama, aşağı akış performansında çok olumsuz yansımalara neden olabilir ve düzeltme için verilerin tam yeniden yazılmasını gerektirebilir. Databricks, kullanıcıların çoğunun pahalı verimsizlikleri önlemek için varsayılan ayarları kullanmasını önerir.