• Viết mới hoàn toàn cho JVM, chỉ làm một việc: đọc Parquet thật nhanh.
• Đa luồng ngay từ lõi, trải giải mã trang ra mọi nhân CPU mặc định.
• Không có phụ thuộc bắt buộc — dễ nhúng, ít xung đột thư viện.
• Trải qua 5 bản preview (Alpha1, Beta1/2, CR1/2) trước khi lên 1.0.

Chi phí đọc file là nút cổ chai âm thầm của mọi lakehouse — bạn có thể tối ưu query engine bao nhiêu tùy thích, nhưng nếu lớp đọc Parquet chậm thì cả pipeline chậm theo. Hardwood đánh đúng chỗ đó: đa luồng, không dependency, dễ nhúng vào Flink, Trino, hay job Spark tùy biến. Điểm mình thích nhất là triết lý phát triển: "built with AI, but not by AI" — mọi thay đổi lớn bắt đầu từ design doc, con người sở hữu kiến trúc, agent chỉ tăng tốc. Với team data JVM tại Việt Nam, đây là thứ nên thử benchmark ngay: nếu job đọc Parquet nặng, thay lớp reader có thể cắt được cả giờ CPU mỗi ngày. Đừng vội thay production, nhưng nên đưa vào danh sách đánh giá.

• Vote thông qua đặc tả Expressions: chốt hành vi lọc/biến đổi dữ liệu.
• Thêm trường specific-name cho UDF để định danh phiên bản hàm.
• Đề xuất kho iceberg-testing dùng chung cho 5 bản cài đặt.
• Iceberg Rust 0.10.0 RC1 được đưa ra bỏ phiếu.

Đây nghe khô khan nhưng lại là tin nền tảng nhất tuần. Khi Iceberg có 5 bản cài (Java, Python, Rust, Go, C++), rủi ro lớn nhất là mỗi bản hiểu spec một kiểu — bạn ghi bằng Spark, đọc bằng Trino mà ra kết quả lệch. Việc chốt đặc tả Expressions và dựng bộ test conformance chung chính là "keo dán" giữ cho hệ sinh thái không phân mảnh. Với doanh nghiệp: đây là lý do bạn có thể yên tâm đặt Iceberg làm format lõi, dùng nhiều engine trên cùng bảng mà không sợ vendor lock hay sai số. Cuộc chiến format đã xong; giờ ai chuẩn hóa và governance tốt hơn sẽ thắng ở tầng catalog và semantic.

• DuckLake inlining: commit nhỏ nằm trong catalog, tránh đẻ file Parquet tí hon.
• Extension Lance: lance_vector_search, lance_fts, lance_hybrid_search bằng SQL.
• MotherDuck Flights: ingest kiểu agent-native.
• Quack — giao thức client-server mới, kèm lớp OAuth.

Điều thú vị là DuckDB đang lặng lẽ trở thành backend cho cả phân tích lẫn RAG. Với extension Lance, bạn làm vector search và hybrid search ngay trong SQL, không cần dựng riêng một vector DB — cực hợp cho prototype RAG và ứng dụng nhỏ. DuckLake inlining giải quyết bài toán "small files" kinh điển của lakehouse: hàng nghìn file Parquet tí hon làm chậm query và đắt storage; giờ commit nhỏ nằm trong catalog SQL. Lời khuyên của mình cho team Việt: nếu dữ liệu dưới vài trăm GB và cần rẻ-nhanh, đừng vội lên warehouse đắt tiền — DuckDB/MotherDuck + Lance đủ để chạy phân tích và RAG production nhỏ.

• Coding agent + terminal nhúng thẳng trong nền tảng, cài sẵn Claude Code & Codex.
• Nhiều phiên agent chạy song song; mô tả bằng lời, agent viết-chạy-lặp code.
• SQL qua Trino, dashboard qua Apache Superset, xuất PDF/PNG.
• Mount external table không copy; ingest bằng DLTHub theo lịch.
• Lõi AI Lakehouse: feature store + model registry + vector database.

Đây là tin mình tâm đắc nhất tuần, vì nó biến "agentic data engineering" từ khẩu hiệu thành sản phẩm. Điểm mạnh: không còn nhảy giữa chục công cụ — ingest, feature store, SQL, dashboard, inference nằm trong một nơi, và agent làm phần khung. Điểm mình đánh giá cao hơn cả tính năng là hướng "sovereign": dữ liệu và cả coding agent chạy trong hạ tầng của bạn, không đẩy hết lên cloud bên thứ ba. Với khu vực công và doanh nghiệp Việt có yêu cầu chủ quyền dữ liệu, đây là điểm cộng thật. Nhưng cảnh báo: agent nhúng sẵn không cứu được dữ liệu bẩn hay thiếu semantic layer. Nên coi Hopsworks 5.0 là chỗ tăng tốc cho team đã có nền tảng dữ liệu tử tế, đừng kỳ vọng nó tự dọn "bãi rác" giúp bạn.

• Vote chấp nhận đặc tả OSI Semantic Model API vào Polaris.
• Khung lưu định nghĩa nghiệp vụ (semantic layer) ngay trong catalog.
• Bàn hỗ trợ đổi backend DB (Postgres → MySQL) lúc chạy, không build lại.
• Có committer mới (Nandor Kollar); rc0 1.6.0 bị vote trượt vì thiếu artifact.

Đây là mảnh ghép ít người để ý nhưng cực quan trọng cho làn sóng agentic. AI agent trả lời sai text-to-SQL phần lớn vì không hiểu "doanh thu thuần" hay "khách active" nghĩa là gì trong ngữ cảnh doanh nghiệp — đó là việc của semantic layer. Đưa semantic model thành chuẩn ngay trong catalog mở (Polaris) nghĩa là định nghĩa nghiệp vụ trở thành tài sản dùng chung cho mọi engine và agent, thay vì bị nhốt trong từng công cụ BI. Nối thẳng với tin Cortex Sense của Snowflake: cả ngành đang hội tụ về một sự thật — muốn agent trả lời đúng, phải chuẩn hóa ngữ nghĩa trước. Team nào đầu tư semantic layer sớm sẽ đỡ đau khi bật agent.

• DataFusion Python bindings 54.0.0 (RC2 được vote thông qua).
• Kiểm chứng trên nhiều kiến trúc Mac (M3, M4).
• Arrow đưa ADBC thành extension cho DuckDB.
• Di chuyển dữ liệu Arrow dạng cột, tránh chuyển đổi từng dòng.

Tin cho dân engine và pipeline: hệ Rust + Arrow đang lớn nhanh và trở thành lớp lõi cho phân tích hiện đại. DataFusion cho bạn một query engine nhúng được, viết bằng Rust, gọi từ Python — nhẹ và nhanh hơn nhiều so với kéo cả Spark cho việc nhỏ. ADBC thì giải quyết "thuế chuyển đổi": lâu nay dữ liệu qua ODBC/JDBC phải serialize từng dòng, giờ Arrow đi thẳng dạng cột, giảm chi phí đáng kể khi đổ dữ liệu giữa DuckDB, Postgres và các engine. Với team Python-heavy, đây là hướng nên theo dõi: ít phụ thuộc JVM hơn, hiệu năng cao hơn cho các job vừa và nhỏ.

• Lớp ngữ cảnh runtime: gom metadata, lịch sử truy vấn, semantic view.
• Độ chính xác benchmark nội bộ: 24,1% → 86,3%.
• Chi phí mỗi truy vấn: 1,76 USD → 0,59 USD.
• Chạy cùng semantic view (chuẩn vàng), tự xây hiểu biết cho phần còn lại.
• Hoạt động trong CoWork/CoCo, có sẵn plugin và MCP connector.

Đây là tin "hot nhất tuần" theo mình, và không phải vì marketing. Con số 24% lên 86% nói toẹt ra điều mà nhiều dự án AI đang vấp: agent không sai vì model kém, mà vì không có ngữ cảnh — nó không biết bảng nào là bảng thật, cột nào là doanh thu, định nghĩa "khách active" ra sao. Cortex Sense về bản chất là "context engineering đóng gói": gom metadata + lịch sử truy vấn + semantic view để agent bớt đoán mò. Cái hay là nó không thay semantic view mà bổ trợ — ở chỗ cần chuẩn thì semantic view là gold standard. Với doanh nghiệp Việt: bài học không phải "mua Cortex Sense", mà là "đầu tư ngữ cảnh và semantic layer trước khi bật agent". Rẻ hơn ba lần mỗi truy vấn cũng là con số thực dụng — grounding tốt giúp agent bớt gọi LLM lung tung, giảm hóa đơn token thấy rõ.

• Wes McKinney dựng lại dịch vụ benchmark conbench của Arrow bằng Codex, nói công khai.
• Parquet bắt đầu soạn chính sách dùng công cụ AI trong dự án.
• Hardwood: "built with AI, but not by AI" — con người sở hữu kiến trúc.
• Cộng đồng lakehouse nằm trong nhóm đầu định hình chuẩn đóng góp có agent.

Đây là góc mình thấy đáng suy ngẫm nhất: không phải một sản phẩm, mà là một chuẩn mực đang hình thành. Các dự án dữ liệu mề nghiêm túc nhất — Arrow, Parquet, Iceberg — không cấm AI, cũng không "vibe coding" bừa. Họ dùng agent để tăng tốc nhưng giữ con người sở hữu kiến trúc, review từng diff, và bắt đầu viết chính sách rõ ràng. Đó chính là mô hình mọi team data nên copy khi đưa agent vào quy trình: agent viết bản nháp, con người quyết định thiết kế và chịu trách nhiệm cuối. Câu "AI khuếch đại người biết làm việc rõ ràng" đúng ở đây — dự án càng có kỷ luật kỹ thuật, agent càng phát huy; dự án lỏng lẻo thì agent chỉ nhân bản mớ hỗn độn nhanh hơn.

• Hopsworks nhúng Claude Code/Codex; Snowflake ra Cortex Sense & Cortex Code.
• Databricks đưa Genie sang pay-as-you-go, mỗi user có 150 DBU LLM/tháng miễn phí.
• Coding agent thành giao diện mặc định để xây pipeline và phân tích.
• Vai trò DE dịch sang thiết kế ngữ cảnh, semantic, governance.

Ba ông lớn khác nhau, cùng một tuần, cùng một hướng — đó không phải trùng hợp mà là dịch chuyển ngành. Với mình, câu hỏi thật cho data engineer không phải "agent có thay tôi không" mà "phần giá trị của tôi dịch đi đâu". Câu trả lời: dịch từ gõ ETL sang thiết kế ngữ cảnh, dựng semantic layer, đặt governance và review đầu ra của agent. Kỹ năng gõ SQL nhanh sẽ mất giá; kỹ năng hiểu nghiệp vụ, mô hình hóa dữ liệu và kiểm soát chất lượng sẽ lên giá. Cảnh báo thực tế: đừng biến agent thành phong trào. Bật agent trên dữ liệu bẩn và không có semantic layer chỉ tạo ra "rác nhanh hơn". Hãy biến nó thành hệ thống có kỷ luật — có ngữ cảnh chuẩn, có người review, có governance.

• DuckDB: mạnh ở phân tích cục bộ/nhúng, chi phí thấp, dễ triển khai.
• ClickHouse: mạnh ở quy mô lớn, real-time, workload nặng.
• Cảnh báo "benchmark blindspots": số đẹp không phản ánh workload thật.
• PostHog và nhiều team dùng cả hai cho mục đích khác nhau.

Tranh luận này quay lại đều đặn, và câu trả lời vẫn vậy: chọn engine theo workload, không theo hype. DuckDB tuyệt vời cho phân tích cục bộ, prototype, RAG nhỏ, và những việc "một máy là đủ" — rẻ, nhanh, không cần vận hành cụm. ClickHouse là lựa chọn khi bạn cần nuốt hàng tỉ dòng, truy vấn real-time, phục vụ dashboard tải cao. Điểm mình muốn nhấn: cẩn thận với benchmark — số liệu đẹp thường đến từ workload được chọn khéo. Cách đúng là benchmark trên chính dữ liệu và câu truy vấn của bạn. Với đa số team Việt quy mô vừa, bắt đầu bằng DuckDB/MotherDuck để tiết kiệm, chỉ lên ClickHouse khi thật sự chạm trần về quy mô hoặc yêu cầu real-time.

• Karp lên CNBC Squawk Box (1/7): "something has gone completely wrong".
• Phê phán bán "token/weights" thay vì kết quả kinh doanh thực.
• Tuyên ngôn 9 điểm về "AI sovereignty" đăng trên X.
• Đặt lại câu hỏi giá trị giữa cơn sốt agentic.

Karp nói lớn tiếng, đôi khi quá đà, nhưng luận điểm cốt lõi thì đúng và hợp thời: đừng bán "token" hay "model", hãy bán kết quả. Với người làm data, đây là lời nhắc thực dụng — dashboard đẹp hay agent xịn không phải mục tiêu; mục tiêu là quyết định tốt hơn, tiết kiệm thật, rủi ro giảm thật. Mình đồng ý phần này, nhưng cẩn trọng ở chỗ: "AI sovereignty" cũng là chiến lược bán hàng của chính Palantir. Cách đọc tin lành mạnh: lấy phần phản biện (đo giá trị nghiệp vụ, đừng chạy theo hype token) và bỏ phần khẩu hiệu. Câu hỏi bạn nên hỏi mọi dự án AI/data: nó thay đổi được con số nào của doanh nghiệp?

• Frontier Company: đơn vị vận hành mới, ngân sách 2,5 tỷ USD.
• Khoảng 6.000 kỹ sư/chuyên gia nhúng vào tổ chức khách hàng.
• Đồng thiết kế, triển khai, cải tiến AI gắn kết quả đo được.
• Nhắm thẳng vào tỉ lệ "pilot AI thất bại" của doanh nghiệp.

Con số biết nói: 2,5 tỷ USD và 6.000 người nhúng vào khách hàng nghĩa là Microsoft thừa nhận nút thắt AI doanh nghiệp không nằm ở model, mà ở triển khai và dữ liệu tại chỗ. Đây là tin data nhiều hơn vẻ ngoài: muốn AI ra kết quả, phải chạm được dữ liệu thật, quy trình thật, con người thật của khách hàng. Với data leader Việt Nam, mình đọc theo hai chiều: (1) áp lực — sếp sẽ hỏi "AI của mình tạo ra kết quả gì?", pilot cho vui hết thời; (2) cơ hội — team dữ liệu nội bộ chính là người hiểu dữ liệu và nghiệp vụ tại chỗ, tức là chỗ tạo ra giá trị mà vendor phải thuê ngoài. Ai làm chủ dữ liệu nội bộ và semantic sẽ có ghế ở bàn quyết định.

• AWS lập tổ chức triển khai AI nội bộ trị giá 1 tỷ USD (30/6).
• Công khai ôm mô hình Forward Deployed Engineering (FDE).
• Đi trước công bố Frontier Company của Microsoft đúng hai ngày.
• Cả ngành hội tụ về "bán triển khai và kết quả", không chỉ bán hạ tầng.

Cùng một tuần, AWS, Microsoft và Palantir đều đặt cược vào forward-deployed engineering — kỹ sư sống cùng khách hàng để đưa AI chạm sản xuất. Đây là tín hiệu chiến lược rõ: bán hạ tầng và model là chưa đủ, phải bán cả năng lực triển khai. Với team data, thông điệp thực dụng là: giá trị dịch về nơi dữ liệu và nghiệp vụ sống. Đừng lo bị thay thế bởi vendor FDE — ngược lại, hãy trở thành "người bản địa" hiểu dữ liệu nội bộ mà bất kỳ kỹ sư nằm vùng nào cũng phải dựa vào. Muốn vậy, đầu tư vào catalog, semantic layer, governance và tài liệu dữ liệu ngay từ bây giờ.