Tải dữ liệu vào Redshift bằng DBT

• Yelp gần đây đã xem xét lại cách tải dữ liệu vào Redshift hiệu quả hơn khi nhu cầu của người dùng đối với dữ liệu ngày càng tăng
• Bài viết này xem xét cách DBT hoạt động liền mạch với Redshift Spectrum để đọc dữ liệu từ Data Lake vào Redshift, giúp giảm đáng kể thời gian chạy, giải quyết các vấn đề về chất lượng dữ liệu và cải thiện năng suất của nhà phát triển

Điểm khởi đầu

• Cách tải dữ liệu batch vào Redshift đã hoạt động hiệu quả trong nhiều năm, nhưng họ vẫn tiếp tục tìm kiếm các điểm có thể cải thiện
• Chủ yếu sử dụng các job Spark để đọc dữ liệu từ S3 và publish vào pipeline dữ liệu nội bộ dựa trên Kafka để đưa dữ liệu vào cả Data Lake lẫn Redshift
• Tuy nhiên, họ bắt đầu gặp phải một số vấn đề:
  • Hiệu năng: các tập dữ liệu lớn (hơn 1 triệu dòng mỗi ngày) bắt đầu bị chậm. Nguyên nhân chủ yếu là do phải quét bảng để bảo đảm khóa chính không bị trùng khi upsert
  • Thay đổi schema: phần lớn các bảng được cấu thành từ schema Avro. Việc thay đổi schema đôi khi phức tạp vì cần một quy trình nhiều bước để tạo và đăng ký schema Avro mới
  • Backfill: hỗ trợ backfill cho việc sửa dữ liệu còn hạn chế, vì không có cách dễ dàng để sửa dòng tại chỗ. Họ thường phải xóa dữ liệu thủ công trước khi ghi dữ liệu đã chỉnh sửa cho toàn bộ partition
  • Chất lượng dữ liệu: việc ghi song song vào Data Lake và Redshift tạo ra rủi ro sai khác dữ liệu, chẳng hạn như khác biệt về kiểu dữ liệu giữa hai kho dữ liệu

Cải thiện việc tải dữ liệu vào Redshift với DBT

• Khi cân nhắc cách di chuyển dữ liệu hiệu quả hơn, họ chọn tận dụng AWS Redshift Spectrum, một công cụ được xây dựng riêng để truy vấn dữ liệu trong Data Lake từ Redshift
• Vì các bảng trong Data Lake thường có schema được cập nhật mới nhất, họ quyết định dùng Data Lake thay cho S3 làm nguồn dữ liệu cho các batch Redshift. Điều này không chỉ giúp giảm sai khác dữ liệu mà còn phù hợp với thực tiễn tốt nhất của họ là coi Data Lake như nguồn chân lý duy nhất
• Để triển khai, Spectrum cần schema được định nghĩa sẵn, và điều này đã có trong Glue cho các bảng Data Lake của họ. Thiết lập bổ sung duy nhất cần thiết là thêm các bảng Data Lake dưới dạng external table để có thể truy cập từ Redshift bằng các truy vấn SQL đơn giản
• Họ đã bắt đầu áp dụng DBT cho các tập dữ liệu khác, và đây cũng là ứng viên hoàn hảo để ghi nhận các truy vấn Redshift Spectrum trong pipeline. DBT rất mạnh trong biến đổi dữ liệu và giúp áp dụng cách viết SQL theo hướng mô-đun, có kiểm soát phiên bản
• Thay vì để job Spark đọc từ S3 sang Redshift, họ dùng DBT để sao chép dữ liệu trực tiếp từ Data Lake vào Redshift. DBT không chỉ mang lại các lợi ích quen thuộc như khả năng tái lập, tính linh hoạt và data lineage, mà còn giúp giải quyết một số vấn đề đã nêu ở trên

Đơn giản hóa thay đổi schema

• Để đơn giản hóa việc thay đổi schema, họ tận dụng đối số cấu hình on_schema_change của DBT. Thiết lập thành append_new_columns để bảo đảm các cột không bị xóa nếu dữ liệu đầu vào không có cột đó
• Họ cũng dùng DBT contracts như lớp bảo vệ thứ hai để xác minh rằng dữ liệu được ghi ra khớp với cấu hình của model

Backfill ít thủ công hơn

• Với DBT, việc backfill cũng trở nên dễ dàng hơn nhiều. Có thể dùng đối số cấu hình pre_hook để chỉ định truy vấn sẽ chạy ngay trước model
• Nhờ đó, có thể xóa dữ liệu cho các partition sắp được ghi một cách tự động hơn
• Giờ đây họ có thể bảo đảm tính idempotent, nên có thể thực hiện backfill mà không phải lo dữ liệu cũ chưa được xóa

Khử trùng lặp dữ liệu

• Để xử lý các dòng trùng lặp, họ thêm một lớp deduplication trong SQL và xác thực bằng DBT test
• DBT có sẵn bài test cột unique, nhưng nó yêu cầu quét toàn bộ bảng nên không khả thi với các bảng lớn
• Thay vào đó, họ dùng hàm expect_column_values_to_be_unique từ gói dbt_expectations. Hàm này cho phép chỉ định điều kiện theo dòng để chỉ quét các dòng mới được ghi gần đây

Cải thiện hiệu năng

• Kết quả nổi bật nhất là cải thiện hiệu năng, đặc biệt ở tập dữ liệu Redshift gặp nhiều vấn đề nhất:
  • Ghi dữ liệu trước đây mất khoảng 2 giờ, còn bây giờ thường chỉ chạy trong 10 phút
  • Trước đây có thể bị trễ tới 6 giờ mỗi tháng, nhưng giờ không còn độ trễ nữa. Điều này giúp giảm đáng kể gánh nặng cho nỗ lực ứng phó sự cố on-call
  • Nâng cấp schema trước đây là một quy trình nhiều bước kéo dài hơn. Giờ đây đã được cải thiện thành quy trình 3 bước chỉ mất vài giờ

Tính nhất quán dữ liệu tốt hơn

• Bằng cách loại bỏ sự phân nhánh trong luồng dữ liệu, họ có mức độ tin cậy cao hơn rằng dữ liệu sẽ không bị sai khác giữa các kho lưu trữ khác nhau
• Mọi dữ liệu đi vào Redshift giờ đều phải đi qua Data Lake trước, nên có thể bảo đảm tốt hơn rằng Data Lake vẫn là nguồn chân lý duy nhất

Kết luận

• Sau thành công của đợt migration, họ đã áp dụng các thay đổi này cho khoảng 12 tập dữ liệu khác và quan sát thấy những lợi ích tương tự trên diện rộng
• Bằng cách tận dụng các công cụ như AWS Redshift Spectrum và DBT, họ đã điều chỉnh hạ tầng để phù hợp với nhu cầu dữ liệu đang thay đổi, từ đó mang lại giá trị lớn hơn cho người dùng và các bên liên quan