Làm thế nào để gỡ lỗi phân tích dữ liệu?

Tôi đã gặp phải vấn đề sau đây, rằng tôi điều chỉnh lại khá điển hình.

Tôi có một số dữ liệu lớn, giả sử, một vài triệu hàng. Tôi chạy một số phân tích không tầm thường trên nó, ví dụ như một truy vấn SQL bao gồm một số truy vấn phụ. Tôi nhận được một số kết quả, ví dụ, thuộc tính X đó đang tăng theo thời gian.

Bây giờ, có hai điều có thể dẫn đến điều đó:

1. X thực sự đang tăng theo thời gian
2. Tôi có một lỗi trong phân tích của tôi

Làm thế nào tôi có thể kiểm tra rằng lần đầu tiên xảy ra, chứ không phải lần thứ hai? Trình gỡ lỗi từng bước, ngay cả khi có tồn tại, sẽ không có ích, vì kết quả trung gian vẫn có thể bao gồm hàng triệu dòng.

Điều duy nhất tôi có thể nghĩ đến là bằng cách nào đó tạo ra một tập hợp dữ liệu nhỏ, tổng hợp với thuộc tính mà tôi muốn kiểm tra và chạy phân tích trên đó dưới dạng thử nghiệm đơn vị. Có công cụ để làm điều này? Đặc biệt, nhưng không giới hạn, SQL.

Đây là một gợi ý:

• Viết mã phân tích của bạn theo cách có thể chạy trên các mẫu phụ.
• Mã hóa một thói quen bổ sung có thể lấy mẫu, ngẫu nhiên hoặc theo thời gian hoặc theo vùng hoặc ... Đây có thể là miền cụ thể. Đây là nơi kiến ​​thức của bạn đi vào.
• Kết hợp cả hai và xem kết quả có ổn định trên các mẫu phụ không.

Đây là những gì tôi thường làm - chiếm các biến quan trọng nhất (dựa trên hiểu biết và giả thuyết kinh doanh của bạn - bạn luôn có thể sửa đổi nó sau), nhóm theo các thuộc tính này để giảm số lượng hàng, sau đó có thể được nhập vào Pivot. Bạn nên bao gồm tổng và số lượng các số liệu có liên quan trên mỗi hàng.

Đảm bảo rằng bạn không đặt bất kỳ bộ lọc nào trong bước trước. Khi bạn có toàn bộ dữ liệu ở mức tóm tắt, bạn có thể chơi xung quanh trong các bảng Pivot và xem những gì đang thay đổi / tăng hoặc giảm.

Nếu dữ liệu quá lớn để được tóm tắt ngay cả trên các tham số quan trọng, bạn cần phân vùng dữ liệu đó trong 3 - 4 tập hợp con và sau đó thực hiện lại.

Hy vọng nó giúp.

Trước tiên, bạn cần xác minh rằng việc thực hiện thuật toán của bạn là chính xác. Đối với điều đó, sử dụng một mẫu dữ liệu nhỏ và kiểm tra xem kết quả có đúng không. Ở giai đoạn này, mẫu không cần phải đại diện cho dân số.

Khi việc triển khai được xác minh, bạn cần xác minh rằng có một mối quan hệ đáng kể giữa các biến mà bạn cố gắng dự đoán. Để làm điều đó xác định giả thuyết null và cố gắng từ chối giả thuyết null với mức độ tin cậy đáng kể. ( kiểm tra giả thuyết cho hồi quy tuyến tính )

Có thể có các khung kiểm tra đơn vị cho phân phối SQL của bạn. Nhưng sử dụng ngôn ngữ lập trình như R sẽ dễ thực hiện hơn.

Tôi thích một chiến lược nhiều bước:

1. Viết mã dễ hiểu, trái ngược với mã ngắn. Tôi biết các nhà thống kê thích mã phức tạp, nhưng phát hiện ra các vấn đề trong mã phức tạp là nguy hiểm. .

2. Phân tích mã của bạn trong các chức năng nhỏ hơn, có thể được kiểm tra và đánh giá trong các stes nhỏ hơn.

3. Tìm các phần tử được kết nối, ví dụ: số trường hợp có điều kiện X là Y - vì vậy truy vấn này PHẢI trả về Y. Thông thường, điều này phức tạp hơn, nhưng có thể thực hiện được.

4. Khi bạn đang chạy tập lệnh của mình lần đầu tiên, hãy kiểm tra nó với một mẫu nhỏ và kiểm tra cẩn thận xem mọi thứ có theo thứ tự không. Mặc dù tôi thích các bài kiểm tra đơn vị trong CNTT, các lỗi trong tập lệnh thống kê thường được phát âm đến mức chúng có thể dễ dàng nhìn thấy khi kiểm tra cẩn thận. Hoặc chúng là các lỗi phương pháp, có lẽ không bao giờ bị bắt bởi các bài kiểm tra đơn vị.

Điều đó đủ để đảm bảo một công việc "một lần" sạch sẽ. Nhưng đối với một chuỗi thời gian như bạn có, tôi sẽ nói thêm rằng bạn nên kiểm tra các giá trị ngoài phạm vi, các kết hợp không thể, v.v. Đối với tôi, hầu hết các tập lệnh đã đạt đến bước 4 có thể không có lỗi - và chúng sẽ giữ nguyên như vậy trừ khi một cái gì đó thay đổi. Và thường xuyên nhất, dữ liệu đang thay đổi - và đó là thứ cần được kiểm tra cho mỗi lần chạy. Viết mã cho điều đó có thể tốn thời gian và phiền toái, nhưng nó đánh bại các lỗi tinh vi do lỗi nhập dữ liệu.