0

私はオースティンの小さなスタートアップでデータ担当をしています。私が (これまでに) 行ったすべての分析は、ラップトップから実行するアドホック スクリプトのセットとして保存されています。これは悪い考えです。

分析を展開するための計画をここにスケッチします。見落としている明白な穴があるかどうか、または考慮すべき他の何かがあるかどうかを知りたいです。私が持っているアウトラインは、必要なときに必要な場所にプラグインできるように十分にアトミックに保たれていると思いますが、1 つのスクリプトを非常に簡単に実行することもできます。二次的な (長期的な) 目標は、ユーザー (つまり、私の会社の従業員) が一度に 1 つずつスクリプトを呼び出せるようにする単純な Web フロントエンドを配置することです。電子メールの結果。

スクリプトをサーバーにデプロイしたいのですが、スクリプトを一連の Python モジュールに編成することを考えています。次に、バッチ スクリプトを次のようにします。

import analysis

batch_dict = analysis.build_batch_dict()
assert sorted(batch_dict.keys()) = ['Hourly', 'Monthly', 'Nightly', 'Weekly']

scripts_to_run = analysis.what_batch() # get from command line?
results_directory = analysis.make_results_directory()
failures = {}
for script in scripts_to_run:
    try:
        script.analyze()
        script.export_results(results_directory)
    except Exception as e:
        failures.update(script.failed(e))

analysis.completed(failures)

クラスによって処理されるように、分析を書き直します。

class AnalysisHandler(object):
    ...
    def analyze():
        pass
    def export_results(some_directory):
        pass
    def failed(exception):
        pass
    def run_with_non_default_args(*args, **kwargs):
        pass
    def something_else_im_missing_now():
        pass

すべてのスクリプトは、AnalysisHandler を継承するものによって処理されます。

サーバー上のディレクトリ構造は次のようになります。

datalytics/
    results/
        02-14-2013/
            script1/
                /log
                /error
                /data
            script2/
                /log
                /error
                /data
            .
            .
            .
            <etc>
    scripts/
        script1/
            bin/
            data/
            doc/
            script_1/
            tests/
            setup.py
        .
        .
        .
    analysis/
        __init__.py
        analysis.py
    batch.py (see above)
    new_script.py
    run_all_tests.py
    run_some_tests.py
    run_this_script.py
    run_everything.py
4

1 に答える 1

1

正式な答えとして：

  • ファイルを作成するとき（パーミッションの問題が発生する可能性があります）、特にフロントエンドを追加し、従業員が変更できないディレクトリに書き込みたい場合は、例外に注意してキャッチしてください。

  • 現在の設定では、ループを「with」ステートメント内にラップし、開いているファイルハンドルを保持し、結果が入ったときにフラッシュすることをお勧めします。これにより、進行状況をある程度追跡でき、通知も得られます。サーバーがクラッシュした場合、テストが実行されていたかどうか、そしておそらくそれらの1つがクラッシュを引き起こした場合

  • あなたはかなりのフレームワークを開発しているようです。unittestモジュールはPythonコードをテストすることを目的としていますが、フレームワークの多くを置き換えるために確実に活用できます（つまり、テストの並べ替え、実行するテストの指定、ロギングなど）。また、インターフェイスを接続し、予想される障害などのテストにマークを付ける簡単な方法も提供します。

  • 出力を持つことは重要ですが、それを有用にすることも重要です。きれいなテキストで印刷したい場合もありますが、たとえばPython辞書で開始し、それをフラット化した場合は、ログファイルにコンマを追加し、辞書を文字列としてダンプして、Pythonに直接スクープできるようにします。必要に応じてデータを操作します。

  • 最後のポイントから離れて、特にログとWeb UIを使用して作業する場合は、json.dumpsとjson.loadsを確認してください。javascriptはその形式で使いやすく、すべてを「python-happy」形式に保つことで、多くの作業を節約できます。

  • 必要に応じて、テストのスレッド化を追加するのは難しくありません。実行に時間がかかるタスクやIOを集中的に使用するタスクがあることがわかっている場合は、それを自動的にスピンオフさせてください。そのルートに進むと思われる場合は、最初から計画を立てて、保護する必要のある変数に注意するか、競合状態の問題を回避するために、すべての結果を辞書ではなくキューにプッシュしてください。

  • タイムスタンプの解決に注意してください。特に、タイムスタンプをキーとして使用する辞書をロードする場合は、o_O--->実行しないでください。

  • config関数と、argsとkwargsを受け入れることに気づきました。uiまたはファイルのいずれかを介してテストの構成を許可する場合、特にファイルの場合は、jsonに適した形式を使用し、kwargs = json.loads（open（configfile、'r'）。read（））およびパーサーや正規表現を記述したり、パラメーターを追加するときにコードを変更したりする必要がなかったことを非常に嬉しく思います。

于 2013-02-14T17:46:41.180 に答える