Databricks, LTAP (Lake Transactional/Analytical Processing) ile operasyonel veri tabanlarını ve analitik sistemleri birbirine yakınlaştırmayı amaçlayan bir mimari sunuyor. ETL veya CDC süreçlerini kullanarak iki dünya arasında veri kopyalamak yerine gelecekte her ikisinin de aynı veritabanı üzerinde çalışması gerekiyor. Databricks bunu, mevcut şirket verilerine her zaman erişmesi gereken yapay zeka aracılarının artan kullanımına bir yanıt olarak görüyor.
Reklamdan sonra devamını okuyun
Günümüzde birçok şirkette iki ayrı veri dünyası bulunmaktadır. Operasyonel uygulamalar, devam eden iş operasyonlarına yönelik verilerini PostgreSQL veya Oracle gibi işlemsel veritabanlarında saklar. Bu veriler daha sonra raporlama, analiz veya yapay zeka uygulamaları için bir veri ambarına veya göl evine kopyalanır. Arada, her iki sistem arasındaki değişiklikleri sürekli olarak senkronize eden ETL süreçleri veya sözde değişiklik verileri yakalama hatları (CDC) vardır. Bu mimari yıllardır standarttır ancak ek operasyonel yüke, veri kopyalarına ve zaman gecikmelerine neden olur.
Databricks'e göre bu model giderek sınırlarına ulaşıyor. Yapay zeka aracıları ve modern uygulamalar, güncel operasyonel verilere ihtiyaç duyar ve dakikalarca veya saatlerce eski kopyalarla çalışamaz. Üretici, LTAP ile işlemsel ve analitik iş yüklerini birbirine yakınlaştırmak istiyor.
Bir yerine iki motor
Ancak fikir yeni değil. Yaklaşık 15 yıl önce HTAP sistemleri (Hibrit İşlemsel/Analitik İşleme), işlemleri ve analizleri ortak bir veritabanı motorunda gerçekleştirmeye çalıştı. Dezavantajı: Aynı motorun hızlı yazma işlemlerini ve karmaşık analitik sorguları aynı anda işlemesi gerekiyordu; bu da genellikle ilgili optimizasyonun pahasına oluyordu.
Databricks'in önceki HTAP yaklaşımlarından önemli farkı tam da bu noktada görüyor. Databricks EMEA Saha Mühendisliği Başkan Yardımcısı Rich Radley, her iki görev için de tek bir motorun kaçınılmaz olarak tavizlere tabi olacağını açıklıyor. Bunun yerine LTAP iki özel motora dayanır: Lakebase, PostgreSQL'e dayalı işlemsel işlemleri yönetir ve Lakehouse analitik sorguları yönetir. Ancak her ikisi de aynı veritabanına erişir.
Bunun temeli, verileri doğrudan göl evinin nesne deposunda depolayan sunucusuz bir PostgreSQL sistemi olan Lakebase'dir. Üreticiye göre, işlem verilerinin tipik satır odaklı verileri, yazıldığında otomatik olarak analitik sorgular için optimize edilmiş sütun odaklı bir formata dönüştürülüyor.
Reklamdan sonra devamını okuyun
Veri organizasyonu için farklı gereksinimlere sahip olmalarına rağmen, ancak o zaman her iki motor da aynı veritabanını kullanabilir. Radley, bu gerçek zamanlı kod dönüştürmeyi mimaride gerçek bir teknik atılım olarak tanımlıyor. Bu, iki özel motorun, operasyonel ve analitik sistemler arasında verileri kopyalamak zorunda kalmadan aynı veriler üzerinde paralel olarak çalışmasına olanak tanır.
Veri kopyaları yerine ortak veritabanı
Lakebase, verileri Lakehouse ile aynı depolama katmanında Delta veya Iceberg gibi açık tablo formatlarında saklar. Birlik Kataloğu aracılığıyla birlikte yönetilirler; bu izinleri, meta verileri ve yönetimi halleder. Bu, hem işlemsel veritabanının hem de göl evinin ek veri kopyaları oluşturmadan aynı veritabanına erişmesine olanak tanır.
Lakebase ayrıca Databricks'i bulutlar arası ve bölgeler arası felaket kurtarma, Git benzeri dallar ve anlık görüntüler ve aracıların sağlığı izlediği ve optimizasyon önerileri sağladığı özerk veritabanı yetenekleriyle tamamlıyor.
Devrim yerine mimari
Databricks, işlemsel ve analitik iş yüklerini birbirine yakınlaştırma yaklaşımıyla kendisini hem HTAP (Hibrit İşlemsel/Analitik İşleme) sistemlerinden hem de daha yeni Sıfır ETL konseptlerinden farklılaştırmayı hedefliyor. HTAP her iki iş yükünü de ortak bir motorda birleştirmeye çalışırken Databricks, Sıfır ETL'nin öncelikle mevcut sistemler arasındaki entegrasyon çabasını azalttığını ancak temeldeki veri kopyalarının kaldığını savunuyor. Öte yandan LTAP, ortak bir veritabanı üzerinde çalışan ve veri kopyalarından tamamen kaçınmayı amaçlayan iki özel motora dayanır.
Ancak bu mimari yaklaşımın gerçekten ETL ve daha büyük ölçekte çoğaltma işlemlerinin yerini alıp alamayacağı verimli kullanımda görülecektir. LTAP henüz genel kullanıma sunulmamıştır ve üretken ortamlardan bağımsız ölçütler veya güvenilir deneyimler bulunmamaktadır.
LTAP, Lakehouse//RT ile birlikte Databricks'in stratejik yönünü gösteriyor: Gelecekte analiz, işlem ve yapay zeka iş yükleri artık çok sayıda veri kopyası ve özel ara sistemler aracılığıyla birbirine bağlanmayacak, bunun yerine ortak bir veritabanında birleşecek. Bu mimari yaklaşımın üretken kullanımda başarılı olduğu kanıtlanırsa, veri yoğunluklu yapay zeka uygulamalarının ve aracı sistemlerinin yapımını kolaylaştırabilir.
(akşam)
Bir yanıt yazın