私は、データウェアハウス開発者が必要とする可能性のあるメタデータ要件のリストを提供する任務を負っています。
これはビジネスメタデータ（適切な説明など）ではなく、変更管理（影響評価とも呼ばれます）、データ系統などに必要なデータです。
私はこの記事メタメタデータデータ-ラルフキンボールを見ましたが、私はこれを行う最初の人ではないので、SOコミュニティにそれを投げています。
実際の質問は次のとおりです。データウェアハウスの開発者は、ETLルーチンの変更を設計、開発、および管理するためにどのメタデータを必要としますか？
PS：回答プラットフォームにとらわれないようにしようとしていますが、コンテキストとしては、これはPL/SQLとDatastageを備えたOracleデータベースです。
私の職場には、自作のETLがあります。私はあなたが眉を上げるのを見ることができます:)。私たちが持っている最小限のメタデータは、次のことを説明しています。サブスクリプションの詳細、監査、データマッピング、実行順序。
サブスクリプションの詳細は、データの購入元のベンダーと、データを使用するチーム/アプリケーションの2つのカテゴリに分類されます。ftp / httpの詳細、アクセス資格情報も保存されます。幸い、SPは絶対にゼロにするように求められましたが、主な例外は「IDジェネレーター」です。
監査の詳細には、データの日付、最終更新時刻、それを実行したユーザー、失敗/成功の数が含まれます。
データマッピングテーブルは、データを保持するテーブルと列名を記述します。以前は、追加の複合キー記述子テーブルがありました。しかし、私たちはそれを廃止することにしました。パフォーマンスの低下は、データテーブルの所有者に適切なパーティション戦略を作成するように依頼することで補われました。
Run_orderテーブル は、ユーザーが実行できるかどうか（Y / N）と実行の順序を決定する別のテーブルです。
メタデータも履歴（日付に基づく）とともに保存されます。したがって、誰かがアーカイブ/履歴サブスクリプションを実行することを決定した場合。実行は先に進みます。
上記の使用法：サブスクリプションの重要性に基づいて、データのロードに優先順位を付けることができます。一般的なレベル（鳥瞰図）で障害を監視できます。動的SQLクエリを作成できるジェネリックコードを記述できます（ハードコーディングなし）。ロードおよび抽出プロセスはデータマッピングテーブルを使用するように強制されるため、ユーザーは古い情報から逃れることはできません。
これは私たちの経験ではこれまでのところうまくいったようです。
最も基本的なレベルでは、ソースシステムから抽出されたtablename.fieldnameのリストを維持できます。ファイルまたはその他のデータベース以外のソースから抽出する場合は、フィールドレベルと同じくらい詳細な依存関係を一覧表示できる場合とできない場合があります。このようなメタデータは、If（ソースフィールド/ファイル形式/テーブルの変更）then（ETLプロセスで何らかの変更が必要になる場合があります）のみを通知します。一部の変更はETLプロセスが壊れないほど小さいためかもしれませんが、ETLプロセスの初期設計中に行われた仮定が無効にならないように、テストとデータプロファイリングを実行する必要があります。
ETL開発者はソースシステムとETLプロセスに精通しているかもしれませんが、大規模なETLプロジェクトの場合、ソースシステムの各依存関係をETLシステムの特定のプロセス/コンポーネントに関連付けるのが賢明でしょう。たとえば、ETLプロセスが多くのストアドプロシージャで構成されている場合は、メタデータで各ソースシステムのフィールド/ファイル形式/テーブルなどを関連付ける必要があります。各ストアドプロシージャに。多くのストアドプロシージャは特定のフィールドに依存する可能性があり、単一のストアドプロシージャは多くのソースフィールドに依存する可能性があるため、これは多対多の関係になります。これは、ETLシステムを作成または更新するときに、ETL開発者が手動で更新するものです。
ETLシステムがストアドプロシージャ以外の何か、またはそれらの組み合わせによって駆動されている場合は、これらのコンポーネントを参照するための命名スキームを考え出す必要があります。しかし、概念は同じです。ソースフィールド/ファイル形式などを関連付けます。ETLシステムのコンポーネントに。
これにより、ソースシステムで「Person.FirstName」が何らかの方法で変更された場合に、検証、更新、および対処するためのテストが必要なすべてのストアドプロシージャを示すレポートをコンパイルできるという十分な情報が得られます。ソースシステムの変更に伴い。
この種の意味は、Person.FirstNameがサイズ、データ型、または完全に削除された方法で変更されたことを知るには、データベース設計者を介して変更を通知し、それに応じてアクションを実行する手動の手順が必要であることを意味します。非常に洗練されたシステムが必要な場合は、ソースシステムを変更するトリガー/監査をDDLに設定して、ETLアーキテクトに変更を自動的に記録して通知できるようにする必要があります。
このような変更が発生した場合、sp_Person_Load、sp_Person_Clean、sp_Person_Transformストアドプロシージャはすべて、Person.FirstNameフィールドを処理することがあります。これは、これらのストアドプロシージャの作成者が、依存関係を文書化するメタデータに記載しているためです。
sp_Person_CleanがPerson.Firstnameに依存せず、実際にはsp_Person_Loadに依存する場合は、さらに複雑にすることができます。依存関係のチェーンを構築するように。これにより、ソースシステムの変更の影響を判断するために依存関係をチェーン化する必要があるため、変更に関するレポートがより複雑になります。また、複雑な一連の依存関係と潜在的な循環参照を構築しているため、ETLプロセス自体を維持するのと同じくらいメタデータを維持することが困難になる可能性があります。ETLシステムが十分に単純で、ETLアーキテクトがソースシステムのフィールド/ファイル/テーブルに関して依存関係を定義できる場合は、それを実行して、物事を単純に保ちます。
データウェアハウス、宛先システムに対する権限を誰が持っているかによっては、これらの依存関係を追跡する必要がある場合があります。多くの場合、ETL開発者はデータウェアハウス開発者でもあります。ただし、他の誰かがデータウェアハウスの設計者であり、データウェアハウスに変更を加える権限を持っている場合、ETL開発者は、変更を追跡して通知するために、自動か手動かにかかわらず、同様のシステムを使用する必要があります。そしてそれらがETLプロセスに与える影響。
本当に、変化をどのように追跡すべきかを考えるとき、私は権威の境界について考えます。ETL開発者がsp_Person_Cleanプロシージャを変更した場合、sp_Person_Transformを更新/テストする必要があることを示すためにemtadataは必要ありません。彼はすでにこれを非常に直感的に知っています。一方、サードパーティ/ベンダーシステムが変更された場合、または同じ組織内の事業部門がスプレッドシートまたはファイル形式を変更した場合、それらはETL開発者によって制定されたものではありません。彼は、独自のETLシステムやデータウェアハウスの場合と同じレベルのソースシステムとの親密さはありません。したがって、彼は、ソースシステムのコンポーネントがETLシステムのコンポーネントにどのように関連しているかを示すメタデータから最も恩恵を受けるでしょう。
「コンポーネント」をどの程度細かく定義するかは、システムの設計方法と、開発者に文書化するメタデータの量によって異なります。細かすぎると、メタデータに溺れてしまいます。もちろん、「私の家はフロリダにあります」と言っているようなものですが、ETL開発者の仕事にはあまり役立ちません。ETLプロセス全体が単一のSQLスクリプトでコーディングされている場合、コンポーネントは1つだけです。したがって、ETLプロセスの特定のコンポーネントやステップを参照できる必要があることを認識して、システムを事前に設計する必要があります。
メタデータは、開発者がメタデータの更新に熱心に取り組んでいる場合にのみ有効です。この種のメタデータを自動的に更新できるシステム/ツールキットがありますが、ツールが依存関係を分析できるように、ツールキットにボックス化する必要があります。私はこれらのシステムが非常に信頼できるとはほとんど確信していません。ソースシステムから宛先に目的の形式でデータを取得するために、本当にハックなことをしなければならないことがよくあります。依存関係アナライザーが依存関係を理解できなかったと想像できます。たとえば、文字列から形成された動的SQLを使用していた場合、ツールキットは依存関係が何であるかを実際に把握することはできません。
ただし、ツールがどれほど優れているかを実際に知るために、ツールを深く掘り下げたことは一度もありません。私はいつも、SQLで通常は簡単なことがツールで非常に面倒であることに気づき、それが価値があるよりも厄介であると判断しました。私はTalendのようなものを手に入れて、最終的な評決を下す前に本当にそれの専門家になると自分に言い聞かせていますが、他の方向に私を引っ張っている他の優先事項が常にあります。