Cách quản lý thay đổi lược đồ với Apache Pulsar

Các lược đồ là một phần thiết yếu của bất kỳ nền tảng dữ liệu nào. Chúng là siêu dữ liệu xác định hình dạng của dữ liệu, tên và kiểu dữ liệu của thuộc tính. Các lược đồ hữu ích theo hai cách. Đầu tiên, chúng cung cấp một kế hoạch chi tiết cố định cho định dạng dữ liệu, điều này có thể ngăn không cho dữ liệu có định dạng xấu được sử dụng trong ngữ cảnh của lược đồ. Thứ hai, các lược đồ cho phép người dùng hiểu cách phân tích cú pháp dữ liệu và những gì mong đợi từ các thuộc tính của nó.

Apache Pulsar là một hệ thống nhắn tin xuất bản-đăng ký phân tán (pub-sub) mã nguồn mở, cho phép vận chuyển dữ liệu từ máy chủ đến máy chủ sử dụng lược đồ . Tin nhắn được gửi qua các chủ đề, với việc nhà sản xuất đưa tin nhắn vào các chủ đề này để người tiêu dùng đọc. Người dùng có thể xác định lược đồ cho một chủ đề được lưu trữ trong sổ đăng ký lược đồ của Pulsar. Khi tin nhắn được thêm vào chủ đề, nhà môi giới Pulsar sẽ kiểm tra xem tin nhắn có phù hợp với lược đồ hay không và đảm bảo chỉ những tin nhắn hợp lệ mới được gửi. Lược đồ hoạt động như một hợp đồng giữa nhà sản xuất và người tiêu dùng, cho phép cả hai bên biết định dạng chính xác của dữ liệu.

Theo thời gian, khi các ứng dụng phát triển, có thể dữ liệu do ứng dụng tạo ra cũng thay đổi. Tuy nhiên, các thay đổi lược đồ có thể ảnh hưởng đến người tiêu dùng hạ lưu dữ liệu mong đợi dữ liệu ở định dạng cụ thể. Không có cách quản lý lược đồ giữa nhà sản xuất và người tiêu dùng, thật khó để thực hiện các thay đổi đối với dữ liệu được ghi trong thông báo hoặc sự kiện mà không gặp rủi ro làm hỏng các ứng dụng xuôi dòng. Để tránh loại sự cố này, lược đồ của thông báo cũng phải phát triển khi các thuộc tính mới được thêm vào và cho phép người tiêu dùng hiểu dữ liệu ở cả định dạng cũ và mới. Khái niệm này được gọi là lược đồ tiến hóa và Pulsar hỗ trợ nó.

Bài viết này thảo luận về lý do tại sao lược đồ phát triển trước khi đi sâu vào cách Pulsar triển khai và hỗ trợ quá trình phát triển lược đồ.

Tại sao lược đồ phát triển

Các lược đồ cung cấp ngữ cảnh về dữ liệu thô. Chúng thường mô tả một thực thể cụ thể trong một hệ thống, bao gồm tất cả các thuộc tính của thực thể đó. Ví dụ: bạn có thể có một ứng dụng đăng ký người dùng. Nó lưu trữ các chi tiết người dùng như tên, địa chỉ email và tuổi. Sẽ có một lược đồ người dùng mô tả dữ liệu cơ bản và cung cấp ngữ cảnh, chẳng hạn như tên của trường và loại dữ liệu trong đó. Lược đồ có thể trông như sau:

Bây giờ, giả sử bạn muốn mở rộng dữ liệu đã thu thập để bao gồm dữ liệu địa chỉ và hỗ trợ gửi thư trực tiếp tới người dùng. Sau đó, bạn sẽ cần mở rộng lược đồ để bao gồm các trường mới để thu thập địa chỉ, chẳng hạn như dòng đầu tiên của địa chỉ, thành phố và mã ZIP. Sau khi bao gồm các trường mới này, lược đồ sẽ trông như thế này:

Đây là một dạng tiến hóa giản đồ đơn giản, vì các trường ban đầu không thay đổi và chỉ các trường mới được thêm vào. Trong hầu hết các trường hợp, đây không phải là một thay đổi đột phá đối với người tiêu dùng cuối nguồn, vì người tiêu dùng có thể tiếp tục như thể không có trường mới. Người tiêu dùng sẽ chỉ cần được cập nhật để sử dụng và sử dụng các thuộc tính mới.

Tuy nhiên, đôi khi các trường hiện có cần được sửa đổi để hỗ trợ chức năng mới. Ví dụ: giả sử rằng người dùng không thoải mái khi đưa ra độ tuổi chính xác và thay vào đó, bạn thay đổi ứng dụng để nắm bắt các độ tuổi như 18-24, 25-39,40-49 và 60+. Cột tuổi sẽ cần sửa kiểu dữ liệu của nó từ số nguyên thành chuỗi.

Đây là một sự phát triển lược đồ phức tạp hơn, vì điều này có thể phá vỡ những người tiêu dùng cuối nguồn đang xử lý thuộc tính tuổi và mong đợi nó là một số hoặc phân tích cú pháp số bằng ngôn ngữ được nhập nghiêm ngặt như Java. Họ cũng có thể thực hiện các phép tính số trên thuộc tính, tính năng này sẽ không còn hoạt động ở định dạng mới.

Để vượt qua thách thức này, các nền tảng dữ liệu có thể hỗ trợ quá trình phát triển lược đồ để xử lý các tình huống như thế này. Pulsar nhận ra tầm quan trọng của lược đồ đối với việc xử lý dữ liệu; trên thực tế, nó coi nó như một công dân hạng nhất bằng cách bao gồm hỗ trợ tiến hóa lược đồ tích hợp sẵn. Hãy xem Pulsar làm điều này như thế nào.

Pulsar hỗ trợ Schema Evolution như thế nào

Pulsar định nghĩa các lược đồ trong một cấu trúc dữ liệu có tên là `SchemaInfo`. Đây là cấu trúc dữ liệu dành riêng cho Pulsar, bản thân nó là một lược đồ, mô tả lược đồ của các thông báo được vận chuyển qua Pulsar. Mỗi `SchemaInfo` thuộc về một chủ đề (kênh thông báo) và mô tả các thông báo sẽ được tạo và sử dụng bằng cách sử dụng chủ đề đó.

Mỗi `SchemaInfo` có một loại mô tả chi tiết loại lược đồ đang được sử dụng. Đây có thể là bất kỳ thứ gì từ một số nguyên, một chuỗi hoặc một lược đồ phức tạp như Avro hoặc Protobuf.

Hỗ trợ lược đồ tiến hóa , Pulsar sử dụng kiểm tra tính tương thích của lược đồ để so sánh lược đồ đến với (các) lược đồ đã biết của chủ đề. Kiểm tra khả năng tương thích lược đồ diễn ra khi nhà sản xuất hoặc người tiêu dùng cố gắng kết nối với một chủ đề cụ thể. Chiến lược được chọn trong khi định cấu hình trình môi giới, với giá trị `schemaCompatibilityStrategy`. Mục tiêu là kiểm tra `SchemaInfo` được cung cấp bởi máy khách đang kết nối với `SchemaInfo` hiện có để xem chúng có tương thích hay không.

Pulsar hỗ trợ tám loại khác nhau của lược đồ tương thích chiến lược , mà bạn có thể đặt dựa trên các yêu cầu của thay đổi. Các chiến lược này cũng đi kèm với các quy tắc nêu rõ những thay đổi nào có thể được thực hiện và gợi ý xung quanh ứng dụng khách nào sẽ cập nhật trước. (Xem tài liệu được liên kết ở trên để được giải thích sâu hơn về từng chiến lược tương thích).

Quay trở lại các ví dụ trước đó, hãy triển khai các thay đổi lược đồ bằng cách sử dụng chiến lược tương thích của Pulsar. Đầu tiên, hãy bắt đầu với lược đồ người dùng ban đầu (không có địa chỉ).

Đây sẽ là V1 của lược đồ của bạn. Vì vậy, khi bạn triển khai nhà sản xuất hoặc người tiêu dùng Pulsar lần đầu tiên, `SchemaInfo` cho phiên bản này sẽ được lưu trữ và nhà sản xuất cũng như người tiêu dùng sẽ hoạt động như mong đợi.

Tiếp theo, bạn muốn thêm các trường địa chỉ mới vào lược đồ người dùng của mình. Bước đầu tiên là tham khảo các chiến lược tương thích lược đồ và xác định chiến lược nào là tốt nhất cho thay đổi này. Bằng cách sử dụng cột "được phép thay đổi" trong tài liệu, bạn đang tìm kiếm bất kỳ chiến lược nào cho phép bổ sung các trường mới. Điều này mang lại cho bạn BACKWARD, BACKWARD_TRANSITIVE, FORWARD và FORWARD_TRANSITIVE.

BACKWARD nên được sử dụng khi không có gì đảm bảo rằng người tiêu dùng sử dụng phiên bản cũ hơn có thể hiểu lược đồ mới. FORWARD được sử dụng khi người tiêu dùng trên phiên bản lược đồ mới nhất có thể không đọc được dữ liệu trong các phiên bản cũ hơn. Nếu bạn muốn cập nhật tất cả người tiêu dùng trước tiên để sử dụng lược đồ mới, hãy sử dụng chiến lược LẠI. Nếu không, FORWARD là tốt nhất.

Nhìn vào bức tranh toàn cảnh hơn, Pulsar đề cập đến toàn bộ hành động phát triển lược đồ của một chủ đề như xác minh lược đồ . Đó là sự kết hợp giữa nhà sản xuất hoặc người tiêu dùng cung cấp `SchemaInfo`, chiến lược tương thích đã chọn cho chủ đề và nhà môi giới quyết định phải làm gì.

Phần kết luận

Rất hiếm khi các lược đồ giữ nguyên như cũ mãi mãi. Khi các tính năng mới được đưa vào ứng dụng, các lược đồ thường phải phát triển để hỗ trợ các tính năng này. Tuy nhiên, việc giữ cho nhà sản xuất và người tiêu dùng của dữ liệu đồng bộ hóa thường có thể là một thách thức khi các lược đồ được sửa đổi.

Các khái niệm tiến hóa lược đồ tích hợp sẵn của Pulsar giúp đối phó với những thay đổi này. Sử dụng các chiến lược tương thích lược đồ, nó có thể xác định các quy tắc về mức độ tương thích của các phiên bản lược đồ khác nhau. Pulsar sử dụng điều này cùng với quy trình xác minh lược đồ, sau đó sử dụng các quy tắc này để xác định người tiêu dùng có thể sử dụng lược đồ nào khi kết nối với một chủ đề cụ thể.

Cũng được xuất bản ở đây.