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

Not

Yönetilen Apache Iceberg tablolarında Unity Kataloğu yalnızca sıvı kümelemeyi destekler ve yan tümcesinde PARTITION BY belirtilen bölümleri sıvı kümeleme için kümeleme anahtarları olarak yorumlar.

Databricks, tüm yeni Delta tabloları ve yönetilen Iceberg tabloları için sıvı kümelemeyi önerir. Bkz. Delta Lake ve Apache Iceberg için Azure Databricks'te Unity Kataloğu tarafından yönetilen tablolar ve tablolar için sıvı kümeleme kullanımı.

Sıvı kümeleri bazen "sıvı bölümleri" olarak da adlandırılır. Bu makale yalnızca eski Delta bölümleme konusuna değinmekte olup sıvı kümelemesini kapsamamaktadır.

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.

Veri alma süresi kümelenmesi kullanma

Delta Lake ve Databricks Runtime 11.3 LTS veya üzerini kullanarak oluşturduğunuz bölümlenmemiş tablolar, alma zamanı kümelemesi'den 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

Databricks, bir tabloda UPDATE veya MERGE deyimlerini kullanarak çok sayıda değişiklik yaparken alım zamanına göre kümelemeyi korumak için, olay zaman damgası veya oluşturulma tarihi gibi veri giriş sırasına uygun bir sütunda "liquid clustering" kullanılmasını önerir. Bkz Tablolar için sıvı kümeleme kullanma.

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.

Not

Delta tablosu için sütun eşlemeyi etkinleştirdiğinizde, Hive stili bölümleme için bölüm dizinlerindeki sütun adlarının yerini rastgele ön ekler alır. Delta Lake sütun eşlemesiile sütunlarını yeniden adlandırma ve bırakma işlemlerine bakın.

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 biriminde saklanı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?

Not

Databricks, tüm yeni tablolar için Z sırasına göre sıvı kümelemesi önerir. Bkz Tablolar için sıvı kümeleme kullanma.

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 gereksinimini ortadan kaldırmak için veri alma zamanı kümeleme avantajını kullanabilir.

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ı OPTIMIZE komutuyla 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ı. CONVERT TO DELTA deyimi, var olan bir Parquet tabanlı tabloyu, mevcut verileri yeniden yazmadan Delta tablosuna dönüştürmenize olanak tanır. 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 stratejisi uygulamak, ardıl performans üzerinde çok olumsuz etkilere neden olabilir ve düzeltmek için verilerin tamamen yeniden yazılmasını gerektirebilir. Databricks, kullanıcıların çoğunun pahalı verimsizlikleri önlemek için varsayılan ayarları kullanmasını önerir.