데이터 과학에 무엇이 잘못될 수 있나요? 데이터 수집

오늘날 100500개의 데이터 과학 과정이 있으며 데이터 과학에서 가장 많은 돈을 데이터 과학 과정을 통해 얻을 수 있다는 것이 오랫동안 알려져 왔습니다(삽을 팔 수 있는데 왜 땅을 파나요?). 이 코스의 가장 큰 단점은 실제 작업과 아무 관련이 없다는 것입니다. 아무도 깨끗하고 처리된 데이터를 필요한 형식으로 제공하지 않습니다. 그리고 코스를 떠나 실제 문제를 해결하기 시작하면 많은 뉘앙스가 나타납니다.

따라서 우리는 나와 내 동료, 동료들에게 일어난 실제 사건을 바탕으로 "데이터 과학에서 무엇이 잘못될 수 있는가"라는 일련의 노트를 시작합니다. 실제 사례를 사용하여 일반적인 데이터 과학 작업을 분석합니다. 이것이 실제로 어떻게 발생하는지 살펴보겠습니다. 오늘은 데이터 수집 작업부터 시작해 보겠습니다.

그리고 사람들이 실제 데이터로 작업을 시작할 때 가장 먼저 실수하는 것은 실제로 우리에게 가장 관련성이 높은 데이터를 수집하는 것입니다. 이 기사의 핵심 메시지는 다음과 같습니다.

우리는 데이터를 수집, 정리 및 준비하는 데 필요한 시간, 리소스 및 노력을 체계적으로 과소평가합니다.

그리고 가장 중요한 것은 이를 방지하기 위해 무엇을 해야 하는지 논의할 것입니다.

다양한 추정에 따르면 정리, 변환, 데이터 처리, 기능 엔지니어링 등에 80~90%의 시간이 소요되고 분석에는 10~20%의 시간이 소요되는 반면, 거의 모든 교육 자료는 분석에만 중점을 두고 있습니다.

대표적인 예로 세 가지 버전의 간단한 분석 문제를 살펴보고 "악화되는 상황"이 무엇인지 살펴보겠습니다.

그리고 예를 들어 다음과 같은 데이터 수집 및 커뮤니티 비교 작업의 유사한 변형을 다시 고려해 보겠습니다.

1. Reddit 하위 레딧 XNUMX개
2. Habr의 두 섹션
3. Odnoklassniki의 두 그룹

이론상의 조건부 접근 방식

사이트를 열고 예제를 읽어보세요. 명확하다면 읽기에 몇 시간, 예제를 사용하여 코드를 디버깅하는 데 몇 시간을 투자하세요. 수집하는 데 몇 시간이 추가됩니다. 몇 시간을 예비로 투자하세요(XNUMX를 곱하고 N시간을 더하세요).

핵심 사항: 예상 시간은 소요 시간에 대한 가정과 추측을 기반으로 합니다.

위에서 설명한 조건부 문제에 대해 다음 매개변수를 추정하여 시간 분석을 시작해야 합니다.

• 데이터의 크기는 얼마이며 물리적으로 수집해야 하는 데이터의 양은 얼마입니까(*아래 참조*).
• 한 기록의 수집 시간은 얼마나 되며, 두 번째 기록을 수집하려면 얼마나 기다려야 합니까?
• 상태를 저장하고 모든 것이 실패하는 경우가 아닌 경우 재시작을 시작하는 코드 작성을 고려해보세요.
• 승인이 필요한지 파악하고 API를 통해 액세스 권한을 얻는 시간을 설정하세요.
• 데이터 복잡성의 함수로 오류 수를 설정합니다. 특정 작업에 대해 평가합니다(구조, 변환 수, 추출 대상 및 방법).
• 비표준 프로젝트 동작과 관련된 네트워크 오류 및 문제를 수정합니다.
• 필요한 기능이 문서에 있는지 평가하고 그렇지 않은 경우 해결 방법과 양이 얼마나 필요한지 평가하십시오.

가장 중요한 것은 시간을 추정하려면 실제로 "실시 중인 정찰"에 시간과 노력을 투자해야 한다는 것입니다. 그래야만 계획이 적절할 것입니다. 따라서 "데이터를 수집하는 데 시간이 얼마나 걸리나요?"라고 아무리 강요하더라도 예비 분석을 위해 시간을 벌고 문제의 실제 매개 변수에 따라 시간이 얼마나 달라질지 논쟁해 보세요.

이제 그러한 매개변수가 변경되는 구체적인 예를 보여 드리겠습니다.

요점: 추정은 작업의 범위와 복잡성에 영향을 미치는 주요 요소에 대한 분석을 기반으로 합니다.

추측 기반 추정은 기능적 요소가 충분히 작고 문제 설계에 크게 영향을 미칠 수 있는 요소가 많지 않은 경우 좋은 접근 방식입니다. 하지만 다수의 데이터 사이언스 문제의 경우에는 그러한 요소가 엄청나게 많아져서 그러한 접근 방식은 부적절해집니다.

Reddit 커뮤니티 비교

가장 간단한 경우부터 시작해 보겠습니다(나중에 밝혀지겠지만). 일반적으로 솔직하게 말하면 거의 이상적인 경우가 있습니다. 복잡성 체크리스트를 확인해 보겠습니다.

• 깔끔하고 명확하며 문서화된 API가 있습니다.
• 매우 간단하며 가장 중요한 것은 토큰이 자동으로 획득된다는 것입니다.
• 이 파이썬 래퍼 - 예가 많아요.
• Reddit에서 데이터를 분석하고 수집하는 커뮤니티(Python 래퍼 사용 방법을 설명하는 YouTube 동영상까지 포함) 예를 들면.
• 우리에게 가장 필요한 메소드는 API에 존재할 가능성이 높습니다. 게다가 코드가 간결하고 깔끔해 보입니다. 아래는 게시물에 대한 댓글을 수집하는 함수의 예입니다.

def get_comments(submission_id):
    reddit = Reddit(check_for_updates=False, user_agent=AGENT)
    submission = reddit.submission(id=submission_id)
    more_comments = submission.comments.replace_more()
    if more_comments:
        skipped_comments = sum(x.count for x in more_comments)
        logger.debug('Skipped %d MoreComments (%d comments)',
                     len(more_comments), skipped_comments)
    return submission.comments.list()

에서 가져온 이 포장을 위한 편리한 유틸리티 선택.

이것이 최선의 경우라는 사실에도 불구하고 실제 생활에서 여러 가지 중요한 요소를 고려할 가치가 있습니다.

• API 제한 - 데이터를 일괄적으로 가져와야 합니다(요청 간 대기 등).
• 수집 시간 - 완전한 분석과 비교를 위해 거미가 하위 레딧을 통과하는 데만 상당한 시간을 확보해야 합니다.
• 봇은 서버에서 실행되어야 합니다. 노트북에서 실행하고 배낭에 넣고 비즈니스를 수행할 수는 없습니다. 그래서 VPS에서 모든 것을 실행했습니다. 프로모션 코드 habrahabr10을 사용하면 비용의 10%를 추가로 절약할 수 있습니다.
• 일부 데이터의 물리적 접근 불가능성(관리자가 볼 수 있거나 수집하기가 너무 어려움) - 이를 고려해야 하며 원칙적으로 모든 데이터가 적절한 시간 내에 수집될 수는 없습니다.
• 네트워크 오류: 네트워킹은 고통스럽습니다.
• 이것은 살아있는 실제 데이터이며 결코 순수하지 않습니다.

물론 이러한 뉘앙스를 개발에 포함시키는 것이 필요합니다. 구체적인 시간/요일은 개발 경험이나 유사한 작업에 대한 경험에 따라 달라집니다. 그러나 여기서는 작업이 순전히 엔지니어링이며 해결하기 위해 추가적인 신체 움직임이 필요하지 않다는 것을 알 수 있습니다. 모든 것이 매우 잘 평가되고, 예약되고 완료될 수 있습니다.

Habr 섹션 비교

Habr의 스레드 및/또는 섹션을 비교하는 보다 흥미롭고 중요하지 않은 사례로 넘어가겠습니다.

복잡성 체크리스트를 확인해 보겠습니다. 여기에서 각 요점을 이해하려면 작업 자체를 조금 더 자세히 살펴보고 실험해야 합니다.

• 처음에는 API가 있다고 생각하지만 그렇지 않습니다. 예, 예, Habr에는 API가 있지만 사용자가 액세스할 수 없습니다(또는 전혀 작동하지 않을 수도 있습니다).
• 그런 다음 html - "가져오기 요청" 구문 분석을 시작합니다. 무엇이 잘못될 수 있습니까?
• 어쨌든 구문 분석하는 방법은 무엇입니까? 가장 간단하고 가장 자주 사용되는 접근 방식은 ID를 반복하는 것입니다. 가장 효율적이지 않으며 다양한 경우를 처리해야 한다는 점에 유의하세요. 다음은 모든 기존 ID 중에서 실제 ID의 밀도에 대한 예입니다.

  
  에서 가져온 이 기사.

• 웹 위에 HTML로 싸인 원시 데이터는 고통스럽습니다. 예를 들어, 기사의 평가를 수집하고 저장하려고 합니다. HTML에서 점수를 떼어내고 추가 처리를 위해 숫자로 저장하기로 결정했습니다. 

  1) int(score)에서 오류가 발생합니다. Habré에는 "-5" 줄과 같이 마이너스가 있으므로 마이너스 기호가 아닌 엔 대시입니다(예기치 않게 그렇죠?). 어떤 시점에서는 그런 끔찍한 수정으로 파서에 생명을 불어넣어야 했습니다.

  try:
        score_txt = post.find(class_="score").text.replace(u"–","-").replace(u"+","+")
        score = int(score_txt)
        if check_date(date):
          post_score += score
  

  날짜, 플러스 및 마이너스가 전혀 없을 수 있습니다(위의 check_date 함수에서 볼 수 있듯이 이런 일이 발생했습니다).

  2) 이스케이프되지 않은 특수 문자 - 특수 문자가 올 것이므로 준비가 필요합니다.

  3) 포스트의 종류에 따라 구조가 달라집니다.

  4) 이전 게시물은 **이상한 구조**를 가질 수 있습니다.

• 기본적으로 오류 처리 및 발생할 수 있는 일과 발생하지 않을 수 있는 일을 처리해야 하며 무엇이 잘못될지, 구조가 어떻게 될지, 무엇이 어디서 떨어질지 확실히 예측할 수 없습니다. 단지 시도하고 고려해야 할 것입니다. 파서가 던지는 오류.
• 그런 다음 여러 스레드에서 구문 분석해야 한다는 것을 깨닫게 됩니다. 그렇지 않으면 하나의 스레드에서 구문 분석하는 데 30시간 이상이 소요됩니다(이는 순전히 이미 작동 중인 단일 스레드 구문 분석기의 실행 시간이며, 잠자기 상태이며 어떤 금지에도 해당되지 않습니다). 안에 이 기사에서 이는 어느 시점에서 유사한 계획으로 이어졌습니다.

복잡성별 전체 체크리스트:

• 네트워크 작업 및 HTML 구문 분석을 반복하고 ID로 검색합니다.
• 이기종 구조의 문서.
• 코드가 쉽게 빠질 수 있는 곳이 많습니다.
• ||를 작성해야 합니다 || 암호.
• 필요한 문서, 코드 예제 및/또는 커뮤니티가 누락되었습니다.

이 작업에 소요되는 예상 시간은 Reddit에서 데이터를 수집하는 데 소요되는 시간보다 3~5배 더 길어집니다.

Odnoklassniki 그룹의 비교

설명된 기술적으로 가장 흥미로운 사례로 넘어가겠습니다. 나에게는 그것이 흥미로웠는데, 언뜻 보면 꽤 사소해 보이지만 막대기를 찌르는 순간 전혀 그렇지 않다는 것이 밝혀졌기 때문이다.

난이도 체크리스트부터 시작해서 그 중 많은 체크리스트가 처음에 보았던 것보다 훨씬 더 어려울 것이라는 점을 알아두세요.

• API가 있지만 필요한 기능이 거의 완전히 부족합니다.
• 특정 기능에 대해서는 메일로 액세스를 요청해야 합니다. 즉, 액세스 권한 부여가 즉시 이루어지지 않습니다.
• 그것은 끔찍하게 문서화되어 있습니다 (처음에는 러시아어와 영어 용어가 모든 곳에서 섞여 있고 완전히 일관성이 없습니다. 때로는 어딘가에서 원하는 것이 무엇인지 추측해야합니다). 또한 디자인은 예를 들어 데이터를 얻는 데 적합하지 않습니다. , 우리에게 필요한 기능.
• 문서에는 세션이 필요하지만 실제로는 사용하지 않습니다. 그리고 API 모드의 모든 복잡성을 이해하고 무언가가 작동할 것이라고 기대하는 것 외에는 방법이 없습니다.
• 사례도 없고 커뮤니티도 없으며 정보 수집에 있어 유일한 지원 지점은 소규모입니다. 싸개 Python에서(사용 사례가 많지 않음)
• 필요한 데이터 중 많은 부분이 잠겨 있기 때문에 Selenium이 가장 실행 가능한 옵션인 것 같습니다.
  1) 즉, 가상의 사용자(및 직접 등록)를 통해 인증이 이루어집니다.

  2) 그러나 Selenium을 사용하면 정확하고 반복 가능한 작업이 보장되지 않습니다(적어도 ok.ru의 경우 확실히).

  3) Ok.ru 웹사이트에는 JavaScript 오류가 포함되어 있으며 때때로 이상하고 일관되지 않게 동작합니다.

  4) 페이지 매김, 요소 로드 등을 수행해야 합니다.

  5) 래퍼가 제공하는 API 오류는 예를 들어 다음과 같이 어색하게 처리되어야 합니다(실험 코드 조각).

  def get_comments(args, context, discussions):
      pause = 1
      if args.extract_comments:
          all_comments = set()
  #makes sense to keep track of already processed discussions
          for discussion in tqdm(discussions): 
              try:
                  comments = get_comments_from_discussion_via_api(context, discussion)
              except odnoklassniki.api.OdnoklassnikiError as e:
                  if "NOT_FOUND" in str(e):
                      comments = set()
                  else:
                      print(e)
                      bp()
                      pass
              all_comments |= comments
              time.sleep(pause)
          return all_comments
  

  내가 가장 좋아하는 실수는 다음과 같습니다.

  OdnoklassnikiError("Error(code: 'None', description: 'HTTP error', method: 'discussions.getComments', params: …)”)

  6) 궁극적으로 Selenium + API가 가장 합리적인 옵션으로 보입니다.

• 상태를 저장하고 시스템을 다시 시작해야 하며 사이트의 일관되지 않은 동작을 포함하여 많은 오류를 처리해야 하며 이러한 오류는 상상하기가 매우 어렵습니다(물론 전문적으로 파서를 작성하지 않는 한).

이 작업의 조건부 예상 시간은 Habr에서 데이터를 수집할 때보다 3~5배 더 높습니다. Habr의 경우 HTML 구문 분석과 함께 정면 접근 방식을 사용하고 OK의 경우 중요한 위치에서 API로 작업할 수 있다는 사실에도 불구하고.

조사 결과

방대한 데이터 처리 파이프라인 모듈의 "현장"(오늘 계획 중입니다!) 기한을 얼마나 예측해야 하는지에 관계없이, 작업 매개변수를 분석하지 않고는 실행 시간을 정성적으로 예측하는 것이 거의 불가능합니다.

좀 더 철학적으로 말하면 민첩한 추정 전략은 엔지니어링 작업에 적합하지만 더 실험적이고 어떤 의미에서 "창의적"이고 탐구적인 문제, 즉 예측 가능성이 낮은 문제는 유사한 주제의 예에서와 같이 어려움을 겪습니다. 우리가 여기서 논의한 것입니다.

물론 데이터 수집은 대표적인 예일 뿐입니다. 이는 일반적으로 믿을 수 없을 정도로 간단하고 기술적으로 복잡하지 않은 작업이며, 악마는 세부 사항에 숨어 있는 경우가 많습니다. 그리고 정확히 이 작업을 통해 무엇이 잘못될 수 있는지, 작업에 소요되는 시간이 정확히 얼마나 되는지에 대한 가능한 옵션의 전체 범위를 보여줄 수 있습니다.

추가 실험 없이 작업의 특성을 살펴보면 Reddit과 OK가 비슷해 보입니다. API, Python 래퍼가 있지만 본질적으로 차이가 큽니다. 이러한 매개변수로 판단하면 Habr의 분석은 OK보다 더 복잡해 보이지만 실제로는 정반대이며 이는 문제의 매개변수를 분석하기 위한 간단한 실험을 수행하여 정확히 알 수 있는 것입니다.

내 경험상 가장 효과적인 접근 방식은 예비 분석 자체와 간단한 첫 번째 실험에 필요한 시간을 대략적으로 추정하고 문서를 읽는 것입니다. 이를 통해 전체 작업에 대한 정확한 추정치를 제공할 수 있습니다. 널리 사용되는 애자일 방법론과 관련하여 "작업 매개변수 추정" 티켓을 생성해 주시기 바랍니다. 이를 바탕으로 "스프린트" 내에서 달성할 수 있는 작업을 평가하고 각각에 대해 보다 정확한 추정을 제공할 수 있습니다. 일.

따라서 가장 효과적인 주장은 "비기술적" 전문가에게 아직 평가되지 않은 매개변수에 따라 얼마나 많은 시간과 자원이 달라질 것인지를 보여주는 주장인 것 같습니다.

출처 : habr.com