• Change data feed trên materialized view: bản Beta, áp dụng cho MV tạo bằng Lakeflow hoặc SQL.
• REPLACE USING flows (Beta): thay thế snapshot từng phần, khoá theo cột chỉ định.
• JAR task trên serverless: chạy Scala/Java không cần provision cluster.
• Tìm và thay thế đa file trong Git folders, tiện refactor pipeline hàng loạt.
• Lakebase hỗ trợ workspace có kiểm soát HIPAA, C5 hoặc TISAX.

Đây là loại release note ít ai đọc nhưng lại đổi cách dựng pipeline. Trước đây, materialized view của Databricks tiện cho tầng phục vụ nhưng bịt đường downstream: muốn biết cái gì vừa đổi thì phải so bảng hoặc chạy lại từ đầu. Có change data feed, MV trở thành một mắt xích thật trong chuỗi incremental. REPLACE USING thì cứu những team làm việc với nguồn chỉ trả snapshot từng phần, ví dụ ERP xuất theo chi nhánh hoặc theo kỳ. Trước đây phải viết logic merge thủ công và cầu trời không sót khoá. JAR trên serverless là món tiết kiệm tiền rõ nhất cho team Việt: job Spark viết bằng Scala thường phải giữ cluster riêng, giờ chỉ trả tiền lúc chạy. Còn Lakebase được duyệt HIPAA, C5, TISAX là tín hiệu cho các doanh nghiệp có dữ liệu nhạy cảm rằng cơ sở dữ liệu OLTP trong lakehouse đã đủ điều kiện đưa vào hệ thống thật. Lời khuyên: đừng đổi kiến trúc vì một feature Beta, nhưng nên dựng một nhánh thử nghiệm CDF trên MV ngay, vì nếu ổn thì nó cắt được cả một tầng bảng trung gian.

• Kiểu Variant vào REST catalog spec: 7 phiếu binding, 15 non-binding, không phiếu chống.
• Remote signing config qua với 5 phiếu binding: client xin catalog ký thay vì giữ credential.
• Iceberg Rust 0.10.1 phát hành, 9 committer ủng hộ.
• Bàn chuyện đổi mặc định từ fast append sang merging append ở bản 1.13.
• Parquet: sort order IEEE_754_TOTAL_ORDER gây lệch giữa Java và Arrow, cân nhắc revert.

Điểm quan trọng nhất tuần này không phải tính năng, mà là cách các dự án xử lý tương thích. Variant vào REST catalog spec nghĩa là dữ liệu bán cấu trúc — thứ mà mọi log, mọi event, mọi payload API đều thuộc về — cuối cùng có một cách mô tả chung giữa catalog và engine, thay vì mỗi bên tự bịa. Parquet quay lại lá phiếu versioning với luật rõ hơn: thay đổi phá vỡ tương thích thì dồn vào major version tiếp theo, tính năng mới phải đánh dấu preview kèm feature flag và cần hai implementation trước khi vào spec. Đó là bài học đau: sort order IEEE_754_TOTAL_ORDER vừa làm Java và Arrow đọc khác nhau, đúng loại lỗi âm thầm mà đội data chỉ phát hiện khi số liệu lệch. Comet 1.0.0 RC1 thì đáng chú ý với ai đang trả tiền cho Spark: Comet dịch physical plan của Spark sang DataFusion, giữ Arrow từ đầu đến cuối, và số công bố là nhanh khoảng 2 lần trên TPC-DS 1TB. Gọi 1.0.0 nghĩa là dự án tin API đã đủ ổn định để người khác xây lên trên. Với team Việt đang cân nhắc mở lakehouse: đây là lúc bám Iceberg và Parquet ở phiên bản có feature flag rõ ràng, đừng chạy theo tính năng preview trong hệ thống sản xuất.

• Dùng CDC gốc của SQL Server, không cần agent cài thêm trên máy chủ nguồn.
• Chọn bảng cần nhân bản, chạy near real-time hoặc theo lịch.
• Nối tiếp connector Oracle đã GA hồi tháng 2/2026 trong cùng bộ Openflow.
• Tự áp thay đổi vào bảng đích, không cần viết logic merge riêng.

Đây là tin nhỏ nhưng chạm thẳng vào ví tiền của nhiều doanh nghiệp Việt. Kịch bản phổ biến ở đây là ERP hoặc core banking chạy SQL Server on-prem, rồi phải mua thêm một công cụ CDC bên thứ ba để đẩy sang cloud warehouse. Khi Snowflake đưa connector CDC vào chính nền tảng và lên GA, bài toán biến thành cấu hình thay vì tích hợp. Điểm cần cẩn trọng: CDC gốc của SQL Server đòi bật ở cấp database và cấp bảng, sinh thêm tải ghi và cần dọn log định kỳ — DBA phải đồng ý trước, đừng để đội data tự bật. Điểm nữa là "gần thời gian thực" không phải là "thời gian thực": nếu bài toán cần dưới một giây thì đây không phải công cụ đúng, hãy đi đường streaming. Với đa số báo cáo vận hành và dashboard, độ trễ vài phút là quá đủ và rẻ hơn nhiều. Theo kinh nghiệm triển khai, chốt chặn thật sự không nằm ở connector mà ở việc mô hình hoá lại dữ liệu sau khi nó chảy sang: CDC đổ vào lakehouse một dòng thay đổi thô, còn báo cáo cần bảng sự kiện sạch.

• Chia sẻ bảng Delta có bật Iceberg reads: bên nhận đọc bằng engine Iceberg bất kỳ.
• Bảng có deletion vectors nay chia sẻ được, không cần rewrite file.
• Bảng bật column mapping (đổi tên, xoá cột) cũng vào diện GA.
• Cùng đợt: connector SharePoint và Google Drive lên GA.

Ai từng dựng data sharing giữa hai công ty đều gặp cảnh trớ trêu: bảng chạy tốt nhất trong hệ thống lại là bảng không chia sẻ được. Deletion vectors giúp xoá dòng mà không phải ghi lại cả file, column mapping cho phép đổi tên cột mà không phá lịch sử — cả hai đều là thực hành chuẩn, và cả hai từng chặn Delta Sharing. Đưa lên GA nghĩa là Databricks đã xử lý xong phần dịch metadata phía người nhận. Phần Iceberg reads mới là điểm chiến lược: bên nhận không cần dùng Databricks, chỉ cần một engine đọc Iceberg là lấy được dữ liệu. Nói cách khác, Databricks đang chấp nhận đánh đổi khoá chân người dùng để lấy vai trò nguồn dữ liệu chuẩn. Với doanh nghiệp Việt, đây là thứ nên tận dụng khi làm dữ liệu chuỗi cung ứng hoặc dữ liệu đối tác: thay vì xuất file CSV hàng đêm rồi cãi nhau về phiên bản, chia sẻ bảng sống có kiểm soát quyền. Nhưng đừng quên phần khó nhất vẫn nằm ngoài công nghệ — thoả thuận ai được xem cột nào và ai chịu trách nhiệm khi số sai.

• Áp dụng cho bảng và volume trong Unity Catalog, dùng governed tags.
• Điều kiện do người dùng định nghĩa, tag được gán hoặc gỡ tự động.
• Đang ở trạng thái Beta, công bố ngày 07/08/2026.
• Cùng đợt có hàm ai_search và change data feed trên materialized view.

Mọi dự án governance đều bắt đầu bằng một buổi workshop hào hứng và kết thúc bằng một bảng Excel không ai cập nhật. Lý do rất đơn giản: gắn nhãn là việc thủ công, lặp lại, không ai được thưởng khi làm và không ai bị phạt khi bỏ. Tag automations đánh đúng chỗ đó — biến chính sách thành quy tắc chạy máy. Nhưng đây cũng là chỗ dễ tự bắn vào chân. Nếu điều kiện viết ẩu, ví dụ gắn nhãn PII cho mọi cột có chữ "email" trong tên, thì sẽ có hàng loạt bảng bị siết quyền sai và người dùng mất truy cập giữa giờ làm việc. Khuyến nghị thực chiến: chạy ở chế độ quan sát trước, xuất danh sách bảng sẽ bị ảnh hưởng, cho chủ dữ liệu duyệt, rồi mới bật thật. Và đừng dùng nó để thay cho việc định nghĩa quyền sở hữu dữ liệu — máy gắn được nhãn chứ không quyết được ai chịu trách nhiệm. Với doanh nghiệp đang chuẩn bị cho agent chạm vào dữ liệu, đây là bước hạ tầng phải làm trước, vì agent đọc nhãn để biết chỗ nào không được vào.

• Truy vết prompt, model call, tool invocation và bước retrieval trong luồng agentic.
• Chấm đầu ra theo độ đúng, độ liên quan và mức bám ý định người dùng.
• Chạy trên môi trường lai: on-premises và nhiều public cloud.
• Tích hợp LangChain, LangGraph, LlamaIndex, CrewAI, AutoGen, ADK, OpenAI, Anthropic.
• Nối trực tiếp với data quality, lineage và pipeline monitoring có sẵn của nền tảng.

Cái hay của tin này nằm ở chỗ nối dây, không nằm ở tính năng. Thị trường đang có hai loại observability sống tách nhau: một bên theo dõi pipeline và chất lượng dữ liệu, một bên theo dõi trace của LLM. Khi agent trả lời sai, đội AI đổ cho dữ liệu, đội data đổ cho mô hình, và không ai chứng minh được. Nối lineage của bảng vào trace của agent nghĩa là truy được đến tận cùng: câu trả lời này lấy từ bảng nào, bảng đó lần cập nhật cuối khi nào, test chất lượng có pass không. Đó là điều kiện tối thiểu để đưa agent vào quy trình có tiền bạc và trách nhiệm. Phần cần cẩn trọng: chấm "độ đúng" bằng máy vẫn là chấm bằng mô hình, và mô hình chấm cũng sai. Đừng biến điểm số đó thành KPI báo cáo lên ban lãnh đạo; hãy dùng nó làm bộ lọc để lôi ra các ca đáng cho người xem. Với doanh nghiệp Việt mới bắt đầu RAG, bài học thực tế là: dựng lineage cho dữ liệu nguồn trước, dựng trace cho agent sau — làm ngược lại thì có trace đẹp mà không biết lỗi từ đâu.

• Gắn policy MPA vào tài khoản để bật cơ chế bốn mắt bắt buộc.
• Áp cho các thao tác trọng yếu ở cấp account, không phải mọi truy vấn.
• Lên GA ngày 04/08/2026.
• Là một phần của hướng chống ransomware và chống xoá dữ liệu diện rộng.

Bốn mắt là khái niệm cũ trong ngân hàng, mới trong data platform. Lý do nó quay lại đúng lúc này rất thực tế: khi agent và automation cầm được credential có quyền cao, một prompt sai hoặc một token rò rỉ có thể xoá cả tài khoản trong vài giây, và tính năng time travel không cứu được nếu chính sách retention bị đổi trước. MPA chèn một con người vào giữa. Cái giá phải trả là ma sát: mỗi lần đổi cấu hình trọng yếu là một lần chờ duyệt, và nếu quy trình duyệt thiết kế dở thì đội vận hành sẽ tìm cách lách. Cách làm đúng là chỉ bật MPA cho một danh sách hẹp thao tác thật sự không thể hoàn tác, đặt SLA duyệt rõ ràng, và có đường xử lý sự cố khẩn. Với doanh nghiệp Việt, tôi thấy phần lớn tổ chức chưa từng liệt kê được "những thao tác nào trên kho dữ liệu là không thể quay lui" — làm cái danh sách đó trước, rồi hãy bật tính năng. Công nghệ chỉ thực thi được chính sách mà mình đã nghĩ rõ.

• Secret lưu trong Unity Catalog với namespace ba cấp, lên GA ngày 03/08/2026.
• Serverless compute access control lên GA cho cả Interactive và Automated Compute.
• Quyền MANAGE không còn yêu cầu quyền usage trên cùng đối tượng.
• Custom tag của materialized view và streaming table nay chảy sang bề mặt tính tiền.

Đây là kiểu tin dễ bị bỏ qua nhưng lại quyết định độ an toàn thật của một nền tảng dữ liệu. Trước đây secret scope sống ở một cơ chế riêng, phân quyền riêng, audit riêng — nghĩa là bạn có thể siết row-level security rất công phu trên bảng khách hàng, trong khi key kết nối tới chính nguồn dữ liệu đó lại nằm ở chỗ ai trong workspace cũng mò được. Đưa secret vào cùng cây quản trị với bảng và volume là hợp nhất đúng chỗ: một mô hình quyền, một dòng audit, một chỗ để trả lời câu hỏi "ai đã đọc cái gì". Món kèm theo cũng đáng tiền: custom tag của materialized view và streaming table giờ chảy sang bề mặt tính tiền, tức là cuối cùng cũng quy được chi phí về từng phòng ban thay vì nhìn một hoá đơn tổng rồi đoán. Kinh nghiệm triển khai cho doanh nghiệp Việt: hãy làm chuẩn đặt tên tag trước khi bật, vì tag đặt loạn thì báo cáo chi phí cũng loạn, và sửa về sau tốn hơn làm đúng từ đầu.

• Native App tạo được Cortex Agents và MCP server do Snowflake quản lý, mức GA.
• Nhà cung cấp đăng ký được endpoint SPCS làm MCP server tự host.
• MCP server phục vụ Cortex Analyst, Cortex Search, Cortex Agents làm tool.
• Xác thực qua dịch vụ OAuth có sẵn, phân quyền bằng RBAC của Snowflake.
• Hỗ trợ cả tool tuỳ biến và thực thi SQL trên cùng giao diện chuẩn.

Điều thật sự mới ở đây không phải MCP — cái đó có từ trước — mà là MCP được đóng gói vào Native App và bán qua marketplace. Trước đây, muốn một agent dùng được dữ liệu của phần mềm đối tác, bạn phải đàm phán API, dựng ETL, đồng bộ schema. Giờ nhà cung cấp app đẩy luôn một MCP server chạy ngay cạnh dữ liệu, với OAuth và RBAC của chính Snowflake. Đó là chuyển từ "tích hợp dữ liệu" sang "phân phối năng lực". Bản chất dễ hiểu: thay vì chép dữ liệu ra ngoài cho AI đọc, bạn mang AI vào trong hàng rào và chỉ cho nó cái cửa đã khoá sẵn. Ai hưởng lợi: doanh nghiệp có dữ liệu nhạy cảm và các ISV muốn bán trên nền Snowflake. Ai nên cẩn trọng: team nhỏ dễ tưởng bật MCP là xong việc, trong khi phần khó nằm ở chỗ định nghĩa tool cho đúng nghiệp vụ và giới hạn phạm vi truy vấn. Khuyến nghị: đừng mở một MCP server vạn năng chạy SQL tự do. Hãy định nghĩa vài tool hẹp, có tham số rõ, gắn semantic view — agent tốt không phải agent được quyền nhiều, mà là agent bị giới hạn đúng.

• ai_search (Beta): hàm SQL truy xuất từ một hoặc nhiều AI Search index.
• Index được khai báo làm knowledge source, gọi thẳng trong truy vấn.
• MCP connector do Databricks quản lý chuyển sang Unity AI Gateway (Beta).
• Genie Code thêm khả năng tìm kiếm web công khai, mặc định tắt.

Đưa retrieval vào SQL là một quyết định kiến trúc chứ không phải một tiện ích. Nó nói rằng dữ liệu phi cấu trúc không còn là thế giới riêng của đội AI, mà là một nguồn nữa mà analyst gọi được bằng ngôn ngữ họ đã biết. Cái lợi rõ nhất là bỏ được một tầng dịch vụ: trước đây muốn kết hợp bảng doanh thu với nội dung hợp đồng, phải viết job Python, đẩy sang vector store, rồi ghép lại. Giờ là một câu truy vấn. Cái cần cảnh giác là chi phí và độ lặp lại: mỗi lần gọi ai_search là một lần chạy mô hình, và câu SQL chạy trên bảng triệu dòng sẽ đốt tiền rất nhanh nếu không lọc trước. Kinh nghiệm khi tôi làm thực hành RAG trên nền lakehouse: retrieval bằng SQL rất tiện để khám phá, nhưng lên sản xuất thì phải chốt tập ứng viên bằng bộ lọc quan hệ trước, rồi mới cho mô hình xử lý phần còn lại. Việc kéo MCP connector về một cổng quản trị chung cũng cùng một mạch tư duy: cho tiện trước, nhưng phải đếm được và chặn được.

• Kimi K3: kiến trúc Mixture-of-Experts, 2,8 nghìn tỷ tham số.
• Cửa sổ ngữ cảnh 1 triệu token, có khả năng xử lý hình ảnh.
• Có sẵn trên Databricks từ ngày 06/08/2026.
• Chạy trong phạm vi quản trị của Unity Catalog, không phải gọi API ra ngoài.

Cái đáng chú ý không phải con số 2,8 nghìn tỷ tham số — MoE nghĩa là mỗi lượt suy luận chỉ kích hoạt một phần nhỏ, nên đừng đọc con số đó như chi phí. Cái đáng chú ý là mô hình mạnh, đa phương thức, context dài đã nằm sẵn trong hàng rào dữ liệu thay vì phải gọi API ra ngoài. Với doanh nghiệp Việt trong ngành có quy định chặt về dữ liệu, khác biệt giữa "dữ liệu rời khỏi hệ thống" và "mô hình chạy cạnh dữ liệu" là khác biệt giữa được duyệt và không được duyệt. Về mặt kỹ thuật, context 1 triệu token thay đổi thiết kế pipeline tài liệu: nhiều bài toán trước đây bắt buộc phải chunk và xây vector index, giờ có thể nhét thẳng cả bộ tài liệu vào. Nhưng đừng vội bỏ RAG. Nhét cả triệu token vào mỗi câu hỏi thì đắt gấp bội và chậm hơn nhiều so với truy xuất đúng vài đoạn. Nguyên tắc tôi dùng: context dài để hiểu tài liệu lần đầu và trích xuất cấu trúc, RAG để phục vụ hàng nghìn câu hỏi lặp lại sau đó. Chọn sai chỗ là hoá đơn đội lên mà chất lượng không tăng.

• Lên GA ngày 04/08/2026, là thành phần của Unity Catalog.
• Kiểm soát dịch vụ AI nào từng nhóm được phép sử dụng.
• Định tuyến và quản lý lưu lượng AI giữa nhiều nhà cung cấp.
• Quản trị MCP server: kiểm soát quyền truy cập và chi phí.
• Theo dõi usage, cost, access, lineage trên cùng một mặt bảng.

Đây là tin lớn nhất tuần, và lý do không nằm ở tính năng mà ở vị trí đặt tính năng. Unity AI Gateway không phải một cổng proxy dựng riêng, nó là một phần của Unity Catalog — cùng cây quản trị với bảng, volume, secret. Nghĩa là câu hỏi "agent nào gọi mô hình nào để đọc bảng nào, tốn bao nhiêu tiền" có một câu trả lời duy nhất thay vì ba hệ thống rời nhau. Nói cho người không rành kỹ thuật: trước đây mỗi đội tự cắm điện vào ổ riêng, giờ có một tủ điện tổng có cầu dao và công tơ. Ai hưởng lợi rõ nhất là doanh nghiệp vừa và lớn đang có ba bốn nhóm cùng nghịch AI mà tài chính không biết tiền đi đâu. Nhóm nào thiệt? Team nhỏ, vì thêm một tầng quản trị là thêm ma sát khi họ chỉ muốn thử nhanh. Cái cốt lõi phải nhớ: quản trị AI không phải là chặn, mà là đếm được và truy được. Khuyến nghị thẳng: nếu doanh nghiệp bạn đã có hơn hai nhóm gọi LLM trên dữ liệu nội bộ, hãy bật cổng này ngay và bắt buộc mọi lời gọi đi qua đó, ngay cả khi ban đầu chỉ để quan sát. Không nên làm điều ngược lại — dựng chính sách chặt trước khi có số liệu, vì rồi sẽ chặn nhầm và cả tổ chức quay lại đi cửa sau.

• Cột agents_info có ở ACCESS_HISTORY của Account Usage và Organization Usage.
• Ghi chi tiết agent đã truy cập dữ liệu thay mặt người dùng nào.
• Inline Stored Procedures cho hybrid table vào public preview cùng ngày.
• Nhắm vào workload vận hành chạy trên hybrid table.

Một cột thêm vào view audit nghe rất nhỏ, nhưng nó xử lý một lỗ hổng đang lớn dần. Khi agent chạy dưới quyền của người dùng, mọi log truy cập đều ghi tên người đó. Đến lúc kiểm toán hỏi "vì sao tài khoản này đọc bảng lương lúc hai giờ sáng", không ai trả lời được là con người hay một automation nào đó. Có agents_info nghĩa là tách được hai lớp danh tính: ai chịu trách nhiệm và cái gì thực thi. Với doanh nghiệp phải tuân thủ, đây là điều kiện cần để được duyệt cho agent đụng vào dữ liệu thật. Lời khuyên thực tế: đừng chờ đến khi có sự cố mới đi tìm cột này. Hãy dựng ngay một báo cáo giám sát đơn giản — mỗi tuần bao nhiêu truy vấn đến từ agent, chạm bảng nào, khối lượng bao nhiêu — và cho chủ dữ liệu xem. Việc này rẻ, mất một buổi, và nó biến câu chuyện quản trị AI từ khẩu hiệu thành số liệu. Data không chỉ để báo cáo, data phải giúp hành động, và audit log cũng vậy.

• DuckDB tăng 50,7% lượt nhắc so với cùng kỳ, dẫn đầu bảng tăng trưởng.
• Phân tích dựa trên 1,8 triệu tiêu đề Hacker News.
• ClickHouse tăng 24,1%, PostgreSQL giữ quỹ đạo ổn định nhất ba năm.
• Các bài nổi bật: pipeline phân tích Spotify dựng bằng AI, AI tự debug SQL.
• Nhóm cloud được quản lý như Redshift, BigQuery, DynamoDB giảm thảo luận tự nhiên.

Con số này nên đọc như tín hiệu về hành vi lập trình viên, không phải thị phần doanh nghiệp. DuckDB thắng vì nó xoá bỏ ma sát: không cần cụm, không cần tài khoản, không cần chờ IT duyệt — cài một thư viện là chạy được truy vấn phân tích trên máy cá nhân. Trong thời mà mỗi lập trình viên có một agent viết code, thứ chạy được ngay trong một tiến trình nhỏ có lợi thế cực lớn. Điều này không có nghĩa kho dữ liệu đám mây sắp chết, nó có nghĩa là ranh giới đang dịch: khám phá, tiền xử lý và kiểm thử chạy tại chỗ, còn dữ liệu chung và quản trị vẫn ở nền tảng tập trung. Với team data nhỏ ở Việt Nam, đây là cơ hội thật để cắt chi phí: rất nhiều tác vụ đang chạy trên warehouse tính tiền theo giây thực ra xử lý vài chục triệu dòng, hoàn toàn nằm gọn trong DuckDB trên một máy. Điều không nên làm là đem tư duy máy cá nhân vào hệ thống sản xuất nhiều người dùng — DuckDB không giải bài toán đồng thời và quản trị, và cố ép nó làm việc đó là chuốc nợ kỹ thuật.

• 273 lượt ủng hộ, 114 bình luận chỉ trong vài ngày đầu tháng 8.
• Bình luận top: senior kiệt sức, đã qua một đợt cắt giảm, chờ đợt tiếp theo.
• Một người mười năm nghề nói chưa từng thấy mình tạo ra giá trị rõ ràng.
• Nhiều người tự gọi nghề mình là "data janitor" — dọn dẹp không hồi kết.
• Chủ đề song song ở r/dataengineeringjobs: bốn năm kinh nghiệm khó kiếm phỏng vấn.

Đọc kỹ các bình luận thì vấn đề không phải công nghệ chán, mà là vòng phản hồi bị đứt. Người làm data hiếm khi thấy kết quả công việc của mình biến thành quyết định của ai đó; họ thấy ticket, thấy pipeline hỏng lúc ba giờ sáng, thấy yêu cầu đổi cột lần thứ tám. Đó là công thức chuẩn để kiệt sức, dù lương có tốt. Có một nghịch lý đáng suy nghĩ: đây đúng tuần các nền tảng ra hàng loạt tính năng tự động hoá, mà cảm giác của người trong nghề lại đi xuống. Theo tôi, tự động hoá không chữa được cái đau này, vì cái đau nằm ở chỗ tổ chức không nối được dữ liệu với hành động. Điều nên làm, cả cho cá nhân và cho quản lý: chọn một bài toán có người dùng thật, đo được kết quả kinh doanh, và đi cùng nó từ đầu đến cuối — kể cả phần thuyết phục người ta đổi cách làm. Điều không nên làm là học thêm một công cụ nữa để hy vọng hết chán. Dashboard đẹp không có nghĩa là đang ra quyết định tốt, và pipeline chạy xanh cũng vậy.

• Netflix GenRec: LLM nền tảng diễn giải lịch sử người dùng, tốt hơn với ít nhãn hơn 40 lần.
• Atlassian StreamHub: chuyển Kinesis sang Kafka ở mức 145 tỷ sự kiện mỗi ngày.
• Spotify: đánh index data lake để phục vụ truy vấn điểm cho dịch vụ online và agent.
• Airbnb: phát triển theo hướng eval-driven, LLM judge hiệu chỉnh về mức đồng thuận cao.
• Thoughtworks: ontology cộng LLM để hiện đại hoá dữ liệu cho AI.

Nếu chỉ đọc một thứ tuần này thì đọc số này. Ba bài lớn nhất kể cùng một câu chuyện từ ba góc. Netflix bỏ cách xây feature thủ công để chuyển sang cho mô hình đọc lịch sử người dùng ở dạng ngôn ngữ — họ gọi đó là dịch chuyển từ feature engineering sang context engineering, và con số ít nhãn hơn 40 lần là lý do kinh tế đằng sau. Atlassian thì cho thấy quy mô thật của streaming hiện đại và lý do rời một dịch vụ được quản lý: chi phí, độ tin cậy API và thời gian giữ dữ liệu. Spotify chạm vào điểm mà nhiều team đang gặp: agent cần lấy dữ liệu của một người dùng cụ thể thật nhanh, nhưng dữ liệu nằm ở data lake chứ không phải key-value store, và không ai đủ tiền chép hết vào bộ nhớ. Bài học chung cho doanh nghiệp Việt: trước khi mơ agent, hãy trả lời được câu "lấy toàn bộ dữ liệu của một khách hàng mất bao lâu". Nếu câu trả lời là mấy chục giây thì mọi trải nghiệm AI phía trên sẽ chậm và đắt, bất kể mô hình nào.

• Số 253, phát hành ngày 03/08/2026, do Tim Spann tổng hợp.
• Bao quát engine xử lý, streaming, định dạng bảng mở và dự án cộng đồng.
• Ra đều đặn hàng tuần, là nguồn theo dõi hệ sinh thái mở lâu năm.

Giá trị của những bản tin kiểu này không nằm ở bài nào cụ thể, mà ở việc chúng giữ cho bạn một bản đồ liên tục về hệ sinh thái mở. Đây là chỗ khác biệt lớn giữa dùng nền tảng thương mại và dùng thành phần mở: nền tảng thương mại có người báo cho bạn khi có gì đổi, còn hệ sinh thái mở thì bạn phải tự theo dõi. Một thay đổi mặc định trong định dạng bảng, một bản vá encoding, một dự án đổi cách đóng gói — mỗi thứ đều nhỏ, nhưng gộp lại đủ làm hỏng một pipeline chạy êm hai năm. Với team data ở Việt Nam đang tự vận hành Spark, Kafka hay Iceberg, tôi khuyên phân công rõ một người đọc một bản tin tuần và mỗi tháng báo lại trong mười lăm phút. Đó là chi phí rất nhỏ để tránh cái giá rất lớn của một lần nâng cấp mù. Đừng biến nó thành phong trào, hãy biến nó thành hệ thống.

• Series B 57 triệu USD do Insight Partners dẫn, công bố ngày 04/08/2026.
• Etna Labs, Spark Capital, Andreessen Horowitz và Justin Kan tham gia.
• Tổng vốn huy động đạt 110,5 triệu USD.
• Nền tảng gồm database có kiểu TypeScript, đảm bảo ACID, live sync, auth và RAG.
• Gần 2 triệu ứng dụng đang chạy; OpenAI và Zapier nằm trong nhóm khách hàng.

Luận điểm của Convex đáng chú ý hơn con số. Họ đặt cược rằng khi agent sinh ra phần lớn code, điểm gãy sẽ chuyển từ tốc độ viết sang độ tin cậy của trạng thái. Một agent viết nhanh gấp mười lần cũng vô nghĩa nếu nó tạo ra một cập nhật không nguyên tử làm lệch số dư tài khoản. Vì vậy họ bán một database có kiểu chặt theo TypeScript, có ACID, có đồng bộ thời gian thực và có sẵn phần RAG — tức là dựng sẵn hàng rào để code do máy sinh khó phá. Đây là góc nhìn tôi đồng tình phần lớn: AI không thay người giỏi, nó khuếch đại người biết làm việc rõ ràng, và cách làm việc rõ ràng trong dữ liệu chính là ràng buộc kiểu và giao dịch. Chỗ cần cẩn trọng là khoá chân: chọn một backend độc quyền cho ứng dụng lõi nghĩa là mọi thứ về sau phải sống theo mô hình của họ. Với startup Việt làm sản phẩm nhanh, đổi lấy tốc độ có thể xứng đáng. Với doanh nghiệp có hệ thống lâu năm, hãy lấy bài học kiến trúc chứ đừng vội đổi nền.

• Doanh thu 410 triệu USD, vượt dự báo 396 triệu; EPS non-GAAP 0,69 so với ước tính 0,55.
• Doanh thu định kỳ 363 triệu USD, tăng 3% theo báo cáo, 2% theo tỷ giá cố định.
• Biên hoạt động non-GAAP mở rộng lên 21,5%.
• AI Studio lên general availability ngay đầu quý 3.
• Giới thiệu Teradata Factory: hệ thống on-premise do Dell dựng, tích hợp CPU và GPU.

Câu chuyện Teradata là câu chuyện của một lớp doanh nghiệp mà nhiều người tưởng đã hết thời. Doanh thu đi ngang nhưng vượt dự báo, doanh thu định kỳ nhích lên, biên mở rộng — đó là hồ sơ của công ty đang cắt gọt để mua thời gian cho một cú xoay trục. Cú xoay đó là nền tảng tri thức tự vận hành cho agentic AI, cộng AI Studio, cộng Teradata Factory do Dell dựng chạy on-premise với cả CPU lẫn GPU. Đọc kỹ hướng đi này rất đáng cho thị trường Việt Nam: nhiều ngân hàng, viễn thông và tập đoàn nhà nước ở đây vẫn có ràng buộc dữ liệu phải ở trong nước và trong trung tâm dữ liệu của mình. Một hệ thống AI đóng gói chạy tại chỗ, ngay cạnh kho dữ liệu đã có sẵn, là lựa chọn thực tế hơn nhiều so với việc chuyển toàn bộ lên cloud rồi cãi nhau về tuân thủ. Điều cần tỉnh táo: nền tảng cũ mà gắn nhãn agentic vẫn là nền tảng cũ nếu mô hình dữ liệu bên dưới không đổi. Hãy hỏi nhà cung cấp một câu duy nhất — agent lấy ngữ cảnh nghiệp vụ từ đâu, và ai duyệt định nghĩa đó.

• Miễn phí Genie One và Genie Agents gia hạn tới 31/01/2027, trước đó dự kiến hết 31/07/2026.
• Genie One vào Databricks Excel Add-in: hỏi bằng ngôn ngữ tự nhiên, kết quả về dạng hàng cột gốc.
• Genie One cũng có trong Databricks Connector cho Google Sheets.
• Excel Add-in bổ sung bộ lọc phân tầng và so khớp chuỗi không phân biệt hoa thường.

Hai tin này phải đọc chung mới thấy chiến lược. Đưa Genie One vào Excel và Google Sheets là đi thẳng vào nơi phần lớn người dùng doanh nghiệp thật sự làm việc — không phải trong công cụ BI, mà trong bảng tính. Và ngay khi mở kênh đó, họ gia hạn miễn phí thêm sáu tháng. Đây là bài toán thói quen chứ không phải bài toán tính năng: ai chiếm được ô nhập liệu của người dùng cuối thì sau này định giá kiểu gì cũng được. Với doanh nghiệp Việt, đây vừa là cơ hội vừa là bẫy. Cơ hội vì bạn có nửa năm dùng thật miễn phí để đánh giá nghiêm túc xem hỏi đáp bằng ngôn ngữ tự nhiên có tạo giá trị hay không. Bẫy vì rất dễ để người dùng quen tay rồi đến tháng 2/2027 mới phát hiện chi phí. Lời khuyên thẳng: dùng ngay, nhưng đo ngay từ đầu — bao nhiêu câu hỏi mỗi tuần, ai hỏi, câu trả lời có dẫn tới quyết định nào không. Nếu sau sáu tháng không trả lời được ba câu đó thì đừng trả tiền. Công nghệ chỉ có giá trị khi chạm được lớp nghiệp vụ và lớp con người.