5

BIの顧客がいて、販売トランザクションから生成された販売データベーステーブルに毎月約4,000万行を生成しています。彼らは、5年間の履歴データを使用して販売データマートを構築したいと考えています。つまり、このファクトテーブルには約2億4000万行が含まれる可能性があります。（40 x12か月x5年）

これはよく構造化されたデータです。

Imがこの量のデータに直面したのはこれが初めてであり、Inforbrightやその他のツールのような垂直データベースツールを分析するために私を連れて行きました。しかし、それでもこの種のソフトウェアでは、単純なクエリの実行に非常に長い時間がかかります。

これでHadoopを確認しましたが、いくつかの記事を読んだ後、Hadoopはファクトテーブルを作成するための最良のオプションではないと結論付けました。私の理解では、非構造化データを処理することを目的としているためです。

だから、私の質問は：この課題を構築するための最良の方法は何でしょうか？、私は適切なテクノロジーを探していませんか？このような大きなファクトテーブルで取得できる最高のクエリ応答時間はどれくらいですか？..または私はここで実際の壁に直面していますか？唯一のオプションは集約されたテーブルを構築することですか？

4

6 に答える 6

4

ニーズに合った Google BigQuery (有料プレミアム サービス) をチェックアウトしましたか。それは次のように簡単です

  1. データを CSV に読み込みます (レコードの場合は改行、フィールドの場合は構成可能な文字で区切られます)。ファイルは gzip 形式にすることができます。既存のテーブルに追加することもできます。

  2. SQL ステートメントを使用してクエリを開始すると (限定された sql ステートメント)、結果は数百万行の秒単位で返されます。

  3. データを CSV または別のテーブルに抽出します (集計レイヤーと同様)。

こちらをご覧ください。https://developers.google.com/bigquery/

データ処理の最初の 100 GB は無料です。したがって、今すぐ始めることができ、管理用のチャートやグラフなどの視覚化を作成できる Google スプレッドシートとも統合されています。Google スプレッドシートを Microsoft Excel / PDF としてエクスポートできます。

Google は、数テラバイトまで拡張でき、リアルタイムのクエリ (数秒の応答) を提供すると述べています。

于 2012-06-08T01:24:08.480 に答える
2

最初に、2400m ではなく 240m だと仮定します。

まず、ssd.analytical-labs.com をご覧ください。

FCC のデモには、Infobright で実行されている 150m のレコード ファクト テーブルがあり、VW ではさらに高速になるのではないかと思います。

重要なのは、それをシンプルに保つことです。遅くなるクエリがありますが、かなり反応が良いです。

集計、クエリの方法、そして重要なことに何をクエリしているのかについて考えることをお勧めします。

たとえば、パフォーマンス別、製品別、ブランド別、年別などでマートに分割します。ユーザーが 1 年未満のデータに対してクエリを実行したい場合 (これは、ほとんどの人が考えているよりも多くの場合に当てはまります) ) その後、はるかに小さなファクト テーブルを使用できます。

ストレージは安価なので、応答性が保たれている限り、データを複製しても特に問題ありません。

もちろん、OLAP を実行している場合は、インライン集計テーブルを使用して、ほとんどのクエリがロールアップされていると仮定して、はるかに許容可能なレベルで実行されるようにすることができます。

ハードウェアも非常に重要です。高速なディスクを用意してください。これがほとんどの場合ボトルネックになります。ディスクからデータを高速に取得できるほど、一般的にエンド ユーザーに表示される速度が速くなります。

スキーマの設計も重要です。最新の列ストア データベースは、可能であれば結合が 0 の非正規化テーブルを非常に好みます。私は過去に、クエリの 90% に対して 1 つの非正規化テーブルを持ち、次にいくつかの結合テーブル (たとえば、日付の薄暗い) を持っていることを発見しました。特殊なケースは、ほとんどのユース ケースに当てはまります。

とにかくそれは私の 2 セントです。スカイプか何かが必要な場合は、ツイッターで私に連絡してください。

トム

編集：

また、JVD の発言を裏付ける非科学的なベンチマークは次のとおりです。

  • 物理ボックスの SSD: 175.67 MB/秒
  • 物理ボックスの sata: 113.52 MB/秒
  • ec2: 75.65 MB/秒
  • ec2 ebs レイド: 89.36 MB/秒

ご覧のとおり、読み取り速度に大きな違いがあります。

于 2012-06-07T19:05:46.750 に答える
2

ここにはいくつかのアプローチがあると思いますが、

1) mondrian で集計テーブルを試す必要があります。集計テーブルの欠点は、ほとんどの再帰クエリのユース ケースを事前に知っておく必要があることです。集計テーブルを最適化しなかったクエリの応答時間。

2) 別のオプションは、ファクト テーブルのデータを年ごとに分割し、年ごとに異なるスキーマを作成し、履歴全体の仮想キューブを作成することです。適切なソフトウェアがあれば、マテリアライズド ビュー (Oracle の場合) またはインデックス ビュー (MS SqlServer の場合) を作成することもできます。

遅いアプローチは私にとって非常にうまく機能し、クエリ時間の顕著な改善が見られました。さらに、RDMBS がすべてのパーティションのデータを更新するプロセスを処理するため、ETL プロセスは影響を受けませんでした (オプション 1 では、集計テーブルを構築および維持するために追加のプロセスを作成する必要があります)。

于 2012-06-07T22:34:09.550 に答える
1

DataStaxEnterpriseなどのパッケージ化されたNoSQL/Analysisソリューションを検討することもできます。これは、 ApacheCassandraをHadoopやその他の便利な分析ツールと組み合わせて使用​​します。Hadoopの「デフォルト」のHDFSファイルシステムは非構造化データに最適ですが、NoSQLデータストア（CassandraやHBaseなど）と統合すると、MapReduceを使用して構造化データをより簡単に分析できます。

于 2012-06-07T18:50:49.083 に答える
1

私が非常に大規模なデータ ウェアハウスに使用して成功したもう 1 つのテクノロジの組み合わせは、Hadoop + Hive です。Map/Reduce ジョブを使用してデータを操作し、外部テーブルとして Hive に提示しました。更新は、ステージとデータ ウェアハウス領域の間でパーティションを交換することによって実行されました。

このアプローチの大きな利点は、データに対して (ほぼ) 通常の SQL クエリを実行できることです。欠点は、Hive バックエンドをインタラクティブ UI フロントエンドに接続できないことです。しかし、毎日のレポートとデータマイニングを実行するだけであれば、これでうまくいくはずです。

于 2012-06-07T19:31:34.943 に答える
0

Hadoop は、このようなビッグ データに最適です。hbase と組み合わせて使用​​すると、数百万の行と数十億の列に拡張でき、優れた水平方向のスケーラビリティも提供されます。リアルタイムのランダム読み取り書き込みアクセスに適しています。一方、Hive はバッチ処理に適しているため、他のタスクのバックグラウンドで Hive ジョブを実行できます..hadoop を従来の RDBMS の代替と間違えるべきではありませんが、巨大なデータ セットを扱うのに非常に役立ちます..別の apache プロジェクト「sqoop」を使用すると、既存のデータベースからデータを Hadoop クラスターに簡単にインポートできます。

于 2012-06-07T19:05:25.673 に答える