Tháp Babel trong kiến trúc Lakehouse: Giải quyết xung đột định danh giữa các công cụ cơ sở dữ liệu

Tháp Babel trong kiến trúc Lakehouse: Giải quyết xung đột định danh giữa các công cụ cơ sở dữ liệu

Lời hứa của kiến trúc Lakehouse hiện đại là tạo ra một lớp dữ liệu thống nhất, nơi các công cụ tính toán đa dạng như Snowflake, Spark, Trino và Flink có thể tương tác liền mạch thông qua các tiêu chuẩn mở như Apache Iceberg. Mặc dù đã có tiến bộ đáng kể trong việc chuẩn hóa các định dạng lưu trữ dữ liệu và siêu dữ liệu, nhưng vẫn còn một khoảng trống lớn về khả năng tương tác: sự thiếu vắng một phương ngữ SQL chung giữa các công cụ cơ sở dữ liệu khác nhau.

Mỗi công cụ đều mang theo những quy tắc lịch sử riêng để phân giải và chuẩn hóa định danh (identifiers), tạo ra hiệu ứng "Tháp Babel" nơi mục tiêu xây dựng các hệ thống dữ liệu/AI được quản trị và thống nhất bị cản trở bởi sự bất đồng ngôn ngữ của các công cụ.

Khoảng cách tương thích của phương ngữ SQL trong Lakehouse

Các định dạng bảng mở như Apache Iceberg đã chuẩn hóa ngữ nghĩa dữ liệu và siêu dữ liệu trên các công cụ, nhưng chúng không cung cấp khả năng tương thích của phương ngữ SQL, để lại việc phân giải định danh phụ thuộc vào từng công cụ. Trong các Lakehouse đa công cụ, việc phân giải định danh đã trở thành một mối quan tâm về kiến trúc, nơi một bảng có thể tồn tại trong siêu dữ liệu chia sẻ nhưng thực tế lại vô hình đối với một số công cụ khác.

Để hiểu rõ vấn đề, hãy xem xét một kịch bản nơi kỹ sư dữ liệu tạo một bảng trong Spark:

CREATE TABLE my_lakehouse.MyTable (id INT, value STRING);
SELECT * from my_lakehouse.mytable; -- Trả về kết quả thành công

Theo mặc định, Spark lưu tên bảng chính xác như đã cung cấp: MyTable. Sau đó, một nhà phân tích kinh doanh cố gắng truy vấn bảng này từ Flink hoặc Trino:

-- Truy vấn này thất bại ở cả Flink và Trino vì các lý do khác nhau
SELECT * FROM my_lakehouse.mytable;

Flink giữ nguyên định danh chính xác như đã nhập, nên khi nhà phân tích viết mytable, Flink gửi mytable đến catalog, nơi bảng được lưu là MyTable. Nếu catalog thực hiện tìm kiếm phân biệt hoa/thường, bảng sẽ không được tìm thấy. Ngay cả khi bảng được giải quyết (ví dụ: thông qua catalog không phân biệt hoa/thường), quyền truy cập cấp cột vẫn phân biệt hoa/thường nghiêm ngặt.

Trino lại tạo ra một thách thức khác. Vì Trino chuẩn hóa định danh thành chữ thường, một truy vấn cho MyTable hoặc mytable sẽ trở thành tìm kiếm cho mytable (chữ thường). Nếu Spark đã lưu bảng là MyTable hoặc MYTABLE, việc tìm kiếm phân biệt hoa/thường của Trino sẽ không tìm thấy kết quả phù hợp.

Thiết lập Lakehouse đa công cụ minh họa các vấn đề về định danh

Tại sao vấn đề này lại quan trọng ngay bây giờ?

Thách thức này không mới mẻ trong lĩnh vực cơ sở dữ liệu, nhưng trong môi trường Lakehouse hiện đại, nhiều công cụ hoạt động trên cùng một dữ liệu đồng thời. Khi Spark coi Table1 và table1 là các đối tượng riêng biệt trong khi Trino coi chúng giống hệt nhau, các quy trình tự động hóa và quy trình làm việc đa công cụ có thể thất bại, gây ra hỏng dữ liệu nghiêm trọng hoặc vi phạm hợp đồng.

Việc quản lý khoảng trống tương thích này phần lớn là trách nhiệm của tổ chức xây dựng chiến lược Lakehouse của họ, chứ không phải được giải quyết bởi một catalog hoặc nền tảng cơ sở dữ liệu đơn lẻ.

Tổng quan kỹ thuật và Khảo sát hành vi

Phân giải tên định danh bao gồm một tập hợp các quy tắc quy định các ký tự nào có thể là một phần của định danh và cách định danh được chuẩn hóa. Trong một stack Lakehouse, nhiều thành phần được phát triển độc lập bởi các nhà cung cấp khác nhau tương tác với nhau để tạo ra hành vi định danh "hiệu quả".

Luồng phân giải định danh cấp cao

Dưới đây là sự khác biệt về hành vi giữa các công cụ cơ sở dữ liệu phổ biến:

• Spark: Giữ nguyên chữ hoa/thường (case-preserving). Phân biệt hoa/thường đối với các catalog chấp nhận mọi trường hợp (ví dụ: Apache Polaris). Không phân biệt đối với catalog chữ thường (ví dụ: Apache Hadoop, AWS Glue, Unity).
• Snowflake (CLD): Chuyển thành chữ thường. Không phân biệt hoa/thường khi giải quyết.
• Trino: Chuyển thành chữ thường. Không phân biệt hoa/thường, chỉ hỗ trợ dạng chữ thường.
• Flink: Giữ nguyên chữ hoa/thường. Phân biệt hoa/thường, chỉ khớp chính xác chữ cái.
• DuckDB: Giữ nguyên chữ hoa/thường. Không phân biệt hoa/thường khi giải quyết.

Ở cấp độ Catalog, các triển khai cũng khác nhau. Apache Polaris tuân theo đặc tả Apache Iceberg và thực hiện so khớp phân biệt hoa/thường. Databricks Unity Catalog chuẩn hóa định danh thành chữ thường. AWS Glue Data Catalog tự động chuyển đổi tên thực thể chữ hoa thành chữ thường.

Các tình huống thực tế

Hãy xem xét tác động của các lựa chọn này qua hai tình huống minh họa:

Tình huống A: NovaPay sử dụng Catalog giữ nguyên chữ hoa/thường (Polaris)

NovaPay sử dụng Apache Polaris, Spark cho ETL, Trino cho phân tích, và Flink cho phát hiện gian lận thời gian thực. Họ chọn hành vi giữ nguyên chữ hoa/thường của Polaris để duy trì quy ước camelCase.

Các pipeline Spark ban đầu hoạt động tốt, nhưng khi nhóm phân tích sử dụng Trino, họ không thể tìm thấy các bảng vì Trino chuyển tên bảng thành chữ thường trong khi Polaris lưu tên có chữ hoa. Nhóm Flink cũng gặp lỗi ở cấp cột do Flink yêu cầu khớp chính xác chữ cái. Giải pháp: NovaPay phải di chuyển tất cả bảng sang snake_case (chữ thường và gạch dưới).

Tình huống B: MediStream sử dụng Catalog chuẩn hóa chữ thường (AWS Glue)

MediStream sử dụng AWS Glue, Spark trên EMR và Athena (dựa trên Trino). Họ mong đợi việc chuẩn hóa chữ thường của Glue sẽ ngăn chặn các vấn đề về chữ cái.

Tuy nhiên, Glue đã từ chối các tên bảng PascalCase ngay lập tức. Đội ngũ đã phải dành hai tuần để viết lại hơn 80 bảng và script ETL sang snake_case. Ngay cả sau khi chuẩn hóa tên bảng, các vấn đề ở cấp cột vẫn tồn tại vì tên cột sống trong siêu dữ liệu Iceberg và vẫn giữ nguyên chữ hoa/thường ban đầu. Athena xử lý vấn đề này minh bạch, nhưng Flink yêu cầu chữ cái chính xác, gây ra lỗi.

Giải pháp: Thiết lập tiêu chuẩn và cấu hình

Để tránh các vấn đề về phát hiện và chữ cái trong stack dữ liệu, điều quan trọng là phải chuẩn hóa và thực thi một tiêu chuẩn đặt tên hoạt động tốt cho tất cả các công cụ. Chiến lược hiệu quả nhất là giới hạn tất cả định danh sử dụng chữ thường với dấu gạch dưới.

Ngoài ra, việc cấu hình các tùy chọn trong stack Lakehouse cũng giúp giảm ma sát:

• Spark: Cấu hình spark.sql.caseSensitive thành false để kiểm soát cách Spark xử lý chữ cái cho các cột bảng.
• Trino: Cấu hình iceberg.rest-catalog.case-insensitive-name-matching thành true khi kết nối với REST catalog có tên hỗn hợp chữ hoa/thường.
• Glue: Cấu hình glue.skip-name-validation cần được cân nhắc cẩn thận, vì việc bỏ qua xác thực phía khách hàng vẫn dẫn đến việc Glue chuyển thành chữ thường phía máy chủ.

Kết luận

Lời hứa của Lakehouse về việc mang bất kỳ công cụ nào đến một bản sao dữ liệu duy nhất vẫn là kim chỉ nam cho kiến trúc dữ liệu, nhưng các ví dụ đã chứng minh rằng lưu trữ chia sẻ và catalog thống nhất là chưa đủ. Vấn đề bắt nguồn từ sự khác biệt triết lý giữa việc giữ nguyên độ trung thực của chữ cái và sự thống nhất khi chuẩn hóa.

Các tổ chức phải ngừng coi việc đặt tên định danh là sở thích của từng công cụ riêng lẻ và bắt đầu coi đó là một hợp đồng dữ liệu quan trọng. Bằng cách thiết lập một quy ước chữ cái nghiêm ngặt trên phạm vi toàn tổ chức, các nhóm có thể giảm thiểu ma sát bất kể công cụ hoặc catalog hoạt động như thế nào. Giải quyết vấn đề "Tháp Babel" đòi hỏi sự thay đổi tư duy: Khả năng tương tác thực sự đạt được không chỉ bằng cách chia sẻ các byte trên đĩa, mà bằng việc thực thi một ngôn ngữ chung trên mọi công cụ chạm đến chúng.