4

スター スキーマとして編成された稼働中の MySQL データ ウェアハウスがあり、ETL プロセスを作成するために Talend Open Studio for Data Integration 5.1 を使用しています。このプロセスを 1 日に 1 回実行したいと思います。ディメンション テーブルの 1 つ (dimUser) には、約 200 万のレコードと 23 の列があると見積もっています。

Talend で小さなテスト ETL プロセスを作成しましたが、これは機能しましたが、毎日更新する必要があるかもしれないデータの量を考えると、現在のパフォーマンスでは不十分です。ETL プロセスでは、dimUser に 1,000 レコードを UPDATE または INSERT するのに 4 分かかります。レコード数と UPDATE または INSERT にかかる時間との間に線形関係があると仮定すると、ETL が 3 ～ 4 時間 (私の希望) で完了する方法はありません。

私は Java に慣れていないので、ETL を Python スクリプトとして作成しましたが、同じ問題に遭遇しました。ただし、INSERT のみを実行すると、プロセスがはるかに高速になることがわかりました。ボトルネックは UPDATE ステートメントが原因であると確信しています。

dimUser の主キーは自動インクリメント整数です。私の友人は、この主キーを破棄して、複数フィールドの主キー (私の場合は 2 ～ 3 フィールド) に置き換えることを提案しました。

ウェアハウスからテスト データを取り出してスキーマを変更する前に、関連する提案やガイドラインを提供してもらえますか

  1. データ ウェアハウスの設計
  2. ETL プロセス
  3. 毎日数百万件のレコードを ETL プロセスで INSERT または UPDATE することがどれほど現実的か
  4. 私の友人の提案は大いに役立ちますか

さらに情報が必要な場合は、お知らせください。投稿します。

更新 - 追加情報:

mysql> describe dimUser;
Field                        Type                Null Key Default            Extra
user_key                     int(10) unsigned    NO   PRI NULL               auto_increment
id_A                         int(10) unsigned    NO       NULL
id_B                         int(10) unsigned    NO       NULL
field_4                      tinyint(4) unsigned NO       0
field_5                      varchar(50)         YES      NULL
city                         varchar(50)         YES      NULL
state                        varchar(2)          YES      NULL
country                      varchar(50)         YES      NULL
zip_code                     varchar(10)         NO       99999
field_10                     tinyint(1)          NO       0
field_11                     tinyint(1)          NO       0
field_12                     tinyint(1)          NO       0
field_13                     tinyint(1)          NO       1
field_14                     tinyint(1)          NO       0
field_15                     tinyint(1)          NO       0
field_16                     tinyint(1)          NO       0
field_17                     tinyint(1)          NO       1
field_18                     tinyint(1)          NO       0
field_19                     tinyint(1)          NO       0
field_20                     tinyint(1)          NO       0
create_date                  datetime            NO       2012-01-01 00:00:00
last_update                  datetime            NO       2012-01-01 00:00:00
run_id                       int(10) unsigned    NO       999

代理キーを使用したのは、それが良い習慣であると読んだからです。ビジネスの観点から、潜在的な不正行為に注意したいので (200 日間、ユーザーが状態 X に関連付けられ、その翌日には状態 Y に関連付けられているとします。移動したか、アカウントが移動した可能性があります)。そのため、地理データが保持されます。フィールド id_B には、関連付けられた id_A のいくつかの異なる値が含まれている可能性がありますが、個別の (id_A、id_B) タプルを知りたいと思っています。この情報のコンテキストで、私の友人は (id_A, id_B, zip_code) のようなものを主キーにすることを提案しました。

毎日の ETL プロセスの大部分 (>80%) では、次のフィールドのみが既存のレコードに対して更新されると予想しています: field_10 - field_14、last_update、および run_id (このフィールドは私の etlLog テーブルへの外部キーであり、 ETL 監査目的)。

4

1 に答える 1

1

ここにあなたの質問に対する私の考えがあります。

1) 倉庫の設計:

Ralph Kimball の本: The Data Warehouse Toolkit を読んでください。

ディメンション テーブルに意味のない名前の列がたくさんあります。field_5 の代わりに、ビジネス上の意味を持つ名前を列に付ける必要があります。データ ウェアハウジングは、ビジネスおよびレポート担当者によるクエリを容易にするためのものです。

ここにはファクト テーブルが表示されません。ユーザー ディメンションの用途を理解することは、その設計において重要です。

2) ETL プロセス

ETL プロセスのボトルネックがどこにあるかを特定しましたか? ソースからのデータの読み取り、そのデータの変換、またはデータベースへの書き込みですか? 1 秒あたり 40,000 行で書き込みを行っている場合でも、XML データ ソースから 1 秒あたり 1,000 行しか読み取ることができない場合、それほど遠くまで到達することはできません。

変更されたレコードを最初にデータベースのステージ テーブルにロードし、変換せずに、次に SQL を使用してデータを変換および更新することを検討しましたか? 多くの場合、データベースでのパフォーマンスは、作業を ETL ツールにオフロードするよりも優れていることがわかります。

3) ハードウェアが処理できる場合、毎日数百万のレコードを更新することは非常に現実的です。変更を上書きするだけのタイプ 1 のディメンションを使用する場合 (この場合、変更行を削除してから挿入する方が、update/else/insert よりも適切なオプションである可能性があります) を理解することが重要だと思います。

タイプ 2 のディメンションで変更履歴を保持している場合は、別のミニディメンションで変更を追跡するフィールドをスノーフレーク化することを検討してください。Kimball は、「顧客」の次元が非常に大きい場合のこの手法について説明しています。次に、定期的なスナップショット ファクト テーブルを使用して、時間の経過に伴うユーザーの変更を追跡できるようにします。

4) 自然なビジネス キーから主キーを作成するという友人の提案は、データ ウェアハウス環境には適していません。整数の代理キーを作成して、ファクト テーブルに含めることができるようにします。これは、ディメンション テーブルよりも桁違いに大きくなるためです。

于 2012-07-05T18:28:21.737 に答える