今日、データサイエンスには100,500のコースがあり、データサイエンスのコースで最も多くのお金を稼ぐことができることは古くから知られています（シャベルを売れるのになぜ掘るのですか？）。これらのコースの主な欠点は、実際の作業とは何の関係もないことです。必要な形式でクリーンな処理済みデータを提供する人は誰もいません。そして、コースを離れて本当の問題を解決し始めると、多くのニュアンスが浮かび上がります。
そのため、私、私の仲間、同僚に起こった実際の出来事に基づいて、「データサイエンスで何がうまくいかない可能性があるか」という一連のメモを開始します。実際の例を使用して、データサイエンスの一般的なタスクを分析します。実際にどのように発生するかです。今日はデータ収集のタスクから始めましょう。
そして、実際のデータを使い始めたときに最初に遭遇するのは、実際にこの最も関連性の高いデータを収集することです。この記事の重要なメッセージ：
データの収集、クリーニング、準備にかかる時間、リソース、労力を体系的に過小評価しています。
そして最も重要なことは、これを防ぐために何をすべきかを議論することです。
さまざまな見積もりによると、クリーニング、変換、データ処理、機能エンジニアリングなどは、時間の80〜90％、分析は10〜20％かかりますが、ほとんどすべてのトレーニング資料は分析のみに焦点を当てています。
典型的な例として、3つのバージョンの単純な分析問題を取り上げ、「悪化する状況」とは何かを見てみましょう。
例として、ここでも、データを収集し、コミュニティを比較するタスクの同様のバリエーションを検討します。
- 2つのRedditサブレディット
- 2つのHabrセクション
- Odnoklassnikiの2つのグループ
理論上の条件付きアプローチ
サイトを開いて例を読んでください。明確な場合は、数時間かけて読んでください。コードの例とデバッグには数時間かかります。収集するために数時間を追加します。予備として数時間で投げます（2を掛けてN時間を追加します）。
キーポイント：時間の見積もりは、仮定と所要時間の推測に基づいています。
上記の条件付き問題について、以下のパラメーターを評価することにより、時間分析を開始する必要があります。
- データのサイズと、物理的に収集する必要のある量（*以下を参照*）。
- 1つのレコードを収集するのにかかる時間と、2番目のレコードを収集するのにかかる時間。
- 状態を保存し、すべてが落ちたとき（そうでない場合）に再起動を開始するコードの記述を置くこと。
- , API.
- , — : , , .
- .
- , , a workaround.
最も重要なことは、時間を見積もるには、実際には「有効な偵察」に時間と労力を費やす必要があるということです。そうして初めて、計画が適切になります。したがって、「データの収集にはどのくらいの時間がかかりますか」と言われたとしても、予備的な分析に時間をかけ、問題の実際のパラメータによってどのくらいの時間が変化するかを議論します。
そして今、そのようなパラメータが変化する特定の例を示します。
キーポイント：評価は、作業の量と複雑さに影響を与える重要な要因の分析に基づいています。
機能要素が十分に小さく、問題の構造に大きな影響を与える可能性のある要因が多くない場合、推定は適切なアプローチです。しかし、多くのデータサイエンスタスクの場合、そのような要因がたくさんあり、そのようなアプローチは不十分になります。
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 — . , : score html :
1) int(score) : , , "–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) ** **. - 実際、エラー処理と発生する可能性のあるものと発生しない可能性のあるものを処理する必要があり、何がうまくいかず、構造が他にどのようになり、何がどこで落ちるかを確実に予測することはできません。パーサーがスローするエラーを考慮に入れる必要があります。
- 次に、複数のスレッドに解析する必要があることを理解します。そうしないと、1つに解析するのに30時間以上かかります（これは、スリープ状態になり、禁止されていない、すでに機能しているシングルスレッドパーサーの実行時間です）。で、この記事では、これは同様のパターンをいくつかの点でつながりました：
総合的な複雑さのチェックリスト：
- 反復およびIDによる反復を使用したWebおよびhtml解析の操作。
- 異種構造のドキュメント。
- コードが簡単に落ちる場所はたくさんあります。
- 書く必要があります|| コード。
- ドキュメント、コード例、および/またはコミュニティがありません。
このタスクの条件付き時間の見積もりは、Redditからデータを収集する場合よりも3〜5倍長くなります。
Odnoklassnikiグループの比較
説明されている最も技術的に興味深いケースに移りましょう。私にとっては、一見些細なことのように見えるので面白かったのですが、棒で突くとすぐにはそうではありません。
難易度チェックリストから始めましょう。それらの多くは、最初に見たものよりもはるかに難しいことが判明することに注意してください。
- APIはありますが、必要な機能がほぼ完全に不足しています。
- 特定の機能へのアクセスをメールで要求する必要があります。つまり、アクセスの発行は瞬時ではありません。
- ( , , — , - ) , , , , .
- , — API, , - .
- , — wrapper ( ).
- Selenium, .
1) ( ).
2) c Selenium ( ok.ru ).
3) . JavaScript .
4) , …
5) API, wrapper , , ( ):
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ラッパーがありますが、実際には大きな違いがあります。これらのパラメータから判断すると、Pars HabrはOKよりも複雑に見えますが、実際にはまったく逆であり、問題のパラメータを分析するための簡単な実験を行うことでこれを見つけることができます。
私の経験では、最も効果的なアプローチは、予備分析自体と簡単な最初の実験に必要な時間の概算であり、ドキュメントを読みます。これにより、作業全体の正確な見積もりを行うことができます。人気のある機敏な方法論に関して、「問題のパラメータの見積もり」の下で私のためにチケットを作成するようにお願いします。これに基づいて、「スプリント」内で達成できることの見積もりを提供し、各問題についてより正確な見積もりを提供できます。
したがって、最も効果的な議論は、「非技術的」スペシャリストに、まだ推定されていないパラメータに応じてどのくらいの時間とリソースが変化するかを示すもののようです。
