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

現在、データサイエンスに関するコースは100500万XNUMX件存在し、データサイエンス分野で最も収益を上げられるのはデータサイエンス関連のコースであることは以前から知られています（シャベルが売れるのに、わざわざ掘る必要はありませんよね？）。こうしたコースの主な欠点は、実際の仕事とは全く関係がないことです。適切な形式で、クリーンで処理済みのデータを提供してくれる人は誰もいません。そして、コースを修了し、実際の問題の解決に取り組むと、多くのニュアンスが浮かび上がってきます。

そこで、私や友人、同僚に実際に起こった出来事をもとに、「データサイエンスで何がうまくいかないのか」というシリーズを始めます。データサイエンスの典型的なタスクを、実際の例を用いて分析し、実際にどのように行われているのかを明らかにします。今日はデータ収集のタスクから始めましょう。

実際のデータに取り組み始めると、まず最初につまずくのは、まさに自分たちにとって関連性のあるデータを収集しているということです。この記事のキーメッセージは次のとおりです。

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

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

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

単純な分析問題の典型的な例を 3 つのバージョンで見て、「悪化させる状況」がどのようなものなのかを見てみましょう。

また、例えば、次のようなデータの収集とコミュニティの比較というタスクの同様のバリエーションを検討します。

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

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

サイトを開いてサンプルを読んでみてください。内容が明確であれば、読解に数時間、サンプルのコードとデバッグに数時間を確保してください。さらに、アセンブリに数時間追加してください。さらに予備として数時間（2倍してN時間）を加えてください。

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

時間分析は、上記の条件付きタスクの次のパラメータの評価から始める必要があります。

• データのサイズはどれくらいですか。また、物理的に収集する必要があるデータはどのくらいありますか（*下記参照*）。
• 1 つのレコードの収集時間はどれくらいですか。また、2 番目のレコードを収集するまでにどれくらい待たなければなりませんか。
• すべてがクラッシュした場合 (クラッシュするはずではない)、状態を保存して再起動を開始するコードを記述します。
• 承認が必要かどうかを判断し、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 の密度の例です。

  
  から取られた この 記事。

• ウェブ上で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 時間以上かかります (これは、スリープ状態であり、禁止されていない、既に動作しているシングル スレッド パーサーの実行時間のみです)。 この この記事は、ある時点で次のような計画につながりました。

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

• ID による反復と列挙を使用して、ネットワークと HTML 解析を操作します。
• 異種構造の文書。
• コードが簡単に抜け落ちてしまう場所はたくさんあります。
• || コードを書く必要があります。
• 適切なドキュメント、コード サンプル、コミュニティが不足しています。

このタスクにかかる推定時間は、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の解析はOKよりも複雑に見えますが、実際には全く逆であり、タスクのパラメータを分析するための簡単な実験を行うことで、まさにそのことがわかります。

私の経験では、最も効果的なアプローチは、ドキュメントを読み、予備分析自体と簡単な最初の実験に必要な時間を大まかに見積もることです。ドキュメントを読むことで、作業全体の正確な見積もりを出すことができます。一般的なアジャイル手法に当てはめると、「タスクパラメータの見積もり」のチケットを作成してもらうように依頼します。これに基づいて、「スプリント」内で完了可能な作業を見積もり、各タスクのより正確な見積もりを出すことができます。

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

出所： habr.com