• Partition evolution cho bảng Iceberg lên GA ngày 18/09/2026
• Đổi sơ đồ phân vùng mà không phải rewrite toàn bộ file dữ liệu
• Cùng ngày: database role được tích hợp vào chức năng backup
• Nằm trong chuỗi 5 ngày Snowflake đẩy hàng loạt tính năng lên GA

Partition evolution là một trong những đặc tính khiến Iceberg khác hẳn Hive-style partitioning. Với Hive, sơ đồ phân vùng nằm trong đường dẫn thư mục, nên đổi partition đồng nghĩa với viết lại cả kho. Iceberg giữ partition trong metadata và đánh số spec theo phiên bản, nên một bảng có thể vừa có file ghi theo spec cũ vừa có file ghi theo spec mới, và engine tự đọc đúng. Điều này nghĩa là gì cho team Việt Nam đang chạy lakehouse trên Snowflake: bạn không còn phải trả giá cho một quyết định phân vùng sai từ hai năm trước bằng một dự án migration ba tháng. Nhưng đừng nhầm GA với miễn phí: đổi spec xong, file cũ vẫn nằm theo layout cũ, và hiệu năng query sẽ không tự nhiên tốt lên cho tới khi bạn rewrite hoặc compaction. Khuyến nghị của mình là đổi spec trước, đo lại query plan, rồi mới tính chuyện rewrite từng phần theo độ ưu tiên.

• Parquet Format 2.14.0 qua vòng bỏ phiếu ngày 11/09, thêm ALP và logical type FILE
• Arrow Rust 60.0.0 ra ngày 15/09, bản Parquet production đầu tiên có ALP
• Crate arrow và parquet 60.0.0 kéo theo DataFusion và iceberg-rust hưởng lợi
• Iceberg Rust 0.11.0 trượt RC1 vì cargo publish, trượt RC2 vì Rust ghi Java không đọc được
• CI của Iceberg Rust bổ sung cargo publish --dry-run sau sự cố

ALP là kiểu mã hoá không mất mát cho số thực, sinh ra để thay cho chuyện nén cột double bằng gzip mà không ăn thua. Với bảng telemetry, giá chứng khoán hay cảm biến IoT toàn cột double, đây là chỗ chi phí lưu trữ và I/O bị đốt nhiều nhất, nên một encoding chuyên dụng có thể cắt rất mạnh. Nhưng điểm đáng học của tuần này không nằm ở ALP. Nó nằm ở chuyện Iceberg Rust trượt vòng hai: toàn bộ test Rust xanh, và chỉ khi đọc mã hoá chéo engine mới lộ ra Java đọc không nổi file do Rust viết. Điều này nghĩa là gì cho người làm data: nếu kiến trúc của bạn có nhiều engine cùng chạm một bảng, đừng tin vào test của từng engine, phải có bộ test đọc chéo. Mình đã thấy đúng lỗi này ở thực tế khi một pipeline Spark ghi ra file mà Trino đọc ra sai kiểu, và không test nào báo đỏ cả. Cách làm an toàn là có một bộ kiểm tra đọc chéo chạy định kỳ trên dữ liệu thật, không phải dữ liệu sinh ra từ chính engine đó.

• Công cụ fuzzing cũ thiết kế cho DBMS tập trung, tỷ lệ truy vấn chạy được thấp
• DAT sinh tổ hợp logical schema và chiến lược phân bố dữ liệu
• Đột biến truy vấn có định hướng để kích hoạt tối ưu phân tán
• Mục tiêu là bug xử lý truy vấn liên quan chiến lược phân bố

Đọc bài này mình nghĩ ngay tới các hệ phân tán mà doanh nghiệp Việt đang dùng: ClickHouse cluster, Doris, StarRocks, hay chính Spark trên lakehouse. Điểm chung là hiệu năng và tính đúng đều phụ thuộc vào chuyện dữ liệu được chia thế nào và join có phải shuffle hay không. Một truy vấn cho kết quả sai chỉ khi chạy trên ba node với một kiểu phân mảnh cụ thể là loại bug khó nhất để bắt, vì trên máy dev một node nó luôn đúng. Điều này nghĩa là gì cho team nhỏ: nếu bạn chạy cluster, bộ test của bạn phải có ít nhất một kịch bản chạy trên nhiều node với dữ liệu chia lệch, không phải chỉ unit test trên một instance. Mình không kỳ vọng doanh nghiệp tự viết fuzzer, nhưng ý tưởng sinh nhiều chiến lược phân mảnh rồi so kết quả là thứ áp dụng được ngay bằng tay.

• Phát hành ngày 15/09/2026
• Ba SPI cắm được: custom evaluator, scaling executor, alignment mode
• Mặc định mới cho autoscaler parallelism alignment
• Hỗ trợ pod ResourceRequirements kiểu Kubernetes native
• Blue/Green kết thúc ngay sau khi deployment cũ bị xoá, không đợi reconcile sau

Autoscaler của Flink là thứ quyết định hoá đơn cloud của một pipeline streaming. Mặc định nó nhìn backlog và busy time rồi đoán parallelism, và cách đó đúng cho phần lớn trường hợp nhưng sai hẳn khi lưu lượng có chu kỳ nghiệp vụ rõ ràng, ví dụ hệ thống bán hàng tăng đột biến vào khung giờ khuyến mãi. Mở custom evaluator nghĩa là bạn được cắm vào đó một tín hiệu bên ngoài, kiểu lịch sử lưu lượng hay lịch sự kiện, thay vì để autoscaler học lại từ đầu mỗi lần. Điều này nghĩa là gì với team vận hành: nếu bạn đang ghim parallelism cứng vì không tin autoscaler, đây là lúc thử lại. Điểm thứ hai đáng chú ý là Blue/Green kết thúc ngay sau khi xoá deployment cũ, vì cái trước đó để lại một khoảng thời gian mà trạng thái hiển thị không khớp thực tế, và đó là nguồn gốc của rất nhiều báo động giả trong giám sát.

• Elastic Channels và durable acknowledgment lên GA ngày 15/09/2026
• Có mặt ở mọi region thương mại AWS, GCP và Azure
• Một đường nạp ngầm mỗi pipe, server tự co giãn
• Không còn phải đặt tên channel, quản thứ tự hay offset token
• Ghi thẳng vào bảng Snowflake và bảng Iceberg do Snowflake quản lý

Ai từng viết client Snowpipe Streaming đều biết phần khó nhất không phải gửi dữ liệu, mà là quản offset token cho đúng để không mất và không trùng bản ghi khi process restart. Đó là code hạ tầng, viết một lần rồi bảo trì mãi, và mỗi lần scale số producer lại phải nghĩ lại cách đặt tên channel. Elastic Channels đẩy toàn bộ phần đó xuống server. Điều này nghĩa là gì cho doanh nghiệp: chi phí xây một đường nạp streaming giảm từ một dự án nhỏ xuống còn cấu hình, và team ít người hoàn toàn có thể làm real-time ingestion mà không cần một kỹ sư chuyên trách. Cảnh báo cần nói thẳng: theo tài liệu hiện tại, kiến trúc hiệu năng cao của Snowpipe Streaming vẫn chưa hỗ trợ bảng Iceberg đã phân vùng và chưa hỗ trợ schema evolution cho Iceberg, nên đừng thiết kế bảng đích với giả định ngược lại.

• Chia sẻ bảng Delta ngoại trú qua OpenSharing lên GA ngày 15/09
• Nguồn hỗ trợ: OneLake, Hive metastore, AWS Glue
• Không phải copy dữ liệu sang Databricks
• Lakebase snapshots API lên Beta, quản bản chụp theo thời điểm của branch
• Data Classification cho view trong Unity Catalog cũng lên Beta cùng ngày

Nhìn theo chuỗi thời gian thì thông điệp khá rõ: ngày 11/09 là bảng Iceberg ngoại trú, ngày 15/09 là bảng Delta ngoại trú, cả hai đều qua OpenSharing và đều là zero-copy. Databricks đang đặt cược rằng doanh nghiệp lớn sẽ không bao giờ gom hết dữ liệu về một nền tảng, nên thay vì ép migration, họ bán vai trò cổng chia sẻ. Điều này nghĩa là gì cho doanh nghiệp Việt có nhiều mảng chạy trên Azure và AWS cùng lúc: bạn có thể mở dữ liệu cho đối tác mà không phải dựng thêm một bản sao và một lịch đồng bộ. Cái phải để ý là quản trị. Zero-copy nghĩa là quyền truy cập trở thành thứ duy nhất chắn giữa đối tác và kho gốc, nên chính sách trên Unity Catalog phải chặt trước khi bật chia sẻ, không phải sau. Mình khuyên bật kèm Data Classification cho view vừa lên Beta để biết cột nào nhạy cảm trước khi ký hợp đồng chia sẻ.

• Databricks Apps telemetry lên GA ngày 18/09/2026
• Dùng giao thức OpenTelemetry, chuẩn mở của ngành
• Trace, log và metric ghi bền vào bảng Unity Catalog
• Databricks Apps bật mặc định cho workspace có compliance security profile

Điểm hay không nằm ở chỗ có telemetry, mà nằm ở chỗ nó ghi vào bảng Unity Catalog chứ không vào một hệ giám sát đóng. Nghĩa là log của ứng dụng chịu chung chính sách quyền với dữ liệu nghiệp vụ, join được với bảng khách hàng, và đưa vào dashboard bằng đúng công cụ BI bạn đang dùng. Điều này nghĩa là gì cho doanh nghiệp: bạn trả lời được câu hỏi mà trước đây phải nối ba hệ thống mới trả lời nổi, kiểu nhóm người dùng nào bỏ giữa chừng ở màn hình nào và họ thuộc phân khúc doanh thu nào. Mặt kia của đồng xu là chi phí lưu trữ và quyền riêng tư: trace ứng dụng rất dày, và nó vô tình chứa tham số truy vấn. Mình khuyên đặt policy giữ dữ liệu và che tham số nhạy cảm ngay từ ngày bật, vì dọn về sau luôn đắt hơn.

• Công bố ngày 17/09/2026 tại hội nghị revAlation
• Sáu sản phẩm mới mở rộng nền tảng AIOS
• 78 phần trăm lãnh đạo cấp C không tự tin qua kiểm toán quản trị AI trong 90 ngày
• Khảo sát Grant Thornton 2026 trên 950 lãnh đạo cấp C

Data catalog từng là chỗ để tra nghĩa của cột, giờ các hãng đều đang đẩy nó lên thành lớp ngữ cảnh cho agent. Logic khá thuyết phục: agent cần biết bảng nào tin được, cột nào nhạy cảm, số liệu nào là bản chính thức, và đó đúng là thứ catalog đã giữ từ lâu. Điều này nghĩa là gì cho doanh nghiệp Việt: nếu bạn đang cân nhắc mua catalog, tiêu chí chọn nên đổi từ tìm kiếm metadata sang khả năng xuất bằng chứng cho kiểm toán và khả năng phục vụ agent qua giao thức mở. Mình chỉ chia sẻ dưới góc nhìn kỹ thuật của một người làm nghề: catalog không tự sinh ra tin cậy. Nếu quy trình đặt tên, sở hữu dữ liệu và vòng đời bảng chưa rõ, mua thêm sáu sản phẩm cũng chỉ ghi lại sự lộn xộn một cách đẹp hơn.

• Unity Gateway API và developer tools lên GA ngày 16/09
• Hỗ trợ đầy đủ thao tác CRUD qua API
• Ngày 17/09: hỗ trợ mọi chuẩn compliance security profile, bật mặc định
• Client secret OAuth không dùng bị tự động xoá sau 90 ngày
• Kimi K2.7 của Moonshot AI nhận thông báo ngừng phục vụ từ 30/10/2026

Chi tiết ít người để ý nhưng đáng giá nhất tuần này là việc client secret OAuth không dùng bị xoá sau 90 ngày. Đây là loại nợ bảo mật mà gần như tổ chức nào cũng có: secret tạo cho một POC từ năm ngoái, người tạo đã nghỉ việc, không ai dám xoá vì không biết còn ai dùng. Tự động hết hạn theo hành vi sử dụng là cách xử lý đúng, nhưng nó cũng nghĩa là bất kỳ job nào chạy theo quý sẽ chết lặng lẽ. Điều này nghĩa là gì cho đội vận hành: rà ngay danh sách service principal và đánh dấu job có chu kỳ dài hơn 90 ngày trước khi chính sách cắn. Phần Unity Gateway thì đúng hướng, nhưng nhớ là thông báo khai tử Kimi K2.7 từ 30/10 nhắc một sự thật khó chịu: model trên gateway của vendor có vòng đời riêng, nên đừng viết prompt bám chặt vào hành vi của một model cụ thể.

• dbt v2 lên GA ngày 16/09/2026 tại dbt Summit, Las Vegas
• Viết lại toàn bộ engine dbt bằng Rust, thay bản Python
• Parse project 10.000 model nhanh gấp 10 lần bản v1
• Phản hồi thời gian thực về lỗi, kiểm tra cột và lineage trước khi chạy
• Thiết kế có tính tới việc agent là người viết SQL

Đây là tin lớn nhất tuần và lý do không nằm ở con số mười lần. Nó nằm ở chỗ dbt đổi vị trí của mình trong vòng lặp làm việc. Với bản Python, parse là một bước bạn chịu đựng trước khi chạy, nên mọi người dồn việc lại rồi chạy một lần cho bõ. Khi parse gần như tức thì và engine trả lỗi cột, lỗi lineage ngay lúc gõ, dbt trở thành thứ giống compiler hơn là scheduler. Điều này nghĩa là gì cho người làm nghề: kiểm tra chất lượng dịch chuyển từ lúc CI sang lúc viết, và đó là thay đổi lớn hơn bất kỳ tính năng nào. Với doanh nghiệp Việt đang xây đội analytics engineering, mình thấy giá trị rõ nhất ở khâu đào tạo, vì người mới học SQL được sửa sai ngay thay vì chờ pipeline đỏ sau nửa tiếng. Điểm cần cân nhắc thật lòng: viết lại bằng Rust nghĩa là hệ sinh thái macro Jinja và adapter cũ phải được kiểm lại từng cái, nên đừng nâng cấp production vào tuần cuối quý. Chạy song song v1 và v2 trên cùng project một thời gian là cách an toàn.

• dbt State lên GA ngày 16/09, dùng metadata warehouse để biết cái gì thật sự đổi
• RxBenefits: giảm 59 phần trăm chi phí warehouse cho job theo lịch
• RxBenefits: 8.173 đô tiết kiệm trong 60 ngày đầu, tái dùng 716 nghìn model
• Virgin Media O2: tiết kiệm 25 phần trăm thời gian chạy job và compute BigQuery
• Lake Compute vào Private Beta: engine SQL một node trên DuckDB, đọc Iceberg
• dbt Charts vào Public Beta: biểu đồ khai báo bằng YAML, version cùng model

Lake Compute là chi tiết đáng nghĩ nhất trong cả gói công bố. Suốt mười năm qua ngành mặc định rằng transform phải chạy trên cụm phân tán, trong khi sự thật là đa số model trong một project dbt xử lý vài triệu dòng, tức là thừa sức cho một máy đơn. DuckDB đọc Iceberg trực tiếp biến phần đó thành một tiến trình rẻ, và warehouse chỉ còn phải gánh những model thật sự lớn. Điều này nghĩa là gì cho doanh nghiệp Việt: mô hình chi phí của lakehouse có thể tách làm hai tầng, và tầng rẻ chiếm phần lớn khối lượng. Con số 59 phần trăm của RxBenefits đến từ dbt State chứ không phải Lake Compute, nên đừng cộng dồn hai thứ vào một kỳ vọng. Cái cần nói thẳng là dbt State chỉ ăn tiền khi pipeline của bạn đang build lại thứ không đổi, mà điều đó lại rất phổ biến. Kiểm tra trước bằng cách đo tỷ lệ model có dữ liệu nguồn thay đổi trong mỗi lần chạy; nếu tỷ lệ đó dưới một nửa, khả năng tiết kiệm là thật.

• Horizon Catalog Explorer thành mặc định trong Snowsight từ 15/09
• Thay thế Database Explorer
• Cây điều hướng cố định, breadcrumb, tìm kiếm thiết kế lại
• Trang chi tiết gộp mô tả, cột, tag và người phụ trách
• Xem trước dữ liệu, kiểm tra quyền và copy history không cần rời explorer

Nghe như một bản cập nhật giao diện, nhưng chỗ đáng chú ý là thứ tự thông tin. Database Explorer đặt cấu trúc kỹ thuật lên trước: database, schema, bảng, cột. Catalog Explorer đặt tag, mô tả và người phụ trách ngang hàng với cột. Đó là một tuyên bố về việc ai là người dùng chính của công cụ này, và câu trả lời không còn chỉ là kỹ sư dữ liệu. Điều này nghĩa là gì cho doanh nghiệp: nếu bảng của bạn chưa có mô tả và chưa có người chịu trách nhiệm, giao diện mới sẽ phơi bày sự trống rỗng đó ra trước mắt người dùng nghiệp vụ mỗi ngày. Mình coi đó là điểm tốt. Công cụ tạo áp lực đúng chỗ thường hiệu quả hơn một cuộc họp nhắc nhở về governance.

• Hai agent chia sẻ cùng một model backbone và khung agentic
• Tối ưu chung bằng reinforcement learning đa agent
• Ba công cụ truy cập database phục vụ suy luận nhiều bước
• Bộ rào chắn rollout giữ cho huấn luyện đa agent không sập
• Nhóm tác giả giới thiệu thêm một benchmark SQL mới

Ai từng dựng text-to-SQL cho doanh nghiệp thật đều biết khâu chết người là nối schema chứ không phải cú pháp SQL. Model viết SQL rất giỏi, nhưng nếu nó chọn sai bảng trong một kho 800 bảng đặt tên theo quy ước từ 2015 thì SQL đẹp đến mấy cũng vô dụng. Tách hai model ra huấn luyện riêng nghe hợp lý về kỹ thuật, nhưng nó tạo ra một điểm gãy: model nối schema không bao giờ biết lựa chọn của nó khiến khâu sau khó đến mức nào. Điều này nghĩa là gì cho người triển khai: kể cả khi bạn dùng model thương mại chứ không tự huấn luyện, bài học vẫn áp dụng được là phải đo hai khâu cùng nhau, không phải đo riêng độ chính xác nối bảng rồi hài lòng. Mình dựng RAG trên dữ liệu doanh nghiệp đủ nhiều để nói rằng chỉ số đẹp từng phần là cái bẫy dễ mắc nhất.

• Truy vấn thật cần đồng thời lọc thuộc tính, multi-vector search và join quan hệ
• Thêm join theo ngưỡng độ tương đồng embedding
• SemJI: chỉ mục join tương đồng thưa cho cặp lân cận hiếm
• Duyệt ANN có nhận biết vị từ, thực thi theo lô
• Xếp hạng bằng hàm chấm điểm đơn điệu trên bộ chứng cứ ứng viên

Chỗ này chạm đúng vào vết thương của phần lớn dự án RAG doanh nghiệp. Bản demo luôn đẹp vì câu hỏi demo chỉ cần tìm một đoạn văn giống nhất. Câu hỏi thật thì luôn kèm điều kiện cứng: chỉ hợp đồng còn hiệu lực, chỉ chi nhánh miền Nam, chỉ trong quý vừa rồi, rồi mới tới phần ngữ nghĩa. Ghép lọc cứng vào vector search theo kiểu lọc trước hay lọc sau đều có giá: lọc trước thì chỉ mục ANN mất tác dụng, lọc sau thì phải lấy thừa rất nhiều ứng viên. Điều này nghĩa là gì cho doanh nghiệp Việt đang xây trợ lý nội bộ: đừng chọn vector database chỉ vì tốc độ tìm k láng giềng, hãy hỏi nó xử lý vị từ và join thế nào. Mình gặp nhiều hệ chạy tốt với mười nghìn tài liệu rồi tắc ở một triệu đúng vì lý do này, chứ không phải vì model kém.

• Fivetran Context Layer vào Private Beta ngày 16/09/2026
• Chạy khám phá ontology trên cả nguồn có cấu trúc và phi cấu trúc
• Mục tiêu: một thuật ngữ như doanh thu quy về đúng một nghĩa
• Bổ sung tri thức phi cấu trúc: tài liệu, luồng thảo luận nội bộ
• Phát hành qua chuẩn mở Agents Schema, truy cập bằng MCP
• Có sẵn tích hợp qua các chợ AI và plugin trong ChatGPT

Mình đi tư vấn Data và BI cho doanh nghiệp đủ lâu để khẳng định: câu hỏi khó nhất trong mọi dự án không phải kỹ thuật, nó là doanh thu tính theo cái gì. Kế toán có một định nghĩa, kinh doanh có một định nghĩa, marketing có định nghĩa thứ ba, và cả ba đều đúng trong bối cảnh của họ. Trước đây sự nhập nhằng đó được hoà giải trong một cuộc họp và ghi vào một file Excel nào đó. Khi agent bắt đầu tự trả lời câu hỏi của sếp, sự nhập nhằng trở thành rủi ro vận hành thật. Điều này nghĩa là gì: lớp ngữ nghĩa từ một tính năng dễ bỏ qua trở thành hạ tầng bắt buộc. Theo mình, điểm đáng giá nhất ở đây là Agents Schema được công bố như chuẩn mở, vì một ontology bị khoá trong một nhà cung cấp thì chẳng khác gì cái bảng tính Excel cũ, chỉ đắt hơn. Nên làm: bắt đầu từ mười khái niệm nghiệp vụ quan trọng nhất và chốt định nghĩa có người ký. Không nên làm: mua công cụ trước rồi hy vọng nó tự nghĩ hộ định nghĩa cho doanh nghiệp bạn.

• Cortex AI Gateway vào Preview ngày 15/09/2026
• Mỗi tài khoản có một đối tượng gateway tên SNOWFLAKE, ACCOUNTADMIN cấp quyền theo role
• Endpoint chuẩn theo định dạng OpenAI Chat Completions hoặc Anthropic Messages
• Bảng trace theo span ghi model đã gọi, thời gian từng bước, số token và lỗi
• View AI_GATEWAY_USAGE_HISTORY trong ACCOUNT_USAGE ghi gateway, user, model và token

Trong mọi doanh nghiệp mình làm việc cùng năm nay, câu hỏi khó trả lời nhất về AI không phải model nào tốt hơn, mà là tháng rồi chúng ta tiêu bao nhiêu cho AI và ai tiêu. Khi mỗi đội tự cắm API key riêng, câu hỏi đó không có câu trả lời, và hệ quả là ngân sách AI bị cắt vì không chứng minh được giá trị chứ không phải vì không có giá trị. Gateway giải đúng bài toán đó: một endpoint, quyền theo role, và một view trong ACCOUNT_USAGE để quy chi phí về từng user và từng model. Điều này nghĩa là gì cho người làm Data ở Việt Nam: bạn có thể trả lời câu hỏi ROI bằng SQL trên chính kho của mình, không cần dựng hệ thống đo riêng. Điểm phải nói thẳng: chấp nhận định dạng của OpenAI và Anthropic nghĩa là code ứng dụng không bị khoá, nhưng phần quan sát và phân quyền thì gắn chặt vào Snowflake. Đó là đánh đổi hợp lý nếu kho dữ liệu của bạn vốn đã ở đó, và là cái giá vô lý nếu không.

• Nêu tên vấn đề agent-data gap: dữ liệu ở ngoài, agent chỉ với qua công cụ chung chung
• Ontology được gói thành MCP server thay vì nhét vào prompt
• Ba lớp: schema, nội dung và công cụ
• Agent chủ động truy vấn ontology tại thời điểm chạy
• Builder agent tự dựng ontology, không cần viết tay toàn bộ

Bài này và Fivetran Context Layer công bố cách nhau hai ngày, giải cùng một bài toán từ hai phía, và đó là dấu hiệu rõ nhất cho thấy ngành đang hội tụ về một câu trả lời. Chi tiết kỹ thuật đáng học là việc bỏ lối nhồi ngữ nghĩa vào prompt. Nhồi vào prompt thì tốn context, không cập nhật được khi schema đổi, và tệ nhất là agent phải đọc hết mọi thứ kể cả phần không liên quan. Gói thành MCP server biến ngữ nghĩa thành thứ agent hỏi khi cần, đúng tinh thần retrieval thay vì tinh thần nhồi. Điều này nghĩa là gì cho người đang dựng trợ lý dữ liệu nội bộ: nếu bạn đang dán từ điển dữ liệu vào system prompt, đó là giải pháp tạm và nó sẽ vỡ khi kho vượt vài trăm bảng. Mình đã đi qua đúng đường đó và chuyển sang mô hình hỏi khi cần là thứ đáng làm sớm.

• Thực thi suy đoán khiến agent sửa trạng thái rải ở nhiều kho khác loại
• Chronos là hệ bolt-on, không bắt đổi database đang dùng
• Đánh phiên bản theo khoảng, gọn, hỗ trợ tạo nhánh và chia sẻ dữ liệu
• Merge thay đổi nhất quán xuyên các kho
• Hệ hiện có chỉ hỗ trợ một phần, buộc ứng dụng tự điều phối

Chủ đề nhánh dữ liệu cho agent đã xuất hiện vài lần trong năm nay, nhưng điểm khác của Chronos là chữ bolt-on. Các đề xuất trước phần lớn giả định bạn đổi sang một database mới có sẵn khả năng phân nhánh, mà đổi database là việc không ai làm vì một tính năng. Gắn thêm lên hệ đang có là con đường thực tế hơn nhiều. Vì sao chuyện này quan trọng: khi agent được quyền ghi, câu hỏi không còn là nó có làm đúng không mà là nếu sai thì lùi kiểu gì. Trên một database thì snapshot giải quyết được; trên ba hệ gồm Postgres, kho object và một cache thì không có ai đảm bảo cả ba lùi về cùng một mốc. Điều này nghĩa là gì cho doanh nghiệp: trước khi cho agent quyền ghi vào hệ thống thật, hãy vẽ ra đúng cơ chế hoàn tác. Nếu câu trả lời là khôi phục từ backup thì thực chất bạn chưa cho phép nó chạy tự động, bạn chỉ chưa gặp sự cố thôi.

• Agent chạy quy trình dài, tác động ra ngoài qua công cụ do bên khác cung cấp
• Retry, thực thi suy đoán, đồng thời và lỗi từng phần gây lệch trạng thái
• Bốn kiểu lệch: thiếu, nhân đôi, huỷ mà vẫn sống, chốt dựa trên trạng thái bị rút
• Mô hình lịch sử tác động tách sự kiện thật và quan sát của runtime
• Danh mục tám kiểu bất thường ở ranh giới agent và công cụ

Đây là bài mà mình nghĩ mọi người đang dựng agent tự động nên đọc, kể cả khi không quan tâm lý thuyết giao dịch. Lý do rất đời: thứ giết một quy trình tự động thường không phải lỗi đỏ mà là thành công giả. Tool trả về hai trăm OK, agent tin là xong, trong khi hệ đích đã ghi hai lần vì retry. Loại lỗi này không hiện lên dashboard, nó hiện ra ở cuối tháng khi số liệu không khớp. Điều này nghĩa là gì trong thực tế: mọi công cụ cho agent dùng phải có khoá idempotency, và runtime phải phân biệt được đã làm rồi với tưởng là đã làm rồi. Mình nói thẳng là phần lớn tích hợp MCP mình thấy hiện nay chưa làm chuyện này, vì lúc demo không ai retry cả. Nên làm ngay: mỗi tác động ghi ra ngoài phải có định danh do phía gọi sinh, và phía nhận phải từ chối định danh trùng.

• Khảo sát Harris Poll trên hơn 300 người ra quyết định tại Mỹ, công bố 18/09
• 9 trên 10 tổ chức đang triển khai AI agent tự trị
• 76 phần trăm tắc khi chuyển từ pilot sang production trong 12 tháng qua
• 72 phần trăm nói gốc rễ thất bại là nền dữ liệu kém hoặc không thống nhất
• 87 phần trăm phải thường xuyên xác minh lại ngữ cảnh mà agent đang dùng
• 51 phần trăm tốn nhiều giờ công rà và sửa tay đầu ra của agent trước khi phát hành

Con số làm mình dừng lại lâu nhất không phải 76 mà là 87 phần trăm phải thường xuyên xác minh lại ngữ cảnh agent đang dùng còn đúng hay không. Nói cách khác, doanh nghiệp tự động hoá được phần sinh ra câu trả lời nhưng lại thêm một việc thủ công mới là kiểm tra xem nền tri thức phía dưới có còn chuẩn không. Đó không phải tiết kiệm, đó là dời việc. Ghép với con số 51 phần trăm phải rà tay đầu ra trước khi phát hành, bức tranh khá rõ: nhiều nơi đang trả tiền cho AI và trả tiếp tiền cho người canh AI. Điều này nghĩa là gì cho doanh nghiệp Việt đang định triển khai agent: đầu tư đúng thứ tự là ngữ nghĩa và quản trị trước, agent sau. Mình không nói điều này để bi quan, ngược lại, những nơi có data warehouse gọn và từ điển dữ liệu rõ đang đi nhanh hơn hẳn phần còn lại, và khoảng cách đó đang giãn ra theo tháng.

• Ryan Blue nêu hai phương án: chặn nghiêm theo phiên bản hay đọc nỗ lực tối đa
• Bối cảnh: thay đổi phá vỡ trong spec như đổi ngữ nghĩa metadata
• Cuối tuần phần đông nghiêng về chặn nghiêm
• Cùng mạch với việc Iceberg cấm ghi _pos và Arrow khai tử Tensor
• Nguyên tắc chung: giữ dữ liệu cũ đọc được, cắt đường ghi mới

Nghe hàn lâm nhưng đây là loại quyết định có hậu quả rất cụ thể với doanh nghiệp. Hình dung một pipeline Spark bản mới ghi file Parquet dùng tính năng mới, còn một job báo cáo chạy thư viện cũ đọc file đó. Nếu reader cố đọc đại, báo cáo vẫn ra số, chỉ là số sai, và không ai biết cho tới khi kế toán thắc mắc. Nếu reader chặn thẳng, job đỏ ngay hôm đó và ai đó phải nâng cấp thư viện. Đau nhưng rõ ràng, và đây là lý do mình ủng hộ phương án chặn. Điều này nghĩa là gì trong thực tế vận hành: hãy coi phiên bản thư viện Parquet và Arrow là thứ phải quản như quản schema, chứ không phải dependency tiện đâu nâng đó. Bài học liên quan là nguyên tắc mà cả Iceberg lẫn Arrow đang theo tuần này, tức giữ dữ liệu cũ đọc được nhưng cắt đường ghi mới, và đó là cách tử tế nhất để một format già đi mà không phản bội dữ liệu đã lưu.

• Croissant là mô tả JSON-LD trên schema.org cho dataset ML
• Từ bản 1.1 có điều kiện sử dụng nhưng không có thủ tục đánh giá
• Profile cộng thêm: tập đóng gồm đúng năm toán tử, có thủ tục quyết định đầy đủ
• Cổng kiểm quyết định chỉ từ bản mô tả và ghi lại đã kiểm những gì
• Đo trên pipeline nf-core thật: thêm 11,7 micro giây so với 119 micro giây mỗi quyết định
• Bóc lớp profile ra vẫn còn một tài liệu Croissant hợp lệ

Đây là chủ đề đang nóng lên rất nhanh vì nó chạm vào chuyện ai được lấy dữ liệu của ai để huấn luyện. Hiện tại giấy phép dataset chủ yếu là văn bản cho người đọc, nên khâu tuân thủ phụ thuộc vào thiện chí và vào việc có ai đọc hay không. Biến điều kiện thành thứ máy quyết định được, với một tập toán tử đóng và chi phí đo được, là bước đi đúng hướng vì nó cho phép cắm cổng kiểm thẳng vào pipeline huấn luyện. Con số 11,7 micro giây là điểm quan trọng nhất của bài: nó cho thấy lý do chi phí không còn là cái cớ để bỏ qua. Điều này nghĩa là gì cho doanh nghiệp Việt đang gom dữ liệu để huấn luyện hoặc fine-tune: hãy lưu điều kiện sử dụng cùng dữ liệu ngay từ lúc nạp, ở dạng máy đọc được, chứ đừng để trong một file hợp đồng PDF. Lúc cần chứng minh nguồn gốc, thứ cứu bạn là nhật ký kiểm tra chứ không phải trí nhớ.

• Số 287 phát hành ngày 14/09/2026
• Pinterest mở rộng nền tảng Manas quản hàng chục tỷ embedding, giảm chi phí hạ tầng
• Thumbtack làm vector search bằng chính Postgres và pipeline sẵn có
• Luận điểm: embedding là dữ liệu bền, phải có quản trị như mọi bảng khác
• AI đang định hình lại đội data trong khi pipeline cũ không sinh ra cho việc này

Mình thích số này vì nó đặt hai thái cực cạnh nhau. Pinterest ở quy mô hàng chục tỷ embedding thì đúng là phải có nền tảng chuyên dụng, không bàn cãi. Nhưng Thumbtack mới là case mà đa số doanh nghiệp nên soi vào: tái dùng Postgres đang có, tái dùng pipeline đang có, và coi embedding như một cột dữ liệu phải được version, phải có người sở hữu, phải biết sinh ra từ model nào. Mình đi tư vấn thấy rất nhiều đội nhảy thẳng sang mua một vector database riêng cho vài trăm nghìn tài liệu, rồi tự tạo thêm một hệ thống phải đồng bộ, phải sao lưu, phải phân quyền lại từ đầu. Điều này nghĩa là gì: hãy bắt đầu từ chỗ dữ liệu đang nằm, và chỉ tách ra khi có số liệu chứng minh đã chạm trần. Câu quan trọng nhất trong số này là embedding phải được coi là dữ liệu có quản trị, vì nó nhắc rằng một embedding sinh từ model cũ mà không ai đánh dấu chính là một quả bom hẹn giờ cho chất lượng tìm kiếm.

• Chi tiêu AI toàn cầu 2026 dự báo 2.700 tỷ đô, tăng 49,5 phần trăm
• Nền tảng phát triển ứng dụng AI: dự báo tăng từ 28 lên 39 phần trăm
• Mô hình generative AI: dự báo tăng từ 110 lên 117 phần trăm
• Dự án chuyển đổi và gián tiếp tạo cơ hội 1.200 tỷ đô cho dịch vụ AI tới 2030
• Gartner tách agent đa chức năng khỏi nhóm phần mềm AI trong cách phân loại mới

Con số tổng thì to nhưng ít dùng được. Thứ đáng phân tích là việc Gartner nâng dự báo cho nền tảng phát triển ứng dụng AI mạnh tới vậy, từ 28 lên 39 phần trăm chỉ sau một quý. Nó nói rằng doanh nghiệp đang chuyển từ mua sản phẩm AI đóng gói sang tự xây ứng dụng riêng trên dữ liệu của mình, và đó chính xác là lý do mọi tin còn lại trong tuần này đều xoay quanh lớp ngữ cảnh, gateway và quản trị. Điều này nghĩa là gì cho doanh nghiệp Việt: nhu cầu nhân sự sẽ dồn về người biết ghép dữ liệu với AI chứ không phải người biết gọi API model. Mình cũng muốn nói thẳng một điều: Gartner nâng dự báo không đồng nghĩa các khoản chi đó sinh lời, và chính nghiên cứu của họ nhắc ít nhất một nửa dự án generative AI doanh nghiệp bị bỏ sau giai đoạn chứng minh khái niệm vì chất lượng dữ liệu kém, chi phí leo thang và kiểm soát rủi ro thiếu. Chi nhiều không phải là chiến lược.

• Công bố ngày 18/09/2026
• xFactory là nhà máy phần mềm AI dạng riêng tư cho môi trường lai
• Xây, kiểm thử và triển khai agent, ứng dụng và phân tích
• Thực thi native trên Apache Spark, Trino và Kafka
• Xuất phát từ mô tả ý định nghiệp vụ, chạy trên dữ liệu liên kết

Có hai trường phái đang đánh nhau trong ngành dữ liệu năm nay. Một bên nói hãy gom hết về một nền tảng rồi mọi thứ sẽ mạch lạc, đó là câu chuyện của Databricks và Snowflake. Bên kia nói dữ liệu sẽ mãi nằm rải rác vì lý do pháp lý và lịch sử, nên hãy đưa tính toán tới chỗ dữ liệu. Acceldata chọn vế thứ hai, và điểm đáng chú ý là họ dựa vào engine mở chứ không dựng runtime riêng. Điều này nghĩa là gì cho doanh nghiệp Việt, nhất là ngân hàng và khối nhà nước: yêu cầu dữ liệu không được rời hạ tầng nội bộ biến phần lớn nền tảng SaaS thành bất khả thi về mặt thủ tục, và mô hình liên kết là cửa duy nhất. Mình chỉ lưu ý một điều từ kinh nghiệm: chạy liên kết nghe đẹp nhưng hiệu năng phụ thuộc hoàn toàn vào đường truyền giữa các cụm, nên hãy đo băng thông và độ trễ trước khi tin vào bản demo.

• Gọi 5 triệu đô từ Mozilla, công bố ngày 18/09/2026
• Ra đời tháng 11/2025, thành công ty độc lập tại Anh trong 2026
• Dữ liệu phủ hơn 450 ngôn ngữ
• 350 tổ chức được duyệt để đóng góp dữ liệu
• Mọi tổ chức đóng góp đều được thẩm định, mọi bộ dữ liệu đều được rà trước khi lên
• Ra mắt Compensated Datasets và cuộc thi Lost in Transcription cho nhận dạng tiếng nói

Con số 450 ngôn ngữ là thứ đáng chú ý với người Việt hơn là số tiền 5 triệu đô, vốn nhỏ so với mặt bằng gọi vốn AI hiện nay. Chất lượng model cho tiếng Việt từ trước tới nay phụ thuộc vào việc dữ liệu tiếng Việt có mặt trong kho huấn luyện với chất lượng thế nào, và phần lớn dữ liệu đó bị cào tự động, không ai trả tiền, không ai kiểm chất lượng. Một chợ dữ liệu có thẩm định nguồn, có giấy phép rõ và có cơ chế trả tiền là hạ tầng mà các ngôn ngữ không phải tiếng Anh đang rất cần. Điều này nghĩa là gì cho tổ chức Việt Nam đang giữ kho dữ liệu tiếng Việt chất lượng: đây có thể là kênh vừa kiếm được tiền vừa cải thiện chất lượng model cho chính ngôn ngữ của mình, thay vì để dữ liệu bị lấy không. Mình nói thẳng là mô hình này còn phải chứng minh về mặt kinh doanh, nhưng hướng đi thì đúng.

• Vòng Series B 72 triệu đô, công bố ngày 17/09/2026
• Tổng vốn huy động đạt 112 triệu đô
• Nhắm thị trường chống thất thoát dữ liệu quy mô nhiều tỷ đô
• Luận điểm: AI đổi cả quy mô lẫn đường đi của dữ liệu nhạy cảm

Nhà đầu tư đổ tiền vào DLP lúc này không phải ngẫu nhiên. Ba năm trước, dữ liệu rời doanh nghiệp qua vài kênh đếm được: email, ổ cứng di động, upload thủ công. Giờ thì mỗi nhân viên có một ô chat nói chuyện với model bên ngoài, mỗi agent có quyền đọc kho tài liệu nội bộ, và mỗi tích hợp MCP là một đường dẫn dữ liệu mới mà đội bảo mật chưa kịp vẽ vào sơ đồ. Điều này nghĩa là gì cho doanh nghiệp Việt: chính sách bảo mật viết cho thời email không bảo vệ được gì trong bối cảnh này, và việc cấm dùng AI cũng không hiệu quả vì nhân viên sẽ dùng bằng máy cá nhân. Cách làm thực tế hơn là cấp một đường chính thức có ghi nhật ký, cộng với phân loại dữ liệu để biết cái gì tuyệt đối không được rời hệ thống. Đó cũng là lý do mình đánh giá cao việc Snowflake và Databricks đều đẩy gateway trong tuần này: một cửa duy nhất có kiểm soát vẫn tốt hơn mười cửa không ai canh.

• Công bố ngày 17/09/2026 tại London
• Niềm tin vào ngân sách alternative data cao nhất trong 3 năm
• 97 phần trăm người trả lời có kỳ vọng tích cực về ngân sách
• Lo ngại về chất lượng dữ liệu vẫn tồn tại song song

Alternative data là dữ liệu ngoài báo cáo tài chính: ảnh vệ tinh bãi xe, dữ liệu thẻ thanh toán, lưu lượng web, tin tuyển dụng. Nó được mua để tìm lợi thế thông tin, nên càng nhiều tiền đổ vào thì càng nhiều nhà cung cấp mới xuất hiện, và chất lượng phân hoá rất nhanh. Cặp số liệu trong khảo sát này kể một câu chuyện quen thuộc: tiền tăng trước, năng lực thẩm định tăng sau. Điều này nghĩa là gì cho bất kỳ ai mua dữ liệu bên ngoài, không riêng ngành tài chính: hợp đồng phải ràng buộc về độ trễ, độ phủ, tỷ lệ thiếu và quy trình khi nhà cung cấp đổi phương pháp thu thập. Mình gặp nhiều trường hợp mô hình đột nhiên lệch không phải vì mô hình hỏng mà vì nhà cung cấp lặng lẽ đổi cách lấy số, và không có điều khoản nào bắt họ phải báo.