Bagaimana cara mendekati misi ETL?

Beberapa kiat ETL umum

1. Pertimbangkan untuk mengaturnya berdasarkan tujuan (misalnya, semua kode untuk menghasilkan dimensi Pelanggan tinggal dalam modul yang sama, terlepas dari sumbernya). Hal ini terkadang dikenal sebagai ETL berorientasi subjek. Ini membuat pencarian lebih mudah dan akan meningkatkan pemeliharaan kode Anda.

2. Jika database SQL2000 berantakan, Anda mungkin akan menemukan bahwa aliran data SSIS adalah cara yang kikuk untuk menangani data. Sebagai aturan, alat ETL berskala buruk dengan kompleksitas; sesuatu seperti setengah dari semua proyek gudang data di perusahaan keuangan dilakukan dengan kode prosedur tersimpan sebagai keputusan arsitektur eksplisit - justru untuk alasan ini. Jika Anda harus memasukkan sejumlah besar kode dalam proses, pertimbangkan untuk memasukkan semua dari kode di sprocs.
   
   Untuk sistem yang melibatkan banyak scrubbing atau transformasi yang kompleks, pendekatan sproc 100% jauh lebih dapat dipertahankan karena ini adalah satu-satunya cara yang layak untuk menempatkan semua transformasi dan logika bisnis di satu tempat. Dengan sistem campuran ETL/sproc, Anda harus mencari di banyak tempat untuk melacak, memecahkan masalah, men-debug, atau mengubah seluruh transformasi.

3. Keunggulan alat ETL ada pada sistem di mana Anda memiliki lebih banyak sumber data dengan transformasi yang relatif sederhana.

4. Jadikan kode dapat diuji, sehingga Anda dapat memilih komponen dan pengujian dalam isolasi. Kode yang hanya dapat dieksekusi dari tengah aliran data yang kompleks dalam alat ETL jauh lebih sulit untuk diuji.

5. Buat ekstrak data menjadi bodoh dengan logika nobusiness, dan salin ke area astaging. Jika Anda memiliki logika bisnis yang tersebar di seluruh lapisan ekstrak dan transformasi, Anda akan memiliki transformasi yang tidak dapat diuji secara terpisah dan membuatnya sulit untuk melacak bug. Jika transformasi berjalan dari area staging, Anda mengurangi ketergantungan keras pada sistem sumber, sekali lagi meningkatkan kemampuan pengujian. Ini adalah kemenangan khusus pada arsitektur berbasis sproc karena memungkinkan basis kode yang hampir sepenuhnya homogen.

6. Buat pengendali dimensi yang berubah perlahan secara umum atau gunakan salah satunya jika tersedia. Ini membuat lebih mudah untuk menguji unit fungsi ini. Jika ini dapat diuji, pengujian sistem tidak harus menguji semua kasus sudut, hanya apakah data yang disajikan benar. Ini tidak serumit kedengarannya - Yang terakhir saya tulis adalah sekitar 600 atau 700 baris kode T-SQL. Hal yang sama berlaku untuk semua fungsi scrubbing umum.

7. Muat secara bertahap jika memungkinkan.

8. Instrumen kode Anda - mintalah membuat entri log, mungkin merekam diagnostik seperti total cek atau penghitungan. Tanpa ini, pemecahan masalah hampir tidak mungkin. Juga, pemeriksaan pernyataan adalah cara yang baik untuk memikirkan penanganan kesalahan untuk ini (apakah jumlah baris dalam jumlah baris yang sama di b, apakah hubungan A:B benar-benar 1:1).

9. Gunakan kunci sintetis. Menggunakan kunci alami dari sistem sumber mengikat sistem Anda ke sumber data, dan mempersulit penambahan sumber tambahan. Kunci dan hubungan dalam sistem harus selalu sejajar - tidak ada nol. Untuk kesalahan, 'tidak tercatat', buat entri 'kesalahan' atau 'tidak tercatat' tertentu di tabel dimensi dan cocokkan dengannya.

10. Jika Anda membangun Operational Data Store (subjek dari banyak perang agama) jangan mendaur ulang kunci ODS dalam skema bintang. Dengan segala cara, gabungkan kunci ODS untuk membangun dimensi, tetapi cocokkan dengan kunci alami. Ini memungkinkan Anda untuk secara sewenang-wenang menjatuhkan dan membuat ulang ODS - mungkin mengubah strukturnya - tanpa mengganggu skema bintang. Memiliki kemampuan ini merupakan keuntungan pemeliharaan yang nyata, karena Anda dapat mengubah struktur ODS atau melakukan pengerahan ulang ODS secara paksa kapan saja.

Poin 1-2 dan 4-5 berarti Anda dapat membangun sistem di mana semua kode untuk setiap subsistem tertentu (misalnya satu dimensi atau tabel fakta) tinggal di satu dan hanya satu tempat dalam sistem. Jenis arsitektur ini juga lebih baik untuk sejumlah besar sumber data.

Poin 3 adalah kebalikan dari poin 2. Pada dasarnya pilihan antara perkakas SQL dan ETL adalah fungsi dari kompleksitas transformasi dan jumlah sistem sumber. Semakin sederhana data dan semakin besar jumlah sumber data, semakin kuat alasan untuk pendekatan berbasis alat. Semakin kompleks data, semakin kuat kasus untuk pindah ke arsitektur berdasarkan prosedur tersimpan. Umumnya lebih baik untuk secara eksklusif atau hampir secara eksklusif menggunakan satu atau yang lain tetapi tidak keduanya.

Poin 6 membuat sistem Anda lebih mudah untuk diuji. Menguji fungsionalitas berbasis SCD atau perubahan apa pun tidak mudah, karena Anda harus dapat menyajikan lebih dari satu versi data sumber ke sistem. Jika Anda memindahkan fungsionalitas manajemen perubahan ke dalam kode infrastruktur, Anda dapat mengujinya secara terpisah dengan kumpulan data pengujian. Ini adalah kemenangan dalam pengujian, karena mengurangi kerumitan persyaratan pengujian sistem Anda.

Poin 7 adalah tip kinerja umum yang perlu Anda perhatikan untuk volume data yang besar. Perhatikan bahwa Anda mungkin hanya memerlukan pemuatan tambahan untuk beberapa bagian sistem; untuk tabel dan dimensi referensi yang lebih kecil, Anda mungkin tidak memerlukannya.

Poin 8 erat dengan proses tanpa kepala apa pun. Jika naik payudara di malam hari, Anda ingin beberapa kesempatan berjuang untuk melihat apa yang salah pada hari berikutnya. Jika kode tidak mencatat dengan benar apa yang terjadi dan menangkap kesalahan, Anda akan memiliki pekerjaan yang jauh lebih sulit untuk memecahkan masalah itu.

Poin 9 memberi data warehouse kehidupannya sendiri. Anda dapat dengan mudah menambah dan melepaskan sistem sumber ketika gudang memiliki kuncinya sendiri. Kunci gudang juga diperlukan untuk menerapkan dimensi yang berubah secara perlahan.

Poin 10 adalah kemenangan pemeliharaan dan penerapan, karena ODS dapat disusun ulang jika Anda perlu menambahkan sistem baru atau mengubah kardinalitas catatan. Ini juga berarti bahwa dimensi dapat dimuat dari lebih dari satu tempat di ODS (pikirkan:menambahkan penyesuaian akuntansi manual) tanpa ketergantungan pada kunci ODS.