• Iceberg khởi động lại đề xuất bỏ equality deletes khỏi spec v4.
• Flink hoàn tất chuyển equality delete sang deletion vector — đã có đường thay thế.
• Iceberg Terraform Provider v0.1.0 ra bản đầu, đóng gói cho Terraform và OpenTofu.
• Mở thảo luận kiểu vector hạng nhất (dense, số chiều cố định) cho embedding.
• Đề xuất thêm Vortex làm định dạng file mới; DataFusion 54.1.0 RC.

Đây là loại tin không lên LinkedIn nhưng quyết định hoá đơn cloud của bạn ba năm tới. Đọc dev-list là đọc trước bản đồ, vì mọi thứ vendor sắp bán ra đều bắt đầu từ những cuộc bỏ phiếu này. Ba tín hiệu tuần này đi cùng một hướng: Iceberg dọn nợ bằng cách bỏ cơ chế equality deletes cũ khi đã có deletion vector nhanh hơn; Terraform Provider ra đời nghĩa là bảng Iceberg giờ quản lý được bằng hạ tầng như mã, đúng cách các đội vận hành nghiêm túc muốn làm; và kiểu vector hạng nhất được đưa ra bàn, tức embedding sắp nằm ngay trong table format. Nghĩa là gì với doanh nghiệp Việt? Nếu bạn đang tính nhét embedding vào một vector database riêng, hãy chờ vài tháng — nhiều khả năng lakehouse sẽ tự lo được, bớt một hệ thống phải vận hành. Đừng vội mua thứ nền tảng sắp có sẵn, và hãy theo dev-list chứ đừng chỉ nghe slide bán hàng.

• Spark 4.2 tập trung vào hiệu năng, streaming và cải thiện hệ sinh thái.
• Nhắm tới pipeline nơi AI agent tiêu thụ dữ liệu tươi và kích hoạt transform.
• Giảm độ trễ và tăng tính dự đoán cho workload real-time.
• Là một trong loạt tin Databricks nổi bật tuần lễ giữa tháng 7.

Spark đã hơn mười tuổi và nhiều người tưởng nó chỉ còn là hạ tầng batch cũ kỹ, nhưng thực tế nó vẫn chạy phần lớn ETL của thế giới doanh nghiệp. Bản 4.2 đáng chú ý không vì một tính năng đắt giá, mà vì hướng đi: uốn một engine sinh ra cho batch về phía streaming và agent. Điều này nghĩa là gì cho đội của bạn? Nếu đang chạy Spark, bạn không phải nhảy sang engine mới để phục vụ agent; con đường nâng cấp tại chỗ vẫn mở. Nhưng đừng nhầm real-time hơn với real-time thật — vẫn phải đo độ trễ trên chính workload của mình trước khi hứa với business. Với đa số team Việt, giá trị lớn nhất của bản này là ổn định và tối ưu, không phải mấy chữ agentic hoa mỹ.

• OOMKill: kernel giết Task Manager, mất việc dở dang, job phải phục hồi từ checkpoint.
• Nguyên nhân: native-memory leak trong block cache RocksDB và phân mảnh jemalloc.
• Sau khi vá: giảm 91,2% Task Manager bị OOMKilled.
• Đỉnh sử dụng bộ nhớ giảm 13%.

Mình thích bài này vì nó là thứ đối lập hoàn toàn với hào nhoáng AI: một người mới vào đội Flink của Confluent ngồi truy tận gốc một lỗi bộ nhớ mà nhiều đội chỉ biết vá bằng cách tăng RAM. OOMKill là cơn ác mộng của streaming: máy bị giết, dữ liệu dở dang mất, job khôi phục từ checkpoint, độ trễ nhảy vọt. Cắt 91,2% số lần OOM không phải là con số marketing, nó là hoá đơn hạ tầng giảm và giấc ngủ của kỹ sư trực đêm được trả lại. Bài học cho team Việt vận hành Flink hay Kafka Streams: khi thấy OOM, đừng vội nhân đôi bộ nhớ, hãy dùng công cụ như jemalloc profiling để tìm rò rỉ native thật. Đây là kiểu kiến thức không mua được bằng vendor, chỉ có bằng đào sâu.

• Gộp OLTP, OLAP và tìm kiếm vector vào một engine duy nhất.
• Nhất quán chuỗi hoá xuyên node, chia sẻ điều khiển đồng thời.
• Hỗ trợ MCP native: agent đọc, ghi, tìm ngữ nghĩa trong một bước.
• Mục tiêu xoá pipeline ETL, giảm chi phí và độ trễ, bớt rủi ro hallucination.
• Gọi 68 triệu USD; nhà đầu tư gồm Frank Slootman, Eyal Waldman.

Đây là tin nóng nhất tuần vì nó chạm đúng giả định nền tảng nhất của nghề. Hai mươi năm nay ta được dạy như kinh thánh: tách database giao dịch khỏi database phân tích, rồi thời AI thêm cả vector database riêng. Mỗi lần tách là một lần copy dữ liệu, một pipeline ETL phải bảo trì, và một chỗ để hai bản dữ liệu lệch nhau lúc hai giờ sáng. RegattaDB lật ngược lập luận: nếu người tiêu thụ dữ liệu giờ là AI agent, và agent cần đọc trạng thái sống, chạy giao dịch rồi tìm ngữ nghĩa liền một mạch, thì việc tách ba hệ thống chính là nguồn của độ trễ và sai lệch. Cắm MCP vào lõi nghĩa là agent nói chuyện thẳng với database bằng một chuẩn chung. Theo mình, đây chưa phải lúc bê vào production — một engine mới cần thời gian chứng minh ở quy mô thật, và hợp nhất luôn kéo theo đánh đổi ẩn. Nhưng nó là tín hiệu rõ nhất cho hướng đi cả ngành: dữ liệu đang được thiết kế lại cho agent chứ không cho con người truy vấn thưa. Đừng vội đổi kiến trúc, nhưng hãy hiểu vì sao câu hỏi này lại đúng.

• Sự kiện trực tiếp ngày 22/7 trình diễn dbt Wizard trên CLI và nền tảng dbt.
• dbt Wizard: viết, refactor, debug model trong ngữ cảnh lineage, test, contract, metric.
• Không đoán mò như chatbot chung — hiểu đúng cấu trúc dự án.
• dbt State bỏ qua model không đổi, tiết kiệm 30% compute trở lên.

dbt là công cụ trung tâm của phần lớn analytics engineer, nên mỗi bước đi của nó ảnh hưởng cả nghề. Điều mình đánh giá cao ở dbt Wizard là nó không tách rời: trợ lý được đặt trong lineage, test, contract và metric của chính dự án, nên nó hiểu đúng chứ không bịa ra một model trông giống thật. Đó là khác biệt giữa AI hữu dụng và AI gây nợ kỹ thuật. Nhưng ngôi sao thầm lặng lại là dbt State. Rất nhiều đội đốt tiền cloud một cách ngớ ngẩn: đổi một model rồi chạy lại toàn bộ pipeline. Bỏ qua phần không đổi là tiết kiệm thật, đo được bằng hoá đơn cuối tháng. Lời khuyên thực chiến của mình: trước khi mê tính năng AI, hãy bật dbt State và chuẩn hoá test, contract cho tử tế. Chính ngữ cảnh sạch đó mới làm trợ lý AI đáng tin — AI không cứu được một dự án dbt hỗn loạn, nó chỉ khuếch đại thứ bạn đã có.

• Hộp thoại Model options nay có sẵn trong web modeling, không cần Desktop.
• REST API Fabric quản lý org app và audience: create, read, update, delete, list.
• Paginated report quản lý qua API để tự động hoá vòng đời và triển khai.
• Hướng chung: web hoá và lập trình hoá việc quản trị Power BI.

Với đội làm Power BI, hai thay đổi này nghe nhỏ nhưng đúng chỗ ngứa. Model options lên web nghĩa là bạn bớt phụ thuộc vào Power BI Desktop trên Windows — cộng tác dễ hơn, và người dùng máy nhẹ hay Mac bớt khổ. REST API cho org app và paginated report thì mở đường tự động hoá thật: thay vì click tay từng bước xuất bản, bạn viết script quản lý vòng đời báo cáo, đưa vào CI/CD. Đây là thứ phân biệt một đội BI trưởng thành với một đội còn làm thủ công. Khuyến nghị của mình cho các team Việt: đừng chờ có nhiều báo cáo mới nghĩ tới tự động hoá — hãy tập dùng API sớm, vì chi phí vận hành thủ công tăng theo cấp số nhân khi số workspace và audience phình ra.

• Qlik Open Lakehouse nay hỗ trợ Qlik Replicate làm nguồn native.
• Đường đi thẳng từ Replicate sẵn có vào lakehouse dựa trên Iceberg.
• Thêm declarative pipeline cho Qlik Talend Data Integration.
• Nâng cấp quản trị và giám sát đi kèm.

Điểm hay của tin này không phải công nghệ mới, mà là con đường di trú. Rất nhiều doanh nghiệp đã đầu tư vào Qlik Replicate để đồng bộ dữ liệu từ hệ nguồn nhiều năm trước, và giờ họ muốn lên lakehouse mở nhưng ngại phải dựng lại toàn bộ pipeline. Cho Replicate cắm thẳng vào Open Lakehouse trên nền Iceberg là cách vendor hạ rào cản: bạn tận dụng thứ đã có thay vì làm lại từ đầu. Bài học rộng hơn cho team Việt: khi chọn hướng hiện đại hoá dữ liệu, giá trị lớn nhất thường không nằm ở tính năng long lanh, mà ở việc nó có tôn trọng khoản đầu tư cũ của bạn không. Declarative pipeline cũng là xu hướng đúng — mô tả kết quả mong muốn thay vì viết từng bước, dễ bảo trì hơn nhiều.

• AIOS ngồi trên data catalog, điều phối model AI, agent và analytics.
• Định tuyến yêu cầu AI tới đúng nguồn và công cụ, cấp ngữ cảnh.
• Thực thi quản trị: biến catalog từ chỉ mục thụ động thành control plane.
• Dùng chính hiểu biết về dữ liệu, chính sách và cách dùng của Alation.

Trong nhiều năm, data catalog bị coi là món trang trí governance: mua về để tick ô tuân thủ, rồi ít ai đụng tới. AIOS là nỗ lực biến nó thành thứ sống: một lớp điều phối, nơi agent hỏi catalog để biết dữ liệu ở đâu, ai được xem, định nghĩa nào đúng, rồi mới hành động. Về ý tưởng, đây là nước đi thông minh — Alation đang lấy đúng tài sản mình có, là hiểu biết về dữ liệu và chính sách, làm lợi thế. Nhưng mình giữ một chút hoài nghi lành mạnh: một catalog dữ liệu sai hoặc lỗi thời mà được nâng lên thành control plane thì sẽ khuếch đại cái sai, chứ không sửa nó. Với doanh nghiệp Việt, bài học không phải là đi mua AIOS, mà là câu hỏi: catalog của bạn đang là chỉ mục chết hay là nguồn sự thật sống? Trả lời được câu đó trước đã, rồi hẵng nói tới việc cho agent dựa vào nó.

• MCP server đưa dữ liệu thị trường tư nhân thẳng vào câu trả lời LLM.
• Khai thác hơn 39 tỷ tín hiệu sống và 15 triệu dự báo.
• Tương thích Claude, ChatGPT, Gemini, Cursor và các agent.
• Một giao diện chuẩn duy nhất, thay vì mỗi khách tự dựng tích hợp.

Tin này nhỏ nhưng minh hoạ đúng cách làm data-for-AI tử tế. Vấn đề muôn thuở của agent là nó bịa khi thiếu dữ liệu, hoặc tự cào web và nhặt về rác. Crunchbase giải bằng cách phơi chính nguồn dữ liệu đã kiểm chứng của mình qua MCP — một chuẩn kết nối chung mà Anthropic đưa ra cuối 2024. Nghĩa là bất kỳ agent nào tương thích MCP đều truy vấn được, không phải dựng tích hợp riêng cho từng khách. Đây chính là mẫu hình mà doanh nghiệp Việt nên học: nếu bạn có một kho dữ liệu giá trị — danh mục sản phẩm, lịch sử giao dịch, tri thức nội bộ — thì cách đưa nó vào kỷ nguyên agent không phải là fine-tune một model, mà là phơi nó qua một chuẩn như MCP với quyền và audit rõ ràng. Dữ liệu sạch, có kiểm soát, cắm chuẩn — đó là lợi thế thật, khó sao chép hơn nhiều so với việc gọi một API model.

• Platform 9.5 thêm Agentic AI Active Context cho lớp data virtualization.
• Duy trì ngữ cảnh ngữ nghĩa và chính sách cập nhật liên tục trên dữ liệu federated.
• Phơi ngữ cảnh cho agent để AI hiểu ý nghĩa, độ nhạy cảm, quy tắc dùng.
• Cho agent hành động mà không phải gom dữ liệu về một kho.

Denodo là ví dụ đẹp của một công nghệ tưởng cũ bỗng thành đúng thời. Data virtualization — truy vấn dữ liệu tại chỗ mà không copy về kho — từng bị lép vế trước làn sóng gom hết vào data warehouse rồi lakehouse. Nhưng thời agent, bài toán đổi: dữ liệu nằm rải rác nhiều nguồn, và bạn cần một lớp biết ý nghĩa, độ nhạy cảm, quy tắc dùng để agent không làm bậy. Đó đúng là chỗ virtualization tỏa sáng. Cùng với Alation AIOS và Teradata, đây là tuần mà cả ngành đồng loạt nói một điều: agent cần ngữ cảnh, và ngữ cảnh phải sống, cập nhật, có chính sách. Với doanh nghiệp Việt có dữ liệu phân tán ở ERP, CRM, file server và vài cloud, hướng cấp ngữ cảnh tại chỗ đáng cân nhắc hơn là ép gom tất cả về một kho — vừa tốn kém vừa chậm.

• Autonomous Knowledge Platform GA trên cả cloud và on-premises.
• Tự động tổ chức, quản trị và tối ưu tài sản dữ liệu, tri thức.
• Nhắm không đánh đổi giữa kiểm soát, hiệu năng và chi phí.
• Mở rộng vai trò Teradata từ engine phân tích sang lớp tri thức cho AI.

Teradata là tên tuổi kho dữ liệu lâu đời, và việc họ đóng gói lại thành lớp tri thức cho agent nói lên nơi giá trị đang dịch chuyển. Điểm mình muốn nhấn: khảo sát ngành suốt năm nay đều chỉ ra cùng một sự thật, rằng thứ chặn AI doanh nghiệp không phải model yếu, mà là dữ liệu bẩn, quản trị lỏng và không đo được ROI. Vậy nên xu hướng vendor nhảy từ engine phân tích sang lớp tri thức có quản trị là hợp lý. Nhưng với đội nhỏ ở Việt Nam, đừng đọc tin này thành phải mua một nền tảng đắt tiền. Đọc nó thành lời nhắc: trước khi mơ agentic AI, hãy làm sạch và định nghĩa dữ liệu của mình cho tử tế. Một nền tảng autonomous vẫn autonomous ra kết quả sai nếu dữ liệu đầu vào đã sai từ gốc.

• Connect AI mở rộng cho môi trường tuân thủ HIPAA.
• Nối ứng dụng và agent AI thẳng vào hệ thống chứa PHI.
• Không sao chép dữ liệu, không nới lỏng kiểm soát.
• Truy cập theo danh tính, có audit và thực thi chính sách.

Câu chuyện thật của AI trong ngành nhạy cảm không phải model thông minh cỡ nào, mà là làm sao cho agent chạm được dữ liệu mà bộ phận tuân thủ vẫn chịu ký. CData giải đúng chỗ đó: thay vì copy dữ liệu PHI ra một nơi để AI dùng — vừa rủi ro vừa dễ vi phạm — họ đưa quyền theo danh tính, audit và chính sách xuống ngay tầng kết nối. Agent truy cập dữ liệu sống nhưng mọi thao tác đều ghi vết và giới hạn theo quyền. Đây là mẫu hình mà fintech, ngân hàng và y tế Việt nên tham khảo, vì bài toán của họ giống hệt: dữ liệu nhạy cảm, quy định chặt, nhưng vẫn muốn dùng AI. Nguyên tắc rút ra: đừng di chuyển dữ liệu tới AI, hãy đưa AI tới dữ liệu với quyền và audit đặt đúng ranh giới. Kiến trúc đó xấu xí hơn demo, nhưng là thứ duy nhất qua được vòng kiểm toán.

• NeuralSearch: tìm kiếm storage-native cho dữ liệu phi cấu trúc.
• Hợp tác ISV với Databricks, tích hợp qua Open Sharing.
• Khám phá và truy vấn dữ liệu bảng lẫn file qua Unity Catalog.
• Biến metadata filesystem thành trí tuệ tìm kiếm thời gian thực.

Một sự thật ít ai nói: phần lớn dữ liệu quý của doanh nghiệp không nằm gọn trong bảng, mà là file — hợp đồng, ảnh, bản vẽ, log, tài liệu kỹ thuật — nằm rải rác trên storage. Khi làm RAG thật cho doanh nghiệp, đây mới là chỗ khó, không phải phần model. Cách làm quen thuộc là copy hết ra rồi index lại, vừa tốn kém vừa tạo bản sao lỗi thời. Qumulo giải bằng cách biến chính metadata của filesystem thành lớp tìm kiếm, rồi nối vào Databricks qua Open Sharing và Unity Catalog để giữ quản trị. Với ai đang xây RAG trên dữ liệu doanh nghiệp — đúng thứ mình đang thực hành — đây là hướng đáng học: tìm kiếm tại chỗ, giữ nguyên quyền, không nhân đôi hạ tầng. Bài học cốt lõi vẫn là: giá trị của RAG nằm ở khâu truy xuất dữ liệu doanh nghiệp cho đúng và có kiểm soát, chứ không phải ở việc gọi model nào.

• Nhiều vendor cùng biến catalog và lớp ngữ cảnh thành nền cho AI.
• Alation ra AIOS, Denodo thêm Active Context, Teradata GA lớp tri thức.
• Editors Lens: catalog chỉ là điểm khởi đầu của data intelligence platform.
• Nền liên tục làm giàu metadata, quan hệ, quản trị, tri thức nghiệp vụ.

Điều đáng chú ý không phải một sản phẩm, mà là sự đồng thuận: trong đúng một tuần, ba vendor lớn cùng nói data catalog và lớp ngữ cảnh phải trở thành nền cho agent. Khi thị trường đồng loạt rẽ về một hướng như vậy, đó thường là tín hiệu thật, không phải mốt. Nhưng theo mình, cần tỉnh táo tách hai lớp. Về công nghệ, hướng này đúng: agent cần ngữ cảnh có quản trị để không làm bậy. Về thực thi, đây là chỗ nhiều doanh nghiệp Việt sẽ vấp, vì họ đang có catalog nhưng để nó chết — không ai cập nhật, định nghĩa lệch nhau. Nâng một catalog rác lên thành control plane cho AI thì chỉ khuếch đại cái rác. Lời khuyên: đừng đợi mua nền tảng AI-ready mới. Hãy bắt đầu bằng việc làm catalog của bạn sống thật — có chủ sở hữu, có định nghĩa metric thống nhất, cập nhật đều. Nền tảng chỉ khuếch đại thứ bạn đã có.

• Databricks đề xuất Delta 5.0 dùng chung cây metadata thích ứng của Iceberg v4.
• Client Delta và Iceberg đọc-ghi cùng cấu trúc trên đĩa, không cần lớp dịch.
• Hai định dạng vẫn độc lập về giao thức commit và catalog.
• Cây phẳng hơn cho phép single-file commit, chi phí metadata gần hằng số.
• Bản ổn định sớm nhất cuối 2027.

Đây là câu chuyện định dạng bảng tưởng đã ngã ngũ nhưng vừa rẽ bất ngờ. Suốt mấy năm, ta bị ép chọn phe: Delta hay Iceberg, và ai chọn sai thì sợ mắc kẹt với một hệ sinh thái, phải trả giá migrate. Đề xuất cho Delta 5.0 và Iceberg v4 dùng chung một cây metadata thích ứng — hai bên vẫn độc lập về commit và catalog nhưng đọc-ghi được cùng cấu trúc metadata — làm giảm hẳn cái giá đó. Về kỹ thuật, cây phẳng thay cho chuỗi manifest nhiều tầng còn mở đường cho single-file commit, kéo chi phí ghi metadata về gần hằng số, thứ mà streaming rất cần. Nhưng mình muốn nói thẳng phần thực dụng: bản ổn định sớm nhất cũng phải cuối 2027, và trong sản xuất, thứ chưa ra thì bằng không. Vậy nên tư thế đúng lúc này là theo dõi và mừng vì rủi ro chọn sai đang giảm, chứ không phải đổi kiến trúc theo một lời hứa. Đây chính là loại tin để hiểu hướng đi, không phải để hành động ngay.

• Lập luận: chỗ đúng cho agent là lớp kiểm chứng đúng đắn, không phải sinh pipeline.
• Agent dò anomaly, kiểm ràng buộc, phát hiện dữ liệu lệch trước khi lan xuống.
• Người tiêu thụ pipeline giờ là agent — niềm tin quan trọng hơn tốc độ dựng.
• Được thảo luận sôi nổi trên Hacker News.

Giữa cơn sốt cho AI sinh code pipeline hộ, bài này là một tiếng nói tỉnh táo mà mình rất đồng tình. Lập luận cốt lõi: chỗ đáng đặt AI trong data engineering không phải là để nó dựng pipeline thay bạn — nơi một lỗi tinh vi có thể âm thầm làm hỏng dữ liệu hàng tháng — mà là lớp kiểm chứng đúng đắn: dò bất thường, kiểm ràng buộc, bắt dữ liệu lệch trước khi nó lan xuống báo cáo. Vì sao đúng? Vì giá trị thật của nghề nằm ở độ tin cậy, và đó cũng là nơi AI vừa hữu ích vừa ít rủi ro nhất: nó gợi ý và cảnh báo, con người quyết. Đây trùng với quan điểm mình hay nói: AI không thay người giỏi, nó khuếch đại người biết làm việc rõ ràng. Với đội Việt, khuyến nghị cụ thể: đừng vội cho agent tự viết và deploy transform lên production; hãy cho nó làm người gác cổng chất lượng dữ liệu trước đã. Vừa an toàn, vừa gặt giá trị nhanh.

• Anaconda mua Kilo Code — nền tảng agentic engineering mã nguồn mở, trung lập model.
• Kilo có hơn 3 triệu lập trình viên trên VS Code, JetBrains, web, CLI.
• Định tuyến gần 10 nghìn tỷ token mỗi tháng.
• Nối tiếp thương vụ mua Outerbounds đầu năm.
• Đưa coding agent thẳng vào môi trường developer dữ liệu đã dùng.

Con số gần mười nghìn tỷ token mỗi tháng đủ để hiểu vì sao thương vụ này lớn. Nhưng thứ mình thấy sắc nhất là vị trí chiến lược. Anaconda vốn là nơi giới khoa học và kỹ thuật dữ liệu cài môi trường, quản thư viện, kiểm soát bảo mật gói — một chỗ đứng thầm lặng nhưng ai làm data cũng đi qua. Giờ họ nhét coding agent vào đúng chỗ đó, thay vì để nó sống ở một công cụ tách rời. Nghĩa là gì? Với doanh nghiệp lo ngại đưa mã và dữ liệu ra dịch vụ ngoài, mô hình agent chạy trong môi trường được quản trị chặt là câu trả lời hấp dẫn. Nhưng cũng có hai mặt: gần mười nghìn tỷ token một tháng đồng nghĩa với một hoá đơn khổng lồ, và bài toán ai cũng phải học là kiểm soát chi phí token. Với team Việt, đừng chạy theo phong trào cắm agent khắp nơi; hãy đo giá trị thực trên vài quy trình cụ thể trước, rồi mới mở rộng. Công cụ mạnh mà không có kỷ luật đo lường thì chỉ tạo ra một hoá đơn đẹp cho nhà cung cấp.

• Gọi 3 tỷ USD ở định giá 188 tỷ, do Coatue dẫn dắt.
• Vòng thứ hai trong năm 2026, tăng 40% so với mức 134 tỷ.
• Dùng vốn tài trợ các thương vụ thâu tóm.
• Mở rộng Genie và Unity AI Gateway để kiểm soát chi phí AI.

Định giá nhảy 40% chỉ trong vài tháng, lên 188 tỷ đô, nói rằng dòng tiền vẫn tin lakehouse gắn AI là ván cược lớn của thập kỷ. Nhưng với người làm nghề, chi tiết đáng đọc không phải con số, mà là hướng dùng tiền: tài trợ thâu tóm và siết công cụ kiểm soát chi phí AI như Unity AI Gateway. Đó là thừa nhận ngầm rằng nỗi đau lớn nhất của khách hàng lúc này không phải thiếu tính năng AI, mà là hoá đơn AI mất kiểm soát. Điều này khớp với tin Genie bật tính tiền vài tuần trước: kỷ nguyên dùng thử miễn phí đã hết, và ai cũng cần công cụ đo, giới hạn, tối ưu chi phí. Với doanh nghiệp Việt cân nhắc đặt cược vào Databricks, đây vừa là tín hiệu vững tâm về sức sống nền tảng, vừa là lời nhắc: hãy vào với một chiến lược quản trị chi phí rõ ràng ngay từ đầu, đừng để tới lúc mở hoá đơn mới giật mình.

• Series D 1,5 tỷ USD mở rộng nền tảng AI đa mô hình.
• Phục vụ workload agentic doanh nghiệp đòi hỏi cao.
• Vốn cho hạ tầng, nghiên cứu và go-to-market.
• Nhắm ca dùng điều phối nhiều model và agent.

Một tỷ rưỡi đô cho tầng phục vụ và điều phối nhiều model là con số đáng để ý, vì nó chỉ ra nơi dòng vốn tin giá trị sẽ đọng lại: không phải model đơn lẻ, mà là lớp orchestration nơi doanh nghiệp ghép nhiều model và agent lại cho một quy trình thật. Với người làm dữ liệu, ý nghĩa là: bài toán của bạn sắp không còn là chọn một model, mà là quản một danh mục model và định tuyến đúng việc cho đúng model, với dữ liệu doanh nghiệp làm nhiên liệu. Đó là lý do các câu chuyện tuần này — RegattaDB, Crunchbase MCP, các lớp ngữ cảnh — đều xoay quanh việc đưa dữ liệu tới agent cho sạch và có kiểm soát. Với team Việt, đừng vội xây hạ tầng đa model phức tạp khi chưa có nhu cầu thật; nhưng hãy hiểu rằng hướng gió đang thổi về orchestration, và kỹ năng thiết kế workflow nhiều agent sẽ ngày càng đáng giá.

• Cloudera gộp nền tảng AI-native với storage hợp nhất của VAST Data.
• Đưa nền tảng AI data tới mọi nơi dữ liệu cư trú.
• Chạy analytics và AI trên on-premises, cloud và edge.
• Không phải tái kiến trúc tầng dữ liệu; coi mọi dữ liệu là AI-ready.

Có một sự thật mà các bài quảng cáo cloud hay lờ đi: rất nhiều doanh nghiệp không thể, hoặc không được phép, gom hết dữ liệu về một cloud công cộng. Lý do có thể là quy định chủ quyền, dữ liệu quá lớn để di chuyển, hay hạ tầng edge ở nơi sóng yếu. Hợp tác Cloudera và VAST đánh đúng khoảng trống đó: đưa AI tới nơi dữ liệu đang nằm, thay vì bắt dữ liệu chạy tới AI. Đây là bài toán mà không ít tổ chức Việt — ngân hàng, sản xuất, khối công — gặp hằng ngày. Về mặt kiến trúc, cách này thực dụng và tôn trọng ràng buộc thật, dù nó phức tạp hơn một kiến trúc all-in-cloud đẹp trên slide. Bài học rút ra: khi thiết kế nền dữ liệu cho AI, đừng bắt đầu bằng câu hỏi dùng cloud nào, hãy bắt đầu bằng câu hỏi dữ liệu của tôi được phép nằm ở đâu. Ràng buộc đó mới là thứ định hình kiến trúc, không phải sở thích công nghệ.

• Khoản đầu tư 130 triệu USD từ Warburg Pincus.
• Mở rộng nền tảng truy cập dữ liệu và web intelligence.
• Nhắm quy mô hạ tầng thu thập, xử lý dữ liệu web cấp doanh nghiệp.
• Nguồn nguyên liệu cho ứng dụng AI cần grounding trên dữ liệu công khai.

Trong cơn sốt model và agent, người ta hay quên rằng AI vẫn phải ăn dữ liệu, và nhiều ứng dụng cần grounding trên dữ liệu web công khai để trả lời cho đúng thực tế. Đó là lý do tầng thu thập dữ liệu web — vốn bị coi là hạ tầng thầm lặng, thậm chí nhạy cảm về pháp lý — đang được định giá lại. Khoản 130 triệu đô cho Oxylabs là chỉ dấu: nguyên liệu đầu vào cho AI đang thành mặt hàng chiến lược, và việc thu thập hợp pháp, sạch, quy mô lớn là một lợi thế cạnh tranh thật. Với doanh nghiệp Việt, bài học không phải là đi cào web, mà là nhận ra: chất lượng và tính hợp pháp của dữ liệu đầu vào quyết định chất lượng đầu ra của AI. Trước khi lo model, hãy lo nguồn dữ liệu — nó bẩn hay sạch, có được phép dùng không, có đại diện cho thực tế không. Dữ liệu vẫn là gốc, model chỉ là cách chế biến.