データリネージとデータの来歴は、一緒に使用されることが多いですが、データの流れの異なる側面に焦点を当てています。

• データリネージは、マクロ、履歴、戦略的な観点からデータの流れを把握します。データアセットの現在の状態に至るまでの完全なパスと変換ロジックに焦点を当てます。これはマップ全体です。
• データの来歴はより細かく具体的で、多くの場合、特定の時点における特定のデータポイントまたはレコードの直接的なソースと所有権に焦点を当てます。データの出所を認証するために使用されることがよくあります。

つまり、リネージは、時間の経過に伴う、さまざまなシステムにわたるデータの進化全体を示すのに対し、来歴は多くの場合、特定のデータ要素のソースと信頼性に焦点を当てます。

優れたデータリネージ マップがあれば、あらゆるデータアセットについて「誰が、いつ、どこで、何を、なぜ」という疑問にすばやく答えることができます。追跡される重要なコンポーネントは次のとおりです。

• ソース: トランザクション データベース、ファイル、外部システムなど、データの発生元
• 変換ロジック: データに適用される特定のオペレーションまたはビジネスルール。これには、SQL クエリ、Python スクリプト、ETL（抽出、変換、読み込み）ジョブのロジックなどがあります。
• パス / フロー: データが移動するシステム、プロセス、データストアのシーケンス
• 時間 / バージョン: データが処理された時間と、使用されたデータまたは変換ロジックのバージョン
• 宛先 / 利用者: データの最終的な保存場所と、規制レポートやマシンなど、データを使用した人またはもの

データリネージは、データ開発ライフサイクルのさまざまな段階で、必要に応じてさまざまな詳細レベルで追跡できます。

設計時リネージは、開発環境やテスト環境で設計、構成されたデータフローをキャプチャします。これは、スキーマ、スクリプト、ETL ジョブ構成といったデータ パイプラインのブループリントの読み取りに基づいており、データに対して何を行うべきかを示します。

実行時リネージは、本番環境で実際に発生したデータフローをキャプチャします。実行されたジョブとプロセスの具体的な入力と出力を記録します。これは予期しない動作やエラーなど、データに何が起こったかを伝えるものです。実行時リネージは現実を反映しているため、データ ガバナンスでは、こちらの方がより価値があるとみなされます。

キャプチャされる詳細のレベルは、粒度と呼ばれます。組織は、データ ガバナンスのニーズと環境の技術的な複雑さに基づいて粒度を選択します。

• テーブルレベル: テーブルまたはデータセット全体でのデータの流れを追跡します。たとえば、「顧客テーブル A」から「販売レポート テーブル B」への流れを示します。
• 例: raw_transactions テーブル全体が daily_aggregations テーブルに読み込まれたことを示します
• 列レベル: ソース列からターゲット列へのデータの流れを、適用された変換を含めて追跡します。これは、コンプライアンスのために必要になることがよくあります。
• 例: ソース データベースの customer_id 列がデータ ウェアハウスで user_key に名前が変更され、これを結合の一部として使用して final_report が作成されたことを追跡します。
• レポートレベル: どのレポート、ダッシュボード、アプリケーションが、どのテーブルと列を使用しているかを追跡します。これは、インパクト分析とビジネス ユーザーの信頼に不可欠です。
• 例: ビジネス アナリストは、経営幹部向けセールス ダッシュボードの指標を、その計算に使用された特定の列とテーブルまで遡って確認できます
• エンドツーエンド: 初期のソース アプリケーション（CRM など）から、すべてのステージング、クリーニング、変換ステップを経て、最終的なレポートや ML モデルまで、すべてのシステムにわたる包括的なビューを示します。
• 例: ウェブアプリのデータベースに記録された最初の登録時から、チャーン予測モデルの出力に利用状況が要約されるまでの 1 人の顧客の行動を追跡します