• Tám coding agent chạy song song sinh hơn 450.000 dòng Rust.
• Chạy sạch hơn 46.000 truy vấn regression, không sai câu nào.
• Bỏ process-per-connection, chuyển sang thread-per-connection.
• Tương thích định dạng đĩa gốc của Postgres.
• Tác giả khẳng định v0.1 chưa production-ready, thiếu phần lớn extension.

Đừng đọc tin này như một tin về database. Hãy đọc nó như một tin về giới hạn của AI. Viết lại một database engine hai mươi năm tuổi là bài toán khó nhất của nghề phần mềm: hàng nghìn ca biên, ngữ nghĩa transaction tinh vi, tương thích nhị phân. Và bộ regression test của Postgres không phải loại test cho có — nó là tài sản mà cộng đồng bồi đắp suốt hai thập kỷ để bắt đúng những chỗ dễ sai nhất. Pass sạch 46.000 truy vấn nghĩa là code này đúng ở mức ngữ nghĩa, không phải chỉ chạy được. Nhưng đừng nhầm: chưa tối ưu hiệu năng, chưa có hệ extension, và một database mà thiếu extension thì với đa số doanh nghiệp là vô dụng. Điều đáng làm ngay không phải là thử pgrust, mà là nhìn lại chính codebase legacy của mình — thứ mà sáu tháng trước bạn còn nghĩ "không đời nào AI đụng vào được".

• Vote dùng version number cho thay đổi phá vỡ tương thích, theo mô hình Iceberg.
• Chốt ngữ nghĩa sắp xếp cho kiểu INT96 legacy, hết cảnh mỗi engine hiểu một kiểu.
• FIXED_SIZE_LIST: lưu vector độ dài cố định, bỏ chi phí mã hoá độ dài biến thiên.
• Benchmark: giải nén nhanh 2,3 lần trên mảng float, thêm 1,5 lần nữa nếu có hints.
• Đề xuất mã hoá ALP khai thác đặc tính số thập phân trá hình trong embedding.

Đây là loại tin không ai chia sẻ trên LinkedIn nhưng lại quyết định hoá đơn cloud của bạn ba năm tới. Parquet nằm dưới gần như mọi lakehouse trên thế giới; mọi thứ bạn gọi là Iceberg, Delta hay Hudi thực chất đều đọc-ghi file Parquet. Suốt nhiều năm, Parquet bị kẹt: không dám phá tương thích nên không thêm được kiểu dữ liệu mới. Vote versioning vừa gỡ nút thắt đó. Và thứ đầu tiên được đẩy qua cửa nói lên tất cả về thời đại: một kiểu mảng cố định để lưu vector. Nghĩa là gì với doanh nghiệp Việt? Nếu bạn đang cân nhắc nhét embedding vào một vector database riêng, hãy chờ thêm vài tháng — nhiều khả năng lakehouse của bạn sẽ tự lo được, rẻ hơn và bớt một hệ thống phải vận hành. Đừng vội mua thêm thứ mà nền tảng sắp có sẵn.

• Iceberg Rust cắt RC3 ngày 8/7 sau khi RC2 lộ lỗi trong khâu verify.
• Arrow 25.0.0 RC1 mở vote ngày 6/7; Arrow Rust 59.1.0 RC1 đã pass ngày 7/7.
• Apache Polaris 1.6.0 thông qua vote phát hành ngày 8/7.
• pyiceberg-core bind iceberg-rust vào Python; DataFusion dùng nó để xử lý truy vấn.
• Polaris bàn Terraform provider và JDBC datasource — dấu hiệu adoption production.

Chi tiết đáng nhớ nhất trong đống release note này là ba chữ: không cần JVM. Suốt mười năm, muốn đọc-ghi một bảng Iceberg tử tế thì gần như phải kéo theo cả hệ sinh thái Java: Spark, Hadoop, vài trăm megabyte dependency, và mấy chục giây khởi động. iceberg-rust đang xóa điều kiện đó. Hệ quả rất cụ thể: bạn có thể viết một service nhỏ, khởi động trong mili-giây, đọc thẳng bảng Iceberg trong S3, chạy trên một container 256MB. Với team data nhỏ ở Việt Nam — nơi ngân sách hạ tầng luôn là bài toán — đây là thay đổi thực chất hơn mọi tính năng AI cộng lại. Nhưng nhớ: RC2 lộ lỗi phải cắt RC3, tức là hệ sinh thái Rust vẫn đang trẻ. Dùng cho tooling và service phụ trợ thì tốt; đừng vội đặt pipeline sản xuất lên đó.

• Bản ổn định vẫn là v1.11 (tháng 5/2026), thuộc kỷ nguyên v3 — v4 chưa phát hành.
• Đã vote thông qua: relative paths (di chuyển bảng không cần viết lại metadata).
• Đã vote thông qua: content stats — thống kê có kiểu, thay cho map chung chung.
• Đang bàn: single-file commits, snapshot offloading, cập nhật cột riêng lẻ.
• Compact bitmaps cho deletion vector đã vote draft spec từ tháng 6.

Đọc roadmap v4 là đọc chính danh sách chỗ đau của những người vận hành Iceberg ở quy mô lớn nhất. Snapshot offloading sinh ra vì metadata.json phình to khi commit liên tục — nỗi khổ kinh điển của streaming. Cập nhật cột riêng lẻ sinh ra vì bảng feature cho AI có hàng nghìn cột, viết lại cả dòng để sửa một cột là lãng phí khủng khiếp. Relative paths sinh ra vì ai từng migrate bucket S3 đều biết cảm giác phải viết lại toàn bộ metadata. Điều này nghĩa là gì nếu bạn đang chọn table format? Đừng chọn theo benchmark hôm nay; chọn theo hướng mà cộng đồng đang khoét sâu. Iceberg đang khoét đúng ba hướng mà workload AI cần. Nhưng cũng nhớ: v4 chưa ra, và trong sản xuất, bản chưa ra thì bằng không.

• Liệt kê đầy đủ các đường đưa streaming vào Iceberg kèm độ trễ thực tế từng đường.
• Chỉ rõ trần độ trễ do cơ chế commit theo snapshot của table format.
• Đưa hướng xử lý khi nghiệp vụ đòi dưới ngưỡng vài giây.
• Liên hệ trực tiếp với đề xuất single-file commits trong roadmap Iceberg v4.

Sai lầm phổ biến nhất mình gặp khi tư vấn: coi lakehouse là thứ vạn năng, rồi hứa với business một dashboard real-time trên Iceberg. Iceberg commit theo snapshot — mỗi lần commit là một lần ghi metadata mới. Đẩy tần suất commit lên để giảm độ trễ thì metadata phình, chi phí bảo trì bảng tăng, và query planner chậm dần. Đây là trần vật lý của kiến trúc, không phải lỗi cấu hình, và không có tham số nào chỉnh được. Vậy nên làm gì? Rất rõ: nếu nghiệp vụ thật sự cần dưới một giây, đừng ép Iceberg — hãy để một tầng streaming store phục vụ đường nóng, và Iceberg phục vụ đường phân tích. Kiến trúc hai đường xấu xí hơn slide bán hàng, nhưng nó chạy được. Còn nếu business chỉ cần "mới trong vòng một phút" thì đừng đốt tiền xây real-time làm gì.

• Kéo dữ liệu từ CRM, POS, helpdesk, tài chính về nền Rippling.
• Org chart và phân quyền dựng sẵn ngay trong modern data stack.
• Trả lời câu hỏi kiểu chi phí nhân sự trên doanh thu, đội nào tiêu quá tay.
• Phơi dữ liệu ra cho dashboard, workflow và custom app.

Ý tưởng ở đây thông minh hơn vẻ ngoài. Bài toán row-level security trong BI thường được giải bằng cách nhồi bảng mapping user-phòng ban rồi tự bảo trì, và nó luôn lệch sau mỗi lần công ty tái cơ cấu. Rippling vốn là hệ thống nhân sự, nên org chart và phân quyền của họ luôn đúng theo định nghĩa — họ chính là nguồn sự thật. Xây BI lên trên đó là lấy đúng thứ mình có sẵn làm lợi thế. Bài học rút ra cho doanh nghiệp Việt không phải là đi mua Rippling, mà là: nguồn sự thật về con người và phân quyền của bạn đang nằm ở đâu, và tại sao data team lại đang tự chép lại nó bằng tay?

• Genie Spaces, Genie Code, Genie One chuyển sang pay-as-you-go từ 00:00 UTC 8/7.
• 150 DBU dùng LLM miễn phí mỗi tháng, khoảng 10,5 đô la tại US East.
• Genie Spaces được đổi tên thành Genie Agents.
• REPLACE WHERE flows lên GA: chỉ thay dòng khớp predicate, không xử lại cả lịch sử bảng.
• Hỗ trợ đọc .xls, .xlsx, .xlsm mặc định; managed Iceberg materialized views vào preview.

Nhiều người sẽ đọc tin này là tin xấu. Mình nghĩ ngược lại: nó lành mạnh. Khi text-to-SQL còn miễn phí, không ai buồn hỏi câu hỏi khó nhất — mô hình ngữ nghĩa của mình có tử tế không? Cứ thả cửa cho người dùng hỏi, AI đoán bừa, ra số nào cũng nhận, sai thì đổ cho AI. Giờ mỗi câu hỏi có giá cụ thể, chất lượng semantic model từ chuyện kỹ thuật lập tức thành chuyện tài chính: một câu hỏi ra một truy vấn gọn hay ra năm cú full scan, hoá đơn cuối tháng sẽ nói cho bạn biết. 150 DBU cháy nhanh hơn bạn tưởng — chỉ cần vài chục người dùng cuối hỏi mỗi ngày. Việc cần làm ngay: dựng quota theo nhóm, cache lại câu hỏi lặp, và quan trọng nhất là chuẩn hoá định nghĩa metric trước khi mở Genie cho cả công ty. Đừng biến nó thành phong trào, hãy biến nó thành hệ thống.

• Vào Apache Incubator ngày 22/6; mở dev list và bật website ngày 8/7.
• Đặc tả YAML và JSON trung lập vendor cho metric, dimension, join.
• Mục tiêu: xoá semantic drift — mỗi hệ thống định nghĩa chỉ số một kiểu.
• Apache Polaris huỷ vote semantic model API riêng để chờ spec của Ossie.
• Spec mới ở v0.1: tư thế đúng lúc này là căn chỉnh và thử nghiệm, chưa phải di trú.

Trong mười năm làm BI cho doanh nghiệp, cuộc họp mình chứng kiến nhiều nhất không phải họp về công nghệ, mà là họp cãi nhau xem con số nào đúng. Marketing tính doanh thu một kiểu, kế toán tính kiểu khác, và ai cũng có dashboard đẹp để chứng minh mình đúng. Đó chính là semantic drift, và nó là lý do sâu xa khiến rất nhiều dự án BI thất bại dù công nghệ chạy ngon. Ossie không phải một công cụ mới — nó là một cách viết ra định nghĩa để máy đọc được. Vì sao lần này khác? Vì Polaris đã hoãn API riêng của mình để chờ nó. Khi một dự án Apache chịu hy sinh spec của chính mình cho một chuẩn chung, đó là tín hiệu thị trường thật. Khuyến nghị của mình: đừng migrate vội, spec mới v0.1. Nhưng nếu bạn sắp xây semantic layer mới trong sáu tháng tới, hãy đọc Ossie trước khi tự đẻ ra một định dạng riêng để rồi ba năm sau phải chuyển đổi.

• AI_TRANSLATE nhận tối đa 100.000 token đầu vào cho một lần gọi.
• Dịch tài liệu dài và văn bản dạng dài ngay trong Snowflake.
• Không phải tự chunk rồi ghép lại — bớt một đoạn pipeline thủ công.
• Dữ liệu không rời khỏi ranh giới nền tảng.

Tin nhỏ nhưng thực dụng. Ai từng làm pipeline dịch tài liệu đều biết đoạn khổ nhất không phải gọi model, mà là chunk văn bản sao cho không cắt giữa câu, rồi ghép lại sao cho ngữ cảnh không đứt. Nâng giới hạn lên 100.000 token là xoá gần hết đoạn đó. Với doanh nghiệp Việt xử lý hợp đồng song ngữ hoặc tài liệu kỹ thuật, còn một điểm quan trọng hơn: dữ liệu không rời khỏi warehouse. Không phải gọi API bên thứ ba, không phải giải trình với phòng pháp chế. Đây là kiểu tính năng ít ai làm video khoe nhưng lại giúp bạn đóng một ticket compliance.

• Agent hành động trực tiếp trên dữ liệu rủi ro và tuân thủ đã kiểm chứng.
• Tự động hoá onboarding, KYC và KYB — giảm 70 đến 90 phần trăm thao tác tay.
• Kết nối qua Model Context Protocol; mở rộng dần sang Copilot và hệ sinh thái Google.
• Nền tảng dữ liệu là D&B Commercial Graph tích luỹ hàng chục năm.

Đây là kiểu triển khai agentic AI mà mình tin. Lý do: agent không được tự do bịa. Nó hành động trên một đồ thị dữ liệu doanh nghiệp đã xác thực, tích luỹ hàng chục năm — nghĩa là phần "sự thật" đã có sẵn, AI chỉ lo phần điều phối và diễn giải. So sánh với các dự án agent thất bại mà mình gặp: hầu hết đều bắt agent vừa tìm sự thật vừa ra quyết định, và nó bịa ở bước đầu rồi sai cả chuỗi. Bài học rất cụ thể cho ngân hàng và fintech Việt đang ngập trong KYC thủ công: trước khi nghĩ đến agent, hãy hỏi dữ liệu nền của mình đã đủ sạch và đủ được xác thực chưa. AI không thay người giỏi; nó khuếch đại hệ thống dữ liệu tử tế. Nếu dữ liệu nền bẩn, agent chỉ giúp bạn sai nhanh hơn.

• GPT-5.6 (Sol, Terra, Luna) thành mô hình Databricks-hosted qua Foundation Model APIs.
• AI Functions Unity Catalog permissions vào Public Preview ngày 8/7.
• Cho phép giới hạn quyền truy cập từng AI Function theo tác vụ.
• Cùng tuần: SQL alerts bật mặc định cho workspace có compliance security profile.

Tin này dễ bị đọc lướt vì ai cũng nhìn vào cái tên model. Nhưng thứ đáng giá nằm ở chỗ khác: mô hình chạy trong ranh giới hạ tầng của khách hàng, và mỗi AI Function có thể phân quyền riêng. Với doanh nghiệp Việt trong ngành ngân hàng, bảo hiểm hay y tế, đây chính là hai câu hỏi mà bộ phận pháp chế luôn hỏi đầu tiên và thường làm dự án AI chết yểu: dữ liệu có ra ngoài không, và ai được gọi cái gì. Trả lời được hai câu đó thì dự án mới đi tiếp. Nói cách khác, Databricks đang bán quản trị chứ không bán model — và đó mới là thứ khách hàng doanh nghiệp thật sự trả tiền.

• Airbyte Agents lên GA; có mặt trên OpenAI App Marketplace.
• Context Store: bản sao dữ liệu vận hành tối ưu cho tìm kiếm, giảm token tiêu thụ.
• MCP endpoint được Airbyte host sẵn, dùng với mọi client tương thích MCP.
• Agent CLI dạng một binary cho luồng developer và CI/CD.
• Connector ghi ngược vào Salesforce và HubSpot — agent hành động, không chỉ đọc.

Điểm kỹ thuật thông minh nhất ở đây là Context Store, và lý do rất thực dụng: gọi thẳng API của Salesforce mỗi lần agent cần lọc dữ liệu thì vừa chậm vừa đốt token khủng khiếp. Giữ một bản sao đã tối ưu tìm kiếm là cách rẻ hơn nhiều. Nhưng phần khiến mình dừng lại là quyền ghi ngược. Đọc sai thì ra câu trả lời sai, còn ghi sai thì hỏng dữ liệu CRM thật của công ty. Đây là ranh giới mà nhiều team sẽ bước qua vì tiện mà quên dựng hàng rào. Khuyến nghị rất rõ: nếu bật quyền ghi cho agent, hãy có audit trail đầy đủ, có môi trường staging, và có quyền tối thiểu theo từng đối tượng. Đừng để agent làm sạch data bằng cách xoá sạch data.

• Chế độ điều tra cho câu hỏi mở, cần suy luận nhiều bước — GA từ 7/7.
• Tự phân rã câu hỏi lớn thành nhiều nhánh điều tra con.
• Chạy song song trên cả dữ liệu có cấu trúc và phi cấu trúc.
• Tổng hợp thành báo cáo có cấu trúc, không phải một kết quả đơn lẻ.
• Mọi khẳng định truy ngược được về dữ liệu nguồn và câu truy vấn đã chạy.

Khoảng cách giữa text-to-SQL và Deep Research chính là khoảng cách giữa "trả lời một câu hỏi" và "điều tra một vấn đề". Câu hỏi kiểu doanh thu quý trước bao nhiêu thì một truy vấn là đủ. Câu hỏi kiểu vì sao khách hàng miền Bắc rời bỏ nhiều hơn thì cần chục truy vấn, cộng đọc ticket support, cộng đối chiếu. Deep Research làm đúng việc đó và làm song song. Nhưng thứ quyết định nó có sống được trong doanh nghiệp không lại là lớp truy vết. Trong thực tế tư vấn, thứ giết chết niềm tin vào báo cáo AI không phải AI viết dở — mà là AI viết hay quá, số nghe rất thuyết phục, và không ai kiểm chứng được nó lấy ở đâu. Một con số không dẫn nguồn thì giám đốc không dám ký. Snowflake bán chính lớp truy vết đó, và họ bán đúng thứ khách hàng cần.

• Đẩy metadata Spark execution plan qua MCP server vào LLM, dùng prompt có cấu trúc.
• Dò anti-pattern: thiếu broadcast join, partition lệch, broadcast quá khổ, full table scan.
• Thời gian chạy job giảm 40 đến 95 phần trăm trên nhiều workload thực tế.
• Chi phí compute giảm 50 đến 95 phần trăm.
• Ví dụ cụ thể: một job từ 20 phút rút còn 1 phút; job hơn 3 tiếng về đúng hạn.

Đây là case study mình sẽ mang đi dạy. Lý do: nó không dùng AI để làm thứ hào nhoáng, nó dùng AI để làm thứ chán ngắt mà con người lười làm — đọc execution plan. Tối ưu Spark xưa nay là nghề của vài chuyên gia hiếm và đắt; họ nhìn plan, thấy ngay chỗ partition lệch hay thiếu broadcast join. Vấn đề là công ty nào cũng chỉ có một hai người như vậy, và họ không đủ thời gian soi hết vài trăm job. Biến tri thức đó thành prompt có cấu trúc, cắm vào MCP server để lấy metadata thật, là cách nhân bản chuyên gia. Con số 50 đến 95 phần trăm chi phí compute không phải marketing — nó đo được trên hoá đơn. Nếu đội bạn đang chạy Spark trên cloud và tháng nào cũng giật mình vì hoá đơn, đây là thứ đáng thử ngay tuần sau, chứ không phải năm sau.

• 429 upvote, 134 bình luận chỉ trong ít ngày — thread nóng nhất tuần của r/dataengineering.
• Công ty tuyển DE hợp đồng vài tháng, tin rằng sau đó không cần ai bảo trì.
• Bình luận top (453 upvote): gọi thẳng đó là sự ngạo mạn.
• Nhiều bình luận coi đây là cờ đỏ, khuyên ứng viên tránh xa.

Ngộ nhận ở đây rất cổ điển và mình gặp hoài khi tư vấn: lãnh đạo nghĩ pipeline giống một toà nhà — xây xong là xong. Thực tế nó giống một khu vườn: bỏ hai tháng không chăm là chết. Chi phí thật của data engineering không nằm ở lúc viết code, nó nằm ở lúc đối tác đổi schema mà không báo, lúc nguồn API chết lúc hai giờ sáng, lúc business đổi định nghĩa doanh thu mà quên nói với ai. Đó chính xác là phần AI hiện vẫn yếu nhất, vì nó đòi ngữ cảnh tổ chức chứ không đòi cú pháp. Nhưng công bằng mà nói, phía kia cũng có phần đúng: nhiều DE thật sự chỉ đang viết SQL và dựng DAG lặp lại — phần đó AI làm được, và làm rồi. Lời khuyên của mình cho bạn trẻ: đừng phòng thủ bằng cách chứng minh AI không viết được SQL. Hãy chuyển giá trị của mình lên phần AI chưa chạm được — thiết kế dữ liệu, định nghĩa nghiệp vụ, và độ tin cậy của hệ thống.

• Nhiều engine cùng ghi thống kê cho một snapshot, engine sau ghi đè engine trước.
• Không có cơ chế trọng tài, không versioning, không mô hình sở hữu thống kê.
• Hai hướng đang bàn: versioning theo snapshot, hoặc nhiều file thống kê có khoá.
• Gábor Kaszab lo ngại về tính mạch lạc của mô hình tư duy và việc khớp engine ID.
• Cùng tuần còn ba tranh luận lớn khác về quản trị, sở hữu thống kê và bảo mật.

Slide bán hàng của mọi vendor lakehouse đều có một câu: một bản dữ liệu, mọi engine đều đọc được. Đây là chỗ câu đó vỡ. Thống kê bảng — số dòng, phân bố giá trị, min-max theo cột — chính là thứ query planner dựa vào để quyết định có broadcast join hay không, có bỏ qua file nào không. Khi Spark ghi thống kê theo mô hình của nó, rồi Trino tính lại theo mô hình của mình và ghi đè, kết quả là planner có thể tin vào một bức tranh sai. Hệ quả rất cụ thể: bạn trả tiền cho một cú full scan lẽ ra không cần. Điều nên làm ngay nếu đang chạy đa engine trên Iceberg: đừng để hai engine cùng ghi thống kê cho một bảng — chọn một engine làm chủ, các engine còn lại chỉ đọc. Xấu, nhưng an toàn, cho tới khi cộng đồng chốt được cơ chế sở hữu.

• Meta: schema metadata hợp nhất và SDK streaming trực tiếp để gỡ nút thắt GPU.
• Stripe: dùng Spark replay traffic production lịch sử để test hồi quy microservice.
• Target: kiến trúc RAG lọc và xếp hạng chiến dịch cũ, đạt độ phủ 100% ở top ba.
• Microsoft: Durable Functions trong PostgreSQL qua extension pg_durable.
• Boaz Palgi phản biện LTAP của Databricks về đảm bảo concurrency và copy-on-write.

Ba case study này đáng đọc kỹ vì chúng cho thấy hạ tầng dữ liệu đang bị AI kéo đi đâu. Meta phải viết lại tầng lưu trữ vì GPU đắt tới mức mọi mili-giây chờ dữ liệu đều thành tiền — bài học là ở quy mô AI, storage chính là nút thắt chứ không phải compute. Stripe replay traffic thật bằng Spark để test hồi quy: đây là cách dùng data engineering để phục vụ độ tin cậy phần mềm, một hướng ít ai nghĩ tới. Target dùng RAG cho dự báo marketing thay vì cho chatbot — đúng kiểu ứng dụng mà mình hay khuyên doanh nghiệp Việt: đừng đi làm chatbot, hãy tìm bài toán quyết định có sẵn dữ liệu lịch sử. Nếu bạn chỉ có thời gian đọc một newsletter tuần này, đọc số này.

• Thị trường ngập ứng viên DE nhưng số người giải được vấn đề rất ít.
• "Ai cũng học được cú pháp và thuật ngữ" — khác biệt nằm ở khả năng giải bài toán.
• Người phỏng vấn kể phải tự hỏi ứng viên thực sự làm gì ở chỗ làm cũ.
• Phỏng vấn DE giờ hỏi cả RAG, LangChain, LangGraph.

Thread này nhỏ về lượt vote nhưng nói trúng thứ mình thấy khi phỏng vấn ở Việt Nam. Thị trường vừa thừa vừa thiếu: hàng trăm CV biết liệt kê Spark, Airflow, dbt, nhưng hỏi tới "dữ liệu này dùng để ra quyết định gì" thì im lặng. Cú pháp học được trong ba tháng; tư duy giải bài toán mất ba năm. Chi tiết đáng chú ý nhất là phỏng vấn DE giờ đã hỏi RAG và LangGraph — nghĩa là mô tả công việc data engineer đang lặng lẽ nuốt thêm phần AI, đúng như những gì tuần này chứng kiến với Airbyte, Databricks và Snowflake. Lời khuyên cụ thể cho bạn trẻ Việt: đừng học thêm một framework nữa. Hãy chọn một bài toán nghiệp vụ thật, làm end-to-end từ nguồn dữ liệu tới con số ra quyết định, và kể được câu chuyện đó trong buổi phỏng vấn. Đó là thứ mà năm trăm CV kia không có.

• Actian (mảng data và AI của HCLSoftware) hoàn tất thâu tóm Jaspersoft.
• Gộp embedded analytics và báo cáo pixel-perfect vào danh mục quản trị dữ liệu.
• Định hướng: đường đi liền mạch từ dữ liệu đã quản trị tới báo cáo vận hành.
• Kế hoạch tiếp: analytics tăng cường AI, trải nghiệm hội thoại, agentic BI.

Thương vụ này không lớn về tiền nhưng đúng về hướng. Nhìn lại nửa đầu 2026: Fivetran gộp dbt Labs, Databricks mua Panther, giờ Actian ôm Jaspersoft. Mẫu chung rất rõ — không ai còn muốn bán một mảnh của chuỗi giá trị dữ liệu nữa, ai cũng muốn bán trọn đường từ nguồn tới quyết định. Với doanh nghiệp Việt, điều này có hai mặt. Mặt tốt: bớt phải tự ghép năm vendor và tự chịu trách nhiệm chỗ nối. Mặt xấu: khoá nhà cung cấp ngày càng chặt, và giá đàm phán về sau chỉ có tăng. Lời khuyên: khi mua nền tảng hợp nhất, hãy hỏi ngay câu khó nhất — nếu ba năm nữa tôi muốn ra đi, dữ liệu và semantic model của tôi có đi theo được không? Trả lời được câu đó rồi hãy ký.

• Khảo sát 1.000 lãnh đạo công nghệ và dữ liệu toàn cầu.
• Bốn rào cản dai dẳng: dữ liệu chưa sẵn sàng, quản trị, đo ROI, thiếu kỹ năng.
• Vấn đề nằm ở chuyển từ pilot rời rạc sang chương trình AI có quản trị.
• Teradata định vị nền tảng dữ liệu AI-ready làm lời giải.

Đọc báo cáo vendor thì phải trừ hao phần bán hàng, nhưng danh sách rào cản này thì mình tin, vì nó khớp đúng những gì thấy khi đi tư vấn. Đáng nói là sau ba năm hype, danh sách không đổi một chữ: dữ liệu bẩn, quản trị lỏng, không đo được ROI, thiếu người. Không có dòng nào ghi "model chưa đủ thông minh". Nghĩa là gì? Nghĩa là phần lớn doanh nghiệp đang mua sai thuốc — họ mua thêm công cụ AI để chữa một bệnh thuộc về dữ liệu và tổ chức. Nếu công ty bạn có ba định nghĩa doanh thu khác nhau, không một model nào cứu được bạn. Việc đúng cần làm trước: dọn định nghĩa metric, chuẩn hoá nguồn, và chọn một bài toán đo được ROI. Rồi mới nói chuyện AI.

• Trụ sở Pháp mới đặt tại trung tâm Paris, phục vụ cả doanh nghiệp lớn và SMB.
• Snowflake Ventures đã đầu tư vào Mistral AI và Dust.
• Chiến lược hệ sinh thái: gắn nền tảng với vô địch AI nội địa.
• Củng cố vị thế Pháp như trung tâm data và AI của châu Âu.

Đây không đơn thuần là tin mở văn phòng. Chiêu của Snowflake tinh vi hơn: vừa đặt hạ tầng tại chỗ, vừa rót vốn vào chính các công ty AI được coi là niềm tự hào quốc gia của Pháp. Khi khách hàng châu Âu lo chủ quyền dữ liệu và muốn dùng model nội địa, Snowflake đã có sẵn câu trả lời — dùng Mistral, chạy trên nền của chúng tôi. Đó là cách vô hiệu hoá lập luận sovereignty mà không cần tranh cãi. Bài học cho thị trường Việt: khi các vendor lớn nói chuyện chủ quyền dữ liệu với ta, hãy hiểu rằng họ đã tính trước nước này ở châu Âu rồi. Câu hỏi ta cần hỏi không phải "dữ liệu có ở Việt Nam không", mà là "nếu tôi rời nền tảng này, tôi mang đi được gì".

• Agent hành động trên dữ liệu nhân đạo hợp nhất trải khắp nhiều cloud và edge.
• Phân tích dữ liệu khí hậu, xung đột và kinh tế; chạy kịch bản dự phóng.
• Tự động hoá một phần quy trình ứng phó khẩn cấp.
• Giữ quản trị dữ liệu, chủ quyền và giám sát của con người ở trung tâm.

Bài toán kỹ thuật ở đây khó hơn vẻ ngoài, và đó là lý do nó đáng học. Dữ liệu nhân đạo không nằm gọn trong một data lake xinh xắn: nó rải từ cloud tới thiết bị edge ở vùng sóng yếu, mất kết nối liên tục, chất lượng thất thường. Xây agent chạy được trên nền dữ liệu như vậy khó hơn nhiều so với xây chatbot trên một warehouse sạch. Điểm mình đánh giá cao là họ giữ giám sát con người ở trung tâm — vì trong ứng phó khẩn cấp, một quyết định sai không phải là con số sai trên dashboard, nó là người. Nhiều tổ chức và doanh nghiệp Việt có bài toán dữ liệu rất giống: chi nhánh xa, kết nối kém, dữ liệu về trễ. Kiến trúc hybrid cloud-edge kiểu này đáng nghiên cứu hơn hầu hết các demo agentic AI bóng bẩy khác.