- Hiện tại, AWS cho phép Aurora PostgreSQL đọc dữ liệu Apache Iceberg và Apache Parquet từ S3 và S3 Tables mà không cần phải tải dữ liệu vào cơ sở dữ liệu trước.
- Tính năng này sử dụng công cụ DuckDB nhúng, tiện ích mở rộng aurora_analytics và vai trò IAM có quyền truy cập vào S3 và AWS Glue.
- Các phiên bản được hỗ trợ là Aurora PostgreSQL 17.11 trở lên, cộng với Aurora PostgreSQL 18.6 trở lên, trên cả khu vực thương mại và GovCloud.
- Các nhóm có thể kết hợp các hàng giao dịch trực tiếp với dữ liệu Lakehouse, lưu trữ kết quả và tạo ra các tập dữ liệu nóng để đọc với độ trễ thấp.
Amazon Web Services đã mở ra một hướng đi mới cho các cụm Aurora PostgreSQL cần kết hợp các bản ghi ứng dụng hàng ngày với các tệp nằm trong kho dữ liệu. Giờ đây, cơ sở dữ liệu được quản lý có thể đọc các bảng Apache Iceberg và các tệp Apache Parquet mà không cần sao chép chúng vào Aurora trước, do đó một câu lệnh SQL duy nhất có thể bao gồm cả các hàng hoạt động trực tiếp và thông tin lưu trữ. Động thái này hướng đến các nhóm đã mệt mỏi với việc xây dựng và giám sát các tác vụ trích xuất, chuyển đổi và tải (ETL) chỉ để trả lời các câu hỏi liên quan đến dữ liệu hiện tại và lịch sử.
Thay vì coi kho dữ liệu (data lake) như một thế giới riêng biệt, dịch vụ này cho phép các máy khách, công cụ và điểm cuối PostgreSQL hiện có truy cập nội dung của kho dữ liệu thông qua các bảng trung gian. Điều đó có nghĩa là không cần phải có bản sao trùng lặp của tập dữ liệu lịch sử bên trong cơ sở dữ liệu hoạt động, và các nhà phát triển ứng dụng có thể tiếp tục sử dụng cú pháp mà họ đã biết. AWS đang quảng bá điều này như một cách để giảm chi phí bảo trì đường dẫn dữ liệu, giảm sự phân tán cơ sở hạ tầng và giúp dễ dàng làm phong phú thêm các giao dịch với ngữ cảnh cũ hơn.
Những thay đổi mà tính năng mới của Aurora PostgreSQL mang lại
Tính năng này không phải là một sản phẩm phân tích riêng biệt mà khách hàng phải tự thiết lập ở nơi khác. Nó được kích hoạt thông qua tiện ích mở rộng aurora_analytics và một vai trò Quản lý danh tính và truy cập AWS (AWS Identity and Access Management) cấp cho cụm quyền truy cập vào Amazon S3 và Danh mục dữ liệu AWS Glue. Sau khi vai trò và tiện ích mở rộng đó được thiết lập, quản trị viên sẽ tạo các bảng ngoại tham chiếu đến dữ liệu Iceberg hoặc Parquet và truy vấn chúng tương tự như các bảng PostgreSQL thông thường.
Một phần đáng chú ý của kiến trúc là DuckDB được nhúng trực tiếp vào Aurora . Công cụ phân tích mã nguồn mở này xử lý việc quét các tập tin lakehouse trong khi Aurora tiếp tục phục vụ các khối lượng công việc vận hành. Quá trình xử lý truy vấn diễn ra trong môi trường cơ sở dữ liệu, tránh việc chuyển giao công việc cho một cụm máy chủ riêng biệt và giúp kiểm soát độ trễ và chi phí mạng.
Các nguồn dữ liệu được hỗ trợ bao gồm các bảng Iceberg được đăng ký trong AWS Glue Data Catalog, các đối tượng Parquet và Iceberg trong Amazon S3, và dữ liệu được lưu trữ trong S3 Tables. Các danh mục bên ngoài tuân theo giao diện Iceberg REST Catalog cũng có thể được truy cập thông qua liên kết với Glue, do đó các nhóm không cần phải từ bỏ các khoản đầu tư vào danh mục mà họ đã có. Một truy vấn có thể kết hợp các hàng từ Aurora với các bảng Iceberg trải rộng trên nhiều danh mục, cung cấp cho các ứng dụng một cái nhìn thống nhất mà không cần di chuyển tệp.
Các phiên bản, thiết lập và dịch vụ được hỗ trợ
Aurora PostgreSQL 17 từ phiên bản 17.11 trở lên và Aurora PostgreSQL 18 từ phiên bản 18.6 trở lên là các phiên bản được hỗ trợ. Sau khi tạo hoặc chọn cụm, quản trị viên sẽ gắn vai trò IAM với tính năng AuroraAnalytics và bật tiện ích mở rộng. Quá trình thiết lập có thể được thực hiện thông qua bảng điều khiển Amazon RDS hoặc một ứng dụng khách PostgreSQL như psql.
Các định nghĩa bảng ngoại có thể được tạo từng cái một, nhưng trong môi trường lớn hơn, có thể sử dụng lệnh IMPORT FOREIGN SCHEMA để tạo nhiều bảng ngoại cùng một lúc từ cơ sở dữ liệu AWS Glue Data Catalog. Đối với các tệp Parquet, Aurora có thể đọc lược đồ từ siêu dữ liệu của tệp, giúp loại bỏ nhu cầu phải khai báo thủ công từng cột. Chi tiết này rất quan trọng đối với các nhóm có tập dữ liệu lớn hoặc thường xuyên thay đổi.
Các truy vấn đọc có thể chạy trên phiên bản ghi hoặc trên bản sao đọc, do đó các quá trình quét phân tích có thể được chuyển ra khỏi khối lượng công việc vận hành chính. Các lệnh ghi dữ liệu vào Aurora, chẳng hạn như CREATE TABLE AS SELECT, INSERT INTO … SELECT hoặc MERGE INTO, chạy trên phiên bản ghi . Điều này cung cấp cho các nhóm một cách để hiện thực hóa dữ liệu lakehouse nóng vào một bảng gốc khi họ cần phản hồi nhanh chóng và nhất quán.
Để xem một truy vấn đang thực hiện những gì, quản trị viên có thể gọi hàm aurora_analytics_stat_statements(). Hàm này báo cáo các chỉ số như số hàng được quét, số byte được đọc từ Amazon S3 và số lần truy cập bộ nhớ cache . Dữ liệu được sử dụng thường xuyên được lưu vào bộ nhớ cache trên phiên bản Aurora, do đó việc truy cập lặp đi lặp lại vào cùng một đối tượng lakehouse có thể trả về kết quả nhanh hơn mà không cần phải liên tục lấy lại cùng một byte từ bộ nhớ lưu trữ đối tượng.
Hiệu năng, bộ nhớ đệm và các đường dẫn có độ trễ thấp
Aurora áp dụng cơ chế đẩy điều kiện lọc xuống (predicate pushdown) và cắt tỉa cột (column pruning ), nghĩa là chỉ những hàng và cột liên quan mới được yêu cầu từ kho dữ liệu. Khi tập dữ liệu cơ bản phát triển, việc lọc này giúp ngăn chặn các truy vấn biến thành các lần quét toàn bộ (full scan). Kết quả được lưu trong bộ nhớ cache và số liệu thống kê truy vấn cung cấp cho người vận hành một cách thiết thực để điều chỉnh khối lượng công việc thay vì phải đoán xem thời gian được dành cho việc gì.
Đối với các ứng dụng yêu cầu độ trễ chỉ vài mili giây, AWS coi việc sao chép dữ liệu (materialization) là giải pháp tối ưu. Các bản ghi được chọn từ data lake có thể được sao chép vào bảng Aurora PostgreSQL gốc bằng các lệnh SQL quen thuộc, sau đó được truy vấn như bất kỳ bảng cục bộ nào khác. Điều này giúp duy trì đường dẫn nhanh cho dữ liệu được truy cập nhiều nhất, đồng thời vẫn cho phép sử dụng toàn bộ data lake để phân tích rộng hơn.
Công ty này liệt kê các bảng điều khiển thời gian thực, các giao dịch được làm giàu bằng ngữ cảnh lịch sử và các tác nhân AI cần suy luận trên cả các bản ghi hiện tại và đã lưu trữ là các trường hợp sử dụng điển hình. Điểm chung là khối lượng công việc không thể chờ đợi quá trình xử lý hàng loạt ban đêm hoặc công việc ETL ngược. Bằng cách cho phép một ứng dụng yêu cầu cả thông tin mới và cũ từ một cơ sở dữ liệu duy nhất, AWS hy vọng sẽ loại bỏ một nguồn phức tạp thường xuyên trong quy trình xử lý dữ liệu.
Tính khả dụng và giá cả
Theo AWS, tính năng này hiện có sẵn tại tất cả các khu vực AWS thương mại và khu vực AWS GovCloud (Hoa Kỳ). Không có phí tính năng riêng biệt. Khách hàng vẫn phải trả phí cho tài nguyên điện toán Aurora bổ sung mà các truy vấn tiêu thụ và phí yêu cầu Amazon S3 liên quan đến việc đọc các tệp dữ liệu trong kho dữ liệu. Mô hình định giá này giúp giảm chi phí ban đầu, mặc dù việc sử dụng cho phân tích chuyên sâu vẫn sẽ ảnh hưởng đến hóa đơn.
AWS đã định hình việc ra mắt này như một phần của nỗ lực rộng lớn hơn nhằm đưa hiệu năng của DuckDB vào các dịch vụ được quản lý của mình. Nhóm DuckLabs, đơn vị duy trì dự án DuckDB, đã gia nhập Amazon, và công ty cho biết những cải tiến trong tương lai đối với công cụ mã nguồn mở này có thể được tích hợp vào Aurora và các dịch vụ khác của AWS. Mối liên hệ đó cho thấy sự tích hợp này được thiết kế để phát triển dần chứ không chỉ là một tính năng riêng lẻ.
Đối với các nhóm quản trị cơ sở dữ liệu, lợi ích thực tiễn khá quen thuộc: ít thành phần chuyển động hơn, ít dữ liệu trùng lặp hơn và con đường từ câu hỏi đến câu trả lời ngắn hơn. Nhược điểm là việc kiểm soát truy cập, quyền IAM và cấu hình danh mục vẫn cần được xử lý cẩn thận. Một cụm máy chủ có thể truy cập cả các hàng dữ liệu sản xuất và các tệp dữ liệu lưu trữ sẽ trở thành một bề mặt truy vấn duy nhất mạnh mẽ , do đó quản trị vẫn là một phần của công việc.
Hiệu quả thực tiễn là tạo ra sự liên kết chặt chẽ hơn giữa Aurora PostgreSQL và kho dữ liệu. Các giao dịch hiện tại và các tệp lịch sử có thể được kết hợp trong một truy vấn SQL duy nhất, DuckDB xử lý việc quét phân tích, và việc tạo dữ liệu vật chất cung cấp một đường dẫn nhanh khi cần thiết. Các nhóm đã đầu tư vào công cụ PostgreSQL sẽ có thêm một lựa chọn cho các khối lượng công việc phân tích chuyên sâu, trong khi những nhóm có yêu cầu bảo mật hoặc kiểm soát chi phí nghiêm ngặt sẽ muốn xem xét lại quyền truy cập, hành vi bộ nhớ đệm và việc sử dụng S3 trước khi triển khai rộng rãi.
