• ADAPTIVE refresh mode cho Dynamic Tables chính thức GA ngày 30/07/2026
• Engine tự chọn incremental hoặc full refresh theo từng lần chạy
• Trước đây refresh_mode phải cố định ngay lúc tạo bảng
• Cùng tuần Snowflake mở preview dashboard giám sát chất lượng dữ liệu

Ai từng vận hành Dynamic Tables đều biết cái bẫy: chọn INCREMENTAL rồi một hôm query đổi, engine âm thầm rơi về FULL và hoá đơn nhảy vọt mà không ai hay. ADAPTIVE gỡ đúng chỗ đó bằng cách để engine quyết theo từng lần refresh. Với team data Việt Nam đang dùng Snowflake, đây là loại thay đổi nên đón nhận ngay vì nó không đòi viết lại pipeline, chỉ đổi một thuộc tính. Nhưng đừng bật rồi quên: vẫn phải theo dõi refresh history để biết engine thực sự chọn gì, nếu không thì bạn chỉ chuyển sự mù mờ từ chỗ này sang chỗ khác. Kinh nghiệm của mình là mọi tính năng "tự động" đều cần một dashboard theo dõi đi kèm, bằng không nó biến thành hộp đen tốn tiền. Nhìn rộng hơn, đây là hướng chung của cả ngành trong 2026: chuyển quyết định tối ưu từ tay kỹ sư sang runtime, kỹ sư chỉ còn lo chỗ đặt ranh giới và ngân sách.

• Fabric Runtime 2.0 vào preview, kèm cơ chế release channel để chọn nhịp cập nhật
• Lakehouse Query Explorer và Materialized Lake Views analytics lên GA
• Materialized Lake Views thêm event-driven refresh (preview)
• Eventstream có connector Oracle CDC, hỗ trợ mTLS và CA tự cấp
• Data Warehouse thêm scalar UDF (preview) và lakehouse table health check GA

Bản tháng 7 này cho thấy Fabric đã qua giai đoạn chạy đua bề rộng và bắt đầu vá những chỗ đau thật của người vận hành. Release channel cho runtime là tính năng nhỏ nhưng quan trọng: trước đây Microsoft đẩy runtime mới là cả workspace ăn theo, giờ team có quyền chọn nhịp. Lakehouse Query Explorer lên GA nghĩa là hết cảnh phải mở notebook chỉ để xem thử vài dòng dữ liệu. Với doanh nghiệp Việt đã mua sẵn E5 và Power BI Premium, Fabric càng lúc càng khó bỏ qua về mặt chi phí biên. Nhưng khuyến nghị của mình vẫn không đổi: đừng chọn nền tảng theo danh sách tính năng, hãy chọn theo đội ngũ bạn có. Fabric mạnh khi tổ chức đã sống trong hệ Microsoft và có người rành Power BI; nếu đội bạn là dân Spark thuần và cần kiểm soát sâu, Databricks vẫn là chỗ ít vật lộn hơn. Điểm đáng theo dõi là Runtime 2.0 — nó sẽ quyết định Fabric có bắt kịp Spark 4.2 hay không.

• Polaris 1.7.0 RC0 huỷ vote: 44/269 jar staged thiếu META-INF/LICENSE và NOTICE
• Parquet duyệt mã hoá ALP cho số thực với 11 phiếu +1, thêm Parquet Java 1.18.0 RC1
• Iceberg Rust 0.10.1 RC1 chạy qua 1.839 test; Maximilian Michels thành committer mới
• Arrow ra ADBC 24, Arrow Rust 58.4.0, Arrow Go 18.7.0; DataFusion 54.1.0 RC1 pass
• Apache Ossie nhắm bản 0.3.0-incubating cuối tháng 8 hoặc đầu tháng 9

Chuyện Polaris gãy release vì thiếu file LICENSE nghe rất buồn cười cho tới khi bạn nhớ Polaris là catalog mà nhiều doanh nghiệp định đặt làm nguồn sự thật cho toàn bộ lakehouse. Một dự án ASF không ship được vì hồ sơ pháp lý chưa sạch là tín hiệu về độ trưởng thành vận hành, không phải về chất lượng code. Với ai đang cân nhắc Polaris cho production trong quý này, đây là lý do hợp lý để chờ thêm một nhịp. Phía Parquet, ALP là thứ đáng quan tâm hơn nhiều so với vẻ ngoài kỹ thuật của nó: nén số thực tốt hơn nghĩa là bảng cảm biến, bảng giá, bảng embedding đều nhỏ đi, mà chi phí lakehouse phần lớn nằm ở byte đọc từ object storage. Điểm cốt lõi phải nhớ tuần này là các format đang tự siết chuẩn để nhiều engine cùng ghi mà không đạp lên nhau. Còn Iceberg Rust với 1.839 test đi qua cho thấy nhánh không-JVM đã đủ nghiêm túc để tính vào kiến trúc, không còn là đồ chơi.

• Automatic upgrades mở rộng từ bảng mới sang bảng managed Unity Catalog đã có
• Hai tính năng đầu tiên được đẩy là row tracking và Checkpoint V2
• Databricks chỉ bật sau khi observation window xác nhận mọi client đều hỗ trợ
• Việc triển khai theo đợt, mỗi khách hàng nhận vào thời điểm khác nhau

Cơ chế observation window là phần thiết kế đáng khen: Databricks quan sát xem mọi client chạm vào bảng có hỗ trợ tính năng chưa rồi mới bật. Nhưng "mọi client" ở đây là những client mà Databricks nhìn thấy. Nếu tổ chức bạn có job Spark tự dựng ngoài workspace, connector cũ, hay một pipeline đọc file Delta trực tiếp qua thư viện phiên bản thấp, thì cửa sổ quan sát đó có lỗ hổng. Việc cần làm ngay là rà lại danh sách reader ngoài luồng và ghim phiên bản delta-spark, đồng thời theo dõi bảng Supported features để biết cái gì sắp tới. Điều tốt là row tracking mở đường cho CDF chính xác và merge nhanh hơn — thứ team data nào cũng muốn. Điều cần cẩn trọng là bạn không còn quyền chọn thời điểm. Theo mình, đây là ví dụ điển hình của xu hướng nền tảng đám mây chuyển rủi ro nâng cấp từ khách hàng sang chính họ, đổi lại khách hàng mất quyền kiểm soát lịch — chấp nhận được, miễn là bạn có giám sát.

• Đăng ký Python UDTF trong Unity Catalog chính thức GA ngày 28/07/2026
• Yêu cầu Databricks Runtime 18; gọi trong mệnh đề FROM của câu SQL
• Chạy trên serverless compute, classic compute standard access và SQL warehouse
• Cùng nhánh với Scala/Java UDF trong Unity Catalog đã GA giữa tháng 7

Ý nghĩa thật của UDTF trong Unity Catalog không nằm ở cú pháp mà ở chỗ nó biến đoạn code xử lý phức tạp thành một tài sản có chủ, có quyền, có audit. Trong mọi dự án BI mình từng làm, thứ giết chết khả năng bảo trì luôn là logic biến đổi nằm rải rác: một ít trong notebook, một ít trong view, một ít trong Power Query. UDTF cho phép kéo phần "sinh nhiều dòng từ một dòng" về đúng một chỗ mà analyst vẫn gọi được bằng SQL thuần. Khuyến nghị cụ thể: chuyển trước những hàm parse dữ liệu bán cấu trúc và hàm bung mảng, vì đó là chỗ code trùng lặp nhiều nhất. Đừng chuyển vội logic nghiệp vụ cốt lõi vào UDTF chỉ vì thấy hay — hàm càng nhiều nghiệp vụ càng khó test và càng khó tối ưu. Và nhớ rằng UDTF Python vẫn chậm hơn hàm native đáng kể, nên đừng đặt nó ở giữa đường dẫn nóng của dashboard.

• OpenAI connector vào Lakeflow Connect ở trạng thái Beta ngày 31/07/2026
• Nạp users, projects, API keys, usage, costs và audit logs từ OpenAI
• Xác thực bằng OpenAI Admin API key qua Organization Admin API
• Workspace admin bật/tắt tính năng từ trang Previews
• Cùng tuần Databricks mở web terminal cho serverless GPU compute (AI Runtime)

Đây là tin nhỏ nhưng nói lên rất nhiều về chỗ ngành đang đi. Sáu tháng trước, câu hỏi của lãnh đạo là "AI làm được gì". Bây giờ câu hỏi là "AI đang tiêu bao nhiêu, ai tiêu, tiêu vào việc gì". Muốn trả lời câu thứ hai thì dữ liệu vận hành của nhà cung cấp mô hình phải nằm trong warehouse chứ không phải trong một trang billing riêng. Với doanh nghiệp Việt đang dùng OpenAI theo tổ chức, việc đầu tiên nên làm là dựng một bảng chi phí theo project và theo người dùng, rồi gắn vào dashboard tài chính sẵn có — đó là nửa ngày công và trả lời được câu hỏi mà giám đốc nào cũng hỏi. Điều không nên làm là chờ nhà cung cấp làm sẵn báo cáo cho bạn; báo cáo của họ luôn theo góc nhìn của họ. Nói rộng hơn, mình nghĩ trong 12 tháng tới FinOps cho AI sẽ thành một mảng nghề riêng, và nó sẽ do team data gánh chứ không phải team IT.

• Community Edition nhận đủ tính năng vốn thuộc bản Enterprise
• Có conversational analytics với LLM do người dùng tự cắm vào
• Bao gồm SSO, row-level security, multi-tenancy, white labeling, report bursting
• Doanh thu chuyển sang bán hỗ trợ, triển khai và dịch vụ thay vì bán tính năng

Với thị trường Việt Nam thì tin này thực tế hơn nhiều tin lớn khác trong tuần. Rất nhiều doanh nghiệp vừa ở đây không cần một lakehouse; họ cần một cổng báo cáo có phân quyền theo phòng ban, nhúng được vào app nội bộ, và không phải trả license theo đầu người. Helical Insight vừa đưa đúng gói đó về mức miễn phí. Nhưng nói thẳng: bỏ hàng rào tính năng không có nghĩa là bạn tiết kiệm được. Chi phí thật của BI nằm ở mô hình dữ liệu, ở người biết đặt câu hỏi, và ở việc duy trì semantic layer sạch — chứ không ở giá license. Mình đã thấy nhiều đội chọn công cụ miễn phí rồi tốn gấp ba lần tiền lương để tự vá những thứ mà bản thương mại làm sẵn. Khuyến nghị: hợp lý cho embedded analytics và cho hệ thống multi-tenant tự dựng; không hợp lý nếu bạn đang định thay Power BI trong một tổ chức đã quen Microsoft, vì phần đắt nhất là thay đổi thói quen người dùng chứ không phải phần mềm.

• Free Tier áp dụng toàn cầu cho triển khai tối đa 5.000 tag
• Không phải bản dùng thử giới hạn thời gian, không phải bản community rút gọn
• Đủ hiệu năng và tính năng, chạy được production kể cả cấu hình high availability
• Gồm lưu trữ time-series, thu thập dữ liệu công nghiệp, asset modeling, phân tích sự kiện

Chiến lược ở đây rất rõ và rất cũ: cho miễn phí ở tầng dưới để giết đối thủ legacy, rồi thu tiền khi khách vượt ngưỡng. 5.000 tag nghe nhiều nhưng một dây chuyền sản xuất trung bình có thể chạm ngưỡng đó trong vài năm mở rộng, nên hãy tính đường nâng cấp ngay từ đầu chứ đừng để bị kẹt. Điểm mình đánh giá cao là TDengine gộp cả asset modeling và phân tích sự kiện vào cùng một nền, thay vì bắt khách ghép ba công cụ. Trong các dự án OT/IT mình từng chạm, chỗ tốn công nhất luôn là ánh xạ từ tag thô sang mô hình thiết bị có nghĩa; ai giải được chỗ đó thì thắng. Lời khuyên thực tế cho doanh nghiệp sản xuất Việt: thử ở một dây chuyền, đo xem đội bảo trì có thực sự đọc được dashboard không, rồi mới nhân rộng. Công nghệ ở tầng này không phải rào cản — rào cản là người vận hành có đổi thói quen ghi chép hay không.

• Data quality monitoring dashboard vào public preview ngày 29/07/2026
• Giới hạn ở tài khoản Enterprise Edition trở lên
• Cùng ngày Snowflake thêm hàm quản lý nhiều hostname cho PrivateLink endpoint
• Nằm trong nhánh data metric function đã có sẵn của nền tảng

Đây là một nước cờ quen thuộc của các nền tảng dữ liệu lớn: nuốt dần từng lớp công cụ vệ tinh. Nhưng cần công bằng — dashboard sẵn có của nền tảng thường chỉ giải quyết được lớp kiểm tra kỹ thuật như null, duplicate, freshness. Phần khó của chất lượng dữ liệu là quy tắc nghiệp vụ: doanh thu ghi nhận có khớp với hợp đồng không, mã khách có tồn tại trong CRM không. Chỗ đó vẫn cần người hiểu nghiệp vụ ngồi định nghĩa. Lời khuyên của mình cho team data đang cân nhắc mua công cụ data observability riêng: hãy bật cái sẵn có trước, chạy ba tháng, xem còn thiếu gì rồi mới quyết chi tiền. Rất nhiều đội mua trước rồi mới phát hiện 80% cảnh báo họ cần đã nằm sẵn trong nền tảng. Và nhớ nguyên tắc gốc: cảnh báo mà không ai chịu trách nhiệm xử lý thì chỉ là tiếng ồn đắt tiền.

• Cortex AI Gateway quản trị cả agent first-party lẫn agent bên thứ ba
• Kiểm soát tập trung ai truy cập dữ liệu nào, gọi mô hình nào, tiêu bao nhiêu token
• Hàng rào bảo mật chống prompt injection và truy cập trái phép
• Tích hợp 1Password, Aembit, Linx Security, Okta XAA, SailPoint, Saviynt
• Mục tiêu công bố: chặn tình trạng chi phí AI vượt kiểm soát

Cái mới thật sự ở đây không phải công nghệ mà là sự thừa nhận: Snowflake chấp nhận rằng agent do đội kỹ thuật tự cắm vào sẽ vào kho dữ liệu bất kể chính sách nói gì, nên tốt hơn là dựng cổng thay vì dựng tường. Đó là cách nghĩ đúng, giống hệt bài học từ thời BYOD điện thoại cá nhân. Bản chất Cortex AI Gateway là một identity-aware proxy cho truy vấn AI: mỗi lượt gọi gắn với một danh tính, một hạn mức, một dấu vết audit. Ai hưởng lợi? Doanh nghiệp có nhiều đội tự triển khai AI và đang không biết ai đang đọc bảng nào. Ai chưa cần? Team nhỏ chạy một agent duy nhất — với họ đây là lớp phức tạp thừa. Điều phải nhớ: quản trị agent là bài toán identity, không phải bài toán AI; danh sách sáu đối tác đều là hãng identity chứ không phải hãng mô hình, và đó là chi tiết nói lên tất cả. Nên làm gì ngay tuần này, kể cả khi bạn không dùng Snowflake: liệt kê xem hiện có bao nhiêu agent, chạy bằng credential của ai, và đọc được những bảng nào. Mình cá là con số sẽ làm bạn giật mình.

• Skill chỉ đọc, không ghi — giới hạn ở chẩn đoán, không tự sửa hệ thống
• Xử lý notebook lỗi, Spark job hỏng, Livy session treo, OOM, shuffle, skew
• Quy trình tự động: triage job, đào log, đọc Spark Advisor, đề xuất khắc phục
• Chạy từ GitHub Copilot CLI, Claude Code, VS Code, Cursor và công cụ tương thích
• Công bố kèm bản cập nhật Fabric tháng 7/2026

Chi tiết quan trọng nhất trong tin này là hai chữ read-only. Microsoft chọn để AI chẩn đoán chứ không để AI tự vá, và mình cho rằng đó là ranh giới đúng ở thời điểm hiện tại. Debug Spark là việc đọc hiểu — đọc log, đọc plan, đọc metric — chứ không phải việc sáng tạo, nên nó hợp với LLM một cách tự nhiên. Giá trị thực tế: một junior engineer với skill này có thể xử lý được lớp sự cố mà trước đây phải chờ người senior. Đó là đòn bẩy năng lực thật, không phải marketing. Nhưng đừng nhầm nó với việc bạn hết cần hiểu Spark; khi AI nói "job bị skew ở khoá khách hàng", bạn vẫn phải biết chọn giữa salting, broadcast join hay đổi mô hình dữ liệu. Đúng như mình vẫn nói: AI không thay người giỏi, nó khuếch đại người biết đặt câu hỏi rõ ràng. Ai đang dùng Fabric nên cài thử ngay trong tuần này, chi phí gần như bằng không.

• AI code suggestions trong Workspaces chuyển sang GA ngày 28/07/2026
• Cùng ngày, bản CoCo Desktop 1.20.2 vá lỗi crash khi cập nhật trên Windows
• CoCo Desktop thêm chia sẻ skill và plugin bằng một cú nhấp
• Nằm trong nhóm cập nhật AI tháng 7 của Snowflake cùng Cortex AI Gateway

Việc mọi nền tảng dữ liệu đều nhét trợ lý code vào editor đã trở thành mặc định của năm 2026 — Databricks có Genie Code, Fabric có Copilot, giờ Snowflake đưa Workspaces lên GA. Điều đáng bàn không phải ai có, mà là chất lượng ngữ cảnh. Trợ lý nằm trong nền tảng thấy được schema, thấy được query history, nên gợi ý sát hơn hẳn trợ lý ngoài. Kinh nghiệm thực tế khi mình hướng dẫn học viên: trợ lý code giúp nhiều nhất ở khâu viết nháp và khâu chuyển dialect SQL, giúp ít nhất ở khâu tối ưu — vì tối ưu cần hiểu phân phối dữ liệu chứ không chỉ hiểu cú pháp. Và có một rủi ro ít ai nói: người mới học dễ chấp nhận câu SQL chạy được nhưng sai nghiệp vụ. Vì vậy quy tắc mình đặt ra cho đội là mọi câu truy vấn do AI viết đều phải qua một bước đối chiếu số với nguồn đã tin cậy trước khi lên báo cáo.

• Snowflake đưa SHOW CORTEX BASE MODELS lên GA để liệt kê mô hình nền có sẵn
• dbt Projects trên Snowflake nhận biến môi trường SQL
• Một lệnh ALTER có thể refresh nhiều Dynamic Table cùng lúc
• Apache NiFi phát hành bản 2.10.0
• Hai hệ giám sát chất lượng không khí IoT dựng trọn bằng Cortex Code, ingest qua Snowpipe Streaming V2

Chi tiết mình chú ý nhất trong số này là AI-BOM scanner của Cisco. Software bill of materials đã thành chuẩn trong bảo mật phần mềm; AI-BOM là bước tiếp theo — liệt kê mô hình nào, trọng số nào, dữ liệu huấn luyện nào đang nằm trong hệ thống của bạn. Với doanh nghiệp Việt sắp phải trả lời câu hỏi tuân thủ về AI, đây là thứ nên tìm hiểu sớm thay vì đợi kiểm toán hỏi. Chi tiết thứ hai đáng học là hai hệ IoT chất lượng không khí được dựng trọn gói bằng công cụ code hỗ trợ AI: từ ingest streaming, semantic view, dashboard tới cảnh báo Slack. Nó chứng minh một điều mình hay nói với học viên — rào cản dựng hệ thống dữ liệu end-to-end đã hạ xuống rất thấp, thứ còn thiếu là người biết thiết kế luồng và đặt câu hỏi đúng. Còn NiFi 2.10.0 thì nhắc rằng công cụ tưởng đã cũ vẫn sống khỏe ở mảng thu thập dữ liệu biên.

• Bài đạt 123 điểm và 39 bình luận trên Hacker News ngày 31/07/2026
• Dùng Apache DataFusion làm engine thực thi thay cho cụm phân tán
• Xử lý đồ thị quy mô tỷ phần tử trong giới hạn 10GB RAM
• Nối tiếp làn sóng single-node analytics cùng hướng với DuckDB

Đây là dạng bài mình thích đọc nhất vì nó tấn công vào thói quen chứ không vào công cụ. Trong mười dự án dựng cụm Spark mình từng gặp, có tới sáu bảy dự án khối lượng dữ liệu thật chỉ vài chục GB — hoàn toàn chạy được trên một máy. Cụm được dựng vì thói quen và vì nghe "big data", không vì số liệu. DataFusion và DuckDB đang làm cái việc rất lành mạnh là buộc người ta phải chứng minh mình cần phân tán. Khuyến nghị rõ ràng: trước khi xin ngân sách cụm, hãy đo dung lượng thật sau khi nén Parquet và thử một vòng trên máy đơn. Nếu chạy được thì mọi thứ phía sau — vận hành, gỡ lỗi, chi phí — đều nhẹ đi một bậc. Ngược lại, đừng cực đoan: khi dữ liệu thật sự vượt bộ nhớ hoặc cần chạy song song nhiều job nặng thì phân tán vẫn là câu trả lời. Vấn đề chưa bao giờ là công cụ, mà là ta có chịu đo trước khi chọn hay không.

• Bài đạt 126 điểm và 33 bình luận trên Hacker News ngày 30/07/2026
• Phân tích điểm nghẽn thường gặp khi dùng bảng Postgres làm hàng đợi
• Thuộc nhánh tranh luận "just use Postgres" đang lan rộng trong cộng đồng
• Liên quan trực tiếp tới thiết kế orchestration cho pipeline dữ liệu

Mình đứng về phía "dùng Postgres trước" trong hầu hết trường hợp, nhưng có điều kiện. Một bảng job trong Postgres cho bạn transaction, cho bạn quan sát bằng SQL, cho bạn khôi phục dễ — ba thứ mà Kafka bắt bạn đánh đổi. Với khối lượng vài nghìn tác vụ mỗi phút, đó là lựa chọn đúng và tiết kiệm cả năm công vận hành. Vấn đề bắt đầu ở chỗ khoá: nếu bạn không dùng SKIP LOCKED và không thiết kế index cho trạng thái, hàng đợi sẽ tự bóp cổ mình khi số worker tăng. Bài viết này đáng đọc chính vì nó chỉ đúng những chỗ đó. Khuyến nghị cho team data Việt: đừng dựng Kafka chỉ để chạy vài job ETL theo lịch — chi phí vận hành lớn hơn lợi ích rất nhiều. Chỉ chuyển sang hệ chuyên dụng khi bạn có bằng chứng đo đạc về throughput hoặc thật sự cần replay dòng sự kiện. Nguyên tắc chung mình vẫn giữ: chọn thứ đơn giản nhất mà vẫn giải được bài toán, rồi nâng cấp khi có số liệu, không nâng cấp vì lo xa.

• Netflix chia sẻ kiến trúc serving LLM nội bộ, nhấn mạnh độ tin cậy khi phục vụ
• Airbnb nén bảy năm hành trình khách thành embedding cập nhật hằng ngày
• JioHotstar mổ xẻ đường đi của một ad request trong hệ real-time
• Bài phân tích MVCC và transaction trong RocksDB của Artem Krylysov
• Housing bàn vì sao phần lớn sáng kiến single source of truth thất bại

Bài đáng đọc nhất trong số này, theo mình, là bài về vì sao sáng kiến single source of truth thường thất bại. Đây là câu chuyện mình gặp ở gần như mọi dự án BI cho doanh nghiệp Việt: ai cũng đồng ý cần một nguồn số liệu duy nhất, nhưng không ai chịu bỏ bảng Excel của phòng mình. Nguyên nhân gốc không phải công nghệ mà là quyền lực dữ liệu và quy trình chứng nhận chỉ số. Cách làm hiệu quả mình đã thấy là chọn ra năm tới bảy chỉ số quan trọng nhất, chứng nhận thật kỹ, gắn tên người chịu trách nhiệm, rồi mới mở rộng — thay vì cố hợp nhất mọi thứ ngay từ đầu. Còn bài Airbnb thì là bài học về context engineering thuần túy: nén lịch sử dài thành đặc trưng cô đọng thay vì nhồi hết vào mô hình. Cùng một nguyên lý áp cho RAG doanh nghiệp — ngữ cảnh tốt thắng ngữ cảnh nhiều.

• Series C 100 triệu USD do One Peak dẫn dắt, công bố ngày 29/07/2026
• Morgan Stanley Expansion Capital tham gia cùng Zeev, Angular, Heavybit, Jibe
• Tổng vốn huy động đạt 160 triệu USD
• Một năm qua doanh thu định kỳ tăng gấp ba, nhân sự toàn cầu tăng gấp đôi
• Nền tảng dựa trên eBPF và OpenTelemetry, kiến trúc bring-your-own-cloud

Luận điểm đầu tư ở đây rất đáng suy nghĩ với dân data: observability về bản chất là một bài toán dữ liệu quy mô lớn, và mô hình kinh doanh của nó vỡ khi khối lượng telemetry tăng theo cấp số nhân vì AI. Khi mỗi lượt gọi agent sinh ra trace, log, metric, hoá đơn Datadog kiểu cũ trở nên vô lý. groundcover chọn cách để dữ liệu ở lại cloud của khách và chỉ bán phần điều khiển — mô hình này vừa rẻ hơn vừa hợp với yêu cầu chủ quyền dữ liệu. Với doanh nghiệp Việt trong ngành tài chính hay y tế, chỗ "dữ liệu không rời hạ tầng của mình" là điểm bán hàng mạnh hơn cả giá. Nhưng cần tỉnh táo: BYOC đẩy phần vận hành hạ tầng lưu trữ về phía khách hàng, nên nếu đội bạn mỏng thì cái rẻ trên hoá đơn có thể đắt trên nhân sự. Điều mình rút ra: lớp telemetry đang trở thành một kho dữ liệu thứ hai của doanh nghiệp, và nó nên được thiết kế bởi người làm data chứ không chỉ bởi team hạ tầng.

• Series B 40 triệu USD do Insight Partners dẫn dắt, công bố ngày 30/07/2026
• Forgepoint, GTM Capital, S3 Ventures tham gia; tổng vốn đạt 59 triệu USD
• Nền tảng xử lý telemetry từ hơn 600 nguồn, trung lập về dữ liệu và mô hình
• Chỉ chuyển tiếp dữ liệu mỗi đích cần, kéo thêm ngữ cảnh theo yêu cầu
• Trụ sở tại Dallas, phục vụ khách hàng Fortune 500; sẽ demo tại Black Hat USA 2026

Cùng tuần với groundcover, DataBahn là mảnh ghép thứ hai của cùng một luận điểm: chỗ nghẽn của AI doanh nghiệp không nằm ở mô hình mà nằm ở đường ống dữ liệu vận hành. Khái niệm "control plane" mượn từ mạng máy tính và mượn rất đúng: tách mặt phẳng điều khiển khỏi mặt phẳng dữ liệu, để bạn đổi đích đến, đổi mô hình, đổi chính sách mà không phải viết lại pipeline. Đây là kiến trúc mà mình nghĩ team data ở doanh nghiệp lớn nên học ngay cả khi không mua sản phẩm nào: đặt một lớp định tuyến giữa nguồn và đích, đừng nối cứng. Cái giá phải trả là thêm một thành phần phải vận hành và một nhà cung cấp nữa để phụ thuộc. Với doanh nghiệp Việt cỡ vừa, mình thấy chưa cần mua — nhưng rất nên áp dụng nguyên tắc lọc-tại-nguồn, vì phần lớn hoá đơn SIEM và log ở đây đến từ dữ liệu không ai từng đọc. Cắt được nửa lượng log vô dụng thường là khoản tiết kiệm lớn nhất mà một kỹ sư dữ liệu có thể mang lại trong quý.

• Sáng kiến DAC công bố ngày 29/07/2026, phạm vi toàn trường, kéo dài nhiều năm
• Do giáo sư Nitesh Chawla làm giám đốc
• Hợp nhất thế mạnh sẵn có ở các trường, khoa và trung tâm nghiên cứu
• Nhấn mạnh ứng dụng công nghệ mới vào các vấn đề xã hội và AI có trách nhiệm

Mình để tin này vào bản tin vì nó chạm đúng câu chuyện đào tạo ở Việt Nam. Chúng ta vẫn đang dạy data như một chuyên ngành hẹp: học SQL, học Python, học dashboard. Trong khi mô hình mà Notre Dame chọn là coi data và AI như năng lực nền, gắn vào từng ngành cụ thể — y tế, kinh tế, xã hội học. Kinh nghiệm dạy của mình nói rằng cách thứ hai hiệu quả hơn nhiều: học viên hiểu bài toán ngành trước rồi mới học công cụ luôn đi nhanh hơn học viên chỉ biết cú pháp. Đó cũng là lý do thị trường tuyển dụng data đang thừa người biết viết truy vấn nhưng thiếu người giải được bài toán. Với các trường và trung tâm đào tạo ở Việt Nam, hướng đi thực tế là gắn chương trình data vào từng khối ngành sẵn có thay vì mở thêm một khoa mới. Còn với người học: đừng chỉ sưu tầm chứng chỉ công cụ, hãy chọn một lĩnh vực và hiểu sâu dữ liệu của nó.

• Vòng gọi vốn 20 triệu USD công bố ngày 28/07/2026
• Khách hàng mục tiêu là doanh nghiệp Fortune 500
• Ba ngành trọng tâm: bảo hiểm, quản lý đội xe, logistics
• Đưa dữ liệu phương tiện và vận hành vào luồng phân tích và AI

Tin này nhỏ nhưng nói lên một điều mà mình hay nhắc trong các dự án tư vấn: phần đắt nhất của một hệ thống dữ liệu ngành không phải kho, không phải mô hình, mà là lớp kết nối và chuẩn hoá nguồn. Trong bảo hiểm xe, mỗi hãng thiết bị GPS trả một định dạng, một tần suất, một cách hiểu về "phanh gấp" khác nhau. Ai chuẩn hoá được lớp đó thì sở hữu con hào cạnh tranh, còn mô hình chấm điểm rủi ro thì ai cũng làm được. Việt Nam đang có bài toán y hệt trong logistics và bảo hiểm ô tô, và phần lớn doanh nghiệp vẫn tự viết parser cho từng nhà cung cấp — vừa tốn vừa dễ hỏng khi đối tác đổi firmware. Khuyến nghị cụ thể: nếu đội bạn đang tích hợp từ ba nhà cung cấp trở lên, hãy đầu tư một canonical model cho sự kiện phương tiện trước khi nghĩ tới mô hình AI. Làm ngược thứ tự là cách nhanh nhất để có một dự án AI chết yểu vì dữ liệu bẩn.