Doku Veri Ambarı'nda veri kümeleme

Şunlar için geçerlidir:✅ Warehouse in Microsoft Fabric

Önemli

Bu özellik önizleme aşamasındadır.

Veri kümeleme, benzerlik temelinde verileri düzenlemek ve depolamak için kullanılan bir tekniktir. Veri kümelemesi sorgu performansını artırır ve benzer kayıtları birlikte gruplandırarak sorgular için işlem ve depolama erişim maliyetlerini azaltır.

Nasıl çalışır?

Veri kümelemesi, alma sırasında benzer değerlere sahip satırları depolamadaki bitişik konumlarda depolayarak çalışır. Veri kümeleme, verileri birden çok boyutta yerelliği koruyacak şekilde düzenlemek için bir alan doldurma eğrisi kullanır; bu da kümeleme sütunları arasında benzer değerlere sahip satırların fiziksel olarak birbirine yakın şekilde depolanması anlamına gelir. Bu yaklaşım, dosya atlayarak ve taranan dosya sayısını azaltarak sorgu performansını önemli ölçüde artırır.

Geleneksel sözcük temelli sıralamanın aksine, veri kümelemesi, bir tablo birden fazla sütunla kümelenmiş olsa bile benzer sütun değerlerine sahip satırları birbirine yakın tutarak yerleştirmek için karmaşık ve gelişmiş bir algoritma kullanır. Bu, veri kümelemesini aralık sorguları, yüksek kardinalite filtreleri ve çarpık dağıtımlara sahip büyük tablolar için ideal hale getirerek daha hızlı okuma, azaltılmış G/Ç ve daha verimli kaynak kullanımı sağlar.

Veri kümeleme ilişkin basitleştirilmiş bir kavramsal çizim aşağıdadır:

Veri ambarında veri kümeleme kavramını gösteren diyagram.

Bu diyagramda etiketli Source data bir tablo, hedefteki kümeleme gruplandırmalarını temsil etmek için farklı renklerde karışık ve vurgulanmış satırları gösterir. Sıralı tablo üç dosya kesimine ayrılır ve her biri satırları benzer renklere göre gruplandırır ve kümelemenin verileri sütun değerlerine göre iyileştirilmiş depolama kesimleri halinde nasıl düzenlediğini gösterir.

Veri kümeleme meta verileri, veri alımı sırasında bildirime eklendiğinden, ambar altyapısının kullanıcı sorguları sırasında erişilmesi gereken dosyalar hakkında akıllı kararlar vermesine olanak tanır. Benzer değerlere sahip satırların birlikte depolanmasıyla birlikte bu meta veriler, filtre koşuluna sahip sorguların koşul kapsamının dışında kalan dosyaların ve satır gruplarının tamamını atlayabilmesini sağlar. Örneğin: Bir sorgu tablonun verilerinin yalnızca 10% hedefleniyorsa kümeleme yalnızca filtre aralığındaki verileri içeren dosyaların taranmasını sağlayarak G/Ç ve işlem tüketimini azaltır. Dosya atlamanın avantajları veri hacmiyle ölçeklendirildiği için daha büyük tablolar veri kümelemesinden daha fazla yararlanır.

Veri kümeleme ne zaman kullanılır?

Veri kümelemenin yararlı olup olmadığını belirlerken, ambardaki sorgu desenlerini ve tablo özelliklerini araştırın. Veri kümeleme, sorgular tekrar tekrar belirli sütunlarda filtreleme yaparken ve taban tablolar büyük olup orta ila yüksek kardinalite veriler içerdiğinde en etkilidir. Bazı yaygın senaryolar şunlardır:

  • Filtrelerle WHERE yinelenen sorgular: İş yükü belirli sütunları filtreleyen sık sık sorgular içeriyorsa, veri kümelemesi okuma sorguları sırasında yalnızca ilgili dosyaların taranmasını sağlar. Bu, filtreler panolarda, raporlarda veya zamanlanmış işlerde tekrar tekrar kullanıldığında ve SQL deyimleri olarak veritabanı motoruna gönderildiğinde de geçerlidir.
  • Daha büyük tablolar: Veri kümeleme en çok, tam veri kümesini taramanın maliyetli olduğu büyük tablolara uygulandığında etkilidir. Veri kümeleme ile satırları düzenleyerek, ambar altyapısı sorgu filtresiyle eşleşmeyen tüm dosyaları ve satır gruplarını atlayabilir ve bu da G/Ç ve işlem kullanımını azaltabilir.
  • Orta ve yüksek kardinalite sütunları: Daha yüksek kardinaliteye sahip sütunlar (örneğin, kimlik veya tarih gibi birçok farklı değere sahip sütunlar), altyapının benzer değerleri yalıtmasına ve birlikte birleştirmesine izin verdikleri için veri kümelemesinden daha fazla yararlanır. Bu, özellikle seçmeli sorgular için verimli dosya atlanması sağlar. Doğası gereği düşük kardinaliteye (örneğin cinsiyet, bölge) sahip sütunların değerleri daha fazla dosyaya yayılmıştır ve bu nedenle dosya atlama için sınırlı fırsatlar sunar.
  • Dar kapsamlı seçmeli sorgular: Sorgular genellikle verilerin küçük bir alt kümesini hedeflediğinde ve WHERE filtresiyle birleştirildiğinde, veri kümelemesi yalnızca ilgili satırları içeren dosyaların okunmasını sağlar.

Veri kümelemesi, satırların nasıl alındığını dikkate almadan veri alımı sırasında otomatik olarak gerçekleşir. Veri kümelemi uygulamak için veri alındıktan sonra kullanıcı işlemleri gerekmez.

CLUSTER BY Sözdizimi

Veri kümeleme, yan tümcesi CLUSTER BY kullanılarak tablo oluşturma sırasında tanımlanır. Söz dizimi aşağıdaki gibidir:

CREATE TABLE (Transact-SQL) söz dizimi:

CREATE TABLE { warehouse_name.schema_name.table_name | schema_name.table_name | table_name } (
 [ ,... n ] –- Column list
) WITH (CLUSTER BY [ ,... n ]);

CREATE TABLE AS SELECT (Transact-SQL) söz dizimi:

CREATE TABLE { warehouse_name.schema_name.table_name | schema_name.table_name | table_name }
( { <column_definition> } [ ,... n ] )
WITH (CLUSTER BY [ ,... n ])
AS <select_statement>;

yan tümcesi CLUSTER BY , veri kümeleme için en az bir sütun ve en fazla dört sütun gerektirir.

ile SELECT INTO veri kümelediğini kullanan bir tablo oluşturma desteklenmez.

Veri türü desteği

Aşağıdaki tabloda yan tümcesinde CLUSTER BY kullanılabilecek sütun türleri özetlenmiştir:

Kategori Veri türü Desteklenen veri kümeleme
Tam sayısal bilgiler bit Hayı
Tam sayısal bilgiler bigint, int, smallint, decimal2, numeric Yes
Yaklaşık sayısal hesaplar float, reel Yes
Tarih ve saat date, datetime2, time Yes
Karakter dizeleri1 char Yes
Karakter dizeleri1 varchar Yes
LOB türleri varchar(max), varbinary(max) Hayı
İkili karakter dizileri varbinary, uniqueidentifier Hayı

1 Dize türleri (karakter/varchar) için sütun istatistikleri oluşturulurken yalnızca ilk 32 karakter kullanılır. Sonuç olarak, uzun ön ek içeren değerlere sahip sütunların veri kümelemeyle sınırlı avantajları olabilir.

2 Hassasiyeti 18'den büyük olan ondalık türler için, koşullar sorgu yürütme sırasında depolamaya aktarılmaz. Veri kümelendirme ile ondalık türleri kullanıyorsanız, daha küçük hassasiyete sahip sütunları tercih edin.

Desteklenmeyen veri türlerine sahip sütunlar, veri kümeleme kullanan bir tabloda bulunabilir, ancak CLUSTER BY ile kullanılamaz.

Veri kümeleme ile ilgili en iyi yöntemler

Veri kümeleme, özellikle orta-yüksek kardinaliteye sahip olanlar ve sorgular sırasında aralık önkoşulları kullanıldığında gerçek sorgu desenlerine göre kümeleme sütunları seçildiğinde daha etkilidir.

Veri kümeleme kullanırken aşağıdaki en iyi yöntemleri göz önünde bulundurun:

  • Veri kümeleme, büyük tablolarda daha etkilidir.
  • Mümkün olduğunda, daha küçük görevler yerine aynı anda daha fazla sayıda satırı işlemek için toplu veri alımı ve güncellemeleri tercih edin. En iyi performans için DML işlemlerinin veri kümelemesinden yararlanabilmesi için en az 1 milyon satır olması gerekir. Ardışık eklemeler, güncelleştirmeler ve silmelerden sonra veri sıkıştırma, daha küçük dosyalardan gelen satırları en uygun boyuttaki dosyalarda birleştirebilir.
  • Veri kümelemesi için orta-yüksek kardinaliteye sahip sütunları seçin; bu sütunlar benzersiz değer dağılımı nedeniyle daha iyi sonuçlar verir. Düşük kardinaliteye sahip sütunlar, dosya ayıklama için sınırlı fırsatlar sunabilir.
  • Dashboard'larda, raporlar, zamanlanmış görevler veya kullanıcı sorgularında sıkça kullanılan WHERE koşullara göre sütunları seçin. Eşitlik birleştirme koşulları veri kümelemesinden fayda sağlamaz. Geçerli iş yükünüz temelinde veri kümeleme sütunlarını seçmenize yardımcı olmak üzere Query Insights'ı nasıl kullanabileceğinizi öğrenmek için Doku Veri Ambarı'nda Veri Kümelemeyi Kullanma Öğreticisine Bakın.
  • Veri kümelemesi için kesinlikle gerekli olandan daha fazla sütun kullanmayın. Çok sütunlu kümeleme depolamaya karmaşıklık ekler, ek yük ekler ve tüm sütunlar koşul içeren sorgularda birlikte kullanılmadığı sürece avantaj sağlamayabilir.
  • içinde CLUSTER BY kullanılan sütun sırası önemli değildir ve satırların depolanma şeklini değiştirmez.
  • Veri kümeleme için CREATE TABLE AS SELECT (CTAS) kullanarak bir tablo oluştururken veya INSERT INTO ... SELECT ile veri alırken, en iyi veri kümeleme kalitesini sağlamak için bu deyimlerin seçme bölümünü olabildiğince basit tutun.

Veri kümelemesi, sorgu önkoşullarıyla uyumluysa sorgular sırasında maliyetleri önemli ölçüde azaltabilir. Ancak veri alımı, veri kümelemesi olmadan aynı veriye sahip eşdeğer bir tabloyla karşılaştırıldığında veri kümelemesi kullanan bir tabloda daha fazla zaman ve kapasite birimine (CU) neden olur. Bunun nedeni ambar motorunun veri alımı sırasında verileri sıralaması gerekmesidir. Alınan veriler birden çok kez okunduğundan, veri kümelemesi belirli bir iş yükünün genel işlem tüketimini azaltabilir.

Sistem görünümleri

Veri kümeleme meta verileri kullanılarak sys.index_columnssorgulanabilir. Veri kümelemesinde kullanılan, CLUSTER BY ifadesindeki sütun sıra numarası dahil olmak üzere, tüm sütunları gösterir.

Aşağıdaki sorgu, geçerli ambardaki veri kümelemesinde kullanılan tüm sütunları ve bunların tablolarını listeler:

SELECT
    t.name AS table_name,
    c.name AS column_name,
    ic.data_clustering_ordinal AS clustering_ordinal
FROM sys.tables t
JOIN sys.columns c
    ON t.object_id = c.object_id
JOIN sys.index_columns ic
    ON c.object_id = ic.object_id
   AND c.column_id = ic.column_id
WHERE ic.data_clustering_ordinal > 0
ORDER BY
    t.name,
    ic.data_clustering_ordinal;

Uyarı

Tablo tanımlandığında kullanılan sütun düzeni yalnızca başvuru amacıyla görüntülenir. En iyi yöntemler bölümünde açıklandığı gibi, sütun sırası performansı etkilemez.

Sınırlamalar ve Açıklamalar

  • Tablolar yüksek oranda değişken veri boyutlarına sahip büyük varchar sütunları içerdiğinde veri alımı performansı düşebilir.
    • Örneğin , varchar(200) sütunlu bir tablo düşünün: Bazı satırlar yalnızca birkaç karakter içeriyorsa ve diğerleri maksimum uzunluğa yaklaşırsa, veri boyutundaki önemli varyans alım hızını olumsuz etkileyebilir.
    • Bu sorun bilinmektedir ve gelecek bir sürümde ele alınacaktır.
  • IDENTITY sütunları ile CLUSTER BYkullanılamaz. IDENTITY sütunu içeren tablolar, CLUSTER BY ile farklı sütunlar kullanıldığı göz önünde bulundurulduğunda veri kümeleme için yine de kullanılabilir.
  • Veri kümeleme, tablo oluşturma sırasında tanımlanmalıdır. Normal bir tabloyu CLUSTER BY ile bir tabloya dönüştürmek desteklenmez. Benzer şekilde, bir tablo oluşturulduktan sonra kümeleme sütunlarını değiştirmeye izin verilmez. Farklı kümeleme sütunları gerekiyorsa, isteğe bağlı olarak (CTAS) kullanarak CREATE TABLE AS SELECT istenen kümeleme sütunlarını içeren yeni bir tablo oluşturun.
  • Bazı durumlarda, veri kümeleme zaman uyumsuz olarak uygulanabilir. Bu gibi durumlarda, veriler bir arka plan göreviyle yeniden düzenlenir ve veri alımı tamamlandığında tablo tamamen optimize edilmeyebilir. Bu, aşağıdaki koşullar altında gerçekleşebilir:
    • INSERT INTO ... SELECT veya CREATE TABLE AS SELECT (CTAS) kullanıldığında ve kaynak ile hedef tabloların sıralamaları farklı olduğunda.
    • Sıkıştırılmış CSV biçimindeki dış verilerden alma sırasında.
    • Bir veri alımı ifadesi 1 milyondan az satıra sahip olduğunda.
  • Veri kümeleme tablolarında veri alımı, veri kümelemesi kullanmayan aynı şemaya sahip bir tabloyla karşılaştırıldığında ek yük oluşturur. Bunun nedeni, depolamayı iyileştirmek için gereken ek hesaplamalardır. Kümeleme sütununda harfe duyarsız harmanlama kullanıldığında, artan ek yük de beklenir.
  • Veri kümeleme sorgu yanıt süresi, kapasite birimi (CU) tüketimi veya her ikisi de yararlı olabilir.

Örnekler

A. Satış verileri için kümelenmiş bir tablo oluşturun

Bu örnek bir basit Sales tablo oluşturur ve veri kümeleme için CustomerID ve SaleDate sütunlarını kullanır.

CREATE TABLE Sales (
    SaleID INT,
    CustomerID INT,
    SaleDate DATE,
    Amount DECIMAL(10,2)
) WITH (CLUSTER BY (CustomerID, SaleDate))

B. CREATE TABLE AS SELECT kullanarak kümelenmiş tablo oluşturma

Bu örnek, sütunuyla var olan tablonun bir kopyasını CREATE TABLE AS SELECT oluşturmak için kullanırSales.CLUSTER BYSaleDate

CREATE TABLE Sales_CTAS 
WITH (CLUSTER BY (SaleDate)) 
AS SELECT * FROM Sales

C. Belirli bir tabloda Veri Kümeleme için kullanılan sütunları görüntüleme

Bu örnekte, tablodaki Sales veri kümeleme için kullanılan sütunlar listeleniyor.

SELECT
    c.name AS column_name,
    ic.data_clustering_ordinal AS clustering_ordinal
FROM sys.tables t
JOIN sys.columns c
    ON t.object_id = c.object_id
JOIN sys.index_columns ic
    ON c.object_id = ic.object_id
   AND c.column_id = ic.column_id
WHERE 
    ic.data_clustering_ordinal > 0
   AND t.name = 'Sales'
ORDER BY
    t.name,
    ic.data_clustering_ordinal;

Sonuçlar:

Kümeleme sütunlarını ve bunların sıralı konumlarını gösteren tablo. İlk satırda kümeleme sıralı CustomerID 1 listelenir. İkinci satırda, kümeleme sıralı 2 ile SaleDate listelenir.

D. Veri kümeleme için sütun seçimlerinin etkinliğini denetleme

Sorgu İçgörüleri, belirli bir sorgu ile özgün tablonun kümelenmiş bir kopyasında eşdeğer çalıştırması arasında taranan CPU süresini ve verileri karşılaştırarak veri kümelemenin iş yükünüz üzerindeki etkisini değerlendirmenize yardımcı olabilir. Aşağıdaki örnekte, ayrılmış CPU süresinin ve belirli bir sorgu için disk, bellek ve uzak depolama alanı genelinde taranan verilerin hacminin nasıl alınıyor olduğu gösterilmektedir.

SELECT 
    allocated_cpu_time_ms, 
    data_scanned_disk_mb, 
    data_scanned_memory_mb, 
    data_scanned_remote_storage_mb
FROM 
    queryinsights.exec_requests_history 
WHERE 
     distributed_statement_id = '<Query_Statement_ID>'

Burada <Query_Statement_ID> , değerlendirmek istediğiniz sorgunun dağıtılmış deyim kimliğidir.

Sonraki adım