Làm thế nào để giữ cho các phân tích thăm dò của các bộ dữ liệu lớn trong kiểm tra?


22

Khi tôi bắt đầu phân tích khám phá trên một tập dữ liệu lớn (nhiều mẫu, nhiều biến), tôi thường thấy mình có hàng trăm biến xuất phát và hàng tấn các ô khác nhau và không có cách nào thực sự để theo dõi những gì đang diễn ra. Mã kết thúc như spaghetti, bởi vì không có hướng từ đầu ...

Có bất kỳ phương pháp được đề nghị để giữ cho một phân tích thăm dò gọn gàng và ngăn nắp? Cụ thể, làm thế nào để bạn đối phó với nhiều nhánh khám phá (bao gồm cả những nhánh đã chết) và với các phiên bản khác nhau của âm mưu?


Để tham khảo, tôi đang làm việc trên dữ liệu địa chất (nhiều biến theo thời gian, đôi khi cũng theo không gian). Tôi thường làm việc với Python hoặc R và lưu trữ mọi thứ trong git và cũng đã dùng thử IPython Notebook. Tuy nhiên, sẽ tốt nếu câu trả lời có phần chung chung và hữu ích cho mọi người trong tất cả các lĩnh vực, với các loại dữ liệu (lớn?) Khác.


1
Tôi sẽ tưởng tượng rất nhiều lời khuyên bạn nhận được sẽ có thể áp dụng như nhau cho các nghiên cứu mô phỏng được thiết kế để đánh giá các phương pháp dự đoán hoặc dự đoán cạnh tranh.
xác suất

1
Vâng, câu trả lời này có lẽ cũng cần phải đọc: stats.stackexchange.com/questions/2910/ . Tôi đã nghĩ rằng có thể có lời khuyên cụ thể hơn, nhưng tôi cho rằng có lẽ không thực sự.
ness101

Câu trả lời:


10

Tôi nghĩ rằng thường xuyên, xu hướng cảm thấy như bạn đã đi xuống một hố thỏ với các phân tích khám phá là do mất tầm nhìn của (các) câu hỏi thực tế mà bạn đang hỏi. Thỉnh thoảng tôi tự làm điều đó, và sau đó phải tự nhắc nhở bản thân mục tiêu của mình là gì. Ví dụ, tôi đang cố gắng xây dựng một mô hình cụ thể, hoặc đánh giá sự đầy đủ của một mô hình hiện có? Tôi có đang tìm kiếm bằng chứng về các vấn đề với dữ liệu (nghĩa là phân tích dữ liệu pháp y) không? Hoặc, đây có phải là trong giai đoạn đầu của phân tích, nơi tôi đang điều tra các câu hỏi cụ thể không chính thức (ví dụ: có mối quan hệ giữa hai biến không?) Trước khi chuyển sang phát triển một mô hình chính thức? Tóm lại, nếu bạn bắt mình phải viết ra các ô và bảng nhưng không thể nói rõ mục tiêu trước mắt của bạn là gì hoặc tại sao lô / bảng đó có liên quan, thì bạn biết bạn '

Tôi cố gắng tiếp cận phân tích dữ liệu khám phá như tôi đang viết, cho dù đó là viết một chương trình hay viết một bài báo. Trong cả hai trường hợp, tôi sẽ không bắt đầu mà không đưa ra một phác thảo đầu tiên. Tất nhiên, phác thảo đó có thể thay đổi (và thường xuyên làm như vậy), nhưng để bắt đầu viết mà không có ai là không hiệu quả, và thường mang lại một sản phẩm cuối cùng kém.

Tổ chức WRT, mỗi nhà phân tích phải tìm ra một quy trình làm việc cho anh ấy hoặc cô ấy, vì vậy IMO quan trọng hơn là cố gắng tuân theo quy trình làm việc của người khác một cách cứng nhắc (mặc dù luôn hữu ích để lấy ý tưởng từ những gì người khác đang làm). Nếu bạn đang làm việc theo chương trình (ví dụ, viết code có thể được chạy để tạo / tái tạo một tập hợp các kết quả) và kiểm tra công việc của bạn vào git, sau đó bạn đã dặm trước nhiều trong vấn đề này. Tôi nghi ngờ rằng bạn có thể chỉ cần dành một chút thời gian để tổ chức mã của mình và vì thế, tôi sẽ đề nghị theo đề cương của bạn. Ví dụ: giữ các tệp phân tích của bạn tương đối ngắn và được nhắm mục tiêu, sao cho mỗi câu trả lời một câu hỏi cụ thể (ví dụ: sơ đồ chẩn đoán cho một mô hình hồi quy cụ thể). Tổ chức chúng thành các thư mục con ở một hoặc hai cấp, tùy thuộc vào quy mô và độ phức tạp của dự án. Theo cách này, dự án trở thành tài liệu tự; một khung nhìn danh sách các thư mục, thư mục con và tệp (cùng với nhận xét ở đầu mỗi tệp), theo lý thuyết, sẽ tái tạo phác thảo của bạn.

Tất nhiên, trong một dự án lớn, bạn cũng có thể có mã quản lý và làm sạch dữ liệu, mã bạn đã viết để ước tính một loại mô hình nhất định hoặc các tiện ích khác mà bạn đã viết và chúng không phù hợp với nội dung chính phác thảo cho phân tích dữ liệu của bạn, vì vậy chúng nên được tổ chức trong một phần khác của thư mục dự án của bạn.

Cập nhật: Sau khi đăng bài này, tôi nhận ra rằng tôi đã không trực tiếp giải quyết câu hỏi của bạn về "ngõ cụt". Nếu bạn thực sự quyết định rằng toàn bộ tập hợp phân tích không có giá trị, thì nếu bạn đang làm việc trong git, bạn luôn có thể xóa (các) tệp tương ứng bằng một thông báo cam kết như "Đã bỏ dòng phân tích này vì nó không hiệu quả. " Không giống như vò nát những gì bạn đã viết và vứt nó vào thùng rác, bạn luôn có thể quay lại những gì bạn đã làm sau này, nếu muốn.

Tuy nhiên, tôi nghĩ bạn sẽ thấy rằng nếu bạn tiến hành từ một phác thảo mà bạn đã suy nghĩ, bạn sẽ có ít cái gọi là ngõ cụt hơn. Thay vào đó, nếu bạn dành thời gian để điều tra một câu hỏi có giá trị và có liên quan ngay cả khi điều này dẫn đến một kết quả không có giá trị hoặc không thành công như bạn dự đoán, bạn có thể vẫn muốn ghi lại những gì bạn đã làm và kết quả (tại tối thiểu, để bạn không phạm sai lầm lặp lại điều này sau này). Chỉ cần di chuyển chúng xuống dưới cùng của phác thảo của bạn, trong một loại "Phụ lục."


4

Tôi không biết câu trả lời chung chung sẽ hữu ích như thế nào. Bạn đang hỏi làm thế nào để làm một cái gì đó khó khăn; câu trả lời tốt có thể sẽ phụ thuộc vào kỷ luật và có thể sẽ dài và sắc thái. :)

Theo như tổ chức, bạn đã sử dụng git, vì vậy tiếp theo bạn nên bắt đầu sử dụng tệp tạo tệp để thực hiện phân tích. Makefile đưa ra cách các tệp khác nhau phụ thuộc vào nhau (nghĩa là thống kê nào được lấy từ mã nào) và khi bạn gọi make, mọi thứ cần được cập nhật sẽ.

Bây giờ, điều đó không giúp ích gì với phần khám phá. Đối với EDA tôi sử dụng (chủ yếu) R trong emacs thông qua ESS. Bạn cần cần REPL cho EDA. Quy trình công việc của tôi là chơi với các ô, ước tính, v.v. trong ESS (trong một exploratory.Rtệp loại), quyết định những gì tôi muốn giữ, sau đó mã hóa lại để nó có thể được thực thi theo lô. Re: git, tôi không biết bạn đang sử dụng nó như thế nào, nhưng tôi sử dụng một kho lưu trữ duy nhất cho mỗi dự án (thường là một tờ giấy) và loại bỏ địa ngục khỏi cơ sở mã của tôi để giữ một lịch sử sạch sẽ; tức là tôi sử dụng

$ git merge meandering-branch --squash
$ git add -p somefile
$ git rebase -i master
$ git reset HEAD --hard

cách hơn khi tôi bắt đầu với git, và cách hơn tôi khuyên bạn nên một người mới bắt đầu. Nếu bạn không quen thuộc với tất cả các lệnh và tùy chọn đó, bạn có thể muốn tìm hiểu thêm git. Điều lớn nhất giúp tôi là kỷ luật về việc đưa ra các cam kết khác biệt về mặt logic; tức là mọi cam kết sẽ chứa tất cả các thay đổi mà bạn có thể muốn hoàn tác tất cả cùng một lúc trong tương lai (và không nhiều hơn hoặc ít hơn).

Theo như thực sự khám phá dữ liệu, tôi đã thấy những cuốn sách này hữu ích và thú vị, và chúng xử lý cụ thể với các bộ dữ liệu lớn (ít nhất là một phần):

  • Đồ họa của các bộ dữ liệu lớn , được chỉnh sửa bởi Unwin, Theus và Hofmann. thông qua springerlink nếu bạn có quyền truy cập, nếu không các chương riêng lẻ có thể có sẵn bằng cách googling.

  • Cẩm nang trực quan hóa dữ liệu , được chỉnh sửa bởi Chen, Härdle và Unwin. cũng thông qua springerlink

  • Phân tích dữ liệu của Huber (2011) ..


3

Hai từ: bản đồ khái niệm. Đó là cách hiệu quả duy nhất tôi tìm thấy để phân chia và chinh phục các tập dữ liệu lớn hoặc bất kỳ khái niệm nào thực sự gây khó chịu. http://en.wikipedia.org/wiki/Concept_maps

Cá nhân, tôi nghĩ trên giấy tốt hơn trên màn hình, vì vậy tôi chỉ quan tâm đến bản đồ những gì tôi đang xử lý trước khi tôi bắt đầu thực hiện bất kỳ phân tích cơ bản nào. Đối với một sơ đồ chuyên nghiệp hơn, có rất nhiều phần mềm bản đồ tư duy http://en.wikipedia.org/wiki/List_of_concept-_and_mind-mapping_software

Sơ đồ tư duy có một số lợi thế:

  • cho tôi biết những gì tôi có về các biến "cốt lõi" và các biến xuất phát (nếu có)
  • cho phép tổ chức / xây dựng mô hình dựa trên lý thuyết / logic
  • chỉ ra những biến nào tôi có thể thiếu và / hoặc có thể thêm nếu mối quan hệ giữa các biến cốt lõi không được triển khai như tôi nghĩ chúng nên

Chỉnh sửa :

Ví dụ, đây là bản đồ khái niệm để phân tích nhân tố: http://www.metacademy.org/graphs/con accept / factor_analysis # f Focus = factor_analysis & mode = explore Bây giờ đây hoàn toàn là để tìm hiểu khái niệm, không thực hiện phân tích, nhưng ý tưởng là như nhau: vạch ra trước thời hạn những gì nó có ý nghĩa để làm, và sau đó làm nó.

Nếu bạn đang tìm kiếm một phiên bản tự động / được mã hóa này, tôi không nghĩ rằng nó tồn tại. Bạn không thể tự động hóa khái niệm mô hình hóa khi bạn đang cố gắng hiểu một hệ thống. (Và đó là một điều tốt vì nó sẽ khiến nhiều người mất việc.)


Hrm ... Điều này có thể làm với một ví dụ chi tiết hơn. Tôi gặp khó khăn khi thấy điều này sẽ giúp giải quyết sự phức tạp mà tôi đang nói đến. Cụ thể, nó không giúp giải quyết những gì cần làm với các phân tích (dữ liệu dẫn xuất, các lô, v.v.) từ các đường dẫn điều tra dẫn đến ngõ cụt.
ness101

Bản đồ khái niệm được thiết kế để chỉ điều tra các đường dẫn sẽ dẫn đến một nơi nào đó dựa trên lý thuyết cụ thể về vấn đề. Nếu nó chỉ ra rằng một cuộc điều tra cụ thể không đi đến đâu, bạn hãy ghi chú nó trên bản đồ khái niệm bởi vì đó là danh sách hướng dẫn / việc cần làm của bạn. Từ đó, bạn sẽ thấy ngay các biến xuất phát bị ảnh hưởng và những điều tra nào khác bạn có thể thử.
rocinante

3

Bạn đã sử dụng git: tại sao không sử dụng kiểm soát phiên bản để tổ chức khám phá của bạn? Tạo một nhánh mới cho mỗi "nhánh" khám phá mới của bạn và cũng rẽ nhánh cho các phiên bản khác nhau của các ô. Phương pháp này sẽ khiến việc kết hợp các kết quả cuối cùng của bạn trở nên khó khăn hơn một chút, nhưng bạn luôn có thể duy trì một thư mục không bị theo dõi, nơi bạn có thể thả vào "viên ngọc" trong phân tích của mình. Bạn có thể muốn bằng cách nào đó gắn nhãn các tệp của bạn trong thư mục này để cho biết họ đến từ ngã ba / cam kết nào. Phương pháp này có thêm lợi ích là làm cho nó thực sự dễ dàng tương phản các phân tích khác nhau thông qua difflệnh.


1

Tôi sẽ xem xét các công cụ Business Intelligence ... nơi phát sinh các vấn đề tương tự. Cụ thể (kho dữ liệu, phân tích thứ nguyên,) phân cấp và khoan sâu.

Ý tưởng cơ bản là bạn cố gắng biểu thị dữ liệu cơ bản của mình dưới dạng số lượng tổng hợp (số lượng, thu nhập, v.v. chứ không phải là tỷ lệ phần trăm). Sau đó, bạn thiết kế hệ thống phân cấp để tổng hợp qua các chi tiết (ví dụ: tháng / tuần / ...). Điều này cho phép bạn có tổng quan đơn giản về tất cả dữ liệu của mình và sau đó phóng to các khu vực cụ thể. xem ví dụ: http://cubes.databrewery.org/ (python) hoặc trục điện excel

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.