• 13/08: CREATE OR ALTER dùng được cho dynamic Apache Iceberg table.
• 10/08: tích hợp Amazon S3 Tables qua Iceberg REST catalog lên GA.
• 10/08: AI_MULTI_EMBED hỗ trợ video lớn trong semantic video search, GA.
• 13/08: bản cập nhật Snowflake Data Clean Rooms.
• 14/08: CoCo Desktop v1.21.0.

Nghe thì khô, nhưng CREATE OR ALTER là thứ đội data engineering chờ lâu rồi. Trước đây muốn sửa định nghĩa một dynamic table thường phải drop rồi tạo lại, kéo theo rủi ro mất lịch sử làm mới và gãy pipeline downstream. Có CREATE OR ALTER thì file định nghĩa bảng thành thứ khai báo được, đưa vào Git rồi apply lại như code hạ tầng. Phần S3 Tables lên GA còn quan trọng hơn về mặt chiến lược: Snowflake đọc bảng Iceberg do AWS quản mà không đòi bạn nạp dữ liệu vào kho của họ. Với doanh nghiệp Việt đang phân vân giữa việc gom hết vào một nhà cung cấp hay giữ dữ liệu ở lớp mở, đây là bằng chứng lớp mở đang thắng dần. Khuyến nghị của mình: nếu team bạn đang xây mới trên Snowflake, hãy chuẩn hoá bảng dạng Iceberg ngay từ đầu, đừng để hai năm nữa mới đi di trú. Còn nếu đã lỡ dùng bảng nội bộ, ít nhất hãy tách phần dữ liệu thô ra định dạng mở trước.

• Daniel Weeks chia phạm vi spec v4 thành ba nhóm công việc rõ ràng.
• Đồng thuận đang hình thành: manifest v4 chỉ dùng Parquet, bỏ Avro.
• EagerInputFile giảm 25-55% thời gian đọc manifest Parquet trên S3.
• PyIceberg 0.12.0rc1 bị chặn vì lỗi tính đúng đắn, chờ rc2.
• Apache Polaris 1.7.0 ra bản mới; Parquet chốt bỏ phiếu về versioning.

Đây là loại tin dễ bị bỏ qua nhưng ảnh hưởng tới mọi người dùng Iceberg. Mỗi truy vấn Iceberg đều phải mở manifest để biết file nào cần đọc; manifest chậm thì kể cả engine nhanh cũng phải chờ. Avro là định dạng dòng, không cho đọc riêng vài cột, nên đọc manifest luôn phải nạp dư. Chuyển sang Parquet, engine chỉ lấy đúng cột cần cho việc pruning. Con số 25 đến 55% từ bản vá EagerInputFile cho thấy dư địa tối ưu còn rất lớn. Với người dùng, tác động thực tế nằm ở bảng lớn nhiều nghìn file, nơi thời gian lập kế hoạch truy vấn đôi khi lâu hơn cả thời gian quét dữ liệu. Chuyện PyIceberg rc1 bị chặn vì lỗi tính đúng đắn cũng đáng khen: cộng đồng chọn dừng phát hành thay vì đẩy ra rồi vá sau. Lời khuyên thực dụng: đừng vội nâng cấp lên spec mới ngay khi ra, nhưng hãy theo dõi engine mình dùng có hỗ trợ đọc manifest Parquet không, vì đó sẽ là điều kiện để hưởng phần tăng tốc này.

• Machine Data Lake, Data Catalog và Agent Launchpad đều lên GA.
• Federated Search mở rộng ra lake, warehouse và nền tảng AI bên ngoài.
• GA trên Splunk Cloud Platform 10.5.2605.5 từ 04/08.
• Bốn khu vực đầu tiên: US-East, Frankfurt, Tokyo, Sydney.
• Mục tiêu: giữ dữ liệu máy full-fidelity mà vẫn kiểm soát chi phí.

Câu chuyện thật ở đây là kinh tế học của log. Mọi tổ chức đều muốn giữ log đủ lâu để điều tra sự cố và đáp ứng kiểm toán, nhưng chi phí index kiểu truyền thống khiến người ta phải cắt bớt thời gian lưu. Machine Data Lake tách phần lưu rẻ ra khỏi phần kích hoạt đắt, còn Catalog và Federated Search lo phần tìm được dữ liệu ở nơi nó nằm. Đây là kiến trúc ngược với tư duy gom hết về một kho trung tâm, và nó phản ánh thực tế rằng chi phí di chuyển dữ liệu giờ thường lớn hơn chi phí lưu. Với doanh nghiệp Việt Nam, nhất là ngân hàng và viễn thông đang bị log phình theo mỗi hệ thống mới, mô hình này đáng cân nhắc trước khi ký gia hạn hợp đồng lưu trữ tập trung. Điều cần cẩn trọng: federated search nghe hay nhưng độ trễ truy vấn xuyên kho luôn cao hơn truy vấn tại chỗ, nên hãy thử nghiệm với truy vấn điều tra sự cố thật, đừng chỉ tin demo.

• Exadata Database Service trên Exascale lên GA cho Oracle AI Database@AWS.
• Chạy native trong Availability Zone của AWS.
• Mua và thanh toán qua AWS Marketplace.
• Compute và storage scale tách rời, tính tiền theo mức dùng.
• Khởi điểm có mặt ở 22 AWS Region.

Rất nhiều doanh nghiệp lớn ở Việt Nam vẫn chạy lõi nghiệp vụ trên Oracle, trong khi đội phân tích và AI lại làm việc trên AWS. Kết quả là một đống pipeline sao chép dữ liệu qua lại, mỗi lần chậm là mỗi lần cãi nhau. Đưa Exadata vào chạy ngay trong Availability Zone của AWS cắt bớt chặng mạng và chặng đồng bộ đó. Điểm đáng chú ý về thương mại là mua qua AWS Marketplace, nghĩa là chi phí Oracle có thể tính vào cam kết chi tiêu với AWS, một chi tiết mà đội tài chính sẽ quan tâm hơn đội kỹ thuật. Nhưng cần nói thẳng phần rủi ro: chạy được ở cùng vùng không có nghĩa là kiến trúc dữ liệu tự tốt lên. Nếu mô hình dữ liệu vẫn là bảng nghiệp vụ thô, không có lớp semantic và không ai định nghĩa chỉ số, thì đưa nó lên đâu cũng vẫn tắc ở khâu báo cáo. Hạ tầng gần nhau chỉ giải quyết độ trễ, không giải quyết ý nghĩa.

• CLI motherduck bản preview: login, chạy SQL, dựng Dives và Flights.
• Đầu ra chọn được bảng, JSON hoặc CSV để đưa vào script.
• Windows cài DuckDB CLI có hỗ trợ MotherDuck bằng một dòng lệnh.
• CREATE DATABASE ... FROM nhận file .db nằm trên cloud storage.
• Favorites: ghim Dives, Notebook, Flights, database lên đầu sidebar.

Điểm mình chú ý nhất không phải Favorites mà là CREATE DATABASE từ file .db trên S3. Nó biến một file DuckDB thành đơn vị phân phối dữ liệu: build xong ở máy hoặc trong CI, đẩy lên object storage, ai cần thì trỏ tới là dùng. Với đội phân tích nhỏ, đây là cách chia sẻ dataset đã xử lý mà không cần dựng warehouse, không cần cấp tài khoản, không cần bàn về chi phí compute. Cộng thêm CLI xuất JSON, bạn có thể nhét truy vấn vào một job cron và đẩy kết quả sang chỗ khác chỉ bằng vài dòng shell. Đây đúng tinh thần mình hay nói: vấn đề không nằm ở công cụ mạnh cỡ nào, mà ở việc bạn thiết kế được workflow gọn tới đâu. Cảnh báo nhỏ: CLI đang ở bản preview, đừng đặt pipeline sản xuất quan trọng lên nó vội, dùng cho báo cáo nội bộ và tự động hoá phụ trước.

• Đối tác chiến lược Alation và PwC Canada, tập trung ngành tài chính.
• Điểm khởi đầu: hướng dẫn OSFI E-21 về khả năng chống chịu vận hành.
• Gói gồm chính sách mẫu, định nghĩa critical data element, template curation.
• Mục tiêu: lineage, quyền sở hữu, kiểm soát và bằng chứng tuân thủ.
• Hướng tới quản lý rủi ro dữ liệu đáng tin cậy hơn cho định chế tài chính.

Mô hình này đáng học hơn là đáng mua. Điều Alation và PwC làm không phải bán thêm tính năng, mà đóng gói tri thức tuân thủ thành template có sẵn: quy định nói gì, dữ liệu nào là trọng yếu, ai chịu trách nhiệm, bằng chứng nộp ra sao. Đó chính là phần khiến dự án governance ở Việt Nam hay chết yểu: mua catalog xong không ai biết điền gì vào, cuối cùng thành một danh bạ bảng chết. Nếu đội bạn đang triển khai catalog, hãy làm ngược lại thứ tự quen thuộc: bắt đầu từ vài chục critical data element gắn với báo cáo bắt buộc hoặc chỉ số điều hành, gán chủ sở hữu thật, rồi mới mở rộng. Đừng cố quét hết mấy nghìn bảng ngay từ đầu. Một catalog phủ 5% dữ liệu nhưng đúng phần quan trọng thì hữu ích hơn nhiều một catalog phủ 100% mà không ai tin.

• Chuyển pipeline production từ Airbyte Core tự host sang Airbyte Cloud.
• Không phải tạo lại connection, không đứt nhịp đồng bộ.
• Dữ liệu giữ nguyên tại warehouse đích hiện có.
• State đồng bộ incremental được chuyển sang Cloud.
• Mục tiêu: bỏ gánh nặng tự vận hành hạ tầng tích hợp.

Ai từng di trú công cụ ELT đều biết state incremental là chỗ đau. Mất cursor là hệ thống chạy lại từ đầu, kéo theo hoá đơn compute và nguy cơ trùng lặp dữ liệu. Airbyte nhận gánh phần này là động thái thương mại thông minh, vì nó đúng lý do khiến người dùng ở lại bản tự host dù đã chán vận hành. Nhìn rộng hơn, đây là tín hiệu của giai đoạn thị trường mã nguồn mở đang siết đường phễu: bản tự host vẫn miễn phí, nhưng con đường rời khỏi nó được lát phẳng về phía bản trả tiền. Với doanh nghiệp Việt, lời khuyên là hãy tính đúng chi phí thật của việc tự host, gồm cả thời gian người trực khi connector gãy lúc nửa đêm, rồi so với giá Cloud theo lượng dữ liệu thật. Nhiều đội mình gặp tự host chỉ vì thấy nó miễn phí, trong khi mỗi tháng đốt vài ngày công để giữ cho nó sống.

• Bản SaaS cloud-native, không cần hạ tầng on-premises.
• Quản lý license tập trung cho toàn bộ chương trình automation.
• Luồng duyệt script trước khi đưa vào chạy.
• Lập lịch job phía server thay vì chạy rải rác trên máy người dùng.
• Audit trail đầy đủ và tự động cập nhật phiên bản.

Bài toán này quen thuộc đến mức buồn cười: một bạn chuyên viên viết macro để đỡ phải nhập tay vào SAP, macro chạy tốt, cả phòng dùng theo, hai năm sau bạn đó nghỉ việc và không ai biết cái file kia đang cập nhật những bảng nào. Đưa lập lịch về phía server và bắt script qua luồng duyệt là cách chữa đúng gốc, không phải cấm automation. Đây cũng là bài học chung khi doanh nghiệp bắt đầu thả AI agent vào quy trình: nếu không có nơi ghi lại ai duyệt, chạy lúc nào, chạm vào gì, thì càng tự động hoá càng khó kiểm toán. Với các công ty Việt Nam đang chạy SAP hoặc ERP tương đương, mình khuyên làm sớm một việc rẻ tiền trước khi mua bất cứ nền tảng nào: kiểm kê xem hiện có bao nhiêu script tự phát đang chạm vào hệ thống lõi. Con số thường lớn hơn dự đoán.

• Thu thập thêm nguồn LeapXpert và LSEG Messenger.
• Đối soát end-to-end phát hiện bản ghi thiếu hoặc về trễ.
• Legal hold hiển thị trạng thái rõ ràng hơn.
• eDiscovery thêm tệp đính kèm và dịch inline khi review.
• Báo cáo hoạt động reviewer, hot word và phân vai.

Bỏ qua lớp từ ngữ compliance thì đây thuần tuý là data engineering: có nguồn, có pipeline thu thập, và có bài toán chứng minh không mất bản ghi nào trên đường đi. Cơ chế đối soát end-to-end chính là thứ nhiều pipeline dữ liệu ở Việt Nam thiếu, khi người ta chỉ đếm số dòng đích mà không đối chiếu với số dòng nguồn theo từng cửa sổ thời gian. Kết quả là mất dữ liệu âm thầm, tới lúc kiểm toán hoặc điều tra sự cố mới lộ. Nếu bạn đang xây pipeline nào chạm tới giao dịch tài chính hay hồ sơ khách hàng, hãy dựng một job đối soát riêng, chạy độc lập với pipeline chính, so số nguồn với số đích theo ngày. Nó tốn vài ngày công nhưng là thứ duy nhất cho phép bạn nói câu dữ liệu của tôi đầy đủ mà không phải bắt chéo ngón tay.

• Atlas Managed MCP Server được host trọn gói, không cần hạ tầng thêm.
• Hỗ trợ Claude Code, Codex, Grok Build và Devin.
• Dùng lại credential và cơ chế kiểm soát truy cập sẵn có của Atlas.
• Hơn 30.000 lượt cài MCP server mỗi tuần.
• Kèm Automated Embeddings và Atlas Embedding, Reranking API.

Điểm mấu chốt không phải MCP, mà là chữ live. Suốt hai năm qua, phần lớn kiến trúc RAG doanh nghiệp làm việc trên bản sao dữ liệu: index đêm qua, embedding tuần trước, và agent trả lời bằng thứ đã cũ. Cho agent đọc trạng thái vận hành thật là bước nhảy về độ hữu ích, đồng thời là bước nhảy về rủi ro. Mình đánh giá cao việc MongoDB dùng lại đúng credential và phân quyền Atlas thay vì đẻ ra lớp quyền song song, vì đây chính là chỗ nhiều đội tự dựng MCP nội bộ làm sai: cấp cho agent một tài khoản quyền cao rồi tự nhủ sẽ siết sau. Với doanh nghiệp Việt, khuyến nghị của mình rất cụ thể: trước khi mở MCP cho bất kỳ agent nào, hãy tạo role riêng chỉ đọc, giới hạn theo collection, bật audit log, và thử ở môi trường staging đủ lâu. Đừng để tiện lợi đi trước phân quyền, vì sửa sau tốn gấp nhiều lần làm đúng từ đầu.

• 53% tổ chức chật vật đưa bối cảnh nghiệp vụ vào hệ thống AI dựa vào.
• 77% lãnh đạo IT coi bối cảnh này là điều kiện để AI trả lời đúng.
• Bối cảnh gồm quy tắc, định nghĩa và tri thức vận hành.
• Đầu tư AI vẫn tăng dù khoảng cách vận hành chưa được lấp.
• Hệ quả: nhiều sáng kiến AI không thành năng lực kinh doanh ổn định.

Khoảng cách giữa 77% và 53% là bức tranh nghề nghiệp của cả ngành: gần như ai cũng biết bối cảnh nghiệp vụ là thiết yếu, nhưng hơn nửa không biến được nó thành thứ hệ thống đọc hiểu. Trong thực tế mình thấy ở doanh nghiệp Việt, tri thức đó nằm trong đầu vài người kỳ cựu, trong file Excel không ai dám sửa, và trong những câu giải thích miệng ở cuộc họp. Agent không đọc được mấy chỗ đó. Việc cần làm không hào nhoáng nhưng hiệu quả: viết ra định nghĩa cho hai ba chục chỉ số quan trọng nhất, ghi rõ công thức, phạm vi, ngoại lệ và ai là chủ, đưa vào semantic layer hoặc metric store để cả người lẫn máy dùng chung một nguồn. Làm được phần đó, chất lượng câu trả lời của mọi công cụ text-to-SQL nhảy lên thấy rõ. Bỏ qua phần đó thì đổi mô hình mạnh cỡ nào cũng không cứu nổi.

• 1.500 người tham gia: enterprise architect, cloud lead, data architect.
• 77% đang dùng AI, nhưng 95% từng hoãn hoặc huỷ sáng kiến AI.
• 72% nói kiến trúc dữ liệu hiện tại phải thay đổi đáng kể.
• 75% đã đổi cách làm storage và kiến trúc vì AI.
• Khảo sát 9 thị trường, thực hiện từ 05/06 đến 22/06/2026.

Con số 95% dễ bị đọc thành lời than, nhưng mình thấy nó là bản đồ chỉ chỗ nên đầu tư. Điểm nghẽn không nằm ở mô hình, mà ở ba thứ rất cụ thể: không biết dữ liệu từ đâu ra, không biết ai được xem, và không chứng minh được với bộ phận tuân thủ. Cả ba đều là bài toán quản trị, giải bằng công việc kỷ luật chứ không bằng ngân sách lớn. Mình vừa học và thi chứng chỉ Databricks, có làm thực hành RAG trên nền lakehouse với Delta, Unity Catalog và vector search, và cảm nhận rõ một điều: khi lớp catalog đã biết ai được đọc bảng nào, việc mở cho agent truy cập bớt đáng sợ hẳn. Ngược lại, cắm RAG thẳng vào một kho không ai quản là cách nhanh nhất để rò rỉ dữ liệu nhạy cảm mà không ai phát hiện. Khuyến nghị: trước khi ký hợp đồng AI tiếp theo, hãy trả lời được ba câu hỏi trên cho đúng mười bảng quan trọng nhất. Làm được thì tốc độ triển khai AI sau đó nhanh hơn nhiều lần.

• Lỗi liên quan tới cơ chế reset write-ahead log của SQLite.
• Tồn tại khoảng 16 năm trước khi được truy ra.
• Hơn 1.200 điểm và hơn 230 bình luận trên Hacker News.
• Ngày lên trang nhất: 12/08/2026.
• Chủ đề hạ tầng dữ liệu được bàn nhiều nhất tuần.

Giá trị của bài này với người làm dữ liệu không nằm ở bản thân cái bug, mà ở phương pháp. Truy một lỗi tầng storage đòi hỏi kỷ luật: tái hiện được, thu hẹp phạm vi, đọc mã nguồn thay vì đoán, và chấp nhận rằng thứ mình tin tưởng nhất có thể sai. Đây đúng là kỹ năng mà nghề data engineering đang cần hơn bao giờ hết, khi AI viết code ngày càng nhiều còn người thì đọc ngày càng ít. Nhân tiện nói thẳng một quan điểm: nếu bạn để agent sinh pipeline mà không đủ sức đọc hiểu phần nó sinh ra, thì mỗi lỗi im lặng như thế này sẽ nằm trong hệ thống của bạn nhiều năm. SQLite còn có cộng đồng lớn để phát hiện sau 16 năm, còn pipeline nội bộ của bạn thì chỉ có bạn. Đọc bài này như một bài tập rèn nghề, không phải như tin tức.

• Luận điểm: nhóm kỹ sư tầm trung bị ép mạnh nhất bởi AI.
• Việc lặp lại dễ tự động hoá, việc khó vẫn cần người rất giỏi.
• Gần 1.000 điểm, hơn 900 bình luận trên Hacker News.
• Ngày lên trang nhất: 12/08/2026.
• Chủ đề nghề nghiệp được tranh luận sôi nhất tuần.

Mình không đồng ý hoàn toàn với bài viết, nhưng phần chẩn đoán thì đúng với ngành dữ liệu. Những việc từng nuôi sống rất nhiều data engineer tầm trung, viết connector, dựng job transform lặp lại, sửa schema thay đổi, đang bị công cụ và agent nuốt dần. Thứ không bị nuốt là phần khó viết thành đặc tả: hiểu bài toán kinh doanh, quyết định mô hình dữ liệu, đặt ra định nghĩa chỉ số và bảo vệ nó trước áp lực từ các phòng ban. Nhìn ngược lại, tin Alteryx trong tuần này nói rằng 53% tổ chức bế tắc đúng ở chỗ đó, tức là nhu cầu cho người làm được phần khó đang tăng chứ không giảm. Lời khuyên thẳng cho bạn nào đang ở giữa: đừng cố nhanh hơn agent ở việc viết SQL. Hãy chuyển trọng tâm sang mô hình hoá, semantic layer, chất lượng dữ liệu và làm việc với người dùng nghiệp vụ. Đó là phần AI khuếch đại bạn, không thay bạn.

• Netflix phần 3: truy vấn graph phân tán qua gRPC, lọc sớm, kiểm soát đồng thời.
• Netflix: tiered storage cho chuỗi thời gian quy mô petabyte.
• Mohamed El Zein: 13 tối ưu đẩy Flink vượt 300 triệu bản ghi mỗi phút.
• Flipkart: dùng LLM gán nhãn độ liên quan cho kết quả tìm kiếm.
• OLX: dùng Propensity Score Matching thay vì tin vào tương quan.

Nếu tuần này chỉ đọc một thứ thì mình chọn số này. Hai bài của Netflix cho thấy cách một tổ chức lớn giải bài toán chi phí: không phải mua thêm dung lượng, mà phân tầng lưu trữ theo tần suất truy cập, và tối ưu truy vấn bằng cách lọc sớm trước khi kéo dữ liệu về. Bài Flink của Mohamed El Zein thì đúng kiểu tài liệu quý, gồm cả những sửa lỗi không có trong tài liệu chính thức. Bài của OLX lại là lời nhắc cho dân analytics: tương quan không phải nhân quả, và Propensity Score Matching là công cụ rẻ để đo tác động thật của một thay đổi sản phẩm. Ở Việt Nam, phần lớn báo cáo tác động vẫn dựa trên so sánh trước sau, tức là gần như luôn thổi phồng kết quả. Nếu đội bạn đang phải chứng minh giá trị của một tính năng hay một chiến dịch, đọc bài OLX trước khi trình số liệu cho lãnh đạo.

• Doanh thu chạy vượt 7 tỷ USD một năm, tăng hơn 80% so cùng kỳ trong quý 2.
• Vòng gọi vốn chiến lược 5 tỷ USD ở định giá 190 tỷ USD.
• Coatue dẫn dắt, cùng Blackstone, MGX, T. Rowe Price, Sixth Street Growth.
• TechCrunch: công ty định gọi 1 tỷ, nhà đầu tư muốn rót tới 15 tỷ.
• Tiền đầu tư vào Lakebase, Genie và Unity AI Gateway.

Định giá 190 tỷ là con số gây choáng, nhưng thứ đáng phân tích là ba sản phẩm được nêu tên. Lakebase là Postgres serverless dựng cho agent, Genie là trợ lý biến dữ liệu kinh doanh thành câu trả lời và hành động, Unity AI Gateway là cổng quản trị và kiểm soát chi phí cho nhiều mô hình. Ghép lại, đó là bản thiết kế của một lakehouse mà người dùng chính không phải con người. Chi tiết công ty định gọi 1 tỷ còn nhà đầu tư muốn 15 tỷ cũng nói lên tâm lý thị trường hiện tại: tiền đang tìm chỗ trú trong hạ tầng dữ liệu cho AI, chứ không phải trong ứng dụng AI. Mình vừa học và thi chứng chỉ Databricks, làm thực hành RAG trên nền của họ, và phải công nhận điểm mạnh nằm ở chỗ gộp data với AI về một nền quản trị thống nhất, chứ không phải ở mô hình. Với doanh nghiệp Việt, khuyến nghị thực dụng: đừng chạy theo định giá, hãy nhìn hướng sản phẩm. Nếu nền tảng dữ liệu của bạn sang năm phải phục vụ agent, thì việc cần làm ngay là chuẩn hoá catalog và phân quyền, không phải đổi nhà cung cấp.

• Series C trị giá 63 triệu USD.
• Đồng dẫn dắt: Cathay Innovation và Dell Technologies Capital.
• Sản phẩm: Context Graph of Work, bản ghi luôn cập nhật về quy trình.
• Quan sát công việc xuyên vai trò, hệ thống và ứng dụng.
• Mục tiêu: cấp bối cảnh vận hành thật cho AI agent.

Đây là mảnh ghép thứ hai của cùng một câu chuyện trong tuần. Alteryx nói 53% tổ chức bế tắc khi đưa bối cảnh nghiệp vụ vào hệ thống AI, còn Skan AI vừa gọi được 63 triệu để bán đúng thứ đó. Cách tiếp cận của họ là quan sát công việc thực tế diễn ra thế nào, gồm cả ngoại lệ và đường vòng mà quy trình chính thức không ghi. Ý tưởng hay, nhưng cần nói rõ mặt khác: quan sát công việc của nhân viên xuyên nhiều hệ thống là chuyện nhạy cảm về quyền riêng tư và quan hệ lao động, ở châu Âu còn vướng quy định. Với doanh nghiệp Việt, mình nghĩ bài học rút ra không phải là đi mua công cụ giám sát, mà là nhận ra rằng metadata quy trình cũng là tài sản dữ liệu. Nếu quy trình phê duyệt, ngoại lệ và lý do từ chối của bạn chỉ tồn tại trong email và cuộc gọi, thì không agent nào học được cách công ty bạn thật sự vận hành.

• Giá mục tiêu nâng từ 295 USD lên 400 USD.
• Lý do: đà tiêu thụ mạnh hơn và tốc độ áp dụng CoCo tăng nhanh.
• Cổ phiếu chạy tốt từ cuối tháng 5.
• Hợp tác nhiều năm trị giá 6 tỷ USD với AWS.
• Snowflake dự kiến báo cáo kết quả ngày 02/09/2026.

Với người làm kỹ thuật, tin chứng khoán thường bị bỏ qua, nhưng logic phía sau đáng đọc. Phân tích viên đang lập luận rằng một agent lập trình làm tăng lượng compute tiêu thụ, vì càng nhiều người viết được truy vấn thì càng nhiều truy vấn chạy. Điều này đúng, và nó cũng là cảnh báo cho phía khách hàng: mô hình tính tiền theo mức dùng cộng với trợ lý AI khiến hoá đơn dễ phình mà không ai để ý. Mình đã thấy vài đội ở Việt Nam bị bất ngờ vì chi phí warehouse tăng gấp đôi sau khi mở cửa cho nhiều người tự query. Khuyến nghị thẳng: nếu bạn bật công cụ AI viết SQL cho người dùng nghiệp vụ, hãy đặt luôn hạn mức compute theo nhóm, bật cảnh báo chi phí hằng ngày, và đưa các truy vấn lặp lại thành view hoặc bảng đã tính sẵn. Tiện lợi cho người dùng phải đi kèm rào chắn cho ngân sách.

• Master of Science, học hoàn toàn online, khai giảng kỳ mùa thu 2026.
• Quy mô 30 tín chỉ, không yêu cầu luận văn.
• Nội dung liên ngành: quản trị công nghệ, tài chính và fintech.
• Có data analytics, AI và chiến lược kinh doanh.
• Nhấn mạnh quản trị công nghệ có trách nhiệm.

Tin này nhỏ nhưng nói đúng chỗ đau của đào tạo dữ liệu. Phần lớn khoá học ở Việt Nam vẫn dạy theo công cụ: học Power BI, học SQL, học Python, rồi kết thúc bằng một dashboard đẹp. Học viên ra khỏi lớp làm được biểu đồ nhưng lúng túng khi sếp hỏi con số này nghĩa là gì và nên làm gì tiếp. Chương trình kiểu này ghép analytics với tài chính, chiến lược và quản trị công nghệ có trách nhiệm, tức là dạy cả phần đọc bài toán chứ không chỉ phần thao tác. Trong công việc đào tạo của mình, đây cũng là hướng mình chọn: mỗi bài thực hành đều phải trả lời được quyết định nào sẽ thay đổi nhờ con số này. Dashboard đẹp không có nghĩa là đang ra quyết định tốt. Nếu bạn đang chọn khoá học để đi lên vai trò dẫn dắt dữ liệu, hãy ưu tiên chương trình bắt bạn làm việc với bài toán kinh doanh thật, chứ không phải chương trình nhiều công cụ nhất.