Định dạng bảng Iceberg, một ý tưởng hay - đặc tả được định nghĩa sai - Phần 2/2

Những vấn đề của đặc tả Iceberg

• Vấn đề nghiêm trọng của đặc tả Iceberg: Đặc tả Iceberg không phải là một nỗ lực nghiêm túc nhằm giải quyết bài toán metadata của các data lake quy mô lớn.
• Bài học lịch sử: Trong phần đầu, tác giả đã quay lại lịch sử để rút ra bài học từ quá khứ và giới thiệu "bài toán quản lý không gian" mà cơ sở dữ liệu phải giải quyết.
  • Các thành phần của vấn đề:
    1. Phân mảnh không gian
    2. Kiểm soát đồng thời ở mức hạt mịn
    3. Tính nguyên tử trên nhiều đối tượng
    4. Sự lệch pha giữa hàng và tệp
    5. Truy cập metadata với độ trễ thấp và thông lượng cao
• Tầm quan trọng của định dạng mở: Tác giả hoàn toàn ủng hộ việc sử dụng định dạng mở trên toàn bộ stack, và đặc biệt hào hứng với việc dùng Parquet làm định dạng lưu trữ chung cho dữ liệu bảng.
• Sự khác biệt giữa tệp Parquet và bảng cơ sở dữ liệu: Chỉ vì có một tập hợp các tệp Parquet không có nghĩa đó là một bảng cơ sở dữ liệu. Một bảng cơ sở dữ liệu còn nhiều hơn chỉ là một tập hợp các hàng.

Tóm tắt bài toán metadata

• Bài toán quản lý không gian: Tác giả nhấn mạnh lại nhiều vấn đề mà cơ sở dữ liệu phải giải quyết.
• Sự cần thiết của metadata: Để làm cho nhiều tệp Parquet trông giống như một bảng cơ sở dữ liệu, cần có các metadata sau:
  1. Danh sách vị trí của mọi tệp cấu thành bảng
  2. Metadata xấp xỉ cho từng tệp
  3. Cơ chế kiểm soát giao dịch để có thể thêm hoặc xóa tệp
  4. Cách để tiến hóa schema của bảng
• Tìm vị trí tệp: Để coi một tập tệp Parquet như một bảng duy nhất, cần có cơ chế tìm ra các tệp.
• Tầm quan trọng của metadata: Mỗi tệp cần thêm metadata để có thể nhanh chóng tìm ra các hàng đáng quan tâm.

Tệp Parquet và bảng cơ sở dữ liệu

• Định nghĩa tệp Parquet: Parquet cung cấp một định dạng dữ liệu dạng bảng, tự mô tả.
• Định nghĩa bảng cơ sở dữ liệu: Một bảng cơ sở dữ liệu không chỉ đơn thuần là một tập hợp các hàng mà còn cần nhiều metadata và cơ chế kiểm soát giao dịch.
• Điều kiện để dùng tệp Parquet như bảng:
  1. Danh sách vị trí tệp
  2. Metadata của từng tệp
  3. Cơ chế kiểm soát giao dịch để thêm và xóa tệp
  4. Cách tiến hóa schema của bảng
• Sự khác biệt giữa tệp và bảng: Chỉ vì các tệp Parquet có cùng bố cục cột không có nghĩa chúng sẽ trông như một bảng cơ sở dữ liệu.

Tệp manifest và manifest list

• Quy trình thêm dữ liệu: Khi một client Iceberg muốn thêm dữ liệu vào bảng, nó phải đi qua các bước sau:
  1. Ghi một hoặc nhiều tệp Parquet vào một vị trí cụ thể (ví dụ: S3).
  2. Ghi một tệp manifest trỏ tới các tệp đã được ghi ở bước 1.
  3. Ghi một manifest list mới.
• Định dạng của tệp manifest: Tệp manifest và manifest list ở định dạng AVRO, được nén và tự mô tả.
• Nội dung của tệp manifest: Tệp manifest chứa con trỏ tới các tệp Parquet và metadata cho từng cột.
• Vấn đề kích thước metadata: Lưu metadata theo cách này làm nó lớn hơn mức cần thiết, và không thể nén bằng cách nhận biết các giá trị chuỗi chung giữa các tệp.

Gánh nặng tăng lên cho client

• Trách nhiệm của client: Xuyên suốt đặc tả Iceberg, client phải làm một lượng lớn công việc bookkeeping chỉ để thực hiện những thay đổi đơn giản.
• Vấn đề độ chính xác của metadata: Nếu client ghi sai một phần nào đó, việc commit snapshot mới phải được kiểm tra rất kỹ để xác minh dữ liệu manifest đã được ghi đúng hay chưa.
• Vấn đề bảo mật: Vì client phải ghi manifest list trỏ tới mọi tệp manifest, vị trí của tất cả các tệp trên S3 sẽ bị lộ.
• Tầm quan trọng của bảo mật dữ liệu: Vì dữ liệu có giá trị cao, cần phải đặt câu hỏi vì sao đặc tả này không coi bảo mật là ưu tiên hàng đầu.

Khiếm khuyết của bảo mật ở mức hàng

• Sự cần thiết của bảo mật mức hàng: Ngay cả ở những quốc gia quản lý tương đối lỏng như Mỹ, bảo mật ở mức hàng vẫn cần thiết để bảo vệ dữ liệu nhạy cảm.
• GDPR của EU: Tại châu Âu, các luật như GDPR đòi hỏi phải nhạy cảm hơn nhiều với việc truy cập dữ liệu.
• Vấn đề truy cập dữ liệu của client: Client có thể thêm dữ liệu vào bảng nhưng không thể bị giới hạn quyền truy cập đối với dữ liệu đã tồn tại từ trước.
• Mức độ nghiêm trọng của vấn đề bảo mật: Việc đặc tả không ưu tiên bảo mật buộc người ta phải đặt câu hỏi về cách nó nhìn nhận giá trị của thông tin trong data lake.

Vai trò của tệp metadata

• Ghi tệp metadata: Sau khi client ghi các tệp Parquet, nó phải tạo tệp manifest tương ứng, đọc manifest list hiện có, tạo một manifest list mới, rồi mới commit dữ liệu.
• Quy trình commit: Việc commit được thực hiện bằng cách ghi tệp metadata (<prefix>.metadata.json).
• Lựa chọn định dạng JSON: Lý do tệp metadata dùng định dạng JSON là không rõ ràng, và điều này tạo cảm giác như một "thiết kế bởi hội đồng".
• Tính lặp lại của metadata: Tệp metadata liệt kê mọi snapshot, làm lãng phí không gian do lặp lại thông tin.

Độ phức tạp của quy trình commit

• Vấn đề tính nguyên tử: Cần biến tệp metadata mới thành tệp mới nhất và thay thế tệp metadata cũ một cách nguyên tử.
• Độ phức tạp của thủ tục commit: Để commit phiên bản metadata mới V+1, cần thực hiện các bước sau:
  1. Tạo tệp metadata bảng mới dựa trên metadata hiện tại.
  2. Ghi metadata bảng mới vào một tệp duy nhất.
  3. Yêu cầu metastore thay con trỏ metadata của bảng từ V sang V+1.
• Xử lý khi swap thất bại: Nếu swap thất bại, nghĩa là một writer khác đã tạo V+1, nên client phải quay lại bước 1.
• Vấn đề race condition: Khi nhiều client cạnh tranh, client phải đọc lại tệp metadata do client trước đó ghi, rồi tạo lại manifest list và tệp metadata.

Vấn đề của kiểm soát đồng thời lạc quan

• Thực tế của đồng thời: Nếu không dự kiến có tranh chấp trên tài nguyên, dùng kiểu kiểm soát đồng thời nào cũng không quá quan trọng.
• Khi dự kiến có tranh chấp: Nếu hai client cùng muốn thay đổi một giá trị, cần dùng cơ chế khóa.
• Giới hạn của kiểm soát đồng thời lạc quan: Trong Iceberg, hai lần ghi đồng thời sẽ luôn xung đột, và nguyên nhân nằm ở cách đặc tả được thiết kế.
• Ngữ nghĩa khóa tệ nhất: Nó đang dùng ngữ nghĩa khóa tệ nhất cho metadata, trong khi nếu chỉ muốn thêm dữ liệu thì không cần điều phối giữa các client.

Giới hạn của việc hoán đổi metadata

• Tập trung hóa metadata: Bằng cách tập trung metadata của bảng vào một tệp duy nhất, nó tạo ra một điểm tranh chấp duy nhất cho mọi thao tác ghi.
• Gánh nặng cho client khi retry: Nếu client thất bại, nó phải đọc dữ liệu do client trước đó ghi và tạo lại manifest list cùng tệp metadata.
• Tốc độ của việc hoán đổi metadata: Dịch vụ thực hiện hoán đổi metadata phải xử lý cả retry, điều này làm giảm hiệu năng.
• Số lượng commit bị giới hạn: Do cách triển khai đồng thời đơn giản, số lượng commit bị giới hạn bởi thời gian thay thế nguyên tử của tệp metadata.

Sự cần thiết của cơ sở dữ liệu

• Tìm vị trí của tệp metadata: Snapshot của bảng Iceberg được mô tả đầy đủ bằng tệp metadata.json.
• Mâu thuẫn trong ý tưởng: Iceberg cố gắng chỉ định dạng metadata chỉ bằng tệp, nhưng cuối cùng vẫn cần đến cơ sở dữ liệu.
• Ưu điểm của cơ sở dữ liệu: Cơ sở dữ liệu hiện đại có thể xử lý hàng trăm nghìn lượt ghi và có thể mở rộng theo kiểu phân tán.
• So sánh giữa hệ thống tệp và cơ sở dữ liệu: Lưu metadata trong cơ sở dữ liệu hiệu quả hơn lưu trong tệp.

Phân mảnh và phình to metadata

• Sự tăng trưởng của tệp metadata.json: Tệp metadata.json trỏ tới snapshot mới nhất, và mỗi tệp metadata đều chứa con trỏ ngược đến snapshot trước đó.
• Metadata tăng liên tục: Metadata liên tục phình ra, tác động tiêu cực tới hiệu năng của data lake.
• Cần dọn dẹp metadata định kỳ: Nếu liên tục thêm dữ liệu vào data lake, cần phải dọn dẹp metadata.
• Chi phí request HTTP: Quá trình xóa các tệp metadata tạo ra các request HTTP, và điều này có thể phát sinh chi phí.

Đọc dữ liệu và lập kế hoạch truy vấn

• Vai trò của tệp manifest: Tệp manifest chứa metadata về các tệp Parquet.
• Độ phức tạp của lập kế hoạch truy vấn: Để thực thi truy vấn, cần đọc tuần tự manifest list và các tệp manifest.
• Vấn đề chi phí: Việc đọc từ S3 phát sinh chi phí, ảnh hưởng đến tốc độ thực thi truy vấn.
• Vấn đề phân mảnh metadata: Khi metadata bị phân mảnh, việc lập kế hoạch truy vấn trở nên phức tạp hơn và việc truy cập dữ liệu cũng khó khăn hơn.

Caching và khó khăn trong lập kế hoạch truy vấn

• Cache manifest: Có thể cache các manifest, nhưng điều đó kém hiệu quả vì kích thước metadata ngày càng lớn.
• Duy trì tính hợp lệ của cache: Cần kiểm tra xem cache có còn mới nhất hay không, điều này kéo theo chi phí và độ phức tạp bổ sung.
• Gánh nặng cho client: Mọi client đều phải cache metadata, dẫn đến hàng triệu request HTTP.
• Độ phức tạp gia tăng: Việc sử dụng data lake trở nên phức tạp hơn, và cần thêm các giải pháp khác để xử lý điều đó.

Kết luận về ý tưởng

• Phê phán ý tưởng: Đặc tả Iceberg không phải là một đặc tả nghiêm túc cho metadata của data lake và đang mang nhiều vấn đề.
• Tóm tắt các vấn đề: Iceberg thêm metadata bằng công việc O(n), không xử lý được commit liên bảng, và không giải quyết được vấn đề phình to metadata.
• Giới hạn về khả năng mở rộng: Iceberg không phù hợp để scale và đẩy quá nhiều độ phức tạp sang phía client.
• Câu hỏi cho ngành công nghiệp: Tác giả đặt câu hỏi vì sao những vấn đề như vậy lại xảy ra trong ngành IT.