LookML ile Yüksek Performanslı Veri Modelleri Oluşturma Rehberi

İyi bir LookML, yalnızca soruları yanıtlamakla kalmaz; onları daha hızlı, daha temiz ve kolay sorgulanabilir hale getirir. Looker’da biraz deneyim kazandıysanız, LookML’in sadece bir modelleme dili olmadığını fark edersiniz. Looker, ham veriyi güvenilir ve iş için hazır içgörülere dönüştüren temel bir platformdur. Ölçeklenebilir bir LookML modeli oluşturmak ise onu sadece “çalışır” hale getirmekle ilgili değildir; temiz, tutarlı ve sürdürülebilir kod yazmayı gerektirir. Bu sayede gelecekte hem siz hem de ekip arkadaşlarınız daha memnun ve verimli olabilirsiniz.

Bu rehberde, temel bilgilerin ötesine geçerek Dimensions ve Measures sözdizimini, Explore ve join tanımlarını, ayrıca türetilmiş tablolar ve PDT’ler ile önbellekleme stratejilerini detaylıca ele alacacağız. Yalnızca her parametrenin ne yaptığını öğrenmekle kalmayacak, onları LookML’de tam olarak nasıl yazacağınızı da göreceksiniz.

İster ilk modelinizi oluşturuyor olun, ister karmaşık bir analitik katmanını yeniden düzenliyor olun; bu örüntüler ve en iyi uygulamalar LookML’inizi anlaşılır, tekrar kullanılabilir ve performans için optimize edilmiş hale getirmenize yardımcı olacak.

1. Boyut (Dimension) ve Ölçüm (Measure) Sözdizimi

1.1 Boyut (Dimension) Tanımlama

Dimension, kaynağınızdaki verinin bir özelliğini (sütun) temsil eder. Tanımlarken şu en iyi uygulamaları takip edin:

• İsimlendirme kuralı: Küçük harflerle yazın ve boşluklar için alt çizgi kullanın (örn. full_name).
• Kod düzeni: Gezinmeyi kolaylaştırmak için yeni dimension’ları view dosyasında mevcut olanların ardına ekleyin.

Örnek:

Önemli dimension parametreleri:

• type
  • string – Metin değerleri için varsayılan.
  • number – Sayısal veriler ve matematiksel hesaplamalar için.
  • yesno – Boolean çıktısı (“Yes”/”No”).
  • tier – Değerleri aralıklara ayırmak için.
• dimension_group – Tek bir alandan birden fazla dimension oluşturur.
  • type: time – Tarih/zaman alanları için (timeframes gerektirir)
  • ${created_date} ile referans verin.
  • type: duration – Zaman farkları için (intervals, sql_start, sql_end gerektirir)
  • Esneklik için sabit kodlanmış DATE_DIFF() yerine kullanın.

1.2 Ölçüm (Measure) Tanımlama

Measure, verinizin toplanmış (aggregate) versiyonudur.

Yaygın measure türleri şunlardır:

• sum – Değerleri toplar.
• average – Ortalama hesaplar.
• count – Satırları sayar, varsayılan olarak primary key kullanır.
• count_distinct – Benzersiz değerleri sayar.

Örnek:

Ek seçenekler:

• value_format_name – Gösterim formatı (örn. para birimi için usd_0).
• filters – Bir measure için koşul uygular.

Örnek:

• Diğer measure’lardan türetme: LookML’de, measure’ları yalnızca ham alanlardan oluşturmakla sınırlı değilsiniz, aynı zamanda mevcut measure’lardan yeni measure’lar da oluşturabilirsiniz. Yeter ki; yeni measure’ın type değerini number olarak ayarlayın.
  
  Bu özellikle, oranlar, yüzdeler veya KPI gibi performans metriklerini hesaplamak istediğinizde faydalıdır. Çünkü bu sayede toplama mantığını tekrar etmenize gerek kalmaz. SQL’i yeniden yazmak yerine diğer measure’lara referans vererek hesaplamalarınızın tutarlı kalmasını ve gelecekte yapılacak değişikliklerin orijinal measure’lara otomatik olarak yansımasını sağlarsınız.

Örnek:

Bu örnekte, total_profit ve total_revenue önceden tanımlanmış measure’lardır. Bunları bölerek şu özelliklere sahip bir hesaplanmış KPI oluşturursunuz:

• Sürdürülmesi daha kolaydır, tekrar eden SQL yoktur.
• Hataya daha az açıktır, orijinal measure’ların mantığını devralır.
• Kaynak measure’lar değişirse, otomatik olarak güncellenir.

💡 Önemli Tavsiye: Measure’lara her zaman ${TABLE}.column_name yerine ${measure_name} ile referans verin. Bunu yaptığınızda, mantığınız ortaklaşır ve tutarsız hesaplamalar yapma riskiniz azalır.

1.3 Alanlara Referans Verme

LookML, mantığı yeniden kullanmak ve sabit kodlamayı azaltmak için yerine koyma operatörleri (substitution operators) kullanır.

• ${field_name} – Aynı view’daki mevcut bir dimension ya da measure’a referans verir.

Örnek:

• ${TABLE}.column_name – Doğrudan bir veritabanı sütununa referans verir, bir alanı ilk kez tanımlarken kullanılır.
• ${view_name.field_name} – Join edilmiş başka bir view’daki alanlara referans verir.

2. Explore ve Join Sözdizimi

2.1 Explore Tanımlama

Explore, önceden join edilmiş view’ları içeren bir analiz başlangıç noktasıdır.

Örnek:

Explore adı mutlaka mevcut bir view adıyla eşleşmelidir.

2.2 Join Tanımlama

Join’ler, Explore içindeki ek view’ları bağlar.

Örnek:

Temel join parametreleri:

• type: left_outer (varsayılan), inner, full_outer, cross.
• sql_on: LookML alan referansları kullanan join koşulu.
• relationship: Simetrik toplama için kardinaliteyi tanımlar (one_to_one, one_to_many, many_to_one, many_to_many).
• from: Aynı view birden fazla kez join edildiğinde alias için kullanılır.

2.3 Birincil Anahtarlar (Primary Keys) ve Filtreleme

• primary_key: yes – Simetrik toplama için her view’da mutlaka tanımlayın.
• sql_always_where – Gizli ve kaldırılamayan bir WHERE ifadesi ekler.
• sql_always_having – Gizli ve kaldırılamayan bir HAVING ifadesi ekler.
• always_filter – Görünür ve zorunlu bir filtre; kullanıcı kaldıramaz.
• conditionally_filter – Görünür filtre; başka bir filtre uygulandığında kaldırılabilir.

Özet Tablo: Filtreleme Türleri

3. Türetilmiş Tablolar (Derived Tables) Sözdizimi

Türetilmiş tablolar; temel veritabanında var olmayan, LookML’de tanımlanmış özel tablolardır. Kaynak şemayı değiştirmeden doğrudan modelinizde tekrar kullanılabilir dönüşümler oluşturmanıza olanak tanır.

💡 Daha önce yayınladığımız Looker en iyi uygulamaları konulu yazıyı incelemek için buraya tıklayın.

3.1 Türetilmiş Tablolar (SQL-Derived Tables – SDTs) -View olarak

SDT’ler LookML içinde ham SQL ile tanımlanır. Bunları SQL Runner üzerinden veya doğrudan IDE içinde oluşturabilirsiniz ve Looker sizin için bir .view dosyası üretir. Bu dosyayı projenizdeki diğer view’lar gibi kullanabilirsiniz.

SDT’ler ne zaman kullanmalı?

• SQL ile ifade edilmesi LookML’den daha kolay olan dönüşümler için idealdir.
• Tek seferlik ön toplama gerektiğinde kullanışlıdır.
• Karmaşık join’ler veya CASE mantığı Explore join’lerine iyi dönüştürülmediğinde faydalıdır.

Örnek:

3.2 Yerel Türetilmiş Tablolar (Native Derived Tables – NDTs)

NDT’ler tamamen LookML ile yazılır ve mevcut LookML nesnelerinden (dimensions, measures, filters) yararlanır.

NDT’ler ne zaman kullanmalı?

LookML modelinizle sıkı bir şekilde entegre kalacak dönüşümler istediğinizde özellikle değerlidir.

• SQL mantığını tekrar etmeyi önler; her şey LookML alanlarına referans verir.
• Kaynak alanlar değiştiğinde güncellemeleri otomatik olarak devralır.
• Bakımı daha kolaydır ve modeller arasında taşınabilir.

Örnek:

Temel Parametreler:

• explore_source – Oluşturulacak Explore (SQL’deki FROM ile eşdeğer).
• column – Türetilmiş tablodaki çıktı alanı; yeniden adlandırılabilir veya alias verilebilir.
• filters – WHERE/HAVING koşulları ekler.
• bind_filters – Explore’dan kullanıcı filtrelerini NDT’ye geçirir.
• derived_column – NDT içinde, hesaplanmış yeni bir sütun oluşturur.
• expression_custom_filter – AND/OR ile karmaşık filtre mantığı oluşturur.

3.3 Kalıcı Türetilmiş Tablolar (Persistent Derived Tables – PDTs)

PDT’ler türetilmiş tabloları veritabanınızda saklar. Böylece her seferinde sorguları yeniden oluşturmak yerine materyalize edilmiş bir versiyon üzerinde çalışır. Bu, performans ağırlıklı sorgular veya anlık veri gösteriminde tutarlılık gerektiğinde kritik öneme sahiptir.

PDT’ler ne zaman kullanmalı?

• Büyük taramalar veya pahalı join’ler gerektirecek sorguları hızlandırır.
• Aynı materyalize edilmiş veriyi sunarak kullanıcılar arasında tutarlılığı sağlar.
• Türetilmiş tabloların birbirine bağlı olduğu durumlarda kademeli mantık için faydalıdır.

Kalıcılık Stratejileri:

Seçenek 1 – datagroup_trigger kullanımı: Tavsiye edilir; önbellek politikasına göre yeniden oluşturur.

Seçenek 2 – sql_trigger_value kullanımı: Sorgu sonucu değiştiğinde yeniden oluşturur.

Seçenek 3 – persist_for kullanımı: PDT’yi belirli bir süre boyunca güncel tutar.

3.4 Geçici Türetilmiş Tablolar (Ephemeral Derived Tables (EDTs)

EDT’ler geçicidir; veritabanında kalıcı olmazlar. Bunun yerine, genellikle Looker’ın oluşturduğu SQL sorgusu içinde yalnızca Ortak Tablo İfadesi (CTE) olarak var olurlar.

EDT’ler ne zaman kullanmalı?

• Hafif ara dönüşümler için idealdir.
• Veritabanı depolama maliyetlerinin önüne geçer.
• Sadece bir defa ihtiyaç duyulan ve tekrar kullanılmayacak mantık için mükemmeldir.

Örnek:

Özet Tablosu: Türetilmiş Tablo Türleri

4. Önbellekleme ve Veri Grubu (Datagroup) Söz Dizimi

Datagroup’lar, Looker’ın önbelleğe alınmış sorgu sonuçlarını veya PDT’lerin ne zaman güncelleneceğini kontrol etme yöntemidir. Onları, birden fazla Explore ve PDT’nin paylaşabileceği merkezi önbellek politikaları olarak düşünebilirsiniz. Böylece veriniz güncel, yüksek performanslı ve tutarlı kalırken, veritabanına fazla yük binmez.

Neden önemlidir?

• Performans: Gereksiz sorguları azaltır ve veritabanı maliyetlerini düşürür.
• Tutarlılık: Tüm bağımlı Explore ve PDT’ler aynı takvime göre güncellenir.
• Kontrol: Önbellek güncellemelerini rastgele bir zamana değil, bir veritabanı değişikliğine (via sql_trigger) bağlayabilirsiniz.

4.1 Datagroup Tanımlama

Datagroup’lar önbellek yenileme kurallarını tanımlar.

En İyi Uygulama:

Her zaman hem max_cache_age (zaman bazlı yenileme) hem de sql_trigger (olay bazlı yenileme) tanımlayın.

• max_cache_age verinin uzun süre eski kalmasını önler.
• sql_trigger gerçek kaynak tablo değişikliklerini algılar ve gerektiğinde hemen yeniler.

Örnek:

• max_cache_age: Veri değişikliği olmasa bile her saat başı yenilemeyi zorlar.
• sql_trigger: En yüksek order_id değerini kontrol eder; değişirse önbellek hemen yenilenir.

4.2 Datagroup Uygulama

• Explore seviyesinde: Explore seviyesinde önbellek kontrolü sağlar.

• PDT yenilemesi için: Yeniden PDT oluşturmayı bir datagroup’a bağlayın.

• Sabit zamanlı önbellekleme (datagroup yoksa): Datagroup desteklenmediğinde kullanılır.

Özet Tablosu: Datagroup vs. persist_for

LookML’de Ustalaşmak için Nihai Özet Tablosu

⭐⭐⭐

LookML yalnızca bir modelleme dili değil, ham veriniz ile iş kararlarınızı yönlendiren içgörüler arasında bir köprüdür. Explore, Dimensions, Measures, türetilmiş tablolar ve veri grubu gibi kavramları ustalıkla kullanarak, hızlı, doğru ve tutarlı analizleri ölçekli şekilde sunma yeteneğini açığa çıkarırsınız. Bu en iyi uygulamalar sayesinde sorgu performansını optimize ederken, yönetişim kurallarını uygularken ya da tekrar kullanılabilir metrikler oluştururken her pano ve veri keşfinin doğru hikayeyi, doğru zamanda anlatmasını sağlarsınız.

Looker deneyiminizi bir üst seviyeye taşımaya hazır mısınız? Ekibimiz, ölçeklenebilir bir LookML çerçevesi tasarlamanıza, performansı optimize etmenize ve iş kullanıcılarınızın yönetişimden ödün vermeden kendi içgörülerini elde edebilmesine yardımcı olabilir.

Bizimle iletişime geçin, verinizi rekabet avantajına dönüştürelim.