• Một bản copy duy nhất phục vụ cả giao dịch lẫn phân tích, định dạng mở
• Loại bỏ pipeline CDC sao chép dữ liệu giữa OLTP và OLAP
• Lakebase xử lý 12 triệu lượt khởi tạo database mỗi ngày
• Thêm DR xuyên cloud/region, snapshot và branching kiểu git dưới 1 giây
• Lakebase Search (beta): vector + full-text, nén 32x cho 1 tỉ+ vector index

Đây là tuyên bố kiến trúc táo bạo nhất Summit. Cả ngành lâu nay sống chung với một sự thật khó chịu: cơ sở dữ liệu giao dịch và kho phân tích là hai thế giới, nối với nhau bằng một mớ CDC và ETL luôn trễ vài phút tới vài giờ. LTAP nói: gộp luôn, một bản dữ liệu, một quyền quản trị. Với agent thì điều này rất quan trọng — agent không chỉ đọc báo cáo cũ, nó ghi trạng thái, đặt đơn, cập nhật hồ sơ ngay lúc đó, nên độ trễ đồng bộ là kẻ thù. Lakebase nền tảng phía dưới đã chạy 12 triệu lượt khởi tạo mỗi ngày, kèm branching kiểu git dưới một giây — nghĩa là tạo bản sao môi trường để thử nghiệm gần như tức thì. Với doanh nghiệp Việt, đừng vội thay stack: hãy theo dõi LTAP như tín hiệu hướng đi, vì nếu mô hình "một copy" chứng minh được ở quy mô lớn, ranh giới giữa kỹ sư backend và kỹ sư dữ liệu sẽ mờ dần.

• Lakeflow Connect: hơn 100 connector quản lý cho app, DB, file, cloud storage
• Lakeflow Designer GA: kéo-thả no-code + ngôn ngữ tự nhiên, sinh code chuẩn
• Zerobus: ghi gần realtime <5s, throughput tới 100MB/s, hơn 10GB/s mỗi bảng
• Real-Time Mode (preview): độ trễ end-to-end thấp tới 5 mili-giây
• Free Tier Connect: 100 DBU/ngày, xử lý tới 100 triệu bản ghi

Lakeflow Designer GA là tin đáng chú ý nhất với analyst: kéo-thả dựng pipeline nhưng phía sau là code sản xuất do Unity Catalog quản trị, tức là analyst làm được việc của data engineer mà không sinh ra "shadow pipeline" mất kiểm soát. Con số 5 mili-giây cho Real-Time Mode đẩy Spark vào sân chơi vốn là của Flink — streaming độ trễ siêu thấp. Điểm thực dụng: ai đang gánh một rừng tool ingestion (Fivetran chỗ này, Airflow chỗ kia, script chỗ nọ) thì đây là lời mời gộp lại. Nhưng cũng nên tỉnh táo — gộp về một vendor đổi lấy sự tiện lợi luôn kèm cái giá khóa chân. Genie ZeroOps là mảnh đáng thử trước: để agent tự dò nguyên nhân job lỗi và đề xuất fix trong sandbox, đỡ những đêm trực pipeline.

• Postgres serverless trên object storage mở, gắn chặt với lakehouse
• Branching và snapshot kiểu git, thao tác dưới một giây
• Disaster recovery xuyên cloud và xuyên region
• Lakebase Search (beta): vector + full-text, nén 32x, 1 tỉ+ vector index
• Quy mô 12 triệu lượt khởi tạo database mỗi ngày

Lakebase là viên gạch nền cho cả câu chuyện LTAP, nên loạt nâng cấp này không chỉ là tính năng lẻ. Lakebase Search đặc biệt đáng để ý: thay vì dựng thêm một vector database riêng (Pinecone, Weaviate…) cạnh Postgres, giờ retrieval lai nằm ngay trong DB vận hành — đỡ một hệ thống, đỡ một pipeline đồng bộ embedding. Nén 32x cho hơn một tỉ vector là con số nhắm thẳng vào bài toán RAG quy mô doanh nghiệp với chi phí thấp. Branching dưới một giây thì giải đúng nỗi đau muôn thuở: muốn test trên dữ liệu thật mà không dám đụng production. Với team Việt đang xây app có RAG, mô hình "Postgres lo cả giao dịch lẫn tìm kiếm ngữ nghĩa" đáng đưa vào danh sách đánh giá thử.

• Managed table đọc/ghi cả Delta lẫn Iceberg, bỏ khóa định dạng bảng
• OpenSharing trở thành dự án Linux Foundation, quản trị trung lập
• Iceberg REST catalog đọc share OpenSharing qua OIDC federation
• SecureConnect và Global Distribution nhân bản xuyên region tự động
• Mở rộng chia sẻ cả model, agent skill và Genie Agents

Cuộc chiến định dạng bảng (Delta vs Iceberg) về cơ bản đã ngã ngũ theo hướng "cả hai cùng tồn tại", và Databricks chọn cách thực dụng: để managed table nói được cả hai thứ tiếng. Quan trọng hơn là việc trao OpenSharing cho Linux Foundation — bài học từ lịch sử mở mã nguồn cho thấy chuẩn nào được quản trị trung lập thì dễ được đối thủ và khách hàng chấp nhận hơn. Với interoperability qua Iceberg REST + OIDC, bên nhận dữ liệu không cần là khách Databricks, chỉ cần engine đọc được Iceberg. Với doanh nghiệp Việt trao đổi dữ liệu giữa các nền tảng khác nhau, đây là tín hiệu nên chuẩn hóa quanh Iceberg REST catalog thay vì khóa cứng vào một vendor — và theo dõi xem Snowflake phản ứng thế nào ở mảng chia sẻ.

• Metrics: định nghĩa KPI một lần, dùng từ SQL, BI, API và agent
• Semantic modeling đa fact, tính toán level-of-detail (LOD)
• Metric tham số hóa, window measure cho phân tích kỳ-so-kỳ dễ hơn
• Business Glossary (preview) và Domains (public preview)
• Lớp ngữ nghĩa người dùng định nghĩa nuôi trực tiếp Genie Ontology

Bài học đắt giá của mọi tổ chức làm BI là "mỗi phòng một định nghĩa doanh thu". Metrics trong Unity Catalog đưa định nghĩa lên tầng quản trị trung tâm, để con người và agent đều lấy cùng một con số — điều kiện tiên quyết để tin được câu trả lời của một agent phân tích. Multi-fact và LOD nghe khô khan nhưng là thứ analyst cần để mô hình hóa nghiệp vụ thật (ví dụ doanh thu theo đơn nhưng chi phí theo dòng sản phẩm). Đáng chú ý là mối nối Metrics → Genie Ontology: lớp ngữ nghĩa do người định nghĩa làm "khung xương", còn Ontology tự học làm "phần thịt". Với team Việt, lời khuyên thực tế: đầu tư semantic layer trước khi thả agent vào dữ liệu, vì agent thông minh đến mấy cũng trả lời sai nếu định nghĩa nghiệp vụ còn loạn.

• Kiểm soát chi phí và smart routing giữa các model
• Guardrail chặn PII và prompt injection ở tầng runtime
• Chính sách dịch vụ theo ngữ cảnh, tracing thống nhất
• Đối tác: CrowdStrike, Palo Alto Networks, Okta, Zscaler, Netskope
• Đi kèm các nâng cấp bảo mật AIM, Okta, Context-Based Ingress

Đây là mảnh ghép ít hào nhoáng nhưng quyết định việc agent có được lên production hay không. Một agent tự do gọi LLM mà không có cổng kiểm soát là cơn ác mộng vừa về hóa đơn vừa về rò rỉ dữ liệu. AI Gateway đứng giữa, làm ba việc: routing để chọn model rẻ/khỏe phù hợp, guardrail để không cho PII lọt ra hay prompt injection lọt vào, và tracing để truy vết khi có sự cố. Việc kéo theo CrowdStrike, Palo Alto, Okta cho thấy Databricks muốn nói chuyện được với đội bảo mật doanh nghiệp lớn. Với CIO/CISO Việt đang lo "thả agent vào dữ liệu nội bộ thì kiểm soát kiểu gì", đây chính là loại lớp hạ tầng cần dựng trước khi nhân rộng, dù dùng vendor nào đi nữa.

• AI/BI: theme, 20+ font, Gantt, choropleth map, cross-filter, drill-through
• Subscription dashboard qua Slack và Teams
• Genie Code: quản lý thread song song, tích hợp MLflow/Model Serving
• Tác vụ nền theo lịch, chạy ngầm cho phân tích lặp lại
• Import report Tableau/Power BI sang AI/BI dashboard (beta)

Databricks đang tấn công vào sân nhà của Tableau và Power BI bằng hai mũi: làm AI/BI đủ tính năng để không thua kém về trực quan hóa (choropleth, cross-filter, drill-through là những thứ analyst đòi hỏi), rồi mở luôn đường nhập khẩu dashboard cũ sang. Đây là chiến thuật kinh điển khi muốn chiếm thị phần: giảm chi phí chuyển đổi xuống gần bằng không. Với Genie Code, việc chạy nhiều thread song song và đặt tác vụ nền theo lịch biến nó từ "trợ lý hỏi-đáp" thành "công nhân chạy ngầm". Tại Việt Nam nơi Power BI thống trị, đừng kỳ vọng migrate ồ ạt ngay — nhưng nếu tổ chức đã đứng trên Databricks, thử nhập một vài dashboard quan trọng sang để đo công sức thực tế là bước đi hợp lý.

• 100.000+ agent đã dựng, hơn một triệu tỉ token mỗi năm
• Model: OpenAI, Anthropic, Gemini, Kimi, Grok (hợp tác SpaceX)
• Hỗ trợ mọi harness: LangGraph, CrewAI, Claude Code SDK
• Managed memory trên Lakebase: agent tự giữ ngữ cảnh, lịch sử phiên
• Omnigent: meta-harness mã nguồn mở Apache 2.0, đặt ngân sách chi phí

Đằng sau những con số khổng lồ là một thay đổi tư duy: Databricks không ép bạn dùng framework của họ mà chấp nhận mọi harness và mọi model, kể cả Grok và Kimi. Đây là canh bạc "làm tầng nền, đừng làm tù ngục" — họ muốn là nơi agent chạy, giữ memory và bị quản trị, còn bạn tự do chọn não. Managed memory trên Lakebase là mảnh quan trọng nhất: vấn đề lớn nhất của agent production không phải model mà là ngữ cảnh — nhớ gì, qua phiên nào, ai được thấy. Omnigent mã nguồn mở Apache 2.0 cho phép đặt ngân sách chi phí và chính sách theo ngữ cảnh, gãi đúng nỗi lo "agent đốt tiền không phanh". Với đội kỹ thuật Việt xây agent nội bộ, bài học là: đừng tự dựng lớp memory và governance từ đầu, hãy tách phần "não" (model) khỏi phần "hạ tầng" (memory, sandbox, cost control).

• Genie One: đồng nghiệp AI trên web, iOS, Android, Slack, Teams
• Genie Ontology: knowledge graph tự học từ bảng, dashboard, query, 50+ app
• Đúng 84,5% câu hỏi nhân viên lần đầu, so với 52,4% agent code thường
• Genie Agents: suy luận trên dữ liệu phi cấu trúc, gọi tool ngoài, chia sẻ qua OpenSharing
• Pay-as-you-go; từ 06/07 tặng 150 DBU miễn phí mỗi user/tháng

Đây là sản phẩm flagship của Summit và là thông điệp rõ nhất về chiến lược Databricks: cuộc đua giờ không phải model nào thông minh nhất, mà nền tảng nào hiểu nghiệp vụ của bạn nhất. Genie Ontology là câu trả lời — một knowledge graph tự cải thiện, hút ngữ cảnh từ bảng, dashboard, query và hơn 50 app công sở để biết "doanh thu" trong công ty bạn nghĩa là gì. Con số 84,5% so với 52,4% là bằng chứng cho luận điểm "context layer ăn đứt model thuần" — cùng một model nhưng có ngữ cảnh đúng thì độ tin cậy nhảy vọt. Đây là vũ khí trực diện đấu Copilot của Microsoft và Cortex của Snowflake. Với doanh nghiệp Việt, bài học áp dụng được ngay kể cả khi không dùng Databricks: muốn agent trả lời đáng tin, đầu tư vào việc codify ngữ cảnh nghiệp vụ quan trọng hơn là săn model mới nhất.

• CDP đầu tiên nhúng thẳng trong lakehouse, không cần copy dữ liệu
• Profile Agent dựng và làm giàu hồ sơ khách hàng tự động
• Campaign Agent kích hoạt chiến dịch cá nhân hóa 1:1
• Toàn bộ được Unity Catalog quản trị, đồng nhất quyền và dòng dõi dữ liệu

CustomerLake cho thấy tham vọng của Databricks lan sang cả lớp ứng dụng nghiệp vụ, không chỉ hạ tầng. Logic rất hợp lý: dữ liệu khách hàng vốn đã nằm trong lakehouse, vậy tại sao phải copy sang một CDP như Segment hay Adobe rồi đồng bộ ngược? Đặt CDP ngay tại chỗ, agent kích hoạt chiến dịch trên dữ liệu gốc được Unity Catalog quản trị — đỡ một silo, đỡ rủi ro lệch dữ liệu giữa nơi phân tích và nơi kích hoạt. Đây là tin đáng chú ý cho team martech và growth tại Việt Nam đang vật lộn với việc dữ liệu khách hàng rải rác. Tuy nhiên cần thực tế: thay một CDP đã chạy không đơn giản, nên xem CustomerLake như lựa chọn cho dự án mới hoặc khi đang tính dựng CDP đầu tiên trên nền lakehouse.

• Luận điểm trung tâm: lakehouse là tầng vận hành có quản trị cho agent
• Sáu nhu cầu: ngữ cảnh quản trị, realtime, nhất quán giao dịch, kiểm soát runtime, chi phí minh bạch, thực thi tin cậy
• Gắn kết các mảnh: Gateway, LTAP, Lakehouse//RT, Genie, CustomerLake
• Databricks mở rộng vai trò sang surface vận hành quanh enterprise AI

Giá trị của bài này nằm ở việc nó kéo hàng chục công bố rời rạc về một câu chuyện duy nhất: lakehouse không còn chỉ để phân tích, nó đang biến thành nơi agent sống và làm việc. Nếu khung này đúng, mọi quyết định kiến trúc dữ liệu trong năm tới sẽ phải trả lời câu hỏi "lớp này có phục vụ được agent realtime, có quản trị được, có kiểm soát chi phí không". Đó cũng là lăng kính để đọc Snowflake, Microsoft Fabric hay BigQuery — ai cũng đang chạy về cùng một đích. Với người làm dữ liệu Việt, đừng đọc Summit như danh sách tính năng mà như bản đồ hướng đi: kỹ năng quản trị ngữ cảnh, semantic layer và governance đang trở thành phần giá trị nhất của nghề, hơn cả việc viết pipeline.

• Databricks mở rộng từ nền tảng dữ liệu sang trọn agentic stack
• Bao gồm OLTP, real-time serving, AI coworker, coding agent, CDP, ZeroOps
• Mục tiêu: chiếm phần "surface vận hành" quanh enterprise AI
• Đặt ra câu hỏi hợp nhất sức mạnh vs rủi ro khóa chân vendor

Điểm hay của Moor Insights là không bị cuốn theo hào quang sân khấu. "Sở hữu trọn stack" nghe tuyệt vời với Databricks nhưng với khách hàng nó là con dao hai lưỡi: tích hợp liền mạch đổi lấy phụ thuộc sâu. Một tổ chức để LTAP làm DB, Genie làm BI, Agent Bricks làm agent, CustomerLake làm CDP thì sau ba năm gần như không thể rời đi. Bài học cho lãnh đạo dữ liệu Việt: tận dụng sự tiện lợi nhưng giữ vài điểm thoát — chuẩn hóa quanh định dạng mở (Iceberg), tách logic nghiệp vụ khỏi công cụ, và đừng để mọi lớp đều thuộc một nhà cung cấp. Hợp nhất là xu hướng tất yếu của thị trường năm nay, nhưng "hợp nhất khôn ngoan" khác với "khóa chân tự nguyện".

• Chủ đề Day 2: agentic AI và catalog federation lên mức enterprise
• Governance và liên thông catalog thành điều kiện triển khai diện rộng
• Agent chuyển từ demo sang workload sản xuất
• Doanh nghiệp quan tâm độ tin cậy, quản trị và chi phí hơn là tính năng

Điểm đáng nhớ trong tường thuật này là sự dịch chuyển trọng tâm câu hỏi của doanh nghiệp. Năm ngoái người ta hỏi "agent làm được gì"; năm nay câu hỏi là "làm sao tin được, quản trị thế nào, tốn bao nhiêu". Catalog federation — khả năng liên thông nhiều catalog mà không phải gom hết về một chỗ — nổi lên vì thực tế doanh nghiệp lớn không bao giờ có một catalog duy nhất. Với team dữ liệu Việt, tín hiệu thực tế là: nếu đang định thử agent phân tích nội bộ, 2026 là thời điểm hợp lý để chuyển từ POC sang triển khai có kiểm soát, nhưng phải dựng governance và semantic layer trước, đừng thả agent vào dữ liệu loạn.

• Databricks cược vào data science và AI-native adoption
• Snowflake cược vào chuẩn hóa do IT dẫn dắt
• Triển khai lai (dùng cả hai) ngày càng phổ biến ở doanh nghiệp lớn
• Cả hai đều dồn lực vào agentic AI và semantic layer mùa Summit

Thực tế ít ai nói thẳng: phần lớn doanh nghiệp lớn cuối cùng dùng cả hai, mỗi nền cho một thế mạnh. Snowflake mạnh ở trải nghiệm SQL warehouse mượt và quản trị do IT dẫn dắt; Databricks mạnh ở data engineering, ML và giờ là agentic stack. Với doanh nghiệp Việt, đừng sa vào tranh luận "ai thắng" mà hỏi tổ chức mình nghiêng về đâu: nếu mạnh đội data science và muốn AI-native, Databricks hợp hơn; nếu cần chuẩn hóa, governance do IT kiểm soát chặt, Snowflake dễ vào hơn. Điểm chung quan trọng nhất: cả hai đang hội tụ về Iceberg và semantic layer, nên đầu tư vào kỹ năng và chuẩn mở sẽ dùng được dù chọn nền nào.

• Mua lại Panther: AI SOC, 100+ tích hợp sẵn, detection-as-code
• LakeWatch: SIEM agentic trên Unity Catalog và OCSF
• Agent tự triage cảnh báo, gom ngữ cảnh, đề xuất bước xử lý
• Hứa giảm tới 80% TCO so với SIEM truyền thống
• Panther vốn được các đội bảo mật hàng đầu, gồm cả Anthropic, tin dùng

Đây là thương vụ M&A đáng chú ý nhất tuần và mở ra một mặt trận mới: "security lakehouse". Logic kinh tế rất rõ — log bảo mật là khối dữ liệu khổng lồ, và SIEM truyền thống như Splunk tính tiền theo lượng nuốt vào nên đắt khủng khiếp. Đổ log thẳng vào lakehouse, dùng compute rẻ và để agent tự triage là công thức giảm chi phí mạnh, con số 80% TCO tuy là tuyên bố vendor nhưng hướng đi hợp lý. Việc Panther được chính Anthropic tin dùng là tín hiệu uy tín. Với CISO và đội SOC Việt Nam đang đau đầu vì hóa đơn SIEM, đây là lựa chọn cần theo dõi — nhất là khi muốn gắn AI agent vào quy trình điều tra. Mặt cần soi: chuyển SIEM là việc lớn, và detection-as-code đòi kỹ năng kỹ sư chứ không chỉ analyst bảo mật.

• Free Edition đã có hơn 500.000 người dùng
• Thêm: Genie Code, serverless GPU, Lakebase, Agent Bricks, Lakeflow Designer
• Thử nghiệm gần trọn ngăn xếp agentic mà không tốn phí
• Chiến lược bottom-up: nuôi developer làm quen nền tảng từ sớm

Đừng xem nhẹ tin "miễn phí" này — nó là vũ khí tăng trưởng. Cho sinh viên, developer và startup dùng serverless GPU cùng Agent Bricks không tốn tiền nghĩa là vài năm nữa cả một thế hệ kỹ sư sẽ thành thạo Databricks trước khi vào doanh nghiệp. Đây đúng kịch bản mà Snowflake, MongoDB hay Postgres từng làm. Với cộng đồng dữ liệu Việt Nam — nơi chi phí cloud luôn là rào cản học tập — Free Edition mở rộng là cơ hội thật để thực hành agentic data engineering, RAG trên Lakebase và thử model trên serverless GPU mà không phải xin ngân sách. Lời khuyên: tận dụng để học và dựng portfolio, nhưng khi lên production hãy tính kỹ chi phí thật và bài toán khóa chân.

• App phân phối tới hơn 20.000 khách hàng, IP được bảo vệ
• Dùng tới 10% Universal Commits mua sản phẩm đối tác đủ điều kiện
• App Spaces làm ranh giới quản trị quyền và bảo mật
• Serverless Micro Apps: runtime nhẹ, tự scale về 0 khi rảnh

Tin này dành cho các công ty phần mềm và ISV hơn là người dùng cuối, nhưng tác động dài hạn lớn. Khi khách hàng được dùng ngân sách cam kết sẵn để mua app đối tác ngay trong Marketplace, rào cản bán hàng giảm hẳn — đối tác bán được hàng mà khách không phải mở quy trình mua sắm mới. Đây là cách Databricks biến nền tảng thành một nền kinh tế, giống AWS Marketplace từng làm. Với startup và công ty phần mềm dữ liệu Việt Nam muốn tiếp cận thị trường quốc tế, xây sản phẩm chạy trên Databricks và lên Marketplace là một kênh phân phối đáng cân nhắc nghiêm túc — tiếp cận hơn 20.000 khách hàng doanh nghiệp là con số không nhỏ.