Databricks, LTAP (Lake Transactional/Analytical Processing) ile operasyonel veri tabanlarını ve analitik sistemleri birbirine yakınlaştırmayı amaçlayan bir mimari sunar. 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 iş verilerine her zaman erişmesi gereken yapay zeka aracılarının artan kullanımına bir yanıt olarak görüyor.
Duyurudan 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, 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 işletme maliyetlerine, veri kopyalarına ve gecikmelere 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 Hibrit İşlemsel/Analitik İşleme (HTAP) sistemleri, 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 zararına oluyordu.
Databricks'in önceki HTAP yaklaşımlarıyla karşılaştırıldığında önemli farkı gördüğü nokta tam da burasıdır. Databricks EMEA Saha Mühendisliği Başkan Yardımcısı Rich Radley, her iki görev için tek bir motorun kaçınılmaz olarak değiş tokuşlara tabi olduğunu açıklıyor. Bunun yerine LTAP iki özel motora dayanır: Lakebase, PostgreSQL tabanlı işlem işlemeyi yönetir ve Lakehouse analitik sorguları yönetir. Ancak her ikisi de aynı veritabanına erişir.
Temeli, verileri doğrudan Lakehouse nesne deposunda depolayan sunucusuz bir PostgreSQL sistemi olan Lakebase'dir. Üreticiye göre, işlem verilerinin tipik satır odaklı verileri, yazarken analitik sorgular için optimize edilmiş sütun odaklı bir formata otomatik olarak dönüştürülüyor.
Duyurudan sonra devamını okuyun
Ancak o zaman her iki motor da aynı veritabanını kullanabilecektir, ancak veri organizasyonu için farklı gereksinimleri vardır. 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 depolar. Birlik Kataloğu aracılığıyla birlikte yönetilirler; bu izinler, meta veriler ve yönetimle ilgilidir. Bu, hem işlemsel veritabanının hem de Lakehouse'un, verilerin ek kopyalarını 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 ajanların sağlığı izlediği ve ayarlama önerileri yaptığı otonom veritabanı yetenekleriyle entegre ediyor.
Devrim yerine mimari
Databricks, işlemsel ve analitik iş yüklerini birbirine yakınlaştırma yaklaşımıyla kendisini hem Hibrit İşlemsel/Analitik İşleme (HTAP) sistemlerinden hem de 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, Zero ETL'nin öncelikle mevcut sistemler arasındaki entegrasyon çabasını azalttığını ancak temeldeki verilerin kopyalarının kaldığını iddia ediyor. LTAP ise ortak bir veritabanı üzerinde çalışan ve veri kopyalamayı tamamen önlemeyi amaçlayan iki özel motora dayanmaktadır.
Ancak bu mimari yaklaşımın, üretim kullanımında daha büyük ölçekte etkili bir şekilde ETL ve çoğaltma işlemlerinin yerini alıp alamayacağını zaman gösterecek. LTAP henüz genel kullanıma sunulmamıştır ve üretim ortamlarından 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 analitik, 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 üretim kullanımında etkili olduğu kanıtlanırsa, veri yoğunluklu yapay zeka uygulamalarının ve aracı sistemlerinin yapımını kolaylaştırabilir.
(yardımcı)
Bir yanıt yazın