Trong chúng tôi đã giới thiệu các trường hợp sử dụng Presto của Uber và cách chúng tôi hợp tác triển khai bộ đệm cục bộ Alluxio để vượt qua những thách thức khác nhau trong việc tăng tốc các truy vấn Presto. Phần thứ hai thảo luận về những cải tiến đối với siêu dữ liệu bộ đệm cục bộ. blog trước, Siêu dữ liệu cấp tệp cho bộ nhớ cache cục bộ Động lực Đầu tiên, chúng tôi muốn ngăn chặn bộ nhớ đệm cũ. Các tệp dữ liệu cơ bản có thể bị thay đổi bởi các khuôn khổ của bên thứ ba. Lưu ý rằng trường hợp này có thể hiếm trong bảng Hive nhưng rất phổ biến trong bảng Hudi. Thứ hai, số lần đọc dữ liệu không trùng lặp hàng ngày từ HDFS có thể lớn, nhưng chúng tôi không có đủ dung lượng bộ nhớ đệm để lưu vào bộ nhớ đệm tất cả dữ liệu. Do đó, chúng tôi có thể giới thiệu quản lý hạn ngạch theo phạm vi bằng cách đặt hạn ngạch cho mỗi bảng. Thứ ba, siêu dữ liệu phải có thể khôi phục được sau khi máy chủ khởi động lại. Chúng tôi đã lưu trữ siêu dữ liệu trong bộ đệm ẩn cục bộ trong bộ nhớ thay vì đĩa, điều này khiến không thể khôi phục siêu dữ liệu khi máy chủ gặp sự cố và khởi động lại. Phương pháp tiếp cận cấp cao Do đó, chúng tôi đề xuất Siêu dữ liệu cấp độ tệp, lưu giữ và giữ lại thời gian sửa đổi lần cuối và phạm vi của mỗi tệp dữ liệu mà chúng tôi đã lưu vào bộ nhớ cache. Kho lưu trữ siêu dữ liệu cấp độ tệp phải được duy trì liên tục trên đĩa để dữ liệu sẽ không biến mất sau khi khởi động lại. Với sự ra đời của siêu dữ liệu cấp tệp, sẽ có nhiều phiên bản dữ liệu. Dấu thời gian mới được tạo khi dữ liệu được cập nhật, tương ứng với phiên bản mới. Một thư mục mới lưu trữ trang mới được tạo tương ứng với dấu thời gian mới này. Đồng thời, chúng tôi sẽ cố gắng xóa dấu thời gian cũ. Dữ liệu bộ nhớ đệm và cấu trúc siêu dữ liệu Như hình trên, chúng ta có hai thư mục tương ứng với hai dấu thời gian: timestamp1 và timestamp2. Thông thường, khi hệ thống đang chạy, sẽ không có hai dấu thời gian đồng thời vì chúng ta sẽ xóa dấu thời gian cũ1 và chỉ giữ lại dấu thời gian2. Tuy nhiên, trong trường hợp máy chủ bận hoặc đồng thời cao, chúng tôi có thể không xóa dấu thời gian đúng lúc, trong trường hợp đó, chúng tôi có thể có hai dấu thời gian cùng một lúc. Ngoài ra, chúng tôi duy trì một tệp siêu dữ liệu chứa thông tin tệp ở định dạng protobuf và dấu thời gian mới nhất. Điều này đảm bảo rằng bộ nhớ cache cục bộ của Alluxio chỉ đọc dữ liệu từ dấu thời gian mới nhất. Khi máy chủ khởi động lại, thông tin dấu thời gian được đọc từ tệp siêu dữ liệu để có thể quản lý chính xác hạn ngạch và thời gian sửa đổi lần cuối. Nhận thức về siêu dữ liệu Bối cảnh bộ nhớ cache Vì Alluxio là một giải pháp bộ nhớ đệm chung, nó vẫn cần công cụ tính toán, như Presto, để chuyển siêu dữ liệu cho Alluxio. Do đó, trên trang Presto, chúng tôi sử dụng HiveFileContext. Đối với mỗi tệp dữ liệu từ bảng Hive hoặc bảng Hudi, Presto tạo một HiveFileContext. Alluxio sử dụng thông tin này khi mở tệp Presto. Khi gọi openFile, Alluxio tạo một phiên bản mới của PrestoCacheContext, chứa HiveFileContext và có phạm vi (bốn cấp: cơ sở dữ liệu, lược đồ, bảng, phân vùng), hạn ngạch, định danh bộ nhớ cache (tức là giá trị md5 của đường dẫn tệp) và thông tin khác. Chúng tôi sẽ chuyển ngữ cảnh bộ nhớ cache này vào hệ thống tệp cục bộ. Do đó, Alluxio có thể quản lý siêu dữ liệu và thu thập các chỉ số. Tổng hợp số liệu trên mỗi truy vấn ở phía trước Ngoài việc chuyển dữ liệu từ Presto sang Alluxio, chúng tôi cũng có thể gọi lại Presto. Khi thực hiện các thao tác truy vấn, chúng ta sẽ biết một số chỉ số nội bộ, chẳng hạn như bao nhiêu byte dữ liệu được đọc vào bộ nhớ đệm và bao nhiêu byte dữ liệu được đọc từ bộ nhớ HDFS bên ngoài. Như hình dưới đây, chúng tôi truyền HiveFileContext chứa PrestoCacheContext vào hệ thống tệp bộ đệm cục bộ (LocalCacheFileSystem), sau đó hệ thống tệp bộ đệm cục bộ gọi lại (IncremetCounter) tới CacheContext. Sau đó, chuỗi gọi lại này sẽ tiếp tục đến HiveFileContext, rồi đến RuntimeStats. Trong Presto, RuntimeStats được sử dụng để thu thập thông tin về số liệu khi thực hiện các truy vấn để chúng ta có thể thực hiện các thao tác tổng hợp. Sau đó, chúng ta có thể xem thông tin về hệ thống tệp bộ đệm cục bộ trong giao diện người dùng của Presto hoặc tệp JSON. Chúng tôi có thể làm cho Alluxio và Presto phối hợp chặt chẽ với nhau với quy trình trên. Về phía Presto, chúng tôi có số liệu thống kê tốt hơn; về phía Alluxio, chúng tôi có một bức tranh rõ ràng hơn về siêu dữ liệu. Công việc tương lai Điều chỉnh hiệu suất Bởi vì quá trình gọi lại được mô tả ở trên làm cho vòng đời của CacheContext phát triển đáng kể, chúng tôi đã gặp phải một số vấn đề về độ trễ GC tăng lên mà chúng tôi đang tìm cách giải quyết. Sử dụng bộ đệm ngữ nghĩa (SC) Chúng tôi sẽ triển khai Bộ đệm ngữ nghĩa (SC) dựa trên siêu dữ liệu cấp tệp mà chúng tôi đề xuất. Ví dụ: chúng ta có thể lưu cấu trúc dữ liệu trong tệp Parquet hoặc ORC, chẳng hạn như footer, index, v.v. Deserialization hiệu quả hơn Để đạt được hiệu quả deserialization hơn, chúng tôi sẽ sử dụng flatbuf thay vì protobuf. Mặc dù protobuf được sử dụng trong nhà máy ORC để lưu trữ siêu dữ liệu, nhưng chúng tôi nhận thấy rằng siêu dữ liệu của ORC mang lại hơn 20-30% tổng mức sử dụng CPU trong sự hợp tác của Alluxio với Facebook. Do đó, chúng tôi đang có kế hoạch thay thế protobuf hiện tại bằng một flatbuf để lưu trữ bộ nhớ cache và siêu dữ liệu, dự kiến sẽ cải thiện đáng kể hiệu suất của quá trình giải mã hóa. Tóm lại, cùng với blog trước, loạt blog gồm hai phần này chia sẻ cách chúng tôi tạo một lớp lưu trữ dữ liệu nóng mới cần thiết cho nhóm Presto của chúng tôi dựa trên sự hợp tác nguồn mở gần đây giữa cộng đồng Presto và Alluxio tại Uber. Cách tiếp cận đơn giản và rõ ràng về mặt kiến trúc này có thể giảm đáng kể độ trễ HDFS với SSD được quản lý và lập lịch quan hệ mềm dựa trên băm nhất quán. Tham gia cùng hơn 9000 thành viên trong cộng đồng của chúng tôi để tìm hiểu thêm. kênh slack Giới thiệu về tác giả là kỹ sư phần mềm cấp cao tại nhóm phân tích tương tác của Uber, tập trung vào Presto. Trước khi gia nhập Uber, Chen là kỹ sư phần mềm nhân viên tại nền tảng Dữ liệu lớn của LinkedIn. Chen cũng là người cam kết và thành viên PMC của Apache Hadoop. Chen có hai bằng thạc sĩ của Đại học Duke và Đại học Brown Chen Liang là một kỹ sư phần mềm từ Alluxio và là người cam kết PrestoDB. Trước Alluxio, anh ấy là Trưởng nhóm Kỹ thuật của nhóm Presto ở Twitter và anh ấy đã xây dựng các hệ thống SQL phân tán quy mô lớn cho nền tảng dữ liệu của Twitter. Anh ấy có kinh nghiệm mười hai năm làm việc về tối ưu hóa hiệu suất, bộ nhớ đệm phân tán và xử lý dữ liệu khối lượng. Ông đã nhận bằng Tiến sĩ của mình. về kỹ thuật máy tính của Đại học Syracuse về kiểm tra mô hình biểu tượng và xác minh thời gian chạy của các hệ thống phân tán. Tiến sĩ Beinan Wang Cũng được xuất bản ở đây.
