Databricks'in Lakebase'i işlem ile analitik arasındaki duvarı yıkıyor

Otuz yılı aşkın süre kurumsal veri mimarileri katı bir iş bölümüne dayanıyordu: PostgreSQL, MySQL ve Oracle gibi OLTP sistemleri düşük gecikmeli, gerçek zamanlı uygulama durumunu yönetirken; Apache Spark, Snowflake ve Delta Lake gibi analitik motorlar tarihsel veriyi tutuyor ve ağır ML iş yüklerini çalıştırıyordu.

İki dünya arasında kırılgan ETL hatları vardı: şirketler operasyonel veriyi analitik lakehouse'a taşımak için karmaşık senkronizasyon kuruyor, ardından özellik verisini uygulamalara geri itmekte zorlanıyordu. HackerNoon'da yayımlanan analizde yazar, Neon teknolojisi üzerine kurulu açık lakehouse tabanlı operasyonel sunucusuz Postgres motoru Lakebase'in bu duvarı yıktığını savunuyor.

Veritabanlarının üçüncü nesli

Yazar Lakebase'i bir başka yönetilen Postgres örneği değil, yeni bir kategori olarak konumlandırıyor. Önceki veritabanları monolitler ya da depolamayı tescilli tutan bulut sistemleriydi; Lakebase üçüncü nesil olarak tanımlanıyor: göl üzerinde açık formatlı depolama ile sunucusuz, geçici Postgres işlem gücünün birleşimi.

Dallanma, scale-to-zero ve zero-ETL

Üç mimari özellik var. Copy-on-write dallanma, üretim verisini klonlamak için geleneksel ortamların ihtiyaç duyduğu saatler yerine milisaniyeler içinde eksiksiz ve yalıtılmış kopyalar oluşturuyor; geliştiriciler ve AI ajanları şema değişikliklerini test edip ortamları anında kaldırabiliyor.

Ayrıştırılmış işlem gücü, örneklerin bir saniyeden kısa sürede başlamasını ve boştayken sıfıra inmesini sağlıyor; bu da dalgalı ajan iş yüklerini kullanıma dayalı tüketime taşıyor. İşlemsel veri lakehouse'un okuyabildiği formatlarda yazıldığı için ekiplerin analitik sorgular ya da LLM'ler için özellik depolarını beslemek üzere CDC veya ETL hatlarına ihtiyacı kalmıyor: Spark, Databricks SQL ve Delta Lake canlı veriyi doğrudan sorguluyor.

Veri ve AI mühendisleri için ne anlama geliyor

Birleşik yönetişim altında işlemsel ve analitik tablolar Unity Catalog üzerinden aynı erişim kontrolüne, güvenlik politikalarına ve soy izlemeye tabi olabiliyor. Yazar AI ajanı belleğini de öne çıkarıyor: ajanlar durum yönetimine, pgvector ile vektör aramaya ve hızlı sorgulara ihtiyaç duyuyor.

Sonuç bitmiş bir ürün değil bir yön: kurumlar otonom ajanlara ve gerçek zamanlı hatlara geçtikçe alttaki veritabanı da evrilmek zorunda — açık, gerçek zamanlı, sunucusuz ve AI-yerel platformlara doğru.