Kerangka kualitas data terbaik untuk insinyur platform senior

Itulah mengapa setiap organisasi yang menganggap data penting bagi fungsi bisnisnya - baik konsumen internal maupun eksternal - perlu mempraktikkan manajemen kualitas data dan menerapkan kerangka kerja kualitas data. Beginilah kedengarannya: Mengembangkan proses dan pola yang idealnya otomatis yang dapat diulang untuk memastikan bahwa data yang masuk ke sistem Anda dan dikirim ke hilir adalah apa yang Anda dan konsumen Anda harapkan.

Dan seperti yang Anda ketahui oleh para insinyur data senior, memahami harapan itu adalah setengah dari perjuangan. Sebagian besar waktu dihabiskan untuk menerjemahkan ekspektasi tersebut ke dalam pelacakan dan peringatan yang akan membantu Anda menemukan dan memperbaiki masalah dalam proses konsumsi yang rumit.

Dalam panduan ini, kami berbagi strategi untuk memastikan bahwa manajemen kualitas data tidak hanya berlapis di atas proses hardcode Anda yang ada, tetapi dibangun ke dalam setiap DAG. Untuk mengelolanya dengan baik, Anda perlu mendeteksi anomali jauh sebelum data berkualitas rendah memasuki lapisan transformasi Anda.

Mari kita mulai dengan definisi. Kerangka kerja kualitas data adalah alat yang dapat digunakan organisasi untuk menentukan atribut kualitas data yang relevan dan memberikan panduan bagi proses manajemen kualitas data untuk terus memastikan kualitas data memenuhi harapan konsumen (SLA).

Kalimat itu sangat rumit, jadi mari kita bongkar:

1. Anda membutuhkan sebuah proses: Kecuali jika Anda memiliki jam kerja teknisi yang tidak terbatas, sebuah proses harus mencakup pengujian unit yang dapat diulang dan idealnya otomatis pada setiap tahap pipeline data Anda (terutama pada saat konsumsi jika Anda ingin mendeteksi masalah secara proaktif), dan alur kerja untuk menangani masalah data.
2. Anda harus terus memastikannya: Kualitas data Anda menurun secara proporsional dengan kecepatan data Anda - juga dikenal sebagai penyimpangan data. Data berkecepatan tinggi seperti yang kita tangani sekarang membutuhkan pemeriksaan yang sering.
3. Anda harus memenuhi harapan konsumen, bukan harapan Anda sendiri: Kualitas data pada dasarnya adalah proses bisnis. SLA data atau "perjanjian layanan" Anda adalah dengan konsumen dan tidak ada masalah di sisi teknik jika ilmuwan data tidak dapat menjalankan model mereka, jika pelanggan menerima perkiraan pengiriman ekspedisi yang tidak akurat, atau jika wakil presiden regional Anda harus pergi ke rapat dewan dengan tangan kosong karena dasbor tidak dimuat.

Ada banyak hal yang diperlukan untuk memenuhi janji di atas, dan masing-masing elemen tersebut penuh dengan dependensi. Misalnya, jika Anda bertanya pada diri sendiri bagaimana merancang sistem seperti itu, Anda akan mengajukan pertanyaan-pertanyaan berikut:

1. Bagaimana Anda bisa memahami harapan konsumen seputar kualitas data?
2. Bagaimana Anda akan menerjemahkan ekspektasi tersebut ke dalam ukuran kualitas data yang dapat diukur?
3. Bagaimana Anda akan menerapkan ukuran kualitas otomatis untuk setiap saluran pipa Anda?
4. Bagaimana Anda akan menentukan ambang batas untuk setiap dimensi kualitas data?
5. Bagaimana Anda akan memberi tahu tim Anda ketika data melanggar ambang batas tersebut?
6. Apa yang akan dilakukan tim Anda ketika mereka menerima peringatan?
7. Bagaimana mereka akan menilai validitas dan urgensi peringatan?
8. Jika ada masalah, bagaimana mereka mengidentifikasi penyebab terdekat?
9. Bagaimana mereka akan mengidentifikasi akar masalahnya?
10. Bagaimana mereka akan membiarkan konsumen tahu apa yang diharapkan?
11. Bagaimana mereka akan mengatasi akar masalahnya?
12. Bagaimana mereka memverifikasi bahwa mereka telah mengatasi akar masalah?
13. Bagaimana mereka mendokumentasikan apa yang terjadi untuk membangun pengetahuan?

Sepertinya daftar bernomor yang panjang dan berpotensi tidak menguntungkan? Jangan pernah takut. Anda dapat mendelegasikan.

Pertanyaan 1 paling cocok untuk analis bisnis di pod atau regu Anda. Terserah kepada mereka untuk berbicara dengan unit bisnis untuk menguraikan cerita pengguna, preferensi yang dinyatakan, preferensi yang tersirat, permintaan, dan post-mortem acara ke dalam daftar "permintaan" untuk data. Ini adalah ekspektasi kualitatif yang dimiliki konsumen terhadap data, dan ini merupakan percakapan dua arah, karena mereka mungkin tidak memiliki kata-kata untuk menggambarkan apa yang mereka inginkan dengan tepat. (Kecuali konsumen data Anda adalah ilmuwan data Anda, yang benar-benar dapat mempercepat ini).

Pertanyaan 2 adalah untuk Anda dan ilmuwan data Anda untuk dijawab bersama (terutama jika mereka juga konsumen). Mengingat karakteristik data Anda untuk setiap pipeline, atribut apa yang dapat Anda ukur untuk menguraikan lebih lanjut daftar ekspektasi kualitatif menjadi daftar pengukuran kuantitatif?

Tergantung pada model kualitas data yang Anda ikuti, ada empat atau lima dimensi kualitas untuk dilihat. Di IBM Databand kami lebih memilih model dengan empat karakteristik:

• Kebugaran
  • Akurasi—data mencerminkan kenyataan
  • Integritas—kualitas/waktu
• Silsilah
  • Sumber—apakah penyedia memenuhi harapan Anda?
  • Asal-usul—dari mana asalnya?
• Pemerintahan
  • Kontrol data
  • Privasi data
  • Peraturan
  • Keamanan
• Stabilitas
  • Konsistensi
  • Keandalan
  • Ketepatan waktu
  • Bias

Dengan adanya metrik tersebut, teknisi data dapat menjawab Pertanyaan 3-13 dan mulai membangun strategi manajemen kualitas data. Dan sebelum kita membahas secara tepat bagaimana melakukan itu, ada baiknya bertanya, mengapa melakukan semua upaya ini?

Beberapa tahun lalu, perubahan konfigurasi yang tidak berbahaya pada Microsoft Dynamics CRM milik pengecer besar menyebabkan jumlah inventaris yang ditampilkan pada setiap item secara daring tidak lagi mencerminkan kenyataan. Penghitungnya tiba-tiba berhenti memperbarui.

Orang-orang terus membeli, tetapi jumlah volume tetap konstan. Pada saat tim rekayasa data diperingatkan, segalanya telah menjadi buruk.

Sebagian besar barang tersedia untuk dibeli secara online, tetapi juga untuk pengambilan di dalam toko. Banyak orang memilih penjemputan di toko. Pesanan diproses, dan barang-barang yang tidak ada tetap dijual. Jadi, konsumen mengunjungi toko-toko di mana para pegawai retail berebut mencari barang pengganti atau menjanjikan diskon atau entah bagaimana cara menenangkan konsumen. Antrean terbentuk. Pengunjung toko harus menunggu untuk membeli dan layanan terhenti oleh begitu banyak orang yang dengan marah mengetuk ponsel mereka. Dan karena butuh waktu berhari-hari untuk menemukan masalah dan memperbaiki pipa, maka butuh beberapa hari lagi sebelum masalah teratasi.

Dengan memperhitungkan hilangnya reputasi merek, kesalahan menelan biaya puluhan juta, dan hal ini tidak perlu terjadi.

Yang bisa dikatakan, masalah data majemuk. Mereka bisa sulit dikenali dan diatasi, dan tumbuh tanpa terlihat. Sangat mudah untuk jatuh ke dalam pola yang menganggap bahwa semuanya berjalan dengan baik hanya karena Anda masih mendapatkan beberapa wawasan, bahkan ketika Anda menambah jumlah utang data bawah tanah.

Selain itu, tanda-tanda paling benar dari masalah kualitas data juga cenderung merupakan indikator yang tertinggal. Misalnya, konsumen memberi tahu Anda. Atau seperti pada contoh CRM retail sebelumnya, ribuan manajer retail dan wakil presiden regional memberi tahu Anda. Itu buruk. Itu berarti bahwa data telah berada di sistem Anda selama beberapa waktu dan akan memakan waktu berhari-hari agar perbaikan menghasilkan hasil. Bicara tentang harapan konsumen yang hilang.

Ini adalah situasi yang dihadapi oleh startup pengiriman Shipper, dan mengapa mereka berinvestasi besar-besaran untuk mencegah hal itu terjadi. Tim rekayasa data mereka memberikan data sedekat mungkin dengan waktu nyata ke sebuah aplikasi yang membantu vendor ecommerce mengirimkan inventaris mereka ke pelabuhan pengiriman. Bukan hanya harapan konsumen mereka yang harus mereka khawatirkan—tetapi konsumen dari konsumen mereka. Dan ketika sistem mereka kadang-kadang tertinggal dua hari, itu menciptakan riak bertingkat dari harapan yang terlewat. Oleh karena itu, mereka berinvestasi besar-besaran dalam manajemen kualitas data dan alat yang dapat memberikan peringatan dini dengan pemeriksaan otomatis.

Manajemen kualitas data adalah cara untuk membuat pemeriksaan kualitas data menjadi otomatis dan meresap, sehingga Anda memerangi kekuatan entropi pada kumpulan data dan pipeline Anda dengan kekuatan yang sama dan berlawanan.

Mari kita kembali ke contoh dan daftar pertanyaan kita sebelumnya. Analis Anda berbicara dengan bisnis untuk mengumpulkan persyaratan, dan Anda menerima daftar ekspektasi konsumen kuantitatif dari ilmuwan data Anda. Bagaimana Anda kemudian bergerak maju dan membangun sistem?

Anda menggambar kerangka kerja kualitas data Anda. Kerangka kerja Anda harus terlebih dahulu mengakui bahwa sistem adalah sebuah siklus dan segala sesuatu yang Anda pelajari tentang ekspektasi konsumen, yang selalu berkembang, akan mempengaruhi sistem.

Mari kita jelajahi masing-masing tahapan ini:

1. Memenuhi syarat: Analis bisnis menguraikan kebutuhan konsumen ke dalam daftar persyaratan
2. Kuantifikasi: Ilmuwan data menguraikan persyaratan menjadi ukuran kualitas data yang dapat diukur, yang pada saat ini masih bersifat teoritis.
3. Rencana: Insinyur data menerjemahkan ukuran kuantitatif kualitas data ke dalam pemeriksaan yang dapat mereka jalankan di platform observabilitas pipa data mereka. Platform semacam itu sangat penting—alur kerja dan sistem penjadwalan pipa seperti Airflow dan Spark dapat mendeteksi masalah dengan pipa itu sendiri, tetapi tidak di dalam data, yang merupakan tempat sebagian besar masalah muncul. Teknisi Anda perlu memahami apa yang dapat dan tidak dapat dilacak di sistem Anda.
4. Menerapkan: Insinyur data mengimplementasikan pelacakan dan mengujinya. Sebagai contoh yang sangat sederhana, jika semua data harus ada, dan tidak ada bidang atau kolom yang hilang, Anda dapat mengatur peringatan di sekitar parameter kelengkapan data. Platform observabilitas seperti Databand memungkinkan hal ini, dan dapat memungkinkan Anda untuk mengatur deteksi anomali sehingga Anda tidak perlu mengatur setiap nilai secara manual.
5. Kelola: Insinyur data menguji ulang peringatan ini terhadap data jalur historis untuk memverifikasi bahwa peringatan tersebut memang berfungsi sebagaimana mestinya. Jika benar, mereka memasukkannya ke dalam produksi bersama dengan rencana manajemen insiden untuk mengetahui siapa yang bertanggung jawab saat peringatan dipicu, dan apa yang akan mereka lakukan saat menerima peringatan tersebut.
6. Verifikasi: Insinyur data dan ilmuwan data mengonfirmasi bahwa memiliki kerangka kerja manajemen data telah meningkatkan kinerja secara terukur pada metrik yang diinginkan. Analis bisnis mengkonfirmasi dengan konsumen bahwa memang demikian.

Dan apa yang Anda lakukan dengan kerangka kerja Anda? Anda mempraktikkannya.

Seperti yang telah kami jelajahi dalam banyak contoh kami, indikator terburuk dari masalah kualitas data adalah indikator yang terlambat, katakanlah, dari konsumen yang memberi tahu Anda bahwa ada sesuatu yang rusak. Begitu banyak dari apa yang kita lakukan dalam rekayasa data adalah membangun kepercayaan bersama dengan pipeline.

Dengan berinvestasi dalam kerangka kerja manajemen kualitas data yang membantu tim Anda mengidentifikasi masalah secara otomatis, Anda akan membuat data yang layak dipercaya. Dan itu membuat pekerjaan Anda jauh lebih mudah.

Jelajahi bagaimana IBM Databand memberikan pemantauan kualitas data yang lebih baik dengan mendeteksi perubahan kolom yang tidak terduga dan catatan nol untuk membantu Anda memenuhi SLA data. Jika Anda siap untuk melihat lebih dalam, pesan demo hari ini.