2 Eylül 2023 Cumartesi

Microsoft Fabric ile Veri ve Analitik Teknolojilerin İdeal Entegrasyonu

Microsoft'un en başarılı bulduğum yanlarından biri de, son derece karmaşık teknolojiler için bile kullanıcı dostu ürünler çıkarma konusunda hassas ve yetenekli olması. 

Mayıs 2023 ile önizlemesi duyurulan Microsoft Fabric bu başarının en güncel örnekleri arasında yerini aldı. Şu günlerde henüz "public preview" aşamasında olan Fabric hakkında bir şeyler söylemeden bekleyemeyeceğim.

Elbette her sistem iyileştirilebilir. Ancak bu haliyle bile Microsoft, Fabric ile bulut tabanlı veri ve analitik teknolojileri birleştirme konusunda ideal bir yol bulmuşa benziyor.

Nedir Bu Microsoft Fabric?

Fabric tanımından önce Lakehouse kavramı hakkında biraz konuşmakta fayda var.

Verilerin bilgisayarlarda depolanmayı başladığı ilk günden bugüne çok fazla şeyle tanıştık. Verinin hızı, türü, büyüklüğü şaşırtıcı derecede değişti, değişmeye devam ediyor. Bu değişime ayak uydurulabilmesi için zamanla bir çok araç ve teknik öne sürüldü. Bunlardan sadece konumuzla doğrudan ilişkili olan veri yönetimi mimarilerine dikkat çekmek istiyorum. 

1970 sonrasında biriken verilerin efektif şekilde analiz edilebilmesi için veri ambarı (Data Warehouse) konseptine odaklandık. Bu alanda ortaya atılan prensipler zamanla olgunlaştı ve Inmon, Kimball metodolojileri olarak bilinir hale geldi. Veri Ambarları uzun zamandır İş Zekası olarak isimlendirdiğimiz ağırlıklı olarak yapısal verinin işlendiği ve raporlandığı önemli bir çalışma alanının bel kemiği haline geldi.

2010 sonrasında verideki değişim kendini iyiden iyiye hissettirmeye başladı. Özellikle 2004'te duyurusu yapılan ve internetin ikinci evresini ifade eden, kullanıcıların da katkı sağlayacak pozisyona gelmesine olanak tanıyan Web 2.0 kavramı meyvelerini verdi. Giderek yaygınlaşan sosyal medya platformları, youtube, wikiler, çevrimiçi iş birliği araçları, akıllı cihazların uygulamaları, dijital fotoğrafçılık vs. derken veri çeşitliliği ve hızı arttı. Artık yapısal verilerle birlikte yapısal olmayan verilerin de işlenmesine ihtiyaç duyulur oldu. Değişimin hızlanmaya başladığı böyle bir dünyada NoSQL veritabanlarının yanı sıra verilerin daha çok depolama aygıtlarında en ham haliyle depolanması tercih edilir oldu. Bu çeşitlilik ve hız veriambarı tasarımları için de alternatif çözümler aramamıza ve zamanla Data Vault gibi çevik tasarım prensiplerinin doğmasına sebep oldu. Bütün bunlarla birlikte rekabette avantaj sağlanabilmesi için olayların iç yüzünü anlamada önemli imkanlar sunan veri bilimi ve makine öğrenimi çalışmalarına da ihtiyaç arttı. Bu gidişat veri gölü (Data Lake) konseptinin doğmasına sebep oldu.

2020'lerde bu iki mimarinin en iyi özelliklerini birleştirmeyi amaçlayan Data Lakehouse mimarisi hakkında konuşur olduk. Çünkü günümüzde neredeyse tüm şirketler rekabette avantaj sağlayabilmek için her türden veriyi sürekli analiz etmek, geçmiş ve gelecek hakkında fikir edinmek zorunda kaldı. 

Lakehouse mimarisine göre çalışan bir platformun anahtar özellikleri şunlardır:

  • Transaction desteği
  • Schema zorunluluğu desteği
  • BI desteği
  • Açık kaynak depolama yöntemlerine destek
  • Depolamanın bilgi işlemden ayrı olması desteği
  • Aynı veri deposunu kullanan farklı iş yüklerinin (DS, ML, SQL vs.) desteklenmesi
  • Uçtan uca akan veri analizine destek
Kuruluşlar lakehouse mimarisine uygun çalışan araçlara her geçen gün daha fazla ihtiyaç duymaktadır. her türden verinin işlenmesi için gerekli olan bu mimarinin hayata geçirilmesinin en yorucu yanı farklı sağlayıcıların ürünlerini birleştirmek olsa gerek.

Microsoft Fabric temelde, OneLake isimli ölçeklenebilir depolama katmanının üzerine inşa edilen ve büyük veri işleme için Apache Spark ve SQL işlem altyapılarını kullanan bir Lakehouse'dur.

Microsoft Fabric, öne çıkan bulut tabanlı veri ve analitik teknolojileri kullanıcı dostu bir bakış açısı ile bir araya getiren yepyeni bir SaaS (Software as a Service) hizmetidir. Amacı veri gölünden raporlamaya kadar geçen tüm süreçler için çözümler sunmaktır.


Microsoft Fabric, veri entegrasyonu, veri depolama, veri mühendisliği, veri bilimi, gerçek zamanlı veri işleme ve iş zekasını kapsayan bulut tabanlı ürünlerle entegre çalışır. Verinin demokratikleştirilmesini, yani her uzmanın veri ile hedeflenen amaca başarıyla ulaşılabilmesi için gerekli araçları ve çalışma ortamını sağlar. 

Synapse Analtics de benzer bir tanıma sahip ancak Microsoft Fabric'te her şey daha derli toplu hale gelmiş ve tüm teknik karmaşa göz önünden kaldırılmış. 

Fabric tüm araçları kullanıcıyı yormadan veri seviyesinde derin bir entegrasyonla ve Power BI benzeri bir arayüz ile sunuyor.

Daha açık konuşmak gerekirse; Microsoft Fabric tüm verilerin OneLake üzerinde depolandığı, SQL ve Spark motorları ile verinin veri seviyesinde bir iş birliği ile işlenebildiği, orkestrasyon ve ETL için Data Factory arayüzlerinin kullanılabildiği, son kullanıcının Power BI'dan alışık olduğu bir arayüzde rapor geliştirebildiği ve internetin olduğu her yerden erişebilen bir SaaS platformu sunuyor.

Konuyu biraz daha açarsak; Microsoft Fabric şu deneyimleri sunmaktadır:
  • OneLake: 
    • OneLake olarak isimlendirilen depolama katmanı OneDrive benzeri bir mantıkla çalışır. Bu depolama katmanı Fabric bileşenleri tarafından ortak şekilde kullanılır. Dosya tabanlı veriler, SQL-Spark tabloları, Power BI Datasetleri vs. Bu şekilde tüm bileşenler kullanıcıyı bir karmaşa ile muhatap etmeden bir birileriyle derin bir iletişimde halinde tutar. 
    • OneDrive uygulamasına benzer şekilde, OneLake File Explorer aracı çalışma alanındaki dosyaları server ile eşleştirilebilir.
    • Tabloların SQL ve Spark tarafından ortak kullanılabilmesi için Delta tablo yapısının tercih edildiğini belirtelim. Bu noktada Synapse ile ilgili yazımızda ele aldığımız Shared Metadata özelliğinin Fabric'te biraz daha geliştirildiğini deneyimliyoruz. 
    • Ayrıca OneLake'in veri yapıları için kısa yollar oluşturma imkanı da bulunmaktadır. Bu özellik önemli bir efor olan veri taşıma ihtiyacını da ortadan kaldırmış durumda.
  • Power BI: 
    • Fabric Power Platform benzeri bir SaaS uygulaması olarak duyuruldu. Power BI Fabric'in reklam yüzü durumunda. Power BI lisanslarıyla da sıkı bir ilişkiye sahip. Power BI'da oluğu gibi ve Power BI ile entegre olan bir çalışma alanı açıp Fabric bileşenlerini deneyimlemeye başlıyoruz. 
    • Ancak burada Fabric'i Power BI'ın bir üst versiyonu gibi algılamamak lazım. Fabric olsa olsa Synapse'in bir üst versiyonu olarak değerlendirilebilir. 
    • Verinin demokratikleştirilmesi iddiasının altını dolduran şey son kullanıcının aşina olduğu Power BI'ın  öğrenim eğrisi bir hayli dik olabilen araçların önünde her an kullanıma hazır şekilde devrede olması.
  • Data Factory: 
    • Azure Data Factory'in tüm yetenekleri desteklenmese de veri taşıma, dönüştürme ve orkestrasyon için yeterli beceriye sahip bir bileşen. 
    • Üstelik DataFlow Gen2 ismiyle duyurulan Power BI kullanıcılarının aşina olduğu Power Query benzeri (tüm fonksiyonalite desteklenmiyor) bir arayüze sahip ve M dili ile verinin dönüştürülmesi konusunda müthiş bir esneklik sunuyor.
  • Data Engineering: 
    • LakeHouse oluşturma noktasında dosya tabanlı veriler ile Spark kullanarak çalışabilirsiniz. Dilerseniz bir Delta tablo inşa edip Shared Metada özelliği sayesinde hem Spark SQL ile hem de SQL Endpoint'i oluşturup Synapse DW olarak isimlendirilen SQL engine ile bu tablo üzerinde çalışabilirsiniz. 
    • Delta tablolar parquet tabanlıdır. Yani kolon bazlı bir depolama mantığına dayalıdır. Parquet formatı verimliliği sebebi ile Büyük Veri dünyasında sıkça tercih edilir. Delta formatı ise parquet formatını ilişkisel veritabanı tabloları gibi kullanmamızı sağlıyor. Yani özetle transaction desteği olan, güncellenebilir tablo formuna sokuyor. Sonuç olarak bir veri gölünde veri dosyası depolama esnekliği ve ilişkisel veritabanı sisteminin birçok avantajını sunan analitik bir veri deposu konforuna ulaşıyoruz.
    • Delta isimli bu açık kaynak dosya formatı (disk yönetim biçimi) şuan konuyu saptırmasın diye girmek istemediğim bazı sebeplerden dolayı son zamanlarda sıkça tercih edilmektedir. Microsoft Fabric kullanırken deneyimleyeceğiniz bazı optimizasyonlar sayesinde bu dosya formatı yüksek yazma ve okuma performansı sunuyor (%50'ye varan). 
    • SQL Enpoint oluştuğunda otomatik olarak bir Power BI Dataset de tanımlanıyor (Kendiniz de bunu tanımlayabilirsiniz). Bu Dataset V-Order gibi sıkıştırma ve segment eleme mantığında çalışan bazı özellikler sayesinde InMemory bir dataset gibi çalışmanızı üstelik refresh yapmanıza da gerek kalmadan tabloların son halini yüksek hızda raporlamanızı mümkün kılıyor. 
    • Bütün bu özelliklerle birlikte bu bölümde veri entegrasyonuna ihtiyaç duyulacağı için Data Factory yeteneklerine erişilebilsin diye bir kısa yol da konmuş durumda.
  • Data Science: 
    • Bu bölüm Spark ve Azure ML üzerinde çalışarak makine öğrenimi modelleri eğitmenize olanak tanıyor. 
    • Açık kaynak MLFlow kütüphanesi desteğiyle hem ML süreçlerini Spark üzerinde daha iyi yönetebilir hem de Spark ve Azure ML iş birliğinden faydalanabilirsiniz.
  • Data Warehouse: 
    • Synapse Data Warehouse olarak isimlendirilen bu ürün MPP mimarisine sahip (yani özetle büyük veri işlemek için işlemcileri dağıtık mimariye benzer mantıkta paralel kullanan) SQL engine hizmetine odaklanıyoruz. Dilerseniz Lakehouse tarafında oluşturduğunuz SQL Enpointlerini de buradaki pencereye ekleyip SQL ile sorgulayabilirsiniz. 
    • Buradaki tablolar için varsayılan bir tabular Power BI modeli otomatik olarak inşa ediliyor. Modelde hangi tabloların olacağını, DAX formullerini vs. belirleyebiliyorsunuz. Ayrıca bölümde model üzerinden bir rapor yapmanız için gerekli kısa yollara ulaşabilirsiniz. 
    • Yine bu bölüme de Data Factory yeteneklerine erişim imkanı konmuş durumda.
  • Real-Time Analytics: 
    • Gerçek zaman veri akışının yönetilebilmesi için en temelde bir tür veri tabanı ve akışı analiz etmek için bir dile ihtiyaç var. 
    • Bu bölüm Büyük hacimli verileri gerçek zamanlı olarak sorgulamak ve analiz etmek için KQL (Kusto Query Language) veritabanı oluşturmanıza ve KQL dili ile çalışmanıza imkan veriyor. Tablo ve sutun kullanımı, syntax olmasa da mantık bakımından SQL diline benzer bir deneyim sunması akan veri analizini bir hayli kolaylaştırıyor.
    • Ayrıca EventStream özelliği ile kod yazmadan kaynak ve hedef belirleyerek bir akışı gerçek zamanlı analiz edebiliyorsunuz.

Nasıl Kullanabilirim, Lisanslama Modelleri Neler?


Microsoft Fabric için bireysel ve kuruluş lisansları bulunuyor.

Kuruluş Lisansları:
  • Kullanıcı Başına Premium (PPU)
  • Kapasite
Bireysel Lisanslar:
  • Ücretsiz
  • Pro
Bu alanda bir makalelik daha konu çıkacağı ve zamanla güncelliğini yitirebileceği için doğrudan Microsoft kaynaklarına bakmanızı öneririm. 

Lisanslama için şu linke bir göz atabilirsiniz:

Microsoft Fabric şu aralar public preview aşamasında olduğu için aşağıdaki linkten ücretsiz olarak deneyebilirsiniz:

Gerekli lisansa sahip olduktan sonra Microsoft Fabric'i aşağıdaki linkinden deneyimlemeye başlayabilirsiniz:

Peki ya Synapse Analytics?


Microsoft Fabric hakkında konuşurken bir çok ifadenin Synapse ile benzer olduğunu fark etmişsinizdir. Fabric, Synapse'in bir üst versiyonu olarak değerlendirilebilir. Synapse bir PaaS çözümü, Fabric ise bir SaaS çözümü olarak karşımıza çıkıyor. Bu bile Fabric tarafında kullanıcı konforunun ön planda olduğunun/olacağının bir alameti farikasıdır. 

Synapse'teki bileşenlerin entegrasyonu sırasında dikkat edilmesi gereken teknik detaylar Fabric'te kullanıcıya yansıtılmamış. Bu haliyle Fabric tam bir Lakehouse mimarisi deneyimi yaşatıyor diyebiliriz. Synapse bileşenlerinin entegrasyonu arayüz seviyesindeyken Fabric üzerinde daha derinlerde veri seviyesinde bir entegrasyon görüyoruz. Üstelik tam anlamıyla uçtan uça bir akış motivasyonu sunulmuş. Veri kümeleri bir sonraki adım için otomatik olarak hazır ediliyor.

Synapse'teki bazı özelliklerden feragat edildi. Bazı yeni özellikler geldi. Mevcut özelliklerin de bazıları daha hızlı, verimli ve esnek şekilde kullanıma sunuldu.

Synapse Analytics uzun bir süre daha var olmaya devam edeceğini düşünüyorum.  Fakat Microsoft'un Fabric tarafına odaklanacağı aşikar.

Genel İntiba


Microsoft Fabric her ne kadar Power BI görünümü ile son kullanıcıyı teşvik etse de arkaplanda koşturan Büyük Veri işleme canavarlarıyla birlikte düşünüldüğünde buz dağını andırıyor. 

Veri Mühendisleri, Veri Bilimcileri ve Veri Analistlerinin iş birliği için yoğun mesai harcadığı, yaygın kullanıma sahip araçlar kullanıcı dostu yeni halleriyle Microsoft Fabric çatısı altında bir arada.

25 Temmuz 2023 Salı

2023-2024 Dönemiyle Birlikte Art Arda 8 Defa Data Platform Alanında En Değerli Profesyonel (MVP) Ödülü!

MVP (Most Valuable Professional) - En Değerli Profesyonel ödülü Microsoft tarafından her yıl yeniden değerlendirme sonucu dünya çapındaki bir kaç bin teknoloji öncüsüne sunulmaktadır. 

Ülkemizde de bu ödüle layık görülen sınırlı sayıda profesyonel, farklı branşlardaki aktiviteleri ile çevresine ışık saçıyor.

2023-2024 dönemiyle birlikte art arda 8 defa Data Platform alanında MVP ödülüne layık görülmekten mutluluk duyuyorum. 

Uzakta sandığımız fakat hayatın kenarında, hatta tam da ortasında olan gerçeklerle yüzleşmenin verdiği acıları her nefesimde hissettiğim şu günlerde bana destek olan tüm yakınlarıma minnettarım. 

Bununla birlikte duygularıma duyarsız kalmayıp ilgi gösteren Microsoft ekibinden Rie Merritt ve Cristina Gonzalez Herrero'ya özellikle teşekkür ediyorum.


Hayatım boyunca yerli ve yabancı kurumsal firmalara götürdüğümüz hizmetlerle gelişen saha tecrübelerimi, kitabi bilgileri ve merakımı cezbeden en güncel teknik ve teknolojik kazanımlarımı, kendini geliştirmek isteyenlerle paylaşmayı üzerime bir borç bildim. 

Bu paylaşımlardan bir çok kişinin istifade ettiğini görmek, bilmek ve özellikle geri dönüşlerini dinlemek beni mutlu ediyor.

Geçen seneki aktivitelerin bir kısmına Microsoft MVP profilimden erişebilirsiniz:

Abdullah KİSE (microsoft.com)

Eğer sizler de İş Zekası, Veritabanı Yönetimi, Büyük Veri, Yapay Zeka, Makine Öğrenimi gibi veri ve analitik konularıyla ilgiliyseniz, bağlantıda kalalım.

Bilgi paylaştıkça artar!

18 Mart 2023 Cumartesi

Azure ML Üzerinde Python ile Makine Öğrenimi Serisi (Playlist)

Azure ML üzerinde Python ile Makine Öğrenimi konusunda nazik ama etkili bir seri oldu.

Keyifli seyriler.

Serideki Bölümler:

Azure ML üzerinde AutoML ile Makine Öğrenimi (Video)


https://youtu.be/YEHgEjrd6Js?list=PLHIuoJ0S5ae6L6etfBO6r62iMuwPHY8nh

Azure ML ile ilgili Makale:

https://www.devcosci.com.tr/Blog/BlogPost/Veri-Bilimcileri-Azure-Machine-Learning-ile-Artik-Daha-Uretken-ve-Daha-Guclu

1 Şubat 2023 Çarşamba

Veri Bilimcileri Azure Machine Learning ile Artık Daha Üretken ve Daha Güçlü

Azure Machine Learning, MLOps ve Microservice yaklaşımlarına uygun bir çalışma ortamı sunan ismiyle müsemma bir bulut hizmetidir. Azure üzerindeki farklı hizmetlerle ve Github ile entegre çalışarak Makine Öğrenimi projelerini kurumsal ölçekte, yüksek kalitede, değişen tüketim taleplerine cevap verecek esneklikte, istenirse otonom olarak, sürekli geliştirmeye ve iyileştirmeye açık olacak şekilde sürdürme imkanı verir.

Bu yazımızda kurumsal ölçekteki Makine Öğrenimi projelerinde dikkat edilmesi gereken bir kaç noktaya, Azure Machine Learning hizmetine ait bileşenlere ve bu hizmetin öne çıkan yeteneklerine odaklanalım istiyorum.

Uzun soluklu Makine Öğrenimi projeleri geliştirmeye niyetlenmeden önce bazı kavram ve metodolojiler hakkında bilgi sahibi olmak ve bu bilginin uygulanabilmesi için gerekli ortamı ve araçları hazır etmek gerekir. 

Kurumsal ölçekte başarılı bir Makine Öğrenimi projesi yürütmek için İstatistiksel tekniklerin ve matematiksel algoritmaların arka planında neler olup bittiğinin derinlemesine biliniyor olması açıkçası önem sırası bakımından pek de üst sıralarda sayılmaz.

Bazılarının bu cümleyle irkildiğini tahmin edebiliyorum. Hemen bu noktada küçük bir savunma yapayım; Bir Matematikçi olarak böyle bir cümleyi kurmak benim için de kolay değil. Lakin proje bütününe ve günümüzdeki araçların geldiği noktaya baktığımızda buna hak vermemek elde değil. 

Burada akademik bilginin önemsiz olduğunu ifade etmiyorum. Makine Öğrenimi konusundaki esaslara hakim olmak zaten gerekli. Bununla birlikte derinlemesine bir akademik bilgi sadece nadir noktalarda etkili sonuçlar elde etmemizi sağlayan avantajlar doğuruyor. Ancak bu avantajlara kavuşmak bir hayli maliyetli olabiliyor. Artık alet işler el övünür dönemindeyiz.

Bir Makine Öğrenimi projesinin hayata geçirilmesinin 12 ay sürdüğünü varsayalım. Bu sürenin yaklaşık 3 ayı model seçme, eğitme ve optimize etmeyle geçer. Üstelik bu süre zarfında en çok kullanılan teknik deneme yanılmadır. Geri kalan sürede kabaca verinin hazır edilmesi, eğitilmiş modelin yayınlanması, sahadaki yansımasının izlenmesi, sürekli iyileştirme ve geliştirme için gerekli otomasyonların kurulması, değişen talep yoğunluğuna cevap verecek dinamik bir alt yapının inşa edilmesi gibi konulara odaklanılır.

Bu sebeple başarılı Makine Öğrenimi projelerini hayata geçirebilmek için CRISP-DM gibi veri bilimi yaşam döngülerini yönetme konusunda kabul görmüş bazı metodolojilere ve özetle iş birliğini, sürdürebilirliği baz alan MLOps kavramına hakim olmak ve elbette bu bilgileri projelerimize uygulayabilecek araçlara sahip olmak gerekir.

İşte tam da bu noktada Azure ML hizmeti karşımıza çıkıyor ve bize başarılı bir uygulama sahası sunuyor.

Bu bulut hizmetinin Makine Öğrenimi projelerinde işlerimizi nasıl da kolaylaştırabileceğine hizmetin bileşenlerini incelerken değinelim.

Azure ML Bileşenleri Neler?

Azure ML hizmetini aktif ettiğimizde her şeyi kapsayan bir Workspace oluşur. Çalışma ortamı içerisindeki bileşenleri yönetmek için Azure Machine Learning Studio ortamına geçiş yaparız.


Soldaki menüde yer alan gruplamaya sadık kalarak Azure ML hizmetinin bileşenlerini ve özelliklerini inceleyelim.

Authoring Bölümü 

Bu bölüm geliştirme odaklı yardımcılara ayrılmış durumda. Kod, arayüz veya sihirbaz yardımıyla geliştirmeye başlayabilirsiniz.

Notebooks: Bu bölümde herhangi bir dildeki scriptlerinizi depolayabilir ve çalıştırabilirsiniz. Eğer tüm makine öğrenimi sürecini scriptlerle yönetmek istiyorsanız ve scrtipleri çalıştırmak için bir makine yatırımı yapmamışsanız, bu bölümü kullanabilirsiniz. 

Notebook, VSCode, RStudio, Terminal vs. gibi uygulamalar ile düzenleyebildiğimiz scriptleri  AzureML Spark Compute (şimdilerde preview durumda) üzerinde çalıştırabilirsiniz. Dilerseniz ihtiyaçlarınıza cevap verebilecek kapasitede yeni bir Compute Instance oluşturup ek uygulamalar yükleyerek (Docker Image yardımıyla) compute içeriğini zenginleştirebilirsiniz.

Automated ML: Makine öğrenimi sürecinde problem tipi belirlendikten sonra verinin hazırlanması Feature Engineering, Feature Selection gibi çalışmalarla kullanışlı hale getirilmesi ve ardından Train, Validation, Test olarak bölümlendirilmesi gerekir. Sonrasında sahadaki ihtiyaca ve maliyetlere göre tahmin başarısını ölçebileceğimiz bir hedef metrik belirlenmesi, ardından bu hedefe uygun çıktının elde edilebilmesi için Makine Öğrenimi algoritmalarının veriye uygulanması ve sonrasında algoritmaların hyperparameterlerinin optimize edilmesi gerekir. Bu süreç her ne kadar uzman görüşü ile yönetilse de çoğunlukla deneme yanılma şeklinde ilerler.

İşte bu noktada orta seviye veri bilimcilerinin görevini üstlenebilecek, ileri seviye veri bilimcilerinin de işlerini kolaylaştıracak olan Automated ML Job sihirbazını devreye alabilirsiniz. Adım adım hedef ve kısıtlarınızı belirtip model eğitme denemelerini tetikleyebilir, sonrasında her deneme hakkında detaylı bilgiye, değerlendirmeye ve eğitilmiş modele ulaşabilirsiniz.

Designer: Satır satır kod yazmak uzun vadede iyi bir seçenek olsa da kısa vadede çıktı üretmek için ara yüzleri kullanmak daha cazip olabilmektedir. Bazen kod karmaşasına boğulmadan hızlıca bir sonucu ulaşmayı arzularız. Belki iyi bilinen, belki fazla yatırım yapmak istemediğimiz bir problemi çözmek, bir prototip geliştirmek veya sadece keşif amaçlı bir makine öğrenimi çalışması yapmak isteyebiliriz. 

Bu bölümde önceden hazırlanmış bazı işlevsel kutucukları sürükle bırak ile bir birine bağlayabilir bir iş akışı oluşturabiliriz. 


Designer menüsündeki Classic prebuilt tabında veri hazırlama, model geliştirme ve modelin web service olarak yayınlanması gibi bir çok konuda hazır işlevler mevcut. Şimdilerde artık Custom tabı ile kendi işlevsel kutucuklarımızı (Component) hazırlayabilme ve özel akışlar oluşturma imkanına da kavuşmuş durumdayız.

Assets Bölümü

Makine Öğrenimi nesneleri ve projelerin sağlıklı şekilde yürütülebilmesi için gerekli olan nesneleri ilgili alt bölümlerde kaydedebilir, versiyonlayabilir daha sonra ulaşıp kullanabiliriz.

Data: Azure ML hizmeti veri depolanabilecek diğer Azure hizmetlerine (Blob Storage, Azure SQL vs.)  ait bağlantıyı Datastore adıyla kullanıma sunmaktadır. Datastore üzerinden veri kaynaklarına erişebilirsiniz. Ek olarak verilerinizi Tablo, File veya Folder şeklinde Azure ML hizmetine kaydedebilir verideki değişimi takip etmenizi sağlayacak Data Drift Detector tanımlayabilirsiniz.

Jobs: Daha önce bu menünün olduğu yerde Experiment mevcuttu. Sanırım odaklanma daha kolay olsun diye artık direk jobları ana menü olarak görmekteyiz.

Normalde bir Experiment oluşturulur ve tüm çalışabilecek şeyler (Script, AutoML, Hyperdrive, Pipeline vs) bu Experiment'a gönderilir (Submit). Bu çalışmalar bir job nesnesi olarak görüntülenebilir. Hatta bu jobların çalışma esnasındaki (run) hallerini de ayrı bir nesne olarak ele alabiliriz.

Jobların çalışma sırasındaki ve sonrasındaki durumu, ortaya çıkan nesneler, metrikler ve bir takım değerlendirmeler anlık olarak takip edilebilir.

Components: Designer bölümündeki Custom tabında kullanabileceğiniz özel işlevlerinizi buraya kaydedebilirsiniz. Component oluşturmak için Python SDK v2 veya Azure ML CLI v2 kullanmanız gerekli. Componentleri bir yapboz parçası gibi tekrar tekrar farklı akışlar içerisinde kullanabilmek oldukça işlevsel.

Pipelines: Veri temizliği, model eğitme, scorelama gibi bağımsız ve anlamlı iş akışlarınızı Designer bölümünde arayüzle veya scriptlerle oluşturup bu bölüme kaydedebilirsiniz. İş akışlarını daha sonra bir tetikleyici (Schedule, Alert, REST API vs.) ile tetikleyebilirsiniz.

Environments: Çalışan her şey için bir compute gücü gerekiyor. Bu compute üzerinde hangi işletim sisteminin kullanılacağı, hangi ayarların yapılacağı, hangi scriptlerin çalıştırılacağı, hangi uygulamaların ve paketlerin kurulu olacağı belirlenebilmektedir. Bu şekilde çalışacak şeyler için gerekli olan Docker imageın nasıl inşa edileceğini tarif etmiş oluyoruz.

Scriptlerin, Jobların ve web servicein çalıştırılacağı ortamın tarif edilebilmesi için Dockerfile ve Conda Specification dosyaları (yaml formatında tanımlar içerir) kullanılır. İşte bu tarif Environments nesnesi olarak kaydedilebilir.

Bazı Environmentlar Microsoft tarafından önceden kaydedilmiş olsa da zamanla yenilerine ihtiyaç duyarız.

Models: Eğitilen makine öğrenimi modellerinin kaydedildiği bölümdür. Modelleri versiyonlayabilir, model hakkında metadata depolayabilir, dilediğinizde modeli bilgisayarınıza indirebilirsiniz.

Endpoints: Makine öğrenimi çalışmaları sonucunda elde edilen modellerin başarısından eminseniz artık modeli kullanıma açmak isteyebilirsiniz. Modeli son kullanıcıya ulaştırmak için bir web service inşa etmek en yaygın yöntemdir. Bu web servicee gelen isteğin nasıl tahminleceğini (Score) ifade eden bir script dosyasına ve bu dosyanın çalışacağı ortamı belirtmek için bir Environment nesnesine ihtiyaç duymaktayız.

Genel olarak iki farklı tahminleme ihtiyacı ile karşılaşıyoruz; 

İlki muhtemelen bir satırlık küçük bir veri ile yapılan tahminlemedir. Mesela acil servise gelen bir hasta hakkında bir kaç kolonluk özet bilgi ile kalp krizi geçirme ihtimalini tahmin etmek isteyebilirsiniz. Bu çıkarımsal çalışmaya Real-Time Inference denir. 

İkincisi daha fazla satırla yani yığın halindeki veri ile yapılan tahminlemedir. Mesela günlük veya haftalık hasta kayıtlarına bakılarak bir segmentasyon yapmak veya bu hastaların şeker hastası olma ihtimalini tahmin etmeye çalışmak isteyebilirsiniz. Bu çıkarımsal çalışmaya Batch Inference denir.

Batch Inference yığın halindeki veri ile yapıldığı için daha büyük bir compute gücüne ihtiyaç duyulur. Muhtemelen bu iş için eğitimde kullandığınız bir clusteri tercih etmek istersiniz.

Real-Time inference için Container Instance (Test amaçlı), Azure Kubernetes Service veya Managed seçenekleri sunulur. Son kullanıcının talep yoğunluğunu yönetebilmek için otomatik veya elle ölçeklendirme ve trafiğin yeni modelle eski model arasında paylaştırılması gibi yeteneklere yer verilmiştir.

Manage Bölümü

Bu bölümde çalışacak her şeyin arkasında yer alan makine gücünü yani Computeleri oluşturup yöntebiliyor, Azure ML hizmetinin bağlanabileceği hizmetleri belirtiyor, bir resim ve metin etiketleme projesi geliştirebiliyoruz.

Compute: Bu bölümde scriptleriniz, joblarınız ve web serviceleriniz için gerekli olan işlemci gücünü yönetebilirsiniz. 

Notebook veya scriptlerinizi çalıştırmak gibi bir nedenden dolayı tek bir makineye ihtiyaç duyduğunuzda Compute Instance oluşturabilirsiniz.

Model eğitmek veya Batch Inference gibi yoğun işlemler için yatay ölçeklendirme ihtiyacı doğmaktadır. Bu ihtiyaca cevap vermek için Compute Cluster oluşturabilirsiniz.

Real-Time inference için bir web service yayınlanır. Bu web service hizmetinin ihtiyaç halinde ölçeklenebilmesi için Kubernetes Cluster oluşturabilirsiniz.

Eğer daha önce Azure üzerinde bir HDInsight cluster, Sanal Makine veya Databricks cluster oluşturmuş iseniz bu gücü Attach Compute bölümündeki tanımlama ile Azure ML için de kullanabilirsiniz.

Linked Services: Azure ML çalışma ortamının erişebileceği diğer Azure hizmetleri burada tanımlanabilir. Mesela Synapse Analytics hizmetini Azure ML'e entegre edebilirsiniz.

Data Labeling: Resim ve metin işleme çalışmalarında en çok zaman alan aşamalardan herhalde en uzunu etiketleme aşamasıdır. Bu bölüm birden fazla kişinin etiketleme projesi yürütebilmesi için ideal bir çalışma ortamı sunmaktadır. Ayrıca bazı ek yeteneklerle bu tarz projelerin konforu her geçen gün artmaktadır.

Dahası var mı?

Azure ML hizmeti diğer bazı Azure hizmetlerinden de destek alır. Bunların bazıları; Docker imagelarının kaydedilmesi için Container Registry, test amaçlı container hizmeti için Container Instance, monitorlemek için Application Insight, logların kaydedilmesi için Azure Blob Storage, şifre ve sertifikaların depolanması için Key Vault, sürekli entegrasyon ve sürekli geliştirme süreçlerinin kurulması için GitHubs ve Azure DevOps hizmetleridir. 

Ayrıca Spark tarafında yaygın şekilde kullanılan MLFlow gibi makine öğrenimi yaşam döngüsünü yönetmeyi sağlayan açık kaynak platformları da destekleyip Spark ML ile Azure ML arasında doğal bir entegrasyonu da mümkün kılar.

Azure ML Bileşenlerini Nasıl Kullanabilirim?

Azure ML hizmetini Azure ML Studio ile büyük oranda kullanabilirsiniz. Fakat tüm yeteneklerin kilidini açmak için Azure ML SDK'lar ile çalışmanızı gerekir. 

Azure ML SDK'larla ilgili bir değişimin olduğu dönemdeyiz. Bu serüven hakkında kısa bir bilgi vereyim.

Azure ML bileşenlerini scriptler ile yönetmek için Python SDK, Azure CLI veya R SDK kullanıyorduk. R SDK 2021 sonu itibari ile artık desteklenmiyor. Bu haber R dili ile Azure ML üzerinde çalışmayacağınız anlamına gelmiyor. Sadece Azure ML hizmetinin bileşenlerini R dili ile artık yönetemeyeceğiniz anlamına geliyor. 

Python ve Azure CLI desteği versiyon 1 olarak hala kullanımda ve ne zaman desteğin kesileceğine dair herhangi bir açıklama şu aralar mevcut değil. Fakat yeni bir Python SDK ve Azure CLI için ML extension duyurusu versiyon 2 olarak yapıldı ve genel kullanıma açıldı. Tüm yeniliklerin bu yeni yaklaşım üzerinden kullanılabilir olacağı belirtildi.

Python kullanıcıları SDK v1'e göre daha kolay bir yaklaşımla Python SDK v2'yi kullanabilir. Python yazmadan diğer dillerle makine öğrenimi yapmak isteyen geliştiriciler tüm Azure ML yetneklerini Azure ML CLI v2 ile benzer mantıkta komut satırından yönetebilir.

Azure ML CLI v2 kullanımı Visual Studio Code'un Azure Machine Learning bileşeni ile çok daha kolay hale geliyor. Tüm Azure ML yeteneklerini yaml dosyaları halinde tarif edebilir, VS Code ile Azure ML CLI v2 komutlarının bu yaml dosyalarını Workspacee iletmesini sağlayabilirsiniz.


Yukarıda bahsi geçen bileşenler ve komut desteğini göz önüne aldığımızda Azure Machine Learning hizmeti uçtan uca Makine Öğrenimi projelerini hayata geçirebilmek konusunda sınıf atlatacak nitelikte olduğunu söyleyebiliriz. 

Eğer daha yakından bakarsanız çok daha fazlasının olduğunu görebilirsiniz. Koddaki, modeldeki ve verideki değişimin takip edilip bir sürecin tetiklenebilmesi, modellerin ölçeklenebilir compute gücü ile eğitilmesi, eğitilmiş modellerin versiyonlanarak web serviceler şeklinde son kullanıcıya yayınlanması ve talep trafiğinin yönlendirmesi gibi görünen ihtiyaçlara cevap verdiği gibi mahremiyet ve adalet gibi bazı etik ve kanuna dayalı görünmeyen ama baş ağrıtabilecek konularda da çözümler sunmaktadır. 

Makine öğrenimi çalışmaları sonucu ortaya çıkabilecek ihlallerin, adaletsizliğin belirlenebilmesi ve modelin açıklanabilmesi çoğu zaman göz ardı edilir. Bu konudaki bir ihmal para ve imaj kaybına sebep olabilir. Kanunlara göre hapis cezası ile bile sonuçlanabilir. 

Bu konularla ilgili Azure ML hizmeti üzerindeki yeteneklerin bir kısmı şu aralar her ne kadar preview aşamasında olsa da tatmin edici sonuçlar elde etmek ve gerekli önlemleri alabilmek pekala mümkün.

Azure ML Hizmeti işin anlaşılmasından, eğitilmiş modelin yayınlanmasına kadar geçen tüm ML sürecini yönetebilme, veri bilimcisinin etik ve kanuni sorumluluklarını yerine getirebilme ve değişen talepler için dinamik compute gücü sağlama konusunda etkileyici çözümler sunuyor. 

Azure Machine Learning hizmetini, makine öğrenimi projeleriniz için bir doğal yaşam alanı haline getirmeniz müşterilerinize, firmanıza ve ekiplerinize rahat bir nefes aldıracaktır.

17 Ocak 2023 Salı

Spark Pool ve SQL Pool Arası İletişim Yöntemleri (Azure Synapse Analytics)

Modern LakeHouse veri yönetim mimarisinin uygulanabildiği önemli bir platform olan Azure Synapse Analytics hizmeti Data&Analytics konusunda muhteşem yetenekler sunuyor. 

Azure Synapse Analytics üzerindeki mevcut yetenekler bir yandan gelişmeye devam ederken, bir yandan da yeni yetenekler gündemimize giriyor.

Bu yazımızda neredeyse Synapse'in doğuşundan beri var olan iki yetenek yani Spark Pool ve SQL Pool arasındaki iletişime odaklanalım istiyorum. İki Pool arasındaki iletişimin hangi şekillerde olabileceği sorusu eğitimlerde sıkça sorulduğu için cevabın özetini yazılı hale getirmek ve sizlerle paylaşmak istedim. 

Bu yazıda söz konusu yöntemlerin detaylarını ele almanın öncelikli hedefim olmadığını belirteyim. Çünkü bu yöntemlerin bir kısmına ait detayları farklı makalelerde ele almıştık. Geriye kalanları da fırsat buldukça ele almayı planlıyorum.

Bu yazının konusuna geçmeden önce Synapse Analytics ile ilgili ilginizi çekeceğini düşündüğüm aşağıdaki makaleleri de sizlerle paylaşmak isterim:

Azure Synapse Analytics ile Bütünleşik Büyük Veri Analitiği - 1

Azure Synapse Analytics ile Bütünleşik Büyük Veri Analitiği - 2

Başlamadan önce bu iki Pool ile ilgili bazı hatırlatmalar yapalım:


  • SQL Pool, MPP mimarisine sahip SQL engine ile sunulan iki benzer SQL hizmetini temsil ediyor. Bunlar özetle veri tutacak bir tablo tanımlanamayan Serverless SQL Pool ve bildiğimiz anlamda tablolarında veri tutabilen Dedicated SQL Pool hizmetleridir. 
  • Spark Pool ise Distributed mimariye sahip optimize edilmiş bir Spark engine ile sunulan bir Spark hizmetidir. 
  • Dedicated SQL Pool ve Spark Pool hizmetlerinden birden fazla açmanız mümkün. Serverless SQL Pool ise Synapse hizmeti ayağa kalktığında kullanıma sunulur ve kapatılamaz.
  • Spark Pool tarafında Managed ve Unmanaged (external) tablo oluşturabilir ve bu tabloları Hive'a kaydedilebilirsiniz. Verileri Hive'a kaydetmeden doğrudan depolama birimine yazmak da mümkün.
  • Serverless SQL Pool tarafında CET (Create Extertal Table) ile depolama birimindeki verileri okuyabilir, bir SELECT çıktısını CETAS (Create Externatal Table As Select) ile depolama birimine kaydedebilirsiniz. Dedicated SQL Pool tarafında ek olarak CT (Create Table) ile fiziksel veri tutabilen tablolar oluşturabilirsiniz.
Hadi gelin şimdi SQL Pool ve Spark Pool arasındaki iletişim yöntemlerine bir göz atalım:


Azure Storage Account Üzerinden İletişim


Synapse hizmeti ayağa kaldırıldığında bağlı bir hizmet olarak Data Lake Storage Gen 2 depolama hizmeti de ayağa kalkar. Bu depolama hizmeti büyük verinin verimli şekilde işlenmesi için gerekli özelliklere sahiptir. 

Dilerseniz daha sonra faklı bir Storage Account ekleyebilir veya mevcut Storage Accountlarınızı kullanabilirsiniz. Storage Accountlardaki dosyalara erişmek için eğer public değilse için Access Key, Shared Access Signature, User Identity, Managed Identity seçeneklerini tercih edebilirsiniz.

Spark Pool tarafından bu Storage Accountlara kolayca erişebilir, verileri işleyebilir ve çıktıları tekrar Storage Accounta kaydedebilirsiniz. Hemen ardından SQL Pool tarafından OPENROWSET fonksiyonu ve Polybase Engine desteği ile Storage Accounttaki verilere erişebilirsiniz. 

Ayrıca Dedicated SQL Pool, COPY scripti ile depolama birimlerindeki verileri yüksek hızda tabloya kopyalama özelliğine sahiptir.

SQL Pool tarafından depolama birimindeki verileri okuma konusuyla alakalı olan Data Virtualization konusuna bir göz atmak isterseniz şu videoyu incelemenizi tavsiye ederim:

Data Virtualization in Azure Synapse Analytics with SQL Pool 

Shared Metadata Özelliği ile İletişim (Serverless SQL Pool için)


Shared Metadata veya Metastore özelliği sayesinde oluşturduğumuz Lake Database tanımı Spark Poollarında Hive veritabanı olarak, Serverless SQL Pool tarafında da ayrı bir veritabanı olarak görünür.

Bu ortak veritabanındaki tablolara her iki tür Pool üzerinden de erişebiliriz. Tabi ki bu tablolar Serverless SQL Pool tarafında external table olarak görüneceğinden veri girişlerini Spark Pool üzerinden yapmanız gerekir.

Shared Metadata konusunda daha yakından bakmak isterseniz aşağıdaki yazımıza bir göz atabilirsiniz:

Azure Synapse Analytics üzerinde Lake Database Kullanımı ve Shared Metadata Deneyimi

Microsoft'un JDBC Connectorü ile İletişim


Apache Spark, SQL enginee bağlantı kurulmasını sağlayan genel bir JDBC connectorüne sahip. Buna ek olarak Microsoft özel bir JDBC connector geliştirdi. Microsoft'un geliştirmiş olduğu bu connector SQL enginea bağlantı konusunda genel JDBC connectorundan 15 kata kadar daha yüksek hız vaat ediyor.

Maven kütüphaneleri arasında "com.microsoft.azure:spark-mssql-connector" ismiyle yer alan bu connectorü Spark ortamına yüklemeniz gerekir. Sonrasında mesela bir tablo okumak için spark.read.format("com.microsoft.azure:spark-mssql-connector") şeklinde başlayan bir kod parçasına diğer option parametrelerini de ekleyerek SQL enginelara bağlantı kurabilirsiniz.

SqlAnalyticsConnector ile İletişim (Dedicated SQL Pool için)


Dedicated SQL Pool, Serverless SQL Pool'a ek olarak fiziksel tablo tutma özelliğine sahiptir demiştik. MPP mimarisine sahip bu engine 60 depolama segmenti ve 60 compute node ile büyük veri işleme konusunda oldukça etkili. Tekil işlemlerden ziyade toplu (bulk) işlemlerde ve özellikle sıkıştırmanın uygulandığı noktalarda bu mimarinin şovunu hayranlıkla izliyoruz.

Microsoft, Spark Pool ve Dedicated SQL Pool arasında doğal bir iletişim imkanı veren Scala da yazılmış bir Spark kütüphanesi sunuyor. Bu kütüphane ile Spark tarafındaki bir dataframe Dedicated SQL Pool tarafında bir tablo olarak kaydedilebilir. Ayrıca Dedicated SQL Pool tarafındaki bir tablo Spark Pool'dan kolayca okunabilir.

SQL tarafındaki verilerle harmanlanarak, Spark tarafında işlenen büyük verinin (Bronze, Silver Table), son tüketiciye (Rapor geliştiricileri) sunulduğu ve interaktif sorgulara cevap vermek üzere index, istatistik, meteralized view, caching özellikleriyle desteklendiği bir tablo (Gold Table) haline getirildiğini düşünün. Bu senaryonun gerçekleştirilmesi için iki Pool arasındaki iletişimi bir fonksiyonla sağlamak önemli bir konfor.

org.apache.spark.sql.SqlAnalyticsConnector._ ve com.microsoft.spark.sqlanalytics.utils.Constants isimli Scala modullerini import ettikten sonra, mesela SQL Pool'daki tabloyu okumak için spark.read.sqlanalytics("<DBName>.<Schema>.<TableName>") ifadesini diğer option parametrelerini de ekleyerek kullanabilirsiniz. 

Bu özellik her ne kadar Scala üzerinde olsa da oluşan DataFrame nesnelerini Tempview veya GlobalTempView olarak kaydedip farklı bir dil, mesela Python ile okuyabilirsiniz.

Spark Pool tarafındaki mevcut bir dataframei (adı df olsun) Dedicated SQL Pool'a tablo olarak kaydetmek isterseniz. Yine Scala ile df.write.sqlanalytics("<DBName>.<Schema>.<TableName>", Constants.INTERNAL) şeklinde bir kod parçası kullanabilirsiniz. Constants.INTERNAL ifadesi normal bir tablo oluştururken Constants.EXTERNAL ifadesi ile bir external tablo oluşturabilirsiniz.

Bu kodlarda geçen sqlanalytics fonksiyonunun ileride desteklenmeyeceği açıklanıyor, bunun yerine yeni synapsesql fonksiyonunu kullanmanızı öneririm.

Son Söz


Farklı şartlar altında ve farklı ihtiyaçlar doğrultusunda farklı yöntemler kullanılabilir. İhtiyacınıza ve içinde bulunduğunuz şartlara göre bir veya daha fazla yönteme yönelebilirsiniz.

Evet! Bazılarımızın bu yöntemlerin nasıl uygulandığını merak ettiğini ve bu yazıda görmek isteyebileceğini tahmin edebiliyorum. Fakat bu yazımızın amacı iki temel Pool arasındaki iletişim hakkında genel bir fikir vermekti. Bu noktada amacımıza ulaştığımızı düşünüyorum. 

Yöntemlerin uygulanması konusunda bir çok kaynağa kolayca ulaşabilirsiniz. Bazılarını blog yazılarımız ve video yayınlarımız arasında da bulabilirsiniz.

4 Ocak 2023 Çarşamba

Azure Synapse Analytics üzerinde Lake Database Kullanımı ve Shared Metadata / Metastore Deneyimi

Azure Synapse Analytics, 2020 yılının sonlarına doğru tanıştığımız Lakehouse Veri Yönetim Mimarisinin uygulama sahası olan çok yönlü, yetenekli ve giderek daha fazla talep gören Microsoft'un göz bebeği bir Azure Veri&Analitik hizmetidir.

Bu hizmet daha önceki yazılarımızda da belirttiğimiz gibi bir çok farklı hizmetin yeteneklerini bir arada sunuyor. Özellikle Azure Storage, SQL (MPP), Spark (Distributed), Data Factory ve Power BI yetenekleri uçtan uca ve her ölçekteki analitik ihtiyaçlara cevap verebilecek seviyeye ulaşmış durumda. Data Explorer, Machine Learning, Cosmos DB ve hatta SQL Server 2022 ile çeşitli şekillerde uyumlu çalışması da göz kamaştırıcı nitelikte diyebilirim. 

Azure Synapse Anaytics ile Enterprise BI, Stream Analytics, Machine Learning ve genel olarak Big Data odaklı ihtiyaçlarınızı etkili çözümler üretebilirsiniz.

Synapse Analytics ile ilgili anlatılacak çok şey var elbette, fakat biz bu yazımızda Shared Metadata veya Shared Metastore olarak ifade edilen bir özelliğe odaklanalım istiyorum.

Shared Metdata Özelliği Nedir?

Azure Synapse Analytics hizmeti ayağa kaldırıldığında ilk başta Serverless SQL Pool adı verilen MPP mimarisine sahip bir SQL engine görürüz. Serverless SQL Pool temel olarak üzerinde veri depolamayan fakat diskteki csv, parquet, json vs. tiplerindeki verileri OPENROWSET ve PolyBase engine sayesinde okuyup SQL dili ile veri dönüştürme imkanı veren ve genel olarak geçici işleri yürütmek için kullandığımız bir SQL enginedır. 

Dilerseniz daha sonra Bir SQL veritabanında veri depolamak için Dedicated SQL Pool, Büyük Veri ihtiyaçlarına cevap üretmek için Spark Pool ve akan veri analizi için Data Explorer Pool açabilirsiniz.

Serverless SQL Pool üzerinde fiziksel tablo oluşturamasak da diskteki verileri tablo olarak görmemizi sağlayan CET (Create External Table) ve SELECT sonuçlarımızı diske yazdırıp tablo olarak sunan CETAS (Create External Table As Select) tablolarını oluşturulabiliyoruz.

Syanapse hizmetini ayağa kaldırdıktan sonra Synapse Studio üzerinden gerekli geliştirmeyi ve yönetimi yapmak mümkün. Synapse Studio üzerinde Data Bölümünden bir Serverless SQL Database oluşturabilirsiniz. Hemen ardından aşağıda görünen Workspace tabından bu veritabanına erişebilirsiniz. Dikkat ederseniz Tablo ile ilgili sadece External Tables klasorü yer alıyor. Yani CET ve CETAS tabloları burada listeleniyor.



Şimdi asıl konumuzla ilgili olan kısma gelelim: Yine aynı menüden bir 'Lake Database'i arayüz yardımıyla oluşturabilirsiniz. 



İlk başta Database1 adında oluşuyor. Fakat daha sonra bu adın yanındaki gizli ".../ Open" ile açılan tasarım penceresinde, en sağda yer alan ayar buton ile Lake Database adını, konumunu ve varsayılan olarak veri depolama yöntemini belirtebilirsiniz. Değişikliklerin geçerli olması için Publish butonuna basmalısınız.


Oluşturduğumuz bu Lake Database tanımı Spark Veritabanı tanımı ile aynıdır (Hive uyumlu). Bu şekilde oluşturduğumuz tüm Lake Databaseler tüm Spark Poolları tarafından erişilebilir ve yönetilebilir, ek olarak Serverless SQL Pool tarafından da erişilebilir hale gelir. 

Lake Database olarak isimlendirilen bu Spark veritabanı temsilinde oluşturduğumuz tablolar Spark Engine olmadan Serverless SQL Pool tarafından bakıldığında yeni bir veritabanı altında dbo scheması içerisinde External Table olarak  listelenir ve içeriği okunabilir. 

Designer penceresi veritabanı ve tablo oluşturmak için gerekli arayüzü bize sağlamaktadır. Fakat tablolara veri eklemek veya tabloların yapısını scriptlerle değiştirmek isterseniz Spark Pool açmanız gerekir.

Microsoft'un Shared Metadata olarak isimlendirdiği bu özellik ile oluşan, Hive uyumlu veritabanı temsili olan Lake Database metadatası ayrı bir katmanda depolanıyor ve bu metadata Serverless SQL Pool ve Spark Poollar arasında asenkron bir şekilde dağıtılıyor. Yani küçük bir gecikme ile Lake Database ve içindeki nesneler bahsettiğimiz poollardan erişilebilir hale geliyor. 

Shared Metadata özelliği sadece tasarım ekranından oluşturulan Lake Databaselerin değil aynı zamanda Spark tarafından oluşturulmuş olan Hive veritabanlarının metadatasını da dağıtarak Serverless SQL Pool ve diğer Spark Poollar ile erişilebilmesini sağlıyor.

Merak edenler için güvenlik konusunda özetle şunu söyleyebiliriz; sorgu gönderen istemci ile ilgili güvenlik kuralları sorgu gönderdiği pooldan geçer ve dosya sistemi seviyesinde kontrol edilir.

Tablo Oluşturmak, Düzenlemek ve Sorgulamak

İlk aşamada Lake Database için ".../Open" ile açılan tasarım ekranında bir tablo oluşturalım. Diskteki bir dosyadan, template ile veya custom seçeneği ile istediğiniz bir tablo tasarımını yapabilirsiniz.

Custom seçeneği ile tablo oluşturalım istedik. Arayüz gayet açık. Tabloyu tıklayıp altındaki bölümden depolama seçeneklerini ve kolonları belirtebilirsiniz. Gerekli değişiklikleri yaptıktan sonra Publish ile bu değişiklikleri yayınlayalım.


Oluşan tabloyu listelediğimizde yanındaki "... / New SQL Script" menusu ile sorgulayabilirsiniz. Yeniden hatırlatmak isterim tablomuz şuan boş, dilerseniz diskteki bir dosyadan tablo türetebilir, içeriğini hemen okuyabilirsiniz. Tabloya veri girişi yapmak için ve script ile düzenleyebilmek için Spark Pool oluşturmamız gerekli. Bu operasyonlar SQL Pool tarafından desteklenmiyor. Bu tabloları Serverless SQL Pool tarafında sadece SELECT ile okuyabiliyor.



Dikkat! Serverless SQL Pool bu tabloyu External Table olarak görüyor ve şuanda bu tablonun diskteki konumu henüz oluşturulmadı o yüzden custom tablo oluşturduğunuzda Spark tarafından veri girişi yapmazsanız aşağıdaki hatayı alırsınız. 

Bu gayet normal bir durum. Şimdi tabloya Spark Pool tarafından veri girişi yapalım ve hatasız şekilde sorgulanmasını sağlayalım.

Ekran görüntülerinden de anlaşıldığı gibi Serverless SQL Pool tarafı Lake Databasei bir SQL veritabanı olarak görüyor. İçerisindeki tabloyu da dbo şeması alıntındaki External Tablo olarak yorumluyor. İşte bu Shared Metadatanın bize sunduğu bir nimet. Şimdi diğer nimete yani bu tabloyu Spark Pool tarafında nasıl yönetebileceğimize bir bakalım.

Spark Pool oluşturma adımlarına burada yer vermeyeceğim. Bir Apache Spark Pool'u Synapse Studio üzerinde Manage bölümünden kolayca oluşturabilirsiniz.

Tablo yanındaki ".../New Notebook" menusu ile bir notebook açalım ve Spark oturumu başlatalım. 

Spark engine bağlı olan bu notebook üzerinde spark.sql fonksiyonu içerisinde HiveQL olarak bilinen bir tür SQL dilini kullanarak çalışabilirsiniz. Aşağıda sorgu sonucunu bir değişene DataFrame olarak attık ve show ile görüntüledik. Hücrenin üzerinde %%pyspark yazdığı için hücremiz Python dilini çalıştırıyor.


Şu an tablo içeriği boş. Biraz veri girişi yapalım. Yine HiveQL komutları kullanarak veri girişi yapabiliriz.

İlk hücrenin hemen altındaki "+ Code" butonunu tıklayıp yeni hücre ekler ve bu hücrenin en üst satırına %%sql yazarsanız spark.sql fonksiyonuna gerek kalmadan SQL komutlarını çalıştırabilirsiniz

Kayıtları girdikten sonra tekrar sorguladığımızda hem Spark Pool tarafından hem de Serverless SQL Pool tarafından verilerin geldiğini görebiliriz. Bu arada farklı poolların tabloya erişirken farklı yollar kullandığını, yani FROM sonrasının farklı olduğunu gözden kaçırmayın.

Spark'ın Hive Kataloğuna kayıtlı veritabanlarını listelediğimizde arayüzden oluşturduğumuz Lake Databasei görebiliyoruz. Hemen sonrasında bu veritabanı içerisindeki tabloları listelediğimizde tablomuzun Spark tarafında External (Unmanaged) yani Hive'a register edilmiş fakat varsayılan hive lokasyonunda değil de bizim belirttiğimiz bir lokasyonda verilerinin depolandığını görebiliyoruz. External (Unmanaged) tablolarda metadata silinse de veriler diskten silinmez. Yani Spark ve SQL tarafındaki Extertnal Tablelar bu yönüyle birbirine benziyor.

Bu arada default isimli varsayılan bir Hive veritabanı da listelenmiş durumda. Yani Spark içerisinde bir CREATE TABLE scripti yazarsanız tablonuz doğrudan default veritabanı altına kaydolur. Tüm Lake Database tablolarına Serverless SQL Pool ve Diğer Spark Poollar üzerinden erişebilirsiniz.



Spark tarafında script ile oluşturulan Managed ve Unmanaged (External Table) tablolar Shared Metadata özelliği sayesinde Serverless SQL Pool tarafından okunabildiğini deneyimledik.

Eğer Spark tarafındaki bir veri kümesini diske doğrudan kaydetmiş iseniz bu durumda Hive'a register etmemişsiniz demektir. Bu veri kümeleri diskte dosya olarak durur fakat Spark veya Serverless SQL Pool tarafından tablo olarak görünmez. Yine de Serverless SQL Pool tarafından OPENROWSET ve PolyBase Engine sayesinde ya da Spark Pool tarafından spark.read. komutları ile diskteki bu verilere kolayca erişim sağlayabilirsiniz.

Özetle 

Shared Metadata özelliği sayesinde Spark Veritabanları ve Manged/UnManged tabloları (şimdilik parquet ve csv depolama formatındakiler) SQL enginedaki temsilleri ile birlikte temel depolama düzeyinde korunur ve diğer poollar ile paylaşılır. Eğer bir Spark View oluşturmuş iseniz bunlar sadece Spark Poollar arasında paylaşılır. Spark tabloları Serverless SQL Pool tarafında External Table olarak temsil edilir fakat Spark Viewleri Serverless SQL Pool tarafında görünmez.

Dedicated SQL Pool ve Spark Pool arasında Scala dilinde yazılmış "spark.read.synapsesql" ve "spark.write.synapsesql" fonksiyonları ile doğal ve güçlü bir entegrasyon mevcut. Shared Metadata özelliği sayesinde Serverless SQL Pool ve Spark Pool arasında da başarılı ve kullanışlı bir entegrasyon deneyimleyebiliyoruz.