MaxCompute:LogView Tanılama Örnekleri

Çalıştırılamayan bir işi tanılama

Bir iş başarısız olduğunda, LogView'daki result sekmesinde hata bilgilerini görüntüleyebilirsiniz. Başarısız olan bir iş için LogView varsayılan olarak result sekmesini açar.

Yavaş çalışan bir işi tanılama

Derleme aşaması

• Zamanlama

  Sorun açıklaması: İşin alt durumu Waiting for cluster resource şeklindedir. İş derlenmeyi beklemektedir.

  Neden: Hesaplama kümesinin kaynakları yetersizdir.

  Çözüm: Hesaplama kümesinin durumunu ve gereken kaynakları kontrol edin. Abonelik tabanlı bir küme kullanıyorsanız, kaynakları ölçeklendirebilirsiniz.

• Optimizasyon

  Sorun açıklaması: İşin alt durumu SQLTask is optimizing query şeklindedir. İyileştirici, yürütme planını optimize etmektedir.

  Neden: Yürütme planı karmaşıktır. İyileştiricinin yürütme planını optimize etmesi uzun zaman alır.

  Çözüm: İyileştiricinin optimizasyonu tamamlamasını bekleyin. Bu işlem çoğu durumda 10 dakikadan az sürer.

• Yürütme planı oluşturma

  Sorun açıklaması: İşin alt durumu SQLTask is generating execution plan şeklindedir.

  Neden 1: Aşırı sayıda bölümden veri okunmaktadır.

  Çözüm: Bölüm sayısını azaltmak için SQL deyimlerini optimize edin. Örneğin, bölüm budama yapabilir, veri okunması gerekmeyen bölümleri filtreleyebilir ve büyük işleri küçük işlere bölebilirsiniz. SQL deyimlerinde bölüm budamanın etkili olup olmadığını belirleme ve bölüm budamanın başarısız olduğu yaygın senaryolar hakkında daha fazla bilgi için bkz. Bölüm budamanın etkili olup olmadığını kontrol etme.

  Neden 2: Aşırı sayıda küçük dosya oluşturulur. Aşağıdaki senaryolarda küçük dosyalar oluşturulur:

  1. Tunnel komutları kullanılarak veri yüklenirken hatalı bir işlem yapılır. Örneğin, her bir veri kaydı yüklendiğinde yeni bir upload session oluşturulur. Daha fazla bilgi için bkz. Tunnel komutları hakkındaki SSS.

  2. Bölümlenmiş bir tabloda insert into işlemini çalıştırdığınızda, partition dizininde yeni bir dosya oluşturulur.

  Çözümler

  1. Aşırı sayıda küçük dosya oluşturulmasını önlemek için verileri daha verimli bir şekilde yüklemek amacıyla TunnelBufferedWriter arayüzünü kullanın.

  2. Küçük dosyaları manuel olarak birleştirin. Daha fazla bilgi için bkz. Küçük dosyaları birleştirme.

  Not

  Küçük dosya sayısı 10.000'den fazlaysa, küçük dosyaların otomatik birleştirilmesini etkinleştirebilirsiniz. Sistem her gün küçük dosyaları otomatik olarak birleştirir. Ancak, sistem özel senaryolarda küçük dosyaları birleştiremezse küçük dosyaları manuel olarak birleştirmeniz gerekir.

• Kümeler arası veri çoğaltma

  Belirti: Alt durum listesinde birden fazla Task rerun örneği gösterilir ve Result sekmesinde FAILED: ODPS-0110141:Data version exception hata iletisi görüntülenir. İş başarısız olmuş gibi görünebilir ancak aslında hala çalışıyor olabilir; bu durum, kümeler arası veri çoğaltıldığını gösterir.

  Neden 1: Proje için kümeler arasında veri geçişi yapılır. Bu durumda, geçiş tamamlandıktan sonraki ilk bir veya iki gün içinde kümeler arası veri çoğaltan çok sayıda iş çalışır.

  Çözüm: Kümeler arası veri çoğaltmanın beklendiği gibi tamamlanmasını bekleyin.

  Neden 2: Proje için kümeler arasında veri geçişi yapılır. Ancak, bölümler beklendiği gibi filtrelenmez. Sonuç olarak, belirli bölümlerden eski veriler okunur.

  Çözüm: Eski verileri içeren bölümleri filtreleyin.

Yürütme aşaması

LogView'daki job details sayfası eksik bir yürütme planı gösterir ve iş durumu hala Running durumundadır. Yürütme aşamasında, bir iş kaynak bekleme, veri eğriliği, verimsiz UDF çalıştırma veya veri şişmesi nedeniyle takılabilir veya beklenenden daha uzun sürebilir. Aşağıdaki bölümlerde her bir senaryo için belirtiler ve çözümler açıklanmaktadır.

• Kaynakları bekleme

  Belirti: Örnekler Ready durumundadır veya bazıları Running durumundayken diğerleri Ready durumundadır. Bir örnek Ready durumunda olsa da bir Debug geçmişine sahipse, kaynakları bekliyor değil, bir hatadan sonra yeniden deneniyor olabilir. Fuxi örnek listesinde, SmartFilter kullanarak duruma göre filtreleme yapabilirsiniz. Status sütunu her bir örneğin mevcut durumunu gösterir.

  Çözüm:

  1. Sıraya alma işleminin normal olup olmadığını belirleyin. LogView'in sol tarafındaki Basic Info panelinde Queue Length değerini kontrol ederek işin kuyruktaki konumunu görebilirsiniz. Alternatif olarak, MaxCompute konsolunda ilgili kota grubunun kaynak kullanımını kontrol edin. MaxCompute konsolunun sol gezinme bölmesinde Project Management > Quota Management > Resource Consumption seçeneklerini seçerek hedef kota grubu için CPU Resource gibi ölçümlerin trend grafiklerini görüntüleyin. Bir kaynağın kullanımı kotaya yakınsa veya kotayı aşarsa, kota grubu kaynak sıkıntısı yaşıyor demektir ve iş sıraya alınması normaldir. Zamanlama sırası yalnızca gönderim zamanına ve önceliğe değil, aynı zamanda gerekli bellek veya CPU kaynaklarının mevcut olup olmadığına da bağlıdır.

  2. Kota grubunu kullanan işleri görüntüleyin.

     Düşük önceliğe sahip büyük işler gönderilmiş veya aynı anda birden çok küçük iş gönderilmiş olabilir. Bu işler çok sayıda kaynak kaplar. İşlerin sahipleriyle iletişime geçerek işleri sonlandırabilir ve işler tarafından kaplanan kaynakları serbest bırakabilirsiniz.

  3. İşin kota grubunu başka bir projenin kota grubuyla değiştirin.

  4. Kaynakları ölçeklendirin. Bu çözüm yalnızca abonelik tabanlı kaynakları kullanan kullanıcılar için uygundur.

• Veri eğriliği

  Belirti: Bir görevdeki çoğu örnek tamamlanmıştır, ancak birkaç "uzun kuyruk" örneği hala çalışmaktadır. Bu örnekler muhtemelen daha büyük miktarda veri işledikleri için yavaş çalışır. SmartFilter içinde Long-Tails sayısını kontrol edebilir ve Latency sütunundaki her bir örneğin süresini karşılaştırabilirsiniz.

  Çözüm: Veri eğriliğinin yaygın nedenleri ve ilgili optimizasyon yöntemleri hakkında daha fazla bilgi için bkz. Veri eğriliği ayarlama.

• Verimsiz UDF çalıştırma

  Bu konuda UDF'ler; kullanıcı tanımlı skaler işlevler (UDF'ler), kullanıcı tanımlı toplama işlevleri (UDAF'ler), kullanıcı tanımlı tablo değerli işlevler (UDTF'ler), kullanıcı tanımlı birleşimler (UDJ'ler) ve kullanıcı tanımlı türler (UDT'ler) dahil olmak üzere çeşitli kullanıcı tanımlı uzantıları ifade eder.

  Açıklama: Bir görevin çalıştırma verimliliği düşüktür ve görev UDF'ler içerir. UDF çalıştırma zaman aşımını belirten aşağıdaki hata iletisi görüntülenebilir: Fuxi job failed - WorkerRestart errCode:252,errMsg:kInstanceMonitorTimeout, usually caused by bad udf performance.

  Sorun giderme: Bir görev başarısız olduğunda, LogView'daki job details sekmesindeki DAG'yi inceleyerek görevin bir UDF içerip içermediğini hızlıca belirleyebilirsiniz. DAG'de, başarısız olan görev kırmızı renkle gösterilir ve düğüm üzerindeki ["JAVA"] gibi bir fx etiketi UDF'nin dilini belirtir. Örneğin, başarısız olan R4_3 görevinin Java ile yazılmış bir UDF içerdiğini görebilirsiniz. Operatör zincirini üstten alta listeleyen ve alt kısımda referans verilen tüm UDF'lerin listesini gösteren Operator görünümünü açmak için R4_3 öğesine çift tıklayın. Ayrıca, görevin StdOut günlüğü UDF'nin giriş kayıt sayısını, çıkış kayıt sayısını ve işleme süresini gösterir. Bu veriler, performans sorunlarını belirlemenize yardımcı olur. Genellikle, Speed(records/s) değeri yüz binlerce veya milyonlarca düzeyindeyse normal kabul edilir. Bu değer on binler seviyesine düşerse bir performans sorunu olması muhtemeldir. Günlükte UDF işlemenin bir özeti ve her bir operatör (CursorId) için OutputCount, InnerTime ve Speed(records/s) değerlerini içeren bir istatistik tablosu görüntülenir.

  Çözüm: Bir performans sorunu oluşursa, sorunu gidermek ve performansı optimize etmek için aşağıdaki yöntemi kullanabilirsiniz.

  1. UDF'de bir hata oluşup oluşmadığını kontrol edin.

     Belirli durumlarda, performans sorunu belirli bir veri değerinden kaynaklanır. Örneğin, belirli bir değer ortaya çıktığında sonsuz bir döngü oluşur. MaxCompute Studio, bir tablonun belirli örnek verilerini indirmenize ve bu verileri yerel makinenizde sorun gidermek için kullanmanıza olanak tanır. Daha fazla bilgi için MaxCompute Studio geliştirme kılavuzundaki Java UDF'leri ve Python UDF konularına bakın.

  2. UDF adının yerleşik bir işlevle aynı olup olmadığını kontrol edin.

     Adı aynı olan bir UDF tarafından yerleşik bir işlev üzerine yazılabilir. Bir işlev yerleşik bir işlev gibi görünüyorsa, adı aynı olan bir UDF'nin yerleşik işlevi üzerine yazıp yazamayacağını belirlemeniz gerekir.

  3. UDF'yi değiştirmek için yerleşik bir işlev kullanın.

     Benzer özellikler sağlayan yerleşik işlevler varsa, UDF'leri kullanmamanız önerilir. Yerleşik işlevler doğrulanmış ve daha verimli bir şekilde kullanılır. Ayrıca, iyileştiriciler yerleşik işlevler üzerinde beyaz kutu testi gerçekleştirir. Bu nedenle, daha fazla optimizasyon yapılabilir. Yerleşik işlevlerin kullanımı hakkında daha fazla bilgi için bkz. Yerleşik işlevler.

  4. Belirli UDF'leri benzer özellikler sağlayan yerleşik işlevlerle değiştirin ve yalnızca yerleşik işlevler kullanılarak uygulanamayan UDF'leri koruyun.

  5. UDF'lerin evaluate yöntemini optimize edin.

     Evaluate yöntemini yalnızca parametrelerle ilgili gerekli işlemlerde kullanın. Evaluate yöntemi tekrar tekrar çalıştırıldığından, başlatmayla ilgili işlemleri veya tekrarlanan hesaplamaları önceden gerçekleştirin.

  6. Bir UDF'nin çalıştırılması için gereken süreyi tahmin edin.

     Bir UDF'nin çalıştırılması için gereken süreyi test etmek amacıyla yerel makinenizde bir örnek tarafından işlenen veri miktarını simüle edin. Ardından, UDF'nin uygulamasını optimize edin. Varsayılan olarak, bir UDF'nin çalıştırılması için gereken maksimum süre 30 dakikadır. Bir UDF, 30 dakika içinde veri döndürmeli veya kalp atışı raporlamak için context.progress() kullanmalıdır. Bir UDF'nin çalıştırılması için tahmini süre 30 dakikadan uzunsa, bir UDF'nin zaman aşımı süresini belirtmek üzere bir parametre yapılandırabilirsiniz.

     Default value: 1800. Unit: seconds. Valid values: 1 to 3600.
     -- Specify the timeout period of a UDF. Unit: seconds. Default value: 600.
     -- You can manually adjust the timeout period of the UDF in the range of [0,3600].

  7. Bellek parametrelerini değiştirin.

     UDF'lerin düşük verimliliği mutlaka hesaplama karmaşıklığından kaynaklanmaz. Depolama karmaşıklığı da UDF'lerin verimliliğini etkileyebilir. Örnekler:

     • Bir UDF büyük miktarda veri üzerinde bellek hesaplama gerçekleştirirse veya sıralama yaparsa bellek taşması oluşur.

     • Yetersiz bellek, yüksek çöp toplama (GC) sıklığına neden olur.

     Önceki sorunları geçici olarak ele almak için bellek parametrelerini değiştirebilirsiniz. Optimizasyon iş gereksinimlerinize göre gerçekleştirilmelidir. Örnek:

     set odps.sql.udf.jvm.memory=
     -- Specify the maximum memory size that can be used for the JVM heap of a UDF. Default value: 1024. Unit: MB.
     -- You can change the value of the odps.sql.udf.jvm.memory parameter in the range of [256,12288].

     Not

     Bir UDF kullanılırsa, bölüm budama geçersiz hale gelebilir. MaxCompute V2.0'dan itibaren UdfProperty ek açıklaması desteklenir. Bir UDF tanımlarken, derleyicinin UDF'nin deterministik olduğunu belirtmesi için bu ek açıklamasını kullanabilirsiniz. Örnek kod:

     @com.aliyun.odps.udf.annotation.UdfProperty(isDeterministic = true)
     public class AnnotatedUdf extends com.aliyun.odps.udf.UDF {
         public String evaluate(String x) {
             return x;
         }
     }

     Bir UDF için SQL deyimini yeniden yazarsanız, UDF'yi bölüm filtrelemede kullanabilirsiniz.

     -- SQL statement before rewriting
     SELECT * FROM t WHERE pt = udf('foo');  -- pt indicates a partition key column of t.
     -- SQL statement after rewriting
     SELECT * FROM t WHERE pt = (SELECT udf('foo')); --pt indicates a partition key column of t.

• Veri şişmesi

  Belirti: Bir görevin çıkış verisi, giriş verisinden çok daha büyüktür. Örneğin, 1 GB'lık veri işlendikten sonra 1 TB'a dönüşürse, 1 TB veriyi işleyen bir örneğin performansı ciddi şekilde düşer. İş tamamlandıktan sonra, görevin I/O Records bölümü giriş ve çıkış veri hacimlerini gösterir. Bir iş Join aşamasında takılı kalırsa, SmartFilter kullanarak birkaç Running örneği seçin ve StdOut simgesine tıklayarak StdOut günlüklerini kontrol edin. StdOut günlüğü sürekli olarak Merge join cursor kayıtları gösteriyor ve OutputRowCount değeri artmaya devam ediyorsa, bu durum ciddi veri şişmesine işaret eder. JOIN koşulunun ve birleştirme anahtarının makul olup olmadığını kontrol etmeniz gerekir.

  Çözüm:

  • Kodda aşağıdaki sorunları kontrol edin: JOIN koşulunun doğru olup olmadığı, JOIN koşulunun Kartezyen çarpım olarak yazılıp yazılmadığı, UDTF'nin normal olup olmadığı ve aşırı çıktı verisi üretilip üretilmediği.

  • Veri şişmesinin toplamadan kaynaklanıp kaynaklanmadığını kontrol edin.

    Çoğu toplayıcı özyinelemeli toplama gerçekleştirir. Bir toplayıcı verileri topladığında, önce ara sonuçları birleştirir. Ara sonuç verilerinin miktarı büyük değildir ve çoğu toplayıcının hesaplama karmaşıklığı düşüktür. Veri miktarı büyük olsa bile toplama hızla tamamlanabilir. Çoğu durumda, toplama sırasında veri şişmesi oluşmaz. Ancak, aşağıdaki senaryolarda toplama gerçekleştirirseniz veri şişmesi oluşabilir:

    • SELECT deyiminde farklı boyutlarda DISTINCT işlemi gerçekleştirmek için toplamayı etkinleştirin. DISTINCT işlemi her gerçekleştirildiğinde veri genişler.

    • GROUPING SETS veya CUBE | ROLLUP deyimi kullanırsanız, ara sonuç verilerinin boyutu orijinal veri boyutuna kıyasla birkaç kat artabilir. Ancak, COLLECT_LIST veya MEDIAN gibi belirli bir deyim kullanırsanız, tüm ara sonuç verilerini korumanız gerekir. Bu durum belirli sorunlara neden olabilir.

  • JOIN işlemleri nedeniyle oluşan veri şişmesini önleyin.

    Örneğin, iki tabloyu birleştirmek istiyorsunuz. Sol tablo büyük miktarda nüfus verisi içerir. Ancak, MaxCompute örneklerinin yüksek paralellliği sayesinde işleme verimliliği yüksektir. Sağ tablo, her cinsiyet için olası kötü alışkanlıklar gibi bilgileri kaydeden bir boyut tablosudur. Boyut tablosu yalnızca iki cinsiyet içerir ancak her cinsiyete karşılık gelen yüzlerce satır mevcuttur. Tabloları cinsiyete göre birleştirirseniz, sol tablodaki veriler yüzlerce kat genişleyebilir. Veri şişmesini önlemek için, tabloları birleştirmeden önce sağ tablodaki veri satırlarını iki satır veri halinde toplayabilirsiniz.

  • Veri şişmesinin GROUPING SET deyimi nedeniyle oluşup oluşmadığını kontrol edin. GROUPING SET deyimi yürütüldüğünde, veri genişler ve çıkış verisi grup sayısına kıyasla birkaç kat artar. Mevcut yürütme planı GROUPING SET deyimine uyum sağlayamaz veya aşağı akış görevlerinin paralellik derecesini değiştiremez. Aşağı akış görevlerinin paralellik derecesini manuel olarak yapılandırabilirsiniz. Örnek deyimler:

    set odps.stage.reducer.num = xxx; 
    set odps.stage.joiner.num = xxx;

Sonlandırma aşaması

• Birden çok aşamada alt sorgu yürütme

  Çoğu durumda, MaxCompute SQL alt sorguları aynı Fuxi DAG'sine derlenir. Bu nedenle, tüm alt sorgular ve ana sorgular tek bir Fuxi işiyle tamamlanır. Ancak, belirli özel alt sorguların ana sorgulardan önce ayrı olarak çalıştırılması gerekir. Örnek kod:

  SELECT
       product,
      sum(price)
   FROM
       sales
   WHERE
       ds in (SELECT DISTINCT ds FROM t_ds_set)
   GROUP BY product;

  Alt sorgu SELECT DISTINCT ds FROM t_ds_set önce yürütülür ve sonucu, ana sorgunun okuduğu bölüm sayısını optimize etmek için bölüm budama amacıyla gerekir. Bu iki çalışma ayrı Fuxi işleridir. LogView'de her Fuxi işi SQL_0_0_0_job_0 ve SQL_0_0_1_job_1 gibi ayrı bir sekmede görünür. DAG ayrıca birden çok JOB düğümü arasındaki bağımlılıkları gösterir. job_1 işinin yürütme durumunu görüntülemek için ikinci sekmeye tıklamanız yeterlidir. Geçiş yaptıktan sonra, job_1 içindeki her bir görevin mevcut durumunu (Running veya Waiting gibi) görebilirsiniz.

• Aşırı sayıda küçük dosya

  Aşırı sayıda küçük dosya öncelikle depolama performansını ve hesaplama performansını etkiler.

  • Depolama: Aşırı sayıda küçük dosya, Apsara Dağıtık Dosya Sistemindeki iş yükünü artırır. Bu durum depolama kullanımını etkiler.

  • Hesaplama: MaxCompute'un tek bir büyük dosyadaki işleme verimliliği birden çok küçük dosyadaki işleme verimliliğinden daha yüksek olduğu için genel işleme performansı etkilenir. Bu nedenle, bir SQL işi tamamlandığında, belirli koşullar karşılanırsa küçük dosyaları birleştirmek için kullanılan işlem otomatik olarak tetiklenir. Bu, sistemin aşırı sayıda küçük dosya oluşturmasını önlemeye yardımcı olur.

• Aşırı sayıda küçük dosya varsa, bir iş sonlandırma aşamasındayken SELECT deyimleri uzun bir süre çalıştırılabilir. Sistem SELECT deyimlerinin yürütme sonuçlarını oluşturup görüntülerken, dosyalardan veri okumak için çok sayıda küçük dosya açması gerekir. Bu işlem zaman alıcıdır. Sistemin çok sayıda yürütme sonucu oluşturmasını önlemek için SELECT deyimlerini kullanmamanız önerilir. Verileri indirmek için Tunnel komutlarını kullanabilirsiniz. Yürütme sonuçlarının sayısı fazla değil ancak dosya sayısı aşırı derecede fazlaysa, odps.merge.smallfile.filesize.threshold parametresinin doğru şekilde yapılandırılıp yapılandırılmadığını kontrol etmeniz önerilir. Küçük dosyaların nasıl birleştirileceği hakkında daha fazla bilgi için bkz. Küçük dosyaları birleştirme.

  Çözüm: İşin otomatik küçük dosya birleştirmeyi tetikleyip tetiklemediğini LogView'de kontrol edebilirsiniz. Çok aşamalı alt sorgu yürütme işleminde olduğu gibi, birleştirme işi ayrı bir sekmede görünür. Bir birleştirme işinin sekme adı SQL_0_0_0_merge gibi görünebilir ve MergeTask ilerlemesini gösterir. Bu durum toplam iş yürütme süresine katkıda bulunsa da, çıkış tablosundaki dosya sayısı ve boyutunun daha makul olmasını sağlar. Bu durum, dosya sistemi üzerinde aşırı baskı oluşmasını önler ve tabloyu kullanan sonraki işler için okuma performansını artırır.

• Dinamik bölümlerde meta veri güncelleme

  Sorun açıklaması: Bir Fuxi işi tamamlandıktan sonra, meta verilerle ilgili belirli işlemler gerçekleştirmeniz gerekebilir. Örneğin, sonuç verilerini belirli bir dizine taşımak ve tablonun meta verilerini güncellemek istiyorsanız, dinamik bölümleme sırasında tabloda çok sayıda bölüm oluşturulabilir. Sonuç olarak, işlem zaman alıcı olur. Örneğin, 2.000 bölüm eklemek için bölümlenmiş sales tablosunda insert into ... values deyimi yürütülür. Örnek deyim:

  INSERT INTO TABLE sales partition (ds)(ds, product, price)
  VALUES ('20170101','a',1),('20170102','b',2),('20170103','c',3), ...;

  Fuxi işi tamamlandıktan sonra, tablonun meta verilerini güncellemek için hala zaman gerekir. LogView'in SubStatusHistory bölümü, işin SQLTask is updating meta information aşamasında takıldığını gösterir. Bu durum 1260 durum koduna karşılık gelir ve meta veri güncellemesinin ne kadar zaman aldığını görmek için Latency değerini kontrol edebilirsiniz.

• Çıkış dosyası boyutunda artış

  Belirti: Giriş ve çıkış kayıt sayıları benzer olsa bile veri birkaç kat genişleyebilir. Fuxi Jobs bölümündeki IO Bytes sütununda, verinin hangi aşamada genişlediğini belirlemek için her bir Görevin Giriş ve Çıkış veri boyutlarını karşılaştırabilirsiniz.

  Çözüm: Bunun nedenlerinden biri, sıkıştırmayı etkileyen veri dağılımındaki bir değişikliktir. Veriler bir tabloya yazılırken sıkıştırılır. Sıkıştırma algoritmaları, tekrarlayan verilerde en yüksek sıkıştırma oranına ulaşır. Bu nedenle, yazma işlemi sırasında aynı veriler birlikte gruplanırsa yüksek bir sıkıştırma oranı elde edilebilir. Veri dağılımı büyük ölçüde yazma aşamasında (Fuxi Jobs'ta R12) verilerin nasıl karıştırıldığına ve sıralandığına bağlıdır. Bu örnekte, son SQL işlemi aşağıdaki birleştirme anahtarıyla bir JOIN işlemidir:

  on  t1.query = t2.query and t1.item_id=t2.item_id

  Verinin özellikleri, çoğu sütunun öğelerin nitelikleri olduğunu gösterir. Bu durumda, aynı item_id değerine sahip öğeler için tüm sütunlar aynıdır. Bu nedenle, sorgudaki tüm öğeler rastgele sırada sıralanır. Bu durum düşük bir sıkıştırma oranına neden olur. Aşağıdaki örnek kod, birleştirme sırasının nasıl değiştirileceğine dair bir örnek sunar. Değişiklikten sonra, veri boyutu orijinal veri boyutunun 1/3'üne düşer.

  on t1.item_id=t2.item_id and t1.query = t2.query

  Değişiklikten sonra, veri boyutu orijinal veri boyutunun 1/3'üne düşer.

  Başka bir durumda, JOIN veya GROUP BY tarafından oluşturulan karıştırma işlemleri sıkıştırma için en uygun sıralama sütununu içermez. Bu durumda, öğeleri yerel makinenizde sıralamak için ZORDER BY yan tümcesini kullanabilirsiniz. Bu sayede, daha düşük maliyetle yüksek bir sıkıştırma oranı elde edebilirsiniz. Veri dağılımını manuel olarak yeniden düzenlemek için bir DISTRIBUTED BY SORT BY deyimi de yürütebilirsiniz. Bu yöntem, veri hesaplaması için uzun bir süre ve yüksek CPU kullanımı gerektirir.