• Iceberg nay chỉ định nghĩa cô lập ở mức một thao tác ghi trên một bảng.
• Hướng 1: API LoadTables theo lô trả về metadata nhiều bảng atomic tại một thời điểm.
• Hướng 2: commit sequence number đơn điệu để ghim lát cắt nhất quán xuyên bảng.
• Russell Spitzer, Andrei Tserakhau, Maninder Parmar tham gia, coi hai hướng bổ trợ.

Nói thẳng: đây là thứ kỹ thuật nhưng cốt lõi cho kỷ nguyên agent. Lâu nay Iceberg chỉ lo một bảng, nên khi agent join năm bảng, nó có thể thấy dữ liệu nửa vời, một phần đã ghi, một phần chưa. Với pipeline đọc bảng fact và mấy bảng dimension, sai một nhịp là ra số sai mà không ai biết. Hai hướng đề xuất không đá nhau: batch load lo phần đọc, sequence number cho đảm bảo mạnh hơn về thứ tự xuyên bảng. Điều đáng giá nhất là cuộc tranh luận buộc cộng đồng quyết định logic nhất quán nên nằm ở catalog, ở format hay ở engine, và câu trả lời sẽ định hình cả semantic layer lẫn scan-planning sau này. Với người Việt làm nền dữ liệu, đừng vội nhưng hãy theo dõi: nền móng cho agent đáng tin đang được đổ ngay lúc này.

• Đưa primary key vào table format thay vì để mỗi engine tự dựng lại.
• Phục vụ mẫu vận hành và change-data, nơi khóa mang ngữ nghĩa thật.
• Khó: chi phí enforcement, merge-on-read, tương tác equality delete.
• Thảo luận còn sớm, chưa thành thay đổi spec.

Đây là tín hiệu Iceberg đang bị kéo từ kho phân tích về phía cơ sở dữ liệu vận hành. Khi khóa nằm trong format, mọi engine đọc Iceberg đều hiểu giống nhau về danh tính từng dòng, thay vì mỗi nơi diễn giải một kiểu, dễ sinh lỗi khi upsert. Lợi ích rõ cho change-data capture và các bài toán trộn OLTP với OLAP, đúng hướng cả ngành đang đi với LTAP và lakehouse vận hành. Nhưng đừng kỳ vọng nhanh: cưỡng chế tính duy nhất của khóa trên dữ liệu phân tán cực tốn, và phải hòa hợp với cơ chế xóa hiện có. Với team Việt, chưa cần làm gì ngay, nhưng nếu bạn đang thiết kế pipeline CDC trên Iceberg, hãy thiết kế sao cho dễ tận dụng khóa native khi nó chín.

• Forensics và trực quan hóa sức khỏe bảng Iceberg.
• Đúc kết từ vận hành Iceberg ở quy mô lớn tại Confluent.
• Phát hiện file nhỏ, dữ liệu mồ côi, metadata phình, snapshot vô hạn.
• Cộng đồng đánh giá là hướng đi hữu ích cho đội nền tảng.

Ai vận hành Iceberg ở quy mô đều thấm: bảng trôi vào trạng thái xấu vì quá nhiều file nhỏ, dữ liệu mồ côi sau khi rewrite, metadata phình và lịch sử snapshot không bao giờ được dọn. Những thứ này âm thầm làm chậm truy vấn và đội hóa đơn object storage. Iceberg Doctor làm cho các bệnh đó nhìn thấy được, đó là bước trưởng thành cần thiết: format đã đủ phổ biến để việc chăm sóc nó, chứ không chỉ ghi vào, trở thành công việc hằng ngày. Với đội data Việt đang chạy lakehouse, đây là gợi ý thực tế: lên lịch maintenance, compaction và expire snapshot ngay từ đầu, đừng đợi tới khi truy vấn chậm mới đi tìm nguyên nhân.

• Gộp ba GET (root manifest, data file, nén file nhỏ) khi đọc Parquet.
• Mục tiêu: cắt số round-trip tới object storage cho workload file nhỏ.
• Quantile sketch ở mức bảng lưu trong Puffin cho Spark CBO.
• Phân phối giá trị tốt hơn giúp join và filter nhanh hơn.

Hai chuyện nhỏ nhưng chạm đúng ví tiền. Với workload streaming ingest và commit liên tục, số file nhỏ bùng nổ, và mỗi lần đọc lại tốn nhiều lệnh GET riêng lẻ tới S3, độ trễ và chi phí phần lớn nằm ở đó chứ không phải ở compute. Gộp các GET lại là cách trực tiếp giảm cả độ trễ lẫn hóa đơn. Còn quantile sketch trong Puffin giúp planner Spark hiểu phân phối dữ liệu để chọn kế hoạch join, filter tốt hơn, nhanh hơn mà không cần đổi gì ở dữ liệu. Đây là loại tối ưu ít ai để ý nhưng cộng dồn lại tiết kiệm thật. Bài học cho team Việt: trước khi nâng cấp cluster, hãy nhìn lại số file nhỏ và cách đọc, nhiều khi đó mới là thủ phạm làm chậm và đắt.

• Phát hành đồng thời 1.5.4 (Variegata) và LTS 1.4.5 (Andium).
• Dòng LTS đã mang AES-256, lệnh MERGE, ghi Iceberg.
• Mức tăng hiệu năng quanh 20% so với trước.
• Chạy từ laptop, edge, browser tới Lambda và Workers.

DuckDB đã rời hẳn vai công cụ notebook để thành hạ tầng phân tích thật. Bản LTS quan trọng với doanh nghiệp vì cho một mốc ổn định, được vá lâu dài, để bám vào mà không phải chạy theo mỗi bản minor. Với team data nhỏ ở Việt Nam, đây là tin vui thực tế: bạn xử lý hàng chục đến hàng trăm GB ngay trên một máy, đọc thẳng Parquet và Iceberg trên S3, mà không cần dựng cluster Spark tốn kém. Lời khuyên của mình: với khối lượng vừa, hãy thử DuckDB trước, chỉ leo lên engine phân tán khi thật sự chạm trần. Tiết kiệm tiền và đơn giản hóa vận hành thường quan trọng hơn là chọn công nghệ nghe oách.

• Gom danh mục về một nền duy nhất: Alteryx One.
• Governed shared workspace + Live Query chạy trong nền khách hàng.
• Agent Studio và MCP server mở workflow ra agent ngoài.
• Nghiên cứu: tự động 75-100% việc lặp, rút timeline DS hơn 40%.

Thông điệp thật của Alteryx không phải thêm một công cụ AI nữa, mà là làm lớp lòng tin cho output AI. Cái hay nằm ở điều kiện in chữ nhỏ: con số tự động hóa 75 đến 100% chỉ đạt được khi khách vào cuộc với dữ liệu đã quản trị và logic nghiệp vụ chuẩn hóa. Đó chính là bài học mình lặp lại với khách hàng: AI chỉ tạo giá trị khi đặt trên dữ liệu sạch và quy tắc rõ ràng, tự động hóa mà không có quản trị chỉ là nhân bản hỗn loạn nhanh hơn. Live Query chạy phân tích ngay trong nền dữ liệu của khách cũng là xu hướng đúng: đưa tính toán tới dữ liệu thay vì kéo dữ liệu ra. Với doanh nghiệp Việt, đừng mua công cụ trước, hãy chuẩn hóa định nghĩa nghiệp vụ và quản trị trước, rồi công cụ mới phát huy.

• Search và Liveboard chạy bằng AI trên warehouse và lakehouse.
• Hỏi dữ liệu bằng ngôn ngữ tự nhiên, không cần SQL.
• Agent gợi ý insight và tự đặt câu hỏi nối tiếp.
• Định vị giao diện search-first để dân chủ hóa phân tích.

Hướng đi của ThoughtSpot đúng nhu cầu thật: phần lớn người ra quyết định trong doanh nghiệp không viết SQL, và mỗi câu hỏi phải qua đội data là một nút thắt. Đưa agent vào để tự gợi ý và đặt câu hỏi nối tiếp biến phân tích thành hội thoại, gần với cách con người tư duy hơn. Nhưng theo mình, điểm yếu muôn thuở của text-to-search vẫn là độ tin cậy: nếu lớp ngữ nghĩa phía dưới không chuẩn, agent có thể trả lời nghe hợp lý nhưng sai, và sai kiểu này nguy hiểm vì người dùng tin ngay. Vì vậy lời khuyên của mình không đổi: muốn agentic BI dùng được, hãy đầu tư semantic layer và định nghĩa metric dùng chung trước, công cụ search chỉ là phần nổi.

• Cobuild chính thức GA cho khách hàng.
• Ngôn ngữ tự nhiên thành dự án AI sẵn sàng sản xuất, không cần code.
• Tự lắp workflow kiểm tra được, kết nối dữ liệu và model.
• Điều phối analytics, ML, agent xuyên nhiều nhà cung cấp.

Cobuild nhắm thẳng vào nỗi đau kinh điển của AI doanh nghiệp: hoặc cho người dùng tự do dựng nhanh và mất kiểm soát, hoặc siết quản trị và mọi thứ ì ạch. Cách Dataiku giải là để agent dựng nhanh nhưng mọi thứ vẫn nằm trong một môi trường quản trị duy nhất, workflow kiểm tra được chứ không phải hộp đen. Theo mình, đây là xu hướng đáng theo dõi nhất cho doanh nghiệp Việt: thay vì tuyển thật nhiều người biết code, hãy đầu tư nền tảng cho người hiểu nghiệp vụ tự dựng giải pháp trong khung quản trị. Nhưng cần tỉnh táo, agent dựng nhanh chỉ tốt khi dữ liệu phía dưới sạch và định nghĩa nghiệp vụ rõ, nếu không nó chỉ giúp bạn sai nhanh hơn. Đừng biến nó thành phong trào, hãy biến nó thành hệ thống.

• AI agent biến output phân tích thành hành động vận hành.
• Nối agent vào dashboard, chỉ số và dự báo.
• Đề xuất hoặc thực thi workflow dưới sự quản trị.
• Nhắm môi trường người vận hành quá tải.

Đây là mảnh ghép mà mình thấy đa số doanh nghiệp Việt còn thiếu: phân tích dừng ở dashboard, rồi nằm đó. Data không chỉ để báo cáo, data phải giúp hành động. Hướng của WisdomAI, nối agent từ chỉ số sang đề xuất và thực thi workflow, đúng tinh thần đó. Nhưng có một lằn ranh phải cẩn thận: để agent đề xuất thì tốt, để agent tự thực thi hành động vận hành thì phải có quản trị và human-in-the-loop ở những quyết định rủi ro cao. Mình khuyên bắt đầu nhỏ: chọn một quy trình lặp lại, rủi ro thấp, đo được giá trị, cho agent đề xuất trước, con người duyệt, rồi mới nới dần quyền tự động. Tự động hóa quyết định mà không có lan can là rước rủi ro vào nhà.

• Loạt cập nhật mới cho Skylar AI.
• Xếp Leader trong IDC MarketScape Worldwide AIOps 2026.
• AI agent trên dữ liệu vận hành và quan sát hệ thống.
• Tự phát hiện bất thường, phân tích nguyên nhân, rút ngắn xử lý sự cố.

AIOps là minh chứng rõ cho luận điểm data-for-AI: khối dữ liệu vận hành, log và metric, vừa khổng lồ vừa đắt, và là nơi AI agent tạo giá trị đo được ngay, giảm thời gian xử lý sự cố. Việc một hãng được xếp Leader trong IDC MarketScape là tín hiệu thị trường này đã chín, không còn là thử nghiệm. Với đội vận hành ở Việt Nam, bài học rút ra không nhất thiết là mua Skylar, mà là cách tiếp cận: gom dữ liệu quan sát về một chỗ có cấu trúc, rồi để agent gánh phần phân loại cảnh báo và gom ngữ cảnh, phần mà con người làm vừa chậm vừa dễ bỏ sót khi quá tải. Đây là dạng tự động hóa an toàn để bắt đầu, vì rủi ro thấp và lợi ích thấy ngay.

• Kiến trúc lan truyền danh tính agent xuyên workflow đa agent.
• Giữ ngữ cảnh người dùng gốc và nguồn gốc từng agent.
• Quyền truy cập theo phạm vi khi agent ủy thác và gọi tool.
• Phân tích kèm góc nhìn Auth0 về access control.

Đây là chủ đề ít hào nhoáng nhưng sẽ quyết định agentic AI có vào được doanh nghiệp thật hay không. Khi một agent gọi agent khác, rồi agent đó truy vấn dữ liệu nhạy cảm, câu hỏi ai đang hành động và với quyền của ai trở nên sống còn. Nếu mất ngữ cảnh người dùng gốc, bạn có hai rủi ro: agent làm việc vượt quyền, hoặc không truy vết được khi có sự cố. Cách Uber giữ provenance và scoped access xuyên chuỗi ủy thác chính là nền cho audit và compliance. Với doanh nghiệp Việt định triển khai agent trên dữ liệu nội bộ, đừng để phần identity và phân quyền tới sau cùng, hãy thiết kế nó ngay từ đầu, vì vá bảo mật sau khi agent đã chạy là việc rất đắt.

• Điểm động thái Alteryx, Dataiku, Domino, Reveal, ThoughtSpot, WisdomAI.
• Editor's Lens: lakehouse mạnh nhưng AI cần nhiều hơn hạ tầng.
• Tổ chức đã đổ tiền vào lake và warehouse nhiều năm.
• AI cần thêm lớp ngữ cảnh, ngữ nghĩa và quản trị.

Bài Editor's Lens chốt đúng tinh thần cả tuần, và mình hoàn toàn đồng ý. Nhiều doanh nghiệp nghĩ chỉ cần dựng được lakehouse là sẵn sàng cho AI, nhưng thực tế hạ tầng chỉ là điều kiện cần. Cái thiếu là lớp ngữ cảnh: định nghĩa nghiệp vụ, semantic layer, quản trị và chất lượng dữ liệu, đó mới là thứ làm agent trả lời đáng tin. Đây cũng là sợi chỉ nối các đề xuất Iceberg và tranh luận catalog tuần này. Với người Việt làm dữ liệu, thông điệp thực dụng: nếu đã có lakehouse mà AI vẫn chưa tạo giá trị, đừng vội đổ thêm tiền vào hạ tầng, hãy soi lại lớp ngữ cảnh và quản trị phía trên, phần lớn vấn đề nằm ở đó.

• Catalog tiến hóa từ danh bạ bảng thành control plane.
• Phục vụ một chỗ cho agent, BI tool và query engine.
• Polaris bàn REST cho định dạng ngoài Iceberg, datasource runtime.
• Semantic layer sống ngay trong catalog.

Cuộc chiến định dạng bảng coi như đã xong, Iceberg gần như là chuẩn mặc định. Chiến trường mới là catalog, và đây là điều mọi người ra quyết định kiến trúc cần hiểu. Khi catalog ôm cả semantic layer, quản trị, bảo mật và liên thông, ai sở hữu nó là kiểm soát optionality của bạn trong cả thập kỷ. Ba hướng Polaris đẩy đều quan trọng: REST mở cho format ngoài Iceberg để không bị khóa, datasource runtime cho linh hoạt, và semantic layer trong catalog để định nghĩa nghiệp vụ dùng chung. Lời khuyên thẳng của mình cho doanh nghiệp Việt: khi chọn nền dữ liệu, đừng chỉ hỏi engine chạy nhanh cỡ nào, hãy hỏi catalog mở tới đâu và có tránh được lock-in không. Đó mới là quyết định khó đảo ngược.

• Cầu kỹ sư dữ liệu cao do nhu cầu nền tảng infrastructure-first.
• Người mới khó vào: ít vị trí entry, cạnh tranh gắt.
• Lối đi phổ biến: data analyst rồi chuyển sang data engineer.
• Tranh cãi: trả tiền học khóa hay tự học với mentor.

Tín hiệu từ cộng đồng rất thực tế cho người Việt đang nhắm ngành dữ liệu. Cầu là thật, nhưng cửa cho người mới hẹp, nên kỳ vọng nhảy thẳng vào vị trí data engineer entry thường vỡ mộng. Lối đi bền hơn là vào bằng data analyst, vững SQL và Python, làm việc thật với dữ liệu rồi chuyển dần sang data engineer. Về chuyện học, mình nghiêng về quan điểm trong thread: tài nguyên miễn phí thừa thãi, cái thiếu là người dẫn và dự án thật, nên có mentor và làm dự án end-to-end quan trọng hơn một tấm chứng chỉ. Và trong thời agent, kỹ năng đáng giá nhất không phải gõ pipeline tay, mà là hiểu kiến trúc, biết kiểm định output của AI và gắn dữ liệu với quyết định nghiệp vụ.

• MLOps cho ngành bị quản lý chặt (tài chính, y tế...).
• Theo dõi thí nghiệm tập trung, quản trị model.
• Pipeline tái lập được cho dự án data science.
• Đáp ứng rủi ro, tuân thủ và kiểm toán mà vẫn ship nhanh.

Với doanh nghiệp Việt trong ngành bị quản chặt như ngân hàng, bảo hiểm, y tế, rào cản đưa AI vào sản xuất hiếm khi là model giỏi tới đâu, mà là chứng minh được model được xây thế nào, dữ liệu nào, ai duyệt, có tái lập được không khi thanh tra hỏi. Đó đúng là chỗ Domino nhắm tới: experiment tracking tập trung, model governance và pipeline reproducible. Theo mình, đây là phần kém hào nhoáng nhưng quyết định AI có ở lại sản xuất hay chết yểu sau pilot. Lời khuyên thực dụng: ngay cả khi chưa mua nền tảng chuyên dụng, hãy thiết lập kỷ luật version hóa dữ liệu, model và code, ghi lại quyết định, vì khi cần audit mà không có vết là rất rủi ro.

• Nhúng dashboard tương tác và tự khám phá dữ liệu trong app SaaS.
• Insight chạy bằng AI ngay trong sản phẩm.
• Tích hợp qua SDK và mẫu low-code.
• Biến phân tích thành phần tự nhiên của luồng sản phẩm.

Embedded analytics là một trong những cách thực dụng nhất để dữ liệu tạo giá trị: thay vì bắt người dùng rời sản phẩm sang một công cụ BI riêng, bạn đưa dashboard và insight ngay vào nơi họ đang làm việc. Với nhà làm SaaS Việt, đây là hướng vừa tăng giá trị sản phẩm vừa giữ chân người dùng, mà không phải tự xây nền BI từ đầu, một việc tốn kém và dễ sa lầy. Theo mình, mấu chốt không phải chọn SDK nào, mà là thiết kế đúng câu hỏi: người dùng cần quyết định gì tại màn hình này, rồi mới đưa đúng số liệu vào đó. Nhồi biểu đồ cho đẹp không giúp ai cả, dashboard đẹp không có nghĩa là đang ra quyết định tốt.