データ サイエンスでは何が問題になるのでしょうか? データ収集

現在、100500 のデータ サイエンス コースがあり、データ サイエンスで最も多くのお金を稼げるのはデータ サイエンス コースであることは昔から知られています (シャベルが売れるのに、なぜ掘る必要がありますか?)。 これらのコースの主な欠点は、実際の作業とは何の関係もないことです。必要な形式できれいに処理されたデータを提供してくれる人は誰もいません。 そして、コースを離れて実際の問題を解決し始めると、多くのニュアンスが現れます。

したがって、私たちは、私や私の同志、同僚に起こった実際の出来事に基づいて、「データサイエンスで何が問題になるのか」という一連のメモを開始します。 実際の例を使用して、典型的なデータ サイエンス タスクを分析します。これが実際にどのように起こるのかを説明します。 今日はデータ収集タスクから始めましょう。

そして、実際のデータを扱い始めるときに最初につまずくのは、私たちに最も関連性のあるデータを実際に収集することです。 この記事の重要なメッセージ:

私たちは、データの収集、クリーニング、準備に必要な時間、リソース、労力を組織的に過小評価しています。

そして最も重要なことは、これを防ぐために何をすべきかを議論することです。

さまざまな見積もりによると、クリーニング、変換、データ処理、特徴エンジニアリングなどが時間の 80 ～ 90% を占め、分析に 10 ～ 20% の時間がかかりますが、ほとんどすべての教材は分析のみに焦点を当てています。

典型的な例として XNUMX つのバージョンの単純な分析問題を見て、「悪化する状況」とは何かを見てみましょう。

例として、データを収集し、コミュニティを比較するタスクの同様のバリエーションを検討します。

1. XNUMX つの Reddit サブレディット
2. ハブルの XNUMX つのセクション
3. オドノクラスニキの XNUMX つのグループ

理論上の条件付きアプローチ

サイトを開いてサンプルを読み、それが明確であれば、読むために数時間を確保し、サンプルを使用したコードとデバッグに数時間を確保します。 収集には数時間を追加します。 数時間を予備として投入します (XNUMX を掛けて N 時間を追加します)。

重要なポイント: 所要時間の見積もりは、どれくらいの時間がかかるかについての仮定と推測に基づいています。

時間分析を開始するには、上記の条件付き問題の次のパラメータを推定する必要があります。

• データのサイズはどれくらいで、物理的に収集する必要があるデータの量はどれくらいですか (*下記を参照*)。
• XNUMX つのレコードの収集時間はどれくらいですか? また、XNUMX 番目のレコードを収集できるようになるまでにどれくらいの時間がかかりますか?
• すべてが失敗した場合ではなく、状態を保存して再起動を開始するコードを作成することを検討してください。
• 認証が必要かどうかを判断し、API 経由でアクセスを取得する時間を設定します。
• データの複雑さに応じてエラーの数を設定します。構造、変換の数、何をどのように抽出するかなど、特定のタスクを評価します。
• ネットワーク エラーと非標準のプロジェクト動作の問題を修正します。
• 必要な機能がドキュメントに記載されているかどうかを評価し、記載されていない場合は、回避策としてどのように、どの程度の量が必要かを評価します。

最も重要なことは、時間を見積もるには、実際には「強力な偵察」に時間と労力を費やす必要がありますが、そうして初めて計画が適切になるということです。 したがって、「データを収集するのにどれくらい時間がかかるか」ということをどれだけ要求されても、予備的な分析のために時間を稼ぎ、問題の実際のパラメータによって時間がどれくらい変わるかを議論してください。

次に、そのようなパラメーターが変更される具体的な例を示します。

キーポイント: 見積もりは、作業の範囲と複雑さに影響を与える主要な要因の分析に基づいています。

推測に基づく推定は、機能要素が十分に小さく、問題の設計に大きな影響を与える可能性のある要素がそれほど多くない場合に適したアプローチです。 しかし、多くのデータ サイエンスの問題の場合、そのような要因が非常に多くなり、そのようなアプローチでは不十分になります。

Redditコミュニティの比較

最も単純なケースから始めましょう (後で判明します)。 一般に、完全に正直に言うと、ほぼ理想的なケースがあります。複雑さのチェックリストを確認してみましょう。

• きちんとした、明確で文書化された API があります。
• 非常にシンプルで、最も重要なことは、トークンが自動的に取得されることです。
• あり Pythonラッパー - たくさんの例とともに。
• 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 の密度の例を示します。

  
  から取られた この 記事。

• Web 上で 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 つのスレッドで解析するのに XNUMX 時間以上かかります (これは純粋に、すでに動作しているシングルスレッド パーサーの実行時間であり、スリープ状態で禁止には該当しません)。 で この の記事によれば、これはある時点で同様のスキームにつながりました。

複雑さ別の合計チェックリスト:

• ネットワークと HTML の反復解析および ID による検索を操作します。
• 異種構造のドキュメント。
• コードが落ちやすい場所はたくさんあります。
• || と書く必要があります。 コード。
• 必要なドキュメント、コード例、コミュニティが不足しています。

このタスクの推定時間は、Reddit からデータを収集する場合よりも 3 ～ 5 倍長くなります。

オドノクラスニキグループの比較

説明されている技術的に最も興味深いケースに移りましょう。 私にとっては、一見すると些細なことのように見えて、実際に棒を突いてみると全くそうではない、だからこそ興味深かったのです。

難易度チェックリストから始めましょう。その多くは、最初に見たよりもはるかに難しいことが判明することに注意してください。

• API はありますが、必要な機能がほとんどありません。
• 特定の機能に対しては、メールでアクセスをリクエストする必要があります。つまり、アクセスの許可は即座には行われません。
• それはひどく文書化されており（そもそも、ロシア語と英語の用語がいたるところで混同されており、まったく一貫性がありません。場合によっては、どこかで彼らが何を求めているのかを推測する必要があるだけです）、さらに、その設計はデータを取得するのには適していません。 、 私たちが必要とする機能.
• ドキュメントではセッションが必要ですが、実際にはセッションが使用されていません。また、API モードの複雑さをすべて理解するには、いろいろ調べて何かが機能することを期待する以外に方法がありません。
• 事例もコミュニティもなく、情報収集の唯一のサポートポイントは小さなものです。 ラッパー Python で (使用例はあまりありません)。
• 必要なデータの多くがロックされているため、Selenium が最も実行可能なオプションと思われます。
  1) つまり、承認は架空のユーザーを通じて行われます (および手動での登録)。

  2) ただし、Selenium では、正確で再現可能な動作の保証はありません (少なくとも ok.ru の場合は確実です)。

  3) Ok.ru Web サイトには 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 の pars は OK よりも複雑に見えますが、実際にはまったく逆であり、これはまさに問題のパラメータを分析する簡単な実験を行うことで判明することができます。

私の経験では、最も効果的なアプローチは、予備分析自体と簡単な最初の実験に必要な時間を大まかに見積もり、ドキュメントを読むことです。これにより、作業全体を正確に見積もることができます。 人気のアジャイル手法に関して言えば、「タスクパラメータの見積もり」のためのチケットを作成するようお願いします。これに基づいて、「スプリント」内で達成できることを評価し、それぞれについてより正確な見積もりを提供できます。タスク。

したがって、最も効果的な議論は、「技術者ではない」専門家に、まだ評価されていないパラメータに応じてどれだけの時間とリソースが変化するかを示す議論であると思われます。

出所： habr.com