9

200,000,000行を超えるフラットファイル（CSV）があり、23個のディメンションテーブルを持つスタースキーマにインポートします。最大のディメンションテーブルには300万行があります。現時点では、1台のコンピューターでインポートプロセスを実行しており、約15時間かかります。時間がかかりすぎるので、40台程度のパソコンを使ってインポートしたいと思います。

私の質問

40台のコンピューターを効率的に利用してインポートを行うにはどうすればよいでしょうか。主な懸念は、すべてのノードでディメンションテーブルを同一にする必要があるため、すべてのノードでディメンションテーブルを複製するのに多くの時間がかかることです。これは、将来、インポートを行うために1000台のサーバーを使用した場合、サーバー間の広範なネットワーク通信と調整のために、単一のサーバーを使用するよりも実際には遅くなる可能性があることを意味します。

誰か提案がありますか？

編集：

以下は、CSVファイルを簡略化したものです。

"avalue";"anothervalue"
"bvalue";"evenanothervalue"
"avalue";"evenanothervalue"
"avalue";"evenanothervalue" 
"bvalue";"evenanothervalue"
"avalue";"anothervalue"

インポート後、テーブルは次のようになります。

ディメンションテーブル1

id  name
1   "avalue"
2   "bvalue"

ディメンションテーブル2

id  name
1   "anothervalue"
2   "evenanothervalue"

ファクトテーブル

  dimension_table1_ID       dimension_table2_ID
    1                      1
    2                      2
    1                       2
    1                       2              
    2                       2
    1                       1
4

8 に答える 8

10

シーケンシャルIDを使用する代わりに、64ビットハッシュ関数を使用しbigintて各文字列のIDを生成することを検討できます。

64ビットのハッシュコードを使用すると、衝突の可能性が0.0031％になる前に、ハッシュテーブルに2 ^（32-7）または3,000万を超えるアイテムを格納できます。

これにより、「ディスパッチ」フェーズと「マージ」フェーズの間でサーバー間で通信を行わずに、すべてのノードで同一のIDを使用できるようになります。

ビット数を増やして、衝突の可能性をさらに下げることもできます。ただ、結果のハッシュを64ビット整数データベースフィールドに適合させることはできません。

見る：

http://en.wikipedia.org/wiki/Fowler_Noll_Vo_hash

http://code.google.com/p/smhasher/wiki/MurmurHash

http://www.partow.net/programming/hashfunctions/index.html

于 2011-04-26T22:10:34.607 に答える
3

CSVデータのデータベースへの読み込みは、データの読み取り、分割、検証が必要なため、時間がかかります。

だからあなたが試してみるべきことはこれです：

  1. 各コンピューターにローカルデータベースをセットアップします。これにより、ネットワーク遅延がなくなります。

  2. 各コンピューターにデータの異なる部分をロードします。各コンピューターに同じチャンクを与えるようにしてください。なんらかの理由でそれが簡単でない場合は、各コンピューターに、たとえば10,000行を割り当てます。それらが完了したら、次のチャンクを与えます。

  3. DBツールを使用してデータをダンプします

  4. すべてのダンプを単一のDBにロードします

ローダーツールが、すでにデータが含まれているテーブルにデータをインポートできることを確認してください。これができない場合は、DBのドキュメントで「リモートテーブル」を確認してください。多くのデータベースでは、別のDBサーバーのテーブルをローカルで表示できます。

これにより、次のようなコマンドを実行できますinsert into TABLE (....) select .... from REMOTE_SERVER.TABLE

主キーが必要な場合（そして必要な場合）、ローカルDBへのインポート中にPKを割り当てるという問題も発生します。PKをCSVファイルに追加することをお勧めします。

[編集]編集内容を確認したら、次のことを試してください。

  1. CSVファイルの1列目と2列目に一意の値を抽出する小さなプログラムを作成します。これは、次のような単純なスクリプトである可能性があります。

     cut -d";" -f1 | sort -u | nawk ' { print FNR";"$0 }'

    これはかなり安価なプロセスです（巨大なファイルの場合でも数分）。それはあなたにID値ファイルを与えます。

  2. 新しいID値ファイルを読み取り、それらをメモリにキャッシュしてから、巨大なCSVファイルを読み取り、値をIDに置き換えるプログラムを作成します。

    ID値ファイルが大きすぎる場合は、小さいファイルに対してこの手順を実行し、大きいファイルを40台のマシンごとのDBすべてにロードします。

  3. 巨大なファイルを40のチャンクに分割し、各マシンにそれぞれをロードします。

    巨大なID値ファイルがある場合は、各マシンで作成されたテーブルを使用して、残っているすべての値を置き換えることができます。

  4. バックアップ/復元またはリモートテーブルを使用して、結果をマージします。

    または、さらに良いことに、40台のマシンにデータを保持し、並列コンピューティングのアルゴリズムを使用して作業を分割し、結果をマージします。このようにして、Googleは数ミリ秒で数十億のWebページから検索結果を作成できます。

紹介については、こちらをご覧ください。

于 2011-04-12T08:17:51.733 に答える
2

N台のコンピューター、それぞれ約50GBのファイルのXファイルを想定し、最後にすべてを含む1つのデータベースを持つことを目標としています。

質問：今は15時間かかります。プロセスのどの部分に最も時間がかかっているか知っていますか？（データの読み取り、データのクレンジング、テーブルへの読み取りデータの保存、インデックス作成…インデックス付けされていないテーブルにデータを挿入し、その後にインデックスを作成していますよね？）

この仕事をN台のコンピューターに分割するには、次のようにします（これは、封筒の裏側の設計です）。

  • 「中央」またはマスターデータベースを用意します。これを使用して、プロセス全体をマンガ化し、最終的な完全な倉庫を保持します。
  • これには、すべてのXファイルとすべてのN-1（それ自体は含まない）「ワーカー」データベースのリストが含まれています。
  • 各ワーカーデータベースは、何らかの形でマスターデータベースにリンクされています（指定していないRDBMSにどのように依存するか）。
  • 稼働中は、「準備完了」のワーカーデータベースがマスターデータベースをポーリングして、処理するファイルを探します。マスターデータベースはファイルをワーカーシステムに配置し、一度に複数のファイルが処理されないようにします。（特定のファイルのロードの成功/失敗を追跡する必要があります。タイムアウト（ワーカーが失敗した）を監視し、再試行を管理します。）
  • ワーカーデータベースには、スタースキーマのローカルインスタンスがあります。ファイルが割り当てられると、スキーマが空になり、その1つのファイルからデータがロードされます。（スケーラビリティのために、一度にいくつかのファイルをロードする価値があるかもしれませんか？）「第1段階」のデータクレンジングは、そのファイルに含まれるデータに対してここで実行されます。
  • ロードされると、マスターデータベースはそのワーカーの「準備完了フラグ」で更新され、待機モードになります。
  • マスターデータベースには、データのロードが完了したワーカーデータベースの独自のToDoリストがあります。待機中の各ワーカーセットを順番に処理します。ワーカーセットが処理されると、ワーカーは「処理する別のファイルがあるかどうかを確認する」モードに戻ります。
  • プロセスの開始時に、マスターデータベースのスタースキーマがクリアされます。ロードされた最初のセットは、おそらく逐語的にコピーすることができます。
  • 2番目以降のセットアップでは、データを読み取って「マージ」する必要があります。冗長なエントリを破棄したり、準拠したディメンションを介してデータをマージしたりします。一度に1セットだけでなく、すべてのデータに適用されるビジネスルールは、次のように実行する必要があります。良い。これは「第2段階」のデータクレンジングになります。
  • 繰り返しますが、すべてのファイルがアップロードされるまで、ワーカーデータベースごとに上記の手順を繰り返します。

利点：

  • ファイルからデータベースへのデータの読み取り/変換と「第1段階」のクレンジングの実行は、N台のコンピューター間でスケールアウトされます。
  • 理想的には、マスターデータベースにほとんど作業（「第2段階」、データセットのマージ）が残されていません。

制限：

  • 大量のデータが最初にワーカーデータベースに読み込まれ、次にネットワーク全体で（DBMSネイティブ形式ではありますが）再度読み込まれます。
  • マスターデータベースは、考えられるチョークポイントです。すべてがここを通過する必要があります。

ショートカット：

  • ワークステーションが新しいファイルを「チェックイン」すると、マスターにすでにロードされているデータのローカルストアを更新し、これに基づいてデータクレンジングの考慮事項を「第1段階」の作業に追加できる可能性があります（つまり、コード5484Jを認識しています）。すでにロードされているため、フィルターで除外し、マスターデータベースに戻さないようにすることができます）。
  • SQL Serverテーブルのパーティション分割または他のRDBMSの同様の物理的な実装のトリックは、おそらく効果的に使用できます。
  • 他のショートカットも考えられますが、実装されているビジネスルールに完全に依存します。

残念ながら、関連するシステムとデータについての詳細な情報や理解がなければ、このプロセスが「すべてを1つのボックスで行う」ソリューションよりも速くなるのか遅くなるのかを判断することはできません。結局のところ、それはあなたのデータに大きく依存します：それは「分割統治」技術に服従しますか、それともすべてを単一の処理インスタンスで実行する必要がありますか？

于 2011-04-21T14:32:42.460 に答える
2

これは非常に一般的な質問であり、データベースのバックエンドを考慮していません。負荷を処理できないデータベースバックエンドで40台または1000台のマシンを使用して起動しても、何も起こりません。このような問題は、特定の方法で答えるには本当に広範です。まず、DBレベルで十分なスキルを持った組織内の人々と連絡を取り、次に、より具体的な質問に戻る必要があります。

于 2011-04-12T08:05:57.187 に答える
2

最も簡単なことは、1台のコンピューターに新しいディメンションアイテムIDの配布を任せることです。ディメンションごとに1つ持つことができます。ディメンション処理コンピューターが同じネットワーク上にある場合は、それらにIDをブロードキャストさせることができます。それは十分に速いはずです。

23次元のスタースキームでどのデータベースを使用する予定でしたか？パフォーマンスのボトルネックは、インポートだけではない可能性があります。分散メインメモリシステムでこれを実行することをお勧めします。これにより、多くの材料化の問題を回避できます。

相関性の高いディメンションがあるかどうかを調査する必要があります。

一般に、大きな次元を持つ23次元のスタースキーマでは、標準のリレーショナルデータベース（SQL Server、PostgreSQL、MySQL）は、データウェアハウスの質問に対して非常に悪いパフォーマンスを示します。全表スキャンを実行する必要をなくすために、リレーショナルデータベースはマテリアライズドビューを使用します。23次元では、十分な余裕がありません。分散メインメモリデータベースは、全表スキャンを十分に高速に実行できる可能性があります（2004年に、DelphiのPentium 4 3 GHzで約800万行/秒/スレッドを実行しました）。Verticaは他のオプションかもしれません。

別の質問：zipしたときのファイルのサイズはどれくらいですか？これにより、実行できる正規化の量を1次で見積もることができます。

[編集]私はあなたの他の質問を見てきました。これは、PostgreSQL（またはMySQLまたはSQLサーバー）には適していません。クエリ結果をどのくらい待ちますか？

于 2011-04-21T15:40:37.773 に答える
1

Rohita、

データベースの外部で最初にデータを要約することにより、負荷から多くの作業を排除することをお勧めします。SolarisのUNIX環境で作業しています。cut私は、ファイルをより管理しやすいチャンクに分割し、それらのチャンクを他の2つのサーバーに均等にファームアウトするkorn-shellスクリプトに傾倒します。nawkスクリプト（nawkには「連想配列」と呼ばれる効率的なハッシュテーブルがあります）を使用してチャンクを処理し、個別の値（ディメンションテーブル）とファクトテーブルを計算します。表示された各新しい名前をこのディメンションのインクリメンターに関連付けてから、ファクトを記述します。

名前付きパイプを介してこれを行うと、「ホスト」コンピューターがそこに座ってデータをテーブルに直接ロードしている間に、データを「オンザフライ」でプッシュ、処理、リモート、およびリードバックすることができます。

2億行のデータ（ギグはいくつですか？）をどのように処理しても、時間がかかることを忘れないでください。楽しんでいるようですね。他の人がこの問題に取り組むことを提案する方法を読むのは興味深いです...古い格言「それを行うには複数の方法があります！」そんなに真実ではありませんでした。幸運を！

乾杯。キース。

于 2011-04-27T08:16:39.073 に答える
0

別の注意点として、WindowsServer用のWindowsHyper-Vクラウドコンピューティングアドオンを利用できます：http：//www.microsoft.com/virtualization/en/us/private-cloud.aspx

于 2011-04-26T18:42:43.907 に答える
0

1 MB /秒（50GB / 15時間）未満の速度で読み込まれるため、実装は非常に非効率的であるようです。

最新の単一サーバー（2x Xeon 5690 CPU+ハッシュテーブルにロードされるすべてのディメンションに十分なRAM+8GB）で適切に実装すると、少なくとも10倍の速度、つまり少なくとも10MB/秒が得られます。

于 2011-07-21T17:18:51.157 に答える