LTAP mimarisi

Lake İşlemsel/Analitik İşleme (LTAP), göldeki birleşik veri depolama katmanından işlem (OLTP) ve analitik (OLAP) iş yüklerini tek bir yönetişim modeli altında hizmet veren bir veri mimaridir; böylece işlemsel ve analitik sistemleri ayrı bir şekilde senkronize tutmanıza gerek kalmaz. Ekiplerin geleneksel olarak operasyonel verileri ayrı bir analitik sisteme kopyalamak için sürdürdüğü değişim veri yakalama (CDC), çoğaltma ve dönüşüm boru hatlarını kaldırır. Azure Databricks, LTAP'ı Lakebase depolama mimarisi üzerine inşa eder. Duyuru için bkz. Databricks LTAP'ı başlatıyor: ilk Lake İşlemcel/Analitik İşleme mimarisi.

LTAP bir mimaridir, tek bir özellik değildir. Azure Databricks, aktif olarak geliştirilen ve genişletilen bir dizi Lakebase yetenekleri aracılığıyla bunu sunuyor. Size sunulan yetenekler bulutunuza bağlıdır. Bu sayfa mimariyi açıklıyor. Bugün bulutunuzda kullanabileceğiniz yetenekler için LTAP'ı uygulayan yetenekler bölümüne bakınız.

Important

Bu sayfayı okumadan önce, Lakebase mimarisi ve bileşenlerini anlamak için Lakebase mimarisini okuyun: durumsuz Postgres hesaplama, safekeeperlar, pageserverlar ve bulut nesne depolama. LTAP, doğrudan Lakebase'in hesaplamayı depolamadan ayırma biçimi üzerine kurulur ve bu sayfanın geri kalanı da bu temeli varsayır.

İki yığını senkronize tutmanın maliyeti

Uygulamalar veri işlerini iki tür iş yüküne ayırır. İşlemsel (OLTP) iş yükleri aynı anda birkaç satır üzerinde hareket eder ve bu satırların tam içeriğine hızlıca ihtiyaç duyar; örneğin bir ödeme işleme veya API sonucunu geri göndermek gibi. Analitik (OLAP) iş yükleri, büyük veri setleri boyunca içgörüler arar; genellikle satışları tahmin etmek veya dolandırıcılığı tespit etmek gibi birçok satırı toplar ve birleştirir. Bu desenler zıt yönlere çekilir: OLTP bireysel satırlarda sürekli düşük gecikmeli okuma ve yazma gerektirirken, OLAP büyük veri hacmlerinde tarama ve toplama işlemleri gerektirir. Onlarca yıl boyunca cevap iki ayrı sistemdi: uygulama için işlemsel veritabanı ve analiz için veri deposu veya göl evi.

Bu iki yığını birleştirmek pahalı kısım. Bunları senkronize tutmak, değişim veri yakalama (CDC), akış boru hatları ve tek işi bir sistemden diğerine veri kopyalamak olan okuma replikalarını çalıştırmak anlamına gelir. Bu altyapı kırılgandır, veri yazıldığı zaman ile analiz edilebildiği zaman arasında gecikme ekler ve birincil işlem veritabanıyla kaynaklar için rekabet eder. Uygulamalar ve yapay zeka ajanları en taze işlem verileri üzerinde giderek daha fazla analitiğe ihtiyaç duydukça, bu boşluk ekipleri yavaşlatıyor. İki sistem arasında veri kopyalamak ayrıca yönetişim riski yaratır: soy veri hareket ettikçe kopabilir, bu da GDPR kaldırma talepleri gibi yükümlülüklerin yerine getirilmesini zorlaştırır.

LTAP depolama katmanında veriyi nasıl birleştiriyor?

İki yığın arasında daha iyi bir boru hattı inşa etmek yerine, LTAP boru hattına olan ihtiyacı tamamen ortadan kaldırır. Bunu, veritabanını depolamadan yukarıya yeniden düşünerek yapar.

Lakebase, durumsuz Postgres hesaplamasını koruyucular, sayfa sunucuları ve bulut nesne depolama katmanından zaten ayırıyor. Bir işlem, bir güvenlik saklayıcıları yeterlikli olarak önceden yazma günlüğünü kalıcı olarak kaydettiğinde işlem yapar ve sayfa sunucuları bu değişiklikleri bulut nesne depolamaya asenkron olarak taşır, böylece veri artık tek bir veritabanı motorunda kilitli kalmaz.

Note

Lakebase'in hesaplama ve depolamayı nasıl ayırdığı için bkz. Lakebase mimarisi.

LTAP, bu depolama katmanına bir basamak ekliyor. Lakebase depolama verileri nesne depolamaya maddeleştirirken, satır tabanlı Postgres verilerini Parquet'in sütunlu düzenine dönüştürür ve veri göle iner ve burada Delta ve Iceberg gibi açık tablo formatları aracılığıyla okunabilir. Bu transkodlama, tek bir veri kopyasının hem OLTP hem de OLAP iş yüklerine hizmet etmesini sağlar. Sütunlu kopyanın Postgres orijinalinin sadık ve verimli bir temsili olarak kalması için tasarlandı:

• Anlamsal kavramlar korunur. Lakebase depolama, orijinal Postgres temsilini koruyarak her değeri sütunlu forma dönüştürür, böylece herhangi bir Postgres uyumlu motor, veri kaybetmeden veriyi yeniden yorumlayabilir. Parquet'e tam olarak eşlenemeyen türler, örneğin NaNtaşma NUMERIC veya vektör, dizi, coğrafya ve JSON gibi uzantı türleri, kanonik Postgres temsilini içeren bir taşma alanında korunur.
• Sıra versiyonları korunmuştur. Transkodlama ara satır versiyonlarını korur, böylece sütunlu kopya satır verisiyle aynı sürüm bilgisini taşır.
• Sütunlu veri iyi sıkıştırılır. Sütunvari düzen oldukça sıkıştırılmıştır, bu da depolama alanını ve nesne depolamaya taşınan veri miktarını azaltır.

Transkodlama tamamen depolama katmanında, birincil Postgres örneğinden izole olarak çalışır, bu yüzden işlemsel hizmet yükünüzü etkilemez. Bu, Lakebase'in zaten yaptığı bir şeyin üzerine inşa ediyor: taahhütlü verileri bulut nesne depolamaya kaydetmek. LTAP aynı düzlüğe sütunlu formatı ekliyor. Oluşturabileceğiniz bir pipeline yok ve veritabanınızı sorgulayan harici bir süreç yok.

Her şey transkodlanmaz. Postgres indeksleri, sütunlara dönüştürülmek yerine dayanıklı depolama katmanındaki orijinal temsillerinde kalır, böylece işlemsel nokta okumaları ve aramalar hızlı kalırken, sütunlu kopya analitiklere hizmet eder.

Veriler dışa dönük, sürümlü depolama içinde yaşadığı için, bir dal oluşturmak veya belirli bir zamana geri yüklemek fiziksel bir kopya değil, metaveri işlemidir. Büyük bir üretim veritabanını saniyeler içinde dallayabilir, bir deney veya riskli bir göç yaparak dala karşı karşıya durup, altta yatan veriyi çoğaltmadan atabilirsiniz.

Note

Lakebase dalı, veritabanınızın depolama alanının kopyalayıp yazma klonudur: ebeveynin mevcut verilerini paylaşır ve sadece değişenleri saklar, bu yüzden veri baştan çoğaltmaz. Zamanında geri yükleme, aynı sürümlü depolamayı kullanarak veritabanını geri yükleme penceresinde daha önceki bir ana döndürür. Daha fazla bilgi için Veritabanı dalları ve Noktada Zamanında Geri Yükleme bölümlerine bakınız.

Bu depolama düzeyindeki yaklaşım, LTAP'ı değişim veri yakalamasından (CDC) ayıran şeydir. CDC, OLTP depodan verileri ayrı bir analitik katmanına çoğaltıyor; bu süreç sürekli birincil veritabanını sorgulayan ve satır değişikliklerini sütunlu veriye dönüştüren bir boru hattı kullanıyor. Bu boru hattı, birincil işlem veritabanınızdaki kaynakları tüketir, şema değişikliklerini ve uç vakaları kendiniz halletmenize izin verir ve veri tazeliğini boru hattı maliyetine karşı takas eder, tüm bunlar sırasında başarısızlık noktaları ekler. LTAP bunun yerine depolama düzeyinde bir yaklaşım benimser: Lakebase depolama, normal depolama operasyonunun bir parçası olarak verileri göle dönüştürür; iş yükünüzle rekabet eden harici bir süreç yoktur ve sizin inşa etmeniz veya bakımınızı yapmanız gereken bir boru hattı yoktur.

LTAP'ın üç temel unsuru

Veri depolama katmanında birleştirilmek, LTAP'a üç tanımlayıcı özellik verir.

• Evrensel yönetişim. Unity Catalog, her iki iş yükünde de verilerinizin bir mantıklı kopyasına analitik erişimi yönetir.
• Amaçlı olarak tasarlanmış motorlar. Postgres işlemlere hizmet verirken, Lakehouse analitiklere hizmet eder ve hiçbiri diğerini tehlikeye atmaz.
• Açık depoda tek bir mantıklı kopya. Her iki motor da verilerinizin bir kopyasını açık formatlarda okur, senkronize tutulacak replikalar veya boru hattları yok.

Evrensel yönetim

Unity Catalog, verilerinize analitik erişimi her iki iş yükü arasında yönetir. Bir Lakebase veritabanı kaydettikten sonra, Unity Kataloğu izinleri, soy ve denetimi onu okuyan harici hesaplamaya uygular.

Note

Unity Kataloğu yönetimi bugün analitik erişim için geçerlidir: Lakehouse//RT ve Change Data Feed gibi harici hesaplama, kayıtlı Lakebase verilerinizi okuyor. Henüz bireysel Postgres tablolarını doğrudan yönetmez. İşlemsel yol üzerinden erişim, yani uygulamalar ve istemciler Postgres'e bağlanırken, Unity Catalog tarafından değil, standart Postgres ayrıcalıkları (GRANT ve REVOKE) tarafından kontrol edilir. Pratikte, Unity Kataloğu analitik ve göl evi erişimini yönetirken, Postgre'nin rolleri ve ayrıcalıkları işlemsel erişimi yönetir.

Özel olarak üretilen motorlar

Postgres işlem yükünüzü karşılarken, Lakehouse analitik hizmetleri sunuyor ve her biri için inşa edildiği güçlü yönlere sahip. Yaygın bir yanlış anlama, ikisini birleştirmenin operasyonel verilerinizin buzdağında soğuk bir veriye dönüşmesi anlamına gelmesidir. Durum böyle değil. Lakebase standart Postgres olarak kalmaktadır. Indeksleme, dallanma, nokta-zaman kurtarma, uzantılar ve düşük gecikmeli nokta okuma ve yazma işlemleri bugün olduğu gibi çalışmaya devam ediyor.

Analitik okumalar, işlem iş yükünüzle rekabet etmez çünkü birincil Postgres örneğinden izole edilirler. Lakehouse//RT gibi bir analitik motor, canlı Lakebase verilerini sorguladığında, veri kopyalamadan taze, işlem açısından tutarlı bir sonuç döndürür:

• Motor, verilerin büyük kısmını nesne depolamadaki sütunlu kopyadan okur, Postgres'ten değil.
• İşlemsel olarak tutarlı bir görünüm elde etmek için, Postgres'ten yalnızca mevcut log dizisi numarasını (LSN) ister; bu tek bir değer ve önceden yazma günlüğünde bir konumu işaretler. Bu ucuz bir meta veri araştırması.
• Göle henüz gelmemiş çok yakın zamanda gelen küçük değişiklikler için ise sayfa sunucusundan okuyor ve üstüne birleştiriyor.

Postgres, tek bir LSN döndürmek dışında analitik okuma trafiğini hizmet vermez ve transkodlama, uygulamanıza hizmet veren Postgres örneğinde değil, depolama katmanında çalışır. Operasyonel iş yükünüz beklendiği gibi çalışmaya devam eder.

Açık depolamada tek bir mantıksal kopya

Veriler gölde sütunlu Parquet olarak yaşadığı ve Delta ve Iceberg gibi açık tablo formatlarıyla okunabilen Lakebase (OLTP) ve Lakehouse (OLAP) aynı depolama temelini paylaşır. Her iki iş yükünde de tek mantıksal veri kopyasını tutarsınız, işlem veritabanını ayrı bir analitik kopyayla uzlaştırmak yerine.

Her motor, performans için veriyi farklı fiziksel formatlarda önbelleyebilir veya temsil edebilir. Lakebase, hızlı OLTP nokta okumaları için Postgres sayfalarını kullanırken, analitik motorlar sütunlu Parquet'i okur. Yine de ayrı işlemsel ve analitik kopyalar tutup senkronize tutmak yerine tek bir mantıksal veri setiyle çalışıyorsunuz.

Her masada tek bir yazar bulunur, ya Lakebase ya da göl evi. Her iki motor da o mantıklı kopyayı okur, böylece aynı veri uygulamalarınıza ve analitiklere ikinci bir kopya olmadan erişilebilir.

Lakebase'i kullanma şeklinizi değiştirmeniz gerekiyor mu?

No. LTAP yeteneklerini benimsemek, veri taşıması veya uygulamalarınızın Lakebase'e bağlanma şeklinde değişiklik gerektirmez. Lakebase standart Postgres olarak kalıyor: mevcut uzantılarınız, indeksleriniz, sorgularınız ve uygulama kodlarınız değişmeden çalışmaya devam ediyor. LTAP yeteneklerinin her biri bağımsızdır, bu yüzden iş yükü gerektiğinde herhangi birini benimseyebilirsiniz.

LTAP'ı uygulayan yetenekler

LTAP mimarisini Lakebase yetenekleri setiyle uygulamaya koyuyor musunuz. Her biri, yukarıda açıklanan paylaşılan depolama temeli üzerine inşa edilir ve birlikte verilerin LTAP üzerinden geçtiği yolları kapsar:

• Yönet ve kaydet: Lakebase verilerini Unity Kataloğu altına getir.
• Lakebase'de Lakehouse verilerini servis edin: senkronize tablolar, LTAP Direct Writes ile hızlandırılmış.
• Canlı Lakebase verilerini sorgulayın: Analitik için Lakehouse//RT, değişim akışları için Lakebase Change Data Feed.

Aşağıdaki diyagram, bu yeteneklerin Unity Kataloğu tarafından yönetilen bir veri kopyasına nasıl yazıldığını ve okunduğunu gösterir.

Lakehouse//RT ve Lakebase Change Data Feed aynı altta yatan veriyi okur ancak farklı şekilde temsil eder. Lakehouse//RT, canlı Postgres verilerinin güncel durumunu analitik için okuyor. Change Data Feed, aşağı akış boru hatları ve denetim için satır seviyesinde değişiklikler akışı sağlar. LTAP'ın kaldırdığı harici CDC de aynı şekilde değil: her ikisi de tek bir veri kopyası üzerinde çalışıyor.

Aşağıdaki tablo, tüm LTAP yeteneklerini ve ne yaptığını ve bulutunuzdaki sürüm durumunu listeliyor. Erişilebilirlik buluta göre değişir, bu yüzden bulutunuzda sunulmayan bir özellik mevcut değil olarak işaretlenir.

Capability	Statü	Description
Lakebase'i Unity Kataloğunda Kaydet	GA	Lakebase verilerine analitik erişimi yönetin ve göl evinden çapraz kaynak sorguları çalıştırın.
Eşitlenmiş tablolarla veri sunma	GA	Düşük gecikmeli OLTP okumaları için Lakebase'te Unity Catalog tablo verilerini servis edin. Snapshot modu ve tam yenileme senkronizasyonları, LTAP Direct Writes (Beta) kullanarak Spark ile paralel olarak doğrudan depolamaya yüklenebilir.
Lakehouse//RT Lakebase sorgusu yapıyor	Beta sürümü	Lakebase OLTP performansını etkilemeden canlı Postgres verilerinde işlem açısından tutarlı OLAP sorguları çalıştırın.
Lakebase Değişiklik Verisi Akışı	Public Preview	Lakebase Postgres tablolarından satır seviyesindeki değişiklikleri Unity Catalog Delta tabloları olarak downstream pipelines ve denetim için depolayın.

Uygulamaya nasıl yaklaşılır

Artık yetenekleri bildiğinize göre, soru iş yükünüzün hangilerine ihtiyacı olduğudur. LTAP'ı, verilerin mimarinizde akışına uyan yetenekleri birleştirerek uygularsınız.

Temel karar yöndür: Her veri seti için hangi sistem yazma cihazına sahip? Her tablonun tek bir yazarı vardır ve bu da hangi yetenekleri kullanacağınızı belirler.

• Lakebase yazı sistemine sahip. Uygulamanız Postgres'e yazıyor ve bu operasyonel verilerin analitik için kopyalanmadan erişilebilir olmasını istersiniz. Örneğin, bir satış uygulaması siparişleri ve ödemeleri gerçekleştikçe Lakebase'e yazar. Bu siparişler üzerinde canlı gelir paneli çalıştırmak için Lakehouse//RT veya her emir değişikliğini bir sonraki boru hattı veya denetim günlüğüne aktarmak için Lakebase Change Data Feed'i kullanın.
• Göl evi yazı evinin sahibidir. Verileriniz göl evinde üretilir veya bakımı yapılır ve uygulamanızdan düşük gecikmeli OLTP okumaları istiyorsunuz. Örneğin, gece bir göl evi işi ürün önerilerini veya fiyat tablosunu hesaplar. Uygulamanızın düşük gecikmeyle okuyabilmesi için senkronize tablolar kullanın ve büyük bir tablonun ilk yükünü hızlandırmak için LTAP Direct Writes'ı etkinleştirin.

Her veri setini bu yönlerden birine eşleyin, veritabanını yönetişim için Unity Kataloğu'na kaydedin , ardından her yolu uygulamak için yetenek dokümanturalarını takip edin. Tek bir uygulama genellikle her iki yönü kullanır: göl evinden Postgres'e referans verisi sunarken, kendi işlemsel yazımlarını analitiği tekrar gösterir. Erişilebilirlik buluta göre değişir, bu yüzden yukarıdaki yetenek tablosuna bakarak bulutunuzda ne sunulduğunu doğrulayın.

Sonraki Adımlar

• Lakebase mimarisi: Lakebase'in durumsuz hesaplamayı dayanıklı depolamadan nasıl ayırdığını anlayın. Bkz. Lakebase mimarisi.
• Unity Catalog: Govern Lakebase verilerini Govern ve lakehouse'dan sorgulayın. Bkz . Unity Kataloğu'nda Lakebase veritabanını kaydetme.
• Verileri senkronize tablolarla sunun: Unity Katalog tablo verilerini düşük gecikmeli okumalar için Lakebase'e senkronize edin ve LTAP Direct Writes ile büyük yükleri hızlandırın. Bkz. Eşitlenmiş tablolarla lakehouse verilerini sunma.

• Lakebase Değişiklik Veri Akışı: Pipeline ve denetim için göl evine satır seviyesinde değişiklikleri akış. Bkz. Lakebase Değişiklik Veri Akışı.

Daha fazla bilgi edinin

• Duyuru: Databricks, ilk Lake İşlemcel/Analitik İşleme mimarisi olan LTAP'ı başlattı
• Mühendislik blogu: Monolitten Lakebase'e, LTAP'a: veritabanını depolamadan yukarıya yeniden düşünme
• Demo: LTAP: İlk Lake İşlemcel/Analitik İşleme mimarisi