良い答えがすでに出ています。したがって、個人的な経験に基づいていくつかの考えを共有します。必要に応じて、関連する考えを自分の状況に合わせて調整します。
以下のための背景や文脈-したがって、このメッセージに忍び寄る可能性のある個人的な偏見を説明することができます-私の仕事の多くは、比較的小さなデータセットに基づいて重要な意思決定を支援することにあります。データの収集に費用がかかる可能性があるため、それらは小さいです（たとえば、地下水モニタリング井戸の最初のサンプルでは1万ドル、珍しい化学物質の分析では数千ドル）。私は、利用可能なデータから可能な限り多くを取得し、それらを死に至らしめ、必要に応じて分析するための新しい方法を発明することに慣れています。しかし、ここ数年、国勢調査のブロックレベルで全米をカバーする社会経済データや工学データ（850万件のレコード、
非常に大きなデータセットでは、アプローチ全体と考え方が変わります。現在、分析するデータが多すぎます。（回帰モデルに重点を置いた）直接的な（そして振り返って）明白な影響のいくつかは以下を含みます：
実行することを考える分析は、多くの時間と計算を要する可能性があります。データセット全体を計算する際のワークフローを計画できるように、サブサンプリングと部分的なデータセットの操作方法を開発する必要があります。（データセット全体と同じくらい豊富なデータの代表的なサブセットが必要なため、サブサンプリングは複雑になる可能性があります。また、保持されたデータでモデルを相互検証することを忘れないでください。）
このため、実行内容を文書化し、すべてをスクリプト化するのにより多くの時間を費やすことになります（繰り返しができるように）。
@dsimchaが指摘したように、優れたプログラミングスキルは役に立ちます。実際には、プログラミング環境での経験ではあまり必要ありませんが、プログラミングへの意欲、プログラミングが役立つことを認識する能力（実際にはほぼすべてのステップで）、および基本的な要素の十分な理解が必要です適切なデータ構造の設計や、アルゴリズムの計算の複雑さを分析する方法などのコンピューターサイエンス。これは、記述する予定のコードが完全なデータセットにスケールアップするかどうかを事前に知るのに役立ちます。
多くの変数（数千または数万、すべてが異なる）を持っているため、一部のデータセットは大きくなります。 データを要約して理解するだけで多くの時間を費やすことを期待してください。ブックまたはデータ辞書、および他の形式のメタデータは、必要不可欠になります。
あなたの時間の大部分は、単にデータを移動して再フォーマットすることに費やされています。大規模なデータベースを処理するスキルと、大量のデータを要約してグラフ化するスキルが必要です。（TufteのSmall Multipleがここで前面に出てきます。）
お気に入りのソフトウェアツールの一部は失敗します。たとえば、スプレッドシートを忘れてください。多くのオープンソースおよびアカデミックソフトウェアは、大規模なデータセットを処理するだけではありません。処理が永遠にかかるか、ソフトウェアがクラッシュします。これを期待し、重要なタスクを達成するための複数の方法があることを確認してください。
実行する統計テストのほとんどは非常に強力であるため、「重要な」効果を特定するのはほぼ確実です。 有意性よりも、効果の大きさなどの統計的重要性にもっと集中する必要があります。
同様に、モデルの選択は面倒です。なぜなら、あなたが考えているほとんどすべての変数と相互作用が重要に見えるからです。 分析することを選択した変数の有意性にもっと集中する必要があります。
変数の適切な非線形変換を識別するのに十分な情報があります。これを行う方法を知っています。
非線形関係、トレンドの変化、非定常性、不均一分散などを検出するのに十分なデータがあります。
あなたは決して終わらないでしょう。永遠にそれらを研究することができる非常に多くのデータがあります。したがって、最初に分析目標を設定し、常にそれらを念頭に置くことが重要です。
最後に、小さなデータセットと大きなデータセットを使用した回帰モデリングの予想外の違いを示す短い逸話で終わります。国勢調査データを使用したプロジェクトの最後に、私が開発した回帰モデルをクライアントのコンピューティングシステムに実装する必要がありました。これは、リレーショナルデータベースにSQLコードを記述することを意味しました。これは日常的な手順ですが、データベースプログラマが生成したコードには数千行のSQLが含まれていました。これにより、バグがないことを保証することはほぼ不可能になりました-バグを検出することはできましたが（テストデータで異なる結果が得られました）、それらを見つけることは別の問題でした。（必要なのは、係数内の1つの誤植だけです...）ソリューションの一部は、モデル推定から直接SQLコマンドを生成するプログラムを書くことでした。これにより、統計パッケージから出力されたものが、RDBMSに入力されたものとまったく同じであることが保証されました。ボーナスとして、このスクリプトの作成に数時間を費やしたことで、おそらく数週間のSQLコーディングとテストが置き換えられました。これは、統計学者が結果を伝えることができることの意味のほんの一部です。