Di chuyển dữ liệu sổ cái của Uber từ DynamoDB sang LedgerStore

• Tuần trước, Uber đã khám phá LedgerStore (LSG), cơ sở dữ liệu kiểu sổ cái độc quyền bổ sung của mình.
• Tuần này, bài viết sẽ đề cập đến cách Uber di chuyển dữ liệu sổ cái quan trọng với hoạt động kinh doanh sang LSG.
• Thảo luận về cách di chuyển minh bạch hơn 1 nghìn tỷ mục dữ liệu (vài petabyte dữ liệu) mà không gián đoạn, cùng những bài học rút ra trong quá trình đó.

Lịch sử

• Gulfstream là nền tảng thanh toán của Uber, được ra mắt vào năm 2017 bằng DynamoDB.
• Ở quy mô của Uber, DynamoDB trở nên đắt đỏ, vì vậy họ bắt đầu chỉ giữ 12 tuần dữ liệu (dữ liệu nóng) trong DynamoDB và lưu dữ liệu cũ hơn (dữ liệu lạnh) trong TerraBlob, blobstore của Uber.
• Về lâu dài, họ muốn dùng LSG như giải pháp dài hạn. LSG được thiết kế chuyên biệt để lưu trữ dữ liệu kiểu thanh toán.
• Các tính năng chính của LSG:
  • Tính bất biến có thể xác minh được (có thể dùng chữ ký mật mã để xác nhận bản ghi chưa bị thay đổi)
  • Lưu trữ phân tầng để quản lý chi phí (dữ liệu nóng được đặt ở nơi phù hợp để xử lý request, dữ liệu lạnh được lưu ở nơi tối ưu cho lưu trữ)
  • Cải thiện độ trễ của secondary index nhất quán cuối cùng
• Đến năm 2021, Gulfstream dùng kết hợp DynamoDB, TerraBlob và LSG để lưu dữ liệu.
  • DynamoDB: dữ liệu 12 tuần gần nhất
  • TerraBlob: dữ liệu lạnh
  • LSG: nơi ghi dữ liệu và là đích cần di chuyển sang

Vì sao phải di chuyển?

• LSG phù hợp hơn để lưu dữ liệu kiểu sổ cái nhờ tính bất biến của nó.
• Việc chuyển sang LSG mang lại mức tiết kiệm chi phí lặp lại rất đáng kể.
• Chuyển từ ba hệ lưu trữ sang một hệ duy nhất giúp đơn giản hóa code và thiết kế của dịch vụ Gulfstream.
• LSG hứa hẹn độ trễ lập chỉ mục ngắn hơn, và vì chạy on-premise trong các trung tâm dữ liệu của Uber nên còn cho độ trễ mạng nhanh hơn.

Rủi ro liên quan đến đặc tính dữ liệu

• Dữ liệu được di chuyển là toàn bộ dữ liệu sổ cái nghiệp vụ của Uber kể từ năm 2017:
  • Bản ghi bất biến: kích thước nén 1.2 PB
  • Secondary index: kích thước không nén 0.5 PB
• Bản ghi bất biến không thể sửa đổi, còn dữ liệu secondary index có sự linh hoạt để chỉnh sửa khi cần khắc phục sự cố.

Xác minh

• Để chắc chắn rằng quá trình backfill là đúng và chấp nhận được trên mọi phương diện, cần xác nhận rằng hệ thống có thể xử lý traffic hiện tại và dữ liệu hiện không được truy cập vẫn là chính xác.
• Tiêu chí xác minh:
  • Tính đầy đủ: mọi bản ghi đã được backfill hay chưa
  • Tính chính xác: mọi bản ghi có chính xác hay không
  • Tải: LSG có thể xử lý tải hiện tại không
  • Độ trễ: độ trễ P99 của LSG có nằm trong ngưỡng chấp nhận được không
  • Độ trễ chờ: độ trễ tạo secondary index có nằm trong ngưỡng chấp nhận được không

Shadow validation

• So sánh phản hồi trước và sau di chuyển để đảm bảo traffic hiện tại không bị ảnh hưởng bởi sự cố di chuyển dữ liệu hay lỗi code.
• Shadow validation xác nhận rằng backfill đạt tối thiểu 99.99% về tính đầy đủ và chính xác, với cận trên đặt ở mức 99.9999%.
• Shadow validation cũng xác nhận LSG có thể xử lý production traffic, đồng thời tạo niềm tin vào code truy cập dữ liệu.
• Shadow validation mang lại sự tin cậy về tính đầy đủ và chính xác của dữ liệu đang được truy cập hiện tại.

Xác minh offline và backfill tăng dần

• So sánh toàn bộ dữ liệu trong LSG với bản dump dữ liệu từ DynamoDB.
• Xác minh offline đảm bảo việc backfill dữ liệu được thực hiện chính xác và bao phủ toàn bộ dữ liệu.
• Xác minh offline nên được thực hiện cùng với shadow validation.

Các vấn đề của backfill

• Mọi đợt backfill đều có rủi ro. Uber đã dùng Apache Spark của mình để thực hiện backfill.
• Cách xử lý vấn đề:
  • Khả năng mở rộng: bắt đầu ở quy mô nhỏ rồi mở rộng dần
  • Backfill tăng dần: chia dữ liệu thành các batch nhỏ để backfill
  • Kiểm soát tốc độ: điều chỉnh tốc độ của job backfill
  • Kiểm soát tốc độ động: theo dõi trạng thái hệ thống hiện tại để điều chỉnh tốc độ
  • Dừng khẩn cấp: cung cấp khả năng dừng nhanh backfill nếu nghi ngờ quá tải
  • Kích thước file dữ liệu: giữ kích thước file dump dữ liệu ở mức phù hợp
  • Khả năng chịu lỗi: xử lý vấn đề chất lượng/hỏng dữ liệu
  • Logging: giới hạn log để không tạo gánh nặng cho hạ tầng logging

Giảm thiểu rủi ro

• Phân tích nhiều loại dữ liệu thống kê về xác minh và backfill, đồng thời rollout LSG một cách thận trọng.
• Ban đầu, họ dùng cơ chế fallback để lấy dữ liệu từ DynamoDB nếu backfill thất bại.
• Kiểm tra log fallback để xác nhận dữ liệu thực sự không bị thiếu trong LSG.

Kết luận

• Bài viết này trình bày quá trình di chuyển dữ liệu sổ cái quan trọng với hoạt động kinh doanh ở quy mô lớn từ một kho dữ liệu sang kho khác.
• Bài viết đề cập đến nhiều khía cạnh như tiêu chí di chuyển, xác minh, các vấn đề backfill và độ an toàn.
• Quá trình di chuyển đã hoàn tất trong 2 năm mà không có gián đoạn hay sự cố.

Ý kiến của GN⁺

• Tầm quan trọng của di chuyển dữ liệu: Di chuyển dữ liệu quy mô lớn rất phức tạp và nhiều rủi ro, nhưng về dài hạn mang lại lợi ích lớn thông qua tiết kiệm chi phí và đơn giản hóa hệ thống.
• Tính hữu ích của shadow validation: Shadow validation là công cụ mạnh để xác nhận tính đầy đủ và chính xác của dữ liệu mà không ảnh hưởng đến traffic thực tế.
• Sự cần thiết của xác minh offline: Xác minh offline cũng là bắt buộc vì nó có thể phát hiện các vấn đề mà chỉ shadow validation thì không thấy được.
• Cách tiếp cận từng bước cho backfill: Chia công việc backfill thành các batch nhỏ và thực hiện từng bước là cách hiệu quả để tránh quá tải hệ thống.
• Chức năng dừng khẩn cấp: Khả năng dừng nhanh khi có sự cố trong quá trình backfill rất quan trọng để duy trì độ ổn định của hệ thống.

[GN⁺]

Ý kiến trên Hacker News

Tóm tắt các bình luận trên Hacker News

• 2 tỷ chuyến đi mỗi quý

  • Uber xử lý 2 tỷ chuyến đi mỗi quý. Quy đổi ra có thể tương đương khoảng 1.000 giao dịch mỗi giây. Khó hiểu vì sao họ phải quá bận tâm đến việc mở rộng hạ tầng như vậy.

• Sử dụng DynamoDB chưa đúng cách

  • Uber đã sử dụng DynamoDB chưa đúng cách. Một số hành trình người dùng quan trọng (CUJ) cần tính nhất quán mạnh, đồng thời cũng cần kho dữ liệu cho các giao dịch lịch sử. Việc họ không chuyển sang kiến trúc DynamoDB và Redshift là điều khá lạ.

• Google từ chối

  • Có vẻ như Uber đã mang về một dự án từng thất bại ở Google. Những dự án kiểu này thường nhắm tới các đợt thăng chức lớn. Kiểu như: "Tự thiết kế và xây dựng hệ thống để tiết kiệm $Xm! Hãy thăng chức cho tôi!". Nhưng chi phí xây dựng thường còn cao hơn, và vài năm sau có khả năng sẽ bị loại bỏ.

• SQLite trên một máy chủ duy nhất

  • Có người thắc mắc liệu có thể lưu 1,7 petabyte dữ liệu (1 nghìn tỷ bản ghi đã được lập chỉ mục) trên một máy chủ bare-metal hiệu năng cao duy nhất bằng SQLite hay không. Có kèm một liên kết ví dụ.

• LedgerStore không phải mã nguồn mở

  • LedgerStore không phải là mã nguồn mở. Muốn tìm thông tin liên quan thì phải lần theo các bài đăng trên blog của Uber. Có kèm liên kết đến một bài viết năm 2021.

• Kỷ nguyên hạ tầng tự xây

  • Vào khoảng năm 2015, nhiều công ty công nghệ như Netflix, Spotify, SoundCloud và Uber đã tự xây rất nhiều công cụ hạ tầng và cơ sở dữ liệu. Dạo gần đây có nhiều kỹ sư chỉ nói chuyện bằng thuật ngữ AWS/cloud. Vì vậy, việc vẫn còn thấy những tổ chức tự xây công cụ như thế này tạo cảm giác khá mới mẻ.

• Cloud độc quyền đắt đỏ

  • Đây là một ví dụ cho thấy các kho lưu trữ dữ liệu dựa trên cloud độc quyền có thể đắt đỏ đến mức nào. Và việc di chuyển sang một giải pháp khác là hoàn toàn khả thi.

• Đã cân nhắc TigerBeetle chưa?

  • Có người thắc mắc liệu họ đã cân nhắc TigerBeetle hay chưa.

• DynamoDB rất đắt

  • Không rõ tính kinh tế của dự án này ra sao, nhưng DynamoDB thực sự rất đắt. Có người từng nghĩ là do những người khác sử dụng sai cách, nhưng ngay cả khi dùng nó như một distributed hash table thì chi phí vẫn rất lớn.

• Chi phí vận hành đội ngũ

  • Có vẻ chi phí vận hành đội dự án này cũng không chênh lệch nhiều so với khoản tiết kiệm được (6 triệu USD). Chưa kể còn có thêm chi phí bảo trì. Hệ thống thanh toán có lẽ không phải là một khoản đầu tư dài hạn. Điều khiến người ta tò mò là vì sao những dự án như vậy vẫn được triển khai. Có thể đó cũng là một dạng chi phí chìm gắn với đội ngũ kỹ sư hiện có.