32

大量のデータ (数テラバイト) があり、蓄積しています... それらは多くのタブ区切りのフラット テキスト ファイル (それぞれ約 30MB) に含まれています。ほとんどのタスクには、データを読み取り、一連の述語ステートメントに基づいて観測/行を集計 (合計/平均 + 追加の変換) し、出力をテキスト、HDF5、または SQLite ファイルなどとして保存することが含まれます。通常は R を使用します。そのようなタスクの場合、これは少し大きいのではないかと心配しています。解決策の候補のいくつかは、

  1. すべてを C (または Fortran) で書く
  2. ファイル (テーブル) をリレーショナル データベースに直接インポートしてから、R または Python でチャンクを取得します (一部の変換は、純粋な SQL ソリューションには適していません)。
  3. 全体をPythonで書く

(3)はまずいのでしょうか？Python で C ルーチンをラップできることは知っていますが、この場合、計算上禁止されているもの (たとえば、多くの反復計算を必要とする最適化ルーチン) がないため、I/O が計算自体と同じくらいボトルネックになる可能性があると思います。さらなる考慮事項や提案について何か推奨事項はありますか? ありがとう

編集回答ありがとうございます。Hadoop については意見が対立しているようですが、いずれにせよ、クラスターにアクセスすることはできません (ネットワーク化されていない複数のマシンを使用することはできますが)。

4

8 に答える 8

14

(3) は必ずしも悪い考えではありません。Python を使用すると、「CSV」ファイルを簡単に処理できます (また、C は Comma の略ですが、セパレータとしてのタブは同じくらい簡単に処理できます)。もちろん、ほぼ同じ帯域幅を取得できます。他の言語と同様に I/O ops で。他の推奨事項についてnumpyは、高速計算 (ステートメントによっては必要ない場合があります) に加えて、非常に便利で柔軟な多次元配列が提供されます。これはタスクに非常に便利です。また、標準ライブラリ モジュールmultiprocessingを使用すると、並列化が容易なタスクに複数のコアを活用できます (最近のほぼすべてのマシンにマルチコアがあるため、重要です ;-)。

于 2010-05-30T05:12:11.227 に答える
13

さて、違いますが、なぜRではないのですか？

  • あなたはRを知っているようですので、コードをすぐに動作させることができます
  • ファイルあたり30MBは、RAMが数GBの標準的なワークステーションでは大きくありません。
  • 引数を介して列のタイプを指定すると、のread.csv()バリアントはread.table()非常に効率的になりますcolClasses。変換のためにタイプをゲスト化する代わりに、これらは効率的に処理されます。
  • ここでのボトルネックはディスクからのI/Oであり、これはすべての言語で同じです。
  • Rには、マルチコアを備えたマシンで並列処理をセットアップするためのマルチコアがあります（Pythonのマルチプロセッシングと同様のようです）
  • 問題の「驚異的並列」構造を採用したい場合、Rには、データ並列問題に適したパッケージがいくつかあります。たとえば、 snowとforeachは、それぞれ1台のマシンまたはネットワーク化されたマシンのセットにデプロイできます。 。
于 2010-05-30T19:28:18.633 に答える
6

ディスコをご覧ください。これは軽量の分散 MapReduce エンジンで、約 2000 行の Erlang で記述されていますが、特に Python 開発用に設計されています。データの操作だけでなく、レプリケーションの確実な保存もサポートします。彼らはちょうどバージョン 0.3 をリリースしました。これにはインデックス作成とデータベース レイヤーが含まれています。

于 2010-05-30T05:13:27.213 に答える
4

Amazon の Elastic Map Reduce で R を Hadoop と一緒に使用できて幸運でした。EMR では、使用したコンピューター時間に対してのみ料金が発生し、AMZN がインスタンスのスピンアップとスピンダウンを処理します。EMR でジョブをどのように構成するかは、分析ワークフローがどのように構成されているかによって異なります。たとえば、1 つのジョブに必要なすべてのレコードが各 csv 内に完全に含まれているか、または分析を完了するために各 csv のビットが必要ですか?

役立つリソースを次に示します。

ブログ投稿で言及した問題は、IO バウンドではなく、CPU バウンドの問題です。あなたの問題はより多くの IO ですが、ライブラリとキャッシュファイルのロードに関するヒントが役立つ場合があります。

これをリレーショナル データベースに出し入れしようとするのは魅力的ですが、RDB のすべてのオーバーヘッドが本当に必要かどうかを慎重に検討することをお勧めします。そうしないと、本当の見返りがないボトルネックと開発課題が発生する可能性があります。

于 2010-06-01T18:22:36.280 に答える
4

テラバイトでは、とにかく多くのディスクで読み取りを並列化する必要があります。そのまま Hadoop に移行することもできます。

Pig または Hive を使用してデータをクエリします。どちらもユーザー定義の変換を幅広くサポートしているため、カスタム コードを使用して必要なことを実装できるはずです。

于 2010-05-30T05:30:47.437 に答える
2

「蓄積する」と言うと、解決策（2）が問題に最も適しているように見えます。
データベースに最初にロードした後は、新しいファイルでデータベースを更新するだけです（毎日、毎週？これが必要な頻度によって異なります）。

（1）と（3）の場合、結果を保存して新しいファイルで更新する方法が見つからない限り、毎回ファイルを処理する必要があります（以前に最も時間/リソースを消費すると述べたもの）。

Rを使用して、csvからSQLiteデータベースなどへのファイルを処理できます。

于 2010-05-31T08:54:21.687 に答える
2

マシンのクラスターがある場合は、Hadoop Mapreduce を使用してアプリケーションを並列化できます。Hadoop は Java で作成されていますが、Python も実行できます。コードを並列化するためのポインターについては、次のリンクをチェックアウトできます - PythonWordCount

于 2010-05-30T05:16:33.183 に答える
1

はい。あなたが正しいです！I/O は、処理時間のほとんどを消費します。このタスクに Hadoop などの分散システムを使用することはお勧めしません。

あなたの仕事は、控えめなワークステーションで行うことができます。私は Python の専門家ではありませんが、非同期プログラミングをサポートしていると思います。F#/.Net では、プラットフォームはそれを十分にサポートしています。私はかつて、20K の画像をディスクにロードし、それらを特徴ベクトルに変換する画像処理の仕事をしていましたが、並行して数分しかかかりませんでした。

全体として、データを並行してロードして処理し、結果をメモリ (小さい場合)、データベース (大きい場合) に保存します。

于 2010-05-30T05:27:53.163 に答える