Spotify Xây dựng Chỉ mục Ngoài để Cho phép Truy vấn Điểm Độ trễ Thấp trên Hồ dữ liệu của mình

Trang chủ InfoQ Tin tức Spotify xây dựng chỉ mục bên ngoài để cho phép truy vấn điểm độ trễ thấp trên Data Lake của mình Kiến trúc & Thiết kế Spotify xây dựng chỉ mục bên ngoài để cho phép truy vấn điểm độ trễ thấp trên Data Lake của mình Ngày 12/8/2026 2 phút đọc bởi Leela Kumili Theo dõi chúng tôi trên Youtube 232K Người theo dõi Linkedin 26K Người theo dõi Instagram Mới RSS 19K Độc giả X 57.1k Người theo dõi Facebook 21K Lượt thích Bluesky Mới Nghe bài viết này - 0:00 Âm thanh sẵn sàng phát Trình duyệt của bạn không hỗ trợ phần tử âm thanh. 0:00 0:00 Bình thường 1.25x 1.5x Thích Danh sách đọc Spotify đã giới thiệu Random Access Parquet (RAP), một kiến trúc lưu trữ cho phép truy vấn điểm (point queries) với độ trễ thấp trực tiếp trên dữ liệu được lưu trữ trong hồ dữ liệu (data lake) của mình. Điều này cho phép các dịch vụ trực tuyến và ứng dụng AI truy xuất từng bản ghi mà không cần sao chép bộ dữ liệu vào các cơ sở dữ liệu vận hành. RAP bổ sung một lớp lập chỉ mục bên ngoài trên các tệp Apache Parquet, cho phép tra cứu tương tác trong khi vẫn tiếp tục sử dụng cùng một bộ dữ liệu cho phân tích, học máy và phục vụ trực tuyến. Spotify giải thích rằng các hồ dữ liệu hiện đại đã trở thành kho lưu trữ trung tâm cho các khối lượng công việc phân tích và AI, nhưng việc truy xuất từng bản ghi vẫn kém hiệu quả vì các công cụ truy vấn phân tán như Trino và BigQuery được tối ưu hóa cho quét phân tích (analytical scans) hơn là tra cứu dựa trên khóa (key-based lookups). Mặc dù các kho đối tượng đám mây như Google Cloud Storage hiện cung cấp độ trễ truy cập ở mức mili giây, nhưng việc lập kế hoạch truy vấn, duyệt siêu dữ liệu và khám phá tệp có thể làm tăng đáng kể chi phí cho các truy vấn điểm. Spotify lưu ý rằng họ lưu trữ petabyte dữ liệu trực tuyến trong Bigtable trong khi exabyte dữ liệu nằm trong hồ dữ liệu dựa trên Google Cloud Storage, khiến việc sao chép quy mô lớn vào các cơ sở dữ liệu phục vụ ngày càng tốn kém. RAP giải quyết thách thức này bằng cách giới thiệu một chỉ mục bên ngoài ánh xạ các khóa tra cứu, chẳng hạn như ID người dùng, trực tiếp đến các tệp Parquet và vị trí hàng. Thay vì quét hàng nghìn tệp, một truy vấn sẽ phân giải khóa thông qua chỉ mục trước khi thực hiện một thao tác đọc theo phạm vi (ranged read) có mục tiêu đối với kho đối tượng. Khi dữ liệu mới được ghi vào các bảng Apache Iceberg, một trình tạo chỉ mục sẽ tạo các phân đoạn chỉ mục chỉ thêm vào (append-only) mà không sửa đổi các tệp Parquet bất biến. Spotify cho biết phương pháp này cho phép cùng một bộ dữ liệu hỗ trợ xử lý phân tích, các quy trình học máy, sổ ghi chép (notebooks), tác nhân AI và các ứng dụng trực tuyến nhạy cảm với độ trễ mà không cần duy trì các hệ thống lưu trữ trùng lặp. Thông báo của Spotify tiếp nối những nỗ lực rộng lớn hơn nhằm mở rộng các công nghệ hồ dữ liệu mở vượt ra ngoài xử lý phân tích. Google Cloud gần đây đã mô tả một kiến trúc lakehouse dựa trên Apache Iceberg cho các ứng dụng AI, cũng tìm cách giảm trùng lặp dữ liệu trong khi cho phép truy cập vận hành vào dữ liệu. Không giống như phương pháp đó, RAP giới thiệu một lớp lập chỉ mục bên ngoài chuyên dụng được tối ưu hóa cho các tra cứu điểm trong khi vẫn tương thích với các tệp Parquet và bảng Iceberg hiện có. Kiến trúc này cũng tạo ra các cuộc thảo luận trong cộng đồng kỹ thuật dữ liệu. Andrew Lamb đã nêu bật RAP như một ví dụ về việc mở rộng các định dạng dữ liệu mở cho các khối lượng công việc tương tác. Trong một cuộc thảo luận riêng trên LinkedIn, Vikas Singh lập luận rằng những cải tiến về hiệu suất lưu trữ đối tượng đám mây đã chuyển phần lớn độ trễ liên quan đến các truy vấn điểm sang lập kế hoạch truy vấn và truy cập siêu dữ liệu, một lĩnh vực mà RAP được thiết kế để giảm thiểu thông qua các chỉ mục được tính toán trước. Spotify cũng mô tả một số tối ưu hóa bố cục lưu trữ giúp giảm độ trễ truy vấn điểm. Chúng bao gồm sắp xếp dữ liệu theo khóa tra cứu để giảm số lượng tệp được truy cập, nhóm các bản ghi liên quan lại với nhau, xen kẽ các cột giá trị để nhiều thuộc tính có thể được truy xuất thông qua một lần đọc liên tục duy nhất và sử dụng các chỉ mục bao phủ (covering indexes) có thể đáp ứng một số truy vấn mà không cần đọc các tệp Parquet. Theo Spotify, các kỹ thuật này đánh đổi sự gia tăng khiêm tốn về kích thước tệp hoặc chỉ mục để giảm số lượng thao tác lưu trữ, cho phép một số truy vấn điểm được phục vụ thông qua một lần đọc theo phạm vi duy nhất chỉ vài kilobyte. Bố cục cột giá trị xen kẽ cho phép các giá trị liên quan từ nhiều cột (Nguồn: Bài đăng trên Blog của Spotify). Spotify cũng hỗ trợ các chỉ mục thứ cấp (secondary indexes), cho phép truy vấn hiệu quả trên nhiều chiều tra cứu, như ID người mua hoặc ID người bán, mà không cần viết lại các tệp Parquet. Các chỉ mục dựa trên hàm băm (hash-based indexes) hỗ trợ tra cứu chính xác, trong khi các chỉ mục đã sắp xếp (sorted indexes) cho phép truy vấn phạm vi. Spotify cho biết các chỉ mục thứ cấp được quản lý ở lớp phục vụ (serving layer), cho phép các đường dẫn truy cập mới mà không thay đổi các đường ống dữ liệu (data pipelines), đồng thời tiếp tục sử dụng cùng một tập dữ liệu Parquet cho cả quét phân tích (analytical scans) và tra cứu điểm tương tác (interactive point lookups). Các kỹ thuật bố cục lưu trữ như Z ordering và đường cong Hilbert có thể cải thiện hơn nữa tính cục bộ của dữ liệu (data locality) cho các chiều tra cứu thứ cấp. Về tác giả Leela Kumili Đánh giá bài viết này Mức độ áp dụng Phong cách Tác giả đã được liên hệ Nội dung này thuộc chủ đề Apache Iceberg Các chủ đề liên quan: Phát triển Kiến trúc & Thiết kế AI, ML & Kỹ thuật dữ liệu Google Cloud Kiến trúc AI Dữ liệu lớn (Big Data) IndexedDB Apache Iceberg Hồ dữ liệu (Data Lake) Kỹ thuật phần mềm Dữ liệu Hệ thống phân tán