E
Emrah Tezcan
Misafir
Misafir
Performans karşılaştırmasına geçmeden önce oyuncuları tanımakta fayda var. Bu yazıda SAP HANA sistemlerinde veri okumanın üç temel yöntemini ele alıyoruz: klasik ABAP Open SQL, Core Data Services (CDS) view’lar ve HANA Calculation View’lar. Her birinin ne olduğunu, neden var olduğunu ve birbirinden nasıl ayrıldığını anlatıyoruz.
Üç SAP geliştiricisine HANA sisteminde veriyi nasıl okuyup toplayacaklarını sorarsanız üç farklı cevap alabilirsiniz: “Bir SELECT yaz, yeter”, “Bir CDS view oluştur” ya da “Calculation View olarak modelle”. Üç cevap da doğru ve konuyu kafa karıştırıcı yapan da bu. Her yöntem farklı bir dönemden ve SAP mimarisinin farklı bir katmanından geliyor. Her birinin kendine özgü güçlü yanları var ve ABAP tarafından her biri farklı bir şekilde kullanılıyor.
Bu yazıda üç yaklaşımı tek tek inceliyor, ardından farklarını yan yana koyuyoruz. Yazı, ölçümlere dayalı performans karşılaştırmamızın kavramsal tamamlayıcısı. Burada amacımız milisaniyeleri değil, yöntemlerin mantığını anlamak.
Open SQL (yeni sürümlerde kısaca ABAP SQL olarak geçiyor), ABAP diline gömülü SQL dilidir. ABAP programları onlarca yıldır veritabanı tablolarını bu yöntemle okuyor:
Open SQL’in en belirgin özelliği, veritabanından bağımsız çalışması ve ABAP ile derin entegrasyonudur. Aynı ifade, SAP’nin desteklediği her veritabanında değişiklik yapmadan çalışır. Bunu sağlayan ABAP çekirdeğidir: ifadeyi alttaki platformun kendi SQL diline çevirir. Bu sırada geliştiricinin hiç düşünmek zorunda kalmadığı işleri de arka planda halleder: client yönetimi (MANDT filtresini otomatik ekler), ABAP ve veritabanı tipleri arasındaki dönüşümler ve sonuçların internal table’lara verimli aktarımı.
Peki neden tercih ediliyor? Çünkü bir ABAP programından veriye ulaşmanın en kısa yolu bu. Ek bir nesne oluşturmanız, aktivasyon yapmanız ya da ayrı bir yaşam döngüsü yönetmeniz gerekmez. Sorgu, programın içinde yaşar. Modern Open SQL ayrıca epey güçlendi: güncel sürümlerde join’ler, toplama fonksiyonları, CASE ifadeleri, SELECT listesinde aritmetik işlemler, CTE’ler ve window fonksiyonları kullanılabiliyor. Bu da kapsamlı bir mantığı tek bir ifadeyle veritabanına taşıyabileceğiniz anlamına geliyor.
Sınırı da bir o kadar net: Open SQL ifadesi yeniden kullanılamaz. Mantık tek bir programın içine hapsolur. Beş farklı rapor aynı join ve toplama mantığına ihtiyaç duyuyorsa, bu mantık beş kez yazılır. Bir sonraki yöntemin çözdüğü sorun da tam olarak bu.
Core Data Services (CDS) view’lar, Eclipse’te (ABAP Development Tools) DDL kaynağı olarak tanımlanan veri modelleridir. Bir CDS view, belirli bir veri mantığını (join’ler, hesaplanan alanlar, toplamalar, association’lar) ABAP sözlüğünde adı olan, yeniden kullanılabilir ve taşınabilir bir nesne olarak tutar:
Artık her ABAP programı bu view’u tek satırlık bir SELECT ile kullanabilir ve her kullanıcı aynı, merkezi olarak yönetilen mantığa erişir. View ABAP katmanında tanımlansa da veritabanında çalışır. CDS, SAP’nin code pushdown (“kodu veriye taşı”) yaklaşımının ana aracıdır.
Kısacası Open SQL ile CDS arasındaki fark, sorgunun nerede çalıştığı değil (ikisi de HANA’ya taşınır), mantığın nerede yaşadığıdır: tek bir programın içinde mi, yoksa paylaşılan ve anlam açısından zengin bir sözlük nesnesi olarak mı?
Calculation View’lar ise madalyonun öbür yüzünden gelir. Bunlar ABAP katmanında değil, HANA Modeler’da (HANA Studio ya da yeni kurulumlarda Web IDE / Business Application Studio) oluşturulan yerel HANA nesneleridir. Geliştirici kod yazmak yerine grafiksel bir veri akışı kurar: seçim ve filtreleme için projection düğümleri, join düğümleri, union düğümleri, aggregation düğümleri, boyutsal modeller için star join’ler ve satır bazlı ifadeler için hesaplanan kolonlar. Akış, hangi alanların attribute, hangilerinin measure olduğunu belirleyen bir semantics düğümüyle tamamlanır.
Ancak ABAP açısından bakıldığında Calculation View aileden biri değil, bir misafirdir. HANA repository’nin kendi yaşam döngüsünü ve yetkilendirme konseptini (analytic privileges) izler. ABAP’tan kullanmak için bir köprü gerekir. Bugün bu köprü genellikle ADBC (_SYS_BIC çalışma zamanı nesnesine karşı native SQL) ya da bir CDS table function içine sarılmış AMDP table function oluyor. Eski Dictionary External View yöntemi artık geçersiz (obsolete/deprecated) ilan edildi. Bazı senaryolarda teknik olarak hâlâ oluşturulabilse de kullanılması önerilmiyor. Native SQL kullanmak ayrıca otomatik client yönetimi gibi Open SQL kolaylıklarının artık otomatik olarak uygulanmadığı anlamına geliyor.
Dürüst cevap şu: Bu üç yöntem birbirine rakip değil, farklı ortamlar için tasarlanmış araçlar. Kısa bir karar rehberi:
Mantık tek bir programa aitse ve yeniden kullanım gündemde değilse Open SQL kullanın. En basit ve en doğrudan seçenek budur. Modern sözdizimiyle de diğerleri kadar veritabanına iş taşıyabilir.
Kullanıcı ABAP dünyasıysa ve mantık bir model olmayı hak ediyorsa CDS kullanın: programlar arasında paylaşılan, Fiori ya da analitik için annotation’larla zenginleştirilmiş, DCL ile güvence altına alınmış ve kodun geri kalanıyla birlikte taşınan bir model. S/4HANA’da stratejik varsayılan seçenek budur.
Doğrudan HANA üzerinde çalışıyorsanız (BW/BPC senaryoları, şemalar arası modeller, veritabanı seviyesinde dönüşümler) ya da grafiksel, düğüm düğüm ilerleyen geliştirme tarzı probleme gerçekten uyuyorsa Calculation View kullanın.
Peki ya performans?
Üçü de veritabanında çalıştığı için “veritabanına ne kadar yakınsa o kadar hızlı” şeklindeki eski sezgi aralarında net bir ayrım yapmaya artık yetmiyor. Aynı iş yükünde gerçekten aynı performansı gösterip göstermedikleri ise ancak ölçümle cevaplanabilecek bir soru. Bu soruyu ölçümler, trace’ler ve execution plan’larla düzgün şekilde cevaplamak için bu yazının devamı niteliğindeki çalışmayı yaptık. Kısaca söylemek gerekirse: sonuçlar, ders kitaplarındaki sıralamanın öngördüğü gibi çıkmadı.
Giriş
Üç SAP geliştiricisine HANA sisteminde veriyi nasıl okuyup toplayacaklarını sorarsanız üç farklı cevap alabilirsiniz: “Bir SELECT yaz, yeter”, “Bir CDS view oluştur” ya da “Calculation View olarak modelle”. Üç cevap da doğru ve konuyu kafa karıştırıcı yapan da bu. Her yöntem farklı bir dönemden ve SAP mimarisinin farklı bir katmanından geliyor. Her birinin kendine özgü güçlü yanları var ve ABAP tarafından her biri farklı bir şekilde kullanılıyor.
Bu yazıda üç yaklaşımı tek tek inceliyor, ardından farklarını yan yana koyuyoruz. Yazı, ölçümlere dayalı performans karşılaştırmamızın kavramsal tamamlayıcısı. Burada amacımız milisaniyeleri değil, yöntemlerin mantığını anlamak.
ABAP Open SQL: Klasik ve Güvenilir Yöntem
Open SQL (yeni sürümlerde kısaca ABAP SQL olarak geçiyor), ABAP diline gömülü SQL dilidir. ABAP programları onlarca yıldır veritabanı tablolarını bu yöntemle okuyor:
Open SQL’in en belirgin özelliği, veritabanından bağımsız çalışması ve ABAP ile derin entegrasyonudur. Aynı ifade, SAP’nin desteklediği her veritabanında değişiklik yapmadan çalışır. Bunu sağlayan ABAP çekirdeğidir: ifadeyi alttaki platformun kendi SQL diline çevirir. Bu sırada geliştiricinin hiç düşünmek zorunda kalmadığı işleri de arka planda halleder: client yönetimi (MANDT filtresini otomatik ekler), ABAP ve veritabanı tipleri arasındaki dönüşümler ve sonuçların internal table’lara verimli aktarımı.
Peki neden tercih ediliyor? Çünkü bir ABAP programından veriye ulaşmanın en kısa yolu bu. Ek bir nesne oluşturmanız, aktivasyon yapmanız ya da ayrı bir yaşam döngüsü yönetmeniz gerekmez. Sorgu, programın içinde yaşar. Modern Open SQL ayrıca epey güçlendi: güncel sürümlerde join’ler, toplama fonksiyonları, CASE ifadeleri, SELECT listesinde aritmetik işlemler, CTE’ler ve window fonksiyonları kullanılabiliyor. Bu da kapsamlı bir mantığı tek bir ifadeyle veritabanına taşıyabileceğiniz anlamına geliyor.
Sınırı da bir o kadar net: Open SQL ifadesi yeniden kullanılamaz. Mantık tek bir programın içine hapsolur. Beş farklı rapor aynı join ve toplama mantığına ihtiyaç duyuyorsa, bu mantık beş kez yazılır. Bir sonraki yöntemin çözdüğü sorun da tam olarak bu.
CDS View: ABAP Katmanında Yeniden Kullanılabilir Veri Modelleri
Core Data Services (CDS) view’lar, Eclipse’te (ABAP Development Tools) DDL kaynağı olarak tanımlanan veri modelleridir. Bir CDS view, belirli bir veri mantığını (join’ler, hesaplanan alanlar, toplamalar, association’lar) ABAP sözlüğünde adı olan, yeniden kullanılabilir ve taşınabilir bir nesne olarak tutar:
Artık her ABAP programı bu view’u tek satırlık bir SELECT ile kullanabilir ve her kullanıcı aynı, merkezi olarak yönetilen mantığa erişir. View ABAP katmanında tanımlansa da veritabanında çalışır. CDS, SAP’nin code pushdown (“kodu veriye taşı”) yaklaşımının ana aracıdır.
CDS’i neden kullanıyoruz? Birbirini güçlendiren birkaç neden var:
- Yeniden kullanılabilirlik ve tek doğruluk kaynağı. Mantık bir kez modellenir ve her yerde kullanılır. Kopyala-yapıştır SELECT’lere gerek kalmaz.
- Tam ABAP yaşam döngüsü. CDS view’lar standart transport’larla taşınır, ABAP kodunun geri kalanıyla birlikte versiyonlanır ve ABAP araçlarıyla kontrol edilir.
- Sadece sözdizimi değil, anlam da taşır. Annotation’lar view’a anlam katar: para birimleri ve ölçü birimleri, metinler, analitik meta verileri, arayüz ipuçları. Fiori Elements ve Embedded Analytics gibi framework’ler bu bilgileri doğrudan okur. Yani bir CDS view sıradan bir sorgudan ibaret değildir, tüm bir uygulama ekranını yönetebilir.
- Entegre yetkilendirme. Erişim kontrolü (DCL), view’ları ABAP yetkilendirme konseptine bağlar.
- Stratejik konum. S/4HANA’da SAP’nin sunduğu binlerce interface ve consumption view’dan oluşan Virtual Data Model (VDM) tamamen CDS üzerine kurulu. CDS, ABAP uygulamaları için önümüzdeki dönemin hedeflenen modelleme katmanı.
- Raporlamaya açılan kapı. Analitik annotation’lara sahip bir CDS view’u aktive ettiğinizde BW tarafında otomatik olarak bir transient provider oluşur. Böylece BI araçları bu view’u BW bağlantı altyapısı üzerinden kullanabilir. Alternatif olarak CDS view, SAP Gateway üzerinden OData servisi olarak da yayınlanabilir. CDS’i Fiori ve S/4HANA Embedded Analytics için veri kaynağı yapan da bu OData yolu. Calculation View’lar bu kanala doğrudan hizmet veremez.
Kısacası Open SQL ile CDS arasındaki fark, sorgunun nerede çalıştığı değil (ikisi de HANA’ya taşınır), mantığın nerede yaşadığıdır: tek bir programın içinde mi, yoksa paylaşılan ve anlam açısından zengin bir sözlük nesnesi olarak mı?
Calculation View: HANA Veritabanında Yerel Modelleme
Calculation View’lar ise madalyonun öbür yüzünden gelir. Bunlar ABAP katmanında değil, HANA Modeler’da (HANA Studio ya da yeni kurulumlarda Web IDE / Business Application Studio) oluşturulan yerel HANA nesneleridir. Geliştirici kod yazmak yerine grafiksel bir veri akışı kurar: seçim ve filtreleme için projection düğümleri, join düğümleri, union düğümleri, aggregation düğümleri, boyutsal modeller için star join’ler ve satır bazlı ifadeler için hesaplanan kolonlar. Akış, hangi alanların attribute, hangilerinin measure olduğunu belirleyen bir semantics düğümüyle tamamlanır.
CDS benzer mantığı kurabiliyorsa Calculation View’lar neden var? Çünkü çalıştıkları alan farklı:
- Veritabanı odaklı senaryolar. Calculation View’lar tamamen HANA içinde yaşar ve SQL konuşan her sistem tarafından kullanılabilir: BW ve BPC, yerel HANA uygulamaları, analitik araçlar. Bunun için bir ABAP sistemine ihtiyaç yoktur. BW/BPC ortamlarında temel yapı taşlarından biridir: Composite Provider’lar bunları kullanabilir, planlama mantığı da bunların içine taşınabilir.
- Görsel geliştirme ve hata ayıklama. Akıştaki her düğümün verisini ayrı ayrı önizleyebilirsiniz. Böylece karmaşık dönüşümleri adım adım inceleyebilirsiniz. Bu, SQL yazmaktan gerçekten farklı bir geliştirme deneyimi.
- Çalışma zamanında akıllı budama. Calculation View’lar sorgu anında gereksiz kısımları eler: kullanıcının istemediği kolonlar ve filtrenin dışarıda bıraktığı union dalları hiç çalıştırılmaz. Böylece tek bir kapsamlı view, farklı yapıdaki pek çok sorguya verimli şekilde hizmet verebilir.
- Erişilebilirlik ve doğrudan BI bağlantısı. Modelleme grafiksel olduğu için Calculation View oluşturmak, DDL yazmaya kıyasla çok daha az SQL bilgisi gerektirir. Kodun yerini düğümler ve bağlantılar alır, bu da BI odaklı modelleyiciler için giriş eşiğini düşürür. View sıradan bir veritabanı nesnesi olduğu için Power BI, Tableau, SAP BusinessObjects ya da SAP Analytics Cloud gibi raporlama araçları, araya bir ABAP sistemi girmeden HANA client’ın ODBC/JDBC sürücüleri üzerinden doğrudan bağlanabilir.
- Esnek dağıtım. Transport, ABAP transport yapısına bağlı değildir. View’lar HANA’nın kendi mekanizmalarıyla taşınabilir: HALM / delivery unit dışa ve içe aktarımı, CTS+ ya da HDI içeriği için MTA dağıtımı. ABAP ile sıkı bir bağ istendiğinde ise HTA ile ABAP transport sistemine de alınabilir.
Ancak ABAP açısından bakıldığında Calculation View aileden biri değil, bir misafirdir. HANA repository’nin kendi yaşam döngüsünü ve yetkilendirme konseptini (analytic privileges) izler. ABAP’tan kullanmak için bir köprü gerekir. Bugün bu köprü genellikle ADBC (_SYS_BIC çalışma zamanı nesnesine karşı native SQL) ya da bir CDS table function içine sarılmış AMDP table function oluyor. Eski Dictionary External View yöntemi artık geçersiz (obsolete/deprecated) ilan edildi. Bazı senaryolarda teknik olarak hâlâ oluşturulabilse de kullanılması önerilmiyor. Native SQL kullanmak ayrıca otomatik client yönetimi gibi Open SQL kolaylıklarının artık otomatik olarak uygulanmadığı anlamına geliyor.
Peki Hangisini Kullanmalısınız?
Dürüst cevap şu: Bu üç yöntem birbirine rakip değil, farklı ortamlar için tasarlanmış araçlar. Kısa bir karar rehberi:
Mantık tek bir programa aitse ve yeniden kullanım gündemde değilse Open SQL kullanın. En basit ve en doğrudan seçenek budur. Modern sözdizimiyle de diğerleri kadar veritabanına iş taşıyabilir.
Kullanıcı ABAP dünyasıysa ve mantık bir model olmayı hak ediyorsa CDS kullanın: programlar arasında paylaşılan, Fiori ya da analitik için annotation’larla zenginleştirilmiş, DCL ile güvence altına alınmış ve kodun geri kalanıyla birlikte taşınan bir model. S/4HANA’da stratejik varsayılan seçenek budur.
Doğrudan HANA üzerinde çalışıyorsanız (BW/BPC senaryoları, şemalar arası modeller, veritabanı seviyesinde dönüşümler) ya da grafiksel, düğüm düğüm ilerleyen geliştirme tarzı probleme gerçekten uyuyorsa Calculation View kullanın.
Peki ya performans?
Üçü de veritabanında çalıştığı için “veritabanına ne kadar yakınsa o kadar hızlı” şeklindeki eski sezgi aralarında net bir ayrım yapmaya artık yetmiyor. Aynı iş yükünde gerçekten aynı performansı gösterip göstermedikleri ise ancak ölçümle cevaplanabilecek bir soru. Bu soruyu ölçümler, trace’ler ve execution plan’larla düzgün şekilde cevaplamak için bu yazının devamı niteliğindeki çalışmayı yaptık. Kısaca söylemek gerekirse: sonuçlar, ders kitaplarındaki sıralamanın öngördüğü gibi çıkmadı.
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.