대규모 데이터 세트에 대한 탐색 적 분석을 유지하는 방법은 무엇입니까?

큰 데이터 세트 (많은 샘플, 많은 변수)에 대한 탐색 적 분석을 시작할 때 종종 수백 개의 파생 변수와 톤의 다른 플롯으로 나 자신을 발견하며 실제 상황을 추적 할 수있는 방법이 없습니다. 처음부터 방향이 없기 때문에 코드는 스파게티처럼 끝납니다.

탐색 적 분석을 깔끔하고 깔끔하게 유지하기 위해 권장되는 방법이 있습니까? 특히, 여러 가지 탐사 지점 (데드 엔드였던 지점 포함)과 다른 버전의 음모를 어떻게 처리합니까?

참고로, 나는 지구 과학 데이터 (시간이 지남에 따라, 때로는 공간에 걸쳐 많은 변수)를 연구하고 있습니다. 나는 보통 Python 또는 R로 작업하고 모든 것을 git에 저장하고 IPython Notebook도 시험해 보았습니다. 그러나 다른 유형의 (대형) 데이터를 가진 모든 분야의 사람들에게 답이 다소 일반 적이고 유용 하다면 좋을 것 입니다.

나는 종종 당신이 탐구 적 분석을 통해 토끼 구멍을 밟은 것처럼 느끼는 경향은 당신이 묻는 실질적인 질문이 보이지 않기 때문이라고 생각합니다. 나는 때때로 스스로 해본 다음 나의 목표가 무엇인지 상기시켜야한다. 예를 들어, 특정 모델을 만들거나 기존 모델의 적합성을 평가하려고합니까? 데이터 문제의 증거 (예 : 법의학 데이터 분석)를 찾고 있습니까? 아니면 공식적인 모델을 개발하기 전에 비공식적으로 특정 질문을 조사하는 (예 : 두 변수 사이의 관계가 있는가) 분석 초기 단계입니까? 요약하면, 도표와 표를 작성하는 데 관심이 있지만 직접적인 목표가 무엇인지 또는 그 도표 / 표가 왜 관련이 있는지 명확하게 설명 할 수 없다면,

프로그램을 작성하든 기사를 작성하든, 작성하는 것처럼 탐색 적 데이터 분석에 접근하려고합니다. 두 경우 모두 먼저 개요를 작성하지 않고 시작하지 않습니다. 물론 그 개요는 변경 될 수 있고 자주 발생하지만, 작성하지 않고 쓰기를 시작하는 것은 비효율적이며 종종 최종 제품의 품질이 좋지 않습니다.

WRT 조직의 각 분석가는 자신에게 적합한 워크 플로를 찾아야합니다. 따라서 다른 사람의 워크 플로를 엄격하게 따르는 것보다 IMO가 더 중요합니다. 프로그래밍 방식으로 작업 (즉, 결과 집합을 생성 / 재생하기 위해 실행할 수있는 코드 작성)하고 작업을 git으로 검사하는 경우 이미 많은 측면에서 앞서 있습니다. 코드를 구성하는 데 시간을 할애해야 할 것 같으므로 개요를 따르는 것이 좋습니다. 예를 들어, 분석 파일을 비교적 짧고 대상으로 지정하여 각각 하나의 특정 질문 (예 : 특정 회귀 모델에 대한 진단 그림)에 답할 수 있습니다. 프로젝트의 규모와 복잡성에 따라 이들을 하나 또는 두 개의 수준으로 하위 디렉토리로 구성하십시오. 이런 방식으로 프로젝트는 자체 문서화됩니다. 디렉토리, 서브 디렉토리 및 파일의 목록보기 (각 파일의 맨 위에있는 주석과 함께)는 이론적으로 개요를 재현해야합니다.

물론 대규모 프로젝트에는 데이터 정리 및 관리를 수행하는 코드, 특정 유형의 모델을 추정하기 위해 작성한 코드 또는 작성한 다른 유틸리티가있을 수 있으며 이는 실질적인 범위에 맞지 않습니다. 데이터 분석에 대한 개요를 제공하므로 프로젝트 폴더의 다른 부분에 정리해야합니다.

업데이트 :이 게시물을 게시 한 후 "데드 엔드"에 대한 귀하의 질문을 직접 처리하지 않았다는 것을 깨달았습니다. 전체 분석 세트가 가치가 없다고 결정한 경우 git에서 작업하는 경우 "이 분석 라인을 포기하지 않았으므로이 분석 라인을 포기했습니다"라는 커밋 메시지를 사용하여 해당 파일을 항상 삭제할 수 있습니다 생산적인." 작성한 내용을 찌그러 뜨리고 휴지통에 버리는 것과는 달리 원하는 경우 언제든지 나중에 한 작업으로 돌아갈 수 있습니다.

그러나 생각을 한 개요에서 진행하면 소위 막 다른 골목이 줄어 듭니다. 대신 가치 있고 관련성있는 질문을 조사하는 데 시간을 허비하더라도 (이것이 널 (null)의 발견으로 이어 지거나 예상대로 나타나지 않는 경우에도) 수행 한 결과와 결과 ( 나중에 이것을 반복하는 실수를하지 않도록 최소). "부록"의 일종으로 개요의 맨 아래로 이동하십시오.

일반적인 답변이 얼마나 도움이 될지 모르겠습니다. 어려운 일을하는 방법을 묻는 것입니다. 좋은 대답은 아마도 훈련에 달려 있고 아마도 길고 미묘한 차이가있을 것입니다. :)

조직이 진행되는 한 이미 git을 사용하고 있으므로 다음으로 makefile 을 사용 하여 분석을 시작해야합니다 . makefile은 서로 다른 파일이 서로 어떻게 종속되는지 (즉, 어떤 통계가 어떤 코드에서 파생되는지) 그리고 호출 할 때 make업데이트해야 할 모든 것이 배치됩니다.

이제는 탐색 적 부분에 도움이되지 않습니다. EDA의 경우 ESS를 통해 emacs에서 주로 R을 사용합니다. EDA를위한 REPL이 필요합니다. 내 워크 플로는 ESS ( exploratory.R유형 파일)의 플롯, 추정값 등으로 재생하고 유지하려는 항목을 결정한 다음 make로 일괄 실행되도록 다시 코딩하는 것입니다. Re : git, 어떻게 사용하는지 모르겠지만 각 프로젝트마다 단일 저장소 (보통 단일 종이)를 사용하고 깨끗한 역사를 유지하기 위해 코드베이스에서 지옥을 리베이스하십시오. 즉 나는 사용한다

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

방법 보다 내가 자식을 시작하고 때보 방법 보다 내가 초보자를 추천 것보다. 이러한 모든 명령과 옵션에 익숙하지 않은 경우 더 많은 git을 배우고 싶을 수도 있습니다. 가장 큰 도움이 된 것은 논리적으로 뚜렷한 커밋을 만드는 것에 대한 훈련을받는 것입니다. 즉, 모든 커밋에는 나중에 한 번에 모두 취소 할 수있는 모든 변경 사항이 포함되어야합니다.

실제로 데이터를 탐색하는 한이 책은 도움이되고 흥미 로웠으며 특히 큰 데이터 세트 (적어도 부분적으로)를 처리합니다.

• Unwin, Theus 및 Hofmann이 편집 한 대용량 데이터 세트의 그래픽 . 액세스 권한이 있다면 springerlink를 통해 , 그렇지 않으면 인터넷 검색을 통해 개별 챕터를 사용할 수 있습니다.

• Chen, Härdle 및 Unwin이 편집 한 데이터 시각화 핸드북 . 또한 springerlink를 통해

• Huber의 데이터 분석 (2011) ..

두 단어 : 개념지도. 그것이 큰 데이터 세트 또는 실제로 복잡한 개념을 나누고 정복하는 유일한 방법입니다. http://en.wikipedia.org/wiki/Concept_maps

개인적으로, 나는 화면보다 종이에 더 잘 생각하기 때문에 기본 분석을 시작하기 전에 내가 다루고있는 것을 매핑하는 것이 좋습니다. 보다 전문적인 다이어그램을 위해 많은 마인드 매핑 소프트웨어가 있습니다 : http://en.wikipedia.org/wiki/List_of_concept-_and_mind-mapping_software

마인드 매핑에는 몇 가지 장점이 있습니다.

• "핵심"변수와 파생 변수 (있는 경우)의 관점에서 내가 가진 것을 알려줍니다
• 이론 / 논리에 기반한 모델의 구성 / 제형
• 핵심 변수 사이의 관계가 내가 생각하는 것처럼 펼쳐지지 않으면 내가 누락 할 수있는 변수 및 / 또는 추가 할 수있는 변수를 가리 킵니다.

편집 :

예를 들어, 여기 요인 분석에 대한 개념지도는 다음과 같습니다 http://www.metacademy.org/graphs/concepts/factor_analysis#focus=factor_analysis&mode=explore 지금 이것은 순전히, 개념을 학습 분석을 수행하지 않는, 그러나 아이디어 똑같다 : 미리 이해하고 행동을 취해야한다.

이 코드의 자동화 된 / 코딩 된 버전을 찾고 있다면 존재하지 않는 것 같습니다. 시스템을 이해하려고 할 때 모델링 개념을 자동화 할 수 없습니다. (그리고 그것은 많은 사람들을 직장에서 퇴출시킬 것이기 때문에 좋은 일입니다.)

이미 git을 사용하고 있습니다. 버전 관리를 사용하여 탐색을 구성하지 않는 이유는 무엇입니까? 탐색의 새 "분기"마다 새 분기를 만들고 다른 버전의 플롯에 대해 분기를 분기합니다. 이 방법을 사용하면 최종 결과를 결합하기가 약간 어려워 지지만 분석의 "보석"에 빠질 수있는 추적되지 않은 디렉토리를 항상 유지할 수 있습니다. 어떤 포크 / 커밋에서 왔는지 표시하기 위해이 디렉토리에 파일에 레이블을 붙이고 싶을 것입니다. 이 방법은 diff명령을 통해 다른 분석을 쉽게 대조 할 수있는 이점이 있습니다.

비슷한 문제가 발생하는 비즈니스 인텔리전스 도구를 살펴 보겠습니다. 특히 (데이터웨어 하우스, 차원 분석) 계층 및 드릴 다운.

기본 아이디어는 기본 데이터를 집계 가능한 수량 (예 : 백분율이 아닌 개수, 수입 등)으로 나타내려고한다는 것입니다. 그런 다음 세부 사항 (예 : 월 / 주 / ...)에 대해 집계 할 계층을 설계합니다. 이를 통해 모든 데이터에 대한 간단한 개요를보고 특정 영역을 확대 할 수 있습니다. 예를 들어 http://cubes.databrewery.org/(python ) 또는 엑셀 파워 피벗 참조