14 Şubat 2017 Salı

SQL Server Analysis Services 2012’de Multidimensional Model ve Tabular Model

Bu yazımızda SSAS’de Tabular model ve Multidimensional model kavramlarını inceleyip, farklarından bahsedeceğim. Veri analizi için hangi modelin hangi durumlarda daha uygun olacağını ortaya koymaya çalışacağız. Farklarından bahsetmeden önce bu modellerin ne olduğunu inceleyelim:

Multidimensional Model (geleneksel OLAP kübü):  İlişkisel bir veritabanından çok farklı yapıda olan ve çok hızlı raporlar üretmemizi sağlayan bir OLAP kübüdür. Geçmişte bu model multidimensional veritabanları oluşturabilmemiz için tek çözümdü. SQL Server 2005’den SQL Server 2016’ya kadar yapısı itibariyle çok değişmedi. SSAS’e yeni eklenen özellikler incelenirse çoğunun Tabular model’le ilgili olduğu görülür.

Tabular Model (in-memory küb): SSAS’deki in-memory veritabanıdır. SQL Server 2012’de tanıtıldı ve her yeni sürümü yeni özellikler içeriyor. Multidimensional Model’den farklı bir engine (xVelocity) kullanır. Multidimensional model satır bazlı depolama yaparken, Tabular model verileri daha çok sıkıştırabilmek için sütun bazlı depolama yapar. Veriler RAM’de saklanır. Bu nedenle sunucunuzun, analizler için yeterli RAM’e ve hızlı CPU’lara sahip olması gerekiyor. Diskler çok önemli bir etmen değildir.

Bu iki model aynı amaca sahiptir: Veri Ambarı üzerinde, son kullanıcıların veriyi keşfetmelerine olanak sağlayan yüksek performanslı yetenekleri olan bir semantic layer oluşturmak. Bu iki modelin Analysis Services’ın bir parçası olması, her iki modelin benzer olduğunu ve bir modelden diğerine kolayca geçilebileceği izlenimini verebilir. Gerçek şu ki bunlar tamamen farklı tasarım deneyimlerine ve veri mimarilerine sahip iki farklı üründür. Aynı sunucuda birlikte bulunabilirler, ancak ikisinin de kendi sql server instance’ları vardır.

Şimdi de veri analizi için önemli olan her katmanda 2 modeli karşılaştıralım:

Hardware

Birçok durum için Multidimensional model’de kullanılan donanımın Tabular model’de kullanılamayacağının açıklığa kavuşturulması önemlidir. Tabular, bellek bağımlı bir çözümdür. Daha fazla bellek, daha iyi bir performans sağlar. Yeterli belleğiniz yoksa, Tabular modeli başarısız olur. Tabular veritabanlarında CPU hızı da çok önemliyken diskler önemli bir etmen değildir.

Data Source Layer

Multidimensional model ile bağlanacağınız her veri kaynağına Tabular ile de bağlanabilirsiniz. Tek kısıtlama vardır: Tabular’da direct query modunu kullanırsanız, sadece SQL Server ilişkisel veritabanlarını kullanabilirsiniz.

Data Access Layer

Tabular model veri erişimi için 2 modu destekler:

Cached modunda, tüm veriler belleğe yüklenir ve tüm sorgulara buradan cevap verilir.

DirectQuery modunda, client uygulamalarının doğrudan veritabanı üzerinde sorgulama yapmasına izin verilir. (yalnızca SQL Server relational engine için desteklenir). Bu modun bazı sınırlamaları vardır:
  •   Sadece DAX sorgulama dilini destekler.
  •   Time calculation’ları desteklemez
  •   Calculated column’ları desteklemez.
Not: Hem Cached hem de DirectQuery modunu seçme imkanı da vardır. Bu durumda, veriler her iki storage modunda da tutulur. Bir storage modu sorguları cevaplamak için varsayılan olarak kullanılır. Connection string’de hangi storage modunu kullanmak istediğinizi belirtebilirsiniz.

Multidimensional modelde veri erişimi için 2 modu destekler:

MOLAP: Varsayılan ve en sık kullanılan depolama modudur. Bu modda, küp process edilirken, veriler veritabanından çekilir; ardından, gerekli aggregation’lar, Analysis Services içinde gerçekleştirilir ve nihayet veriler, Analysis Services sunucusunda sıkıştırılmış ve çok boyutlu bir biçimde saklanır.

ROLAP: Verileri ilişkisel veritabanından OLAP sunucusuna çekmez; hem küp detay verileri hem de hesaplanmış alanlar ilişkisel veritabanında kalır. Hesaplanmış alanları depolamak için veritabanı sunucusu ek veritabanı objeleri oluşturur. (indexed views gibi). Genellikle real-time verilere erişmek için kullanılır. ROLAP, DirectQuery moduyla karşılaştırılabilir; her ikisi de verileri saklamaz ve sorguyu cevaplamak ilişkisel veritabanlarını kullanırlar. ROLAP modu çok nadiren kullanılır, çünkü birçok durumda, yüksek miktarda veriye eriştikçe performans son kullanıcılar için yetersiz olur ve çoğu senaryoda, ilişkisel veritabanındaki verilere gerçek zamanlı erişim gerekmez.

Performans

Aşağıdaki tabloda farklı senaryolara ilişkin performans karşılaştırmaları mevcuttur:

Scenarios Multidimensional MOLAP Tabular In-Memory More Performant
Report on Low granularity data Read atomic data from disk. Read columnar data from RAM. Tabular In –Memory.
Report on aggregated data with no predefined aggregation Read atomic data from disk. Aggregate data in Memory Read columnar data from RAM. Aggregate data in Memory Tabular In –Memory.
Report on aggregated data with predefined aggregations on Cold Cache Read aggregated data from disk. Read columnar data from RAM. Aggregate data in Memory Comparable.
Report on aggregated data with predefined aggregations on Warm Cache Read aggregated data from RAM. Read columnar data from RAM. Aggregate data in Memory Multidimensional.

Data Language Layer

Multidimensional Model, MDX dilini kullanır. Bu dili öğrenmek zordur çünkü multidimensional kavramlarının kapsamlı bir şekilde anlaşılmasını gerektirir.
Tabular Model, DAX dilini kullanır. DAX ifadeleri, excel formüllerine benzer. Sorgulamalar, ilişkisel veritabanındaki sorgulamalara benzer. Bu nedenle multidimensional kavramlarının iyi bilinmesine gerek yoktur.

Data Model Layer

Hem Tabular hem de Multidimensional modelde data setler arasında ilişkiler tanımlanır. En önemli farkları; Tabular modelde tablolar arasında ilişki kurmak için yalnızca 1 sütun kullanılabilirken multidimensional modelde birden fazla sütun kullanılabilir.
Tabular projesi, geliştiriciler için daha kolay gözükür, çünkü attribute’ler arasındaki ilişkileri tanımlamanıza gerek yoktur. Bu adım, hiyerarşileri tanımlayabilmek ve böylece performansı optimize edebilmek için Multidimensional modellerde zorunludur.

Tabular modelin Multidimensional modele kıyasla sınırlamaları:
  • Role-playing dimension’lar (özellikle Tarih boyutu için kullanışlıdır) tanımlanamaz.
  • Many to many ilişkiler tanımlanamaz (aynı sonuçları elde etmek için bazı geçici çözümler var ancak çok karmaşık DAX formüllerini kullanılmak zorunda)
  • Parent-Child hiyerarşi tanımlanamaz.
  • Action tanımlanamaz.
  • Write-back desteklenmiyor.

Reporting Layer

SSAS Multidimensional modelde raporlar oluşturan her raporlama çözümü (Microsoft Excel, SQL Server Reporting Services, vb.), Tabular modeli kullanarak da aynı işlemi gerçekleştirebilir. Her ikisi de aynı connection interface’i kullanır ve MDX’i yorumlayabilir. MDX generate eden her raporlama aracı Tabular modeli de kullanabilir. Tabular model engine, MDX’i DAX’a çevirme yeteneğine sahiptir.

Multidimensional model, DAX dilini yorumlayamaz. DAX sorguları üreten bir raporlama aracı, multidimensional bir projeyi kaynak olarak kullanamaz. (Power View gibi)

Sonuç

Aşağıdaki tabloda her katmana ilişkin her iki modelin avantaj ve dezavantaj karşılaştırmaları mevcuttur:


Tabular Model Multidimensional Model
Avantaj
    • Çoğu durumda OLAP’tan daha performanslı
    • Multidimensional model’den daha kolay geliştirilir.
    • Power Pivot ile entegre
    • Çok büyük miktarda veriyi işlemek için ölçeklendirilebilir
    • Gelişmiş modelleme ve hesaplama gereksinimleriyle başa çıkabilir
Dezavantaj
    • Hala geliştirilmeye devam ediyor
    • Performansı kullanılabilir RAM ile sınırlıdır
    • MDX’de mevcut bazı gelişmiş hesaplamaları kullanamaz.
    • Power View ile kullanılamaz.
    • Bu model ile ilgili yeni sürümlerde beklenecek önemli bir yenilik yok
    • Tabular’dan daha komplekstir.

Sonuç olarak:
  • Eğer son kullanıcılar memnunsa var olan bir Multidimensional model, Tabular modele migrate edilmemeli.
  • Yüksek bir miktarda veriye sahip değilseniz veya çok kompleks iş gereksinimleriniz yoksa her yeni proje için Tabular model seçilmeli.

30 Haziran 2015 Salı

Natural Key ve Surrogate Key Nedir?

Bir tablodaki Primary Key olacak alanı seçmek database performansı için gerçekten önemlidir. Primary Key; her tabloda en fazla 1 adet bulunur, null değer alamaz, unique (tekil) değerler alır, verileri değiştirilemez. Primary key içerdiği verilere göre Natural veya Surrogate key olur.

Natural Key

Tablo ile mantıksal olarak ilişkilidir. Natural key, dış dünyadaki gerçek verileri temsil eder. Örneğin; TC kimlik numarası, bir kitabın ISBN numarası, bir ürünün ismi gibi...

Natural key, tablodaki tek bir sütun veya sütunların bileşiminden oluşur. İçerdiği veri, tablonun diğer sütunlarındaki veriler ile ilişkilidir. Tekil değerler içerir.


Surrogate Key

Surrogate key içeren veriler tablo için mantıklı herhangi bir anlama sahip değildirler. Surrogate key'ler, veritabanı yönetim sistemleri tarafından üretilirler. (Oracle, sequence'leri kullanır; Sql server, identity column özelliğini kullanır; MySql auto_increment özelliğini kullanır.) Genel olarak kayıt eklenmeden önce üretilirler ve çoğu zaman numeric tiptedirler. Tekil değerler içerir.

Natural Key vs. Surrogate Key Performans Testi

Natural Keys


     

Surrogate Keys

 


Test Sorguları

 

Sonuç:

Surrogate Key'e sahip olan tablolardan sql sorgularının sonuçları daha hızlı döndü. Çünkü, primary indexleri küçük boyutludur. Ama genel olarak database designer'lar anlamlı olduğu için natural key kullanırlar.





1 Nisan 2015 Çarşamba

[Microsoft][ODBC Excel Driver] Syntax error (missing operator) in query expression 'case when ...', Odbc driver returned an error (SQLExecDirectW).

OBIEE'e Excel'den çektiğimiz veriler ile http://localhost:7001/analytics sayfasında yeni bir analiz oluşturmak istediğimizde bu hata ile karşılaşabiliriz. Bu hata, analize eklenen bir sütun üzerindeyken Edit Formula ekranına case when ifadesi yazdığımızda ortaya çıkar. (Genellikle iç içe case ifadeleri varsa ve bu ifadeler numeric değilse ortaya çıkar.) Bunun nedeni Excel'in Case ifadelerini desteklemiyor olmasıdır.


Hatanın ayrıntılı hali:

Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred.
[nQSError: 16001] ODBC error state: 37000 code: -3100 message:
[Microsoft][ODBC Excel Driver] Syntax error (missing operator) in query expression 'CASE WHEN PRODUCT."NAME"='Bag' THEN 1 ..'
[nQSError: 16014] SQL statement preparation failed. (HY000)
SQL Issued: SELECT Product.Name saw_0, CASE WHEN PRODUCT."NAME"='Bag' THEN 1 ... END saw_1 FROM Product ORDER BY saw_0, saw_1

Hatanın çözümü şu şekildedir:
  • BI Administration da excel verilerinin bulunduğu repository açılır.
  • Physical layer'da excel verilerini tutan database üzerinde sağ tuş Properties->Features sekmesinde Query DBMS butonu tıklanır.
  • Yapılan değişikliğin analize etki etmesi için ve Subject Area'nın yeniden yüklenmesi için Oracle BI Answers'da Criteria->Subject Area bölümünde Reload Server Metadata tıklanır.
İyi Çalışmalar

29 Mart 2015 Pazar

OBIEE'de Excel Dosyasını Import Etme

Bu yazımda OBIEE Administration Tool'da Excel dosyasını veri kaynağı olarak kullanmayı anlatacağım. Bunun için aşağıdaki adımlar sırasıyla gerçekleştirilir:

  1. İlk önce veri kaynağı olarak eklemek istediğimiz excel dosyası açılır. Ekleyeceğimiz veriler Excel'in Aralığı Adlandır özelliğiyle isimlendirilir.

     
     
  2. Denetim Masası->Yönetimsel Araçlar->Data Sources (ODBC)->System DSN tabında Add butonuna tıklanır ve veri kaynağı olarak Microsoft Excel Driver seçilir.



    Veri kaynağı isimlendirilir ve Çalışma Kitabı Seç butonuna tıklanır.



    Excel dosyası seçilir.


  3. OBI Administration Tool açılır ve Physical Layer'da sağ tuş ile yeni bir database eklenir.



    Connection Pools sekmesine tıklanarak yeni bir bağlantı eklenir. Data Source Name'de eklenen excel veri kaynağı seçilir.



    Database ve connection pool oluşturulduktan sonra Physical Layer'da connection pool üzerinde sağ tuş Import Metadata'ya tıklanır. Gelen ekranda Excel veri kaynağı seçilir.





    Physical Layer'da yeni eklenen database seçilerek excel dosyası import edilir.



    Finish'e tıklanarak import işlemi tamamlanır.

    İyi Çalışmalar

27 Mart 2015 Cuma

nQSError: 37005 Transnational Update Failed Hatası

Çözümü gerçekten basit olan fakat OBI'da başlangıç düzeyinde olanlar için görüldüğünde sinir bozan bir hata:) Genellikle OBIEE Administration Tool'da online mode da iken physical layer'a database ekleyip kaydettiğimizde bu hata karşımıza çıkar. Hatanın kaynağı tablo isimleri olabilir. (Benim karşılaştıklarım öyleydi.)

  • C:\Middleware\instances\instance1\diagnostics\logs\OracleBIServerComponent\coreapplication_obis1 yolunda bulunan NQServer.log dosyasında "has name with leading or trailing space(s)." adındaki hata bulunur. Bu hataya neden olan database içindeki tablo ve sütun ismi log dosyasında yazılıdır. O sütun ismi düzeltildikten sonra bu hatayla bir daha karşılaşmayız. ( Yani  öyle umuyorum:) )
İyi Çalışmalar