Bagaimana cara men-debug analisis data?


10

Saya telah menemukan masalah berikut, yang saya rekomendasikan agak khas.

Saya punya beberapa data besar, katakanlah, beberapa juta baris. Saya menjalankan beberapa analisis non-sepele, misalnya query SQL yang terdiri dari beberapa sub-query. Saya mendapatkan beberapa hasil, dengan menyatakan, misalnya, bahwa properti X meningkat dari waktu ke waktu.

Sekarang, ada dua hal yang mungkin bisa mengarah pada itu:

  1. X memang meningkat seiring waktu
  2. Saya memiliki bug dalam analisis saya

Bagaimana saya bisa menguji bahwa yang pertama terjadi, bukan yang kedua? Debugger langkah-bijaksana, bahkan jika ada, tidak akan membantu, karena hasil antara masih dapat terdiri dari jutaan baris.

Satu-satunya hal yang dapat saya pikirkan adalah entah bagaimana menghasilkan set kecil, data sintetik dengan properti yang ingin saya uji dan menjalankan analisis sebagai unit test. Apakah ada alat untuk melakukan ini? Khususnya, tetapi tidak terbatas pada, SQL.


Pertanyaan bagus! Saya pikir ini adalah masalah penting dan non-sepele.
Ben

Jawaban:


4

Berikut ini sarannya:

  • Buat kode analisis Anda sedemikian rupa sehingga dapat dijalankan pada sub-sampel.
  • Kode rutin rutin pelengkap yang dapat dicicipi, baik secara acak, atau berdasarkan waktu, atau berdasarkan wilayah, atau ... Ini mungkin khusus domain. Di sinilah pengetahuan Anda masuk.
  • Gabungkan keduanya dan lihat apakah hasilnya stabil di seluruh subsamples.

Bukankah itu juga berarti bug saya stabil di seluruh subsamples?
Little Bobby Tables

Itu adalah hasil yang mungkin, tetapi Anda hanya akan tahu setelah Anda mencobanya. Dan jika demikian, Anda setidaknya bisa melakukan debug pada set data yang lebih kecil.
Dirk Eddelbuettel

1

Inilah yang biasanya saya lakukan - mengambil variabel yang paling penting (berdasarkan pemahaman dan hipotesis bisnis Anda - Anda selalu dapat merevisinya nanti), kelompokkan pada atribut-atribut ini untuk mengurangi jumlah baris, yang kemudian dapat diimpor ke Pivot. Anda harus memasukkan jumlah dan jumlah metrik yang relevan di setiap baris.

Pastikan Anda tidak memasukkan filter apa pun pada langkah sebelumnya. Setelah Anda memiliki seluruh data pada tingkat ringkasan, Anda bisa bermain-main di tabel Pivot dan melihat hal-hal apa yang berubah / meningkat atau menurun.

Jika data terlalu besar untuk dirangkum bahkan pada parameter penting, Anda perlu mempartisi dalam 3 - 4 himpunan bagian dan kemudian melakukan ini lagi.

Semoga ini bisa membantu.


1

Pertama, Anda perlu memverifikasi bahwa implementasi algoritma Anda akurat. Untuk itu gunakan sampel data kecil dan periksa apakah hasilnya benar. Pada tahap ini sampel tidak perlu mewakili populasi.

Setelah implementasi diverifikasi, Anda perlu memverifikasi bahwa ada hubungan yang signifikan antara variabel yang Anda coba prediksi. Untuk melakukan itu, tentukan hipotesis nol dan cobalah untuk menolak hipotesis nol dengan tingkat kepercayaan yang signifikan. ( pengujian hipotesis untuk regresi linier )

Mungkin ada kerangka kerja unit test untuk distribusi SQL Anda. Tetapi menggunakan bahasa pemrograman seperti R akan lebih mudah diimplementasikan.


1

Saya suka strategi beberapa langkah:

  1. Tulis kode yang mudah dimengerti dan bersih, dan bukan kode pendek-rumit. Saya tahu ahli statistik menyukai kode rumit, tetapi menemukan masalah dalam kode rumit berbahaya. (Saya menyebutkan ini karena penyelia saya menyukai skrip python 500 baris tidak berdokumen - bersenang-senang men-debug kekacauan itu dan saya telah melihat pola itu banyak, terutama dari orang-orang yang bukan dari latar belakang IT)

  2. Hancurkan kode Anda dalam fungsi yang lebih kecil, yang dapat diuji dan dievaluasi dalam ukuran yang lebih kecil.

  3. Cari elemen yang terhubung, misalnya jumlah kasus dengan kondisi X adalah Y - jadi permintaan ini HARUS mengembalikan Y. Paling sering ini lebih kompleks, tetapi dapat dilakukan.

  4. Ketika Anda menjalankan skrip Anda pertama kali, uji dengan subsampel kecil dan hati-hati memeriksa apakah semuanya beres. Sementara saya menyukai tes unit dalam TI, bug dalam skrip statistik sering kali diucapkan sehingga mudah dilihat dengan melakukan pengecekan dengan cermat. Atau mereka adalah kesalahan metodis, yang mungkin tidak pernah ditangkap oleh unit test.

Itu sudah cukup untuk memastikan pekerjaan "satu kali" yang bersih. Tetapi untuk rangkaian waktu seperti yang tampaknya Anda miliki, saya akan menambahkan bahwa Anda harus memeriksa nilai di luar kisaran, kombinasi mustahil dll. Bagi saya, sebagian besar skrip yang telah mencapai langkah 4 mungkin bebas bug - dan mereka akan tetap seperti itu kecuali sesuatu berubah. Dan yang paling sering, data berubah - dan itu adalah sesuatu yang harus diperiksa untuk setiap proses. Menulis kode untuk itu bisa memakan waktu dan menyebalkan, tetapi mengalahkan kesalahan halus karena kesalahan entri data.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.