Dự đoán về sự ra mắt của một dòng chảy mới với tốc độ Chúng tôi đã chuẩn bị một bản dịch tài liệu thú vị.
Xem xét
Chúng ta sẽ nói về một mô hình khá phổ biến trong đó các ứng dụng sử dụng nhiều kho dữ liệu, trong đó mỗi kho được sử dụng cho các mục đích riêng, chẳng hạn như để lưu trữ dạng dữ liệu chuẩn (MySQL, v.v.), cung cấp khả năng tìm kiếm nâng cao (ElasticSearch, v.v.) .), bộ nhớ đệm (Memcached, v.v.) và những thứ khác. Thông thường, khi sử dụng nhiều kho dữ liệu, một trong số chúng đóng vai trò là kho lưu trữ chính và kho còn lại đóng vai trò là kho lưu trữ phái sinh. Vấn đề duy nhất là làm thế nào để đồng bộ hóa các kho dữ liệu này.
Chúng tôi đã xem xét một số mẫu khác nhau nhằm cố gắng giải quyết vấn đề đồng bộ hóa nhiều cửa hàng, chẳng hạn như ghi kép, giao dịch phân tán, v.v. Tuy nhiên, những phương pháp này có những hạn chế đáng kể về mặt sử dụng, độ tin cậy và bảo trì trong đời thực. Ngoài việc đồng bộ hóa dữ liệu, một số ứng dụng còn cần làm phong phú dữ liệu bằng cách gọi các dịch vụ bên ngoài.
Delta được phát triển để giải quyết những vấn đề này. Cuối cùng, Delta cung cấp một nền tảng nhất quán, hướng đến sự kiện để đồng bộ hóa và làm phong phú dữ liệu.
Các giải pháp hiện có
mục nhập kép
Để giữ cho hai kho dữ liệu được đồng bộ hóa, bạn có thể sử dụng tính năng ghi kép, ghi vào một kho rồi ghi vào kho kia ngay sau đó. Bản ghi đầu tiên có thể được thử lại và bản ghi thứ hai có thể bị hủy nếu lần đầu tiên không thành công sau khi đã hết số lần thử. Tuy nhiên, hai kho dữ liệu có thể không đồng bộ nếu việc ghi vào kho thứ hai không thành công. Sự cố này thường được giải quyết bằng cách tạo quy trình khôi phục có thể truyền lại dữ liệu theo định kỳ từ bộ lưu trữ đầu tiên sang bộ lưu trữ thứ hai hoặc chỉ làm như vậy nếu phát hiện thấy sự khác biệt trong dữ liệu.
Các vấn đề:
Thực hiện quy trình khôi phục là một công việc cụ thể không thể sử dụng lại. Ngoài ra, dữ liệu giữa các vị trí lưu trữ vẫn không đồng bộ cho đến khi quá trình khôi phục diễn ra. Giải pháp trở nên phức tạp hơn nếu sử dụng nhiều hơn hai kho dữ liệu. Cuối cùng, quy trình khôi phục có thể thêm tải vào nguồn dữ liệu gốc.
Thay đổi bảng nhật ký
Khi các thay đổi xảy ra với một tập hợp bảng (chẳng hạn như chèn, cập nhật và xóa bản ghi), các bản ghi thay đổi sẽ được thêm vào bảng nhật ký như một phần của cùng một giao dịch. Một luồng hoặc quy trình khác liên tục yêu cầu các sự kiện từ bảng nhật ký và ghi chúng vào một hoặc nhiều kho dữ liệu, nếu cần, xóa các sự kiện khỏi bảng nhật ký sau khi bản ghi đã được tất cả các cửa hàng xác nhận.
Các vấn đề:
Mẫu này phải được triển khai dưới dạng thư viện và lý tưởng nhất là không thay đổi mã của ứng dụng sử dụng nó. Trong môi trường đa ngôn ngữ, việc triển khai thư viện như vậy phải tồn tại bằng bất kỳ ngôn ngữ cần thiết nào, nhưng việc đảm bảo tính nhất quán về chức năng và hành vi giữa các ngôn ngữ là rất khó.
Một vấn đề khác nằm ở việc thu thập các thay đổi lược đồ trong các hệ thống không hỗ trợ thay đổi lược đồ giao dịch [1] [2], chẳng hạn như MySQL. Do đó, kiểu thực hiện thay đổi (ví dụ: thay đổi lược đồ) và ghi lại nó theo giao dịch vào bảng nhật ký thay đổi sẽ không phải lúc nào cũng hiệu quả.
Giao dịch phân phối
Các giao dịch phân tán có thể được sử dụng để phân chia một giao dịch thành nhiều kho dữ liệu không đồng nhất để hoạt động được cam kết với tất cả các kho dữ liệu được sử dụng hoặc không được cam kết với bất kỳ kho dữ liệu nào trong số đó.
Các vấn đề:
Giao dịch phân tán là một vấn đề rất lớn đối với các kho dữ liệu không đồng nhất. Về bản chất, chúng chỉ có thể dựa vào mẫu số chung thấp nhất của các hệ thống liên quan. Ví dụ: các giao dịch XA sẽ chặn việc thực thi nếu quá trình ứng dụng không thành công trong giai đoạn chuẩn bị. Ngoài ra, XA không cung cấp khả năng phát hiện bế tắc hoặc hỗ trợ các sơ đồ kiểm soát đồng thời lạc quan. Ngoài ra, một số hệ thống như ElasticSearch không hỗ trợ XA hoặc bất kỳ mô hình giao dịch không đồng nhất nào khác. Vì vậy, việc đảm bảo tính nguyên tử ghi trong các công nghệ lưu trữ dữ liệu khác nhau vẫn là một nhiệm vụ rất khó khăn đối với các ứng dụng [3].
đồng bằng
Delta được thiết kế để giải quyết những hạn chế của các giải pháp đồng bộ hóa dữ liệu hiện có và cũng cho phép làm phong phú dữ liệu một cách nhanh chóng. Mục tiêu của chúng tôi là loại bỏ tất cả những vấn đề phức tạp này khỏi các nhà phát triển ứng dụng để họ có thể tập trung hoàn toàn vào việc triển khai chức năng kinh doanh. Tiếp theo, chúng tôi sẽ mô tả "Tìm kiếm phim", trường hợp sử dụng thực tế cho Delta của Netflix.
Netflix sử dụng rộng rãi kiến trúc vi dịch vụ và mỗi vi dịch vụ thường phục vụ một loại dữ liệu. Thông tin cơ bản về phim được chứa trong một vi dịch vụ có tên là Dịch vụ phim và dữ liệu liên quan như thông tin về nhà sản xuất, diễn viên, nhà cung cấp, v.v. được quản lý bởi một số vi dịch vụ khác (cụ thể là Dịch vụ giao dịch, Dịch vụ nhân tài và Dịch vụ nhà cung cấp).
Người dùng doanh nghiệp tại Netflix Studios thường cần tìm kiếm theo nhiều tiêu chí phim khác nhau, đó là lý do tại sao việc họ có thể tìm kiếm trên tất cả dữ liệu liên quan đến phim là rất quan trọng.
Trước Delta, nhóm tìm kiếm phim cần lấy dữ liệu từ nhiều vi dịch vụ trước khi lập chỉ mục dữ liệu phim. Ngoài ra, nhóm phải phát triển một hệ thống cập nhật định kỳ chỉ mục tìm kiếm bằng cách yêu cầu thay đổi từ các vi dịch vụ khác, ngay cả khi không có thay đổi nào cả. Hệ thống này nhanh chóng trở nên phức tạp và khó bảo trì.
Hình 1. Hệ thống bỏ phiếu tới Delta
Sau khi sử dụng Delta, hệ thống đã được đơn giản hóa thành hệ thống điều khiển sự kiện như minh họa trong hình dưới đây. Các sự kiện CDC (Change-Data-Capture) được gửi đến các chủ đề Keystone Kafka bằng Delta-Connector. Một ứng dụng Delta được xây dựng bằng Khung xử lý dòng Delta (dựa trên Flink) nhận các sự kiện CDC từ một chủ đề, làm phong phú thêm chúng bằng cách gọi các dịch vụ vi mô khác và cuối cùng chuyển dữ liệu đã được làm giàu đến chỉ mục tìm kiếm trong Elaticsearch. Toàn bộ quá trình diễn ra gần như theo thời gian thực, tức là ngay khi có thay đổi đối với kho dữ liệu, các chỉ mục tìm kiếm sẽ được cập nhật.
Hình 2. Đường dẫn dữ liệu sử dụng Delta
Trong các phần sau, chúng tôi sẽ mô tả hoạt động của Delta-Connector, kết nối với bộ lưu trữ và xuất bản các sự kiện CDC lên lớp vận chuyển, đây là cơ sở hạ tầng truyền dữ liệu theo thời gian thực định tuyến các sự kiện CDC đến các chủ đề Kafka. Và ở phần cuối, chúng ta sẽ nói về khung xử lý luồng Delta mà các nhà phát triển ứng dụng có thể sử dụng để xử lý dữ liệu và làm giàu logic.
CDC (Thay đổi-Thu thập dữ liệu)
Chúng tôi đã phát triển dịch vụ CDC có tên Delta-Connector, dịch vụ này có thể ghi lại những thay đổi đã cam kết từ kho lưu trữ dữ liệu trong thời gian thực và ghi chúng vào luồng. Các thay đổi theo thời gian thực được lấy từ nhật ký giao dịch và kho lưu trữ. Các kết xuất được sử dụng vì nhật ký giao dịch thường không lưu trữ toàn bộ lịch sử thay đổi. Các thay đổi thường được tuần tự hóa dưới dạng sự kiện Delta, do đó người nhận không phải lo lắng về việc thay đổi đến từ đâu.
Delta-Connector hỗ trợ một số tính năng bổ sung như:
- Khả năng ghi dữ liệu đầu ra tùy chỉnh qua Kafka.
- Khả năng kích hoạt kết xuất thủ công bất kỳ lúc nào cho tất cả các bảng, một bảng cụ thể hoặc cho các khóa chính cụ thể.
- Các bãi chứa có thể được truy xuất theo từng khối, do đó không cần phải bắt đầu lại từ đầu trong trường hợp thất bại.
- Không cần phải đặt khóa trên bảng, điều này rất quan trọng để đảm bảo rằng lưu lượng ghi cơ sở dữ liệu không bao giờ bị dịch vụ của chúng tôi chặn.
- Tính sẵn sàng cao nhờ có các phiên bản dư thừa trong Vùng sẵn sàng AWS.
Chúng tôi hiện hỗ trợ MySQL và Postgres, bao gồm cả việc triển khai trên AWS RDS và Aurora. Chúng tôi cũng hỗ trợ Cassandra (đa chủ). Bạn có thể tìm hiểu thêm chi tiết về Delta-Connector tại đây .
Kafka và lớp vận chuyển
Lớp truyền tải sự kiện của Delta được xây dựng trên dịch vụ nhắn tin của nền tảng .
Trong lịch sử, việc đăng bài trên Netflix đã được tối ưu hóa về khả năng truy cập hơn là thời gian sử dụng (xem bên dưới). ). Sự đánh đổi là dữ liệu của nhà môi giới có thể không nhất quán trong các tình huống khác nhau. Ví dụ, bầu cử lãnh đạo ô uế chịu trách nhiệm về việc người nhận có khả năng gặp phải các sự kiện trùng lặp hoặc bị mất.
Với Delta, chúng tôi muốn đảm bảo độ bền cao hơn để đảm bảo phân phối các sự kiện CDC đến các cửa hàng xuất phát. Với mục đích này, chúng tôi đã đề xuất một cụm Kafka được thiết kế đặc biệt làm đối tượng hạng nhất. Bạn có thể xem một số cài đặt môi giới trong bảng dưới đây:
Trong cụm Keystone Kafka, bầu cử lãnh đạo ô uế thường được bao gồm để đảm bảo khả năng tiếp cận của nhà xuất bản. Điều này có thể dẫn đến mất tin nhắn nếu một bản sao không đồng bộ được bầu làm người đứng đầu. Đối với cụm Kafka có tính sẵn sàng cao mới, tùy chọn bầu cử lãnh đạo ô uế tắt để tránh mất tin nhắn.
Chúng tôi cũng tăng yếu tố nhân rộng từ 2 đến 3 và bản sao không đồng bộ tối thiểu 1 đến 2. Các nhà xuất bản viết vào cụm này yêu cầu tất cả những người khác xác nhận, đảm bảo rằng 2 trong số 3 bản sao có các thông báo mới nhất do nhà xuất bản gửi.
Khi một phiên bản môi giới chấm dứt, một phiên bản mới sẽ thay thế phiên bản cũ. Tuy nhiên, nhà môi giới mới sẽ cần phải xử lý các bản sao chưa được đồng bộ hóa, quá trình này có thể mất vài giờ. Để giảm thời gian khôi phục cho trường hợp này, chúng tôi đã bắt đầu sử dụng bộ lưu trữ dữ liệu khối (Amazon Elastic Block Store) thay vì đĩa môi giới cục bộ. Khi một phiên bản mới thay thế một phiên bản môi giới đã chấm dứt, nó sẽ đính kèm ổ đĩa EBS mà phiên bản đã chấm dứt có và bắt đầu bắt kịp các tin nhắn mới. Quá trình này giúp giảm thời gian giải quyết tồn đọng từ vài giờ xuống còn vài phút vì phiên bản mới không còn cần phải sao chép từ trạng thái trống nữa. Nhìn chung, vòng đời lưu trữ và môi giới riêng biệt làm giảm đáng kể tác động của việc chuyển đổi nhà môi giới.
Để tăng cường hơn nữa việc đảm bảo cung cấp dữ liệu, chúng tôi đã sử dụng để phát hiện bất kỳ sự mất mát tin nhắn nào trong các điều kiện khắc nghiệt (ví dụ: giải đồng bộ hóa đồng hồ trong trình lãnh đạo phân vùng).
Khung xử lý luồng
Lớp xử lý của Delta được xây dựng trên nền tảng Netflix SPaaS, nền tảng này cung cấp khả năng tích hợp Apache Flink với hệ sinh thái Netflix. Nền tảng này cung cấp giao diện người dùng quản lý việc triển khai các công việc Flink và điều phối các cụm Flink trên nền tảng quản lý vùng chứa Titus của chúng tôi. Giao diện cũng quản lý cấu hình công việc và cho phép người dùng thực hiện các thay đổi cấu hình một cách linh hoạt mà không cần phải biên dịch lại các công việc Flink.
Delta cung cấp khung xử lý luồng dựa trên Flink và SPaaS sử dụng dựa trên chú thích DSL (Ngôn ngữ cụ thể của miền) đến các chi tiết kỹ thuật trừu tượng. Ví dụ: để xác định bước mà các sự kiện sẽ được bổ sung bằng cách gọi các dịch vụ bên ngoài, người dùng cần viết DSL sau và khung sẽ tạo một mô hình dựa trên nó, mô hình này sẽ được Flink thực thi.
Hình 3. Ví dụ về làm giàu trên DSL ở Delta
Khung xử lý không chỉ làm giảm thời gian học tập mà còn cung cấp các tính năng xử lý luồng phổ biến như chống trùng lặp, sơ đồ hóa cũng như tính linh hoạt và khả năng phục hồi để giải quyết các vấn đề vận hành phổ biến.
Khung xử lý dòng Delta bao gồm hai mô-đun chính, mô-đun DSL & API và mô-đun Thời gian chạy. Mô-đun DSL & API cung cấp API DSL và UDF (Chức năng do người dùng xác định) để người dùng có thể viết logic xử lý của riêng họ (chẳng hạn như lọc hoặc chuyển đổi). Mô-đun Runtime cung cấp cách triển khai trình phân tích cú pháp DSL để xây dựng bản trình bày nội bộ về các bước xử lý trong mô hình DAG. Thành phần Thực thi diễn giải các mô hình DAG để khởi tạo các câu lệnh Flink thực tế và cuối cùng chạy ứng dụng Flink. Kiến trúc của khung được minh họa trong hình dưới đây.
Hình 4. Kiến trúc khung xử lý dòng Delta
Cách tiếp cận này có một số ưu điểm:
- Người dùng có thể tập trung vào logic kinh doanh của mình mà không cần phải đi sâu vào chi tiết cụ thể về cấu trúc Flink hoặc SPaaS.
- Việc tối ưu hóa có thể được thực hiện theo cách minh bạch đối với người dùng và có thể sửa lỗi mà không yêu cầu bất kỳ thay đổi nào đối với mã người dùng (UDF).
- Trải nghiệm ứng dụng Delta được đơn giản hóa cho người dùng vì nền tảng này cung cấp tính linh hoạt và khả năng phục hồi vượt trội, đồng thời thu thập nhiều số liệu chi tiết có thể được sử dụng để cảnh báo.
Sử dụng sản xuất
Delta đã được sản xuất hơn một năm và đóng vai trò quan trọng trong nhiều ứng dụng Netflix Studio. Cô đã giúp các nhóm triển khai các trường hợp sử dụng như lập chỉ mục tìm kiếm, lưu trữ dữ liệu và quy trình làm việc theo sự kiện. Dưới đây là tổng quan về kiến trúc cấp cao của nền tảng Delta.
Hình 5. Kiến trúc cấp cao của Delta.
Sự nhìn nhận
Chúng tôi xin cảm ơn những người sau đã tham gia vào quá trình tạo dựng và phát triển Delta tại Netflix: Allen Wang, Charles Zhao, Jaebin Yoon, Josh Snyder, Kasturi Chatterjee, Mark Cho, Olof Johansson, Piyush Goyal, Prashanth Ramdas, Raghuram Onti Srinivasan, Sandeep Gupta, Steven Wu, Tharanga Gamaethige, Yun Wang và Zhenzhong Xu.
nguồn
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Xử lý sự kiện trực tuyến. Cộng đồng. ACM 62(5): 43–49 (2019). DOI:
: “Công cụ xây dựng dữ liệu cho bộ lưu trữ Amazon Redshift.”
Nguồn: www.habr.com