Memuat Data ke Redshift dengan DBT

• Yelp baru-baru ini meninjau kembali cara memuat data ke Redshift dengan lebih efisien seiring meningkatnya permintaan konsumen terhadap data
• Artikel ini membahas bagaimana DBT dapat digunakan secara mulus dengan Redshift Spectrum untuk membaca data dari Data Lake ke Redshift, secara signifikan mengurangi runtime, menyelesaikan masalah kualitas data, dan meningkatkan produktivitas developer

Titik awal

• Metode memuat data batch ke Redshift telah efektif selama bertahun-tahun, tetapi mereka terus mencari ruang untuk perbaikan
• Mereka terutama menggunakan pekerjaan Spark untuk membaca data S3 dan memublikasikannya ke pipeline data internal berbasis Kafka untuk memasukkan data ke Data Lake maupun Redshift
• Namun, mereka mulai menghadapi beberapa masalah:
  • Kinerja: set data besar (lebih dari 1 juta baris per hari) mulai mengalami keterlambatan. Penyebab utamanya adalah pemindaian tabel untuk memastikan tidak ada duplikasi primary key saat upsert
  • Perubahan skema: sebagian besar tabel disusun dengan skema Avro. Perubahan skema terkadang rumit karena memerlukan proses multi-langkah untuk membuat dan mendaftarkan skema Avro baru
  • Backfill: dukungan backfill untuk koreksi data kurang memadai karena tidak ada cara mudah untuk memodifikasi baris secara in-place. Sering kali mereka harus menghapus data secara manual sebelum menulis data yang telah diperbaiki untuk seluruh partisi
  • Kualitas data: menulis secara paralel ke Data Lake dan Redshift menimbulkan risiko perbedaan data, seperti perbedaan tipe data di antara dua data store tersebut

Meningkatkan pemuatan Redshift dengan DBT

• Saat mempertimbangkan cara memindahkan data dengan lebih efisien, mereka memilih memanfaatkan AWS Redshift Spectrum, alat yang secara khusus dibangun agar Redshift dapat melakukan query terhadap data Data Lake
• Karena tabel Data Lake umumnya memiliki skema yang paling mutakhir, mereka memutuskan menggunakan Data Lake alih-alih S3 sebagai sumber data untuk batch Redshift. Ini tidak hanya membantu mengurangi perbedaan data, tetapi juga selaras dengan praktik terbaik mereka yang memperlakukan Data Lake sebagai single source of truth
• Untuk implementasi, Spectrum memerlukan skema yang terdefinisi, dan ini sudah ada di Glue untuk tabel Data Lake mereka. Satu-satunya pengaturan tambahan yang diperlukan hanyalah menambahkan tabel Data Lake sebagai external table agar dapat diakses dari Redshift dengan query SQL sederhana
• Mereka sudah mulai mengadopsi DBT untuk set data lain, dan DBT juga tampak sebagai kandidat sempurna untuk menangkap query Redshift Spectrum dalam pipeline mereka. DBT unggul dalam transformasi data dan membantu menerapkan penulisan SQL yang modular serta dikendalikan versi
• Alih-alih pekerjaan Spark membaca dari S3 ke Redshift, mereka menggunakan DBT untuk menyalin data langsung dari Data Lake ke Redshift. Selain memberikan manfaat khas seperti reproducibility, fleksibilitas, dan data lineage, DBT juga membantu menyelesaikan beberapa masalah yang disebutkan di atas

Perubahan skema yang disederhanakan

• Untuk menyederhanakan perubahan skema, mereka memanfaatkan argumen konfigurasi on_schema_change milik DBT. Dengan menyetelnya ke append_new_columns, mereka memastikan kolom tidak dihapus saat data yang masuk tidak memilikinya
• Mereka juga menggunakan kontrak DBT sebagai lapisan perlindungan kedua untuk memastikan data yang ditulis sesuai dengan konfigurasi model

Backfill yang lebih sedikit manual

• Backfill juga menjadi jauh lebih mudah melalui DBT. Dengan argumen konfigurasi pre_hook, mereka dapat menentukan query yang dijalankan tepat sebelum model
• Ini memungkinkan mereka menghapus data untuk partisi yang akan ditulis dengan cara yang lebih otomatis
• Kini mereka dapat menjamin idempotensi, sehingga bisa melakukan backfill tanpa khawatir data lama tidak terhapus

Penghapusan duplikasi data

• Untuk menangani baris duplikat, mereka menambahkan lapisan deduplikasi ke SQL dan memvalidasinya dengan pengujian DBT
• DBT memiliki pengujian bawaan untuk kolom unique, tetapi itu memerlukan pemindaian seluruh tabel sehingga tidak praktis untuk tabel besar
• Sebagai gantinya, mereka menggunakan fungsi expect_column_values_to_be_unique dari paket dbt_expectations. Ini memungkinkan mereka menentukan kondisi baris sehingga hanya baris yang baru ditulis yang dipindai

Peningkatan kinerja

• Hasil yang paling mencolok adalah peningkatan kinerja, terutama pada set data Redshift yang paling bermasalah:
  • Penulisan sebelumnya memakan waktu sekitar 2 jam, tetapi sekarang umumnya selesai hanya dalam 10 menit
  • Sebelumnya ada keterlambatan hingga 6 jam per bulan, tetapi sekarang keterlambatan itu tidak ada lagi. Ini sangat mengurangi beban upaya respons insiden on-call
  • Upgrade skema sebelumnya merupakan proses multi-langkah yang lebih panjang. Sekarang menjadi proses 3 langkah yang hanya memakan beberapa jam

Konsistensi data yang lebih baik

• Dengan menghilangkan percabangan dalam aliran data, keyakinan mereka meningkat bahwa data tidak akan berbeda antar penyimpanan data yang berbeda
• Semua data yang masuk ke Redshift kini harus terlebih dahulu melewati Data Lake, sehingga lebih terjamin bahwa Data Lake tetap menjadi single source of truth

Kesimpulan

• Setelah keberhasilan migrasi, mereka menerapkan perubahan ini pada sekitar 12 set data lainnya dan secara umum mengamati manfaat yang serupa
• Dengan memanfaatkan alat seperti AWS Redshift Spectrum dan DBT, mereka menyesuaikan infrastruktur dengan kebutuhan data yang terus berkembang untuk memberikan nilai yang lebih besar kepada pengguna dan pemangku kepentingan