Selama beberapa dekade, organisasi harus memelihara dua dunia terpisah untuk data mereka. Sistem Online Transactional Processing (OLTP) menangani operasi sehari-hari—pesanan, pembaruan inventaris, catatan pelanggan—sementara sistem Online Analytical Processing (OLAP) menjalankan pelaporan, dasbor, dan pelatihan model. Memindahkan data di antara keduanya membutuhkan pipeline extract, transform, and load (ETL), yang menimbulkan latensi, biaya, dan masalah tata kelola.

LTAP bertujuan menyatukan beban kerja ini pada satu salinan data yang disimpan di data lake. Menurut Databricks, arsitektur ini menghilangkan ETL, replika, dan pergerakan data secara desain . Data transaksional tersedia untuk analitik secara instan, tanpa transformasi atau pemeliharaan pipeline.

Fondasi dari LTAP adalah Lakebase, layanan Postgres serverless Databricks yang dibangun di atas penyimpanan objek terbuka. Lakebase saat ini sudah melayani ribuan pelanggan dan menangani 12 juta peluncuran database per hari di seluruh platform . Dalam model LTAP, Lakebase menyimpan data langsung di Unity Catalog menggunakan format terbuka—Delta Lake dan Apache Iceberg—sehingga data transaksional yang diatur tata kelolanya dapat langsung di-query untuk beban kerja analitik .

Perusahaan menjelaskan beberapa properti kunci untuk arsitektur ini: tata kelola terpadu dengan satu sumber kebenaran, penskalaan independen untuk beban kerja transaksional dan analitik, semantik ACID penuh untuk beban kerja Postgres, dan tidak ada pipeline atau konektor tersembunyi untuk dipelihara .

Kemampuan Baru Lakebase

Sejalan dengan pengumuman LTAP, Databricks mengungkapkan beberapa peningkatan pada Lakebase itu sendiri:

• Pemulihan bencana lintas-cloud dan lintas-wilayah untuk database Postgres produksi.
• Branching dan snapshot gaya Git, memungkinkan eksperimen aman langsung pada data produksi.
• Operasi database otonom yang memantau perlambatan, mendeteksi anomali, dan memicu pemulihan otomatis .

Fitur-fitur ini menandakan niat Databricks untuk menjadikan Postgres serverless sebagai database operasional kelas satu untuk aplikasi dan AI agen, bukan sekadar lapisan kemudahan untuk analitik.

Lakehouse//RT: Analitik Real-Time pada Data yang Diatur

Pengumuman infrastruktur besar kedua adalah Lakehouse//RT, sebuah lakehouse real-time yang didukung oleh mesin komputasi baru bernama Reyden (singkatan dari "Reynold's Dream Engine", dinamai dari salah satu pendiri, Reynold Xin) . Databricks menyatakan Reyden memberikan latensi kueri milidetik pada puluhan ribu pengguna dan agen secara bersamaan, berjalan langsung di atas tabel Delta Lake dan Apache Iceberg yang diatur .

Implikasinya signifikan: perusahaan tidak perlu lagi menyiapkan infrastruktur penyajian terpisah—seperti lapisan cache, materialized view, atau mesin kueri eksternal—untuk mencapai kinerja real-time. Sigma Computing bergabung sebagai mitra peluncuran, terhubung langsung ke Lakehouse//RT untuk analitik tertanam .

Salah satu pendiri Databricks, Reynold Xin, menggambarkan peluncuran ini sebagai "mungkin pengenalan tunggal terbesar yang kami lakukan sejak peluncuran Lakehouse" .

Dorongan Agen: Genie One, Agent Bricks, dan Perangkat AI yang Lebih Luas

Databricks menggunakan konferensi ini untuk memposisikan platformnya sebagai fondasi bagi AI agen perusahaan. Pengumumannya meliputi:

• Genie One: Rekan kerja agen AI yang dirancang untuk membantu tim bisnis mengotomatiskan pekerjaan yang didasarkan pada data bisnis nyata, dengan peningkatan untuk konteks agen .
• Genie Agents dan Agent Bricks: Alat untuk membangun dan menerapkan AI agen yang dapat mengamati, menalar, dan bertindak di seluruh data perusahaan. Agent Bricks adalah komponen pra-bangun yang mengoptimalkan agen secara otomatis menggunakan data yang diatur .
• Unity AI Gateway: Tata kelola multi-AI dan kontrol biaya untuk organisasi yang mengelola beberapa penyedia model AI .

Narasi yang lebih luas, seperti yang ditangkap oleh analis industri, adalah bahwa LTAP dan Lakehouse//RT adalah lapisan penyajian data di bawah arsitektur perusahaan agen. Dengan menempatkan data operasional dalam format terbuka pada penyimpanan yang diatur, Databricks percaya AI agen dapat mengakses, menalar, dan bertindak pada database produksi tanpa memindahkan atau menyalin data .

Integrasi Azure dan Microsoft

Databricks memperdalam integrasi ekosistem Azure dengan beberapa kemampuan yang diumumkan bersama:

• Copilot Studio dan GitHub Copilot: Pengguna dapat membuat agen Copilot Studio yang menalar seluruh ruang kerja Azure Databricks melalui satu koneksi MCP (Model-Centric-Protocol) .
• Genie untuk Microsoft Teams dan M365 Copilot (Beta): Pengguna dapat menandai Genie di utas Teams dan menerima jawaban yang sadar konteks langsung dari lingkungan Azure Databricks mereka .
• Azure Databricks Excel Add-in (Public Preview) dan ingesti Excel native (GA) memungkinkan analitik tanpa pengemudi dari spreadsheet .
• Databricks CustomerLake: Platform data pelanggan lakehouse-native pertama, diperkenalkan untuk Azure Databricks .

Integrasi ini menunjukkan strategi untuk menyematkan kemampuan tata kelola dan AI Databricks ke dalam alat kolaborasi tempat keputusan bisnis terjadi, tanpa mengharuskan pengguna beralih ke antarmuka analitik terpisah.

Apa Artinya Ini bagi Arsitektur Data Perusahaan

Secara kolektif, pengumuman di konferensi ini mewakili taruhan platform yang koheren: bahwa generasi aplikasi perusahaan berikutnya akan bersifat agen, real-time, dan diatur tata kelolanya. LTAP menghilangkan pemisah transaksional-analitik, Lakehouse//RT menghilangkan kompromi latensi untuk kueri analitik, dan keluarga Genie menyediakan lapisan orkestrasi agen.

Jika berhasil, arsitektur ini dapat mengurangi jumlah bagian yang bergerak dalam tumpukan data perusahaan pada umumnya—lebih sedikit database, lebih sedikit pipeline, lebih sedikit lapisan penyajian—sambil menyediakan AI agen dengan konteks yang diatur dan real-time yang mereka butuhkan untuk bertindak secara otonom pada data bisnis.

Databricks tidak sendirian dalam mengejar konvergensi ini, tetapi dengan Lakebase yang sudah mencapai 12 juta peluncuran database harian dan konferensi yang diperkuat oleh 30.000 peserta, pengumuman LTAP menandai tonggak penting dalam evolusi arsitektur lakehouse dari platform analitik menjadi tulang punggung data operasional .

Selama beberapa dekade, organisasi harus memelihara dua dunia terpisah untuk data mereka. Sistem Online Transactional Processing (OLTP) menangani operasi sehari-hari—pesanan, pembaruan inventaris, catatan pelanggan—sementara sistem Online Analytical Processing (OLAP) menjalankan pelaporan, dasbor, dan pelatihan model. Memindahkan data di antara keduanya membutuhkan pipeline extract, transform, and load (ETL), yang menimbulkan latensi, biaya, dan masalah tata kelola.

LTAP bertujuan menyatukan beban kerja ini pada satu salinan data yang disimpan di data lake. Menurut Databricks, arsitektur ini menghilangkan ETL, replika, dan pergerakan data secara desain . Data transaksional tersedia untuk analitik secara instan, tanpa transformasi atau pemeliharaan pipeline.

Fondasi dari LTAP adalah Lakebase, layanan Postgres serverless Databricks yang dibangun di atas penyimpanan objek terbuka. Lakebase saat ini sudah melayani ribuan pelanggan dan menangani 12 juta peluncuran database per hari di seluruh platform . Dalam model LTAP, Lakebase menyimpan data langsung di Unity Catalog menggunakan format terbuka—Delta Lake dan Apache Iceberg—sehingga data transaksional yang diatur tata kelolanya dapat langsung di-query untuk beban kerja analitik .

Perusahaan menjelaskan beberapa properti kunci untuk arsitektur ini: tata kelola terpadu dengan satu sumber kebenaran, penskalaan independen untuk beban kerja transaksional dan analitik, semantik ACID penuh untuk beban kerja Postgres, dan tidak ada pipeline atau konektor tersembunyi untuk dipelihara .

Kemampuan Baru Lakebase

Sejalan dengan pengumuman LTAP, Databricks mengungkapkan beberapa peningkatan pada Lakebase itu sendiri:

• Pemulihan bencana lintas-cloud dan lintas-wilayah untuk database Postgres produksi.
• Branching dan snapshot gaya Git, memungkinkan eksperimen aman langsung pada data produksi.
• Operasi database otonom yang memantau perlambatan, mendeteksi anomali, dan memicu pemulihan otomatis .

Fitur-fitur ini menandakan niat Databricks untuk menjadikan Postgres serverless sebagai database operasional kelas satu untuk aplikasi dan AI agen, bukan sekadar lapisan kemudahan untuk analitik.

Lakehouse//RT: Analitik Real-Time pada Data yang Diatur

Pengumuman infrastruktur besar kedua adalah Lakehouse//RT, sebuah lakehouse real-time yang didukung oleh mesin komputasi baru bernama Reyden (singkatan dari "Reynold's Dream Engine", dinamai dari salah satu pendiri, Reynold Xin) . Databricks menyatakan Reyden memberikan latensi kueri milidetik pada puluhan ribu pengguna dan agen secara bersamaan, berjalan langsung di atas tabel Delta Lake dan Apache Iceberg yang diatur .

Implikasinya signifikan: perusahaan tidak perlu lagi menyiapkan infrastruktur penyajian terpisah—seperti lapisan cache, materialized view, atau mesin kueri eksternal—untuk mencapai kinerja real-time. Sigma Computing bergabung sebagai mitra peluncuran, terhubung langsung ke Lakehouse//RT untuk analitik tertanam .

Salah satu pendiri Databricks, Reynold Xin, menggambarkan peluncuran ini sebagai "mungkin pengenalan tunggal terbesar yang kami lakukan sejak peluncuran Lakehouse" .

Dorongan Agen: Genie One, Agent Bricks, dan Perangkat AI yang Lebih Luas

Databricks menggunakan konferensi ini untuk memposisikan platformnya sebagai fondasi bagi AI agen perusahaan. Pengumumannya meliputi:

• Genie One: Rekan kerja agen AI yang dirancang untuk membantu tim bisnis mengotomatiskan pekerjaan yang didasarkan pada data bisnis nyata, dengan peningkatan untuk konteks agen .
• Genie Agents dan Agent Bricks: Alat untuk membangun dan menerapkan AI agen yang dapat mengamati, menalar, dan bertindak di seluruh data perusahaan. Agent Bricks adalah komponen pra-bangun yang mengoptimalkan agen secara otomatis menggunakan data yang diatur .
• Unity AI Gateway: Tata kelola multi-AI dan kontrol biaya untuk organisasi yang mengelola beberapa penyedia model AI .

Narasi yang lebih luas, seperti yang ditangkap oleh analis industri, adalah bahwa LTAP dan Lakehouse//RT adalah lapisan penyajian data di bawah arsitektur perusahaan agen. Dengan menempatkan data operasional dalam format terbuka pada penyimpanan yang diatur, Databricks percaya AI agen dapat mengakses, menalar, dan bertindak pada database produksi tanpa memindahkan atau menyalin data .

Integrasi Azure dan Microsoft

Databricks memperdalam integrasi ekosistem Azure dengan beberapa kemampuan yang diumumkan bersama:

• Copilot Studio dan GitHub Copilot: Pengguna dapat membuat agen Copilot Studio yang menalar seluruh ruang kerja Azure Databricks melalui satu koneksi MCP (Model-Centric-Protocol) .
• Genie untuk Microsoft Teams dan M365 Copilot (Beta): Pengguna dapat menandai Genie di utas Teams dan menerima jawaban yang sadar konteks langsung dari lingkungan Azure Databricks mereka .
• Azure Databricks Excel Add-in (Public Preview) dan ingesti Excel native (GA) memungkinkan analitik tanpa pengemudi dari spreadsheet .
• Databricks CustomerLake: Platform data pelanggan lakehouse-native pertama, diperkenalkan untuk Azure Databricks .

Integrasi ini menunjukkan strategi untuk menyematkan kemampuan tata kelola dan AI Databricks ke dalam alat kolaborasi tempat keputusan bisnis terjadi, tanpa mengharuskan pengguna beralih ke antarmuka analitik terpisah.

Apa Artinya Ini bagi Arsitektur Data Perusahaan

Secara kolektif, pengumuman di konferensi ini mewakili taruhan platform yang koheren: bahwa generasi aplikasi perusahaan berikutnya akan bersifat agen, real-time, dan diatur tata kelolanya. LTAP menghilangkan pemisah transaksional-analitik, Lakehouse//RT menghilangkan kompromi latensi untuk kueri analitik, dan keluarga Genie menyediakan lapisan orkestrasi agen.

Jika berhasil, arsitektur ini dapat mengurangi jumlah bagian yang bergerak dalam tumpukan data perusahaan pada umumnya—lebih sedikit database, lebih sedikit pipeline, lebih sedikit lapisan penyajian—sambil menyediakan AI agen dengan konteks yang diatur dan real-time yang mereka butuhkan untuk bertindak secara otonom pada data bisnis.

Databricks tidak sendirian dalam mengejar konvergensi ini, tetapi dengan Lakebase yang sudah mencapai 12 juta peluncuran database harian dan konferensi yang diperkuat oleh 30.000 peserta, pengumuman LTAP menandai tonggak penting dalam evolusi arsitektur lakehouse dari platform analitik menjadi tulang punggung data operasional .