Python、オプション、および考慮事項を使用したファイルの読み取り/書き込みでのリソースの使用

Question

私はまだゲームに慣れていないPythonで開発しています。この問題に正しく取り組むことを確認したいと思います。すべてのアドバイスを喜んで受け入れます。

複数のフラットファイルに保存されているデータを使用しようとしていることを想像してください。多くの場合、合計サイズが20〜35 GBを超えています。最も一般的なケースでは、これらのファイルは区切られたもの（CSV、タブ）であるか、単に固定幅である場合があります。目標は、これらのファイル、または各ファイルの一部のサブセットを取得し、入力（各列はデータの変数を表す）を解析し、宛先（ローカルまたはリモートSQL、さまざまな他のローカルファイルである可能性があります）に送信することです。テキストやStataの.dtaなどの独自のデータ形式を含む出力形式の

目標は、利用可能なシステムリソースを使用して、この操作を可能な限り速い方法で実行することです（1秒あたりKBに関しては？）

質問：

1. コンパイルされたCを使用して読み取り操作を行うことで効率的な利益はありますか？もしそうなら、どのライブラリの使用方法を学ぶべきですか？また、Cも解析と出力を行う必要がありますか？

2. ファイルが.zipまたは.gzに入っている場合、読み書きの前にファイル全体を解凍する必要がありますか、それとも圧縮されたままにして、圧縮ファイルから読み取りできるライブラリを使用しますか？

3. プログラムはマルチスレッドを使用する必要がありますか？ファイルのサブセットを読んで（たとえば、一度にn行）、たとえばjスレッドを解析して出力することを想像します。ファイルを一度に1行ずつ読み取ることが最適であることは明らかではありません...そして、スレッドとプロセスの最適な数は、利用可能なリソースとジョブのサイズに依存するようです。
   したがって、コードは、使用するスレッドの数と各スレッドが予想される作業量を最適に決定するのに十分なほど「スマート」でなければなりません。

4. 異なる方法間で効率をどのように測定して比較しますか？

5. プログラムはこれを動的に行い、パフォーマンスに基づいて入力出力メソッドを選択できる必要がありますか？ （メソッドAは常に厳密にメソッドBを支配しますか、または展開環境の特異な変更を行います）

明確にするために、私はリソース効率の無視できない改善と引き換えに、ほぼすべてのレベルのコード非効率性を受け入れることをいとわない

これらの質問が、私が何を理解しようとしているかについての明確なアイデアを提供することを願っています。私のプログラミングの経験は、主に科学的/統計的パッケージに限定されているため、私の質問のいずれかが「RTM」に要約された場合は、穏やかで適切なマニュアルを提案してください。

Answer 1

コンパイルされたCを使用して読み取り操作を行うことで効率的な利益はありますか？

あまり。制限はI/O帯域幅になり、Pythonは基礎となるCライブラリを使用します。

ファイルが.zipまたは.gzに入っている場合、読み書きの前にファイル全体を解凍する必要がありますか、それとも圧縮されたままにして、圧縮ファイルから読み取りできるライブラリを使用しますか？

まず、他のすべてをうまく機能させます。これを前もってフィネスしようとしないでください。 PythonのZipfile実装は、ZIPアーカイブメンバーを拡張せずにZIPアーカイブメンバーを開くことにより、CSV形式ファイルを処理できます。

これは速いですか？事前に知ることはできません。あなたはそれを構築し、あなたが構築したものを測定することによってのみ知ることができます。手を絞らないでください。コードのほんの数行です。両方を構築します。

プログラムはマルチスレッドを使用する必要がありますか？

いいえ。

OSレベルのマルチプロセスを使用します。

python something.py source.zip | python part2.py | python part3.py | python part4.py >result

これは驚くほど速くなり、多くの作業がなければ使用しません すべて 利用可能なOSリソース。

異なる方法間で効率をどのように測定して比較しますか？

うーん...それはばかげた質問です。あなたはそれを構築して測定します。経過時間は、他の何よりも良い尺度です。混乱している場合は、ストップウォッチを使用してください。真剣に。魔法はありません。

プログラムはこれを動的に行い、パフォーマンスに基づいて入力出力メソッドを選択できる必要がありますか？

いいえ。

（メソッドAは常に厳密にメソッドBを支配しますか、または展開環境の特異な変更を行います）

はい。はい。一部の方法は常により効率的です。ただし、OSは地獄のように複雑であるため、シンプルで柔軟なコンポーネント設計に代わるものはありません。

柔軟に再結合できるシンプルなピースを構築します。

事前に手で塗らないでください。可能な場合は、適切なデータ構造とアルゴリズムを設計します。できないときは、賢明なものを選んで先に進みます。何かを構築してチューニングすることは、詳細を心配するよりもはるかに簡単です。

1. 何かを作る。

2. 測定。

3. ボトルネックを見つけてください。

4. 最適化 それだけ 実績のあるボトルネック。